This chapter describes the major concepts and notations used in the SOMT method. The notations treated includes object models, state charts, SDL diagrams and Message Sequence Charts. Note that the descriptions in this section only briefly describes the different notations. For a more thorough treatment, please consult a textbook on the specific notation.
As seen in the previous chapter, the SOMT method describes object oriented analysis and design as a number of activities that produce one or more models. A model is here used in an abstract fashion to denote a collection of diagrams, text documents or whatever is needed in the particular model. The concept of a model is used to be able to discuss the results of an activity without going into detail of how the actual diagrams/documents are organized.
A module, on the other hand, is the concept used in SOMT to define how the diagrams/documents are organized. The major purpose of the modules is that they form units that should be fairly self-contained and that can be developed by themselves, maybe by different teams. A module is a container of e.g. diagrams and textual documents that has no semantics by itself but that forms a scope unit for names (if this is not given by the notation used). For example, if the Analysis Object Model is described in two modules that both contain a class called "Person", then these definitions do not refer to the same class. There will be two different "Person" classes, one in each module.
In practice it is beneficial to have a simple mapping between models and modules, either a one-to-one or, if a model is too large, a one-to many mapping where a model is decomposed into several modules.
The actual documentation produced according to SOMT is thus a collection of modules containing diagrams/documents that together form this particular projects representation of the SOMT models.
The SOMT method introduces a number of different models that are used to describe different aspects of the system. In particular there are three levels formed by:
One very common relation between objects in different models is that one object can be seen as an implementation of an object in another model. For example, an object in the object model created in the system analysis phase may be reintroduced in the design model as a process type or an ADT (abstract data type). Another example may be an object that was identified in the requirements analysis as something visible on the system boundary, and that later is reintroduced in the analysis object model and finally ends up as a signal in the SDL design. To represent this type of relations among objects the concept of implementation links (implinks) is used. An implink is a directed relation between two objects, usually (but not necessarily) in different models. Conceptually we get a picture as in Figure 3.
Figure 3 : Implinks between objects in different models
|
|
If used carefully, the implinks give a possibility to trace requirements all the way down into code. There are several situations where the implinks are very useful:
It is important to see that the act of creating an implink is a creative design action that encapsulates a design decision. The Paste As mechanism is a special concept used in SOMT to support the task of creating implinks. The idea is that an object in one model can be copied and then pasted as a new object in another model, see Figure 4. This action serves both to create the new object and to document the design step using an implink.
Figure 4
: Using Paste As to capture a design step from
the system analysis model to SDL
|
|
The SOMT method uses a number of models and notations and the checking of various aspects of the models is an important part of a development project. This checking can be formulated as a question of identifying "entities" or "concepts" in different models (or in one model), to identify some rules of how these entities should relate to each other, and finally to check that the models are consistent with respect to these rules. This type of checking is in this document called consistency checking. Three different types of consistency checking can be identified:
In some sense the checking of traceability aspects is a special case of the checking of the consistency between two models, but it is an important special case and it is given a special treatment in SOMT.
One general observation that can be made is that the identification of concepts/entities is very much depending on the particular notation used. Each separate notation will have to be treated separately following the particular rules that apply to this language. For formal languages like SDL, the concepts and procedures how to find the entities are well defined, while for other languages the rules are different, and for plain, informal text the entity identification will have to be explicitly done by the user. In SOMT there is a special possibility to "mark" words or phrases in text documents. The intention is that this marking means "this concept is important" or "this is a concept that I would like to for consistency checks".
In the rest of this volume, each activity of the SOMT method together with its associated models will be described in different chapters. Each of these chapters will also include a discussion on consistency rules that are relevant for this particular model.
The object model notation from Object Modeling Technique (OMT) and Unified Modeling Language (UML) is a commonly accepted graphical notation used for drawing diagrams that describe objects and the relations between them. The notation that is used in examples in this volume is shown in Figure 5 through Figure 10. For more details about other, more advanced OMT object model concepts, please consult [4], and for details about the UML notation see [20] and [21].
The most important concept in an object model is the class definition. A class is a description of a group of similar objects that share the properties defined by the class. The object model notation for a class is exemplified in Figure 5, where the second class definition also shows how to define attributes and operations.
Figure 5 :
A collapsed class symbol and a class symbol
with attributes and operations
|
|
In some cases it is necessary to reference classes from an external module. The notation used for this purpose is ExternalModule::Class.
Classes may inherit attributes and operations from other classes. The object model notation for this is shown in Figure 6.
Figure 6 : Inheritance between classes
|
|
Classes may be physically or logically related to each other. This is shown in the object model by means of associations as shown in Figure 7. An association may have a name and/or the endpoints of the association may be labeled by the role of this endpoint.
Figure 7 : Associations between classes
|
|
Aggregation is special kind of association that has its own notation as shown in Figure 8.
|
|
The endpoints of associations and aggregations may have a multiplicity as shown in Figure 9.
Figure 9 : Multiplicity of associations and aggregations
|
|
In practise the complete requirements object model is often too big to fit into one diagram. To solve this problem it is possible to use multiple object model diagrams that can be organized into a module, which simply is a list of diagrams. It is important to notice that a class may be present in more than one diagram and still only represent one logical class.
Besides class definitions, object models may of course also contain objects and their relations. The relation that exists between objects are links, which corresponds to the associations for classes. The object symbol has one field containing the name of the object together with a reference to the class, and an attribute field where constant or default values can be assigned to the object attributes. See Figure 10.
Figure 10 : Objects related by links
|
|
The notation presented in this section is a subset of the notation for state charts presented by David Harel [19] which is used in the Unified Modeling Language (UML) [20] as well as in the Object Modeling Technique (OMT) [4].
A state chart model is suitable to use together with class and object models. The descriptions of the behavior of a class in a class diagram is collected into a state chart which describes the dynamic view of the model by means of states and transitions. The notation to use is presented below.
To describe state charts a state symbol is needed. The state symbol is divided into three compartments, State Name, State Variable and Internal Activity, which are all optional. The top compartment contains the optional name of the state. State symbols with the same name within the same context are considered to be the same. It is not necessary to name states and if several anonymous states exists; each anonymous state symbol is considered to be an individual state. Figure 11 shows a collapsed state and a state with state variables and events.
Figure 11
: A collapsed state symbol and a state symbol
with state variables and events
|
|
A state symbol may contain a State Variable compartment. This compartment highlights attributes of the class which are used or in some way affected by the behavior described in the state chart.
The third compartment is the Internal Activity compartment which describes the activities of the current state, activities that are done upon entering the state, activities taking place while in the state and activities executed when exiting the state. Each activity is described in the format:
Each event name may appear only once within a state symbol. The event names "entry", "exit" and "do" are reserved and they describe the following actions:
The second necessary symbol for drawing state charts is the transition. The transition symbol is an arrow which connects two symbols of either type of state, start and termination, see Figure 12.
Figure 12
: The transition from state1 to state2 is triggered by the event
my_event and the condition that attr1 is less than attr2
|
|
The syntax for the transition symbol follows the format:
The event-signature consists of the parts:
The guard-condition is a Boolean expression formed by the parameters of the triggering event together with possible attributes and links of the object described by the state chart.
The action-expression describes the action that is executed during the transition. The action may be described by procedures, affected attributes and links.
The send-clause has the format:
The destination-expression identifies the receiving object or a set of receiving objects.
The Destination-event-name is the name of an event that may be received by the receiving object(s).
The start symbol denotes the starting point of a state machine described by a state chart and the termination symbol denotes the point of termination of a state machine. Figure 13 shows a simple state machine, describing the behavior of a door, including a start symbol and a termination symbol.
Figure 13 : A simple state chart with a start symbol and a termination symbol
|
|
States may be refined into nested diagrams of sub-states, or hierarchical states. The state represents a simplification of more complex behavior expressed in the nested diagram.
Figure 14 : A state chart with states and substates.
|
|
Both State Charts and SDL process graphs are two notations used to express state machines. The two notations have both their advantages. State Charts are good for expressing high level functionality typically used in early activities like analysis. SDL is good for expressing detailed functionality as in design activities. SDL is also a formal notation, with well defined semantics, from which it is possible to generate code.
State charts might be used to express high level functionality of a system by focusing on the behavior of the system rather than the behavior of the system's parts. It might also be useful to express the behavior of complex actors that are interacting with the system.
In the context of system analysis, state charts are useful to express the behavior of the system parts and how these parts interact dynamically. The architecture of the system is described in a class diagram named Logical Architecture. Using state charts in addition to the class diagram makes it possible to describe the dynamic properties and the behavior of the system or parts of the system. The behavior descriptions should be included in a set of documents called the Object Behavior Diagram which together with the Logical Architecture is part if the Analysis Object Model.
During the activities of System and Object Design, SDL process diagram is the preferred notation for describing the behavior of the system. The product of the Object Design activity should be a complete description of the system which enables code generation. State Charts, due to their weak semantics, may be useful to express a less detailed overview of rather complex behavior expressed in SDL.
A message sequence chart (MSC) is a high-level description of the message interaction between system components and their environment. A major advantage of the MSC language is its clear and unambiguous graphical layout which immediately gives an intuitive understanding of the described system behavior. The syntax and semantics of MSCs are standardized by ITU-T, as recommendation Z.120 [9].
There are various application areas for MSCs and within the system development process MSCs play a role in nearly all stages, complementing SDL on many respects. MSCs can e.g. be used:
The most fundamental language constructs of MSCs are instances (e.g., entities of SDL systems, blocks, processes and services) and messages describing the communication events, see Figure 15.
Another basic language construct is the condition symbol which is drawn as a hexagon. A condition describes either a global system state referring to all instances contained in the MSC, or a state referring to a subset of instances (a non-global condition). The minimum subset is a single instance.
An MSC can reference another MSC using an MSC reference symbol. (Such a symbol can also reference a High-level MSC, explained later.) This symbol is drawn as a rectangle with rounded corners and has the name of the associated MSC stated inside it. MSC references can for example be used to have one MSC describing an initialization sequence and then reference this MSC from a number of other MSCs.
The reference symbol may not only refer to an MSC but can also contain MSC reference expressions that reference more than one MSC. This construct gives us a very compact MSC representation and it also provides an excellent means for reusability of certain MSCs.
The textual MSC expressions are constructed from the operators alt, par, loop, opt and exc:
loop<n,m>, where n and m are natural numbers, denotes iteration at least n and most m times. The operands may be replaced by the keyword inf, like in loop<n,inf>. This means that the loop will be executed at least n times. If the second operand is omitted, like in loop<n>, this will be interpreted as loop<n,n>. If both operands are omitted the interpretation will be loop<1,inf>.
Figure 15 : Example of a plain MSC
|
|
By means of inline operator expressions composition of event structures may be defined inside an MSC. Graphically, the inline expression is described by a rectangle with dashed horizontal lines as separators. The operator keyword alt, loop, opt, par or exc, placed in the upper left corner, are used with the same meaning as when used together with the MSC reference symbol.
Whether to use inline operator expressions or MSC reference symbols with an operator is a matter of taste. The same things can be expressed with both notations. Using inline expression several scenarios can be expressed in one single diagram, i.e. we just have one single file to handle. If we use MSC reference symbols to express e.g. exceptions and alternatives there is a need for us to handle several files. On the other hand, the diagram becomes less cluttered if we refer to other MSCs instead of trying to express all possible scenarios in it.
Figure 16 : A plain MSC with inline operator expression
|
|
For information about more plain MSC concepts, like e.g. timers, please consult the MSC standard Z.120.
A high-level MSC (HMSC) provides a means to graphically define how a set of MSCs can be combined. Contrary to plain MSCs, instances and messages are not shown within an HMSC, but it focus completely on the composition aspects. You can get a picture of how an HMSC works in practice by comparing it with a road map. HMSCs, like normal road maps, may easily become quite complex if they are not structured in any way. Fortunately, HMSCs can be hierarchically structured, i.e. it is possible to refine HMSCs by other HMSCs. The power of the MSC language is considerably improved with the new concepts introduced with HMSCs. It is e.g. much easier to specify a main scenario together with all accompanying exceptions.
An HMSC is a directed graph where each node is either (see Figure 17):
Flow lines connect the nodes in the HMSC and they indicate the sequencing that is possible among the nodes in the HMSC. If there is more than one outgoing flow line from a node this indicates an alternative.
Figure 17 : Example of an HMSC
|
|
SDL (Specification and Description Language) is mainly used for specifying behavior of real-time systems. This section provides a small overview of the language. For further reading, we recommend [10], [11] and [12] as useful textbooks about SDL. The SDL language is standardized by ITU-T, as recommendation Z.100 [7].
An SDL system consists of the following components:
Figure 18 shows the hierarchical levels in SDL: system, block, process, procedure and service.
Figure 18 : The hierarchical decomposition of an SDL specification
|
|
A system must contain at least one block and a block must contain at least one process. Services can exist within a process, being executed one at a time, controlled by the received signals. Thus the incoming signal sets of services in one process must be disjoint. Using procedures is a way to structure the information within processes and services. Processes, services and procedures are described by a flow chart-alike notation, see Behavior.
The static structure of a system is defined in terms of blocks. Blocks communicate by means of channels.
The dynamic structure of an SDL system consists of a set of processes that run in parallel. A process is a finite state machine extended with data. Processes are independent of each other and communicate with discrete signals by means of signal routes.
Since SDL does not allow any use of global data, all information that has to be exchanged must be sent along with signals between processes, or between processes and environment. Signals are sent asynchronously, i.e. the sending process continues executing without waiting for an acknowledgment from the receiving process.
Signals travel through channels between blocks, and from one process to another via signal routes. See Figure 18.
Synchronous communication is possible via a shorthand, remote procedure call. This shorthand is transformed to signal sending with an extra signal for the acknowledgment. Remote procedures are often used when a process wants to offer services to other processes.
The dynamic behavior in an SDL system is described in the processes. Processes in SDL can be created at system start or created and terminated dynamically at run time. More than one instance of a process can exist. Each instance has a unique process identifier (PId). This makes it possible to send signals to individual instances of a process. The concept of processes and process instances that work autonomously and concurrently makes SDL appropriate for distributed applications.
Figure 19 : Behavior described by an SDL process
|
|
A process must have one start symbol. Since a process is a state machine, a transition between two states is made only after a signal has been received. If there are no incoming signals the process is inactive in a state. In SDL a transition takes no time. To be able to model time, and to set time restrictions, there is a timer concept. Each process has its own set of timers that can be set to expire on different durations.
The set of predefined sorts in SDL makes it possible to work with data in SDL in a traditional way:
More complex data sorts can be created by using arrays, strings and structs.
Abstract Data Types in SDL can be used for more than representing data, e.g:
Data manipulation is hidden in operators. For a more thorough description on how to use complex data structures with operators in practice, please see [15].
The object-oriented concepts of SDL give you powerful tools for structuring and reuse. The concept is based on type definitions. All structural building blocks can be typed: system type, block type, process type and service type. An exception is the procedure that is a type in its original form.
Figure 20 : Package with type definitions
|
|
Type definitions may be placed outside the system in packages. Packages can be seen as libraries of frequently used functions. The structural typing concepts are shown in Figure 20. All types can inherit from other types of the same kind.
Figure 21 : A system diagram with block instantiation and communication
|
|
One of the major benefits of using an object oriented language is the possibility to create new objects by adding new properties to existing objects, or to redefine properties of existing objects. This is what is commonly referred to as specialization.
In SDL-92, specialization of types can be accomplished in two ways:
Figure 21 and Figure 22 describe adding and redefining properties in a system and in a block type while Figure 23 describes the same features in a process type diagram.
To be able to instantiate a type regardless the context (by means of channels), a special concept is needed: gates.
Since a channel always has to be connected to a signal route and the connection mechanism lies inside the process, a gate is necessary since it is a way to specify the connection in a transparent manner.
Figure 22 :
An inherited block type diagram with process
specialization, instantiation and communication
In the inherited block type Control, the process ctrl is an instance of the process type Control.
|
|
Figure 23 :
A specialized process type with added signals, a new
transition and a redefined transition
|
|
The SDL language supports two notations that are equivalent. Beside the graphical representation (SDL-GR), a textual phrase representation (SDL-PR) is standardized.
TTCN (Tree and Tabular Combined Notation) is a special purpose notation to describe test suites [17]. TTCN is a language standardized by ISO for the specification of tests for communicating systems. TTCN has been developed within the framework of standardized conformance testing (ISO/IEC 9646).
With TTCN a test suite is specified. This is a collection of various test cases together with all the declarations and components it needs.
Each test case is described as an event tree. The tree is represented as an indented list in a table. The indentation represents progression with respect to time. See Example 1.
Behavior Description Constraints Verdict
1 DuToEnv? Display Enter_Card
2 EnvToDu! Card Card1
3 DuToEnv? Display Enter_Code
4 EnvToDu! Digit digit1
5 EnvToDu! Digit digit3
6 EnvToDu! Digit digit5
7 EnvToDu! Digit digit7
8 DuToEnv? Unlock nopar
9 EnvToDu! Open nopar
10 DuToEnv? Display Please_Enter
11 EnvToDu! Close nopar
12 DuToEnv? Lock nopar
13 DuToEnv? Display Enter_Card PASS
14 EnvToDu! Digit digit1
15 DuToEnv? Display WrongCode
16 DuToEnv? Display Enter_Card PASS
Each line consists of a line number, a statement, a constraint reference and a mandatory verdict. A statement can be:
The event statements are statements that can be successful dependent on the occurrence of a certain event, either:
The action statements will always execute and will therefore always be successful:
A qualifier is simply an expression that must be true if an event should match or an action should be performed.
In TTCN, the communication is asynchronous. The implementation under test, IUT, communicates with the environment via points of control and observation, PCOs. The interaction occurs at PCOs and are described by protocol data units, PDUs, embedded in abstract service primitives, ASPs.
At line 1 in s above, the ASP Display occurs at the PCO DuToEnv. The constraint Enter_Card determines exactly which ASP value is to be received.
The leaves in the tree are usually assigned a verdict.
The Common Object Request Broker Architecture (CORBA) is a standard that specifies ways for server objects and clients to interact with each other. The Object Management Group (OMG) is responsible for maintaining the standard, which is defined in [14]. The mission of OMG is to develop a single architecture, using object technology, for distributed application integration, with the following objectives in mind:
The idea behind CORBA is to provide a framework that allows objects to communicate with each other, independent of specific platforms and techniques used to implement the objects. The central component of CORBA is an Object Request Broker (ORB), which is an implementation of CORBA that enables objects to transparently make and receive requests and interact over a network of heterogeneous systems. In this way, applications acquired from different vendors and installed on different systems are able to freely exchange information.
A key component of CORBA is IDL, which is a textual language that enables designers to capture object interfaces and data types without tying these definitions to implementation aspects of the objects. The IDL specification is used as a contract between a client and a server, where the server informs everyone about the services it offers, and the client is told which services that are available. Using the IDL specification it is then possible for clients to transparently access remote objects without caring about how they are actually implemented.
IDL as a language is based on C++, but has been extended with constructs and keywords that better facilitate definition of distributed objects. An IDL specification is basically a collection of object interfaces, together with all the information necessary to define these interfaces, such as types and constants. The most important IDL concepts are briefly described below.
|
Note: CORBA and IDL support in SDT is only available on UNIX. |
An interface in IDL is used to abstractly describe the functionality that is provided by an object, either as attributes or as operations. Attributes are used to define server variables that should be available from a client, and it is possible to both set and get the value of an attribute unless it has been specified as read-only, in which case it is only permitted to get the value of the attribute.
// IDL
interface Account {
readonly attribute double balance;
attribute string owner;
};
In Example 2, an example is shown of an interface containing two attributes. An account object is described, and it contains an attribute that is used to store the current balance of the account. A client cannot change the value of this attribute directly, but it would be possible to offer operations that are able to increase or decrease this value, which is shown in Example 4. The other attribute, though, which names the owner of the account, can be freely accessed.
An operation describes the services that are offered by an object. It may carry typed parameters of different kinds (in-, out-, and inout-parameters), and may also return a value. Operations are usually used for synchronous communication, where the client is blocked during execution of the call, but by stating that the operation is one-way it is possible to model asynchronous communication as well, where the client may continue executing directly after the operation has been issued.
It is possible to use interfaces as parameters to operations, but then it is not really the interface that is sent, but rather an object reference to the actual object instance that implements the interface.
In Example 3, two operations are defined. The first one, which is used to close an account, does not require a reply, but it is necessary to include an object reference to the account that should be closed. The second operation, which is used to create a new account, returns a reference to the created object instance to the client in order to facilitate subsequent operations on that account.
// IDL
interface Cashier {
oneway void CloseAccount (in Account acc);
Account NewAccount (in string owner);
};
When modeling objects the concept of inheritance is very important, and this is supported in IDL by allowing interfaces to inherit other interfaces (multiple inheritance is allowed).
// IDL
interface BankAccount: Account {
oneway void Insert (in double amount);
boolean Withdraw (in double amount,
out double newBalance);
};
In Example 4, a new kind of account suitable for banks is created by inheriting the account interface that was given in Example 2, and then adding a few operations to allow the client to insert and withdraw money from it, thereby changing the accumulated balance. When an interface is inherited by another interface, all operations and attributes are available in the new interface as if they were actually defined within it. This is also true for any types or constants that happen to be defined in the inherited interface.
A module is used to group interfaces and other definitions (including other modules) into logical units. This is also useful because a module defines a naming scope, i.e., names that are defined within a module do not clash with names defined outside the module. Modules can thus be used to structure a system in manageable units.
// IDL
module Bank {
interface BankAccount: Account {
oneway void Insert (in double amount);
boolean Withdraw (in double amount,
out double newBalance);
};
interface Cashier {
oneway void CloseAccount (in Account acc);
Account NewAccount (in string owner);
};
};
Modules and to some extent interfaces are used to structure an IDL specification, but there are several other basic concepts that are equally important, such as types, constants, and exceptions.
There are many predefined basic types in IDL, and they are used as the basic building blocks when creating new types: long, short, unsigned long, unsigned short, double, float, boolean, char, octet, and any. Furthermore, there are several concepts that can be used to build more complex types: struct, enum, union, sequence, string, and array. These types are used when defining parameters to operations, and when defining attributes.
It is also possible to define new types using the keyword typedef, just like in C++.
If a value should be constant in both the server and the client, it is possible to assign constant values in IDL by using the keyword const.
Error handling is managed by using exceptions. An operation may raise previously defined exceptions if anything goes wrong in order to inform the client of the error, but there also exists a set of predefined standard exceptions that can always be raised.
// IDL
interface AlternativeCashier {
exception reject {
string reason;
};
Account NewAccount (in string owner) raises (reject);
};
An example of a user defined exception is shown in Example 6; if an attempt is made to create a new account, but fails, the client can then determine how to proceed by examining the returned exception.
ASN.1, described in [6], stands for Abstract Syntax Notation One. ASN.1 is a language for the specification of data types and values. ASN.1 is very popular for the specification of data in telecommunication protocols and services, especially in higher (i.e. application oriented) layers. Many telecommunication standards are based on ASN.1. Also TTCN is based on ASN.1. An example of an ASN.1 module is shown below.
ProtocolData DEFINITIONS ::=
BEGIN
- - contains data definitions for an example protocol
CheckSum ::= INTEGER (0..65535)
DataField ::= OCTET STRING (SIZE (0..56))
PDU ::= SEQUENCE {
sequenceNr INTEGER (0..255),
dataField DataField,
checksum CheckSum OPTIONAL }
END
A strong point of ASN.1 is that there are encoding rules that define how an ASN.1 data value is encoded to bits, the most well-known being the Basic Encoding Rules. From an ASN.1 data type definition, functions can be automatically generated that take care of the coding and decoding.
An ASN.1 definition can be imported into SDL as if it was a package. When an ASN.1 data type is imported into SDL, automatically a set of operators that is defined in Z.105 [8] is available for that type.
It is recommended to use ASN.1 for the specification of parameters of signals to/from the environment of the SDL system, especially when encoding rules are to be applied on such signals, or when a TTCN test suite is to be developed. In the latter case the ASN.1 definitions can be directly reused in the TTCN test suite.