From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.6 required=5.0 tests=BAYES_05,INVALID_DATE
	autolearn=no autolearn_force=no version=3.4.4
Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!linus!philabs!cmcl2!harvard!husc6!panda!genrad!decvax!ittatc!dcdwest!sdcsvax!sdcrdcf!hplabs!hpda!hpisoa2!hpitg!ucbvax!EBERARD@ucbvax
From: EBERARD@ucbvax
Newsgroups: net.lang.ada
Subject: Structured Analysis and Design, and
Message-ID: <14346450@ucbvax>
Date: Mon, 28-Apr-86 15:26:00 EDT
Article-I.D.: ucbvax.14346450
Posted: Mon Apr 28 15:26:00 1986
Date-Received: Wed, 14-May-86 01:15:05 EDT
List-Id: <comp.lang.ada>

Subject: Structured Analysis and Design, and OOD

Sam,
Regarding the use of traditional Structured Analysis (SA) and Structured
Design (SD) as a "front end" for an Object Oriented Design (OOD)
process: 

   1) SA and SD localize on functionality and OOD localizes on objects.
      (localization is based primarily on physical proximity.) This leads
      to some serious problems when it comes to interfacing "chunks" of
      the system which were designed on a high level with SASD and on a
      low level using OOD. While the scheme you have proposed is indeed
      feasible, based on observations of people who have actually tried
      it, you will have to become very familiar with variant records
      with large numbers of variants (i.e., this is one solution to the
      interface problem).

   2) "Object Oriented thinking" is very different from "Data and
      Process thinking." Those new to OOD often attempt to map familiar
      concepts, e.g., data and processes, directly to OOD concepts,
      e.g., objects and operations. For example, to the novice, it seems
      perfectly reasonable to map the data flows of SA to objects, and
      the processes of SA to operations. THIS IS ACCURATE ONLY IF THE
      DATA FLOW DIAGRAMS (DFD) WERE CREATED WITH AN "OBJECT ORIENTED
      MINDSET." Consider that in an OOD solution objects may have
      "life," e.g., an airplane in an air traffic control system
      (modeled as a task type in the Ada language), and operations may
      be treated as objects, e.g., passed as parameters.

There are some other observations: object oriented approaches tend to
produce more reusable software than approaches like SA and SD, SA and SD
tend to produce solutions with much more source code than object
oriented approaches, and it is far easier to trace requirements in an
object oriented solution since the solution more closely resembles the
original problem.

There are other approaches to software design which are as good as (and
sometimes better) than an object oriented approach. For example, Jackson
System Development (JSD) is an excellent real-time methodology, and is
far more appropriate as a "front end" for OOD than SA and SD. Some of
the modifications to the Vienna Development Method (VDM) seem to hold
great promise for the design of Ada software.
				-- Ed Berard
				   (301) 695 - 6960
-------