|2.8 The Complex Method SSADM|
SSADM - Structured Systems Analysis and Design Method
The application of SSADM aims at the development of information systems on the basis of database systems and less at the development of real-time-oriented software. Therefore, the method concentrates on data flows, data models, and-as a specialty-the chronological life cycles of entities.
Contrary to the strict separation of procedure and method in the software development standard of the German Federal Armed Forces, a lifecycle process model has been integrated into the method in SSADM.
The lifecycle process model of SSADM supplies both detailed procedures and instructions for analysis and design in connection with software generation (SD1 - System Requirements Analysis to SD5 SW - Detailed SW Design) in the following areas:
However, all implementation and integration activities have been excluded on purpose. In the same way are the accompanying activities of submodels PM, CM, and QA not subject of SSADM but distributed to special methods (e. g. PRINCE, CRAMM).
The following comparison refers to the methodical components of SSADM in the sense of the GD 251. In SSADM, they are referred to as Techniques. These techniques include:
Contains a general instruction with regard to the definition of requirements.
The "Dialog Design" consists of two steps. In a first step ("dialog identification") the dialogs of the application to be modeled are identified from the point of view of the later user. The "dialog design" is realized at some later date at which menu structures and dialog sequences are developed from the input/output of the application functions.
The data flow modeling is used to describe how the DFD processes of the application are communicating with each other and with the environment. The data flow diagrams in SSADM are predominantly used for the documentation and less for the support of an information system design.
The technique "Logical data modeling" is based on E/R models. The E/R model represents the entities relevant for an application, together with the corresponding relationships. For the functions identified during the analysis the access path to the E/R model is recorded.
Business system options are text descriptions of the information system to be realized. Therefore, they can be considered as a product as well. The required selection for the later implementation must be made from the business system options.
In SSADM, functions are the interface between analysis and design. During the analysis phase, identified and logically interacting DFD processes are grouped into functions by taking into consideration the application requirements.
Within the scope of the relational data analysis, the entities of the data model are transformed into relations, key attributes are defined, and the normalization is realized.
In SSADM, prototyping is predominantly used for assessing the requirements with regard to accuracy and consistency and less for an evolutionary application development. The future user is to have the opportunity to make individual comments about the user interface or the planned functionality as early as possible.
Entity Event Modeling is the interface between the data side (E/R model) and the functions based on DFD processes. It checks which externally initiated events refer to the application to be realized, how it must react with regard to the functions, and which entities are affected by the processing of the event.
The character of technical system options corresponds to those of the business system options. The topics are technical aspects of the application to be realized, though.
A logical database process design specifies the internal structure of the processes accessing the database. In this connection, the data analysis (access paths in the E/R model) and the entity event modeling (Entity Life Histories) are used as a basis.
The logical data model available in a normalized relational form is converted into a physical design.
Within the scope of the physical process specification, software modules are specified that are used to realize the identified functions. The module structure has to be as detailed as a programming specification.
Comparison of the Basic Methods and the
Methodological Components of SSADM
|AUD - Audit|
|ACC - Analysis of Covert Channels|
|BAR - Bar Plan|
|TREE - Tree Diagram|
|BBTD - Black Box Test Case Design|
|CRC - Class Responsibility Collaboration|
|DIAL - Dialog Design Modeling||
/Downs, 1992/ chap. 3.4
|DFM - Data Flow Modeling||
Data Flow Modeling|
/Downs, 1992/ chap. 3.5
|DNAV - Data Navigation Modeling||
Logical Data Modeling|
/Downs, 1992/ chap. 3.6
|DVER - Design Verification|
|ELH - Entity Life History||
Entity Event Modeling|
/Downs, 1992/ chap. 3.11
|ER - E/R Modeling||
Logical Data Modeling|
/Downs, 1992/ chap. 3.6 (*)
|DTAB - Decision Table Technique|
|EVT - Earned Value Method|
|EXPM - Expertise Model|
|FCTD - Functional Decomposition||
Data Flow Modeling|
/Downs, 1992/ chap. 3.5
|FMEA - Failure Mode Effect Analysis|
|FNET - Function Net Modeling|
|FS - Formal Specification|
|IAM - Interaction Modeling|
|CFM - Control Flow Modeling|
|COM - Class/Object Modeling|
|LOGM - Logical DB Modeling||
Relational Data Analysis|
/Downs, 1992/ chap. 3.9
|MODIAG - Module Diagrams|
|NORM - Normalization||
Relational Data Analysis|
/Downs, 1992/ chap. 3.9 (*)
|NPT - Network Planning Technique|
|BA - Benefit Analysis|
|ODT - Object Design Technique|
|OGC - Organizational Chart|
|PCODE - Pseudocode||
Logical Database Process Design|
/Downs, 1992/ chap. 3.13
|PRODIAG - Process Diagrams|
|PVER - Program Verification|
|PIM - Process Interaction Modeling|
|REV - Review|
|SIMU - Simulation Models|
|EMOD - Estimation Models|
|SSM - Subsystem Modeling|
|STAT - Static Analysis|
|STRD - Structured Design||Entity Event Modeling Logical Database Process Design /Downs, 1992/ chapters 3.11 and 3.13|
|SBM - System Behavior Models|
|T - Test|
|TRDA - Trend Analysis|
|UCM - Use Case Modeling|
|WBTD - White Box Test Case Design|
|STM - State Transition Modeling|
|STMO - State Modeling in the OO Field|
|RELM - Reliability Models|
Dialog Design Modeling
|/Downs, 1992/ chap. 3.4 "Dialog design", p. 96||
The method Dialog Design has two "subtechniques":
Data Flow Modeling
|/Downs, 1992/ chap. 3.5 "Data flow modeling", p. 103||The data flow modeling in SSADM covers the basic method DFM completely. In addition to the graphical means of representation "process", "terminator", "data flow", and "data store" required in DFM, so-called physical flows exist in SSADM to describe the material flow between users (terminators) and the system to be modeled (processes). They are used for the user-level description and are only applied on the highest level in data flow diagrams.|
Data Navigation Modeling
|/Downs, 1992/ chap. 3.6 "Logical data modeling", "Enquiry access paths", p. 136||Based on the E/R diagram and the identified functions of the information system, the name of the query is defined for all database queries to be realized, the initiating event and the data affected by the query (key, selection criteria), and the path through the data model at the time of the query execution are described.|
Entity Life History
|/Downs, 1992/ chap. 3.11 "Entity event modeling", "Entity Life History", p. 170||All of the possible operational sequences are graphically described for each entity type during the life cycle of that entity. Means of representation are Structure Charts. ELHs are used to check the completeness of the functional description, to describe interdependencies between functions, and to derive test cases.|
|/Downs, 1992/ chap. 3.5 "Data flow modeling", p. 103||The functional decomposition is implicitly contained in technique "Data Flow Modeling". The processes identified during the analysis of the data flows are hierarchically refined on lower levels. The processes generated during the data flow modeling can be arranged into a tree structure.|
Logical DB Modeling
|/Downs, 1992/ chap. 3.9 "Relational data analysis", p. 149||Technique "relational data analysis" completely covers the basic method LOGM for the area of relational database systems. The result of the E/R model conversion are tables describing the keys and attributes of the entities. Relationships between entities are (after prior normalization) realized by means of external keys.|
|/Downs, 1992/ chap. 3.13 "Logical database process design", p. 198||
The logical database process design is used to describe processes that are accessing a database. Processes receiving or sending data via the user interface or those mapping technical aspects are not described.|
The result of this description is a Process Structure Diagram which is upgraded by operations and control structures.
|/Downs, 1992/ chap. 3.11 "Entity event modeling" p. 170; chap. 3.13 "Logical database process design", p. 198||The Structure Charts from STRD are applied at various places in SSADM. On the one hand, Entity Life Histories are illustrated with the help of Structure Charts, on the other hand they are utilized in connection with the description of the structure of processes.|
|GDPA Online Last Updated 01.Jan.2002 Updated by Webmaster Last Revised 01.Jan.2002 Revised by Webmaster|