OODP- OOA/OOD– Lecture 3

1. OODP- OOA/OOD– Lecture 3 Introduction to the Design Model Eli Katsiri Department of Computer Science and Information Systems Birkbeck College, University of London Email: eli@dcs.bbk.ac.uk Web Page:http://www.dcs.bbk.ac.uk/~eli

2. The Unified Process Discipline Artifact Inc. Elab. Con. Tran. Bus. Modeling Domain Model s Requirements Use-case Model s r Vision, SS, Glossary s r Design Design Model s r Data Model s r Architecture Docum. s Implementation Implement. Model s r r Project Mngmt SW Developm. Plan s r r r Testing Test Model s r Environment Development Case s r

3. Overview of lecture 3 • The Design Model • Representation of the Design Model using UML notation: • Interaction diagrams • Collaboration diagrams • Sequence diagrams • Introduction to the Domain Model • Designing conceptual classes • Adding Attributes • Adding Associations • A mini workshop: examples of interaction diagrams

4. NextGen POS system Use Case 1.Process_Sale Descirption A user arrives at a POS sales point and tries to purchase an item. Actors Cashier (Primary)‏ Assumptions Cashier is identified and authenticated Steps • Customer arrives at POS checkout with goods to purchase. • Cashier starts a new sale. • WHILE more_items DO • Cashier enters item identifier. • System records sale line item and presents item description, price and running total. END WHILE • System presents total with taxes calculated. • Cashier tells Customer the total, and asks for payment. • Customer pays and System handles payment. • System presents receipt. • Customer leaves with receipt and goods (if any).

5. An SSD example :System :Cashier makeNewSale()‏ enterItem(itemID, quantity)‏ description, total * [more_items] endSale()‏ total with taxes makePayment(amount)‏ change due, receipt

6. Interaction diagrams Collaboration diagramSequence diagram msg1()‏ :ClassAInstance :ClassAInstance :ClassBInstance 1.msg2()‏ msg1()‏ 2.msg3()‏ msg2()‏ :ClassBInstance msg3()‏

7. Common interaction diagram notation • Classes and instances class example: instance examples: • Message expression syntax return:= message ({parameter:parameterType}) : returnType message example: spec := getProductSpec (id:ItemID) : ProductSpec (type information can be omitted)‏ Payment :Payment p1:Payment

8. Sequence diagram notation • Sequence is inferred by order of arrowed lines (top-bottom)‏ • Activation boxes show message nesting • Returns are illustrated with dotted lines :ClassA :ClassB msg0()‏ msg1()‏ create()‏ msg2()‏ :ClassC msg3()‏ msg4()‏ msg5()‏

9. Sequence diagram notation (cont.)‏ • Conditional messages • Messages to class objects :ClassA :ClassB ClassC msg0()‏ [day=Sunday] msg1()‏ opt [day=workday] msg2()‏ msg3()‏

10. Sequence diagram notation (cont.)‏ • Conditional messages • Mutually exclusive conditional messages • Messages to class objects :ClassA :ClassB ClassC msg0(int amount)‏ alt calculate()‏ [amount<10] calculate()‏ [else]

11. Sequence diagram notation (cont.)‏ • Iteration of a message • Iteration of multiple messages • Iteration over the items of a Collection object :CollClassInst :ClassAInstance :ClassBInstance msg0()‏ *[condition] msg1()‏ loop msg2()‏ msg3()‏ *[i:=1..N]

