Xref: utzoo comp.software-eng:375 comp.lang.c++:931
Path: utzoo!mnetor!uunet!husc6!mailrus!ames!elroy!devvax!jplpro!des
From: des@jplpro.JPL.NASA.GOV (David Smyth)
Newsgroups: comp.software-eng,comp.lang.c++
Subject: Re: Object Oriented Design
Message-ID: <1711@devvax.JPL.NASA.GOV>
Date: 30 Mar 88 18:03:33 GMT
References: <2045@munnari.oz>
Sender: news@devvax.JPL.NASA.GOV
Reply-To: des@jplpro.JPL.NASA.GOV (David Smyth)
Organization: Jet Propulsion Laboratory, Pasadena CA.
Lines: 59

In article <2045@munnari.oz> taso@munnari.oz (Taso Hatzi) writes:
>
>I am seeking comment on the following questions from people who have 
>had success with any object oriented design methodology.

we are currently using ood for a system which in the past has been very large
and complex.  At this stage in the design everything looks rather straight-
forward, I am hoping for success!

>
> o What design documentation did you need and what form did it take?

The requirements were collected from lots of people with experience
at doing what the new system is supposed to support (programming
unmanned spacecraft, in this case).  The requirements were documented
in whatever manner seemed effective to the req author, and were not in
any way "object oriented" - confused along the line of "structured
design" if anything.

The design documents have an outline like this:
abstract
1.0 intro
1.1 references
1.2 bs to meet documentation standards
2.0 informal discussion of the problem, sort of an object-oriented
    requirements.
3.0 formal specification of the objects identified and discussed
    casually in section 2.  For each object:
3.x.1 Methods (functions, operators)
3.x.2 Attributes (public data)

We are still developing the documentation.  For example, people are still
not clear on what is class data, and instance data from the list of
Attributes.  It makes a big difference when people start implementing
the objects.  Also, the section numbers start getting too long when
we try and represent the inheritance of classes within the document
structure.  I have started just using .NH 3 only, because a fully
hierarchical numbering system precludes multiple inheritance, and
we need multiple inheritance.  

We have 2 layers of these design documents.  One for a "system" and
one fort each of the objects in section 3: 3.x would go into one
object design doc, 3.y goes into another.


>
> o What characterizes a properly designed system?

Does it work?  Is it easy for people to understand?  Does it do
what the requirements people REALLY need (not just what they wrote,
which is usually an improper subset of the ACTUAL requirements).
>
> o Do there exist any well known object oriented design methodologies?

1. understand the problem however you need to.
2. figure out the general objects required, and what look like (attrs),
   what they act like (methods).
3. formally list and describe the attrs and methods for each object.
4. implement the objects, most general first, most specific last.