Do C++ and Java professionals use UML??

[Arne Vajhøj]

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

 

[Robert Klemme]

On 7/22/2012 10:26 PM, Gene Wirchenko wrote:

Which is wrong.

Not necessarily. As long as it's finished before someone else needs to
work with the code.

Maybe.

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


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.

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

Kind regards

robert

 

[Gene Wirchenko]

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.

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

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

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

 

[markspace]

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/

 

[Gene Wirchenko]

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

Well, any such tool is going to be more fiddly than just
sketching. I understand that. I do not know that other tools would
be any easier IN THE GENERAL CASE. That stated ...

http://yuml.me/

I tried their Web demo. Leaving aside no documentation, I did
fudge a simple diagram. The demo works for the basics. That it
appears to give reasonable output is to the good. If it had to be
adjusted, would it be difficult?

My concern would be it fitting on a page; a lot of my UML tool
fiddling had to do with that and keeping alignment, and I was forced
to do this. If a tool does this for me, then it would be good enough
for most use. My priorities are roughly:
1) Is it readable, clear, and neat?
2) Is it pretty?
3) Can the output be tweaked?

For my own use, I would usually not bother, but on a large
project, this might do the trick.

I suppose that I have been bitten badly on these high-end design
tools. One (PowerDesigner?) generates some code, but to specify
parameters for methods, one has to drill down two levels. Since the
documentation is badly fragmented, this was not a good tool to get a
quick first product with. I understand that it is also rather
expen$ive.

I hope there are better tools out there.

Sincerely,

Gene Wirchenko

 

[Robert Klemme]

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.

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.

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

 

[Arne Vajhøj]

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.

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

 

[Arne Vajhøj]

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.


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


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.

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.

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

 

[Gene Wirchenko]

On 7/23/2012 1:03 PM, Gene Wirchenko wrote:
[snip]

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.

How cute.

How on earth does someone learn about a system when the
documentation is so inadequate?

Sincerely,

Gene Wirchenko

 

[Arne Vajhøj]

On 7/23/2012 1:03 PM, Gene Wirchenko wrote:
[snip]

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.

How cute.

How on earth does someone learn about a system when the
documentation is so inadequate?

Millions have managed to do so.

It is even seen that Java documentation is praised over
the documentation for other languages.

Arne

 

[R kamalakkannan]

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