From: rmartin@yosemite.Rational.COM (Bob Martin)
Newsgroups: comp.object
Subject: Re: OOA: Should "Classification" be performed in OOD phase?
Keywords: Class based vs Classless implementations.
Date: 21 Jul 92 15:27:39 GMT

brr@abcom.ATT.COM (Rao) writes:


|A few postings on OOA (and a few personal emails ) suggested
|that "identification" of classes should perhaps be done
|during the OOD phase, while "identification" of objects
|should be performed in the OOA phase.

|This would allow for OOA without being influenced by issues
|such as Class-based implementation (and Class-based OOD) or
|Class-less implementation (meaning Delegation based).

|Question: When does OOA end and OOD begin?

That is a meaningless question, It is like asking the wavelength at
which orange begins and red stops.  In a spectrum, there is definitely
red and orange, but no specific boundary.  The same is true of OOA and
OOD.

|Another Question: In what phase do we decide if objects should be 
|	"Classified"? During OOA or OOD?

There is no firm answer to this question, since "Classification' can
happen both as part of analysis and of design.  However, I have a
bias.  I accept classification as a valid part of analysis, but such
classifications are 'soft' in that they need not imply inheritance.
In Analysis we can say that object X conforms to such and such an
interface, or that object y and object z are polymorphic forms of
object w.  But it is generally premature to say that D inherits from
B.

I view inheritance as a design tool.  The construction of huge
inheritance hierarchies requires a decision process which employs
design trade-offs.  Many inheritance decisions have more to do with
the structure of the solution rather than the structure of the
problem.

Thus, when we classify object in analysis, we are stating a soft
relationship.  During design, that relationship may be hardened into
inheritance, or it may be manipuated into some other form such as
generic instantiation or simple interface congruence.

|Most OOA models include "Classification of objects" as part
|of the OOA phase. For example, in the OMT (Rumbaugh et. al.)
|the following process is recommended:

|Step 1. Initial written description.

|Step 2. Build an object Model.
|	- Identify object classes.
|	- Begin a data dictionary ,......
|	- Add association between classes.
|	etc.

|	Clearly, Rumbaugh's OMT model is "Class-based".

We are learning more and more every day about OOA and OOD.  In earlier
times it seemed that OO == inheritance, thus OOA must involve
inheritance in some way.  Now, this equation is weakining.  It was
common to see inheritance bandied about in the OOA book of the last
few years.  I think this trend will decrease.

Classification will remain important as an analysis tool, but it
represents more options than just inheritance.  So inheritance will,
more and more, be relagated to the domain of design.

|I hope I am not repeating old arguments and rehashing old
|battles. If so, please ignore.

This is cutting edge stuff.  Nobody really knows what OOA is.  We all
have clues and guesses.  It will take time (many man-millenia) before
we can be more definitive.


--
+---Robert C. Martin---+-RRR---CCC-M-----M-| R.C.M. Consulting         |
| rmartin@rational.com |-R--R-C----M-M-M-M-| C++/C/Unix Engineering    |
|     (Uncle Bob.)     |-RRR--C----M--M--M-| OOA/OOD/OOP Training      |
+----------------------+-R--R--CCC-M-----M-| Product Design & Devel.   |
Xref: sparky comp.object:3071 comp.specification:334