CS 151 ObjectOriented Design September 3 Class Meeting
CS 151: Object-Oriented Design September 3 Class Meeting Department of Computer Science San Jose State University Spring 2013 Instructor: Ron Mak www. cs. sjsu. edu/~mak
Ye Olde Waterfall Model Requirements Design Implementation Testing SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 2
The Waterfall Model o Make sure each phase is 100% complete and absolutely correct before proceeding to the next phase. o Big Design Up Front (BDUF) n Set requirements in stone before starting the design. o n o Otherwise, design work that is based on “incorrect” requirements would be wasted. Spend extra time at the beginning to make sure that the requirements and design are absolutely correct. The waterfall model has been mostly discredited. n n It doesn’t work! But it’s still commonly practiced. Requirements Design Source: Wikipedia article on “Waterfall Model” Implementation Testing SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 3
Project Phases o Today we know that development is a series of iterations. n n Each iteration is a “mini waterfall” consisting of design, code, and test. Advocates of Extreme Programming will say: design, test, code SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 4
Agile Software Development o Iterative and incremental development n Each iteration is a “mini waterfall”: o o n Requirements plan (with new requirements) refine design add new code unit and integration testing Design Implementation Testing Iterations are short: days and weeks rather than months. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 5
Ways to Elicit Requirements o Interview the stakeholders n n o Joint Application Design (JAD) n o But you need to know the right questions to ask! Be aware of cultural or political issues. Multi-day workshop with stakeholders and developers to hash out requirements. Ethnography n Developers “live with” the users to observe, learn, and understand their world. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 6
But … o Users don’t always know what they want! n n There must be an ongoing dialog among the developers, the clients, and the users. There needs to be an iterative process: o o Developers show something Clients and users validate Repeat If the developers force the clients or users to come up with the requirements too soon. . . n n They make something up! Such requirements will most likely be wrong or incomplete. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 7
Requirements Elicitation Tasks o Identify actors o Identify and document use cases n o Identify functional requirements n o Abstractions of actor-system interactions. Extract functional requirements from the use cases. Identify nonfunctional requirements n n Do this at the same time as when you’re identifying the functional requirements (as embodied by the use cases). Nonfunctional requirements have as much impact on the development and cost of the system as functional requirements. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 8
Use Cases o A use case describes how to achieve a single goal or accomplish a single task. n n o Actors are external agents that interact or communicate with the system. n n o A complete sequence of actions or events. Primary sequence plus alternate sequences (“exception paths”). A sequence is triggered by an actor. Focus on what the system must do, not how to do it. actor = role abstraction An actor can be a person or another system. A use case treats the system as a “black box”. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak ? 9
Example: Bank ATM System system Start up ATM actor Operator Shut down ATM system boundary use cases Log in customer interaction Log out customer Customer UML use case diagram SJSU Dept. of Computer Science Spring 2013: September 3 Withdraw cash Display balance CS 151: Object-Oriented Design © R. Mak Bank 10
Example Use Case Description o Name: Withdraw Cash o Goal: Customer withdraws cash from ATM. o Summary: A customer who has logged in can withdraw up to $500 cash in $20 bills. o Actors: The customer and the bank o Preconditions: n n What must be true before the use can start. The ATM has been started up. o n verb object See use case “Start up ATM”. The customer has inserted a valid bank card. The customer has entered a correct PIN. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 11
Example Use Case Description, cont’d o Trigger: The customer selects the “Withdraw Cash” option. o Primary sequence: 1. 2. 3. 4. 5. 6. At most about 10 steps. The system prompts the customer for the amount. The customer chooses from a list of amounts or enters a amount. The customer submits the amount. The system dispenses the amount in $20 bills. The bank deducts the amount from the customer’s balance. The system displays the customer’s balance n See use case “Display balance”. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 12
Example Use Case Description, cont’d o Alternate sequences: n 3. 1 The customer entered an amount not a multiple of $20. o o n 3. 2 The customer’s bank balance is insufficient. o o 3. 1. 1 The system displays a message to the customer. 3. 1. 2. The system prompts the customer for a new amount. 3. 2. 1 etc. Postconditions: n n What must be true after the use case is done. The customer receives the desired amount of cash. o The amount is deducted from the customer’s account. o The customer sees the new account balance. OR: The customer receives no cash. o The customer’s account is unchanged. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 13
Example Use Case Description, cont’d o Nonfunctional requirements: n n o The system responds to each customer input within 5 seconds. The system displays messages in either English, Spanish, or Vietnamese. Glossary n n n customer = a person who wants to withdraw cash from the ATM. bank = a system that maintains customer accounts and balances. etc. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 14
Use Case Guidelines o Use case names should be verb object. n o Keep use cases short, simple, and informal. n n o Each name should describe an achievable goal (e. g. , “Withdraw Cash”). Clients and users need to understand them. No GUI or implementation details. When your use cases cover most possible scenarios of your application, then you have enough requirements to start design. n Some use cases may cause you to add new requirements. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 15
Assignment #1 o Your team is going to write an application that where the computer plays the Rock-Paper-Scissors game with a human player. n o Note: You will not actually write this application for this assignment. A match consists of one or more throws: n The number of throws per match is an input parameter. o n n n Example: 20 throws per match For each throw, the human player inputs his or her choice (rock, paper, or scissors) and then the computer responds with its choice. Although the computer records the human’s choice, its own choice must not depend on knowledge of the human’s choice. The computer keeps track of who wins each throw (or it’s a tie). SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 16
Assignment #1 o Instead of entering his or her choice, the human can ask for n n o At the end of a match, the computer displays n n o the current score a help message the number of throws won by the human the number of throws won by the computer the number of ties who is the winner of the match See these links: n n http: //en. wikipedia. org/wiki/Rock-paper-scissors http: //www. nytimes. com/interactive/science/rock-paper-scissors. html SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 17
Assignment #1 o Write a Function Specification for this application. It must contain, in this order: n n n o problem statement objectives functional requirements (at least 6) nonfunctional requirements (at least 3) use case diagram containing at least 3 use cases use case descriptions (at least 3) Use case form: http: //www. cs. sjsu. edu/~mak/CS 151/assignments/1/Use. Case. Form. doc SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 18
Assignment #1 o Send as a Word document or a PDF to ron. mak@sjsu. edu n n Subject: CS 151 Assignment #1 team-name CC all the team members Team assignment (each team has one hand-in) Due Thursday, September 12 at 11: 59 PM SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 19
Where Do Classes Come From? o Textual analysis n n Look for nouns and verbs in your use cases. Nouns classes o n n Some nouns are actors. Verbs methods Class names should be nouns in the singular form, such as Inventory, Instrument. Spec. o How will the classes support the behaviors that your use cases describe? o Focus on concepts, not implementation. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 20
Categories of Classes o Things n o Agents n n n o Examples: Instrument, Instrument. Spec Represent doers of tasks. Names often end in “er” or “or” Examples: Scanner, Paginator Events and transactions n n Model records of activities that describe what happened in the past or what needs to be done later Example: Mouse. Event remembers when and where the mouse was moved or clicked. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 21
Categories of Classes o Users and roles n n n o System n n o Model a subsystem or the overall system being built. Typical methods: initialize, shutdown, read input System interfaces and devices n o Stand-in for the actual users of the application. Common in systems that are used by more than one person or where one person needs to perform distinct tasks. Examples: Administrator, Reviewer Interfaces to the host operating system, file system, etc. Foundation n Typically the built-in classes. Examples: String, Date SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 22
Class Responsibilities o Responsibilities correspond to verbs in the use cases. o Each responsibility should be owned by one and only one class. o Common mistakes: n n n Assigning a responsibility to an inappropriate class. Assigning too many responsibilities to a class. Ideally, each class should have a single primary responsibility. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 23
Class Responsibilities Example o class Automobile n n n n o start() stop() change. Tires() drive() wash() display. Oil. Level() check. Oil() n n n o o SJSU Dept. of Computer Science Spring 2013: September 3 drive() class Car. Wash n o start() stop() display. Oil. Level() class Driver n Too many responsibilities! A cohesive class does one thing really well and does not try to be something else. class Automobile wash() class Mechanic n n change. Tires() check. Oil() CS 151: Object-Oriented Design © R. Mak 24
Class Relationships: Dependency o Class C depends on class D: n n o Dependency is asymmetric. n n o Some method of C manipulates objects of D Example: Mailbox objects manipulate Message objects. The Message class is not aware of the existence of the Mailbox class. Therefore, Message objects do not depend on Mailbox objects. Loose coupling n n Minimize the number of dependency relationships. Another way for a design to handle change. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 25
Class Relationships: Aggregation o Class C aggregates class A: n o A special case of dependency. n n o Objects of class C contains objects of class A over a period of time. The “has-a” relationship. Example: An Inventory object has a list of Instrument objects. Multiplicity n n 1: 1 – Example: Each Person object has a single Street. Address object. 1: n – Example: Each Inventory object has an array of multiple Instrument objects. SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 26
Class Relationships: Inheritance o Class C inherits from class S. n n n o The “is-a” relationship. All class C objects are special cases of class S objects. Class S is the superclass of class C. Class C is a subclass of class S. An object of class C is an object of class S. Note n n Aggregation: A Mailbox object has a Message object. Inheritance: A Forwarded. Message object is a Message object. _ SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 27
- Slides: 27
