fbpx
Wikipedia

Structured analysis and design technique

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.

SADT basis element.

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 was 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:

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

References edit

  1. ^ a b D. Marca, C. McGowan, Structured Analysis and Design Technique, McGraw-Hill, 1987, ISBN 0-07-040235-3
  2. ^ a b c d e John Mylopoulos (2004). Conceptual Modelling III. Structured Analysis and Design Technique (SADT). Retrieved 21 September 2008.
  3. ^ SADT at Free-logistics.com. Retrieved 21 September 2008.
  4. ^ D. T. Ross: Structured Analysis (SA): A Language for Communicating Ideas. IEEE Transactions on Software Engineering, SE-3(1), pp. 16-34. Abstract
  5. ^ Dave Levitt (2000):Introduction to Structured Analysis and Design 7 September 2006 at the Wayback Machine. Retrieved 21 September 2008.
  6. ^ Gavriel Salvendy (2001). Handbook of Industrial Engineering: Technology and Operations Management.. p.508.
  7. ^ Nam Pyo Suh (2007). Axiomatic Design - Advances and Applications. New York : Oxford University Press Chapter 5, pp. 239-298.
  8. ^ 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

  • The IDEF0 method
  • A course about SADT diagrams

structured, analysis, design, technique, sadt, redirects, here, other, uses, sadt, disambiguation, sadt, systems, engineering, software, engineering, methodology, describing, systems, hierarchy, functions, sadt, structured, analysis, modelling, language, which. SADT redirects here For other uses see SADT disambiguation 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 SADT basis element Contents 1 Overview 2 History 3 SADT topics 3 1 Top down approach 3 2 Diagrams 3 3 Roles 4 Usage 5 See also 6 References 7 Further reading 8 External linksOverview editStructured 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 editSADT was 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 amp Sarson McMenamin amp Palmer Information technology engineering in circa 1990 with James Martin In 1981 the IDEF0 formalism was published based on SADT 6 SADT topics edit nbsp Top down decomposition structure nbsp 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 usersUsage editSADT 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 editIDEF0 Jackson structured programming Structure chart Structured systems analysis and design method Systems analysisReferences edit a b D Marca C McGowan Structured Analysis and Design Technique McGraw Hill 1987 ISBN 0 07 040235 3 a b c d e John Mylopoulos 2004 Conceptual Modelling III Structured Analysis and Design Technique SADT Retrieved 21 September 2008 SADT at Free logistics com Retrieved 21 September 2008 D T Ross Structured Analysis SA A Language for Communicating Ideas IEEE Transactions on Software Engineering SE 3 1 pp 16 34 Abstract Dave Levitt 2000 Introduction to Structured Analysis and Design Archived 7 September 2006 at the Wayback Machine Retrieved 21 September 2008 Gavriel Salvendy 2001 Handbook of Industrial Engineering Technology and Operations Management p 508 Nam Pyo Suh 2007 Axiomatic Design Advances and Applications New York Oxford University Press Chapter 5 pp 239 298 Ross Douglas T and Kenneth E Schoman Jr Structured analysis for requirements definition Software Engineering IEEE Transactions on 1 1977 6 15 Further reading editWilliam 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 amp 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 6External links edit nbsp Wikimedia Commons has media related to SADT The IDEF0 method A course about SADT diagrams Retrieved from https en wikipedia org w index php title Structured analysis and design technique amp oldid 1072058203, wikipedia, wiki, book, books, library,

article

, read, download, free, free download, mp3, video, mp4, 3gp, jpg, jpeg, gif, png, picture, music, song, movie, book, game, games.