Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Object Identification & Detailing under Rumbaugh/Booch/Jacobson

97 views
Skip to first unread message

Dhananjay Nene

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

Based on my understanding the object identification and detailing differ
a little bit under the various methodologies. However I am not sure of
the impact of these differences on the final analysis/design.

Rumbaugh/OMT -
1. Identify all objects from domain / problem statement
2. Identify Attributes,
3. Identify Operations

Booch -
1. --- I don't know how the objects are identified ---
2. Identify what roles the objects are playing which lead to the
operations
2. Identify the attributes

Jacobson / Objectory -
1. Identify the use cases for the system
2. The use cases should help identifying the objects
3. Based on the object roles in the use cases identify the operations,
followed by the attributes based on these use cases.

(Please correct me if I misrepresented any of the methodologies)

Also since the 3 authors have pooled their efforts to have a common
notation (but NOT a common process), these differences may not get
resolved easily in the near future.

While the operation/attribute identification is an iterative process, I
wonder how important the order is.

Q.1 : Under what situations is one approach better than the other ?
Q.2 : Are the end results significantly different depending upon the
approach used ? If so, how and to what extent ? Are there any documented
studies towards this end ?
Q.3 : Is there any reason to believe one approach is more OO vs. SA/SD
than others (I have heard opinions expressed in either direction) ?

Any help towards resolving these questions will be most welcome.

Thanks
--------------------------------------------------------------
Dhananjay Nene - dn...@gnn.com


Robert C. Martin

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

Dhananjay Nene wrote:
>
> Based on my understanding the object identification and detailing differ
> a little bit under the various methodologies. However I am not sure of
> the impact of these differences on the final analysis/design.
>
> Rumbaugh/OMT -
> 1. Identify all objects from domain / problem statement
> 2. Identify Attributes,
> 3. Identify Operations
>
> Booch -
> 1. --- I don't know how the objects are identified ---
> 2. Identify what roles the objects are playing which lead to the
> operations
> 2. Identify the attributes
>
> Jacobson / Objectory -
> 1. Identify the use cases for the system
> 2. The use cases should help identifying the objects
> 3. Based on the object roles in the use cases identify the operations,
> followed by the attributes based on these use cases.
>
> (Please correct me if I misrepresented any of the methodologies)

I don't think you have misrepresented what these people say, but you
may have misrepresented the significance that they apply to these
points.

I don't believe that any of the above methodolgists would suggest that
there is only one way to identify objects. I think you would find that
they all suggest that you try one way first, and if that fails, try
another.

> While the operation/attribute identification is an iterative process, I
> wonder how important the order is.

Not very. In my experience, object identification, regardless of the
method employed, is a creative exercise that depends upon a great
deal of experience and insight into the domain. The methods simply act
as stimuli to this creative process.

I prefer a use case driven approach. However, I have found that there are
times when uses-cases don't seem to lead me anywhere. Whether this is
an attribute of a particular kind of problem, or an attribute of my own
hormonal cycle, is debatable. The solution, however, is to try another
approach. The Attribute/Operation approach often works well to jog my
creative juices. Sometimes I will even write noun-lists or draw
data flow diagrams. Anything that will spark the insight and creative
energy needed to abstract the problem domain.


>
> Q.3 : Is there any reason to believe one approach is more OO vs. SA/SD
> than others (I have heard opinions expressed in either direction) ?

No, there really isn't. OO is an attribute that can be applied to
a software design that conforms to certain principles, and uses
a particular kind of toolset. Any method that supports the creation
of such a design might be called an OO method. On the other hand,
there are methods that support OO designs, and structured designs alike.
Such methods are no less OO because of this. Indeed, the OO attribute
can be quite ambiguous when describing methods as opposed to designs.

--
Robert Martin | Design Consulting | Training courses offered:
Object Mentor Assoc.| rma...@oma.com | OOA/D, C++, Advanced OO
14619 N. Somerset Cr| Tel: (847) 918-1004 | Mgt. Overview of OOT
Green Oaks IL 60048 | Fax: (847) 918-1023 | http://www.oma.com

Ell

unread,
May 3, 1996, 3:00:00 AM5/3/96
to

Robert C. Martin (rma...@oma.com) wrote:

: Dhananjay Nene wrote:
: >
: > Based on my understanding the object identification and detailing differ
: > a little bit under the various methodologies. However I am not sure of
: > the impact of these differences on the final analysis/design.
: > [writer's perception of each of Booch, Jacobson, and Rumbaugh
methodologies deleted.]

: I don't think you have misrepresented what these people say, but you


: may have misrepresented the significance that they apply to these
: points.
:
: I don't believe that any of the above methodolgists would suggest that
: there is only one way to identify objects. I think you would find that
: they all suggest that you try one way first, and if that fails, try
: another.

Yet they properly, imo, seem to favor use cases cum CRC. (Yes they are
married :-)

Elliott

0 new messages