CS 151: Object-Oriented Design September 3 Class Meeting Department of Computer Science San Jose State University Spring 2013 Instructor: Ron Mak

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 2 Ye Olde Waterfall Model Requirements DesignImplementation Testing

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 3 The Waterfall Model  Make sure each phase is 100% complete and absolutely correct before proceeding to the next phase.  Big Design Up Front (BDUF) Set requirements in stone before starting the design.  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. It doesn’t work! But it’s still commonly practiced. Source: Wikipedia article on “Waterfall Model” Requirements Design Implementation Testing

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 4 Project Phases  Today we know that development is a series of iterations. 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 5 Agile Software Development  Iterative and incremental development Each iteration is a “mini waterfall”:  plan (with new requirements)  refine design  add new code  unit and integration testing Iterations are short: days and weeks rather than months. _ Requirements Design Implementation Testing

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 6 Ways to Elicit Requirements  Interview the stakeholders But you need to know the right questions to ask! Be aware of cultural or political issues.  Joint Application Design (JAD) Multi-day workshop with stakeholders and developers to hash out requirements.  Ethnography 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 7 But …  Users don’t always know what they want! There must be an ongoing dialog among the developers, the clients, and the users. There needs to be an iterative process:  Developers show something  Clients and users validate  Repeat  If the developers force the clients or users to come up with the requirements too soon... They may 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 8 Requirements Elicitation Tasks  Identify actors  Identify and document use cases Abstractions of actor-system interactions.  Identify functional requirements Extract functional requirements from the use cases.  Identify nonfunctional requirements 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 9 Use Cases  A use case describes how to achieve a single goal or accomplish a single task. 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.  Actors are external agents that interact or communicate with the system. 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 10 Example: Bank ATM System Log in customer Display balance Shut down ATM Start up ATM Log out customer Withdraw cash Operator Customer Bank system boundary actor interaction system UML use case diagram use cases

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 11 Example Use Case Description  Name: Withdraw Cash  Goal: Customer withdraws cash from ATM.  Summary: A customer who has logged in can withdraw up to $500 cash in $20 bills.  Actors: The customer and the bank  Preconditions: The ATM has been started up.  See use case “Start up ATM”. The customer has inserted a valid bank card. The customer has entered a correct PIN. What must be true before the use case can start. verb object

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 12 Example Use Case Description, cont’d  Trigger: The customer selects the “Withdraw Cash” option.  Primary sequence: 1. The system prompts the customer for the amount. 2. The customer chooses from a list of amounts or enters a amount. 3. The customer submits the amount. 4. The system dispenses the amount in $20 bills. 5. The bank deducts the amount from the customer’s balance. 6. The system displays the customer’s balance See use case “Display balance”. At most about 10 steps.

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 13 Example Use Case Description, cont’d  Alternate sequences: 3.1 The customer entered an amount not a multiple of $20.  The system displays a message to the customer.  The system prompts the customer for a new amount. 3.2 The customer’s bank balance is insufficient.  etc.  Postconditions: The customer receives the desired amount of cash.  The amount is deducted from the customer’s account.  The customer sees the new account balance. OR: The customer receives no cash.  The customer’s account is unchanged. What must be true after the use case is done.

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 14 Example Use Case Description, cont’d  Nonfunctional requirements: The system responds to each customer input within 5 seconds. The system displays messages in either English, Spanish, or Vietnamese.  Glossary 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 15 Use Case Guidelines  Use case names should be verb object. Each name should describe an achievable goal (e.g., “Withdraw Cash”).  Keep use cases short, simple, and informal. 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. 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 16 Assignment #1  Your team is going to write an application that where the computer plays the Rock-Paper-Scissors game with a human player. Note: You will not actually write this application for this assignment.  A match consists of one or more throws: The number of throws per match is an input parameter.  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 17 Assignment #1  Instead of entering his or her choice, the human can ask for the current score a help message  At the end of a match, the computer displays 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:

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 18 Assignment #1  Write a Function Specification for this application. It must contain, in this order: 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:

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 19 Assignment #1  Send as a Word document or a PDF to 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 20 Where Do Classes Come From?  Textual analysis Look for nouns and verbs in your use cases. Nouns  classes  Some nouns are actors. Verbs  methods Class names should be nouns in the singular form, such as Inventory, Instrument, InstrumentSpec.  How will the classes support the behaviors that your use cases describe?  Focus on concepts, not implementation. _

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 21 Categories of Classes  Things Examples: Instrument, InstrumentSpec  Agents Represent doers of tasks. Names often end in “er” or “or” Examples: Scanner, Paginator  Events and transactions Model records of activities that describe what happened in the past or what needs to be done later Example: MouseEvent 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 22 Categories of Classes  Users and roles 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  System Model a subsystem or the overall system being built. Typical methods: initialize, shutdown, read input  System interfaces and devices Interfaces to the host operating system, file system, etc.  Foundation Typically the built-in classes. Examples: String, Date

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 23 Class Responsibilities  Responsibilities correspond to verbs in the use cases.  Each responsibility should be owned by one and only one class.  Common mistakes: 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 24 Class Responsibilities Example  class Automobile start() stop() changeTires() drive() wash() displayOilLevel() checkOil()  class Automobile start() stop() displayOilLevel()  class Driver drive()  class CarWash wash()  class Mechanic changeTires() checkOil() Too many responsibilities! A cohesive class does one thing really well and does not try to be something else.

SJSU Dept. of Computer Science Spring 2013: September 3 CS 151: Object-Oriented Design © R. Mak 25 Class Relationships: Dependency  Class C depends on class D : Some method of C manipulates objects of D Example: Mailbox objects manipulate Message objects.  Dependency is asymmetric. The Message class is not aware of the existence of the Mailbox class. Therefore, Message objects do not depend on Mailbox objects.  Loose coupling 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 26 Class Relationships: Aggregation  Class C aggregates class A : Objects of class C contains objects of class A over a period of time.  A special case of dependency. The “has-a” relationship. Example: An Inventory object has a list of Instrument objects.  Multiplicity 1:1 – Example: Each Person object has a single StreetAddress 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 27 Class Relationships: Inheritance  Class C inherits from class S. 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 Aggregation: A Mailbox object has a Message object. Inheritance: A ForwardedMessage object is a Message object. _