Booch Vs Rumbaugh's OMT
P.J. Sitoh
I find Booch to be a better methodology in that it provide consistent
support over the entire software development life cycle. OMT methodology is
only relevent for the analysis phase of oo software development.
Any comments or counter argument?
Satish Thatte
>
> I find Booch to be a better methodology in that it provide consistent
> support over the entire software development life cycle. OMT methodology is
> only relevent for the analysis phase of oo software development.
Could someone post a short summary of the Booch methodology?
I have tried to read Booch's book (2nd edition) but couldn't
see any well-defined methodology, just a bunch of advice.
Satish
Ell
> Booch Vs OMT?
>
> I find Booch to be a better methodology in that it provide consistent
> support over the entire software development life cycle. OMT methodology is
> only relevent for the analysis phase of oo software development.
I just completed reading Rumbaug et al's book on System Design and Object
Design and I would beg to differ that it has no relevance for OOD. In
fact it is very relevant and meaty, IMHO. I think there is a lot to get
from _both_ books on OOD.
Elliott
Ell
The Booch has more application development examples and is in that sense
more meaty with respect to Design. However, Rumbaugh et al's book deals
pretty comprehensively with the key and many ancillary concepts involved in
Object Design. They demonstrate, in a detailed way, the design of Objects
based on the Analysis and the System Design determined earlier. I found a
lot in common with R. Martin's Object Design method demonstrated in his
recent articles in "C++ Report".
BTW, they also emphasize how the whole development process, including
getting Object Design right, is also based on iterating the whole process.
Elliott
Ell
> In <3aq8gd$j...@library.erc.clarkson.edu> sat...@gandalf.mcs.clarkson.edu
> writes:
> > Could someone post a short summary of the Booch methodology?
> >
> > I have tried to read Booch's book (2nd edition) but couldn't
> > see any well-defined methodology, just a bunch of advice.
>
> And that's all it should be.
>
> Elliott
Actually, there is a method: 1) Get client requirements. 2) Analysis to
discover the abstractions underlying the application space leading to an
object model which can be used to understand the space. Employ use cases
and responsibilities as the key analytical tools. 3) Use the object
model to determine the system's overall architecture. 4) Use the
architecture to refine the abstractions in the object model. 5) Code the
abstractions and architecture from steps 3 and 4. 6) Test the system by
having the client use it.
Analysis should initially focus on discovering the fundamental set of
application space abstractions. The whole process loops. There is uneven
development of the things within a step. There should be feedback from
each step to all prior steps. To paraphase Booch, these are guidelines not
dogma to be applied mechanically.
Elliott
Ell
The object model consists of 3 models: an abstraction (classes and
associations), state and process (data transformation) models. Generally,
the abstraction model is key, but the application space actually determines
the relative weight each model has.
And the above is Rumbaugh et al's Object Modeling Technique (OMT) method.
Also Booch and Rumbaugh have recently teamed up.
Elliott
Ell
writes:
And that's all it should be.
Elliott
Ell
> >
> > Actually, there is a method: 1) Get client requirements. 2) Analysis to
> > discover the abstractions underlying the application space leading to an
> > object model which can be used to understand the space. Employ use cases
> > and responsibilities as the key analytical tools. 3) Use the object
> > model to determine the system's overall architecture. 4) Use the
> > architecture to refine the abstractions in the object model. 5) Code the
> > abstractions and architecture from steps 3 and 4. 6) Test the system by
> > having the client use it.
> >
> > Analysis should initially focus on discovering the fundamental set of
> > application space abstractions. The whole process loops. There is uneven
> > development of the things within a step. There should be feedback from
> > each step to all prior steps. To paraphase Booch, these are guidelines not
> > dogma to be applied mechanically.
>
> The object model consists of 3 models: an abstraction (classes and
> associations), state and process (data transformation) models. Generally,
> the abstraction model is key, but the application space actually determines
> the relative weight each model has.
>
> And the above is Rumbaugh et al's Object Modeling Technique (OMT) method.
> Also Booch and Rumbaugh have recently teamed up.
I guess no mention of the Booch method would be complete without
mentioning project management especially with regard to the macro and
micro aspects of development. One of the central features of the macro
aspect is release planning -- developing a timeline and feature set for
each release. This drives the micro aspect which is iteration through the
stages the development between each release. External releases to the
client help to keep the project focused and internal releases serve the
internal development process. Booch also advocates mini-development efforts
on the side, which focus on a particular aspect of the overall effort. Work
from the mini effort is incorporated into the overall project in a planned
way.
Elliott
George Yuan
: >
: > only relevent for the analysis phase of oo software development.
: I just completed reading Rumbaug et al's book on System Design and Object
: Design and I would beg to differ that it has no relevance for OOD. In
: fact it is very relevant and meaty, IMHO. I think there is a lot to get
: from _both_ books on OOD.
I beg differ. OMT is very very weak on OOD. There is no object and dynamic
models for design. All the models are for analysis of real-world objects.
How can we specify the system and classes we want to build?
--
George Yuan
Senior OO Architect and Consultant
IBM Object-Oriented Technology Center
Email: yu...@ralvm29.vnet.ibm.com
(919) 254-7317 (Work)
George Yuan
: In <3aqo1q$7...@nova.umd.edu> COA...@UMUC.UMD.EDU writes:
: The Booch has more application development examples and is in that sense
: more meaty with respect to Design. However, Rumbaugh et al's book deals
: pretty comprehensively with the key and many ancillary concepts involved in
: Object Design. They demonstrate, in a detailed way, the design of Objects
: based on the Analysis and the System Design determined earlier. I found a
: lot in common with R. Martin's Object Design method demonstrated in his
: recent articles in "C++ Report".
Booch has rich notations for design, but failed to point out how to derive
out a design from analysis. We need to understand analysis is very key
to design. The mapping process is missing in Booch method.
Rumbaugh et al. simply mentioned a couple of issues in design, but it cannot
be considered as OOD.
My colleagues and I in IBM OOTC have extended Rumbaugh et al.'s object modeling
notation into Object Model at the Analysis Level, and Object Model at the Design
Level. At the design level, all the associations are directional and represents
physical links (no more conceptual links). There is no "association class"
in design either.
We think Jacobson's Object-Interaction Diagram is very easy to use and powerful
in modeling. We extend it into OID at the analysis level, and OID at the design
level. The former CAPTURES FACTS about dynamic behaviors of real-world objects
in OOA, and the latter SPECIFIES the design of dynamic behaviors of system
objects. The resulting specification from OOD will be implemented. The
OID description from OOA form the basis for mapping classes in the problem
domain to the solution domains.
Send me your snailmail address, and I will send you one paper about our
method. Feedback is also asked.
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> : The Booch has more application development examples and is in that sense
> : more meaty with respect to Design. However, Rumbaugh et al's book deals
> : pretty comprehensively with the key and many ancillary concepts involved in
> : Object Design. They demonstrate, in a detailed way, the design of Objects
> : based on the Analysis and the System Design determined earlier. I found a
> : lot in common with R. Martin's Object Design method demonstrated in his
> : recent articles in "C++ Report".
> Booch has rich notations for design, but failed to point out how to derive
> out a design from analysis. We need to understand analysis is very key
> to design. The mapping process is missing in Booch method.
I use the second edition of OOA&D and he does everything you say he
doesn't there.
> Rumbaugh et al. simply mentioned a couple of issues in design, but it cannot
> be considered as OOD.
It's a _lot_ more than a couple.
> My colleagues and I in IBM OOTC have extended Rumbaugh et al.'s object
> modeling
> notation into Object Model at the Analysis Level, and Object Model at the
> Design
> Level. At the design level, all the associations are directional and
> represents
> physical links (no more conceptual links).
Sounds _just_ like Booch and OMT to me.
> There is no "association class" in design either.
>
> We think Jacobson's Object-Interaction Diagram is very easy to use and
> powerful
> in modeling. We extend it into OID at the analysis level, and OID at the
> design
> level. The former CAPTURES FACTS about dynamic behaviors of real-world
> objects
> in OOA, and the latter SPECIFIES the design of dynamic behaviors of system
> objects. The resulting specification from OOD will be implemented. The
> OID description from OOA form the basis for mapping classes in the problem
> domain to the solution domains.
Sounds _just_ like Booch and OMT to me.
Elliott
Ell
> : > only relevent for the analysis phase of oo software development.
[This quote was _not_ Elliott's. Elliott.]
> Ell (COA...@UMUC.UMD.EDU) wrote:
> : I just completed reading Rumbaug et al's book on System Design and Object
> : Design and I would beg to differ that it has no relevance for OOD. In
> : fact it is very relevant and meaty, IMHO. I think there is a lot to get
> : from _both_ books on OOD.
> I beg differ. OMT is very very weak on OOD. There is no object and dynamic
> models for design. All the models are for analysis of real-world objects.
> How can we specify the system and classes we want to build?
Use the various models from Analysis including the object model and modify
them. On the basis of Analysis models, create new models in Design. That's
what both OMT and Booch advocate.
The object (abstractions and associations), and dynamic (state) models
are two of the 3 models both the OMT and Booch method suggest should be
created during Analysis. The other is the functional model (data
transformation). These models along with requirements serve as the
primary inputs to the Design stage. They are modified in the Design
stage, where they become Design models as opposed to Analysis models.
The Analysis models still exist and receive feedback from Design, but
new Design models are generated in the Design stage and serve as key
elements for input to the Implementation stage.
Elliott
Ell
> Rumbaugh et al. simply mentioned a couple of issues in design, but it
> cannot be considered as OOD.
Rumbaugh et al's book deals with the key, and many ancillary concepts,
involved in System and Object Design. They demonstrate, in a detailed
way, the design of Objects and Subsystems based on the Analysis and overall
System Design determined earlier. (See Rumbaugh et al, OOM&D chapters 9
10 and 11) [chapter 9 for System Design and chapter 10 for Object Design,
chapter a short summary; 67 pages of dense material]
Elliott
P.J. Sitoh
> Booch Vs OMT?
> I find Booch to be a better methodology in that it provide consistent
> support over the entire software development life cycle. OMT methodology is
> only relevent for the analysis phase of oo software development.
^^^^^^^^
> Any comments or counter argument?
--------------------------- Reply -------------------------------------------
In my last article, I may have given the impression that OMT has _NO_
relevence to OOD. Instead what I should have said is that I have
reservations about OMT as an adequate methodology for oo software
development. My reservations are as follows:
(a) The functional modeling element in OMT. Now I'm not suggesting that
functional modeling has no place in object-orientation, but it is "good"
practice to avoid it. Functional modeling has the danger of drawing one's
mindset away from the OO mindset. As Booch indicated functional modeling
is "orthogonal" to the OO paradigm.
(b) In Booch there is the emphasis on the distinction between a "logical"
view and a "physical" view. For instance, note Booch's distinction
between a 'class category' (i.e. the logical view) and a 'module' (i.e.
the physical view). OMT don't make that distinction and it is not good
design practice to mix the logical and physical. My reasoning is best
illustrated by the following analogy.
Imagine an architect wanting to build his or her dream house. At the
onset, the architect is most likely produce a schematic (i.e. logical
view) of his or her dream house, quite possibly, at the back of an
envelope. Now it is quite inconceivable that the architect would use the
schematic as the basis of a blue-print. For a blue print, the
architecture would most likely have to produced a scaled drawing (i.e.
physical view) of his or her dream-house.
Likewise in oo development, we use the class diagram to show the logical
relationship between classes. We then use the module diagram to show the
physical relationships between programming units (e.g. in C++, the
relationship between .cpp and .h files).
(c) OMT bundles the notations for the construction of class-relationships
and object-relationships under the same banner as notations for "Object
Modeling". Again my feeling is that it is inherently a bad practice.
Paul Sitoh
Ian Mitchell
>From: "P.J. Sitoh" <P.J....@ncl.ac.uk>
>Subject: Booch Vs Rumbaugh's OMT
>Date: 21 Nov 1994 09:11:48 GMT
>Booch Vs OMT?
Booch offers 6 views of a system - class, object, STD, interaction, module, and
process, compared to Rumbaugh's 3 - object (really a hybrid class/object),
dynamic and functional. The Booch system is therefore potentially more
rigorous and better suited for design documentation. However, it can be
argued that the tripartite orthogonal views supported in OMT are
nonetheless rigorous enough for the entire lifecycle, not just for analysis.
This would be borne out by the fact that OMTool supports code generation.
Regards, Ian Mitchell
-----------------------------------------------------
Ian Mitchell Ian.Mi...@sunderland.ac.uk
-----------------------------------------------------
sic biscuitus disintegrat
-----------------------------------------------------
Ell
> (c) OMT bundles the notations for the construction of class-relationships
> and object-relationships under the same banner as notations for "Object
> Modeling". Again my feeling is that it is inherently a bad practice.
But two distinct diagrams are created for the class and object models
respectively. Taken together, OMT calls them the Object model. The
notation and semantics of each kind of diagram is different from the
other. The differences arise from their different purposes.
Elliott
Ell
> Booch offers 6 views of a system - class, object, STD, interaction, module,
> and
> process, compared to Rumbaugh's 3 - object (really a hybrid class/object),
> dynamic and functional. The Booch system is therefore potentially more
> rigorous and better suited for design documentation.
There have been 4 models in OMT to this point. 4 models because OMT's
object diagram is not a hybrid, there are two different models in the
diagram. There is a class model with classes and associations and
an object model with objects/instances and links.
Also in the October JOOP, Rumbaugh begins to lay out notation for
subsystems. So that's 5.
> However, it can be
> argued that the tripartite orthogonal views supported in OMT are
> nonetheless rigorous enough for the entire lifecycle, not just for analysis.
> This would be borne out by the fact that OMTool supports code generation.
Elliott
Paul Harapiak
>notation into Object Model at the Analysis Level, and Object Model at the Design
>Level. At the design level, all the associations are directional and represents
>physical links (no more conceptual links). There is no "association class"
>in design either.
>
>We think Jacobson's Object-Interaction Diagram is very easy to use and powerful
>in modeling. We extend it into OID at the analysis level, and OID at the design
>level. The former CAPTURES FACTS about dynamic behaviors of real-world objects
>in OOA, and the latter SPECIFIES the design of dynamic behaviors of system
>objects. The resulting specification from OOD will be implemented. The
>OID description from OOA form the basis for mapping classes in the problem
>domain to the solution domains.
>
>Send me your snailmail address, and I will send you one paper about our
>method. Feedback is also asked.
>
This sounds very interesting, I'd like a copy of your paper.
Here's my address:
96 Pandora Avenue North
Kitchener, Ontario
Canada N2H 3C6
Thanks in advance.
P.J. Sitoh
> Elliott
OMT do mix notations. Look at the way OMT models propagation of
operations (see pg 60 of Rumbaugh et al's book). Unless, I have
misunderstood the definition, I presume propagation means 'message
passing'.
In OMT propagation is modelled by a line drawn between two rectangles,
with an arrow parallel to the line. New if rectangles were meant to represent
classes, then there is a semantic anomaly in the way OMT models propagation
- classes don't propagate behaviours. Only objects do!
Paul Sitoh
Robert Martin
>sat...@gandalf.mcs.clarkson.edu writes:
>> I have tried to read Booch's book (2nd edition) but couldn't
>> see any well-defined methodology, just a bunch of advice.
COA...@UMUC.UMD.EDU (Ell) writes:
>And that's all it should be.
Well, yes and no. I recommend reading through the book again. You
will find that there is a method hidden in there. However, that
method is not a 1. -- 2. -- 3. -- step by step process. Is is a set
of forces that push and prod you in different direction.
In my book, I have attempted to express those forces as *principles*
that the OO designer can focus upon and can measure (numerically) his
design against.
Designing Object Oriented C++ Applications using the Booch Method
Robert Martin
Prentice Hall, 1995
ISBN 0-13-203837-4
--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
Robert Martin
>(a) The functional modeling element in OMT. Now I'm not suggesting that
>functional modeling has no place in object-orientation, but it is "good"
>practice to avoid it. Functional modeling has the danger of drawing one's
>mindset away from the OO mindset. As Booch indicated functional modeling
>is "orthogonal" to the OO paradigm.
True. But software design takes place in N-Dimensional space.
Orthogonality is a strength not a weakness. It allows the space to be
explored in a direction which does not interfere with other aspects of
the design.
Now, in SA/SD, functional modeling *defined* the static structure of
the software. Thus, it was not orthogonal, it was tightly coupled.
But in OMT there is no such coupling. Functional modeling is simply a
way to express the functional model, not the static structure of the
software.
>(b) In Booch there is the emphasis on the distinction between a "logical"
>view and a "physical" view. For instance, note Booch's distinction
>between a 'class category' (i.e. the logical view) and a 'module' (i.e.
>the physical view). OMT don't make that distinction and it is not good
>design practice to mix the logical and physical. My reasoning is best
>illustrated by the following analogy.
True as far as it goes. I agree that Booch has done more work than
Rumbaugh in this regard, however these concerns could be added to OMT
without much problem. (And I am sure that they will be.)
>Likewise in oo development, we use the class diagram to show the logical
>relationship between classes. We then use the module diagram to show the
>physical relationships between programming units (e.g. in C++, the
>relationship between .cpp and .h files).
Don't forget the most important of all: Category diagrams, which depict the physical architecture, release structure and reuse structure.
P.J. Sitoh
> >(a) The functional modeling element in OMT. Now I'm not suggesting that
> >functional modeling has no place in object-orientation, but it is "good"
> >practice to avoid it. Functional modeling has the danger of drawing one's
> >mindset away from the OO mindset. As Booch indicated functional modeling
> >is "orthogonal" to the OO paradigm.
Robert Martin (rma...@rcmcon.com) wrote:
> True. But software design takes place in N-Dimensional space.
> Orthogonality is a strength not a weakness. It allows the space to be
> explored in a direction which does not interfere with other aspects of
> the design.
> Now, in SA/SD, functional modeling *defined* the static structure of
> the software. Thus, it was not orthogonal, it was tightly coupled.
> But in OMT there is no such coupling. Functional modeling is simply a
> way to express the functional model, not the static structure of the
> software.
----------- in response to Robert Martin -----
The strength or otherwise of orthogonality is not the issue. Nevertheless, I
agree with the gists of Robert's argument. I guess one can say that
functional modeling helps one, to coin a famous phrase in star trek,
"to boldly go where o-o has not gone before".
When I brought out the issue of functional modeling, I was troubled by
the role of functional modeling in O-O. If, as Robert noted, functional
modeling in OMT is not meant to define the static structure of the
software then what is it for, in the context of O-O?
Since I have no hand in the creation of OMT, I can only guess that
Rumbaugh_et_al saw functional modeling as a way of discovering or
validating object behaviour. If so, won't Jacobson's use case analysis be
a 'more appropriate' approach?
Paul Sitoh.
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> > In <3b1tni$m...@whitbeck.ncl.ac.uk> P.J....@ncl.ac.uk writes:
>
> > > (c) OMT bundles the notations for the construction of class-relationships
> > > and object-relationships under the same banner as notations for "Object
> > > Modeling". Again my feeling is that it is inherently a bad practice.
>
> > But two distinct diagrams are created for the class and object models
> > respectively. Taken together, OMT calls them the Object model. The
> > notation and semantics of each kind of diagram is different from the
> > other. The differences arise from their different purposes.
>
> > Elliott
>
> OMT do mix notations. Look at the way OMT models propagation of
> operations (see pg 60 of Rumbaugh et al's book). Unless, I have
> misunderstood the definition, I presume propagation means 'message
> passing'.
It means for instance that copying a document copies the paragrpaphs and
character the document consists of.
>
> In OMT propagation is modelled by a line drawn between two rectangles,
> with an arrow parallel to the line. New if rectangles were meant to represent
> classes, then there is a semantic anomaly in the way OMT models propagation
> - classes don't propagate behaviours. Only objects do!
I think their point is that an operation on one type (class) can affect
other types (classes). Sure only objects can be instantiated, but their
nature is defined by their class type.
Elliott
Desmond Dsouza
<3b7lk7$4...@whitbeck.ncl.ac.uk> "P.J. Sitoh" <P.J....@ncl.ac.uk> writes:
On the 24 Nov 1994 "P.J. Sitoh" <P.J....@ncl.ac.uk> writes:
> >(a) The functional modeling element in OMT. Now I'm not suggesting that
> >functional modeling has no place in object-orientation, but it is "good"
> >practice to avoid it. Functional modeling has the danger of drawing one's
> >mindset away from the OO mindset. As Booch indicated functional modeling
> >is "orthogonal" to the OO paradigm.
It is effective, in some situations, to specify an operation in terms
of its pre-conditions and post-conditions (and exceptions, and ...).
[This is not unique to OO, but can be leveraged effectively in OO due
to encapsulation and polymorphism.]
In order to express the pre- and post-conditions we need:
A: a base vocabulary . This vocabulary can be provided by:
- logical attributes (not data storage, just appropriate 'views' of
hypothetical internal state)
- 'view'-functions (logical attributes with parameters)
- even in terms of object-model and state-model like pictures, provided
we focus on the 'before' and 'after' configurations, and
are clear about their interpretation.
B: a language to compose these with, e.g. using logical operations
like =>, <=>, &, |, sets, sequences. This 'language' itself may be
extensible if it is object-based.
So where does 'functional modeling' fit in? A specification of pre-
and post-conditions itself is often simplified by using auxiliary
(convenience) functions and local variables. These may or may not be
'encapsulated', but there is usually no reason to force them to be at
this level. And we can use flow-graph notation to visually depict the
operation specification (compilers do this all the time).
It is possible to get a very coherent integration of OMT-style models,
including the object, dynamic, and "functional" model, on this basis.
It is also possible to carry the approach through design and down to
code. We've done it and use it a lot.
Desmond D'Souza
-----------------------
ICON Computing, Inc.
OO Education and Consulting
12343 Hymeadow Drive, Suite 3C Austin, TX 78750
(v) 512.258.8437 (f) 512.258.0086 (e) in...@iconcomp.com
--
-----------
12343 Hymeadow Drive, Suite 3C
Austin, TX 78750
Desmond Dsouza
> >(a) The functional modeling element in OMT. Now I'm not suggesting that
> >functional modeling has no place in object-orientation, but it is "good"
> >practice to avoid it. Functional modeling has the danger of drawing one's
> >mindset away from the OO mindset. As Booch indicated functional modeling
> >is "orthogonal" to the OO paradigm.
It is effective, in some situations, to specify an operation in terms
Ell
>(a) The functional modeling element in OMT. Now I'm not suggesting that
>functional modeling has no place in object-orientation, but it is "good"
>practice to avoid it. Functional modeling has the danger of drawing one's
>mindset away from the OO mindset. As Booch indicated functional modeling
>is "orthogonal" to the OO paradigm.
Booch and OMT advocate building various types of models. They say that each
model is "orthogonal" to the others, with the class and object models being
key in OOA and OOD. So that the functional model is "orthogonal" to the
others, as they all are to each other, but that doesn't mean that the
functional model is "orthogonal" to the "OO paradigm".
Elliott
Ell
> >sat...@gandalf.mcs.clarkson.edu writes:
> >> I have tried to read Booch's book (2nd edition) but couldn't
> >> see any well-defined methodology, just a bunch of advice.
>
> COA...@UMUC.UMD.EDU (Ell) writes:
> >And that's all it should be.
>
> Well, yes and no. I recommend reading through the book again. You
> will find that there is a method hidden in there.
Yes, and I summarized most of the key elements here.
> However, that method is not a 1. -- 2. -- 3. -- step by step process.
> Is [It] is a set of forces that push and prod you in different direction.
I have read most sections once and more. I still get the understanding
that the Booch method is iterative (looping) and incremental (sequential)
as in 1, 2, 3, .... Witness the macro and micro aspect of Booch's
"Evolution". The macro process is an iterative development management
process having step by step incremental progress which has micro
iterations through all of the stages - OOA, OOD and OOP - occuring between
each executable release.
Elliott
Ell
> In <3b4vd1$f...@whitbeck.ncl.ac.uk> P.J....@ncl.ac.uk writes:
> > OMT do mix notations. Look at the way OMT models propagation of
> > operations (see pg 60 of Rumbaugh et al's book). Unless, I have
> > misunderstood the definition, I presume propagation means 'message
> > passing'.
> It means for instance that copying a document copies the paragrpaphs and
> character the document consists of.
>
> Elliott
Propagation means, for instance, that copying a document copies the
[paragraphs] and character[s] the document consists of.
Elliott
P.J. Sitoh
> Booch and OMT advocate building various types of models. They say that each
> model is "orthogonal" to the others, with the class and object models being
> key in OOA and OOD. So that the functional model is "orthogonal" to the
> others, as they all are to each other, but that doesn't mean that the
> functional model is "orthogonal" to the "OO paradigm".
> Elliott
In functional modeling your mindset is focussed on the input/output
entities and transformation entities that are found in a problem domain.
In object-orientation, the focus of attention is the agents(i.e. objects)
in a problem domain and also how these agents collaborate with one another.
That is what I mean by functional analysis (modelling) being orthogonal
to the OO paradigm.
Paul Sitoh
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> > Booch and OMT advocate building various types of models. They say that each
> > model is "orthogonal" to the others, with the class and object models being
> > key in OOA and OOD. So that the functional model is "orthogonal" to the
> > others, as they all are to each other, but that doesn't mean that the
> > functional model is "orthogonal" to the "OO paradigm".
> In functional modeling your mindset is focussed on the input/output
> entities and transformation entities that are found in a problem domain.
>
> In object-orientation, the focus of attention is the agents(i.e. objects)
> in a problem domain and also how these agents collaborate with one another.
Right, and doesn't it aid in understanding the objects to have a diagram
of how data flows between them and is transformed by them? The functional
diagram helps us to understand the objects.
Regards,
Elliott
Robert Martin
>The strength or otherwise of orthogonality is not the issue. Nevertheless, I
>agree with the gists of Robert's argument. I guess one can say that
>functional modeling helps one, to coin a famous phrase in star trek,
>"to boldly go where o-o has not gone before".
Functional decomposition is an important part of OO. In OO we
decompose the function of the application into methods that are
protected by abstract interfaces, and intrinsically associated with
the data they manipulate.
If you take a close look at Booch's object diagrams, or Rumbaugh's
counterpart, you will find that they have aspects of a DFD within
them. They are more than a DFD, but they *do* show data and process
and their interrelations and interactions. So, OO has been to the
land of "functional modelling", but the terrain may not be immediately
recognizable.
>When I brought out the issue of functional modeling, I was troubled by
>the role of functional modeling in O-O. If, as Robert noted, functional
>modeling in OMT is not meant to define the static structure of the
>software then what is it for, in the context of O-O?
Sometimes the best way to discover the objects within an application
is to perform a functional decomposition first. There are times
(believe it or not) when a data flow diagram exposes the object
structure of an application and leads to a very nice OOD.
>Since I have no hand in the creation of OMT, I can only guess that
>Rumbaugh_et_al saw functional modeling as a way of discovering or
>validating object behaviour. If so, won't Jacobson's use case analysis be
>a 'more appropriate' approach?
Use cases answer a different question. They describe the closed loop
between the user and the system. DFDs describe the different
functions that participate in that loop and the data that flows
between them.
--------
There is no such thing as an invalid tool. If DFDs are appropriate to
the problem, use them. If you can learn something by drawing a
flowchart, draw one. There is no edict in OO that proscribes any kind
of tool.
Robert Martin
>Elliott
My point is that sometimes you do some of 2 and 3 before you have
finished with 1. There is no strict procedure. You cannot, and
should not, draw a flowchart showing the steps and decision branches.
The process must remain fluid and dnynamic.
Ell
> COA...@UMUC.UMD.EDU (Ell) writes:
>> In <1994Nov25....@rcmcon.com> rma...@rcmcon.com writes:
>>> However, that method is not a 1. -- 2. -- 3. -- step by step process.
>>> Is [It] is a set of forces that push and prod you in different direction.
>>>>I have read most sections once and more. I still get the understanding
>>>>that the Booch method is iterative (looping) and incremental (sequential)
>>>>as in 1, 2, 3, .... Witness the macro and micro aspect of Booch's
>>>>"Evolution". The macro process is an iterative development management
>>>>process having step by step incremental progress which has micro
>>>>iterations through all of the stages - OOA, OOD and OOP - occuring between
>>>>each executable release.
>>>>Elliott
> My point is that sometimes you do some of 2 and 3 before you have
> finished with 1. There is no strict procedure. You cannot, and
> should not, draw a flowchart showing the steps and decision branches.
> The process must remain fluid and dnynamic.
Agreed about doing "some of 2 and 3 before you have finished with 1".
This is true given the iterative nature of OOADP. However, I think it's a
good idea to lay out the formal incremental side of OOADP, and let the
experts shortcut as they see appropriate. And even for non-experts, the
formal method also specifies the iterative aspect. Meaning that they should
know that they should iterate through the development process, first
concentrating work on analyzing and designing the fundamental set of
functionality and then on the others. (Not that we'll be able to finish
them all on the first pass, just that it should the purpose of initial work
in all stages) And this applies to the experts, because, for the life of me,
I don't see how one could _efficiently_ develop not dealing with the
fundamentals of the application space first.
Regards,
Elliott
P.J. Sitoh
> Propagation means, for instance, that copying a document copies the
> [paragraphs] and character[s] the document consists of.
> Elliott
In the example you give, I would have modelled paragraph as an
aggregation of characters. Since it is already implicit that propagation
occur in aggregation type relationship, so why is it necessary to
explicitly model propagation?
Paul Sitoh
George Yuan
: Use the various models from Analysis including the object model and modify
: them. On the basis of Analysis models, create new models in Design. That's
: what both OMT and Booch advocate.
First, does OMT have models at the design level? What are their notations?
Second, what is the relationship between analysis models and design models?
Are they "Refinement" (OMT), "Translation" (Shaler/Mellor),
or "Mapping from the problem domain to application, application-specific and
application-generic domains" (Yuan).
: The object (abstractions and associations), and dynamic (state) models
: are two of the 3 models both the OMT and Booch method suggest should be
: created during Analysis. The other is the functional model (data
: transformation). These models along with requirements serve as the
: primary inputs to the Design stage.
No argument here.
: They are modified in the Design Stage
^^^^^^^^
How do you modify real-world object models? When you do so, you
are modify the facts modelled by analysis model. Analysis models
stand well by themselves, and cannot be modified in design. In design
we create design models for specifications of a system to be built.
In analysis, we present facts of real life or requirements.
: The Analysis models still exist and receive feedback from Design, but
: new Design models are generated in the Design stage and serve as key
: elements for input to the Implementation stage.
What is the design model in OMT?
We advocate a design-level object model with directed associations.
We also advocate a design-level dynamic model with OIDs that can
generate pseudo code of method specifications for classes.
I think Rumbaugh has a similar view about the design-level object model
presented in his column early this year.
George Yuan
: In <3avn2d$14...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:
: I use the second edition of OOA&D and he does everything you say he
: doesn't there.
How do you derive an object model at the design level in Booch's notation?
He does not have an analysis-level object model.
He has statechart as dynamic model at the analysis level, but he does not
tell how to derive out the dynamic model at the design level such as
Object-Interaction Diagrams, from the analysis-level one. There are many
techniques in Booch's second edition book, but links are definitely missing.
: Sounds _just_ like Booch and OMT to me.
: Elliott
Read our paper, and tell me.
George Yuan
: > In <3avn2d$14...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:
Does OMT has an object model and a dynamic model for design or system
specification?
George Yuan
: In <Ian.Mitchell...@sunderland.ac.uk> writes:
: > Booch offers 6 views of a system - class, object, STD, interaction, module,
: > and
: > process, compared to Rumbaugh's 3 - object (really a hybrid class/object),
: > dynamic and functional. The Booch system is therefore potentially more
: > rigorous and better suited for design documentation.
: There have been 4 models in OMT to this point. 4 models because OMT's
: object diagram is not a hybrid, there are two different models in the
: diagram. There is a class model with classes and associations and
: an object model with objects/instances and links.
: Also in the October JOOP, Rumbaugh begins to lay out notation for
: subsystems. So that's 5.
:
It is not very meaningful to compare how many models one method can provide.
For example, at analysis level, OMT provides three models, but in reality, most
OO projects I consulted only use their analysis-level object model. We consider
it is wastting our time to develop state chart model and functional model. Of course
you might have a question of how to we represent the dynamic aspect of real-world
objects. We use object-interaction diagrams at the analysis level to represent
the dynimic side. Actually, object and dynamic modeling should be carried in
parallel, since dyanmic modeling provides strong feedbacks to the class relationships.
I read one append mentioning code generation from object model at the analysis level.
This is a mis-conception to do so. The major problem is misunderstanding the
boundary between the analysis and design as well as their purposes.
I have one paper to be published in Report on Object Analysis and Design (I think
it will appear in March 1995), and it will give you some solutions. You are welcome
to get a copy from me or from your IBM friends. Send me your snailmail address
(USA only).
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> : > In <3avn2d$14...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:=
> : > Rumbaugh et al. simply mentioned a couple of issues in design, but it
> : > cannot be considered as OOD.
>
> : Rumbaugh et al's book deals with the key, and many ancillary concepts,
> : involved in System and Object Design. They demonstrate, in a detailed
> : way, the design of Objects and Subsystems based on the Analysis and overall
> : System Design determined earlier. (See Rumbaugh et al, OOM&D chapters 9
> : 10 and 11) [chapter 9 for System Design and chapter 10 for Object Design,
> : chapter a short summary; 67 pages of dense material]
>
> Does OMT has an object model and a dynamic model for design or system
> specification?
Yes it does.
Regards,
Elliott
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> : Use the various models from Analysis including the object model and modify
> : them. On the basis of Analysis models, create new models in Design. That's
> : what both OMT and Booch advocate.
>
> First, does OMT have models at the design level? What are their notations?
Yesit does, they are the same notation used during analysis. They are
simply detailed and added to in design.
> Second, what is the relationship between analysis models and design models?
> Are they "Refinement" (OMT), "Translation" (Shaler/Mellor),
> or "Mapping from the problem domain to application, application-specific and
> application-generic domains" (Yuan).
Refinement in OMT is the same as yours and is essentially what Booch does.
The object model from Analysis is fleshed out and enhanced in preparation
for implementation.
>
> : The object (abstractions and associations), and dynamic (state) models
> : are two of the 3 models both the OMT and Booch method suggest should be
> : created during Analysis. The other is the functional model (data
> : transformation). These models along with requirements serve as the
> : primary inputs to the Design stage.
>
> No argument here.
>
> : They are modified in the Design Stage
> ^^^^^^^^
> How do you modify real-world object models? When you do so, you
> are modify the facts modelled by analysis model. Analysis models
> stand well by themselves, and cannot be modified in design. In design
> we create design models for specifications of a system to be built.
> In analysis, we present facts of real life or requirements.
Fleshing out and adding implementation artifacts modifies the model from
analysis, but it doesn't change the real world. Also the analysis model
is kept intact except with feedback from design that enhances the
understanding of the application space. The design stage has it's own set
of models that originate as the analysis models, but again are fleshed out
and added to for implementation.
> : The Analysis models still exist and receive feedback from Design, but
> : new Design models are generated in the Design stage and serve as key
> : elements for input to the Implementation stage.
>
> What is the design model in OMT?
I just spoke on that.
> We advocate a design-level object model with directed associations.
> We also advocate a design-level dynamic model with OIDs that can
> generate pseudo code of method specifications for classes.
> I think Rumbaugh has a similar view about the design-level object model
> presented in his column early this year.
OMT directs the associations in design and specifies how to implement, i.e
with pointers.
>
> --
> George Yuan
Elliott
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> : In <3avn2d$14...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:
> : I use the second edition of OOA&D and he does everything you say he
> : doesn't there.
>
> How do you derive an object model at the design level in Booch's notation?
> He does not have an analysis-level object model.
He very much does. He discusses how the object model is passed from
analysis to design to implementation.
> He has statechart as dynamic model at the analysis level, but he does not
> tell how to derive out the dynamic model at the design level such as
> Object-Interaction Diagrams, from the analysis-level one. There are many
> techniques in Booch's second edition book, but links are definitely missing.
Right, that's OMT. But now they are merging. But he does advocate
building an object model during design.
Elliott
P.J. Sitoh
> --------
> There is no such thing as an invalid tool. If DFDs are appropriate to
> the problem, use them. If you can learn something by drawing a
> flowchart, draw one. There is no edict in OO that proscribes any kind
> of tool.
> --
Again, I fully agree with that sentiments but the main thread of my
argument is the case of OMT vs Booch.
If we stick to this thread, what I am saying is that
(a) I would prefer Booch's object diagram to OMT's functional modeling
simply because the former reinforce the mindset of O-O more so than the
latter.
(b) Given the choice between Jacobson's and functional modeling as a
basis for OOA, I would have prefered the former. Reason as in (a).
By all means use any methods that are most appropriate. After all
software development is itself a creative process! Nevertheless, it is very
useful to be consistent.
Paul Sitoh
Robert Martin
>How do you modify real-world object models? When you do so, you
>are modify the facts modelled by analysis model. Analysis models
>stand well by themselves, and cannot be modified in design. In design
>we create design models for specifications of a system to be built.
>In analysis, we present facts of real life or requirements.
However, these 'facts' are rarely immutable. Often the exigencies of
the design force changes to these 'facts'. Moreover, once the user is
exposed to prototypes, or even working systems, he often alters the
'facts'. Finally, the 'real-world' model is really just a mapping of
concepts from the specification to the object model, and this mapping
is not unique. Often the analysts can choose a mapping which is not
conducive to design, and must be changed.
One of the greatest weaknesses in Structured Analysis and Design was
the fact that the analysis model was separated from the design model
by a huge barrier. They used separate notations. The reason that
this was a problem was that problems with the analysis were alway
found during the design phase, and could not be easily corrected.
In OOAD, we address this issue in two ways. First, we use the same
notation for both design and analysis. Second, we perform analysis
and design concurrently.
Ell
> (a) I would prefer Booch's object diagram to OMT's functional modeling
> simply because the former reinforce the mindset of O-O more so than the
> latter.
OMT HAS BOTH A CLASS AND INSTANCE MODEL. How many times does it have to be
said! If you read the book, you'll see it plain as day. Dang!
Elliott
Ell
> yu...@raleigh.ibm.com (George Yuan) writes:
>
> >How do you modify real-world object models? When you do so, you
> >are modify the facts modelled by analysis model. Analysis models
> >stand well by themselves, and cannot be modified in design. In design
> >we create design models for specifications of a system to be built.
> >In analysis, we present facts of real life or requirements.
>
> However, these 'facts' are rarely immutable. Often the exigencies of
> the design force changes to these 'facts'. Moreover, once the user is
> exposed to prototypes, or even working systems, he often alters the
> 'facts'. Finally, the 'real-world' model is really just a mapping of
> concepts from the specification to the object model, and this mapping
> is not unique. Often the analysts can choose a mapping which is not
> conducive to design, and must be changed.
There is an objective reality behind the requirements. Anything else is
extremely silly solipism. I'm 100% against solipsitic thrashing and
hacking.
Elliott
Ell
Booch says the same thing about "hacking" in his "Benefits of OO
Development" article in "Object" magazine this year.
People may be happy, but how much time and money would be saved, if some
architecture were applied early on. And if we tried to find out the
objective nature of the application space during Analysis? If we
approached Analysis and System Design as the external aspect as Booch
and OMT both explicitly advocate? If we developed according to Iseult
White's book?
Come on, others of you out there surely have something to say about this?
Elliott
Ell
> In <3bf0gl$2...@whitbeck.ncl.ac.uk> P.J....@ncl.ac.uk writes:
>
> > (a) I would prefer Booch's object diagram to OMT's functional modeling
> > simply because the former reinforce the mindset of O-O more so than the
> > latter.
>
OMT has both a _class_ and _instance_ model. It's been said repeatedly in
this discussion. If you read the book, you'll see that it is the truth.
Further, OMT explicitly states in the book that the class and instance
models are the _key_ models for Analysis, Design and Implementation.
Elliott
Ell
>
> > yu...@raleigh.ibm.com (George Yuan) writes:
> > >How do you modify real-world object models? When you do so, you
> > >are modify the facts modelled by analysis model. Analysis models
> > >stand well by themselves, and cannot be modified in design. In design
> > >we create design models for specifications of a system to be built.
> > >In analysis, we present facts of real life or requirements.
> >
> > However, these 'facts' are rarely immutable. Often the exigencies of
> > the design force changes to these 'facts'. Moreover, once the user is
> > exposed to prototypes, or even working systems, he often alters the
> > 'facts'. Finally, the 'real-world' model is really just a mapping of
> > concepts from the specification to the object model, and this mapping
> > is not unique. Often the analysts can choose a mapping which is not
> > conducive to design, and must be changed.
Upon review, you're right on all counts, please excuse my extremely silly
earlier ranting. The point I'd like to make is that there are two models,
one for analysis and another for design. The analysis model is for
understanding the application space and the design one for design of a
solution. A copy of the analysis model is made as the initial design
model. The two stand side by side.
The analysis model is modified insofar as other development stages give
a better understanding of the application space. It should not be
modified with implementation artifacts and contrivances.
Regards,
Elliott
P.J. Sitoh
> OMT HAS BOTH A CLASS AND INSTANCE MODEL. How many times does it have to be
> said! If you read the book, you'll see it plain as day. Dang!
> Elliott
OMT, so-called instance diagram, only shows instantiation of class!
Pretty redundant modeling notations I must say!
Tell me where in the OMT methodology are there notations for:
(a) Object/message link;
(b) Synchronisation between objects/message link (e.g. simple,
synchronous, balking, timeout and asynchronous);
(c) Object visibility (i.e. global, parameter, field or local).
You can use OMT functional modeling to show the relationships between
objects but it shows only data flow not 'message passing' between
objects. I rest my case!
If you wish to have a better understanding of the
difference between algorithmic and object-oriented decomposition read
Booch's OOA&D (2nd Edition),pg 16-17, carefully!
Paul Sitoh
Robert Martin
>In <1994Nov29....@rcmcon.com> rma...@rcmcon.com writes:
You may be opposed to it, but I doubt that you will escape it. I have
never once seen a system whose initial analysis was identical (or even
strongly similar) to the final result. The targets always move,
because the world always moves.
Robert Martin
>In <3bfpea$i...@nova.umd.edu> COA...@UMUC.UMD.EDU writes:
Guys, I am not advocating "hacking". Of course you need to think
through your analysis and designs. Of course you have to provide a
framework and architecture to build upon. But as a great general
once said: "The first casualty of the battle, is the battle plan."
When you create your framework and architecture, it cannot be with the
idea that you have "done" the analysis and now "understand" the
problem domain. Niether will be true. You will have made errors in
the analysis, and the problem domain will drift.
If you bank on the fact that your initial analysis is "correct", you
will end up designing and implementing the wrong product. On the
other hand, if you iterate often and drive small segments of the
problem to detail quickly, you will get the feedback you need to
properly track the drift and find the errors.
Ell
> COA...@UMUC.UMD.EDU (Ell) writes:
> >In <1994Nov29....@rcmcon.com> rma...@rcmcon.com writes:
> >> However, these 'facts' are rarely immutable. Often the exigencies of
> >> the design force changes to these 'facts'. Moreover, once the user is
> >> exposed to prototypes, or even working systems, he often alters the
> >> 'facts'. Finally, the 'real-world' model is really just a mapping of
> >> concepts from the specification to the object model, and this mapping
> >> is not unique. Often the analysts can choose a mapping which is not
> >> conducive to design, and must be changed.
> >There is an objective reality behind the requirements. Anything else is
> >extremely silly solipism. I'm 100% against solipsitic thrashing and
> >hacking.
>
> You may be opposed to it, but I doubt that you will escape it. I have
> never once seen a system whose initial analysis was identical (or even
> strongly similar) to the final result. The targets always move,
> because the world always moves.
Or the target is standing still and we just don't fully understand it yet.
Elliott
Ell
> In <3bfpea$i...@nova.umd.edu> COA...@UMUC.UMD.EDU writes:
> >> In <1994Nov29....@rcmcon.com> rma...@rcmcon.com writes:
> >> > However, these 'facts' are rarely immutable. Often the exigencies of
> >> > the design force changes to these 'facts'. Moreover, once the user is
> >> > exposed to prototypes, or even working systems, he often alters the
> >> > 'facts'. Finally, the 'real-world' model is really just a mapping of
> >> > concepts from the specification to the object model, and this mapping
> >> > is not unique. Often the analysts can choose a mapping which is not
> >> > conducive to design, and must be changed.
> >There is an objective reality behind the requirements. Anything else is
> >extremely silly solipism. I'm 100% against solipsitic thrashing and
> >hacking.
> >
> >Booch says the same thing about "hacking" in his "Benefits of OO
> >Development" article in "Object" magazine this year.
> >People may be happy, but how much time and money would be saved, if some
> >architecture were applied early on. And if we tried to find out the
> >objective nature of the application space during Analysis? If we
> >approached Analysis and System Design as the external aspect as Booch
> >and OMT both explicitly advocate? If we developed according to Iseult
> >White's book?
> Guys, I am not advocating "hacking". Of course you need to think
> through your analysis and designs. Of course you have to provide a
> framework and architecture to build upon. But as a great general
> once said: "The first casualty of the battle, is the battle plan."
I guess I thought that way because you so rarely mention architecture,
the need to _attempt_ to tackle the fundamentals of the application
first and the need to have different foci for the stages. I don't think
Booch's, White's, Cockburn's and OMT's emphasis on these things are for
nothing. In fact they say these things are crucial to real savings in
time and money.
> When you create your framework and architecture, it cannot be with the
> idea that you have "done" the analysis and now "understand" the
> problem domain. Niether will be true. You will have made errors in
> the analysis, and the problem domain will drift.
>
> If you bank on the fact that your initial analysis is "correct", you
> will end up designing and implementing the wrong product. On the
> other hand, if you iterate often and drive small segments of the
> problem to detail quickly, you will get the feedback you need to
> properly track the drift and find the errors.
Yes, and I've always advocated the need for iteration. And yes iterative
analysis, design and implementation is a part of the method, not just for
experts. Maybe I haven't made that clear recently. I've always known and
advocated it in one way or another however. When I say we need to
iterate, maybe I make the wrong assumption that people will automatically
know that we're iterating because the stages aren't complete -- that stages
develop unevenly.
Elliott
Ell
> OMT, so-called instance diagram, only shows instantiation of class!
> Pretty redundant modeling notations I must say!
No OMT doesn't have a lot of that in the book. But Rumbaugh shows
messages between objects in an article in JOOP about 5 or 6 months ago.
Pretty extensive.
But the above and below by you is different from your earlier assertion
that OMT relies on the fuctional model and has no class and instance model.
What are you a saboteur? :-}
> Tell me where in the OMT methodology are there notations for:
>
> (a) Object/message link;
>
> (b) Synchronisation between objects/message link (e.g. simple,
> synchronous, balking, timeout and asynchronous);
>
> (c) Object visibility (i.e. global, parameter, field or local).
>
> You can use OMT functional modeling to show the relationships between
> objects but it shows only data flow not 'message passing' between
> objects. I rest my case!
>
> If you wish to have a better understanding of the
> difference between algorithmic and object-oriented decomposition read
> Booch's OOA&D (2nd Edition),pg 16-17, carefully!
Will do.
>
> Paul Sitoh
Elliott
Ell
> If you wish to have a better understanding of the
> difference between algorithmic and object-oriented decomposition read
> Booch's OOA&D (2nd Edition),pg 16-17, carefully!
I understand the difference. What I don't understand is you saying OMT
relies on the functional more than the class and object model, lack of
prominent message notation notwithstanding. However I do agree that it
does help a lot.
Elliott
P.J. Sitoh
> Elliott
If I have given the impression that you say I have, then let me correct
it. What I've been trying to say is that I do not find OMT's approach in
using the functional modeling approach as being particularly consistent
with the O-O mindset. The functional modeling approach but only one
component of the entire OMT methodology. My probelm is that that
component and only that component is, to me, "out of synchronisation",
"orthogonal", or call it what you like with the O-O mindset.
When you set it against the context of Booch's "Object Modeling", I would
have prefered Booch's to OMT's functional approach. Not because, Booch is
better or inherently more valid but because I think it is more consistent.
The point about modeling is that we want to use models to communicate
and, thus, consistency is a virtue!
Having said that, I have to say that there is one component of Booch that
I find not particularly not attractive and that is the class model. The
problem I have is the style of the notations. At a glance it is not easy
to tell the difference between the notation for 'inheritence' and 'using'
relationship. OMT 'Object Modeling' notations are much clearer and mind
you easier to sketch out on a piece of paper!
Paul Sitoh
Ell
> Ell (COA...@UMUC.UMD.EDU) wrote:
> > What I don't understand is you saying OMT
> > relies on the functional more than the class and object model, lack of
> > prominent message notation notwithstanding. However I do agree that it
> > does help a lot.
> If I have given the impression that you say I have, then let me correct
> it. What I've been trying to say is that I do not find OMT's approach in
> using the functional modeling approach as being particularly consistent
> with the O-O mindset. The functional modeling approach but only one
> component of the entire OMT methodology. My probelm is that that
> component and only that component is, to me, "out of synchronisation",
> "orthogonal", or call it what you like with the O-O mindset.
>
> When you set it against the context of Booch's "Object Modeling", I would
> have prefered Booch's to OMT's functional approach. Not because, Booch is
> better or inherently more valid but because I think it is more consistent.
> The point about modeling is that we want to use models to communicate
> and, thus, consistency is a virtue!
But from the first paragraph, I take it you really don't like the
functional model from anybody, Booch or otherwise? You would rather
dispense with it and use the OID to cover what the methods get out of the
functional model now? Which sounds interesting and possibly like a good
thing to me.
> Having said that, I have to say that there is one component of Booch that
> I find not particularly not attractive and that is the class model. The
> problem I have is the style of the notations. At a glance it is not easy
> to tell the difference between the notation for 'inheritence' and 'using'
> relationship. OMT 'Object Modeling' notations are much clearer and mind
> you easier to sketch out on a piece of paper!
Yeah I don't even really like the clouds for manual notation, OMT is much
easier in that respect. I'm buying Rational for C++ and that should take
care of the manual stuff. Then again one could use the Visio SW
engineering template for a quick take.
Elliott
George Yuan
: > In <3avn2d$14...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:
: > Rumbaugh et al. simply mentioned a couple of issues in design, but it
: > cannot be considered as OOD.
: Rumbaugh et al's book deals with the key, and many ancillary concepts,
: involved in System and Object Design. They demonstrate, in a detailed
: way, the design of Objects and Subsystems based on the Analysis and overall
: System Design determined earlier. (See Rumbaugh et al, OOM&D chapters 9
: 10 and 11) [chapter 9 for System Design and chapter 10 for Object Design,
: chapter a short summary; 67 pages of dense material]
Judge through OO practice and application, not through book reading..
George Yuan
: In <3bd8t7$f...@sernews.raleigh.ibm.com> yu...@raleigh.ibm.com writes:
: > Ell (COA...@UMUC.UMD.EDU) wrote:
: >
: > First, does OMT have models at the design level? What are their notations?
: Yesit does, they are the same notation used during analysis. They are
: simply detailed and added to in design.
I am afraid that Rumbaugh won't agree with that. In his columns (march 1994, Joop),
he also considers the object model at the analysis level fails to capture the
specification informtion. For example, many classes will be eliminated from
object model at the the analysis level when moving into design. Many relationships
that representing conceptual links will be eliminated too. All the relationships
(associations and aggregations) representing physical links must be directional....
..... It is not simply "detailed". It is a mapping. I donot think anything of
these is documented in OMT.
I even argue that the analysis class is different from its design class. For
example, we have a class called Account. In analysis, what we are concerned is
how its real-world objects work. The analysis-level class is the fact description
of this Account. We can assume that it has multiple inheritance, or other features.
In design, we have to go through a mapping with consideration of the frameworks,
arhcitectures, design patterns, and system constraints.
In other words, the design-level class Account is different from the analysis-level
class, although we try to the design- level one to match the requirement
presented in the analysis-level one. Unfortunately it is not always the case.
If we use Smalltalk, we have to consider the system
constraint that only single inheritance can be used. In other words, the design-
level class Account have be changed into single inheritance with aggregations.
If the system architecture is involved with View and DataBase, in the mapping
we might have to split the behavior of the analysis-level class Account into
three design-level classes: AccountView, Account, and AccountStore.
: > Second, what is the relationship between analysis models and design models?
: > Are they "Refinement" (OMT), "Translation" (Shaler/Mellor),
: > or "Mapping from the problem domain to application, application-specific and
: > application-generic domains" (Yuan).
: Refinement in OMT is the same as yours and is essentially what Booch does.
: The object model from Analysis is fleshed out and enhanced in preparation
: for implementation.
That is what you think.
: Elliott
Ell
> : Refinement in OMT is the same as yours and is essentially what Booch does.
> : The object model from Analysis is fleshed out and enhanced in preparation
> : for implementation.
>
> That is what you think.
>
Sorry, all I can do is tell you what I read. I'll quote when I can access
my copy later and I have more time. I don't know what the OMT book writers
do in actual practice, but they say they do.
Elliott
George Yuan
: However, these 'facts' are rarely immutable. Often the exigencies of
: the design force changes to these 'facts'. Moreover, once the user is
: exposed to prototypes, or even working systems, he often alters the
: 'facts'. Finally, the 'real-world' model is really just a mapping of
: concepts from the specification to the object model, and this mapping
: is not unique. Often the analysts can choose a mapping which is not
: conducive to design, and must be changed.
I guess that you mix the analysis models from design models. Analysis models
are just descriptions of real-world objects, and design models are the
specifications of your system. You can get many different design mapping
out of your analysis design, based on different design decisions. On the
other hand, the analysis model should be unique. Otherwise, you give
ambiguous requirements.
: In OOAD, we address this issue in two ways. First, we use the same
: notation for both design and analysis.
It is not true. I do not think it is a good practice to use the same notations
although they can be similar, consistent with each other, or verifiable from
one to the other. For example, a bi-directional association at the analysis level
tells little in design whether you will use a relationship class, a pointer,
and two pointers for them to point to each other.
Second, we perform analysis
: and design concurrently.
This is true. Iterations are good.
George Yuan
: Ell (COA...@UMUC.UMD.EDU) wrote:
: OMT, so-called instance diagram, only shows instantiation of class!
: Pretty redundant modeling notations I must say!
Agree!
: Tell me where in the OMT methodology are there notations for:
: (a) Object/message link;
For the analysis-level object model, you can use associations for classes
represent the "conceptual link" between two objects they pass messages.
For the design-level object model (OMT does not have one), my paper suggests
you to use a concept called "visibility". If an object in class A sends message
to one in class B, class B is visible to class A.
The associations in the design-level object model only reflect the physical
links among objects. If class A has an association with class B and the
association is directed from A to B, A should have a pointer attribute in
the class. We notice that not all the message passing is going through the
physical link. Some objects can be passed through parameters. That is why
we use "visibility" to represent a "pure" object/message passing relationship
(maybe I want to take away the "message link concept")
: (b) Synchronisation between objects/message link (e.g. simple,
: synchronous, balking, timeout and asynchronous);
You are talking about the dynamic modeling. I use OID to represent
synchronous, etc.. Object model only reflects the static part of the
system, while the dynamic model, OID, is used to reflect the dynamic
side, as well as the function side (I use "Action Specification" for
OIDs at the analysis level, and "Method Specification" for the OIDs
at the design level. I can see everything you present here can be
specified in my dynamic model at the design level.
: (c) Object visibility (i.e. global, parameter, field or local).
I guess I discussed this in the first paragraph. Object visibility should
be specified separated. Booch has a visibility diagram, and I just put
it in the class specification. They serve the same purpose.
: You can use OMT functional modeling to show the relationships between
: objects but it shows only data flow not 'message passing' between
: objects. I rest my case!
I do not think it is a good idea to use the functional modeling of OMT.
Ell
> Robert Martin (rma...@rcmcon.com) wrote:
> : In OOAD, we address this issue in two ways. First, we use the same
> : notation for both design and analysis.
>
> It is not true. I do not think it is a good practice to use the same
> notations
> although they can be similar, consistent with each other, or verifiable from
> one to the other. For example, a bi-directional association at the analysis
> level
> tells little in design whether you will use a relationship class, a pointer,
> and two pointers for them to point to each other.
Right, so in design just _add_ notation that one or both classes have a
pointer to the other. Or _add_ a class to the diagram. Or rearrange
and add appropriate notation.
Elliott
Ell
> P.J. Sitoh (P.J....@ncl.ac.uk) wrote:
> : Ell (COA...@UMUC.UMD.EDU) wrote:
>
> : OMT, so-called instance diagram, only shows instantiation of class!
> : Pretty redundant modeling notations I must say!
To be clear, Elliott didn't say the above, Paul Sitoh did.
>
> Agree!
I don't agree with Paul, Dr. Yuan. The instance diagram of OMT most
importantly shows the links between objects, for a whole new kind of
semantics different from OMT's class associations. The depiction of
those links between instances makes the instance diagram, in most
cases, look radically different from the class model with associations.
OMT's instance diagram shows each state different instance of a class
we see in Analysis, or intend to instantiate in Design. It shows the
links each of these instances has with other instances of the same or
different types. So that the single associations between classes in
the class diagram become a multiplicity of links between various objects
in the instance diagram. A difference from the class diagram to be sure.
> : You can use OMT functional modeling to show the relationships between
> : objects but it shows only data flow not 'message passing' between
> : objects. I rest my case!
Now it does. See Rumbaugh's article in JOOP this year. He specifies an
OID as well as class interaction diagram (CID).
> I do not think it is a good idea to use the functional modeling of OMT.
I think that in some cases it can be useful -- it depends on the nature of
the application space and requirements.
Elliott
Ell
> Robert Martin (rma...@rcmcon.com) wrote:
> : However, these 'facts' are rarely immutable. Often the exigencies of
> : the design force changes to these 'facts'. Moreover, once the user is
> : exposed to prototypes, or even working systems, he often alters the
> : 'facts'. Finally, the 'real-world' model is really just a mapping of
> : concepts from the specification to the object model, and this mapping
> : is not unique. Often the analysts can choose a mapping which is not
> : conducive to design, and must be changed.
>
> I guess that you mix the analysis models from design models. Analysis models
> are just descriptions of real-world objects, and design models are the
> specifications of your system. You can get many different design mapping
> out of your analysis design, based on different design decisions. On the
> other hand, the analysis model should be unique. Otherwise, you give
> ambiguous requirements.
Upon further thought due to George Yuan's reminder, I have to disagree
with Robert's "Finally, the 'real-world' model is really just a mapping of
concepts from the specification to the object model, and this mapping
is not unique. Often the analysts can choose a mapping which is not
conducive to design, and must be changed."
We should attempt in Analysis to "reflect" the application domain as we
are interested in it for the development requirements (the application
space). This is because we are attempting in Analysis to "understand"
the space. Even though our knowledge of the space generally deepens due
to the feedback from the iterative development process overall, the space
is _objective_ nevertheless. It is this objectivity we attempt to
understand and model during Analysis.
> : In OOAD, we address this issue in two ways. First, we use the same
> : notation for both design and analysis.
> It is not true. I do not think it is a good practice to use the same
> notations
> although they can be similar, consistent with each other, or verifiable
> from one to the other. For example, a bi-directional association at the
> analysis level
> tells little in design whether you will use a relationship class, a
> pointer, and two pointers for them to point to each other.
I have to agree with Robert here. Our notation should be the same to
enhance seamless integration of the development stages and phases. Booch
and OMT in fact do so, and I think that's correct.
> : Second, we perform analysis and design concurrently.
> This is true. Iterations are good.
Agreed, most definitely. It's a _fundamental_ aspect of the development
process, not an aside.
Elliott
Ell
> I don't agree with Paul, Dr. Yuan. The instance diagram of OMT most
Sorry about the difference in name semantics here Mr. Sitoh. I couldn't
recall Dr. Yuan's first name and I thought my formulation was clearer
given the name "blurbs" at the top of that message.
Elliott
Ell
Ditto for my last response in this thread referencing Robert Martin.
Elliott
P.J. Sitoh
> In <3bka97$d...@whitbeck.ncl.ac.uk> P.J....@ncl.ac.uk writes:
> > If I have given the impression that you say I have, then let me correct
> > it. What I've been trying to say is that I do not find OMT's approach in
> > using the functional modeling approach as being particularly consistent
> > with the O-O mindset. The functional modeling approach but only one
> > component of the entire OMT methodology. My probelm is that that
> > component and only that component is, to me, "out of synchronisation",
> > "orthogonal", or call it what you like with the O-O mindset.
> >
> > When you set it against the context of Booch's "Object Modeling", I would
> > have prefered Booch's to OMT's functional approach. Not because, Booch is
> > better or inherently more valid but because I think it is more consistent.
> > The point about modeling is that we want to use models to communicate
> > and, thus, consistency is a virtue!
> But from the first paragraph, I take it you really don't like the
> functional model from anybody, Booch or otherwise? You would rather
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> dispense with it and use the OID to cover what the methods get out of the
> functional model now? Which sounds interesting and possibly like a good
> thing to me.
> Elliott
If I chose to approach my development problem from an O-O basis I would
_Avoid_ presenting my model in a functional manner. Nevertheless, that
should not stop you from using functional model as a side activity to
lead you to an object model. Again, I would _Avoid_ not _Dispense_ with
functional modeling of any kind!
Dispense with functional modeling? I'm afraid a mortal like me is
in no position to do so. Only luminaries like Rumbaugh and Booch can do
so. :)
Robert Martin
>What I've been trying to say is that I do not find OMT's approach in
>using the functional modeling approach as being particularly consistent
>with the O-O mindset. The functional modeling approach but only one
>component of the entire OMT methodology. My probelm is that that
>component and only that component is, to me, "out of synchronisation",
>"orthogonal", or call it what you like with the O-O mindset.
Please understand that the terms that you are using are imprecise. To
rephrase your statement: you have a "gut feel" that there is a
mismatch between functional modeling and OO.
Perhaps we can shed some light on your "gut" by noting that when
functional modeling is used to describe the architecture of a system,
it violates the open-closed principle. For example. In functional
modeling we describe a system as a hierarchy of function calls, where
high level functions call low level functions. Thus, the high level
functions *depend* upon the low level functions. This means that when
new low level functions are added, the high level functions must be
changed. This violates the open-closed principle.
In OO, we like to see the exact opposite. We want low level functions
(i.e. polymorphic methods) depending upon high level abstractions
(abstract interfaces). In this way, new low level functions
(derivatives) can be added without changing the high level
abstractions. (clients that use the abstract interfaces).
So, your gut is "right" in the sense that overdependence upon
functional modeling will yeild designs that do not fit the OO
paradigm. However, this does not mean that functional modeling has
no place in, or is "out of sync" with, the OO paradigm. Often times,
functional modeling can be used as an analysis tool (i.e. DFDs) to
document "what" a system should do. This does not violate the
principles of OO, so long as the architecture of the system does not
directly derive from that functional model. Instead, the functional
model must be convolved with abstract polymorphic interfaces so that
it conforms to the open-closed principle. i.e. The functional model
must be reinterpreted as class and object diagrams with the
appropriate abstraction built in.
Robert Martin
>Robert Martin (rma...@rcmcon.com) wrote:
>: However, these 'facts' are rarely immutable. Often the exigencies of
>: the design force changes to these 'facts'. Moreover, once the user is
>: exposed to prototypes, or even working systems, he often alters the
>: 'facts'. Finally, the 'real-world' model is really just a mapping of
>: concepts from the specification to the object model, and this mapping
>: is not unique. Often the analysts can choose a mapping which is not
>: conducive to design, and must be changed.
>I guess that you mix the analysis models from design models. Analysis models
>are just descriptions of real-world objects, and design models are the
>specifications of your system. You can get many different design mapping
>out of your analysis design, based on different design decisions. On the
>other hand, the analysis model should be unique. Otherwise, you give
>ambiguous requirements.
And that is the issue. In the real world, requirements are often
ambiguous, and often change faster than the product can be developed.
Any methodology that depends upon a stable requirements model is
doomed for projects like this (IMHO).
>: In OOAD, we address this issue in two ways. First, we use the same
>: notation for both design and analysis.
>It is not true. I do not think it is a good practice to use the same
>notations although they can be similar, consistent with each other,
>or verifiable from one to the other. For example, a bi-directional
>association at the analysis level tells little in design whether you
>will use a relationship class, a pointer, and two pointers for them
>to point to each other.
Look closely at Booch's notation. The notation is "additive".
Concepts that the analysis level can be elaborated during design by
adding to the diagrams, rather than modifying them. i.e. associations
can be elaborated to directional using relationships by ploping down
an open circle. Using relationships can be upgraded to contains
relationships by filling in the open circle. Contains relationships
can be upgraded to relationship classes by using the dotted line
notation.
It is an essential attribute of a methodology that the analysis and
design notations are compatible. Otherwise, we will recreate the
nightmare scenario of SA/SD. In SA/SD, if you found an analysis
problem during design, you had a huge translation barrier to jump
accross. Typically this was too hard to do, and maintain schedules,
so the analysis model was left uncorrected and the design was kluged.
By the end of the design, the analysis model was sorely out of date.
In OOA/D we solve this by making the corrections in one place in space
and time. Not only do we use a single set of diagrams to represent
both the analysis and design, we also use a single time reference.
Analysis and design are not necessarily done at separate times. They
can (and should) occurr concurrently.
Robert Martin
>We should attempt in Analysis to "reflect" the application domain as we
>are interested in it for the development requirements (the application
>space). This is because we are attempting in Analysis to "understand"
>the space. Even though our knowledge of the space generally deepens due
>to the feedback from the iterative development process overall, the space
>is _objective_ nevertheless. It is this objectivity we attempt to
>understand and model during Analysis.
This ignores the fact that the problem space is defined by the user is
not objective. The user "thinks" he knows what he wants, but when he
finally sees the solution he realizes that his original specifications
are lacking, and that new features should be added, and other features
should be changed. Often this reassesment of the problem domain
occurs at a level which is so fundemental that the architecture of the
product is insufficient to compensate for it. In essense, the initial
requirements can often lead to an analysis and design which leave the
product in a cul-de-sac.
To avoid this, the problem domain must be treated as being subjective,
and the method employed to analyze and design the product must be able
to adapt to the subjective drift of the requirments. In other words,
you have to get the user involved with lots of prototypes and
milestones, so that you find out about his reassesments as early as
possible.
R. S. Koss
Robert Martin <rma...@rcmcon.com> wrote:
>Not only do we use a single set of diagrams to represent
>both the analysis and design, we also use a single time reference.
If you only use one set of diagrams, doesn't the essence of the problem
become lost in the design? If you keep adding to the analysis diagrams
how do you recover the "what" from the "how"?
How does the analysis team do analysis for version 2 if the diagrams are
in a state of flux from the efforts of the design team?
Bob
George Yuan
Here I would like to talk a little bit more about OMT's Object Modeling + Jacobson's
OIDs. Combining both techniques for OOA/OOD modeling has been practiced much more
widely than I thought.
In OOPSLA'94, I at least heard three successful experience reports (I remember two names
and forget the third: AT&T, and Anderson Consulting), and all of them have successfully
use these two techniques as the major modeling tools.
In OOPSLA'94, I also saw a demo of a CASE tool that supports OMT's object model notation
and Jacobson's OIDs notation, called Select OMT Professional (Select Software Tool Inc.
1.714.957.6633)
P.J. Sitoh
> > I don't agree with Paul, Dr. Yuan. The instance diagram of OMT most
> Sorry about the difference in name semantics here Mr. Sitoh. I couldn't
^^^^^^^^^^
> recall Dr. Yuan's first name and I thought my formulation was clearer
> given the name "blurbs" at the top of that message.
> Elliott
Come, come Mr Coates...oops Elliot, do we have to be that formal!
Paul Sitoh
P.J. Sitoh
> >What I've been trying to say is that I do not find OMT's approach in
> >using the functional modeling approach as being particularly consistent
> >with the O-O mindset. The functional modeling approach but only one
> >component of the entire OMT methodology. My probelm is that that
> >component and only that component is, to me, "out of synchronisation",
> >"orthogonal", or call it what you like with the O-O mindset.
> Please understand that the terms that you are using are imprecise. To
> rephrase your statement: you have a "gut feel" that there is a
> mismatch between functional modeling and OO.
> So, your gut is "right" in the sense that overdependence upon
> functional modeling will yeild designs that do not fit the OO
> paradigm. However, this does not mean that functional modeling has
> no place in, or is "out of sync" with, the OO paradigm. Often times,
> functional modeling can be used as an analysis tool (i.e. DFDs) to
> document "what" a system should do. This does not violate the
> principles of OO, so long as the architecture of the system does not
> directly derive from that functional model. Instead, the functional
> model must be convolved with abstract polymorphic interfaces so that
> it conforms to the open-closed principle. i.e. The functional model
> must be reinterpreted as class and object diagrams with the
> appropriate abstraction built in.
> --
> Robert Martin | Design Consulting | Training courses offered:
> Object Mentor Assoc.| rma...@rcmcon.com | Object Oriented Analysis
> 2080 Cranbrook Rd. | Tel: (708) 918-1004 | Object Oriented Design
> Green Oaks IL 60048 | Fax: (708) 918-1023 | C++
I have not suggested that functional modeling has no place in O-O
development. Nor have I suggested that functional modeling is invalid in
the O-O paradigm. What I do agree that, as Robert indicated, that my
wrong use of terms may have given the impression that I've dismissed
functional modeling altogether!
My key assertion is that the purpose of modeling is to communicate the
problem domain and design domain. As I have indicated in my previous posting,
functional modeling can be used as a front end to the O-O process but I don't
think the semantics of a functional model is _CONSISTENT_ with the vocabularies
one normally associate with the O-O paradigm. However, in the absence of
any alternative to functional model, than use it! But when presented with
alternatives as in the case of Booch's 'Object Model' and/or 'Jacobson
use case', I would say that Booch presents a much more consistent set of
modeling semantics.
All-in-all I must say Robert has read my mind very well! I'm afraid, having
come from a Mechanical Engineering Discipline have not endowed me with
the eloquance that Robert has so clearly demonstrated.
Paul Sitoh
Ell
> This ignores the fact that the problem space is defined by the user is
> not objective. The user "thinks" he knows what he wants, but when he
> finally sees the solution he realizes that his original specifications
> are lacking, and that new features should be added, and other features
> should be changed.
The space may or may not be objective. For a new system we want to take
into account any existing manual systems. For an upgrade we want to take
into account the existing automatic system.
> Often this reassesment of the problem domain
> occurs at a level which is so fundemental that the architecture of the
> product is insufficient to compensate for it. In essense, the initial
> requirements can often lead to an analysis and design which leave the
> product in a cul-de-sac.
>
> To avoid this, the problem domain must be treated as being subjective,
> and the method employed to analyze and design the product must be able
> to adapt to the subjective drift of the requirments. In other words,
> you have to get the user involved with lots of prototypes and
> milestones, so that you find out about his reassesments as early as
> possible.
The client may have stated, fuzzy and unknown needs. Although we often
need to assist the client in finding all of their needs, I think it's
best to take the approach that the client has objective needs relative to
the developers. We're pretty close in that we both want to understand
what the client needs. Just a nit. :-}
Elliott
John Goodsen
An excellent point. How can you really tackle the exploration of
alternative designs based upon the same analysis model. Another area
of breakdown is when you attempt to use the Booch notation in an
incremental delivery process model, which means that we can have
several "versions" of a model that are active at any time, but only a
particular "version" of the model applies to the current development
cycle (e.g we need to track analysis and design information that is
learned during the current development cycle and store it in models
that will be worked on in future development cycles, while at the same
time keeping all the models consistent).
Still, I don't see this as a fault of the method, although, incremental
development is hardly addressed by any of the "main OO authors".
I am free to "freeze" an Analysis model and further refine it at any point. On
paper this is nearly impossible to maintain. This is a CASE tool
problem. In order to effectively delve into alternative designs or
allocate analysis and design models to development cycles, we really
need CASE tool support to manage the dependencies between versions of diagrams.
Last I looked, Rose still doesn't really provide support for this
yet... but, hey, we're still refining our Incremental Delivery process
model, so we haven't really conveyed the need to CASE vendors
yet... (your off the hook this quarter :-)
--
--
John Goodsen Currently on-site at:
The Dalmatian Group JP Morgan
User Interface Specialists 60 Wall St., New York City
jgoo...@radsoft.com jgoo...@jpmorgan.com
John Goodsen
This ignores the fact that the problem space is defined by the user is
not objective. The user "thinks" he knows what he wants, but when he
finally sees the solution he realizes that his original specifications
are lacking, and that new features should be added, and other features
should be changed. Often this reassesment of the problem domain
occurs at a level which is so fundemental that the architecture of the
product is insufficient to compensate for it. In essense, the initial
requirements can often lead to an analysis and design which leave the
product in a cul-de-sac.
To avoid this, the problem domain must be treated as being subjective,
and the method employed to analyze and design the product must be able
to adapt to the subjective drift of the requirments. In other words,
you have to get the user involved with lots of prototypes and
milestones, so that you find out about his reassesments as early as
possible.
(hi bob)
Fundamentally, I don't think anyone disagrees with this position,
but what I can see is that very few people know how to incorporate
this approach into something that can be planned, scheduled and tracked
from a project management prospective. At some point, a project
manager needs to *freeze* the analysis and design activities so that
the implementation can be fleshed out and tested.
Using the Rapid Incremental Delivery process, we perform this *freezing*
at predetermined points in each cycle of development. After that point
in a development cycle, changes to requirements or defect removal efforts
fall under a much stricter change management policy than might have
been in effect earlier in the delivery cycle.
We have been choosing development cycles of 4-6 weeks and find that
this approach allows for both the fluid, creative analysis/design
activities to be properly addressed while at the same time, *returning
control* to the project manager as the delivery cycle comes to a close.
Ell
jgoo...@trinidad.radsoft.com writes:
>...
> something that can be planned, scheduled and tracked
> from a project management prospective. At some point, a project
> manager needs to *freeze* the analysis and design activities so that
> the implementation can be fleshed out and tested.
>
> Using the Rapid Incremental Delivery process, we perform this *freezing*
> at predetermined points in each cycle of development. After that point
> in a development cycle, changes to requirements or defect removal efforts
> fall under a much stricter change management policy than might have
> been in effect earlier in the delivery cycle.
This is the same as the macro and micro aspect of the Booch method. The
macro side is controlled by management and controls the micro process
which is run by the programmers. At some point the macro process feeds
the current micro process output into an executable release.
> We have been choosing development cycles of 4-6 weeks and find that
> this approach allows for both the fluid, creative analysis/design
> activities to be properly addressed while at the same time, *returning
> control* to the project manager as the delivery cycle comes to a close.
That's the purpose of macro control over the micro. Preferably, loose
control, but control nontheless.
Elliott
Mark S. Hathaway
> rma...@rcmcon.com (Robert Martin) writes:
I agree with Mr. Martin.
Once you've got a library of classes which can be reused and you've
done the OOD for your application there will still be an algorithm
that applies (uses) these components. That algorithm has to be designed
with another methodology, doesn't it? What's the best method for
designing an algorithm where all the objects are already established?
You can design and build a truck, but then someone has to know how
to drive it and how to get to the destination.
I tend to think of a low-level class as somewhat like an interface to
a device. You have to have a good low-level library before you can
build any kind of application. There are the OS calls, the API with
Windows, the standard C library calls with Unix, the X window system,
and others. That gives us a starting point. The creation of objects
specifically for an application are similar to an API. You're looking
at low-level things as far as the application is concerned, but then
you design each one and code it top-down. Then you can move to the
primary (highest-level) algorithm and design it top-down with the use
of those low-level objects you have created. This method brings the
lowest-level up closer to the primary highest-level algorithm(s).
One difficulty for larger systems is that the creation of an application
API of only one layer may not bring the bottom up very far. That's where
the ability to build upon low-level classes to create higher-level classes
of more complexity is critical. The mechanisms to do this in the language
must be powerful without being overly complex to write or read and maintain.
Mark S. Hathaway <hath...@marshall.edu>
Janet Gardner
|> Here I would like to talk a little bit more about OMT's Object Modeling + Jacobson's
|> OIDs. Combining both techniques for OOA/OOD modeling has been practiced much more
|> widely than I thought.
|>
|> In OOPSLA'94, I at least heard three successful experience reports (I remember two names
|> and forget the third: AT&T, and Anderson Consulting), and all of them have successfully
|> use these two techniques as the major modeling tools.
|>
|> In OOPSLA'94, I also saw a demo of a CASE tool that supports OMT's object model notation
|> and Jacobson's OIDs notation, called Select OMT Professional (Select Software Tool Inc.
|> 1.714.957.6633)
Check out IDE's new version of StP/OMT 2.0. They have integrated in a significant
Use Case component as a result of customer requests for the functionality combined
with the OMT approach.
I know Protosoft was talking about doing this, but I do not know if
they ever implemented it - maybe someone else can comment on them.
Janet
----------------------- MATISSE ODBMS -----------------------
Janet GARDNER ADB, Inc.
ja...@adb.com 238 Broadway, Cambridge, MA 02139
Ph.: (617) 354-4220 FAX:(617) 547-5420
--------------------------------------------------------------
Chonoles Michael Jesse
been coming. Jim Rumbaugh has added OIDs to the OMT methodology. Eddy
also has been promoting them.
The OIDs serve many purposes, and have several different forms for
slightly different uses. They can be used as alternative form of
event trace diagram, or even as an alternative form of DFD.
---
Michael
Michael Jesse Chonoles PER chon...@acc.vf.ge.com +1 610 992 6212
Chief of Methodology ACC a...@acc.vf.ge.com
Advanced Concepts Center of Martin Marietta FAX +1 610 992 6299
640 Freedom Business Center TOLL FREE 1 800 43 TRAIN
P.O. Box 1561 General and Course Information a...@acc.vf.ge.com
King of Prussia, PA 19405 OMTool Questions omt...@acc.vf.ge.com
United States Other Technical Questions ques...@acc.vf.ge.com
P.J. Sitoh
qualified association. My answer is no! The notationations for qualified
association is only available in OMT.
How useful is the modeling of qualified association? I can't give a
definitive answer but my experience in applying OMT and Booch to some
simple case study, seemed to indicate that yes the OMT notations is more
expressive than Booch. In the sense that I could read immediately the
semantics behind the OMT model than Booch's. Using the OMT illustration
of the association between a file and a directory, it is certainly more
expressive to say that a directory plus a filename identifies a file. In
Booch equivalent would have been a many to many relationship between
directory and file. In other words the Booch model would be read as a
directory identifies many files, and each file can be identified by a
directory. Certainly not very expressive, for that context.
Here, I would regard OMT's ability to model qualified association as
being more superior to Booch's methodology.
Paul Sitoh
PS: To whoever emailed me the query on qualified association I hope that
answer your question. My apologies for accidentially erasing your mail
address from my mail list.
George Yuan
: > functional model from anybody, Booch or otherwise? You would rather
: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: > dispense with it and use the OID to cover what the methods get out of the
: > functional model now? Which sounds interesting and possibly like a good
: > thing to me.
: If I chose to approach my development problem from an O-O basis I would
: _Avoid_ presenting my model in a functional manner. Nevertheless, that
: should not stop you from using functional model as a side activity to
: lead you to an object model. Again, I would _Avoid_ not _Dispense_ with
: functional modeling of any kind!
: Dispense with functional modeling? I'm afraid a mortal like me is
: in no position to do so. Only luminaries like Rumbaugh and Booch can do
: so. :)
Our of my curiosity, is there anyone having really used
the OMT's functional modeling for OOA in the real project?
What is the feedback out of it (will you do the same way again
next time)?
I had a chance to go over the Report on Object Analysis and Design
10/94 last week. Booch's column on scenarios is very good. He also
uses Object Diagrams to reflect another view of OIDs. It seems to me
that almost everyone is agreeing on Use Cases/Scenarios/OIDs.
Grady Booch
: said! If you read the book, you'll see it plain as day. Dang!
true; but in omt classic, the semantics for instance diagrams were
quite limited. ifyou lookat jim's ongoing work, you'll see he's adoped
object diagram semantics from booch.
egb
Grady Booch
: architecture were applied early on. And if we tried to find out the
: objective nature of the application space during Analysis? If we
: approached Analysis and System Design as the external aspect as Booch
: and OMT both explicitly advocate? If we developed according to Iseult
: White's book?
I concur with elliot's comments re architecture; this is why I'm so
interested in the patterns work going on, particularly relative to
the "big architectural patterns" mary shaw et al have begun to
uncover.
on another topic, do I really approach analysis as external to my
method? um, I don't think so...
egb
Grady Booch
: one for analysis and another for design. ...
I agree and also disagree with you.
first, there is, in my mind, only one model...if you have two distinct
models, you run the risk of those models diverging. however, there may
be multiple views of the same model: perhaps one for analysis and one
for design
egb
Grady Booch
: I find not particularly not attractive and that is the class model. The
: problem I have is the style of the notations. At a glance it is not easy
: to tell the difference between the notation for 'inheritence' and 'using'
: relationship. OMT 'Object Modeling' notations are much clearer and mind
: you easier to sketch out on a piece of paper!
and this is why jim and I are working together....
Grady Booch
: development is hardly addressed by any of the "main OO authors".
: I am free to "freeze" an Analysis model and further refine it at any point. On
: paper this is nearly impossible to maintain. This is a CASE tool
: problem.
I agree; it's not an issue of notation.
: In order to effectively delve into alternative designs or
: allocate analysis and design models to development cycles, we really
: need CASE tool support to manage the dependencies between versions
of diagrams.
also in violent agreement; I believe there should be explicit support
for releases in case tool representation.
gee, I wonder if there are any such tool I might be able to
influence...;-)
: Last I looked, Rose still doesn't really provide support for this
Grady Booch
: this approach allows for both the fluid, creative analysis/design
: activities to be properly addressed while at the same time, *returning
: control* to the project manager as the delivery cycle comes to a close.
in my experience, different projects demand different increments....
some massive project I've encountered to a new release every 6 months
or so (e.g. the canadian air traffic control system) other have a
release cycle every week or two (e.g. some telephony apps and trading
apps)
egb
Mark Yablonski
> Use Case component as a result of customer requests for the functionality combined
> with the OMT approach.
For those who aren't aware, StP/OMT 2.1, the next version due out in the
near future, will be adding support for OIGs.
Mark
+----------------------------------------------------------------+
| Mark Yablonski DSC Communications Corp. |
| myab...@cpdsc.com MS ATMS1 |
| 1000 Coit Rd. |
| (214) 519-5745 Plano, TX 75075 |
+----------------------------------------------------------------+
"I speak for myself"
--
+----------------------------------------------------------------+
| Mark Yablonski DSC Communications Corp. |
| myab...@cpdsc.com MS ATMS1 |
| 1000 Coit Rd. |
| (214) 519-5745 Plano, TX 75075 |
+----------------------------------------------------------------+
"I speak for myself"
Ell
What I meant was that like encapsulation for a single object, there is a
public external interface and an internal implementation. And that
analysis and system design are more concerned with interfaces rather
than internal object design.
Elliott
Bertrand Meyer
to mention another alternative which may interest readers
of this newsgroup.
In response to
> : In order to effectively delve into alternative designs or
> : allocate analysis and design models to development cycles, we really
> : need CASE tool support to manage the dependencies between versions
> of diagrams,
Grady Booch wrote:
> Also in violent agreement; I believe there should be explicit support
> for releases in case tool representation.
>
> Gee, I wonder if there are any such tool I might be able to
> influence...;-)
Readers may wish to check out the BON method, described
in the recently published book by Kim Walden and Jean-Marc Nerson:
Seamless Object-Oriented Software Architecture, Prentice Hall,
ISBN 0-13-031303-3. Although the book does not discuss
version control, BON explicitly supports reversibility, that is
to say the ability to go back from implementation to design and
analysis - a key component of a properly applied O-O method,
addressing at least part of the goals stated in the above messages.
ISE's EiffelCase tool supports BON and in particular reversibility.
It is one of the very few CASE tools that makes it possible not
just to go from diagrams to code (the [relatively] easy part!)
but also from code to diagrams. EiffelCase will reverse-engineer
O-O code into the high-level diagrams; the code may have been
produced by EiffelCase, but it may also have been obtained
by any other independent means. If it has been produced by EiffelCase,
it may in the meantime have been modified manually (e.g. using a
text editor).
This seamless, reversible integration of textual and graphical
input is, I think, a fundamental requirement for object-oriented
development environments and CASE tools.
Notes:
1. EiffelCase is currently in beta test and was shown at TOOLS PACIFIC
last week. It will be released for good in January.
2. Since the Walden-Nerson book is recent and may not yet be
available everywhere, ISE is selling it directly. See our
World-Wide Web page (http://www.eiffel.com) or e-mail to
<in...@eiffel.com>.
--
Bertrand Meyer,
ISE, Santa Barbara
805-685-1006, fax 805-685-6869, <bert...@eiffel.com>
Web home page: http://www.eiffel.com
George Yuan
I may totally disagree with above statement. The key here is that
the analysis and design models serve different purposes. When we understand
the purpose, and we can see whether there are different models or
different views.
The analysis model is the abstraction of "real-world objects", and
description of the facts and requirements (as it is). We can have
different views for the analysis model, static and dyanmic.
The design model is the specification of your "system objects" that
you will build for your system. You may try to do your best to match up
the system objects to the "real-world objects". But it is more
complicated and controlled by other factors. This matching is a
mapping process constrained by other factors such as
existing frameworks, design patterns you would like to use,
language, system and envrionment constraints, ..... We can also
have different views at this level to specify different aspects for
a system.
Bob Weissman
Oh, no! Please, Grady, don't adopt Rumbaugh notation! Booch notation
is much more expressive and maps much better into C++.
Maybe it's just my historical bias showing... but maybe not.
/b
P.J. Sitoh
> and this is why jim and I are working together....
When my colleague and I heard that Booch and Rumbaugh had come to
collaborate with one another, we decided to predict the outcome of the
collaboration. The following are some of the outcome:
(a) Prediction 1. The result will be a broadly Booch-based notations.
All of OMT notations will be abandon, except for the OMT notations for
aggregation, generalisation, ternary association, cardinality and qualified
association.
(b) Prediction 2. The result will be a compromised class notation - a
hybrid cloud and rectangle notation, say an octogan. A circle notation
for qualified association. The OMT practice of populating the class
notation with all details of class attributes and operations will be
dropped. The Booch practice of maintaining class attributes and
operations on a separate specification template will be retained. For
that, Booch notations for aggregation, inheritence and cardinality
will have to be scarificed and OMT's equivalent adopted.
(c) Prediction 3. A mainly OMT framework but retaining Booch's notations
for object instances, class category, system and module. In this
scenario, the class category notation will be altered, say, into an octagon.
(d) Prediction 4. No change to either OMT or Booch. The fortcomming
methodology will depend on the "arm wrestling" competition between Grady
and Jim. :-)
Paul Sitoh
21/12/94
--- Seasons greetings to all comp.object readers.
Thomas Cox
Here's my $.02. One of the big improvements in the 2nd edition was the
adoption of Harel's statechart notation. IMHO, the consolidation of notations
is both a neccesary and welcome sign of maturity in OO.
As for the aesthetics of the class diagram, I am a big fan of `clouds', but
I would like to see the use of more visually distinctive adornments,
particularly for class relationships and export control. In short, something
that I can see when I have a fuzzy, third generation copy of a photo-reduced
diagram...
Thanks.
-----
____ ____ ____
(____)-------------------(____)----------------------------------------(____)
| | Thomas W. Cox | | **** ***** **** | |
| | | | *** *** ** *** | |
| | System Developer | | *** *** ** *** | |
| | SAS Institute | | **** **** ** **** | |
| | Office R4147 | | **** **** ** **** | |
| | Cary NC 27513 | | *** ********* *** | |
| | 919.677.8000x6295 | | *** *** ** *** | |
| | | | *** *** ** *** | |
|__| sas...@unx.sas.com |__| **** **** ** **** |__|
(____)-------------------(____)----------------------------------------(____)
Robert Martin
>When my colleague and I heard that Booch and Rumbaugh had come to
>collaborate with one another, we decided to predict the outcome of the
>collaboration. The following are some of the outcome:
>[...] The result will be a broadly Booch-based notations.
>All of OMT notations will be abandon, [...]
It seems unlikely that all OMT notation will be abandoned since Booch
94 included OMT icons as alternatives when drawing the diagrams by
hand.
>[...] The OMT practice of populating the class
>notation with all details of class attributes and operations will be
>dropped.
This seems unlikely since Booch 94 includes it.
>(d) Prediction 4. No change to either OMT or Booch. The fortcomming
>methodology will depend on the "arm wrestling" competition between Grady
>and Jim. :-)
I expect a sythesis of the two techniques, with some features from OMT
and Booch 94, and some new features that are borne out of the
discussions.