UML supports the MDD process: No match made in heaven or oxymoron.

This post builds on previous posts and is serves as additional commentary and context to a post by Franco Civello - UML for MDD – Oxymoron or match made in heaven? Not sure what Model-Driven Development (MDD) is exactly, then check out IBM’s MDD Redbook which is one perspective.

UML is a modeling language with thousands of features and facets.  Most people discount UML, even experienced modelers and language developers, without understanding what the language is capable off.  The primary UML feature missed of importance here is the UML Profiles capability.  People miss that UML Profiles allow for extension and constraints of the language itself, read section 18 of the UML Superstructure or take a look at the UML profile catalog.  The two linked posts (1,2) speak to what UML profiles are etc, so you might consider reading them before proceeding.  This extension and constraint mechanism is exactly what is needed to create domain specific models i.e. support MDD.

Now MDD is just a process, so what are the actual implementations or tooling used?  The following are just examples and it is not complete as I am sure there are a hundred ways to do it.  Firstly, there are DSL (Domain Specific Language) tool kits.  A classic example would be YACC and LEX, but a modern example is Eclipse XText Model/Language Definition.  Another significant way is with DSM (Domain Specific Modeling) tool kits, such as Eclipse EMF or MetaEdit+ (a leader in the DSM space).  The DSM space is not free from it’s challenges too, but they are further along on average.  Think of DSMs as graphically represented DSLs if you are newer to this area.  Finally UML Profiles are another way to implement the domain specific tooling required.  Tools such as Rational Software Modeler (RSA/RSM), Eclipse MDT, and other tools.

What adds to the confusion between DSL/DSM and UML Profiles when it comes to the creation of domain models for MDD processes is approach and familiarity. The good DSL/DSM tools typically are tabla rasa (blank slate) model creation, much like a empty file when you start programming.  There is less baggage by starting with a blank slate, you also do not have to worry about removing or limiting existing model elements.  Now strictly speaking for UML Profiles you can start with a basically blank slate, but most tools don’t support this.  A modeler in the UML Profile space must not only construct/extend the model, but constrain the other model elements that are not needed or conflict with the DSM.  You also have to research and pick the right UML element type to extend to minimize the constraining work you have to do.  Interestingly, in my experience creating small DSMs/logical constructs for a group of architects having a rich language actually reduces the work, but this need not always be the case.

You could really do MDD with any of the tools above, the question often becomes what is the cost, time, and skill level needed by the resources?  What actually seperates the tools are the features and ease of rolling out model tooling to all of the involved parties, such as business, vendors, developers, etc.  So the seven hundred pound gorilla in the room is actually the lack of wide spread usable tooling to build UML Profiles.  Few tools if any implement all of the UML Profile features and creating tooling for use in the MDD process can be very difficult.  I suspect most people use free or drawing oriented UML tools and thus never get exposure to UML Profiles.  Even if they did they would have to buy a specific software suite to support it fulling.  I use Rational Software Modeler (RSM/RSA) which is thousands of dollars and even it does not correctly implement UML Profiles, but it is close.  The DSM tools are not all free, but at least there is Eclipse MDT with EMF/GMF and the generative tools needed.  In a year or two Eclipse may have an offering that is usable enough for novices and support UML Profiles for the tooling efforts more fully.

So UML and MDD go together just fine when you understand the extension, constraining, and profiling capabilities of the language, but all is not well with the union.  UML requires lots of time and energy to learn and understand it before it will begin yielding results.  Better cheap tooling and tutorials are still needed to support the modeling and programming communities at large lest UML/MDD/MDA remain for ‘experts only’ which I would quantify as a failure by it’s advocates.  Much of these challenges are not just limited to a UML Profiles based approach to MDD.

It is worth noting that at some point the industry should look back to Case Tools and YACC/Lex to evaluate why Domain Specific movements have failed in the past, or we may just repeat it.

January 10, 2010 | No Comments »

Reference Cards, Cheat Sheets, Posters, whatever they are called.

Tonight I tried to find quick reference sheets for both UML and BPMN, free of course.  There are quite a fewer different terms for them be it poster, reference cards, cheat sheets, quick guides etc.  However, once I got into several sites by searching for “Reference Cards” I found the other names for these small printable guides to various technologies. Oh yes, and much more managable or likely to be used than “pocket references” which don’t fit in your pocket.

List of quality sites quick guides:

I did not find a suitable quality UML guide (Stackoverflow has a list), but the BPMN poster at itPoster.net though outdated at time of this post was still really well done. There are several red herring links which get referenced a lot, but are not that good, ex: (How are you to carry this around?) Any other good sites that have a listing of printable reference guides?

January 4, 2010 | No Comments »

UML vs Domain-Specific Languages

