IBM
Contents Index Previous Next



Performing the System Analysis


Figure 734 : Overview of the SOMT process

What You Will Learn

Introduction to the Exercise

In this exercise you will perform the system analysis activity. The purpose of the exercise is to outline a logical model of the Access Control system. This model will fulfil the requirements that were identified in the requirements analysis. In other words, the purpose of this activity is to identify the objects that are needed in the Access Control system and the services these objects should provide.

Producing a complete system analysis structure takes too much time. Thus, you will only perform parts of every step necessary to produce the complete structure.

The input to the system analysis activity is a complete requirements structure with the two main models:

The output from the system analysis activity are the two models:

These two models should be created in parallel through a number of iterations.

Preparing the Exercise

  1. Open the system file somttutorial/SysA/accesscontrol.sdt (on UNIX), or somttutorial\sysa\accesscontrol.sdt (in Windows).
  2. Check that the Source directory is set to somttutorial/SysA/ (on UNIX), or somttutorial\sysa\ (in Windows).

What you see in the Organizer window is a complete requirements analysis structure with all implinks made.

Creating the Analysis Object Model

The analysis object model is a refinement of the requirements object model. However, when transferring from the requirements analysis to the system analysis you change the focus.

During the requirements analysis the focus is on understanding the problem and the problem domain. In the system analysis the focus is to model a solution and to understand the logical structure of the system that will be the solution to the stated problem. This change of focus should be reflected by the analysis object model.

Little emphasis should be put on implementation aspects during the system analysis activity. Questions regarding the implementation of the solution will very likely hide our actual problem.

A glance at the headlines may give you the impression that the activity of creating the analysis object model is a sequential activity, but it is not. You will probably not first add all the necessary classes, then the relations, and finally specify the attributes and operations. This is, however, the way the text is structured here to make it readable and to highlight the important tasks of the activity.

Creating a Logical Architecture

Now it is time to create the logical architecture diagram.

  1. Select the AnalysisObjectModel module in the System Analysis Documents chapter in the Organizer.
  2. Add a new object model diagram and name it LogicalArchitecture.
  3. Open the LogicalStructure diagram from the previous activity as well as the new LogicalArchitecture diagram in the OM Editor.

Adding Classes to the Logical Architecture

Now you should start adding classes to the logical architecture diagram. For information on how to find the classes, see Finding Classes.

Several of the classes in the requirements object model can be transferred as-is to the analysis object model. The provided Paste As mechanism lets you transfer objects from one model to another while automatically creating implinks between the objects in the two separate models. This mechanism should be used here, see below.

  1. Select the class CentralControl in the LogicalStructure diagram and choose Copy in the Edit menu.
  2. Go to the LogicalArchitecture diagram by selecting it in the Diagrams menu.
  3. Choose Paste As in the Edit menu. The Paste As dialog is opened.
  4. Set the option menu to Class and see to it that the Create link toggle button is set. Press the Paste As button.
  5. Select where in the LogicalArchitecture diagram you want to place the CentralControl object.

Now you have created a class named CentralControl in your LogicalArchitecture diagram. The class is connected with an implink to the CentralControl class in the LogicalStructure diagram. The link is indicated by the filled triangle on the class symbol.

  1. Repeat the procedure above with the class Entrance but name the new class EntranceUnit as this is a more descriptive name.
  2. The classes Cardreader, Keypad, Display and ExitButton are obvious interfaces to our system and, also, parts of an EntranceUnit. Repeat the procedure above with these classes. As it is often useful to name objects according to their function, give the new classes names of the form xxxInterface.

One class in the requirements object model may result in several classes in the analysis object model. One reason may be that the class provides so much functionality that splitting the class into several smaller may be convenient. Another reason may be that a class identified in the requirements object model needs services from other, not yet introduced classes. Consequently these classes should be introduced at this point of the development process.

In practice, the actions in the two cases above are the same. The newly introduced classes should be linked to the original class in the requirements object model. In our example this is the case with the class Door. In the requirements object model we have one single class representing the door. Further analysis, however, shows that the door object includes both a door lock as well as a door sensor. This aggregation structure should be shown in the analysis object model. See section Finding Relations.

  1. Copy the class Door in the LogicalStructure diagram.
  2. Paste it three times as a class in the LogicalArchitecture diagram and see to it that the implinks are created at the same time. Name the new classes DoorUnit, DoorLockInterface and DoorSensorInterface respectively.

