The UML graphical notations

UML provides several types of diagrams which allow to capture different aspects and views of the system. The semantics of UML diagrams is defined by the metamodel layer that is described in the next section. A detailed description of each UML notation is out of the scope of this chapter. We will give, instead, a brief description of them, lingering on those diagrams and their corresponding features that have been used in the thesis.

Class Diagram Class Diagrams (CDs) describe the static structure of the system, i.e., in terms of classes and their relationships. This UML notation comes from a melding of OMT, Booch and class diagrams of most other object-oriented methods. The Class Diagram depicted in Figure 2.1 models for example a customer order. A class is a description of a set of objects with similar structure, behavior, relations and semantics. At run time execution objects as instances of classes are used and all objects of a class share the same list of attributes and operations. The scope of an attribute can be at instance level, in this case each object holds its own value for the attribute, or at class level, in this case there is just one value of the attribute for the entire class: class-scope attributes are shown underlined while instance-scope attributes are shown not marked. A class, e.g., class Order in the Figure 2.1, is drawn as a rectangle in which the upper part contains the class name. Names of abstract classes, i.e., not instantiable classes, are written in italics (e.g., class Payment). In case the attributes and the operations of the class are shown as well, the rectangle is divided into three parts: the upper part contains the

class name, the central part contains the (partial) list of the attributes and the bottom part contains the (partial) list of the operations. Structural relations between two classes are specified by associations and generalizations.

In particular, a binary association between two classes is represented by a line connecting the classes and an optional association name, e.g., association sale depicted in Figure 2.1 represents a binary association between classes Customer and Order.

The UML metamodel distinguishes the association itself from its ends: binary associations have exactly two association ends. Different adornments specifying association properties, such as navigability, aggregation, role names, qualifier and multiplicities, may be attached to the association ends.

An association is navigable if, given an object at one end, it is possible to get to objects at the other end directly, usually because of the existence in the source object of some references to target objects. Navigability in one direction is graphically represented with an arrowhead attached to the end of the line representing the association, e.g., like association paid by in Figure 2.1; while the simple line without any arrows represents the navigability in both directions.

A special kind of binary association is the aggregation that represents a part-of relationship. There are two forms of aggregation: 1) a weaker form of aggregation, whose intended meaning is to distinguish the whole from a part and that is graphically denoted as a diamond attached to the association end closer to the class representing the whole. 2) A stronger form of aggregation, i.e., the composition, expressing that the part is strongly owned by the composite and may not be part of any other object. Composition association is graphically depicted as a filled diamond attached to the association end closer to the composite class.

Another adornment that may be attached to an association end is the rolename that indicates the role played by the class attached to the end of the path near the rolename. For example in Figure 2.1 the rolename line item, attached to an association end of the aggregation between classes Order and OrderDetail, allows to represent an order as an aggregation of lines, each line specifying in detail each ordered item. The rolename represents a pseudo-attribute of the source class and it provides a name for traversing from a source instance across the association to the target instance(s), e.g., by using the dotted syntax we can represent an order o∈ Order as a set of order details o.line item ={od1, ..., od_n}.

A qualifier is an attribute of an association, whose values allow to partition the set of instances associated with an instance across the association. A qualifier is shown as a small rectangle attached to the end of an association and close to the class that it connects to, see in Figure 2.1 the qualifier order #. An instance of the source class together with a value of the qualifier select a partition in the set of the target instances on the other end of the association.

An association end may be characterized by multiplicity specifying the number of target instances that may be associated with a source instance. The multiplicity is a (set of) range(s) of non negative integers denoted as lower-bound..upper-bound. If a single integer value is specified, then the integer range contains exactly the single integer value. In addition, the star character (“*”) may be used either for the upper bound to denote an unlimited

CHAPTER 2. BACKGROUND 15 upper bound or alone with the same meaning of 0..*. For example, in Figure 2.1 an order detail specifies a single item and, vice-versa, a single item can be mentioned in zero or more orders.

Classes of a CD can be related by a generalization/specialization relationship which is used to model inheritance between classes. The subclass inherits all the properties of the superclass, i.e., attributes, operations, associations.

Moreover, additional properties can be specified in the subclass. Generalization is graphically represented by a solid-line path from the subclass to the superclass with a large hollow triangle at the end of the path, close to the superclass; e.g., in the CD of Figure 2.1 classes Credit, Cash and Check are subclasses of the class Payment.

Interaction diagrams There are two forms of Interaction diagrams: Collaboration Diagrams and Sequence Diagrams (SDs). A Collaboration Diagram shows an interaction among a set of participants and it is used to emphasize the roles played by the participants and their relationships. A SD shows instead an explicit sequence of communications among the participants of an interaction. Both the types of Interaction Diagrams convey the same underlying information described by the Collaboration metamodel and they can be used either at specifi-cation level, in which participants are generic objects of classes, or at instance level, in which participants are objects with its own identities.

