Omg Fundamental Certification 4

Post on 06-May-2015

6,069 views 3 download

Tags:

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?