Uml Omg Fundamental Certification 3

1

UML 2-OMG certification course(OCUP Fundamental-2)

Instructor:

M.C. Ricardo Quintero

2

Constraints

Def.- A constraint is an expression that constrains the semantics of an element, and it must always be true.

This can be a formal expression (OCL) or a semiformal or human-language formulation

3

Constraints-Notation & Semantics

Constraints are written between curled brackets ({}).

They can be written directly after a textual element or within a comment symbol.

Constraints can have names. The syntax for constraints is define as follows:

‘{‘ [<name> ‘:’]<Boolean expression> ‘}’ The xor constraint is predefined in UML and

can be graphically written between associations.

4

Example of constraintsCircle

radius:int {radius>0}

Boss

salary

Employee

salary

1assistant

{Salary:self.salary > assistant.salary}

Article

Warehouse

Store

{xor}

(OCL) constraint named “Salary”

xor constraint

5

Checklist: constraints

1. How is the name of a constraint written?

2. Which constraint is predefined in UML?

6

The metamodel for constraints

PackageableElement

Namespace

ValueSpecification

Constraint

*0..1 *

+/context

0..1 {union}

0..1 *

+namespace

0..1 {subsets context}

+ownedRule

*{subsets ownedMember}

0..1

1+owningConstraint

0..1

{subsets owner}

+specif ication

1

{subsets ownedElement}

Element

*

+constrainedElement

*{ordered}

7

Instance specification

Def.- An instance specification represents a concrete instance in the modeled system. The terms instance and object are used synonymously. A slot represents values for a structure element of an instance specification, such as an attribute value of an object.

8

Instance specification-Notation

An instance specification can be incomplete, which means that you don’t have to specify all values of the attributes of the pertaining class.

9

Instance specification-examples

license Plate:String“HH-OO 42”

license Plate:String=“HH-OO 42”

:Circle

name:String=“oott.mx”street:String=“Obregon 53”city:String=“Culiacan,MX”phone:String=“7134567”

InstanceSpecification

InstanceSpecification(alternative notation)


10

The metamodel for instance specifications

PackageableElementElement

ValueSpecification

Classi fier


0..1 0..1

+owningInstanceSpec

0..1

{subsets owner} +speci fication

0..1{subsets ownedElement}

0..*

+classifier

0..*

ValueSpecificationSlot

1 *

+owningInstance

1 {subsets owner}

+slot

*{subsets ownedElement}

0..1*

+owningSlot

0..1

{subsets owner} +value

*{ordered,

subsets ownedElement}

StructuralFeature

1

+definingFeature

1

11

Checklist: instances specifications

1. How does a slot differ from an instance specification?

12

Classifier

Def.- A classifier is an abstract class that classifies the instances with regard their features.

A classifier is a namespace and a type, and it can be generalized (i.e. inherited).

13

The classifier metamodel

DirectedRelationshipNamedElement NamespaceRedefinableElement Type

RedefinableElement

isLeaf : Boolean = false

*

+/redefinedElement

*{union}

General ization

isSubsti tutable : Boolean

NamedElement

Classi fier

isAbstract : Boolean = false

*

+redefinedClassifier

* {subsets redefinedElement}

*

+/redefini tionContext

*{union}

1 *

+speci fic

1{subsets source, subsets owner}

+generalization


1

+general

1 {subsets target}

*+/general *

*

+/inheri tedMember

*{subsets member}

Property 0..1*

+classifier

0..1

{subsets redefini tionContext}+/attribute

*

{union,subsets feature}

Or features

14

Classifier-Notation and Semantics

Concrete classifiers in the UML metamodel include, for example, class, component and use cases.

Classifier

Class UseCase Component

15


A classifier associates a set of features. Concrete features are operations and attributes.

Though the metamodel class classifier is abstract, a notation is nevertheless defined in the notation. This notation is inherited by the subclasses and used by them.

Some of the notation will eventually be overwritten.

16


aClass<<class>>

aUseCase<<use case>>

aComponent<<component>>

aClass aUseCase aComponent

Notation

AlternativeNotation

The standard notation for Classifier is a rectangle that contains the namen with the name of the subclass in guillemets above it

17


A classifier is abstract if its description is incomplete. Abstractness is a feature of classifiers.

The name of abstract classifiers are written in italics. Optionally, you can add the property string {abstract}.

18

Classifiers-Examples

GeomFigure

Circle Rectangle

{abstract} Circleradius : int {radius>0}

show()enlarge()

An abstract class called GeomFigure

A class with compartments for name, attributes and operations

19

Features

Def.- A feature describes a structural or behavioral characteristic of a classifier’s instances.

A structural feature is an abstract metaclass, which describes a typed structure of an instance of a classifier. To prevent a structural feature from being changed,

you can specify that it be {readonly}. In the oposite, a changeable structural feature can be

specified with {unrestricted}.

20

Features

A behavioral feature is an abstract metaclass, which means that an instance of a classifier can respond to requests by calling certain behavior.

More specifically, parameters can be passed to requests and returned.

A behavior can also thrown an exception. An operation is a common example of a

behavioral feature.

21

The metamodel for featuresRedefinableElement

StructuralFeature

isReadOnly : Boolean = f alse

TypedElement

ParameterDirectionKind

ininoutoutreturn

<<enumeration>>

Feature

isStatic : Boolean = f alseClassifier

*0..*

+/f eature

*{union}

+/f eaturingClassif ier

0..* {union}

Namespace

[0..1]

MultiplicityElementMultiplicityElement

TypedElement

ValueSpecification

Parameter

direction : ParameterDirectionKind = in/ def ault : String

0..1

0..1

+owningParameter0..1

{subsets owner}

+def aultValue0..1 {subsets ownedElement}

BehavioralFeature

0..1 *

+ownerFormalParam

0..1

{subsets namespace} +ownedParameter

*{ordered,subsets ownedMember}

Type

*+raisedException *

22

Features

A parameter is the specification of an argument that is passed by a behavioral feature or returned by this behavioral feature.

A parameter has a type, a multiplicity and a direction.

Optionall you can state a default value and a name.

23

Features

The direction of a parameter is specified by use of the keywords in, out, inout or return.

The default value in is assumed if no direction is stated.

In The caller passes the parameter value to the behavior

Out The behavior passes the parameter value to the caller

Inout The caller first passes the parameter value to the behavior, which returns it to the caller

Return Similar tu out, except that return explicitly specifies the return values of the behavior

24

Features-notation

The syntax of a parameter looks like this:

[direction] name:type [multiplicity] [=default] [{property string}]

The property string for a parameter can be one of the values known for properties, such as {ordered} and {nonunique}.

25

Checklist: features

1. How are a feature, a structural feature, and a behavior feature related?

2. What direction statements can be used for parameters?

26

Operations

Def.- An operation is a behavioral feature of a classifier, which specifies name, type, parameters and contraints for the call of the behavior.

In addition to the features and operation inherits from BehavioralFeature, the operation can: Have preconditions and postconditions and a body condition. Specify whether it will change the state of the pertaining instance

(see isQuery). Have a type.

27

The metamodel for operationsBehavioralFeature

[0..1][0..1]

Constraint

Parameter

Type

Operation

isQuery : Boolean = false/ isOrdered : Boolean/ isUnique : Boolean/ lower : Integer/ upper : UnlimitedNatural

*

+redefinedOperation


0..1

*+preContext

0..1

{subsets namespace}

+precondition

*{subsets ownedRule}

0..1

*+postContext

0..1

{subsets namespace}

+postcondition

*{subsets ownedRule}

0..10..1

+bodyCondition

0..1

{subsets ownedRule}+bodyContext

0..1

{subsets namespace}

*

0..1 +ownedParameter

*+operation

0..1

{subsets namespace}

0..1

+/type

0..1

*

+raisedException

*

28

Notation and Semantics

Although the syntax of operations is described somewhat imprecisely in the UML specification, the notation should look like this:

[visibility]name(parameter list)[:type][{property string}]

29

Operation Property

{query} can be used to specify a property value for the operation.

This characterizes an operation that has no side effects, that is, an operation that does not change the state of the object and other objects such as get() operations

30

Pre-Post-Body conditions

The precondition must always be true before the operation is executed.

The postconditions have to be true after the exection.

The body condition has to be true during the execution.

If an exception occurs during operation execution, the postconditions must not be true.

31

Difference between body condition and postcondition The difference between body condition

and postcondition is that the invariant (of the body condition) can be owerwritten (redefined) by inheritance.

A postcondition merely lets you add postconditions. The latter is also true for a precondition.

32

Examples