SDs are more suitable for real-time specifications and for representation of complex scenarios in which it is important to represent explicitly the temporal aspects. They have been used in a variety of Object-Oriented methods under the names of interaction diagrams, message trace diagrams, event trace diagrams, and, in general, they can be considered as successors of message sequence charts [47]. A SD shows an interaction arranged in time sequence: usually, the time is represented by the vertical axis of the SD and it proceeds downward while the participants are represented by the horizontal dimension. In Figure 2.2 an example of SD modeling a possible interaction among a set of tasks performing a distributed synchronization is depicted. Each object participating to the interaction modeled by a SD is represented by a vertical dashed line called lifeline together with a rectangular box (i.e, object symbol) superscribed with the string: Objectname ‘/’ ClassifierRolename ‘:’ Classifiername, where Objectname is name of the object, ClassifierRolename is the name of the role played by the object in the interaction and, finally, Classifiername is the name of the class the object belongs to. In general, it is not required a complete specification of the string written above for each participating object. For example, the name of the role can be omitted if there is only one role to be played by the objects of a given class, as well as the name of the object when it represents a generic object of a given class¹. In Figure 2.2 the participants to the interaction are: a generic object belonging to the Synchronizer class, the three tasks task1, task2, task3 belonging to classes TK node1, TK node2, TK node3, respectively, and a generic object aAgent of class Agent. The task1 plays the role of Master while task2 and task3 play the role of Slave. When the participating objects interact also with an external environment then the latter can be included into the SD and it is represented by an actor symbol.

A message exchanged between two objects in the SD is graphically represented by an arrow from the sender’s

1A generic object can also be named as “aClass”, where “Class” is the name of the class it belongs to.

:Synchronizer

Figure 2.2: Example of UML Sequence Diagram.

to the receiver’s lifeline. Depending on the type of action performed by the sender that caused the message to be sent the arrow corresponding to the message can be of different type. Messages caused by synchronous actions are drawn as filled solid arrowhead arrows, while messages caused by asynchronous actions are drawn as stick arrowhead arrows. Among the latter, messages representing return from procedure calls are further distinguished and depicted as dashed arrows. Moreover, message arrows can be either drawn horizontally, indicating the time required to send the message is “atomic” (instantaneous message), or slanted downward, indicating that the message requires some time to arrive (timed message). If an object is created in consequence of the execution of a create action, then the creation message arrow points to the created object symbol (e.g., the message labeled as init in Figure 2.2); whilst if an object is destroyed in consequence of the execution of a destroy action then the destruction message arrow is followed by a large “X” along the lifeline of the destroyed object (e.g., the message labeled as exclude).

Message arrows are labeled with the name of the operation to be invoked or with the name of the signal to be raised. The arrow may also be labeled with a sequence expression, consisting of a dot-separated list of

CHAPTER 2. BACKGROUND 17

Figure 2.3: Example of UML Statechart.

sequence terms followed by a colon, to show the sequence of the messages in the overall interaction and/or condition/iteration expression.

Sequence numbers/names are often omitted in SDs, as the physical location of the arrow shows the relative sequences; however they are useful for example to emphasize concurrent messages as is the case of the branch-ing messages labeled as 2.a: include, 2.b: include and 2.c: include characterized by the same sequence number and by concurrent threads of control. Branching points are shown by multiple message arrows leaving a single point: branch construct may represent either concurrency or conditionality depending on the labels attached to the messages belonging to the branch. The branch depicted in Figure 2.2, consisting of the two messages la-beled as [failed=true]restart and [failed=false]exclude, represents conditionality being the conditional messages characterized by mutual exclusive conditions.

A set of arrows in a SD can be enclosed in a rectangle and labeled with an iteration clause: the iteration indicates that the set of messages belonging to the iteration can occur multiple times. UML does not prescribe any format neither for iteration clauses nor for conditional clauses, they can be expressed in pseudo-code or in an actual programming language, e.g., in Figure 2.2 the iteration clause is equal to 1..n meaning that the sequence of messages enclosed in the rectangle is repeated n times. Note that this specification may correspond to either a while-true statement or a for statement depending on meaning assigned by the modeler to n.

StateCharts Statecharts (SCs) are the graphical representation of UML State Machines, they are basically Harel [40] statecharts with minor modification. The execution of a state machine is based on the run-to-completion step algorithm in which an event instance can only be dequeued and dispatched if the processing of the previous current event instance is fully completed. In particular, a state machine is characterized by the following components: an event queue, that holds incoming event instances until they are dispatched; an event dispatch mechanism, that selects and dequeues event instances from the event queue and, finally, an event pro-cessor that executes dispatched events.

SCs are used to model the behavior of class objects and they describe possible sequences of states and ac-tions through which objects can proceed during their lifetimes as a result of reacting to occurrence of discrete events (e.g., signals, operation invocations)[64]. An example of two statecharts representing the behavior of an application process and its error detector (i.e., the watchdog mechanism), are depicted in Figure 2.3.

A SC basically consists of states and transitions. States represent situations during the life of the object in which either it satisfies some condition, or it performs some action or it waits for some event to occur. A simple state, such as states wait, compute, error in SC Application and states unused, paused, count and expired in SC Watchdog of Figure 2.3, is drawn as a rectangle with rounded corners subdivided in two compartments separated by a horizontal line: the upper part contains the name of the state, the lower part may contain actions, that are performed while the represented object is in the state, deferred events and internal transitions. Initial states are instead special states (pseudo-states), and they are drawn as a small solid filled circle.

