UML may suck, but is there anything better?

UML has been getting a lot of criticism from all sides, even from the modeling community. Sure, it has its warts:

  • it is a huge language, that wants to be all things to all kinds of people (business analysts, designers, developers, users)
  • it has a specification that is lengthy, hard to navigate and often vague, incomplete or inconsistent
  • it is modular, but its composition mechanism (package merging) is esoteric and not well understood by most
  • it is extensible, but language extensions (profiles and stereotypes) are 2nd-class citizens
  • it lacks a reference implementation
  • its model interchange specification is so vague that often two valid implementations won’t work with each other
  • its committees work behind closed doors, there is no opportunity for non-members to provide feedback on specifications while they are in progress (membership is paid)
  • <add your own grudges here>

However, even though I see a lot of room for improvement, I still don’t think there is anything better out there. The more I become familiar with the UML specification, the more impressed I am about its completeness, and how issues I had never thought about before were dealt with by its designers. And it seems that the OMG recognizes some of the issues I raised above as shortcomings and is working towards addressing them. Unfortunately, some fundamental problems are likely to remain.

In my opinion (hey, this is my blog!), for a modeling language to beat UML:

  • it must be general purpose, not tailored to a specific architecture or style of software
  • it must not be tailored to an implementation language
  • it must be based on or compatible with the object paradigm
  • it must not be limited to one of the dominant aspects of software (state, structure, behavior)
  • it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication
  • it must be modular, and user extensions should be 1st class citizens
  • its specification should follow an open process
  • it must not be owned/controlled by a single company
  • it must not require royalties for adoption/implementation

My suspicion is that the next modeling language that will beat the UML as we know today is the future major release of UML. Honestly, I would rather see a new modeling language built from scratch, focused on building systems, that didn’t carry all that requirement/communication/documentation-oriented crap^H^H^H^Hbaggage that UML has (yes, I am talking about you, use case, sequence, instance and collaboration diagrams!), and developed in a more open and agile process than the OMG can possibly do. But I am not hopeful. The current divide between general purpose and domain specific modeling communities is not helping either.

So, what is your opinion? Do you think there are any better alternatives that address the shortcomings of UML without imposing any significant caveats of their own? Have your say.

Email this to someoneShare on FacebookShare on LinkedInShare on Google+Tweet about this on Twitter

