1. Workshop for CS-AP Teachers
Object-Oriented Design
Workshop for CS-AP Teachers
Chapter 4
Object-Oriented Design
Georgia Institute of Technology

2. Object-Oriented Design
Learning Goals
Understand the basics of object-oriented design
Purpose of Design
Goals of Object-Oriented Design
Principles of Good Object-Oriented Design
How to transition from analysis to design
The design process
Georgia Institute of Technology

3. Object-Oriented Design
The purpose of design is to build an abstract, high-level, description of HOW the system will work
In Structured Design the emphasis is on:
Top-down design
Successive refinement of functions
In OO Design the emphasis is on:
Refinement of the classes and the relationships between them
Mapping classes to the implementation environment
Choosing libraries, designing the user interface
Georgia Institute of Technology

4. Goals of Object-Oriented Design
Decrease coupling: the degree to which two components depend on each other’s implementations (minimize the effect of changes)
Increase cohesion: the degree to which the responsibilities of a class are related (maximize the ability to combine objects)
Train cars are coupled together.
Georgia Institute of Technology

5. Good Object-Oriented Design
Is based on real world artifacts
That makes the design reusable
Information access is enough
Objects don't need information that they can't get to.
Objects can get to the information they need
directly or indirectly
Responsibility, control, and communication is distributed
No one object does everything
Attributes and operations are factored out as high in the class hierarchy as possible
Using inheritance
There should be little or no redundancy
Code should appear only once
Georgia Institute of Technology

6. Georgia Institute of Technology
Good Design Exercise
Double click on battle.html and run the battleship game
Open the class battle.java in the folder exercises/battleship
What do you think of this design?
How easy or hard would it be to change this game?
adding 2 players
adding more ships
changing the size of the game board
Georgia Institute of Technology

7. Moving from Analysis to Design
Object-Oriented Design
Moving from Analysis to Design
Determine the length of the next iteration
From 2 weeks to many months
Try to keep the iterations the same length
Review the use cases and determine which use cases will be implemented in the next iteration
Based on priority, risk, and time estimates
Tackle high priority and high risk first
Georgia Institute of Technology

8. Getting Started on Design
Object-Oriented Design
Getting Started on Design
Design can be partitioned into
Internal Design:
Converting conceptual models into specification models
Refinement of classes and the relationships between classes
Interface Design: Define the external interface to
Users
Persistent data
Other programs
OOD does not usually require
Pseudo-code for class operations
Class designs to be “frozen” before implementation commences
Design and programming phases often overlap
Georgia Institute of Technology

9. Object-Oriented Design
Design Process
Review the class diagram
Create detailed use cases
Include user interface details and interface prototypes
Modify the class diagram to add attributes, operations, and new classes
Found in the detailed use cases
Add packages as the number of classes gets too large
Determine how to make the objects persistent
Georgia Institute of Technology

10. Review the Class Diagram
Object-Oriented Design
Review the Class Diagram
Georgia Institute of Technology

11. Object-Oriented Design
Example Class Diagram
This model is just one feasible static object model
At design time, we can refine the model
Is a Deck the same object as the Stock pile?
How do we handle moving piles of cards?
Georgia Institute of Technology

12. Review the Class Diagram
Object-Oriented Design
Review the Class Diagram
Review classes and remove
vague classes
system
redundant classes
a class should appear only once in the diagram
irrelevant classes
outside the domain
Review the class names
Review attributes
Review operations
Review the relationships between classes
Georgia Institute of Technology

13. Object-Oriented Design
Review the Class Names
Do the names reflect the domain?
Does the name reflect the purpose of the class?
Is a connector between shapes a line or a connector?
Are the names pronounceable?
Does each word in a class name start with a capital letter: ShapeCanvas?
Are the names clear and unambiguous?
Are the names singular?
Course not Courses
Georgia Institute of Technology

14. Object-Oriented Design
Review Attributes
Add types to attributes
Using types in the chosen language (if needed)
Some attributes need to be expanded
A person’s name
Some attributes should be classes
An address
Some attributes can be grouped into a class
A date range
Not all OO languages require variables to have types. Smalltalk and lisp do not require variables to have types.
The top picture shows the Person class after analysis.
The bottom picture shows the Person class after a design review. It shows that a person can have 0 to many addresses. There is an association class that says for each 1 to 1 pairing of person and address there is a date range and an indication if this is a permanent or temporary location. This architecture would be useful for students and others that have several addresses during a year.
Georgia Institute of Technology

15. Object-Oriented Design
Review Operations
Check the names of the operations
Are they easy to read and clear?
Add parameters and return types
Check that the operations are on the correct class
The class you expect would be doing the action
Check if several classes have similar operations that can be put in a parent class
Even if the names of the operations are different
Georgia Institute of Technology

16. Object-Oriented Design
Review Inheritance
Use inheritance only when the child class is a “type of” the parent class
Use association if this isn’t true
Modify multiple inheritance to use interface realization
if you are using a language that doesn’t support multiple inheritance
A course session is not a type of course. A course session has a course associated with it.
The open triangle with the solid line is the UML generalization relationship. The open triangle with the dashed line is the realization relationship. Realization is used when the child class implements the interface defined in the parent class.
Georgia Institute of Technology

