NetNews Usenet Archive 1992 #18/NN_1992_18.iso/spool/comp/object/3215

Text File | 1992-08-15 | 3.6 KB | 75 lines

Newsgroups: comp.object
Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!moe.ksu.ksu.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!johnson
From: [e-mail] (Ralph Johnson)
Subject: Re: Class methods
Message-ID: <[e-mail]>
Organization: University of Illinois, Dept. of Comp. Sci., Urbana, IL
References: <[e-mail]> <[e-mail]>
Date: Sat, 15 Aug 1992 14:34:26 GMT
Lines: 64

[e-mail] (Sally Shlaer) writes:

>     THE PURPOSE OF ANALYSIS IS TO CAPTURE ALL OF THE INFORMATION ABOUT A
> PROBLEM DOMAIN:  What are the conceptual entities in the problem ... the
> the interrelationships between those entities, how the entities have to
> behave over time.  That is what Shlaer-Mellor OOA is all about.

later ...

> Yes.  And to preserve the information in a *useful form*, we must keep the
> information about the problem domain segregated from the information about
> the solution (a.k.a. design).  Once you mix these two domains of
> information, later designers and implementers cannot tell what they are
> free to change (design information) and what must be left intact (problem
> information).

[e-mail] writes:

>I fully agree with this premise.  I don't support the conclusion that
>the symbology must differ, or must differ entirely.  Not everything
>must be or should be expressed in symbology.  Consider the diagram on
>p. 187 of _Object Lifecycles_.  I cannot fathom what the hexagons
>contribute; so far as I can tell, the information could be presented
>purely as text.

Mat then says that what we really need to do is to tag each piece of
information with the phase in which it was introduced, and in that way
we can distinguish between the anlysis domain and the design domain.
(He actually has several more steps, but the idea is the same).

The Scandinavian school of objects says that programming is modeling,
and that an application program should be a model of the application
problem.  If you take this to an extreme, there shouldn't be any
difference between analysis and design.

Another point of view is that one person's specification is another
person's design.  You might write an equation that must hold between
a set of attributes of different objects and claim that this is a
specification that falls out of analysis, that it is part of the problem
domain and not the solution domain.  However, if you are using a
constraint programming language then those equations ARE your program.

The only real point I am trying to make here is that the boundary
between analysis and design is not only currently fuzzy, it will
always be fuzzy.  Making different notations for the various phases
might make it seem less fuzzy in people's minds, but that is an
artificial boundary.  Using a single notation for both not only makes
it easy to go from analysis to design, but it makes it easy to go
backwards, which often happens when you build a system and find out
that the customers didn't tell you what they really wanted, or that
introducing the system changes the environment that you were modeling.

Thus doesn't mean that we shouldn't try to separate analysis from design,
since first figuring out what problem you are trying to solve and then
trying to solve it is a standard and time-proven technique for solving
problems.  However, as in math and physics, trying to solve a problem
often shows us that we are trying to solve the wrong problem, so there
can never be an absolute separation between the two.

Probably everybody knows this already and I am just rambling.  But it
seemed like the two people I quoted might disagree with it.

Ralph Johnson