Why UML Fails to Add Value to the Design and Development Process

While attending the Domain Specific Modeling workshop at OOPSLA 2008, I heard many pointed criticisms of UML. No one went into detail, so I bought a book on DSM by Steven Kelly and Juha-Pekka Tolvanen. The book was not cheap– over ninety bucks when tax was added. (Doh!) So far I’ve read the first four chapters, but they cover the problems of UML fairly well in those early sections and also outline the basic tenets of the DSM philosophy as well. I’ve synthesized the gist of their points below. All the good ideas about modeling architecture below are imperfect summaries of Kelly and Tolvanen’s work. The opinionated ideas about programming languages and tools are my own.

UML is applying an abstraction at the wrong end of the problem. It is primarily used to sketch object models for inferior languages. As such, it tends to explode into incomprehensible patterns of accidental complexity in order to accommodate the various “design patterns” that are used work around the lack of essential language features. Because the UML models cannot be compiled, executed, or interpreted, they are reduced to the level of mere documentation. As such, it is generally not even worth keeping in sync– the manual round trip from the code to the model and back is just too expensive for something that adds no more value to a project than an elaborate code comment. (Slides of elaborate UML diagrams, on the other hand, are nevertheless great for impressing the uninitiated in a presentation, of course– that goes without saying!) Efforts to “fix” UML tend to not to gain traction: the specification is itself too broad and coding environments and applications are themselves too diverse.

A modeling language needs to do three things on order to become useful:

First, it should map directly to domain problem concepts. UML is designed to map to coding architectures– and because of this it fails to raise the level of abstraction. The jump from assembler to C gave an order of magnitude increase in productivity because of its corresponding increase in abstraction. OOP languages and UML have not given the increase in productivity gains that they should have– in some cases they may even hurt productivity. Modelers should not even think about implementation details when they develop their language. Instead they need to focus on mapping their ideas directly to the domain concepts. (Note: this is not a new idea. Ableson and Sussman popularized this approach in their SICP lectures at MIT where they demonstrated how Scheme would allow them to define programs that called functions that didn’t even exist yet. They would start with the right solution… and then gradually build up until it would run. Michael Harrison talked about this when he described the ‘wishful thinking’ approach to programming from SICP.)

Second, the modeling language must be formalized. The modeling language must be a first-class citizen of the development process rather than just make-work for architects and project managers. It must be possible to generate useful executable code from the models made within the language. The language needs to add value not just in communicating with domain experts and helping them validate the “business logic”– it needs to add value at all levels of the development process. It needs to raise the level of abstraction for the code maintainers by allowing them to stop thinking about the underlying frameworks and libraries. It needs to contribute to testing efforts by eliminating the need for implementing certain classes of tests and also by providing a basis for generating other classes of tests automatically from the models. It needs to possible to generate documentation automatically from the models. The models should be useful in and of themselves and should be significantly useful to all development tasks downstream from them.

Finally, the modeling language should have first-class tooling support. The tools should not be thought of as IDE extensions for programmers. These tools are not “wizards” to generate ugly code or partial stubs for developers to flesh out. The tooling should stand alone for the domain experts; if they have to think about the code at all then the tools are developing in the wrong direction. Expert developers aware of the intricacies of the domain problem need to organize their frameworks and libraries in such a way that the models can be “compiled” into fully functioning code. The correct analogy for this is, again, to think in terms of compiling C to machine code. The C compilers are created by machine language experts. C programmers do not modify the compiled machine code– they use the results in practically all cases. The C programming environment allows the programmer to work at a higher level– without having to think in terms of the underlying machine code or hardware. C is, in effect, a modeling language for machine code.

So, to get a modeling language that is actually useful, you have to go “Domain Specific” on both sides of the problem: the modeling language has to map directly to the problem domain and the generated code has to map directly to the target environment. 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.

As Steven Kelly said in a 2006 article, “To make model-driven development work this way, you cannot use a general-purpose design language like UML and a modeling tool’s built-in code generator. The people that created UML did not design it for describing applications in your domain, or for generating code other than skeletons. Despite the efforts of many to make it suitable for generation, no one has ever, or will ever, make it happen in a way which is still smart and convenient. An application’s behavior and the rules it has to adhere to are domain-specific. To capture that effectively and completely in a graphical design, you need a Domain-Specific Modeling language.”

Update 10/30/08:

I have discovered some interesting ideas from the opposite point of view. Here is some remarks from Franco Civello— someone that has used UML successfully in model driven development:

“… having produced informal use cases to clarify requirements, and a domain model to get an initial understanding of the subject area, the analyst produces a precise specification model, in UML, in which the system to be developed is represented as an object, belonging to a type (note, not a class, as the system is an abstraction used to define visible behaviour, not a software entity to be directly implemented in e.g. Java).”