getPosition(return x:int, return y:int) Enlarge(byFactor:Real):GeomFiguer +addPhone(phone:String) #release():contractStatus

33

Checklist: operations

1. What is the type of an operation?

2. Explain pre-, post-, and body condition.

3. What happens to the condition if an exception occurs?

34

Properties

Def.- A property is a special structural feature that if it belongs to a class, is an attribute.

(However, it can also belong to an association. But more about this later).

35

Notation & Semantics

An attribute is a (data) element that is equally contained in every object of a class and that is represented by an individual value in each object.

Attributes have no identity outside the object to which they belong.

Attributes are fully under the control of the objects of which they are part.

36

Attribute metamodel

The UML meatamodel does not have a metaclass for attributes.

An attribute is a role that a property can take on.

UML 2.0 no longer strictly separates attributes and association ends. In other words, the representation of an attribute in a class and its representation as a navigable association are the same.

37

The metamodel for properties

[0..1]

StructuralFeatureClassifier

AggregationKind

nonesharedcomposite

<<enumeration>>

Relationship

[0..1]

Classifier

Classifier

Operation

ValueSpecification

Class

0..1 *

+class

0..1 {subsets namespace,subsets redef init ionContext}

+nestedClassif ier

*{ordered, subsets ownedMember}

*

+/superClass

*{redef ines general}

0..1 *

+class

0..1{subsets redef initionContext,subsets namespace,

subsets f eaturingClassif ier}

+ownedOperation

*{ordered,

subsets f eature,subsets

ownedMember}

Type

Property

isDeriv ed : Boolean = f alseisReadOnly : Boolean = f alseisDeriv edUnion : Boolean = f alse/ def ault : Stringaggregation : AggregationKind = none/ isComposite : Boolean

*

+redef inedProperty

*{subsets redef inedElement}

0..1 +/opposite0..1

*

+subsettedProperty

*

0..1 0..1

+owningProperty

0..1

{subsets owner}

+def aultValue

0..1


0..1 *

+class

