Hi,

I get a lot of questions from prospective clients about UML and what
modeling tools I have experience with, which I do not. But when I ask them
if they are currently using UML? The answer is generaly "no, but that's the
direction we want go..."
Is UML have any application in real world of Software design world or is it
just an overhyped convept?

I've never worked at a place that used it - although several companies have
sent me to classes to learn it.

UML is an ideal that can't ever be reasonably reached. It takes too much
time and too much effort, by people that are expensive - to come up with a
good design. On top of that, those same people could've BUILT what they were
designing in the same or less time. And on top of THAT, many times the
technology changes during the project (which is now twice as long) - so
there are better alternatives, half-way through.

For example, imagine finishing up the design on an app in June, based on
version 1.1 of the Framework.. there are a lot of big, big changes in 2.0
that could very well change something fundamental in your design, but by
then it's too late.

So basically, to me - it's a paradox. It seems like the right thing to do,
but in order to do it - it costs you productivity, agility, money and time..


"LP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I get a lot of questions from prospective clients about UML and what
> modeling tools I have experience with, which I do not. But when I ask them
> if they are currently using UML? The answer is generaly "no, but that's
> the
> direction we want go..."
> Is UML have any application in real world of Software design world or is
> it
> just an overhyped convept?
>
>

Every place I've ever worked that talked UML was at exactly that
stage... trying to get going on it.

IMHO, UML as a notation is a great idea. I really should learn more of
it. It (finally) gives programmers a common graphic way of drawing
relationships between classes, etc. so that everyone is "speaking the
same language".

As someone who has been working in the industry for 20 years, I can
tell you that this is no small achievement.

As a development model, I think that UML is just a flash in the pan.
Every five years the industry gurus come up with "the way" to run
software projects and document what is happening. Some of it sticks,
but for the most part it's just what worked in one place for somebody
and is now earning them lots of money selling books and doing the
conference circuit.

So, my opinion: UML as a notation is brilliant. Learn it, use it. UML
as a development plan is still unproven, and probably will not survive.

I agree with you UML is a great notation for modelling almost anything, and
it is no good as a development plan. The latter because that is not what it
is intended to be.

UML is a Modelling Language not a development process.

I use it on every project, even the smallest, and in contrast to the claim
made by RCS using UML does not extend the development time of a project when
used appropriately, especially when used with an excellent tool like
Enterprise Architect from Sparx Systems.

I use UML along with MSF and every single project I have lead in the last 7
years, within this framework came in ahead of time, within budget, and well
able to cope with the rate of change in the industry, and probably more
importantly from the customers point of view at a much lower cost, because a
well designed system can be delivered by a smaller team than one designed and
built on the fly.

Mike Hanson
MCSD , MCSE+I, MCDBA, SCP

"Bruce Wood" wrote:

> Every place I've ever worked that talked UML was at exactly that
> stage... trying to get going on it.
>
> IMHO, UML as a notation is a great idea. I really should learn more of
> it. It (finally) gives programmers a common graphic way of drawing
> relationships between classes, etc. so that everyone is "speaking the
> same language".
>
> As someone who has been working in the industry for 20 years, I can
> tell you that this is no small achievement.
>
> As a development model, I think that UML is just a flash in the pan.
> Every five years the industry gurus come up with "the way" to run
> software projects and document what is happening. Some of it sticks,
> but for the most part it's just what worked in one place for somebody
> and is now earning them lots of money selling books and doing the
> conference circuit.
>
> So, my opinion: UML as a notation is brilliant. Learn it, use it. UML
> as a development plan is still unproven, and probably will not survive.
>
>

Hi,

I use Rational XDE , it's a great tool but unfortunally it seems that it
does not support .NET anymore.

Regarding the use of it in a project development I find it useful, but with
measure, the problem seems that people gets it to the extreme and try to use
it at all stages all the time.

Personally I design all the DB with it, I have been doing it this way for
over 4 or 5 years now ( using Rose before ) and I find it very easy.

