![]() |
![]() |
![]() |
![]() |
![]() |
A Small Example
This example is intended to show how the UML2SDL utility can be used. The example contains a small analysis model of a game - the Demon game - which is intended to be implemented in SDL through a design model. The Demon game is used as an example in other parts of the documentation. For example, see The Demon Game.
Model Relationships
The purpose of an analysis model is to identify the problem: what is to be done? The following model is the design model which identifies the solution. The design model answers the question how it is to be done. Good practice is to have clear dependencies between the two models, that is, traceability. Traceability is one of the key factors in a successful project.
Very often, the analysis model can be reused when the design model is created. The information provided by the problem statement is needed in the design model. The purpose of the UML2SDL utility is to automate this reuse as much as possible.
The Analysis Model
The Class Diagram
The analysis model is presented in Figure 356. It contains a set of classes which describes an overview of the Demon game. A pure analysis model might not be as detailed as the one given in the example, but the level of detail in the example is chosen to highlight the functionality of the UML2SDL utility.
All operations of the classes in the Analysis Object Model will be mapped to signals since no operation contains a return value. Aggregate classes containing «process» classes, or marked with the stereotype «block», like GameBlock and DemonBlock, will become SDL blocks. The aggregations also tell the UML2SDL utility where to place the «process» classes. For example, the process Demon will be placed inside the block DemonBlock and the other processes will be placed inside the GameBlock.
Associations between classes are mapped to channels and signal routes. The association between the two classes GameBlock and DemonBlock will become a channel between the corresponding blocks. The association between the classes Main and the ProcessDemon will result in a path of communication between the resulting processes.
The inheritance relationship between the Game class and its sub-classes will become inheritance relationships between the corresponding processes as well. Since associations are inherited in UML but signal routes or channels are not inherited in SDL, the UML2SDL utility creates signal routes/channels for inherited associations. This results in signal routes between the process Main and Game, as well as between Main and the sub-processes of Game.
Classes with the stereotype «actor» is mapped as communication with the environment. In our example the class Player will become a channel to the environment. The operations of the class Player will be signals to the environment.
The State Charts
There exist two state charts named Main and Game in the module that will be converted, see Figure 357. The intention of using state charts in the analysis is to get an overview of the behavior of important classes, see Figure 358. The state charts will be transformed together with the class diagram. Since two «process» classes Main and Game exist the result of the UML to SDL conversion will be two complete process descriptions.
The Design Model
The nature of software engineering always requires design information to be added to the analysis at some stage, because we can never solve a problem without providing a solution. This is also true when the UML2SDL utility is used.
Typically, information that needs to be added is behavior that is not described at the UML level. For instance, there is no good way of describing behavior that is redefined in a sub-class at the UML level. For example, such behavior is added to the sub-processes of process Game. Also, there was no need of modeling the simple behavior of ProcessDemon at the stage of analysis, but we have to do that in the design.
Besides adding the basic behavior, we also need to provide a full design. This includes actions like introducing variables, timers, etc. For example, in the process Main we need to describe how the process is responsible for the creation of Game processes, see Figure 359.
When these steps are taken, the Demon game should be complete and possible to simulate like other SDL systems.
Summary
The intention with the UML2SDL utility is to automate the transfer from the analysis model to the design model as much as possible. The transfer will most likely include manual steps, but in theory it is possible to generate an SDL model which is detailed enough to simulate.
http://www.ibm.com/rational |
![]() |
![]() |
![]() |
![]() |