Practical Object-Oriented Design with UML 2e Slide 1/1 ©The McGraw-Hill Companies, 2004 PRACTICAL OBJECT-ORIENTED DESIGN WITH UML 2e Chapter 12: Constraints

Practical Object-Oriented Design with UML 2e Slide 1/2 ©The McGraw-Hill Companies, 2004 Constraints ●Most of UML’s notation is graphical –this is good for expressing structural properties ●Most systems have properties or business rules that cannot be shown on diagrams –eg that the balance in a bank account must be within the range 0 to 250,000 ●Such properties can be added to a model in the form of constraints

Practical Object-Oriented Design with UML 2e Slide 1/3 ©The McGraw-Hill Companies, 2004 A Simple Constraint ●Constraints are Boolean assertions –they are attached to one or more model element –this shows a note containing a class constraint

Practical Object-Oriented Design with UML 2e Slide 1/4 ©The McGraw-Hill Companies, 2004 UML Constraints ●Constraints can be expressed using informal English ●UML defines a some standard constraints to handle common situations –the xor constraint –the subset constraint ●The formal language OCL can be used to write precise, general constraints

Practical Object-Oriented Design with UML 2e Slide 1/5 ©The McGraw-Hill Companies, 2004 The xor Constraint ●The xor constraint asserts that two associations are mutually exclusive –a customer can hold a savings account or a deposit account, but not both

Practical Object-Oriented Design with UML 2e Slide 1/6 ©The McGraw-Hill Companies, 2004 The subset Constraint ●The subset constraint asserts that objects linked by one association are also linked by another –the chair of a committee is also a member of it

Practical Object-Oriented Design with UML 2e Slide 1/7 ©The McGraw-Hill Companies, 2004 The Need for General Constraints ●Many constraints cannot be handled by these general means –eg we might want to rule out this situation

Practical Object-Oriented Design with UML 2e Slide 1/8 ©The McGraw-Hill Companies, 2004 Formulating a Constraint ●We could express the constraint as follows –find the holder of any given debit card –find the holder of the account it belongs to –you must reach the same customer each time ●OCL: the Object Constraint Language –a user-friendly formal language –expresses constraints precisely and concisely –well-adapted for use with UML

Practical Object-Oriented Design with UML 2e Slide 1/9 ©The McGraw-Hill Companies, 2004 Requirements for OCL ●Expressions written in the OCL are used to specify additional integrity constraints on a model. ●A constraint language should provide –the ability to specify what model elements are being constrained –the ability to navigate through the model to identify related objects and data values –the ability to make assertions about the entities reached through navigation

Practical Object-Oriented Design with UML 2e Slide 1/10 ©The McGraw-Hill Companies, 2004 OCL Software (USE) ●A model can be animated to validate the specification against non-formal requirements. System states (snapshots of a running system) can be created and manipulated during an animation. For each snapshot the OCL constraints are automatically checked. Information about a system state is given by graphical views. OCL expressions can be entered and evaluated to query detailed information about a system state. OCL cannot change state, only USE system adds, sets, and deletes variables.

Practical Object-Oriented Design with UML 2e Slide 1/11 ©The McGraw-Hill Companies, 2004 ●The OCL cannot change state, only the USE system adds, sets, and deletes variables. ●The picture below gives a general view of the USE approach.

Practical Object-Oriented Design with UML 2e Slide 1/12 ©The McGraw-Hill Companies, 2004 USE example

Practical Object-Oriented Design with UML 2e Slide 1/13 ©The McGraw-Hill Companies, 2004 OCL overview ●OCL is a specification language defined in UML and compliments the graphical aspects of UML by providing a language for formally expressing the constraints of the model. ● OCL is an expression language. It has no side effects, this means that the state of the system will never change because of an OCL expression, even though an OCL expression can be used to specify a state change, e.g. in a post-condition ●A constraint is a restriction on one or more values of an OO model. There are many constraints that cannot be expressed with a UML diagrams.

Practical Object-Oriented Design with UML 2e Slide 1/14 ©The McGraw-Hill Companies, 2004 USE constraints ●The number of employees working in a department must be greater or equal to the number of projects controlled by the department. ●Employees get a higher salary when they work on more projects. ●The budget of a project must not exceed the budget of the controlling department. ●Employees working on a project must also work in the controlling department.

