IBM
Contents Index Previous Next



Describing Object Behavior


Once the type of SDL target concept has been chosen, the behavior of the object can be defined. Processes and process types are defined by creating the process graphs and ADTs are preferably defined by giving operator diagrams for the operators.

In practise, the major task of the object design activity is the definition of the behavior of SDL processes since they are the SDL representation of active objects that tend to have a more complex behavior than the passive objects. SDL process graphs provide a graphical notation for extended finite state machines, i.e. finite state machines with variables. In Figure 711 an example of a small process graph that illustrates some of the constructs possible in an SDL process is shown. More details about SDL and SDL process graphs are provided in section SDL.

Figure 711 : An SDL process graph

The possible inputs to the process design task are illustrated in Figure 712. The possible inputs directly from the system analysis/design are:

The inputs resulting from the mapping of object models to SDL are:

Based on these inputs the goal of the process design is to create a process diagram that defines the behavior of the process.

Figure 712 : Inputs and output of the process design task

A useful way to structure the tasks that are needed to create a complete process are:

  1. Create a first version of the process that defines the control structure in terms of states and transitions. There are two subtasks that in practise are performed more or less in parallel:
    • Defining the control structure
    • Defining data aspects.
  2. Elaborate the process by e.g. considering secondary use cases and exceptional cases.

The First Version - Defining the Control Structure

The control structure of an SDL process is defined by the states and the transitions of the process. Ideally the states of a process represent what the environment might expect of the process. Different states represent different stable phases in the life-time of a process and depending on what state a process is in it will respond differently to requests and inputs from the environment.

One straight-forward way to find the states of a process is to analyze the use cases. Since the use cases show an external view of the processes they reflect the expectations the environment can have on the behavior of the process. Both directly in terms of sequences of inputs and outputs the process has to conform to but also indirectly in terms of states since each input of a process must be preceded by a state.

So, the task of designing the control structure of the process starts with selecting a set of typical and essential use cases. If the use cases are in MSC format and on an appropriate abstraction level that includes the process to be defined, the use cases can be analyzed directly. If not they should be rewritten to clearly show the responsibilities of the process in question.

Analyze each use case in terms of states and transitions for the process. Incrementally build up the process graph by adding states and transitions. Start in the beginning of the use case and figure out what state the process must be in. Manually walk through the use case, checking the process defined so far and incrementally adding states and transitions to the process graph. Check for each transition in the use case (i.e. input followed by one or more outputs by the process in question) that the transition exists in the process graph. If it does not exist, add it. Take a look in the use case to see if there is an external need for a state change in the process: has the expectations on the process changed after this transition in the use case? If no: go back to the same state again. If yes: is there an already defined state that may fit these expectations? If there is one, use it. If there is no such state, create a new one and give it a name that describes the expectations. Continue until all use cases has been analyzed.

When adding transitions do not forget to check with the mapping from the object model if it is a regular transition with input and outputs or a remote procedure that is to be added. Also check if state lists (and "*" states) can be used as the starting state of the transition.

During the design of the process also consider what part of the control to put in the process graph states and what to put in variable values. In general it is recommended to define the control flow using the process graph states, but there are cases when it is better to put parts of the control in data values instead of as explicit process states. One example is loop variables that count the number of occurrences of something and is used to exit the loop after a certain number.

One problem that might occur during the use case analysis is that two of the use cases seem to be very difficult to combine in the same process since they require different states of the process. This is an indication that some restructuring is needed and that maybe the process should be divided into different processes or into a set of services.

When finished with the analysis of the selected use cases the result should be a skeleton process graph that contains states and transitions with mainly inputs, outputs, remote procedures, timer actions and a few tasks and decisions that deal with control variables. Make sure that the state/transition structure makes sense. The states should represent external expectations on the behavior and their names should reflect it. This is an important issue, in particular for the possibilities to maintain the process.

The next step is now to consider the data aspects of the transitions.

The First Version - Data Aspects

Often there will be three kinds of variables in an SDL process: temporary variables used to handle the parameters of signals, control variables like loop counters as discussed above, and "real" variables that store information about some entity that will be accessed later during the execution. Most of the "real" variables should have been identified during the analysis are given by the mapping from the object model to SDL. The task now is to define how the "real" variables are affected by the transitions. Add temporary variables handling the parameters of the signals when needed and tasks with expressions that define the needed computations. If complex computations are needed it is good practise to hide them in procedures or operators. The transitions should preferably stay fairly simple.

The first version of the process is considered to be finished when it is possible to verify that the process fulfills the selected use cases, e.g. by running a simulator or verifying MSC use cases (compare with Design Testing). Both the control and the data aspects should be dealt with.

Now it is time to start with the elaboration of the process.

Elaboration of the Process

The purpose of the first version of the process was to define the control structure of the process and make sure that this is able to cope with the requirements from the most typical and important use cases. The purpose of the elaboration is to complete and refine this structure to make the process definition reliable and facilitate the maintenance. There are several aspects to cover in this elaboration:

The major topic for the elaboration task is to consider the secondary use case that was not treated in the first version and also the exceptional cases of the already treated use cases. This is done essentially the same way as when creating the first version as described in The First Version - Defining the Control Structure. The use cases are walked through by hand and the process graph is checked and possibly extended to cope with the new cases.

To enable the understanding of the process and thus also to make it possible to maintain it, it is important that the definition is as simple as possible. This is a topic that is dealt with in the elaboration task. Procedures can be used to simplify process definitions considerably by defining a particular piece of code in one place and using it in several. Procedures can also be used on a higher level to indicate different phases in the lifetime of the process. Using state lists and "*" states it is also possible to simplify the definition of a process by defining transitions that are common to many states in one place.

The robustness and completeness of the process must also be handled in the elaboration. The strategy is essentially to make sure that the appropriate action is taken by the process, not only for the expected cases but also for unexpected cases. So, for each state in the process and each input signal/ remote procedure call possible; check that the action taken makes sense. Also check the treatment of unexpected parameter values.

Another topic to be treated in the elaboration is to consider how to facilitate reuse of the created process. Is it possible to create a more general process type by factoring out some parts of the definition and defining a more general process type that can be specialized in other situations?

The elaboration is in practise an iterative process where all the aspects above are treated more or less in parallel. When the elaboration is finished, the process definition is completed and is ready for integration test. The module test should preferably already have been done at this stage.

Operator Diagrams

When defining the behavior of passive data types defined in SDL the preferred way to define the operator is using operator diagrams. An operator diagram is essentially a flow graph with a start symbol, symbols defining the actions performed by the operation and one or more return symbols. The symbols may for example be tasks with assignments or decisions. An example is given in Figure 713 that shows the operator diagram for an operator BirthDay that increases the age of a person by 1.

Figure 713 : An operator diagram


http://www.ibm.com/rational
Contents Index Previous Next