Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Groups keyboard shortcuts have been updated
Dismiss
See shortcuts

UML Too Difficult for the Average Developer to Learn?

26 views
Skip to first unread message

Skipjack Software

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
I have been trying to use UML on our latest project, but have found that
getting people to use and understand it is a very daunting task. One thing
that I will agree with them on is that UML is too difficult for the average
developer to learn on-the-job (i.e., most developers are unwilling to set
aside ten to twenty hours a week of their free time, after putting in fifty
to sixty hour weeks, to learn an overly complex modeling technique.) Unlike
logic-charting, data-flow-diagramming, and entity-relationship-diagramming,
UML cannot be mastered with a month of practice. I hate to say it, but its
complexity will be its downfall. Unless someone comes up with a simplified
version of the UML (anyone up to designing a KISS-ML?,) I believe it will be
replaced by yet another modeling technique.

Mark

Erik Funkenbusch

unread,
May 17, 1999, 3:00:00 AM5/17/99
to
Your problem is that you're expecting the developers to learn this on their
own. That's not their job. Their job is to do what they were hired to do.
It's in their best interest to stay abreast of new technologies and learn
new methods, but it's not a requirement for them to do the job they were
hired to do.

What you need to do is MAKE it part of their job. Get managment to allocate
time to learning and training. If they won't, your acceptance of new
methods will be slim at best.

Skipjack Software <m...@skipjacksoftware.com> wrote in message
news:7hq0q4$n27$1...@autumn.news.rcn.net...

David B Lightstone

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
I don't know how to state this diplomatically, but the complexity in UML
is not in my opinion acceptable. It reminds me very much of a programming
language developed by a committee of experts. (Everyone's pet software
development brainstorm, the best theoretical results and a little
glue to hold it together. )

Perhaps I am being a bit pessimistic, but I suspect that a serious
(rather than a toy, academic proof of concept project) project using
UML has yet to be completed.

Do any of the gurus who read this thread know of a serious project that has
been completed (i.e. delivered to the customer) and has its requirements
documented (in retrospect) using UML? (I state documented in retrospect,
rather than initially, as it is a weaker success criteria than initially
developed
using UML)

The absence of such a project would, in my humble, opinion transform
Mr. Funkenbusch's advise - to MAKE it part of their job, into a disingenuous
effort to cajole others into participating in the development of another
firms
product, expecting little or nothing in return for the professional and
political
assistance.


Erik Funkenbusch wrote in message ...

Petronius Arbiter

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
In article <Jy203.4864$5g.1...@news.cwix.com>, "David B Lightstone" <david.li...@cwixMail.com> wrote:
>I don't know how to state this diplomatically, but the complexity in UML
>is not in my opinion acceptable. It reminds me very much of a programming
>language developed by a committee of experts. (Everyone's pet software
>development brainstorm, the best theoretical results and a little
>glue to hold it together. )
encore.....

Having been doing OO for over a decade, IMHO the only people getting any
benefit out of UML are UML consultants, UML authors, and UML tool makers.

UML does not provide the information needs to build a system and UML is not a
useful tool for designing a system. IMHO, a text-oriented design system is
more useful than UMLs bewildering pictures.

John - N8086N
Big brother is watching. Disable cookies in your web browser.
-------------------------------------------
Wise man says "Never use a bank with the initials F. U."
-------------------------------------------
Are you interested in a professional society or
guild for programmers? Want to fight section 1706?


See www.programmersguild.org
Newsgroup: us.issues.occupations.computer-programmers


EMail Address:
_m-i-a-n-o_@_c_o_l_o_s_s_e_u_m_b_u_i_l_d_e_r_s._c_o_m_


Michael Schuerig

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
Petronius Arbiter <end...@yahoo.com> wrote:

> UML does not provide the information needs to build a system and UML is not a
> useful tool for designing a system. IMHO, a text-oriented design system is
> more useful than UMLs bewildering pictures.

Would you mind to be more specific? What exactly is missing? And why is
UML not useful?

Michael

--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/

Erik Funkenbusch

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
David B Lightstone <david.li...@cwixMail.com> wrote in message
news:Jy203.4864$5g.1...@news.cwix.com...

> I don't know how to state this diplomatically, but the complexity in UML
> is not in my opinion acceptable. It reminds me very much of a programming
> language developed by a committee of experts. (Everyone's pet software
> development brainstorm, the best theoretical results and a little
> glue to hold it together. )

While it's true that the UML was developed as bits and pieces of different
methods and this is sometimes painfully obvious, the fact remains that the
UML is essentially the "best" of several widely accepted notations.

Many projects have been built over the last 10 years using Booch, OMT, and
Objectory. Try not to confuse the notation with the method. The notation
is designed to be a method independant (although it was certainly designed
with one method in mind).

> Perhaps I am being a bit pessimistic, but I suspect that a serious
> (rather than a toy, academic proof of concept project) project using
> UML has yet to be completed.

Well, considering that the UML was only finalized a little over a year ago,
it's doubtful that any long term projects that were started with the UML
have been completed yet. But given that the UML is essentially a redesigned
Booch, OMT and Objectory Notation, it can easily be said that many projects
have been successfully built using the parents of the UML's notation.
There's a good book called Clouds to Code by Jesse Liberty which walks you
through a semi-serious application from start to end in the UML.

> Do any of the gurus who read this thread know of a serious project that
has
> been completed (i.e. delivered to the customer) and has its requirements
> documented (in retrospect) using UML? (I state documented in retrospect,
> rather than initially, as it is a weaker success criteria than initially
> developed
> using UML)

Few companies want to detail and publicly document their projects. I think
it might be difficult to find a publicly available source of documentation
on this for a few more years (until large scale projects have been completed
that started with the UML).

Why would a team go back and change it's documentation method after the
fact?

> The absence of such a project would, in my humble, opinion transform
> Mr. Funkenbusch's advise - to MAKE it part of their job, into a
disingenuous
> effort to cajole others into participating in the development of another
> firms product, expecting little or nothing in return for the professional
and
> political assistance.