Great minds think and do not always think alike. In surfing the web this week around clojure, Stack Overflow, Architecture and DSL (Domain-Specific Language) sites there is just a broad misunderstanding of UML. Really smart people seem to miss that UML is more than a modeling language with everything and the kitchen sink that is to vague to use. Just keep reading…really.

UML is meant for extension and restriction as it offers, via the UML Profiles, mechanism which I recently extolled in Profiles – The UML problem solver. I have found others that are in this camp, http://www.dsmforum.org/. They even wrote a paper UML vs. Domain-Specific Languages, Methods and Tools which if you go by the title seems to pit UML against DSLs, however it is quite the opposite. They seem to understand that UML profiles can be used to create restricted models or DSMs (Domain Specific Modeling); and yes I am using DSM and DSL interchangeably. Call me crazy, but this is also what the OMG – Object Management Group(www.omg.org) thinks who created UML. They just like to call DSLs and DSMs by MDA (Model Driven Architecture), UML Profiles, Meta-Modeling. I hope to post just on the book OMG book “MDA Distilled” by Stephen J. Mellor soon as it really helps you understand the whole modeling thing in the context of UML, but any how. There seems to be more of a PR problem than feature problem. It does not help that schools don’t teach functional languages let alone modeling languages.

Additionally people equate the UML primitive “class” with Java classes so they infer that UML must then be object oriented, which it is, but objects can be anything really such as functions, you just need to specify. So, UML can model functions as classes, yup, it’s called stereotyping. People seem to think stereotyping is some fancy <<Comment>>, which is how they use it, never knowing that they are on the verge of using UML profiles. All they would have to do is formalize the <<Stereotype>> in the UML profile and then apply it to their model. Take modeling a lisp function. Just create a stereotype <<function>> in your UML profile and then constrict it using a constraint language such as OCL (Object Constraint Language):
1. Constrain all classes to be functions, that way I can only model functions.
2. Constrain that by stereotyped classes cannot have methods, as they don’t make sense in the context of functions.
3. Constrain all parameters/attributes to only be other functions or primitives (like lists), functions, or numbers.
4. Constrain your function stereotype to only “use” other functions, not extend, realize, or other object stuff.
…and so on.
The point here is not complete nor would it help you stay awake to be, the point is remember that <<stereotype>>s are so much more than comments; UML has comments which are called notes.

Not yet on board. Fine, but take a look at how others are creating DSLs and DSMs with UML. You just need to speak UML acronym soup:
*UML Profiles – Implemented in many UML tools.
*Rational (RAS) Re-usable Assets – A pattern as a profile.
*RSA Plug-ins (Deployable profiles)
*MDA – Model Driven Architecture
*MOF – Really not UML, but what UML is defined in.
Some notable examples:
*UML 2.0 Profile for Software Services
*OMG – UML Profile Specifications
Further Reading:
UML vs. Domain-Specific Languages

November 19, 2008 | No Comments »

Profiles – The UML problem solver

In reading several posts on stackoverflow.com (and posting) and through personal interactions it has become clear that people hate UML because they think of UML as a drawing language and not a tool for modeling. Nothing new so far, however, I realized as people search to bring teams together or gain efficiencies in communication UML all together skip UML profiles. People would really benefit from the added rigour that UML profiles can be used to create.

UML problem – How a UML profile helps:
* UML is to big – Profiles reduce the scope and mature tools only display valid elements and relationships. Only allow drawing that which should be drawn (modeled).

* UML is slow – Profiles reduce the problem space and force the modeler to solve only the important pieces for your particular problem space.

* UML is complex – Yup it is, but profile can reduce the possibilities and focus on simpler problem spaces. Novel idea, you mean I don’t have to diagram the bits and the components. There is a point of diminishing returns, find where it is with your peers.

* UML is to general – Ok, make it specific with UML profiles. You can force many things about the model or diagram. For instance, you might limit all classes to be .NET types as you are only a .NET shop. Or all classes must by services as you only want to show solutions at the services level.

Everyone wants to think that the creation part of their jobs should be free and unbridled, which is great for painters. Unfortunately architects and designers need their creations to communicate the idea quickly and simply. The terms patterns and re-use are accepted at the code level as must haves and best practices, but what modeling or drawing with UML or no language this seems foreign. Your work is 80% the same and only 20% unique. Allow UML profiles to help you and your peers focus on the 20% new stuff and create a profile for the 80% to go more quickly.

Example: If your company only uses widgets and sprockets to create solutions, create a profile to only allow widgets and sprockets in the model. Further more, limit the behavior and structure to what widgets and sprockets would allow. Now, as a Senior sprocket and widget consultant you can focus on the 20% that is new and creative. Also, all the other SSWCs (Senior sprocket and widget consultants) use the same terminology and symbols easing communication.

November 9, 2008 | No Comments »