1. Chapter 17 – Object- Oriented Design

2. 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

3. 17.1 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

4. 5 phases 1. Analysis 2. Design 3. Implementation 4. Testing 5. Deployment / Operation

5. 5 phases 1. Analysis – What is the program supposed to do? Output: requirements document 2. Design 3. Implementation 4. Testing 5. Deployment / Operation

6. 5 phases 1. Analysis 2. Design – How is it going to be implemented? Output: Design document (UML/CRC cards/Javadocs) 3. Implementation 4. Testing 5. Deployment / Operation

7. 5 phases 1. Analysis 2. Design 3. Implementation – Write the code (edit/compile/run) Output: Completed program 4. Testing 5. Deployment / Operation

8. 5 phases 1. Analysis 2. Design 3. Implementation 4. Testing – Verify that it works correctly Output: Test cases passed (unit/system) 5. Deployment / Operation

9. 5 phases 1. Analysis 2. Design 3. Implementation 4. Testing 5. Deployment / Operation – Maintain the program Output: Public product, patches, new features

10. 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?

11. Waterfall Model

12. 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

13. 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 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 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

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

15. 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

16. Practices 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

17. Cont. 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

18. 17.2 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

19. Class = concept 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

20. 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

21. 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 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? Could have argument for both – but must balance generality with limiting design Could have argument for both – but must balance generality with limiting design

22. 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

23. 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)

25. 17.3 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 4 total important relationships 4 total important relationships Inheritance is often overused, recognize its unique application Inheritance is often overused, recognize its unique application

26. 3 relationships Inheritance Inheritance Interface Implementation Interface Implementation Aggregation Aggregation Dependency Dependency

27. 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

28. 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

29. 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

30. 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; }

31. 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

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

34. AT 17.1

35. Attributes and Methods in UML Diagrams UML has a lot of rules, but you can be as specific as necessary for the design UML has a lot of rules, but you can be as specific as necessary for the design Include access specifiers Include access specifiers + is public + is public - is private - is private Include parameter types and return type Include parameter types and return type Include relationships between classes Include relationships between classes