12. Asynchronous call‏ public class ClockStarter{ public void StartClock() { //Clock implements the runnable interface Thread t=new Thread(new Clock()); t.start(); //asynchronous call to the run method on clock }} :ClockStarter System startClock()‏ create() :Clock run() stopClock‏() runFinalisation()‏ destroy()

13. Example: Cellular phone • Consider the software that controls a very simple cellular telephone. • Such a phone has buttons for dialing digits, and a “send” button for initiating a call. • It has “dialler” hardware and software that gathers the digits to be dialled and emits the appropriate tones. • It has a cellular radio that deals with the connection to the cellular network. • It has a microphone, a speaker, and a display.

14. Cellular phone Use Case Use case: Make Phone Call • 1. User presses the digit buttons to enter the phone number. • 2. For each digit, the display is updated to add the digit to the phone number. • 3. For each digit, the dialler generates the corresponding tone and emits it from the speaker. • 4. User presses “Send” • 5. The “in use” indicator is illuminated on the display • 6. The cellular radio establishes a connection to the network. • 7. The accumulated digits are sent to the network. • 8. The connection is made to the called party.

15. Cellular Phone: Connection An asynchronous message is a message that returns immediately after spawning a new thread in the receiving object. The Connect message, for instance, returns immediately to the CellularRadio object. Yet you can see by the activation rectangle on the connection lifeline that the Connect method continues to execute. The Connect method is executing in a separate thread. This demonstrates the power that sequence diagrams have for showing concurrent multi-threaded interactions.

16. Polymorphism Payment {abstract} authorise() {abstract} Credit Payment DebitPayment authorise() authorise()

17. Inheritance‏ :Register Payment {abstract} doX()‏ authorise() :DebitPayment :Foo :Bar :CreditPayment authorise() doX() doA() authorise() doB()

18. Collaboration diagram notation • Message number sequencing • Message direction • Creation messages • Self messages 2.create(…)‏ msg()‏ :ClassA :ClassB 1.msg1()‏

19. Collaboration diagram notation (cont.)‏ • Nesting of messages • Conditional messages • Mutually exclusive conditional paths 1.msg1()‏ msg()‏ :ClassA :ClassB 1.1 [cond1]:msg2()‏ 2.msg3()‏ 2b[not cond2].msg5()‏ 2a[cond2].msg4()‏ :ClassC :ClassD

20. Collaboration diagram notation (cont.)‏ • Iteration or looping • Iteration over a collection • Messages to a class, rather than an instance ClassD 1.2: staticMsg()‏ 1.msg1()‏ msg()‏ :ClassA :ClassB 2*: msg3()‏ 1.1 * [i=1..N]:msg2()‏ * :ClassE :ClassC

21. Asynchronous invocation‏ startClock‏ 3.runFinalisation :ClockStarter System:Class 1.create 2. run‏ :Clock

22. Dynamic view Static view Interaction diagrams Class diagrams (next lecture)‏ The Domain Model • Comparing the Design Model to the Domain Model • they both use the object-oriented paradigm • the Domain Model describes the problem at hand (does the right thing), whereas the Design Model designs a good solution for the problem (“does the thing right”)‏ • the Domain Model provides a static view of conceptual classes, whereas the Design Model provides both a static and a dynamic view of software objects and classes.

23. From requirements to business modeling • Domain model • the most important artifact of business modeling • a visual representation of conceptual classes or real-world objects in a domain of interest • not a visualization of software components • Class diagrams (UML notation) show: • conceptual classes • attributes of conceptual classes • associations between conceptual classes • Why do business modeling?

24. How to generate a domain model • List candidate conceptual classes • Draw them in a domain model • Add associations for which information must be maintained • Add the attributes necessary to fulfill the information requirements

25. Conceptual classes • Three ways of viewing a conceptual class: • Symbol • Intension • Extension • In a domain model, we are interested in both the symbol and the intension of a conceptual class. “A sale represents the event of a purchase transaction. It has a date and a time.” Sale date time sale-1 sale-3 sale-2 sale-4

26. How to identify conceptual classes Use a conceptual class category list. - physical objects - specifications, descriptions - places - transactions - transaction line items - roles of people - containers or contained item - event - catalog etc. Linguistic analysis: Identify noun phrases in the use cases. Process Sale … Main Success Scenario: 1. Customer arrives at a POS checkout with goods to purchase. 2. Cashier starts a new sale. 3. Cashier enters item identifier. 4. System records sale line item and presents item description, price and total. …

27. Some common mistakes Why? Store should be a separate class A specification or description class is needed Improved object model Sale store Sale Store Item serial no description price prodId Product Specification description price prodId Item serial no

28. How to identify associations • An association is a relationship between object instances that indicates some meaningful and interesting connection • worth remembering • derived from the Common Associations List • A is a physical (or logical) part of B • A is physically (or logically) contained in • A is a description of B • A is known/captured/logged/recorded in B • A uses or manages B • A is related to a transaction B • Etc.

29. Candidate associations • Relationships that need to be remembered: • Register Records Sale (why?)‏ • Sale Paid-by Payment (why?)‏ • ProductCatalog Records ProductSpecification (why?)‏ • Relationships derived from the Common Associations List • SalesLineItem Is-contained-in Sale • Store Contains Item • ProductSpecification Describes Item • Cashier Is-member-of Store • Cashier Uses/Manages Register • Customer/Cashier Makes/Receives (Is-related-to) Payment • Etc.

30. Multiplicity of associations T * Attention! The multiplicity value of a relationship indicates how many object instances can be validly associated with another, at a particular moment, rather than over a span of time. 1..* T 1..2 T 5 T 1,2,5 T

31. Adding associations (names/multipl.)‏ Product Catalog Product Specification SalesLineItem Store Item Sale Captured-on Register Manager 1 1 Cashier Payment Customer

32. How to identify attributes • Attributes in a domain model should preferably be simple attributes or data types • Common types: boolean, date, number, string, text, time • Other types: address, color, geometrics, phone number, national insurance number, universal product code, postal codes • Do not relate conceptual classes with an attribute! • Represent a data type as a non-primitive class if: • It is composed of separate sections • Operations are associated with it (e.g. parsing)‏ • It has other attributes • It is an abstraction of one or more types (UPC, EAN)‏

33. More pitfalls Why? prodID in class Item is a foreign key. Foreign keys must not be added. amount is just a number. Where is the currency? Product Specification description prodID Item serial no prodID Describes 1 * Payment amount:Number Cashier name:String currentRegister:Register currentRegister is not a valid attribute. The connection between Cashier and Register should be denoted with a relationship

34. Adding attributes 1 ProductCatalog * Contains ProductSpecification … SalesLineItem quantity 1 1..* 1 Used-by * Store … 1..* Stocks Item Contained-in 1 0 1 Sale … Captured-on Register Manager 1 1 Started-by 1 1 1 1 Paid-by 1 Initiated-by 1 Records-sale-on Cashier Payment … Customer 1 1

35. Dynamic view Static view Interaction diagrams Class diagrams (next lecture)‏ The Design Model • Comparing the Design Model to the Domain Model • they both use the object-oriented paradigm • the Domain Model describes the problem at hand (does the right thing), whereas the Design Model designs a good solution for the problem (“does the thing right”)‏ • the Domain Model provides a static view of conceptual classes, whereas the Design Model provides both a static and a dynamic view of software objects and classes.

36. From requirements and analysis to design Process Sale ……………………………… UP Use-case Model Payment date time Sale amount Paid-by UP Domain Model 1 1 Sale amount getBalance():Money Payment date Time getTotal():Money Paid-by UP Design Model 1 1

37. Realisation (1) • From Design to Implementation Model • How to derive class definitions from DCDs • How to define method bodies from interaction diagrams SalesLineItem quantity:Integer getSubtotal():Money ProductSpec description:Text price:Money itemID:ItemID … Described-by 1 * productSpec public class SalesLineItem { private int quantity; private ProductSpec productSpec; public SalesLineItem(ProductSpec spec, int qty) { … } public Money getSubtotal() { … } }

38. Realisation(2) • From Design to Implementation Model • How to derive class definitions from DCDs • How to define method bodies from interaction diagrams 2:makeLineItem(spec,qty)‏ enterItem(id,qty)‏ :Sale :Register 2.1:create(spec,qty)‏ 1:spec:=getSpecification(id)‏ sl:SalesLine Item :Product Catalog public void enterItem (ItemID id, int qty)‏ { ProductSpec spec = catalog.getSpecification(id); currentSale.makeLineItem (spec, qty); }

39. Realisation (3) • From Design to Implementation Model • How to derive class definitions from DCDs • How to define method bodies from interaction diagrams Register Sale 1 isComplete:Boolean Time:DateTime endSale() enterItem(id:ItemID, qty:Integer) makeNewSale() makePayment(cashTendered: Money) currentSale becomeComplete() makeLineItem(…) makePayment(…) getTotal() public class Register { private productCatalog catalog; private Sale currentSale; public Register(ProductCatalog pc) { … } public void endSale() { … } public void enterItem(itemID id, int qty) {…} public void makeNewSale(){…} public void makePayment(Money cashTendered){…} }

40. Overview of lecture 4 • The Design Model • Representation of the Design Model using UML notation: • Collaborationdiagrams • Sequence diagrams • Introduction to the Object Design: • assigning responsibilities to objects • responsibilities and methods • responsibilities and interaction diagrams • design patterns • A mini workshop: examples of interaction diagrams

41. Main design consideration • The most important task in the Design Model is to assign responsibilities to objects. • The use cases describe different tasks that must be performed in their context. Who is responsible for performing these tasks? Are they going to be performed by one element (object) or delegated to (shared amongst) many elements? • Responsibilities are obligations of an object in terms of its behavior. There are two kinds: • knowing • doing

42. Object responsibilities • Doing responsibilities of an object include: creating an object, doing a calculation, initiating action in other objects, coordinating activities in other objects • Knowing responsibilities of an object include: knowing about private data, about related objects, about things it can derive and calculate • Examples: • “A Sale is responsible for creating SalesLineItem” • “A Sale is responsible for knowing its total”

43. Responsibilities and methods • In general, responsibilities are implemented using methods. • Methods either act alone or collaborate with other object methods. • Depending on its granularity, a responsibility may correspond to a single method in a class, or it may involve many methods across many classes packaged in a subsystem.

44. Responsibilities and interaction diagrams • How do we assign responsibilities (implemented as methods) to objects? Interaction diagrams show choices in assigning responsibilities. :Sale makePayment(cashRcvd)‏ create(cashRcvd)‏ :Payment It implies Sale objects have a responsibility to create Payments. This responsibility is invoked with a makePayment message and handled with a corresponding makePayment method.

45. Workshop: interaction diagrams • We will produce a set of collaboration and sequence diagrams • Goals of this exercise: • Learn notation: practice generating interaction diagrams • Understand how responsibilities are reflected in interaction diagrams • For each of the following scenarios, draw a corresponding collaboration and sequence diagram. Explain which object is responsible for the tasks mentioned in the scenarios.

46. Workshop scenarios • The system event startSale is first sent to a Register object, which clears its state and creates a new Sale object. • The system event newItem(id,quantity) is sent to the Register object. Upon receiving this system event, the Register object gets the spec of this item from a ProductCatalog object. It then asks the Sale object to create a new SalesLineItem object with this spec and quantity. • A payment is entered through a Register to a Sale object (system event). If the Sale’s state is complete a new Payment object is created.

47. Workshop scenarios • Like 3, with the following modification. If the Sale’s state is not complete then set it to be complete and create a new Payment object. • A system event asks for the total of a Sale object. The Sale evaluates its total by asking the SalesLineItem objects to evaluate their subtotals. Based on the spec, the SalesLineItem identifies which ProductSpec object knows the price of the corresponding product. A SalesLineItem identifies its subtotal based on the quantity and the price of the corresponding ProductSpec. • An Account object receives a message evaluateInterest. After checking that its state is active, the Account object asks each AccountEntry to evaluate its partial interest. Every AccountEntry does so by using a static method of an InterestCalculator class (and passing appropriate parameters).

48. Summary of lecture 4 • Interaction (Collaboration and Sequence) diagrams can be used to illustrate object interaction. • They show who messages are exchanged between objects and the order in which they are exchanged. • Interaction diagrams may represent a series of notions, like self-messages, create-messages, loops, iteration over collections, conditional messages, mutually exclusive paths and messages to classes. • The way in which objects interact in these diagrams implies how responsibilities are assigned to objects - a great design consideration. • Good object designs can be generated by applying general design principles (often called patterns).