1 Kyung Hee University Constraints Spring 2001. 2 Kyung Hee University Graphical Notations Graphical notations are well suited for displaying structural

11

Kyung Hee University

ConstraintsConstraints

Spring 2001

22


Graphical Notations

Graphical notations are well suited for displaying structural

aspects of systems, but less effective for documenting the fine

details of a system’s specification. One disadvantage is that

graphical notation can quickly become very complex.

Graphical notations can be supplemented where necessary by

textual annotations which state properties that are not implied by

the diagram. Such annotations are known as constraints

A constraint is an assertion about a model element, often a class,

which states properties that must be satisfied in a legal model of

the system.

33


Graphical Notations (cont’d)

Constraints are written in UML in braces ‘{‘ and ‘}’ in or near the model

element that they describe. UML defines standard constraints for a handful of

common situations.

More general constraints can be written either in informal English, in a more

formal constraints language, or even using the notation of the target

programming language.

UML defines a constraint language, called the Object Constraint Language or

OCL

Figure 9.1 A constrained saving account

44


Standard Constraints

‘New’ and ‘Destroyed’ are simple examples of the standard

constraints defined by UML Two other commonly used standard

constraints describe properties of pairs of related associations

55


Standard Constraints (cont’d)

The subset constraint

The subset constraint can be applied to pairs of associations that link the same classes, and states that the set of links which are instances of one associations with a dependency arrow to which the constraint is attached

In general, this constraint means that if two objects are linked by an instance of the association at the tail of the dependency arrow, they must also be linked by an instance of the association at the head of the dependency arrow

66


Standard Constraints (cont’d)

The xor constraint

The xor constraint can be applied to pairs of associations that are connected at one end to the same class. It is used to specify that an instance of the shared class can not participate in both associations at the same time

Figure 9.3 The xor constraint

The xor constraint can be applied to pairs of associations that are connected at one end to the same class. It is used to specify that an instance of the shared class can not participate in both associations at the same time

77


Standard Constraints (cont’d)Standard Constraints (cont’d)

In general, this constraint means that an instance of the class that is connected to both the constraint associations can at any given time participate in a link from one of the associations or the other, but not both. Notice that this means that the multiplicity of the constrained associations must include the zero case.

88


The Object Constraint LanguageThe Object Constraint Language

The object constraint language

The standard constraint are useful in particular cases, but in order to handle the arbitrary constraints that can arise on modeling a constraint specification language is required. OCL, the Object Constraint Language, is a text-based formal language which allows completely general constraints to be written for the elements appearing in UML models, particularly in class diagrams.

99


Standard Constraints (cont’d)Standard Constraints (cont’d)

OCL has to provide three essential capabilities

The ability to specify which model element is being constrained

The ability to navigate through a model to identify other objects which may be relevant to the constraint being defined

The ability to make assertions about the relationships between the context object and any objects retrieved by means of navigation expressions

1010


The Context of A ConstraintThe Context of A Constraint

Every OCL constraint has a context, which is simply the model el

ement that is being constrained

Sometimes, the context of a constraint will be a class

If context is a class, this can be done by writing the constraint in t

he class symbol near the element constrained

Figure 9.5 A simple constraint

1111


The Context of a Constraint (cont’d)The Context of a Constraint (cont’d)

Constraints can also be written in textual form, instead of being shown on a diagram. In this case, the context needs to be explicitly recorded

The keyword ‘self’ in the textual form of the constraint simply refers to the current context object

This notation is clearly chosen to resemble the notation used in languages such as Java and C++ for accessing features of classes

SavingsAccount

self.balance > 0 and self.balance < 250000

1212


Navigation ExpressionsNavigation Expressions

The use of constraints is not limited to stating the invariants of classes considered in isolation.

Many constraints place restriction on relationships between model elements

Informal links to gain access to other objects

Navigation expressions

1313


Navigation Expressions (cont’d)Navigation Expressions (cont’d)

A self-association on the employee class shows who in the company is managed by whom. A qualified association allows individual employees to be accessed by a unique payroll number

1414



The association between the person and company classes represents the relationship of a person working for the company

Following links

The basic form of navigation involves following links from one object to another

To show navigation, role names on the association end opposite the context object are written after the name of that object, using dot notation for attributes

Department

Self.staff

1515


Navigation Expressions (cont’d)Navigation Expressions (cont’d) If an association has no role name, the name of the class at the further end of the association is used instead, with a lower-case initial letter

The class name cannot be used in this way if there is any danger of ambiguity, for example if there are two associations between a pair of classes. In this case, suitable role names must be added to the associations to allow the required navigation expressions to be formed unambiguously

Company

Self.department

1616



Collections

A navigation expression denotes the object that are retrieved by following the specified links from the context object

Depending on the multiplicities of the associations traversed, however, the number of such objects may vary

Person

Self.department

Person

Self.manager

1717



In general, in OCL a navigation expression that can return more that one object is said to return a collection, whereas others simply return single objects

Iterated traversal

Navigation expressions are not limited to following a single association. More complicated paths through a diagram can be described by writing a sequence of role or class names, separated by dots.

Company

Self.department.staff

1818



Traversing qualified associations

Qualified associations can be used in navigation just as well as ordinary ones, but they provide an additional capacity for locating individual objects.

When navigating towards the qualifier, there is no difference between a qualified and an unqualified association.

Person

Self.employer

1919