17. Add Classes to Clarify Relations
Object-Oriented Design
Add Classes to Clarify Relations
Doctor, Nurse, and Patient are all “a kind of” Person
But Doctor and Nurse are both Medical Personnel too
Introduce a new class Medical Person
This allows you to use the abstraction of medical person in your solution. For example both doctors and nurses can understand medical definitions but you want to have different definitions for non-medical people.
Georgia Institute of Technology

18. Delegation instead of Inheritance
Object-Oriented Design
Delegation instead of Inheritance
Use delegation to simply use (buy) another class
An object handles a message by sending messages to other objects
User gets the person name from person
Allows an object to invoke other objects’ operations without adding the overhead of inherited operations
A user could be thought to inherit from person but it isn’t really a type of person. By using the has-a relation instead we can subclass person.
If we have user inherit from person we can’t tell if we have medical users or not easily.
An ordered collection maintains elements in relative positions. It has methods that remove or add to either end of the ordered collection. So, is a stack a type of ordered collection or should it just buy (use) an ordered collection?
Inheritance tightly couples the base class and the super class. An ordered collection has many more operations than are needed or desired for a stack class. So, a stack class should only use an ordered class and not inherit from it.
Georgia Institute of Technology

19. Object-Oriented Design
Review Association
Use association when an object of a class “has a” object of another class
A catalog has items
Add navigability to show which side of an association cares about the relationship
A catalog will track the items in it but the items won’t care what catalog they are in
If you don’t have an arrow to show the navigability then it means two different things. Either you haven’t decided yet or both sides keep track of the relationship.
Georgia Institute of Technology

20. Create Detailed Use Cases
Object-Oriented Design
Create Detailed Use Cases
Georgia Institute of Technology

21. Create Detailed Use Cases
Object-Oriented Design
Create Detailed Use Cases
Expand the high-level use cases from analysis
Go into the details including the user interface
Elicit rare or minor use cases
People remember the “standard” things.
Consider future use cases
What things might we want the system to do in the near future?
Assign use cases to iterations
When will you implement the use case?
Some processes say don’t worry about what is going to happen in the future (XP). But, you should know what is happening during the iteration.
Georgia Institute of Technology

22. Object-Oriented Design
A Detailed Use Case
Defines how as well as what
Names the user interface elements
Names parts of the system
Go into the details of how
Describes the success scenario
Sequence of steps when everything goes well
Describes alternative scenarios as well
Times when things go wrong or
Times when things are handled differently
The success scenario describe what happens when everything goes well. This is also called the “happy day” scenario.
A scenario is a sequence of interactions between the user and the system. A use case is a collection of all scenarios about a user goal.
Georgia Institute of Technology

23. Scenarios versus Use Cases
Object-Oriented Design
Scenarios versus Use Cases
A scenario is a sequence of interactions between a user and a system
About a user goal
Example for the goal of making a bulleted list:
User selects some text and then clicks on the icon to make the text a bulleted list. The system modifies the text to make it a bulleted list.
A use case is a set of scenarios that have the same user goal
Includes the success scenario “happy day” scenario
Includes failures and alternative success scenarios as well
Georgia Institute of Technology

24. Detailed Use Case Format
Object-Oriented Design
Detailed Use Case Format
There is no standard format
Two typical types
Use case with alternative scenarios included in the body of the success scenario
Indenting used to show alternatives
Use case with uninterrupted success scenario
Alternatives are listed after the success scenario
Numbering
Some use simple numbering 1, 2, 3, …
Others use decimal numbering 1, , 1.2.1,
Use whatever format works for your team.
Georgia Institute of Technology

25. Detailed Use Case Example
Object-Oriented Design
Detailed Use Case Example
Name: Placing an Order
Actors: customer (initiates), salesperson, Frequency: common, Priority: Essential
A customer calls in an order. The salesperson brings up an Order Entry page. The User Interface (UI) prompts the salesperson for the number on the catalog that identifies the catalog and customer.
The customer gives the number
The salesperson verifies the customer name and catalog name and asks for the first item
For each item the customer gives the item number
For each item the salesperson gives the item name, price and asks the customer for the options and quantity
For each item the customer gives the quantity and the salesperson reserves this quantity for the customer
When there are no more items in the order the salesperson gives the shipping choices, length of time, and cost
The customer picks a shipping method
Georgia Institute of Technology

26. Detailed Use Case Example
Object-Oriented Design
Detailed Use Case Example
The salesperson gives the total cost of the order and gets or verifies the credit card information. A check is made to make sure the credit card will allow the charge.
The salesperson gives the order confirmation number (order number) and tells the customer when to expect the order.
The order status is set to pending and after the credit card approval occurs it changes to approved
The shipping clerk uses the Waiting to be Shipped page to see the items needed for the order.
The shipping clerk uses the Item Locator page to find where the items are in the warehouse.
The shipping clerk prints off an invoice, mailing label, and packs the order. The credit card is charged for the order.
The shipping company picks up the order and delivers it.
Georgia Institute of Technology

