Date post: | 06-May-2015 |
Category: |
Technology |
Upload: | ricardo-quintero |
View: | 9,605 times |
Download: | 1 times |
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)
InstanceSpecification
10
The metamodel for instance specifications
PackageableElementElement
ValueSpecification
Classi fier
InstanceSpecification
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
*{subsets ownedElement}
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
Classifier-Notation and Semantics
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
Classifier-Notation and Semantics
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
Classifier-Notation and Semantics
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
* {subsets redefinedElement}
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
{subsets ownedElement}
0..1 *
+class
0..1 {subsets classif ier,subsets namespace,
subsets f eaturingClassif ier}
+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,
subsets f eaturingClassif ier}
+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
Attribute full sintax
[visibility][/] name [:type][multiplicity][=initial value][{property string}]
Where: / simbolizes a derived attribute. Multiplicity is in square brackets (e.g. [1..*]). Default value specifies the initial value of the attribute.
41
Attribute full sintax
[visibility][/] name [:type][multiplicity][=initial value][{property string}]
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
Attribute full sintax
[visibility][/] name [:type][multiplicity][=initial value][{property string}]
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]
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
{subsets ownedElement}
0..1 *
+class
0..1 {subsets classif ier,subsets namespace,
subsets f eaturingClassif ier}
+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,
subsets f eaturingClassif ier}
+ownedEnd
* {ordered,subsets memberEnd,
subsets f eature,subsets ownedMember}
0..12..*
+association
0..1
+memberEnd
2..*
{ordered, subsets member}
*
+nav igableOwnedEnd
* {subsets ownedEnd}
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]
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
{subsets ownedElement}
0..1 *
+class
0..1 {subsets classif ier,subsets namespace,
subsets f eaturingClassif ier}
+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,
subsets f eaturingClassif ier}
+ownedEnd
* {ordered,subsets memberEnd,
subsets f eature,subsets ownedMember}
0..12..*
+association
0..1
+memberEnd
2..*
{ordered, subsets member}
*
+nav igableOwnedEnd
* {subsets ownedEnd}
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
attribute1attribute2
Class
operation1()operation2()
Class
attribute1attribute2
Class
operation1()operation2()
74
Notation & Semantics
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
isAbstract : Boolean = false
*
+redefinedClassi fier
* {subsets redefinedElement}
*
+/redefini tionContext
*{union}
1 *
+speci fic
1{subsets source, subsets owner}
+generalization
*{subsets ownedElement}
1
+general
1 {subsets target}
*+/general *
*
+/inheri tedMember
*{subsets member}
0..1*
+classifier
0..1
{subsets redefinitionContext}
77
Notation & Semantics
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
Notation & Semantics
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
isAbstract : Boolean = false
*
+redefinedClassifier
* {subsets redefinedElement}
*
+/redefini tionContext
*{union}
1 *
+speci fic
1{subsets source, subsets owner}
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
*{subsets ownedElement}
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
Notation & Semantics
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
Notation & Semantics
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?