Need a discussion of UML/UML tools

Posted on 2004-11-15
Last Modified: 2010-04-17
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?
Question by:rfr1tz
    LVL 11

    Assisted Solution

    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.
    LVL 4

    Author Comment

    Is the concept that you can generate code from the UML model? Or is that just marketing hype?
    LVL 11

    Assisted Solution

    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.

    LVL 1

    Accepted Solution

    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.
    LVL 3

    Assisted Solution


    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.

    LVL 4

    Author Comment

    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.
    LVL 1

    Assisted Solution

    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.


    Write Comment

    Please enter a first name

    Please enter a last name

    We will never share this with anyone.

    Featured Post

    Free Trending Threat Insights Every Day

    Enhance your security with threat intelligence from the web. Get trending threat insights on hackers, exploits, and suspicious IP addresses delivered to your inbox with our free Cyber Daily.

    Suggested Solutions

    Title # Comments Views Activity
    Fix45 challenge 15 65
    hasOne  challenge 59 62
    countHi challenge 25 57
    parentbit challenge 3 36
    Whether you've completed a degree in computer sciences or you're a self-taught programmer, writing your first lines of code in the real world is always a challenge. Here are some of the most common pitfalls for new programmers.
    If you’re thinking to yourself “That description sounds a lot like two people doing the work that one could accomplish,” you’re not alone.
    In this fifth video of the Xpdf series, we discuss and demonstrate the PDFdetach utility, which is able to list and, more importantly, extract attachments that are embedded in PDF files. It does this via a command line interface, making it suitable …
    In this seventh video of the Xpdf series, we discuss and demonstrate the PDFfonts utility, which lists all the fonts used in a PDF file. It does this via a command line interface, making it suitable for use in programs, scripts, batch files — any pl…

    759 members asked questions and received personalized solutions in the past 7 days.

    Join the community of 500,000 technology professionals and ask your questions.

    Join & Ask a Question

    Need Help in Real-Time?

    Connect with top rated Experts

    11 Experts available now in Live!

    Get 1:1 Help Now