![]() |
![]() |
![]() |
![]() |
![]() |
System Analysis of the Access Control System
The system analysis is based on the results after analyzing the requirements and the problem domain on a high level. The models in the system analysis focuses more on the internal structure of the system to be built, without taking design decisions (or at least as few as possible).
Analysis Object Model: Basic Version
The inheritance concept is not used in the basic version because the information that needs to be modeled has a very simple structure. What can be seen in Figure 4 is the aggregation and the association relations between the classes and the attributes and operations for the individual classes.
Compared to the requirements object model, the following changes have been made:
- The actors are removed from the object model to simplify the reading.
- Classes have been structured in a way that makes the mapping to an SDL design easier. Especially the aggregation hierarchy is designed with this in mind; the structure will basically be kept when making an SDL design.
- Classes from the requirements object model that are redundant (only introduced to increase the understanding of the problem) are removed.
- A difference between active and passive objects has been taken into account. The active objects have behavior while the passive objects only have data structure and data manipulation. The classes in the aggregation hierarchy are all active, while the classes in the information structure are passive.
- Attributes and operations have been added to the classes.
- The analysis object model is structured into three parts, each part showing a different view of the relationship between the classes: containment, communication and information.
The Analysis Use Case Model
The following MSC describes the use case for opening a door and is a part of the complete analysis use case model. The level of granularity can either be very detailed (each involved leaf object is represented by an MSC instance) or general (each subsystem of the aggregation hierarchy is described by an instance). This choice between readability and expressiveness is dependent of the application area and design customs. In this case, the subsystem representation was chosen (see Figure 2).
Note that the MSC instances are, in fact, instances, i.e. they represent objects. To indicate this, the naming of the instances include both an object name and the correspondent class name.
It should also be noticed that all MSC messages do not map strictly to class operations. In some cases, the operation is synchronous, that is demands a return message. This return message is also described in the MSC use case in Figure 2 (e.g. the operation ValidateCard is described by the messages ValidateCard and OK).
Analysis Object Model: Enhanced Version
The following example is how an analysis of the additional requirement of time handling can be performed. The addition of a clock function will mainly add a new operation to the class Display (display of current time). A new class Clock must also be introduced. The properties of this class handle the clock and update the current time. Figure 6 describes the enhanced analysis object model for the Access Control system.
When adding behavior, the other models must of course also be extended, including the internal textual requirements and the use case models of the requirements and system analysis.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |