With the introduction of SDL-2000, SDL has reached a high level of object-oriented formal description power and expressiveness. Unfortunately, this was accompanied by high level of complexity as noted in [KLP+04, She05]. It is argued that several features available in SDL are only used by a minority of users. This becomes underlined as the tool support of SDL-2000 is still poor.
Most tools are even not fully SDL-96 compliant. In contrast, several concepts for the modeling of next-generation telecommunication protocols are cumbersome to be described by SDL as already noted in the previous chapters.
Hence, instead of defining a new language concept from scratch for a UML profile, a mapping from the UML to SDL will be defined. The semantics of SDL have been formally described by means of the Abstract State Machines formalism. It has undergone several revisions and improvements since its initial release [Pri02]. The SDL semantics will be re-used for this profile. In most cases, this allows a mapping from a UML system to an SDL design specification. Based on the translated specification, the static and dynamic semantics of the UML model can be simulated and validated. In addition, the syntax has to be verified by the SDL tool, because textual SDL language expressions can be defined in several UML CS model elements. These expressions are (currently) not checked in a UML modeling tool. Hence, this allows using any SDL statement within a system description even if it is currently not supported by this profile. An overview of the specification and description process for communicating systems is given in Figure 60. Providing a mapping to SDL shows that a formal description of telecommunication systems is feasible by using the UML CS profile.
However, this approach currently constitutes the downside that in case of errors a direct correspondence between the erroneous language element in the UML and the detected error in SDL cannot be made. The reason is that some UML CS elements are grouped together in a single SDL
statement while others are decomposed into several SDL statements. This circumstance sometimes may only allow to give a rough estimate of the location of the error. In the future, however, modeling tools might be able to support UML CS directly without the need to map the UML diagrams to SDL first. This would allow a much tighter integration of the software engineering process covering the requirements, analysis and design and further to the implementation.
Figure 60: Specification and Description Process using UML CS Profile
As in SDL, UML CS introduces concepts (especially for larger systems) for structuring, behavior and data description. The basis of structuring is the hierarchical decomposition of system views and hierarchies of types. The basis for behavior description is a communicating extended finite state machine. Data description is based on types of objects and values. These are the three constituent parts of this profile and defined in the following sections in detail.
7.1.1 Reading the Profile Definition
The profile comprises of stereotypes that can define tags, tagged values and constraints. For clarity, each stereotype is defined by means of a table.
Figure 61: Example of Stereotype Definition Table
UMLNODE TYPE UMLNOTATION REFERENCE
«port» Port (from Ports) inputQueue: Boolean = false
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context port
inv: self.isBehavior=false inv: self.isService=true
The optional inputQueue specifies if inbound signals are queued by this port until the are consumed by a process.
7.1 Introduction
An arbitrary example of such a table is shown in Figure 61. This table provides the following information: First, it gives a name to the stereotype that is shown in the cell labeled UML CS Stereotype. This unique name identifies this stereotype. Either a stereotype can extend a UML metaclass or it can specialize another stereotype. The base metaclass to which this stereotype refers to is shown in the cell UML Node Type. This identifies the modeling element (UML metaclass) that is extended. The metaclass or stereotype, which is extended by this stereotype, can be found in the cell UML MetaClass. In this example, the stereotype «port» is extended from the UML metaclass Port (from Ports). The expression from shown in brackets denotes the package in the UML Superstructure where this metaclass is defined. The package qualifier is needed as some metaclass are incrementally defined in multiple packages by the UML package merge technique. Furthermore, the relevant UML Superstructure document’s section heading of the extended metaclass is shown in the cell Reference.
Additionally, the profile proposes a graphical notation. This symbol is shown in the cell UML Notation. In most cases, further alternative notations are given that should be preferred depending on the UML tool’s capabilities. If they are provided, they are not added in this table, but given in the description. Note that textual notations are specified in the Extended Backus-Naur Form (EBNF), described in Section 3.3.2. Most of the expressions, references and rule names refer to the EBNF defined for the concrete grammar in the SDL-2000 document [ITU02a].
For the definition of a stereotype, constraints and tagged values can be defined. The constraints are specified in OCL. The constraints, which apply to this stereotype, are shown in the cell OCL Constraints. In most cases, these constraints are underlined and explained by an informal description which can be found under Informal Constraints. Note that both types of constraints must not contradict. If such an event occurs, none of them has precedence over the other. This error must be corrected. Finally, the additional attributes defined by this stereotype are given. An attribute definition of a stereotype is named a tag definition, and their concrete assignment is a tagged value. Therefore, this can be found in the cell Tagged Values. In this exemplary case, the port stereotype defines an additional Boolean attribute inputQueue which is initially set to a false value. Each stereotype also has an informal semantics description. If the informal semantics description refers to a metaclass attribute or stereotype tag definition (attribute of a stereotype), this specific attribute name is underlined.
For clarity, there are auxiliary OCL operations defined which are re-used in the constraints of the stereotypes. The following OCL operation isStereotypedBy results in a true value if the given element is stereotyped by the specified stereotype classifier. Otherwise, it results in a false value.
UMLCS::isStereotypedBy(e: Element, s: Stereotype) : Boolean;
post: result=e.extension->exists(e | e.type=s)
The OCL operation isRemote checks whether two NamedElements are defined within the same namespace. This is used to check if an operationCall action calls an operation within the same agent or not, rendering it a Remote Procedure Call (RPC). This is also required to recognize access to local or remote variables. The operation isRemote returns a true value if both given elements acting as parameters are belonging to different namespaces.
UMLCS::isRemote(n1: NamedElement, n2: NamedElement) : Boolean;
post: result=n2.allNamespaces()->reject(n1.allNamespaces())->notEmpty() The result of the OCL operation random is a unique, randomized String value. This feature cannot be expressed in OCL. However, the returned String value must never be identical to a previous value for the same system. This operation is required to assign an identifier to implicitly defined elements within a model.
UMLCS::random() : String;
Notice, all stereotypes use a multiplicity of 0..1 for extension. This implies that there are UML modeling elements allowed without having the appropriate stereotype extension. This is intended to allow a combined notation between UML CS models as well as other profile elements or non-extended UML model elements within the same model repository. However, if model elements are used within a UML CS model without having the appropriate stereotype extension, the model semantics is undefined.
In this chapter, there is a specific notation used for UML metaclass elements: References to the UML metaclasses are capitalized, e.g. Event, Transition or Trigger. Attributes of the metaclasses are written in lowercase letters in the text and are underlined.
7.1.2 Queue Disciplines
The invocation of a behavior by means of signals is a sequence of occurrences according to the UML common behavior: a signal may have an associated Event, in particular a SignalEvent that is a specialized form of an Event. If the SignalEvent occurs, it may invoke a Trigger. This Trigger can invoke a behavior, e.g. on a state machine’s transition. According to the UML Superstructure document, events are placed into an input pool. The event is dispatched when it is taken from this input pool and causes a behavior, either directly or indirectly. It is removed from the input pool thereafter. It is a UML semantic variation whether an event is discarded if there is no appropriate trigger defined for them. In UML CS, this is specified as described in the state semantics in Section 7.3.3.
The UML input pool semantics for pending events is constrained in the UML CS profile. Currently, only SDL communication semantics is supported for signal events which is a single input queue with first-in first-out (FIFO) semantics for each active class. Nevertheless, the UML CS profile supports multiple different queue disciplines where queues are being used. For example, a port can have an input queue for incoming signals. The default setting is that all ports share a common input queue for the process they are associated. The default queue discipline is first-in first-out (FIFO) strategy. This is compatible with the process input queue model of SDL-2000.
However, the UML CS is not bound to this predefined queuing strategy. UML CS is intended to give extensibility and customizability to formal system descriptions. For example, the formal description technique ESTELLE supports a common input queue at the interaction points (port instances) as well as an individual queue for each port [Hog89]. The vision is that additional mapping implementations can map UML CS models to ESTELLE based descriptions of systems by means of the same models that can be mapped to SDL.
To enable multiple queuing strategies, a Scheduler interface is defined. A Scheduler can be assigned to ports and agent within the UML CS model. The modeling tool or mapping implementation shall also be aware of the specified Scheduler or shall be able to compile the Scheduler implementation (e.g. also specified by means of a UML CS model). For instance, a mapping implementation which is only able to map a UML CS model to an SDL specification should report an error if the scheduler differs from the SDL semantics – or it should be able to replicate the same semantics by means of various mechanism (e.g. creating port-emulating processes as a replacement for ports). This interface specifies the operations which shall be supplied by a Scheduler implementation.
7.1 Introduction
<<interface>>
Scheduler Operations
+addSignal(in receivedSignal: signal[1])
+retrieveSignal(in signalList: signal[1..*], in saveList: signal[0..*]):signal
Figure 62: Interface Definition of Scheduler
As depicted in Figure 62, a Scheduler is an interface. If a queue discipline will be defined, it must implement this Scheduler interface. The Scheduler defines two operations: addSignal and retrieveSignal. The detailed BehavioralFeature of the two operations are:
addSignal(in receivedSignal: signal[1]{is ordered=false; is unique=false}):
addSignal adds a received signal to its internal data structure (possibly a queue or pool). It is not restricted in any way how this is accomplished or maintained. It is also not specified if the input pool or queue has an infinite size or if it is limited. If it is limited, the replacement strategy is up to the concrete implementation of a Scheduler.
retrieveSignal(in signalList: signal[1..*]{is ordered=false; is unique=false}, in saveList:
signal[0..*]{is ordered=false; is unique=false}, return selectedSignal: signal [0..1]{is ordered=false; is unique=false})
retrieveSignal retrieves a single signal from its internal signal queuing structure. The signal is removed then. The first parameter signalList specifies a list of signal candidates which are allowed to be retrieved. An optional list of signals, the saveList, may be specified. This is a list of signal which are specified to be saved during this retrieval process until the next signal query is due. The result value selectedSignal returns the signal selected by the internal queue strategy. It is also possible to return an empty list. This means that a signal specified by the signalList has not been received so far.
Two pre-defined Schedulers are currently available and act as default values for a process and for a port: For processes, the sdlScheduler is assigned as the default Scheduler which has the same queue discipline as described in the dynamic semantics of SDL-2000. There is no Scheduler assigned to ports by default. That implies that all elements received are simply forwarded. This is intended for ports to have no event queue as in SDL-2000. As noted, if the schedulers are set to a different scheduler than the default assigned schedulers, this may impose different mapping techniques to SDL. However, the remainder of this thesis assumes that SDL-2000 input queue semantics are used.
7.1.3 Name resolution
Names used within a UML system specification shall be re-solved according to the UML name binding rules. However, the naming rules of UML are very loose and cannot be used for the naming used in other formal description techniques. The following stereotype constraints the available characters for names with respect to the SDL-2000 grammar for names.
NamedElement is extended by «namedElement» from the metaclass NAMEDELEMENT (FROM
KERNEL, DEPENDENCIES). A «namedElement» has the multiplicity one and is therefore a required stereotype. This stereotype serves the purpose that a coherent mapping to other formal description techniques is possible.