Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!rutgers!rochester!pt.cs.cmu.edu!sei!ajpo!eberard
From: eberard@ajpo.sei.cmu.edu (Edward Berard)
Newsgroups: comp.software-eng
Subject: Re: SA/SD vs OOD
Summary: Localization is the major problem
Message-ID: <524@ajpo.sei.cmu.edu>
Date: 22 Jun 89 12:02:18 GMT
References: <9482@aw.sei.cmu.edu>
Lines: 70

In article <9482@aw.sei.cmu.edu>, sdec@sei.cmu.edu (Susan Coddington) writes:
> I am interested in any research and/or experience dealing with compatibility 
> issues between structured methodologies (i.e. Structured Analysis and 
> Structured Design) and Object Oriented Design.
> 
> If you have any information on this subject, please respond via e-mail.
> 

Functional decomposition approaches, such as SA/SD, localize
information around functions. Object-oriented approaches, such as OOD,
localize information around objects. Since objects are not functions,
this results in quite a few nasty problems, e.g.:

	- A large project is initially partitioned along functional
	  lines (e.g., CSCIs). Each of these large functional chunks
	  is given to a separate team for further development using an
	  object-oriented approach.  Team A, for example, identifies a
	  candidate object (X) with attributes A, B, and C. Team B
	  identifies the same object (X), but with attributes B, D,
	  and F. Each has an incomplete (and incompatible) view of the
	  same object. This problem, unfortunately, will not be
	  uncovered until integration, i.e., late in the development
	  part of the life-cycle.

	- Even if the above problem is surmounted, there is still a
	  large traceability problem. SA/SD meshes very nicely with
	  functional requirements. However, due to localization
	  incompatibilities, it is very difficult to trace functional
	  requirements to object-oriented code.

	- The technical staff may be very familiar with functional
	  decomposition, but very unfamiliar with object-oriented
	  approaches. All goes well until the point where they are
	  supposed to transition to the object-oriented approach. In
	  the resulting confusion, many errors are introduced.

Years ago, in the 1970s, structured approaches helped to bring (at
least some) order out of the chaos of software development. Now there
seems to be a "better" approach, i.e., an object-oriented approach. It
is correct to assume that we can take some of the things we learned
from structured approaches, and apply them to an object-oriented
approach. The question is "which things?"

Good candidates are: loose module coupling, high module cohesion,
defensive programming, avoidance of decision splitting, and an overall
systematic top-down approach. Not so good candidates are: data flow
diagrams, structure charts, data dictionaries, and
input-processing-output

In addition to leaving some things behind, many new concepts must be
introduced, including, reusability, classes, "objects with life," and
systems of objects.

At one time I used to say that OOD (ala Booch) required a "front end,"
i.e., something which preceded it in the life-cycle. I still say that.
However, I, and others, know from unpleasant experience, that that
precursor should be object-oriented (e.g., Object-Oriented
Requirements Analysis (OORA)).

Finally, a warning: watch out for well-intentioned people who try to
sell you methodologies or CASE tools which claim to blend functional
decomposition approaches with object-oriented approaches. The more you
understand about object-orientation, the less you will see a need for
such items.

				-- Ed Berard
				   Berard Software Engineering, Inc.
				   18620 Mateney Road
				   Germantown, Maryland 20874
				   Phone: (301) 353-9652