The Model Driven Software Network

Raise your level of abstraction

Dear community,

as a new member of the MDSN I'd like to introduce myself and my company's product EM/OS. I'm generating code since about 1988 (bison, flex & co then, first template driven C generator in 1990) and have experienced the CASE and MDA hype around '90 and '00 as well as endured the "Trough of Disillusionment" afterwards - still committed to CG/MD.

Our goal was and still is a complete, executable, comprehensible and maintainable single source model for enterprises - maybe that's what it is all about anyway for all of us here - more or less disenchanted, more or less enthusiastic (20 years ago it all seemed so easy).

Starting with the plain CASE approach of "make code from model", then introducing abstraction layers in the model and thereby doing something like MDA/PIM/PSM, we developed several additional concepts and components and integrated them into our system. The major one's of these additions are listed and commented below. Since all of them matured over the years it is difficult to put them in a timely order, so the ordering is more or less meaningless.

While we like and support the idea of open source, our product is partially open, and partially commmercial. We do not see currently enough benefits of converting everything into OSS, maintaining a community is not for free. Maybe we do so some day. Nevertheless, in addition to our OSS components we provide already, I like to share and discuss concepts in an open fashion as much as possible - some of the websites mentioned below are intended as an heartily invitation to so.

Our product is called "EM/OS - Enterprise Model Operation Services". "EM" is clear, "Operation" implies that we generate, compile and interprete and that from a usage perspective this is considered unimportant: the model is just operated. "Services" implies the decomposability into independent parts, maybe "EM/OC" would have been more appropriate, but "Services" seemed more fashionable.

The concepts and components are:

1. VUI - Virtual User Interface

Around '90, while generating UI code for PCs, Workstations and plain ASCII terminals, our templates became more and more unreadable and intermangled - a better approach was needed. The problem of generalized UIs was that it is difficult if not impossible to find a good abstration over different types of UIs. Interestingly enough (20 years later!), many UI approaches today still try to find that kind of abstraction. The key in my opinion is the reversal of the abstration direction: do not look from code to UI, but look from UI to code. I.e., apply the MVC idea more rigidly. This leads to the M3V pattern ( and in consequence to a new application layer we call "Virtual User Interface". This layer provides an interface which is independent of business layer specifics, as well as independent from any specific presentation media. It is used by socalled "frontend adapters (FEA)", and it is implemented by binding it to a given business layer. This binding then is what is left to generate from the model, or provided by interpretation of a model, or provided by e.g. java annotations, i.e. a "model in the code".

2. Business Logic Interaction

Being independent from business layers, there is no room left for "UI Logic" in the VUI/FEA layers anymore - which is good. But where to put that homeless logic? Another layer materialized in our code, the "Business Logic Interaction (BLI)" layer. It contains factories, editors, retrievers, workspaces and transactions, but not the core business objects, which stay in the "Business Logic Core (BLC)" layer. BLC is just a more specific name for the classical Business Layer. The BLI objects are not related to user interface mapping at all, they merely contain code for interaction with business objects.

Summarizing that, you may say:
- the BLC contains plain business objects
- the BLI provides all functionality required to operate the application, but it is neither convenient nor safe
- the VUI provides all the functionality in a safe and convenient manner, including texts, help and all this stuff, but it is still a plain programming API, not related to presentational issues
- a FEA renders the VUI to a specific frontend (HTML, Desktop UI, mobile UI, etc.)

Of course, the BLI and BLC are in most cases created from a model, too. There is a library of parameterizable standard BLI building blocks, e.g. for creating, editing or deleting business objects. By choosing such a library, the application behaviour can be adopted to specific needs; this tuning is part of a socalled "application profile" (see also XModel below).

3. Transparent State Management

As a side effect we more discovered then developed, the BLI provides good hooks to attach database transaction management code to, since the "transactions" in the BLI are a representation of just that: application domain transactions, which are strongly related while not identical to database transactions.

4. OCP - Object Construction Plans

Beginning with an XML test data import tool, this component evolved into an indispenable part of our system. It is an open source component, see It assembles object instances into object aggregates - but has a bunch of much more powerful features than just that; see e.g. the next topic. Today, in our code, there are 15 % of OCP files compared to Java files, the number constantly increasing.

5. Dynamic Model Transformations with OCPs

We perform our model transformations with these OCPs. Basically, this acts like a Table View in relational databases, but it's an "OO View". I.e., you define your target objects in a clear, declarative XML syntax, while accessing an underlying object model dynamically. We use these "Dynamic MDA OO Views" for "PIM/PSM"-like transformations as well as for "DSL/PIM"-like ones. The latter is specifically interesting, since it is possible with the OCP approach to define something like "DSL macros", thereby allowing a smooth step by step evolvement from a "PIM" to a "DSL".