When designing classes usually I juse UML as part of the documentation, not
at design time, I find more useful a simple pen and paper



cheers,

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation


"LP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I get a lot of questions from prospective clients about UML and what
> modeling tools I have experience with, which I do not. But when I ask them
> if they are currently using UML? The answer is generaly "no, but that's
> the
> direction we want go..."
> Is UML have any application in real world of Software design world or is
> it
> just an overhyped convept?
>
>

"LP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I get a lot of questions from prospective clients about UML and what
> modeling tools I have experience with, which I do not. But when I ask them
> if they are currently using UML? The answer is generaly "no, but that's
> the
> direction we want go..."
> Is UML have any application in real world of Software design world or is
> it
> just an overhyped convept?

We use UML very much at my work. But only on whiteboards for brainstorming
purposes.

Spending time documenting a couple of silly strawman and connecting them to
little eggs and call that a use case diagram is just a waste of time. =)

On a more serious sidenote. I think using RUP/UML can be very destructive
for a system development process.

Having this cool analyst/architect that overdesign a use case with class
diagrams and sequence diagrams can have serious side-effects. if you give a
complete specs to a system developer with all the little details like, -
"This class aggregates a hashtable that I have decided that you should name
list" etc etc.. can turn a competent programmer into a living typewriter.

The gumption, flow and presence is not there and that's when the bugs bite
you...

- Michael S

I think what I am hearing is this; UML can be used in real world but it
doesn't do anything "special" for you. It's just a way to represent or model
systems with bunch of neat looking shapes, lines, arows, etc. It's good that
those shapes can be interpreated by different programmers to mean the same
thing, but if those programmers can't take it any further than that, what is
the use of that? It's important to have a good desing period, but then you
need someone who can take your design and actually write code that actually
works in predictable and efficient way. And more often than not what looks
good on paper is not practical in real world. It takes a clever programmer
to work around that.



"LP" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi,
>
> I get a lot of questions from prospective clients about UML and what
> modeling tools I have experience with, which I do not. But when I ask them
> if they are currently using UML? The answer is generaly "no, but that's
the
> direction we want go..."
> Is UML have any application in real world of Software design world or is
it
> just an overhyped convept?
>
>

I agree with everything you said, but having said it, don't undervalue
"...shapes [that] can be interepreted by different programmers to mean
the same thing."

True, overdesigning a system up front can lead to problems later on.
However, misunderstandings between designers because they're each using
their own diagramming method leads to just as many problems. If I draw
an arrow and you take that to mean "aggregates", while what I really
mean was "inherits" then we're going to have some serious class
hierarchy problems.

Even if UML is good for nothing more than brainstorming on a
whiteboard, that is, as I said, a huge step forward over the (not so
old) days in which everyone had their own system of squiggles and boxes.

I believe that Michael S is at an ideal median when it comes to using
UML, specially for smaller projects. UML is most useful in
communicating ideas, exploring possible implementations, and catpuring
the bigger picture. As one moves from design to coding, every UML
diagram slowly turns into a liability.

The same goes for the breadth of the UML specification. Only 20% of the
UML notation will bring you 80% of the value. The others are just
fodder for documentation.

Not that I'm undermining the value of UML. As Bruce had said, even it's
just for brainstorming on whiteborads, it's still very useful. The
secret is knowing just how much is good enough.

"Mohammad" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>I believe that Michael S is at an ideal median when it comes to using
> UML, specially for smaller projects. UML is most useful in
> communicating ideas, exploring possible implementations, and catpuring
> the bigger picture. As one moves from design to coding, every UML
> diagram slowly turns into a liability.
>
> The same goes for the breadth of the UML specification. Only 20% of the
> UML notation will bring you 80% of the value. The others are just
> fodder for documentation.
>
> Not that I'm undermining the value of UML. As Bruce had said, even it's
> just for brainstorming on whiteborads, it's still very useful. The
> secret is knowing just how much is good enough.

Amen!