what is the relationship between UML and C++?

[vib.cpp]

I read a post in a forum, said that one should learn some UML before
learning C++, so what is your guys' opinions? Is it necessary$B!)(BWhat
aspects in C++ may it help? And when is the best time to touch UML,
what is UML really for? Should I read some UML books when finished my
reading a primer book introducing C++, or should I wait to know more C+
+, and then to try to turn my attention to UML?

 

[DerTopper]

I read a post in a forum, said that one should learn some UML before
learning C++, so what is your guys' opinions? Is it necessary$B!)(BWhat
aspects in C++ may it help? And when is the best time to touch UML,
what is UML really for?

Maybe its time that you type "UML" into your Google search field and
hit enter. After reading for, let's say, an hour you'll probably find
a lot of answers to your questions.

Why do you think its a good idea to ask in this newsgroup? UML is off-
topic here (even though a lot of people may use it in thier
profession).

Stu

 

[Allen]

I read a post in a forum, said that one should learn some UML before
learning C++, so what is your guys' opinions? Is it necessary$B!)(BWhat
aspects in C++ may it help? And when is the best time to touch UML,
what is UML really for? Should I read some UML books when finished my
reading a primer book introducing C++, or should I wait to know more C+
+, and then to try to turn my attention to UML?

C++ is a programming language.
UML is a language? Absolute no, although it claims.
UML is just a CAD of software engineering.

Allen

 

[Pascal J. Bourguignon]

C++ is a programming language.
UML is a language? Absolute no, although it claims.
UML is just a CAD of software engineering.

Yes, UML is a language. A Modeling Language. Not a programming
language, but then, HTML is not a programming language either, and
neither English.

 

[Pascal J. Bourguignon]

I read a post in a forum, said that one should learn some UML before
learning C++, so what is your guys' opinions? Is it necessary？What
aspects in C++ may it help? And when is the best time to touch UML,
what is UML really for? Should I read some UML books when finished my
reading a primer book introducing C++, or should I wait to know more C+
+, and then to try to turn my attention to UML?

UML = Unified Modeling Language (not to be confonded with uml = user mode linix).

I think that yes, it is important to learn some OO before learning C++.

You could leanr OO modeling learning UML. In general, books by the
authors of UML are quite good to learn about OO modeling. James
Rumbaugh, Grady Booch, Ivar Jacobson. But you would be well advised
to learn also an OO programming language such as Smalltalk (Alan Kay)
or Eiffel (Bertrand Meyer) before learning C++. Then you would have
good bases in Object Oriented Programming and Modeling, and you could
make the best of C++ from an OO standpoint.

 

[gw7rib]

Why do you think its a good idea to ask in this newsgroup? UML is off-
topic here (even though a lot of people may use it in thier
profession).

He clearly mis-phrased the question slightly. What he meant to say was
"Does C++ have any features that would make the learning of UML before
the learning of C++ a good idea?", which is clearly on-topic as it
relates to the features of the language itself.

 

[Matthias Buelow]

Every 10 years or so, the bright new minds in computer science must
come up with a new graphical scheme to represent computer programs.
UML is the latest. It was not the first. It will no be the last.

My hypothesis is that there's a partition into (more) visual and (more)
grammatical people; the visual people always want to abstract
schematically in diagrams, and don't understand why grammatical people
can't see the point of that. Unfortunately (for the visualizers),
diagrams are a less expressive language than grammatical ones for
programming so it will never really catch on.

 

[Noah Roberts]

I'm no expert on UML, but I have tried to use it to communicate with
coworkers, without much success.

Probably at least partially because nobody knows the language.

It seems to have been largely

influenced by the Smalltalk-derived, runtime-heavy school of OOP that is
now so popular.

Yeah, but you can "extend" it if you need. The little <<xxxx>> guys are
meant for that. StarUML has a couple "stereotypes" already defined for
C++ use if that helps.

I find that if I've written a design in UML before coding it that I can
usually slap it out rather quickly. On the other hand, I've written it.

Some things I think could help us write better UML are:

1) experiment first.
2) be as complete as possible (people often try to shorthand uml)
3) write proof code

The reason to do the last is that it is so easy to come up with a design
that looks great in UML, but doesn't work at all in code.

Another thing you can do is get a decent tool for writing it. I'm using
StarUML right now and am pretty happy with it.

Beyond that, you have to learn it, which is really hard (it's a
complicated language), get the team to learn it...you can't just draw a
diagram and expect people to get it. Like, what's the difference
between the black diamond and the white one? Developing a subset out of
UML to use within the team might be a good idea.

Really, as was mentioned, some people are visual and some otherwise. In
a team you're going to have both and have people that are both. You
need everyone to know what the code's supposed to be doing and look
like. So you really can't get away from UML, or something like it, even
if you, personally, work better without it.

 

[Matthias Buelow]

It seems to have been largely
influenced by the Smalltalk-derived, runtime-heavy school of OOP that is
now so popular. I found the same shortcoming in the GoF Design Patterns
book, whose foreword was written by Grady Booch. Even some C++
developers, especially those who spent a long time in academia, seem now
to have the bias that static type systems are just for "checks," and do
not understand the implications re. partial evaluation, programmable
program structure (including both object layout and overload
resolution), generic programming, etc.