Now look at the classes you have so far in the LogicalArchitecture diagram. Think about the tasks of the different objects. As you can see there is no class that can handle the logic, that is, an object that is responsible for what happens at an entrance. Therefore, you should add such an object and name it EntranceCtrl, see below. The EntranceCtrl will be a part of the EntranceUnit.

  1. Copy the class Entrance from the LogicalStructure diagram.
  2. Paste it as a class in the LogicalArchitecture and rename the class, giving it the name EntranceCtrl.
  3. Also, copy and paste the SecurityLevel class and its subclasses.

Classes in the requirements object model that only exist outside the system border or classes that do not provide any necessary services should not be transferred at all to the analysis object model.

Finding Classes

Useful sources where you can find objects that may be included in the analysis object model are:

When you intend to transfer objects from the requirements object model to the analysis object model, consider the following to validate each requirements object:

Another useful way to find the objects is to examine which interfaces the system needs. Often the application area itself makes it obvious what interfaces must exist. To find the interface objects, go through the list of actors and, for each actor, decide which interfaces that are needed to the system.

The use cases from the system analysis activity are also a useful source for finding the objects. The problem is that we have not created these use cases yet. As stated before, the work done in each activity is often done iteratively. This is a typical situation where an iteration is needed as some objects in the analysis object model may not be found until we have created and inspected the analysis use case model.

When you have created the MSCs you should examine them to check which interface objects that are involved and which internal objects that are modified. Also, check if there is a control object that might handle the logic of the use case or if there is a need to introduce such an object in the analysis object model.

Adding Relations to the Logical Architecture

When you have identified all classes it is time to add the relations. For information about how to add relations, see Finding Relations.

In our Access Control system example, most of the relations from the requirements object model can be preserved.

  1. Connect the CentralControl to the EntranceUnit with an association. Add multiplicity to the association. The CentralControl may be connected to several EntranceUnits but the Access Control system has only one CentralControl.
  2. Connect the EntranceUnit to the DoorUnit with an aggregation. One EntranceUnit consists of only one DoorUnit.
  3. The DoorUnit consists of a DoorLockInterface and a DoorSensorInterface. Add aggregations from the DoorUnit to the DoorLockInterface and to the DoorSensorInterface.
  4. Connect the rest of the classes you have added with necessary associations, aggregations and generalizations. Also consider if multiplicity is needed or not.
Finding Relations

Useful sources that may assist the process of finding relations are:

The process of finding new relations and verifying old ones are closely related to the process of creating the analysis use case model. It is mainly a question about which other objects the object needs to know about to be able to provide its services. Also generalizations and aggregational dependencies have to be considered, see Identifying the Relations.

Adding Attributes to the Logical Architecture

Now we have come to the point where it is time to add the attributes. For information on how to find the attributes, see Identifying Attributes.

There are not many classes in our LogicalArchitecture diagram that need any attributes. In fact there is only one, the class Display. This class must be able to display different text messages depending on the situation at hand. Therefore:

  1. Define Text to be an attribute of the class DisplayInterface.
Identifying Attributes

Attributes can be found in:

Attributes describe a property of an object and often correspond to nouns. For example, possible attributes of an object "Person" may be eye color, weight, shoe size, and so on. Attributes that may describe a vehicle are owner, color, current speed, current gear, and direction.

Adding Operations to the Logical Architecture

The last thing to add to the logical structure object model are the operations. For information on how to find the operations, see Identifying Operations.

Add the operations Open, Close, Lock and Unlock to the assembly class DoorUnit. This implies that you also must add the operations Open and Close to the class DoorSensorInterface and Unlock and Lock to the class DoorLockInterface.

  1. Select the class DoorUnit.
  2. Click on the operations section in the class.
  3. Add the operations Open, Close, Lock and Unlock.
  4. Repeat the procedure for the classes DoorLockInterface and DoorSensorInterface adding their respective operations.
  5. Continue to add the missing operations of the other classes in the diagram. When you are finished, your diagram should look something like in Figure 735.
  6. Save the diagram.

