8 Part 8: Annex
8.1 Method References
8.1.16 System Analysis
Usage
Preparing External Hardware Module Specification, Preparing Hardware Specification, Preparing Logistic Support Specification, Preparing External Software Module Specification, Preparing Software Specification, Preparing External Unit Specification, Preparing Overall System Specification, Preparing System Specification
Reference
Purpose
The objective of the system analysis is the identification, modeling and evaluation of systems. The following methods may be used:
Object-oriented Analysis (OOA)
For the OOA, resources of the UML method family may be used:
1. Use Case Modeling
The objective of this method is to identify and describe the functional requirements for a system made from the point of view of external operating units ("actors"). The requirements have to be described in the form of use cases. A use case may be put into more concrete terms in a number of scenarios. External operating units (for example staff, the »Project Leader or the administrator) represent »Roles that may be played by actual persons, machines, computer tasks or other systems.
2. Class/Object Modeling
This method is used for object-oriented system development, which requires the modeling of classes, associated attributes and operations and the relations between the classes. It is the task of class modeling to determine the static class structure in class models. With regard to the design of a system, a class is statical and defines the structure and behavior of similar objects. Objects have to be modeled as instances of classes.
In object-oriented development, class/object modeling may be used both in the analysis and in the design phase. In the analysis phase, the class structures and the object structures have to be modeled from the point of view of the user in order to express what a system does. In the design, these structures have to be refined, and it has to be determined how things are done by the system.
In class modeling, attributes have to be used to model identifying, descriptive and referencing information in a class. The development results may be refined using additional modeling options, such as for example determining the visibility, allocating role names, assigning constraints, describing derived attributes and using higher order relations.
Class modeling concepts may also be used to define the statical aspects of interfaces of classes and subsystems and their application. Those parts of classes (attributes, operations) or subsystems (classes, relations) that are defined as interfaces may be marked once again in separate interface models.
3. Interaction Modeling
This method is used for object-oriented system development. The objective is to use interaction models to describe interactions between objects and their order. Interactions may be used to express the occurrence of events or the exchange of messages. The method may be used for formalizing scenarios (succession of events and the related system behavior) and for modeling the dynamic sequence of operations. In this process sequence diagrams are used to concentrate on modeling and visualizing the sequence-oriented order of the interactions between objects. For a more detailed modeling of the relations of the interactions and in order to place emphasis on the software structure, mainly interaction graphs ("collaboration diagrams") are used. During the modeling of the interactions, the time required for communication is not directly considered; it is possible, however, to model time limits. Concurrencies can be modeled. Development results may be refined by modeling signatures, synchronous and asynchronous sequences, time, sequence and synchronization conditions, branchings, iterations and recursions and by generating and deleting objects.
4. Activtiy Diagrams
Activity diagrams may be used as a concretization of the use cases by applying activity diagrams to use cases, thus describing dependencies, concurrent processes and decision/branching points. Activity diagrams also may be used as a special kind of state diagram, which shows exclusively activities and transitions between those activities. An activity is assigned to a state and represents a continuing internal action.
5. State Modeling
The objective of state modeling in the field of object-oriented system development is to model the dynamic behavior of a system. The most important area of application is the modeling of the dynamic behavior of objects of significant, event-controlled classes. Such classes usually specify "active" objects.
The behavior of the objects of a class has to be abstracted as a life cylcle and is modeled in a state model. The state model is to define all states that an object may take on, the possible state transitions, the events that may effect state transitions, the conditions that have to be fulfilled in addition to the events so that a state transition can occur, and the actions that have to be taken because of state transitions.
The states are used to determine data values that may assumed by the attributes of an object of a class and possible connections with other objects. The state transition that occurs for an object of a class in a concrete situation is unambiguously defined by the current state of the object, the event that occurred and specified conditions.
In a state model, a path represents a sequence of events. It must be possible to model scenarios that are frequently used during the analysis to formulate desired sequences of events on the paths of the specified state models.
Struktured Analysis (SA)
The structured analysis consists of the combination of the following methods:
1. Data Flow Modeling
The objective of "data flow modeling" is to specify the functional structure of a system by the combined examination of functions and data. In this process the data flows form the interfaces between the functions. Data flow modeling abstracts from the physical conditions of a planned system.
In a top-down approach, more and more detailed levels of the future systems will be specified. The starting point is a layout diagram ("context diagram") that shows only the system's data flows from and to its environment. When refining the data flow model, the functions identified in the functional hierarchy are refined with the help of a data flow diagram of the corresponding level.
A data flow diagram of a specific hierarchical level may be described as an interplay between processes that are connected via data flows. A refinement of the data is always carried out in coordination with the corresponding refinement of the functional hierarchy. When modeling the data flows, it is important to find a logical internal structure of the planned system, which is stable and independent of design decisions and hardware factors.
2. Functional Modeling
The objective of functional modeling is to break down a system step-by-step, starting with the view on the main functions of the system over the intermediate levels down to the elementary function level. At each level abstraction from details of the next lower level is performed. Together the subfunctions yield completely the function that was broken down (functional hierarchy).
Formal Specification
The formal specification is a specification that follows strict rules. A distinction is made between two classes of formal specifications: the abstract specification (which is neutral with regard to the implementation, reflects a black box view and is an algebraic specification) and the model-based specification, in which the change of the state of the system is described on the basis of one or more operations (an example of this is the Z specification). The objective of a formal specification is a short and accurate description with the possibility to translate it directly into code. It is desirable to be able to verify the system so that faults can be detected and to have a proof for the correctness of the program on the basis of the specification. The disadvantage of a formal specification is its difficult and costly preparation, which is mastered only by a few developers or project leaders, and the fact that it is impossible to understand for the acquirer (i. e. it cannot be used as a basis for communication) and that it is limited to some functional requirements (e. g. mathematical calculations). Sine it seems to be hardly possible to realize a purely formal specification, a mixture of formal and semi-formal or informal specification is the optimum solution. It should be used for everything that can be formally specified. The remainder will be handled with a different specification variant.