omg fundamental certification 4
TRANSCRIPT
1
UML 2-OMG certification course(OCUP Fundamental-3)
Instructor:
M.C. Ricardo Quintero
2
Dependencies
Def.- A dependency is a relationship between one (or several) source elements and one (or several) target elements.
The target elements are required for the specification or implementation of the source elements.
The source elements are incomplete without the target elements.
3
Notation & Semantics
A dependency is represented by a dashed arrow, where the arrow points from the dependent element to the independent element.
dependent independent
dependent
independent1
independent1
4
The metamodel for dependencies
Usage
Realization
SubstitutionClassifier
1*
+contract
1
{subsets supplier, subsets target}
*
*
1+substitution
*
{subsets ownedElement, subsets clientDependency}
+substitutingClassifier
1
{subsets client, subsets source}
OpaqueExpression(from Kernel) Abstraction0..1 0..1
+mapping
0..1
{subsets ownedElement}
0..1
DirectedRelationship(from Kernel)
Packageab leElement(from Kernel)
DependencyNamedElement
*1..*
+supplierDependency
*
+supplier
1..*
*1..*
+clientDependency
*
+client
1..*
5
Notation & Semantics
The type of dependency can be specified by using a keyword or stereotype.
6
Causes of Dependencies
A package depends on another package. A class uses a specific interface to another
class. If the interface is changed, then changes are also required in the class that uses this interface.
An operation depends on a class. (e.g. The class is used in an operation parameter).
7
Types of dependency relationships
Abstraction relationship: dependency relationship between model elements at various abstraction levels. Used with a stereotype. Default stereotypes: <<derive>>, <<trace>> and <<refine>>.
An abstraction relationship always has a mapping rule, specifying how the participating elements relate to one another (formal o informal).
The relationship can also be bidirectional, depending on the stereotype and mapping rule.
A special abstraction relationship is realization, a relationship between an implementation an its specification element.
8
Types of dependency relationships
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).
List
Sortable list
<<substitute>>
9
Types of dependency relationships 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
ListOrder<<use>>
10
Types of dependency relationships A permission relationship is a special dependency
relationship that allows the dependent element to access the independent element.
In the example Boss obtains the right to access the class Employee (including the private attribute salary).
Employee
+name-salary
Boss<<permit>>
11
Types of dependency relationships An example using the dependency relationship: a
design class and its optimized implemention. A text comment is often very helpful.
TariffingBoss<<derive>>
Optimized performance (i.e. The calculation
now uses locally replicated data)
12
Types of dependency relationship
Keyword/Stereotype Description
<<call>> 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)
<<Create>> Stereotype to usage relationship
The dependent element creates instances of the independent element. Is delined between classifiers
<<derive>> Stereotype to abstraction relationship
The dependent element is derived from the independent element
<<instantiate>> Stereotype to usage relationship
The dependent element creates instances of the independent element. Is defined between classifiers.
<<permit>> Keyword for permission relationship
The dependent element is permitted to use private of this independent element
13
Types of dependency relationship
Keyword/Stereotype Description
<<refine>> Steretotype to abstracton relationship
The dependent element resides on a more concrete semantic level than the independent element
<<trace>> Stereotype to abstraction relationship
The dependent element leads to the independent to trace semantic dependencies (e.g. From a use case to a class)
<<use>> Keyword fo usage relationship
The dependent element uses the independent element for its implementation
14
Checklist: dependency relationships1. In what context is the term “incomplete” used for a
dependency relationship?2. In which direction does the arrow point that indicates
the relationship between dependent and independent elements?
3. What is an abstraction relationship?4. What is a realization relationship?5. What is a substitution relationship?6. What is a usage relationship?7. What is a permission relationship?
15
Interfaces
Def.- Interfaces are special classifiers that use a set of features to specify a selected part of the externally visible behavior of model elements (mainly classes and components).
An implementation (or InterfaceRealization) relationship is a special realization relationship between a classifier and an interface.
The classifier implements the features specified in the interface.
16
The metamodel for interfaces
Realization(from Dependencies)
BehavioredClassifier
Property(from Kernel)
InterfaceRealization
*
1 +interfaceRealization
*
{subsets ownedElement,subsets clientDependency}
+implementingClassifier
1
{subsets client, subsets source}
Classifier(from Kernel)
Interface
*
*
*
+redefinedInterface*{subsets redefinedElement}
*
0..1+ownedAttribute
*
{ordered, subsets attribute, subsets ownedMember}0..1
{subsets classifier, subsets namespace, subsets featuringClassifier}
1
*
+contract 1
{subsets supplier, subsets target}
*
*
0..1
+nestedClassifier
*
{ordered, subsets ownedMember}
0..1 {subsets namespace, subsets redefinitionContext}
Operation0..1
* +interface0..1
{subsets redefinitionContext}
+ownedOperation
*
{ordered, subsets feature, subsets ownedMember}
17
Notation & Semantics
Interfaces are denoted the way that classifiers are denoted except that they carry the keyword <<interface>>.
A supplied interface is provided by a model element for use by another element.
A required interface is an interface requested by another model element.
18
Notation & Semantics
Intefaces specify not only operations, but also attributes.
Accodingly its metamodel, interfaces can have associations to other interfaces or classes.
If a classifier wants to implement an interface, it has to implement all operations defined in that interface.
19
Notation & Semantics
If the interface has attribute, the classifier has to behave as if it owned these attributes.
In the simplest case, it actually implements the attributes.
However, it is also sufficient to supply just the pertaining get() and set() methods.
20
Notation & Semantics
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.
21
Supplied Interface (arrow notation & plug notation)
Opel AstraspeeddrivingDirection
steer()changeGear()brake()accelerate()enableAutopilot()
CarspeeddrivingDirection
steer()changeGear()brake()accelerate()
<<Interface>>
Opel AstraspeeddrivingDirection
steer()changeGear()brake()accelerate()enableAutopilot()
Car
Opel Astra implements the interface Car.
Opel Astra provides the Car
interface
Provider
Provider <<interface>>Interface-A
Interface-A
22
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>>
23
Example extending and implementing interfaces
CarspeeddrivingDirection
steer()changeGear()brake()accelerate()
<<Interface>>
LuxuryCarusePhone()adjustSeatHeating()enableNavigationSystem()
<<Interface>>
Chauffeur+driver
JaguarspeeddrivingDirection
steer()changeGear()brake()accelerate()enableAutopilot()usePhone()adjustSeatHeating()enableNavigationSystem()
Opel Astra
Car
Chauffeur
LuxuryCar
+driver
RacingDriver
Car
Manager
LuxuryCar
24
Checklist: Interfaces
1. What specifies an interfaces?
2. What do you call the relationship between an implementing classifier and an interface?
3. What is a ball-socket notation?
25
Behavior basics
We are going to discuss the representation and description of general behavior in UML.
Behavior basics refers to the package CommonBehaviors::BasicBehaviors in the UML 2.0 specification.
It constitutes 10 percent of the test.
26
Introduction
The process of modeling involves a description of flows, time dependency, state changes, the processing of events and similar things.
UML is object-oriented, which means that behevior is nothing that exists independently, but always concerns specific objects.
The responsability for a behavior can always be put down in detail to an object.
27
Introduction
The description of behavior refers to the behavior of a classifier.
Four descriptions are available:State and protocol automatons (state
machines).Activities and actions. Interactions.Use cases.
28
Packages for dynamic modeling in the metamodel
Interactions UseCasesStateMachinesActivities
CommonBehaviors
Classes
Actions
Behavioral descriptions
29
Introduction
The package CommonBehaviors defines the fundamental concepts used to describe behavior and corresponding relations with structural elements.
Every behavior results from actions of at least one object and causes the participating objects to change their states.
30
Two forms of behavior
Executing behavior: is directly connected to an object that processes this behavior (host) and to another object that caused this behavior (invoker).
The execution of this behavior is triggered by calling a behavioral feature of an object, where this call is made by another object or an event or by creating a new object.
31
Two forms of behavior
Emergent behavior: refers to the interactions among different participating objects. It is an abstraction and summary of the behavior of several single objects or a set of objects.
This form of behavior doesn’t give a clue as to which object trigger or process what.
32
The metamodel for basic behaviorClassifier(from Kernel)
Class(f rom Kernel)
BehavioralFeature
isAbstract : Boolean
Parameter(f rom Kernel)
BehavioredClassifier Behavior
isReentrant : Boolean
*
*
+redefinedBehavior
*
{subsets redefinedElem...
*
*0..1
+method
*
+specification
0..1
*
0..1 +ownedParameter
*{ordered, subsets ownedMember}
0..1
0..1
*
0..1+ownedBehavior
*
{subsets ownedMember}
0..10..1
+classifierBehavior
0..1
{subsets ownedBehavior}
0..1
0..1 *
+context
0..1 *
OpaqueBehavior
body : String [1..*] {ordered}language : String [0..*] {ordered}
FunctionBehavior
33
The basic behavior metamodel
Behavior can be defined directly and independently as a class.
Behavior is specialization of Class. Behavioral description can be defined within another classifier (BehavioredClassifier) that owns this behavior who is its context.
Behavior can access the structural and behvarioal features of the context classifier.
34
The basic behavior metamodel
A BehavioradClassifier can own several behaviors, but each of these behaviors would then have exactly one context.
Similar, operations (behavioral features) can own behavior. The behavior is the implementation of the operation and the operation is the specification of the behavior.
The context is identical to that of the classifier, which owns this operation.
35
Checklist: behavior basics
1. What forms can behaviors have?
2. Can behaviors be defined independently as a class?
3. Can a classifier own behavior?
4. What is the context of a behavior?
36
The call model
Behavior in UML is event oriented by definition. The execution of behavior is always triggered
by an event. The execution of an event can trigger the
execution of behavior. New events may happen during each execution
of behavior. Two particular events occur always: the start
occurrence and the termination occurrence.
37
The notational model for executing behavior
Request
SendRequest
CallRequest
InvocationOccurrence
CallInvocationOccurrence
SendInvocationOccurrence SignalOccurrence
ReceiveOccurrence
CallOccurrence
+sendEvent +message +message +receiveEvent
1 1..* 11
38
The call model
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).
39
Event hierarchy
Event
TriggerEvent CallBehaviorEvent
SpontaneousEvent
ChangeEvent TimeEvent
ReceivingEvent
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.
40
Checklist: the call model
1. How is the execution of behavior triggered?
2. What is the Request object?
3. What are the two ways to invoke behavior?
4. Is the sender or the receiver responsible for selecting the behavior to be executed?
41
Behavior parameters
A behavior can have an arbitrary number of parameters.
Upon calling a behavior, the input parameters are made available to that behavior.
The output parameters are filled with values when the behavior terminates.
42
Behavior parameters
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.
43
Behavior parameters
The attribute isActive (of BehavioredClassifier) can be used to whether the classifier can have their own control flows (active objects).
44
Behavior parameters
If an object is not active, then its behavior is executed with other objects in a common control flow. In this case we can state how concurrent calls to a behavior should be handled: Concurrent: calls are executed independently of one
another and concurrently. Sequential: the participating instances have to police
the situation themselves (there is no coordination of concurrent calls).
Guarded: only one behavior is called at a time. Deadlocks have to be handled by the developer.
45
Checklist:Behavior parameters
1. How can be behaviored classifiers be defined as active objects?
46
Activity Diagrams
The topics refer to the following metamodel areas: Package: Activities::BasicActivities
Nodes Edges (flows) Actions (basic only) Control nodes.
This topic area constitutes 20 percent of the test.
47
Definition
An activity describes the sequence of actions based on control models and object flow models.
An activity contains edges and activity nodes-special actions
An action is an abstract class. Specific subclasses are also defined in UML. They are described in the so-called Action Semantics.
48
Notation & Semantics
An activity is represented by a rectangle with rounded corners including nodes and edges of the activity. The name of the activity appears at the top left of the rectangle.
An activity is derived from Class so activities themselves can be generalized.
49
Notation & Semantics
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.
50
Example of an activity
ProducedBottles[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 ProductionProduced Bottles:BootlesNew Six-Pack:Six-Pack
Six-Pack
ActionsPins
(input or output parameters of
actions)
keywords
Activity input parameter Activity output
parameter
Declaration of activity parameters
Decision node
51
Types of activity nodeActivityNode
ExecutableNode ControlNode
ActivityParameterNOde
CallBehaviorAction
ActionPin
ObjectNode
52
Predefined actions
The kinds of action are predefined in UML. Examples: Calling a behavior (e.g. Another activity). Calling an operation. Sending a receiving signals. Creating, deleting and changing objects.
An example of specific action is CallBehaviorAction. The action calls another behavior (another activity or a state machine). Is the case of our example.
Other could be CreateObjectAction.
53
ActivityEdge
The edges in an activity (ActivityEdge) are divided into control flow edges and object flow edges.
Both edges types are equal as far as the notation –a straight line with an open arrowhead.
54
The metamodel for activity edges
ControlFlow ObjectFlow
RedefinableElement(from Kernel)
ActivityNodeActivityEdge
*
1 +outgoing
*+source
1
1
*+target
1 +incoming
*
*
+redefinedElement
*
{redefines redefinedElement}
Activity
*
0..1+edge
*
{subsets ownedElement}
+activity
0..1
{subsets owner}
55
Connector edge
It can easily happen in activity diagrams that you will have to draw and edge across the entire diagrams.
To ensure easy reading of the diagram, we could introduce connectors.
A connector is used to split an edge. It’s only a notational means and doesn’t influence the underlying model.
56
Notation for connectors
A
...
A
57
NodesActivityNode
ExecutableNode ControlNode
ActivityParameterNode
CallBehaviorAction
ActionPin
ObjectNode
Actions
Object nodes
Control nodes
58
Practice
Activity diagrams can be used for graphical representations of the kinds of flows that are, for instance, described in use cases.
Activity diagrams allow you to represent even very complex flows that include many exceptions, variants, jumps and iterations, and still remain clear and understandable.
59
Checklist: Activities
1. What does an activity represent?
2. What does an action represent?
3. What are pins?
4. What kinds of edge are there?
5. What kinds of activity node are there?
60
Token flow
The semantics of an activity is based on a token flow.
More specifically, control tokens or object tokens flow between nodes over edges.
61
Token flow
These flows obey the following elementary rules:An action can start only if tokens are available
at all incoming edges (implicit synchronization; and semantics).
When an action terminates, a token is made available at all outgoing edges (implicit splitting; and semantics).
62
Token flow
(Continue...) elementary rules:A token flows from one action to the next if
The token is made available at the outgoing action. The leading action is ready to take the token. And the rules allow the edge to accept the token
flow.Every edge has a condition referred to as a
guard that has to be true in order to be able to transport tokens. The default is true.
63
The metamodel for activity edges
ControlFlow ObjectFlow
RedefinableElement(from Kernel)
ActivityNodeActivityEdge
*
1 +outgoing
*+source
1
1
*+target
1 +incoming
*
*
+redefinedElement
*
{redefines redefinedElement}
Activity
*
0..1+edge
*
{subsets ownedElement}
+activity
0..1
{subsets owner}
ValueSpecification
1
+guard{subsets ownedElement}{default value is true}
64
Token flow
There are two types of edge: control flow edges and object flow edges.
Their notation is identical.
65
Control flow- “and” semantics
A
CB
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
66
Object Flow-”and” semantics
A
CB
A B
C
Except by the fact that the actions have input and output pins, the
same rules from control flow apply
67
Object Flow-”or” semantics
A
CB
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.
68
Checklist: Token flow
1. What prerequisite must be met for an action to execute?
2. At which outgoing edges are tokens made available when an action terminates?
3. When does the or semantics apply to object flows?
69
Control Nodes
Definitions: 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.
70
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
71
Decision node
As soon as a token is supplied over the incoming edge, the guards at the outgoing edges are evaluated. The sequence of evaluation is not defined.
As son as a condition is true, the token traverses the respective outgoing edge
[X>=0]
[X<0]
72
Decision node
A decision can also define a behavior (i.e. A complex calculation). Every token arriving over the incoming edge is passed to the behavior before the guard are evaluated.
The result of such calculation can be accesed in the individual guards. The behavior must not have side effects (no object changes).
[X>=0]
[X<0]
<<decisionInput>>x=sqrt(y)
73
MergeNode The only purpose of a merge node is to connect
incoming edges and one outgoing edge. Nothing is calculated, and nothing is expected.
Merge and decision can be combined. The rhombus has several incoming and several outgoing control flows. The implicit sequence is important: first the merge and then the decision.
[X>=0]
[X<0]
74
The metamodel for control nodes
ForkNode JoinNode
ControlNode(from BasicActivities)
FlowFinalNode
FinalNode DecisionNode
Behavior(from BasicBehaviors)
*
0..1
*
+decisionInput 0..1
ActivityFinalNode
MergeNode
75
Checklist: control nodes
1. How many incoming edges can an initial node have?
2. What do several edges outgoing from one initial node signify?
3. What do several edges incoming into one final node signify?
4. What is the meaning of behavior (decision input) that can be defined by a decision?
76
Object node
Def.- An ObjectNode specifies that an object or a set of objects exists within a flow at a certain point in time.
Object nodes can be used in activities (activity parameter nodes) to serve as incoming or outgoing parameters.
Or can be used as incoming or outgoing parameters of actions (pins).
An object flow is a special edge which transports object tokens.
77
Notation & Semantics
An object flow is used to express that the objects involved are required by action nodes or are created or modified by them.
An action won’t start until the required object are present.
At the end of an action, the new or modified objects will be made available.
78
Notation & Semantics
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.
79
Notation for activity parameters
Make vechicle ready for rental
Vehicle: CarProtocol: HandOverProtocol
Vehicle ProtocolTake down car
condition... Take down car
condition
Input Parameter
Output ParameterParameter declaration
80
Notation & Semantics
A pin is always allocated to an action. There are to types of pins: input pins and
output pins. An action can have an arbitrary number of
pins.
81
The metamodel for pinsTypedElement
(from Kernel)
Pin
ValuePin
ValueSpecification(from Kernel)
0..1
1
0..1
+value1
OutputPin InputPin
Action
*
1
+/output*
{ordered, union,subsets ownedElement}
1
*
1
+/input*
{ordered, union,subsets ownedElement}
1
MultiplicityElement
82
Various notations for pins
Action Action
Object[state]
Object[state]
Action ActionObject type[state]
Action Action
An object flow without details
83
Various object typesActivity 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
84
Labeling object nodes
Action
Object Type[state]
Book vehicle
Booking
Action
Object Name: Type[state]
Identify Customer
Booker:Customer
85
Input pins and output pins without edges
ActionInput 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
86
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
87
Checklist:Object nodes
1. What happens at the input parameters of an activity when that activity is called?
2. What happens at the output parameters of an activity when that activity is terminated?
3. How many pins can an action have?
4. When may pins modeled alternatively as large rectangles with incoming and outgoind edges?