There's a clear definition of the UML structures, at least for 95+% of what
you're likely needing to do, and it is simple. The fact that people can
charge in and start using it and start communicating sooner is a good thing.
There may be some communication on improper usage of the modeling features,
but there's always going to be a learning process in whatever we do - point
is the sooner there is communication the better. That's what ultimately gets
the job done - collaboration and multiple developers/support folk agreeing
on an approach.
My point really was just that a common nomenclature is better than everyone
having their only personal drawing methodology - it saves alot of time if we
are all speaking the same language. For companies trying to make money off
developers perhaps confusion and differences are better things, but I think
there is a strong case for the opposite as well. With a common design
language as a commodity, there is then much room for money to be made in
tools to help automate software development processes... This is happening
now with UML and the model driven architecture - http://www.omg.org/mda/.
From: Simon Wright [mailto:[log in to unmask]]
Sent: Thursday, February 13, 2003 4:00 PM
To: [log in to unmask]
Cc: [log in to unmask]
Subject: Re: Designing for Ada 95?
> From: Bruce Hennessy <[log in to unmask]>
> Forget about having a pissing contest on which diagram technique to
> use; the thing with UML is that it is a global standard, hence a
> language that all developers can use to communicate design
Seems to me that the problem with UML is that it's presented so
informally that people think they can just charge in and start using
it. This doesn't lead to good communication!