Notice the key similarity there with the Kelly/Tolvanen Tolvanen approach. Civello is not using UML to describe the code architecture– he is mapping the UML more toward the problem domain.

“Steps in the use case flows are then formalised as operations on the system type, with a declarative specification of behaviour based on the notion of functional contract, written as pre- and post-conditions expressed on an underlying model (the system type model, derived closely from the domain model).”

Again, this point reflects back to my second point: there must be a formalization of the modeling language at some point. Note also, we have (possibly) an analog to the declarative approaches that I saw in the ModelTalk presentation last week.

“UML static modelling gives you the language to represent the state of the system in abstract and yet precise terms. Just don’t think of your classes as software things with methods and member data, but as specification types that give you the vocabulary to specify the business outcome of a system operation. These types can have attributes, associations, queries, constraints and definitions, all powerful UML concepts, but no state-changing operations. The only state-changing operations are defined at the system level, and are not elaborated into message-based solutions, but just specified declaratively in terms of business logic, steering clear of any design decisions.”

28 Responses to “Why UML Fails to Add Value to the Design and Development Process”

There’s another side to UML. It’s a convenient notation for sketching on boards while talking with other programmers. It’s a tad more formal than English, more agreed-upon than a do-it-yourself diagram, but still high enough level that you can chat about general directions without getting bogged down.

That way, UML *does* work. Particularly when you have to use a cruddy language for whatever reason. (Not everyone has the time to port a language implementation to a new platform *and* get their application running.)

Trying to make UML into a multi-language graphical programming language crashed and burned just like every previous attempt and for exactly the same reasons. Each project thought that a different way to draw the boxes and arrows would magically make it work.

The domain-specific folks are going in a different direction that has worked in the past: Be just general enough, and don’t try to cover every level of implementation. Graphical programming has worked in various pipeline processing environments (e.g. Khoros) for just that reason.

> (Not everyone has the time to port a language implementation to a new platform *and* get their application running.)
Kelly’s remark applies here, the *tooling* is necessary. And, yes, a *multitude* of domain-specific languages can be developed, rapidly, with zero-to-near zero learning curve? Why such a low learning curve? B/c the grammar/nomenclature is the SMEs/stakeholders terminology, i.e. their domain. RAD DSLs are indeed possible, e.g. http://bengillis.wordpress.com/2009/04/18/a-variety-of-dsls-in-real-world-examples/

it certainly is true, have you tried the same projects via domain-specific modeling?
keep in mind, en mass publication is not the leading edge of competitive methodology.
the best practices are competitive advantages, and while slowly coming out to the general audience, the practice of DSM has indeed kicked the alternatives a$$ when it comes to productivity.

That was a very interesting article, however, I feel you are blurring the lines between UML and Rappid Application Development (RAD) Tools. UML was never meant to be a RAD tool, and it’s usefullness is in the fact that it is sufficiently removed from development to allow for moddeling in a range not limited to the SDLC, or even IT for that matter. For example, Activity diagrams can be extremely useful for documenting manual systems. I personally find that Entity Relationship Diagrams (ERD) are particularly useful for getting a quick overview and understanding of how database elements function together, and how the underlying business rules govern the behaviour of objects or collections of data.

What you are suggesting as the ideal modeling language would more accurately be refered to as a RAD tool. UML definately has its place, but I would definately like to see some of your ideas being put into action in terms of Rappid Development.

1) I want to eliminate an entire chunk of code maintenance altogether.

2) I want the elite developers to not have to spend so much energy communicating with mediocre developers and domain experts– I want to leverage their “mad skills” to create frameworks so that other members of the team do not have to think on their lower level of abstraction.

3) I want the models to be first class citizens of the development process and (by association) I want the domain experts to become first class participants in the development process.

I think a formalized subset of UML can be key to making this happen.

Is this RAD? Perhaps. I think there’s more to it than that, though.

VB, for instance, did abstract away the WIN32 API so that non-IT people could program… but it was still a general purpose language. I think more could be gained by going “domain specific” at both ends of the problem… making it (gasp!) RAD 2.0!

I’m reading Craig Larman’s book on UML and love it. I hope one day I will find a shop that will actually do it. Imagine, people talking to one another, dialogue, discussions, brainstorming !!! Software engineers actually co-operating.

So far, every shop I have been is full of cowboy coders. Introverted and anti-social coders that act like it’s a burden to have to share their brain cells with an inferior coder. I think I may have just described the “mad skill” people Lispy mentioned in the previous post. Ooops, sorry.

I don’t understand the inability to talk about coding, either. It’s not just from the arrogant smarty-pants types like myself. The uncommunicative crowd that I’ve seen would not respond to a “nerd” with a few UML diagrams, either.

Even the “day coder” class has the asperger’s-like quality of wanting to just get it done and be left alone. “Tell me what to do, but don’t tell me how to do it.” They have no pretensions about being “geniuses” or anything, yet the idea of discussion or brainstorming is anathema to them.

Oh… and I think I’m trying to help by proprosing a scheme through which the domain experts could become first class citizens of the development process. I want more and better discussion unimpeded by accidental complexity! (Aren’t we on the same side here?)

UML is most useful in sketching the business work flow, requirements, what-to-do diagrams, etc. Implementation is a different story, which is dependant mainly on the capability of the developer.

UML is useful for software design only on the second order, that is I agree on your doubts about the value UML adds to the desing process but… it doesn’t have to fail all the time, provided that it’s used wisely.

And again we come to the point where the capability of the developer matters 🙂

Do you really think OOP languages haven’t increased productivity at lenght?
I agree with you about your assumptions about the target environment, which it’s composed by frameworks that take care of generated code or ‘code bullets’ and run the model along the business logic it describes.
Moreover, the UML merely used outside an MDA is merely documentation, then no so much useful.

However, I’d argue about some points you lie down:
– UML is a MOF specialization. It’s so generic that doesn’t exist a correlation between UML and coding architectures like C, the UML compiler depends on you business domain, remember that (IMHO) models are not code.
– Test issues hardly could be define in high level UML models, but you may extrapolated that during the generation code and it doesn’t represent the key value of an MDA. As you said, the target environment is the counter party of models, focus the tests there.

I believe the current dogma of “always apply OOP” is counter productive. There are some cases where it is not the right tool for the right job. There are some significant voices in the development community voicing this concern possibly for different reasons, but they are definitely the minority even now. Of course, OOP itself is a slippery concept and could mean a combination of any number of things.

If I could rephrase my point, I would clarify that OOP, IDE’s, UML, and other major components of modern development have not been the silver bullets that that we expected. We wanted something more like the productivity jump we got when we moved from assembler to C, but we just haven’t gotten it, yet.

So yeah, there is no silver bullet…. But if you take a synthesis of several not-so-mainstream ideas, you can get the leap in productivity that we should have been enjoying years ago. In your view, models are not code. I believe that by making models executable (or by making usuable code be generated from models), we can get a clue as to what direction to go in the new architectural approach. Also, we can add rules to the models and also exclude bad design choices from the model… thereby eliminating the need to test for such thing down stream. Also, the automated code generation (once it is robust enough) will allow for major changes to be made at a high level without having to test for stupid bugs that are too often inadvertently added when implementing such changes by hand.

@As Steven Kelly said in a 2006 article, “To make model-driven development work this way, you cannot use a general-purpose design language like UML and a modeling tool’s built-in code generator. The people that created UML did not design it for describing applications in your domain, or for generating code other than skeletons.[…]”

This is the same thesis presented OVER 20 YEARS AGO by the ROOM folks. The problem was that ROOM was “ahead of its time”: it was a domain-specific pictorial modeling language for distributed, real-time systems. It also basically failed in the marketplace, in part because it was proprietary and in part because it served such a narrow niche that it didn’t attract the attention of mainstream journalists who could write silly but useful promotional articles, with headers that say, “PROGRAMMING HAS NEVER BEEN EASIER.”

UML is a very general notation for Object oriented design. It’s a swiss cutlery for a very general software design. It’s not always the best fit, but it works if we don’t overuse it.

But in domain specific cases, UML can be not enought. System conception is not only software design, and, if we add business rules and domain constraints, the best notation won’t be UML.

But UML introduced the notion of profile, which is way to extend UML, adding new concepts or refining existing concept. Profiles can be used to add lower concepts (Platform specific extension, ie “this class is a C++ class or a C structure”), but also high level concepts (This is the concept of requirement, which will be declared as implemented in this use case, and its technical realization will be this software component).

With this extensions, we can adapts UML to domain specific needs. The most advanced is sysML, which is an OMG profile for system modeling, but the user can create its own profile to its domain. I’m currently working on a profile for system modeling using a enterprise-specific method.

With such a tool, UML can be adapted to the user domain, and tooling can be created among this model to help user manipulating it.

But why use a profile instead of creating a specific metamodel and its manipulation from scratch ? Many UML tools supports profil, and, if the user profile reuse some UML diagrams (sequence diagram are horrible to rewrite and are very common in many methods), thoses diagrams come freely with the tool.

Note that if your business specific modeling is very far of UML modelling, the complexity of profil and UML mapping can be a very bad idea. You have to be very pragmatic, as usual.

