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:
- 1. 13 reasons for UML’s descent into darkness
- 2. 13 reasons why Ruby, Python and the gang will push Java to die… of old age
Have you tried Mia-Generation?
It is far from perfect but it still beats the hell out of any other solution I have seen.
Most of UML is totally useless though. Only Class diagrams can be used effectively for generation.
Good point and great reasoning. The only diagrams I find most useful have been class diagrams and sequence diagrams (and some times use-cases) in early phases of a project to communicate the overall idea.
However, I am no pro on UML so I may have missed something.
btw those who don’t want to pay for expensive tools, use Netbeans 6.0 or Visual Paradigm for UML (Community Edition). both are good.
You make a lot of very good points, especially about code generation. Even IBM found that you must invest as much time in customising the code generators as you would simply writing and debugging the code from scratch. Add in the cost of the tools, the inability to do any prototyping and the result is a big fail.
I worked on a project that decided to generate all of its code from diagrams (not UML but Schlaer-Mellor) and it took two weeks to get the models processed and the code compiled. Given that the code generator was being tweaked often, this slow turn-around really impacted the project.
As for tools focussing on reverse engineering for documentation, my experience is that nothing comes close to the usefulness of Doxygen.
Noo, yaar. I need help estimating project completion time. lol
It’s time to nail the coffin shut on UML. I really really tried giving it a chance, but it just got in the way.
As far as a language to help communication between stakeholders, it has failed utterly. Pull out a UML diagram and watch peoples eyes glaze over. Nobody is going to try and read even the simplest diagram to see if it makes sense. It’s helps people look professional, and as such it’s a useful sales tool, but it has no value as a design tool.
I find UML rather handy for quick sketches in the design phase. Violet UML is a simple tool that makes drawing UML diagrams like using a pencil on paper, just even easier!
Other Tools I have tried (Together, Omondo, ArgoUML, Visio) try to lure you into that model stuff, which can be annoying, if all you want to do is a quick sketch as opposed to full code generation.
BUT: I can see where model driven architecture might really help. This could be used to overcome “flaws” in languages like Java (or it’s stack) which require a lot of boilerplate code. Using a model for entities, a lot of boring code that is needed by your framework could be generated. Make these generated classes abstract base classes and subclass them in your actual code (so you don’t have to go the ugly comment route but still benefit from round-trip engineering). This way, you can have ActiveRecord ala Ruby *and* static typing… Imagine a Java on Rails framework that generated the code at compile time from similar descriptions as the model files in Rails.
In addition to class and sequence diagrams, I would like to bring attention to state diagrams: I find them really useful! (they can also be used to generate code skeletons nicely…)
Also: Yes, you do need to write/maintain your own generators. Yes, that can be a pain. It is also very meta-meta and thus not a task for your grunt programmers. Model driven architecture has quite a bit of overhead that will only pay back with a big enough project: Your generator is an investment in an application framework. If you are going to throw it away after your hobby project, you are wasting time - use some dynamic magic instead.
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.
No need to say, its popularity was welcomed by all those IT-parasites
who can’t be brought to understand a line of code no matter what, but
they still want to interfere with the production o software. And get
paid while doing so.
I don’t believe academia think much about UML either. It has always been more of a vendor thing.
Well said. I was actually a big fan of Booch notation back since `91 although I used circles/ovals instead of clouds and reduced the double lines to single ones. It was effective for me though. I could glance at a class diagram and have a pretty good idea of the system’s architecture. I never got that out of UML (or Rumbaugh which is most closely resembles). Something to be said for aesthetics I guess. Sequence/Event diagrams were useful for select cases. Code generation - right out! Wish I had a tool that did my modified Booch easily, alas…
I agree. A real good idea (a standarised way to communicate high level ideas to other developers) has been overwhelmed by the (wrong) idea that it is possible to define every single detail of a project using it.
I strongly believe that basic UML is a required tool for every developer. But I mean just a subset of the whole specification, class and sequence diagrams, and only the basic relationships and decorations. Everything else is, for me at least, only noise that doesn’t add any useful information .
Excellent article. Agreed in most of your points. Personally I just use UML for transmiting ideas and concepts. No code generation shit. Just a small document with almost no literature and some structural+behavioral diagrams (UC,CL,some AD/SD,CD)
Just for the record, give a try to Enteprise Architect if you want a very cheap UML modeling tool. By far the best one I have used so far.
UML is meaningless and for good reasons…
A read an awesome article today called “13 reasons for UML’s descent into darkness” which outlines many of the issues I personally do also consider to be the main issues with UML.
I’ll just quote the ones I think are most important:
“The obses…
Very nice post. I find most of the UML diagrams useless except Class diagram and Activity diagram and may be a couple more.
UML’s job was to simplify things but it ended up making it complex.
Oh Maan!! ur tellin us this now!??
we’ve just been doin UML for our course… xams approaching!
no i know exactly what to write in them papers!
Thanks, you just changed a paradigm of mine:
I never understood UML –> I’m stupid
UML not seen in academia? Gadzooks! I have almost finished a course in “Software Engineering” for my undergraduate, and the subtext of the textbook was “Java, Patterns, and UML”.
So true.
There is definatly a need for laying out concepts and such, but strict UML always leads to such a headache.
Anybody thought about an ‘UML-Light’?
We have been on the UML kick for some time now. It all starts with a simple Class diagram… where to go from there. We are now using MDA, ORM, etc. and finding that it takes longer to deliver anything. This is why .Net is kicking Java’s butt because we in the Java land spend more time playing with tools and UML then coding. This is why Ruby on Rails is so great, all the constructs, none of the crap.
Couldn’t agree with you more.
Amen. I’ve been watching Booch and Yourdin et al do variations on this theme since the early 80’s and it never really made any difference.
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…
Giancarlo Frison
gfrison.com
right on spot with this article. especially no. 13 made me nod in agreement. a tool to quickly generate UML to get an overview over a certain aspect of a system is something i wish i have had a number of times.
expensive tools?!
You should try StarUML and the likes.
Brilliant man
I especially liked the part about “management seems to think about coding as ‘manufacturing’”…
I think *THE* most important thing to understand about SW development if you’re ever to come close to a R&D department than 100 miles is that CODING IS ART! PERIOD!
Great reading, 1+ from me at DZone
This should actually be called Why Programming with UML Has Decended Into Darkness. In fact, some bullets are really more process oriented as than UML oriented, e.g., “assumes you know everything before you write a line of code.” That’s a problem with or without UML.
I think an Agile Modeling approach mitigates these problems. It can enable you to get the best of both worlds by using UML as needed for 1000 ft. view stuff, like showing component architecture or very lightweight class design (focusing on class dependencies and eschewing the evil class level sequence diagrams). It’s also good for showing patterns. Beyond that level of detail, doxygen or good ol’ code is what’s needed. Add an iterative approach of design a little, code a little, test a little, and toss in some Test Driven Development, you’ve got a great toolbox–where each tool adds a unique piece of the process pie.
ill tell you why it has failed, because i am a software engineer, not a document writer. yet its always my job to do the laborious task of UML diagramming.
i dont know any programmer that likes to write documentation. as long as we force people that dont want to do this shit to write these UML diagrams, its going to continue to be half-assed.
if a company wants nice UML diagrams and great documentation, they should hire doc writers.
Blog author - please find someone to edit your article
before posting. It’s a difficult read, at best. Example:
“This is one is very big and usually a recipe . . . ”
(there are many other examples).
I see why UML is unintelligible, since you have not
mastered the English language. Sorry, if you publish
to the world, expect public feedback.
And to folks, such as “chris”, when you mature as a
developer, you will understand the importance of process
and of documentation.
I witnessed two intelligent responses - one by Ken K.
and the other by Giancarlo Frison. They “get it”; that is,
they understand the power of a meta model and what
it imparts to developers who also understand it. And
when to throttle back.
Mind you, I’m not suggesting that the whole of UML be
embraced, but if you understand it and understand the
tools that capitalize on it, you will reap its rewards.
What I have found, over the years, is that the hard core
techies are the folks who complain the most, because,
honestly, they don’t get it.
Regards, mjt - author, ad nauseam.
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.
I agree with most of your points, UML has become way too complex and although the spec is huge it isn’t even very precise..
That said, I find that for documenting sofware, class diagrams and sequence diagrams are actually quite clear in what they try to convey - if used properly.
“CASE” tools have been bloated and lacking in the usability department.
Mind you, there are “light-weight” tools that try to do a better job at improving your productivity. For example, for sequence diagrams I’ve created Trace Modeler, have a look at
http://www.tracemodeler.com/download/index.html#demo
for a quick 30 sec demo.
Best regards,
Yanic
First of all I want to thank everybody for the feedback. I didn’t expect this little rant to have such an audience.
@mjt - Thank you also for pointing out mistakes in the text. This was a kind gesture
On the other hand I don’t get why English and UML cannot be understood in separation… Isn’t UML supposed to be a graphical language?
I get very clear from your comment that you have a very different opinion regarding UML. And I respect that. But I consider intelligent all the responses given here not only 2 of them. People have the right to have an opinion and your/my preference is not a measure for their intelligence.
I sense you have an attachment to this technology. Maybe you are a participant in UML’s creation, an author, maybe a consultant or an UML evangelist. My question is: if you are so sure UML is so useful and people “get it” why do you need to defend it? People on the side of a successful and mature technology don’t bother defending it against a small rant in broken English.
Or maybe you know/feel there is something wrong with the state of UML and somehow the generous idea of offering a Unified Modeling Language for real designers, who can “get it”, got lost on the way?
It may be worth trying to imagine why the hard core techies complain the most: maybe they are too busy actually creating software and the whole UML “help” slows them down, maybe they “got it” already.
I drew a collaboration diagram just yesterday for an API I am working on. And I use class diagrams, sequence diagrams, state diagrams, and use cases too, from time to time. Even occasionally a deployment diagram. But I only use them when it makes sense. I don’t have my projects plastered with diagrams.
I use UML from time to time, but I don’t believe in the full roundtrip engineering promised by tools like Rational, Together either. I tried it many years ago, and didn’t like it.
I’m an infrastructure architect, and while this article very nicely addresses the concerns from the operational side of the house, I also want to make a plug for the fuctional side of the house. We really need to have a good, mature modeling “language” for infrastructure. While a UML deployment diagram can be “made” to work, it doesn’t represent a robust method for representing how hardware and software combine to meet a customers requirements. Just my two cents…
Daniel you should learn more about meta-modelling and modelling in other sciences.
Most programmers do not grasp these concepts and only think in terms of real ‘code’.
But by the use of models code because clearer to others.
UML gives a common understanding separate from the programming language. Software Systems without UML models are often badly designed, or not designed at all.
“Think before you program” is supported by UML.
To go one step furhter like Giancarlo Frison pointed out:
Model Driven Engineering (MDE, or MDA) is the next step in programming. We went from assemly languages to higher languages like Java and C# today. But ultimately we will use domain models to describe our software system. In that way a lot of code can be generated.
For example:
For a simple web applicaiton with some data-model:
we have to create the database (SQL)
we have to create the objects in memmory (POJO’s)
we have to create web forms
we have to create validation code
we have to handle CRUD requests (create retrieve update delete)
Using only a datamodel we can generate all this code.
So stop thinking in terms of code only, start thinking in models. And UML is a good start (altough my teacher disagrees, because there are more meta-modelling languages out there)
I am only now learning UML in a university course, and my experience is mixed.
The problems you mentioned, do exists, UML is too complex and is hard to understand, but I do not think, it cannot be used as a programmers tool.
The roundtrip engineering do not work now, only at a very basic level - for platform specific modeling. UML is not the best tool for platform specific modeling: those models are much too complex, and in a visual diagram all we want to look on the diagram for a moment, and understand the main message of it. And it is quite impossible to get platform-independent models from the code (in these models a lot of details can be omitted).
But if somebody manages a complete model transformation/code generation system from platform independent models, it might help a lot. At that time it might make sense to use UML diagrams for the full project instead of coding, but not before.
I’m seeing a lot of responses from students here. The more experienced commentators are defending UML, even if gently.
The point about visual programming is not well made, as it is supported only by hand-waving. It is true though that UML tries to be a visual programming tool based on some essentially made-up notations. Languages handed down from on high are the problem here.
The notation does have some value - mostly that we aren’t all learning a bunch of different notations, and that we can use the one we have to communicate ideas in their current state. It’s not great, but it suffices for the tasks for which it suffices. People may be telling you to use it for inappropriate applications, but that is not a problem with UML as such.
So true. The more time you invest into UML and start to see why co-workers dread the mention of UML where a simple code change become bureaucratic nightmare.
I hate UML since my first contact 8 years ago.
It mislead us sometimes.
I really enjoyed reading the article, as well as the debate it generated. I think most people understood, and agreed, with its conclusion: UML was supposed to be a way to improve the communication between software developers (and not only) by providing a common modeling language and, as long as used for this purpose, it’s still a valuable tool. However, by trying to become a code generation tool, UML lost its focus and it’s now more of a hindrance than a help.
Giancarlo Frison writes that “UML is a meta-model to design models, not code [...] it’s not build with Java inner classes in mind”, which, BTW, is absolutely true… But then, how do you expect to use your UML model to create a platform specific model if it lacks the knowledge about the intricacies of that platform?
A special mention goes to mjt/ad nauseam (BTW congratulations for the title)… You should remember that most people posting on the net are not native English speakers. However, according to mjt, for them UML will remain forever “unintelligible”. So please, O Wise One, explain “the power of a meta model and what it imparts to developers who also understand it” to those immature “hard core techies” so that they too can “get it”.
And finally, to Tjerk Wolterink… Yes, we need UML and modeling to define the architecture/high-level design of our software, and yes, “Think before you program” is the correct way. However, expecting to be able to generate low-level code from high-level model diagrams (as MDA proponents claim) is, for me, purely wishful thinking. Modeling and coding (and also debugging and maintaining existing code) are different skills and are all required for a good developer.
Please consider designing something that will impact 100s (or more) stakeholders. Without a common language with which to articulate the concept, you then also need to spend energy teaching the semantics with which you have elected to articulate the concept, i.e. teach someone English so you can talk to them about the weather.
That said, on smaller scale engineer to engineer interactions often lighter weight artifacts, e.g. whiteboard or notepad drawings are often more useful as they are quickly realized. The reason you can do this is that the folks involved have very similar contexts with the problem at hand. When the audience grow, that degree of shared context decreases and more formal ways of articulating the idea, such as UML, are needed.
Good points, and i agree on most of them.
To be honesti would rather have UML and use parts of it’s fetures than not have it at all.
I think there are so many things that you an use from UML that can help make a project succesful. you dont have to use the whole thing…
Perhaps you could have compressed all 13 reasons into one: It evolved out of ‘enterprisey’ software development.
Same problem as we can see all over the internet: People being disappointed because despite UML, in this case, they still have to sit down, think and actually work.
Then they decide that the tool is Bad and feel that they need to tell the world about their “discovery”.
I use parts of UML and like it. I don’t need all of it, nor all of the “UML utilities” that are around - in fact, a paper and a pen works just fine.
I read the other day that the main problem with Java is mainly the Java programmers. I think this applies for UML too.
An interesting selection of points, and I can appreciate most of them.
Was it Churchill who said something about democracy being flawed, but also being better than the alternatives? What are the alternatives?
I don’t agree with most of his points as you could say that about any design language. UML is not alone. If you wanted something that didn’t have these potential issues, you would just code…without design (see #8)
It all resides in how the tool is used. From point #13 it is obvious that the author doesn’t understand the problem that UML is meant to solve, only what the uneducated think it is supposed to be.
UML is a toolbox. It doesn’t solve your problems, but gives you the tools to do so. Why use C++? Shouldn’t I just be able to write English and software pop out?
For me, UML is an uber-geek’s gold mine for learning how to express abstract concepts and integrate business rules. I own the latest UML Guide and have expanded my perspective for looking at projects from my reading. (Yes, I have actually read entire chapters.) Reading about UML’s history has given me an insight into the genealogy of programming.
I’m an infant in the developer’s world when it comes to coding, but I love the dynamic of creating software that “works”. By “works” I mean it accurately represents the process it is meant to automate. Yes, this is art and requires a great deal of creativity. This is where a good team comes in handy so you can play off each other’s strengths. When you’re solo, it’s just as silviup said, “Modeling and coding (and also debugging and maintaining existing code) are different skills and are all required for a good developer.”
A trend I observed in college is to push coders to document first, code second. From what I was spoon-fed, this was not the previous paradigm. For me, I learned to start with diagrams and pseudo code. For others, this would simply slow them down. UML is still a good introduction to structured analysis for students regardless of their use later in life. It’s why we (try to) teach all children algebra, to strengthen their problem solving skills.
Some folks will inevitably be specialists, and as such, have trouble integrating UML into their coding process. These coders do what they know best- dive right in and let nothing slow them down. I prefer to analyze and plan first. I believe we’re both professionals and need to learn as much from each other as we can. Just recognize that learning doesn’t necessarily change practice. There’s room for us all in this industry.
I got fired from a job because I couldn’t remember UML arrows. Actually that’s not strictly true, but I think the reliance on UML in that particular code-shop was a bit too much. I’ve got a UML certificate but I’ve since lost all knowledge of it.
I’m in game development now. I haven’t see any UML schematic yet.
One idea is that creating and maintaining two independent representations of the same information by hand is a big negative.
Based on this principal there are two reasonable ways to use UML:
1. As a high level explanation of a relatively stable part of the system for human consumption.
2. As an implementation tool.
I don’t think the tools are adequate to know if 2 is desirable, so in the real world only 1 is a reasonable choice.
Great article, I will forward on to my old team who are suffering a manager who dreams of a great leap forward into a UML world.
If you appreciate language lawyers, one of your sentences has less punctuation than I would like used. Rather than:
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.
I would prefer:
UML offers software designers a common language. But this idea got lost for economic reasons.
In terms of content rather than delivery, packages, classes, functions written in a programming language can express some design ideas well, and so constitute a design language. So software designers already had a number of languages before UML.
Both UML and packages/classes are bad ways to express some design ideas. I have met many UML and OO proponents who have not worked this out.
You should check out LabVIEW (ni.com/labview). It is a general-purpose graphical programming language. It’s not UML, but it is a programming language which is very intuitive and powerful without the need for text. Things like parallel programming and multi-threading are so simple you don’t even have to think about the fact that you’re doing them, and memory management is handled for you (without garbage collection). It’s an awesome language. You can read more about it on the Wikipedia page for LabVIEW.
Disclaimer: I do work on the product. This is still my honest opinion.
I would claim that ObjectAid is a decent reverse-engineering UML tool. Only for Java on Eclipse right now, but better than nothing.
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.
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.
Only The Code Contains The Truth.
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.
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.
#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.)
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
I think that ‘IT parasite’ will be new resume by-line. Thanks Jamballo.
“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.
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.
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.
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
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.
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?
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.
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.
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!
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
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.
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.
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!