Chapter 17 – Object- Oriented Design

Chapter Goals To learn about the software life cycle To learn about the software life cycle To learn how to discover new classes and methods To learn how to discover new classes and methods To understand the use of CRC cards for class discovery To understand the use of CRC cards for class discovery To be able to identify inheritance, aggregation, and dependency relationships between classes To be able to identify inheritance, aggregation, and dependency relationships between classes To master the use of UML class diagrams to describe class relationships To master the use of UML class diagrams to describe class relationships To learn how to use object-oriented design to build complex programs To learn how to use object-oriented design to build complex programs

Software Life Cycle Software Life Cycle: all activities from initial analysis until obsolescence Software Life Cycle: all activities from initial analysis until obsolescence Formal process for software development Formal process for software development Describes phases of the development process Describes phases of the development process Gives guidelines for how to carry out the phases Gives guidelines for how to carry out the phases

Software Life Cycle 1. Analysis 2. Design 3. Implementation 4. Testing 5. Deployment / Operation

1. Analysis Decide what the project is suppose to do, what the goal of the final product is Decide what the project is suppose to do, what the goal of the final product is Do NOT think about how the program will accomplish tasks Do NOT think about how the program will accomplish tasks Output of this phase - requirements document Output of this phase - requirements document Describes what program will do once completed Describes what program will do once completed Example – Example – User manual: tells how user will operate program User manual: tells how user will operate program Performance criteria (will complete X tasks in Y time) Performance criteria (will complete X tasks in Y time)

2. Design Plan for implementation Plan for implementation Decide what structures will best suit your task Decide what structures will best suit your task In object-oriented programming, this is choosing the classes and methods to use (and create) In object-oriented programming, this is choosing the classes and methods to use (and create) Output: Classes and methods description Output: Classes and methods description Usually diagramed using UML, can use CRC cards Usually diagramed using UML, can use CRC cards

3. Implementation Actual coding part of the process Actual coding part of the process Edit  Compile  Run Edit  Compile  Run Output: Completed program Output: Completed program

4. Testing Run tests to verify the program works correctly Run tests to verify the program works correctly Remember the two main types of testing Remember the two main types of testing Unit Testing Unit Testing System Testing System Testing Output: a report of the tests and their results Output: a report of the tests and their results

5. Deployment AKA Operation, Maintenance AKA Operation, Maintenance Users install program Users install program Users use program for its intended purpose Users use program for its intended purpose Bug fixes Bug fixes New features New features

Example Analysis – the specs we provide Analysis – the specs we provide Design – We provided for first four assignments, what you did for A5 Design – We provided for first four assignments, what you did for A5 Implementation – the code you write to solve the specs Implementation – the code you write to solve the specs Testing – PathTester, BankAccountTester, etc. Testing – PathTester, BankAccountTester, etc. Deployment – TAs using your program on sample runs. Our reaction is your grade Deployment – TAs using your program on sample runs. Our reaction is your grade

Perfect World In a perfect world, everything would flow perfectly in this process In a perfect world, everything would flow perfectly in this process Output from one phase signifies it is complete and can start the next phase Output from one phase signifies it is complete and can start the next phase Doesn’t really work Doesn’t really work You’ve probably noticed this You’ve probably noticed this Was anyone’s A5 perfect? Was anyone’s A5 perfect? Have your tests every worked completely? Have your tests every worked completely?

Waterfall Model

Problems with Waterfall Model Specs usually have flaws Specs usually have flaws Contradictions Contradictions Non-thorough (what needs to happen on bad input?) Non-thorough (what needs to happen on bad input?) Design too complicated, implementation flawed Design too complicated, implementation flawed Testing incomplete Testing incomplete

What’s the flaw? Customer didn’t know what to expect Customer didn’t know what to expect How can you fully specify what the program needs to do without seeing it? How can you fully specify what the program needs to do without seeing it? Analogous to the edit-compile-run cycle Analogous to the edit-compile-run cycle Never get it right the first time, have to iterate back to prior phases Never get it right the first time, have to iterate back to prior phases

Spiral Model Breaks development process down into multiple phases Breaks development process down into multiple phases Early phases focus on the construction of prototypes Early phases focus on the construction of prototypes Shows some aspects of the final product  quick implementation Shows some aspects of the final product  quick implementation Aren’t deployed to the user, used to reconsider analysis Aren’t deployed to the user, used to reconsider analysis Lessons learned from development of one prototype can be applied to the next iteration Lessons learned from development of one prototype can be applied to the next iteration

