chapter17 - Chapter 17 ObjectOriented Design Chapter Goals...

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: Chapter 17 ObjectOriented Design Chapter Goals To learn about the software life cycle To learn how to discover new classes and methods To understand the use of CRC cards for class discovery 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 learn how to use object-oriented design to build complex programs Software Life Cycle Software Life Cycle: all activities from initial analysis until obsolescence Formal process for software development Describes phases of the development process Gives guidelines for how to carry out the phases Software Life Cycle 1. 2. 3. 4. 5. Analysis Design Implementation Testing Deployment / Operation 1. Analysis 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 Output of this phase - requirements document Describes what program will do once completed Example User manual: tells how user will operate program Performance criteria (will complete X tasks in Y time) 2. Design Plan for implementation Decide what structures will best suit your task In object-oriented programming, this is choosing the classes and methods to use (and create) Output: Classes and methods description Usually diagramed using UML, can use CRC cards 3. Implementation Actual coding part of the process Edit Compile Run Output: Completed program 4. Testing Run tests to verify the program works correctly Remember the two main types of testing Unit Testing System Testing Output: a report of the tests and their results 5. Deployment AKA Operation, Maintenance Users install program Users use program for its intended purpose Bug fixes New features Example Analysis the specs we provide Design We provided for first four assignments, what you did for A5 Implementation the code you write to solve the specs Testing PathTester, BankAccountTester, etc. 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 Output from one phase signifies it is complete and can start the next phase Doesn't really work You've probably noticed this Was anyone's A5 perfect? Have your tests every worked completely? Waterfall Model Problems with Waterfall Model Specs usually have flaws Contradictions Non-thorough (what needs to happen on bad input?) Design too complicated, implementation flawed Testing incomplete What's the flaw? Customer didn't know what to expect How can you fully specify what the program needs to do without seeing it? Analogous to the edit-compile-run cycle Never get it right the first time, have to iterate back to prior phases Spiral Model Breaks development process down into multiple phases Early phases focus on the construction of prototypes Shows some aspects of the final product quick implementation Aren't deployed to the user, used to reconsider analysis Lessons learned from development of one prototype can be applied to the next iteration Spiral Design Analysis Prototype 2 Prototype 1 Implementation Final Product Deployment Testing Spiral 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 Extreme Programming Approach suggested by Kent Back in 1999 Goal: Simplicity Cut out formal structure 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?) Small Releases start small, update later Metaphor common story among programmers Simplicity simple solution is best Testing by everyone! Refactoring restructure as you go Extreme Programming Pair Programming Collective Ownership Continuous Organization 40-hour week On-site customer Coding standards Surprising results Studies have shown that the common sense approaches are synergistic, work better together Shows coding is not all of software development 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 In OOD this translates into 3 steps Discover classes Determine the responsibilities of each class Describe relationships between each class Discovering Classes Recall that a class represents a concept Some are concrete (i.e. real world) A bank account Rental items Database of items Pile Others are abstract Scanner Streams, Math Discovering Classes Simple Rule: Look for nouns in task description (specs) Obviously not all nouns are classes But can create a list of candidate classes Then determine which ones are useful Cross them off your list Example: Invoice To describe an invoice, you can start with a few ideas by looking at the nouns Invoice, LineItem, Customer Key points Class represents set of objects with the same behavior Entities with multiple occurrences in problem description are good candidates for objects Find out what they have in common Design classes to capture commonalities Why is Song a good class? Menu a bad one? Key Points Not all nouns need a new class 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 Could have argument for both but must balance generality with limiting design Key Points 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 Some classes may already exist Can use inheritance to add capabilities Behavior After set of classes have been sketched up, define behavior/purpose, of each class Verbs = methods Example: Compute amount due for invoice program Which class? Customer? Invoice? LineItem? CRC Card Describes a class, its responsibilities, and its collaborators Use an index card for each class Pick the class that should be responsible for each method (verb) Write the responsibility onto the class card Indicate what other classes are needed to fulfill responsibility (collaborators) CRC Design Informal method Not complete (only high level activity) Defines what classes define each method Also helps find other methods Why is LineItem a collaborator? What info do I need from it? How do I get it? getPrice() method for LineItem Relationships Between Classes Good practice to document relationship between classes Can uncover common behavior Divide uncommon classes among programming teams We have learned about inheritance as a relationship 3 total important relationships Inheritance is often overused, recognize its unique application 3 relationships Inheritance Aggregation Dependency Inheritance Is-a relationship Relationship between a more general class (superclass) and a more specialized class (subclass) Every savings account is a bank account DVD rental is a rental King is a chess piece Inheritance Every circle is an ellipse (with equal width and height) It is sometimes abused Should the class Tire be a subclass of a class Circle? The has-a relationship would be more appropriate here Aggregation Has-a relationship Objects of one class contain references to objects of another class Use an instance variable Class A aggregates class B if A contains an instance field of type B Aggregation vs. Inheritance Two are often confused Example Why not make BankAccount an instance field of CheckingAccount? How about extend a Circle for Tire A Tire is not a circle it is a car part But it can be described by a circle Aggregation A tire has a circle as its boundary: class Tire { . . . private String rating; private Circle boundary; } Example Car is a Vehicle Inheritance Car has a set of Tires Aggregation class Car extends Vehicle { . . . private Tire tires; } Dependency Dependency occurs when a class uses another class methods Uses relationship Example: many of our applications depend on the Scanner class to read input Aggregation is a stronger form of dependency Obviously uses the class if it is an instance field Dependency Reverse not true Just because there is a dependency, it doesn't mean aggregation is present Could be a local variable Example: local Scanner is not aggregation Aggregation is needed when an object needs to be remembered in between method calls I.e. cannot be sent as a parameter every time Relationship Inheritance Interface Implementation Aggregation Symbol Line Style Solid Dotted Solid Arrow Tip Triangle Triangle Diamond Dependency Dotted Open Class Diagram Attributes and Methods in UML Diagrams Do not need to list all attributes and methods in a UML diagram List important ones Key to meeting a requirement in the spec Useful for implementation to notice Don't have to repeat aggregation relationships Trivial internal structure Aggregation and Association Association: more general relationship between classes 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 Given a Bank object, you can navigate to Customer objects ...
View Full Document

This note was uploaded on 08/08/2008 for the course CS 302 taught by Professor Willbenton during the Spring '07 term at Wisconsin.

Ask a homework question - tutors are online