Practical Object-Oriented Design with UML 2e Slide 1/15 ©The McGraw-Hill Companies, 2004 USE OCL ●Department -- the number of employees working in a department must -- be greater or equal to the number of projects -- controlled by the department ●context Department ●inv MoreEmployeesThanProjects: self.employee->size >= self.project->size

Practical Object-Oriented Design with UML 2e Slide 1/16 ©The McGraw-Hill Companies, 2004 USE OCL ●employees get a higher salary when they work on more projects ●context Employee ●inv MoreProjectsHigherSalary: Employee.allInstances- >forAll(e1, e2 | e1.project- >size > e2.project->size implies e1.salary > e2.salary)

Practical Object-Oriented Design with UML 2e Slide 1/17 ©The McGraw-Hill Companies, 2004 USE OCL ●the budget of a project must not exceed the budget of the controlling department ●context Project ● inv BudgetWithinDepartmentBudget: self.budget <= self.department.budget

Practical Object-Oriented Design with UML 2e Slide 1/18 ©The McGraw-Hill Companies, 2004 USE OCL ● employees working on a project must also work in the -- controlling department ●context Project ●inv EmployeesInControllingDepartment: self.department.employee- >includesAll(self.employee)

Practical Object-Oriented Design with UML 2e Slide 1/19 ©The McGraw-Hill Companies, 2004 The Context of a Constraint ●Every OCL constraint has a context –this relates the constraint to the model elements being constrained ●Constraints can be shown on diagrams –in the constrained element or in an attached note

Practical Object-Oriented Design with UML 2e Slide 1/20 ©The McGraw-Hill Companies, 2004 Textual Constraints ●Constraints are more often written as text accompanying a model –they start with a context declaration defining the context context SavingsAccount inv: self.balance > 0 and self.balance < –‘inv’ indicates that the constraint is an invariant

Practical Object-Oriented Design with UML 2e Slide 1/21 ©The McGraw-Hill Companies, 2004 Constraint Syntax ●A dot ‘. ’ is used to refer to a feature of a model element, such as an attribute value ●‘ self ’ refers to the context object –it can be omitted if preferred ●the context object and the constraint itself can be named context acc:SavingsAccount inv limits: acc.balance > 0 and acc.balance <

Practical Object-Oriented Design with UML 2e Slide 1/22 ©The McGraw-Hill Companies, 2004 Constraint Syntax ●A dot ‘. ’ is used to refer to a feature of a model element, such as an attribute value ●‘ self ’ refers to the context object –it can be omitted if preferred ●the context object and the constraint itself can be named context SavingsAccount inv limits: self.balance > 0 and self.balance <

Practical Object-Oriented Design with UML 2e Slide 1/23 ©The McGraw-Hill Companies, 2004 An Payroll System ●Further examples are based on this model

Practical Object-Oriented Design with UML 2e Slide 1/24 ©The McGraw-Hill Companies, 2004 Whole-Part relationship ●The UML provides a two ways to record the nature of a whole-part relationship. Why use them? This relationship frequently occurs in application domains: ●Aggregation: We can describe a 'whole–part' relationship where the part is not mandatory. For example the whole could be an invoice which is made up from the invoice lines (the parts). It would be possible to add, remove or replace one of the ‘parts’ and still have a meaningful relationship: an invoice would still be an aggregation of invoice lines if another invoice line were to be added. For aggregation, you simply add an open diamond to the end of the association to indicate the class that is to act as the whole. ●Composition: We can describe a 'whole–part' relationship where the part is mandatory. For example the association that holds between a chess-board and the squares on it. If you were to remove (or add) a square you would no longer have a recognizable chess-board. A chess-board and its squares are much more intimately related than an invoice and its invoice lines because a chess board cannot exist unless it has 64 squares. The chess-board and square association is a particular kind of aggregation known as a composition. Composition, as a stronger form of aggregation, is shown as a solid black diamond.

Practical Object-Oriented Design with UML 2e Slide 1/25 ©The McGraw-Hill Companies, 2004 Qualified Associations

Practical Object-Oriented Design with UML 2e Slide 1/26 ©The McGraw-Hill Companies, 2004 Qualified Associations ●If the system you are modeling includes a mechanism for identifying objects uniquely, you can use qualified associations to record this information. For example, a bank usually identifies individual bank accounts by a unique account number. The use of account numbers to uniquely identify accounts would be noted in the glossary.

