![]() |
![]() |
![]() |
![]() |
![]() |
Performing an Iteration
What You Will Learn
- To introduce changes to a system in a controlled way
- To use the implementation links to assist you in the activity
Introduction to the Exercise
During the life time of a system new requirements and changes in existing requirements are almost always introduced. We have to be able to handle these requirement changes and adapt the system to the new situation in a controlled way. We call this process iteration. An iteration may also be planned in advance in, for example, incremental development.
This section will describe the scenario of an iteration caused by the introduction of an additional requirement.
Preparing the Exercise
As input to this exercise we will use the complete Access Control system.
- Open the system file somttutorial/Iter/accesscontrol.sdt (on UNIX), or somttutorial\iter\accesscontrol.sdt (in Windows).
- Check that the Source directory is set to somttutorial/Iter/ (on UNIX), or somttutorial\iter\ (in Windows).
- Create a new chapter and name it Iteration Documents.
- Add a new module called AdditionalTextualRequirements to the new chapter.
- Add the existing file AdditionalTextualRequirements.txt to the new module.
Studying the Additional Requirements
- Open the additional textual requirements document if it is not already open. The example below shows the document.
Example 656 : Additional requirements
The system should be able handle the languages English, German and French. One version of the system should handle a specific language and the system should be easily configured to handle a new language.
As stated in the example above, the task is to redesign the system so it can handle different languages. The design should be made in a way that makes it easy to configure the system to new languages.
The words English, German and French are marked as endpoints in the document.
Examining the Consequences
Now it is time to validate what consequences the new requirement has on the system. The new requirement identify one object that may be affected, the Display object.
- Study the requirements regarding the Display in the original textual requirements document. You should find that the new requirement does not contradict with the original requirements.
- Traverse the implementation link from the text fragment Display in the original textual requirements. The logical structure diagram in the requirements object model will pop up with the class Display selected.
- With the class still selected, choose Traverse Link once more and follow the link to the logical architecture diagram in the analysis object model. The class DisplayInterface, with operation Display and attribute Text will be selected. The class is a part of the class EntranceUnit. It also has a connection to the class EntranceCtrl, see Figure 762.
- Continue to follow the link of the class DisplayInterface, from the logical architecture to the package EntranceUnitPackage. The class is connected with the block type EntranceInterface and the process type DisplayInterface as well as with the signal interface defining the signal Display.
- You can also follow the implementation links from the class DisplayInterface to the block theEntranceInterface (within the block type EntranceUnit) and to the process theDisplayInterface (within the block type EntranceInterface).
- Open the block type EntranceInterface in the Object Design Documents structure. Study the signal routes leading to and from the process theDisplayInterface. You will notice two signals: Display and EnvDisplay. Examining the two signals with help of the Signal Dictionary will give you information about the signals. EnvDisplay has the parameter Charstring and the signal Display has the parameter MessageType.
- Open the process type DisplayInterface. Study the behavior. You will notice that it is possible to change the content of the EnvDisplay signal without affecting the behavior of the process type. It also seems like the required changes to the system are limited to the process type DisplayInterface.
Introducing Changes in Documents
Now you should introduce the necessary changes to the system to get the desired behavior. Changes should be made in a controlled way. All documents affected of the changes should be edited, to keep the consistency.
Updating the Data Dictionary
- Open the data dictionary. Include information presented in the additional requirements to the data dictionary.
- Save the file as DataDictionary.txt in the current directory.
Updating the Requirements Object Model
As we saw earlier, the change we have to introduce to the system is focused on the process type DisplayInterface. The new requirement specify that one version of the system should handle a specific language and the only language dependent part of the system is the process type DisplayInterface.
It seems natural to introduce a class for each one of the languages English, German and French in the logical structure diagram. These classes should be subclasses to the class Display, i.e. an inheritance structure is needed.
- Add the three new classes to the logical structure diagram in the requirements object model. Name the classes FrenchDisplay, EnglishDisplay and GermanDisplay respectively.
- Link the classes with the corresponding text in the additional textual requirements document.
- Save the diagram as logicalstructure.som in the current directory.
- Make a link from the class Display to the class DisplayInterface in the logical architecture diagram in the analysis object model.
Updating the Analysis Object Model
In the logical architecture diagram we have to create an inheritance hierarchy corresponding to the inheritance hierarchy in the logical structure.
- Create the three subclasses to the class DisplayInterface. Name the classes EnglishDisplayInterface, GermanDisplayInterface and FrenchDisplayInterface.
- Create implementation links to the corresponding classes in the logical structure diagram. (An alternative here would have been to copy the classes from the logical structure diagram and paste them as classes in the logical architecture diagram. The implementation links would then have been created automatically.)
- Traverse the link from the class DisplayInterface to the process type DisplayInterface in the EntranceUnitPackage.
Updating the SDL Design
Now it is time to make some changes to the SDL design, making it correspond to the logical architecture. The inheritance hierarchy of the DisplayInterface classes should be mapped to an inheritance hierarchy of process types.
- Create two new process types in the EntranceUnitPackage. Name the process types GermanDisplayInterface and FrenchDisplayInterface. The already existing DisplayInterface process type will function as the EnglishDisplayInterface.
- Mark these process types as endpoints and create links between them and the corresponding classes in the logical architecture. (Alternatively, use the Copy-Paste As mechanism.)
- Double-click on the DisplayInterface process type in the EntranceUnitPackage.
- Create a variable of type charstring for each possible message that can be sent to the environment. You will need eight such variables.
- Put the text Virtual in the start symbol.
- Insert a task symbol just after the start symbol.
- In the task symbol you should initialize the message variables to the corresponding message.
- Edit each output symbol making it use the corresponding message variable as a parameter instead of a text string. The process type DisplayInterface will use English language.
After editing the DisplayInterface process type it is time to create the process types GermanDisplayInterface and the FrenchDisplayInterface. For each process follow the steps below:
- Open a graph page for each process type by double-clicking on the corresponding process type symbol in the EntranceUnitPackage. Press OK in the edit dialog.
- In the additional heading you should enter the text:
INHERITS DisplayInterface ADDING;- Place a start symbol in the diagram and enter the text REDEFINED in the symbol.
- Connect a task symbol to the start symbol. The task is to initialize the message variables to the appropriate messages. Do not use national characters.
- Connect a state symbol with the task symbol and name it Wait_for_signal.
- Save the diagrams.
Now the necessary behavior is described and it is time to show how to configure the system to make use of the new design.
Configuring the System
The necessary design is done and we want to configure our system to make use of the new design. Following the steps below will configure the system to a German version.
- Open the block type EntranceInterface.
- Select the process theDisplayInterface and change the text theDisplayInterface(1,1):DisplayInterface to theDisplayInterface(1,1):GermanDisplayInterface
- Now you can analyze the system. Perhaps you want to simulate the new version of the system; if so, follow the steps described in Simulating the System.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |