![]() |
![]() |
![]() |
![]() |
![]() |
Performing the System Design
What You Will Learn
- To create a design module structure
- To define the static interfaces in packages
- To make an architecture definition of the system
- To make formalized testable use cases
- To use the Paste As mechanism when transferring from the system analysis activity to the system design activity
Introduction to the Exercise
This is an exercise on system design. In this activity we no longer make use of object models; from now on SDL will be used. You will learn how to map concepts from the analysis object model from the previous activity into an SDL model. Mapping object-oriented concepts to SDL concepts forces you to make several design decisions. Support for these design decisions is provided through the Paste As mechanism. This exercise will teach you to make use of this support.
Useful sources for information in the system design activity are the analysis object model and the analysis use case model. The first provides information about the static structure and is useful when structuring the system into units. The latter provides information about the dynamic structure and is useful for the definition of the interfaces between the units.
Major tasks to perform in the system design are:
- Define the design module structure.
- Define the static interfaces.
- Create an SDL system structure as a starting point for the formalization of the architecture.
- Define the dynamic aspects of the interfaces by a continued use of use cases.
Producing a complete system design structure in the tutorial takes too much time. Thus, you will only perform parts of every step necessary to produce a system design structure.
Preparing the Exercise
- Open the system file somttutorial/SysD/accesscontrol.sdt (on UNIX), or somttutorial\sysd\accesscontrol.sdt (in Windows).
- Check that the Source directory is set to somttutorial/SysD/ (on UNIX), or somttutorial\sysd\ (in Windows).
What you now see in the Organizer window is a complete requirements analysis and system analysis structure.
Design Module Structure
An important part of the system design is to divide the system into units considering division of work, distribution of functionality and physical distribution.
The purpose of the design module structure is to show the actual source code modules the application will be built from. The most important aspect of the module structure is that it forms the basis for dividing the work load on different development teams.
In our Access Control system example we have two different subsystems, EntranceUnit and CentralControl. It might be the case that these subsystems are implemented by two different teams. Therefore, it seems natural to introduce two different modules, each module being described by the concept of a package. The contents of the packages will not be defined until the architecture definition, the task here is only to identify the modules needed.
The notation that will be used in this tutorial to describe the design module structure is the object model instance diagram where the instances represent the different modules.
Creating a Design Module Structure
- Add a new object model diagram to the Organizer in the module DesignModuleStructure and name the document DesignModuleStructure.
- In the OM Editor, create a first object instance symbol representing the whole SDL system. Name it using the name SDL_System_Access_Control.
- Decide which modules, i.e. packages, the SDL system is to make use of. In this example it might be suitable to introduce two different modules, one for each subsystem. Therefore, create two more object instances and name them CentralControlPackage and EntranceUnitPackage respectively.
- Draw associations from the SDL system module to the two new modules. The associations describe that the SDL system uses these two packages.
- Create yet another module which will consist of all common types and signals. This package is used by the other two packages and thus also by the SDL system itself. Name the module UtilityTypesPackage and draw the associations. Your diagram should now look like in Figure 742.
- Create endpoints out of the three packages. (Endpoints are not created automatically for object instance symbols.)
- Save the diagram giving it the name designmodulestructure.som.
Creating the Architecture Definition
When using SDL to design a system, the architecture is defined by block diagrams which define how the system is decomposed into blocks. The block diagrams are more or less a formalization of the analysis object model.
The first thing we will do when defining the architecture is to define the contents of the packages introduced in the design module structure, see Defining the Packages. The UtilityTypesPackage will contain data type declarations that are common to the subsystems of the system. Signals/remote procedures that make up the interface between the subsystems will also be defined in the UtilityTypesPackage. The other two packages, CentralControlPackage and EntranceUnitPackage, will contain block types and the signals/remote procedures that make up the interface to the particular block. If you have many signals it is often useful to structure these into signal lists.
The basic mechanism used in SOMT when going from analysis to design is the Paste As mechanism. This is used here when defining the signal interfaces, the blocks and block types, and, to some extent, the data type declarations.
The second task to do when creating the architecture definition is to define the system by means of SDL block diagrams, see Creating the SDL System Diagram.
Defining the Packages
Mapping Object Models to SDL Block Types
You should now define the two block types, CentralControl and EntranceUnit in their respective package using the Paste As mechanism.
- Add three new SDL packages to the ArchitectureDefinition module in the Organizer and name them according to the modules in the design module structure.
- Open the LogicalArchitecture diagram in the AnalysisObjectModel module.
- Select the class CentralControl and copy it.
- Go to the SDL Editor and the CentralControlPackage diagram and choose Paste As. The Paste As dialog is opened.
- Paste the class CentralControl as a Block Type (use the option menu) and create an implementation link from the copied object to the pasted object at the same time. The link is automatically created by default.
- Copy and paste the class EntranceUnit as a block type in the EntranceUnitPackage in a similar way.
Mapping Object Models to SDL Interface Definitions
Now it is time to design the interfaces of the newly pasted blocks. Interface definitions in SDL are defined using signals and/or remote procedure calls. Consequently, this is what is produced when mapping a class to an SDL interface.
Note that the signals that constitute the interface between our subsystems should be described in the UtilityTypesPackage. The rest of the signals, i.e. signals that are not exchanged between the subsystems should be described now. Signals from the environment to the subsystem and signals inside the subsystem are such signals.
- Once again, go to the LogicalArchitecture diagram in the AnalysisObjectModel and copy the class EntranceUnit.
- Go to the SDL Editor and the EntranceUnitPackage diagram and paste the class as a Text symbol with SDL interface. See to it that an implementation link is created at the same time.
- Delete the ChangeSecurityLevel signal.
- Add the signal parameters. The signals ReadCard and ReadDigit are the only ones that need parameters. See Figure 743.
- Save the diagram, giving it the name entranceunitpackage.sun.
- Go back to the LogicalArchitecture diagram and copy the class CentralControl.
- Paste it as a text symbol with SDL interface in the CentralControlPackage.
- If you look at the signal definition you realize that the ValidateCard, ValidateCode and RegisterEntrance signals are signals exchanged between our subsystems and, thus, should not be defined here. Therefore, delete these signals from the signal definition.
- Add a signal parameter of the type integer to the ChangeSystemSecurity signal, see Figure 744.
- Save the diagram, giving it the name centralcontrolpackage.sun.
It is now time to define the last package, the UtilityTypesPackage. It will define the common data types needed in the subsystems as well as the interface between the subsystems. To define the package you should use the same procedure as above.
- Copy the class CentralControl from the LogicalArchitecture diagram.
- Paste it as a text symbol with SDL interface in the UtilityTypesPackage diagram.
- Delete the signal ChangeSystemSecurity as this has already been defined in the CentralControlPackage (because it is a signal from the environment).
- Add signal parameters to the three remaining signals.
- Continue with copying the class EntranceUnit and paste it as a text symbol with SDL interface in the UtilityTypesPackage.
- Remove all signals that have already been defined, i.e., all but the ChangeSecurityLevel signal.
Note that the Validate commands (ValidateCard and ValidateCode) have to be implemented with signals and not remote procedure calls. This is due to the fact that we must be able to keep track of how long it takes before we get the answer of a validation (to find out if there is a connection failure or not). As a consequence of this, the reply signals to the Validate commands have to be defined here.
- Add the two signals ValidateCardReply and ValidateCodeReply to the latest pasted signal definition.
- Add signal parameters to the three signals in the definition.
Mapping Object Models to SDL NewTypes
Now it is time to declare the common data types. In our Access Control system example the concepts of card and code are data types common to all parts of the system.
The data type Card is best declared as a SYNTYPE. You will have to do this declaration manually as there is no support in the Paste As mechanism for pasting something as a SYNTYPE. In declaring the data type Code, however, the Paste As mechanism can be used.
- Declare the Card concept as a SYNTYPE in the UtilityTypespackage, see Figure 745.
- Open the InformationDiagram in the AnalysisObjectModel and copy the class Code.
- Go to the SDL Editor and the UtilityTypesPackage and choose Paste As. The Paste As dialog is opened.
- Paste the class Code as a NEWTYPE with graphical operator or as NEWTYPE with textual operator (it does not matter which one you choose as the class Code has no operator) and see to it that an implementation link is created at the same time. This will only give you the structure, you have to fill in all relevant information yourself.
- As it is a type we are declaring, change the name Code to CodeType. Define the CodeType concept to be an array consisting of four integers (you will have to delete the word STRUCT). The index type of the array should be integer and you will have to define this type too, see Figure 745.
- Declare a SYNONYM NbrOfEntrances that will be used to alter the number of entrances we are to control in our system. For now, you can set the value of the variable to 1, see Figure 745.
Before you save and close the diagram you should create an implementation link between the class Card from the InformationDiagram to the definition of Card in this diagram. You have earlier used the Link Manager to manually create links. We will now show how to use the entity dictionary for this.
The entity dictionary is available in all editors and lists all entities in the system, i.e. all modules, diagrams, and endpoints. The main usage of the entity dictionary is to reuse names of entities, but it can also be used to create links.
- In the UtilityTypesPackage diagram, select the text symbol containing the Card definition.
- From the Window menu, choose Entity Dictionary. The Entity Dictionary window is opened. You will recognize the structure and icons of chapters, modules and diagrams from the Organizer window. In addition, all endpoints are listed beneath the corresponding diagram.
- Scroll the Entity Dictionary window until you find the class Card in the InformationDiagram in the AnalysisObjectModel module. Select the icon representing the class Card. (Make sure not to double-click an icon, since that will copy the name of the icon into the current diagram!)
- In the Entity dictionary, press the Create Link quick button.
- The Create Link dialog pops up. (This is the same dialog as when you created links in the Link Manager.) Set the from radio button, name the link Implementation Link and press Create.
- Close the Entity dictionary by using the Close quick button.
- Save the diagram, giving it the name utilitytypespackage.sun.
Creating the SDL System Diagram
Now you should define the system structure, something which is to be done by means of SDL blocks in a system diagram.
- Add an SDL system diagram to the ArchitectureDefinition module in the Organizer and name it AccessControl.
- Copy the class CentralControl in the LogicalArchitecture diagram and paste it as a Block in the system diagram. See to it that an implementation link is created at the same time.
- Also, copy and paste the class EntranceUnit as a block.
- Change the name of the block instances, from CentralControl to theCentralControl and from EntranceUnit to theEntranceUnit. Also, define which block type the blocks are an instance of, see Figure 746.
- There will often be more than one entrance in a building and therefore you should define the block theEntranceUnit as a block instance set. (Use the variable NbrOfEntrances defined in the UtilityTypesPackage.)
- Draw the channels through which the blocks communicate and name them and the gates with suitable names. Also, draw the channels to/from the environment. State which signals that run on a certain channel. To identify the signals consult the AnalysisObjectModel made in the system analysis.
- At this point we see the need to introduce a new signal, the EnvDisplay signal which goes from the EntranceUnit to the environment (i.e, to the display hardware). This signal contains information that is to be read by persons in the system environment. The parameter of this signal is Charstring. Define it in the EntranceUnitPackage.
- Reference the packages the SDL system makes use of in a USE clause in the top of the diagram. Your system diagram should now look like in Figure 746.
- Save the diagram, giving it the name accesscontrol.ssy.
Refining the EntranceUnit - Mapping Aggregations
Considering the aggregation structure in the LogicalArchitecture diagram, the block EntranceUnit may be divided into several sub-blocks.
When mapping an aggregation structure from the analysis object model to an SDL diagram, the most common choice is to map the assembly class to a block type. Classes which are part of the assembly class will be mapped to process types, or, if the part class itself is an assembly class, to block types.
The block type corresponding to an assembly class will thus contain processes or blocks.
The process types and block types should be placed in a suitable package to enable reuse. The instances of the types should then be placed in the appropriate system or block diagram to form the system.
Mapping Classes to Block Types and Signal Interfaces
- Select the class DoorUnit in the LogicalArchitecture diagram. Copy it and paste it as a block type in the EntranceUnitPackage.
- Call the Paste As command again. This time, choose to paste the class as a text symbol with SDL interface in the EntranceUnitPackage.
- The resulting signal definition contains two signals that already have been defined in the package, namely Open and Close. Therefore, delete these signals in the newly pasted signal definition.
Mapping Classes to Blocks
Now it is time to place a block instance of the DoorUnit block type in the EntranceUnit block type.
- Double-click on the EntranceUnit block type in the EntranceUnitPackage diagram. The Edit dialog pops up, press OK. The Add Page dialog pops up. Create a block interaction page.
- For the third time, choose Paste As and paste the class DoorUnit as a block in the EntranceUnit block diagram. The block will be named DoorUnit.
- Change the block name so it is marked as an instance of the block type according to the SDL syntax. Change the name to theDoorUnit:DoorUnit.
Introducing new Block Types
Since SDL does not allow processes and blocks at the same level you have to create two more block types to be placed in the EntranceUnitPackage. These block types will be used as containers to the remaining classes that will be mapped to processes and process types. Give the first block type the name EntranceInterface. We introduce this block as a generic term for all those classes that represent an interface to the system, i.e. the cardreader, the keypad, the display and the exitbutton. The second block type to be placed in the EntranceUnitPackage is EntranceCtrl.
- Copy the class DisplayInterface in the LogicalArchitecture diagram.
- Paste it as a block type and as a text symbol with SDL interface in the EntranceUnitPackage.
- Rename the block type and give it the name EntranceInterface.
- Add a signal parameter called MessageType to the Display signal definition. By using this type for messages the EntranceCtrl does not have to handle strings. This solution makes the system independent of the language used, see Performing an Iteration for an example on how this works.
- Define the NEWTYPE MessageType, see Figure 748.
- Also, paste the class DisplayInterface as a block in the EntranceUnit block diagram. Rename the block and give it the name theEntranceInterface:EntranceInterface.
- Using the Entity Dictionary, create implementation links between the CardReaderInterface, KeypadInterface and ExitButtonInterface classes in the LogicalArchitecture diagram and the EntranceInterface block type and block.
- Now, copy and paste the class EntranceCtrl as a block type and as a text symbol with SDL interface in the EntranceUnitPackage.
- Delete the signal ChangeSecurityLevel as this already has been defined in the UtilityTypesPackage.
- Add signal parameters where they are needed i.e. to the signals ReceiveCard and ReceiveCode.
- Also, paste the class as a block in the block type EntranceUnit diagram. Give the block the name theEntranceCtrl:EntranceCtrl.
The EntranceUnitPackage will look like in Figure 748.
The block type EntranceUnit diagram should now contain three blocks: theDoorUnit, theEntranceInterface and theEntranceCtrl.
Defining the Communication Structure
Now you should define the communication structures within the block type EntranceUnit. Define the channels needed for the three blocks theEntranceCtrl, theEntranceInterface and theDoorUnit to communicate.
To define the channels in the block type EntranceUnit, follow the steps described below.
- Identify necessary channels.
- Identify the signals that should be carried by the channels. You get a lot of information from the AnalysisObjectModel here.
- Name the channels and the gates.
- The complete block diagram for EntranceUnit should look something like in Figure 750.
When you have completed the architecture definition, the System Design Documents chapter should look like in Figure 751.
Creating the Design Use Case Model
In system design we continue with the use of use cases, this time to define the dynamic interfaces between the blocks in the system.
In our example, the block theEntranceUnit in the system diagram is split into the three blocks, theEntranceCtrl, theEntranceInterface and theDoorUnit. The use cases will consist of the block instances theCentralControl, theEntranceCtrl, theEntranceInterface and theDoorUnit as well as an instance representing the environment.
The use cases must be formalized to a sufficient degree of detail, a level that is consistent with the level of detail found in the static interface definition. Also, the level of detail must be precise enough to make the design use cases act as detailed test specifications.
Formalizing Use Cases
A number of things have to be done when formalizing and refining analysis use cases to design use cases.
- Check that each MSC instance head has a corresponding block in the architecture definition. The use cases define the dynamic interface between the blocks in the system and thus all blocks have to be represented.
- The MSC instances corresponding to actors in the system environment should have env_ stated in their instance head before the actual name, e.g. env_Employee.
- The MSC instances must have names corresponding to block instances as it is the instances that communicate. That is, the name of those instances that have been defined as block types in the SDL package structure must be changed to the corresponding block instance name. E.g. the MSC instance CentralControl can no longer have this name; the name has to be changed to theCentralControl according to the architecture definition.
- The messages often have to be replaced with a sequence of message exchanges.
- The MSC messages have to be complemented with parameters according to the definition of signals and remote procedures in the architecture definition. It should not be the name of the parameter that should be added but a value that the parameter can take. Alternatively the parameters can be skipped entirely.
Creating a Formalized Use Case
Now you should begin to formalize and refine one of the use cases from the system analysis.
- Add a new MSC diagram to the DesignUseCaseModel module in the Organizer.
- In the Add New dialog, set the toggle button Copy existing file. As the file to be copied, select the MSC Enter_Office_With_Card_And_Code_SysA from the system analysis activity. This file can be found in the somttutorial/sysanalysis directory.
- In the MSC Editor, rename the instance head Employee to env_Employee and change/add the other instance head names. They should conform to the names used on the block instances in the SDL system diagram and the blocks in the EntranceUnit block diagram in the architecture definition.
- For each message, decide if it has to be exchanged with a sequence of messages. If so, add these new messages to the MSC.
- Add parameters to the messages. Look at the definition of the signals in the architecture definition and add parameters to those messages that are defined to have parameters. E.g. the message ReadCard should have a parameter consisting of the card. Note that it is not the parameter name Card that is to be used here but an example of a value that the parameter can take, e.g. 123.
- Rename the use case and save it under its new name, Enter_Office_With_Card_And_Code_SysD (use Save As).
The exceptions and behavior patterns to this use case must also be formalized.
The other design use cases are created in a similar way. All design use cases should also be connected with implementation links to the corresponding analysis use case and exception. This is done in order to make it possible to check that all use cases from the requirements analysis and system analysis have been refined to design use cases.
Consistency Checks
Now the time has come to performing consistency checks on the models created in system design.
Entity Match
The first thing to check is that the actual modules (SDL packages) used in the design are consistent with the design module structure.
- In the Link Manager, choose Consistency Check in the Tools menu and set the entity match radio button. Note that you have to be in entity mode to be able to perform an entity match.
- Let the packages in the ArchitectureDefinition form the from group and the DesignModuleStructure module the to group.
The result shows that all packages in the ArchitectureDefinition really are described in the DesignModuleStructure. The consistency view (i.e. the resulting Link Manager window) also shows the contents of the packages. As you can see there are no matching entities to the block references, block types, etc. in the DesignModuleStructure. There should not be any, so just ignore this.
Link Check
By doing a link check we will first check that all objects in the analysis object model are mapped to the architecture definition.
- Once more, choose Consistency Check in the Tools menu and perform a link check. It does not matter which view you have in the link Manager window, a link check can be performed in either view.
- Let the AnalysisObjectModel form the from group and the ArchitectureDefinition module form the to group.
The result shows that most of the objects from the analysis object model are described as block types and block references in the architecture definition. Many of the objects have also been mapped to an interface definition. The fact that some classes have no corresponding mapping indicates that these classes probably should reside as processes inside some of the mapped blocks. This holds e.g. for the DoorSensorInterface and the DoorLockInterface as well as for the SecurityLevel classes.
At this point you can also select any block or block type in the architecture definition and choose Traverse link. The corresponding class in the analysis object model will then be selected. By choosing Traverse link again you can follow a link all the way back to the textual requirements. It is also possible to follow a link in the other direction, i.e. from the textual requirements via the object models, to the design. Try this!
Summary
After having completed an entire system design the corresponding document structure in the Organizer would look like in Figure 752.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |