Structured analysis: Difference between revisions

Revision as of 20:43, 11 August 2016

Revision as of 01:09, 7 September 2016

Line 6:

== Objectives of structured analysis ==

Structured analysis became popular in the 1980s and is still used by many. {{Citation needed|date=March 2016}} The 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 very hard to track and the number of bubbles can get to be extremely large. One approach is to firstfirstly define events from the outside world that require the system to react, then assign a bubble to that event,. bubblesBubbles 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 were accompanied by notation methods including [[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.

Line 40:

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]] 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 ===

Line 52:

* [[Data dictionary]]

Hereby the [[data flow diagram]]s (DFDs) are directed graphs. The arcs represent [[data]], and the nodes (circles or bubbles) represent processes that transform the data. A process can be further decomposed to a more detailed DFD which shows the subprocesses and data flows within it. The subprocesses can in turn be decomposed further with another set of DFDs until their functions can be easily understood. Functional primitives are processes which do not need to be decomposed further. Functional primitives are described by a process specification (or mini-spec). The process specification can consist of pseudo-code, [[flowchart]]s, or structured English. The DFDs model the structure of the system as a network of interconnected processes composed of functional primitives. The [[data dictionary]] is a set of entries (definitions) of data flows, data elements, files., and data basesdatabases. The data dictionary entries are partitioned in a top-down manner. They can be referenced in other data dictionary entries and in data flow diagrams.<ref name="HeSi86"/>

=== Context diagram ===

Line 89:

* module specifications

* 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 ===