13 reasons for UML’s descent into darkness

UML lost the programmers. There is no doubt about it… in my mind. And when a software design technology loses the programmers it fades away no matter what the academia thinks. This happened because UML was pushed in a direction that most code writers don’t like: it started to look a lot like bureaucratic paper work. If we list what went wrong it starts to look a lot like the mishaps of other committee driven technologies like CORBA for example. In random order I can list:

1. Design by committee

This one is very big and usually a recipe for failure in the long term. Just look at CORBA and for a new case at the never ending list of web service standards.

2. The obsessive focus on monetizing UML

Trying to sell expensive tools for a technology that is not mature enough and only makes promises to the management (just express your ideas in pictures and the code will be generated by our magic wand) can only work in short term. At some moment somebody realizes the costs are too big for the benefits. Lots of programmers instinctively hated the whole thing. Others were persuaded by management or by curiosity to try it. Most of them never used UML tools for more than a project.

3. Tries to unify everything even the kitchen sink (UML specs > 800 pages)

When you try to offer a solution for every problem in a domain, in the end you are not offering anything useful for any problem in that domain. UML tried to solve all the issues with software development. My feeling is it just forgot about the “software development” part. Software is used or it can be used in almost every human activity. Trying to capture everything is an impossible task – even at 800 pages, UML covers only a small part of the complexity of software engineering needs. It is too big but still too generic and abstract.

4. Departure from what programmers perceived as the initial goal

As a programmer I liked the standardization UML provided for design related communication. It was great to be able to use a common set of symbols to communicate my ideas to another programmer or designer. I think most programmers still use only the class diagram and maybe occasionally when they write a document the sequence diagram. UML started to go up into the stratosphere with all those business oriented diagrams that even the business people didn’t understand or use.

5. Concept bloat

Trying to bridge UML to reality made it incorporate concepts from all the languages in fashion during the last 10-15 years. Anybody knows how to represent a Java anonymous inner class?

6. Always catch-up with new languages and concepts

In continuation of the above… and because the promised prize was full code generation you have to be able to represent specific language constructs. Closures in UML anybody?

7. UML attempts to become a programming language

By aiming to be able to generate full code actually UML tries to be a programming language. In my mind there is a big problem with a general purpose graphical programming language. In human history the written form of all languages evolved from graphical to textual. Alphabets proved to be more versatile and more expressive than pictures in capturing ideas. Try to describe any simple process in images. The funny thing is you still have to annotate the images with words. And the full text version with no pictures still gives you more details. Pictures prove to be good at sharing ideas and allowing people to visualize concepts. But in the end words are better at describing the fine details.

8. The need for expensive tools vs. just a text editor

The entry level for using UML for more than just informally sharing ideas on a white-board is very high. Tools that are any good are insanely expensive. On top of that they need training as they are not all the time the most intuitive tools. They start to look like a solution screaming for a problem to solve. Consulting companies seem to love these tools since they open opportunities for expensive training courses.

9. Lack of model clarity

Pictures are interpretable. I heard this kind of complaints from programmers trying to understand the design of a system from UML diagrams: you need to read the code to understand what the diagrams mean.

10. Lack of solutions for real software design issues

While the specifications are huge there are no good solutions for problems common in software systems. Quick examples are:

  • No solution for multi-tasking and communication between tasks
  • No dependency between use cases

11. Assumes you can know everything before writing the first line of code

The concept of writing first the user manual and then the generate the code based on it is a noble goal but… probably impossible to achieve. In practice everything is so dynamic, that the maintenance of the UML diagrams so they conform with the reality of the code becomes very fast a chore nobody wants to do.

12. Treat software development like manufacturing

Software design is not manufacturing no matter how much management likes to think about it this way. Software creation is a creative activity so a more accurate description would be craft, art or something along this line. UML tries to standardize and formalize the unknown, the imagination and the talent.

13. UML tools focus on the wrong goal

Most of the UML tools out there promise code generation. This is most of the time useless since they generate just empty class bodies with no logic. It is also cumbersome and annoying because one has to keep the code and the diagrams in sync. Some even use ugly formatted comments as markers.
Another problem with these tools is the amount of real estate diagram elements take on the screen. I tried many times to look at UML diagrams of complicated systems but looking at only the lower left corner of a class square along with two crossed segments doesn’t help much with understanding.
I think the tools should have focused on reverse engineering for documentation purposes. In my opinion no decent reasonable priced tool exists in this area. Even tools that manage to decently reverse engineer the code do a poor job for documentation purposes since they cannot differentiate between what is essential and what is just noise/boilerplate in the code.
As a result most finished projects that use UML have code that doesn’t resemble at all the nice UML diagrams drawn at the beginning of the project.
In general I don’t think code generation is a good idea. Usually what can be generated is repetitive code and most projects would be better off with that common code implemented in a library and called from there.

In the end as a conclusion I think UML had a generous idea to bring software designers speak a common language. But this idea got lost on the way for economical reasons. And when the value is lost the customers leave.

This article is part of a series of opinions and rants:

97 thoughts on “13 reasons for UML’s descent into darkness”

  1. As mentioned by a few people I think using UML to convey a high-level view of a software design and/or low-level views of complex/crucial part of a software or design patterns is valuable as compared to just showing code.
    I agree that trying to generate code from UML is overkill and would be equivalent to try to implement a software using diagrams instead of code which is not realistic in terms of expressive power / implementation details.
    Also I think people who “think in words” i.e. people who are the “auditory” type cannot be in their element when faced with UML diagrams. At the opposite people who “think in pictures” i.e. people who are the “visual” type will find UML valuable to help them understand a software design.
    I think UML, used with reason, can be a good communication tool but using it as a graphical object oriented programming language is not appropriate.

  2. The article mentions CORBA as another example of something that got too complicated for its own good. Hardly surprising that UML got to the same point, since they were both developped by the Object Management Group.

    In any case, I work for a large software company, very much into doing proper analysis and design, implementing development process, CMMI certification and what not.

    We looked into MDA, generating code from UML. I piloted the first project (large J2EE app) and assisted on the second (.Net/C#). We did the whole full-scale UML modeling, PIM/PSM, tagging model elements with meta-data, code generation templates, etc.

    We dropped it afterwards. Too much time spent customizing, then maintaining the templates. Too much time spent modeling and tagging very detailed elements in UML. The round-trip from UML to code to implementation back to UML was just too great on a large project. We got to a point where it would take hours to regenerate the code base.

    Never mind that the generation templates’ development cost was supposed to be amortized over several projects, but it turned out that each project, due to specific architecture requirements, would require adding or changing the template set, nullifying the cost-saving.

    In the end, it wasn’t worth it. MDA tries to turn the architects and designers into developers. There’s a reason you have human beings writing the code. They’re a lot more versatile than hard-coded templates.

    Now we still use UML, but only high-level class diagrams, to show the system’s entity, and high level sequence diagrams to show the program flow. State diagram if there’s a state machine in there, but it’s not that common. And that’s it.

    If you have a problem with boilerplate code, it’s not a code generating problem, it’s a framework problem. Get a better framework that takes away the need to write boilerplate and you take away the need to generate it. You also simplify your entire application.

  3. One problem is when UML is looked at as an end, not a means to an end. The point is to use UML as a tool to help with project design, not to generate diagrams for stakeholders that they won’t understand anyway. The developer should be free to use UML *as he sees fit*, but he shouldn’t be required to use it.

    Like a lot of people I think it’s useful for general ideas, like when you’re brainstorming a project’s overall design. More often than not, I think UML’s proper place is on a whiteboard.

  4. I’ve used UML off and on for years… the thing is, many parts can be useful but only when used in moderation.

    Personally, I think the push for model driven design is actually the heart of the problem. It simply cannot cope with changes always required underneath, or as touched on in your article allow for ways to express specifically how to take advantage of language/platform specific features. If you’re simply coding for some generic language from above, you are always going to be out of touch with tweaks that have gone on underneath in the real code and thus end up with many surprises, or poor code. It simply is never practical to always work straight from the model, nor can it be unless you tie a model too close to your platform to really be understandable to the people who need to look at models instead of code.

    In fact I think the key to making UML truly useful to software development is something mentioned near the end – good reverse engineering tools that give you reasonable UML diagrams from code. That way a proper understanding can be had at a higher level for architects all during the development phase of what the code is really doing, and the architects in turn can guide the business side to understand what is happening, what will happen, and collect suggested changes.

    I have had some inkling of this in the past, when taking over code that was not my own – UML was never so helpful as when gathering class and sequence diagrams from strange code. It provided a much faster way to understand the structure, and flow of an application and let me make intelligent changes much sooner than I would otherwise. If everyone had good reverse engineering tools, then new developers could come up to speed more quickly and even the lowest level developers could get a good high level view at any time. As it is, tools like Together are just too expensive to make it practical for everyone on a team (or in many cases, anyone on a team) to make use of them.

    Part of the key to making a good reverse engineering tool is, I feel, to allow easy hand annotation of generated diagrams to say things like “really there is a relationship here the diagram generator cannot understand” or “the sequence continues through here even though the code generator could not follow”. Such annotations could be stored to work through multiple revisions of the code, and would make diagrams truly present the overview that everyone craves. But again, the fact that most tools are built around a model-driven mindset makes it heresy to claim the models are wrong and add connections that were not defined in the model or in ways the model could be parsed from.

    Like all other techniques and technologies, I have no doubt that parts of UML will carry forward and eventually morph into something else, so we’ll see UML back in another form. I just hope someday that someone can come up with tools that are truly oriented to understanding code you have rather than trying to make code from a rough understanding of a problem.

  5. #11 is about the best and most obvious reason. Frankly, I use code to DISCOVER entities – if an entity pops up, it gets refactored into a class or interface or something. With UML, it’s like you have to know all these entities before you even start, and if you did, you wouldn’t need UML! Bottom up works better with OO languages because you can just refactor something off into its.own.component someplace when it looks like it’s an entity. UML looks like it was written by a COBOL designer. (UML also doesn’t map well to relational database design, either – if I have to build an OO interface around an existing relational design, which often happens, UML is UsLess.)

  6. I’m with Ishaq

    The concept of building a set of use cases and flow diagrams before starting your requirements is spot on. This is probably the most useful thing I’ve gotten out of UML.

    Business people understand use cases and love to talk about them. Getting them to talk is the toughest part of any programmer’s job.

    Any programmer knows that 95% of the work takes 10% of the time. The last 5% (details and the stuff the business people forgot to mention) eats up the rest of the time.

    Getting these use cases right and focusing on them one at a time, helps you get most of these details known up front and can save a lot of refactoring. To me this is infinitely more useful than any spec I’ve ever seen or written.

    The class diagram stuff is a really useful tool as well but that’s where I left it. I stopped short of letting it generate code…

    The structured use case has, by enabling me to connect with my customer more effectively, done more for my life than just about any other tool.

    UML simply got bloated and out of control… I’ll probably use it til I die to generate pretty pictures and diagrams to work from, but that’s where it stops.

    -Viz

  7. “Software design is not manufacturing no matter how much management likes to think about it this way.”

    In all forms of engineering there is one document which defines the product; it is the first unambiguous statement of the product. In architecture and civil engineering, it is the blueprint. In electrical engineering, it is the circuit diagram. Not that all engineering is done at this point, but it is the first time someone else can look at the product and say, “Yes, it will work,” or “No, it will not.” There is no more maybe, no more fuzzy thinking.

    A blueprint tells you two things: 1. How the product works; 2. How the product is made.

    In all forms of engineering except one: software engineering. If you create a “blueprint” for a program, you are creating an unambiguous statement. Because it is unambiguous, it can be compiled. (If you foolish to create your blueprint in a language you don’t have a compiler for, that’s your hard case.) In software, the blueprint tells you only one thing: how the product works.

    In software, the blueprint IS the product.

  8. As the saying goes, let’s not through the baby out with the bathwater. I think the concept of UML is good – the execution has been sub par. We need a way to think and communicate in abstraction. All other engineering disciplines have such mechanisms. Until Software Engineering has such a common tool, it will remain an art. My take is large scale enterprise software should be an engineering effort, not an art effort. Others may disagree.

    The tool ERWin has been vastly successful with respect to RDBMS database design. It has also been successful with SQL code generation and maintenance. Is this domain different? Was the correct solution easier to find? Did the developers of ERWin happen upon it?

    I have used the tool Enterprise Architect in training. It is a great tool for the price. If IBM WebSphere Software Architect is too expensive, you may want to try Enterprise Architect. I have no relationship to them. (http://www.sparxsystems.com.au/)

    One thing that has always bugged me about UML is the obvious concepts that are missing. That is, it has not native support for Data Flow, Databases, and User Interfaces. Without these, a large percentage of the communication does not go on. For example, I have tried until I am blue in the face to say that dependencies show data flow in a more general and useful way. However, users always want to see how the data will flow.

    Good topic.

  9. I doubt the author (or many people commenting here) have any idea how difficult and tedious it was to get a consensus and get the spec for UML 2 approved. UML 2 was influenced heavily by European Telecoms who wanted to abandon SDL, a standard of ISO that was competing with OMG’s UML. I see the decline of SDL in favor of UML the last step in unifying the modeling langauges. The investment from companies and elsewhere to bring UML and its precise semantics into being is simply too high for it to be perceived as “dead” anytime in the next seven years.

  10. UML is not only for software development;
    I wrote a UML profile for Modelica (Bond Graphs), to build models specific to this platform, this models are generated to Modelica code that is simulated on the Modelica platform, this way the mechanical (or elctronics, or others) engineer can modify his model easily, re-generate and re-simulate, those engineers (who are not always good on software development) simulate a lot before start building their systems, UML is very usefull in this kind of applications. So like any other tool (genrerally) you have to understand where that tool could help you most and find the good practices that will boost your process.
    What i described there is an application of the MDE (mode driven engineering).

    hope this helps

  11. I regard UML as an important part of the whole software/system development process. It was not (initially) created to replace or to generate code, but rather to work at a higher abstraction level. When you are part of the programming team at work, seeing the benefits of UML is hard. Capturing and analyzing requirements, building the architecture of the system, showing how components/objects interact, executing the model to verify its correctness (see Executable UML), these are some of the utilities of UML. It improves the software/system development process. And for projects that contain more than just software components, like hardware, electrical, mechanical elements, you have SysML.

  12. Maybe we could render it down to what’s actually of pragmatic value by keeping only the core concepts that relate directly to generating code and supporting only class diagrams for that core. We could even define a textual notation for it as well as a graphical one. And we could design a generator to support iterative development that allows real programmers to switch between coding and modeling to best suit the task at hand.

    Hey, that sounds a lot like Ecore and the Eclipse Modeling Framework. Didn’t someone use EMF to build all this UML stuff?

  13. I write model compilers for a living and I would agree with the writer that UML has gone off of the deep end in that the scope of the meta-model has become very large and complex.

    But on the other hand, software engineering is a big subject.

    Note that hardware engineering is also a big subject and they make extensive use of modeling tools to the point that very few EEs now work at the logic level. Instead, they work at a high level of abstraction – the functional level.

    Given that state of our business, we are going to have to go to that direction. How will we get there? Well the solution will involve working at a very high level of abstraction compared to what we do right now.

    UML as it is now, was driven by vendors that have an existing tool set and the standard reflects that tool set. Probably what will happen is that someone comes out of left field with a new way of doing things that solves a certain set of problems but then another set of problems will pop up.

  14. Partialy I agree with the author’s points, UML is too complex, and there are something is still stay at acadmic level. Some guys really like to keep adding complexity to UML, and it looks like they don’t care how many guys can really understand them, the complex makes they feel happy, and some guys can sell trainings or tools to you.

    But on the other hand, we should say many designers do find part of diagrams are usefull, the class diagram, sequence diagram and even state diagram do looks suit for describing program framework, but most designers only use these stuffs. The issue comes out when you want to hand over your diagrams to coders, without many further explainations, in fact you can’t guarentee any implementation exactly. This is really an issue still doesn’t have solution.

  15. most people who are not up-to-date with the education and dynamics of UML would think its useless. Believe me you, you will witness an era in the coming ages when UML shall itself be a programming language. after all the goal of technology is to ease life, we all would agree. othrewise who would want to go back to those early days of fortran and cobol, NONE!

  16. I agree with Knocturnal. The latest development trends aims to raise the level of abstraction. There was a time when people familier with assembly language hate upcomming 3GL languages due to the fear that they have to learn new things. Does not means

    One more thing problem is not in the UML, problem is in the way you carry out your development. In the start if you keep things simple UML facilitates you, and increment in your models as your understanding of the project grows (iterative and evolutionary…thanks to RUP). The concept of model driven architecture is also a worhty one but still in its infancy. Time will come when you will feel how easy it is to just draw and get what u want..

    i think the author has a bit exaggerated. Some points are still valid but these things can be cured by further research in this area and by bringing more sophisticated tools

  17. I have read all the comments on this UML thread with interest. Most of my experience is in embedded systems and I have been trying to learn all I can about the various high level software modeling environments, both model driven (MDD) ones, such as UML and model based (MBD) ones such as Mathwork’s Matlab/Simulink combo and National Instrument’s Labview.

    Why? For a number of reasons: (1) the day of the individual
    code developer is coming to an end with more and more development done by large teams often separated geographically around the world (2) systems, especially in the embedded world, are becoming more complex and require millions of lines of code running on multicore CPUs (3) even if you get the code right, entire projects could come to a halt if the system design and the relationships between entities are flawed. And then there is the problem of documentation.

    I find myself in the position well described in a column by Jack Ganssle on Embedded.com (“Can we design embedded systems faster, cheaper, better” at http://www.embedded.com/columns/breakpoint/208400913

    “With project complexities exploding, it’s clear that unless we dedicate ourselves to a new paradigm of development, using so much that has been learned about software engineering in the last half-century, we’ll stagnate, wither, and fail. Those companies that accept new modes – and old proven modes–of thinking will prosper.”
    Another article on the site ronline at Embedded.com (“MDD and IDEs: making the twain meet in embedded systems design” at “http://www.embedded.com/design/208400915) describes a
    bidirectional framework that allows developers to move back and forth between two environments, an embedded IDE for code development and an MDD such as UML at the system definition level. It seems that for me such an enviroment offers a way to work in both the code level and the system level environments. I was particularly struck by the following statement in the conclusion of the article:

    “The MDD tools within this bidirectional environment can then
    generate production quality C, C++, Java, and Ada source code
    automatically from the UML models, which can be fed into the IDE’s
    C/C++, Java, and Ada compilers, and object code then transferred to the target. The developer can then take programs running on the target, set breakpoints on the graphics in the modeling environment, and have the program stop at the same point in the IDE’s source-level debugger.

    “Working from the other direction, a developer can load and debug the code in the IDE environment and set break points as well.”

    Maybe the author is overstating the case but the move toward such
    merged IDE/MDD environments seem to be gaining ground: the one
    described in this article was developed for use with the open source
    Eclipse IDE.

    But I have heard that Wind River is moving in the same
    direction with the the Tornado IDE it has for both its Linux OSes as
    well as its Vxworks RTOSes. And Green Hills Software at one point was working with one of the UML providers to create a bidirectional
    framework between the UML system level environment and its proprietary MULTI IDE for developers using its Integrity, Velocity and
    micro-Velocity RTOSes.

  18. I have found UML very good at helping me structure my thinking about a project. On the other hand I rarely find anyone who understands the graphics. Few programmers are trained in the methodology, and fewer end users, the people you most need to communicate with when building a system.

    Many academics have been rather late getting on the band wagon for this approach, particularly in the smaller universities, as they themselves don’t understand it. This results in many people graduating with Computer related degrees who’ve not had the necessary exposure to the concepts. I know because I’ve just recently helped a professor friend get the course going at this school.

    There is a great reverse engineering tool for Microsoft based projects called Project Analyzer by Aivosto, which I’ve used for a number of years.

  19. I had an entire university module on UML and it was probably the most boring course of the year (the fact the lecturer teaching it spoke with a dry hard to listen to russian accent didn’t help). I tried to pay attention but just couldn’t work out what the difference between half the diagrams were, this wasn’t helped by the poor examples. Luckily it was let slip that UML didn’t actually feature in the final exams it was just included as part of a group project, hence only one person from the group needed to learn it!

  20. I think that as an UML software vendors we did many mistakes in the past fews years. The current problem is that Jee architects and developers were previously disappointed and don’t see any good reason to try it again.

    I have written an article on Agile Jee/Java project and UML metamodel modeling. It is available at: http://www.uml2.org/feature_charts/Model_Java_Project_with_no_Java_code.html

    I know that live code and model synchronization failed because of matureness. Now we should not stop using UML because I believe there should be a solution to use UML and improve productivity.
    I don’t say that Omondo have found the silver bullet but we trying to change.
    New EclipseUML Architecture in 2008 in order to adapt our core to the latest technologies and agile methodology.

    I think this is still not perfect and we need to work more on these issues. We should not stop NOW, it would be a terrible waste. Don’t forget that UML is coming from mature methodologies used in the last 30 years and that software development changed but a man is still a man and this would never change.

    I can testify inside Omondo core developed in 2004. We have created all core classes which have been merged and changed in the last 4 years. Having an EMF core generated was the only possible solution in order to allow very complex java project evolution and maintenance. Without a model this EclipseUML complex project would never have been able to migrate and evolve. Is-it really possible to create complex software composed by over 100 000 classes if you have no UML model. Hard codding is a good methodology but only if all your team is working together and if they are mature. How many team are working together and are only composed by only senior architects or developers ?
    The challenge is therefore that a manager not doing any modeling is like creating a house with no blue print.
    It could be finished quickly, but it will be impossible to maintain and evolve.
    This is my penny to this post :-)

    Vlad
    Omondo

  21. I am reading the post of NoUML, on May 31st, 2008 at 2:54 pm:

    You are complaining that entities are not reversed in an UML diagram. I fully agree with you :-) because it should be reversed !!
    If you look at our EclipseUML EJB 3 reverse then you will notice that reversing a project also shows entity displayed as a stereotype. See our example at: http://www.uml2.org/JEE_reverse_EJB3.html

    I think that the UML reverse engineering getting Class or sequence diagram was not appropriate. This is one of the changed we did in our tool.

    Vlad,
    Omondo

  22. UML should have remained nothing but a visual help to outline the
    framework of a complex program. It should have been kept much simpler
    than it is today. In that form, unfortunately it wouldn’t have
    required all that snake oil that is sold nowadays in the form of
    courses and modelling software.

    More than an Universal Modelling Language it has become an Ugly
    Meta-Language that promises to bridge the gap between the vague ideas
    of those corporate figures who are less technically inclined and the
    implementation itself. It doesn’t, but the management hasn’t figured
    out yet.

    thanks :)

  23. I think that Java is a fantastic language but it is a poor language if you try to code complex applications.
    UML is therefore needed to extend Java language and code these kind of projects.
    It is also impossible to create large and complex new software architecture without any modeling (see my previous post on EMF)
    These are two ways where Java projects absolutely needs UML !!

    I have written a small technical on the The successful development Cycle : http://www.forum-omondo.com/documentation_eclipseuml_2008/development_cycle.html

    One of the current UML modeling problem for Java project is that for corporate project development should decide which level of abstraction to use immediately at the beginning of the project and then be blocked till the end of the project (e.g. model with no code synchronization or live code and model synchronization).
    This UML limitation was to my point of view one of the major problem using UML during all the project life.
    I don’t think that UML should only deliver a blue print (e.g. be only a visual help) because of this technical project life limitations.
    Omondo have been working on live code and model synchronization and have extended it to metamodel triple live synchronization. (I think that UML is like “Gillette” the more blades you have the better the shaving is :-) )

    Another problem today is that many open source projects are created and large corporation customer believe integrators dreaming stories !!
    Many customers don’t understand what is EMF, GEF and and think they can create from scratch a customized tool for their specific need.
    The cost for just getting a basic UML class diagram would be over 2 000 days of development.
    The cost for getting an acceptable UML tool would be about 20 000 days of development.
    The cost for getting a UML tool such as Omondo’s would be at least 200 000 days of development (several million dollar research project).
    Companies invest 2 000 days and get a non DSL/UML usable tool and are disappointed at the end of the project.

    Vlad VARNICA
    Omondo
    French Java User Group Coordinator

  24. Vlad wrote on 3rd August:

    “Is-it really possible to create complex software composed by over 100 000 classes if you have no UML model.”

    This is the wrong question. Indeed you need a “model”. The question is, if UML is the best way of representing it.

    BTW: Modelling and generating the server part, like controller and business entities, may be doable, but UML lacks every support for designing the presentation part.

    “Hard codding is a good methodology but only if all your team is working together and if they are mature. How many team are working together and are only composed by only senior architects or developers ?”

    “Abstraction” can also be achieved by better textual languages. It is not as close coupled to graphics as the UML folk tries to convice us.

    Although graphical representation is good for getting an overview, it is for many aspects best used as output of a query or analysing tool, not as input interface.
    Productive working with a graphical tool is more blocking than creating a psychological “flow” (an experience you will indeed have in modern textual IDEs) when it comes to working on details.

    Textual representation does not mean “hard coding”. When trying to generate a fully functional program out of UML models it becomes clear that even UML is only one specific “language”, and creating a functional complete model is as much “hard coding” in UML like in any other language.
    Sometimes even much “harder”, as for creating the necessary input to express the software in graphical form, most UML tools are too cumbersome in its handling.

    Beside that, it is absolute nonsense -I can tell from experience- that using UML as The Language would allow for engaging less mature developers in a project.
    Inexperienced people can destroy the overall architecture, misuse frameworks, misinterpret semantics a.s.o. in a graphical UML representation as well as in textual code.

    Sometimes even with more disastrous results, as UML model refactoring in a really big MDA project is in no way easier or less riskful than in written code, I would even consider the opposite.

    And at least:
    The ever cited comparision to “blueprints” in architecture begins to be annoying. Architecture is about constructing a static structure. And that is represented in drawings.

    Software is in very much parts process/interaction/algorithmic.

    And it is no coincidence that most sciences, like chemistry, physics, astronomy do most part of their job in textual formula languages.

    Even a building needs a good bunch of calculation (statics, material calculations, thermal insulation, air condition, energy consumption) and other detail description in textual form (e.g. parts lists, material specifications) to be fully represented. Information which is not contained in drawings alone.

  25. Det,

    I think that one of the first use of UML should be to control the development job.
    This is stupid but without control there is no good software.
    If you look integrator or offshore business model then you will see the current UML dilema :-)
    No UML as much as possible is asked by integrators because they are paid by customers to create new softwares. Why will an integrator gives the opportunity to his customer to control the architecture of the software ?
    It is better for them not to have any competition and block their customers.
    This is one example where UML should always be required by companies when integrators/offshore companies are doing the job.

    Another use is for software architectures.
    How to model large software application and maintain it many years if you don’t have a very solid architecture ?
    The complex object approach is only possible with model approach. It could be UML or other, but currently UML is the most mature and widely adop language by a large community. For example would you speak English on this forum on select another language. Everybody will speak English like UML is used in many projects.
    It is easier for everybody to have a common reference and use UML.
    My other recommendation why to use UML would be “Think to object and not only to code” !!
    EMF or Model driven is the most convenient way to do it.

    I would like to say that Java JEE architect or developers should not just be recruited for codding or hard codding. They can do a lot more !!
    UML open new frontiers to Java projects and this is why we like it :-)

    Vlad VARNICA
    OMONDO

  26. What depresses me w.r.t. UML, and the reason why I don’t use it, it that UML only lets the user generate ‘skeleton’ code – class and method outlines, not actual algorithms and the like. And, unfortunately, the latest MDA trend is of no help here either.

  27. The reason that UML is a Useless Modelling Language is that it was an attempt to extend Software Engineering [which is really project management] into the area of software design and construction. UML is another attempt to have a tool make up for the lack of skill of the user. Given to people without the necessary skills, it had to fail.

    In a world where people with 3 years of experience are considered “senior” it is no wonder that most software is amateurish garbage. If it were a bridge you wold be afraid to walk on it. Once you have ten or twenty years of non-fad chasing experience, then we can have a serious competent discussion.

    Forget all the OO and Java fads. Tools will not make up for lack of skill and understanding. This have been proved numerous times since the 1950s. You can give me Michaelangelo’s hammers and chisels but it won’t make me a sculptor – only years of making chips under good guidance will do that.

    Do your homework. Go back to concrete designs [queues & procedures with scenarios] instead of your so called patterns and use cases. Real patterns are like real world processes of pipelines and workstations. If you can’t design a system which can operate concretely with NO COMPUTERS but rather people on skates with clipboards and forklifts, you can’t build it in the abstract in software. If you can’t build and understand concrete machines of nuts, bolts, power trains and electronic controls, you have no business trying to build abstract machines in software.

    Once you have achieved that skill, you are ready to start in software as a novice an your way to being a real journeyman or master in another 10 or 20+ years.

    Sorry if the truth hurts. I am tired of rescuing projects hacked together by someone’s nephew or graduate student following fads including UML, …
    etc., etc., etc., …

    Thanks for letting me rant.

  28. Dimitri,

    If you look at AndroMDA project you can just from class, usecase and state UML 2 diagrams create all you need.
    I mean business tiers, persistence and glue with presentation. I have create a model example inside EclipseUML 2008 Studio using AndroMDA core and Omondo templates for UML 2.1 and JSF 2 at: http://www.forum-omondo.com/viewtopic.php?f=29&t=1489

    UML will never replace developer integration talents but could make it easier not to spend as much time on not strategic codding.
    Why to map manually everything if you can just from UML diagrams get this job done :-)

    Vlad
    Omondo

  29. I’ve stopped using UML for things that are too close to the implementation level. At that level the code itself is the documentation and if needed: different documentation views can be generated from the code itself using tools like doxygen (and not vice versa/no sync).

    I use UML just to describe architectural decisions (packages, components, …) and requirements elicitation (goals, usecases/actors, domain entities, processes, …).

  30. Oh, and as someone said that UML lacks support for UI stuff: at least the screenflow can be modeled using state machine diagrams. Some apps even realize screen flow logic with a FSM.

  31. The reason that UML is a Useless Modelling Language is that it was an attempt to extend Software Engineering [which is really project management] into the area of software design and construction. UML is another attempt to have a tool make up for the lack of skill of the user. Given to people without the necessary skills, it had to fail.

    I don’t think so!

  32. But this post miss the most important (and annoying) feature of UML :UML is not a single modeling language but is

    OVER 7 DIFFERENT KIND OF MODELS!!!!!

    for example UML state diagram and Use Case.
    Truly, it is insane.

  33. As mentioned by a few people I think using UML to convey a high-level view of a software design and/or low-level views of complex/crucial part of a software or design patterns is valuable as compared to just showing code.
    I agree that trying to generate code from UML is overkill and would be equivalent to try to implement a software using diagrams instead of code which is not realistic in terms of expressive power / implementation details.
    Also I think people who “think in words” i.e. people who are the “auditory” type cannot be in their element when faced with UML diagrams. At the opposite people who “think in pictures” i.e. people who are the “visual” type will find UML valuable to help them understand a software design.
    I think UML, used with reason, can be a good communication tool but using it as a graphical object oriented programming language is not appropriate.

  34. I liked the reasoning, nice article.

    Agree that just a few types of diagrams make sense and i guess its mostly to help you grasp bigger picture not to spawn tons of useless graphs.

    I think its a good thing to design stuff before you code it and basic graphs may actually help, but i agree, tools are crap and UML itself is overly complicated. Keeping it simple might help but if you really want to look professional during the meetings use full featured graphs ;- )

    PS. captcha on this website sucks and fails my forms constantly!

    Art

  35. UML should have remained nothing but a visual help to outline the
    framework of a complex program. It should have been kept much simpler
    than it is today. In that form, unfortunately it wouldn’t have
    required all that snake oil that is sold nowadays in the form of
    courses and modelling software.

    More than an Universal Modelling Language it has become an Ugly
    Meta-Language that promises to bridge the gap between the vague ideas
    of those corporate figures who are less technically inclined and the
    implementation itself. It doesn’t, but the management hasn’t figured
    out yet.

  36. I completely agree with you. I had a project to the university, where everything had to model in UML, after reading 2 books of reference on UML, I found completely ridiculous the existence of a graphic language as a tool for modelling. Sometimes gave me to think it had to be so difficult modeling software. I just write all the code and at the end I make the diagrams that I was requested. UML always seemed software vendor language. Worse, with UML I felt trapped. I have to decide that in life I will never use UML but for purposes of documentation.

  37. UML is a meta-model to design models, not code.
    You could interpret the abstract model as java, .net, whatever implementation you want, but it’s not build with Java inner classes in mind…
    If you use UML as a coding developer tool you may expect no more than better objects ‘visualization’ for documentation, but the UML paradigms aim to cover more generic scopes. Components, interactions, systems, business rule for example.
    With UML models you may create PIM and PMS trasformation (platform indipendent/specific models) but not handle in a ‘one-click-and-go’ java IO handling for instance or generic paradigms to code Java closures…

  38. AH! Good article!

    I liked UML 1.0, it helped to understand, communicate and define software problems. Then came UML 2.0 and Rational Software Architect, and I gave up.

    Best UML tool out there: http://www.websequencediagrams.com/, basically lets you write sequence diagram from a simplified language and generate diagrams for you.

    Example:
    Alice->Bob: Authentication Request
    note right of Bob: Bob thinks about it.
    Bob–>Alice: Authentication Response

    Generates this:
    http://www.websequencediagrams.com/cgi-bin/cdraw?lz=QWxpY2UtPkJvYjogQXV0aGVudGljYXRpb24gUmVxdWVzdApub3RlIHJpZ2h0IG9mIAAlBUJvYiB0aGlua3MgYWJvdXQgaXQuCkJvYi0tPgBMBQA5E3Nwb25zZQ&s=default

    And now I love UML again :)

  39. Great post. Cannot agree more!
    I totally agree with point #11. Classes evolve and it’s a pain to update the UML as well. It might be good during the initial stage of a project but after that it really becomes a pain to maintain it.

  40. make UML -light like mind map. complex associations need to be express with link description.
    mindmap styled UML should bring more fun to people brainstorming.

    greate post. UML 2.0 sucks.

  41. In any case, the Three Amigos should have been done for plagiarism. The Class diagram is nothing but an ERD, Sequence diagrams have been used by electronics and signalling industries for decades, similarly Statecharts were around years ago, and the Activity diagram is just a glorified flow chart that anyone from the 1950s would recognise.

    And yet, given the lies and propaganda of the snake-oil vending toolmakers, UML was supposed to revolutionise software engineering. These people should have the hardback copy of ‘No Silver Bullet’, suitably smothered in Vaseline, inserted into their bodies.

    Lies, Damned Lies, Statistics, Rapists, Paedophiles, UML Tool Vendors…

  42. MDD (Model driven development) is dead but not UML.
    In my project I use an Eclipse tool which provide merge option. It means that I can model, then type my code manually or let the tool generate the code, and code manually my project and then reverse it again and again and again as many times as needed. My model is always updated and accurate.

    Such UML is really cool and it exist today with Eclipse. I will not give the name of the tool I use but if you google you should easily find.

Comments are closed.