UML is overrated

[Mark Herschberg]

I feel that sometimes UML is overrated. What do I mean by this?
I view UML like Robert's Rules of Order. Every try to run a meeting of 6 people using Robert's Rules? It's overkill. How about 600? Then you better have a very formal system, and Robert's Rules are a good starting point. The same holds true for UML, especially given how appliable the 80/20 rule is to it.
The benefit of UML is that it is a common language. In small groups, it's easier to get everyone to agree on a common, custom, home-grown notation. At that point, UML may be overkill. In large groups, it's easier to go with a standard.
I think it is important for everyone to know UML, for the same reason most programmers need to know English, it's a defacto standard language among develops in many countries in the world. But if you're particular project, group, company wants to use a language different than English/UML, and that works well for you, I don't see any reason not to do it.*
*OK, there's the chance that 3 years from now, the company is huge and/or has lots of contractors and it's no longer such a small group. But usually this is not an abrupt change, and during the transition, the diagrams and documentation get updated as the code evolves.

--Mark
[e-mail]

[Thomas Paul]

Forget about the company getting huge... what if 3 months from now 4 of your buddies have left and new people have arrived. Now you have to teach them your non-standard methods and convince them that your method is better than UML. And what if all of you leave and the new people can't figure out what the hell you did. This is like saying that since the staff agreed, we will write all our documentation in Swedish even though we are in New York City.

[Mark Herschberg]

Originally posted by Thomas Paul:
Forget about the company getting huge... what if 3 months from now 4 of your buddies have left and new people have arrived. Now you have to teach them your non-standard methods and convince them that your method is better than UML. And what if all of you leave and the new people can't figure out what the hell you did. This is like saying that since the staff agreed, we will write all our documentation in Swedish even though we are in New York City.

Well, we're obviously talking in generalities here, but there are two cases:
1) Your 4 buddies are a significant size of the team
If your group was that small, you are probably using a lightweight process. There aren't going to be complex, custom diagrams. It shouldn't take that long to teach the custom diagrams. (How different can inheritence diagrams be, for instance, just different arrows, different symbols for access to methods, etc.)
2) You 4 buddies are a small number of people
In this case the diagrams may be more complex; but by this point you should have documented the format, anyway, and the new employees can read the docs.

If you have 4 people leave at once, and it's not insignificant (as it would be a very large companies) you probably have bigger programs anyway. Hey, what if you're a company of 8 people, using UML, and 4 leave, and the 4 new hires don't know UML, well wouldn't it be faster to teach them a lightweight language and get them up to speed sooner? You can always come up with an arbitrary, bad circumstance. Talking in generalities, I think custom lightweight processes are often good enough for many projects.

--Mark
[e-mail]

[Brian Schaefer]

It is true that UML is important because it provides a common language. However, one of the "over rated" aspects of it is how complete a language it is. It is analogous to icons compared to English: Like a Hand on the crosswalk light instead of WALK, or a circle with a line through it superimposed on a drawing of a bicycle. It suffers from the lack of richness that a language possesses. The common language for coders is code. When we think, we talk to ourselves in code. Personally, when I find myself designing, I think in terms of what the methods are doing, and what state they are operating on. A UML diagram does not contain that information. The names and signatures of methods only, and association lines all over the place, don't seem to help me very much. Class diagrams are certainly helpful to visualize a complex hierarchy, but that is simply a diagram that we would sketch anyway, like a directory key. The multiplicity notation may be helpful to some people, however I find it confusing until I know how it's implemented in the code through collections and sets. Tools for using UML, like TogetherJ, where the code and UML are visible and automatically kept in sync do hold more promise of helping coders think and communicate. However, the diagram will always be redundant to the code. I'm reminded of the saying, "A picture is worth a thousand words," and the observation that you need words to say that. Also needed is a person who thinks in that language. A picture may be worth thousands of words because of the details, but a set of icons is worth an exact small number of words.
One diagram that is useful to me is the old flow chart, activity diagrams. However even flow charts, as I've learned to code simpler, smaller methods and objects, are losing their usefulness. The goal is simple, self documenting code, that can be read by anyone... pleasurably, like poetry.

[John Wetherbie]

I would disagree that UML is too heavyweight. I guess it could be, like pretty much anything else, if you used every aspect of it. UML has the advantage of being pretty well known and the important parts (class diagrams, sequence diagrams, and state diagrams) are pretty easy to learn. I've used OMT (UML is 90% OMT) or UML on teams that have ranged in size from 2 to 110 people.
I see it like design patterns where you say "I think we need a Mediator here" - you draw a class diagram and the person understands what you have drawn. But as I noted above, you can get carried away with it, draw tons of diagrams, and totally bog things down. It's a tool - use it wisely and where needed.
John