Figure 735 : The logical architecture

Identifying Operations

Sources that may support the identification of operations are:

By studying the responsibilities of each object is it possible to identify a set of operations that will provide the services assigned to the object.

Let one operation perform only one task. However, the class should not contain too many public operations. A large public interface of a class may indicate that the object is assigned too many responsibilities. Instead the object should probably be split and the responsibilities of the object should be distributed between several objects.

The easiest way to find the operations is probably to look at the MSC messages in the system analysis use cases. The messages can often be considered as operations in the analysis object model. A message received by an instance in an MSC corresponds to an operation on the corresponding class. Note that the operations on the classes representing subsystems define the interface of this subsystem and should often also exist as operations on some of the objects within the subsystem.

Creating an Information Diagram

Now it is time to create an information diagram. This diagram describes the concepts outside the system that the system must know of to fulfill its task. In our Access Control system example, Card and Code are two such concepts.

  1. Add a new object model diagram to the Organizer in the module AnalysisObjectModel. Name the diagram InformationDiagram.
  2. Open the LogicalStructure diagram from the previous activity and the new InformationDiagram in the OM Editor.
  3. Select and copy the classes Card and Code in the LogicalStructure diagram and paste them as classes in the InformationDiagram, while automatically creating the implinks.
  4. Consider if any or both of the classes should have any attributes.
  5. Associate the classes with each other.
  6. Save the diagram.

Your diagram should look like in Figure 736 when you are finished.

Figure 736 : The Information diagram

Creating the Analysis Use Case Model

The design of the two models in the system analysis activity, the object model and the use case model, is usually going on in parallel. The models view the Access Control system from two different perspectives, a dynamic perspective and a static perspective.

The analysis use case model shows the dynamic aspects and consists of a set of MSC diagrams. These diagrams may be categorized into two types:

Refined Requirements Use Case

A refined requirement use case is what it reads like. Each valid use case from the requirements use case model is transferred to the analysis use case model and redesigned and refined to the analysis object model.

The purpose of the refined use cases is to validate whether the analysis object model really implements the requirements. At the same time the analysis use case model is an important source of information for identifying operations on the classes in the object model.

In the analysis use case model, the use cases are documented preferably using MSCs. MSC diagrams are more formal and correspond better to the object model than textual use cases.

Each instance in the MSC diagram corresponds to an object or subsystem in the analysis object model. The level of abstraction you choose is a trade-off between detail and clarity.

An object which encapsulates interfaces and just transfers the calls to other objects without adding much functionality may be omitted, but objects providing crucial functionality should be part of the MSC.

Creating a Refined Requirements Use Case

Now you should create an analysis use case of the Enter_Office_With_Card_And_Code use case from the requirements analysis activity.

  1. Create a new MSC diagram in the AnalysisUseCaseModel module and name it Enter_Office_With_Card_And_Code_SysA.
  2. Open the requirements use case Enter_Office_With_Card_And_Code. The system analysis use case is based on the requirements use case and it is therefore useful to use the latter as a reference (using copy and paste).
  3. Create the MSC on subsystem level, that is, replace the original system instance with instances of EntranceUnit and CentralControl.
  4. Create endpoints of the three instances in the MSC diagram. (Select Create Endpoint from the Link submenu in the Tools menu.)
  5. For each message in the requirements use case decide which instances that exchange that particular message in the analysis use case. Also consider which additional messages you need to add. All message exchanges inside the system that we did not consider in the requirements use cases have to be added at this point. Also, make references to exceptions at the points where these can occur.
  6. Replace the four ReadDigit signals with an MSC reference symbol referring to the MSC ReadCode. ReadCode is a behavior pattern which you will create later, see Behavior Pattern Use Cases.
  7. Save the diagram.
  8. In the Organizer, create an endpoint out of the newly created MSC diagram. (This is done in the same way as in the editors.)
  9. Open the Link Manager and connect this endpoint to the Enter_Office_With_Card_And_Code MSC from the requirements use case model. Name the link Implementation Link.

The created MSC should look like in Figure 737.

