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.| rmar...@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
