UML profiles and OCL
Hello,
if you would like to better understand the concept of UML profiles and their relation to the Object Constraint Language (OCL) I would recommend to read the nice paper OCL-based Validation of a Railway Domain Profile by Kirsten Berkenkötter.
Usually, OCL is propagated as a means to make UML models more precise, i.e. “better”, by adding information to the model that cannot be expressed with diagrams.
The usage of OCL in UML profiles is the other major application of the OCL. There it is used – along with stereotypes – to create a domain specific subset of the UML that is better suited for a given domain than just plain UML. Usually, a UML stereotype also defines a domain specific graphical presentation for the stereotyped element.
If you are familiar with the world of software modeling you are probably aware that currently two major schools of thought are contending for dominance. There are the proponents of Domain Specific Modeling Languages (DSL) who claim that a dedicated modeling language must be created for a specific application domain to allow effective modeling. And then there are the proponents of UML who claim that the UML provides a standardized, well defined and widely known modeling language which can of course be tailored to a specific domain (using profiles). Unfortunately, most of the people who make public statements concerning these contending approaches are biased, because they work for a tool vendor. For example, people working for IBM Rational will advocate the usage of UML, and people working for Metacase will propagate the DSL approach. Since this is a complicated topic I’m afraid that the only way to find an answer to the question “which is the best approach for my specific project?” is to make a careful evaluation and maybe a pilot project.
Best regards,
Andreas
April 20th, 2008 at 10:00 pm
Just because somebody works for a tool vendor doesn’t necessarily mean they are biased beyond hope. Here for instance is what Grady Booch, Alan Brown, Sridhar Iyengar, Jim Rumbaugh and Bran Selic say in the MDA Journal, 2004: “the full value of MDA is only achieved when the modeling concepts map directly to domain concepts rather than computer technology concepts. … It does not require much insight to realize that different domains will need different, domain-specific languages (DSLs)”
http://www.bptrends.com/publicationfiles/05-04%20COL%20IBM%20Manifesto%20-%20Frankel%20-3.pdf
Having talked with most of the authors about the subject, I am not left with the impression of people just pushing their own company’s technology. Similarly, MetaCase are happy to use UML when it is the most appropriate language – e.g. to describe an existing set of Java classes. On the level of ideas, I think all vendors in this space agree on the need for companies to be able to create their own DSM languages easily.
Of course which tool is best for that task, or whose approach to creating languages is best, is a more open question. There’s a nice comparison of all the major tools being used by their creators to make the same DSM language at the MDD Tool Implementors’ Forum:
http://www.dsmforum.org/events/MDD-TIF07/
April 21st, 2008 at 9:33 pm
Hello Steven,
thanks for taking the time to comment.
I would not argue about the value of a domain specific modeling approach in general.
If someone wants to start such a project their first choice is:
Do I use a UML based modeling tool, create a profile along with graphical representations for stereotypes, OCL constraints and transformations or do I use a DSL tool vendors proprietary approach?
They ask IBM Rational for the best approach and they ask MetaCase for the best approach. Will they really get a thorough analysis of their needs and the recommendation that returns the best value for their investment?
(if it’s not as obvious as reverse engineering existing Java classes)
Let me cite from the article you mentioned:
“…3. Open standards. Standards have been one of the most effective boosters of progress throughout the history of technology. Industry standards not only help eliminate gratuitous diversity but they also encourage an ecosystem of vendors producing tools for general purposes as well as all kinds of specialized niches, greatly increasing the attractiveness of the whole endeavor to users.”
I see this as a vote for OMG based specifications, namely UML and profiles.
That said, please see it as positive that I used MetaCase as example for the “DSL approach” because I see you as the most well known vendor in this “domain”.
Of course I realize that each company has bright people that exchange their opinions freely and unbiased. But given the sum of all public statements – including articles in trade magazines and talks with “presales consultants” – how much objectivity do we really have?
Best regards,
Andreas
April 22nd, 2008 at 2:36 pm
Hi Andreas, and thanks for taking the time to respond!
I’m sure you’re right that if “public statements” includes discussions with sales staff, there will be some less than totally objective statements. Mind you, some of the nicest sales people I know are human beings
. About 50% of trade articles seem to be pretty objective, the other half poorly disguised sales pitches. Fortunately it’s generally easy to recognise a sales pitch for what it is (although an objective message about something good can also sound like it might be a sales pitch – look for real, documented industrial cases and numbers to be sure).
Standards are great, but to be useful they must a) be fit for their purpose and b) be widely followed in the same way. In other words, they should be sound both a) academically / theoretically and b) industrially / pragmatically. As a recent article shows, and Arnold deVos confirms, some OMG modeling “standards” don’t fit those criteria:
http://www.metacase.com/blogs/stevek/blogView?showComments=true&entry=3385202330
If “standards” are being used as a marketing tool, it’s not the end of the world – but it does mean we have to check whether all the communities relevant to our needs accept those standards, and whether they are followed in the same way within those communities.
Coming back to the MDA Manifesto, I think we should make clear that the authors offer two ways to make modeling languages more domain-specific: UML profiles and metamodels. If all you want is to tweak UML, e.g. to make it more specific for your implementation platform, profiles may work. For more meaninful changes, profiles aren’t enough – e.g. since profiles cannot remove anything, it’s hard to see how they can create a subset of UML. Trying to use profiles to turn UML into a modeling language for your problem domain is like trying to use preprocessor macros to turn C into Ruby on Rails. It may be theoretically possible, but you’re better starting from scratch, just reusing your knowledge and experience, not any existing implementation.
If you want to create a new modeling language whose concepts are from your *problem* domain (not the implementation domain like most in UML), the OMG says you need to metamodel. That’s the same message as the DSM community, and where both groups of experts believe the future lies. Which is the best metamodeling language, toolset and approach is a discussion for another day – although of course I am honoured that you chose to cite MetaCase as the most well known vendor!