Home Assignment 4 OCL

Transcription

1 Home Assignment 4 OCL This home assignment is about writing formal specifications using the Object Constraint Language. You will exercise formulating conditions/invariants on domain models that go beyond the expressiveness of UML class diagrams. Then, you will use OCL for writing contracts for methods, i.e., to specify behaviour. The main purpose of doing that is to get a feeling for textual formal specification languages like OCL, JML or Alloy, which can be used, amongst others, to provide better more precise documentation of software systems. Comments for the Corrector This week, we have added comments about how to correct only to some of the questions. Generally, when correcting you should not care too much about purely syntactic issues. It is more important that the constraints are logically correct, e.g., that the right collection operations are used (in the right way). Give comments when you subtract points, because the person that wrote the solution will not have the opportunity to ask you for comments personally. Exercise 1 (4p) This question is about strengthening the given domain model by formulating further properties in the Object Constraint Language. Order - sum:double - fee:double - orderedbooks Book - price:double - idnumber:int a) (1p) Give an OCL invariant that specifies that the sum attribute cannot be negative. context Order inv: sum >= 0 b) (1p) 1

2 Give an OCL invariant that specifies that the sum attribute will be zero if no books are ordered. context Order inv: orderedbooks->isempty() implies sum = 0 c) (1p) Give an OCL invariant that specifies that the sum attribute really describes the price of the books ordered. context Order inv: sum = orderedbooks->collect(price)->sum() using short-h notation: context Order inv: sum = orderedbooks.price->sum() d) (1p) Give an OCL invariant that specifies that different instances of Book have different idnumbers. A number of different solutions here: context Book inv: Book.allInstances()->forAll(b1, b2 b1 <> b2 implies b1.idnumber <> b2.idnumber) context Book inv: Book.allInstances()->forAll(b1, b2 b1.idnumber = b2.idnumber implies b1 = b2) context Book inv: Book.allInstances()->forAll(b b <> self implies 2

3 context Book inv: Book.allInstances()->isUnique(idNumber) b.idnumber <> self.idnumber) You can make use of the following OCL operations: OclType: allinstances() OclAny: object<>(object2) String: = Integer: <> Real: +, >=, Boolean: b1 implies b2, b1 b2 (b1,b2:boolean) Collection, Set, Bag, Sequence: collection-> sum() collection-> size() collection->collect(element:type <expr>) collection-> select (element:type <expr>) collection-> forall(element:type <expr>) collection-> exists(element:type <expr>) collection->isunique(element:type <expr>) collection-> iterate(element:typ1; result:type2 = <expr> <expr-with-element--result>) Exercise 2 (12p) This question continues exercise 3 4 from the first home assignment. The context is the following domain model, which is one possible solution to exercise 3 of that assignment: 3

4 One possible solution: Bank name 1.. Account balance interest PaymentRemarks date info remarks customer account 1 Customer status name associate warrantor Address SteetName StreetNumber city country address 1 Income amount date income loan Loan amount interest payment 0..1 security own 0..1 House taxvalue loanfor 0..1 With help of the multiplicity one can constrain the domain model. But there are other conditions, business rules, which cannot be described by only a domain model using multiplicities. Such rules can be written in a precise manner using OCL. a) Invariants (1) (2p) Write the following constraint as an OCL invariant of concept Loan: If a loan has a warrantor, then the warrantor is an associate of the customer who has the loan. context Loan inv: warrantor->notempty() implies customer.associate->includes(warrantor) b) Invariants (2) (2p) 4

5 Write the following constraint as an OCL invariant of concept Loan: If a Loan has a House as security, then the Customer having the Loan must own that House. context Loan inv: security->notempty() implies security.customer = customer or context Loan inv: security->notempty() implies customer.own->includes(self.security) c) Invariants (3) (2p) Write the following constraint as an OCL invariant of concept Loan: If a Loan has a House as security, then that House must have a taxvalue (assessed value) of at least 20% of the amount of the Loan. context Loan inv: security->notempty() implies (security.taxvalue / amount) 100 >= 20 d) Pre-/Postconditions: Customer::getLoan() (2p) In order to simplify the following question, we assume that the number of instances of concept Income that are related with a customer shows how many times during the last 12 months the person got a salary. If there are, for example, 9 instances of Income related to a customer, then the customer got a salary in 9 out of 12 months. We start with refining the domain model into a class diagram. Therefore, an operation getloan():boolean is added to class Customer. 1 This operation is supposed to return whether a customer can be given a loan (true) or not (false). As a business decision, a customer can be given a loan if only if the following conditions hold (unless houses as securities or warrantors are involved, in this case the whole situation gets more complicated): 1 Whether this is good design is questionable, but this is not the point of this exercise... 5

6 The customer got a salary in each of the last 12 months. In each of the last 12 months, the salary was more than kr. Give an OCL specification of Customer::getLoan() that expresses these conditions. context Customer::getLoan():Boolean post: result = (income->size() = 12 income->forall(amount>14000)) e) Pre-/Postconditions: Customer::addLoan() (4p) The following question is a difficult one... Good luck! As the next step, we create an operation addloan(amount:real, interest:real, payment:real):loan[0..1] for really adding a loan. The operation will again be added to class Customer. The result of the operation is either the loan instance that was created (if adding the loan was successful) or the empty set (otherwise). The preconditions of the operation have to express that the arguments have reasonable values. Decide yourself about what is reasonable, but also give a short justification for the conditions that you came up with. The effect of the operation is supposed to be the following: If the customer is directly allowed to get a loan (i.e., the conditions from d) are satisfied): A Loan object has been created, its attributes have the values that were given as arguments of addloan(), the object has been related with the customer. Otherwise: If the customer has an associate customer that is allowed to get a loan (again according to the conditions from d)): A Loan object has been created like in the first case, but in addition the associate has been added as a warrantor. Otherwise: No loan is added. Give an OCL specification of Customer::addLoan() that expresses all these conditions. Hint: Note that you can use the query Customer::getLoan() in OCL expressions. We consider the following values of the arguments as reasonable: 6

7 amount is positive. interest must not be negative, because the bank does not want to pay its customers for taking loans. The value 0 is possible might occur for very special customers... The monthly/yearly payment (whatever) must not be negative, must not be greater than the amount. context Customer::addLoan(p_amount:Real, p_interest:real, p_payment:real):loan[0..1] pre: p_amount > 0 p_interest >= 0 p_payment >= 0 p_payment <= p_amount post: (loan - loan@pre)->forall(amount = p_amount interest = p_interest payment = p_payment security->isempty() loanfor->isempty()) if getloan() then result->notempty() result.oclisnew() loan = loan@pre->including(result) result.warrantor->isempty() else if associate->exists(getloan()) then result->notempty() result.oclisnew() loan = loan@pre->including(result) associate->exists (war war.getloan() result.warrantor = war) else loan = loan@pre result->isempty() endif endif Comments for the Corrector Give up to 1p for reasonable pre-conditions that are correctly formalised (which must not exactly be the pre-conditions given as solution here). Give up to 1p for correctly distinguishing the different possible cases (warrantor, no warrantor, no loan at all). 7

8 Give up to 1p for correctly creating a Loan object, for assigning the attributes/associations amount, interest, payment, security, loanfor, for adding it to self.loan. Give up to 1p for correctly setting up the warrantor field of the newly created Loan object. (total 16p) 8