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 <newsgroup.nospam@virtualinfinity.net> 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" <ramon@conexus.net> wrote in news:7b5978a1-16bd-4700-
acd8-b6446f5c3218@j4g2000yqf.googlegroups.com:

> 
> 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

In comp.lang.java.programmer Ramon F. Herrera <ramon@conexus.net> wrote:
> 
> I guess my question should be: Under what circumstances is advisable
> to use UML?

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.

The above might sound glib, but it really is an honest answer. The
particulars of when those conditions occurs is going to depend on you,
your coworkers, your tools, the size and complexity and domain of the
system and the organization and business culture the work's being done
in.

-- 
Leif Roar Moldskred

On Thu, 19 Jul 2012 17:41:46 -0500, Leif Roar Moldskred
<leifm@dimnakorr.com> 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 <lluh08lnc655tiu1mo4972oddebc3ciss2@4ax.com> 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

In comp.lang.java.programmer Roedy Green <see_website@mindprod.com.invalid> wrote:
> On Thu, 19 Jul 2012 17:41:46 -0500, Leif Roar Moldskred
> <leifm@dimnakorr.com> 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.

That depends what they're used _for_. Most times I use UML diagrams --
particularly UML class diagrams, which perhaps is what most developers
think of when they hear UML -- it's as part of the design process
either as a way to structure my own thoughts about the design, or to
suggest a design to other developers in order to receive feedback.

In my opinion, class diagrams doesn't have much value as long-term
documentation except sometimes to explain usage patterns for an
API. With Java in particular they're not even suitable for that as
API documentation is done with Javadoc and it doesn't have any good
support for embedding diagrams or figures.

There are other UML diagrams that _do_ have value as long-term
documentation, though. Component and deployment diagrams are useful,
and relatively static over the lifetime of a system. The various
behaviour and interaction diagrams can also be very useful long-term
documentation (I personally think UML sequence diagrams is one of the
better ways of describing a communication protocol.) Just don't feel
you _have_ to make use of them, but apply them sparingly where they're
most advantageous.

-- 
Leif Roar Moldskred

On 20.07.2012 09:16, Fredrik Jonson wrote:
> In <lluh08lnc655tiu1mo4972oddebc3ciss2@4ax.com> 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/

On Fri, 20 Jul 2012 13:39:20 +0200, Robert Klemme wrote:

> 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.
>
I've only ever seen one that did. It came out of a UK University but 
never seems to have come to anything. Its 'presentation face' mixed 
textual documentation and code fragments in a similar fashion to K&R or 
(better) Kernighan & Pike, while still keeping the ability to maintain 
the text without interfering with the code and to develop and compile the 
code without screwing up the overall look and feel of the 'presentation 
face'. I can't remember how it dealt with diagrammatic material. I 
thought it had a lot of promise though it was probably not a much higher-
level tool that Javadocs.

My main objection to all theses methodologies is that the documentation 
is usually stored and maintained separately from the code, which to me 
means that it isn't going to be maintained. As I've said before, the big 
advantage, as I see it, of Javadocs is that at least there's a good 
chance that module-level documentation will be maintained as the code 
gets modified. 

Its a pity there isn't anything similar for a system's higher level 
documentation like, for instance a combination source repository and data 
dictionary, but the nearest I've seen to a decent attempt at that was the 
long-defunct ICL Advanced Data Dictionary with its four quadrant 
structure, version control and linkages between the quadrants:

      processes          |    entities
      data and           |    attributes
      control flow       |    relationships
      ---------------------------------------
      programs           |    schemas
      pipelines          |    storage schemas
      process management |    tables

This could generate project documentation and code (both DDS and program 
source) and manage version control across an entire system.


-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

Martin Gregorie <martin@address-in-sig.invalid> writes:
>My main objection to all theses methodologies is that the documentation 
>is usually stored and maintained separately from the code, which to me 
>means that it isn't going to be maintained.

  IIRC, Doxygen generates docs from the source code and has an
  extension or an option that will also generate some UML diagrams
  from the source code.

  And then, what answer would a /professional/ give to the question
  �Do you use UML?�? I think a /professional/ answer would be:
  �Whenever I am paid (sufficiently) to do this.�

