Login | Register   
LinkedIn
Google+
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Useful UML Modeling: Simplify the UML?

Simplifying is a hot topic, but Robert Maksimchuk submits that we are already simplifying the UML in our respective projects through self-selection.


advertisement
I am continually amazed at the serendipity that occur every day. A short time ago I was having lunch with an industry insider when he mentioned the beginnings of a movement to simplify the UML.

Having read the 700+ page UML specification a number of times (Sadistic, isn't it?) it immediately struck me as a good idea. While software modeling is an "acknowledged" technique, it still is not a "standard" practice on most software projects. From the common, repeating questions that I have been asked over the years, many people still struggle with how to do it well. Modeling has a way to go to become truly mainstream. So a simpler UML sounded like a fine idea.

Within a week, I ran across an article where two other people in the industry were discussing the same topic. How coincidental. (You can hear the Theremin playing a creepy strain in the background.) I thought, maybe this "simplify the UML idea" actually has legs. But then, near the end of the article, the line of reasoning turned ugly. One of the article's principals touted what he thought was a great benefit of simplifying the UML -- once simplified they could take it and create a specialized UML (and specialized tooling) for all the various industry domains. In other words, we would go from one simplified UML to an insurance UML, a manufacturing UML, a defense UML, a pharmaceutical UML, a retail UML, a banking UML, and on and on.



[login] Is this a bad thing? Some would point to one good example of UML specialization: the SysML, which both simplified and specialized the UML for Systems Engineering. Although it is commonly used in the defense industry, it is not really specialized for that one industry. It can be used by anyone doing Systems Engineering. It is not industry domain specific.

We've heard this idea before, beginning many years ago, under the auspices of domain specific languages. That is an idea that clearly has not to this day enabled modeling to become widespread and commonplace in our industry. Nor has it made modeling any easier for the practitioners. But it certainly would be a boon to tool vendors who could sell a separate tool for each industry, along with more consulting.

This would be good for writers and publishers too. At my last count there were over 3,600 UML books published. This number would quickly burgeon many-fold; books about the simplified UML, books comparing the old and new UML, books about each industry UML, and so on. Training companies would do well. And just think of the certification industry! Each specialized UML could have its own certification path. New standards committees. Marketers would have a field day. More Websites. More seminars. More conventions. More chachkas. Just think of it.

But how would this specialization help the day-to-day practitioner in the trenches? Would model quality be improved? Would modeling become a more widespread practice? Would it become more accepted? Or could this become a barrier when you want to change jobs and move to a different industry? "Sorry, you don't know Enzymology UML." Companies that really feel they need a specialized version of UML have already created / can create their own through approaches such as the use of UML stereotypes, profiles, and industry models.

Yet wouldn't the idea of simplification itself help the practitioners? It might. However, I would submit that we are already simplifying the UML in our respective projects through self-selection. Various research studies confirm what a recent Project Pragmatics survey has shown -- only a small subset of the UML is typically used on projects. (Even the authors of the UML have written that most projects can do what they need to do by using only 20% of the UML.)

We practitioners already ARE simplifying the UML by using just what is useful to our specific projects. And who knows better what works for them than those who are using it in the real world. (Of course, we do have to avoid the "I Did It My Way" anti-pattern. See the earlier article in this series "http://www.devx.com/architect/Article/44828 Don't Rewrite the UML".) So we should be cautious when we "smell silver" in the latest and greatest promise. As Robert Burns wrote: "The best laid schemes o' Mice an' Men, Gang aft agley…"


   
Bob Maksimchuk is a systems engineer, author, speaker, and principal consultant at Project Pragmatics, LLC., specializing in helping software development teams get work done by introducing practical techniques, streamlined process, and focused training and mentoring. Twitter: @BobMaksimchuk
Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap