02291: System Integration

Size: px

Start display at page:

Download "02291: System Integration"

Melina Poole
6 years ago
Views:

1 02291: System Integration Week 8 Hubert Baumeister huba@dtu.dk DTU Compute Technical University of Denmark Spring 2018

2 Last Week Components: Synchronized communication Sequence Diagrams Use Case Realization

3 Contents Desgin by Contract and OCL Principles of Good Design

4 What does this function do? Implementation public List<Integer> f(list<integer> vector) { if (vector.size() <= 1) return vector; int k = vector.elementat(0); List<Integer> less = new List<Integer>(); List<Integer> equal = new List<Integer>(); List<Integer> bigger = new List<Integer>(); g(k,vector,less,equal,bigger); List<Integer> r = f(less); r.addall(equal); r.addall(f(bigger)); } return r; public void g(int k, List<Integer> vector, List<Integer> less, List<Integer> equal, List<Integer> bigger) { for (int i : vector) { if (i < k) less.add(i); if (i == k) equal.add(i); if (i > k) bigger.add(i); } }

5 Contract for the sort function in OCL Specification (Contract) in OCL context C::sort(a : Sequence(Integer)) : Sequence(Integer) pre: a <> null post: issorted(result) and sameelements(a,result) def: issorted(result) = Sequence {1..a.length}->forAll(i Sequence {1..a.length}->forAll( j i < j implies a->at(i) <= a->at(j)) def: sameelements(a1, a2 : Sequence(Integer)) = a1->forall( i a1->count(i) = a2->count(i)) and a2->forall( i a1->count(i) = a2->count(i))

6 Contracts {The field i should always be greater than 0.} i : int Counter inc() : void dec() : void {The operation dec should be called only if i is greater than zero. In this case i is decremented by one.} {The inc operation increases i by one.} public T n(t1 a1,.., Tn an, Counter c)... c.dec();... Contract for dec Method n ensures pre-condition c.i > 0 before calling c.dec() Method dec ensures counter is decremented, only when c.i > 0 Undefined what happens when c.i <= 0

7 Example {The field i should always be greater than 0.} i : int Counter inc() : void dec() : void {The operation dec should be called only if i is greater than zero. In this case i is decremented by one.} {The inc operation increases i by one.}

8 Example {The field i should always be greater than 0.} i : int Counter inc() : void dec() : void {The operation dec should be called only if i is greater than zero. In this case i is decremented by one.} {The inc operation increases i by one.} {context Counter :: dec ( ) pre: i > 0 post: i = i@pre - 1 } i : int Counter inc() : void dec() : void {context Counter inv: i >= 0} {context Counter :: inc ( ) post: i = i@pre + 1}

9 Object Constraint Language (OCL) Express constraints in UML diagrams in a formal way 1 Invariants of UML diagrams 2 The contract of operations (i.e. pre- and postconditions of operations) 3 body of query operations ( query ; don t change the state) query operations can be used in OCL constraints, but not state changing operations

10 Bank example with constraints Bank {context Bank inv: accounts->forall(a a.owner = self) owner 1 accounts 0..* Account bal : int update(n : int) : void {inv: bal >= 0} {pre: bal + n >= 0 post: bal = bal@pre + n and history.oclisnew() and history.bal = bal@pre and history.prev = history@pre} History 0..1 bal : int prev History() : void 1

11 Update operation of Account State before executing update(n) {n + b >= 0} a: Account bal = b bal = m h: History

12 Update operation of Account State before executing update(n) State after executing update(n) {n + b >= 0} a: Account bal = b + n a: Account bal = b h1: History bal = b bal = m h: History bal = m prev h: History

13 OCL Syntax More on OCL operators and OCL Online on Safari books: Object Constraint Language by Jos Warmer, Anneke Kleppe (cf. course home page)

14 OCL expressions and their evaluation OCL expression evaluated in a context. Class, Operation, Association,... Expression cannot change the state of the system can t call state changing operations (basically no method calls are allowed) Exception: calls to methods marked {query} are allowed No assignment operator (= means equality)

15 Type of constraints The type of the constraint Most common Invariant for classes (inv:) precondition for operations (pre:) postcondition for operations (post:) Others body: exp def: name(parameter:type) : type = expr Ex. def: initial : String = name.substring(1,1) Ex. def: gettotalpoints(d:date) : Integer = OCL expression

16 Notation Within notes in {} {pre: i > 0 post: i = i@pre -1} Counter i : int inc dec {inv: i >= 0} {post: i = i@pre + 1} As separate text. In this case the context part must be present context Counter inv: i >= 0 context Counter :: inc post: i = i@pre + 1

17 OCL Syntax (simplified): Available types Basic datatypes: Integer, Real, Boolean, String Boolean operators: =, <>, not, and, or, implies,..., x.isocltypeof (C) All classes C from the UML model Collection types: Set(C), OrderedSet(C), Bag(C), Sequence(C)

18 OCL Syntax (simplified): Basic operations y:int m() A a b x:int B Attribute / Navigation (in the context of class A) self self.b.x Operation Calls self.m(c1,, c n ) (Method call) self.b cop(...) (Call to a method on collections) context A inv: self.b.x->includes(3)

19 Navigation Navigation via dot (.) notation to roles and attributes y:int A a b x:int B a1:a {y = 10} b1:b {x = 5} a1.b = a1.b.x =

20 Navigation Navigation via dot (.) notation to roles and attributes y:int A a b x:int B {x = 3} b1:b {y = 10} a1:a {x = 5} b2:b a1.b = a1.b.x =

21 OCL Syntax (simplified): OCL Boolean Operators and Collections Boolean operators Equal (=), Not-Equal (<>) not, and, or, implies,... x.isocltypeof (C) is true if x is an object of type C or a subtype thereof Collections Collection(C): Abstract supertype Set(C) (not ordered, no duplicates) OrderedSet(C) (ordered, no duplicates) Bag(C) (not ordered, allowes duplicates) Sequence(C) (ordered, allowes duplicates)

22 OCL Syntax (simplified): Operations on collections I collection forall(x P[x]) corresponds to x collection : P[x] collection exists(x P[x]) corresponds to x collection : P[x] collection select(x P[x]) corresponds to {x collection P[x]} collection collect(x E[x]) corresponds to {E[x] x collection} self.employee collect(birthday) = self.employee.birthday P[x] and E[x] means that x occures in predicate P and expression E

23 OCL Syntax (simplified): Operations on collections II Sequence{1, 2, 3} includes(3) = true more: includesall(collection), excludes, isempty, union, intersection, count... compare with Sequence{1, 2, 3} including(5) = Sequence {1, 2, 3, 5 } Conversions between collections: asset, asbag, assequence,... C.allInstances() sequence at(i) (s at(1) is the first element)

24 Flattening Collections Federation 1 * Club * member * Person f.club.member = f.club->collect(member) = f.club->collectnested(member) =

25 OCL Syntax (simplified): Postconditions Additionally in postconditions: result x.oclisnew() xˆm() Message m was send to x e.g. observerˆupdate

26 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg)

27 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed

28 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed)

