Is UML Class diagrams that great?

Question

So i have been on a couple research projects with a teacher of mine and he LOVES UML class diagrams. After using them to build a VERY complex data structure kept in a database (representing a graph that can change based on the physics of a real world problem)

I found that UML is not to great to use beyond just initial stages. I found that with 5 people, multidisciplinary, that the UML would get built. Then when the programming starts, the UML would have to be changed. Over and over and over and over... Then what happened would that the UML would lag beyond the projects progress due to demands and then the worse thing that could happened happens... Stale comments.

Do other people feel the same way? Is there a better tool? With my next project i have decided to go a different route. Define a FLOW diagram of all the different user interactions. Then the program is programmed as the flow diagrams dictate rather than the structure of a UML diagram. I have found that i do not have to change the structure of either one and new comers understand the program quicker.

Is this a good approach as the program grows above 30k lines of code? 50k? 100k?

In UML defense i will say this. That building a program in UML will allow you to spot Design patterns quicker. Which is very nice.

Does anyone have any input?

Answer 1

The class diagram is absolutely magic if you use it with Java language. I am able to model, to generate code, change my code, refactor it merge it again with UML etc..; Never a problem, always a perfect updated documentation. For database creation I use java annotations with hibernate which has been created from my class diagram.

Really coooool !!!

Answer 2

I personally feel UML class diagrams are best suited for low level design. It is better to keep the high level design details abstract...

really found this answer UML Diagrams - Discussion pretty nice.

Answer 3

Many developers think that making a design / model, in UML or other, will stay. Changing a diagram its very frecuent. Some developers skip updating the diagram, after the initial versions, due to time & resources restrictions.

My suggestion is that you should get used to the idea, that crafting a Software App. is complex, and its going to change very frecuently, not like a building where, architects make their UML ("blueprint"), and once the program ("building") its designed based in that UML, it going to stay that way.

Working with several incremental prototype versions, both for Modeling and programming, instead on thinking for a single complex app., could work for your software team.

And to be honest, buildings and their blueprints, changes also, maybe not as frecuent as a Software Applications, but, they do.

Answer 4

Michael,

Your teacher seems to death by UML Fever ( Article Link ):-)

Many people has "wrong" understanding about UML.(What is it and what it is NOT)

The UML is simply a standard diagramming notationboxes, lines, etc . Visual modeling with a common notation can be a great aid, but it is hardly as important as knowing how to design and think in objects. Such design knowledge is a very different and more important skill, and is not mastered by learning UML notation or using a CASE or MDA tool. A person not having good OO design and programming skills who draws UML is just drawing bad designs. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition By Craig Larman [ 1.6. What is the UML?] )

And also has "miss-understanding" about drawing UML diagrams ( when to draw a diagram and who will draw it)

Useful UML is sketched by deeply experienced OO programmers (ideally in pairs at whiteboards) as an aid to creative thought and communication before they themselves use their own sketches * as inspiration * during programming. ... What is important is being able to create good object designs and programs—the art of OOA/D. When the rubber hits the road and code needs to be cut, what matters is our ability to assign responsibilities and create a design with low coupling, high cohesion, comprehensibility, and ease of modification. That''s very different than knowing a diagramming notation such as the UML.( Craig Larman, What UML Is and Isn't Article Link )

And many people think that UML has just one diagram:(or just one usefull diagram) which is Class Diagram . That is also wrong.

The name of paradigm is Object-Oriented Modeling/Design/Programing/. Not Class-oriented ... Class diagrams just show static relationship between your classes.You can not understand a truely object oriented system but just looking its "static" structure.

An object-oriented program's run-time structure often bears little resemblance to its code structure . The code structure is frozen at compile-time; it consists of classes in fixed inheritance relationships. A program's run-time structure consists of rapidly changing networks of communicating objects. In fact, the two structures are largely independent. Trying to understand one from the other is like trying to understand the dynamism of living ecosystems from the static taxonomy of plants and animals, and vice versa. [Design Patterns,Elements of Reusable Object-Oriented Software by by Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides [Relating Run-Time and Compile-Time Structures]

So to explore those interactions using Sequence or Communication digrams can be also usefull.

As a rule:(so simple so forgotten rule)

If you are drawing a diagram, you should have a good reason: Why you do this? If you do not have a concrete answer( the answer must show real benefit), do not draw anything. Modeling is not a documentation activity. And eat your own dog's food. Draw for yourself, not for others.