UML Fever

CowboyRobot writes "Queue has a couple of articles about UML: Death by UML Fever by Boeing software architect Alex Bell describes the problems that can result from over-reliance on modeling tools, with lighthearted lessons for the software development process in general and numerous illuminating quotations, such as: "Good judgment comes from experience. Experience comes from bad judgment. - Jim Horning." Then, one of the developers of UML, Grady Booch of IBM, follows with The Fever is Real, in which he explains the motivations for creating the language, how it's used today, and where he expects it to go soon."

Comments

Re: Everything, including tools, in moderation!

[Face the Facts]

Design patterns and UML were designed as practical tools, not dogma. If they help you do what you were doing anyway (and they often do), then great: use 'em. But if they don't, then don't. They're there to serve you, not the other way around.

This is true, but note that the UML/patterns/OO newbie is in no position to determine that. One common mistake is to read the book, discard the parts you don't think is necessary, and then proceed with your design work. The rules that you chose to ignore were put there by pretty smart people, and there's a good chance they were put there for a good reason. When the design finally fails because you were missing something, the egotistical designer then blames the method.

The point is, I think the parent post was suggesting that the programmers in question may simply have broken the rules, and not actually found some instance where the methods really apply poorly. It's ego-boosting to think that what you do is unique and beyond the reach of old stuffy rules, but the truth is that most of us are doing things that have been done before.

This isn't to say that those cases don't exist, but that they're probably rarer than you think, especially if your team of programmers is trying it out for the first time, especially if you don't have a senior engineer already experienced in the method guiding your team. For the first time, at least, the instructions should be followed to the letter and strictly enforced. They should be dogma until you've at least went through a complete product life cycle with them.

What you suggest we've already tried for decades. The result is prevasively poor documentation and fragile designs.

UML

[JaxWeb]

Who uses UML? The designers or the programmers?

I should imagine the designers wouldn't be very good at it, and I should imagine that programmers would have better ways to express themselves.

Sorry, this has just been a question I've wanted to know the answer to. And the story has been /.'ed.

Re:UML

[sporty]

As a programmer, who has used various UML tools, doing OOD (oo development) is a little easier with a graphical tool. It becomes REALLY easy to see how everything relates. Think of it like an ERD (entity relationship diagram) for a DB schema. Once I have my class diagrams and what not, i can generate java from them. I don't have to type out the class framework. Better yet, I can take an existing project and show how everything relates and in turn, have a map of an existing project.

Re:UML

[Woogiemonger]

I've rarely seen where the designers aren't the programmers as well, at least somewhat. If there are people doing the design for a software, they're generally the lead developers and have a better chance at coming up with an intelligible, well-crafted set of UML diagrams than the programmers not involved in software architecting. When you say "better ways to express themselves", what ways are you referring to? While UML can be considered overkill, it certainly covers the bases.

Re:UML

[toesate]

Before reading on, let me just say that I am a proponent of using UML/IDL/Design patterns. So..

One of the idea of UML is that this framework allows for people of different roles to converse in a common modelling language.

A business/product person will easily understand Use Case and high level sequence diagrams.

A product architect/designer is able to transform these use cases and sequence diagrams into "lower level requirements" - more sequence diagrams, state diagrams, and define the IDL interfaces relationships between interacting "boxes".

An engineer is able to take in these low level requirements, read the state diagrams and IDLs, create the component and class diagrams, and generate the skeleton codes for actual implementation.

From managing requirements point of view, UML is a good tool, provided that everyone in the food chain understand their roles and know how to create proper diagrams and read their counterpart's diagrams. (You cannot blame the tool if someone do not know how to do their work.)

In case someone misunderstood me, UML itself is not sufficient for software development, but with UML, the whole software development can be a much pleasant tasks.

Overall, (I think) UML does make my engineering team more efficient - you know when the first thing my fellow engineers do after opening a specification document is to look for some UML diagrams.

Re:UML

[toesate]

If the programmer and designer aren't the same person, I'd argue that the project is already in trouble.

Not necessarily, I'd argue otherwise.

One of the way to make this work is to bring Xtreme Programming from coding to designing too.

For example, you design this side of the interface, I design the other side of the interface. And then, I implement this side of the interface that you had design, and you implement the other side of the interface that I had design.

So, you see, the designer and programmer are different persons, one design and the other code what was designed. And this can work pretty well actually.

Of course, for argument sake, this can still means that the programmer and the designer is the same person, since they are both working on the /same bigger thing/.