29 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed) context Observable::hasChanged() post: result = changed

30 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed) context Observable::hasChanged() post: result = changed context Observable::hasChanged() body: changed

31 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed) context Observable::hasChanged() post: result = changed context Observable::addObservers(Observer o) post: observers = observers@pre->including(o) context Observable::hasChanged() body: changed

32 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed) context Observable::hasChanged() post: result = changed context Observable::addObservers(Observer o) post: observers = observers@pre->including(o) context Observable::notifyObservers(Object arg) pre: changed post: observers->forall( o oˆupdate(self, arg)) and not(changed) context Observable::hasChanged() body: changed

33 Observer Pattern «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) haschanged() : bool setchanged() clearchanged() notifyobservers(object arg) context Observable::setChanged() post: changed context Observable::clearChanged() post: not(changed) context Observable::hasChanged() post: result = changed context Observable::addObservers(Observer o) post: observers = observers@pre->including(o) context Observable::notifyObservers(Object arg) pre: changed post: observers->forall( o oˆupdate(self, arg)) and not(changed) context Observable::hasChanged() body: changed context Observable::notifyObservers(Object arg) post: changed@pre implies (observers->forall( o oˆupdate(self, arg)) and not(changed))

34 Observer Pattern Final «Interface» Observer update(observable o, Object arg) * Observable changed : bool addobserver(observer o) notifyobservers(object arg) context Observable::addObservers(Observer o) post: observers = observers@pre->including(o) context Observable::notifyObservers(Object arg) post: changed@pre implies (observers->forall( o oˆupdate(self, arg)) and not(changed))

35 Example Vending Machine

36 Vending machine behaviour with OCL constraints {inv: currentmoney >= 0 and totalmoney >= 0 and restmoney >= 0 } {pre: m > 0 post: if (selectedfruit <> null and enoughmoney(selectedfruit)) then itemdispensed(f,currentmoney@pre + m) else currentmoney = currentmoney@pre + m endif } {post: if enoughmoney(f) then itemdispensed(f,currentmoney@pre) else selectedfruit = f endif } {post: currentmoney = 0 and restmoney = currentmoney@pre and selectedfruit->size() = 0 } {def: itemdispensed(f:fruit, oldcm:int) = dispenseditem = f and restmoney = oldcm - pricefor(f) and currentmoney = 0 and totalmoney = totalmoney + pricefor(f) } VendingMachine fruit «enumeration» * currentmoney: int Fruit totalmoney: int dispenseditem 0..1 banana restmoney: int selectedfruit 0..1 apple input(m:int) select(f:fruit) {body: currentmoney >= pricefor(f)} cancel() enoughmoney(f:fruit) {isquery} hasfruit(f:fruit) {isquery} {body: fruit->collect(f1 f1 = f)->size() >= 1} dispense(f:fruit) pricefor(f:fruit) {isquery} {pre: enoughmoney(f) and hasfruit(f) post: itemdispensed(f,currentmoney@pre) } {pre: (f = banana) or (f = apple) body: if (f = banana) then 5 else 3 }

