A history of Metamodeling

In 2010 I was happy to welcome Sridhar Yyengar to give a seminar in Nantes with the following title: A (Meta)modeling Odyssey : Future of modeling, metamodeling, tools integration and the semantic web. The abstract is below (1).

Sridhar Yyengar leads the technical strategy group for Software Tools & Methods at the IBM TJ Watson Research Centre and led the definition of OMG MOF and XMI standards, among many other contributions as member of the OMG Board of Directors. Sridhar has been very influential in developing the MOF vision at OMG (Meta Object Facility).

But what we need now is something much broader that the strict MOF historical vision to understand the pertinence of these reflective languages to describe metamodels, their deep goal, structure, usage, rationale and evolution. We need to revisit these metamodel description DSLs and to look carefully at their positioning towards other DSLs and GPLs.

In January 2012 I was giving a course at the National Institute of Informatics in Tokyo and I started looking at the history of these metamodel description languages. I will try to write down some of my notes on this blog in the future. In the meantime, I will be happy to exchange and discuss on this blog  or on Twitter or Google+ with anyone interested in the history of MOF-like languages.

______________________________

(1) Abstract: The past 15 years have seen some very interesting advances in the world of modeling, metamodeling and their use in developing tools and middleware across the complete application lifecycle. Industry modeling standards from OMG and web infrastructure standards like XML, WSDL and more recently semantic web standards like RDF and OWL have made their way into tools that cover the entire application lifecycle for both custom developed as well as packaged application implementations. As we start a new decade what can we expect in the next 10 years? This presentation will summarize the historical journey, take a snapshot of where the industry and related standards are as we begin the new decade. We will have a look at how we expect the world of the internet and semantic web will shape modeling, metamodeling and tools integration over the next decade. We will look at how emerging collaborative application lifecycle platforms like Jazz (www.jazz.net) and emerging standards like SMOF (Semantic MOF) and future versions of UML and BPMN are evolving to address the challenges of the new decade.

Architecture Ecosystem

The Architecture Ecosystem OMG Special Interest Group.

The AESIG initiative at OMG has a focus on interoperability and integration:

We recognize that different groups at different times, with different concerns may address the same concepts in different ways. This can happen by accident or intent. It can result from confusing viewpoints with information metamodels. It can result from political consequences or simply personalities of the people involved. And it happens all the time, over almost any subject one could imagine.

But we also recognize the value of information integration, sharing, collaborative development and the network effect the the promotion of effective information discovery, management and use.

As a result, it may be helpful to examine different approaches to how information can be integrated, their characteristics, and benefits and drawbacks. Then we can layer on top of these different approaches the methods, tools and best practices techniques that would support these different approaches. This information may be helpful in charting an initial course of action for the AE SIG that we can evolve over time.

Different approaches to integration may be found on the AESIG Wiki.

As a more specific discussion of alignment, a previous post may also be relevant.

The Wiki has a pointer on the Zoos (see also post).

See also the Petstore benchmark as a set of linked models (UseCase)

Bits of History (UML/MOF Alignment)

The long story of UML/MOF Alignment

The word alignment has been very often used when there are two divergent views and we need to show a consistency or a correspondence between these views. For example the business/IT alignment is often quoted as an important goal when IT platforms are rapidly changing and when business goals and global context are similarly evolving.

