UML Too Difficult for the Average Developer to Learn?
Skipjack Software
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
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
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
>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. )
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
> 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
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
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
>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
>
>
> 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
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
>
>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
diagramming convention and asked:
> Any obvious pitfalls I should be aware of?
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
>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
> 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
>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
> 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
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
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
>
> 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
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
>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
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
>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
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
>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
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
>
> 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
> 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
>...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
>
> 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
>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
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
[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
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
>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
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.
>
>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
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
>
> 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
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
#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
>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
#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
#<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
#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
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
>
> 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.
(having saying that, Merise is not for OO, but you seem to say that UML
is the first notation for projects)?
John D Salt
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
>how activity diagrams fit in
In the meta-model they are a special class
of statediagrams with a number of partitions(swimlanes?), and
partitions are related to sets of model elements.
Personally, Iwant to use to them analyse an existing system
or to review or present a complete design.
I'd not use them to design a system that doesn't exist.
Now I have some the bad news
> the revolting
>"decision activity"
is actually part of UML statecharts. You'll find them
on pages 194 and 195 of "UML in a Nutshell".
I figure they are a kind of abreviation.
Personally I much prefer to use tables to document
complicated conditions. To say nothing of letting
polymorphism handle them.
Dennis Gearon
believe means "communication", "responsibility", and "control". Let's
face it gals and guys, Programs only do three things: wait, decide what
to do, do it. The most problem I seee with code is no structure or
simplicity in the decision making part of the program, unexplored sets
of events and condtions causing problems with poor recovery. What else
can object oriented programming do besides abstract the code for a set
of datums and associated processes? I know it can save developer time if
PROPERLY used.
Dennis Gearon
stuff is, i.e.
<name first button/link><name second button/link>:bottom of page.
Robert C. Martin wrote:
>
> 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 | 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.
--
pat...@c837917-a.potlnd1.or.home.com
: Coming from an embedded point of view, I like the idea of CRC, which
: I believe means "communication", "responsibility", and
: "control".
Class, Responsibilities, Collaborators
Each card describes a class, its responsibilities, and its
collaborators. Actually CRC cards are at least as useful *before* the
classes are known. The cards represent potential objects in the
system. Deciding what the classes are should come *after* deciding what
the objects are!
--
Patrick D. Logan mailto:patric...@home.com
argo...@my-deja.com
What has been the experience of people
using UML in general? Of using OOP in general?
What were any benefits? Downfalls?
Regards,
Argosy
In article <7hq0q4$n27$1...@autumn.news.rcn.net>,
"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
univ...@saltmine.radix.net
> Coming from an embedded point of view, I like the idea of CRC, which I
> believe means "communication", "responsibility", and "control".
Usually in OO it has meant "class responsibility collaboration". It is a
technique for understanding how classes with specific responsibilities in
a design will collaborate with each other to achieve the intended result
or use case goal.
Wirfs-Brock and I think Goldberg introduced the idea in a book at least 10
years ago.
> Let's
> face it gals and guys, Programs only do three things: wait, decide what
> to do, do it.
I find that programs do other things also. Process, control, and provide
services are some key ones.
Elliott
pat...@c837917-a.potlnd1.or.home.com
: Wirfs-Brock and I think Goldberg introduced [CRC cards] in a book at
: least 10 years ago.
Actually Ward Cunningham and Kent Beck introduced them. (I think Ward
created them first and then the two developed the idea.)
http://c2.com/doc/oopsla89/paper.html
Wirfs-Brock was at Tektronix at the same time as Cunningham and Beck,
and carried CRC cards into her later development and book on
Responsibility Driven Design.
Jim Cochrane
Richard Smol <bl...@cleveland.Freenet.Edu> wrote:
>
>In a previous article, end...@yahoo.com (Julius Lancer) says:
>
>>people who know UML [notation] rather than finding people who can analyze the
>>problem. In fact, I regularly hear people talk about "UML Methodology".
>
>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.
A methodology like Business Object Notation would probably be more suitable
in such a situation. The notation and the concepts behind the notation are
designed specifically for OO modeling. It's difficult to create
ERDs using BON. This, I think, would help guide beginners in the right
direction.
>
>Greetz,
>
>RS
>
--
Jim Cochrane
j...@dimensional.com
Robert C. Martin
Dennis Gearon wrote in message <374C0E...@oit.edu>...
>I would be grateful if this gentleman would share where in his page
>stuff is, i.e.
>
><name first button/link><name second button/link>:bottom of page.
>Robert C. Martin wrote:
>> Then you should go to my website and read the papers there that cover the
>> Principles of OOD. Read:
>>
>> 1. The Open Closed Principle
http://www.oma.com/PDF/ocp.pdf
>> 2. The Liskov Substitution Principle
http://www.oma.com/PDF/lsp.pdf
>> 3. The Dependency Inversion Principle
http://www.oma.com/PDF/dip.pdf
>> 4. The Interface Segregation Principle
http://www.oma.com/PDF/isp.pdf
>> 5. Granularity
http://www.oma.com/PDF/granularity.pdf
>> 6. Stability.
http://www.oma.com/PDF/stability.pdf
Ell
#I have a related question.
#
#What has been the experience of people
#using UML in general? Of using OOP in general?
#
#What were any benefits? Downfalls?
Generally UML and most other modelling has helped the projects I have been in
to understand and model client requirements and to design systems at all
degrees and levels of concreteness and detail.
UML has been of use in our OO projects. Typically we use Chen's
Entity/Relationship notation to model rdbms'es. Our structured programs have
benefitted from Data Flow Diagrams (DFD's), HIPPO's - hierarchy input/output
charts, and flow charts.
The only problem we have run into using a notation is when that notation is
not suitable for the nature of the material, or elements being modelled.
We've never really had that problem with UML because it's typically clear when
objects are or are not being modelled.
Fatso the Innocent
> 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.
>
> square box or a round box or a cloud to represent a particular item? (Unless
> you are a tool vendor.)
>
> people who know UML [notation] rather than finding people who can analyze the
> problem. In fact, I regularly hear people talk about "UML Methodology".
don't become programmers, while people with real bad heads all go into
management. The latter become targets of all this UML-related hulabaloo.
Nothing wrong with UML, but the importance of it is rather small. Of
course, there's a new caste of self-proclaimed OO gurus who make
everything to make UML appear rocket science...
Ell
#Julius Lancer wrote:
#> 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".
#Perfect. 100% on the money. That's because people with real good heads
#don't become programmers,
!?
# while people with real bad heads all go into
#management.
!?
# The latter become targets of all this UML-related hulabaloo.
#Nothing wrong with UML, but the importance of it is rather small.
Please explain. If it is at least one of the 2 means of graphical OO notation
how is it's importance small.
# Of
#course, there's a new caste of self-proclaimed OO gurus who make
#everything to make UML appear rocket science...
Obviously making UML appear to be rocket science is wrong because it's not,
but that doesn't mean the importance of UML is rather small.
Fatso the Innocent
> #Perfect. 100% on the money. That's because people with real good heads
> #don't become programmers,
> !?
otherwise) challenging profession. And I'm not even talking about the
writing and even spelling capacity <g> of our people. Anyway,
sharp-minded people can grasp UML or similar very quickly and properly
relegate it to where it belongs--one from among many very secondary
tools.
> # while people with real bad heads all go into
> #management.
> !?
Here what didn't you get <g>? I'm yet to see a manager who can have a
learned opinion about things like UML (or Corba, or OLE, or whatever the
hell else.) At least they're not numerous, and the ones that know the
tech side, don't waste $2000 of company's money for every Rational Rose
licence. They'd _know_ it's not worth it (even if the s/w were good,
which it isn't.) But mostly they know nothing and are routinely sold a
bill of goods. Then it sits on the shelf and the projects still get
cancelled or result in delivering a load of crap with a stack of UML
diagrams <g>. Then we, consultants, come it, do the job and UML what we
did for their ease of heart <g>. Although sometimes they don't wanna pay
for the UML part, and I can't blame them...
> # The latter become targets of all this UML-related hulabaloo.
> #Nothing wrong with UML, but the importance of it is rather small.
>
> Please explain. If it is at least one of the 2 means of graphical OO notation
> how is it's importance small.
What do you mean 'one of the 2'? What's the other one <g>? There are an
unlimited number of ways to document design. Plain text, informal
diagrams, OMT, UML, ERD, DFD, (add a zillion other acronyms--all just as
good as any other), doodles on a whiteboard...
> Obviously making UML appear to be rocket science is wrong because it's not,
> but that doesn't mean the importance of UML is rather small.
Read Lancer's comment. He's absolutely right. The important thing is to
develop something that works, works reliably, is robust, quick,
maintainable, testable, learnable, affordable, solving your business
problems, etc. Those are the real issues. Whether you use UML--and to
what degree--is very unimportant compared to achievement of the above
goals. UML is nothing but another type of notation. It's even less
important than technical drawing in mechanical engineering.
------------------------------------------
len
if you must use email, reply to:
73 662 dot 26 51 at compuserve dot com
Michael Schuerig
> > #Perfect. 100% on the money. That's because people with real good heads
> > #don't become programmers,
> > !?
> Well, in my opinion <g>. I don't think it's the most intellectually (and
> otherwise) challenging profession.
Well, it depends on what you make of it <g>.
Michael
--
Michael Schuerig
mailto:schu...@acm.org
http://www.schuerig.de/michael/
thi
> Ell wrote:
>
> > Please explain. If it is at least one of the 2 means of graphical OO
> > notation how is it's importance small.
>
> What do you mean 'one of the 2'? What's the other one <g>? There are an
> unlimited number of ways to document design. Plain text, informal
> diagrams, OMT, UML, ERD, DFD, (add a zillion other acronyms--all just as
> good as any other), doodles on a whiteboard...
i am shocked that logic is not passed along using vulcan mind melds.
intermediate formats are so inefficient!
thi
Richard Smol
In a previous article, pat...@c837917-a.potlnd1.or.home.com () says:
>Dennis Gearon (gea...@oit.edu) wrote:
>
>: Coming from an embedded point of view, I like the idea of CRC, which
>: I believe means "communication", "responsibility", and
>: "control".
>
>Class, Responsibilities, Collaborators
>
>Each card describes a class, its responsibilities, and its
>collaborators. Actually CRC cards are at least as useful *before* the
>classes are known. The cards represent potential objects in the
>system. Deciding what the classes are should come *after* deciding what
>the objects are!
CRC cards sound nice, but in practice I do have some problems with it,
especially when the project is rather technical or the domain experts have
a technical background. I have big difficulties trying to get their heads
of of the gutter and think higher-level about their system.
Greets,
RS
Richard Smol
In a previous article, j...@dimensional.com (Jim Cochrane) says:
>>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.
>
>A methodology like Business Object Notation would probably be more suitable
>in such a situation. The notation and the concepts behind the notation are
>designed specifically for OO modeling. It's difficult to create
>ERDs using BON. This, I think, would help guide beginners in the right
>direction.
I associate BON with Eiffel. If it were up to me, I'd do most of my
projects in Eiffel and BON anyway. Alas, Java seems to have become quite
mainstream and although it's not a half bad language, I feel it lacking in
some respects (primitive types, C-like syntax, no MI, etc).
UML indeed lends itself to some abuse, just BECAUSE it's so flexible and
extensible. And if noone really understand sequence-diagrams, there is no
need to use any. On the other hand, UML is already useful at quite simple
levels.
Greetz,
RS
Ian Oliver
> UML indeed lends itself to some abuse, just BECAUSE it's so flexible and
> extensible. And if noone really understand sequence-diagrams, there is no
> need to use any. On the other hand, UML is already useful at quite simple
> levels.
I've been trying to stay out of this debate but...UML is just a NOTATION - OK so
you can bolt on processes but that's another matter. As for UML-abuse - you can
abuse any notation/methodology etc, the one I keep on seeing is people modelling
their code rather than the problem, ie: how to I write the UML for this C++
code, when you should be writing the C++/Java/whatever to fit the model.
Now modelling and what constitutes a good model is another topic altogether...
In summary: UML is EASY - Modelling is HARD
Ian
--
+------------------------------------------------------------------------+
Ian Oliver ian.o...@bcs.org.uk
Researcher http://www.cs.ukc.ac.uk/people/rpg/ijo1
Computing Laboratory +44 (0)1227 764000 x3822
University of Kent "Iechyd da i bawb!"
+------------------------------------------------------------------------+
Alan Gauld
> H'mmmm. So what [kind + brave] soul is going to explain
I haven't used activity diagrams yet - but plan to soon,
so my ideas might change! But my view is that they do
for UML what DFDs do in SA/SD. They capture a business
process flow in a diagramatic form which at least bears
some relation to the static model.
Thats not much of an explanation, but its as much as
I'll venture till I've used them...
Alan G.
--
=================================================
This post represents the views of the author
and does not necessarily accurately represent
the views of BT.
Alan Gauld
> system. Deciding what the classes are should come *after* deciding what
> the objects are!
Hear hear!
Its a fact not often explicitly stated in discussions of OOA.
Rjbotting
>CRC cards sound nice, but in practice
>especially when the project is rather technical or the domain experts have
>a technical background. I have big difficulties trying to get their heads
>of of the gutter and think higher-level about their system.
If the domain is full of data being processed it can be
very difficult to see what is going behind the data.
In this kind of situation it might be worth creeping
up on the problem by using some kind of work-flow
and data-flow model of the current system and then
trying to remove the accidental features... The
benefit is that you don't miss as many of those facts that
"every body knows" but never mentions.
The software development task gets embedded in
re-engineering an existing system that has usually
undrgone a lot evolution....
Dennis Gearon
end of the release.
--
Dennis Gearon
syntax and file structures to implement modeling notation contructs
would be useful? After MUCH thought and reading, I've come up with what
works for me on small micros to make SSAD in C. It works 90% of the time
and I don't have to think much about implementation except to tune
speed/size.
Fatso the Innocent wrote:
>
> Ell wrote:
> > #Perfect. 100% on the money. That's because people with real good heads
> > #don't become programmers,
> > !?
> Well, in my opinion <g>. I don't think it's the most intellectually (and
> otherwise) challenging profession. And I'm not even talking about the
> writing and even spelling capacity <g> of our people. Anyway,
> sharp-minded people can grasp UML or similar very quickly and properly
> relegate it to where it belongs--one from among many very secondary
> tools.
>
> > # while people with real bad heads all go into
> > #management.
> > !?
> Here what didn't you get <g>? I'm yet to see a manager who can have a
> learned opinion about things like UML (or Corba, or OLE, or whatever the
> hell else.) At least they're not numerous, and the ones that know the
> tech side, don't waste $2000 of company's money for every Rational Rose
> licence. They'd _know_ it's not worth it (even if the s/w were good,
> which it isn't.) But mostly they know nothing and are routinely sold a
> bill of goods. Then it sits on the shelf and the projects still get
> cancelled or result in delivering a load of crap with a stack of UML
> diagrams <g>. Then we, consultants, come it, do the job and UML what we
> did for their ease of heart <g>. Although sometimes they don't wanna pay
> for the UML part, and I can't blame them...
>
> > # The latter become targets of all this UML-related hulabaloo.
> > #Nothing wrong with UML, but the importance of it is rather small.
> >
> > Please explain. If it is at least one of the 2 means of graphical OO notation
> > how is it's importance small.
> What do you mean 'one of the 2'? What's the other one <g>? There are an
> unlimited number of ways to document design. Plain text, informal
> diagrams, OMT, UML, ERD, DFD, (add a zillion other acronyms--all just as
> good as any other), doodles on a whiteboard...
>
> > Obviously making UML appear to be rocket science is wrong because it's not,
> > but that doesn't mean the importance of UML is rather small.
> Read Lancer's comment. He's absolutely right. The important thing is to
> develop something that works, works reliably, is robust, quick,
> maintainable, testable, learnable, affordable, solving your business
> problems, etc. Those are the real issues. Whether you use UML--and to
> what degree--is very unimportant compared to achievement of the above
> goals. UML is nothing but another type of notation. It's even less
> important than technical drawing in mechanical engineering.
>
> ------------------------------------------
> len
> if you must use email, reply to:
> 73 662 dot 26 51 at compuserve dot com
--
Ken O'Brien
Julius Lancer <end...@yahoo.com> wrote in message news: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.
>
My experience has been just the opposite. I've picked up other peoples UML
documents and knew exactly what they were doing. The important point is
that I didn't need them there to explain the notation. Most books now
contain UML for the same reason. They don't have to waste time explaining
the notation - Design Patterns is a case in point.
I've also picked up a UML document and knew the design was bad. The UML
wasn't bad. The system described using UML didn't make any sense. That was
an OO problem, not a UML one.
Ken
Ken O'Brien
> 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 [] in fact the one trying to make ERD equivalent to OO, by saying OO
> is just souped up [ERD].
>
> Elliott
I thought he was saying that UML contains an enhanced ERD, among other things.
This seems quite different than saying OO is an enhanced ERD. Replacing the
word UML with OO can't be done. Seems like that was implied in RCMs comments
that UML is just a notation.
Ken
Ell
#Ell <univ...@radix.net> wrote in message news:37504ed5...@news1.radix.net...
#> 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 [] in fact the one trying to make ERD equivalent to OO, by saying OO
#> is just souped up [ERD].
#I thought he was saying that UML contains an enhanced ERD, among other things.
#This seems quite different than saying OO is an enhanced ERD. Replacing the
#word UML with OO can't be done. Seems like that was implied in RCMs comments
#that UML is just a notation.
His words were definitely along the lines if not exactly: OO is souped up ERD.
pat...@c837917-a.potlnd1.or.home.com
: His words were definitely along the lines if not exactly: OO is
: souped up ERD.
It seemed to me he said that part of UML is souped up ERD. It did not
seem to me he was describing OOP in general.
Let's all argue about what we think someone else said. No, let's
not. Go read DejaNews if you think it worthwhile.
Robert C. Martin
Ell wrote in message <3752ae63...@news1.radix.net>...
>"Ken O'Brien" <nom...@nomail.com> wrote:
>
>#Ell <univ...@radix.net> wrote in message
news:37504ed5...@news1.radix.net...
>#> 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 [] in fact the one trying to make ERD equivalent to OO, by saying
OO
>#> is just souped up [ERD].
>
>#I thought he was saying that UML contains an enhanced ERD, among other
things.
>#This seems quite different than saying OO is an enhanced ERD. Replacing
the
>#word UML with OO can't be done. Seems like that was implied in RCMs
comments
>#that UML is just a notation.
>
ERD.
The actual quote from article 7idc2f$491$1...@hirame.wwa.com was:
"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."
The entire article is reproduced below for your convenience.
============================================================================
==
From: "Robert C. Martin" <rma...@oma.com>
Subject: Re: UML Too Difficult for the Average Developer to Learn?
Date: 25 May 1999 00:00:00 GMT
Message-ID: <7idc2f$491$1...@hirame.wwa.com>
References: <7hq0q4$n27$1...@autumn.news.rcn.net>
<37412109...@earthlink.net>
Organization: WorldWide Access - Midwestern Internet Services - www.wwa.com
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3155.0
Newsgroups: comp.software-eng,comp.object
>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.
>
Tim Ottinger
>
> In comp.object Dennis Gearon <gea...@oit.edu> wrote:
> > Coming from an embedded point of view, I like the idea of CRC, which I
> > believe means "communication", "responsibility", and "control".
>
> technique for understanding how classes with specific responsibilities in
> a design will collaborate with each other to achieve the intended result
> or use case goal.
>
> years ago.
Absolutely true.
> > Let's
> > face it gals and guys, Programs only do three things: wait, decide what
> > to do, do it.
>
> I find that programs do other things also. Process, control, and provide
> services are some key ones.
That's the argument that the universe isn't just made out of
particles and waves, but also of chairs, planets, and people.
It's not an argument of content, but scale.
--
--------- 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
pat...@c837917-a.potlnd1.or.home.com
: univ...@saltmine.radix.net wrote:
: >
: > In comp.object Dennis Gearon <gea...@oit.edu> wrote:
: > > Coming from an embedded point of view, I like the idea of CRC, which I
: > > believe means "communication", "responsibility", and "control".
: >
: > Usually in OO it has meant "class responsibility collaboration". It is a
: > technique for understanding how classes with specific responsibilities in
: > a design will collaborate with each other to achieve the intended result
: > or use case goal.
: >
: > Wirfs-Brock and I think Goldberg introduced the idea in a book at least 10
: > years ago.
: Absolutely true.
No. Let's give credit where it is due. Ward Cunningham developed CRC
cards. Cunningham and Kent Beck furthered them and published the first
report on them. Wirfs-Brock adopted them and put them in book form for
the first time.
Ronald Garcia
univ...@radix.net (Ell) writes:
>
> "Ken O'Brien" <nom...@nomail.com> wrote:
>
> #I thought he was saying that UML contains an enhanced ERD, among other things.
> #This seems quite different than saying OO is an enhanced ERD. Replacing the
> #word UML with OO can't be done. Seems like that was implied in RCMs comments
> #that UML is just a notation.
>
> His words were definitely along the lines if not exactly: OO is souped up ERD.
>
> Elliott
Taken from DejaNews:
http://www.deja.com/getdoc.xp?AN=481782861
---<snip>---
UML is not a modeling technique. It is just a notation. And it't a lot
simpler than you make it seem.
...
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.
---<snip>---
doesn't sound like 'OO is souped up ERD' to me...
ron
Richard Smol
In a previous article, ian.o...@bcs.org.uk (Ian Oliver) says:
>Richard Smol wrote:
>
>> UML indeed lends itself to some abuse, just BECAUSE it's so flexible and
>> extensible. And if noone really understand sequence-diagrams, there is no
>> need to use any. On the other hand, UML is already useful at quite simple
>> levels.
>
>I've been trying to stay out of this debate but...UML is just a NOTATION -
>OK so you can bolt on processes but that's another matter. As for
>UML-abuse - you can abuse any notation/methodology etc, the one I keep
>on seeing is people modelling their code rather than the problem, ie: how
>to I write the UML for this C++ code, when you should be writing the
>C++/Java/whatever to fit the model.
There is nothing intrinsically wrong with designing using a programming
language. When you practice round-trip engineering you do that a lot.
The problem with Java and C++ is that those languages are really
quite unfit for that purpose. Eiffel on the other hand can be used as a
modelling language in its own right. You could also use CORBA IDL or ILU
ISL for the same purpose.
>In summary: UML is EASY - Modelling is HARD
My point exactly. If you don't grasp OO or modelling principles in general,
UML or any other notation is not of much use.
Greetz,
RS
Richard Smol
In a previous article, alan....@gssec.bt.co.uk (Alan Gauld) says:
>pat...@c837917-a.potlnd1.or.home.com wrote:
>> system. Deciding what the classes are should come *after* deciding what
>> the objects are!
>
>Hear hear!
>Its a fact not often explicitly stated in discussions of OOA.
Because it's not true. It all depends. Some systems benefit more from a
data-driven approach, where a static (class) model is more beneficial. If
the functional (e.g. behavioral) aspects of the system are more important,
than object models are usually better to start with. In the end, there
should be both class and object diagrams.
Greetz,
RS
pat...@c837917-a.potlnd1.or.home.com
: Because it's not true. It all depends. Some systems benefit more
: from a data-driven approach, where a static (class) model is more
: beneficial.
Why would a *class* model be appropriate for a *data* driven approach?
Can you provide an example? If I were to start with the data I would
be thinking of some kind of data model approach, not a class model.
Paul Campbell
Dennis Gearon wrote:
> Coming from an embedded point of view, I like the idea of CRC, which I
> believe means "communication", "responsibility", and "control". Let's
> face it gals and guys, Programs only do three things: wait, decide what
> to do, do it. The most problem I seee with code is no structure or
> simplicity in the decision making part of the program, unexplored sets
> of events and condtions causing problems with poor recovery. What else
> can object oriented programming do besides abstract the code for a set
> of datums and associated processes? I know it can save developer time if
> PROPERLY used.
> --
> ---------------------------------------------------------------
> I am here only to be truly helpful - Dennis Gearon
> ---------------------------------------------------------------
FFS if we wanted practical common sence we'ed be reading some programming
NG's. I mean whats up with you - your post didnt even demean the political
views
of the originator and attribute all his missconceptions to them.
Get with the program.
Paul.
--
-------------------------------------------------------------
"The trouble with democracy is that stupid people are
still allowed to vote" - Paul Campbell
-------------------------------------------------------------
Paul Campbell
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.
>
> Elliott
>
This is a spoof post right ?.
Though so, pretty funny actually.
Paul.
Paul Campbell
Sinan Si Alhir wrote:
> 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.
If somone isnt smart enough to learn UML they arent smart enough to develop
software.
Besides UML isnt *that* much more complex than the sum of the things youve
just mentioned - at lest not by an order of magnitude or anything like that.
Sinan Si Alhir
> 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
Sinan Si Alhir wrote:
> 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
Paul Campbell
argo...@my-deja.com wrote:
> I have a related question.
>
> What has been the experience of people
> using UML in general? Of using OOP in general?
>
> What were any benefits? Downfalls?
>
> Regards,
>
> Argosy
This question is a little too focussed I think. It might be more useful for
someone
just to give a quick overview of the sum of human knowledge to date.
Might I suggest that when you ask a question that is one of the most
fundamental
in modern software engineering that you at least start a new thread :).
Paul.
David B Lightstone
Paul Campbell wrote in message <3767C41D...@bigfoot.com.no-spam>...
>
>
>Sinan Si Alhir wrote:
>
>> 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.
>
>If somone isnt smart enough to learn UML they arent smart enough to develop
>software.
When you present your UML diagrams I trust there will be no managers
present!
They not you are the developer of the software, you simply are implementing
their
decisions. Occassionally they do defer to the expertise of their
subordinates.
On those occasions, when they realize that they do not understand enough to
make
a "good" decision, they indeed do make good decisions.
The reality of the matter is that UML functions as a communiucation media.
Whether it
is a formal language, or just a scribbling notation, is irrelevant. What is
relevant is
the complexity and extent of the alphabet. In my opinion it is too complex
and contains too many symbols. When a limited subset is used for a specific
task, it probably can be explained to those who are ignorant. The more
sophisticated
aspects require extensive training. It is in the mixing of the simple and
the sophisticated
where the difficulty for the average developer will occur. In the past some
shops
established coding standards in an effort the avoid misuse of a language.
Prior to
block structured programming languages these were to control abuses of the
GOTO
statement. At other times they were to limit the size of code to one reading
page. Eventually
shops will realized that the mix and match options of UML create
understandability
problems. When that occures UMLing standards will soon follow. In the mean
time
we all get to muddle on with our new silver bullet.
Ronald E Jeffries
<sal...@earthlink.net> wrote:
>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.)
Suggestion: Begin with Martin Fowler's excellent book, UML Distilled.
Start with simple diagrams using just basic notation. Every few days
when a specific need arises, add another feature.
Suggestion: If you're working sixty hour weeks, you're too tired to be
doing good software.
Suggestion: Use CRC design for figuring out what to do, not UML. UML
is perhaps decent for documenting a design if for some reason the team
cannot produce clear code or someone has dictated UML documentation.
It's far too slow a process for actually doing designing, even on the
whiteboard, and certainly if you're using a tool.
Ron Jeffries
Extreme Programmer
http://www.armaties.com
Martin Rand
(Ronald E Jeffries) wrote:
snip...
>
>Suggestion: Begin with Martin Fowler's excellent book, UML Distilled.
>Start with simple diagrams using just basic notation. Every few days
>when a specific need arises, add another feature.
>
I've come late to this thread. Has anyone mentioned also Doug
Rosenberg's book "Use Case Driven Object Modelling with UML"?
Martin Rand
Highfield Software Ltd
m...@hsl.tcp.co.uk
Phone: +44 1703 252445
Fax: +44 1703 252445
Paul Campbell
David B Lightstone wrote:
> Paul Campbell wrote in message <3767C41D...@bigfoot.com.no-spam>...
>
> >If somone isnt smart enough to learn UML they arent smart enough to develop
> >software.
>
> When you present your UML diagrams I trust there will be no managers
> present!
> They not you are the developer of the software, you simply are implementing
> their
> decisions.
LOL. What on earth have managers got to do with designing software ?. I have
*never* been in a situation where managers have been involved in anything
beyond user-level requirements. Use cases can be reduced to
plain english descriptions if need be and I see no need for non-technical people
to
get involved beyond that stage.
Then again what we call a "principal engineer" in the UK is called a "manager"
in the US.
Let em put it another way, what possible value can somone from a non-technical
background add any to sort of formal representation. FFS YOU are the engineer -
if you rmanager cant trust you and your peers to do the job then get the hell
out
of there to a position where your gonna get some respect.
Paul.
Paul Campbell
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 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.
Why do third parties want to know how it works ?.
I admit in my experience that people involved in requirements capture often
have strong implementation oriented preconceptions about how the reqs should
be met, This howerver needs to be brutally nipped in the bud and not encouraged
IMO - the "how" of it is a software issue and not a domain one. Im sorry
but I dont want systems engineers and users dabbling in software design.
In fact Ive had a few instances where "requirements" turned out to be the expected
characteristics of some pre-conceived system design:
E.g.:"downtime for daily system archiving should not exceed 5 miniutes" -
rather than "In the event of system failure, all data entered ealier than
xxx time interval should be recoverable".
Anyway requirements capture/anlysis can never be sufficient to build a
system with anything but non trivial architecture (like a single OS process)
and this especially true in a distributed object environment. There is huge tranche
of "architecture" stuff to do like client server topology (in the CORBA sence)
and inter-object API specifications. The analysis does not and should not
(IMO) concern itself with this.
BTW out-of-the box UML is indeed woefully inadaquate for the top level system
design/archtecture of a distributed system but the "Enterprise CORBA" book
has a nice set of extensions which address this.
Paul.
David B Lightstone
Paul Campbell wrote in message <3770C460...@bigfoot.com.no-spam>...
>
>
>David B Lightstone wrote:
>
>> Paul Campbell wrote in message <3767C41D...@bigfoot.com.no-spam>...
>>
>> >If somone isnt smart enough to learn UML they arent smart enough to
develop
>> >software.
>>
>> When you present your UML diagrams I trust there will be no managers
>> present!
>> They not you are the developer of the software, you simply are
implementing
>> their
>> decisions.
>
>LOL. What on earth have managers got to do with designing software ?.
Not all people who must read UML are developers. If you consider it to be
a drawing/communication notation, then you must determine the intended
audience of
the diagrams.
You appear to consider it to be only a design notation. Sorry, but it is
much more
than that.
> I have
>*never* been in a situation where managers have been involved in anything
>beyond user-level requirements.
I do not know how to state this but the design must somehow be reviewed. It
must somehow be compared to the requirements. You imply that the
participants
in these activities are knowledgable of UML.
What happens when you are developing a product that requires Governmental
certification (say a medical device or a control system for an airplane,
nuclear
reactor or weapon)? Do you really believe the everyone in the approval
process
will be fully knowedgable of UML?
>Use cases can be reduced to
>plain english descriptions if need be and I see no need for non-technical
people
>to
>get involved beyond that stage.
Quite true, but doesn't translating the USE cases to plain English, French,
German, etc
sort of defeat the purpose of the notation. Additionally it creates an
additional accuracy
verification in the process.
>
>Then again what we call a "principal engineer" in the UK is called a
"manager"
>in the US.
>
>Let em put it another way, what possible value can somone from a
non-technical
>background add any to sort of formal representation.
Very little, but then again they authorize the payment of funds.
> FFS YOU are the engineer -
>if you rmanager cant trust you and your peers to do the job then get the
hell
>out
>of there to a position where your gonna get some respect.
>
Well spoken, sadly the manager of the project may be an employee of a
different
organization. Consider a grid management based organization. Clearly your
technical leads and maybe even the technical manager will be sufficiently
competant, but what about the project gird manager and his staff.
>
>Paul.
>
>
>
David B Lightstone
Paul Campbell wrote in message <3770D895...@bigfoot.com.no-spam>...
>
>
>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 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.
>
>Why do third parties want to know how it works ?.
>
They may be required to do so by law (Medical devices, aircraft controls,
etc). The
communication of the design is to them.
>
>I admit in my experience that people involved in requirements capture often
>have strong implementation oriented preconceptions about how the reqs
should
>be met, This howerver needs to be brutally nipped in the bud and not
encouraged
>
Were it only possible
>IMO - the "how" of it is a software issue and not a domain one. Im sorry
>but I dont want systems engineers and users dabbling in software design.
>In fact Ive had a few instances where "requirements" turned out to be the
expected
>characteristics of some pre-conceived system design:
>
happens all the time. Like when you are told which operating system to use.
They
are design constraints, not requirements
>
>E.g.:"downtime for daily system archiving should not exceed 5 miniutes" -
>rather than "In the event of system failure, all data entered ealier than
>xxx time interval should be recoverable".
>
Not all requirements are well written, that's why they are subject to
negociation.
That's why the requirements analysts must probe to determine the true intent
of
the client
>
>Anyway requirements capture/anlysis can never be sufficient to build a
>system with anything but non trivial architecture (like a single OS
process)
>and this especially true in a distributed object environment. There is
huge tranche
>of "architecture" stuff to do like client server topology (in the CORBA
sence)
>and inter-object API specifications. The analysis does not and should not
>(IMO) concern itself with this.
>
UML probably can do such things. If true this would be one of its problems
in my opinion
Andy Dent
<pncam...@bigfoot.com.no-spam> wrote:
>Why do third parties want to know how it works ?.
Because they have been let down by programmers or disappointed by software
projects enough that they are totally paranoid.
If you can't explain how it works in their terms then there's a high
chance you have missed something or your understanding of the domain is
weak enough that your ability to translate requirements is limited.
>IMO - the "how" of it is a software issue and not a domain one.
I agree, but as responsible professionals we have to be able to explain
things with confidence.
>E.g.:"downtime for daily system archiving should not exceed 5 miniutes" -
>rather than "In the event of system failure, all data entered ealier than
>xxx time interval should be recoverable".
Huh?
These are NOT the same requirement.
One is about interruption to service. Your alternative is about data
retrieval and says nothing about the interruption.
(12yo memories of a 23x7 mine parts warehouse system come drifting back ...
you ain't seen a dirty terminal until you've seen a once-white VT220 from
the diesel fitters' bay at a coal mine!
:-)
>BTW out-of-the box UML is indeed woefully inadaquate for the top level system
>design/archtecture of a distributed system
and many other tasks.
I find UML disturbingly weak as a communications paradigm. It's like a
teaser for Rational's full $$ services and tools. I resent the way it was
sold to the commmunity as a "standard" compared to the cooperation
involved in (for example) the XML standards by the W3C.
In particular, UML totally fails to address one of the most important
issues - WHY a decision was made, not just the end results of the
decision.
(In case you're wondering what this has to do with a visual communications
language - there is no simple way to indicate variants or links to
variants in the standard. There should have been, along with a lot of
other hints to let CASE vendors present a better standard.)
You can always reverse engineer the results. You can't reverse engineer
the thinking process.
--
Andy Dent BSc MACS AACM, Software Designer, A.D. Software, Western Australia
OOFILE - Database, Reports, Graphs, GUI for c++ on Mac, Unix & Windows
PP2MFC - PowerPlant->MFC portability
http://www.oofile.com.au/
Paul Campbell
Andy Dent wrote:
> In article <3770D895...@bigfoot.com.no-spam>, Paul Campbell
> <pncam...@bigfoot.com.no-spam> wrote:
>
> >Why do third parties want to know how it works ?.
> Because they have been let down by programmers or disappointed by software
> projects enough that they are totally paranoid.
>
> If you can't explain how it works in their terms then there's a high
> chance you have missed something or your understanding of the domain is
> weak enough that your ability to translate requirements is limited.
>
> >IMO - the "how" of it is a software issue and not a domain one.
> I agree, but as responsible professionals we have to be able to explain
> things with confidence.
OK answer me this - why does this only happen with software then ?. I dont see
engineers
in other industries being routinely second guessed by non-technical managers and
users.
What exactly is the cause and effect here. Maybe the dabbling by users in the
design
is what causes poor designs and ultimately poor systems, if so then this is a
cycle we should
break. We need to get away from this idea that software is "easy" and that complex
systems
can be understood by a lay-person even superficially.
I mean, noone except a specialist would expect nuclear physicists to produce
equations
that they could understand to prove that a powerstation was safe would they, so
why
do people assume that any software system can be described "simply" ?.
>
> >E.g.:"downtime for daily system archiving should not exceed 5 miniutes" -
> >rather than "In the event of system failure, all data entered ealier than
> >xxx time interval should be recoverable".
> Huh?
>
> These are NOT the same requirement.
> One is about interruption to service. Your alternative is about data
> retrieval and says nothing about the interruption.
Yes but the user assumed that data backup would be done en-mess
causing a period of downtime or at least severly degraded performance. They then
felt the need to introduce a requirement to address this assumed characteristic
of the system.
My point is that the backup *mechanism* is not somthing the users should be
concerned
with at all. The users simply state thier availability and data recovery
requirements - we
the engineers assess their viability and design the system to meet them.
Paul.
John Doe
>In particular, UML totally fails to address one of the most important
>issues - WHY a decision was made, not just the end results of the
>decision.
>
>(In case you're wondering what this has to do with a visual communications
>language - there is no simple way to indicate variants or links to
>variants in the standard. There should have been, along with a lot of
>other hints to let CASE vendors present a better standard.)
>
>You can always reverse engineer the results. You can't reverse engineer
>the thinking process.
Directly on target!
Object-oriented design in general and UML use efficient causation
analysis rather than final causation analysis.
This is the essential difference between the object-oriented approach
and the functional decomposition approach.
The object-oriented system decomposition systematically equivocates
between blind cause-effect and purposeful, goal-directed causation.
Object-oriented thinking is nothing more than dialectical reasoning
applied to software.
Aristotle draws the essential distinction between dialectical reasoning
and demonstrative reasoning in the first few paragraphs of his book on
deductive logic. It's worth looking at if you've been trying to understand
what "object-oriented" really means.
Tim McDermott
Paul Campbell wrote:
>
> OK answer me this - why does this only happen with software then ?. I dont see
> engineers
> in other industries being routinely second guessed by non-technical managers and
> users.
I think there are two things at work here. The first thing is that
software is non-tangible, and so people who are not intimate with the
vicissitudes of building software can't guess how hard it is to build by
looking at it.
The second, related issue is that lots of people have written small
programs in basic or logo and think that is all there is to software.
It is obvious that having thrown a plank across a ditch does not make a
person quaified to build the Golden Gate bridge. It is not obvious to a
lay person that complex programs are complex, hard, or require
specialized expertise to build.
Tim
cde...@my-deja.com
> I've come late to this thread. Has anyone mentioned also Doug
> Rosenberg's book "Use Case Driven Object Modelling with UML"?
Very few of the books I have read reveal lessons learned from real use
case projects. One of the few that does is "Applying Use Cases: A
practical guide" by Geri Schneider. Best white paper I have read so
far, and a must read is "Literate Modelling-Capturing Business Knowledge
with UML" at http://www.literatemodelling.com/papers.htm. It basically
says your customers (managers, people you are building the system for)
don't understand anything except Use Cases and Use Case diagrams. I
agree with the authors on this point.
I have a laundry list of problems with Use Cases. One of the biggest is
organizing them. UML notation of packages is insufficient because it
does little in terms of presenting the use case in groups; its more of a
convenient storage mechanism with little value added. Trying to create
'parent' or 'system' use cases to organize other use cases is even
worse. Having said that, I am still a big fan of use cases. Quote from
our last team doing structured a&d "The only reason we got through the
rqts was that we were so disgusted with the process (lines of text for
rqts) that after 4 weeks well all gave up-and that is how we completed
the rqts"
When your first start developing a use case put a great deal of thought
into the name, purpose, and pre/post conditions. These are more
imporant than the guts of the use case, believe or not. You can always
fill in the rest later, but going back and trying to reorganize use
cases that were not built properly (i.e. trying to do too much in one)is
a real mess because the developers can't seem to accept trashing what
they have already built; that usually just want to modify it.
Finally, remember that use case are usually your rqts, and rqts have to
be testable. I don't think many developers realize this, given the kinds
of statements I see in use case which are often a paragraph. Keep steps
limited to simple statements that are testable.
I'll get off the soapbox now.
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Andy Dent
<pncam...@bigfoot.com.no-spam> wrote:
>Andy Dent wrote:
>
>> >Why do third parties want to know how it works ?.
>> Because they have been let down by programmers or disappointed by software
>> projects enough that they are totally paranoid.
>OK answer me this - why does this only happen with software then ?. I dont see
>engineers in other industries being routinely second guessed
>by non-technical managers and users.
Other industries don't have a scary a history of failure as software.
>What exactly is the cause and effect here. Maybe the dabbling by users in the
>design is what causes poor designs and ultimately poor systems
Look, I don't know what your situation is that led to this gripe but I think
you are are doing people a major disservice by blaming user participation
in design.
If there can be said to be a single problem it is schedule pressure. This has
been well documented by people such as Steve McConnell ("Rapid
Development" & "Software Project Survival Guide") and in a great
"Communications of the ACM" article by Robert Glass (Dec 98 Vol 41.12 -
"Practical Programmer - How Not to Prepare for a Consulting Assignment and
other Ugly Truths").
In software, more than any other production domain, it is possible to
a) make decisions which trade off reliability for time
b) have crap accepted by the market.
Given those realities, the resulting economic system ensures that most
commercial results will be of relatively low quality.
The same model applies to corporate environments. As companies almost
never measure the true cost of stress and poor tools on their employees,
they fail to bring the true cost of bad software to the surface. Hence
judgements on the balance sheet are made on partial information and the
results cause the kind of angst you perceive.
Have a bit of empathy - most of the time the poor sods trying to get
involved in your process are driven by equal desperation to improve
things. I suggest you try to find ways to make their participation pay off
rather than arguing against it.
Thomas Letzkus
<mcde...@draper.com>:
>
>The second, related issue is that lots of people have written small
>programs in basic or logo and think that is all there is to software.
I think this is the main problem: Everybody nowadays can, and is able
to, write programs, but when it comes to develop software, there's
the difference.
And I guess that the people that 'kill' software projects by imposing
unrealistic restrictions are rather, but not granted, program-writers
(if at all) than software-developers.
Greetings from Switzerland
Thomas Letzkus
-----------------------------------------------------------------------------------------------------
eMail: Thomas....@writeme.com
-----------------------------------------------------------------------------------------------------
NB: Delete TTT from the address to reply
Colin Stock
>
> Andy Dent writes:
>
[snip]
> analysis rather than final causation analysis.
>
analysis and what is "final causation analysis"? How do they differ?
Why isn't final causation analysis efficient?
[snip]
> between blind cause-effect and purposeful, goal-directed causation.
>
"purposeful, goal directed causation".
> applied to software.
>
[snip]
--
========================================================================
Colin Stock colin...@gecm.com
Doh.