Structured analysis and design technique

From Wikipedia, the free encyclopedia

"SADT" redirects here. For other uses, see SADT (disambiguation).

SADT basis element.

Structured analysis and design technique (SADT) is a systems engineering and software
engineering methodology for describing systems as a hierarchy of functions. SADT is
a structured analysis modelling language, which uses two types of diagrams: activity
models and data models. It was developed in the late 1960s by Douglas T. Ross, and was
formalized and published as IDEF0 in 1981.

Contents
[hide]

 1Overview
 2History
 3SADT topics
o 3.1Top-down approach
o 3.2Diagrams
o 3.3Roles
 4Usage
 5See also
 6References
 7Further reading
 8External links

Overview[edit]
Structured analysis and design technique (SADT) is a diagrammatic notation designed
specifically to help people describe and understand systems.[1] It offers building blocks to
represent entities and activities, and a variety of arrows to relate boxes. These boxes and
arrows have an associated informal semantics.[2]SADT can be used as a functional analysis
tool of a given process, using successive levels of details. The SADT method not only allows
one to define user needs for IT developments, which is often used in the industrial Information
Systems, but also to explain and present an activity’s manufacturing processes and
procedures.[3]

History[edit]
SADT has been developed and field-tested during the period of 1969 to 1973 by Douglas T.
Ross and SofTech, Inc..[1][4] The methodology was used in the MIT Automatic Programming
Tool (APT) project. It received extensive use starting in 1973 by the US Air Force Integrated
Computer Aided Manufacturing program.
According to Levitt (2000) SADT is "part of a series of structured methods, that represent a
collection of analysis, design, and programming techniques that were developed in response to
the problems facing the software world from the 1960s to the 1980s. In this timeframe most
commercial programming was done in COBOL and Fortran, then C and BASIC. There was
little guidance on “good” design and programming techniques, and there were no standard
techniques for documenting requirements and designs. Systems were getting larger and more
complex, and the information system development became harder and harder to do so. As a
way to help manage large and complex software.[5]
SADT was among a series of similar structured methods, which had emerged since the 1960
such as:

 Structured programming in circa 1967 with Edsger W. Dijkstra.

 Structured design around 1975 with Larry Constantine and Ed
Yourdon
 Structured analysis in circa 1978 with Tom DeMarco,
Yourdon, Gane & Sarson, McMenamin & Palmer.
 Information engineering in circa 1990 with James Martin.
In 1981 the IDEF0 formalism was published, based on SADT.[6]

SADT topics[edit]
Top down decomposition structure.

An SADT example.

Top-down approach[edit]
The structured analysis and design technique uses a decomposition with the top-down
approach. This decomposition is conducted only in the physical domain from an axiomatic
design viewpoint.[7]
Diagrams[edit]
SADT uses two types of diagrams: activity models and data models. It uses arrows to build
these diagrams. The SADT’s representation is the following:

 A main box where the name of the process or the action is

specified
 On the left-hand side of this box, incoming arrows: inputs of
the action.
 On the upper part, the incoming arrows: data necessary for
the action.
  On the bottom of the box, incoming arrows: means used for
the action.
 On the right-hand side of the box, outgoing arrows: outputs of
the action.
The semantics of arrows for activities:[2]

 Inputs enter from the left and represent data or consumables

that are needed by the activity.
 Outputs exit to the right and represent data or products that
are produced by the activity.
 Controls enter from the top and represent commands or
conditions which influence the execution of an activity but are
not consumed.
 Mechanisms identify the means, components or tools used to
accomplish the activity. Represents allocation of activities.
The semantics of arrows for data:[2]

 Inputs are activities that produce the data.

 Outputs consume the data.
 Controls influence the internal state of the data.
Roles[edit]
According to Mylopoulos (2004) in the software development process multiple roles can or
should be distinguished:[2]

 Author or developer of the SADT models

 Commenters, who review the author's work
 Readers or users of the SADT models
 Experts, who can advise the authors
 Technical committee or reviewers of the SADT models in
detail
 Project librarian, who govern the project documentation
 Project manager, who governs the system analysis and