Deployment Testing Implementation Design Analysis Spiral Prototype 2 Final Product Prototype 1

Spiral Increased probability of developing a quality interface/system Increased probability of developing a quality interface/system Problem: can lead to many iterations, and process can take too long to complete  high cost and low throughput Problem: can lead to many iterations, and process can take too long to complete  high cost and low throughput

Extreme Programming Approach suggested by Kent Back in 1999 Approach suggested by Kent Back in 1999 Goal: Simplicity Goal: Simplicity Cut out formal structure Cut out formal structure Focus on set of practices to make programming more efficient and satisfactory Focus on set of practices to make programming more efficient and satisfactory

Extreme Programming Realistic planning: Customers make business decisions (what should it look like?), programmers make technical ones (how do we that?) Realistic planning: Customers make business decisions (what should it look like?), programmers make technical ones (how do we that?) Small Releases – start small, update later Small Releases – start small, update later Metaphor – common story among programmers Metaphor – common story among programmers Simplicity – simple solution is best Simplicity – simple solution is best Testing – by everyone! Testing – by everyone! Refactoring – restructure as you go Refactoring – restructure as you go

Extreme Programming Pair Programming Pair Programming Collective Ownership Collective Ownership Continuous Organization Continuous Organization 40-hour week 40-hour week On-site customer On-site customer Coding standards Coding standards

Surprising results Studies have shown that the common sense approaches are synergistic, work better together Studies have shown that the common sense approaches are synergistic, work better together Shows coding is not all of software development Shows coding is not all of software development Let’s talk more about designing… Let’s talk more about designing…

Discovering Classes Recall that part of the design phase is deciding what structures you need to solve a task Recall that part of the design phase is deciding what structures you need to solve a task In OOD this translates into 3 steps In OOD this translates into 3 steps Discover classes Discover classes Determine the responsibilities of each class Determine the responsibilities of each class Describe relationships between each class Describe relationships between each class

Discovering Classes Recall that a class represents a concept Recall that a class represents a concept Some are concrete (i.e. real world) Some are concrete (i.e. real world) A bank account A bank account Rental items Rental items Database of items Database of items Pile Pile Others are abstract Others are abstract Scanner Scanner Streams, Math Streams, Math

Discovering Classes Simple Rule: Simple Rule: Look for nouns in task description (specs) Look for nouns in task description (specs) Obviously not all nouns are classes Obviously not all nouns are classes But can create a list of candidate classes But can create a list of candidate classes Then determine which ones are useful Then determine which ones are useful Cross them off your list Cross them off your list

Example: Invoice To describe an invoice, you can start with a few ideas by looking at the nouns To describe an invoice, you can start with a few ideas by looking at the nouns Invoice, LineItem, Customer Invoice, LineItem, Customer

Key points Class represents set of objects with the same behavior Class represents set of objects with the same behavior Entities with multiple occurrences in problem description are good candidates for objects Entities with multiple occurrences in problem description are good candidates for objects Find out what they have in common Find out what they have in common Design classes to capture commonalities Design classes to capture commonalities Why is Song a good class? Menu a bad one? Why is Song a good class? Menu a bad one?

Key Points Not all nouns need a new class Not all nouns need a new class Address needs to represented, do we need a new class or can we use a String? Address needs to represented, do we need a new class or can we use a String? Represent some entities as objects, others as primitive types Represent some entities as objects, others as primitive types Could have argument for both – but must balance generality with limiting design Could have argument for both – but must balance generality with limiting design

Key Points Not all classes can be discovered in analysis phase Not all classes can be discovered in analysis phase Creating a database class may not be evident from specifications, but further analysis and actual implementation dictate that one is better Creating a database class may not be evident from specifications, but further analysis and actual implementation dictate that one is better Some classes may already exist Some classes may already exist Can use inheritance to add capabilities Can use inheritance to add capabilities

Behavior After set of classes have been sketched up, define behavior/purpose, of each class After set of classes have been sketched up, define behavior/purpose, of each class Verbs = methods Verbs = methods Example: Compute amount due for invoice program Example: Compute amount due for invoice program Which class? Customer ? Invoice ? LineItem ? Which class? Customer ? Invoice ? LineItem ?

CRC Card Describes a class, its responsibilities, and its collaborators Describes a class, its responsibilities, and its collaborators Use an index card for each class Use an index card for each class Pick the class that should be responsible for each method (verb) Pick the class that should be responsible for each method (verb) Write the responsibility onto the class card Write the responsibility onto the class card Indicate what other classes are needed to fulfill responsibility (collaborators) Indicate what other classes are needed to fulfill responsibility (collaborators)

