rfr1tz
asked on
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?
But I doubt it.
Anyone have anything great/not-so-great to say about UML?
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
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.
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.
SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER