A post by lispy entitled “Why UML Fails to Add Value to the Design and Development Process” reminded me of an existing methodology put together by IBM.
Lispy wrote (I cut a lot out) –
“The modeling language must be a first-class citizen of the development process rather than just make-work for architects and project managers… There are two linguistic abstraction barriers that must be implemented in order to make this work: 1) the modeling language between the models and the generated code and 2) the framework between the generated code and the target libraries. You must build up from your core code components to the framework… and you must build down from the models to the generated code. If the code generation process is too complicated, you may need better abstractions at the framework level. If the code generation process is impossible, then the modeling language may not be providing a detailed enough description of the requirements. If there is too much repetition in the models, then the modeling language will need to be extended to cover additional concepts.”
What I was reminded of was “Patterns: Model-Driven Development Using IBM Rational Software Architect”, by the way you don’t have to use IBM’s products. You can go off and the whole thing, but chapter 4 is where the meat is and Figure 4.2 on pg 47 and the related descriptions on the following pages put it all in place. It really lays out a process which in my mind covers some of Lispy’s concerns.
A short post just to share an interesting modeling process I learned about sometime ago.
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.
