Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!bellcore!uunet!munnari.oz.au!yoyo.aarnet.edu.au!sirius.ucs.adelaide.edu.au!fang!dch
From: dch@aeg.dsto.oz.au (Dave Hanslip)
Newsgroups: comp.lang.c++
Subject: Re: Analysis/Design Methods for OOP
Message-ID: <1574@fang.dsto.oz>
Date: 21 Jun 91 19:51:13 GMT
References: <44056@fmsrl7.UUCP> <542@daily-planet.concordia.ca>
Sender: news@fang.dsto.oz
Lines: 80

victor@concour.cs.concordia.ca (KRAWCZUK victor) writes:


>But if the project is of any significant size, the design phase can
>become too much of a task for one or two people.  Adding more people
>without a war plan (like top-down design teams for non-OO programming)
>to the design team is obviously fruitless.  Has anyone had any
>experience good in this realm?  Or, can anyone recommend a good book
>or article on how the design phase of an OO project can be managed
>when the design must be done in a hurry, and the task is too involved
>for 1 or 2 people who can tap each other on the shoulder, since the
>boss expects quality work but can't wait until the 21st century?

We have been wrestling with this problem for some time. As with any large
problem, one must decompose the problem into smaller ones, analysable,
designable and implementable by small teams. There is no guidance anywhere as
far as I know on how to do this best from an OO point of view. As Booch notes,
non-problem space matters impinge on this too, such as implementation by 
different contractors and one's schedule. In our case we have a small team and
long schedule. This means incremental development and this too impacts how one
structures the design.

I have just been reading a paper by Shlaer and Mellor, "Recursive Design and
its Effect on the Project Life Cycle" in which they propose breaking the 
problem into loosely coupled "domains" that enclose "specific and separate
subject matter". "Domain" may or may not equate to "subsystem". I need to
cogitate more on this. Right now "domains" as identified in the paper don't
spring to mind for our project.

We have actually ended up with a subsystem breakdown that is based primarily on
encapsulation and information hiding. We are now firmly committed to the
principles expounded by Booch and are using his notation. A CASE tool would
definitely be useful here!

I am structuring the system using an approach that I have not seen elsewhere in
that I am using the static objects to structure both the design and the
documentation. This is difficult to explain in a text only forum. For example
though, we have an object called theUserInterface. It consists of objects such
as theDisplaySubsystem, theAlertSubsystem, theCueSubsystem, theKeyboard etc.
theUserInterface has a member function displayCue. It passes on the message
to theCueSubsystem. It assembles characters from theKeyboard into aCueResponse.
theUserInterface also has a member function sendCueResponse. theCueSubsystem
sends a message to theUserInterface:

theUserInterface -> sendCueResponse(&CueResponse);

theUserInterface then notifies the appropriate object of the cue response. This
is simplified but essentially it allows theCueSubsystem to be designed and 
implemented independently.

The structure we end up with looks like this:

              A----------------------------------------R
             / \                                      / \
            /   \                                    /   \
           B     C                                  S     T
          / \   / \                                / \   / \
         /   |  |  \                              /   |  |  \
        D    E  F   G                            U    V  W   X

This is an object diagram, with A an aggregate of the classes below it, and R
an aggregate of the classes below it. All classes are "static" in that they 
exist for the life of the application. Messaging between classes below
A and below B could be handled by making them visible to each other but we
have elected to route messages up and down through the hierachies. The hierarchies of static objects we end up with are a bit like a functional
decomposition structure but they are objects not functions. The static objects
manage, operate on or dispatch around the system, the dynamic objects such as,
in our case, cues, alerts and radar contacts.

Since the A and R objects above are loosely coupled and equate with subsystems,
the amount of communication between them should not be great. We now have a
decomposition which allows design and implementation by a team followed by an
integration phase. This also provides us with a natural way of assembling the 
system.

Hope this helps.

David C. Hanslip                              E-mail: dch@aeg.dsto.oz.au
Aeronautical Research Laboratory              Phone: +61 8 259 5792
DSTO Salisbury, South Australia               Fax: +61 8 259 5507