![]() |
![]() |
![]() |
![]() |
![]() |
Performing the Object Design
What You Will Learn
- To transfer the analysis object model into a consistent object design model in SDL
- To use the Paste As functionality to assist the task
- To perform design level testing
Introduction to the Exercise
In this exercise you will perform the object design activity. This activity is, like the system design activity, focused on SDL. However, while the system design is focused on how to structure the architecture and how to decompose the system into blocks, the object design is focused on decomposing the blocks into processes and defining the behavior of the single processes.
The object design activity may be divided into three separate tasks:
- Map the classes and associations in the analysis object model to suitable SDL concepts.
- Choose a set of essential use cases and define the behavior of the SDL processes and data types that implement these use cases.
- Elaborate the design by introducing more use cases and refine the SDL design to handle also these use cases.
Preparing the Exercise
The input to this activity should be a complete requirements analysis, system analysis and system design structure.
- Open the system file somttutorial/ObjD/accesscontrol.sdt (on UNIX), or somttutorial\objd\accesscontrol.sdt (in Windows).
- Check that the Source directory is set to somttutorial/ObjD/ (on UNIX), or somttutorial\objd\ (in Windows).
Mapping Active Objects to SDL
An object with its own behavior is called active object. The opposite is an object which acts as an information container - a passive object. Active objects are, most often, mapped to SDL process types. Active objects may also sometimes, as was the case in the system design activity, be mapped to block types.
The default choice in the Paste As mechanism is to paste a class copied from an object model diagram as a process type in an SDL diagram.
The attributes of the copied object will be pasted as variables. The operations will be pasted either as signals or as remote procedures of the process type. This depends on whether the operations are synchronous or asynchronous.
Mapping to Process Types
Now it is time to map the classes in the analysis object model that should be mapped to SDL process types. In this example you should map the processes which will reside within the block type EntranceInterface.
The classes which should reside as processes in the block EntranceInterface are: the CardreaderInterface, the KeypadInterface, the DisplayInterface and the ExitButtonInterface.
- Copy and paste each class from the LogicalArchitecture diagram as a Process Type in the EntranceUnitPackage.
- Open the block type EntranceInterface diagram in the SDL Editor by double-clicking on the corresponding block type symbol in the EntranceUnitPackage. Press OK in the Edit dialog. In the Add Page dialog choose to create a process interaction page.
- Copy each class once again and paste it as a Process in the block type EntranceInterface diagram.
When pasting e.g. the class KeypadInterface as a process, the process will get the same name as the class. This name should be changed since the syntax for process instances requires both an instance name and the name of the corresponding process type. The number of statically and dynamically created instances must also be stated.
- Name the process theKeypadInterface. The process theKeyPadInterface should have one statically created instance and it should not be possible to create any instances dynamically. The following text should thus be written in the process name area: theKeyPadInterface(1,1):KeyPadInterface.
- Change the other three process names too, according to the above.
Now the block type EntranceInterface should contain four processes named: theCardreaderInterface, theKeyPadInterface, theExitButtonInterface and theDisplayInterface.
Defining the Communication Structure
You have already specified the channels to and from the block theEntranceInterface (this was done in the block type EntranceUnit). Now you have to connect the processes within this block with the outside.
Creating a communication structure between processes and the border of the block is made in the same way as creating communication structures between blocks, with one difference. The terminology specifies signal routes instead of channels as the name for the communication structures at this level. However, there is no practical difference between signal routes and channels.
Now, edit the block type EntranceInterface diagram:
- Connect each process with the border of the block with a signal route in each direction.
- Give the gate of the input signal to each process the name Entry and the other gate the name Exit.
- Specify the signals that are transported on each signal route. Consult the system analysis object model and the specification of the block theEntranceUnit to find all signals you should specify.
- Connect the signal routes with the channels by specifying the appropriate gate for each signal route.
Defining the Object Behavior
The activity of describing object behavior is a pure SDL design activity. This section is intended to describe how to structure this activity. It will not focus on specific SDL details.
The most important source of information in this activity are the use cases which specify the signal calls and responses to and from the blocks and processes in the system.
The design of the processes is best made iteratively:
- Select a subset of use cases which describe the most common interaction sequences. Create a basic version of the processes that correspond to these use cases.
- Second, you should introduce a couple of more use cases. Edit the behavior of the processes making them correspond to the extended subset of use cases.
- Continue with introducing more use cases. Edit the processes to cover these, until the behavior of the objects correspond to the complete set of use cases.
Using MSCs to describe the use cases makes it fairly simple to identify the states and transitions of the processes. A transition in a process graph is an input signal, often followed by one or more output signals from the actual process in a use case.
If the situation occurs that two use cases are difficult to combine, you should consider to split the process in question into two separate processes, one process for each use case.
An example is the block type EntranceInterface which have a quite complex structure of input and output signals. However, by dividing the block type into four separate processes, each one of these processes becomes fairly simple.
Defining the Basic Behavior of a Process
- Take a look at the process type KeypadInterface. You will see that the process has a signal set of only two signals: the input signal ReadDigit and the output signal ReceiveCode.
- If you study the MSC diagram Enter_Office_With_Card_And_Code_SysD and the behavior pattern ReadCode you see that four ReadDigit signals generate the output signal ReceiveCode.
- Creating the behavior of the process out of this information is a quite easy task. Adding the timer, which provides the time-out functionality, will make the first version of the behavior specification of the process complete.
- In the EntranceUnitPackage, double-click on the KeypadInterface process type symbol.
- In the process type diagram, define the basic behavior of the process.
Defining the Data of a Process
The processes will of course also need some data containers, entity variables and control variables. The control variables, such as loop counters and flags, are identified during the object design. Entity variables are most often identified during the system analysis and they may be mapped to the process diagrams from the analysis diagrams.
If we take a look at the process theKeyPadInterface again we will notice that we need to introduce a counter to control the number of times a digit will be read before the signal ReceiveCode will be sent. We will also need an index to place the read digit in the correct position of the Code array.
- Place a text symbol in the diagram and declare a CodeIndexType named i in the process.
- The parameter of the ReadDigit signal is of type integer. Declare a variable named Digit of type integer.
- The parameter of the ReceiveCode signal is of type CodeType. Therefore, declare a variable Code of this type.
- Change the name of the gate GKeypadInterface to Entry.
- Also, add an Exit gate and the signal ReceiveCode going out of the process type.
- Declare a timer KeyStrokeTimer with duration 3.
- Refine the behavior of the process.
- Save the diagram.
The rest of the processes in the system are created in a similar way. However, this will not be done in this tutorial.
Design Testing
SDL makes it possible to test the system already during the design. It is possible to simulate an SDL system taking both concurrency and distribution into account. It is also possible to verify requirements specified in MSCs using the Explorer.
The MSC diagrams may, with no or little effort, be used directly as input to the Explorer. This makes the requirements verification simple and efficient.
Preparing the Design Testing
To be able to test your design you must have a complete system.
- Open the system file somttutorial/objdesign/accesscontrol.sdt (on UNIX), or somttutorial\objdesign\accesscontrol.sdt (in Windows). What you see in the Organizer now is a complete system structure. All four documentation chapters representing activities from the SOMT method are complete.
- Check that the Source directory is set to somttutorial/objdesign/ (on UNIX), or somttutorial\objdesign\ (in Windows).
Simulating the System
Simulating the system gives information about how different parts respond to certain inputs and how different parts of the system interacts with other parts. Simulating is often done during the object design to test different parts of the system.
The complete system should also be tested using the simulator to verify that the whole system works as it is intended to.
Try to simulate the system AccessControl. Follow the steps below to make a simulator version of the system AccessControl.
- Select the system AccessControl in the Organizer.
- Choose the Make option in the Generate menu.
- In the Make dialog, choose the code generator to be Cbasic.
- Choose the standard kernel to be Simulation.
- Press the Analyze Options button to open the Analyze SDL dialog and make sure the Case sensitive SDL option is not ticked.
- Press Full Make. The system will be automatically analyzed. If there are any warnings you can ignore them. These warnings show up because we have not used all our declared signal lists. As they are just warnings, not errors, you can ignore them.
- When the make process is finished, start the Simulator by choosing Simulator UI in the SDL submenu in the Tools menu.
- In the SDL Simulator UI window, open the file accesscontrol1_smb.sct (on UNIX), or accesscontrol1_smb.exe (in Windows). Now you can simulate the system, as you have learned in previous tutorials.
Validating the System
When the design of the system is finished you want to verify that the system meets the requirements. This is quite easily done in the SDL Suite by using the SDL Explorer.
MSCs from the system design are used as input to the Explorer.
The requirements use case model is the essential part of the requirements and is often the specification of the system which the customer and the contractor agree upon. Thus, by verifying the system with the MSCs from the system design you are verifying that the system meets the customers requirements.
By making it possible to verify the customers requirements already in the object design and not in a special system design test phase, as in an ordinary design process, you save a lot of effort and time.
Now you should validate some of the MSCs from the system design activity.
- Select the system AccessControl in the Organizer.
- Choose the Make option in the Generate menu.
- In the Make dialog, choose the code generator to be Cbasic.
- Choose the standard kernel to be Validation.
- When the Make process is finished, start the Explorer UI and open the file accesscontrol1_vlb.val (on UNIX), or accesscontrol1_vlb.exe (in Windows). Now the system is ready to be validated.
- Press the Verify MSC button and choose the system design MSC diagram enter_office_with_card_sysd.msc which you can find in the directory somttutorial/sysdesign.
- If the verification succeeds, you will get the message "** MSC <Diagram name> verified **".
It is perhaps too much work to verify all the MSC diagrams of the system design activity during this tutorial and you may quit when you feel that you have understood the principle of how to verify an SDL system.
If all diagrams can be verified against the system, then it is verified that the system also meets the requirements specified in the beginning of this tutorial.
Consistency Checks
There are mainly two consistency checks that should be performed in the object design activity:
- Check that all objects from the analysis object model have been implemented in the design.
- Check that the design model correctly implements the requirements from the design use cases.
The second consistency check is done through design level testing, see Design Testing. The first one will be performed through a link check, see below.
Link Check
In our complete Access Control system there are implementation links from the system analysis models to both the system design models and the object design models. This implies that we must check our analysis object model against both these design models to see if all the classes have been implemented in the design.
- Perform a link check. Let the analysis object model form the from group. The architecture definition and the SDL design model will form the to groups.
The result shows that all classes but the class SecurityLevel have corresponding processes, blocks, signal interfaces or procedures in the design. The SecurityLevel does not have any behavior of its own, it is implemented through its subclasses, and, therefore, the result is just as we want it.
We have now completed the design of the system. It is possible to pick an endpoint in the textual requirements and follow the implink from it, through the object models, to SDL. It is also possible to traverse links the other way, i.e. from design to requirements. Try this!
The use cases are also connected to each other, from requirements to design, as can be seen in the view of the link file in the Link Manager window.
Summary
After having completed an entire object design the corresponding document structure in the Organizer would look like in Figure 760.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |