13 reasons for UML’s descent into darkness
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!
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
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
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
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
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.
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
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.
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.
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
Nice post.
Back in 2006, I did a quick survey on uml impact. It may be of interest to some of you. It would be nice if somebody knows of recent numbers.
Look at:
http://amazinnggg.blogspot.com/2006/04/how-widespread-is-uml.html
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, …).
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.
http://www.message_bascna.com/
http://www.message_deltrdelvidr.com/
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!
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.
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.
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
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.
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.
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…
This could be not very easy to compose good thesis topic just about this good topic by your own! My advice is to find the experienced dissertation writing service and other way, you have an opportunity to buy dissertation online at custom thesis writing services.
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
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.
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.
Gr8 post, and bang on target. I couldn’t agree more with you. For any project of even medium complexity, the act of creating/maintaining UML diagrams can quickly become a real PITA. I myself use it mainly for Class Diagrams and some really high-level Sequence Diagrams, and in fact most of the other developers I know also do pretty much the same.
Frankly, beyond simple scenarios, UML is just way too verbose and unwieldy!
-kodeninja
In Corporate World UML has well penetrated. Because UML is promoted by IBM IT professional are forced to adopt it but that doesn’t mean UML is useless.
UML is the aggregation of multiple methodologies of the 3 Amigo, it’s more a patchwork than the Unified Marketing Mantra want make us to believe.
Nonetheless like all tools you need to be educated and above all PRACTICE it to know how it can be usefull.
I have mixed opinions about it. Software development is an iterative process. You can start with basic UML laying out your design and then jump to code. Once you code you can come back and revise your UML for any changes. This leads to classics issue, how do you keep your documentation in sync with code. The other aspect is that you can do design however you like, code it and them use UML Generator tools to reverse engg. to code. I guess what ever works.
I disagree that UML is totally useless. The class diagrams are useful for depicting static analysis and sequence diagrams are useful for depicting dynamic analysis. A case can also be made for state diagrams from time to time.
I find that reverse engineering UML diagrams from existing code using IntelliJ IDEA is helpful to intellectually grasp the design from the 30,000 foot level. By the same token I also like looking at ER diagrams to understand a database schema quickly - particularly the relationship between tables.
If a legacy codebase has been designed poorly, UML diagrams and possibly metrics like cyclomatic complexity will quickly point out its deficiencies.
I do agree that making a case for designing with UML (and spending a lot of time on it) is getting harder and harder in these days of Scrum and agile development. Management and customers often want to see partial functionality rather than pretty pictures. Orthodox Fortune-500 companies may still be using UML heavily though.
Very oft different people try to search for the theme close to custom written term paper. Hence, I would propose to take the aid of writing service. At the same time, that is ok to use some stuff from this good post issue.
Hi,
It was a very nice article! Just want to say thank you for the information you have shared. Just continue writing this kind of post. Thanks.
Business Plan Writers
Excellent rant. My hatred of UML (or to be more precise, OMT) began in ’96, when it (and the appalling tool known as Rose) was forced on a project. Before long all the problems you mention manifested themselves. Huge diagrams where you could only see a corner. Idiotic stick men describing useless cases. Hideous comments appearing as markers in code. Models which proved to be unworkable as soon as you cut real code. Models that consequently had nothing to do, or misleading little, to do with the code. And did the project succeed on time and budget? You guess.
Tragically we still have this abortion, with tool makers giving us stuff at vast expense that supposedly makes UML executable. Rubbish!
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…
Don’t get me wrong – I think the diagrams I’ve described above can be very useful, when applied to the back of an envelope, whiteboard or Post It. What I despise is the fact that I might be expected to document the entire effing project no matter how trivial, and why I should pay a tool vendor £000’s just because they’ve taken these established techniques, called them UML and made a rotten tool.
Did they use UML (or OMT or whatever) when they designed R*t*o*al R*se? If so, what an indictment! Terrible, buggy, clunky software. UGHHHHHH!
I must admit this resource is great for education, very helpful materials for professors and students.
Thanks again for a very well written post, I thought I would leave some positive feedback as this blog has me coming back time and time again, many thanks from the UK and keep up the good work.
this post is fun to read but informative…
College Essay, College Papers
The attempt to become an actual programming language is the biggest problem by far..
Biletul Zilei
To be successful means to get the high academic grade and for this, guys should demonstrate the great quality written essays. But is this possible to perform it without an aid of the professional writing service? Sure, that’s manageable, but it can be more easier to buy essay paper reffering to this post in web.
Your idea supposes to be amazing, but there’re a lot of points to buy the non-plagiarized essay from the term paper writing service. This could present students a chance to get A+!
These kind of articles are always attractive and I am happy to find so many good point here in the post, writing is simply great, thanks for sharing. Dior Sunglasses
Hi,
That’s a great info. Thanks for sharing, really like your view. I can see that you are putting a lot of time and effort into your blog. Keep posting the good work.
Custom Essays
I found this informative and interesting blog so i think so its very useful and knowledge able.I would like to thank you for the efforts you have made in writing this article. I am hoping the same best work from you in the future as well. In fact your creative writing abilities has inspired me.
Hi,
This is really a sad news. Programmers must be very careful about using UML. It is necessary to invest much time in code generation in order to make good web. If you want to convince stakeholders than it is necessary, to make a web page that will encourage them and for this you have to make an effective web page by using an effective language. Coding is really an art.
Thanks, this blog is amazing. Keep posting.
Online Marketing Plan
Thanks, its a very good information of sharing and making people know about the activites that are being carried out.
Really good information. Thanks for sharing
That is the best time to tell that you surprised me with your superb idea about this good post. Hence, we should seek to write the history dissertation according to your article. Or maybe, that is manageable to detect the dissertation service.
thank you very much
Very nice and helpful information has been given in this article. I like the way you explain the things. Keep posting. Thanks.
Very usefull article, thank you for sharing it with us!
Keep it up!
I think the diagrams I’ve described above can be very useful, when applied to the back of an envelope, whiteboard or Post It. What I despise is the fact that I might be expected to document the entire effing project no matter how trivial,
Interesting views. UML has defo become way too complex!:D
I am willing to state that a professional essays online service supposes to be a good assistant on the way of argumentative term paper composing. Hence, people should utilize it every time they want buy essay papers.
When a company does not consider human resource is a matter of time before you go bankrupt. The human resource is what gives value to a company. That any employer should know.
People deserve very good life time and loan or just short term loan would make it much better. Just because people’s freedom relies on money.
Even their attitude towards me surptinde programmers. That is the only resource that brings gain, human resource.
Don Rippert’s comments were (in summary) that by the time you got to any level of specificity in the model that the complexity of the models made them harder to follow than code.
I’ve been using Enterprise Architect to reverse engineer code by loading the code into EA and looking at the generated UML. I’ve given up and gone back to emacs.
Information is very good and useful has been made in this article. I like how you explain things. Keep posting. Thanks.