[Thomas Paul]

If you buy into RUP then you have probably taken things to extremes. We use maybe 6-8 diagram types for most applications and that is sufficient. As far as hiring people who don't know UML, you can't even pick up a basic Java book anymore without it having class and sequence diagrams.

[Michal Harezlak]

Mark:
UML is not a Process. I think that is a main misconception here. We all agree that communicating what we are doing is necessary (even better if we keep it for documentation). I see not major drawbacks (personal preferences) comparing UML to any other notation. You can choose desired subset of UML and it will be as "lightweight" as anything else out there (with comparable capabilities). What would be the overkill you speak of? UML strength is its flexibility and extensibility.
SIDE NOTE:
Yes, English has very significant influence on CS, but you probably overrate it. In most Europeans countries I worked in (except for UK of course ), you would come across some sort of slang with strong English influence, but no lamer could understand it. Czechs and French use have no English derived vocabulary I know of.
Brian:
If I am not mistaken you might be looking for Dynamic Diagrams, very helpful. As for loaded and hard to read Class diagrams. Duplicating a code in the Class diagrams is really unnecessary. Well-commented code is all you need. Class diagrams with different levels of details are used on various stages of design. Good introduction would be "UML Distilled".
regards.
michal.
[This message has been edited by Michal Harezlak (edited February 28, 2001).]

[Mark Herschberg]

Originally posted by Michal Harezlak:
[B]Mark:
UML is not a Process. I think that is a main misconception here.... You can choose any subset of UML and it will be as "lightweight" as anything else out there (with comparable capabilities). What would be the overkill you are speaking of? [B]

No, I'm quite clear on the difference between notation and process. My claim is that if you have engineers who have a common "language" for diagramming code designs, it it not always necessary to switch to UML--although I have seen some pundits/consultants/instructors who claim UML is a must.

Originally posted by Michal Harezlak:
[B]Mark:
SIDE NOTE:
Yes, English has very significant influence on CS, but you probably overrate it. In most Europeans countries I worked in (except for UK of course ), you would come across some sort of slang with strong English influence, but no lamer could understand it. Czechs and French use have no English derived vocabulary I know of.
[B]

Again, my claims aren't universal. But from what I understand English is the predominant language (having aplurality in the arket if not majority). Go to Isreal for instance, where it's not uncommon to have Americans, British, Russians, and Isreali programmers; they generally choose English as the language for the office. (I may be wrong on this point, because all my information is second hand.)

--Mark
[e-mail]

[Michal Harezlak]

No, I'm quite clear on the difference between notation and process. My claim is that if you have engineers who have a common "language" for diagramming code designs, it it not always necessary to switch to UML--although I have seen some pundits/consultants/instructors who claim UML is a must.
Agreed, switching methodologies/technologies in the middle of the project is not always the best thing to do. Depends of circumstances of course. Extremism is almost never a good thing. But the tool is not to be blame for ones �devotion� (as you call them pundits/consultants/instructors). UML is the best thing out there, for many reason and when you start fresh probably the best alternative?
Again, my claims aren't universal. But from what I understand English is the predominant language (having aplurality in the arket if not majority). Go to Isreal for instance, where it's not uncommon to have Americans, British, Russians, and Isreali programmers; they generally choose English as the language for the office. (I may be wrong on this point, because all my information is second hand.)
I am not trying to start anything here, Mark. Hope we all are friends. Just shearing the information and trying to learn. No matter how un-PC it will sound: English is the most popular language in the civilized world despite of what Franchis like to think, so it would be a common denominator in many situations, not only CS related but most modern technologies and business.
Regards.
Michal/
[This message has been edited by Michal Harezlak (edited February 28, 2001).]

[Mark Herschberg]

Originally posted by Michal Harezlak:
Agreed, switching methodologies/technologies in the middle of the project is not always the best thing to do. Depends of circumstances of course... UML is the best thing out there, for many reason and when you start fresh probably the best alternative?

Prof Daniel Jackson of MIT would probably disagree. He argues that UML is too complex and created his own modeling language called Alloy. See http://www.javaranch.com/ubb/Forum9/HTML/000198.html for more info.

Originally posted by Michal Harezlak:
I am not trying to start anything here, Mark. Hope we all are friends.

I don't get offended easily, certainly not by open discussions of ideas. :-)

--Mark
[e-mail]

[Thomas Paul]

When I read stuff like "UML is too complex" I have to laugh. UML is flexible and that flexibility leads to complexity. As I mentioned earlier, we use maybe 6-8 diagrams. Is that really too complex? On some systems we may use a diagram that we don't normally use. The fact that UML provides so many options is the strength of UML, not its weakness.