On 20.07.2012 21:38, Stefan Ram wrote:
> Martin Gregorie <martin@address-in-sig.invalid> writes:
>> My main objection to all theses methodologies is that the documentatio=
n
>> is usually stored and maintained separately from the code, which to me=

>> means that it isn't going to be maintained.
>
>    IIRC, Doxygen generates docs from the source code and has an
>    extension or an option that will also generate some UML diagrams
>    from the source code.

It has the same limitation as any other tool which generates diagrams=20
from source code: it cannot automatically add information needed for=20
proper diagram placement etc.  The point is that laying out a diagram is =

a creative task and diagrams are not just another representation of the=20
code.  A properly crafted diagram adds information to what is present in =

the code.

>    And then, what answer would a /professional/ give to the question
>    =BBDo you use UML?=AB? I think a /professional/ answer would be:
>    =BBWhenever I am paid (sufficiently) to do this.=AB

That does not sound like an answer of a software development=20
professional - it reminds me more of a professional contract killer.=20
You make it sound like doing UML diagrams was something tedious or=20
distasteful which needs additional payment for compensation. ("We're a=20
code shop only.  If you need diagrams that'll cost you extra bucks.")=20
Rather the needs of the task at hand should dictate whether a diagram is =

in order or not.

Cheers

	robert


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

On 7/20/2012 3:02 PM, Robert Klemme wrote:
> On 20.07.2012 21:38, Stefan Ram wrote:
>> Martin Gregorie <martin@address-in-sig.invalid> writes:
>>> My main objection to all theses methodologies is that the documentation
>>> is usually stored and maintained separately from the code, which to me
>>> means that it isn't going to be maintained.
>>
>>    IIRC, Doxygen generates docs from the source code and has an
>>    extension or an option that will also generate some UML diagrams
>>    from the source code.
>
> It has the same limitation as any other tool which generates diagrams
> from source code: it cannot automatically add information needed for
> proper diagram placement etc.  The point is that laying out a diagram is
> a creative task and diagrams are not just another representation of the
> code.  A properly crafted diagram adds information to what is present in
> the code.

If anything, it is more important to remove information. A diagram with
a box for each tree is not a good way of communicating the structure of
a forest.

Patricia

On Fri, 20 Jul 2012 15:22:52 -0700, Patricia Shanahan wrote:

> On 7/20/2012 3:02 PM, Robert Klemme wrote:
>> On 20.07.2012 21:38, Stefan Ram wrote:
>>> Martin Gregorie <martin@address-in-sig.invalid> writes:
>>>> My main objection to all theses methodologies is that the
>>>> documentation is usually stored and maintained separately from the
>>>> code, which to me means that it isn't going to be maintained.
>>>
>>>    IIRC, Doxygen generates docs from the source code and has an
>>>    extension or an option that will also generate some UML diagrams
>>>    from the source code.
>>
>> It has the same limitation as any other tool which generates diagrams
>> from source code: it cannot automatically add information needed for
>> proper diagram placement etc.  The point is that laying out a diagram
>> is a creative task and diagrams are not just another representation of
>> the code.  A properly crafted diagram adds information to what is
>> present in the code.
> 
> If anything, it is more important to remove information. A diagram with
> a box for each tree is not a good way of communicating the structure of
> a forest.
>

+1
 



-- 
martin@   | Martin Gregorie
gregorie. | Essex, UK
org       |

On 7/20/2012 2:29 AM, Roedy Green wrote:
> On Thu, 19 Jul 2012 17:41:46 -0500, Leif Roar Moldskred
> <leifm@dimnakorr.com> 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.

With the level of detail most often used in UML diagrams, they
should not need to be updated so often.

Arne

On 7/20/2012 7:39 AM, Robert Klemme wrote:
> On 20.07.2012 09:16, Fredrik Jonson wrote:
>> In <lluh08lnc655tiu1mo4972oddebc3ciss2@4ax.com> 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.

Completely agree.

> 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.

I think ArgoUML is pretty nice.

I has some generation and reverse generation capabilities but I consider
those more as one time tools than the real round trip tool.

>> 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

For me: class, sequence, deployment, activity, use case.

Arne

On 7/20/2012 6:22 PM, Patricia Shanahan wrote:
> If anything, it is more important to remove information. A diagram with
> a box for each tree is not a good way of communicating the structure of
> a forest.

Yes.

Someone smart once said that insight is not about collecting
information but about throwing away information.

Arne

On 07/21/2012 12:22 AM, Patricia Shanahan wrote:
> On 7/20/2012 3:02 PM, Robert Klemme wrote:
>> On 20.07.2012 21:38, Stefan Ram wrote:
>>> Martin Gregorie <martin@address-in-sig.invalid> writes:
>>>> My main objection to all theses methodologies is that the documentation
>>>> is usually stored and maintained separately from the code, which to me
>>>> means that it isn't going to be maintained.
>>>
>>>    IIRC, Doxygen generates docs from the source code and has an
>>>    extension or an option that will also generate some UML diagrams
>>>    from the source code.
>>
>> It has the same limitation as any other tool which generates diagrams
>> from source code: it cannot automatically add information needed for
>> proper diagram placement etc.  The point is that laying out a diagram is
>> a creative task and diagrams are not just another representation of the
>> code.  A properly crafted diagram adds information to what is present in
>> the code.
>
> If anything, it is more important to remove information. A diagram with
> a box for each tree is not a good way of communicating the structure of
> a forest.

Right.  It's both: adding and removing, but the point remains the same: 
this is a task which cannot be automated.

Kind regards

	robert

In article <7b5978a1-16bd-4700-acd8-b6446f5c3218
@j4g2000yqf.googlegroups.com>, ramon@conexus.net says...
> 
> 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?

I find that UML class diagrams aree very good to visualize database 
structures that are built from entity beans.

I also think that UML activity diagrams are a great way to visualize the 
broad path the user can take through an application. By "broad path", I 
mean not drawing a decision node for each "if"-statement, but rather a 
more general decision node, like:
 [Order form] --ok--> <order failed> --yes--> [Error page]
                            !--no--> [ confirm order page ]

Activity diagrams have a lot in common with flow charts, but by adding 
the object flow you have a good overview which entity or value object is 
passed between the different views (activities).

Kind regards,
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

In article <a6subnFf45U1@mid.individual.net>, shortcutter@googlemail.com 
says...

> 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.  

I have professionally worked with a framework that tries to do this, so 
I've got a bit experience in that. It works remarkably well.

What we were doing, when we were using the tool, was to model the 
database entities in detail as class diagrams, but for the activity 
diagrams we had to keep as much technical detail out of the diagrams as 
possible and abstract a lot. We described the broad business decisions 
only and coded the detail like you've been doing it all the time: In 
plain old Java. For conditionals, the framework generated a hook method 
from the diagram, which we filled with life. For each activity a view 
was generated by the framework, which we could customize using a UI-
designer and Java.

It's very convenient, as long as you don't try to squeeze everything 
into one diagram. The only drawback is that you're virtually always 
short of screen estate.

> And btw., roundtrip tools don't help much with updating diagrams which 
> are sitting in text documents.

We've not put the diagrams onto paper. All we modelled and talked about 
was stored in model-files that the system held in sync with the 
software.

Kind regards,
-Wanja-


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

In article <a6vdptF3n7U1@mid.individual.net>, shortcutter@googlemail.com 
says...

> Right.  It's both: adding and removing, but the point remains the same: 
> this is a task which cannot be automated.

Of course the user wants to make the diagram look as he likes to. That's 
why a good tool will store metadata, so the diagram generation will not 
mess up what the user has already "sorted", when (re)generating a 
diagram from the source.

Kind regards,
Wanja


-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On 21.07.2012 19:16, Wanja Gayk wrote:
> In article <a6subnFf45U1@mid.individual.net>, shortcutter@googlemail.com
> says...
>
>> 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.
>
> I have professionally worked with a framework that tries to do this, so
> I've got a bit experience in that. It works remarkably well.

I'd love to learn the name of the tool you used.

> What we were doing, when we were using the tool, was to model the
> database entities in detail as class diagrams, but for the activity
> diagrams we had to keep as much technical detail out of the diagrams as
> possible and abstract a lot.

What does that mean?  Are your activity diagrams disconnected from the 
Java code?

> We described the broad business decisions
> only and coded the detail like you've been doing it all the time: In
> plain old Java. For conditionals, the framework generated a hook method
> from the diagram, which we filled with life. For each activity a view
> was generated by the framework, which we could customize using a UI-
> designer and Java.

Do you mean view as in MVC?  What kind of application are we talking 
about here?

> It's very convenient, as long as you don't try to squeeze everything
> into one diagram.

Obviously.

> The only drawback is that you're virtually always
> short of screen estate.

:-)

