Need a discussion of UML/UML tools

I'm trying out a UML drawing tool by running through the tutorial. I was a Fortran/C/C++ programmer a few years ago. I'm running through this tutorial thinking "Do people actually use this crap to design software." Maybe I haven't yet received the big picture. I kind of thought I did have the big picture. Maybe the tool is just bad - (Telelogic TAU Architect). Maybe I just have to get more familiar with the tool. Maybe the beauty of UML will suddenly crystalize before my eyes and a new world will open to me.

But I doubt it.

Anyone have anything great/not-so-great to say about UML?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Your Question "Do people actually use this crap to design software?", could refer to the software tool you are evaluating (Telelogic TAU Architect) or UML in general, so I'll address both as best I can.

Yes - Modelling a system in UML is a valid and useful technique.  It can greatly enhance and speed-up the design process for complex systems/applications.  It is particularly useful when bridging the communication gap between the requirements knowledge of project sponsors (users), and the technical knowledge of architects and developers.  However, I have had mixed success in the last few years since the first specification was ratified and the first few tools became available.

For example, I have found that in very large developments of over 100 developers split into functional teams, and with a disparate group of analysts/architects, the tools are useful only during the initial design stages.  Once the project has iterated through its first few prototypes/POC's the effort required to maintain the UML model can quickly outweigh the benefits.  In one project, running to a budget of £14 million, we stopped maintaining the UML model as soon as a small release of basic functionality went live.  After this we used more traditional methods based on requirements documents and change control software.  One of the main problems we had was that with so many coders/architects etc, there were very few people who knew UML or any of the tools we were using.  In this case, there was an additional 4-6 weeks of 'training/experience' until a programmer began to show a thorough knowledge of the model and was able to work effectively.

In another example, on a very small project of 5 or less programmers, the UML model was maintained throughout the development and did contribute to the RAD / Extreme Programming approach we employed.  However the cost of the tool licenses (in this case) and additional headcount required to maintain the model made the project very expensive in the first 3-6 months.  Later development and maintenance however was very cheap.

In my experience, a significant cause of annoyance with UML modelling is the expression of a complex GUI form.  Since each input on a form has a relatively limited scope on its own, the underlying behaviour model for a form is usually tiny compared to the model itself.  I usually recommend that modellers limit the number of real inputs that they include in the GUI model, or re-model breaking a larger GUI form into a number of smaller models.  You might want to consider how the Telelogic tool addresses this sort of issue.

You might also look at how TAU architect models component interaction.  When the Telelogic offering was evaluated by my last client, they had difficulty following an interaction over several components, although they admit that they had not moved over to the UML mind-set yet and were perhaps still thinking in a procedural design approach.

Finally, I am a big fan of Rational tools in support of Extreme Programming on larger projects.  Although large and expensive, the tools are comprehensive effective, and tie in with Rationals excellent software development and maintenance tools.  Programmers, Analysts and Architects are more comfortable gaining training credits in a market leading product and are more likely to continue to maintain the model throughout the Software Lifecycle.

For smaller projects, I would make sure your design and development team are completely behind the decision to use UML and are dedicated to maintaining the model throughout.  Remember that UML is primarily about documentation, design and communication, while providing a good head start on your ddevelopment.
rfr1tzAuthor Commented:
Is the concept that you can generate code from the UML model? Or is that just marketing hype?
Yes.  There are a number of tools to generate code directly from the UML model.  Some teams just generate the class and method stubs and fill in the code manually, and other people prefer to generate fully working code and then optimise from there.

In my experience ALL generated code is faulty or inefficient in some way, so there is always further development to do, even if you have a well behaved generator and the main development effort is on look & feel or customisation.

A quick search on the www will give you some good "UML Code Generators".  Rational have a suite "Technical Developer" which is an excellent aid to Extreme Programming.

The Ultimate Tool Kit for Technolgy Solution Provi

Broken down into practical pointers and step-by-step instructions, the IT Service Excellence Tool Kit delivers expert advice for technology solution providers. Get your free copy for valuable how-to assets including sample agreements, checklists, flowcharts, and more!

There are alot of different diagrams in UML as you probably know and some are more applicable to software then others.  If you've ever done flowcharts for software design, the UML equivilent are activity diagrams.  This is useful in my opinion.  Also, Use case diagrams are kind of the staple that almost all UML developers use.  Basically, I make a Use Case diagram, then make activity diagrams (flow charts) for each use case and that should be a good start.  It helps you to make sure you don't miss anything.

They say that the most valuable thing that you get from UML modeling isn't the model itself, it's the thinking that you have to do in order to do it.  You're just less likely to miss anything the first time around.  I'd also say that it's more beneficial in the early stages than it is in the latter stages of a product.

There's a good book called Agile Modeling that strikes a good balance on how not to over do it when designing with UML so you don't end up slowing yourself down.

As for code generation, if you do class diagrams (which can be useful), generating the class stub code and declarations from them is a good way to do it.  Plenty of tools do that depending on what you decide to program in.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial

To give another opinion, UML can be considered a communication tool as well. Here i draw a parallel with engineering drawing and design used in Mechanical industries. The point is, u can write a long report on how a mechanical part should look like, the necessary dimension, shape, size and all details in english, only to find out that the engineer actually building the part misinterpreted some instructions and screwed up. Engineering Drawing, more than visualization, is a discipline, which uses standard methods and notations to indicate various aspects of design and is universally understood. So if i make a drawing down here in India and send it to US, assuming that the drawing is complete, the part made in India and the one made in US would be exactly the same.

