Help with the design of the system analysis

6 Part 8: Appendix

6.1 Method references

6.1.13 System analysis

Sense and purpose

The aim of the system analysis is the identification, modeling and evaluation of systems. The following methods can be used:

Object Oriented Analysis (OOA)

The OOA can be carried out with the resources of the UML method family:

1. Use case modeling

The aim of the method is to record and display the functional requirements placed on a system from the point of view of external operating units ("actuators"). The requirements are to be described in the form of use cases. A use case can be concretized in a number of scenarios. External operating units (e.g. employees, project managers or administrators) represent roles that can be assumed by specific people, machines, computer "tasks" or other systems.

2. Class / object modeling

The method is used for object-oriented system development. This requires the modeling of classes, associated attributes and operations as well as the relationships between the classes. It is the task of class modeling to define the static class structure in class models. A class is static in relation to the execution of a system and defines the structure and behavior of similar objects. Objects are to be modeled as instances of classes.

Class / object modeling can be used in object-oriented development both during the analysis and during the design phase. During the analysis, the class structure or the object structures must be modeled from the user's point of view in order to express what a system is doing. These structures have to be refined in the design and how the system does something has to be determined.

In class modeling, attributes are to be used to model identifying, descriptive or referencing information in a class. The development results can be refined through additional modeling options, such as the definition of visibilities, the assignment of role names, the assignment of restrictions (“constraints”), the description of derived attributes and the use of higher-order relationships.

The concepts of class modeling can also be used to define the static aspects of interfaces of classes and subsystems and their application. The parts of classes (attributes, operations) or subsystems (classes, relationships) that are to be defined as interfaces can be identified again in their own interface models.

3. Interaction modeling

The method is used for object-oriented system development. The aim is to describe interactions between objects and their order in interaction models. The occurrence of events or the exchange of messages can be expressed through interactions. The method can be used to formalize scenarios (consequences of events and the associated system behavior) and to model the dynamic sequence of operations. With time line diagrams (“Sequence Diagrams”) the aim is to focus on modeling and visualizing the sequence-oriented order of the interactions between the objects. In order to model the interaction relationships in more detail and to emphasize the software structure, interaction graphs ("collaboration diagrams") are predominantly used. The time required for communication is not directly considered in interaction modeling, but time restrictions can be modeled. Concurrency can be mapped. By modeling signatures, synchronous and asynchronous processes, time, process and synchronization conditions, branches, iterations, recursions as well as the creation and deletion of objects, development results can be refined.

4. Activity diagrams

Activity diagrams can be used to specify the use cases by creating activity diagrams in use cases. This means that dependencies, concurrent processes, decision-making / branching points can be displayed. Furthermore, activity diagrams can be used as a special type of state diagram that only shows activities and transitions between them. An activity is assigned to a state and represents an ongoing internal action.

5. State modeling

The objective of state modeling in the object-oriented area 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-driven classes. Such classes generally specify "active" objects.

The behavior of objects of a class is to be abstracted as a life cycle and is modeled in a state model. The state model should define all states that an object can assume, the possible state transitions, the events that can cause state transitions, the conditions that must be met in addition to the events for a state change, and the actions that are to be carried out as a result of state transitions .

The states are used to define data values ​​that the attributes of an object of a class can assume and possible links with other objects. The state transition that occurs for an object of a class in a specific situation is clearly determined by the state in which the object is currently located, the event that has occurred and specified conditions.

A path in a state model represents a sequence of events. Scenarios that are often used during the analysis to formulate the desired sequence of events must be mappable on the paths of the specified state models.

Structured Analysis (SA)

The structured analysis consists of a combination of methods:

1. Data flow modeling

The aim of "data flow modeling" is to specify the functional structure of a system through the combined consideration of functions and data. The data flows form the interfaces between the functions. The data flow modeling abstracts from the physical conditions of a planned system.

In a top-down approach, more and more detailed layers of the future system are specified. The starting point is an overview diagram (“context diagram”), which only shows the data flows of the system from and to its environment. When the data flow model is refined, the functions identified in the function hierarchy are refined by means of a data flow diagram of the corresponding level.

A data flow diagram of a certain hierarchy level can be represented as an interplay of processes that are connected via data flows. A refinement on the data side 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 that is stable and independent of design decisions and hardware conditions.

2. Function modeling

The aim of function modeling is to break down a system step by step, starting with the view of the main function of a system through the intermediate levels to the level of elementary functions. On one level, details of the level below are abstracted. The sub-functions taken together completely result in the broken down function (function hierarchy).

Formal specification

The formal specification is a specification based on strict rules. A distinction is made between two classes of formal specification: the abstract specification (implementation-neutral, black box view, algebraic specification) and the model-based specification, in which the state change of the system due to one or more operations is described (example is the Z specification) formal specification is a concise and precise representation with the possibility of converting it directly into code. A verification option for error detection and proof of the program's correctness based on the specification are desirable. The disadvantage of a formal specification is the difficult and time-consuming creation that only a few developers / project managers have mastered, the incomprehensibility for the customer (i.e. it cannot be used as a basis for communication) and the limitation to a few functional requirements (e.g. mathematical calculations). Since a purely formal specification hardly seems realizable, a mixture of formal and semi-informal or informal specification is the optimum. What can be formally specified should be described with it, the rest is dealt with using a different specification variant.