Practical Object-Oriented Design with UML 2e Slide 1/27 ©The McGraw-Hill Companies, 2004 Qualified Associations ●Given the combination of a bank and an account number, there is either zero or one associated account. The advantage of this approach is that you have put more information into the model and have placed less reliance upon people using the glossary. ●This illustrates the general point that a qualified association often replaces an association with a multiplicity of * with a multiplicity of either 1 or In the UML, a qualifier is considered to be an attribute of an association. It tells you about the properties of the concept that relates the classes at the ends of the association. In practice, qualifiers can be found in the attributes of one of the classes. ●Why use them? Qualified associations are a way of capturing the uniqueness of some manner of identifying objects, such as in the case of account numbers in a bank.

Practical Object-Oriented Design with UML 2e Slide 1/28 ©The McGraw-Hill Companies, 2004 Derived associations ●Derived associations are probably the most common kind of derived element, closely followed by derived attributes. Any attribute can be marked as a derived attribute using the forward slash notation. For instance, a Person might have attributes of dateOfBirth and ageInYears. These are not independent, so the age could be marked as a derived attribute, as in / ageInYears.

Practical Object-Oriented Design with UML 2e Slide 1/29 ©The McGraw-Hill Companies, 2004 Derived associations ●Typically, the rule by which one attribute is derived from another would be held in the glossary but you could also express it in a note attached to the appropriate element in a model. For example, the value of ageInYears is obtained by comparing dateOfBirth with the current date. A derived attribute can be represented in OCL.

Practical Object-Oriented Design with UML 2e Slide 1/30 ©The McGraw-Hill Companies, 2004 Derived associations By preceding a role name with a slash, you indicate that an association is derivable, although you do not say how it is derived. That information should be put in the project glossary.

Practical Object-Oriented Design with UML 2e Slide 1/31 ©The McGraw-Hill Companies, 2004 Derived associations ●Why use them? There are several reasons for choosing to identify a derived element. For example, during analysis, a derived attribute or association may be used to identify and define a useful concept such those children in a family who are teenagers. Derived attributes and associations are a way of optimizing a design and give more efficient access paths to data than those that exist in the original design. The disadvantage is a redundancy in the overall model that requires a processing overhead for consistency checking. Whatever the reason you choose to identify a derived element, its presence in a model implies that there is a responsibility to consider changing it if there is a change in the elements used to derive it.

Practical Object-Oriented Design with UML 2e Slide 1/32 ©The McGraw-Hill Companies, 2004 Navigation Expressions ●Starting from the context object we can follow links to arrive at other objects ●To navigate across an association use –the role name at the far end of the association –or the name of the class at the far end ●The dot notation is used to separate these from the context object name

Practical Object-Oriented Design with UML 2e Slide 1/33 ©The McGraw-Hill Companies, 2004 Simple Navigations ●“The employees working in a department” –this uses a role name context Department inv: self.staff ●“The set of all departments in the company” –this uses a class name context Company inv: self.department

Practical Object-Oriented Design with UML 2e Slide 1/34 ©The McGraw-Hill Companies, 2004 Navigations ●A navigational expression is used to refer to notations in which you name an object or object attribute by starting at another object and hop from one object to another. You use role names to identify the next object and attribute names to identify which attribute of the object is of interest. We must be clear about the direction of potential messages between instances of one class and instances of another where there is an association between the two of them.

Practical Object-Oriented Design with UML 2e Slide 1/35 ©The McGraw-Hill Companies, 2004 Navigations ●In the UML, you can put an open arrowhead at one or both ends of an association to indicate that it is possible to reach one class from another following the direction of the arrow. In doing so, you are restricting access to instances of the class at end of the association where you placed the arrowhead.

Practical Object-Oriented Design with UML 2e Slide 1/36 ©The McGraw-Hill Companies, 2004 Navigations ●Navigational expressions are only about naming remote attributes. They are not directly related to the sending of messages. Contrast with the Law of Demeter, which offers guidelines on the use of objects reachable only by following chains of role names. Why use them? As class diagrams become complex, we need to check for loops.

Practical Object-Oriented Design with UML 2e Slide 1/37 ©The McGraw-Hill Companies, 2004 Objects and Collections ●What does a navigation expression return? –if there are many linked objects a collection is returned –if there is one linked object, the object is returned –if there are no linked objects, an empty collection is returned ●OCL converts single objects to collections wherever necessary –it is as if a collection was always returned

