Structured analysis: Difference between revisions

Revision as of 12:50, 18 January 2017

Latest revision as of 09:54, 29 July 2025

(34 intermediate revisions by 30 users not shown)

Line 1:

{{Short description|Software engineering method}}

[[Image:Context diagram and Technical Criteria Derivation.jpg|thumb|320px|Example of a structured analysis approach.<ref>Tricia Gilbert (2006) [http://acast.grc.nasa.gov/wp-content/uploads/icns/2006/06_Session_B1/03-Gilbert.pdf FCS Evaluation criterea for technology assessment] {{Webarchive|url=https://web.archive.org/web/20080918012417/http://acast.grc.nasa.gov/wp-content/uploads/icns/2006/06_Session_B1/03-Gilbert.pdf |date=2008-09-18 }}</ref>]]

In [[software engineering]], '''structured analysis''' (SA) and '''structured design''' (SD) are methods for analyzing business [[requirements]] and developing [[specification]]s for converting practices into [[computer program]]s, hardware configurations, and related manual procedures.

Line 5 ⟶ 6:

== Objectives of structured analysis ==

Structured analysis became popular in the 1980s and is still in use today. {{Citation needed|date=March 2016}} Structured analysis consists of interpreting the [[system]] concept (or real world situations) into data and control terminology represented by [[data flow diagram]]s. The flow of data and control from bubble to the data store to bubble can be difficult to track and the number of bubbles can increase.

One approach is to first define events from the outside world that require the system to react, then assign a bubble to that event. Bubbles that need to interact are then connected until the system is defined. Bubbles are usually grouped into higher level bubbles to decrease complexity. [[Data dictionary|Data dictionaries]] are needed to describe the data and command flows, and a process specification is needed to capture the transaction/transformation information.<ref name="FAA00">FAA (2000). [http://www.faa.gov/regulations_policies/handbooks_manuals/aviation/risk_management/ss_handbook/media/app_d_1200.pdf ''FAA System Safety Handbook, Appendix D'']. December 30, 2000.</ref>

SA and SD are diplayeddisplayed with [[structure chart]]s, [[data flow diagram]]s and [[data model diagram]]s, of which there were many variations, including those developed by [[Tom DeMarco]], [[Ken Orr]], [[Larry Constantine]], [[Vaughn Frick]], [[Ed Yourdon]], Steven Ward, [[Peter Chen]], and others.

These techniques were combined in various published [[Software development process|system development methodologies]], including [[structured systems analysis and design method]], profitable information by design (PRIDE), Nastec structured analysis & design, SDM/70 and the Spectrum structured system development methodology.

== History ==

Structured analysis 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 (programming language)|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."<ref name="DL00">Dave Levitt (2000). "Introduction to Structured Analysis and Design." at ''faculty.inverhills.edu/dlevitt''. Retrieved 21 Sep 2008. No longer online 2017.</ref>

As a way to help manage large and complex software, the following structured methods emerged since the end of the 1960s :<ref name="DL00"/>

* [[Structured programming]] in circa 1967 with [[Edsger Dijkstra]] - "Go To Statement Considered Harmful"

* [[Niklaus Wirth]] Stepwise design in 1971

Line 23 ⟶ 24:

* [[HIPO]] in 1974 - IBM Hierarchy input-process-output (though this should really be output-input-process)

* [[Structured design]] around 1975 with [[Larry Constantine]], [[Ed Yourdon]] and [[Wayne Stevens (software engineer)|Wayne Stevens]].{{sfn|Stevens|Myers|Constantine|1974}}{{sfn|Yourdon|Constantine|1979}}

* [[Jackson structured programming]] in circa 1975 developed by [[Michael A. Jackson (computer scientist)|Michael A. Jackson]]

* Structured analysis in circa 1978 with [[Tom DeMarco]], [[Edward Yourdon]], Gane & Sarson, McMenamin & Palmer.

* [[Structured Analysis and Design Technique|Structured analysis and design technique]] (SADT) developed by [[Douglas T. Ross]]

* [[Edward Yourdon#Yourdon Structured Method|Yourdon structured method]] developed by [[Edward Yourdon]].

* Structured analysis and system specification published in 19791978 by [[Tom DeMarco]].

* [[Structured systems analysis and design method]] (SSADM) first presented in 1983 developed by the [[UK government|UK]] [[Office of Government Commerce]].

*[[Essential Systems Analysis]], proposed by Stephen M. McMenamin and John F. Palmer<ref>{{Cite book|last1=McMenamin|first1=Stephen M.|url=https://archive.org/details/essentialsystems00mcme|url-access=registration|title=Essential Systems Analysis|last2=Palmer|first2=John F.|date=1984|publisher=Yourdon Press|isbn=978-0-13-287905-7|language=en}}</ref>

* [[IDEF0]] based on SADT, developed by [[Douglas T. Ross]] in 1985.<ref>Gavriel Salvendy (2001). ''Handbook of Industrial Engineering: Technology and Operations Management.''. p.508.</ref>

* [[Hatley-Pirbhai modeling]], defined in "Strategies for Real-Time System Specification" by Derek J. Hatley and Imtiaz A. Pirbhai in 1988.

*[[Modern Structured Analysis]], developed by Edward Yourdon, after Essential System Analysis was published, and published in 1989.<ref>{{Cite book|last=Yourdon|first=Edward|url=https://books.google.com/books?id=QetnQgAACAAJ&dq=Modern+Structured+Analysis|title=Modern Structured Analysis|date=1989|publisher=Prentice-Hall|isbn=978-0-13-598632-5|language=en}}</ref>

* [[Information technology engineering]] in circa 1990 with Finkelstein and popularised by [[James Martin (author)|James Martin]].

According to Hay (1999) "[[information engineering]] was a logical extension of the structured techniques that were developed during the 1970's1970s. Structured programming led to structured design, which in turn led to structured systems analysis. These techniques were characterized by their use of [[diagram]]s: structure charts for structured design, and data flow diagrams for structured analysis, both to aid in communication between users and developers, and to improve the analyst's and the designer's discipline. During the 1980's1980s, tools began to appear which both automated the drawing of the diagrams, and kept track of the things drawn in a [[data dictionary]]".<ref>David C. Hay (1999) [http://www.ihs.gov/Misc/links_gateway/download.cfm?doc_id=138&app_dir_id=4&doc_file=ieoo.pdf Achieving buzzword compliance in Object orientation] {{Webarchive|url=https://web.archive.org/web/20081020060208/http://www.ihs.gov/misc/links_gateway/download.cfm?doc_id=138&app_dir_id=4&doc_file=ieoo.pdf |date=2008-10-20 }} Essential Strategies, Inc.</ref> After the example of [[computer-aided design]] and [[computer-aided manufacturing]] (CAD/CAM), the use of these tools was named [[computer-aided software engineering]] (CASE).

== Structured analysis topics ==

Line 41 ⟶ 44:

Structured analysis typically creates a hierarchy employing a single abstraction mechanism. The structured analysis method can employ [[IDEF]] (see figure), is process driven, and starts with a purpose and a viewpoint. This method identifies the overall function and iteratively divides functions into smaller functions, preserving inputs, outputs, controls, and mechanisms necessary to optimize processes. Also known as a [[functional decomposition]] approach, it focuses on cohesion within functions and coupling between functions leading to structured data.<ref name="DoDAF V2"/>

The functional decomposition of the structured method describes the process without delineating system behavior and dictates system structure in the form of required functions. The method identifies inputs and outputs as related to the activities. One reason for the popularity of structured analysis is its intuitive ability to communicate high-level processes and concepts, whether in single system or enterprise levels. Discovering how objects might support functions for commercially prevalent [[Object-oriented programming|object-oriented]] development is unclear. In contrast to IDEF, the [[Unified Modeling Language|UML]] is interface driven with multiple abstraction mechanisms useful in describing [[service-orientation|service-oriented]] architectures (SOAs).<ref name="DoDAF V2"/>

=== Approach ===

Structured Analysisanalysis views a system from the perspective of the data flowing through it. The function of the system is described by processes that transform the data flows. Structured analysis takes advantage of information hiding through successive decomposition (or top down) analysis. This allows attention to be focused on pertinent details and avoids confusion from looking at irrelevant details. As the level of detail increases, the breadth of information is reduced. The result of structured analysis is a set of related graphical diagrams, process descriptions, and data definitions. They describe the transformations that need to take place and the data required to meet a system's [[functional requirement]]s.<ref name="HeSi86">

Alan Hecht and Andy Simmons (1986) [httphttps://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19890006956_1989006956.pdf Integrating Automated Structured Analysis and Design with Ada Programming Support Environments] NASA 1986.</ref>

[[Image:Analysis Model Objects.jpg|thumb|320px|The structured analyse approach develops perspectives on both process objects and data objects.<ref name="HeSi86"/>]]

De Marco's approach<ref>[[Tom DeMarco]] (1978). ''Structured Analysis and System Specification''. Yourdon Press, New York, 1978.</ref> consists of the following objects (see figure):<ref name="HeSi86"/>

* [[Context diagram]]

* [[Dataflow diagram|Data flow diagram]]

* Process specifications

* [[Data dictionary]]

Line 56 ⟶ 59:

=== Context diagram ===

{{Main|Context diagram}}

[[Image:NDE Context Diagram (vector).svg|thumb|320px|Example of a system context diagram.<ref>[http://projects.osd.noaa.gov/NDE/proj_context_diagram.htm NDE Project Management] {{Webarchive|url=https://web.archive.org/web/20081107193850/http://projects.osd.noaa.gov/NDE/proj_context_diagram.htm |date=2008-11-07 }} (NPOESS) Data Exploitation web site. 2008.</ref>]]

[[System Context Diagram|Context diagrams]] are diagrams that represent the actors outside a system that could interact with that system.<ref name="KoSw03"/> This diagram is the highest level view of a [[system]], similar to [[block diagram]], showing a, possibly [[software system|software]]-based, system as a whole and its inputs and outputs from/to external factors.

Line 62 ⟶ 66:

=== Data dictionary ===

{{Main|Data dictionary}}

[[Image:Entity Relationship Diagram.jpg|thumb|320px|left| [[Entity relationship diagram]], essential for the design of database tables, extracts, and metadata.<ref name="USDT01"/>]]

A [[data dictionary]] or ''database dictionary'' is a file that defines the basic organization of a [[database]].<ref name="USDT01">[http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All+Documents/4825476B2B5C687285256B1F00544258/$FILE/DIGloss.pdf Data Integration Glossary] {{Webarchive|url=https://web.archive.org/web/20120218233448/http://knowledge.fhwa.dot.gov/tam/aashto.nsf/All%20Documents/4825476B2B5C687285256B1F00544258/%24FILE/DIGloss.pdf |date=2012-02-18 }}, U.S. Department of Transportation, August 2001.</ref> A database dictionary contains a list of all files in the database, the number of records in each file, and the names and types of each data field. Most [[database management system]]s keep the data dictionary hidden from users to prevent them from accidentally destroying its contents. Data dictionaries do not contain any actual data from the database, only bookkeeping information for managing it. Without a data dictionary, however, a database management system cannot access data from the database.<ref name="USDT01"/>

Database users and [[Application software|application]] developers can benefit from an authoritative data dictionary document that catalogs the organization, contents, and conventions of one or more databases.<ref>TechTarget, ''SearchSOA'', [http://searchsoa.techtarget.com/sDefinition/0,,sid26_gci211896,00.html What is a data dictionary?]</ref> This typically includes the names and descriptions of various [[Table (database)|tables]] and [[Column (database)|fields]] in each database, plus additional details, like the [[Data type|type]] and length of each [[data element]]. There is no universal standard as to the level of detail in such a document, but it is primarily a distillation of [[metadata]] about [[Database design|database structure]], not the data itself. A data dictionary document also may include further information describing how data elements are encoded. One of the advantages of well-designed data dictionary documentation is that it helps to establish consistency throughout a complex database, or across a large collection of [[federated database]]s.<ref>AHIMA Practice Brief, [http://library.ahima.org/xpedio/groups/public/documents/ahima/bok1_030582.hcsp?dDocName=bok1_030582 Guidelines for Developing a Data Dictionary], ''Journal of AHIMA'' 77, no.2 (February 2006): 64A-D.</ref>

=== Data flow diagrams ===

{{Main|Data flow diagram}}

[[Image:Data Flow Diagram Example.jpg|thumb|330px|Data flow diagram example.<ref>John Azzolini (2000). [http://ses.gsfc.nasa.gov/ses_data_2000/000712_Azzolini.ppt Introduction to Systems Engineering Practices]. July 2000.</ref>]]

A [[data flow diagram]] (DFD) is a graphical representation of the "flow" of data through an [[information system]]. It differs from the system [[flowchart]] as it shows the flow of data through processes instead of [[computer hardware]]. Data flow diagrams were invented by [[Larry Constantine]], developer of [[structured design]], based on Martin and Estrin's "data flow graph" model of computation.<ref>W. Stevens, G. Myers, L. Constantine, "Structured Design", IBM Systems Journal, 13 (2), 115-139, 1974.</ref>

Line 76 ⟶ 82:

=== Structure chart ===

{{Main|Structure chart}}

[[Image:Configuration System Structure Chart.jpg|thumb|320px|A configuration system structure chart.<ref name="IRT"/>]]

A [[structure chart]] (SC) is a chart that shows the breakdown of the [[configuration system]] to the lowest manageable levels.<ref name="IRT">[httphttps://www.irs.gov/irm/part2/ch17s01.html "Configuration Management"] In: ''IRS Resources Part 2. Information Technology Chapter 27. Configuration Management''. Accessed 14 Nov 2008.</ref> This chart is used in [[structured programming]] to arrange the program modules in a tree structure. Each module is represented by a box which contains the name of the modules. The tree structure visualizes the relationships between the modules.<ref>[[James Martin (author)|James Martin]], Carma L. McClure (1988). ''Structured Techniques: The Basis for Case''. Prentice Hall. p.56.</ref>

Structure charts are used in structured analysis to specify the high-level design, or architecture, of a [[computer program]]. As a design tool, they aid the programmer in dividing and conquering a large software problem, that is, recursively breaking a problem down into parts that are small enough to be understood by a human brain. The process is called [[top-down design]], or [[functional decomposition]]. Programmers use a structure chart to build a program in a manner similar to how an architect uses a blueprint to build a house. In the design stage, the chart is drawn and used as a way for the client and the various software designers to communicate. During the actual building of the program (implementation), the chart is continually referred to as the master-plan.<ref name= "Wol">David Wolber "[http://www.usfca.edu/~wolberd/cs112/SupplementalNotes/structureChart.doc Structure Charts] {{Webarchive|url=https://web.archive.org/web/20090219083522/http://www.usfca.edu/~wolberd/cs112/SupplementalNotes/structureChart.doc |date=2009-02-19 }}: Supplementary Notes Structure Charts and Bottom-up Implementation: Java Version.</ref>

=== Structured design ===

Line 91 ⟶ 98:

* data dictionary.

The [[structure chart]] aims to show "the module hierarchy or calling sequence relationship of modules. There is a module specification for each module shown on the structure chart. The module specifications can be composed of pseudo-code or a program design language. The [[data dictionary]] is like that of structured analysis. At this stage in the [[software development lifecycle]], after analysis and design have been performed, it is possible to automatically generate data type declarations",<ref>Belkhouche, B., and J.E. Urban. (1986). "Direct Implementation of Abstract Data Types from Abstract Specifications". In: ''IEEE Transactions on Software Engineering'' pp. 549-661, May 1986.</ref> and procedure or subroutine templates.<ref name="HeSi86" />

=== Structured query language ===

The [[structured query language]] (SQL) is a standardized language for querying information from a [[database]]. SQL was first introduced as a commercial database system in 1979 and has since been the favorite query language for database management systems running on minicomputers and mainframes. Increasingly, however, SQL is being supported by PC database systems because it supports distributed databases (see definition of distributed database). This enables several users on a computer network to access the same database simultaneously. Although there are different dialects of SQL, it is nevertheless the closest thing to a standard query language that currently exists.<ref name="USDT01"/>

== Criticisms ==

Line 117 ⟶ 121:

== Further reading ==

* {{Cite journal| doi = 10.1147/sj.132.0115| title = Structured design| journal = IBM Systems Journal| volume = 13| issue = 2| pages = 115–139| date=June 1974 | last1 = Stevens | first1 = W. P.| authorlink1author-link1 = Wayne Stevens (software engineer)| last2 = Myers | first2 = G. J.| authorlink2author-link2 = Glenford Myers| last3 = Constantine | first3 = L. L.| authorlink3author-link3 = Larry Constantine| ref = harv}}

* {{Cite book | isbn = 0-13-854471-9 | title = Structured Design: Fundamentals of a Discipline of Computer Program and Systems Design | last1 = Yourdon | first1 = Edward | authorlink1author-link1 = Edward Yourdon | last2 = Constantine | first2 = Larry L. | authorlink2author-link2 = Larry Constantine | year = 1979 | origyearorig-year = 1975 | publisher = Yourdon Press | pages = }}

* [[Tom DeMarco]] (19791978). ''Structured Analysis and System Specification''. Prentice HallYourdon. {{ISBN |0-1391-854380707207-13}}

* {{citation|last=Page-Jones|first=M |year=1980|title=The Practical Guide to Structured Systems Design|publisher=Yourdon Press|___location=New York|ref=harv}}

* Derek J. Hatley, Imtiaz A. Pirbhai (1988). ''Strategies for Real Time System Specification''. John Wiley and Sons Ltd. {{ISBN |0-932633-04-8}}

* [[Stephen J. Mellor]] und Paul T. Ward (1986). ''Structured Development for Real-Time Systems: Implementation Modeling Techniques: 003''. Prentice Hall. {{ISBN |0-13-854803-X}}

* [[Edward Yourdon]] (1989). ''Modern Structured Analysis'', Yourdon Press Computing Series, 1989, {{ISBN |0-13-598624-9}}

* Keith Edwards (1993). ''Real-Time Structured Methods, System Analysis''. Wiley. {{ISBN |0-471-93415-1}}

==External links==

{{Commons category|Structured analysis}}

* [https://web.archive.org/web/20070203213944/http://www.yourdon.com/strucanalysis/wiki/index.php?title=Introduction Structured Analysis Wiki]

* [http://www.cragsystems.co.uk/ITMUML/fun01/04fun01.htm Three views of structured analysis] CRaG Systems, 2004.

Line 135 ⟶ 139:

{{DEFAULTSORT:Structured Analysis}}

[[Category:Software design]]

[[Category:Edsger W. Dijkstra]]