Actions within a state are denoted as action label / action expression where action label allows to determine whether the action specified by action espression is an entry action or a do action or an exit action. Entry actions are performed upon entry to the state (e.g., action continue in state compute in SC Application), do actions correspond to an ongoing activity performed as long as the object is in the state or until the computation specified by the action is completed (e.g., action counting down in state count of SC Watchdog), exit actions are instead performed upon exit from the state (e.g., action timeout in state count of SC Watchdog).

The events received by an object are results of actions either carried out by the object itself or by other objects interacting with the former. In particular, deferred events are those events that do not cause a change of the state:

they are simply retained to be processed subsequently. For example, in the SC Watchdog the event heartbeat in state paused is a deferred event, meaning that while the watchdog is in a pause state potentially can consume an heartbeat event but is not able to process it so that the event is retained to be processed when the watchdog is in another state.

A transition indicates that specific actions will be performed when a specified event occurs provided that a certain condition is satisfied. In general in a SC, a transition is labeled as event name ( parameter-list ) [ guard-condition ] / action expression. A transition is triggered by at most one event that represents the reception of either a signal or a request to invoke a specific operation, in this latter case a list of parameters are associated that conform to the operation’s list of parameters. The guard provides control over the firing of the transition:

CHAPTER 2. BACKGROUND 19 it is represented as boolean expression and, when not explicitly specified, is assumed always true. When the transition fires, an action (or a sequence of actions) may be performed. When the transition has not an explicit trigger event is called completion transition and it fires only after all the events and actions present in the current state are processed and completed.

There are two main types of transitions: internal and outgoing. Internal transitions, as deferred events, do not cause a change of state when fire but, unlike deferred events, the event that triggers the transition is processed and, when specified, the associated action(s) are executed.

Firing of an outgoing transition causes an exit from the state and an entry into the target state, possibly the source state itself in case of self-loop transition. Self-loop transitions are different from internal transitions:

indeed, while the firing of the formers cause the execution of entry and exit actions, the firing of an internal transition do not cause neither an entry in the state or an exit from the state.

StateCharts may represent other important constructs, such as synchronization states, stub states, composite states, sub-machine states and pseudo-states that are mainly meant for a hierarchical definition of the underlying state machines, and for introducing concurrency inside a state machine or between different state machines. We omit to describe such features, since we have not dealt with them explicitly, while we focus on the relationships between StateCharts and Class Diagrams and between Statecharts and Sequence Diagrams for a better under-standing of the second part of the thesis devoted to the automatic translation of UML Sequence Diagrams into Generalized Stochastic Petri Nets for their combined use with the translated StateCharts. StateCharts are related to both Class Diagrams and Sequence Diagrams. A CD defines attributes, operations and relations for a class of objects: this static structure is fundamental for the inter-object behavior (represented by Sequence Diagrams) and for the intra-object behavior (represented by StateCharts).

Let us assume to have a set of StateCharts representing interacting objects; among the actions executed by an object there exist some actions that invoke operations of the called object or that generate signals that can be perceived by other objects. The invocation of an operation (or the generation of a signal) provokes one or more event occurrences that are perceived by other objects.

The interactions between StateCharts, and the relationships between StateCharts and Class Diagrams, can be exemplified by looking at two SCs of Figure 2.3: the application, whose behavior is modeled by the SC Appli-cation, and the watchdog, whose behavior is modeled by the SC Watchdog, are two communicating processes.

Both the application and the watchdog can be considered as two objects belonging to two different classes, e.g., AP and WD respectively. In particular, let us assume class WD be characterized by an attribute timer and by two operations init(timervalue) and confirm(). A first type of interaction between the two objects occurs when, being both the application and the watchdog in their corresponding initial states wait and unused, the application initializes the watchdog setting up the watchdog timer. This interaction is carried out through the call action initiate that invokes the operation init(timervalue) in order to set the timer attribute to the value timervalue. The invocation of such operation provokes the occurrence of a setup event in the watchdog and the processing of such

event brings the watchdog in the paused state. Other interactions between the application and the watchdog occur through either the causal chain: action continue - operation confirm() - event start, when the application confirms the settings and the watchdog starts its count-down to expiration, or the causal chain: action Iamalive - signal kick - event heartbeat, when the application sends an “Iamalive” to the watchdog in order to reset its timer to the initial value.

On the other hand, a message exchanged between two objects in a SD is caused by the execution of an action (e.g., a call action when an operation is invoked, a send action when a signal is generated), that causes the reception of an event in the receiver object. Looking at the SCs of Figure 2.3 we can represent their interactions

On the other hand, a message exchanged between two objects in a SD is caused by the execution of an action (e.g., a call action when an operation is invoked, a send action when a signal is generated), that causes the reception of an event in the receiver object. Looking at the SCs of Figure 2.3 we can represent their interactions