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.

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?

Connecting UML Components with the Ball and Socket notation in Rational Software Modeler (RSM/RSA) and Eclipse UML2 Tools is not fully implemented or flawed. Too fully understand my point you have to keep in mind that these tools are for modeling, not just drawing a picture/diagram. Thus the internal model representation of what you diagram must be correct and complete.

The Need:
I discovered this issue while trying to design a suitable domain specific language/model for architects to talk about systems and what interfaces/data connections they had between them. The users understand components, so our systems were components. Additionally, interfaces at a high level make sense for being an “agreed upon” contract of interaction between systems. So, the components will realize the interfaces or <> them to show providing and consumption between the systems. The figure below shows two examples of this.

If you look closely at the diagram you will note that the ball and socket do not really connect, which is the first indication that there is a problem. RSM will not let you connect the ball and socket visually or in the model. The Eclipse UML2 Tools will let you connect them, but it fails to model them correctly, though it is still in the early phases of open source development so it kind of gets a pass for most of this discussion.
UML Defines:
So what does UML say should be possible, both from a visual representation (syntax) and model structure (more semantics)? The UML specification 2.2 (Superstructure) says on pg 151 in section 8.1 at a high level that:
“As a result, components and subsystems can be flexibly reused and replaced by
connecting (“wiring”) them together via their provided and required interfaces….
In addition, the BasicComponents package defines specialized connectors for ‘wiring’ components together based on interface compatibility.”
The Assembly kind of Connector
At the syntax and semantics level however there are a few details to understand. The major construct to support “wiring” are Connectors. The ComponentBase extends the Connector definition allowing for two kinds of Component specific Connectors, Delegation and Assembly. Also, you “wire” both components and component parts/ports which can make the spec hard to read. It states on page 155 in section 8.3.3:
“The connector concept is extended in the Com ponents package to include interface based constraints and notation.
A delegation connector is a connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component’s parts. It represents the forwarding of signals (operation requests and events): a signal that arrives at a port that has a delegation connector to a part or to another port will be passed on to that target for handling.
An assembly connector is a connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port.”
Notice that for assembly it does not say compo nent part, but components and uses the word between. To make things confusing the major examples (pg 153 Figure 8.15) are on Component Instances that are Parts, not between components so to be sure I also found the following on page 156 under constraints:
“[5] An assembly connector must only be defined from a required Interface or Ports to a provided Interface or Port.”
An interesting note, but I will go no deeper is that the table 8.2 makes it sound like connecting the ball and socket by a usage/dependency would be equivalent, especially when you factor in
Figure 8.14. Table 8.2 from page 160:
So, the assembly connector defined in UML supports connecting the ball and socket between components, which should be reflected in the model as an Assembly kind of Connector.

Ecore/EMF Provides:
It turns out that the Ecore/EMF model of UML which Rational and Eclipse UML2 Tools leverage support the Assembly Connector per the UML spec. The below two figures show from Eclipse the construction of a component required interface connecting via an Assembly Connector to the same interface provided/realized by a component. The properties could be set and the selector filtered the options correctly given that the interface type had to match.


How Rational (RSM) FAILs gracefully:
In Rational you cannot even create an assembly connector between two components either visually or in the model. The diagram canvas will not allow you to select a component that is not an instance nor will it let you specify it when you are drawing a new (yet to be typed) line. In the model if you try to add a new relationship between two components it will not give you the assembly connector option.
Even worse if you try to connect the ball and socket in Rational with a use or depends you will actually be connecting the interface to itself, see below. Basically the ball and the socket are representations of the interface, not the provided or required ones.

Sadly, Rational provides the Assembly connector and even renders it fine when you are using instances of components (Parts) in the structural view inside a component. So, in my estimation the just mis-understood the specification or they did not keep up with the changes to UML as this was added as part of 2.0 from what I can tell.
A bug will be logged with IBM for the Rational Software Modeler (RSA/RSM) tools, and the ID/Link to it is TDB.


I have to admit that I am lured into the pocket size form factor used by O’Reilly and others. The cute baby animals on the cover, like the gorilla on the front of the UML 2.0 – Pocket Reference is just fun. I also have The Elements of UML Style in the same easy to consume and not really pocket sized size. Parts of this review also apply to both pocket books, but the majority is about the UML 2.0 – Pocket Reference.

If you do actually end up bringing this “pocket” reference around with you then great, but consider when will you actually use it. While you are walking around the park thinking about UML and all of its confusing details? This book only covers syntax and usage, not really semantics which is where most people struggle anyhow, as the semantics and detailed syntax consume over 1000 pages. You could bring it to meetings and wow people with perfect diagrams. Again, this book might help with that, but how often are you drawing a diagram on the white board and everyone is confused because you lines are not specific enough, or the shape is just not right. This does not happen because the people in the meeting have the context of the conversation and thus do not need perfection, the drawing is just a tool to move the conversation forward not get hung up on syntax, semantic maybe, but this book won’t help with that beyond the bare surface.

