Friday, March 04, 2005

The problem with investing great amounts of time in UML, before you need to discuss a particular topic, is that there are many different views of the same system. Unless you're talking to another coder, a class diagram will not aid in discussing business logic. There are typically quite a few representations of the same system and based upon your discussion only one of those is of any use. Composing these diagrams can be highly time consuming for small projects at the risk of not completing the small project at all. For larger projects its probably impossible to diagram every aspect unless you employ the use of design recovery companies.

While excessive time to compose a correct and complete model of design does not constitute a failure of UML (dont ask me to develop and formalise such a large diagram), I do think that UML is necessary. If you cannot communicate correctly, on at least a small scale, then you're at a disadvantage. There are many diagramming methodologies of which a professional should understand and use at least one modelling system correctly. That is: the ability to use the correct diagram to quickly sketch the interactions being discussed instead of using the incorrect diagram and forcing information into the diagram.

A UML Tutorial [Link]

6 comments:

Twylite said...

Is presenting different views a weakness or a strength? It is common in spoken language to describe a misunderstood issue from another viewpoint. It stands to reason that other forms of communication should offer similar features, or else specialised dialects to ensure that misunderstandings cannot occur.

UML provides specialised dialects (diagrams) that are other views.

A Use Case captures a customer's notion of what a system should do, but not how it is done. A sequence diagram can capture the user's view of how (s)he should interact with the system to achieve a task, and can be extended to capture how system components communicate to make the task happen. A class diagram models the hierarchical relationships between classes that are mentioned in the sequence diagram.

I view the fact that you have different representations for talking to a coder versus talking to a business person as a strength, not a weakness. The two people have different communication needs, each focused on achieving their job, which the other does not understand.

I'm renovating my bathroom, so I'll use an evil construction analogy. My plans say "bath goes here, basin goes here, walls are white, use louvre windows". I don't know where the pipes run or what size drain I need. Those are part of my bathroom, but they're on the plumber's plan. So long as the shower head comes out at the right place, and the tiler covers over the pipes, I really don't care where they go. Same bathroom, different views.

Tim Twelves said...

My reservations are around 'professionals' using the incorrect dialect to put across a concept. Inevitably, information gets lost because the lack of language constructs disable the person.

A professional should be able to use those views effectively. At the same time, I dont advocate a UML-Everything. Use the correct view, as needed, whenever reasonable.

Anonymous said...

Great work!
[url=http://qeonuets.com/uwwi/oqdz.html]My homepage[/url] | [url=http://bxpwirkl.com/eejz/irvb.html]Cool site[/url]

Anonymous said...

Good design!
My homepage | Please visit

Anonymous said...

Good design!
http://qeonuets.com/uwwi/oqdz.html | http://zgxdiifa.com/fvut/uqjp.html

Anonymous said...

Good design!
http://qeonuets.com/uwwi/oqdz.html | http://zgxdiifa.com/fvut/uqjp.html