Home

78 SOMT Tutorial

1. e Create an SDL system structure as a starting point for the formaliza tion of the architecture e 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 1 Open the system file somttutorial SysD accesscontrol sdt on UNIX or somttutorial sysd accesscontrol sdt in Windows 2 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 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Design 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 as pect 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 sub systems EntranceUnit and CentralControl It might be the case that these subsystems are implemented by two different teams The
2. Telelogic Tau 4 5 User s Manual 3911 Chapter 78 SOMT Tutorial 3912 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 de composing the blocks into processes and defining the behavior of the single processes The object design activity may be divided into three separate tasks 1 Map the classes and associations in the analysis object model to suitable SDL concepts 2 Choose a set of essential use cases and define the behavior of the SDL processes and data types that implement these use cases 3 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 1 Open the system file somttutorial ObjD accesscontrol sdt on UNIX or somttutorial objd accesscontrol sdt in Windows 2 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 Ac tive object
3. ka Alt Figure 748 The signal sequence of the process theKeyPadInterface 3918 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the Object Design Creating the behavior of the process out of this information is a quite easy task Adding the timer which provides the time out func tionality will make the first version of the behavior specification of the process complete 3 In the EntranceUnit Package double click on the KeypadInterface process type symbol 4 In the process type diagram define the basic behavior of the pro cess Process Type KeypadInterface WaitForDigit RESET KeyStrokeTimer WaitForDigit SET frosting Preece cies Figure 749 Basic behavior of the KeypadInterface process type Defining the Data of a Process The processes will of course also need some data containers entity vari ables 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 Telelogic Tau 4 5 User s Manual 3919 Chapter 78 SOMT Tutorial 3920
4. EnvDispiN EnvDisplay EnvDisplay EnvDisplay EnwDisplay Env Display EnterCardy EnterCodgy DoorlsOpert DoorlsLogk d KInvalidCarg WrongCode CodeTimefadt Connectigntailure J k k k k k SET Display Timer Oita Delay Figure 755 The process type DisplayInterface Save the diagram in the current working directory 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 10 11 12 13 14 15 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 na tional characters Connect a state symbol with the task symbol and name it Wait_for_signal Save the diagrams Telelogic Tau 4 5 User s Manual July 2003 Performing an Iteration Now the necessary behavior is described and it is time to show how to configure the system to make use of the new design Process Type GermanDisplay nterface 1 1 REDEFINED EnterC
5. Foalysis use case model textMSC Foalysis object model class diagram Data dictionary System Analysis System design use di eem model SDL MSC ATTCN r Object design Dosen model SDL ASE J y Code hardware ete Figure 725 Overview of the SOMT process Implementation What You Will Learn e To identify and present the logical architecture of a system which includes refining the object model from the previous phase e To refine use cases from the previous phase To use the Paste As mechanism 3870 Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis Introduction to the Exercise In this exercise you will perform the system analysis activity The pur pose 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 e requirements object model e requirements use case model The output from the system analysis activity are the two
6. ment This section will describe the scenario of an iteration caused by the in troduction of an additional requirement Preparing the Exercise As input to this exercise we will use the complete Access Control sys tem 1 Open the system file somttutorial Iter accesscontrol sdt on UNIX or somttutorial iter accesscontrol sdt in Windows 2 Check that the Source directory is set to somttutorial Iter on UNIX or somttutorial iter in Windows 3 Create a new chapter and name it Iteration Documents 4 Add anew module called AdditionalTextualRequirements to the new chapter 5 Add the existing file AdditionalTextualRequirements txt to the new module 3928 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing an Iteration Studying the Additional Requirements e Open the additional textual requirements document if it is not al ready open The example below shows the document Example 612 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 Exami
7. Telelogic Tau 4 5 User s Manual 3865 Chapter 78 SOMT Tutorial 3866 Yet another dialog appears asking you to select the documents rep resenting the to group Select the DataDictionaryModel module and press Check The Link Manager window will show the result of the entity match in a new consistency view Entities from the from group are shown as normal endpoints and entities from the to group are shown as dashed endpoints The links shown are temporary links created by the Link Manager to indicate matching entities see Figure 723 i Text Office Module TextualRequirementsModel Matching Temporary link Text Office Module DataDictionaryModel root N re Figure 723 Matching entities As you can see if you scroll through the Link Manager window all the concepts from the textual requirements have a matching entity in the data dictionary An endpoint from the to group without a matching link from it would have indicated that no corresponding entity could be found in the to group There are a few more consistency checks which you can perform at this point Check that all entities in the requirements object model are de scribed in the data dictionary Let the RequirementsObjectModel module form the from group and the DataDictionary module the to group As you can see from the result all concepts but the four different security levels have been described in the data dictionary Check that all import
8. The class is connected with the block type Ent ranceInterface and the process type DisplayInterface as well as with the signal inter face defining the signal Display You can also follow the implementation links from the class the block type 1 DisplayInterface to the block theEntranceInterface within 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 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing an Iteration 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 7 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 lim ited 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
9. also need an index to place the read digit in the correct position of the Code array 1 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 process type Exit gate and the signal ReceiveCode going out of the Declare a timer KeyStrokeTimer with duration 3 Refine the behavior of the process Save the diagram Telelogic Tau 4 5 User s Manual July 2003 Performing the Object Design Process Type Keypadinterface potresce k i A i DCL is IMER A EERE 4 Digit Integer 3 CodelndexType Key Stroke Timer 3 Code CodeType D Wait For Digit Read Digit Key Stroke Digit Timer RESET it Key StrokeTimet a Wait For Digit Codeti Digit i i 1 Figure 750 The complete process type KeypadInterface The rest of the processes in the system are created in a similar way However this will not be done in this tutorial July 2003 Telelogic Tau 4 5 User s Manual 3921 Chapter 78 SOMT Tutorial 3922 Design Testing SDL makes it possible to test the system already during the design It is possible to simulate an SDL system taking bot
10. CentralControl In the Link submenu in the Tools menu choose Traverse The OM Editor will open the LogicalStructure diagram and the CentralControl class will be selected Go yet another step back wards by choosing Traverse in this diagram 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 The Text Editor opens and the endpoint centralcontrol1 is select ed Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis 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 Asa document representing the from group select the MSC Enter Office With Card And Code_SysaA 4 As documents representing the to group select the AnalysisObjectModel module and the ActorsList 5 The result shows that all MSC instances really
11. Exc_Invalid_Card MSC with the Enter Office With Card _And_ Code MSC as it is an exception to this use case The Requirements Documents chapter should now look like in Figure 717 In reality you repeat the steps above for all the use cases found and as sociate each one of them with its exceptions In this tutorial however Telelogic Tau 4 5 User s Manual 3859 Chapter 78 SOMT Tutorial we will not create the entire use case model as that would take too much time Requirements Documents E TextualRequirementsModel TextualRequirements E DataDictionaryModel E DataDictionary E RequirementsUseCasemodel ActorsList UseCaseList Enter_of fice_With_Card_and_Code Enter_Of fice_With_Card_and_Code Exc_Invalid_Card Requirementsob jectModel MSC_Exceptions_Rega Exc_Invalid_card Figure 717 The Requirements Documents chapter Now when we have our use cases and a data dictionary we will contin ue the activity with producing a requirements object model In practise you should work with all the models in parallel The activities in SOMT are not supposed to be performed in a sequential order rather produc ing the models is a highly iterative process 3860 Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements Creating the Requirements Object Model The requirements object model is intended to capture the objects the re lations between these objects and other conc
12. 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 require ments 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 Telelogic Tau 4 5 User s Manual 3873 Chapter 78 SOMT Tutorial 3874 should be shown in the analysis object model See section Finding Re lations on page 3876 11 Copy the class Door in the LogicalStructure diagram 12 Paste it three times as a class in the LogicalArchitecture dia gram 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 re sponsible for what happens at an entrance Therefore you should add such an object and name it EntranceCtrl see below The Entrancec trl will be a part of the EntranceUnit 13 Copy the class Entrance from the LogicalStructure diagram 14 Paste it as a class in the LogicalArchitecture and rename the class giving it the name EntranceCtrl 15 Also
13. L 1 IGNALLIST SLCentralControl ValidateCard ValidateCode RegisterEntrance Entrance Unit interface definition IGNAL ChangeSecurityLevel Integer ValidateCardReply Boolean ValidateCodeReply Boolean SIGNALLIST SLEntranceUnit ChangeSecorityLevel ValidateCardReply ValidateCodeReply Card definition YNTYPE Card Integex NDSYNTYPE SYNONYM b NbrOfEntrances Integer 1 dj Code definition EWTYPE CodeType Axray CodelndexType Integer ENDNEWTYPE CodeType BYNTYPE CodelndexType Integer CONSTANTS 1 4 ENDSYNTYPE CodelndexType Figure 736 The UtilityTypespackage 8 In the Organizer create endpoints out of the three packages 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 1 Add an SDL system diagram to the ArchitectureDefinition module in the Organizer and name it AccessControl 2 Copy the class CentralControl in the LogicalArchitecture di agram and paste it as a Block in the system diagram See to it that an implementation link is created at the same time 3 Also copy and paste the class EntranceUnit as a block 4 Change the name of the block instances from Cent ralCont rol to theCentralControl and from EntranceUnit to theEntranceUnit Also define which block type the blocks are an instance of see Figure 737 5 There will often be more than one entrance in
14. ReadCode is a behavior pattern which you will create later see Behavior Pattern Use Cases on page 3883 7 Save the diagram 8 Inthe 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 require ments use case model Name the link Implementation Link July 2003 Telelogic Tau 4 5 User s Manual 3881 Chapter 78 SOMT Tutorial 3882 The created MSC should look like in Figure 728 MSC Enter_Office_With_Card_And_Code_SysA Employee EntranceUnit CentralControl ReadCard ValidateCard g gt exc No_Connection ValidateCardReply a gt exc Invalid_Card Display _ Enter Code 4 s ReadCode ValidateCode ValidateCodeReply cr L exc Wrong_Code Display Please enter exc Door_Not_Opened DoorTimer 10 Open Close Display Enter card Figure 728 A system analysis MSC use case Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis 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 be cause that would take too much time Behavior Pattern Use Cases A behavior pattern is a detailed use case that m
15. Tutorial Block Type EntrancelInterface fre oe AN tw PASA E 4 G1 ReadCard ReadDigity PressExit Display ToCr et theCardreaderInterface 1 1 Resco CardreaderInterface FrCr G2 Tokp P G1 ReaaDigit theKeypadInterface 1 1 ne KeypadInterface G2 e Entry theDisplayInterface 1 1 Pay DisplayInterface G3 1 xt G3 EnvDisplay Figure 747 The complete structure of the block type Entrancelnterface 3916 Telelogic Tau 4 5 User s Manual July 2003 Performing the Object Design 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 e Select a subset of use cases which describe the most common inter action sequences Create a basic version of the processes that corre spond to these use cases e 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 e Continue with introducing more use cases Edit the processes to cover these until the behavior of the objects correspond to the com plete
16. a building and there fore you should define the block theEntranceUnit as a block in stance set Use the variable NbrofEntrances defined in the UtilityTypesPackage Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Design The two blocks theCentralControl and theEntranceUnit must be able to communicate with each other as well as with the environ ment The next step is to create all necessary channels in the system diagram Draw the channels through which the blocks communicate and name them and the gates with suitable names Also draw the chan nels to from the environment State which signals that run on a cer tain 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 en vironment i e to the display hardware This signal contains infor mation that is to be read by persons in the system environment The parameter of this signal is Charstring Define it in the EntranceUnit Package 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 737 Save the diagram giving it the name accesscontrol ssy Telelogic Tau 4 5 User s Manual 3899 Chapter 78 SOMT Tutorial 3900 USE CentralControlPackagPs USE EntyanceUnitPackage USE UtilityTypesPa
17. all axes 3 Save the MSC diagram giving it the name Enter Office With Card And Code msc July 2003 Telelogic Tau 4 5 User s Manual 3857 Chapter 78 3858 SOMT Tutorial MSC Enter_office_With_Card_and_Code Employee AC System Readcard exc No_Connect ion exc Keystroke_Timeout ReadDigit exc Keystroke_Timeout N ReadDigit a exc Keystroke_Timeout N ReadDigit exc Keystroke _Timeout SEEN Oooo d exc Wrong_Code Unlock exc Door_Not_Opened Door Timer 10 il aerial Receiveclose Display Ente Figure 715 An MSC example Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements Create a new module in the Requirements Documents chapter in the Organizer Name the module Msc_Exceptions_ReqgA Add a new MSC document to the newly created module in the Or ganizer and name the document Exc_Invalid_ Card In the MSC Editor try to create the exception i e describe what happens when an employee has entered an invalid card Save the diagram giving it the name Exc_Invalid Card msc MSC Exc_Invalid_Card Employee AC System Display Invalid card DisplayTimer 3 Display Enter card Figure 716 An MSC exception example In the Organizer view select the MSC Exc_Invalid_Card and then choose Associate in the Edit menu The Associate dialog ap pears Choose to associate the
18. copy and paste the SecurityLevel class and its subclasses Classes in the requirements object model that only exist outside the sys tem 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 e the requirements object model e interfaces that the system will have to the environment e use cases When you intend to transfer objects from the requirements object model to the analysis object model consider the following to validate each re quirements object e Decide if the system needs information about the object to fulfill its task e Ifthe answer is yes then add the class to the analysis object model Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Analysis 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
19. displays Enter card Postconditions The door is closed and locked again Description An employee enters a card into the card reader The dis play displays Enter code The employee enters a code consisting of four digits using the keypad The door is unlocked and Please enter is displayed The employee opens the door enters the office and closes the door again The door is locked and Enter card is displayed Exceptions If the employee enters an invalid or unregistered card Invalid card is displayed for three seconds and then Enter card is displayed If the time between consequent keystrokes when typing the code ex ceeds three seconds everything is interrupted and Enter card is dis played If the employee types the wrong code Wrong code is displayed for three seconds and then Enter card is displayed If the employee does not open the door within ten seconds after it has been unlocked the door is locked again and Enter card is displayed If there is no connection between the entrance and the central control ler and a card is entered then the text Connection failure is displayed for three seconds and then Enter card is displayed again Creating an MSC Use Case The second notation for use cases used in SOMT is MSCs Creating MSCs for all the use cases and their exceptions takes too much time in this tutorial Therefore you will concentrate on th
20. for ten seconds and the employee may enter In case of an invalid or unregistered card access to the office is not allowed In case of an incorrect code the employee is informed of this and must try again by entering the card into the card reader and retyping the personal code The Access Control system must read its data consisting of card num bers with their corresponding personal code from a database The data base is managed by using a separate management system that is not de veloped within the project The system operator who is running the management system is authorized to register new employees cards and codes to change a code if the employee wishes so to delete employees from the database and to change the security level of an entrance The system operator is also responsible for initializing the Access Control system All the actions mentioned above are done using the manage ment system The system must be able to recover from computer and connection fail ures If a connection between an entrance and the central controller is lost the door is locked from the outside not permitting anyone to enter i e security level four is set It is however possible to open the door from the inside by means of the exit button The system must be extensible to include new functions and be easily maintained Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements Creating Textual Endpoints Now
21. have gained knowledge about how to apply the SOMT method on a development process Note Platform differences This tutorial and the others that are possible to run on both the UNIX and Windows platform are described in a way common to both platforms In case there are differences between the platforms this is indicated by texts like on UNIX Windows only etc When such platform indicators are found please pay attention only to the instructions for the platform you are running on Normally screen shots will only be shown for one of the platforms provided they contain the same information for both platforms This means that the layout and appearance of screen shots may differ slightly from what you see when running Telelogic Tau on your platform Only if a screen shot differ in an important aspect between the platforms two separate screen shots will be shown 3836 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Introduction Required Skills Itis assumed that you have a basic knowledge about UML and SDL We also recommend newcomers to acquaint themselves with the basic fea tures of the SDL suite tools You can do this by practising on the exer cises in the tutorials provided for the different tools Please see the pre vious chapters in this volume It is recommended that you have read the SOMT Methodology Guide lines starting in chapter 69 in the User s Manual Preparations 1 Make a new empty direc
22. newly cre ated and the link file has not been saved yet the background of the endpoints is painted gray 8 Save the link file from the File menu giving it the name Links s1li 9 Close the Link Manager window Telelogic Tau 4 5 User s Manual 3847 Chapter 78 SOMT Tutorial 3848 Creating the Data Dictionary A data dictionary is a textual document which should define all impor tant concepts found during the whole development process It forms a common vocabulary for the members of the project It is a good idea to e Provide each item included in the data dictionary with a name and a brief explanation e Categorize the concepts in nouns verb phrases and relation phrases e Sort the concepts alphabetically e Have a section in the data dictionary for each activity This might be a good idea because a certain concept often has different meanings in different activities For example a concept can be described by a class in one activity and in the next activity it might be described by a block with a corresponding process All the important objects relations and verbs that you find in the textual requirements should be included in the data dictionary This has already been done in an existing DataDictionary file so you do not have to do anything Just add the existing file 1 Add the existing DataDictionary txt file to the DataDictionaryModel module in the Organizer The Text Editor will show the DataDictionary 2
23. the system analysis use cases The messages can often be considered as operations in the analysis object model A message re ceived by an instance in an MSC corresponds to an operation on the cor responding 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 itis 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 anew object model diagram to the Organizer in the module AnalysisObjectModel Name the diagram InformationDiagran 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 Informat ionDiagram 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 727 when you are finished July 2003 Telelogic Tau 4 5 User s Manual 3879 Chapter 78 SOMT Tutorial 3880 InformationDiagram Figure 727 The Information diagram Creating the Analysis Use Case Mo
24. types as endpoints and create links between them and the corresponding classes in the logical architecture Al ternatively use the Copy Paste As mechanism Now edit the DisplayInterface process type to make it more general and suitable for reuse 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 vari ables 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 Telelogic Tau 4 5 User s Manual 3933 Chapter 78 SOMT Tutorial 3934 9 Exit Dispi Entry i Process Type Displaylnterface 1 2 friMeER pet Display Timer 3 Msg MessageType Ce lEnterCard lEnterCode DoortsOpen DoorisLocked nvalidCard ongCode Enter card CocleTime Out Connection Failure Charstring Delay Code Time Out it Display Tm Display RESET t_for_sign Display Timer A ifor sonh KO Scud EntCde Door Opn DoorLocked InvCard WrngCde CdeTiOut ConnFail EnvDisplay EnvDisplay
25. 44 e To create a textual use case e Tocreate an MSC use case out of a textual use case e To make a requirements object model e To connect important concepts in the different documents with im plinks e To perform consistency checks Introduction to the Exercise In this exercise you will perform the tasks associated with the require ments analysis activity The purpose of the requirements analysis is to e Gain understanding of the problem domain the Access Control system and the environment in which it is going to exist e Find and understand all requirements imposed on the Access Con trol system Producing a complete requirements analysis would take too much time in this tutorial Therefore you will only perform parts of every required step of the process The result will not be a complete requirements structure but you will have acquired knowledge of how to use the SOMT method in the pro cess of identifying requirements Preparing the Exercise You can use your own document structure from the previous exercise just move your accesscontrol sdt file to the RegA directory or use a provided solution 1 Open the system file somttutorial RegA accesscontrol sdt on UNIX or somttutorial reqa accesscontrol sdt in Win dows 2 Check that the Source directory is set to somttutorial RegA on UNIX or somttutorial rega in Windows in the same way as you did in the preparation to this tutorial see Prep
26. Chapter TS SOMT Tutorial This tutorial is intended to present how to combine object oriented analysis and SDL design in practise in a development process This is a method developed by Telelogic known as the SOMT method SDL oriented Object Modeling Technique We will demonstrate using an Access Control system as example the various activities and models in SOMT together with the pro vided tool support for SOMT in Telelogic Tau Through the tutorial you will practise on various exercises that will get you familiar with the SDL suite tools as well as the SOMT meth od July 2003 Telelogic Tau 4 5 User s Manual 3835 Chapter 78 SOMT Tutorial Introduction Purpose of This Tutorial This tutorial presents how to use the SOMT method and Telelogic Tau in practise in a design process The working example is an Access Control system The system shall control the entrances to an office Each employee working in the office has a card and a personal code To enter the office the employee enters a card into a card reader and types a personal code on a keypad To exit the office the employee presses an exit button You will perform the development process for the Access Control sys tem applying the SOMT method The tutorial will guide you through the development process step by step presenting a number of hands on exercises for you to perform The tutorial is expected to be read sequen tially After reading the tutorial you should
27. In system design we continue with the use of use cases this time to de fine 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 the DoorUnit The use cases will consist of the block instances theCentral Control 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 def inition Also the level of detail must be precise enough to make the de sign use cases act as detailed test specifications 3906 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Design Formalizing Use Cases A number of things have to be done when formalizing and refining anal ysis 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 inter face between the blocks in the system and thus all blocks have to be represented The MSC instances corresponding to actors in the system environ ment should have env_ stated in their instance head before the ac tual name e g env_Employee The MSC instances must have names corresponding to block in stances as it is the instances that communicate That i
28. N Code hardware ete Figure 732 Overview of the SOMT process What You Will Learn To create a design module structure To make formalized testable use cases Telelogic Tau 4 5 User s Manual To define the static interfaces in packages To make an architecture definition of the system To use the Paste As mechanism when transferring from the system analysis activity to the system design activity 3889 Chapter 78 SOMT Tutorial 3890 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 ex ercise 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 pro vides information about the static structure and is useful when structur ing the system into units The latter provides information about the dy namic structure and is useful for the definition of the interfaces between the units Major tasks to perform in the system design are e Define the design module structure e Define the static interfaces
29. Read through the document to get yourself acquainted with the problem domain vocabulary All nouns relation phrases and verb phrases in the data dictionary are marked as link endpoints This has been done to make it possible to do entity matches between any model and the data dictionary An entity match checks that all entities in one model have matching entities in an other model That is we can check that all entities in a model really are described in the data dictionary This will be performed in Entity Match on page 3865 The example below shows a part of the requirements analysis data dic tionary Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements Example 608 A data dictionary Nouns Objects Access control system A system to control the access rights to an of fice so that no unauthorized persons can enter without permission Card Each employee working in the office gets a card and a corre sponding personal code By means of this card and code the employee can get access to the office Cardnumber The number that uniquely defines a card Relation Phrases Card with code Each employee in the office has a card with a personal code Connection between central controller and entrance There is a connec tion between every entrance and the central controller Verb Phrases Change code An operation done by the system operator to change the code of a card Change Security Leve
30. 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 in troduce 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 EntranceUnit Package is EntranceCtrl 1 Copy the class DisplayInterface in the LogicalArchitecture diagram 2 Paste it as a block type and as a text symbol with SDL interface in the EntranceUnitPackage 3 Rename the block type and give it the name EntranceInterface 4 Add a signal parameter called MessageType to the Display signal definition By using this type for messages the Ent ranceCtr1 does not have to handle strings This solution makes the system indepen dent of the language used see Performing an Iteration on page 3928 for an example on how this works 5 Define the NEWTYPE MessageType see Figure 739 6 Also paste the class DisplayInterface as a block in the EntranceUnit block diagram Rename the block and give it the name theEntranceInterface EntranceInterface 7 Using the Entity Dictionary create implementation links between the CardReaderInterface KeypadInterface and ExitButtonInterface classes in the LogicalArchitecture diagram and the Ent ranceInterface block type and block Note that you do not ha
31. Unit 1 1 ica tata Y 1 ty EunitToCC CCToEunit i i essscescss J ValidateCard ValidateCardReply ValidateCode ValidateCodeReply RegisterEntrance ChangeSecurityLevel Ol Il theEntranceCtrl EntranceCtrl EuToD ulovu Il 0l Il 0i its RecetveCard A Unlock ReceiveCode ReceivePressExit Js EQToEI EIT EC sy Display G1 A nyToEunit DuToEu EnvToDunit the mieria theDoorUnit ReadCard ReadCard eSnirenceinterace ReceiveOpen DoorUnit ReadDigi ReadDigit Entrancelnterface ReceiveClose G2 Open PressExit PressExit G3 Close Open Close EIToEny yY ExwDisplay EnvDisplay Figure 741 The complete structure of the block Type EntranceUnit When you have completed the architecture definition the System Design Documents chapter should look like in Figure 742 G1 July 2003 Telelogic Tau 4 5 User s Manual 3905 Chapter 78 SOMT Tutorial System Design Documents DesignModuleStructure DesignModuleStructure E architecturebefinition CentralControlPackage oS Centralcontrol T EntranceUnitPackage EntranceUnit theDoorUnit DoorUnit xu theEntrancectrl Entrancectrl Door Unit theEntrancelInterface EntranceInterface Entrancectrl EntrancelInter face tilityTy pesPackage ecessControl thecentralcontrol Centralcontrol theEntranceUnit EntranceUnit DesignUseCasemodel Figure 742 The System Design Documents chapter Creating the Design Use Case Model
32. _Card_Door_Not_Opened_SysD Enter_of fice_With_Caord_and_Code_SysD Enter_of fice_With_Caord_aAnd_Code_No_Connection_SysD Enter_of fice_With_Card_aAnd_Code_Invalid_Card_SysD Enter_of fice_With_Card_and_Code_Timeout1_SysD Enter_of fice_With_Card_and_Code_Timeout2_SysD Enter_of fice_With_Cord_and_Code_Timeout3_SysD Enter_of fice_With_Card_aAnd_Code_Timeout4_SysD Enter_of fice_With_Card_aAnd_Code_wWrong_Code_SysD Enter_of fice_With_Card_and_Code_Door_Not_Opened_SysD Exit_office_SysD Exit_oOf fice_Door_Not_Opened_SysD Change_Security_Level_SysD Figure 743 The entire System Design Documents structure 3910 Telelogic Tau 4 5 User s Manual July 2003 Performing the Object Design Performing the Object Design July 2003 Object Design Textual requirements model text Requirements object model class diagram Requirements use case model Requirements i textMSC Foalysis Foalysis object model Foalysis use case model Data dictionary System class diagram textMSC Foalysis System design use ona System model SDL Design veg sii Object design model SDL Implementation ZA Code hardware ete Figure 744 Overview of the SOMT process 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
33. age and draw the associations Your diagram should now look like in Figure 733 6 Create endpoints out of the three packages Endpoints are not cre ated automatically for object instance symbols 7 Save the diagram giving it the name designmodulestructure som DesignModuleStructure Figure 733 The Design Module Structure 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 anal ysis 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 on page 3893 The UtilityTypesPackage will contain data type declarations that are common to the subsystems of the system Signals remote procedures that make up the interface be tween the subsystems will also be defined in the UtilityTypesPackage The other two packages CentralControl Package and EntranceUnit Package will contain block types and the signals remote procedures that make up the inter face to the particular block If you have many signals it is often useful to structure these into signal lists Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Design The basic mechanism used in SOMT when going from analysis to de sign is the P
34. ant concepts in the textual use cases are de scribed in the data dictionary and in the use case list Important con cepts in a textual use case are the actors and the use case name The actors should be described in the data dictionary and in the actors list The use case name should be described in the use case list In this case the from group will be the textual use case Enter Office With Card And Code and the to group will be the DataDictionary the ActorsList and the Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements UseCaseList You can select any number of individual docu ments in the list not only modules The result shows that the use case name was found in the UseCaseList and that the actors were described both in the data dictionary and in the list of actors e Check that all actors in the use cases are modeled in the context di agram and vice versa First the Actorslist will form the from group and the Context Diagram will form the to group then we will do an other entity match with the groups vice versa Creating Implinks Now that we know that all our models are consistent it is time to add the implinks Implinks are used to enable traceability between the mod els We will start with creating implinks from the concepts in the textual re quirements to the requirements object model in particular the logical structure diagram 1 Open the Link Manage
35. arations on page 3837 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements Studying the Textual Requirements Including External Textual Requirements A textual document with requirements is the input to the Access Control system development project and it will form the base from which the Access Control system is developed You will later on create implemen tation links so called implinks between the textual requirements docu ment and other models This is done to make it possible to follow a re quirement through a number of models all the way down to code The textual requirements document of the Access Control system is contained in a text file This file should now be included in the Organiz er work area 1 Select the module named TextualRequirementsModel in the Requirements Documents chapter 2 Select the Add Existing command in the Edit menu 3 Inthe Add Existing dialog change the filter to txt and press the Filter button Select the file TextualRequirements txt and press OK to add it 4 The TextualRequirements document is now added to the module TextualRequirementsModel in the Organizer and the Text Editor showing the document is opened The document looks like Example 607 Example 607 The textual requirements The task is to design the software to support a computerized Access Control system The purpose of the system is to control the accesses to an office An
36. ard Karte bitte EnterCode Geheimnummer bitte DoorlsOpen Tur geoeffnet DoorlsLocked Tur geschlossen InvalidCard Karte nicht registriert WrongCode Falche Eingabe CodeTimeOut Zeit abgelaufen GonnectionFailure Kein Computer Kontakt ait_for_signal Figure 756 The process type GermanDisplayInterface 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 1 Open the block type EntranceInterface 2 Select the process theDisplayInterface and change the text theDisplayInterface 1 1 DisplayInterface to theDisplayInterface 1 1 GermanDisplayInterface 3 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 on page 3922 July 2003 Telelogic Tau 4 5 User s Manual 3935 Chapter 78 SOMT Tutorial 3936 Block Type Entrancelnterface 1 1 Ieee Oe oN i 1 G1 ReadCard ReadDig t PressExit E ToCr G1 ntry theCardreaderlnterface 1 1 Readcard Cardreaderinterface ey G2 FrOr Exit ReceiveCard ToKp G1 ntry ReadDigit theKeypadinterface 1 1 Erk Keypadinterface G2 mel Exit ReceiveCode G1 HOP ntry PressExit theExitB
37. are described in the analysis object model or in the list of actors July 2003 Telelogic Tau 4 5 User s Manual 3887 Chapter 78 SOMT Tutorial Summary After having completed an entire system analysis the System Analysis Document chapter would look like in Figure 731 System Analysis Documents AnalysisUseCasemodel Enter Office With Card And Code SysA ji Behavior_Pattern_ReadCode Exc_Invalid_Card_Sysa Exc_Keystroke_Timeodut_Sysa Exc_Door_Not_Opened_Sysa k ma Change Security_Level SysA E Analysisob jectModel B InformationDiagram L LogicalArchitecture BehaviorPatterns Behavior Pattern ReadCode fm dim MSC_Exceptions_Sysa Exe_No Connection SysA T Exe Invalid Card SysA Exe_ Door Not_Opened_ SysA Exe Keystroke TimeOut_SysA Exe Wrong Code SysA Figure 731 The entire system analysis document structure 3888 Telelogic Tau 4 5 User s Manual July 2003 Performing the System Design Performing the System Design July 2003 Requirements Foalysis System Foalysis Design System Object Design Implementation Textual requirements model text Requirements object model class diagram Requirements use case model textMSC Foalysis object model System design model SDL class diagram Foalysis use case model textMSC Data dictionary Design use case model MSC TTC
38. aste As mechanism This is used here when defining the sig nal 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 de fine the system by means of SDL block diagrams see Creating the SDL System Diagram on page 3898 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 mecha nism 1 Add three new SDL packages to the ArchitectureDefinition module in the Organizer and name them according to the modules in the design module structure 2 Open the LogicalArchitecture diagram in the AnalysisObjectModel module 3 Select the class Centralcontrol and copy it 4 Go to the SDL Editor and the centralControlPackage diagram and choose Paste As The Paste As dialog is opened 5 Paste the class CcentralCcontrol 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 6 Copy and paste the class EntranceUnit as a block type in the EntranceUnit Package in a similar way Mapping Object Models to SDL Interface Definitions Now it is time to design the interfaces of the newly pasted blocks Inter face definitions in SDL are defined using signals and or remote proce du
39. ay 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 under stand 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 lev el With the help of behavior patterns we can describe what really hap pens 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 be havior 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 Inthe MSC Editor create the behavior pattern ReadCode see Figure 729 3 Save the diagram using the name Behavior Pattern _ReadCode 4 Inthe 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 July 2003 Telelogic Tau 4 5 User s Manua
40. block type symbol in the Ent ranceUnit Package Press OK in the Edit dialog In the Add Page dialog choose to create a process interaction page 3 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 Telelogic Tau 4 5 User s Manual 3913 Chapter 78 SOMT Tutorial 4 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 If the Remove Reference Symbol dialog appears just click OK 5 Change the other three process names too according to the above Now the block type EntranceInterface should contain four process es named theCardreaderInterface theKeyPadInterface theExitButtonInterface and theDisplayInterface Block Type Entrancelnterface Los th th i ey Lecce 3 P theCardreaderInterface 1 1 CardreaderInterface theKeypadInterface 1 1 KeypadInterface theExitButtonInterface 1 1 Ex
41. bly 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 architec ture 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 tex tual requirements via the object models to the design Try this July 2003 Telelogic Tau 4 5 User s Manual 3909 Chapter 78 SOMT Tutorial Summary After having completed an entire system design the corresponding doc ument structure in the Organizer would look like in Figure 743 System Design Documents DesignModuleStructure DesignModuleStructure ArchitectureDefinition 1 CentralcontrolPackage CO Centralcontrol T EntranceUnitPackage EntranceuUnit theDoorUnit DoorUnit theEntrancectrl Entrancectrl theEntrancelInterface EntrancelInterface CO EntrancelInter face CO DoorUnit CO Entrancectrl UtilityTypesPackage AccessControl xty theEntranceUnit EntranceUnit thecentralcontrol Centralcontrol signUseCaseModel Enter_of fice_With_Card_SysD Enter_of fice_With_Card_No_Connection_SysD Enter_of fice_With_Card_Invalid_Card_SysD Enter_of fice_With
42. ced in the appropriate system or block diagram to form the system Mapping Classes to Block Types and Signal Interfaces 1 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 There fore 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 1 EntranceUnit block type Double click on the EntranceUnit block type in the EntranceUnit Package 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 Telelogic Tau 4 5 User s Manual 3901 Chapter 78 SOMT Tutorial 3902 3 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 EntranceUnit Package
43. ckage System AccessControl G3 ManSysToCc theCentralControl Changesysternsecenity CentralControl G2 CcToEu ValidateCodeReply ChangeSecurityLevel ValidateCardReply ValidateCard ValidateCode RegisterEntrance WV G3 G2 theEntranceUnit NbrOfEntrances Entrance Unit EUToEnyv Gi G4 ExwDisplay Figure 737 The Access Control system diagram EnvToEu ReadCard ReadDigit PressExit Open Close 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 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Design Assembly Paste As a Assembly Part1 Part2 Figure 738 Mapping aggregation to a block type The process types and block types should be placed in a suitable pack age to enable reuse The instances of the types should then be pla
44. created are saved by default and from where to read when opening and converting documents Since there are multiple versions of the Access Control system each version with diagrams stored on files with identical names but in different directories omitting to specify the source directory may cause the wrong ver sion of a file to be opened 6 In the Set Directories dialog that is opened select the third radio button associated with Source directory In the text field enter the complete path and name of yourown somttutorial directory if it is not there already Press OK to close the dialog You do not have to change any of the other options in this dialog Preparing the Documentation Structure 3838 What You Will Learn e To prepare aSOMT project by making preparations in the Organiz er Introduction to the Exercise Your task is to modify the basic view of the Organizer to get the desired document structure The result of the exercise will be an Organizer structure containing a number of chapters and modules see Figure 713 on page 3842 The chapters will correspond to the different activities in SOMT and the modules will correspond to the models in each activity Deleting Unwanted Chapters When you start a new project with Telelogic Tau you will get the default basic Organizer view see Figure 711 This view could be different if you do not have the default preferences set The Organizer contains a few black line
45. del 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 mod els 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 e Refined requirements use cases e Behavior pattern use cases 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 iden tifying 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 sub system in the analysis object model The level of abstraction you choose is a trade off between detail and clarity Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis An object which encapsulates
46. documents and diagrams from one particular activity You will have to add four chapters and they will be named Requirements Documents System Analysis Documents System Design Documents and Object Design Documents respec tively First add the Requirements Documents chapter 1 Select the Add New command in the Edit menu The Add New dia log arises with the Organizer radio button set 2 Select the Chapter option in the option menu connected to the Or ganizer radio button 3 Change the document name Untitled to Requirements Documents 4 Press the OK button or lt Return gt A chapter named Requirements Documents will appear as the uppermost chapter object 5 Now repeat the steps above and add the three remaining chapters and name them System Analysis Documents System Design Documents and Object Design Documents respectively If the chapters show up in another order than the one you want in the Organizer window you may move a selected chapter by using the arrow quick buttons in the tool bar 6 Ifneeded move the chapters in the Organizer to get a structure cor responding to the one in Figure 712 3840 Telelogic Tau 4 5 User s Manual July 2003 Preparing the Documentation Structure 9 Organizer OF x File Edit View Generate Tools Help Saj S le zal zll Ml ltt a ele 2 mv C TelelogicTaud40 workisomttutorial Requirements Documents System Analysis Documents System Design Docume
47. e use case correspond ing to the textual description you just created Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements Enter Office With _Card_And_Code and one of its exceptions when an employee enters an invalid card 1 Select the module Requirement sUseCaseModel and choose Add New In the Add New dialog set the MSC radio button Name the document Enter Office With Card And Code and set the Show in Editor toggle button 2 Inthe MSC Editor try to create the MSC Look at the textual de scription of the use case and describe it by means of the notations defined for MSCs Also make references to exceptions at the points where these can occur Figure 715 shows an example of the com plete MSC Each actor should be represented by a separate instance The Access Control system itself should also be represented by a separate instance Actions displayed messages etc should be drawn as MSC messages between the instances An exception is drawn by adding an MSC reference symbol lo cated last in the MSC Editor s symbol menu An MSC reference symbol is a reference to another MSC described in a separate MSC diagram The symbol is added to one of the instance axes By convention MSC exceptions are named exc followed by the name of the exception To connect the symbol to all three ax es select Connect from the Edit menu Press the Global button to connect the reference symbol to
48. eing used by our system and therefore should be added to the list The third actor the door may not be so easy to find at a first glance but when you have created the MSCs it will be come more evident that the door is an actor as well The door s interac tion with the system consists of notifying the system every time it is opened or closed The example below shows a part of the list of actors Example 609 Part of a list of Actors Employee Someone who needs to enter and exit the office To enter the office an employee must have a registered card and depending on the current security level a corresponding personal code To exit the employee must press an exit button to unlock the door ManagementSystem The management system starts and maintains the Access Control system All changes to the database are handled by the management system The management system is run by a system oper ator Creating a List of Use Cases When you have defined the set of actors it is time to describe the way they interact with the system which is done in use cases The first step is to create a list of all use cases The list of use cases should list the use cases by name together with a short description 1 Add a new plain text document in the Requirement sUseCaseModel module Name it UseCaseList and set the toggle button Show in Editor Press OK 2 Try to find the normal use cases and list them in the newly created textual document For i
49. entrance leading to an office can have four different security levels Always unlocked Requires a card to unlock Requires a card as well as a code to unlock Always locked PTUS The security levels of an office entrance can be altered during the day Each employee working in the office has a card with a personal code consisting of four digits To open a door with security level three the Telelogic Tau 4 5 User s Manual 3845 Chapter 78 SOMT Tutorial 3846 employee enters her card into a card reader and types her personal code on a keypad The time between consecutive keystrokes when typing the code is not allowed to exceed three seconds To enter through a door with security level two the employee just enters her card into a card reader Each entrance leading into the office consists of a door with an electric lock as well as a card reader a keypad and a display on the outside and an exit button on the inside The employee needs a card and a code to enter the office To exit the employee just presses the exit button and the door is unlocked for ten seconds All entrances communicate directly with a central controller which makes sure that a validation of the correctness of cards and codes is per formed The controller has access to a database consisting of all card numbers and their corresponding personal codes If the card is valid and in case of security level three the corresponding code correct the door is unlocked
50. epts of the real world that are of importance for the application we intend to build There are dif ferent types of concepts that can be described in this model The two major diagram types show the logical structure of the data and informa tion and the context of the system Relations between objects in the model will be expressed through asso ciations aggregations and inheritance Creating a Requirements Object Model Now you should create the requirements object model 1 In the Organizer select the Requirement sObjectModel module and choose Add New In the Add New dialog set the UML radio but ton and make sure the Object Model option in the UML option menu is set Name the new document LogicalStructure and set the toggle button Show in Editor This will pop up an empty OM Editor window 2 Try to find the objects see Identifying the Objects on page 3863 3 Enter the classes found into the object model diagram in the OM Ed itor and give them a suitable name As you can see every class is automatically marked as an endpoint 4 Relate the classes by means of associations aggregations and inher itance see Identifying the Relations on page 3864 5 Consider if multiplicity is needed on any of the associations and if so add it Double click a line to bring up the Line Details dialog 6 To increase the readability of the model name the associations or attach role names to the classes The diagram shou
51. et the entity match radio button Note that you have to be in en tity mode to be able to perform an entity match 2 Let the packages in the ArchitectureDefinition form the from group and the DesignModuleStructure module the to group Telelogic Tau 4 5 User s Manual July 2003 Performing the System Design 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 1 Once more choose Consistency Check in the Tools menu and per form 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 2 Let the AnalysisObjectModel form the from group and the ArchitectureDef inition 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 proba
52. h concurrency and distri bution into account It is also possible to verify requirements specified in MSCs using the Validator The MSC diagrams may with no or little effort be used directly as in put to the Validator 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 1 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 2 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 re spond 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 1 Select the system AccessControl in the Organizer 2 Choose the Make option in the Generate menu 3 In the Make dialog choose the code gene
53. hat we can trace a design decision back wards to requirements through either object models or use case models Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements Summary After having completed an entire requirements analysis the Requirements Document chapter the Organizer view should look like in Figure 724 Requirements Documents TextualRequirementsModel TextualRequirements DataDictionaryModel DataDictionary txt E RequirementsUseCasemModel ActorsList UseCaseList Enter _Of fice_With_Card_And_Code Enter_of fice_With_Card_And_Code i Exc _Door_Not_Opened Exc_Invalid_Card i Exc_Keystroke_Timedut Exc_No_Connection Fi Exc Wrong Code Enter_Of fice_With_Card 2 Enter_office_With_card Exc_Door_Not_Opened Exc_Invalid_card Exc_No_Connection Exit_office P Exit_office eri Exc _Door_Not_Opened change_Security_Level Change_Security_Llevel RequirementsObjectModel LogicalStructure ContextDiagram E MSc_Exceptions Exc_No_Connection Exc_Invalid_card Exc_Door_Not_Opened Exc_Keystroke_Timedut Exc_Wrong_Code Figure 724 The entire requirements analysis document structure July 2003 Telelogic Tau 4 5 User s Manual 3869 Chapter 78 SOMT Tutorial Performing the System Analysis Textual requirements model text Requirements use case model textMiSC Requirements object model Requirements i class diagram Foalysis
54. he EntranceUnitPackage 6 Go back to the LogicalArchitecture diagram and copy the class CentralControl 7 Paste it as a text symbol with SDL interface in the CentralControlPackage Telelogic Tau 4 5 User s Manual July 2003 Performing the System Design July 2003 8 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 def inition Add a signal parameter of the type integer to the ChangeSystemSecurity signal see Figure 735 10 Save the diagram giving it the name centralcontrolpackage sun Package CentralControlPackage SIGNAL ChangeSystemSecority Integer SIGN ALLIST SLCentralControl ChangeSystemSecurity CentralControl Figure 735 The CentralControlPackage 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 1 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 signa
55. he list of use cases and of the actors involved in the use case Save the document giving it the name Enter Office With Card And Code txt Describing a Textual Use Case A textual use case should consists of the following fields Name The name of the use case Actors A list of the actors involved in the use case Preconditions A list of properties that must be true for this use case to take place Postconditions A list of properties that are true when the use case is finished Description A textual description of the normal sequence of events that describe the interaction between the actors and the system Exceptions A list of exceptional interactions that complement the normal flow of events described in the Description field If an ex ception leads to different postcondition properties compared to the normal sequence this should be noted The description field should thus describe what happens when every thing is going as expected No exceptions should be considered here They are not described until the exceptions field The example below shows a textual description of the use case Enter office with card and code Telelogic Tau 4 5 User s Manual 3855 Chapter 78 SOMT Tutorial 3856 Example 611 A Textual Use Case Use case name Enter_Office_With_Card_And_Code Actor Employee door Preconditions System is initialized security level three is set and the door is closed and locked The display
56. hrough a door with security level two Enter_Office_With_Card_And_Code Describes the interaction be tween an employee and the Access Control system when the em ployee wants to enter the office through a door with security level three Exit_Office Describes the interaction between an employee and the Access Control system when the employee wants to exit the of fice Exceptional Cases Exc_No_Connection Exc_Invalid_Card Creating a Textual Use Case Now that we have a list of the actors to the system as well as a list of use cases we can Start to create a more detailed description of the use cases A textual use case consists essentially of natural text structured into a number of text fields see Describing a Textual Use Case on page 3855 In this exercise we will only create one textual use case as creat ing them all takes too much time The use case we will focus on Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements throughout the rest of the tutorial is the one where an employee enters an office with both a card and a code 1 Add a new textual document in the Requirement sUseCaseModel module and name it Enter Office With Card And Code Try to create the textual use case consisting of the fields described in Describing a Textual Use Case on page 3855 Create endpoints of the textual use case name for consistency use exactly the same name as you used in t
57. ial activity but it is not You will probably not first add all the necessary classes then the rela tions 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 anew object model diagram and name it LogicalArchitecture 3 Openthe 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 on page 3874 Several of the classes in the requirements object model can be trans ferred as is to the analysis object model The provided Paste As mech anism lets you transfer objects from one model to another while auto Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Analysis matically creating implinks between the objects in the two separate models This mechanism should be used here see below 4 Select the class CentralControl in the LogicalStructure dia gram and choose Copy in the Edit menu 5 Goto the LogicalArchitecture diagram by selec
58. 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 mod ule 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 sys tem 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 in stances 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
59. it is quite easy to see that the system itself is built up of a central control and a number of entrances each having its own local control Therefore Telelogic Tau 4 5 User s Manual 3863 Chapter 78 SOMT Tutorial in the requirements object model we do not model the heart of the sys tem as one class but as two communicating classes Identifying the Relations The information sources when identifying relations between objects are the same as when identifying the objects Look for relation phrases in the textual requirements or use the data dictionary as an information source You may also take a look at each object and ask the questions 1 What services does the object provide 2 Does the object need services from other objects to complete its ser vices If the object needs services from other objects identify these objects and model the relations in the object model There are three different types of relations described below The Association Relation The association relation describes how different classes relate to each other by means of information exchange works for io Figure 720 An Association relation The Aggregation Relation The aggregation relation is a special case of the association relation and it describes a consists of relation For example a document consists of paragraphs Figure 721 An Aggregation relation 3864 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Ide
60. itButtonInterface theDisplayInterface 1 1 DisplayInterface Figure 746 The block type EntranceInterface 3914 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the Object Design 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 struc tures 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 be tween signal routes and channels Now edit the block type EntranceInterface diagram 1 Connect each process with the border of the block with a signal route in each direction 2 Give the gate of the input signal to each process the name Entry and the other gate the name Exit 3 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 4 Connect the signal routes with the channels by specifying the appro priate gate for each signal route Telelogic Tau 4 5 User s Manual 3915 Chapter 78 SOMT
61. l System Analysis Documents AnalysisUseCasemodel AnalysisobjectModel System Design Documents DesignModuleStructure ArchitectureDefinition DesignUseCasemModel Object Design Documents SDL_DesignModel Figure 713 The complete document structure This structure will form the framework to organize the forthcoming documents around 7 Save the Organizer structure and name the file accesscontrol sdt Now you have finished the preparations and you can start to develop the Access Control system using the SOMT method 3842 Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements Identifying the Requirements July 2003 Requirements Foalysis Textual requirements model text Requirements use case model text MSC Requirements object model class diagram Analysis object model Foalysis use case model Data dictionary System class diagram textMSC Foalysis System design use poner System model SDL Design MSC TTCN Object Design Code hardware ete Figure 714 Overview of the SOMT process Implementation What You Will Learn To bring in external requirements documents into the Organizer To identify important concepts To use a data dictionary To identify actors and use cases and to compile the information gained into textual documents Telelogic Tau 4 5 User s Manual 3843 Chapter 78 SOMT Tutorial 38
62. l An operation done by the system operator to alter the security level of an entrance Connection is lost The connection between an entrance and the central controller can sometimes fail In case of broken connection nobody can enter the office It is however possible to leave the office July 2003 Telelogic Tau 4 5 User s Manual 3849 Chapter 78 SOMT Tutorial 3850 Creating the Use Case Model The purpose of a use case model is to capture the requirements and present them from the users point of view thus making it easier for the intended users to validate the correctness of the requirements analysis The use case model consists of e A list of actors e A list of use cases e A number of MSCs message sequence charts and or textual use cases The use case model is also a useful source of information when devel oping the requirements object model see Creating the Requirements Object Model on page 3861 A use case is a sequence of actions showing a possible usage of a sys tem Use cases developed during the requirements analysis activity should mainly concern the interaction between the system and the users of the system No message exchanges within the system should be shown Users of a system may be people other systems or objects outside the system border which interact with the system An actor is a user taking part in a use case An actor is not supposed to be an individual user but rather represen
63. l 3883 Chapter 78 SOMT Tutorial MSC Behavior _Pattern_ReadCode Employee frtranceotr exc Keystroke _Timedut W A ReadDigit exc Keystroke_Time0ut XN A ReadDigit exc Keystroke_Timedut X ReadDigit exc Keystroke_Timedut ReadDigit ReceiveCode Figure 729 A behavior pattern example The System Analysis Documents chapter should now look like in Figure 730 3884 Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis System Analysis Documents E analysisUseCaseModel Enter Office With_Card And_Code_SysA i gt Behavior_Pattern_ReadCode E AnalysisobjectModel InformationDiagram LogiealArchitecture E BehaviorPatterns Behavior Pattern ReadCode Figure 730 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 activ ity We want to be able to check e That all requirements have been implemented e Which system analysis object that implements a certain requirement e Which requirement that is implemented by a certain object in the analysis object model The means to check the issues above is through consistency checks There are two types of consistency checks e Entity matches e Link checks We will start with a link check and then we will perform an entity match Jul
64. l parameters to the three remaining signals Telelogic Tau 4 5 User s Manual 3895 Chapter 78 SOMT Tutorial 3896 5 Continue with copying the class EntranceUnit and paste it as a text symbol with SDL interface in the UtilityTypesPackage 6 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 7 Add the two signals validateCardReply and ValidateCodeRep y to the latest pasted signal definition 8 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 mech anism for pasting something as a SYNTYPE In declaring the data type Code however the Paste As mechanism can be used 1 Declare the card concept as a SYNTYPE in the UtilityTypespackage see Fig
65. ld look some thing like in Figure 718 when you are finished July 2003 Telelogic Tau 4 5 User s Manual 3861 Chapter 78 SOMT Tutorial LogicalStructure 101 a Security_ Security_ Security_ Security_ T Office 4 Works in Employee Has p Card level level level3 level4 y i k f Has y System_ Code Operator r Security_ Entrance Central_ level Has Communicates with Control 4 Maintains Management_ System Communicates with p Maintains v iz Door CardReader Display T keypad Exit_ Data_ Button Base Figure 718 The logical structure 7 Save the diagram giving it the name logicalstructure som 8 Add yet another object model to the Requirement sObjectModel module in the Organizer Name it ContextDiagram 9 Inthe diagram show the system and the external actors interacting with it Use collapsed class symbols select Collapse from the Edit menu The classes are automatically marked as endpoints 10 Clear the endpoint on the Access _Control_System class as we will not need this Select Clear Endpoint from the Link submenu in the Tools menu 11 Save the diagram giving it the name contextdiagram som 3862 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements Con
66. models e analysis object model e analysis use case model These two models should be created in parallel through a number of it erations 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 anal ysis structure with all implinks made July 2003 Telelogic Tau 4 5 User s Manual 3871 Chapter 78 SOMT Tutorial 3872 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 sys tem analysis activity Questions regarding the implementation of the so lution 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 sequent
67. n IGNAL ErcvDisplay Charstring DoorLocked InvCard WrogCde NDNEWTYPE MessageType Figure 739 The Entrance UnitPackage The block type EntranceUnit diagram should now contain three blocks theDoorUnit theEntranceInterface and theEntranceCtrl July 2003 Telelogic Tau 4 5 User s Manual 3903 Chapter 78 SOMT Tutorial Block Type Entrance Unit theDoorUnit DoorUnit theEntranceCtrl EntranceCtrl theEntrancelnterface Entrancelnterface Figure 740 The block Type Defining the Communication Structure Entrance Unit Now you should define the communication structures within the block type theEntranceCtrl thel communicate EntranceInter To define the channels in the block type 1 steps described below EntranceUnit Define the channels needed for the three blocks face and theDoorUnit to EntranceUnit follow the 1 Identify necessary channels 2 Identify the signals that should be carried by the channels You get a lot of information from the AnalysisObjectModel here 3 Name the channels and the gates 4 The complete block diagram for EntranceUnit should look some thing like in Figure 741 3904 Telelogic Tau 4 5 User s Manual July 2003 Performing the System Design ValidateCard ValidateCardReply ValidateCode G2 G3 ValidateCodeReply RegisterEntrance ChangeSecurityLevel gt e Block Type Entrance
68. nformation on how to find use cases see Finding Use Cases on page 3853 3 To each use case add a general one sentence description of its func tionality Telelogic Tau 4 5 User s Manual July 2003 July 2003 Identifying the Requirements 4 For each normal use case examine which exceptions that can occur and state these exceptions as well in the list 5 Mark the use case names in the UseCaseList as endpoints 6 Save the document giving it the name UseCaseList txt Finding Use Cases It is often quite easy to identify use cases by looking at the purpose of the system To verify that you have identified most of the important use cases you should e look at the list of actors and for each actor e identify the tasks that the actor should be able to perform and the tasks which the system needs the actor to perform Each such task is a candidate for a new use case It is often very useful to check the textual requirements document for verb phrases or you could look directly in the DataDictionary to see which verb phrases that have been stated as important these are possible candidates for use cas es Start with the employee actor and try to determine which actions he or she needs to perform There are different ways to enter an office either using a card or using both a card and a code Both ways are obvious can didates for the use case list Also the employee must be able to exit the office this will be ye
69. ning 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 af fected the Display object 1 Study the requirements regarding the Display in the original textu al requirements document You should find that the new require ment does not contradict with the original requirements 2 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 3 With the class still selected choose Traverse Link once more and follow the link to the logical architecture diagram in the analysis ob ject 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 753 Telelogic Tau 4 5 User s Manual 3929 Chapter 78 SOMT Tutorial 3930 PressExit Cardreader_ K Interface Interface eypad_ ExitButton_ Interface Figure PressExit Entrance_ Ctrl Change Security Level Recieve Open RecieveClose RecieveCard Recieve Code Recieve PressExit 753 Part of the Logical Architecture diagram 4 Continue to follow the link of the class DisplayInterface from the logical architecture to the package EntranceUnit Package
70. ntifying the Requirements The Inheritance Relation The inheritance relation describes an is a relation For example a car is a vehicle Vehicle Figure 722 An Inheritance relation Entity Match Now it is time to do some consistency checks between the created mod els When you do an entity match you check that all entities in one mod el have matching entities in another model 1 Open the Link Manager The window popping up shows all end points from the models you have created during the requirements analysis activity To be able to perform an entity match you must be in entity mode i e not in endpoint mode Press the Show endpoints or entities button in the Tool bar to change to entity mode The view in the Link Manager window will look just the same since one entity cor responds to exactly one endpoint in all our models The first thing we will check is that all important concepts in the textual requirements model are described in the data dictionary 3 Choose Consistency Check in the Tools menu The Consistency Check dialog appears and you are asked to choose between a link check and an entity match Set the entity match radio button and press Continue A new dialog appears and you are asked to select the documents representing the from group Select the TextualRequirementsModel module and press Continue As you can see the text document in the module is also selected when you select the module
71. nts Object Design Documents Figure 712 The Chapter structure Adding the Organizer Modules The next step to take when preparing the document structure is to add the Organizer modules A module in the Organizer forms a naming scope around the documents it contains It may contain any kind of doc uments As each activity in SOMT consists of a number of models it seems nat ural to let a model correspond to a module in the corresponding chapter You should now add the modules to the chapters in the Organizer struc ture 1 Select the chapter named Requirements Documents 2 Select the Add New command in the Edit menu 3 Inthe Add New dialog make sure that the Organizer radio button is set Select the Module option in the Organizer option menu 4 Change the name Untitled to RequirementsUseCaseModel Note You are not allowed to have any space characters in the name of a module July 2003 Telelogic Tau 4 5 User s Manual 3841 Chapter 78 SOMT Tutorial 5 Press the OK button A module named Requirement sUseCaseModel appears in the Requirements Documents chapter 6 Now add the other modules to their respective chapter in the Orga nizer view Let each model in a SOMT activity have its own mod ule The document structure in the Organizer should look like Figure 713 when you are finished Requirements Documents TextualRequirementsModel DataDictionaryModel RequirementsUseCaseModel Requirementsob jectMode
72. o each other from requirements to de sign as can be seen in the view of the link file in the Link Manager win dow Telelogic Tau 4 5 User s Manual 3925 Chapter 78 SOMT Tutorial Summary After having completed an entire object design the corresponding doc ument structure in the Organizer would look like in Figure 751 Object Design Documents SDL_Des ignModel fy UtilituTupesPackage EntranceUnitPackage EntranceiInter face beryl theCardreaderInterface 1 1 Cardreader Interface Q theDisploayInterfoce 1 1 DisployInter face sry theExitButtonInterface 1 1 ExitButtonInter face id thekeypadiInterfoce 1 1 KeypadInter face Entrancectr1 xid theEntrancecontrol 1 1 Entrancectrl DoorUnit xd theDoorLockInterface 1 1 DoorLockInterface k theDoorSensor Interface 1 1 DoorSensorInter face J Entranceunit theDoorUnit DoorUnit theentrancectrl Entrancectrl theentranceInterface EntranceInter face HED Keypadinter face Co Entrancectrl Levell OpenDoor Level2 Level3 Leveld C cardreader Inter face HE Door Sensor Inter face HC ExitButtonInter face HE DoorLock Inter face LC DisplayInter face CentralcontrolPackage Centralcontrol iy thecentralctrl 1 1 Centralcontrol Co Centralcontrol Secur ityChange VYalidatecard VYolidatecode aAccessControl thecentralcontrol Centralcontrol theentranceUnit EntranceUnit Figure 751 The entire Object Design Documen
73. ors 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 1 In the UtilityTypesPackage diagram select the text symbol con taining the Cara definition From the Window menu choose Entity Dictionary The Entity Dic tionary window is opened You will recognize the structure and icons of chapters modules and diagrams from the Organizer win dow 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 dou ble 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 Telelogic Tau 4 5 User s Manual 3897 Chapter 78 SOMT Tutorial 3898 Package UtilityTypesPackage ea re te CentralControl interface definition H A IGNAL ValidateCard Card ValidateCode Card CodeType RegisterEntrance Pid
74. r by selecting it in the submenu Link in the Tools menu if it is not already open 2 Make sure the window shows endpoint view not entity view or con sistency view If necessary press the Show endpoint or entities quick button In the Link Manager window you see all the endpoints from the dif ferent models in the requirements analysis activity If you scroll to the very end of the window you can see how many endpoints and links you have in your system There should be no links at this point 3 To check that all endpoints are present in the Link Manager win dow choose Check Endpoints in the Tools menu 4 The Check Endpoints window will pop up showing if any previous ly unknown endpoints were found If so select these and press Add Then press Continue 5 Another version of the Check Endpoints window pops up showing if any invalid endpoints were found In such case you can choose to Telelogic Tau 4 5 User s Manual 3867 Chapter 78 SOMT Tutorial 3868 delete these by pressing Delete Press OK when you are done and want to close the dialog 6 To be able to create the implinks between the textual requirements and the classes in the logical structure you only need to see the end points from these diagrams in the Link Manager window You do not have to see all the other endpoints Therefore choose Filter in the View menu The Filter dialog pops up and you can choose to set filter settings for links endpoint or document
75. r 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 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the System Analysis Adding Operations to the Logical Architecture The last thing to add to the logical structure object model are the oper ations For information on how to find the operations see Identifying Operations on page 3878 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 di agram When you are finished your diagram should look something like in Figure 726 6 Save the diagram Telelogic Tau 4 5 User s Manual 3877 Chapter 78 SOMT Tutorial LogicalArchitecture Central_ Entrance_ Control Unit DoorUnit Validate Card Change SecurityLevel Validate Code Open Change System Security Register Entrance PressExi
76. rator to be Cbasic 4 Choose the standard kernel to be Simulation Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the Object Design 5 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 6 When the make process is finished start the Simulator by choosing Simulator UI in the SDL submenu in the Tools menu 7 Inthe SDL Simulator UI window open the file accesscontroll1_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 Validator MSCs from the system design are used as input to the Validator The requirements use case model is the essential part of the require ments 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 proce
77. re calls Consequently this is what is produced when mapping a class to an SDL interface Telelogic Tau 4 5 User s Manual 3893 Chapter 78 SOMT Tutorial 3894 Note that the signals that constitute the interface between our sub systems 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 sub system and signals inside the subsystem are such signals 1 Once again go to the LogicalArchitecture diagram in the Anal ysisObjectModel and copy the class EntranceUnit 2 Goto the SDL Editor and the Ent ranceUnit Package 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 If you look at the signal definition you see that the ChangeSecurityLevel signal is present This is a signal ex changed between our two subsystems and thus should not be de clared here 3 Delete the CchangeSecurityLevel signal 4 Add the signal parameters The signals ReadCard and ReadDigit are the only ones that need parameters See Figure 734 5 Save the diagram giving it the name entranceunitpackage sun Package EntranceUnitPackage Da T SIGNAL Close Open PressExit ReadCard Card ReadDigit Integer h A SIGN ALLIST SLEntzanceUnit Close Open PressExit ReadCard ReadDigi Lecvesiee ce J EntranceUnit Figure 734 T
78. refore 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 mod ule structure is the object model instance diagram where the instances represent the different modules Creating a Design Module Structure 1 Add anew object model diagram to the Organizer in the module DesignModuleStructure and name the document DesignModuleStructure 2 Inthe OM Editor create a first object instance symbol representing the whole SDL system Name it using the name SDL System Access Control 3 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 4 Draw associations from the SDL system module to the two new modules The associations describe that the SDL system uses these two packages 5 Create yet another module which will consist of all common types and signals This package is used by the other two packages and thus Telelogic Tau 4 5 User s Manual 3891 Chapter 78 SOMT Tutorial 3892 also by the SDL system itself Name the module UtilityTypesPack
79. s by selecting from the option menus 7 Choose to set the filter for documents and select that the only docu ments to be shown should be the textual requirements and the logi cal structure documents 8 Press Apply and then Done 9 Inthe Link Manager window highlight the endpoint Text Office by first selecting the endpoint and then clicking the Highlight quick button in the tool bar The endpoint is highlighted with a frame around it 10 Create an implink to the Class Office by first selecting the class and then pressing the Create Link quick button in the tool bar The Create Link dialog will open 11 Name the link Implementation Link and press the Create button A link from the text office to the class Office is created The rest of the links between the textual requirements and the object model diagram are created in a similar way You can do this if you want or go to the next exercise where this has been done and check out the result Links from the UseCaseList to the different MSCs and their excep tions should also be created You cannot do this here however as you have not created all the use cases What we aim at here is to create links from the textual requirements through the object models of the different activities to the SDL design Simultaneously we want to create links from the list of use cases through the use case models in the different activities to the SDL de sign The result of this will be t
80. s the name of those instances that have been defined as block types in the SDL package structure must be changed to the corresponding block in stance name E g the MSC instance Cent ralCont rol can no long er 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 ac cording to the definition of signals and remote procedures in the ar chitecture definition It should not be the name of the parameter that should be added but a value that the parameter can take Alterna tively 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 f 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 Telelogic Tau 4 5 User s Manual 3907 Chapter 78 SOMT Tutorial 3908 3 Inthe 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 block
81. s are most often mapped to SDL process types Active ob jects 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 op erations will be pasted either as signals or as remote procedures of the Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the Object Design process type This depends on whether the operations are synchronous or asynchronous Analysis model Design model object model SDL DoorControl aste As_ DoorControl Figure 745 Mapping a class to a process type 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 EntrancelInterface The classes which should reside as processes in the block EntranceInterface are the CardreaderInterface the KeypadInterface the DisplayInterface and the ExitButtonInterface 1 Copy and paste each class from the LogicalArchitecture dia gram as a Process Type in the EntranceUnit Package 2 Open the block type EntranceInterface diagram in the SDL Ed itor by double clicking on the corresponding
82. s in the EntranceUnit block diagram in the architecture definition 4 For each message decide if it has to be exchanged with a sequence of messages If so add these new messages to the MSC 5 Add parameters to the messages Look at the definition of the sig nals in the architecture definition and add parameters to those mes sages 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 ex ample of a value that the parameter can take e g 123 6 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 for malized The other design use cases are created in a similar way All design use cases should also be connected with implementation links to the corre sponding 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 1 Inthe Link Manager choose Consistency Check in the Tools menu and s
83. s needed or not Telelogic Tau 4 5 User s Manual 3875 Chapter 78 SOMT Tutorial 3876 Finding Relations Useful sources that may assist the process of finding relations are e the requirements object model preserving and modifying existing relations e analysis use case model e textual requirements 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 main ly 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 on page 3864 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 At tributes on page 3876 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 e the requirements model keeping existing attributes e the textual use cases e the textual requirements Attributes describe a property of an object and often correspond to nouns Fo
84. s with attached names the chapters The purpose of these chapters is to group together collections of documents Telelogic Tau 4 5 User s Manual July 2003 Preparing the Documentation Structure 8 Organizer OF x File Edit View Generate Tools Help Stal S Bla F R nl ltt a ele rw CATelelogicTau40 BINWVINI386 Analysis Model Used Files SDL System Structure TICN Test Specification Other Documents Figure 711 The basic Organizer view We want each chapter in the Organizer view to represent an activity in SOMT The current chapters in the Organizer will not fit into our future documentation structure so they should be removed Delete the unwanted chapters by following the steps below 1 Make sure you have the basic view in the Organizer 2 Select the chapter named Analysis Model 3 Select the Remove command in the Edit menu or press the lt Delete gt button You also find the Remove command in the pop up menu The Remove dialog is issued asking you to Remove or to Cancel the action 4 Press the Remove button The dialog disappears and the chapter is deleted 5 Repeat the steps above and remove all of the remaining chapters July 2003 Telelogic Tau 4 5 User s Manual 3839 Chapter 78 SOMT Tutorial Adding New Chapters You should now organize the Organizer view into chapters correspond ing to the different activities in the SOMT method i e each chapter should contain
85. 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 pro cesses 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 be comes fairly simple July 2003 Telelogic Tau 4 5 User s Manual 3917 Chapter 78 SOMT Tutorial Defining the Basic Behavior of a Process 1 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 2 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 Env Employee thdEntraneeinterthce oeEntrance ct Key StrokeTimer 3 Read Digit J k Key StrokeTimer 3 Read Digit l k Key StrokeTimer 3 Read Digit J y K Key StrokeTimer 3 Read Digit U _ l K Receive Code
86. sign e 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 on page 3922 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 e 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 cor responding processes blocks signal interfaces or procedures in the de sign The SecurityLevel does not have any behavior of its own it is Telelogic Tau 4 5 User s Manual July 2003 July 2003 Performing the Object Design 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 t
87. ss you save a lot of effort and time Now you should validate some of the MSCs from the system design ac tivity 1 Select the system AccessControl in the Organizer 2 Choose the Make option in the Generate menu 3 In the Make dialog choose the code generator to be Cbasic 4 Choose the standard kernel to be Validation 5 When the Make process is finished start the Validator UI and open the file accesscontroll_vlb val on UNIX or accesscontroll_vlb exe in Windows Now the system is ready to be validated Telelogic Tau 4 5 User s Manual 3923 Chapter 78 SOMT Tutorial 3924 6 Press the Verify MSC button and choose the system design MSC di agram enter_office with _card_sysd msc which you can find in the directory somttutorial sysdesign 7 Ifthe verification succeeds you will get the message MSC lt Diagram name gt verified It is perhaps too much work to verify all the MSC diagrams of the sys tem 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 e Check that all objects from the analysis object model have been im plemented in the de
88. t re Cardreader_ Tees Display_ ExitButton_ DoorLock_ DoorSensor_ Interface Interface Interface Interface Interface Interface Unlock Open Lock Close Text Read Digit Display PressExit ReadCard Security_ Level3 Security_ Level4 Security_ Levell Security_ Level2 Entrance_ Ctrl Receive ReceiveClose ReceiveCard ReceiveCode ReceivePress Exit Change Security Level Open Security_ Level ia j Figure 726 The logical architecture Identifying Operations Sources that may support the identification of operations are e the requirements object model e the analysis use case model the messages in the MSC diagrams e the data dictionary the description of the objects 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 3878 Telelogic Tau 4 5 User s Manual July 2003 Performing the System Analysis 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 In stead 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
89. t another use case The Management system must inform the Access Control system when there has been a change in security level This will be our fourth use case As for the door actor the task of notifying the system when a door is opened and closed can be included in the enter exit office use cases You should always try to make the use cases as complete as possible that is make one complete use case instead of several minor ones When you have found the normal use cases refine them by examining the exceptions that are possible for each use case Look in the textual requirements document and try to find the exceptions that can occur In the case where an employee enters the office the first thing that can go wrong is that there is a connection failure between the entrance and the central controller Other possible things that can fail are that the card Telelogic Tau 4 5 User s Manual 3853 Chapter 78 SOMT Tutorial 3854 is invalid the code is wrong the time between consequent keystrokes when typing the code is too long and finally the door is never opened even though it was unlocked All these exceptional cases can be found by studying the textual requirements thoroughly The example below shows a part of the use case list Example 610 Part of a Use Case List Normal Cases Enter_Office_With_Card Describes the interaction between an employee and the Access Control system when the employee wants to enter the office t
90. textDiagram Employee Access Control_ System i Management_ System Figure 719 The Context diagram Identifying the Objects The main input sources to the requirements object model are the textual requirements the use case model and the data dictionary Other sources of information are domain experts textbooks etc A classical way to find the objects is to study the textual requirements and note all nouns or look directly in the nouns section in the data dic tionary If a particular noun appears in many places the concept is probably important for the problem domain and should be modeled in the requirements object model The use cases are also helpful for finding the objects They define the actors that interact with the system and these are obvious object candi dates Other likely object candidates are the entities that are transported in to or out of the system The use cases are helpful in identifying these concepts as well The requirements object model should at least describe all concepts that are visible on the outside of the system This includes all physical enti ties that a user can see as well as the knowledge a user must have to use the system It is however not only concepts outside the system that should be modeled in the requirements object model Concepts inside the system that are so obvious that we know of them already at this stage should be dealt with as well In our Access Control system for instance
91. the textual requirements in Example 607 on page 3845 For information on how to find actors see Finding Actors on page 3851 below 3 List the actors by name in the newly created textual document to gether with a brief description of the actor s role when interacting with the system 4 Mark the actors in the ActorsList as endpoints in the same way as you did in Creating Textual Endpoints on page 3847 5 Save the document giving it the name ActorsList txt Finding Actors You will find actors by studying the textual requirements Useful ques tions to ask are e Which users will need services from the system to perform their tasks e Which users are needed by the system to perform its tasks e Are there any external systems that use or are being used by our sys tem In practise the activity of defining actors should be performed iterative ly Try to find as many of the actors as possible now If you do not be lieve you found them all start creating some MSC use cases as having done some MSCs often makes it easier to determine the actors Then go back and complete the list of actors In our case with the Access Control system we find that an employee who daily interacts with the system is an obvious candidate for the list Telelogic Tau 4 5 User s Manual 3851 Chapter 78 SOMT Tutorial 3852 of actors Also considering the third question above it is obvious that the management system is b
92. the consis tency Updating the Data Dictionary 1 Open the data dictionary Include information presented in the addi tional requirements to the data dictionary 2 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 fo cused 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 En glish German and French in the logical structure diagram These class es should be subclasses to the class Display i e an inheritance struc ture is needed 1 Add the three new classes to the logical structure diagram in the re quirements object model Name the classes FrenchDisplay EnglishDisplay and GermanDisplay respectively 2 Link the classes with the corresponding text in the additional textual requirements document Telelogic Tau 4 5 User s Manual 3931 Chapter 78 SOMT Tutorial 3 Save the diagram as logicalstructure som in the current direc tory Display French_ Display Engl Display ish_ German_ Display Figure 754 The class Display and its subclasses 4 Make a link from the class Display to the class DisplayInterface in the logical architec
93. ting it in the Di agrams menu 6 Choose Paste As in the Edit menu The Paste As dialog is opened 7 Set the option menu to Class and see to it that the Create link toggle button is set Press the Paste As button 8 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 im plink to the CentralCcontrol class in the LogicalStructure dia gram The link is indicated by the filled triangle on the class symbol 9 Repeat the procedure above with the class Ent rance but name the new class EntranceUnit as this is a more descriptive name 10 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 itis 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 require ments object model needs services from other not yet introduced class es Consequently these classes should be introduced at this point of the development process
94. tory of your own for the purpose of this tu torial e g somttutorial on UNIX or C Telelogic SDL_ TTCN Suite4 5 work somttutorial in Windows 2 Copy the SOMT tutorial directory and its subdirectories in telelogic sdt examples somttutorial on UNIX or C Telelogic SDL TTCN Suite4 5 sdt examples somtt utorial in Windows into this new directory contact if necessary your system manager Note Installation directory On UNIX the Telelogic Tau installation directory is pointed out by the environment variable telelogic If this variable is not set in your UNIX environment you should ask your system manag er or the person responsible for the Telelogic Tau environment at your site for instructions on how to set this variable correctly In Windows the Telelogic Tau installation directory is assumed to be c Telelogic SDL_TTCN Suite4 5 throughout this tu torial If you cannot find this directory on your PC you should ask your system manager or the person responsible for the Telelogic Tau environment at your site for the correct path to the installation direc tory 3 On UNIX cd to your own subdirectory somttutorial 4 Start Telelogic Tau Telelogic Tau 4 5 User s Manual 3837 Chapter 78 SOMT Tutorial 5 Specify the source directory for the system by double clicking on the Source directory symbol located second uppermost in the Orga nizer window The source directory specifies where new documents that you have
95. ts one of the different roles a user can play when interacting with the system There are different ways to describe a use case e A textual description of the use case e A description of the use case using an MSC e A combination of both a textual description and an MSC Describing use cases using textual descriptions will make it easier to model exceptions and alternative paths of action sequences Describing use cases using MSCs will make the use cases more formal and easier to verify Also as MSCs will be used in the coming activities it might be a good idea to start using them already in the requirements analysis The tutorial will use both textual descriptions and MSCs in the require ments analysis activity and only MSCs in the later activities Telelogic Tau 4 5 User s Manual July 2003 Identifying the Requirements July 2003 Creating a List of Actors Now it is time to create a list of actors The list of actors should list the actors by name together with their respective responsibility 1 Inthe Organizer select the Requirement sUseCaseModel module and choose Add New In the Add New dialog set the Text radio but ton and choose Plain in the corresponding option menu Name the new document ActorsList and set the toggle button Show in Ed itor This will give you a new text document in the Organizer win dow and an empty Text Editor window will pop up 2 Try to find the actors of the Access Control system by studying
96. ts structure 3926 Telelogic Tau 4 5 User s Manual July 2003 Implementation Implementation Textual requirements model text Requirements Requirements Requirements object model use case model Foalysis class diagram ftextMiSC Foalysis Foalysis object model use case model System class diagram text MSC Foalysis Systa design use ada stem Design model SDL MSC TTCN A Object design Object Design model SDL OPONA land aane oa A AZ Implementation Code hardware ete Figure 752 Overview of the SOMT process Data dictionary The implementation of the system lies outside the scope of this tutorial For information about the implementation activity see the SOMT Methodology Guidelines starting in chapter 69 in the User s Manual July 2003 Telelogic Tau 4 5 User s Manual 3927 Chapter 78 SOMT Tutorial Performing an Iteration What You Will Learn e To introduce changes to a system in a controlled way e 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 exist ing requirements are almost always introduced We have to be able to handle these requirement changes and adapt the system to the new situ ation in a controlled way We call this process iteration An iteration may also be planned in advance in for example incremental develop
97. ture diagram in the anal ysis object model Updating the Analysis Object Model In the logical architecture diagram we have to create an inheritance hi erarchy corresponding to the inheritance hierarchy in the logical struc ture 1 Create the three subclasses to the class DisplayInterface Name the classes EnglishDisplayInterface GermanDisplayInterface and FrenchDisplayInterface 2 Create implementation links to the corresponding classes in the log ical 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 3 Traverse the link from the class DisplayInterface to the process type DisplayInterface in the EntranceUnitPackage 3932 Telelogic Tau 4 5 User s Manual July 2003 Performing an Iteration Updating the SDL Design Now it is time to make some changes to the SDL design making it cor respond to the logical architecture The inheritance hierarchy of the DisplayInterface classes should be mapped to an inheritance hierar chy of process types 1 July 2003 Create two new process types in the EntranceUnit Package Name the process types GermanDisplayInterface and FrenchDisplayInterface The already existing DisplayInterface process type will function as the EnglishDisplayInterface Mark these process
98. ure 736 2 Open the InformationDiagram in the AnalysisObjectModel and copy the class Code 3 Go to the SDL Editor and the UtilityTypesPackage and choose Paste As The Paste As dialog is opened 4 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 im plementation link is created at the same time This will only give you the structure you have to fill in all relevant information your self Telelogic Tau 4 5 User s Manual July 2003 July 2003 5 Performing the System Design 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 inte gers 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 736 Declare a SYNONYM NbrofeEntrances 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 736 Before you save and close the diagram you should create an implemen tation link between the class card from the InformationDiagram to the definition of card in this diagram You have earlier used the Link Man ager to manually create links We will now show how to use the entity dictionary for this The entity dictionary is available in all edit
99. uttonInterface 1 1 en ExitButtonInterface rl G2 Exit ReceivePressExit ki ToD ntry y theDisplaylnterface 1 1 Display a aea Monash G3 FD exit EnvDisplay G2 EnvDisplay ReceivePressExit ReceiveCode ReceiveCard Go enosn Figure 757 The block type Entrancelnterface Now you have completed the iteration exercise Telelogic Tau 4 5 User s Manual July 2003 To Conclude To Conclude July 2003 You have now learned the steps of the SOMT method and we hope you have enjoyed the tour Once again we would like to point out that the activities are presented in a sequential order in this tutorial just to simplify the reading In prac tise the task of developing a system using SOMT is a highly iterative process One activity may start before the preceding activity is complet ed and the models inside an activity are usually created in parallel The SOMT method is intended to support the development process not to control it In other words it is a proposed way of working For your own work you should not feel that you are locked by SOMT but pick the parts that suit you best Telelogic Tau 4 5 User s Manual 3937 Chapter 78 SOMT Tutorial 3938 Telelogic Tau 4 5 User s Manual July 2003
100. ve to paste these three classes as SDL inter faces as their operations have already been defined as signals in the EntranceUnitPackage Telelogic Tau 4 5 User s Manual July 2003 Performing the System Design 8 Now copy and paste the class EntranceCtr1 as a block type and as a text symbol with SDL interface in the EntranceUnitPackage 9 Delete the signal CchangeSecurityLevel as this already has been defined in the UtilityTypesPackage 10 Add signal parameters where they are needed i e to the signals ReceiveCard and ReceiveCode 11 Also paste the class as a block in the block type EntranceUnit di agram Give the block the name theEntranceCtrl EntranceCtrl The EntranceUnit Package will look like in Figure 739 Package EntranceUnitPackage ie Pe T SIGNAL Close Open PressExit Readcard Card ReadDigitiInteger A SIGNALLIST SLEntranceUnit Close Open PressExit ReadCard ReadDigi bee see 3 PT IGNAL Lock Unlock IGNALLIST SLDoorUnit Lock Unlock EntranceUnit ntrancelnterfac SIGNAL Display MessageType N wo S PIGNALLIST SLDisplayInterface Display DoorUnit EntranceCtrl IGN AL ReceiveCard Card RecetweClose ReceiveCode Codetype RecetveOpen ReceivePressExit IGNALLIST SLEntranceCtrl RecetweCard RecetveClose EWTYPE MessageType ReceiveCode RecetveOpen ReceivePressExit LITERALS EntCrd EntCde CdeTiOut ConnFail DoorOp
101. 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 on page 3876 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 asso ciation Add multiplicity to the association The Centralcontrol may be connected to several EntranceUnits but the Access Con trol 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 asso ciations aggregations and generalizations Also consider if multi plicity i
102. y 2003 Telelogic Tau 4 5 User s Manual 3885 Chapter 78 SOMT Tutorial 3886 Link Check The first thing to check is that all entities described in the logical struc ture in the requirements object model are either represented in the anal ysis object model or not really needed by the application 1 Open the Link Manager A link check can be performed in both en tity and endpoint view so it does not matter which view you have in the window Choose Consistency Check in the Tools menu to perform a link check The Consistency Check dialog pops up asking you to select the doc uments representing the from group Select the LogicalStructure object model and press Continue 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 docu ments in the module and press Check The Link Manager will show the result of the link check You can see that all entities from the requirements except the system opera tor employee database management system and office are repre sented in the analysis object model These are concepts on the out side of the system and thus not really needed by the application To follow links from one model to another we use the Traverse com mand To see how this works follow the steps below 6 10 Go to the LogicalArchitecture diagram in the OM Editor and select the class
103. you should study the textual requirements document and mark all concepts nouns that you find essential for the problem domain as link endpoints These marks will be very useful in later stages of the project In this tutorial most of the endpoints in the textual requirements docu ment have already been created You task is to add the two missing ones 1 Inthe second sentence of the textual requirements document locate the word office and mark it with the mouse When you mark an endpoint see to it that you only mark the word itself and not any additional characters like a space or a dot after the word 2 In the Link submenu in the Tools menu choose Create Endpoint 3 The text will be underlined indicating that the text fragment now is a link endpoint 4 Now locate the word entrance in the third sentence and create an endpoint out of it by repeating the procedure above 5 Ifyou go through the rest of the document you can see that the rest of the important concepts already have been marked as endpoints 6 Save the document 7 Open the Link Manager This is done by choosing Link Manager in the Link submenu in the Tools menu You can do this either in the Organizer window or in the Text Editor window the result will be the same The Link Manager window will pop up showing all the endpoints of the textual requirements document The endpoint background color is used to show the endpoint status As the endpoints are

78 SOMT Tutorial

Contents

Download Pdf Manuals

Related Search

Related Contents