«

Every time I see newfangled gizmos like "UML diagrams' (which remind
me of the old-fashioned flowcharts, NOT the best of tools, since it
leads to spaghetti code) I can't help but remember the saying:

- "Those who know, do. Those who don't manage".

I guess my question should be: Under what circumstances is advisable
to use UML?

-Ramon

On 7/19/12 1:09 PM, Ramon F. Herrera wrote:
>
> Every time I see newfangled gizmos like "UML diagrams' (which remind
> me of the old-fashioned flowcharts, NOT the best of tools, since it
> leads to spaghetti code) I can't help but remember the saying:
>
> - "Those who know, do. Those who don't manage".
>
> I guess my question should be: Under what circumstances is advisable
> to use UML?

UML has been a round for a long time. I haven't ever really been
educated in it, so I'm not sure if it adds value or not.

Ramon F Herrera wrote:
> Every time I see newfangled gizmos like "UML diagrams' (which remind

I'm sorry, "newfangled"? "gizmo"? How do either of those terms apply to UML?

> me of the old-fashioned flowcharts, NOT the best of tools, since it
> leads to spaghetti code) I can't help but remember the saying:

Au contraire, flowcharts and related tools lead to the elimination of
spaghetti code.

What is your evidence to the contrary?

My evidence in favor is my experience with good diagrams (bad ones
by definition won't help) that led to insights into how to optimize code,
better code structure for readability and maintainability, and confirmation
whether all possible input conditions were handled.

> - "Those who know, do. Those who don't manage".

Which is actually bullshit. Disempowering bullshit, at that.

> I guess my question should be: Under what circumstances is advisable
> to use UML?

When you need diagrams in a structured software-development environment,
particularly when such diagrams will be part of a permanent documentation set.

Also useful when the team is large or the time scale long, which conditions
often correlate to the need for permanent documentation sets.

--
Lew

On 2012-07-19, Daniel Pitts <> wrote:
> On 7/19/12 1:09 PM, Ramon F. Herrera wrote:
>>
>> Every time I see newfangled gizmos like "UML diagrams' (which remind
>> me of the old-fashioned flowcharts, NOT the best of tools, since it
>> leads to spaghetti code) I can't help but remember the saying:
>>
>> - "Those who know, do. Those who don't manage".
>>
>> I guess my question should be: Under what circumstances is advisable
>> to use UML?
>
> UML has been a round for a long time. I haven't ever really been
> educated in it, so I'm not sure if it adds value or not.
>

There's decent enough value in it to better understand complex systems. Being
able to read UML of different types is a good base of knowledge to have. I
definitely wouldn't use it for much beyond a better understanding of complex
systems though

On 7/19/2012 4:09 PM, Ramon F. Herrera wrote:
> Every time I see newfangled gizmos like "UML diagrams' (which remind
> me of the old-fashioned flowcharts, NOT the best of tools, since it
> leads to spaghetti code) I can't help but remember the saying:
>
> - "Those who know, do. Those who don't manage".
>
> I guess my question should be: Under what circumstances is advisable
> to use UML?

Anytime you need to do a diagram that can be done via UML.

And that would be most non-trivial software projects.

Arne

PS: UML is from 1997 so it is not new.

On 7/19/2012 5:12 PM, Daniel Pitts wrote:
> On 7/19/12 1:09 PM, Ramon F. Herrera wrote:
>> Every time I see newfangled gizmos like "UML diagrams' (which remind
>> me of the old-fashioned flowcharts, NOT the best of tools, since it
>> leads to spaghetti code) I can't help but remember the saying:
>>
>> - "Those who know, do. Those who don't manage".
>>
>> I guess my question should be: Under what circumstances is advisable
>> to use UML?
>
> UML has been a round for a long time. I haven't ever really been
> educated in it, so I'm not sure if it adds value or not.

It adds value to describe IT systems using diagrams.

It adds value to have a standard notation for such diagrams.

UML is such a standard notation.

Arne

"Ramon F. Herrera" <> wrote in news:7b5978a1-16bd-4700-
acd8-:

