Taking the temperature of UML by Ivar Jacobson

More than twelve years have passed since UML, the Unified Modeling Language, became a standard. During these years the perception of UML has ranged from the heights of the heavens to the depths of the earth.

At the beginning of the 1990s there were 26 published methods on object-orientation, most methods with its own notation. It was to address at least the notation problem that UML was conceived. As most of you probably know, Grady Booch, Jim Rumbaugh and I initiated the design of what became UML, but very quickly many other great people joined the effort and OMG undertook to launch the result. UML quickly made most other notations superfluous. Along with the notations many methods also fell by the wayside, leaving the Unified Process, which had embraced UML, as a de-facto standard along with UML. UML’s adoption spread like wildfire.

In retrospect, such outstanding initial success was sure to spark a backlash, as the initial hype was not realized. Everyone expected magical things to happen but, after all, UML was only a notation, not a silver bullet. Compounding this was a lack of good UML tools, some of which were very advanced, but hard to use. All of the tools were oversold. Many users were understandably disappointed that just drawing diagrams with UML did not magically improve their results. Over time, the spread of UML slowed.

UML also found a number of detractors. It was criticized by the academic world. The great David Parnas called UML the “Undefined Modeling Language”, a strongly exaggerated but not unfounded criticism. The criticism stung.
The original leaders of the agile movement were also strongly against modeling. For them it was the “Unnecessary Modeling Language” - they said “no modeling – just code”. Microsoft, reticent to do anything that might strengthen the competition, also did not initially support UML. Instead they were moving in a different direction based on domain-specific languages. The interest for UML waned dramatically, especially in the years following 2003. The momentum was clearly moving away from UML.

Now we find the pendulum swinging back. There are a number of good and easy to use tools. The criticism from the academic community has quieted. Agility has been embraced by large companies who see value in both “smart” modeling combined with an agile approach. People use UML though skepticism about the tools remains; many people work with sketches on white boards and use tools sparingly. Microsoft found that domain-specific languages did not replace the role for UML and that customers actually wanted to use UML. Today Microsoft is a strong supporter of UML.

Today the world looks upon UML with a more balanced perspective. UML is not the ”silver bullet” it was sold as ten years ago. Nor is it as bad as academicians, agilistas and competitors claimed five years ago. Used appropriately it is a practical tool for raising the level of abstraction on software from the level of code to the level of the overall system. And its use increases again, as it should, but now with more common sense.

Still, UML has become complex and clumsy. For 80% of all software only 20% of UML is needed. However, it is not easy to find the subset of UML which we would call the “Essential” UML. We must make UML smarter to use.