I'm not sure if I would categorize the UML as a "product" of one firm.
While it was indeed developed by one firm, dozens of other companies had
input into it's finalized and standardized version (since it *IS* an OMG
standard now). It's also no longer under the control of Rational (although
clearly the three amigo's are still very influential) having had it's
working progress co-opted by the OMG.

When you speak of cajoling others, it almost seems as if you think that
individual developers in a company should be allowed to develop software
however they see fit. As if company standards, ISO 900x standardization or
CMM level repeatability is not a worthy goal. I hope that's not what you
were trying to say.

Sinan Si Alhir

unread,
May 18, 1999, 3:00:00 AM5/18/99
to Skipjack Software
Dear Skipjack Software (m...@skipjacksoftware.com) and
comp.software-eng/comp.object:

> Unlike
> logic-charting, data-flow-diagramming, and entity-relationship-diagramming,
> UML cannot be mastered with a month of practice. I hate to say it, but its
> complexity will be its downfall. Unless someone comes up with a simplified
> version of the UML (anyone up to designing a KISS-ML?,) I believe it will be
> replaced by yet another modeling technique.

Consider the Core Modeling Language (CML)...

The following papers (among others at http://home.earthlink.net/~salhir) may be
of interest to you:

* Extending the Unified Modeling Language (UML)
(http://home.earthlink.net/~salhir/#extendingtheuml)
This paper elaborates on extending the UML and explores the necessity,
sufficiency, and consistency of the UML’s extension mechanisms to conclude that
there are *inconsistencies* with the UML’s extension mechanisms.

* "Unified Modeling Language Extension Mechanisms"
[Distributed Computing magazine, December 1998]
(http://home.earthlink.net/~salhir/#umlextensionmechanisms)
This paper elaborates on the UML to conclude that there may be a need for a
Core Modeling Language (CML).

* "The Unified Modeling Language (UML) - One Year After Adoption of the
Standard"
(http://home.earthlink.net/~salhir/#theumloneyearafteradoptionofthestandard)
This paper is a reflection on the past, present, and future of the UML one
year after adoption of the standard to conclude that the goals and scope of the
UML are not fully realized by the language.

These papers are available at http://home.earthlink.net/~salhir.

I welcome your comments.

Thank you.

Sincerely,
Sinan Si Alhir
Email: mailto:sal...@earthlink.net
WWW: http://home.earthlink.net/~salhir

--- --- ---
Comments and Feedback regarding "UML in a Nutshell":

* "Advanced UML; for a limited audience" - "When in the field using UML, I have
my notes from Booch's User Guide, and a copy of this book." - Portland, Oregon,
April 5, 1999 (Amazon.com)
* "This was the most edifying text I had read since Catalysis. ... It was as
satisfying to read as Coplien’s ‘Advanced C++’ book." - Catalyzers Read...,
April 2, 1999 (Catalysis.org - Research Discussion Forum)
* "The writer uses bulleted paragraphs throughout the book - that is well
suited to a quick reference guide. The inclusion of mini and many diagrams
makes comprehension even better." - Education & Training Academy, March/April
Reviews, 1999 (ETA Reviews)
* "Rare UML expertise is available here!" - "This is a concise, extremely well
thought out REFERENCE work, allowing the reader access to the most subtle and
powerful aspects of this sophisticated modelling language." - United Kingdom,
February 21, 1999 (Amazon.com)
* "This is a serviceable reference for those using UML." - Robert M. Slade,
1998 (Rob Slade’s Computer and Technical Book Reviews)
--- --- ---

Rjbotting

unread,
May 18, 1999, 3:00:00 AM5/18/99
to
David B Lightstone wrote

>I don't know how to state this diplomatically, but the complexity in UML
>is not in my opinion acceptable. It reminds me very much of a programming
>language developed by a committee of experts. (Everyone's pet software
>development brainstorm, the best theoretical results and a little
>glue to hold it togethe

Yes.... and this means you can grab just a piece of it
at a time and use it. As a rule I prefer incremental
changes to a complex process rather than a big bang.

Especialy if other techniques are already in place which
have a totally different perspective on things.
Richard Botting, CSUSB or DocDick@home

Ken Foskey

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Rjbotting wrote:
>
>
> Yes.... and this means you can grab just a piece of it
> at a time and use it. As a rule I prefer incremental
> changes to a complex process rather than a big bang.
>
> Especialy if other techniques are already in place which
> have a totally different perspective on things.
> Richard Botting, CSUSB or DocDick@home

I agree with this I am using Use cases on a Cobol Mainframe
development. It is not limited to OO designs!

Kurt Luoto

unread,
May 19, 1999, 3:00:00 AM5/19/99
to

Rjbotting wrote in message <19990518103506...@ng-fr1.aol.com>...

>David B Lightstone wrote
>>I don't know how to state this diplomatically, but the complexity in UML
>>is not in my opinion acceptable. It reminds me very much of a programming
>>language developed by a committee of experts. (Everyone's pet software
>>development brainstorm, the best theoretical results and a little
>>glue to hold it togethe
>
>Yes.... and this means you can grab just a piece of it
>at a time and use it. As a rule I prefer incremental
>changes to a complex process rather than a big bang.
>
>Especialy if other techniques are already in place which
>have a totally different perspective on things.
>Richard Botting, CSUSB or DocDick@home


I am anticipating starting a new project within the next year, with a new
company, new team, and no software process in place yet. We get to
decide on it.

Having been away from OO development for a few years (after being a
happy OO developer for many more years before that), and not being in the
mood to reinvent any more wheels than necessary, I looked around recently
to see what sort of standards were available. It saves _so_ much time to
take your processes off-the-shelf when practical.

So I go into Computer Literacy bookstore and I see all these books on UML.
I thumb through a few, and it seems like it might be a nice addition to our
toolkit.
Sure beats flowcharts. (I should add that I have no experience with Booch
notations or any of the other UML predecessors, save for state diagrams and
event diagrams.) For starters I settle on one of the slimmer volumes,
"Real-time
Design Using UML" (or something like that) by McDouglass. It makes no
attempt
to give comprehensive coverage of UML. Rather it focusses on those parts
that
are immediately useful to designers of real-time systems (which is the type
of
software I do). It's a bit breezy, more of an intro really, and it has its
share of
typos and mistakes. But on the whole I think it meets its stated goals
within the
limits the author chose to work in. I think I can see how to apply those
parts of
UML that he presents, at least informally. I didn't need weeks of time or
training
to digest the book.

So far this one book is really the _only_ exposure I have had to UML, and I
have
not developed any projects with it. With that disclaimer, my impression is
that
UML (or the parts of it I've read about) would actually be a useful notation
for
those places in the development process where we need a notation. I would
not
for a moment think that it obviates the need for textual descriptions in
documents,
nor would I be inclined to invest in any related CASE tools without having
used it
manually on a trial project first. I foresee it as a set of conventions for
diagrams
that accompany stages of documentation, rather than as a means of fully
capturing
any stage without resorting to text. The biggest benefits I see is that UML
probably
meets the needs of having a set of a diagramming conventions that meets all
of our near term needs, and it is a standard that we can point to, which
makes it
easy to justify (to managers, anyway), more or less ready to use, and books,
training and third party support are readily available if and when we feel
the need
for them.

Any obvious pitfalls I should be aware of?

-- Kurt Luoto


Rjbotting

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Kurt Luoto noted that UML is usable as a standard
diagramming convention and asked:

> Any obvious pitfalls I should be aware of?
I've found people make some common mistakes
Confusion with OMT notations.
Confusing diferent kinds of links(and how!)
(I might even forbid the use of diamonds and arrows
at first!)
Paralysis by analysis.
Rushing into to diagrams.
Postit notes, 3><5 cards, whiteboards, videotapes,....
workshops trying out the design
and a trash can.

Loss of sesne of humor.

(All off the top of my head.... must go...)

Julius Lancer

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
In article <1drzcs0.jxnia0lgn9icN@[192.168.1.2]>, schu...@acm.org (Michael Schuerig) wrote:
>Petronius Arbiter <end...@yahoo.com> wrote:
>
>> UML does not provide the information needs to build a system and UML is not a
>> useful tool for designing a system. IMHO, a text-oriented design system is
>> more useful than UMLs bewildering pictures.
>
>Would you mind to be more specific? What exactly is missing? And why is
>UML not useful?

Ever tried to turn UML into code? The maze of drawing is not useful at all. In
C++ for example, what is it you need to know when building class? That
information is better presented in tabular form rather than a maze of
drawings.

Michael Schuerig

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Julius Lancer <end...@yahoo.com> wrote:

> In article <1drzcs0.jxnia0lgn9icN@[192.168.1.2]>, schu...@acm.org
> (Michael Schuerig) wrote: >Petronius Arbiter <end...@yahoo.com> wrote:
> >
> >> UML does not provide the information needs to build a system and UML is
> >> not a useful tool for designing a system. IMHO, a text-oriented design
> >> system is more useful than UMLs bewildering pictures.
> >
> >Would you mind to be more specific? What exactly is missing? And why is
> >UML not useful?
>
> Ever tried to turn UML into code? The maze of drawing is not useful at all.

And your reply is not very specific at all, too. I don't mind if you say
that _you_ don't like UML, or that _you_ don't want to use it. What you
are saying is that UML is not useful in general; but you hardly make a
case for this bold statement.

> In C++ for example, what is it you need to know when building class? That
> information is better presented in tabular form rather than a maze of
> drawings.

Now, there's more to a design than a bunch of unrelated classes. The
tools I've encountered so far allow to attach as much info to a single
class as is necessary.

Julius Lancer

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
In article <1ds2f77.19b0h0tp5sj5eN@[192.168.1.2]>, schu...@acm.org (Michael Schuerig) wrote:
>And your reply is not very specific at all, too. I don't mind if you say
>that _you_ don't like UML, or that _you_ don't want to use it. What you
>are saying is that UML is not useful in general; but you hardly make a
>case for this bold statement.

Sorry but I don't have all day to type at newsgroups. If I can make the time I
will set down a list. At the high level, pictures are not what you need to
turn a design into a system. Pictures provide useful illustrations at key
points, but they are not the core of what you need for design.

Yes, pictures are great if:
1.You are a consultant trying to impress non-programmer senior managers
2.You make tools for drawing pictures

Michael Schuerig

unread,
May 19, 1999, 3:00:00 AM5/19/99
to
Julius Lancer <end...@yahoo.com> wrote:

> In article <1ds2f77.19b0h0tp5sj5eN@[192.168.1.2]>, schu...@acm.org
> (Michael Schuerig) wrote: >And your reply is not very specific at all,
> too. I don't mind if you say >that _you_ don't like UML, or that _you_
> don't want to use it. What you >are saying is that UML is not useful in
> general; but you hardly make a >case for this bold statement.
>
> Sorry but I don't have all day to type at newsgroups. If I can make the time I
> will set down a list. At the high level, pictures are not what you need to
> turn a design into a system. Pictures provide useful illustrations at key
> points, but they are not the core of what you need for design.

It's not that I or anyone is forcing you to spend your time writing on
usenet. It's just that I'm asking you to back your claims. So far you
haven't made it very far. Maybe we can get further, if you tried to
explain what exactly you'd like to have instead of UML diagrams.

SoftDocWiz

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
As I see it, the UML is meant to help people build great software by
facilitating communication and focusing efforts on the thought process. The
thinking is that you can't have great code unless everyone's on the same page.
It's not meant to be a silver bullet by any means.

If you're looking for a way to learn the most generally useful elements of the
UML relatively painlessly, check out "UML Distilled." (Note that a somewhat
reworked second edition is due out in August, but the current version seems to
work OK.) If you want humor, by all means, find a copy of "Use Case Driven
Object Modeling with UML," which also addresses the subject of analysis
paralysis throughout. And watch my Web site, because in a few weeks, I'll have
a new version of my UML Dictionary, this time based on the amigos' books, the
RUP book, and the OCL book, which should make for an even friendlier glossary
than the one I have in place now.


Kendall Scott
ken...@softdocwiz.com
http://softdocwiz.com


David B Lightstone

unread,
May 20, 1999, 3:00:00 AM5/20/99
to

Rjbotting wrote in message <19990518103506...@ng-fr1.aol.com>...
>David B Lightstone wrote
>>I don't know how to state this diplomatically, but the complexity in UML
>>is not in my opinion acceptable. It reminds me very much of a programming
>>language developed by a committee of experts. (Everyone's pet software
>>development brainstorm, the best theoretical results and a little
>>glue to hold it togethe
>
>Yes.... and this means you can grab just a piece of it
>at a time and use it. As a rule I prefer incremental
>changes to a complex process rather than a big bang.
>

It also means that the piece which I grab will be different from the
one which you grab. Such is the problem with general purpose
one size fits all tools. Babble is easily created.

>
>Especialy if other techniques are already in place which
>have a totally different perspective on things.

Ken Foskey

unread,
May 20, 1999, 3:00:00 AM5/20/99
to
Julius Lancer wrote:
>
> Sorry but I don't have all day to type at newsgroups. If I can make
> the time I will set down a list. At the high level, pictures are not
> what you need to turn a design into a system. Pictures provide useful
> illustrations at key points, but they are not the core of what you
> need for design.
>

I liked the fact that you can draw sequence diagrams that have
relevance to the system. It really shows the sequence and
interactions.

What I particularly liked (rational) was the ability to attach
very long involved descriptions and generate detailed
specifications in english from it.

I must admit to not doing a major project in one though. I would
suspect that the usefulness of the diagrams would degenerate after
X different objects. My guess for X would be less than 50.

t...@hpl.hp.com

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
Surely if your project needs UML then you will make project time
available for your staff to learn UML. Or even actively train them to
use UML effectively.

Personally I think UML has it's problems, but complexity isn't one of
them: the complexity reflects the complexity of what it's trying to
notate.

Skipjack Software (m...@skipjacksoftware.com) wrote:
|I have been trying to use UML on our latest project, but have found that
|getting people to use and understand it is a very daunting task. One thing
|that I will agree with them on is that UML is too difficult for the average
|developer to learn on-the-job (i.e., most developers are unwilling to set
|aside ten to twenty hours a week of their free time, after putting in fifty
|to sixty hour weeks, to learn an overly complex modeling technique.) Unlike
|logic-charting, data-flow-diagramming, and entity-relationship-diagramming,
|UML cannot be mastered with a month of practice. I hate to say it, but its
|complexity will be its downfall. Unless someone comes up with a simplified
|version of the UML (anyone up to designing a KISS-ML?,) I believe it will be
|replaced by yet another modeling technique.

|Mark

--
============================================================================
The above are my own views, not the views of HP
Tom Gardner Hewlett Packard Laboratories, Filton Rd,
t...@hpl.hp.com Stoke Gifford, Bristol, Avon, BS34 8QZ, ENGLAND.
Fax: +44 117 9228924 Tel: +44 117 92 29 29 1
============================================================================


Skipjack Software

unread,
May 21, 1999, 3:00:00 AM5/21/99
to
t...@hpl.hp.com wrote in message ...

>Surely if your project needs UML then you will make project time
>available for your staff to learn UML. Or even actively train them to
>use UML effectively.
>


I would love to make project time available for learning UML; however, the
project on which I am working is not controlled by my company (i.e., I am
just a hired gun on this project.)

Mark

Chris Cawsey

unread,
May 23, 1999, 3:00:00 AM5/23/99
to
Hi Erik, Hi All

Erik Funkenbusch wrote:
<good stuff snipped>


> There's a good book called Clouds to Code by Jesse Liberty which walks
you
> through a semi-serious application from start to end in the UML.

<more good stuff snipped>

I've got a copy of "Clouds to Code", I agree its worth a read, but I found
it a bit dull in places. Can I ask what you mean by "semi-serious" ?, maybe
I've missed something but I got the impression that the whole premise of
the work was that the project was for a genuine commercial, technically
non-trivial product. Have I been conned ;-) ?.

Cheers,

Chris Cawsey

John Burton

unread,
May 23, 1999, 3:00:00 AM5/23/99
to
Skipjack Software wrote in message <7hq0q4$n27$1...@autumn.news.rcn.net>...

>I have been trying to use UML on our latest project, but have found that
>getting people to use and understand it is a very daunting task. One
thing
>that I will agree with them on is that UML is too difficult for the average
>developer to learn on-the-job (i.e., most developers are unwilling to set
>aside ten to twenty hours a week of their free time, after putting in fifty
>to sixty hour weeks, to learn an overly complex modeling technique.)
Unlike
>logic-charting, data-flow-diagramming, and entity-relationship-diagramming,
>UML cannot be mastered with a month of practice. I hate to say it, but
its
>complexity will be its downfall. Unless someone comes up with a
simplified
>version of the UML (anyone up to designing a KISS-ML?,) I believe it will
be
>replaced by yet another modeling technique.


I think you need to find some very small projects where parts of UML can be
gradually introduced. Getting many people who have not used UML before to
suddenly starts using it on a large project is likely going to be a
disaster.

Personally I'd pick a small fairly self contained part of a project and use
part of UML to help with the design. For example use the static class
diagrams (whatever they are call in UML).

Also, I think that a frequent mistake is to try to produce one single model
of the whole system using UML. It just becomes hideously complicated. It
often seems much better to model small parts to an appropriate level.

Start small and gradually introduce features until you either have something
as complex as you can cope with, or else decide to scrap the whole idea ang
use something esle,.

Erik Funkenbusch

unread,
May 23, 1999, 3:00:00 AM5/23/99
to
Chris Cawsey <cmc_@_yahoo_dot_com> wrote in message
news:01bea51e$74cb3930$927f989e@dcbpccmc2...

Well, it wasn't exactly a HUGE project, a better term would have been
"semi-large". It was non-trivial, but it wasn't on the scale of many
corporate projects either.

Robert C. Martin

unread,
May 25, 1999, 3:00:00 AM5/25/99
to

>Skipjack Software wrote:
>
>> I have been trying to use UML on our latest project, but have found that
>> getting people to use and understand it is a very daunting task. One
thing
>> that I will agree with them on is that UML is too difficult for the
average
>> developer to learn on-the-job (i.e., most developers are unwilling to set
>> aside ten to twenty hours a week of their free time, after putting in
fifty
>> to sixty hour weeks, to learn an overly complex modeling technique.)
Unlike
>> logic-charting, data-flow-diagramming, and
entity-relationship-diagramming,
>> UML cannot be mastered with a month of practice. I hate to say it, but
its
>> complexity will be its downfall. Unless someone comes up with a
simplified
>> version of the UML (anyone up to designing a KISS-ML?,) I believe it will
be
>> replaced by yet another modeling technique.


UML is not a modeling technique. It is just a notation. And it't a lot
simpler than you make it seem.

I teach the essence of UML in about 4 hours. It's just not that big of a
deal. Nobody should need twenty hours per week to learn UML. You should be
able to learn it in 10 hours max, probably much less. I teach it in
conjunction with the principles of OOD and OO project management. It takes
me five days to get through all that with lots of in-depth labs.

All UML really is is souped up ER notation, Message sequence charts from the
telecommunication industry, STDs and Petri-nets from the 1960s, and a few
widgets and icons. No biggie.

That is, of course, if you already know OO. If you don't know OO, then UML
is the *least* of your worries.


Robert C. Martin | Design Consulting | Training courses offered:
Object Mentor | rma...@oma.com | Object Oriented Design
14619 N Somerset Cr | Tel: (800) 338-6716 | C++
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

TINCC.

John D Salt

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
In article <7idc2f$491$1...@hirame.wwa.com>,
Robert C. Martin <rma...@oma.com> wrote:
[Snips]

>All UML really is is souped up ER notation, Message sequence charts from the
>telecommunication industry, STDs and Petri-nets from the 1960s, and a few
>widgets and icons. No biggie.

...and this lucky bag of assorted diagram types is described by the
adjective "Unified", in a deperate attempt to conceal the fact that
it isn't. :-)

All the best,

John.
--
John D Salt Dept of IS & Computing,| Barr's Law of Recursive Futility
Brunel U, Uxbridge, Middx UB8 3PH | [BLORF]: If you are smart enough
Disclaimers: I speak only for me. | to use one of these... you can
Launcher may train without warning.| probably manage without one.

jlib...@libertyassociates.com

unread,
May 25, 1999, 3:00:00 AM5/25/99
to

>
> I've got a copy of "Clouds to Code", I agree its worth a read, but I
found
> it a bit dull in places.

Ouch. The unkindest cut of all <grin>.


Can I ask what you mean by "semi-serious" ?, maybe
> I've missed something but I got the impression that the whole premise
of
> the work was that the project was for a genuine commercial,
technically
> non-trivial product. Have I been conned ;-) ?.

You have not been conned. it was genuine, commercial, I found it
technically non-trivial.

Thanks for reading it. If others want to read a sample chapter and
reviews, they can do so on my web site
(http://www.libertyassociates.com) by clicking on books & resources.

Thanks.

Jesse Liberty
Liberty Associates, Inc.


--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---

univ...@saltmine.radix.net

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
In comp.object Ken Foskey <war...@zip.com.au> wrote:

> Robert C. Martin wrote:
>>
>> All UML really is is souped up ER notation, Message sequence charts

> I had a lecturer at Uni (who really did not understand OO)
> correlate everything to ER and dataflow diagrams. This gross
> simplification and can get you totally lost. IMHO :->

I agree 100%. Seeing UML as souped up ER is your view of UML if you do
not grasp the modelling power of OO and how different it is from any other
modelling paradigm. It is a sterile, sclerotic, right wing view of OO.

Elliott


> It was interesting listening to someone describe an object as a
> thing of a thing of a thing (literally).


Rjbotting

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
John D Salt of Brunel U, Uxbridge wrote

>...and this lucky bag of assorted diagram types is described by the
>adjective "Unified", in a deperate attempt to conceal the fact that
>it isn't. :-)

The unification is not at the level of syntax... I'm not
sure that there exists a single syntax that is good for
expressing statics, dynamics, interfaces, behavior,
etc etc. (My own failures at doing this make me fairly
sure it is impossible...).

There is an underlying "semantic model" that is unified
however.

Its kind of: E Pluribus Unum.

Tim Ottinger

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
univ...@saltmine.radix.net wrote:
>
> In comp.object Ken Foskey <war...@zip.com.au> wrote:
> > Robert C. Martin wrote:
> >>
> >> All UML really is is souped up ER notation, Message sequence charts
>
> > I had a lecturer at Uni (who really did not understand OO)
> > correlate everything to ER and dataflow diagrams. This gross
> > simplification and can get you totally lost. IMHO :->
>
> I agree 100%. Seeing UML as souped up ER is your view of UML if you do
> not grasp the modelling power of OO and how different it is from any other
> modelling paradigm. It is a sterile, sclerotic, right wing view of OO.

ERDs *are* modeling of entities, with real-world semantics. It's
as much a modeling diagram as anything else around. And there is a
mapping between the relationships (for instance, a foreign key IS
a qualified association). So ERDs are just a subset of the UML
class diagrams. If you take methods out of objects and only use
qualified associations and association classes, you end up with
ERDS. Really. And ERDS have plenty of science and useful practice
behind them.

But UML isn't *just* ERDs. It's also petri nets, message sequence
charts, state machines, etc. THat was already said. Even so, class
diagrams are just ERDs on steroids. Good steroids.

--
--------- There is no craftite conspiracy -------------
Tim Ottinger Object Mentor OO Training and
otti...@oma.com www.oma.com Mentoring
-------------------------------------------------------
We can interpret a bad temper as a sign of inferiority.
-- Alfred Adler

Julius Lancer

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
In article <7idc2f$491$1...@hirame.wwa.com>, "Robert C. Martin" <rma...@oma.com> wrote:

>UML is not a modeling technique. It is just a notation. And it't a lot
>simpler than you make it seem.

Over the past decade, I have found it very significant that there has been
much more emphasis on notation than there has been on solving the underlying
problem.

The actual notation used should be a minor issue. Who cares if you use a
square box or a round box or a cloud to represent a particular item? (Unless
you are a tool vendor.)

When I visit companies, they are invariably more concerned about finding
people who know UML [notation] rather than finding people who can analyze the
problem. In fact, I regularly hear people talk about "UML Methodology".

Erik Funkenbusch

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
Julius Lancer <end...@yahoo.com> wrote in message
news:7if7sa$kle$1...@oak.prod.itd.earthlink.net...

> In article <7idc2f$491$1...@hirame.wwa.com>, "Robert C. Martin"
<rma...@oma.com> wrote:
>
> >UML is not a modeling technique. It is just a notation. And it't a lot
> >simpler than you make it seem.
>
> Over the past decade, I have found it very significant that there has been
> much more emphasis on notation than there has been on solving the
underlying
> problem.

One of the underlying problems in analysis and design is finding a common
language to communicate your solution so that others are capable of
understanding it. What makes more sense? A solution that is wonderful but
nobody can understand, or a not so great solution that makes perfect sense
to everyone that looks at it?

> The actual notation used should be a minor issue. Who cares if you use a
> square box or a round box or a cloud to represent a particular item?
(Unless
> you are a tool vendor.)

Imagine if everyone in a company spoke and communciated in a different
language. More time would be spent on interpreting what was said than
actual work being done. UML is an attempt to put an end to that, and allow
focusing on the issues.

You seem to be looking at it from a single developer point of view. Often
times development requires large teams that need to communicate with varying
backgrounds.

If you look at the dozens (if not hundreds) of varying notational styles
that have been in use, there is no way for someone who's not familiar with
the notation to pick any one of them up and make sense of it, even if you
know other notations. Documentation should reflect the fact that you want
people to understand what you're saying.

By providing a standardized notation, you're giving everyone the same
language to speak in. It doesn't really matter if it's UML or Booch, or
OMT, but UML was an attempt to simplify these other styles and bring
together the best of all worlds. That way, even non-technical people can
understand it with a small amount of training.

> When I visit companies, they are invariably more concerned about finding
> people who know UML [notation] rather than finding people who can analyze
the
> problem. In fact, I regularly hear people talk about "UML Methodology".

How people use (or don't use) UML has nothing to do with the value of the
notation in a proper setting. Lots of people talk about OOP while writing C
code with classes. That doesn't make OOP less useful, it just means that
people aren't really clued into what it's supposed to be.


Tim Ottinger

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
Julius Lancer wrote:
[paragraphs rearranged for dramatic effect]

> Over the past decade, I have found it very significant that there has been
> much more emphasis on notation than there has been on solving the underlying
> problem.

> The actual notation used should be a minor issue. Who cares if you use a


> square box or a round box or a cloud to represent a particular item? (Unless
> you are a tool vendor.)

...or a diagram reader.


At one time, the plethora of notations *was* the problem. I don't know
if you were trying to read books and magazines in the late 80s and
early
90s, but if so you'd see that you had to know at least four or five
notations to do so. One article would be in Booch, the next in OMT,
the
next in Coad, and the next two in some notation you've never seen
before.

Or try consulting then.. you need to know a bunch of notations because
you're never sure what you'll be reviewing next time around. Go from
one company to another, and even more retraining is required.

In short, the lack of a common notation was an artificial barrier.
To better communicate with each other, it was necessary to have a
common
modeling notation. Thankfully, three notations pretty much dominated
the
landscape, and Rational picked up all three and created UML.

It's not a solution to the difficulties of design and implemenation,
but it solved (or is solving) one of the difficulties of publishing
and reading articles which do address the difficulties of design
and implementation.

> When I visit companies, they are invariably more concerned about finding
> people who know UML [notation] rather than finding people who can analyze the
> problem. In fact, I regularly hear people talk about "UML Methodology".

Yep. Alot of companies hire workers and buy products purely off
of a checklist. It's much easier than really getting to know
what you need and want. To their credit, a lot of companies only
do that to thin down the applicants. It's better than some other
practices I've heard of, and you can learn UML easily enough.

Tim

Dennis Gearon

unread,
May 25, 1999, 3:00:00 AM5/25/99
to
Romantic Period Music vs Classical Period Music,
Ditto for Art,
Job Availability vs. Getting Automated/Outdated Out of work,
Notation vs Methodology,
Importance of Application Vs OS Facilities

EVERYTHING GOES IN CYCLES

Our jobs will go overseas and be thinned out by autoprogramming, then
they'll need better programmers for the next great autoprogramming
idea/wave and away we go again!
--
---------------------------------------------------------------
I am here only to be truly helpful - Dennis Gearon
---------------------------------------------------------------

Robert C. Martin

unread,
May 25, 1999, 3:00:00 AM5/25/99
to

>Seeing UML as souped up ER is your view of UML if you do
>not grasp the modelling power of OO and how different it is from any other
>modelling paradigm. It is a sterile, sclerotic, right wing view of OO.
======= ========= =====
A A A
Clean----------------------------+ | |
Hard---------------------------------------+ |
Correct---------------------------------------------+


;^)

Robert C. Martin

unread,
May 25, 1999, 3:00:00 AM5/25/99
to

Julius Lancer wrote in message <7if7sa$kle$1...@oak.prod.itd.earthlink.net>...

>In article <7idc2f$491$1...@hirame.wwa.com>, "Robert C. Martin"
<rma...@oma.com> wrote:
>
>>UML is not a modeling technique. It is just a notation. And it't a lot
>>simpler than you make it seem.
>
>Over the past decade, I have found it very significant that there has been
>much more emphasis on notation than there has been on solving the
underlying
>problem.

Then you should go to my website and read the papers there that cover the
Principles of OOD. Read:

1. The Open Closed Principle
2. The Liskov Substitution Principle
3. The Dependency Inversion Principle
4. The Interface Segregation Principle
5. Granularity
6. Stability.

You should also read the Design Patterns Book, and the various other pattern
books including "Pattern Languages of Program Design" vols 1, 2, and 3. You
should read "Analysis Patterns" and "A System of Patterns". Actually, over
the last decade there has been a *lot* of work don on how to solve the


underlying problem.
>
>The actual notation used should be a minor issue. Who cares if you use a
>square box or a round box or a cloud to represent a particular item?
(Unless
>you are a tool vendor.)

You care if you want to use the same notation as everyone else. That's all
UML is really about. It's a way of standardizing our notation.

>When I visit companies, they are invariably more concerned about finding
>people who know UML [notation] rather than finding people who can analyze
the
>problem. In fact, I regularly hear people talk about "UML Methodology".

UML methodology does not exist. And finding people who know UML is pretty
easy since UML can be learned in an afternoon.

Robert C. Martin

unread,
May 25, 1999, 3:00:00 AM5/25/99
to

Julius Lancer wrote in message <7iffir$o16$1...@ash.prod.itd.earthlink.net>...

>
>A short way of summing it up is that IMHO UML does not do a good job of
>describing to 3rd parties what a system is supposed to do and how it is to
>work.


Well, I believe you are wrong. UML diagrams can be very unambiguous about
how systems are to be structured and how they are to work. I agree that
they can be abused by dilletante consultants, but that's a different matter.

See the UML Tutorial papers at my website. They show the mapping of UML to
C++ and Java pretty well.

Ken Foskey

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
Robert C. Martin wrote:
>
> All UML really is is souped up ER notation, Message sequence charts

I had a lecturer at Uni (who really did not understand OO)
correlate everything to ER and dataflow diagrams. This gross
simplification and can get you totally lost. IMHO :->

It was interesting listening to someone describe an object as a

David B Lightstone

unread,
May 26, 1999, 3:00:00 AM5/26/99
to

Some things are possible, some things are not. I am inclined
to believe that the modeling notation standardization argument
does not apply to UML. UML is an extendable notation. That
is users can develop stereotypes. These stereotypes probably
create a situation in which the notations will be subject to
ambiguous interpretation

Dave Lightstone


Erik Funkenbusch wrote in message ...


>Julius Lancer <end...@yahoo.com> wrote in message
>news:7if7sa$kle$1...@oak.prod.itd.earthlink.net...

>> In article <7idc2f$491$1...@hirame.wwa.com>, "Robert C. Martin"
><rma...@oma.com> wrote:
>>
>> >UML is not a modeling technique. It is just a notation. And it't a lot
>> >simpler than you make it seem.
>>
>> Over the past decade, I have found it very significant that there has
been
>> much more emphasis on notation than there has been on solving the
>underlying
>> problem.
>

>One of the underlying problems in analysis and design is finding a common
>language to communicate your solution so that others are capable of
>understanding it. What makes more sense? A solution that is wonderful but
>nobody can understand, or a not so great solution that makes perfect sense
>to everyone that looks at it?
>

>> The actual notation used should be a minor issue. Who cares if you use a
>> square box or a round box or a cloud to represent a particular item?
>(Unless
>> you are a tool vendor.)
>

>Imagine if everyone in a company spoke and communciated in a different
>language. More time would be spent on interpreting what was said than
>actual work being done. UML is an attempt to put an end to that, and allow
>focusing on the issues.
>
>You seem to be looking at it from a single developer point of view. Often
>times development requires large teams that need to communicate with
varying
>backgrounds.
>
>If you look at the dozens (if not hundreds) of varying notational styles
>that have been in use, there is no way for someone who's not familiar with
>the notation to pick any one of them up and make sense of it, even if you
>know other notations. Documentation should reflect the fact that you want
>people to understand what you're saying.
>
>By providing a standardized notation, you're giving everyone the same
>language to speak in. It doesn't really matter if it's UML or Booch, or
>OMT, but UML was an attempt to simplify these other styles and bring
>together the best of all worlds. That way, even non-technical people can
>understand it with a small amount of training.
>

>> When I visit companies, they are invariably more concerned about finding
>> people who know UML [notation] rather than finding people who can analyze
>the
>> problem. In fact, I regularly hear people talk about "UML Methodology".
>

Ell

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
Tim Ottinger <otti...@oma.com> wrote:

#univ...@saltmine.radix.net wrote:
#>
#> In comp.object Ken Foskey <war...@zip.com.au> wrote:
#> >
#> > Robert C. Martin wrote:
#> >>
#> >> All UML really is is souped up ER notation, Message sequence charts

#> > I had a lecturer at Uni (who really did not understand OO)
#> > correlate everything to ER and dataflow diagrams. This gross
#> > simplification and can get you totally lost. IMHO :->

#> I agree 100%. Seeing UML as souped up ER is your view of UML if you do
#> not grasp the modelling power of OO and how different it is from any other
#> modelling paradigm. It is a sterile, sclerotic, right wing view of OO.

#ERDs *are* modeling of entities, with real-world semantics. It's
#as much a modeling diagram as anything else around.

I didn't say ERD wasn't a modelling paradigm, I'm making the case that OO is
different more powerful one than ERD.

RCM is saying basically OO is the same as ERD, but souped up. I'm saying
it's a different and generally superior form of modelling to ERD. The bad
thing is that it is RCM - your prez - who is the in fact the one trying to
make ERD equivalent to OO, by saying OO is just souped up OO.

Elliott
--
:=***=: Objective * Holistic * Overall pre-code Modelling :=***=:
Hallmarks of the best SW Engineering
study Craftite vs. Full Blown OO: http://www.access.digex.net/~ell
copyright 1999 Elliott. exclusive of others' writing. may be copied freely
only in comp., phil., sci. usenet & bitnet & otug.

Julius Lancer

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
In article <PRF23.792$j65.1...@ptah.visi.com>, "Erik Funkenbusch" <er...@visi.com> wrote:
>You seem to be looking at it from a single developer point of view. Often
>times development requires large teams that need to communicate with varying
>backgrounds.

No, I see all to many cases where people (generally outside
consultants) generate UML representations of systems and few can figure out
what they mean or how to translate them into a system.

The same problem existed in the "Structured Analysis" period. At the end of
the analysis process you had stacks of diagrams, that were difficult for
people who had not been involved in the initiali process to translate and
turn into a system. (On the other hand, DeMarco et al had a methodology for
people to create the diagrams in the first place.)

A short way of summing it up is that IMHO UML does not do a good job of
describing to 3rd parties what a system is supposed to do and how it is to
work.

John - N8086N

Ell

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
univ...@radix.net (Ell) wrote:

#RCM is saying basically OO is the same as ERD, but souped up. I'm saying
#it's a different and generally superior form of modelling to ERD. The bad
#thing is that it is RCM - your prez - who is the in fact the one trying to
#make ERD equivalent to OO, by saying OO is just souped up OO.

Correction:

#RCM is saying basically OO is the same as ERD, but souped up. I'm saying
#it's a different and generally superior form of modelling to ERD. The bad
#thing is that it is RCM - your prez -
who is [] in fact the one trying to make ERD equivalent to OO, by saying OO

is just souped up [ERD].

Ell

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
Dave Thomas <Da...@Thomases.com> wrote:

#<univ...@saltmine.radix.net> writes:
#


#> modelling paradigm. It is a sterile, sclerotic, right wing view of OO.

#It hardens your tissues?
#
#My!

I should have used the word "arteriosclerotic". To say that OO is simply
souped up ERD reflects a hardening of the arteries, especially of cerebral
arteries, of the those espousing such a view. Arteriosclerosis is generally
a disease of old age and often causes regressive, flawed thinking due to the
low amount of oxygen and other nutrients.

I mean its a tired, dead hand of the past, view to see OO as simply better ERD
and not as the vital, vibrant and excitingly superior form of modelling that
in fact it is. The tired view is an attempt to emasculate and neuter OO. It
reflects at the very least a dislike for the futuristic, and progressive
things that OO is really about. It attempts to chop off and limit that
goodness about OO.

Ell

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
end...@yahoo.com (Julius Lancer) wrote:

#In article <PRF23.792$j65.1...@ptah.visi.com>, "Erik Funkenbusch" <er...@visi.com> wrote:
#>You seem to be looking at it from a single developer point of view. Often
#>times development requires large teams that need to communicate with varying
#>backgrounds.
#
#No, I see all to many cases where people (generally outside
#consultants) generate UML representations of systems and few can figure out
#what they mean or how to translate them into a system.
#
#The same problem existed in the "Structured Analysis" period. At the end of
#the analysis process you had stacks of diagrams, that were difficult for
#people who had not been involved in the initiali process to translate and
#turn into a system. (On the other hand, DeMarco et al had a methodology for
#people to create the diagrams in the first place.)

A good thing about IID (iterative and incremental development) is that the
various elements of development are married to each other before its all or
nothing. Analysis diagrams would be used earlier on and improvements and
changes in their form and content would made so that they were effective tools
and not difficult to use stacks of paper.

#A short way of summing it up is that IMHO UML does not do a good job of
#describing to 3rd parties what a system is supposed to do and how it is to
#work.

UML is not a process though.

For a process from the UML core designers - the amigos - check out Rational
Unified Process (RUP) at the Rational site. Peruse and check out the process
papers by the amigos given at a recent UML conference. Also P. Kruthcheon has
an o-fish-ul RUP book out at the big bookstores.

Richard Smol

unread,
May 26, 1999, 3:00:00 AM5/26/99
to

In a previous article, end...@yahoo.com (Julius Lancer) says:

>When I visit companies, they are invariably more concerned about finding
>people who know UML [notation] rather than finding people who can analyze the
>problem. In fact, I regularly hear people talk about "UML Methodology".

People who claim that usually don't follow any methodology at all. UML,
like any other notation, does prsent certain ideas though about how systems
should be analysed and designed. With UML it's the OO way (obviously). I
find that UML is not hard to understand at all once you have a thorough
understanding of OO in general. I could imagine that it might be
intimidating for people who don't have much of an OO background.

I am now working in a project where this is the case. These people want to
use UML, but they hardly have any notion of what an object is, really. In
such a situation UML is quite a useless tool. The project leader is using
class diagrams as some sort of enhanced ERDs, without a true understanding
of the matter.

Greetz,

RS


Cristele LARTIGUE

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
Erik Funkenbusch wrote:
>
> Julius Lancer <end...@yahoo.com> wrote in message
> news:7if7sa$kle$1...@oak.prod.itd.earthlink.net...
> > In article <7idc2f$491$1...@hirame.wwa.com>, "Robert C. Martin"
> <rma...@oma.com> wrote:
> >
> > >UML is not a modeling technique. It is just a notation. And it't a lot
> > >simpler than you make it seem.
> >
> > Over the past decade, I have found it very significant that there has been
> > much more emphasis on notation than there has been on solving the
> underlying
> > problem.
you seem to ignore Merise notation. Is it omly a european notation
(having saying that, Merise is not for OO, but you seem to say that UML
is the first notation for projects)?

John D Salt

unread,
May 26, 1999, 3:00:00 AM5/26/99
to
In article <19990525141828...@ng-fg1.aol.com>,
Rjbotting <rjbo...@aol.com.not> wrote:
[Snips of me grumbling about UML not appearing "unified"]

>There is an underlying "semantic model" that is unified
>however.

H'mmmm. So what [kind + brave] soul is going to explain
to me how activity diagrams fit in with an object model?
(especially, why did they decide to include the revolting
"decision activity" illustrated on p. 130 of Fowler's
"UML distilled"?).

Rjbotting

unread,
May 26, 1999, 3:00:00 AM5/26/99