The static structure or architecture of a specification gives information on which entities take part in the description and which entities are communicating with each other. It further allows logical and hierarchical (de-)composition of closely or loosely coupled entities. This section describes the structural mapping by defining stereotyped extension to the UML metaclasses. This also enables a mapping to SDL.
In this section, the following UML metaclasses are extended by stereotypes: Package, Class, Operation, Interface, Signal, Generalization, Port, Connector, InformationFlow and InformationItem.
The main structuring element of a definition is an agent. An agent is either a system, block or process whereas a system is a special block. An agent may contain other agents except for a process that may contain only processes. A block executes its embedded state machines concurrently, whereas the embedded state machines of a process are executed using interleaving on transition base.
C
LASSThe following graphical elements mainly apply to the specification of class (diagrams). All agents, which are a kind of system, block or process, are stereotyped extensions from the metaclass Class.
UMLNODE TYPE UMLNOTATION REFERENCE
NamedElement
- no specific notation -
7.3.33 NamedElement
UMLCSSTEREOTYPE UMLMETACLASS
«namedElement» NamedElement (from Kernel)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context NamedElement inv: self.name->notEmpty() inv: isConformant(self.name)
namedElement::isConformant(n: String, i: Integer): Boolean let ch: String = n.substring(i, i+1) in
if ch->size()=0 then result=true
else if letter->exist(ch) then result=isConformant(n,i+1) else result=false
A name must only consist of uppercase or lowercase Latin letters, decimal digits or underscore ‘_’. A name must not be empty and must contain at least a letter or the underscore ‘_’.
This stereotype is a required extension.
7.2 Structure
7.2.1 Package
A package is extended by «package» from the metaclass PACKAGE (FROM KERNEL). A «package»
gives a common namespace to all its contained definitions.
Semantics
A «package» gives a common namespace to all its containing agents and definitions. This allows a logical grouping of the agents and of all operations, signals, attributes being defined. Therefore, a package enables re-using of previous specifications. Furthermore, a package restricts the visibility of attribute and operations to agents that are specified outside the package (see the package visibility modifier for attributes and operations).
The ownedMember attribute specifies the contained types of agents, variables and signals. The nestedPackage defines further contained packages.
7.2.2 System
The System is extended by «system» from the metaclass CLASS (FROM COMMUNICATIONS). A
«system» specifies the outermost block of the specification. All specifications are only allowed within a «system» with the the exception of packages which must not be part of a system definition.
UMLNODE TYPE UMLNOTATION REFERENCE
Package
<<package>>
samplePackage
7.3.37 Package
UMLCSSTEREOTYPE UMLMETACLASS
«package» Package (from Kernel)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Package
inv: self.name->notEmpty()
inv: self.visibility=VisibilityKind::public inv: self.packageMerge->isEmpty()
Package merging is not supported.
UMLNODE TYPE UMLNOTATION REFERENCE
Class <<system>>
sampleSystem
13.3.8 Class
UMLCSSTEREOTYPE UMLMETACLASS
«system» Class (from Communications)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Class A system is not an active class and therefore
Semantics
A «system» is the UML CS representation or description of a system. A system defines the outermost block of the specification. A system type of a class is a singleton class. That is, exactly one system must be defined if no package is defined. The system separates the environment from its contained set of agents. Signals can be conveyed to the border of the system through the system’s port associations and the defined interfaces.
The nestedClassifier attribute consisting of classes extended by block or process specifies all contained agents within the system. Remaining elements in the nestedClassifier attribute are part of this system and define – depending on their stereotype – a data type, an interface or a signal.
ownedAttribute defines the system-visible variables of this system. The ownedConnector and ownedPort define the channels and ports at system level. ownedOperation defines system visible operations. If superClass is not empty, the system inherits its properties from a parent system (see Section 7.2.8 for details on generalization). Use of packages is defined using PackageImport notation.
7.2.3 Block
The Block is extended by «block» from the metaclass CLASS (FROM COMMUNICATIONS). A block is an agent to allow logical separation or composition of processes. Blocks are not required to have a direct physical correspondence on the target system. Blocks provide notational means to allow hierarchical structuring and to retain clearness and manageability of the specification.
inv: self.isActive=false
specifies no behavior. There must be a name assigned. A system must only contain processes or blocks. There is only one system instance allowed.
UMLNODE TYPE UMLNOTATION REFERENCE
Class <<block>>
sampleBlock
13.3.8 Class
UMLCSSTEREOTYPE UMLMETACLASS
«block» Class (from Communications)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Class
A block agent may contain blocks and/or processes but no system.
7.2 Structure
Semantics
A «block» gives a logical structure to its contained agents. Communication with its containing parent is enabled by communicating with its environment. The environment as an agent within this block conveys signals to its parent block (or system) or inside this block. All agents nested in this block are executed concurrently. A block is an explicit definition of an agent type. Instantiation of this type are deployed within a composite structure.
Variables and operations declared in a block have its scope according to its visibility specified:
• Public (+): the attribute or operation is visible to all other agents.
• Private (-): the attribute or operation is visible only to its owning agent.
• Protected (#): the attribute or operation is visible only to its owning agent and to all agents being a specialization of the owning agent.
• Package (~): the attribute or operation is visible only to agents defined in the same package.
The term visibility includes the fact that neither the variable nor the operation can be read, written, accessed, referenced or called by an agent that is not included in the visibility scope.
The nestedClassifier attribute consisting of classes extended by block or process specifies all contained agents within the block. Remaining elements in the nestedClassifier attribute are part of this block and define – depending on their stereotype – a data type, an interface or a signal. ownedAttribute defines the block-visible variables of this system. The ownedConnector and ownedPort define the channels and ports at block level. ownedOperation defines block-visible operations. If superClass is not empty, the block inherits its properties from a parent block (see Section 7.2.8 for details on generalization). Single generalization of block agents is supported. That is, a specialized block agent can add ports, processes and new blocks. Re-definition (overwriting) of agents is not allowed.
Specialization of block agents must follow the Liskov-substitution principle (described in more detail in Section 7.2.8). Use of packages is defined using PackageImport notation.
7.2.4 Process
The Process is extended by «process» from the metaclass CLASS (FROM COMMUNICATIONS). A process defines behavior by specification of an enhanced communicating finite state machine.
forAll(c | isStereotypedBy(c,block) or isStereotypedBy(c, process))
UMLNODE TYPE UMLNOTATION REFERENCE
Class 13.3.8 Class
UMLCSSTEREOTYPE UMLMETACLASS TAGGED VALUES
«process» Class (from Communications) self: Pid
sender: Pid offspring: Pid parent: Pid
Semantics
A «process» is an active class that communicates with its environment by means of signals. The communication is done through specified interaction points, namely ports. A process owns an observable behavior. The definition of a process is done by the specification of an enhanced finite state machine. That is, the state machine defined in a process may own variables and assigns values to them. The state machine also has the ability to receive signals and to send signals to other agents which belong to its environment. This enables inter-process communication between the instances of the distributed system. If a process agent contains another process, an interleaved concurrency scheme for execution of the processes is applied.
Different to passive classes (for instance, signals), a process may also react to the reception of signals if it is specified to do so. Passive classes are only allowed to react on a signal reception with a behavior. This may introduce effects such as race-conditions. Variables and operations declared in a process have their scope according to their specified visibility:
• Public (+): the attribute or operation is visible to all other agents.
• Private (-): the attribute or operation is visible only to its owning agent.
• Protected (#): the attribute or operation is visible only to its owning agent and to all agents being a specialization of the owning agent.
• Package (~): the attribute or operation is visible only to agents defined in the same package.
The term visibility includes the fact that neither the variable nor the operation can be read, written, accessed, referenced or called by an agent that is not included in the visibility scope.
The self tag definition is the process identification value of type Pid assigned by the executing (virtual) machine. This value is unique within the system and is read-only. This value unambiguously specifies one process within the system and does not change during the lifetime of the execution run of the system. However, it is not guaranteed that a process gets the same process identification assigned in each run of the system. The concrete value is lost after termination of the system. The sender contains the Pid of the process from which a signal has been received most recently. It is undefined if no signal has been received. offspring holds the Pid of a created agent by this agent. parent contains the Pid of the agent that has created this agent. All values are read-only.
The nestedClassifier attribute consisting of classes extended by process specifies all contained process agents within the process. Remaining elements in the nestedClassifier attribute are part of this process and define – depending on their stereotype – a data type, interface or signal. ownedAttribute defines at least (depending on the visibility modifier) process-visible variables of this system. The ownedConnector and ownedPort define the channels and ports at process level. ownedOperation
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Class
A process agent must only contain other processes if any. Multiple inheritance is not allowed. A process agent must have a classifierBehavior of type stateMachine.
7.2 Structure
defines process operations. If superClass is not empty, the process inherits its properties from a parent process (see Section 7.2.8 for details on generalization). Single generalization of process agents is supported. That is, a specialized process agent can add ports and processes. Re-definition (overwriting) of agents is not allowed. Specialization of process agents must follow the Liskov-substitution principle (described in more detail in Section 7.2.8). Use of packages is defined using PackageImport notation.
7.2.5 Operation
An Operation is extended by «operation» from the metaclass OPERATION (FROM COMMUNICATIONS).
A method defines its behavior by means of a state machine or activity. The default visibility of an operation is protected. This implies that the operation is only visible to the agent where it is declared and to its owned agents.
Semantics
An «operation» owns a parameterizable behavior that is its method. The method’s behavior is specified by a state machine or an activity. An operation can be invoked through the activity CallOperationAction, as described in Section 7.4.6. Operation invocation is only possible if the visibility rules apply and the operation is within the scope of the calling process. The operation invocation is done synchronously. That is, the calling process is suspended until the invoked method
UMLNODE TYPE UMLNOTATION REFERENCE
UMLCSSTEREOTYPE UMLMETACLASS
«operation» Operation (from
Communications)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Operation inv: isStereotypedBy(self.class, process) or
isStereotypedBy(self.class, block) or isStereotypedBy(self.class, system) or isStereotypedBy(self.class, package) inv: self.raisedException->isEmpty()
An operation must not have any pre-, body-, or postconditions constraints applied. The behavior must be specified by either a state machine or an activity.
The owner of an operation can only be a package or agent. Exceptions shall not be defined.
has completed its activity. After termination of the invoked behavior, the return value is passed back to the calling process which is then resumed.
Variables and operations declared in an agent have their scope according to their specified visibility:
• Public (+): the attribute or operation is visible to all other agents.
• Private (-): the attribute or operation is visible only to its owning agent.
• Protected (#): the attribute or operation is visible only to its owning agent and to all agents that are a specialization of the owning agent.
• Package (~): the attribute or operation is visible only to agents that are defined in the same package.
The term visibility includes the fact that neither the variable nor the operation can be read, written, accessed, referenced or called by an agent that is not included in the visibility scope.
The ownedParameter attribute defines the formal parameters of the operation and its associated method. The method defines the behavior of this operation and shall only associate a state machine or an activity.
7.2.6 Signal
A signal is extended by «signal» from the metaclass SIGNAL (FROM COMMUNICATIONS). A «signal» is a specification of a type of information for send request instances communicated between processes.
The receiving process handles the signal instance according to its specified behavior. Data values can be carried by a send request and passed onto it. The send invocation event that has caused the request can convey information by the signal which is represented as attributes of the signal instance. Signals are defined independently of the processes handling the signal, but within the visibility scope.
UMLNODE TYPE UMLNOTATION REFERENCE
Signal <<signal>>
sampleSignal
13.3.23 Signal
UMLCSSTEREOTYPE UMLMETACLASS TAGGED VALUES
«signal» Signal (from Communications) priority: Integer = 0 sender: Pid
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Signal
inv: self.general->size()<=1
inv: self.extension_signal.priority>=0 and
self.extension_signal.priority<256 inv: self.ownedOperation->isEmpty()
The optional priority attribute defines a possible precedence of this signal. A higher value specifies a higher priority.
The tagged value sender represents the sender process identification that has executed the output statement sending this signal.
7.2 Structure
Semantics
A «signal» triggers a behavior in the receiver in an asynchronous way. That is, the sender does not get a response to its sent signal. The sender of a signal will not block waiting for a response but continues its execution immediately. A process specifies that its instances will be able to receive that signal by declaring a reception associated to a given signal. The process will respond to it with the designated behavior.
The priority can be specified with a value to a signal. However, the semantics of the priority value is up to the port scheduling algorithm that is being used. With SDL semantics by default, this value is ignored by the process where the signal has been received. The concrete range of possible priority values is chosen independently from any existing priority rules.
The sender is the process identification of the process that has sent the signal by invoking an output action (see Section 7.4.5). This value is implicitly set by the executing machine when the output is executed. A signal can be specialized and further attributes can be added.
The ownedAttribute attribute defines the attributes of this signal. The general attribute defines the generalized signal.
7.2.7 SignalList
A signal is extended by «signalList» from the metaclass SIGNAL (FROM COMMUNICATIONS). A
«signalList» is a defined composition of several signals.
Semantics
A «signalList» specifies a list of several signals and groups them under a single name. It can be used as shorthand to define multiple signals on a channel. A «signalList» cannot be used in a SignalEvent or Output.
The ownedSignal tag definition specifies the set of signals it represents.
UMLNODE TYPE UMLNOTATION REFERENCE
Signal 13.3.23 Signal
UMLCSSTEREOTYPE UMLMETACLASS TAGGED VALUES
«signalList» Signal (from Communications) ownedSignal: Signal [0..*]
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Signal
inv: self.ownedOperation->isEmpty() inv: self.ownedAttribute->isEmpty() inv: self.general->size()=0
context signal
inv: self.ownedSignal->asSet()=ownedSignal
A signalList shall only contain other signals.
Generalization is not supported.
ownedSignal shall not contain duplicates.
7.2.8 Generalization
A generalization is extended by «generalization» from the metaclass GENERALIZATION (FROM
KERNEL, POWERTYPES). A «generalization» implements object-orientated features to the profile.
Specializing a process allows re-definition of states and adds transitions and actions to the derived process. A specialization can be applied to processes, blocks, systems, ports and primitives.
Semantics
For specialization, the Liskov substitution principle applies which provides a guideline to sub-typing any existing type [LW93]:
Let q(x) be a property provable about objects x of type T. Then q(y) should be true for objects y of type S where S is a subtype of T.
In other words, all operations with a reference to the base class should be completely transparent to the type of the inherited object. It should be possible to substitute an object of one type with another within the same class hierarchy. Inheriting classes must not perform any actions that will invalidate the assumptions made by the base class.
Let M be a state machine defined by process with M = (S, T) and let M’ be a process generalized by M with a state machine M’ = (S’, T’). Let (S’’, T’’) be a set of states and transitions that specialize M, the following rules must apply:
These rules imply that for a specialization of a process, states and transitions cannot be removed. It is only allowed to add states and transitions to the specialized state machine. The observable behavior of a class to its generalized class must not differ.
When an operation is called which may be specialized from a base class object-oriented resolution applies. That is, when an operation call request is received, the class of the target object is examined whether it defines an operation with matching signature (its matching formal parameters). If such a
UMLNODE TYPE UMLNOTATION REFERENCE
Generalization 7.3.20 Generalization
UMLCSSTEREOTYPE UMLMETACLASS
«generalization» Generalization (from Kernel, PowerTypes)
OCLCONSTRAINTS INFORMAL CONSTRAINTS
context Generalization
Multiple inheritance is not supported on any type. Specialization is only possible between same types.
7.2 Structure
resolution. If not, the general (or parent) classifier is examined for a matching operation and so on up the generalization hierarchy. This resolution procedure is repeated until a method is found or the base agent of the system specification is reached. As this profile does not support multiple parent classes (multiple inheritance), there is only one single generalization look-up path to be examined. If a method is found in one of the ancestor classes, then this method is the result of the resolution process.
The general attribute defines the generalized agent; the specific attribute specifies the specialized agent.
7.2.9 Class
A Passive Class is extended by «class» from the metaclass CLASS (FROM COMMUNICATIONS). A
«class» defines a class for object instances that have no own thread of control and do not perform any activity upon instantiation. Invocation of a behavior can only be triggered from other active agents.
Instances of this class definition can be created by using CreateObjectAction (see Section 7.4.4). A passive class merely acts as a cohesive container for several operations for remote procedure calls.
Semantics
A passive «class» describes a collection of encapsulated instance variables and operations (methods) together with the implementation of those types. It is a cohesive package consisting of a particular kind of compile-time metadata for its instances. This is very similar to an object data type described in Section 7.7. However, different from an object type this class must not define infix operations.
A passive «class» describes a collection of encapsulated instance variables and operations (methods) together with the implementation of those types. It is a cohesive package consisting of a particular kind of compile-time metadata for its instances. This is very similar to an object data type described in Section 7.7. However, different from an object type this class must not define infix operations.