OO Methodology Elaboration Phase Iteration 1- Part 2

2 Table of Contents Use-case model: System Sequence Diagrams Domain Model: Visualizing Concepts Domain Model: Adding Associations Domain Model: Adding Attributes Use-Case Model: Adding Detail with Operation Contracts From Requirements to Design Interaction Diagram Notations GRASP: Designing Objects with Responsibilities Design Model: Use-case Realizations Design Model: Determining Visibilities Design Model: Creating Design Class Diagrams Implementation Model

3 Operation Contracts Contracts describe detailed system behavior in terms of state changes to objects in the Domain Model Contracts may be defined for system operations System operations and the system interface

4 Contracts Sections Defined in terms of preconditions and postconditions Operation: name of operation and parameters Cross references: use cases this operation can occur within Preconditions: noteworthy assumptions about the state of the system or objects in the Domain Model before execution of the operation Postconditions:the state of objects in the Domain Model after completion of the operation Example: enterItem operation Operation: enterItem(itemID: ItemID, quantity:Integer) Cross references: Process Sale Preconditions:There is a sale underway Postconditions:- A SelesLineIterm instance sli was created (instance creation) - sli was associated with the current Sale (association formed) - sli.quantity became quantity (attribute modification) - sli was associated with a ProductSpecification, based on itemID match(association formed)

5 Contracts Post conditions describe changes in the state of objects in the Domain Model. State change has three categories –instance creation and deletion –attribute modification –association (links) formed and broken Postconditions are related to the Domain Model Contracts are expressed in a declarative way without describing how they are to be achieved –requirement analysis, not software design The contracts will not be complete Writing contracts leads to Domain Model updates Why not the contractual requirements in use cases –use cases become overly verbose and detailed When are contracts useful –in those situations where the details and complexity of required state changes are awkward to capture in use cases

6 Guidelines: Contracts 1.Identify system operations from the SSDs 2.For system operations that are complex and perhaps subtle in their result, or which are not clear in the use case, construct a contract 3.To describe the postconditions, use the following categories: 1.instance creation and deletion 2.attribute modification 3.associations formed and broken State the postconditions in a declarative, passive past tense form to emphasize the declaration of state change rather than a design of how it is going to be achieved: (better) A SalesLineItem was created (worse) Create a SalesLineItem Don’t forget forming association between existing objects and newly created objects

7 NextGen POS Example System Operations of Process Sale Operation: MakeNewSale() Cross references: Process Sale Preconditions:none Postconditions:- A Sale instance s was created - s was associated with the Register - Attributed of s were initialized Operation: endSale() Cross references: Process Sale Preconditions:There is a sale underway Postconditions:- set the completion status in the Sale Operation: makePayment(amount:Money) Cross references: Process Sale Preconditions:completion of Sale Postconditions:- A Payment instance p was created - p.amountTendered became amount - p was associated with the current Sae - The current Sale was associated with the Store (for logging)

8 Contracts and UML Contracts can be specified by operations in UML –an UML operation is a specification of a transformation or query that an object may be called to execute An UML operation is an abstraction, not implementation, a method is an implementation of an operation An UML operation has a signature and also an operation specification (flexible, but pre- and postconditions are most well-known approach to formal operation specification) Operation specification can be expressed by OCL(Object Constraint Language) System::makeNewSale() pre: post:

9 Sample UP Artifact Influence

10 Contract Relationship to other Artifacts

11 From Requirements to Design Iteratively do the right thing, do the thing right –the requirement and object-oriented analysis – do the right thing –design work – do the thing right During object design, a logical solution is developed Two important artifacts –Interaction Diagrams –(Design) Class Diagrams Fundamental object design requires knowledge of: –principles of responsibility assignment –design patterns Object Design Skill vs UML Notation Skill

12 Interaction Diagram Notations Interaction diagrams –to illustrate how objects interact via messages –collaboration diagrams –sequence diagrams TypeStrengthsWeakness sequenceclearly show sequence or time ordering of messages simple consumes horizontal space collaborationbetter to illustrate complex branching, iteration, and concurrent behavior difficult to see sequence of messages more complex

13 GRASP: Designing Objects with Responsibilities Objectives –Define patterns –Learn to apply five of the GRASP patterns Object design is sometimes described: After identifying your requirements and creating a domain model, then add methods to the software classes, and define the message between the objects to fulfill the requirements How? We need a methodical, rational, explainable approach in which we apply design principles and design reasoning –based on patterns of assigning responsibilities