>> And btw., roundtrip tools don't help much with updating diagrams which
>> are sitting in text documents.
>
> We've not put the diagrams onto paper. All we modelled and talked about
> was stored in model-files that the system held in sync with the
> software.

I wasn't specifically talking about paper.  Did you include diagrams in 
text documents (design documents) which explained the rationale of the 
design in a more reader friendly way?  If yes, how did you deal with 
updating diagrams?  If not, how did you convey the essence of the design 
to other people (new team members etc.)?

Kind regards

	robert


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

In article <a708e2Fch4U1@mid.individual.net>, shortcutter@googlemail.com 
says...

> > I have professionally worked with a framework that tries to do this, so
> > I've got a bit experience in that. It works remarkably well.
> 
> I'd love to learn the name of the tool you used.

It's a commercial application development framework called "TREND" by a 
company called "GEBIT Solutions" and I was pretty impressed! It's built 
from a series of Eclipse plugins. On their website they offer an 
analyst/requirements engineering tool, but that's barely scratching the 
surface of the rich framework that they use for creating applications 
(which can be swing client or web applications). You can build 
applications pretty fast using that stuff. Of course, as with every 
other framework in the world, you'll find things that you won't like and 
face some challenges, but it's still very impressive.

> > What we were doing, when we were using the tool, was to model the
> > database entities in detail as class diagrams, but for the activity
> > diagrams we had to keep as much technical detail out of the diagrams as
> > possible and abstract a lot.
> 
> What does that mean?  Are your activity diagrams disconnected from the 
> Java code?