When navigating in the opposite direction, however, the qualifier provides a way of picking out a particular employee whose payroll number is known.

This notation can be freely combined with subsequent navigation or selection of attributes. For example, the following expression returns the manager of the employee with payroll number 314159.

Company

Self.employee[314159]

Company

Self.employee[314159].manager

2020



Using association classes

Navigate from an instance of an association class to the objects at the ends of the association, using role names or class names as normal.

Grade

Self.contract.employee

Person

Self.contract.grade

2121


Objects and CollectionsObjects and Collections

OCL is designed so that in many situations the distinction between individual objects and collections, or between different kinds of collections, can be ignored.

Operations on objects

Apart from collections, the types available in OCL consist of basic types representing boolean values, real and integer numbers and strings, and model types corresponding to classes defined in the UML model for which constraints are being written

Expression Person

Self.age()

Self.contract.grade.salary

2222


Objects and Collections (cont’d)Objects and Collections (cont’d)

Different types of collection

Department

staff.contract.grade

representing the collection of grade objects for the employees in the department

A form of collection which can contain duplicate items

bag

2323



Operations on collections

OCL defines a number of basic operations on collections of all types. One of these is an operation ‘sum’, which adds together all the elements in the collection and returns the total.

Using this operation, the total salary bill for a department could be defined as shown below. Notice that the symbol ‘->’ is used in OCL indicate that a collection operation is being applied

Department

Staff.contract.grade.salary->sum()

2424


Objects and Collections (cont’d)Objects and Collections (cont’d)Another useful operation (return the value)

This particular example could be handled if it was possible to form a new collection by picking out the required employees from the larger collection returned by simple navigation. OCL provides a number of operations on collections to perform such tasks.

including the declaration of a ‘local variable’ which provides a context for navigation in the boolean expression

Department

staff.contract.grade.asSet()->size

Company

employee->select(p:Person | p.contract.grade.salary > 50000)

2525


Objects and Collections (cont’d)Objects and Collections (cont’d)Retrieving the managers of highly paid employees

Company

Employee.select (contract.grade.salary > 5000).manager

Department

Staff -> collect (p : Person | p.age ( ))

• retuning the ages of all the employees in a department

Company

Contract.grade -> collect (salary * 1.1) -> sum ( )

• using a collect expression to calculate the company’s salary

2626



Deparment

Self.staff -> collect (name)

Self.staff.name

• equivalent ways of returning the names of all the employees in a department

2727


Constraint

Basic constraints

standard operators : ‘=‘ , ‘<>’ for equality and inequality

Person

Self.employer = self.department.company

Company

Employee -> select (age () < 18 ) -> isEmpty

Employee -> select (age () < 18 ) -> size = 0

• the assertion that all employees are aged 18 or over, and often be formalized by defining a collection

2828


Constraint (cont’d)

Department

Company.employee->includesAll(staff)

Person

Employee.grade->includes(contract.grade)

• every employee’s grade is one of the set of grades linked to that employee’s company

• the staff of department are all employees of the company the department belongs to

2929



Combining constraints

Constraints can be combined using the boolean operators ‘and’, ‘or’, ‘xor’ ,’not’. OCL differs from most programming languages in defining a boolean operator representing implication.

Person

self.age() > 50 implies self.contract.grade.salary > 2500

3030



Iterative constraints

Iterative constraints resemble iterative operators such as ‘select’ in that they are defined over collections, and return a result which is determined by applying a boolean expression

Rather than returning a new collection, however, they return a boolean value which depends on the results obtained for each individual element.

Company

self.grade->forAll (g | not g.contract->isEmpty())

Department

Staff -> exists (e | e.manager -> isEmpty ())

3131



Grade

salary > 20000

Grade

Grade.allInstance->forAll(g | g.salary > 20000)

Grade

Grade.allInstance->forAll(g : Grade | g <> self implies g.salary <> self.salary)

3232


Stereotyped ConstraintsStereotyped Constraints

Constraints are commonly used to state properties of a class and its operations that cannot be represented graphically.

Include limitations on the possible states of instances of the class, and certain aspects of the operations defined in the class.

Class invariants

A class invariant is a property of a class that is intended to be true at all times for all instance of the class.

Figure 9.7 class specification using constraints

SavingAccountbalance > 0 and balance < 250000

3333


Time events

Preconditions and postconditions

Even if an invariant is defined for a class, there is no guarantee that the operations of the class will ensure that the invariant is maintained.

Preconditions and postconditions are special constraints that can be written for operations.

Precondition is something that must be true just before an operation is called. And usually expressed as a constraint relating the attributes of a class instance and the actual parameters of the operation being specified

Postcondition is something that must be true just after operation has completed. And typically specify the effect of an operation by comparing the attributes values before and after execution of the operationSavingAccount :: withdraw (amt)

Pre: amt < balance Post : balance = balance@pre - amt

3434


Constraints and GeneralizationConstraints and Generalization

Generalization relationships do not give rise to any navigable

relationships between object, and so they do not feature explicitly

in constraints

Figure 9.8 Polymorphic account holding

3535


Constraints and GeneralizationConstraints and GeneralizationCustomerAccount->size > 0 impliesAccount->select(oc1IstypedOf(currentAccount))->size 1

IndividualAccount-> forAll (a | a.oclType) = personalAccount)

Documents

1 Kyung Hee University Constraints Spring 2001. 2 Kyung Hee University Graphical Notations Graphical notations are well suited for displaying structural