Additionally this spartan “pocket” reference decided to include OCL, which is 5 pages long. Distilling a language, context, and usage in 5 tiny pocket pages really was just a waste of space. There are 100+ page books on OCL to do it justice, if the book is even current or matches your implementation of UML.
It seems far more rational to make your own pocket guide using a print out from websites with examples or the front and back flaps of UML Distilled, by Martin Fowler. This follows the 80/20 approach in that you get 80% of the value with 20% of the cost and complexity. Pick the diagrams or elements you typically use, such as classes and components or sequence diagrams and limit your pocket guide to those. Or just bring your laptop and have some favorite UML sites bookmarked.
Finally if they are really trying to make a reference, create tabs for the sections at least, having to look up the page in the front or term in the back is not very efficient if you use the book frequently. And if you are like me and the pocket references end up on a bookshelf they don’t even fit in, the black sheep of your library.

The short lesson: When looking at eclipse features dig deep and work off the website and examples. Books are outdated quickly and are often written to just the major usage of a package or feature. Never be to proud to use the eclipse project specific mailing list.

The story: Whenever I take time off work, I invariably take on creating some new thing or read a technical book, basically just go down a rabbit hole of some kind as much of my day to day work requires abstraction from the details and hands on coding.

The Christmas 2009 break is no different. This time I dug a little deeper than I normally do with eclipse and plug-ins. I have been creating an eclipse plug-in to import UML objects from an outside server which houses use cases, requirements, and test cases. I figure why copy and paste or manually sync them which you can have a wizard done. Great so after a COM Bridge, EMF Transactions, UML Profile, and a shovel I have an import working. I did not do this in a vacuum, but instead have been going off, eclipse books, the eclipse.org dev websites etc. I had checked into Eclipse Team about 8 months back and found it was decidedly IResource (File/Folder/Project/WorkspaceRoot) limited as all of the methods seem to require IResource to operate. This lead me to just drop the “Syncronization” and Team approach to integrating UML models with outside data sources. Heck I figure even IBMs Rational suite has to do all the sub-file (UML object) comparisons with a comparitor, that must be it.

As I completed a workable Alpha of the importing plug-in and began to lust after the export, update, and delta features one expects when collaborating, I decided to double check that the Eclipse Team (CVS,SVN, etc) really would not work. Into the rabbit hole I went. This time as I went to the website and played with examples. They all showed promise as features had been added in recent releases. The org.eclipse.team.examples code is helpful for understanding this seriously complex package/feature. But more importantly there had been additions since 3.2 and how there seemed to be support for Logical Models. Great models are what I am doing.

So I really dig in. The trouble was that I cannot find a good example to how this would be done in a non trivial way. The example Logical Model code was trivial as each “Model Element” was still a IResource, so it did not show that this could be done. Even though they had in the API/Eclipse documentation mentioned Ecore models it all seemed to be still focused on IResources. Finally, however, I am convinced that the Logical Model Team feature set will meet the need of Syncing non-IResource model components, ie sub-file detail level representation. The wiki page about the team logical model objective said it most clearly.

The following paragraph, taken from the Eclipse 3.2 plan, describes the motivation for the logical model integration support that was added in Eclipse 3.2.

The Eclipse Platform supports a strong physical view of projects, files, and folders in the workspace. However, there are many situations where a physical view is not the most salient or useful for many purposes. In some cases, multiple distinct objects happen to be stored in a single file, like an archive. Conversely, in other cases, something that is logically a single object is stored across multiple files. This discrepancy between logical and physical creates problems for common operations such as searching, comparing, and versioning, which need to work in the physical realm. Eclipse should support some way of mapping between a logical view and the physical organization of files on disk.
At the beginning of the 3.2 development cycle, we captured the requirements from several clients in a requirements document.

And while I was writing this post I found THE emf example that has not been merged in with the other org.eclipse.team.examples, seriously, I can’t even find an email dev list to post about this issue. Also, the link on that page is dead, I found the code in the CVS archive however.

So, hours of playing with the examples, running them in the debugger trying to figure out the slight of hand and object types being used, and reading pages of seemingly contradictory documentation, nearly giving up assuming that it must not work, only to search or dig just a little bit more and find out it is supported. I know way more about the Team feature set now then I actually need to know for writing the plug-in. Hopefully next time I will navigate the eclipse web a little more efficiently, or I am find a mailing list and enlist the help of others rather than just digging deeper into my rabbit hole alone, and even Google Search failed me.

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

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.

Over at Stack Overflow a question was posted “Is UML practical?“. The question itself is fine, but several of the answers were so narrowly focused. I believe that the everyday developer only sees UML as only a common set of shapes drawing a picture. Granted it has a common set of shapes for notation, but UML is first and foremost about modeling. (Big surprise coming from a Modeling Website).

Where did this dis-information come from? In my experience the UML for diagrams message comes from schools/universities and popular UML books. Schools will often only teach UML as a way to diagram the solution you and your team of group participants are going to code up. Well of course it seems a little redundant in that contrived learning environment. UML’s concepts are to large to teach in the same class as project management 101 or multi-developer projects 101. Most people just don’t go any further with it and thus the collective knowledge is that UML is for making diagrams. A smaller problem in my estimation is that UML books often teach or focus on UML as a diagramming tool. They have to sell books to the PM 101 courses so who can blame them. However, what is slightly more scary is that often in the forward or introduction chapter it will come out that the author really only feels UML is practical for communication ie. drawing diagrams.

Just thought you might need to be reminded that most technical people don’t get UML. In 5 years UML will be so mis-understood that it will be viewed like LISP or SCHEME, that thing you used in class that was supposed to be great, but really it was only good for learning how to do X.

Keep an eye on the Stack Overflow post I referenced and the UML topics in general at the website. Maybe we can turn this oil tanker around.