design.
 Monitor or chief analyst to assists SADT developers and users
 Instructor to train SADT developers and users

Usage[edit]
SADT is used as diagrammatic notation in conceptual design of software engineering and
systems engineering to sketch applications,[2] for more detailed structured analysis, for
requirements definition,[8] and structured design.

See also[edit]
 IDEF0
  Jackson structured programming
 Structure chart
 Structured systems analysis and design method
 Systems analysis

References[edit]
1. ^ Jump up to:a b D. Marca, C. McGowan, Structured Analysis
and Design Technique, McGraw-Hill, 1987, ISBN 0-07-040235-3
2. ^ Jump up to:a b c d e John Mylopoulos (2004). Conceptual
Modelling III. Structured Analysis and Design Technique
(SADT). Retrieved 21 September 2008.
3. Jump up^ SADT at Free-logisitcs.com. Retrieved 21
September 2008.
4. Jump up^ D. T. Ross: Structured Analysis (SA): A Language
for Communicating Ideas. IEEE Transactions on Software
Engineering, SE-3(1), pp. 16-34. Abstract
5. Jump up^ Dave Levitt (2000):Introduction to Structured
Analysis and Design. Retrieved 21 September 2008.
6. Jump up^ Gavriel Salvendy (2001). Handbook of Industrial
Engineering: Technology and Operations Management.. p.508.
7. Jump up^ Nam Pyo Suh (2007). Axiomatic Design - Advances
and Applications. New York : Oxford University Press Chapter 5,
pp. 239-298.
8. Jump up^ Ross, Douglas T., and Kenneth E. Schoman Jr.
"Structured analysis for requirements definition." Software
Engineering, IEEE Transactions on 1 (1977): 6-15.

Further reading[edit]
 William S. Davis (1992). Tools and Techniques for Structured
Systems Analysis and Design. Addison-Wesley. ISBN 0-201-
10274-9
 Marca, D.A., and C.L. McGowan. (1988). SADT: structured
analysis and design technique. McGraw-Hill Book Co., Inc.:
New York, NY.
 Jerry FitzGerald and Ardra F. FitzGerald
(1987). Fundamentals of Systems Analysis: Using Structured
Analysis and Design Techniques. Wiley. ISBN 0-471-88597-5
 David A. Marca and Clement L. McGowan (1988). SADT:
Structured Analysis and Design Technique. McGraw-
Hill. ISBN 0-07-040235-3
 D. Millington (1981). Systems Analysis and Design for
Computer Applications. E. Horwood. ISBN 0-85312-249-0
 Robertson & Robertson (1999). Mastering the Requirements
Process. Addison Wesley.
 James C. Wetherbe (1984). Systems Analysis and Design:
Traditional, Structured, and Advanced Concepts and
Techniques. West Pub. Co. ISBN 0-314-77858-6
 External links[edit]
Wikimedia Commons has
media related to SADT.

 The IDEF0 method

 A course about SADT diagrams
Categories:
 Systems analysis
Navigation menu
 Not logged in

 Talk

 Contributions

 Create account

 Log in
 Article
 Talk
 Read
 Edit
 View history
Search
Go

 Main page
 Contents
 Featured content
 Current events
 Random article
 Donate to Wikipedia
 Wikipedia store
Interaction
 Help
 About Wikipedia
 Community portal
 Recent changes
 Contact page
Tools
 What links here
 Related changes
 Upload file
 Special pages
 Permanent link
 Page information
 Wikidata item
 Cite this page
Print/export
 Create a book
 Download as PDF
 Printable version
In other projects
 Wikimedia Commons
Languages
 Deutsch
 Español
 Français
 日本語
 Русский
Edit links
 This page was last edited on 1 July 2017, at 20:21.
 Text is available under the Creative Commons Attribution-ShareAlike License;
additional terms may apply. By using this site, you agree to the Terms of
Use and Privacy Policy. Wikipedia® is a registered trademark of the Wikimedia
Foundation, Inc., a non-profit organization.

 Privacy policy

 About Wikipedia

 Disclaimers

 Contact Wikipedia

 Developers

 Cookie statement

 Mobile view