«

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?

On 7 Jan., 08:35, "vib....@gmail.com" <vib....@gmail.com> wrote:
> 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

On Jan 7, 3:35 pm, "vib....@gmail.com" <vib....@gmail.com> wrote:
> 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

Allen <> writes:

> On Jan 7, 3:35 pm, "vib....@gmail.com" <vib....@gmail.com> wrote:
>> 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?
>
> 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 Bourguignon__

"" <> writes:

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

--
__Pascal Bourguignon__

On 7 Jan, 08:16, DerTop...@web.de wrote:
> On 7 Jan., 08:35, "vib....@gmail.com" <vib....@gmail.com> wrote:
>
> > 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?
>
> 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.

Jack Klein wrote:

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

Jeff Schwab wrote:
> Matthias Buelow wrote:
>> Jack Klein wrote:
>>
>>> 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.
>
> 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.

Jeff Schwab wrote:

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

On Jan 9, 3:08 pm, Matthias Buelow <m...@incubus.de> wrote:
> Jack Klein wrote:
> > 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.

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 (GABI Software) email:
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34