By the time I have some UML diagram ready, I could have run through
several redesigns in the code, when using a dynamic and expressive
highlevel language. Of course this doesn't work with something as
inflexible as C++ where every little design change amounts to hours of
numbing refactoring work. I think those who use UML (and not just
because their job imposes it on them) try to offload that design &
prototyping phase from the code onto the UML editor because the language
itself is so stiff and unwieldy. Which doesn't work either, of course.
And yes, I think static typing is useful for checking and code
optimization but a burden otherwise (that is, it should not impose any
changes on the semantics of a correct program using manifest/dynamic
typing.)

 

[James Kanze]

My hypothesis is that there's a partition into (more) visual
and (more) grammatical people; the visual people always want
to abstract schematically in diagrams, and don't understand
why grammatical people can't see the point of that.
Unfortunately (for the visualizers), diagrams are a less
expressive language than grammatical ones for programming so
it will never really catch on.

The only real problem is that just about every tool makes it an
either/or proposition. Some things are best expressed in text,
others in diagrams, and still others in various forms of
mathematical notation and pseudo-code. UML is a very useful
design tool; I don't know of a better alternative for describing
class relationships, for example. But the tools I know which
support it don't support text very well.

 

[James Kanze]

I'm no expert on UML, but I have tried to use it to
communicate with coworkers, without much success. It seems to
have been largely influenced by the Smalltalk-derived,
runtime-heavy school of OOP that is now so popular.

I've not found this at all. At least the tools I've used with
UML (Rational Rose and Together) have very strong support for
static typing.

[...]

I don't know that it's inherently inferior to "grammatical"
(textual?) programming. The languages I prefer nowadays are
all text-based, but that has a lot to do with the fact that I
can type a lot faster than I can click, and Gui-based tools
tend to make the keyboard a second-class citizen to the mouse.

That's certainly a problem. But since at the design level,
you're doing a lot less writing than reading, it's not a big
problem. And for relationships and such (and sequence diagrams,
and ...), a picture is worth a thousand words.

Text-based interfaces also tend to be much more frugal re.
network resources, so being comfortable with a text-based
interface means I get to use ssh instead of VNC, can debug my
workstation when X11 hangs, etc.

The solution there would be to debug X11 first. (I've never
seen it hang under Solaris. Or anywhere but under Linux, in
fact.) And I've noticed no big problem using ssh with graphical
interfaces---once you're logged on to the other machine, just
set DISPLAY, and you're in.

 

[James Kanze]

[...]

I've never worked on a team where code architecture was
specified by normative diagrams. The diagrams are often
present, but they are meant only to clarify the text.

I've been on at least two projects where the diagrams were
normative. The text was still present, but it was only meant to
clarify the diagrams.

Seriously: in the first case, at least, conventions were adopted
for "comments" specifying pre- and post-conventions, and tools
like Rational Rose do require a lot of text input, particularly
at the lower levels. You need both.

I dispute the claim that UML tells you "what the code's
supposed to look like," since the code itself is typically
textual, not graphical. Finally, as you pointed out, most
engineers don't know the language, because in practice, they
don't need it.

I've yet to see a well designed project that didn't use it. You
need something, and for better or worse, there doesn't seem to
be many alternatives.

 

[Default User]

James Kanze wrote:

I've yet to see a well designed project that didn't use it. You
need something, and for better or worse, there doesn't seem to
be many alternatives.

I'll confess to writing the code first, then using reverse engineering
in Rose to create the UML.




Brian

 

[Noah Roberts]

Noah Roberts wrote:

That does not follow. The need for common documents does not imply that
the documents must be visual; in particular, required reading of purely
visual documentation could be a show-stopper for blind developers, since
their hardware has much better support for text than for arbitrary
graphics. (Yes, this is a real issue, and no, I'm not blind.)

I was not implying that visual documents be the only documentation but
that you need both and therefor can't get away from one or the other.

 

[Matthias Buelow]

"I don't know how to use this tool, ergo this tool is useless."

I don't say it's completely useless -- it has some limited usability for
illustrating, like when giving a talk.

 

[Matthias Buelow]

I use static typing for a lot more than type checks, every day,
professionally. It's unfortunate that so many people are unwilling to
consider its serious use, mostly because they don't care for the syntax
of the languages that implement it. I sincerely wish you the best of luck.

Well, to each his own, I prefer a dynamic environment. What I can agree
with is that it's indispensible to use a language's syntax or expression
features and not just write simplistic and verbose stereotypical code.
Better yet if the language can be grown and modified to be a closer
match to the problem domain. That's much better than sitting a
diagrammatic language that's unspecific for the problem domain as a kind
of seperate phase in front of a simplistic implementation language (Java
perhaps being the best example for that) and having to do the extra
translation step by hand, possibly in an interative fashion. That's just
a time-wasting and frustratingly slow process.