CRC  Design Informal method Informal method Not complete (only high level activity) Not complete (only high level activity) Defines what classes define each method Defines what classes define each method Also helps find other methods Also helps find other methods Why is LineItem a collaborator? What info do I need from it? How do I get it? Why is LineItem a collaborator? What info do I need from it? How do I get it?  getPrice() method for LineItem  getPrice() method for LineItem

Relationships Between Classes Good practice to document relationship between classes Good practice to document relationship between classes Can uncover common behavior Can uncover common behavior Divide uncommon classes among programming teams Divide uncommon classes among programming teams We have learned about inheritance as a relationship We have learned about inheritance as a relationship 3 total important relationships 3 total important relationships Inheritance is often overused, recognize its unique application Inheritance is often overused, recognize its unique application

3 relationships Inheritance Inheritance Aggregation Aggregation Dependency Dependency

Inheritance Is-a relationship Is-a relationship Relationship between a more general class (superclass) and a more specialized class (subclass) Relationship between a more general class (superclass) and a more specialized class (subclass) Every Every savings account is a bank account savings account is a bank account DVD rental is a rental DVD rental is a rental King is a chess piece King is a chess piece

Inheritance Every circle is an ellipse (with equal width and height) Every circle is an ellipse (with equal width and height) It is sometimes abused It is sometimes abused Should the class Tire be a subclass of a class Circle? Should the class Tire be a subclass of a class Circle? The has-a relationship would be more appropriate here The has-a relationship would be more appropriate here

Aggregation Has-a relationship Has-a relationship Objects of one class contain references to objects of another class Objects of one class contain references to objects of another class Use an instance variable Use an instance variable Class A aggregates class B if A contains an instance field of type B Class A aggregates class B if A contains an instance field of type B

Aggregation vs. Inheritance Two are often confused Two are often confused Example Example Why not make BankAccount an instance field of CheckingAccount ? Why not make BankAccount an instance field of CheckingAccount ? How about extend a Circle for Tire How about extend a Circle for Tire A Tire is not a circle – it is a car part A Tire is not a circle – it is a car part But it can be described by a circle But it can be described by a circle

Aggregation A tire has a circle as its boundary: A tire has a circle as its boundary: class Tire {... private String rating; private Circle boundary; }

Example Car is a Vehicle – Inheritance Car is a Vehicle – Inheritance Car has a set of Tires – Aggregation Car has a set of Tires – Aggregation class Car extends Vehicle {... private Tire[] tires; }

Dependency Dependency occurs when a class uses another class methods Dependency occurs when a class uses another class methods Uses relationship Uses relationship Example: many of our applications depend on the Scanner class to read input Example: many of our applications depend on the Scanner class to read input Aggregation is a stronger form of dependency Aggregation is a stronger form of dependency Obviously uses the class if it is an instance field Obviously uses the class if it is an instance field

Dependency Reverse not true Reverse not true Just because there is a dependency, it doesn’t mean aggregation is present Just because there is a dependency, it doesn’t mean aggregation is present Could be a local variable Could be a local variable Example: local Scanner is not aggregation Example: local Scanner is not aggregation Aggregation is needed when an object needs to be remembered in between method calls Aggregation is needed when an object needs to be remembered in between method calls I.e. cannot be sent as a parameter every time I.e. cannot be sent as a parameter every time

RelationshipSymbolLine StyleArrow Tip Inheritance SolidTriangle Interface Implementation DottedTriangle Aggregation SolidDiamond Dependency DottedOpen

Class Diagram

Attributes and Methods in UML Diagrams Do not need to list all attributes and methods in a UML diagram Do not need to list all attributes and methods in a UML diagram List important ones List important ones Key to meeting a requirement in the spec Key to meeting a requirement in the spec Useful for implementation to notice Useful for implementation to notice Don’t have to repeat aggregation relationships Don’t have to repeat aggregation relationships Trivial internal structure Trivial internal structure

Aggregation and Association Association: more general relationship between classes Association: more general relationship between classes Use early in the design phase Use early in the design phase A class is associated with another if you can navigate from objects of one class to objects of the other A class is associated with another if you can navigate from objects of one class to objects of the other Given a Bank object, you can navigate to Customer objects Given a Bank object, you can navigate to Customer objects