Constraints

1. Constraints Spring 2001

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

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

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

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

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

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

8. The 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.

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

10. The Context of A Constraint • Every OCL constraint has a context, which is simply the model element 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 the class symbol near the element constrained Figure 9.5 A simple constraint

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

12. Navigation 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

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

14. Navigation Expressions (cont’d) • 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

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

16. Navigation Expressions (cont’d) • 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

17. Navigation Expressions (cont’d) • 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

18. Navigation Expressions (cont’d) • 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

19. Navigation Expressions (cont’d) • 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

20. Navigation Expressions (cont’d) • 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

21. Objects 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

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

23. Objects and Collections (cont’d) • 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()

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

25. Objects and Collections (cont’d) • Retrieving the managers of highly paid employees Company Employee.select (contract.grade.salary > 5000).manager • retuning the ages of all the employees in a department Department Staff -> collect (p : Person | p.age ( )) • using a collect expression to calculate the company’s salary Company Contract.grade -> collect (salary * 1.1) -> sum ( )

26. Objects and Collections (cont’d) • equivalent ways of returning the names of all the employees • in a department Deparment Self.staff -> collect (name) Self.staff.name

27. Constraint • Basic constraints • standard operators : ‘=‘ , ‘<>’ for equality and inequality Person Self.employer = self.department.company • the assertion that all employees are aged 18 or over, and often • be formalized by defining a collection Company Employee -> select (age () < 18 ) -> isEmpty Employee -> select (age () < 18 ) -> size = 0

28. Constraint (cont’d) • every employee’s grade is one of the set of grades linked to that • employee’s company Person Employee.grade->includes(contract.grade) • the staff of department are all employees of the company • the department belongs to Department Company.employee->includesAll(staff)

29. Constraint (cont’d) • 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

30. Constraint (cont’d) • 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 ())

31. Constraint (cont’d) Grade salary > 20000 Grade Grade.allInstance->forAll(g | g.salary > 20000) Grade Grade.allInstance->forAll(g : Grade | g <> self implies g.salary <> self.salary)

32. Stereotyped 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. SavingAccount balance > 0 and balance < 250000 Figure 9.7 class specification using constraints

33. 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 operation SavingAccount :: withdraw (amt) Pre: amt < balance Post : balance = balance@pre - amt

34. Constraints 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

35. Constraints and Generalization Customer Account->size > 0 implies Account->select(oc1IstypedOf(currentAccount))->size 1 Individual Account-> forAll (a | a.oclType) = personalAccount)