I would like to emphasize the domain-specific parts of a language. This is essential here as it is needed to raise the level of abstraction as well as to make the code generation possible. UML simply can’t do that since it does not “know” about any particular domain, such as automotive, telecom, bank, insurance etc. For those who want to see a comparison via an example, please take a look of the Chapter 1, Section 1.3. at Wiley site. (http://media.wiley.com/product_data/excerpt/64/04700366/0470036664.pdf)

In the example the DSM solution is created for a narrow area of interest (Symbian applications), raise the level of abstraction and provide full code generation from the models. I would be interested to see a similar kind of working example made with a general purpose modeling language, like UML, SySML, SSADM, EXPRESS-G, MERISE or IDEF. I would be even more interested to see the profile definition for this domain with UML. Implementing the profile would be enormous tasks since most domains are really different to that UML provides.

In my opinion, SysML is not a domain-specific modeling language. I share the view of OMG (http://www.omgsysml.org/#What-Is_SysML) as I can’t see from SysML any specific kind of systems it addresses. A more domain-specific language addressing system modeling would be for instance AUTOSAR, EAST-ADL or AADL – all targeting automotive domain.

It is true that with executable UML we can also generate code but the models are at low level of abstraction. And it is the raise in the level of abstraction that improved productivity in the past and will do so in future too. Moreover, (executable)UML does not guide developers making correct designs or prevent creating models that don’t execute or execute with a poor performance. This simply because a general purpose language don’t know about the domain we are working in. In my opinion the whole term executable UML is a bit misleading since most of the executable work (by Kennedy Carter, Olivanova/Oasis, Schaler&Mellor) existed already before UML and they already know then the “right” parts of the UML specification 😉

Philippe Desfray who developed Objecteering (and UML CASE) had a theory behind it to transform models automatically. See “Object Engineering The Fourth Dimension” http://www.softeam.com/references_publications_livre.php
Objecteering includes a programming language (“J” in older versions, Java in the latest IIANW), that allows to implement model transformations. With this language you can theorically write kind of macros to transform or decorate an analysis model into a design model, or a design model into an application model and then generate code.

Unfortunately in practice that doesn’t work, and the reason is that it is not Lisp! It doesn’t work because it is much more harder to implement any software transformation in a system that is not homoiconic, where you need special (commercial) tools to have access to all the features, and where you need a full feature programming language to develop sophisticated algorithms and heuristics to transform your systems and designs, or just to generate code. The way it is implemented in Objecteering with J is just too hard and idiosyncratic to be worth in practice to do something that lisp programmers do everyday: writting macros transforming high level expressions into lowlevel code.

And there’s no need for a graphical representation such as UML to do that, lisp symbol expressions are all you need to climb the abstraction ladder.

To Pascal: The model transformation approach you described looks for me as OMG’s MDA initiative. I can’t either see how it could work. For example, one obvious and still unresolved challenge in MDA is how to correctly make changes to the models that were created partly earlier by transformation.

I also share you view on using the capabilities of a host language to create abstractions that map closer to the actual problem domain. Lisp seems a good choice for you. In teams and bigger organizations the usual challenge with embedded/internal DSLs is how to make sure that other developers also use the higher level expressions and do not “drop” to the host language. External DSLs solve this issue. See examples of various domain-specific graphical languages at http://www.dsmforum.org/cases.html

UML, seems to be the best way modeling a system. It scores upper hand in giving the insight of how system is supposed to behave under ideal and non-ideal cases. Following the sequential steps of Use Case, it becomes very easy to think of what codes needs to be written for building a system

I am quoting Ralfe Poisson and Arora to say I thought so and we can “Make Most of UML and Go Beyond”

“UML ….and it’s usefullness is in the fact that it is sufficiently removed from development to allow for moddeling …..For example, Activity diagrams can be extremely useful for documenting manual systems.”

Very True. I have worked with Process Maps automation exploration. Activity Diagrams, if corrected and enhanced, are very useful to model IS and TO BE Processes. They should be created before Use Case Diagrams / Use Case Descriptions. I wish to interact with some of you separately. Let me know your email IDs.

aurora72 Says: “UML is most useful in sketching the business work flow, requirements, what-to-do diagrams, etc.”

Very True but UML is not used for these purposes by software developers. May be Business Analysts would make good use of UML. This may meet Lispy’s THREE Things.

Yes implementation is a different phase but there must be a path to it and all participants should be able to know how the requirements would be met, even if they cannot understand design and code.

[…] immediately known the guy didn’t know what he was talking about when he started espousing Universal Modeling Language (UML) design and its methodologies as the correct way to design software. For those not familier […]

Good read. I always knew there was a reason I hated UML, now I know. It’s because it sucks. 😉

I do love the guys talking about how great UML diagrams are when in fact the diagrams are more confusing than a road map written in Mayan hieroglyphics. I tried to show one to a technically savvy client and he physically pushed it away and said, “Just tell me what it does son.”

Four years later, last week in fact, I showed that same client some Cucumber feature descriptions and he not only pulled them towards himself he started writing his own! Talk about a win! Not only did I get the client to actually write useful specs he LIKED DOING IT! He actually said it was “fun!”