I try to produce correct UML when we have our design/whiteboarding sessions but my attempt at well structured UML ALWAYS degrades into uml-looking-but-understandable-to-those-in-the-room-with-a-little-explanation. But is this good enough for the consummate engineer? Do you always produce well-structured UML in your whiteboard sessions? What advise do you have for the developer who might not think it that important lest he sees it in a design pattern book and have no idea wtf is going on.
+3
A:
I never use UML in my design sessions. It's always free-form. Then, depending on the project, we circle back and convert that into much more structured UML design when creating the "final" spec docs that we developers will code from. It's been my experience that it tends to hinder design sessions to much to focus on proper form, especially when half or more of the people in the room have no idea what any of the diagramming means.
BBlake
2009-10-08 16:18:21
I'm lucky to get one other person understanding anything outside of a class diagram...
Jason D
2009-12-08 04:24:08
A:
Well, I really don't think you need strict UML.
As far as everybody understands the design and acknowledges it it's ok. I prefer an agile methodology to be able to prototype/test the project on the run and being able to change "non-strict" specification than having everything decided and untouchable from scratch.
In the real world you get surprises even with the most carefully planned UML specification
Marc
2009-10-08 17:11:30
I find that using UML as a guideline helps avert "big surprises" in architecture, even on small components and subsystems... However, I'm also a fan of prototype and fine tune so I do a lot of reverse engineering of code to class diagrams, then post those as a part of the spec....
Jason D
2009-12-08 04:25:55
+1
A:
You see there is a lot of debate about software engineering and whether we need it or not, the fact it depends on the kind of system you're developing. The more ambiguous the requirements of the system is, the more you need SE tools and techniques!
UML helps the client to have a picture of the internal system. This is when you have use case diagrams. It is true that some people do't get it, but it is very easy to explain specially the use-case diagram. Then you have the class diagram which helps you to grasp the first major classes and packages you need to design. Other UML digram are not that important.
Here is a simple website that helps you create class digram and use case digram in seconds online:
I never did i middle/large size project without using these two digrams
Shankarooni
2009-10-08 17:12:41