Newsgroups: comp.lang.c++,comp.object,comp.lang.smalltalk
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!howland.reston.ans.net!pipex!uunet!rcm!rmartin
From: rmartin@rcmcon.com (Robert Martin)
Subject: Re: Teaching OO
References: <1994Dec26.162401.6570@rcmcon.com> <RFR0lOfN33q2071yn@IIA> <AKV.95Jan8184845@srl03.usl.edu> <3ettm9$rj3@seralph9.essex.ac.uk> <3evfec$5ah@nova.umd.edu> <3evjp1$13fg@news-s01.ny.us.ibm.net> <gened.73.2F169515@cns.com>
Organization: R. C. M. Consulting Inc. 708-918-1004
Date: Sat, 14 Jan 1995 18:00:36 GMT
Message-ID: <1995Jan14.180036.5148@rcmcon.com>
Lines: 180
Xref: glinda.oz.cs.cmu.edu comp.lang.c++:107473 comp.object:25054 comp.lang.smalltalk:19544

gened@cns.com (Eugene Dowen) writes:

>Robert,

>I've been reading this thread for some time now and I have a number of 
>concerns on how you approach OO.  First let me provide a context.  I see OO 
>as a "revolutionary evolution".  In SA/D we spent our time deciding:
>	what to do?
>	what to do it to?, and
>	where to do it?

>These tasks lead us through DFD's and structure charts, and these method(s) 
>have served us well.  OO has the same tasks (the evolution), but the focus is 
>on the "thing", not on the "process".  In OO:
>	what is it?
>	what does it contain?, and 
>	what do we do to it?

>This is a fundamental change in how we approach a problem (revolution!).  
>We no longer use the "process" as the beginning of a design, we identify the 
>"things" we need to worry about in the problem domain first.  

If you think about this more, I think you will find that the "need"
for a process comes first.  Then the identification of an object that
can fulfull that process, then the identifcation of an abstraction of
that object, and then the identification of the particular derivative
of that abstraction, and finally the actual process itself.

