SPEM and the motivation for UML Profiles
As discussed in a previous post, one of the important move in the UML history was to change from Unified Method to Unified Language. Ed Seidewitz rightly suggests that the credit should probably be given to Rational (Jim Rumbaugh and Grady Booch) for this move. Remember that all this process was in the sequence of the work of the OOADTF group at OMG (Object-Oriented Analysis and Design Task Force) and that this group was organizing a confrontation and convergence between methodologies and methodologists. The idea of a methodology-agnostic language took thus some time to mature. If this idea seems obvious today, it was not always the same in 1995.
My observation point was the attendance to some OMG meetings from time to time. I had no information from inside Rational. I understand that the RUP (Rational Unified Process) was very important but I have no idea on the origin of the project inside Rational. I imagine that Philippe Kruchten was very influential on the process, but I don’t know the dates of these contributions and influences.
Coming back to this drawing of the previous post reproduced above, I should have mentioned that this is completely abstract and artificial. The dichotomy between product and process in software modeling is conceptually well presented above but there are two errors in the picture:
- The first one is that the name SPEM was found much later. If my memory is good, the work started with an unnamed goal, some sort of Unified Software Process Language.
- The second error in the picture was that there was never consensus on the use of a full fledged metamodel for SPEM. This is the story I want to record in this post.
The context was the continuing tension at OMG between so called lightweight and heavyweight modeling approaches, between UML strict orthodoxy and MOF deviants. The lessons of this tension could perhaps be examined today in a less passionate debate, but let us keep that for another discussion.
Of course nobody is naive and we all know the major influence of tool vendors on the definition of modeling standards and recommendations. At that time this was particularly important. After all, these companies were taking a major risk and it may seem normal to give them a major role in the definition of these standards. But it should be made clear that it was not industrial users or academics or any other categories of people that took the main decisions
The definition of SPEM was more or less made at the same period that the definition of UML profiles. The official motivation for profiles was to provide openness to the UML definition. But the real risk for providers of UML tools was to see the concurrent corporation of CAPE tools catching the market of software processes (CAPE = Computer Assisted/Aided Process Engineering). As a matter of fact, the description of the production of software (who is doing what, when, how and why?) is very similar to the process description of any other marketed goods.
In order to keep the SPEM market within the CASE scope (Computer Assisted Software Engineering, understand UML modelers), it was important that SPEM could be defined not only as a metamodel, but also as an UML profile.
This strategy worked quite well and has been more recently proposed again with BPMN. My opinion is that the profile mechanism has not been defined for conceptual reasons, but mainly for economical reasons, to protect the business of UML tool vendors and to allow them to make the heavy investments on building and maintaining their software tools.
There is now a significant literature on comparing the strict metamodeling approach and the UML profiling for defining Domain Specific Languages (DSLs). The debate is far from being closed. I just wished here to state that the rationale for initially introducing UML profiles was an economic and industrial strategy choice made by CASE tools vendors. The SPEM metamodel is much simpler than the UML metamodel and a pure SPEM tool would have been much easier to build. But the missed revenues would have weakened the UML tool market.
Models Everywhere 
One day I need to write a real post on the forgotten origins of UML profiles. But let me make a few comments here.
UML 1.0/1.1 had stereotypes and tagged values, but no concept of “profile”. There were a couple of examples in the standard of using stereotypes (such as for Jacobson business modeling), but these were referred to as “UML extensions”.
Dave Frankel and I first introduced the concept of profiles to UML in a series of RFPs that came out of the Business Object Initiative started by Dave after the Business Object Component Architecture work at OMG was effectively killed by the emerging UML community. At this time, there was a lot of resistance to modifying the newly standardized UML metamodel in any way for specific modeling purposes. For the RFPs we were writing, we decided to instead request a standard that delineated how to use a subset of UML for the purposes of a specific modeling community — initially, for us, the Enterprise Distributed Object Computing (EDOC) community.
Though I sometime hesitate to admit it these days, I was actually the one who originally suggested the use of the term “profile” for this purpose, based on an earlier use of the term by Bran Selic during discussions on the fist Action Semantics RFP. (Those of you with OMG server access can see my old email with the first full definition of a “UML profile” at http://www.omg.org/archives/boi-wg/msg00013.html.) This definition (with some important improvements suggested by Dave Frankel) was eventually incorporated into early RFPs for Profiles for EDOC, CORBA and Real Time (the last of which was the first outside the BOI). The definition was first standardized in UML 1.3, though no specific “profile” mechanism was added to the language.
The rest was, as they say, history. The concept took off faster and more widely than anyone at the time could have imagined. The current language support for profiles in UML 2.x is much greater than in UML 1.x (based on a good deal of work by Philippe Desfray and others in the intervening years). But it should really be remembered that the concept of a UML profile was introduced not as a language mechanism, but truly for the purpose of creating what we would now call DSL subsets of UML.
Whatever the issues with the current language mechanisms, I think this purpose is something we should not lose.
(P.S. Thank you Jean your interesting series of reflective posts, prompting memories of the “old days”!)
Thanks Ed for this very informative description of the origins of profiles. I did not know this side of the story and it is quite interesting.
Jean, Ed:
one of the key problems UML profiles have introduced is that UML itself became a de facto M3 layer, this has lead to major difficulties across the modeling land. Figure 1 was the correct one and should have been the focus of MDA.
Jean-Jacques —
Well, I think a deeper problem may be the whole notion of fixed “M” layers. As originally conceived at Rational and as submitted for UML 1.0, the UML metamodel was defined reflexively in UML — there was no “M3” layer. The idea of the four M layers was introduced with MOF 1.0, and with UML 1.1, as adopted, the UML metamodel was formally supposed to be defined using the MOF meta-metamodel.
But, since the groups doing MOF and UML at the time were not entirely the same, a lot of discussion had to go on about “aligning” MOF and UML. And, in reality, most people working on the UML 1.x serious of standards still thought of the UML metamodel as a UML model, at least until it came time to generate IDL or XMI.
With UML 2.0 and MOF 2.0, both the UML metamodel and the MOF meta-metamodel were supposed to be based on the same UML Infrastructure. And, interestingly enough, MOF 2.0 dropped the M layer architecture from the spec (though the concept remained pretty entrenched in much OMG thinking). Instead, the idea was supposed to be that the “meta” relationship was always relative, not a fixed set of layers. But the whole infrastructure/superstructure split ended up being worse than useless. And while UML proceeding on to later versions, MOF stayed at 2.0 and continued to be formally based on the UML 2.0 infrastructure (!).
This is finally going to be all worked out with the almost done “2.4” series of specs at OMG. MOF and XMI are both going to jump their version numbers to 2.4, to align with UML 2.4, and MOF 2.4 will no longer be based on the UML infrastructure. Instead, the core MOF 2.4 meta-metamodel will be defined as a strict subset of the full UML 2.4 superstructure metamodel. So we will be more or less back to the original idea of UML defining itself!
(I think there will still be a UML Infrastructure spec for UML 2.4, because of the technical issues of extricating it from the superstructure, but this will finally be eliminated as part of the UML 2.5 spec simplification effort.)
As to profiles, what most people don’t realize is that the semantics of stereotype application in UML 2.x are defined in terms of an “equivalent MOF metamodel” based on the stereotype model. And stereotype applications are actually serialized in XMI based on this equivalent metamodel. (The discussion of stereotype application semantics was rather confused with serialization up through UML 2.3, but this is clarified in the UML 2.4 spec.)
So UML tools that truly support profiles these days already effectively have to support some level of MOF metamodeling! The nice thing about profiles is that you can do incremental tailoring of the UML metamodel within UML. But it is largely realized now within the group working on UML, MOF and XMI standards (which really are being worked on together these days) that this kind of a capability should be an integral part of MOF, not just part of UML.
Interestingly, the new Semantic MOF (SMOF) spec provides capabilities that are essentially the same as (though more general than) what UML provides through stereotypes. So the future, I think, is to keep the concept of UML profiles for their original purpose to tailor UML (or maybe generalize the to MOF profiles), but to base stereotyping on the underlying capabilities of SMOF. This will finally give us the proper, integrated metamodeling tools we really need to do good “modeling DSLs”. But this will likely not happen until after UML 2.5, so we still have a few years to wait…