6. XModel Properties and Application Profiles

During M2M or M2T in addition to the core model usually a large amount of properties is needed to control the transaformations. We organize them as follows: First, all properties are grouped by putting them into classses. E.g., there is class called "XMPresentation" (XM = XModel = "Extended Model Properites") which contains all properties related to presentation (name, description etc.).

Now these XM-Classes can be placed at Model Classes. This still leeds to overloaded models in the long run. For a while, we tried the approach of separating the properties into another model, but this leads to dependencies between remote model parts which are difficult to understand and maintain. Therefore we placed them at stereotypes, and added an elaborated property interpretation mechanism to our model.

In short, stereotypes can contain XM-Classes too, XM-Classes can be made sensitive to target types (if the stereotype is used e.g. at an attribute), moreover stereotypes can be derived from one another and a class can have several stereotypes. Properties are looked up in the nearest scope: instance, direct stereotype, chain of super stereotypes. To complete this, properties are in several ways context sensitive: they can contain placeholders and code which are interpreted or executed in several possible stages form processing the model into the final runtime application or even frontend client context.

These means have to be used careful: while it is possible to write completely incomprehensible properties, it is also possible to create well organized stereotype libraries, which are another important part of our socalled application profiles. Using this approach, the final customer project model contains only very few properties directly (most of them are presentation properties), while the majority of them are implicitly referenced by a few stereotype markups at the model classes.

7. OOEM and ASM

Not a different concept, but a name for a combination of concepts, is our "OO Enterprise Model" , which is a general language for PIMs, expressed as a formular:
  OOEM = UML + XModel + OCP + UBPML (see below)
Speaking of names, our "PSM" is called "ASM Architecture Specific Model", since it is still independent of platform features like a specific frontend media or a specific database.

8. OO Generator

The M2T part; we use our own technology for code generation for two reasons: first, switching to another technology is always some effort, and secondly, it provides certain features which are important to us to maintain clear, comprehensible and maintainable templates. This technology is open source, too, see . Please note that the tutorial is currently poorly incomplete there. The most visible feature of the generator is probably the "Unicode Syntax", which allows to write compact code. If you don't like it, there's a JSP like syntax available, and if you dislike both you may happily discover the modular architecture of the generator. Not so visible, but even important is the "OOness" of the approach. Nowadays, we do not see any purpose in advertising a code generator. There are lot's of them. Love it or hate it.

9. OOModels Repository

Our apporach to community modelling is based on the mediawiki software with extensions to write classes in the "WIML Wiki Modelling Language" as well as in arbitrary text based formats. The server provides the technology to convert between different formats, the conversion is also defined in wiki pages containing templates (xslt, our generator etc.) See

10. Unified Business Process & IT Systems Modelling

Finally, since BPM became more and more important in the business management and IT systems area we have to face the challenges given by that. A bunch of redundant and inconsistent models in the company is a source of conflict and a sink of money. With our initiative of we try to advance the idea of re-unified modelling of processes and structures in an object oriented manner and providing means to really bridge the gap between business and IT. Currently we're working on a tight integration of UBPML and OOEM, which is at the time being still too loose.

I'm looking forward to comments and interesting discussions!

Kind regards,

Views: 31

Reply to This

Replies to This Discussion

Thank you for a very good insight on the evolution of your development. You have a strong focus on business applications, making it unsuitable for any other domain, which is actually OK if you are intending to focus on a single market.

Also, having your "open-technology" sites in German is a major blocking issue, IMHO.
I'd say that, if you are going to see it as a domain, "business applications" is a very large one. I'd go as far as saying that the majority of software already and to be written would fall into that domain, so if one targets exclusively enterprise/business applications, that is hardly limiting.
The focus of EM/OS is certainly business applications, as far as we are concerned, the corresponding market is by all means sufficient. From a technical point of view this is also a limitation, it's not, let's say, embedded. This applies to our specific model (OOEM) as well as the transformations. It does not equally apply to all components, there are about 45 of them, they have to be judged separately.

As for German: my apologies! The sites (oogenerator & xocp) are in a poor state. Nevertheless, there are (perfectly hidden) english pages. For OCPs goto, on the left in the box saying "deutsch" select "english", then go to menu "Tutorial", (ignore the "soon" text), click the down arrow, and then press the forward arrow (there are some blank pages inbetween which is a bug, in fact there is text). The same applies to, but it's worse, since there are missing images. Perfectly intuitive. Again: sorry for that mess, there's no excuse and we have to move this up in our priority.
The translation of site

(which is about BPM, suitable for MDSD) is completed.

(following is work on and




© 2018   Created by Mark Dalgarno.   Powered by

Badges  |  Report an Issue  |  Terms of Service