[Michal Harezlak]

Mark:
From what I know about Alloy (and it is not much so enlighten me please if I am mistaken) it is strongly methodized (algebraic based) notation. It might not have very complex syntax, but for most people will be hard to grasp conceptually (not many people dose well in algebra which requires lots of practice with abstract thinking). UML dose (IMHO) excellent job with communicating requirements and design is easily readable for (use cases, conceptual class diagrams) the client (future user). Alloy fits in well on implementation faze when you deal mostly with precisely thinking people (engineers). Because of Alloy's strict notation it dose well in tasks like reveres engendering or CASE where UML dose not shine. So it seems to me that UML and Alloy dose not compete for the same niche.

[Michael Ernest]

I'm not a big fan of UML, nor am I opposed to it. I cast my lot with consistent code practice. UML is one form of consistency, and its promotion seems as much political as anything else. What would make UML valuable to me is if it provided a scheme with tangible advantages over other styles. So if it's inherently simpler than a) reading the source code or b) using another style, fine.
The big dream that UML rhetoricians cast about is that UML brings consistency and efficiency to the INDUSTRY. So a rally around UML will make it easier to understand and maintain code someone else has written. Instead of touting "write once, run anywhere," UML says, "design once, implement anyway that suits you." And, if you happen to leave the project, the design will speak for itself what remains to be done. Mm hm.
That's also sounds like a claim that applications can be designed independently of the language used to express them, and that vision only goes so far. Real architecture recognizes that materials impose limits of their own. A blueprint doesn't try to pretend that what can be done with steel and glass could also be done with brick and mortar.
Asking all architects in our industry (OO Architects, anyway) to agree to a common language sounds like a dubious goal at best.
------------------
Michael Ernest, co-author of: The Complete Java 2 Certification Study Guide
[This message has been edited by Michael Ernest (edited February 28, 2001).]

[Geoff Tate]

I agree with Michael Ernest - it is tough to design without consideration for the materials - you could solve the same problem domain using VB or Java yet I bet that the UML used in designing the system would look quite a bit different...

[Thomas Paul]

I think if you are planning on developing using a good OO language, then UML really doesn't have to worry about the actual language choice. Of course, VB is not a good OO language.

[Anonymous]

Originally posted by Michal Harezlak:
Mark:
From what I know about Alloy (and it is not much so enlighten me please if I am mistaken) it is strongly methodized (algebraic based) notation. It might not have very complex syntax, but for most people will be hard to grasp conceptually (not many people dose well in algebra which requires lots of practice with abstract thinking). UML dose (IMHO) excellent job with communicating requirements and design is easily readable for (use cases, conceptual class diagrams) the client (future user). Alloy fits in well on implementation faze when you deal mostly with precisely thinking people (engineers). Because of Alloy's strict notation it dose well in tasks like reveres engendering or CASE where UML dose not shine. So it seems to me that UML and Alloy dose not compete for the same niche.

Alloy isn't algebraic. It is 'strict' in the sense that it has a syntax that can be checked, but then so is UML (and any language that hopes to have tool support). What makes Alloy different from UML is (1) that it's designed for tool support -- you can check for consistency, do simulated execution, etc, whereas UML offers only shallow syntactic checks, and (2) it is conceptually very simple. It's not intended to compete with UML as a whole. If it competes with anything, it's OCL, UML's object constraint language. You probably don't need a constraint language like OCL or Alloy if you just want to lay out some classes, but if you want to express complex business rules, analyze a protocol or check subtleties of a design, you'll need more than diagrams. Alloy is a kind of "software blueprinting" language. We used it, for example, to fix problems in the design of a resource discovery service. Our model was about 100 lines long and took 2 weeks to build: much less effort than the system itself, and it found bugs that the system's developers hadn't found. More info at http://sdg.lcs.mit.edu/alloy.
/daniel
edited to remove period from URL
[This message has been edited by Frank Carver (edited March 06, 2001).]

[John Wetherbie]

Thanks for the link, Daniel.
Oops, just received a not found error. Guess I should follow the link first and post the reply second. Anyone know of a working link to this?
Thanks,
John
[This message has been edited by John Wetherbie (edited March 05, 2001).]

[Michal Harezlak]

Originally posted by John Wetherbie:
Thanks for the link, Daniel.
Oops, just received a not found error. Guess I should follow the link first and post the reply second. Anyone know of a working link to this?
Thanks,
John
[This message has been edited by John Wetherbie (edited March 05, 2001).]

yes, just remove the '.' at the end.

[John Wetherbie]

Thanks, I see that the period is part of the URL now. (Duh!)
John