UML worthwhile

Our experience with UML on complex projects hasn't been good. You end up spending too much time in manipulating diagrams and keeping them in sync with the code.

Also working with graphical files and merging models on different branches is difficult and complex.

Sandeep

--

My (albeit very limited) experience of UML has been similar. I'm fundamentally unhappy with graphical analysis.

Many years ago we used flowcharts, and had huge synchronism problems - it was always easier to tweak code than flowcharts, so the flowcharts were always hopelessly of date. They also required reams of comments. At a certain point I discovered KDL, then moved to a generic C-like written structured pseudocode. Nowadays I simply write well-commented C.

However for analysis I've always used written documents - and now UML requires me to revert to using graphics. And to memorise a large set of graphical conventions that I know my customers have no chance of being able to understand and comment on. Since "clarity" is probably my most important design/analysis criterion, I choose to eschew the pleasures of UML.

I look forward to a text-based UML ;).

Steve (who sincerely hopes that UML is but one step towards something better)

I've used Visio 2000's UML stencils to draw class, collaboration, and sequence diagrams both during the design phase before code and to document code after the fact. I think it made for some decent documentation. The Visio diagrams were put into MS Word software design documentation to go along with descriptive text. There was no comprehensive tool to automatically tie the diagrams to the code. For me, its a lot quicker to use pencil and large pieces of paper to sketch the diagrams and then Visio once its mature. Or get a drafter to do it.

To keep the code in synch, how about code generation from the models?

Bruce

The code generation from UML tools is pretty lame. Basically you get a class declaration and function body.

The biggest problem is working on two parallel branches of software. In that case you have to maintain two branches of the model, merge them etc.

Merging in UML tools is painful as you have to carryout a graphical merge.

Sandeep

--

Disclaimer. I'm writing here from the point of view of someone who generally works on small embedded systems, on 'systems' stuff rather than apps, or on fairly generic networking/middleware systems. I don't do big 'IT' systems, I don't do stuff with a complex user interface -- I suspect I'm a fairly typical developer/manager as far as this newsgroup is concerned.

For small embedded systems, I find that UML is just overkill. At most you need state machines, and something along the lines of MASCOT to show the dataflow. There just *aren't* objects in most small systems, at least not in the UML sense!

Where UML does come in useful is in sketching out bigger systems - developing use-cases, data models and the top levels of the class hierarchy. I've used UML and CASE tools for the architectural design of a big middleware project, but the 'detailed design' was done manually without the aid of UML or tools.

I certainly wouldn't voluntarily use UML for anything much smaller than (say) a large-ish PC or serverside application. I think the low information density and high bureaucracy mean that it's less efficient and less comprehensible than conventional specs and design documents.

UML starts to pay off on huge systems. Having a centralised view of what the system looks like and the concepts it's meant to embody is useful when the system's too big to fit into one (or a very small number of) heads.

I've been profoundly disappointed with Rose and Rhapsody when I evaluated them, though. Their round-tripping and reverse-engineering ability is poor, and they just feel too clunky to use 'ad hoc' to express requirements or high-level designs.

In fact, the best UML tool I've come across is probably Poseidon - which lacks the do-it-all pretentions of the heavy commercial hitters and actually concentrates on letting you get your ideas down.

