Path: utzoo!attcan!uunet!ncc!alberta!oha!access!edm!ahe3b1!root
From: root@ahe3b1.UUCP (Root)
Newsgroups: comp.software-eng
Subject: Re: Anybody know about SADT?
Message-ID: <2662@ahe3b1.UUCP>
Date: 15 May 88 01:49:21 GMT
References: <660@vsi.UUCP>
Distribution: comp
Organization: Alberta Hospital, Edmonton,AB.
Lines: 75

From article <660@vsi.UUCP>, by friedl@vsi.UUCP (Stephen J. Friedl):
> SADT: Structured Analysis and Design Technique by David A.
> Marca and Clement L. McGowan ("with a forward by Douglas T.
> Ross").
> 
>      (A) How is SADT?
>      (B) How is this particular book?
>      (C) If one wanted to be exposed to a couple of ways
> 	 of doing SA, what is a good second choice?
>

From my reading of the book, SADT is an extremely powerful system
modeling technique with potential way beyond software engineering.
In fact, it appears to have gotten more use in organizational analysis
and design than anywhere else (E.G. job design and control).

The basic conceptual unit (the SA box) :

                       |
                       |  CONTROL
                       V
                -----------------
                |               |
 INPUT  ------> | (subject)     | ---> OUTPUT
                |               |
                -----------------
                       ^
                       |  MECHANISM


can be combined and/or successively decomposed to model virtually
any task. The running example in the book is an analysis of a
Tool Shop. Example subjects: Pick Tools, Setup Machining Place,
Evaluate Job Progress. Example control flows: Blueprints, Job
Completion requests, Job order steps. Example Outputs/Inputs: 
Unfinished Parts, Tool Crib, etc.

The book is an extremely detailed 'step-by-step' cookbook which
includes a great deal of information about how to manage 
and organize the products (including standards,etc.)
of an SADT analysis (Each set of SA box diagrams is called a KIT, the
construction of a KIT is called an AUTHOR/READER cycle). The latter
half of the book gives example KITS from 4 application areas.
The technique is of course copyrighted and sold by a Mass. company
called SofTech.

The most frustrating aspect of the book to me was the enigmatic
claim in the preface by the technique's inventor:
'There are two main styles of SA modeling: activity models stress
the happenings of the system; data models stress the things of
a system. Both use the same box-and-arrow graphic language, in dual
ways (the roles of boxes and arrows interchange)'.

That unfortunately was the last reference to data modeling; the rest
of the book concentrates exclusively on activity modelling.

I have absolutely no doubt that a properly executed SADT would serve
as a superb basis for a software construction project.

It would take a long time and it would highlight the context within which
the system would be expected to operate, but it might raise very sticky
questions about the functioning of the organizational unit being modeled.
(i.e. make sure that a corporate sponser is prepared to question the
operation of the WHOLE unit, not just the 'computerized' part of it).
 
As the authors present the method, I have doubts about its utility/cost
ratio. But as a structured technique for requirements analysis or
'getting a feel for the problem' it makes a useful addition to the
armamentorium of the individual system analyst/designer.


Don Schopflocher
Alberta Hospital Edmonton Psychiatric Treatment Center

'Yes and I must be nuts to be in this business'