27. Object-Oriented Design
Use Case Alternatives
Alternative: New Customer
At step 1 this may be a new customer so use the use case of creating a new customer
Alternative: Expired Catalog
At step 1 this may be an expired catalog and if so notify the user that the prices may be out of date
Alternative: Backordered Item
At step 6 the item may indicate that it is on backorder. If so the salesperson will notify the customer and ask if they want to continue
Alternative: Cancel
At any point the customer can cancel the order
Georgia Institute of Technology

28. Detailed Use Case Example
Object-Oriented Design
Detailed Use Case Example
Use Case: Withdraw from ATM
Actors: Customer, ATM (Customer Initiates)
Frequency: Common
Priority: Essential
Description:
This slide shows another type of detailed use case with the customer actions on the left and the system actions on the right.
Georgia Institute of Technology

29. Vending Machine Exercise
Object-Oriented Design
Vending Machine Exercise
Objective: Practice Object-Oriented design
Duration: 30 minutes
Exercise: Modify a class diagram for the following requirements. Then write a detailed use case describing getting an item from the vending machine.
Create the next generation vending machine that can tell when a part of it is broken and can place a service call so that a repairman can come and fix it.
Georgia Institute of Technology

30. Vending Machine Class Diagram
Object-Oriented Design
Vending Machine Class Diagram
Georgia Institute of Technology

31. Revised Vending Machine
Object-Oriented Design
Revised Vending Machine
By having all parts of a vending machine inherit from the abstract class part we can have each part have a part number and an attribute that says if it is working. We can also have a call for service that will place a service call with a service company that can fix that part.
The part class also has an abstract method checkIfBroken that each child will need to override. Each part may check in a different manner.
Georgia Institute of Technology

32. Detailed Vending Use Case
Object-Oriented Design
Detailed Vending Use Case
Name: Get item from machine
Actors(s): Customer (initiates)
Frequency: Common
Priority: Essential
Description:
The customer starts a transaction by putting money in the vending machine
The money holder validates the money entered and if valid adds it to the amount entered
The money holder updates the display to show the amount entered.
The customer pushes an item selector (sends a select to the item selector)
The item selector tells the item holder to dispense
The item holder gets the price from the item.
The item holder tells the display to display the item price.
The item holder checks if the money holder can make the required change.
The item holder dispenses the item
The item holder tells the money holder to dispense the change
The item holder tells item to decrement the quantity in stock
Item will decrement the quantity in stock and check if it is at the restock level and if so send a message to the supplier
Georgia Institute of Technology

33. Detailed Vending Use Case - Alts
Object-Oriented Design
Detailed Vending Use Case - Alts
Alternative – Validate money fails
Step 2. If the validate money fails the money is returned to the user and the display tells the user
Alternative – Can’t make change
Step 8. If the money holder can’t make change then the display tells the user so the user can cancel the transaction
Alternative – Can’t dispense item
Step 9. If the item isn’t dispensed the display is updated to tell the user so the user can cancel the transaction
Alternative – Can’t reach supplier
Step 12. If the supplier can’t be reached try again every few hours and notify the vending machine company
The last alternative means the class diagram will need to include the vending machine company.
Georgia Institute of Technology

34. Revise the Class Diagram
Object-Oriented Design
Revise the Class Diagram
Georgia Institute of Technology

35. Adding Operations and Attributes
Object-Oriented Design
Adding Operations and Attributes
Creating detailed use cases will likely uncover attributes and operations that were not thought of in analysis.
Determining where the new attributes and operations should go depends on the class responsibilities.
The assignment of responsibilities is a crucial skill in object-oriented design.
Often new classes need to be created to refine the responsibilities.
In the mail order application we had items holding the quantity of items in the warehouse. But if we have multiple warehouses then perhaps a new class the ItemWarehouse class should be created to hold the quantity of an item in a particular warehouse.
Georgia Institute of Technology

36. Responsibility Assignment
Object-Oriented Design
Responsibility Assignment
Where to put an attribute?
Assign attributes to the class that it belongs to or who you would expect to be able to ask about it.
Where to put an operation?
Assign an operation to the class that has the data needed for the operation or assign the operation to an intermediate class to reduce coupling (indirection).
Georgia Institute of Technology

37. Responsibility Assignment
Object-Oriented Design
Responsibility Assignment
Who should create an object of a class?
A should create B if A contains B.
A should create B if A has the initializing data for B.
Who should handle an event?
The object that takes action based on the event or the container that holds the object that where the event occurred.
Georgia Institute of Technology

38. Georgia Institute of Technology
Summary
The purpose of design is to build a high-level description of how the system will work
The goals of design are to reduce coupling and increase cohesion
During design we should
Build a class diagram of the solution
Add types and method parameters
Create detailed use cases
Create user interface prototypes
Georgia Institute of Technology