There are files which are kept in sync by the framework, diagram files 
and generated Java code. The generated Java code is annotated. It's a 
round trip thing: Once generated from the model, the Java code can be 
edited, which will reflect back into the diagrams. 
So you could, for example, add some attributes to your entity class and  
you'll see them appearing in the diagram as you save, likewise you can 
alter the diagram and you'll see the change appearing in the code.
The activity diagrams are also backed by Java code.

I don't know to which extend I'm allowed to speak about all this, there 
have been non disclosure agreements that I had to sign, which I don't 
have at hand, so please forgive me if I'm not going into too much detail 
here. But they've been working on this tool chain for well over a 
decade, and that's pretty apparent when you're using it.

You'll find some valuable information on their website (German):
> http://www.gebit.de/loesungen/technische-loesungen/trend-framework-
develop/beschreibung.html


> > We described the broad business decisions
> > only and coded the detail like you've been doing it all the time: In
> > plain old Java. For conditionals, the framework generated a hook method
> > from the diagram, which we filled with life. For each activity a view
> > was generated by the framework, which we could customize using a UI-
> > designer and Java.
> 
> Do you mean view as in MVC?  What kind of application are we talking 
> about here?

Yes, it's all MVC. 
I have been working on a Swing client (very large scale) and I've seen 
them creating a JSF-Web client using the same tools. I've also seen 
something based on the Eclipse platform, not entirely sure to which 
extend they have used their modeler for that (just had a quick chat with 
the developer and other things on my mind), but I think so.

> Did you include diagrams in 
> text documents (design documents) which explained the rationale of the 
> design in a more reader friendly way? 
> If yes, how did you deal with 
> updating diagrams?  If not, how did you convey the essence of the design 
> to other people (new team members etc.)?