Practical Object-Oriented Design with UML 2e Slide 1/38 ©The McGraw-Hill Companies, 2004 Iterated traversal ●More complex navigation expressions can follow a chain of associations –“All the people who work for the company” context Company inv: self.department.staff ●This is evaluated in a step-by-step manner –first get the collection of departments –then get the staff in each department –merge these collections of staff to get the result

Practical Object-Oriented Design with UML 2e Slide 1/39 ©The McGraw-Hill Companies, 2004 Qualified Associations (1) ●Navigation towards the qualifier is the same as unqualified associations ●In the other direction, use qualifier values to identify individuals: –“the employee with payroll number ” context Company inv: self.employee[314159]

Practical Object-Oriented Design with UML 2e Slide 1/40 ©The McGraw-Hill Companies, 2004 Qualified Associations (2) ●Qualifiers can be combined with further navigation: –“that person’s manager” context Company inv: self.employee[314159].manager ●Or omitted altogether: –“all the company’s employees” context Company inv: self.employee

Practical Object-Oriented Design with UML 2e Slide 1/41 ©The McGraw-Hill Companies, 2004 Association Classes ●Navigate from in the normal way: –“all the employees of a particular grade” context Grade inv: self.contract.employee ●Navigate to using association class name: –“the grade of a particular employee” context Person inv: self.contract.grade

Practical Object-Oriented Design with UML 2e Slide 1/42 ©The McGraw-Hill Companies, 2004 OCL Basic Types ●OCL defines basic types to describe data –Boolean –Integer –Real ●These can be assumed to be the same as the corresponding UML types

Practical Object-Oriented Design with UML 2e Slide 1/43 ©The McGraw-Hill Companies, 2004 Model Types ●UML classes give rise to OCL model types ●Model types have a number of properties –every UML attribute gives rise to a property –the far end of an association attached to the class gives rise to a property –query operations give rise to properties ●Not every operation is a property –OCL expressions must not change object state

Practical Object-Oriented Design with UML 2e Slide 1/44 ©The McGraw-Hill Companies, 2004 Property Values ●Properties are denoted with the dot notation: –“the age and salary of an employee” context Person inv: self.age() inv: self.contract.grade.salary ●Property expressions can denote collections –“the names of employees in a department” context Department inv: self.staff.name

Practical Object-Oriented Design with UML 2e Slide 1/45 ©The McGraw-Hill Companies, 2004 Enumerations ●UML enumerations can be used in constraints –“a signal must be red or green” context Signal inv: colour = Colour::red or colour = Colour::green

Practical Object-Oriented Design with UML 2e Slide 1/46 ©The McGraw-Hill Companies, 2004 Collections ●What is the salary bill for a department? –collect the grades of each staff member context Department inv: self.staff.contract.grade –and add up the salaries ●But there will be many staff members on the same grade –a set of grades will give the wrong answer

Practical Object-Oriented Design with UML 2e Slide 1/47 ©The McGraw-Hill Companies, 2004 Collection Types ●OCL defines three types of collection: –sets: an object can only appear once in a set –bags: an object can appear more than once –sequences: objects in a sequence are ordered ●Navigation from a single object returns a set –because there can only be one link to an object ●Navigation from a set returns a bag –so we get a bag of grades in the example

Practical Object-Oriented Design with UML 2e Slide 1/48 ©The McGraw-Hill Companies, 2004 Operations on Collections ●We can add up the elements in a collection: –“the total salary bill for a department” context Department inv: staff.contract.grade->sum() –collection operations are preceded by ‘ -> ’ ●Or find the number of different grades –convert the bag to a set and get its size context Department inv: staff.contract.grade->asSet()->size()

Practical Object-Oriented Design with UML 2e Slide 1/49 ©The McGraw-Hill Companies, 2004 Selecting elements ●Sometimes we are only interested in some elements in a collection –“employees with a salary greater than 50,000” context Company inv: self.employee->select(p:Person | p.contract.grade.salary > 50000)

Practical Object-Oriented Design with UML 2e Slide 1/50 ©The McGraw-Hill Companies, 2004 The Select Operation ●The ‘local variable’ is optional but can clarify expressions ●‘ select ’ returns a collection that can be used for further navigation –“the managers of highly paid employees” context Company inv: employee->select (contract.grade.salary > 50000).manager