This also requires both parties (you and I in this case) to trash out any misunderstanding during designing phase, or during early stages of coding. And it will definitely help when both are versed in, for example UML.

Re:UML

[plover]

Your post reminded me of my initial reluctance to adopt UML techniques. My first exposure to this was about 10 years ago when Booch, Rumbaugh, et al, were still busy duking it out whether you should draw relationships as dashed lines or dotted lines to red clouds or black boxes. There were some really heinous proposals floating around (Booch had some of the worst, as I recall, because they all centered on "you should draw this thing exactly this way," where a stray curlique on the left side of a comment box might mean "but only in odd years preceding a leap year.")

UML still suffers from some of that: filled arrowheads vs. stick arrowheads, for example. Arrows do inherently express a relationship (at least to me,) but neither filled nor hollow represents "synchronous" vs "asynchronous". The UML is an 800 page standard, of which about 750 pages are useless detail fluff of this nature. Yet they're all "part of the standard" and thus are all equally important, at least to the AR+ people who religiously push these things. I understand that if you want to precisely express an idea that you should use the precise syntax in the language. But practical use of UML shouldn't require knowing all 800 pages, just as writing practical C++ code doesn't require an intimate knowledge of templates.

Please don't dismiss me immediately as a UML critic (or a template critic!) One of the places that I find it of value is that it gives us developers a common ground on which to meet the analysts and business users. But much of the syntax is simply too cryptic to be of real working value in expressing ideas. And if you look at developers as the "compilers" of UML (the people who have to interpret it into code) we would have to know every last comma of the standard to perfectly implement it. Not a realistic assessment.

Designs cast in Stone

[Titusdot Groan]

My first encounter with a group using UML was when I was called in to review the design of a medical imaging system. I learned UML, thought it was pretty cool, and then reviewed the design.

I found a significant design flaw with a pattern that they were using everywhere and raised it as an issue. Turns out they knew about the flaw but didn't want to fix it since they would have to redo all their UML diagrams for the bulk of the project.

Then they had the nerve to ask me to signoff on the design. Further they had the nerve to ask me to use UML on my next project!

UML is really great for communication of designs. But if you invest too much into the UML you end up "coding" the proposed design and it becomes too hard to modify.

Where UML really shines is in HUGE projects, where systems analysts design the system in UML and programmers write the code. Anything else it's a little bit of overkill and a little dangerous.

Re:Designs cast in Stone

[naden]

Parent is exactly right:

UML is perfect for HUGE projects where you have a large number of developers, designers and managers all of whom must understand what is going to be delivered.

Everything smaller should be interface driven. That is, you do storyboards and interface mockups as the next step after the requirements specs. THEN you give those mockups to the programmers and tell them to implement it.

This tends to result in the best quality programs because it comes from a user-centred point of view rather than a programming point of view.

This is how you explain the difference between OSX (top down) versus Linux (bottom up) approach to developing the OS.

Boring, but true story

[smallfeet]

A worked on a new development project a while back and we decided to try XP for the design and development cycle. Another project in the same department started at about the same time and used Rational Rose and produced a lot of UML design specs up front. We had part of our application up and running to the users satisfaction within 3 months, but then ran into a major design oversight that bogged us down for the next 3 months. The other project didn't start to program for 2 months and didn't have anything really to show the customer after 6 months. In the end both projects were killed.

The moral: There are no magic bullets.

UML and OO

[No. 24601]

While UML is better suited to OO designs, it does provide facilities (activity diagrams) for designing algorithms in say C or Pascal and for describing system interaction with external components (sequence diagrams). However, UML is particularly directed at OO development and using it to develop software in non-OO languages requires a bit of a hack.

One facility I think is particularly absent from UML is modelling of error conditions. In most cases it's awkward to indicate that an error might exist and how to handle it if does occur. Also, UML notation seems incredibly basic (gulp!) and simply can't tackle algorithmic modelling for complex applications like memory management or software interrupt handling in an operating system.

If not already underway, the open source community should step forward and come up with a more advanced alternative to UML and then perhaps demonstrate its usefulness by applying it to a complete modelling of say.. oh.. umm... Linux ;)

Two Words: Sprint