37 Vending machine behaviour as life cycle state machine

38 Contents Desgin by Contract and OCL Principles of Good Design

39 DRY principle DRY principle Don t repeat yourself Every piece of knowledge must have a single, unambiguous, authoritative representation within a system. The Pragmatic Programmer, Andrew Hunt and David Thomas code documentation build stystem

40 Example: Code Duplication

41 Example: Code Duplication Person name cpr-number home-address-street home-address-city printaddress Person name cpr-number home address Address street city printaddress address works at Company name c-address-street c-address-city printaddress works at name Company

42 DRY principle Techniques to avoid duplication Use appropriate abstractions Delegation Inheritance Classes with instance variables Methods with parameters Refactor to remove duplication Generate artefacts from a common source. Eg. Javadoc

43 KISS principle KISS principle Keep it short and simple (sometimes also: Keep it simple, stupid) simplest solution first Strive for simplicity Takes time!! refactor for simplicity Antoine de Saint Exupéry It seems that perfection is reached not when there is nothing left to add, but when there is nothing left to take away.

44 YAGNI principle YAGNI principle You ain t gonna needed it Focus on the task at hand E.g. using the observer pattern because it might be needed Two different kinds of flexibility make your design changeable tests, easy to refactor design for change Use good OO principles High cohesion, low coupling Decentralized control Both are needed, but focus on the first before introducing not needed constructs for the second

45 Low Coupling High coupling A B C D E F

46 Low Coupling High coupling A B C D E F Low coupling A C B E D F

47 High Cohesion Low Cohesion Person name cpr-number companyname work-address-street work-address-city home-address-street home-address-city

48 High Cohesion Low Cohesion Person name cpr-number companyname work-address-street work-address-city home-address-street home-address-city High Cohesion Person name cpr-number home address street city Address address works at name Company

49 Law of Demeter Law of Demeter Only talk to your immediate friends Only method calls to the following objects are allowed the object itself its components objects created by that object parameters of methods Law of Demeter = low coupling delegate functionality decentralised control

50 Computing the price of an order Order calculate price calculate base price calculate discounts 1 Customer name discount info quantity * OrderLine 1 name price Product

51 Computing the price of an order Order calculate price calculate base price calculate discounts 1 Customer name discount info calculate discount * OrderLine quantity calculate price 1 Product name price get price for quantity

52 Layered Architecture Eric Evans, Domain Driven Design, Addison-Wesley, 2004

53 Example Vending Machine Two different presentation layers Swing GUI Command line interface Current Money: DKK 5 0) Exit 1) Input 1 DKK 2) Input 2 DKK 3) Input 5 DKK 4) Select banana 5) Select apple 6) Cancel Select a number (0-6): Rest: DKK 2 Current Money: DKK 0 Dispensing: Apple

54 Architecture Presentation Layer Presentation Layer VendingMachineUI «delegate» VendingMachineTextUI «delegate» Observer Observer Application Layer Observable «delegate» VendingMachine dispenseditem : Fruit currentmoney : int totalmoney : int restmoney : int input(money : int) select(f : fruit) cancel() «enumeration» Fruit APPLE BANANA

55 Presentation Layer: Swing GUI sd:buy apple

56 Presentation Layer: Command Line Interface sd:buy apple

57 Advantages of the separation 1 Presentation layer easily changed 2 Additional presentation layers 3 Automatic tests under the GUI

58 Buy Fruit Fit tests Main Scenario ActionFixture start VendingMachineFixture check number of apples 5 enter input 1 enter input 2 press apple check dispensed item apple check rest money 0 check number of apples 4 Alternative Scenario a ActionFixture start VendingMachineFixture check number of apples 5 enter input 1 enter input 5 press apple check dispensed item apple check rest money 3 check number of apples 4 Use Case Buy Fruit main scenario: 1. Input coins until the price for the fruit to be selected is reached 2. Select a fruit 3. Vending machine dispenses fruit alternative scnearios: a1. User inputs more coins than necessary a2. select a fruit a3. Vending machine dispenses fruit a4. Vending machine returns excessive coins

59 Project Goal: Create a model Domain model Requirements model Test model Design model Class diagram Component diagram Behaviour diagrams Use case validation, i.e., use case realization Teams with 6 people Teams are formed next time Make sure you, or someone who can speak for you, is at the lecture next time to sign up the team. If not, there won t be any guarantees for being able to join a team

02291: System Integration

02291: System Integration Hubert Baumeister hub@imm.dtu.dk Spring 2011 Contents 1 Recap 1 2 More UML Diagrams 2 2.1 Object Diagrams........................................... 2 2.2 Communication Diagrams......................................