Practical Object-Oriented Design with UML 2e Slide 1/51 ©The McGraw-Hill Companies, 2004 The Collect Operation ●We can collect together the values of an expression applied to every element of a collection –“the ages of all employees in a department” context Department inv: staff->collect(p:Person | p.age()) –“the company’s salary bill after a 10% pay rise” context company inv: contract.grade ->collect(salary*1.1)->sum()

Practical Object-Oriented Design with UML 2e Slide 1/52 ©The McGraw-Hill Companies, 2004 Shorthand for Collect ●Often we want to collect all the values of a particular attribute over a collection context Department inv: self.staff->collect(name) ●This is usually abbreviated to the familiar context Department inv: self.staff.name

Practical Object-Oriented Design with UML 2e Slide 1/53 ©The McGraw-Hill Companies, 2004 Basic Constraints ●Write navigation expressions to denote the data values of interest ●Use relational operations to express the constraint –“an employee works for the company that their department is in” context Person inv: self.employer = self.department.company

Practical Object-Oriented Design with UML 2e Slide 1/54 ©The McGraw-Hill Companies, 2004 Constraints on Collections ●Various properties of collections can be tested –two ways of saying that all employees are aged 18 or more context Department inv: employee->select(age() isEmpty() context Department inv: employee->select(age() size() = 0

Practical Object-Oriented Design with UML 2e Slide 1/55 ©The McGraw-Hill Companies, 2004 Collection predicates ●We can check that an object is in a collection –“every grade used is known to the company” context Person inv: employee.grade->includes(contract.grade) ●And that one collection is included in another –“a department’s staff all belong to the company” context Department inv: company.employee->includesAll(staff)

Practical Object-Oriented Design with UML 2e Slide 1/56 ©The McGraw-Hill Companies, 2004 Combining Constraints ●Combine constraints using Boolean operators – not, and, or, xor ●OCL also has an ‘implies’ operator –“every employee over 50 gets at least 25000” context Person inv: age() >= 50 implies contract.grade.salary >= 25000

Practical Object-Oriented Design with UML 2e Slide 1/57 ©The McGraw-Hill Companies, 2004 Iterative Constraints ●Iterative constraints apply a Boolean expression to every member of a collection ●The ‘ forAll ’ quantifier checks if a property is true for all members of a collection –“there is an employee at every grade” context Company inv: self.grade->forAll( g : Grade | not g.contract->isEmpty())

Practical Object-Oriented Design with UML 2e Slide 1/58 ©The McGraw-Hill Companies, 2004 The ‘exists’ Quantifier ●The ‘ exists ’ quantifier checks if a property is true for at least one member of a collection –“every department has a head” (defined as someone with no manager) context Department inv: staff->exists(e : Person | e.manager->isEmpty())

Practical Object-Oriented Design with UML 2e Slide 1/59 ©The McGraw-Hill Companies, 2004 All Class Instances ●Simple constraints apply to all instances –“the salary for every grade is more than 20000” context Grade inv: salary > ●The ‘ allInstances ’ operation does this explicitly context Company inv: Grade.allInstances->forAll(g | g.salary > 20000)

Practical Object-Oriented Design with UML 2e Slide 1/60 ©The McGraw-Hill Companies, 2004 Comparing Class Instances ●This is necessary to state some properties of the instances of a class –“no two grades have the same salary” context Grade inv: Grade.allInstances->forall(g : Grade | g <> self implies g.salary <> self.salary –both ‘ self ’ and ‘ g ’ range over all grades

Practical Object-Oriented Design with UML 2e Slide 1/61 ©The McGraw-Hill Companies, 2004 Class Invariants ●Most constraints state properties of classes that are meant to be true at all times ●These are known as invariants –“an account’s balance must be in a given range” context SavingsAccount inv: balance > 0 and balance < 25000

Practical Object-Oriented Design with UML 2e Slide 1/62 ©The McGraw-Hill Companies, 2004 Preconditions ●Sometimes constraints are used to define properties of operations ●Preconditions state what must be true before an operation is executed –“you can only withdraw an amount less than the balance in an account” context SavingsAccount::withdraw(amt:Real) pre: amt < balance

Practical Object-Oriented Design with UML 2e Slide 1/63 ©The McGraw-Hill Companies, 2004 Postconditions ●Postconditions specify the result of an operation –“withdraw withdraws the amount given to it” context SavingsAccount::withdraw(amt:Real) post: balance = amt –‘ ’ denotes the balance before the operation executed

Practical Object-Oriented Design with UML 2e Slide 1/64 ©The McGraw-Hill Companies, 2004 Stereotyped Constraints ●Constraints can be stereotyped if they are shown on a class diagram

Practical Object-Oriented Design with UML 2e Slide 1/65 ©The McGraw-Hill Companies, 2004 Constraints and Generalization ●Generalization doesn’t give rise to any navigable relationships ●Sometimes the run-time type of an object is important for a constraint

Practical Object-Oriented Design with UML 2e Slide 1/66 ©The McGraw-Hill Companies, 2004 Checking Run-time Type ●“Every customer holds a current account” context Customer inv: account->size() > 0 implies account.select(oclIsTypeOf(CurrentAccount)) ->size() > 1 –“if the customer holds any accounts at all, at least one of them must be a current account” –‘ oclIsTypeOf ’ returns true if an object belongs to the specified type

Practical Object-Oriented Design with UML 2e Slide 1/67 ©The McGraw-Hill Companies, 2004 Parallel Generalization ●Another situation with parallel hierarchies –“only individuals can hold personal accounts”

Practical Object-Oriented Design with UML 2e Slide 1/68 ©The McGraw-Hill Companies, 2004 Finding the Type of an Object ●Check that all the accounts belonging to an individual are of the correct class context Individual inv: account->forAll(a : Account | a.oclType = PersonalAccount) –‘ oclType ’ returns the type of any object

Practical Object-Oriented Design with UML 2e Slide 1/69 ©The McGraw-Hill Companies, 2004 OCL overview ●The standard pre-defines a small number of constraints (for example the xor constraint over a set of associations indicating that only one may be manifest for any particular instance). ● While the advantages of formal specification are well known, the disadvantage of traditional formal specification languages (e.g. Z) is that they are useable to persons with a strong mathematical background, but difficult for the average business or system modeler to use. ● OCL is not a programming language, so it is not possible to write program logic or flow control in OCL. OCL facilitates the concept of an executable specification of constraints and some code generation e.g. pre/post conditions on methods.

Practical Object-Oriented Design with UML 2e Slide 1/70 ©The McGraw-Hill Companies, 2004 OCL and testing ●OCL can be used to test models. With appropriate software OCL can be used during analysis and design to test general purpose constraints and other modeling needs, testing is all done at the modeling stage. OCL can also influence code tests. ●To specify and test invariants on classes, attributes, associations and types in a class model; ●To specify and test type invariants for stereotypes; ●To describe and test pre- and post-conditions on use-cases, operations and methods;

Practical Object-Oriented Design with UML 2e Slide 1/71 ©The McGraw-Hill Companies, 2004 OCL and testing ●To describe and test guards; A transition in a state transition diagram can be coupled to an action. This action is a procedural expression that is executed when the transaction fires and it targeted at a specific object or at a set of objects. ●As a navigation language. This can help express constraints on loops in class diagrams and test for looping situations.

Practical Object-Oriented Design with UML 2e Slide 1/72 ©The McGraw-Hill Companies, 2004 OCL and testing ●To specify and test constraints on operations. ●A message in a sequence or collaboration diagram can have an attached condition that specifies in what circumstances the message is sent. ●To express and check parameters. For example, messages in collaboration and sequence diagram can take parameters. ●Specify and test multiplicity and mandatory constraints.

Practical Object-Oriented Design with UML 2e Slide 1/73 ©The McGraw-Hill Companies, 2004 OCL and testing ●To represent derived associations and test their validity. ●To represent and test end-user queries on a UML (with suitable tool can answer queries) ●To specify and test initial attribute values. ●Specifying and testing the derivation rules for attributes or associations. ●Specifying and testing the body of a query operation ●Specifying and testing guards on state charts ●Specifying the targets for messages being sent.

Practical Object-Oriented Design with UML 2e Slide 1/74 ©The McGraw-Hill Companies, 2004 More OCL ●1 The dates of the current bookings must be equal to the current date stored in the booking system object ●2 Booking times for the same table must not overlap. ●3 There are exactly ten tables in the restaurant. ●4 Only customers who have booked may be allocated a table. context BookingSystem inv MustBook: self.current->forAll(b : Booking | b.date = self.date) context Restaurant inv NoOverLap : self.bookings->forAll(a,b : Booking | (a.duration->intersection(b.duration)- >isEmpty) and ….) context Restaurant inv TenTables : self.table->size=10 context Restaurant inv mustBook : self.bookings->forAll(route to customer should be the same via both paths)