>
> Every time I see newfangled gizmos like "UML diagrams' (which remind
> me of the old-fashioned flowcharts, NOT the best of tools, since it
> leads to spaghetti code) I can't help but remember the saying:
>
> - "Those who know, do. Those who don't manage".
>
> I guess my question should be: Under what circumstances is advisable
> to use UML?
>
> -Ramon

It would be advisable to use a UML diagram when discussing how classes of
objects relate to each other, there is a need for a formal document, and
the group of people that will use the document understand UML diagrams.

David

On Thu, 19 Jul 2012 17:41:46 -0500, Leif Roar Moldskred
<> wrote, quoted or indirectly quoted someone who
said :

>
>When it helps you to think and reason about the system you're developing
>and when it helps to communicate information about the system to other
>people working on it.

I think the biggest problem comes with keeping it up to date. This is
extra work, but without it the diagrams are worse than useless.
--
Roedy Green Canadian Mind Products
http://mindprod.com
The greatest shortcoming of the human race is our inability to understand the exponential function.
~ Dr. Albert A. Bartlett (born: 1923-03-21 age: 89)
http://www.youtube.com/watch?v=F-QA2rkpBSY

In <> Roedy Green wrote:

> I think the biggest problem [of UML] comes with keeping it up
> to date.

The more expensive UML tools have round trip engineering which makes
keeping it up to date with code less of a hassle. My limited experience
with round trip engineering is that has its own weakness; it picks up all
minor parts of the code too, including things that are not necessarily is
important to get the main picture of the design.

Still, as others already mentioned, it is convenient to have a common
design language that is not implementation specific, and that is known by
most programmers out there. That's the strength of UML. Never mind the
fancy tools, which gets in your way, UML is first and foremost valuable
as a language to communicate design among your peers.

Myself, I mostly use class diagrams and sequence diagrams to introduce a
design to other developers. In most cases the diagrams never go further
than a whiteboard. When I have to, I use Umlet to persist them too.

--
Fredrik Jonson

On 20.07.2012 09:16, Fredrik Jonson wrote:
> In <> Roedy Green wrote:
>
>> I think the biggest problem [of UML] comes with keeping it up
>> to date.
>
> The more expensive UML tools have round trip engineering which makes
> keeping it up to date with code less of a hassle. My limited experience
> with round trip engineering is that has its own weakness; it picks up all
> minor parts of the code too, including things that are not necessarily is
> important to get the main picture of the design.

Graphical programming (what these round trip tools promise to be able to
do) does not work. The mere fact that you need to have every part of
the code in the diagram leads to diagram overload. One of the important
tasks when creating diagrams (not only UML) is to select what needs to
be shown and how it needs to be shown. This is something a human needs
to do. It cannot be automated. Normally to understand a system only a
few classes need to be depicted and not with every detail (method, data
member etc.). Updating diagrams with every changed detail is tedious
and useless because it does not improve understanding. Often the basic
relationships between classes remain the same because they are at the
heart of the design.

And btw., roundtrip tools don't help much with updating diagrams which
are sitting in text documents. That still has to be done manually -
unless someone invents a system which manages everything (code and
documentation). But then it would still need a human being to decide
whether a new sub class should show up on a particular diagram or not.

My preferred tool is Visio with the free available set of UML stencils.
This makes creating UML diagrams easy (because all the elements are
there) but retains enough flexibility to mix in other information as needed.

> Still, as others already mentioned, it is convenient to have a common
> design language that is not implementation specific, and that is known by
> most programmers out there. That's the strength of UML. Never mind the
> fancy tools, which gets in your way, UML is first and foremost valuable
> as a language to communicate design among your peers.

I couldn't agree more.

> Myself, I mostly use class diagrams and sequence diagrams to introduce a
> design to other developers. In most cases the diagrams never go further
> than a whiteboard. When I have to, I use Umlet to persist them too.

I use these diagram types in decreasing (estimated) frequency:
- class
- activity
- state
- sequence

rarely:
- object
- deployment

Kind regards

robert


--
remember.guy do |as, often| as.you_can - without end
http://blog.rubybestpractices.com/