>Many analysis tools (like Jacobson's Use Cases) use process focused 
>techniques to identify objects, 

Yes, to isolate the "need" for the process.

>but , IMHO, once the objects are identified (what is it?) the next
>two steps come in order.  This implies that the "program" part (that
>part of the system that manipulates the objects to solve specific
>requirements in the problem domain) of the solution is ignored.
>Domain object construction focuses only on what this object has to
>provide the system to satisfy it's own duties (requirements).  This
>enhances the probability of being able to reuse these domain objects
>for different specific solutions within the whole domain, not just
>this particular solution.

Once the objects are identified, they need to be abstracted.  Some of
the behavior will be relegated to the abstract component.  This will
be the high level policy that is reusable with the abstraction.  The
details can be defered to a later time.

>This approach is not a single (waterfall) pass but is iterative 

AGREED.

>With that as a very simplified context:

>>Date: Thu, 5 Jan 1995 23:13:35 GMT
>>Message-ID: <1995Jan5.231335.7496@rcmcon.com>

>>Detail first IMHO.  Binary, simple logic, flow charts, etc.  Then
>>Knuth's Fundemental Algorithms.  Then Wirth's Algorithms + Data
>>Structures = Programs.  Then Demarco's Structure Analysis and
>>Page-Jones' Structured Design.   Then Booch or Rumbaugh, OOD.  And
>>many other steps in between.

>Here I agree except that I would switch OOD with SA/D.  I believe
>SA/D techniques are very power tools for flushing out the methods
>defined for a particular object.  In using them we can identify
>internal objects that may not have been identified yet as a part of
>the iterative process.  But I don't believe teaching SA/D first is as
>useful as establishing a strong OO floor on which to build OOA, OOD,
>and then SA/D.

I think you are equating OOAD with software engineering.  I think we
strong Software engineering floor upon which to build OOAD skills.
Part of that floor is SA/SD. IMHO.

>>Date: Thu, 5 Jan 1995 23:23:48 GMT
>>Message-ID: <1995Jan5.232348.7623@rcmcon.com>
>>SADP is not simpler than OOAD, because OOAD subsumes SADP and then
>>adds.  All the same rules of SADP apply to OOAD, and then more are
>>added.  

>This may be true for implementation languages like C++, but I disagree that 
>all the same rules apply.  SA/D demanded that the process space that solved 
>the problem in the domain be analyzed and defined in procedural terms first.  
>This just is not the way, IMHO, OO should be tackled.  I first want to ID the 
>"things", not the "processes", that's last.

I should have been more specific.  OO puts SA/SD into a new context.
Within an OO project, one does not practice SA/SD as it was intended;
i.e. as a the mechanisms for analysing and designing the whole
project.  But one can use it for isolated parts of the application.
And within those isolated parts, the old rules still apply, as long as
they do not contradict the OO principles that override them.

>>Date: Fri, 6 Jan 1995 22:36:37 GMT
>>Message-ID: <1995Jan6.223637.13950@rcmcon.com>
>>SD produces high level policies that depend upon the details that they
>>control.  This is evident in a structure chart.  The high level policy
>>laden functions must call the low level detail laden functions.
>>
>>In OOD, the opposite is true, the low level detailed classes depend
>>upon the high level abtract classes that set the policies.  This is
>>"dependency inversion" and it is at the heart of OOD.

>This is profound!  OOA will define abstract things that make up the problem 
>domain.  OOD will refine this abstract world and give it form.  This process 
>produces a design that achieves "dependency inversion" while preserving the 
>abstractions that define the problem domain and the solution that manipulates 
>the classes to fulfill the requirements for the specific problem within the 
>domain.

>>Date: Fri, 6 Jan 1995 22:50:53 GMT
>>Message-ID: <1995Jan6.225053.14088@rcmcon.com>
>>Usually the benefits of OOD outweigh the costs.  But not in every
>>case.  There will always be applications that have short lifetimes, or
>>limited deployment that could never recapture the costs of OOD and are
>>better off being developed using SA/SD.

>This is just flat wrong.  I can still (and do) produce better, more
>error free solutions using OO techniques.  For systems I -know- will
>be short lived, I may not spend as much time analyzing the hierarchy,
>designing for reuse, or adjusting objects for a more polymorphic fit.
>But even if I do nothing but apply encapsulation - I will have a
>better system than SA/D alone will give me.

I won't dispute that you fare better using OO techniques (if not OOD)
in short life-cycle tasks.  On the other hand, I still maintain that
SA/SD has a place in the tooklit of an engineer.  And that there are
applications and environments that will fare better if they are
primarily SA/SD driven. I think they are few, and extremely unique.
But I think they exist.

>>Date: Thu, 29 Dec 1994 13:42:27 GMT
>>Message-ID: <1994Dec29.134227.9665@rcmcon.com>
>>>I allways thought to model an object you

>>>1. name the object
>>>2. describe its structure [variables/attributs]
>>>3.      and its _potential_ behavior [methods]
>>>4. describe its _actual_ behavior [state(transition)s]

>>Flip a few of these:

>>1. Ascertain that a certain behavior exists
>>2. Assign it to an appropriate object. 
>>3. Create the state machine for the object
>>4. Implement the object.
>>    4a. Determine a workable data structure
>>    4b. implement the state machine.

>I see this as an interesting mix of OO and SA/D.  How do you assign a 
>behavior that is complex and uses several potential peer objects?  

You abstract the behavior in terms of the abstract interfaces of its
peers.

>How can you assign the behavior to an object if the objects are not
>defined yet?

Part of defining an object is determining that a behavior must exist.
Thus you need an object in which to place that behavior.

>How do you know what behaviors are needed until the attributes are
>identified?

The behaviors of the application are known well in advance of the
attributes of certain objects.  That's what a requirements document
is, when you boil it down; it is a list of required behaviors.

>Who owns the behavior you start with?  In what context does the behavior 
>exist?

Is begins ownerless.  We seek to find groups of behaviors that can be
clustered under a single umbrella and given state information.  i.e.
objects.  
-- 
Robert Martin       | Design Consulting   | Training courses offered:
Object Mentor Assoc.| rmartin@rcmcon.com  |   Object Oriented Analysis
2080 Cranbrook Rd.  | Tel: (708) 918-1004 |   Object Oriented Design
Green Oaks IL 60048 | Fax: (708) 918-1023 |   C++