0..1 {subsets classif ier,subsets namespace,


+ownedAttribute

*{ordered,subsets attribute,

subsets ownedMember}

Association

isDeriv ed : Boolean = f alse

1..*+/endTy pe 1..*

{ordered}

0..1*

+owningAssociation

0..1{subsets association,subsets namespace,


+ownedEnd

* {ordered,subsets memberEnd,

subsets f eature,subsets ownedMember}

0..12..*

+association

0..1

+memberEnd

2..*

{ordered, subsets member}

*

+nav igableOwnedEnd

* {subsets ownedEnd}

38

Example Attributes

Customer Bookings-bookings

Customer

-bookings:Bookings[0..*]

0..*

An attribute as either an

association or an attribute notation

Class Customer owns the property bookings in both

cases

39

Attribute full sintax

[visibility][/] name [:type][multiplicity][=initial value][{property string}]

Where: Visibility:

+ public: it can be seen and used by all. -private: only the class itself can get hold of private attributes. #protected: both the class itself and its subclasses have access. ~ package: only classes from the same package can access these

attributes.

40



Where: / simbolizes a derived attribute. Multiplicity is in square brackets (e.g. [1..*]). Default value specifies the initial value of the attribute.

41



Property string indicates a modifier that applies to the attribute: {readonly}: the property can be read but not changed. {union}: the property is a union of subsets. {subsets <property>}: the property is a subset of <property>. {redefines <property>}: the property is a new definition of

<property> (overwritten by inheritance).

42



Property string indicates a modifier that applies to the attribute: {ordered}, {unordered}: an ordered or unordered set. {unique}, {nonunique} or {bag}: a set may or may not contain

several identical elements. {sequence}: an ordered list (array; identical elements permited). {composite}: the property is an existence-dependent part and

others.

43

Attribute

If the multiplicity is greater than 1, then the attribute represents a set.

Additional information can be specified for the order (isOrdered) and uniqueness (isUnique). (see Multiplicity metamodel).

Depending on the combination of these two pieces of information, we obtain differente collection classes (see next table).

44

Attribute – Order & Uniqueness

IsUnique isOrdered Collection Class

Yes Yes Ordered set {ordered}

Yes No Set (default)

No Yes Ordered list {sequence}

No No {bag}

45

Ownership of properties

Customer Booking-bookings

0..*

-booker

1

Property bookings belongs to the Customer class (it is an attribute of

Customer, navigation from Customer toward Booking).

But what about the property booker? The class Booking knows nothing

about this property (see navigational direction)

46

The object model for the UML metamodel

c:Class

name=“Customer”

b:Class

name=“Booking”

p2:property

name=“bookings”

p1:property

name=“booker”

:Association

ownedEnd

memberEnd

memberEnd

ownedAttributetype type

47

Examples

name:String = ‘unknown’ birthDate:Date radius: Integer = 25 {readonly} /age:Integer {age=today-birthDate} -versionNo:Integer time:DateTime::Time dynamArray[*] {ordered} name:String[1] firstName:String[0..1] firstNames:String[1..5]

48

Checklist: Properties

1. What do a property and an attribute have in common?

2. How do an attribute and an association relate?

3. What property strings can a property have?

4. Who owns a property?

5. Explain the meaning of “tuple” in the context of an association.

49

Associations

Def.- An association describes a set of tuples of typed instances.

The multiplicity of an association specifies how many objects of the opposite class an object can be associate with.

If this number is variable, we state a range, that is, the minimum and maximum values.

A minimum of 0 means that the relationship is optional (the relationship exists, nevertheless, but the number of elements is 0).

50

The metamodel for association

[0..1]


AggregationKind

nonesharedcomposite

<<enumeration>>

Relationship

[0..1]

Classifier

Classifier

Operation

ValueSpecification

Class

0..1 *

+class


+nestedClassif ier


*

+/superClass


0..1 *

+class



+ownedOperation

*{ordered,


ownedMember}

Type

Property


*

+redef inedProperty


0..1 +/opposite0..1

*

+subsettedProperty

*

0..1 0..1

+owningProperty

0..1

{subsets owner}

+def aultValue

0..1


0..1 *

+class



+ownedAttribute



Association


1..*+/endTy pe 1..*

{ordered}

0..1*

+owningAssociation



+ownedEnd



0..12..*

+association

0..1

+memberEnd

2..*


*

+nav igableOwnedEnd


51

Association-Notation & Semantics

Roles and Constraints: an association is represented by a straight line between the participating properites. At least two properties participate in an association.

Customer CustomerAccount*

belongs to1

BookingPosition

-bpos+account

11

An association/composition with names, reading direction, multiplicities, role names, and visitiblity information

52

Association name

Each association can be given a name an a reading direction within a small filled triange.

The reading direction does not refer to the navigability of the association.

At either end of the association, role names can be added to describe in more detail what roles the objects have within the relationship.

These roles are the names of properties (for example, attributes), which belong to the association or to one of the participating classes.

53

Association name

Is possible to add visibility information to either end of the association.

If an association end is declared private (-), then the object itself (i.e. the operations of this object) can use the association, but neighboring classes have no access (like a private attribute).

54

Property strings

Properties can have the property strings {union} and {subsets}

Company Employees

Managers

Workers

/employee{union}

workers*

{subsets employee}

bosses1..*

{subsets employee}

The attribute employee in the class Company is a derived union, which means that you will also find the

corresponding subsets in the class model: bosses and workers are subsets of employee, jointly

representing the union

55

N-ary association

An association can have more than two ends (fewer than two is invalid).

Traveler Seat

Train

56

Association generalization

Since associations are special classifiers, they can be generalized or inherited.

The number of association ends has to remain equal and the corresponding classes have to be compliant to one another (they either are identical or have direct or indirect generalization relationship).

The multiplicity of the superassociation can be restricted but not expanded.

57

Example - Association generalization

Company Employees

+employee

MyCompany

1..*+me{redefines employee}

58

An aggregation and composition

An aggregation is an association representing a whole-parts hierarchy.

An aggregation is used to describe how something whole is logically composed of its parts.

A composition is a strict form of aggregation, where the existence of its parts depends on the whole. The whole is the owner of its parts.

59

An aggregation and composition

An aggregation or composition is a property of the metamodel class property (i.e. a property of the property).

The type is an enumeration called AggregationKind with the literals none, shared (which refers to aggregation) and composite.

So, formally, neither aggregation nor composition is a form of relationship of its own.

60

A rombus symbolizes an aggregation

Whole Part0..1 *

consists of

61

Association and composition

Whole Part

Aggregation

Existentially dependent part

Composition

62

Composition VS AggregationCar Engine

10..1

Boat

1has

has0..1

Car Engine10..1

Boat

1has

has0..1

The Engine object concurrently belongs to a Car object and a Boat object

Here not !

63

Composition

If a variable multiplicity for the parts is specified (e.g. 1..*), then they don’t have to be created together with the aggregate; they can be created later.

From the time of their creation, however, they normally belong immeediatly to the whole.

Similarly, they can be destroyed before the aggregate at any time.

However, generally the latest they are destroyed is when the aggregate is destroyed.

64

Navigation option

A directed association is an association that lets you navigate from one of the participating association roles to the other.

It has an open arrowhead at the side of the class to which we can navigate.

Both multiplicity and role names can also be denoted at the side to which we cannot navigate, in this case the property belongs to the association rather than to a class.

65

Navigation exclusion

To explicitily exclude a navigation direction, we put a small cross to the side of the class that shouldn’t be navigated to.

66

Possible forms of interpretation for navigability (UML 1.x & 2.0)1. All arrows and crosses means that all navigation

options are explicitly denoted.2. No arrows and crosses means that there is no

statement on navigability. There is no way to tell the difference between some kind of navigation that may be present and some kind of unspecified navigation.

3. Arrows only for associations with a navigation direction means that there is no unspecificied navigability, that is, no arrow has a meaning equal to the cross representation. This is the common interpretation of the UML metamodel diagrams.

67

Defining association directions: unidirectional and bidirectional relationships

Invoice Addresscontains 1

Station Carcontains 1

Insurance Contributorhas 1

68

Reading direction VS navigation direction The navigation direction tells us whether

an object can access another object. The reading direction is used to

understand the association name

69

Checklist: associations

1. What does an association describe?

2. What are the semantics of an aggregation?

3. What are the semantics of an composition?

4. What are the forms of interpreting the navigability?

70

Classes

Def.- A class describes a set of instances that have some features, constraints and semantics. A class is a special classifier.

71

The metamodel for Class

[0..1]


AggregationKind

nonesharedcomposite

<<enumeration>>

Relationship

[0..1]

Classifier

Classifier

Operation

ValueSpecification

Class

0..1 *

+class


+nestedClassif ier


*

+/superClass


0..1 *

+class



+ownedOperation

*{ordered,


ownedMember}

Type

Property


*

+redef inedProperty


0..1 +/opposite0..1

*

+subsettedProperty

*

0..1 0..1

+owningProperty

0..1

{subsets owner}

+def aultValue

0..1


0..1 *

+class



+ownedAttribute



Association


1..*+/endTy pe 1..*

{ordered}

0..1*

+owningAssociation



+ownedEnd



0..12..*

+association

0..1

+memberEnd

2..*


*

+nav igableOwnedEnd


72

Notation and Semantics

Classes are represented by rectangles that carry just the name of the class or the class name plus attributes and operations.

These three compartments (class name, attributes and operations) are separated by a horizontal line.

This notation stems from the classifier superclass.

73

Notation variants for attributes and operations

Class

attribute1attribute2

operation1()operation2()

Class


Class


Class


Class


74


Instances are never created from an abstract class. An abstract class is intentionally incomplete, thus forming the basis for other subclasses that can have instances.

An abstract class is represented like a regular class, but the name of the class is set in italics. Optionally, we can add the property string {abstract} below the class name.

75

Generalization

Def.- A generalization is an abstraction principle applied to hierarchically structure the semantics of a model.

A generalization is a relationship between a general classifier and a special classifier, where the special classifier adds more features (specialization) and behaves in a way compatible to the general classifier.

76

The metamodel for generalizationsDirectedRelationshipNamespaceRedefinableElement Type

*

+/redefinedElement

{union}

General ization

isSubsti tutable : Boolean

NamedElement

Classi fier


*

+redefinedClassi fier


*


*{union}

1 *

+speci fic


+generalization


1

+general

1 {subsets target}

*+/general *

*

+/inheri tedMember

*{subsets member}

0..1*

+classifier

0..1

{subsets redefinitionContext}

77


A generalization or specialization classifies features hierarchically; features with general meinings are allocated to general classifiers and special features are allocated to classifiers that area subclassifiers of general classifiers.

The features of superclassifiers are passed on to their subclassifiers (inheritance).

So a subclassifier has the features specified for it and the features of its superclassifiers (or overwrite them).

78

The notation for generalization

GeomFigure

Circle Rectangle Triangle

79


In UML, overwriting (redefining) features is controlled by the metamodel class RedefinableElement.

All metamodel classes that are subclasses of RedefinableElement can be overwritten in a generalization relationship.

The overwriting element stores a reference to the overwritten element.

For attributes, this relationship also transpires in the notation by the property string {redefines <property>}

80

The metamodel for redefinable elements

NamedElement NamespaceRedefinableElement Type

RedefinableElement

isLeaf : Boolean = false

*

+/redefinedElement

*{union}

Classi fier


*

+redefinedClassifier


*


*{union}

1 *

+speci fic


1

+general

1 {subsets target}

*+/general *

*

Property 0..1*

+classifier

0..1

{subsets redefini tionContext}+/attribute

*

{union,subsets feature}

81

Packages

Def.- A package is a collection of model elements that can be of arbitrary types and that are used to structure the entire model in smaller, easily manageable units.

Package can contain all elements that are derived from PackageableElement.

A package defines a namespace (the names of the elements in a package have to be unique).

Packages can contain other packages.

82

The metamodel for packagesPackageableElementNamespace

DirectedRelationship

PackageableElement

PackageMerge

Type

Package

0..1 *

+owningPackage

0..1

{subsets namespace} +ownedMember

*{redefines ownedMember}

1 *

+receivingPackage

1{subsets source,subsets owner}

+packageMerge


1

+mergedPackage

1 {subsets target}

*

0..1

+/nestedPackage *{subsets ownedMember}

+nestingPackage

0..1 {subsets namespace}

*0..1

+/ownedType

*{subsets ownedMember}

+package

0..1 {subsets namespace}

83


Packages can contain various model elements (e.g. classes and use cases).

They can be also contain other packages. A model element, such as a class, can be

used in several packages, but every class has its home package.

84


All other packages would merely mention it by its qualified name:package name::class name

This causes dependencies to form between the packages involved; a package uses classes of another package.

85

A package modelProduct Partner

Contract

Property

Life

Tariffing

Contract

86

Member notation-”contains” o “consists”

Contract

Tariffing Property Life

The member notation is not limited to packages, it can be used to represent the hierarchical structure of other elements, such as

classes residing in a package

87

Generalization VS Package merge

A package merge is a relationship between two packages, where generalization and redefinition are used to merge the content of the target (the general) package with the content of the source (the specific) package.

One important assumption of this merge is that equally named elements in different packages are based on the same concept.

88

A package merge

R

A

y:int

C

P

A

x:int

B

*aList

<<merge>>

The content of package P is merged into package R.

Next we are going to review the formally defined rules to do this

89

Merging rules (transformation rules)1. The merge relationship is converted into a package

import relationship, so private elements are not included in the package merge.

2. A new (empty) classifier is created in the source package (R) for each classifier in the target package (P) that does not exist in the source package. Then a generlization relationship for equelly named classifiers in the target package is defined between all the classifiers in the source package. All features of the superclassifier are redefined in the respective subclassifier.

90

Merging rules(transformation rules)3. Generalization relationships between classifiers in

the target package are transferred to the corresponding classifiers in the source package.

4. A subpackage by the same name is created in the source package for each subpackage in the target package, unless it already exists. Subsequently, a package merge relationship is defined between the equally named packages of both the source and the target packages.

91

Merging rules(transformation rules)

5. Package and element import relationships from the target package are transferred to the source package.

6. Finally, all elements from the target package that cannot be generalized are copied to the source package and equipped with the same relationships to the other elements.

92

The merge result

R(Merge-Result)

P::A

x:int

B

The content of package P is merged into package R.

Next we are going to review the formally defined rules to do this

P::B

A

y:intx:int{redefines x}

*aList

C

{redefines aList}

93

The package merge relationship in the UML metamodel The package merge relationship is used intensively to

structure the UML’s metamodel.

IntermediateActions

CompleteActivities

CompleteStructuredActivities

ExtraStructuredActivities

IntermediateActivities AssociationCla

sses

<<merge>>

SimpleTime InvocationActions

BasicInteractions

Fragments

<<merge>>

<<merge>>

StructuredActivities

<<merge>>

<<merge>>

<<merge>>

CompleteActions

<<merge>>

94

Checklist: packages

1. What does the generalization relationship have to do with packages?

2. What additional semantics for grouping property does a package have?

3. How does the package merge work?

Technology

Uml Omg Fundamental Certification 3