Omg Fundamental Certification 4

UML 2-OMG certification course (OCUP Fundamental-3) Instructor: M.C. Ricardo Quintero

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.

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

The metamodel for dependencies

The type of dependency can be specified by using a keyword or stereotype .

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).

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.

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>>

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
List Order <<use>>

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>>

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

Checklist: dependency relationships
In what context is the term “incomplete” used for a dependency relationship?
In which direction does the arrow point that indicates the relationship between dependent and independent elements?
What is an abstraction relationship?
What is a realization relationship?
What is a substitution relationship?
What is a usage relationship?
What is a permission relationship?

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.

The metamodel for interfaces

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.

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.

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.

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

Checklist: Interfaces
What specifies an interfaces?
What do you call the relationship between an implementing classifier and an interface?
What is a ball-socket notation?

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.

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.

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.

Packages for dynamic modeling in the metamodel Behavioral descriptions

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 .

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 .

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 .

The metamodel for basic behavior

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.

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.

Checklist: behavior basics
What forms can behaviors have?
Can behaviors be defined independently as a class?
Can a classifier own behavior?
What is the context of a behavior?

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 .

The notational model for executing behavior Request SendRequest CallRequest InvocationOccurrence CallInvocationOccurrence SendInvocationOccurrence SignalOccurrence ReceiveOccurrence CallOccurrence +sendEvent +message +message +receiveEvent 1 1..* 1 1

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).

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.

Checklist: the call model
How is the execution of behavior triggered?
What is the Request object?
What are the two ways to invoke behavior?
Is the sender or the receiver responsible for selecting the behavior to be executed?

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 .

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.

Behavior parameters
The attribute isActive (of BehavioredClassifier ) can be used to whether the classifier can have their own control flows (active objects).

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.

Checklist:Behavior parameters
How can be behaviored classifiers be defined as active objects?

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.

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 .

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.

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

Types of activity node ActivityNode ExecutableNode ControlNode ActivityParameterNOde CallBehaviorAction Action Pin ObjectNode

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 .

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.

The metamodel for activity edges

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.

Notation for connectors A ... A

Nodes ActivityNode ExecutableNode ControlNode ActivityParameterNode CallBehaviorAction Action Pin ObjectNode Actions Object nodes Control nodes

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.

Checklist: Activities
What does an activity represent?
What does an action represent?
What are pins?
What kinds of edge are there?
What kinds of activity node are there?

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.

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).

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 .

The metamodel for activity edges ValueSpecification 1 +guard {subsets ownedElement} {default value is true}

Token flow
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 .

Checklist: Token flow
What prerequisite must be met for an action to execute?
At which outgoing edges are tokens made available when an action terminates?
When does the or semantics apply to object flows?

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.

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

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]

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)

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]

The metamodel for control nodes

Checklist: control nodes
How many incoming edges can an initial node have?
What do several edges outgoing from one initial node signify?
What do several edges incoming into one final node signify?
What is the meaning of behavior (decision input) that can be defined by a decision?

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 .

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.

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

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.

The metamodel for pins

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

Checklist:Object nodes
What happens at the input parameters of an activity when that activity is called?
What happens at the output parameters of an activity when that activity is terminated?
How many pins can an action have?
When may pins modeled alternatively as large rectangles with incoming and outgoind edges?

http://www.jasondeoliveira.com	485
http://www.roth-soft.de	116
http://www.slideshare.net	19
http://wahoo.atsva.com	8
http://dotnet-architecture-jdo.blogspot.com	7
http://test2.roth-soft.de	2
http://translate.googleusercontent.com	1

Omg Fundamental Certification 4

by iscrquinter on Aug 30, 2007

Accessibility

Categories

Tags

Upload Details

Usage Rights

7 Embeds 638

Statistics

Omg Fundamental Certification 4 — Presentation Transcript