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
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
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
product, expecting little or nothing in return for the professional and
Erik Funkenbusch wrote in message ...
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?
> 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?
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
> 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
> 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
> 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
> effort to cajole others into participating in the development of another
> firms product, expecting little or nothing in return for the professional
> 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.
> 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)
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]
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
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.
--- --- ---
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)
--- --- ---
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!
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
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,
Design Using UML" (or something like that) by McDouglass. It makes no
to give comprehensive coverage of UML. Rather it focusses on those parts
are immediately useful to designers of real-time systems (which is the type
software I do). It's a bit breezy, more of an intro really, and it has its
typos and mistakes. But on the whole I think it meets its stated goals
limits the author chose to work in. I think I can see how to apply those
UML that he presents, at least informally. I didn't need weeks of time or
to digest the book.
So far this one book is really the _only_ exposure I have had to UML, and I
not developed any projects with it. With that disclaimer, my impression is
UML (or the parts of it I've read about) would actually be a useful notation
those places in the development process where we need a notation. I would
for a moment think that it obviates the need for textual descriptions in
nor would I be inclined to invest in any related CASE tools without having
manually on a trial project first. I foresee it as a set of conventions for
that accompany stages of documentation, rather than as a means of fully
any stage without resorting to text. The biggest benefits I see is that UML
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
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
Any obvious pitfalls I should be aware of?
-- Kurt Luoto
Loss of sesne of humor.
(All off the top of my head.... must go...)
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
> 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
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.
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
> 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.
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.
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.
I liked the fact that you can draw sequence diagrams that have
relevance to the system. It really shows the sequence and
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.
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
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.
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
>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.)
Erik Funkenbusch wrote:
<good stuff snipped>
> There's a good book called Clouds to Code by Jesse Liberty which walks
> 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 ;-) ?.
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
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,.
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.
>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
>> that I will agree with them on is that UML is too difficult for the
>> 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
>> to sixty hour weeks, to learn an overly complex modeling technique.)
>> logic-charting, data-flow-diagramming, and
>> UML cannot be mastered with a month of practice. I hate to say it, but
>> complexity will be its downfall. Unless someone comes up with a
>> version of the UML (anyone up to designing a KISS-ML?,) I believe it will
>> 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
...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 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.
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
> the work was that the project was for a genuine commercial,
> non-trivial product. Have I been conned ;-) ?.
You have not been conned. it was genuine, commercial, I found it
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.
Liberty Associates, Inc.
--== Sent via Deja.com http://www.deja.com/ ==--
---Share what you know. Learn what you don't.---
> 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.
> It was interesting listening to someone describe an object as a
> thing of a thing of a thing (literally).
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
Its kind of: E Pluribus Unum.
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
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
>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
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".
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?
> 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
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
> 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.
> 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
> 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
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,
next in Coad, and the next two in some notation you've never seen
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
modeling notation. Thankfully, three notations pretty much dominated
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
> 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.
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