The RE-Tool that the framework vendor is selling allows to create design 
documents that include diagrams that are kept in sync, so an update in 
the diagram is reflected in the document. The tool also integrates with 
Eclipse and the documents as well as the diagrams can be stored in an 
SCM system. 

Here's a link (German language):
> http://www.gebit.de/loesungen/technische-loesungen/trend-analyst-
requirements/beschreibung.html <

You might like to check out their community edition, which is free of 
charge. Mind you that that tool is just for documentation purposes, if 
you're seriously interested in the complete framework you should contact 
their sales rep. Their customers are quite large companies, so I doubt 
it will be cheap, but probably valuable. 

Kind regards,
Wanja

-- 
...Alesi's problem was that the back of the car was jumping up and down 
dangerously - and I can assure you from having been teammate to 
Jean Alesi and knowing what kind of cars that he can pull up with, 
when Jean Alesi says that a car is dangerous - it is. [Jonathan Palmer]

--- Posted via news://freenews.netfront.net/ - Complaints to news@netfront.net ---

On Sat, 21 Jul 2012 00:02:08 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

[snip]

>>    And then, what answer would a /professional/ give to the question
>>    �Do you use UML?�? I think a /professional/ answer would be:
>>    �Whenever I am paid (sufficiently) to do this.�
>
>That does not sound like an answer of a software development 
>professional - it reminds me more of a professional contract killer. 
>You make it sound like doing UML diagrams was something tedious or 
>distasteful which needs additional payment for compensation. ("We're a 
>code shop only.  If you need diagrams that'll cost you extra bucks.") 
>Rather the needs of the task at hand should dictate whether a diagram is 
>in order or not.

     I have not found formal diagramming to be very useful.  I had to
document using UML diagrams in some of my uni courses.  I generally
did them *after* I wrote the code.  Creating them required a bunch of
fiddling to make them come out clear.  They were a time sink and did
not add anything to my understanding of the system.

     OTOH, in-line code documentation I wrote as I coded.  That stuff
was useful.

     User documentation was stright-forward typing.  I did that after
coding using bits of code as needed.

     I can understand someone not wanting to do things that do not
help do the job.  Avoid needless work.

Sincerely,

Gene Wirchenko

On 7/22/2012 10:26 PM, Gene Wirchenko wrote:
> On Sat, 21 Jul 2012 00:02:08 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>>>     And then, what answer would a /professional/ give to the question
>>>     �Do you use UML?�? I think a /professional/ answer would be:
>>>     �Whenever I am paid (sufficiently) to do this.�
>>
>> That does not sound like an answer of a software development
>> professional - it reminds me more of a professional contract killer.
>> You make it sound like doing UML diagrams was something tedious or
>> distasteful which needs additional payment for compensation. ("We're a
>> code shop only.  If you need diagrams that'll cost you extra bucks.")
>> Rather the needs of the task at hand should dictate whether a diagram is
>> in order or not.
>
>       I have not found formal diagramming to be very useful.

That is not surprising given the below.

>                                                             I had to
> document using UML diagrams in some of my uni courses.  I generally
> did them *after* I wrote the code.

Which is wrong.

>                                    Creating them required a bunch of
> fiddling to make them come out clear.

Most good things require some work.

>                                       They were a time sink and did
> not add anything to my understanding of the system.

Maybe.

But given that the purpose of the UML is to give other a better
understanding of the system not so relevant.

>       I can understand someone not wanting to do things that do not
> help do the job.  Avoid needless work.

But before concluding about whether it helps or are useless it is
necessary to understand why and how it is done.

Arne

On 23.07.2012 04:52, Arne Vajh=F8j wrote:
> On 7/22/2012 10:26 PM, Gene Wirchenko wrote:

>> document using UML diagrams in some of my uni courses.  I generally
>> did them *after* I wrote the code.
>
> Which is wrong.

Not necessarily.  As long as it's finished before someone else needs to=20
work with the code. :-)

>>                                       They were a time sink and did
>> not add anything to my understanding of the system.
>
> Maybe.
>
> But given that the purpose of the UML is to give other a better
> understanding of the system not so relevant.

+1

>>       I can understand someone not wanting to do things that do not
>> help do the job.  Avoid needless work.
>
> But before concluding about whether it helps or are useless it is
> necessary to understand why and how it is done.

Exactly.  Gene makes it sound as if the whole purpose of putting UML=20
diagrams was the benefit of the *writer*.  I rather think the writer can =

make good use of UML on a whiteboard or piece of paper during design=20
phase.  UML in documents is there to help *readers* better understand a=20
design.

<rant>I have seen quite a lot of documents apparently written with the=20
writer in mind instead of the reader ("brain dump").  That attitude=20
seems to be fairly common.  This is unfortunate since it limits=20
usefulness of documents a lot.

Unfortunately that seems to be true for code as well: there seems to be=20
a tendency to just make things work without consideration of ease of=20
use.  That is mostly determined by API and not internals.  Programmers=20
(on average) seem to be more concerned with internal workings of their=20
classes than with the public visible and usable API.</rant>

Kind regards

	robert

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

On Mon, 23 Jul 2012 09:17:09 +0200, Robert Klemme
<shortcutter@googlemail.com> wrote:

>On 23.07.2012 04:52, Arne Vajh�j wrote:
>> On 7/22/2012 10:26 PM, Gene Wirchenko wrote:
>
>>> document using UML diagrams in some of my uni courses.  I generally
>>> did them *after* I wrote the code.
>>
>> Which is wrong.
>
>Not necessarily.  As long as it's finished before someone else needs to 
>work with the code. :-)

     Yes.

     And, UML did not do me any good.  UML did not help me design my