[That's Mister Jesus]

OK, that's not really two words, but two words with a colon after it is much funnier than one word with a colon after it. Anyway, folks from the Kansas City area are familiar with Sprint, for whom we've all worked occassionally. It's your typical environment where management is non-technical but deluded to the contrary and they overcommit to things like RUP, UML, and code generation toold. Some people will tell you there should be sequence diagrams for every single bit of logic in an application and so on. It's all been said before and I'm sure there are many Sprint's out there. The applications work eventually, but at great cost, delay and frustration.

In my rarely humble opinion, UML is misused as just another management crutch, like powerpoint and outsourcing. Managers want to wow their uppers with charts and graphs and a few simple innovative ideas rather than than be hands on and make the tough decisions required to bring a project in on time and on budget. They put all their faith in an ideas like UML and RUP that they themselves don't fully comprehend and expect the world to magically change.

I was recently in a working group meeting for an insurance standards body called Acord. Somebody whipped out an interaction diagram and all these MBA's thought it was the second coming of Christ(or the first coming if you're Jewish).

Is UML really a language?

[pohl]

What is the justification for the 'L' in 'UML'. I realize that in the loosest sense, UML is intended to be a means of communicating ideas, but it feels extremely primitive, like cave drawings. There's not even a standard machine-parseable representation for UML so that various programs can generate/manipulate/transform UML models without reverse-engineering some proprietary cryptic file format. And as for communicating person-to-person, I find it much more practical to use design-pattern language and a few terms from The Jargon File to improve communication with my team. Think about the jargon used between surgeons and their assistants -- to me, that's the kind of language that actually improves communication where it matters...UML seem to take the part of the development cycle that proceeds at the most frustratingly glacial pace and make it even slower. And that seems to make it different from all of the other languages that I've learned.

uml2code...

[StarBar]

Unified Modelling Language is exacatly that, a unified way to build system descriptions with. Before UML people battled themselfs blue in the face about weather clowds or elipses were to be preferred when drawing systems graphically. The big problem with UML & co is how to generate code *and* get code changes back to the design at the UML level. No, you don't want to redraw the design and regenerate the whole program structure just because you found a small design flaw. Much of this requires expensive method specific tools (ie Rational's) that will wall you in like a whale.

What I would like to see instead is an Open Source command line tool uml2code that will generate source code or patches to an existing code base from an XML description. This would not work unless there is a reverse tool code2uml to analyze code changes, with necessary markup of cource, and generate a change to the XML description. There are some work done in the area but no tools that I know of. This aproach would give the benefits of a common XML interface between the GUI and the code generation and also the freedom to work with any normal set of compiler and tools on the output. Hmmm, just dreams though...

Here is a really easy methodology:

[master_p]

I have used UML in the past, but it is an overkill for most projects. Here is a quick altenative which works and can be applied mechanically:

1) write all functionality down as text
2) scan the text and:
a) note all nouns
b) note all verbs
3) make the nouns as objects
4) make the verbs as methods
5) write a dictionary.
6) discard what's left.
7) find the common parts between classes (find base classes)
8) draw an inheritance diagram.
9) draw an ownership diagram (the object model).
10) make up some examples and act them out (either by yourself or with a team) to see if anything else is needed.

It has worked for me quite well in the past for most cases. You can also repeat any number of steps any number of times desired, if cyclic developement is required.

Re: Everything, including tools, in moderation!

[eyeye]

What book is that?
Thanks.

Re:Programmers don't build programs

[Bozdune]

That's certainly true, but the "usual problems" can be mitigated with careful thought and good design. I've built lots of software from inadequate specifications. It's possible to do a good job if you take the time to understand the problem domain, even if the specification is poor or nonexistent.

Neither of the following examples involved me, but I was an interested contemporaneous observer of both.

Case study #1: Web application (buying portal). The app was designed with J2EE tools, and the Architect allowed the tools to automagically generate the schema that supported the app. Problem: The Architect did not consider that reports would need to be generated from the schema, some day. When it came time to write them, the task was horrific and nearly impossible, and the team almost failed. Who is guilty, management, for not specifying all the reports up front, or the architect, for not anticipating the need for reporting? The Architect, of course, blamed management; management, naturally, blamed the Architect.

Case study #2: A very arge commercial bank wanted a system for loan portfolio analysis. The Architect endured management displeasure over his long-ish timeline by designing a pseudo-language first, in which the team ultimately wrote the portfolio analysis package. The Architect did this because he envisioned massive downstream changes to the specification. Numerous changes to the specification then occurred over a two-year period, just as the Architect had predicted. Result: The Architect's company pocketed huge sums by bidding half of what the competition bid on the same project, and incurring almost zero cost, because the pseudo-language changes were so trivial to make.