(Although in a pinch I'd be as happy using Visio. It doesn't actually matter to me whether UML diagrams have automatically-checked semantics. They're something to bring to meetings and argue through with your co-designers...)

pete

Seconded. Actually, at one point I just used to scan in the diagrams from my notebook. After all, design documents are *internal* and don't need to look immaculate ;)

pete

I use a UML subset, without all of the complexity that tools require to generate code.

Class diagrams are useful for identifying objects and relationships between components during analysis. In particular, I have found that exploring the cardinality of relationship between components and subsystems is especially useful during problem decomposition.

UML state machines are especially useful during the design phase to describe complex behaviors.

In all of the above, I use Visio (I wish there were an equivalent OSS tool ... sigh) with some UML templates.

For architectural concepts, I find that a graphical representation is a much more effective communication tool than a large textual document. This is especially true in meetings.

However, while pretty pictures are nice for presenting concepts, there's nothing like text (e.g. C++ source) for the detail and implementation.

By way of analogy, look at the way our hardware brethern work. Schematic capture is used to describe the higher level connectivity and logic of a system, while a text based language (e.g. VHDL) is used to describe the detail.

That being said, my favorite use of UML is in the design of state machines. I have become quite adept at translating UML state machines to C++ using the GOF State pattern.

Disclaimer: I work with medium to large size 32-bit embedded systems. YMMV.

I haven't used it. I have been through a 3-day course on it, and I've also worked an a company where some projects did use it (Rose, IIRC). IMO, it was a huge waste of time. The projects that used UML typically required twice as many people and took longer than similar projects that didn't use UML.

Typical problems encountered by the UML users included the "big-surprise" when all the modules were finally coded and linked: The code was twice as big as the ROM, and basic assumptions about how hardware worked were wrong. So, the whole design is tossed, and the one poor guy who's left on the project at that point basically re-writes the thing from scratch.

Smaller teams that took a more incremental approach seemed to have far better results.

These were all smallish projects involving 32K-64K of code on

I have read the book "Practical Statecharts in C/C++" by Dr. Miro Samek, who proposes the Quantum Framework. I find it a very practical approach to applying UML (in fact a subset of UML statecharts) in embedded systems. It's far more competent than the State pattern illustrated by GOF, as it supports a hierarchy of states. Hierarchical statecharts are much more powerful than the single level state-transition diagrams.

Also read the book "User Interface Design with Statecharts" by Horrocks.

In summary I think Statecharts are the single most useful tools in UML, followed by Class diagrams and sequence diagrams. You don't necessary use CASE tools to do that. Visio is sufficient.

Lawrence

there

The responses so far seem to be pretty negative. I've never used UML, but you might be interested in what the author, somewhat pretentiously IMHO, calls "quantum programming":

It's a methodology and application framework for doing "UML" directly in code, without needing automated tools. Concentrates on heirarchical statecharts / state machines.

Yes, I was sufficiently impressed to buy the book too; it looks like good stuff so far although I have not had a chance to try out many of the ideas.

BruceL wrote: > I would like to get feedback on the usefulness of UML. Anybody out there > using it? Used it and threw it out? Loved it? Any users of Rhapsody, > Springboard, Bridgepoint, Rose real-time, etc?

I have been working as a systems architetc for a long time, without producing any software myself for at least 20 years. However as architect I do have to understand (and read) the produced software.

I personally severely dislike UML diagrams. My main problem is that the diagrams contain a lot of informatiom, which I don't need, while the information I am looking for is somewhere hidden in all that noise.

I would prefer a few diagrams which contain the hot issues, which might be a state diagram (but drawn in a way that makes the main issues immidiately clear), a class diagram (same condition applies) etcetera.

As a tool I like (graphical) browsers, which show me aspects which are invisible if you look at the linear code files. Most UML documentation seems to fit more in that category, but poorly visualized. I also do like to analyse the code with all kind of UNIX tools (grep, wc, Python scripts) which works very good on clear textual source code, but is more difficult to use on the propietary intermediate text formats of UML tools.

kind regards, Gerrit

able

important

Actually, the OMG specification for UML uses natural language (in this case, English) to define the semantics for all UML concepts. It is quite possible to use UML in a meaningful way without ever having to resort to graphics.

I have been using UML (or rather, Rational's implementation of UML) off and on for many different projects. I have found that I use it most often and most successfully during initial requirements analysis -- anything after that gets to be a real pain to maintain. (Although, that is more of a tool problem than a problem with UML itself.)

Travis

I've got the book "Practical Statecharts". Pretty straightforward stuff.

Bruce

there

Suberb book! The "Practical Statecharts in C/C++" concept is to code UML statecharts in either C or C++ and cut out the middle man (UML Tools). The compiled code is small and efficient; essentially its a C/C++ library that does all the donkey work involved in executing state machines; all the developer has to do is define the state machine using high.level constructs (states, initial state, events, transitions).

My experience is also that UML tools are collosal monsters that slow down development; yet another obsticle between concept and having something running. You can't beat pencil and paper during the early days, then just a simple diagraming tool when things stabilise.

On the other hand, it is good to have a standard graphical notation for documenting state-machines, class relations ships, sequence diagrmas, interaction diagrams; here, UML serves some pupose at least. The notation is useful but the tools stink.

Tim

Sorry I missed the original post.

I've been working with Rhapsody for 4 years now, using UML for design, and using the full code generation capabilities. I've found UML very helpful for some aspects of design, particulary class diagrams, sequence charts, and state diagrams. Many of the diagrams have not proved useful. For example, since this is a real-time embedded system, use cases/diagrams have not been very useful. There are still aspects of the design that can't be represented in UML, for example our math intensive algorithms. Overall, I'd say the usage of UML has been a plus to my work; possibly the best thing about it is that there are a lot of software professionals that know UML. In the 'old' days, all the competing notations made it difficult to move to different projects, or bring people into a project.

Rhapsody does a decent job providing an environment to design software through UML diagrams. It's imperfect, but overall makes life easier than writing straight C++ code. I can go into more detail if you have more specific questions.

Paul Kinzer

QTI

there

Thanks Paul. You're one of the few with good experiences. I have found diagramming and code generation very helpful and will be doing it much into the future.

Bruce

for

been

represented

is

Rhapsody,

tools.