19 thoughts on “UML may suck, but is there anything better?

  1. Vlad Varnica

    February 8, 2010 at 8:57am

    UML is just perfect and is a return of experience of over 1 millions users around the world.
    The current UML problem is related to model transformation because no native integration with Java and metamodel.
    In France we call it “Usine à Gaz” and my personal English translation is EMF software factory :-)

    Vlad,

  2. Jilles van Gurp

    February 8, 2010 at 12:12pm

    Maybe you’re asking the wrong question: why do you need a modeling language to begin with and why does it need all those qualities? Who is the customer for your models and does he/she agree with the amount of resources you spend on creating them? After all, models just sit there and they are not executable code representing actual business value.

    For me the answer is, I don’t need a modeling language and I don’t really need anything beyond a whiteboard in terms of standardization, portability and what not. Draw and forget is my motto. If someone insists, photos get taken with my phone camera (though in my experience these photos are archived and never looked at). That’s it. I have some tools available if somenone needs a powerpoint friendly version. Though presenting hand drawn images is kind of cool in some places nowadays. I almost never use these tools because frankly nobody that matters gives a shit about UML diagrams where I work. At best uml diagrams are a checkbox in the documentation requirements list, a i.e. a low priority diagram in an artifact that we occasionally spit shine. If we have time and if it doesn’t eat too much into Friday afternoon beers.

    Agile and UML don’t go together unless you are faking either the modeling bit or the agile bit. I’ve seen a lot of people faking both. Seriously, there is no modeling phase in an iterative & agile project. There’s iterative development of all the development artifacts (requirements, designs, code, tests, documentation). Iterative meaning working code at the end of each sprint (2-3 weeks). If you are wasting most of your sprint on modeling you are not delivering business value. So if you spent a lot of time modeling in a project either your models never change, i.e. you are doing waterfall, not agile, or you spend a shitload of time revising your models every sprint, meaning that you are wasting a lot of time better spend on something that will actually last, i.e. code. Tell tale signs that you are faking it: you have uml diagrams, each sprint is organized like a mini waterfall, you don’t have working code at the end of a sprint.

    MDA may seem like a good idea. However, you have to realize that with MDA you are just redefining what is your programming language. So, you are merely programming in a different language (i.e. UML) and no longer modeling but coding. UML is a modeling language, it is not a programming language. Some would even argue it is suitable for neither purpose. If you want to do MDA, you are probably better off with a domain specific language on top of a well defined framework. You will end up with less code to maintain, which is good. This in a nutshell is why Ruby, Ruby on Rails and the dozen or so similar languages and frameworks are so popular lately. These solutions are ideal for quickly implementing frameworks and then co-evolving the framework with the scripting code that uses it. Much more light weight, much more easy to fit in an agile work style.

    In most companies I have had the pleasure of working with, visiting, or otherwise had to deal with, MDA was a dirty word and the available rational rose licenses were exclusively used for writing documentation and creating pretty pictures for power point slides (despite the often equally nobel and misguided reasons for purchasing said licenses). Generally the more primitive the programming language used, the more need there is for documenting the decades of crap in the version control system and the more time and resources people seem to spend on documenting the crappy code they have. I know of several embedded software development companies where multiple attempts of introducing rational rose silver bullet type solutions have failed utterly and completely. On the other hand. introducing TDD, agile and other more sensible practices is the reason why some of these companies are still around.

  3. rafael.chaves

    February 8, 2010 at 12:28pm

    Thanks for your comment, Jilles. Yeah, I realized later that I didn’t state clearly (or otherwise) the only reason I care about UML: it is as a general purpose modeling language for MDD.

    While I read your comment with much interest, I fundamentally disagree with much of what you said about MDD being coding, not modeling, that UML is not suitable as a MDD modeling language, that agile and UML don’t go together, or that DSLs are the only way to go. I hope to have time later today to write a more elaborate response.

    Cheers.

  4. Vlad Varnica

    February 8, 2010 at 3:30pm

    I agree with Jilles that MDA has failed in agile development till now but it is not because we failed at the first attempt that you should not try again. It remember my first love experience which was really very mediocre but after many year of experience it is totally different today :-) Sorry for this language but this is my true feeling reading your post !!
    Except my today’s joke I would say that for me MDA is not agile but UML could be agile. I am today deeply chocked by UML users just trying quickly to create few views and don’t even use 1% of the power of UML. A minimum investment is a requirement and if you don’t want to take this time then it is better not to do any UML. In the last 12 months I have seen many modeling projects and it was really very very poor.
    My question is: Is it MDD or an education problem concerning the adoption of MDD in an agile project ?

  5. Rui Curado

    February 8, 2010 at 4:49pm

    I am working on a MDD methodology aiming to replace/displace UML/MDA/EMF/others. There’s a lot of ambition here, of course!… So, let’s see how ABSE ranks in your language-to-kill-UML checklist:

    * it must be general purpose, not tailored to a specific architecture or style of software

    Check

    * it must not be tailored to an implementation language

    Check

    * it must be based on or compatible with the object paradigm

    Check

    * it must not be limited to one of the dominant aspects of software (state, structure, behavior)

    Check

    * it must be focused on executability/code generation (and thus suitable for MDD) as opposed to documentation/communication

    Check

    * it must be modular, and user extensions should be 1st class citizens

    Check

    * its specification should follow an open process

    Check. Although I have to make a living out of it, I’m trying to keep ABSE as open as possible.

    * it must not be owned/controlled by a single company

    If it’s open, then there’s no “vendor lock-in”. But everything not yet clear at this point. Half-check!

    * it must not require royalties for adoption/implementation

    Check

    Score : 8.5/9
    So, ABSE is looking good so far per your requirements…

  6. rafael.chaves

    February 9, 2010 at 12:23am

    @Jilles:

    “why do you need a modeling language to begin with and why does it need all those qualities?”

    MDD allows developers to work at a more proper (higher) level of abstraction through a better separation of domain concerns from technological concerns.

    “Who is the customer for your models and does he/she agree with the amount of resources you spend on creating them?”

    I and my peer developers are the consumers of the models, just as with source code. The customer itself does not care how I build software, but does care if quality is more consistent, or if time to delivery is more predictable, or if takes less time for a new hire to become an effective contributor, or if it is easier to enhance the software to adapt to changes in the problem domain or technological requirements.

    “After all, models just sit there and they are not executable code representing actual business value.”

    My fault for not making it clearer from the beginning. My sole interest in UML is for creating executable models (MDD). Executable models don’t sit there. They are the real deal.

    “For me the answer is, I don’t need a modeling language and I don’t really need anything beyond a whiteboard in terms of standardization, portability and what not. (…) If we have time and if it doesn’t eat too much into Friday afternoon beers.”

    Totally agree if we are talking about models for documentation. I can’t care less. Totally disagree if we are talking about model-driven development, with executable models (which *is* indeed what I was talking about in this post).

    “Agile and UML don’t go together unless you are faking either the modeling bit or the agile bit. (…) Tell tale signs that you are faking it: you have uml diagrams, each sprint is organized like a mini waterfall, you don’t have working code at the end of a sprint.”

    Again, if talking about UML as communication/documentation notation, true, but not if talking about UML as programming language. See an old post on “UML modes“.

    “MDA may seem like a good idea. However, you have to realize that with MDA you are just redefining what is your programming language.”

    That is a fine perspective, but what is wrong with raising the level of abstraction of my ‘programming language’?

    “So, you are merely programming in a different language (i.e. UML) and no longer modeling but coding. UML is a modeling language, it is not a programming language.”

    Java, Ruby, C/C++, Smalltalk are just different 3G GPLs. There is a clear difference in level of abstraction between C and 8086 assembly. Same thing between UML and Java or Ruby. Re: modeling vs. programming, that is really relative. One can say a C source file is a model for an executable file, or that a UML model is the source while the generated Java code is object code. See “On code being model“.

    Re: UML capability as a ‘programming’ language, I think it is powerful enough for what we need, and that is why I refuse to accept anything more ‘powerful’ (because that leads to over-specification).

    “If you want to do MDA, you are probably better off with a domain specific language on top of a well defined framework.”

    Why should I commit to a specific implementation technology when I have no intent to make use of it? Why should I lose my investment if I decide to target another implementation technology? Why should I choose Ruby for an accounting system, when Ruby’s technical capabilities have no bearing in my understanding of how to implement an accounting system? Why not use a pure, highly abstract language that forces me avoid adding more detail than necessary, instead of a full-fledged GPL that is bound to impose its technical idiosyncrasies?

    “You will end up with less code to maintain, which is good.”

    Not sure how MDD leads to more code. For me, MDD is the ultimate refactoring technology.

    “This in a nutshell is why Ruby, Ruby on Rails and the dozen or so similar languages and frameworks are so popular lately. These solutions are ideal for quickly implementing frameworks and then co-evolving the framework with the scripting code that uses it. Much more light weight, much more easy to fit in an agile work style.”

    Ignoring the fact that they have a more limited purpose, Ruby on Rails and Grails share much of the MDD mindset, using a convention-based programming model on top of GPLs, instead of a true modeling language.

    As per MDA being a dirty word, I am working towards cleaning its name. ;)

    I apologize for dumping a bunch of links to older posts on you, just trying to make my point of view more clear without repeating myself too much.

    Cheers,

    Rafael

  7. rafael.chaves

    February 9, 2010 at 12:28am

    @Rui: ABSE does sound promising, looking forward to seeing your work. Good luck!

  8. Emilio R. Priego

    February 9, 2010 at 4:53pm

    Good post!. Essentially, I agree with your opinion about UML. I am using UML in my company (from Government sector in Spain) where it has been very useful for “sketching”. However, MDA/MDE is not generally used for generate code in real life. Why?. Theory is very good, but in practice there are not clean PIM, PSM and CIM reference models to start with.
    I think UML is very complex and people are using only the simple/easy part. UML theory is very hard to understand. In my opinion Model theory is a superset of UML Theory. Modeling is a new paradigm but UML is based in the Object Oriented (previously winner) paradigm. OMG tried to fit all pieces but it’s confusing use objects to explain models. The right way is just the opposite.
    (e.g. nobody use operations part in a class model and in contrast, UML models are not true object-oriented e.g. there is not a diagram expressing both structure and behaviour).
    The other main problem is model terminology. There are a lot of papers about modeling, discussing concepts (model, metamodel, modeling languages, etc.). And UML concepts (instance of, package, merge, etc.) add more confusion in that discussion. It’s not possible to apply MDE if you don’t understand the modeling concepts as it’s not possible to write good Java programs if you don’t understand object oriented concepts.
    I’m not hopeful about the future of UML. I think that the problem is that paradigm shift is doing without a widely accepted agreement about the modeling theory concepts.

  9. Dominique De Vito

    February 11, 2010 at 1:42am

    I think a UML alternative could be IP – Intentional Programming : http://en.wikipedia.org/wiki/Intentional_programming

    Here are some differences with UML:
    - IP standardizes the abstract level and authorizes as many view as one wants
    - IP enables to integrate graphical descriptions and DSL
    - with IP, the integration of the different views in relation with the abstract model is a problem from the start because there could be N views, but there is only one abstract model: and it’s good that this is a problem from the start, because users then don’t forget the final step: the code generation.
    - etc.

  10. rafael.chaves

    February 11, 2010 at 8:21am

    @Dominique

    I find the ideas behind Intentional Programming very cool, but isn’t IP a paradigm instead of a concrete technology? The only concrete technology implementation I know of is by Simonyi’s Intentional Software, but I suspect that fails the last three criteria (open process, open standard, patent free).

  11. Dominique De Vito

    February 12, 2010 at 3:42am

    @Rafael

    The papers I have read say that there is a IP concrete technology implementation, and indeed, that’s the Simonyi’s one; it’s said to be used by Cap Gemini, for example, for some real-world test projects.

    And, yes, I am sure it fails the last three criteria (open process, open standard, patent free) ;-)

    But while I am an open source proponent, I still value non-open source products if they show enough added-value, and I am happy there is still some initiatives outside the all-inclusive-UML world, for drawing new interesting directions.

    This being said, you may be interested to read my post about UML drawbacks I see:
    “UML business hotspot is over (but modeling business still makes sense)”
    http://www.jroller.com/dmdevito/entry/uml_business_hotspot_is_over

  12. rafael.chaves

    February 12, 2010 at 8:37am

    @Dominique

    Note that I did not say anything about an implementation having to be open-source. My problem is with control and competition.

    Thanks for the link, it was an interesting read.

  13. Vladimir

    February 12, 2010 at 10:48am

    About modeling and agile. I’ve participated in two projects implemented using MDD approach. Both projects use UML (or MOF) as a base for modeling. Both projects were agile. These projects were even more agile than obvoius ones since there were no such resistance for model refactorings as it’s without MDD. It was agile just because developers don’t have to rewrite a bunch of things like Java, XML’s, deployment descriptors, DDLs, on any “agile” model change.

  14. Jilles van Gurp

    February 13, 2010 at 6:44am

    @Rafael. Exactly, you are treating your UML tool as an IDE. Fine, but stop calling it modeling then. Or if you insist, the rest of the world models in traditional programming languages. BTW. what about agile practices such as TDD, refactoring, etc. What about the inevitable case where the domain starts to evolve (there’s no such thing as non evolving software)? I’ve seen a few MDA projects fail quite spectacularly a couple of years ago exactly for this reason. As for agile, it’s a very overloaded term, even more than the word modeling. Lets just say that not all agile projects are created equally. Also most companies that I have encountered that claimed to do agile were in fact faking it badly. Finally, UML is a specific implementation technology that you seem to have committed to. Like with any such commitment, migration to some different technology quickly becomes infeasible. If it suits your needs fine, but don’t attribute too much magical value to it in terms of being a level up in terms of abstraction. There’s quite a bit of interesting stuff going on that is quite hard to map to UML, such as erlang/go style concurrency, AOP and annotations, closures, map reduce, etc. Basically all of that is way out of the comfort zone of MDA. Apples and oranges, I know. But the point here is that MDA is just good 30 year old OOP. Your text UML sample looks disturbingly like Delphi met Java. Needlessly verbose and I’ve seen nicer ways of saying hello world.

    @Dominique, I’ve been following Simonyi and IP for about a decade. Unfortunately, beyond the papers he has never produced anything substantial in public. What they are doing exactly at intentional software is pretty much a big mystery. To me the time that has gone by without any substance suggests a pile of software that is not working as advertised (in the papers a decade ago). Meanwhile, Ruby seems to fill the gap quite nicely when it comes to DSLs and meta programming. Not the same thing of course but so much more practical right now.

    @Vladimir model refactoring assumes that everything your model depends on in the real world is stable. It’s not unheard off but usually pretty much exclusively limited banking or insurance type IT projects, which incidentally is also a domain where DSLs have been used successfully. In the rest of the world, change is the norm in all layers of the system.

  15. rafael.chaves

    February 13, 2010 at 10:31am

    @Jilles

    “what about agile practices such as TDD, refactoring, etc. What about the inevitable case where the domain starts to evolve (there’s no such thing as non evolving software)?”

    Why would MDD be inherently incapable of allowing these? If what I am calling modeling here is just higher-level-of-abstraction programming, what are the challenges with refactoring and automated testing that you are alluding to? They might be obvious to you, but I can’t see any. Models are executable, so they can be exercised by automated tests the usual way. And refactoring of models should be simpler, not harder than ordinary code, because with the better separation of concerns, changes are handled in a more localized way, reducing the chances for widespread changes.

    “Finally, UML is a specific implementation technology that you seem to have committed to.”

    First, it is different from conventional implementation technologies because it goes out of its way to be removed from mundane technical implementation details. In modeling, we strive not to over-specify a solution, thus preserving its generality and allowing it to be realized in different ways, effectively separating the general solution concerns (intentions) from concrete technology implementation concerns.

    Second, I am not committed to UML, I will happily drop it for any better alternative (that was the whole point of this post!), according to the constraints I refer to.

    “migration to some different technology quickly becomes infeasible”

    That is one of the selling points of raising the level of abstraction. You don’t need to migrate as often, as you get farther from concrete implementation technologies, things are much more stable. And when you do have to migrate, you have way higher chances to be dealt with an automated transformation, as model compilers can make sense of the intent behind a model way more easily. Win-win.

    “There’s quite a bit of interesting stuff going on that is quite hard to map to UML, such as erlang/go style concurrency, AOP and annotations, closures, map reduce, etc.”

    Why do you say so? If those things can be done in ordinary OOPL, what is the difficulty with doing that with UML? Any concrete examples? UML activities are inherently parallel, you have to go out of your way to make things execute sequentially. UML supports annotations way before any programming language I know (stereotypes and tagged values). UML can be extended to support closures very easily (TextUML allows them, search the main page for “closures”). For things it does not have native constructs for, you can address the library-way instead of the language way, and if beneficial still provide native support in your notation (such as I did with closures). The language can be evolved to address gaps where it makes sense, but in most cases concrete implementation improvements are more properly taken advantage of by changing the transformation rules, not the models.

    “Your text UML sample looks disturbingly like Delphi met Java. Needlessly verbose and I’ve seen nicer ways of saying hello world.”

    That does not seem to be related to what we are talking about in this post, which is about executable modeling languages (and how UML seems to be the only option at this point), not about TextUML specifically. Actually, separation between abstract and concrete syntax (which may not even be specified) is another must-have for any replacement to UML, as it is something very valuable that it already does well.

    That being said, I would be glad to hear your complaints/suggestions about the TextUML notation or the TextUML Toolkit by e-mail (rafael at this domain), twitter (abstratt), discussion forum or issue tracker.

    Cheers,

    Rafael

  16. Design then develop

    May 3, 2010 at 6:40am

    Well,

    If you have a good tool to rapid create a prototype and simulate your application then UML is pretty good.

    Does anyone have tried UML Almighty tool ?

    What about the simulated Web application ? Is it good ?

    Regards.

  17. Marco Brambilla

    November 5, 2010 at 3:08pm

    Back to: “UML, is there anything better?”
    Yes, there is, if you know what you are going to do.
    In other words: a universal modeling language may not always be the best solution. We are actually witnessing the increasing success of domain specific languages/ models (DSL/M), targeting the needs of specific application domains and the expectations of specific users.

Comments are closed.