Alignment is related to interoperability or integration. It is particularly important when it comes to guarantee mutual consistency between two dynamically evolving views or situations. Alignment may be partial. It is a concept that is becoming quite popular in software modeling. Wikipedia defines ontology alignment as the process of determining correspondences between concepts (http://en.wikipedia.org/wiki/Ontology_alignment). The notion of model weaving in Eclipse proposed a way to compute, to represent and to enforces the abstract and declarative correspondences between two models by a specific model called the weaving model (http://wiki.eclipse.org/AMW). The AESIG OMG initiative (Architecture Ecosytem Special Interest Group) has the objective of managing the alignments between different recommendations or communities at OMG, UML and SysML or UML and BPMN for example (http://www.omgwiki.org/architecture-ecosystem).

The issue of alignment is more than a technical issue. Since it often involves two different communities, each having its specific goal and roadmap, it may be seen also as an organisational, social and human relation issue. This is why the rise of abstraction, from programming to modeling, often brings to the forefront alignment enforcement difficulties.

As an example of a situation of continuous alignment spanning now on more than fifteen years, we may look at the competition/collaboration between two modeling visions/communities at OMG, the so-called heavyweight and lightweight communities.

As a summary of previous episodes, Ed Seidewitz has nicely reported how UML 1.0/1.1 introduced stereotypes and tagged values for extension and openness, but that the notion of “profile” came later, proposed by himself and Dave Frankel in the context of the Business Object Initiative. I copy below the beginning of this proposal:

It seems clear that these guys were trying to define a new language for business modeling (a DSL for Enterprise Distributed Object Computing) but knew that they would never be allowed to draft a completely stand-alone language that could compete with UML. Very wisely they managed to present this as just a minor variant of UML, and this was not only accepted but encouraged by UML tool vendors because it could be integrated in their products and in their strategy.

Since I was just an observer and I could just attend a meeting from time to time, my reporting may be distorted. At OMG academics are not full players and are just allowed to watch the game. I was just trying to understand and explain what was going on. Digging in my old stuff, I recently found two slides that I used to explain my personal interpretation of OMG ongoing work to my students at that time. The first one shows my understanding of the evolution of modeling languages.

• Phase (a) Since UML is not only unified but “universal”, it is able to describe everything in the computer or business world. As a consequence it should also be able to describe itself.
• Phase (b) UML is mainly for code and the CWMI (Common Warehouse Metadata Interchange) for data. So we need an upper language that could describe at the same time UML and CWMI. Let’s call this upper language the MOF (Meta Object Facility).
• Phase (c) As a matter of fact the MOF may not only define UML and CWMI but also Workflow situations, software process (Process Working Group or PWG to become SPEM later), Component model, Action language, etc. This corresponds to the heavyweight language definition. When the language to define is “closer” to UML, it is possible to take a less expensive way to define it, called ligthweigth extension mode. For example if we wish to define a “UML for Business Objects” or a “UML for C++” or “UML for CORBA“.

It is clear that the lightweight definition mode is perfectly acceptable for UML tool vendors. But what about the heavyweight one? Will people need a different CASE tool to produce and edit MOF metamodels? This was a big concern. Finally there was an agreement that MOF will be allowed to fly only if MOF metamodels may be defined by UML tools. In other words, MOF and UML should be permanently aligned. As a matter of fact, MOF should be aligned with a clearly identified subset of UML .

So this lead us, about fifteen years later, in the same situation, with two different ways to define DSLs, full-fledged metamodels or UML profiles. And during these fifteen years or so, the two communities of MOF and UML orthodoxies have been obliged to maintain the strict alignment.

In retrospect it is quite interesting to analyze this situation.  We can make a number of remarks.

This has been possible under the strong supervision of the AB at OMG (Architecture Board or AB is the “police of OMG”, checking that everything is in line and politically correct).

Technically there are few examples of two different languages having been aligned for such a long period. But now we are starting to understand  why this has been possible. Of course UML and MOF have completely different purposes and semantics. It is complete nonsense to align the semantics of these two languages. The trick has been to align only the concrete syntaxes of MOF and UML. And since UML tools do nearly no semantic work, everybody was happy.

In the few situations where there were small problems, then ad-hoc situations could be found. For example in the Sun MDR/NetBeans system, an open source tool that was quite popular was the UML2MOF tool. This tool may be found as a servlet for example at: http://www.soluta.net/en/page/18/xmi2mof.php

It is funny to notice that when metamodels were mainly paper metamodels, the MOF/UML alignment posed absolutely no problem. The first difficulties emerged only with transformation languages like QVT or ATL when we needed real metamodels. This operation UML2MOF was called a promotion operation because it transformed a model into a metamodel. Later, when transformation tools improved, the need for this operation became less important and this transformation was even proposed as a standard transformation, in the ATL transformation library. It is interesting to note that the reverse operation of demotion (transforming a metamodel  into a UML model).

So, basically the language alignment between MOF and UML was possible because it was an alignment of concrete syntaxes only and the few difficult cases, a simple transformation could do the trick.

But in retrospect, this “strongly encouraged” alignment between MOF and UML had some positive impact to Model Driven Engineering. It contributed to the unification of models (instance or terminal models), metamodels and metametamodels. All these entities are abstract models, i.e. typed graphs.  And this is a noted advantage of Modelware on Grammarware.  In Grammarware, there is no such alignment on the concrete syntaxes of EBNF and Java for example.

From Unified Method to Unified Language

Products and Processes in Software Engineering

Here is a diagram illustrating the history of UML.

When we look at this picture, one remark comes immediately to mind.

Why this change, between 1995 and 1996 from “Unified Method” to “Unified Language“? The reason is that, at this period people realized that there was no possibility to propose a unique software development method. The goal of the OOAD at OMG was not only too ambitious, but is was an impossible mission.

There is an infinity of possible software processes answering the question of who is doing what, when, how and why in the software development and maintenance world.

The decision of OMG to reduce the ambition of this initiative was most clever. The goal was then reduced only to define a language for describing a subset of software artefacts. The name was chosen to be Unified Modeling Language. And the discussions on process description were ignored and delayed for further studies. Only when UML got stabilized in its first versions, people at OMG came back to the problem of process description and this effort finally produced the SPEM contribution (Software Process Engineering Metamodel).

This move was not a surprize and corresponded to the classical separation between process and product in most advanced engineering disciplines (think of chemistry for example).

But the language to describe software artefacts (UML) and the language to define software processes (SPEM) could not be completely independent. The idea was thus to consider them as two languages conforming to a common language as a matter of fact a metalnguage. And this metalanguage already existed at OMG: the MOF (Meta Object Facility).

This is not sufficient to make explicit the relations between SPEM and UML, but at least having both languages expressed in terms of a common metalanguage should facilitate in the future the precise expression of their relations.

Bits of History (The birth of UML)

Niçoise salad, Salade niçoise or Insalata nizzarda

or

How to choose the good ingredients to get a good UML?

In novembre 1996, I was lucky to attend the OMG meeting in Nice, France.  The weather was splendid and at that time OMG was still organizing meetings outside USA, in wonderful places. But this meeting was particularly important because it was there that the main initial decisions about UML were taken.

The big player in the game was Rational (at that time Rational had not been acquired by IBM). The main opposition was coming from IBM, allied to a small canadian company called ObjectTime (Bran Selic was behind this company). The problem was to unify different proposals to the ongoing RFP. I remember having been asked by IBM to present at the time our three-layer metamodeling system (sNets) in a private IBM meeting.   I believe that, at the same meeting,  Trygve Reenskaug also tried to convince them to make the concept of role first class in UML, without more success.

But the rule of the game was different. It was obvious that Rational proposal was going to be overwhelming accepted. The only question was about how. It was difficult to accept 100% of the Rational proposal and 0% of the IBM proposal.  IBM should be allowed to make a marginal contribution to UML.

As a matter of fact, IBM was proposing two important contributions to UML: The schema organization and the OCL annotation language. The guy behind both proposals was Steve Cook (the same Steve that is today still working on UML, but on behalf of Microsoft). Steve was not present in Nice, but he was probably the main artisan of IBM proposal. If I remember well, the IBM negotiation team was led by Dipayan Gangopadhyay (I met him at TOOLS much later and he had left IBM).

The following slide presented the IBM/ObjectTime main contribution:

The proposal was quite clear. OCL on one side and a clean mechanism for modeling language extension called Modeling Schemes on the other side.

This is the place where history was made. Probably not in a full OMG meeting at the main hotel, but in some café of the”Promenade des anglais”. I suspect that the discussion went somehow as follows: “It is impossible to ignore IBM proposal, but on the other side we don’t want to take their full proposal. Which one shall we chose? OCL or Modeling Schemas?“

I dont claim that they used coin tossing, but the result was clear: OCL was choosen for the best and the worst and the second proposal of Modeling Schemes was simply ignored.

This is the sad story. This is why we have to deal today with the ugly OCL syntax. And this is probably why we miss so much a clean extensibility scheme or all the OMG modeling languages. I remember this with a lot of sadness and I often look to the following slide that was also presented in Nice by the IBM/ObjectTime team:

Isn’t this slide fantastic? Presented at the initial UML definition meeting in 1996. And this was simply ignored at the time. What a pity!

Of course, Steve Cook was probably proposing ideas in advance of their time in 1996. But some cycles later (i.e. some OMG meetings later), people had completely forgotten this. And they started complaining of missing parametrization and openness of UML. Guess what they did at that time: invent the notion of UML Pofile! What a pity. But this is another story that we may discuss later.

By the way, if you want to know the main culprits, here is a list of people involved in this OMG meeting in Nice.

As you can see, Steve Cook is not on the list but he was certainlythe “eminence grise” at IBM at the time.

Anyway, this story shows that UML started from the beginning as a “salade niçoise” as they call it there!

Happy Birthday, MDA!

Ten years of MDA soon

On November 27, 2000 the OMG published the so-called MDA whitepaper Draft 3.2 . This will soon be ten years ago.

Ten years is a good period to reflect on where we stand, what has been achieved, what remains to do and where we are leading.

But before doing that, we may quote some interesting parts of this seminal report and indulge in some paraphrasing (the subtitles have been added).

Integration/Interoperability

It’s about integration. It’s about interoperability. For eleven years, the Object Management Group (OMG) has focused on making sure that you can integrate what you’ve built, with what you’re building, with what you’re going to build. As the pace of technology continues to quicken, and the demands of integrating your existing legacy systems, your new intranet, and your e­business fall on your shoulders, you need an architecture that makes interoperability central to your infrastructure. The bad news is that there will never be a single operating system, single programming language, or single network architecture that replaces all that has passed; the good news is that you can still manage to build systems economically in this environment.

Declaration by Fred Waskiewicz

CORBA was a powerful first step, but we have more steps to take.

Modeling standards are ready

UML, the Unified Modeling Language, allows a model to be constructed, viewed, developed, and manipulated in a standard way at analysis and design time. As blueprints do for an office building, UML models allow an application design to be evaluated and critiqued before it is coded, when changes are easier and less expensive to make. In addition, the Common Warehouse Meta­model (CWM) standardizes how to represent database models (schema), schema transformation models, OLAP and data mining models, etc. The Meta­Object Facility (MOF) standardizes a facility for managing models in a repository. And finally, XML Metadata Interchange (XMI) is an interchange format for models, based on the MOF and the popular language XML. The OMG’s modeling specifications complement but not limited to CORBA. They are being used in virtually every development environment including Java/EJB, message­oriented middleware, DCOM/COM+/.NET and XML/SOAP.

The OMG standardization process may be used in modeling also

In addition to its technologies, OMG has the world’s best standardization process. Executing our process, building consensus as they converge on technical details, OMG members produce each  new specification in nine to seventeen months. Proven in the marketplace with the standardization of CORBA, the CORBAservices, Domain Facilities, UML, the MOF, and OMG’s other modeling standards, the process is one of our group’s major assets. OMG’s technology adoption process will play a major role in the extended standardization work proposed in this paper.

The problems caused by middleware proliferation

What’s middleware? Middleware environments started out providing interoperability using architectures that are standard (i.e., CORBA), proprietary (e.g., DCOM or MQseries), or somewhere in the middle (e.g., JMI or HTTP/XML/SOAP). Essential services such as transactions, directory, persistence, event handling, and messaging, were added over time.

Recently, more powerful middleware has emerged that builds on the basic interoperability environments to make it easier to construct transactional enterprise components (CORBA Component Model, EJB, MTS/COM+) that execute on application servers.

Over the past decade or more, companies have endured a succession of middleware platforms.

Let’s end the middleware war …

It’s difficult — in fact, next to impossible — for a large enterprise to standardize on a single middleware platform. Some enterprises found themselves with more than one because their different departments have different requirements, others because mergers or acquisitions created a mix. Even the lucky enterprise with a single middleware choice still has to use other technologies to interoperate with other enterprises and B2B markets.

The middleware environments that are most visible today are CORBA, Enterprise JavaBeans, message­oriented middleware, XML/SOAP, COM+ and .NET. However, over the past decade or so, the middleware landscape has continually shifted. For years we’ve assumed that a clear winner will emerge and stabilize this state of flux, but it’s time to admit what we’ve all suspected: The sequence has no end! And, in spite of the advantages (sometimes real, sometimes imagined) of the latest middleware platform, migration is expensive and disruptive. (We know an industry standards group that, having migrated their standard infrastructure twice already, is now moving from their latest platform du jour to XML.)

… and move to the new modeling era

… There is a way to manage this situation, and it’s based on the core modeling standards from OMG. What we have is the ability to apply modeling technology to pull the whole picture together.

Companies that adopt the MDA gain the ultimate in flexibility: the ability to derive code from a stable model as the underlying infrastructure shifts over time. ROI flows from the reuse of application and domain models across the software lifespan.

The central figure

The core of the architecture, at the center of the figure, is based on OMG’s modeling standards: UML, the MOF and CWM. There will be multiple core models (UML profiles) : One will represent Enterprise Computing with its component structure and transactional interaction; another will represent Real­Time computing with its special needs for resource control; more will be added to represent other specialized environments but the total number will be small. Each core model will be independent of any middleware platform. The number of core models stays small because each core model represents the common features of all of the platforms in its category.

Whether your ultimate target is CCM, EJB, MTS, or some other component or transaction­based platform, the first step when constructing an MDA­based application will be to create a platform­independent application model expressed via UML in terms of the appropriate core model.

Platform specialists will convert this general application model into one targeted to a specific platform such as CCM, EJB, or MTS. Standard mappings will allow tools to automate some of the conversion. In Figure 1, these target platforms occupy the thin ring surrounding the core.

When we map a platform-independent model to a particular platform, we produce not only artifacts native to that platform (IDL, deployment descriptors, etc.) but also a platform­-specific UML model. We do this because the UML model can express the semantics of the platform-specific solution much more richly than IDL or XML.

Towards automation

Maximizing automation of the mapping step is a goal; however, in most cases some hand coding will be required, especially in the absence of MDA tools. As users and tool builders gain experience, and techniques for modeling application semantics become better developed, the amount of intervention required will decrease.

The platform­s-pecific model faithfully represents both the business and technical run­time semantics of the application. It’s still a UML model, but is expressed (because of the conversion step) in a dialect (i.e. a profile) of UML that precisely mirrors technical run­time elements of the target platform. The semantics of the platform­independent original model are carried through into the platform­specific model.

We can generate a lot of the code and reduce the need for hand programming by an order of magnitude, and in some restricted cases we will be able to generate all of the code.

The next step is to generate application code itself. For component environments, the system will have to produce many types of code and configuration files including interface files, component definition files, program code files, component configuration files, and assembly configuration files. The more completely the platform­-specific UML dialect reflects the actual platform environment, the more completely the application semantics and run­time behavior can be included in the platform-specific application model and the more complete the generated code can be. In a mature MDA environment, code generation will be substantial or, perhaps in some cases, even complete. Early versions are unlikely to provide a high degree of automatic generation, but even initial implementations will simplify development projects and represent a significant gain, on balance, for early adopters, because they will be using a consistent architecture for managing the platform­independent and platform­specific aspects of their applications.

Modeling as much of the application semantics as precisely as possible enables a greater degree of code generation.

Then the main direction

As the next generation of OMG standards, the MDA plays the role of the next generation Internet ORB, integrating across all middleware platforms — past, present, and future.

OMG, the organization that knows ORBs better than any other, is the ideal organization to extend this concept beyond middleware standards to a middleware­neutral, model­driven approach.

Models are built, viewed, and manipulated via UML,  

transmitted via XMI

and stored in MOF repositories.

Formal declaration of semantics of systems (through modeling) will increase software quality and extend the useful lifetime of designs (and thus return on investment).

zTrue integration requires a common model for directory services, events and signals, and security.

 

By extending them to a generalized model, implementable in the different environments and easily integrated, the Model Driven Architecture becomes the basis of our goal of universal integration: the global information appliance.

Conclusion

We are continuing our quest to support integration and interoperability across heterogeneity at all levels. Our first mission, to enable integration through the introduction of the distributed object model, is complete: objects are the way systems are built today, at the core of every vendor’s enabling architecture and also at the core of all e­businesses. But the integration task is not yet done. To focus on this, OMG will extend our focus from a middleware centric to a modeling­ centric organization.

CORBA is a foundation of this new architecture. As the only vendor­ and language­independent middleware, it is a vital and necessary part of the MDA superstructure; software bridges would be hard to build without it. Extending this superstructure, the MDA is expressed completely in terms of modeling concepts, moving the reuse equation up one level.

 

The need for integration remains strong and OMG’s work is not yet complete — we need to build on the success of UML and CORBA. With our experience, cohesive membership, established process, and tradition of consensus­based decision­making, OMG is in the ideal position to provide the model­based standards that are necessary to extend integration beyond the middleware approach. We’ve outlined the task, and directions of the solution, in this paper.

Now is the time to put this plan into effect.

Now is the time for the Model Driven Architecture.

_______________________________________

Ten years after  this report was written, we can only congratulate Richard Soley and his team for the vision they proposed to the computer industry. Happy birthday MDA!

SEMAT now an OMG activity

The new SEMAT Kernel RFP

On December 8, there will be a presentation of a new RFP at OMG by Ivar Jacobson and Arne J. Berre:

14:00 “A domain-specific language and a kernel of essentials for Software Engineering”, Draft RFP presentation and discussion (Ivar Jacobson and Arne J. Berre)

This is on the preliminary agenda of the Analysis and Design Task Force Meeting,  in Santa Clara, on 8 December 2010.

This means that SEMAT is going one step further to becoming a standard OMG activity by the proposal of a RFP (Request For Proposal). This is good news since it will give more stability and visibility to the SEMAT initiative.