14 Responsibilities and Methods Responsibilities are related to the obligations of an object in terms of its behavior Two types of responsibilities –Doing responsibilities doing something itself, such as creating an object or a calculation initiating action in other objects controlling and coordinating activities in other objects –Knowing responsibilities knowing about private encapsulated data knowing about related objects knowing about things it can derive or calculate Examples –a Sale is responsible for creating SalesLineItems –a Sale is responsible for knowing its total A responsibility is not the same thing as a method –responsibilities are implemented using methods that either act alone or collaborate with other methods or objects

15 Responsibilities and Interaction Diagrams Determining the assignment of responsibilities often occurs during the creation of interaction diagrams(part of Design Model), Interaction diagrams show choices in assigning responsibilities to objects Sale objects have been given a responsibility to create Payments The fulfillment of this responsibility requires collaboration to create the Payment object

16 Patterns A pattern is a named description of a problem and solution that can be applied to new contexts, with advice on how to apply it in various situations A pattern consists of: –Pattern Name: –Problem: –Solution: GRASP –patterns of general principles in assigning responsibilities –first five patterns Information Expert Creator High Cohesion Low Coupling Controller

17 Information Expert Solution Assign a responsibility to the information expert – class that has the information necessary to fulfill the responsibility (Do-It-Myself strategy) Problem What is a general principle of assign responsibilities to objects ExampleWho should be responsible for knowing the grand total of a sale? 1) What information is need to determine the grand total? A) need to know about all the SalesLineItem instances of the sale

18 Information Expert 2) Sale is a suitable class of object 3) Create a software class in the Design Model (Sale) 4) Give it the responsibility of knowing its total (getTotal) 5) Who should be responsible for knowing the subtotal? 6) What information is needed to determine the line item subtotal? A) SalesLineItem.quantity and ProductionSpecification. price 7) SalesLineItem should determine the subtotal 8) Add SalesLineItem class and getSubtotal() method

19 Information Expert 9)Sale needs to send getSubtotal message to each of the SalesLineItem 10)To fulfill the responsibility of knowing and answering its subtotal, a SalesLineItem needs to know the product price 11)ProductSpecification is an information expert on answering its price 12)Add ProductSpecification class and getPrice() methods 13)SalesLineItem sends getPrice message to ProductSpecification

20 Information Expert Contradiction –who should be responsible for saving a Sale in a database? –by information expert, the answer would be Sale –But, this leads to problems in cohesion, coupling, duplication and violate a basic architectural principle, separation of concerns –Keep application logic in one place, keep database logic in another place, and so forth. Benefits –Information encapsulation => low coupling –Behavior is distributed across the classes that have the required information => high cohesion

21 Creator Solution Assign class B the responsibility to create an instance of class A if on or more of the following is true: –B aggregates A objects –B contains A objects –B records instances of A objects –B closely uses A objects –B has the initializing data ProblemWho should be responsible for creating a new instances of some class ExampleWho should be responsible for creating a SalesLineItem instance?

22 Low Coupling Solution Assign a responsibility so that remains low ProblemHow to support low dependency, low change impact, and increased reuse? Example What class should be responsible to create Payment and associate it with the Sale? Solution1) Register class is a candidate since it records a Payment in the real world domain(Creator Pattern) Solution 2): Sale creates Payments (Low Coupling)

23 High Cohesion Solution Assign a responsibility so that cohesion remains high ProblemHow to keep complexity manageable? ExampleWho create Payment and associate it with Sale Solution 1) Register creates it (Creator) Imagine there were fifty system operations and Register should be responsible for them => incohesive

24 High Cohesion Solution 2) Register delegates the payment creation responsibility to the Sale => higher cohesion in the Register Cohesion and Coupling are yin and yang of software engineering Exceptions SQL statements in one class Coarse-Grained Remote Interface

25 Controller Solution Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: –represents the overall system, device, or subsystem (Facade Controller) –represent a use case scenario within which the system event occurs, often named Handler, Controller etc. (Use case controller) ProblemWho should be responsible for handling an input system event? - A Controller is non-user interface object responsible for receiving or handling a system event - A Controller defines the method for the system operation

26 Controller ExampleWho responsible for enterItem system operation? Solutions Facade controller : Register, POSSystem Use case controller : ProcessSaleHandler, ProcessSaleController

27 Facade vs Use-Case Controller

28 Interface Layer does not handle system events

29 Interface Layer does not handle system events