Figure 737 : A system analysis MSC use case

The rest of the requirements use cases and their respective exceptions are refined in a similar way. This will not be done in this tutorial because that would take too much time.

Behavior Pattern Use Cases

A behavior pattern is a detailed use case that may be used to examine special communication patterns in detail. A behavior pattern is part of an ordinary use case and most often several use cases share a behavior pattern. A use case may include none or several behavior patterns.

Behavior patterns let refined requirements use cases be presented in a higher abstraction level, making these less complex and easier to understand. By focusing use cases on special parts of the system it is easier to understand and maintain the requirements on the involved objects.

Creating a Behavior Pattern

The refined use case that you just created was created on subsystem level. With the help of behavior patterns we can describe what really happens at a certain point in the use case, i.e. which objects that interact and the messages that they exchange. In our case, where we will create a behavior pattern for the task of reading a code, we have to replace the MSC instance EntranceUnit with the MSC instances KeypadInterface and EntranceCtrl.

  1. Create a new Organizer module in the System Analysis Documents chapter. Name it BehaviorPatterns.
  2. In the MSC Editor, create the behavior pattern ReadCode, see Figure 738.
  3. Save the diagram using the name Behavior_Pattern_ReadCode.
  4. In the Organizer, associate the behavior pattern MSC with the use case MSC which it really is a part of. That is, associate it with Enter_Office_With_Card_And_Code_SysA.

Figure 738 : A behavior pattern example

The System Analysis Documents chapter should now look like in Figure 739.

Figure 739 : The System Analysis Documents chapter

Requirements Traceability

One important aspect in this activity is the relation between the models created here and the models created in the requirements analysis activity. We want to be able to check:

The means to check the issues above is through consistency checks. There are two types of consistency checks:

We will start with a link check and then we will perform an entity match.

Link Check

The first thing to check is that all entities described in the logical structure in the requirements object model are either represented in the analysis object model or not really needed by the application.

  1. Open the Link Manager. A link check can be performed in both entity and endpoint view, so it does not matter which view you have in the window.
  2. Choose Consistency Check in the Tools menu to perform a link check.
  3. The Consistency Check dialog pops up asking you to select the documents representing the from group. Select the LogicalStructure object model and press Continue.
  4. Yet another Consistency Check dialog appears, now asking you to select the documents representing the to group. Select the AnalysisObjectModel module (this will also highlight the documents in the module) and press Check.
  5. The Link Manager will show the result of the link check. You can see that all entities from the requirements, except the system operator, employee, database, management system and office, are represented in the analysis object model. These are concepts on the outside of the system and, thus, not really needed by the application.

To follow links from one model to another we use the Traverse command. To see how this works follow the steps below:

  1. Go to the LogicalArchitecture diagram in the OM Editor and select the class CentralControl.
  2. In the Link submenu in the Tools menu, choose Traverse.
  3. The OM Editor will open the LogicalStructure diagram and the CentralControl class will be selected. Go yet another step backwards by choosing Traverse in this diagram.
  4. The Traverse Link dialog pops up asking you to select a link to traverse. The class is the one we just came from so you should choose the text fragment and press Traverse Link.
  5. The Text Editor opens and the endpoint centralcontrol is selected.

In the same way we traversed from system analysis to requirements here, you can also traverse from the requirements to system analysis. Try this!

Entity Match

Now it is time for another consistency check. This time you should check that the instances in the MSC diagram correspond to classes in the object model or to actors that interact with the system.

  1. See to it that you have entity view in the Link Manager window. If not, press the Show endpoint or entities button in the tool bar.
  2. Choose Consistency Check in the Tools menu. Set the entity match radio button in the Consistency Check dialog and press Continue.
  3. As a document representing the from group, select the MSC Enter_Office_With_Card_And_Code_SysA.
  4. As documents representing the to group, select the AnalysisObjectModel module and the ActorsList.
  5. The result shows that all MSC instances really are described in the analysis object model or in the list of actors.

Summary

After having completed an entire system analysis, the System Analysis Document chapter would look like in Figure 740.

Figure 740 : The entire system analysis document structure


http://www.ibm.com/rational
Contents Index Previous Next