A substitution relationship specifies that instances of the independent element can be substituted by instances of the dependent element at runtime. (e.g. When the elements implement the same interfaces).
A usage relationship is a special dependency relationship limited to the implementation and it doesn’t apply to specification. This means that the dependent element requires the independent element for its implementation.
More specifically, there can be no usage relationship between interfaces but ther can be a dependency relationship
An example using the dependency relationship: a design class and its optimized implemention. A text comment is often very helpful.
Tariffing Boss <<derive>> Optimized performance (i.e. The calculation now uses locally replicated data)
Types of dependency relationship Keyword for permission relationship The dependent element is permitted to use private of this independent element <<permit>> Stereotype to usage relationship The dependent element creates instances of the independent element. Is defined between classifiers. <<instantiate>> Stereotype to abstraction relationship The dependent element is derived from the independent element <<derive>> Stereotype to usage relationship The dependent element creates instances of the independent element. Is delined between classifiers <<Create>> Stereotype to usage relationship Is defined and specified from one operation to another operation, so that the source operation calls the target operation. The source can also be a class (the class contains an operation that calls the target operation) <<call>> Description Keyword/Stereotype
Types of dependency relationship Keyword fo usage relationship The dependent element uses the independent element for its implementation <<use>> Stereotype to abstraction relationship The dependent element leads to the independent to trace semantic dependencies (e.g. From a use case to a class) <<trace>> Steretotype to abstracton relationship The dependent element resides on a more concrete semantic level than the independent element <<refine>> Description Keyword/Stereotype
A classifier can implement several interfaces and also contain other properties.
In other words, an interface generally describes a subset of a classifier’s operations and attributes .
Supplied Interface (arrow notation & plug notation) Opel Astra implements the interface Car. Opel Astra provides the Car interface Provider Provider <<interface>> Interface-A Interface-A
Required Interface (arrow notation & plug notation) For a required interface, the requiring element has a usage relationship with the interface User <<interface>> Interface-A RacingDriver Car User Interface-A <<use>>
Example extending and implementing interfaces RacingDriver Car Manager LuxuryCar
When a behavior call is triggered by the receipt of a message rather than by an operation call, then this form of request is described by using signals .
Signals can be arranged in a specialization hierarchy (see next figure).
Event hierarchy Event TriggerEvent CallBehavior Event SpontaneousEvent ChangeEvent TimeEvent Receiving Event Exceptions are a special form of signals. Only active objects can receive signals. Signals always represent an asynchronous call behavior. The receiver of a signal is responsible for selecting the behavior to be executed.
The attribute isReentrant (of Behavior ) can be used to define whether the behavior can be called several times concurrently or whether one call to the behavior has to be terminated before another call for tha same behavior can be made.
An activity (like any behavior in UML) can also have parameters . Objects incoming to or outgoing from an activity model are referred to as the parameters of that activity.
Example of an activity Produced Bottles [empty] New Six-Pack Fill Bottles Label Bottles Bundle Pack Bottles [labeled] Bottles [empty] Bottles [filled] Bottles [filled] [knockOff] [continue] <<precondition>> Boolean expression <<postcondition>>Boolean expression Six-Pack Production Produced Bottles:Bootles New Six-Pack:Six-Pack Six-Pack Actions Pins (input or output parameters of actions) keywords Activity input parameter Activity output parameter Declaration of activity parameters Decision node
There are two types of edge: control flow edges and object flow edges .
Their notation is identical.
Control flow- “and” semantics A C B A B C Implicit splitting Once action A terminates, a control token is made available at both outgoing edges. After action A , actions B and C start concurrently Implicit synchronization Action C doesn’t start until tokens are available at both incoming edges. Actions A and B have to terminate first
Object Flow-”and” semantics A C B A B C Except by the fact that the actions have input and output pins, the same rules from control flow apply
Object Flow-”or” semantics A C B A B C A has only one output pin , wich means that the action supplies one object token . Outgoing are two edges . Which one of these edges the object token will select is not defined The model behavior cannot anticipated Actions A and B each supply an object token. But action C has only one input pin . Action C would be called twice .
InitialNode : the point of departure for an activity’s flow. A start node.
ActivityFinalNode : An activity’s end node which causes the defined flow to terminate.
DecisionNode : a control node with one or several outgoing edges, at which decisions are made based on certain conditions (i.e. at which of the continuing edges the token flow should continue).
MergeNode : a control node, at which each of several incoming token flows leads immediatly to a common outgoing token flow.
Notation & Semantics Initial Node When calling an activity, a control token is placed on each initial node . If an activity has several initial nodes, there will be several concurrent flows after an activity has been called. It is not mandatory for an activity to have an initial node It has at least one incoming edge, but no outgoing edge . The entire activity terminates as soon as a token reaches a final node, regardlees of how many other tokens are still within the activity. It is not mandatory for an activity to have a final node Final Node
Activity parameters can include the name of the object and optionally the object state within square brackets.
When an activity is called , object tokens are present at all input parameters .
When an activity terminates , there are object tokens at all output parameters .
If the corresponding object does not exist, then a null (or zero) token is created and can then be used for any object type
An initil node is normally not required when there are input parameters.
Notation for activity parameters Make vechicle ready for rental Vehicle: Car Protocol: HandOverProtocol Vehicle Protocol Take down car condition ... Take down car condition Input Parameter Output Parameter Parameter declaration
Various notations for pins Action Action Object [state] Object [state] Action Action Object type [state] Action Action An object flow without details
Various object types Activity Section from an activity Identify Customer Display Data Customer Person class Person/Customer Customer Person Object types and object states of output pins and their partners input pins don’t have to be identical , but it should be easy to derive the object type at the input pin from the incoming object types
Labeling object nodes Action Object Type [state] Book vehicle Booking Action Object Name: Type [state] Identify Customer Booker:Customer
Input pins and output pins without edges Action Input pin Output pin An output pin without continuing edges expresses that the pertaining action has an output parameter which, however, doesn’t play a role in the activity’s further flow
A special form of input pin: the value pin Create invoice Tarif.SALESTAX The notation adds a value specification, describing a value in the model, next to the pin. Value pins are used, for example, to model constants in activities