systems.  Indeed, all of the fiddling about with the editor was
distracting.

     There is a lot to be said for simply putting pen to ink.  It is
quick, and it is amenable to change.

>>>                                       They were a time sink and did
>>> not add anything to my understanding of the system.
>>
>> Maybe.

     No, definitely the case.  It is much slower to use a UML editor
than simply sketching.

>> But given that the purpose of the UML is to give other a better
>> understanding of the system not so relevant.
>
>+1

     UML is hardly the only way to do so.

     Have you ever used a sketch map?  A good sketch can be very
useful and very quickly made.

>>>       I can understand someone not wanting to do things that do not
>>> help do the job.  Avoid needless work.
>>
>> But before concluding about whether it helps or are useless it is
>> necessary to understand why and how it is done.
>
>Exactly.  Gene makes it sound as if the whole purpose of putting UML 
>diagrams was the benefit of the *writer*.  I rather think the writer can 
>make good use of UML on a whiteboard or piece of paper during design 
>phase.  UML in documents is there to help *readers* better understand a 
>design.

     That is about it.  Now, why can't the reader read the sketch?
Even if I have to redraw the sketch to neaten it up, that is almost
certainly faster than entering the data with a UML editor.

     My big complaint with UML is that the tools to enter it are
awkward and slow to use.  I prefer to avoid such tools.

     My secondary one is that it tries to force-fit things into its
diagram types.

><rant>I have seen quite a lot of documents apparently written with the 
>writer in mind instead of the reader ("brain dump").  That attitude 
>seems to be fairly common.  This is unfortunate since it limits 
>usefulness of documents a lot.
>
>Unfortunately that seems to be true for code as well: there seems to be 
>a tendency to just make things work without consideration of ease of 
>use.  That is mostly determined by API and not internals.  Programmers 
>(on average) seem to be more concerned with internal workings of their 
>classes than with the public visible and usable API.</rant>

     What rant?

     I think that one of the biggest things holding us back is lack of
proper documentation.

     I have been trying to find out how to communicate from browser to
SQL Server in a secure way and without using ActiveX.  I finally gave
up.  Sure, you can find someone pushing a solution but typically
without useful details so that you can make go yourself.

     Before that, it was learning JavaScript.  I ran into the case of
most books covering the basics and then stopping.  The next step just
is not there.

     If you want an example of imitation documentation, look at the
official documentation for Java.  It has about one-third of what it
should.  Were I grading it, it would get a solid D.

Sincerely,

Gene Wirchenko

On 7/23/2012 10:03 AM, Gene Wirchenko wrote:

>       And, UML did not do me any good.  UML did not help me design my
> systems.  Indeed, all of the fiddling about with the editor was
> distracting.
>
>       There is a lot to be said for simply putting pen to ink.  It is
> quick, and it is amenable to change.

>
>       Have you ever used a sketch map?  A good sketch can be very
> useful and very quickly made.


Interesting.  And I think you make some very valid points.  However, 
perhaps it was merely that your tool was bad?


http://yuml.me/

On 23.07.2012 19:03, Gene Wirchenko wrote:
> On Mon, 23 Jul 2012 09:17:09 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:

>       And, UML did not do me any good.  UML did not help me design my
> systems.  Indeed, all of the fiddling about with the editor was
> distracting.
>
>       There is a lot to be said for simply putting pen to ink.  It is
> quick, and it is amenable to change.

Then why did you try to use an electronic tool?  I use diagramming tools 
(I did mention Visio, did I?) only for creating diagrams for documents. 
  And it is quite fast at that.  A tool that does not get in your way. 
When designing it's UML on whiteboard or paper.

>>> But given that the purpose of the UML is to give other a better
>>> understanding of the system not so relevant.
>>
>> +1
>
>       UML is hardly the only way to do so.

No, certainly not.  I don't think anybody claimed that so far.  UML does 
have an advantage of being widely known and covering many important 
aspects of software engineering.

>       Have you ever used a sketch map?  A good sketch can be very
> useful and very quickly made.

Is this some kind of specific tool or do you mean a sketch map?  I am 
asking because nowadays this sounds like it could be a tool's name.  I 
am sketching all the time - and also likely violating strict UML while 
doing so. :-)

>       That is about it.  Now, why can't the reader read the sketch?
> Even if I have to redraw the sketch to neaten it up, that is almost
> certainly faster than entering the data with a UML editor.

That depends on the UML tool.

>       My big complaint with UML is that the tools to enter it are
> awkward and slow to use.  I prefer to avoid such tools.

Understandably.  But I'd say there are tools which do not suffer from 
this.  (MagicDraw is certainly *not* one of them.)

>       My secondary one is that it tries to force-fit things into its
> diagram types.

That's why I prefer a drawing tool over an UML modeling tool any time.

>> <rant>I have seen quite a lot of documents apparently written with the
>> writer in mind instead of the reader ("brain dump").  That attitude
>> seems to be fairly common.  This is unfortunate since it limits
>> usefulness of documents a lot.
>>
>> Unfortunately that seems to be true for code as well: there seems to be
>> a tendency to just make things work without consideration of ease of
>> use.  That is mostly determined by API and not internals.  Programmers
>> (on average) seem to be more concerned with internal workings of their
>> classes than with the public visible and usable API.</rant>
>
>       What rant?

Oh, isn't it ranty enough? ;-)  I can write a version with explicit 
language - but that won't go public. :-)

>       I think that one of the biggest things holding us back is lack of
> proper documentation.

Absolutely true!

>       If you want an example of imitation documentation, look at the
> official documentation for Java.  It has about one-third of what it
> should.  Were I grading it, it would get a solid D.

Hmmm.  I can't say I was really lacking that much.  In which areas do 
you see deficiencies?  Or: what would you add?

Kind regards

	robert


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

On 7/23/2012 3:17 AM, Robert Klemme wrote:
> On 23.07.2012 04:52, Arne Vajh�j wrote:
>> On 7/22/2012 10:26 PM, Gene Wirchenko wrote:
>
>>> document using UML diagrams in some of my uni courses.  I generally
>>> did them *after* I wrote the code.
>>
>> Which is wrong.
>
> Not necessarily.  As long as it's finished before someone else needs to
> work with the code. :-)

Just like writing unit tests before implementation reduces the risk
of unit tests expecting wrong behavior to match wrong code, then
writing the UML before implementation reduces the risk of of
UML design being influenced by bad implementation.

Of course both should be updated if the implementation is changed for 
good reasons.

