Using the 20% of UML

Via Jordi Cabot I found a quite interesting comment made by one of the “Three Amigos” about UML usage in his blog-post titled Taking the temperature of UML:

“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.”

Ivar Jacobson

The full post is a good review about the origins, the growth, and the current status of UML made by one of its three fathers. Ivar also argues about the current size of UML (really fat nowadays) and the necessity to put it on diet to achieve a kind of “Essential UML”. I like the idea of essential UML. It makes worthy to read it.

On the other hand, I want to stress the quote of Ivar Jacobson:

“For 80% of all software only 20% of UML is needed.”

I agree. My own quick usage stats of UML models when creating business software could be the following ones (please share your experience):

  • Class models: 100% (a must: always, to define the static structure and derive DB support if needed)
  • Component diagrams, Sequence diagrams, Package diagrams: 10% (when the complexity of the design needed)
  • Deployment diagrams 10% (to describe non trivial deployments)
  • Statecharts 5% (when needed)
  • Object diagrams 1% (just to explain complex configuration of error conditions)
  • Use Cases diagrams 20% (Informal usage only: sorry it’s me, the semantics of Use Cases never were clear to me.)

When developing business software, my problem is not with the part that can be expressed using a 20% of UML. On the contrary, the key issue is how to model and reuse the knowledge about the part that can not be naturally expressed using UML.

With the adjective naturally, I want to express the suitability of a (visual or not) language to describe a problem in a given context. I will provide some samples about that in a few lines.

  • A great percent of current software is created for supporting day to day business operations in companies: let’s call it business software. And this software is developed using Java, C#, PHP, (choose you favorite language), etc. using more or less standardized frameworks usually providing ORM, IoC and MVC capabilities. I will skip this time games, OS, drivers and real time apart for the discussion (different domains).
  • In this kind of software, the user interface is about the 50% of the development effort accordingly to Brad A. Myers survey [Myers92] (and corroborated by my experience).

Therefore, to cite a few other domains not (well?) addressed by UML:

  • What part of UML can help you to naturally describe your User Interfaces? There is no specific support in UML for describing UIs as first class citizens.
    • Task models?
    • Navigational diagrams?
    • Presentation diagrams? 2D layout relationships and aesthetics?
    • Presentation logic?
  • How to express in UML high level algorithms for describing the key business logic? Visual languages do not scale well, and text languages (like pseudo-code) are more convenient.
  • What type of UML diagram can I use to describe a security model for my app?

In this context, my statement could be:

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

Of course, lots of people will argue (and some people guys tried this before): you have MDA, you have the possibility of creating a profile. You can use stereotypes to derive from a UML model of your choice, change the semantic, change the symbols and change the rules and you got it. But the result is not as good as you can achieve with a custom DSL: a hyper-tuned Class Diagram is not good enough to describe a good UI. And it is not good enough (not for me at least) because:

  • The concepts stereotyped could have a different semantic. A class is a class, but after you apply a stereotype, now it can represent an HTML page, or a windows control (it depends). This causes confusion in users.
  • The restrictions of the base (visual) language are inherited and its difficult to prune or extend metamodels in the way you need it if the target ones is really different with respect to the base metamodel.
  • Model editors matters: a class diagram is not explored and edited in the same way as you work with a navigation diagrams, for example. Scalability of the model matters when you start to have a non trivial example.

A 35% percent is not too much. And this explain why here we are: having some of us doing MDD, using forbidden MDA-outlaw custom DSLs to describe service description, workflows,  user interfaces, concurrency, and some other domains that could be in the extreme be modeled, but not in a natural way, with UML today.

Of course, UML has provided a great utility providing to developers and software architects as a starting point for a standardized common language for designing software. For this point, it makes a great contribution. But also, is necessary to say that more frequently that recognized, you need something else that is not included in UML (not yet).

In this sense, I hope to see de-facto standardized DSL/languages/diagrams for other software domains included in UML in the next releases.

To be continued… …UML 3.0 is coming!

BTW, till completing UML, long life to custom DSLs! }:-)


  1. […] I like Pedro J. Molina’s article in his post “Using the 20% of UML”. […]

  2. Hi Pedro,

    I agree with you in that you don’t find suitable constructs in UML to model many of software aspects/concerns. UI is just one of those aspects that seems to be forgotten by the specification.

    However, I’ve often wonder whether it is really our fault to have considered UML as actually adequate to model any aspect of software! As an example, in that very same post, Jacobson recommends “to just model what it is architecturally significant (usually less than 10% of the code).” Perhaps UML just stands for modeling objects and their relationships and interactions, in a narrow (and somehow blur) strep of a generative architecture.

    I’m a deep advocate of MDE/MDD, so I think every aspect of the software development must be expressed as a model, and definitely UML and its extension/specialization mechanism (Profiles) is not the solution to give support to any necessary DSL we came across to model those aspects.

  3. Hi Orlando:
    Thanks for you comments. I agree.
    With this post, I wanted to emphasize the bad practice of abusing of UML and profiles thinking in terms of one-size fits-all.

    Glad to see MDA work in progress in Canarias!
    I didn’t know about your company and now I see you are working in the area.

    Kind regards from Valencia.

  4. Hi Pedro,

    I’m very interested in your statement that “20% of UML is useful to describe the 35% of the design”. ¿Do you have any experiment or experience report to support those figures?

    This is part of a larger discussion: UML vs MOF to build up DSLs. Disciplines such as Language-Oriented Programming, Model-Driven Engineering and Software Architecture have already found serious limitations in UML to describe the diferent concerns/aspects of a software system. An experiment or case study showing your 20%-35% ratio (or so) would be terrific 😉

    BTW: I’ll send you a linkedin invitation to my network so we can keep in touch for interesting discussions.


Post a comment.