24 Comments
  1. Andrea Baruffaldi | October 16, 2009 at 10:19 am Reply

    avatar

    Ivar,
    just wondering if you could put an hyperlink to our “UML lovers” Linkedin group.

    http://www.linkedin.com/groups?gid=143183

    Thank you anyway and
    Regards,
    Andrea Baruffaldi

  2. Skip Pletcher | September 16, 2009 at 3:48 pm Reply

    avatar

    “Used appropriately it is a practical tool for raising the level of abstraction on software from the level of code to the level of the overall system.”

    SysML extended UML to raise the level again. Might the part of UML adopted in SysML (Table 4.1 in the v1.1 SysML spec) compose a candidate core UML?

  3. Pedro J. Molina | September 4, 2009 at 10:30 pm Reply

    avatar

    Excelent post! My reaction to it is:

    “The 20% of UML is useful to describe the 35% of the design. (For the restating 65%, other models are still needed, if possible!)”

    http://pjmolina.com/metalevel/2009/09/using-the-20-percent-of-uml/

  4. Andrea Baruffaldi | July 22, 2009 at 4:06 pm Reply

    avatar

    I think that we do have great tools (Rational, Nomagic, Select, etc.) so UML is really more applicable than in the years 2000-2003
    (Ivar, I swear I never believed in automatical software :-).

    I found UML 1.5 good enough for most sw development, so UML 2.0 might have created too many new entities and diagrams. It might be a good thing but I think it will “frighten” newcomers, making UML a complex thing.

    I hope 3.0 will not be too complex…

  5. David Morris | July 9, 2009 at 8:59 am Reply

    avatar

    I think the idea of an Essential UML would be good, as there are whole tracts of UML that I have never used (probably because of the types of projects with which I’ve been involved).

    Interestingly, I sit in the camp of using UML on assignments likely to result in software and BPMN for assignments likely to result in business process change (UML seems so counter-intuitive to most business people).

    However, Occasionally you start with one then realise you need the other. If only there were some way of getting them to work better together. They are both managed by OMG, but do not seem to be in ‘danger’ of converging.

    A plea: Perhaps we could have a universal business and systems modeling notation that covers software and business?

  6. Mike MacDonagh | July 8, 2009 at 11:02 am Reply

    avatar

    Hi all,

    Ivar’s currently in China and so can’t access IvarBlog to comment but he asked me to post on his behalf to say that he’ll reply as soon as he can access the site again.

    Mike.

  7. JF Couturier | July 7, 2009 at 12:11 pm Reply

    avatar

    As i wrote on LinkedIn groups “UML Lovers”, i found an interesting paper on “How UML is used” by Brian Dobing and Jeffrey Parsons.

    http://www.informatik.uni-freiburg.de:8080/swt/teaching/winter-term-2008/software-design-modelling-and-analysis-in-uml/p109-dobing.pdf

  8. Scott Ambler | July 7, 2009 at 12:22 am Reply

    avatar

    In Agile Modeling we talk about how the primary value is in the act of modeling because it enables communication and promotes understanding.

    If you’re using sophisticated, software-based modeling tools, and have the skill to keep the models in sync with the code, and actually take the time to do so then there is potentially significant value in this. Sadly, few people seem to do this in practice.

  9. Jeppe Cramon | July 3, 2009 at 6:45 pm Reply

    avatar

    Dean, I agree and don’t agree. There’s SOO much that UML incapable of capturing, but what it does fairly well is capture flows and structural models, such as Domain Models. Textual DSL’s are very poor at describing structures and flows (to some degree), but I agree they beat most visual models for just about anything else.

    We’ve had great success modeling VERY complex domains (insurance for instance) in UML combined with Profiles which help you raise the level of abstractions hugely (It’s of great benefit to developers and business people modeling together, to be able to annotate an association between to entities with <> for Active history and <> for a full-blown Temporal Object pattern). Raising the level of abstraction :)

    If UML (mainly Class diagrams) is combined with a strong code generation infrastructure you can turn the dead model in to a live artifact :-)
    It’s actually quite agile – we’ve created both Hibernate/JPA domain classes and WSDL/XmlSchemas based on UML class diagrams. We can go back and refine the model, we can annotate it give more meaning. We can regenerate based on the refined model. We can find out that we need to approach certain parts of the JPA mapping differently or we have to change our service principles to encompass a new platform, refine the generator and regenerate. For code generation (e.g. Java or C#) this all comes with support for developer extensions that wont be overwritten by the generator (can e.g. be partial classes, 3 level inheritance, Scala mixins or privileged aspects). Perhaps you realize that you want to handle embeddable objects mapping different (e.g. have a boolean present field in each embeddable for technical reasons). No sweat, refine the generator and regenerate the code and you’re good to go.

    I’ve blogged about this here (link to a presentation): http://www.cramon.dk/Cramon/Blog/Entries/2009/5/7_Presentation_on_Model_Driven_Software_Development.html

  10. Dean Wampler | July 3, 2009 at 5:15 pm Reply

    avatar

    In practical terms, UML is still a failure, but so is every other attempt at graphical programming, with very few exceptions. To be fair, it seemed like a good idea at the time. Unfortunately, the old enthusiasm for UML prolonged the destructive obsession with Big Design Up Front.

    I find it useful maybe 1-2% of the time for whiteboard discussions, but it fails utterly to capture behavior, functional programming, aspects, etc., etc.

    Based on my years of experience, nothing beats a good textual DSL (or similar code or structured prose at the appropriately level of abstraction) for concision, expressiveness, and productivity. It’s not modeling, per se, that’s bad; it’s graphical modeling that’s bad.

    I say this as a former UML enthusiast who once worked on UML-based tools at a major software vendor.

  11. Skip Pletcher | July 2, 2009 at 5:10 pm Reply

    avatar

    Business rule (BR) community advocates seem to remain particularly dissatisfied with UML and able to articulate particular complaints. Few of these rulers overtly recognize UML (and software’s) distinctions between behavior and structure or that BRs exist in the latter (affecting the former when decisions occur). So the SBVR submission uses numerous UML and formal logic semantics to improve understanding, yet prefers natural language for rules declaration. Does BR feedback imply UML should grow, adopting new structural semantics to represent n-ary relations or do rules fall into the 20%?

    While simplifying by abstraction is human and noble, history implies language growth is the very tool for simplification. Although RISC was a successful contrary, processor instruction sets generally increase vocabulary over time; programming languages add more terms (directly or through Standard Libraries) than deprecated, and natural languages evolve and intermingle daily. It may be there some finite (if indistinct) human limit which necessitates natural language term abandonment, but there are also regional extensions by dialect, and the peculiarities and cants of special interest groups. Paradoxically, it would seem that if we wish to reduce the practically useful set of UML semantics, we would do so by extending its vocabulary to support higher abstraction.

    UML is your child; a child may get older and smarter, but not smaller!

    Perhaps in an industry attempting SOA amid growing technological capacity for independent concurrent decisions we should consider not a simplification of the language but a method for simplifying its specialization. UML Profiles are in some sense Domain Specific Modeling Languages which exist in their own ‘namespaces.’ No magic bullet in that approach, but perhaps a valuable idea may ricochet.

  12. Laurent | June 30, 2009 at 8:22 pm Reply

    avatar

    Good retrospective about UML.

    You say that “For 80% of all software only 20% of UML is needed”. But is all “features” of UML used at least somewhere? I would think so, even if some features are really more domain specific than others.

    As for the “Essential” UML, I’m pretty sure that would depend of where you work, what’s the project, what other principles are in place and what other techniques you’re already using.

    Having said that, I still agree with you that some kind of quick guide about the more used/useful features of UML could definitely help its correct adoption and remove some myth about it.

  13. Skip Pletcher | July 6, 2009 at 6:42 pm Reply

    avatar

    Is graphical modeling bad? Having worked with HP-VEE years ago, I found the graphical construct quite valuable for simplifying the development and documentation. Certainly it encouraged (top-down) incremental detailing. Eventually we detailed in C, but that C code became black-box reusable in (labeled) graphical terms.

    Or, as Jeppe commented, perhaps utility of modeling method depends on the modeled subject? Rules are certainly well-suited to text; geometric dynamics (how one flight path may intersect another) may be better suited to graphics. If so, then UML is just not one-size-fits-all.

  14. Ivar Jacobson | July 14, 2009 at 2:36 am Reply

    avatar

    Dean,
    Saying that UML is a failure is not based on any facts. My impression from visiting hundreds of companies every year is that every large software organization around the world uses UML and its usage is growing, now in a more reasonable pace. UML replaces SDL in the telecom market, and SDL has been in use by all telecom vendors for all telecom products for 30-40 years. Such modeling languages make it possible to understand, develop, maintain large software systems.

    Many of these big companies have used a subset of SDL/UML that integrated well with their programming language of choice. The effect was that whatever they modeled also became the code and vice versa. In these cases it was reasonable to model quite a lot of the system they were building. That situation doesn’t exist for most organizations, in which case I recommend people to just model what is architecturally significant (usually less than 10% of the code). And this is of course done iteratively so no Big Upfront Design is advocated.

    Saying that it “fails utterly to capture behavior, functional programming, aspects” is also not correct. SDL and UML have several different constructs to help with behavioral descriptions (in my opinion most don’t belong to the basics) such as state charts and activity diagrams. Functions (as in functional programming) should still be expressed as text or as procedures/formulas, possibly in task boxes if that makes them more explicit. My own book “Aspect-oriented software development with use cases” makes extensive use of UML.

    Recall, UML is not just diagrams. A typical UML diagram uses a lot of text as well, domain-specific language, rules, functions, etc.

    Dean, I want to ask you to try one more time.

  15. Skip Pletcher | July 6, 2009 at 6:55 pm Reply

    avatar

    Jeppe, would you go so far as to say the value of the model is directly related to the ability to keep it in sync with executable code? If so, the problem with applying UML would seem to lie in our ability to translate to/from machine language.

  16. ivar2 | July 7, 2009 at 12:14 am Reply

    avatar

    Personally I believe Essential UML will be so basic so most products would benefit from it.

    Important though that Essential UML can scale to much more, to most of what is in UML today. However, the ability to scale must not impact the small base. Thus designing UML using aspect techniques would help us achieve that goal

  17. ivar2 | July 7, 2009 at 12:20 am Reply

    avatar

    Skip,
    Being able to specify contraints using business rules is an important feature of a modeling language. These rules are best specified using text or a rule-based language. However, i am not sure I would classify it as part of Essential UML, but it certainly must be an extension to this basic subset of UML.

    Now, I have no problem that UML as a whole is quite big as long as it is structured so that you only need to learn the basics, if you only need the basics. The technique to describe UML in such a structured way is by using aspects. We have done exactly that to describe the Unified Process, starting from a very small kernel of say 15 elements. We can do the same thing for UML. I will write more about it in another blog.

  18. Jeppe Cramon | July 7, 2009 at 12:51 pm Reply

    avatar

    To me UML serves many purposes other than code generation, such as an overview (e.g. a Component diagram), sketching (e.g. constructive communication between a few people at the whiteboard) and illustrative purposes (e.g. visualizing call paths during program execution) where it’s a medium of.

    But all of these are of limited value as they are snapshots or projections of the application, which quickly get out of sync. It’s like Java doc that’s no longer representative of the design/code.
    To me the true value of a model is how well it is in sync with the world/application that it models. It doesn’t matter if the model represent a specific view/projection of a model as long as it’s in sync.
    Different models for different people, but in alignment with the implementation :-)

    As Scott mentioned below, it requires skill and discipline to make this work. I’ve been involved with several projects where we did this with great success. I’ve also been involved with customers that didn’t want to commit to this way of working with models. In these case I agree that the focus of modeling should be on communication with a clear indication that this is a momentary snapshot and doesn’t reflect reality :)

  19. andreabaruzzo | July 8, 2009 at 1:36 pm Reply

    avatar

    Scott, I substantially agree with your position on Agile Modeling and UML, especially concerning the need to keep models in synch with code. Even not all uses of UML are focused on building software systems, in the long run such ability is very useful. Nevertheless, I believe that keeping models synchronized with code should not be a responsibility of the (sole) modeler. This is (from my point of view) a clear defect of current tools, especially of MDA tools.
    Simply, at the moment we have not tools which are enough sophisticated and usable to perform this task, but I hope that in future things will change, as they changed concerning the (basic) support of the UML standard in the last five-tens years.

    Many current UML tools nowadays do a pretty good job in organizing the overal model in several views (logical, physical, ad so on…), working more or less consistently with many diagrams. But all these diagrams remain at a single “abstraction level” (in the sense of PIM, or PSM, accordingly to MDA speaking). What if a tool would be able to consistently manage also the transformations from the PIM model to any platform-specific model (including also the code “model”), letting the modeler working at the level of abstraction that best fits his current needs? I understand the technical difficulties in doing such a tool, but I believe that the only viable route to keep UML diagrams in synch with code without perverting them in implementation artifacts is automation. Unfortunately, doing automatic synchronization today coincides often (at least in my experience) with the dead of the design :( in favour of (a supposed) increment in productivity. The final result, is typically different: a system built quickly, always in synch with code, where the level of design is completely lost (if never entered in the project at all).

  20. Ivar Jacobson | July 14, 2009 at 2:56 am Reply

    avatar

    Andrea and Scott,

    I don’t think I could have said it better than you.

    Five years ago I truly believed we could make UML executable. I still believe it could have been done, but for many reasons (political, existing platforms, frameworks, etc.) it won’t be done. However, there is really no fundamental reason to have a clear separation with modeling and coding, unless you believe visual models are not useful.

  21. CWW | September 1, 2009 at 4:57 pm Reply

    avatar

    Scott Ambler Says: “keep the models in sync with the code, and actually take the time to do so”

    I think that hits the nail on the head squarely. ‘Real’ accurate stories (or data flows) in agile, ‘real’ accurate SRDs/RQTMs in waterfall, or ‘real’ accurate UML diagrams in sprial synced with code/implementation gurantees that the critical path will be solved. And yes, I have yet to see a team (big or small) using all the current methodologies really dedicate time to document appropriately–it’s a stewardship issue that no methodology has stressed and with the rapid turnaround of s/w nowadays (somewhat due to agile methods), teams easily fall into the trap to skip the needed documentation, “put the docs in the code”, and call it a day… since the next refactor/version/design is just around the corner.

    And having teams stay disciplined on communication protocol with one another creates an environment that design and documentation is decoupled from code: that’s a good thing. That was a thing lacking in the agile world that UML had, of course, until agile modeling took hold, and provided the consistent grounds for team members to communicate tasks (via the models)–we found agile modeling incredibly valuable if your agile team members have different domain expertise.

  22. Ivar Jacobson | July 14, 2009 at 3:10 am Reply

    avatar

    Originally UML 1.1 contained support for business process modeling. Frankly, I have not followed the development of UML in detail since then so I don’t know if it has been pushed out by the UML 2.0 people.

    I have done a lot of business modeling and I see no fundamental problem with UML to support it. However, I believe we need to be sensitive to notation. Business people want a notation that is close to their own business and not a generic notation.

    We also need to realize that using activity diagrams or similar to model business processes really only work for well-known processes — and then the need is much less than for new processes. The problem is that the activities are not anchored in anything concrete. I have exaggerated and said “the activities are floating around in the semantic emptiness”, only understandable to the people who write the diagrams (if to them even).

    In my opinion you rarely need to do activity diagrams when modeling business processes intended to be implemented (fully or partly) in software.

    The consequences of having different modeling languages for business and software are 1) too much modeling, 2) translations between the models are very hard to do and introduce unnecessary failures. This is the same problem you have with domian specific languages with no common language base.