So UML provides this functionality for the software industry. Again this is a discipline, not a code generation wizard. So if done sloppyily, does more harm than good. Using standard UML notations i can completely describe the structure of object oriented software application and these diagrams, may it be sent to any part of the planet, would result in same functionality being implemented and worked upon. The practical reasons for failure are ofcourse not enforcing the rigidity in Design, where developers, when they differ with the design, code the alternate logic for it. Now the code may work, but the design is dead. Imagine this situation in a factory where the skilled workers who might be experts in the use of certain tools, taking it up on them to modify the design as they see fit. If that happened, you wouldnt find any piece of machinery owrking today.

So then are the designers never wrong? ofcourse not. More than often we have seen many mechanical parts fail due to faulty design. The same goes with software. But by experience and knowledge of the technology and tools involved, the designers get better. And for this system to work, atleast in the IT industry, the developers must give their feedbacks about system to the archtects who would then review the design and them be iomplemented accordingly. But unless strict conformance to UML is enforced, as conformance to drawings are enforced in mechanical engineering design, its just another fancy tool to add up to the documentation done.

rfr1tzAuthor Commented:
Thanks to everyone for their comments.

Here's my conclusions - please tell me if you disagree:

1) UML is over-hyped. It's a standard methodology for things we used to do with a green IBM stencils. Basically, the "tools" are expensive, specialized drawing packages with a few enforced conventions. The conventions must work for several languages, so the conventions are mindnumbing generalizations of concepts with which most people are familiar - inheritance, for example, is not called inheritance, but rather "generalization" or maybe "aggregation".

Just browsing through my book, I spot a "Consolidated Collaboration Diagram". It's got <<coordinator>> boxes, <<state dependent control>> boxes, etc. 39 (as near as I can count) arrows often pointing in both directions - and what exactly does this monster do? I guess it's kind of like a block diagram on steriods. And the representation is obviously a subjective matter - maybe someone else would have used 45 arrows. There sure as hell is no code being generated by this "thing".

2) The use of the word "model" is a gross overstatement - unless you consider a bunch of class diagrams and some other assorted amorphous, subjective, incomplete documentation to be a model.

3) People use only a very small part of the UML functionality. Looking at the textbooks, learning even 1/2 of the "standardized" representations looks like a career. Use cases, class diagrams, activity diagrams, sequence diagrams - that's probably more than enough for the average person - and more than he really wants to handle.

4) It looks like the "code generation" is basically stub code generated from class diagrams.

5) Is there any interaction between ,say, a use case and and a sequence diagram? I say "no, there isn't" unless the reader uses his intelligence to piece the hints together. Basically, the "model" pieces aren't required to fit together, there is no right or wrong answer. Pitifully little consistency checking.

6) Bottom line is that I seriously doubt there is a payback for using this methodology (BTW, the tool I am using is $13,000 per floating license). Maybe if management makes a massive effort to get everyone on the same page of music (UML). Or you have UML "specialist" who basically does little else except draw UML diagrams. But really, how often are you going to do this kind of thing? It's way too hard to use once every 2 or 3 years. SiliconBrit mentions that they stop updating the "model" (I use the word loosely) after a short time.

It looks like this is an attempt to solve the "software design" problem, but it seems to me it is total over-kill. As I mentioned, the use cases, class diagrams, activity diagrams, and sequence diagrams look useful. The other 80-90% is some Phd's thesis.
1.  Over-hyped.  Yes, I'd say so.  Although since design is a must UML is a must since using aspects of UML like you mention (use cases, activity diagrams, sequence diagrams, class diagrams) instead of some non-standardized hen-scratching on a piece of paper is a better alternative if anyone else will have to look at and interpret your info.  It's useful and should be used but it's probably too hyped.  Much like xml and alot of new necessary but not cure-all technolgoies.

2.  You can fairly completely model most systems with UML if you put in the extra info that can be done such as use case descriptions beneath the uml diagrams and so on.  I include some other non-uml but still standard info such as data-models.

3.  Depending on what your modeling you use different components of UML.  For example UML can even be used to model mechanical movements and these would require different things than software.  Also, object oriented development would require different diagrams than non-ood as an example.

4.  I've never seen full code generation done and personally can't see how it could be done in a large scale project.  Stub code only.

5.  There is really.  If you are given all of the sequence diagrams and activity diagrams you could probably derive the use case diagrams from them.  Use cases are kind of the upper level or starting point.

6.  Well, payback is in developing right the first time.  Not in code generation or any of the techy parts of UML.  Developing right the first time comes from good design and only you will know what level of detail you need to do in order to be able to design fully and communicate those designs properly.  If you're going to do good design, you might as well use the UML equivilents to what you need to do in order to design effectively rather than doing the same type of diagrams in a non-standard way.  You probably don't have to use most diagrams.  Only the ones you think are appropriate.  It's meant as a time saver and communication aid.

Also, keep in mind that UML can be done with a pad and paper.  You don't need $13,000 tools to do the job.  Be sure that whatever extra the expensive tools are giving you, is a benefit enough to warrant the purchase.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.