Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!husc6!cmcl2!philabs!steinmetz!macbeth!hallett
From: hallett@macbeth.steinmetz (Hallett)
Newsgroups: comp.sys.mac,comp.lang.smalltalk,comp.lang.c++
Subject: Re: Systematic OO development method
Message-ID: <6029@steinmetz.steinmetz.UUCP>
Date: Thu, 21-May-87 08:59:06 EDT
Article-I.D.: steinmet.6029
Posted: Thu May 21 08:59:06 1987
Date-Received: Sat, 23-May-87 14:20:15 EDT
References: <623@SouthBank.UUCP>
Sender: root@steinmetz.steinmetz.UUCP
Reply-To: hallett@desdemona.UUCP (Hallett)
Organization: General Electric CRD, Schenectady, NY
Lines: 90
Keywords: object oriented design, MacApp, Object Pascal, Smalltalk, requirements elicitatio
Summary: A Brief Methodology
Xref: mnetor comp.sys.mac:3375 comp.lang.smalltalk:117 comp.lang.c++:282

I apologize to everyone who doesn't care about this.  I found myself unable 
to respond directly to the address below.  For some reason it came back.
Oh, well.  If Nick will send me mail directly, perhaps I can reply with
more info.

In article <623@SouthBank.UUCP> lawesn@SouthBank.UUCP (Nick Lawes) writes:
>
>Request for information from designers/developers
>of object oriented systems:
>
>The idea is to structure information about the target system at the earliest
>possible stage.
>
First, I salute him on his approach.  An excellent idea and very sound 
software engineering.
>
>	+ what kind of approach did you take to the design of your system.
>	+ how did you select your classes.
>	+ how did you manage inheritance in your system.
>	+ did you make use of the model-view-controller paradigm.
>	+ based on your experience, how would you approach the same problem
>	  if you had to start all over again.
>

There are several sources of O.O. design principles now on the market.  
If Nick writes me, I will be glad to relate those (if ANYONE writes ...).
One in particular advanced here goes something as follows:

1.  Identify the data abstractions for each subsystem.
	Most OO systems are obviously OO systems, ie. the majority of
the objects come straight from the requirements document and the rest are
often discovered when working in a top-down manner (refining).  These
objects are usually physical components of the system, but sometimes,
pseudo-objects or "control objects" must be introduced.

2.   Identify the attributes of each abstraction.
	Again, there are obvious ones, but only after refining the design 
will more become apparent.

3.  Identify the operations (methods) for each abstraction.

4.  Identify the communication between the abstractions.
	This involves identifying the messages required to activate the 
methods of #3.

5.  TEST the design with scenarios.
	This is the refining step mentioned above.  Draw pictures do what
ever is necessary to act out situations.  This is where the designer tests
if the system is matching the requirements.  Often, these scenarios will
point out objects, attributes and messages that are missing.

6.  Apply inheritance.
	Collapse classes that share attributes.  Don't attempt to do this
immediately unless it is terribly obvious.  Wait until all the objects are
established and then compare them to find similarities.

7.  REITERATE.  (Obviously... 8=))

I'm not an expert and don't claim to be.  I've just done some of this and
this method works well for me.  A rule of thumb I live by is that solutions
suggest implementations.  Don't try to force O.O. just because it is a good
buzz-word.  If you design suggests O.O. then do it; if it looks like O.O
will only give you problems, throw it out.  This goes for language choice,
data structures and other things as well.

One last note -- when doing scenarios, it is important to enact them as
stupidly as possible.  I mean that you shouldn't read in information
from your point of view.  You know more than the objects in the system,
so don't assume they know things.  Act it out entirely from their point
of view, working with only what they know.  This is the most difficult
thing to do and takes the most care and practice.  It is also where many
O.O. systems go wrong in designing.

Sorry about the long-windedness.  Again, if you have flames, send them to
me.  Let's not be stupid like me and tie up the net debating ;-).  I have
further references for interested people.

Jeffrey A. Hallett               (hallett@ge-crd.arpa   hallett@desdemona.uucp)
Software Technology Program
General Electric Corporate Research and Development

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"The needs of the few outweigh the needs of the many"

                                 -- Kirk  (STIII)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Disclaimer:  My opinions do not represent my employer's, but it is his fault 
             for giving me this thing.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~