>>>                                       They were a time sink and did
>>> not add anything to my understanding of the system.
>>
>> Maybe.
>>
>> But given that the purpose of the UML is to give other a better
>> understanding of the system not so relevant.
>
> +1
>
>>>       I can understand someone not wanting to do things that do not
>>> help do the job.  Avoid needless work.
>>
>> But before concluding about whether it helps or are useless it is
>> necessary to understand why and how it is done.
>
> Exactly.  Gene makes it sound as if the whole purpose of putting UML
> diagrams was the benefit of the *writer*.  I rather think the writer can
> make good use of UML on a whiteboard or piece of paper during design
> phase.  UML in documents is there to help *readers* better understand a
> design.

Yes.

Arne

On 7/23/2012 1:03 PM, Gene Wirchenko wrote:
> On Mon, 23 Jul 2012 09:17:09 +0200, Robert Klemme
> <shortcutter@googlemail.com> wrote:
>
>> On 23.07.2012 04:52, Arne Vajh�j wrote:
>>> On 7/22/2012 10:26 PM, Gene Wirchenko wrote:
>>
>>>> document using UML diagrams in some of my uni courses.  I generally
>>>> did them *after* I wrote the code.
>>>
>>> Which is wrong.
>>
>> Not necessarily.  As long as it's finished before someone else needs to
>> work with the code. :-)
>
>       Yes.
>
>       And, UML did not do me any good.  UML did not help me design my
> systems.  Indeed, all of the fiddling about with the editor was
> distracting.
>
>       There is a lot to be said for simply putting pen to ink.  It is
> quick, and it is amenable to change.
>
>>>>                                        They were a time sink and did
>>>> not add anything to my understanding of the system.
>>>
>>> Maybe.
>
>       No, definitely the case.  It is much slower to use a UML editor
> than simply sketching.
>
>>> But given that the purpose of the UML is to give other a better
>>> understanding of the system not so relevant.
>>
>> +1
>
>       UML is hardly the only way to do so.
>
>       Have you ever used a sketch map?  A good sketch can be very
> useful and very quickly made.

You seem to be confusing the notation and the media.

You can use whiteboard or paper for UML. In fact that is rather
common as well.

If you need to put it in a word document or in a web page, then
using a tool instead of something handwritten makes it look a bit
more professional.

>>>>        I can understand someone not wanting to do things that do not
>>>> help do the job.  Avoid needless work.
>>>
>>> But before concluding about whether it helps or are useless it is
>>> necessary to understand why and how it is done.
>>
>> Exactly.  Gene makes it sound as if the whole purpose of putting UML
>> diagrams was the benefit of the *writer*.  I rather think the writer can
>> make good use of UML on a whiteboard or piece of paper during design
>> phase.  UML in documents is there to help *readers* better understand a
>> design.
>
>       That is about it.  Now, why can't the reader read the sketch?
> Even if I have to redraw the sketch to neaten it up, that is almost
> certainly faster than entering the data with a UML editor.
>
>       My big complaint with UML is that the tools to enter it are
> awkward and slow to use.  I prefer to avoid such tools.

Pick another tool.

>       My secondary one is that it tries to force-fit things into its
> diagram types.

You can invent your own language, but you communicate more
efficiently by using a language that other understand.

UML is by far the most widely used notation today. Making it
the best for communication with other.


>> <rant>I have seen quite a lot of documents apparently written with the
>> writer in mind instead of the reader ("brain dump").  That attitude
>> seems to be fairly common.  This is unfortunate since it limits
>> usefulness of documents a lot.
>>
>> Unfortunately that seems to be true for code as well: there seems to be
>> a tendency to just make things work without consideration of ease of
>> use.  That is mostly determined by API and not internals.  Programmers
>> (on average) seem to be more concerned with internal workings of their
>> classes than with the public visible and usable API.</rant>
>
>       What rant?

His own.

Check up on XML syntax.

>       If you want an example of imitation documentation, look at the
> official documentation for Java.  It has about one-third of what it
> should.  Were I grading it, it would get a solid D.

With your skills in software engineering I suspect that is a good thing.

Arne

On Friday, July 20, 2012 1:39:16 AM UTC+5:30, 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?
> 
> 
> 
> -Ramon