Mark
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...
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 ...
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_
> 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/
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.
> 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)
--- --- ---
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
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
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
drawings.
> 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.
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.
Kendall Scott
ken...@softdocwiz.com
http://softdocwiz.com
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
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.
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
============================================================================
>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
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
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,.
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
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.
...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.
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.---
> 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).
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.
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
>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".
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.
> 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
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
---------------------------------------------------------------
;^)
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.
>
>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.
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
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".
>
#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.
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
#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].
#<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.
#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.
>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
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"?).