Week 2

• Concepts normally in week 1• Software Development Life Cycle• Use Cases• Lab project• Lab 1

Kate Gregory

Date Week Topic Hand Out Due Back Test

6-Sep-13 1 Administrivia / Overview / Motivation, benefits of OO

13-Sep-13 2 Use Cases Lab 1: Use cases    

20-Sep-13 3 CRC Cards, collab graphs Lab 2: CRC cards lab 1 5%

27-Sep-134 start class diag lab 2 5%

4-Oct-13 5 Finish class diag, Associations Lab 3: Class Diag

11-Oct-13 6 Inh & Polymorphism / midterm review lab 3 5%

18-Oct-13 7 midterm Midterm 25%

25-Oct-13 Reading Break

1-Nov-13 8 Interaction diag / Design Patterns Lab 4: Interaction Diag    

8-Nov-13 9 Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID

Lab 5: Critiques lab 4 5%

15-Nov-13 10 State diagrams / Activity diagrams / Summary and Conclusion / The Future

22-Nov-13 11 Critiques critique lab (before class) 15%

29-Nov-13 12 Critiques

TBD Final Exam Final 40%

Kate Gregory

“Old Fashioned” Software Methodologies

• What did developers do before OO?

• What do untrained / self taught developers tend to do?

• Data driven– Data structures developed initially

– Algorithms developed to work on the data

• Algorithm driven– Algorithms developed initially

– Data structures developed to fit the algorithms

• Both methods are prone to problems since something is ignored in the initial design

Kate Gregory

Object Oriented Methodology

• Centered on both data (attributes) and algorithms (methods)

• An object is constructed of both attributes and methods – neither is ignored during the design of a system.

• Attributes represent state within the object and the methods represent the “things that the object can do”.

• Example, Employee– Attributes include : name, salary, email address

– Methods include: issue paycheque for, send email to

Kate Gregory

Object Attributes• Represents state of the object

• External representation may be independent of the internal representation.– Possible representations of colour

• String – “Red”, “Yellow”

• Integer – 0 = black, 255 = white

• Several integers - (0,0,0)= (Red, Green, Blue)

• Object – Red, Yellow

Kate Gregory

Methods• Methods are the OO concept

– Various languages call them functions, procedures, and subroutines.

• Methods encapsulate the behaviour of the object, provide an interface to the object and hide the internal representation of the object’s attributes.– Use methods to access the attributes of an object

• Example : myCar.getColour() instead of myCar.Colour.• Why ?

– Some OO languages expose properties: look like accessible attributes, act like methods

• Best of both worlds

• Think about what might change, and encapsulate it

Kate Gregory

Object Communication – Messages

• Messages are requests by one piece of code for the object to do its thing– Different objects might run different code for the same

message

– This is actually key to object orientation

Kate Gregory

Messages - Example• Two objects – Graph, Text Document• Both objects expose a draw method as part of their

interface• Graph.Draw( ) and TextDoc.Draw( ) are both

legal calls– Sure, many languages don’t allow two functions with

the same name, but you can tell them apart and so can the compiler

• Each method does different things– drawing a graph is different than drawing a text

document

Kate Gregory

Methods• Sending a message implies calling a method

• The object is responsible for “figuring out” what to do when the message is received

• Contrast to a traditional function which would not imply any knowledge or capability not already known to those who call it

• The calling code trusts the object to handle the request appropriately

Kate Gregory

Key Vocabulary

– This section is meant to make you aware of the terms and provide a simple introduction. More detailed coverage will follow.

• Encapsulation

• Inheritance

• Virtual

• Polymorphism

• Aggregation

Kate Gregory

Encapsulation• Data Hiding

• Implemented in many OO languages with keywords such as public, private, protected – Public: exposed to the whole system.– Private: internal to the class, not visible to the

whole system– Protected: exposed only to subclasses (covered

later)

Kate Gregory

PrivateA ttributes

andm ethods

Public A ttributesand M ethods

System

Kate Gregory

Example of Encapsulation: Car engine

• Different cars have different engines and mechanisms (fuel injection, turbo, etc)

• Interface between driver and the car is common: gas pedal. Push for faster, don’t push for slower.

• All drivers can accelerate all cars. Details of the engine are encapsulated inside the hood, and the driver can ignore them.

Kate Gregory

Encapsulation

• Item to be used in an invoicing application– Description, price, weight

• How to access description?– newitem.description– newitem.GetDescription()

• Effect of design changes

Kate Gregory

Encapsulation

• Invoice holds customer reference, list of items purchased

• Should invoice print method:– get customer details and print them?– Ask customer to print details?

• What happens when customer design changes?

Kate Gregory

Aggregation

• Objects many contain references to other objects.

• Example, a Car object may contain:– 4 wheel objects

– 1 engine object

– 1+ seat objects

Car

Seat Engine Wheel

Kate Gregory

Hierarchy and InheritanceMotor Vehicle

-colour-price-model

+go()+stop()+turn left()+turn right()

Bus Truck Car

Kate Gregory

Inheritance

• From the general to the specific• Subclasses inherit all attributes and methods from

the super class• Subclasses often add methods and attributes to

refine or redefine functionality

Kate Gregory

Inheritance example - vehicles

• All vehicles have a Stop method – involves pressure on the brakes

• One specific kind of car has Anti-Lock Brakes– Stop method has different implementation

• Client code just asks for Stop

Kate Gregory

PolymorphismMotor Vehicle

+colour: ?+price: ?+model: ?

+go()+stop()+turn left()+turn right()

Bus Truck Car

Ford Mustang

+Stop()+go()

Toyota Corolla Pontiac Sunfire

Kate Gregory

Polymorphism

• Imagine an array of MotorVehicles• Want to do the same thing to all of them• Send them all a Stop message• Same message, different behaviours (Anti-

lock etc) from different vehicles• The correct version of the method will be

called even though the object is being referred to in more generic terms.

Kate Gregory

Polymorphism

• Must involve an inheritance hierarchy– All shapes can be drawn– All employees can be paid– All documents can be printed

• The details don’t matter to the calling code

Kate Gregory

OO Benefits for Developers

• Less to remember

• Less gotcha bugs

• Freedom to make changes

• Less time on routine and more time on interesting parts

• Programs tend to succeed

• Proof: developers won’t go back

Kate Gregory

OO Benefits for Users

• Programs are more robust the first time

• Programs get better, not patchy

• Modifications are quicker

• Applications are more likely to solve the business problem

Kate Gregory

Encapsulation Benefit

• Bank account: balance in pennies or dollars?

• Product: description as character array in object, or read from database when needed?

• Object consumers benefit because they don’t need to know

• Object providers benefit because they are free to change

Kate Gregory

Enforcing Rules

• Remember to:– open a file before you write to it– charge a service charge for all withdrawals– add all deposits to the transaction log– set the colour before you draw, and reset it

afterwards

Kate Gregory

OO Promotes Reuse

• Class libraries – with compilers– for sale by third parties– free on the net

• Classes from previous projects

• Inheritance - instant reuse

Kate Gregory

Reuse Benefits

• Less work for developer

• A reused class is a tested class

• Reuse boring stuff : linked lists, hash tables, database access...

• Use your time for unique parts of the problem

Software Development LifeCycle

• Requirements

• Analysis

• Design

• Implementation

• Testing and Acceptance

• Revisions and Enhancements

Kate Gregory

Analysis and Design Matter

• The foundation for your program

• Changing your mind is easy at this stage

• Get it as right as you can

• Record your decisions

• Expect about 25% of total time– Per phase or stage

• OO A&D slower than procedural– save that time during later stages

LifeCycle Models

• Waterfall– what managers believe

• Fountain– reality

• Recursion– only really possible with OO

• Agile– Compatible with OO

Kate Gregory

How to Save Time

• Prototyping– paper– disposable– evolutionary

• Component Based Programming

• Rapid Application Development

• Reuse: ideas, classes, code

Kate Gregory

The Course ProjectA client is about to open a campground and needs you to

develop a software system to support operations. In the future, the client plans to offer reservations and cancellations from the Internet. You are requested not to make design decisions that would hamper this expansion.

 The specific operations that the client wishes to track include

site reservations, site rentals, cancellations, charges for site rentals, cancellation fees, and reservation fees. This system will not handle payroll or other non-site-related aspects of the campground such as renting canoes or tents to campers, running a snack bar, or submitting taxes to the authorities. In addition the simple flat charge for a carful of people to use the day use area will not be handled by this system.

The Course Project

• Work in groups

• Work on the same problem all term

• Build up an analysis and the start of a design

• Critique a deliberately flawed solution

• 4 labs @ 5%, Critique @ 15%

Kate Gregory

Working in Groups

• Since 1999, students in groups have done MUCH better than students who work alone on these labs

• Students report learning a great deal from their groupmates throughout the term

• Choose wisely• Group size 3 or 4

– 2 or 5 with my permission

Kate Gregory

Requirements Difficulties

• Incomplete requirements– “it should be obvious” how to do

something, or that a feature is needed

• Fuzzy descriptions – fast response, intuitive interface

– ten transactions per second

• Unneeded featuresKate Gregory

Use cases help find requirements

• Capturing use cases is one of the first things to do in coming up with requirements.

• Every use case holds potential requirements.

• Asking the questions to write the use case reveals details of the business rules

Kate Gregory

What is a use case?

• What the users are doing with the system?

• Or, in the case of a new system, what users will be doing with the system?

Kate Gregory

Use cases provide comprehensive documentation of the system under study,

using the language of the customer.

Use Cases Capture Sequence

• Use cases describe scenarios to help everyone understand system requirements.

• A use case shows a course of events in order and carries a sense of time.

Kate Gregory

Checking into a hotel• Customer approaches front desk• Clerk greets customer• Customer provides name (and company name?)• Clerk retrieves reservation• Clerk requests credit card• Customer provides card• . . .

Kate Gregory

What if?

• No clerk is free when customer arrives?

• Clerk cannot find reservation?

• Reservation is wrong (# guests, dates, smoking/non-smoking)?

• Customer has no credit card?

• Authorization is declined?

• ...

Kate Gregory

Use Cases Have Names

• Customer Makes Reservation

• Clerk Finds Available Room

• Customer Checks In

• Customer Checks Out

• …

Kate Gregory

Use Case: Customer Checks In

• A: Customer approaches the desk and speaks to a clerk

• B: Clerk obtains customer’s name and finds existing reservation

• C: Customer confirms reservation is correct

• D: Customer provides credit card

• …

Kate Gregory

Diversions

• At A, if no clerk is free, customer waits until a clerk is available

• At B, if customer has no reservation, clerk performs Clerk Finds Available Room

• At C, if reservation on file is incorrect, clerk performs Clerk Finds Available Room with corrected values

• …

Kate Gregory

Use Case Key Concepts• Use case. Each use case is a flow of events

through the system.

• Actors. An actor is independent of the system and does not need to be modelled.

• Diversion. This refers to a variation from the expected flow of events.

Kate Gregory

Guidelines for Finding Use Cases

• For each actor, find the tasks and functions that the actor should be able to perform or that the system needs the actor to perform.

• Name the use cases. Use the pattern Actor Verb Something

• Describe the use cases briefly using terms with which the user is familiar.

• Start with the optimistic or expected approach then add diversions.

Kate Gregory

Familiar Vocabulary

• Use a vocabulary that your readers understand and are comfortable with.

• The main objective here is to communicate with readers, not impress them with buzz words.

• The longer your documents stay in business jargon, the longer your users are in the loop.

Kate Gregory

Use Associations• The use association occurs when you are

describing your use cases and notice that some of them have common subflows.

• The use association allows you to extract the common subflow and make it a use case of its own.

• Example: Clerk Finds Available Room is a use case of its own that is used in Customer Checks In as well.

Kate Gregory

Extends Associations• The extends association is used when you

have one use case that is similar to another use case but does a bit more or is more specialized– Similar to inheritance for classes

• Example: Customer Checks Out Early is a specialized version of Customer Checks Out.

Kate Gregory

Should you extend a use case?• 5 steps, all 5 are different (order, diversions, what is

actually done) for checking out early than for regular checking out– write a whole separate use case

• 11 steps, and one is slightly different eg you add $50 to the bill. – one use case, Customer Checks Out, with diversion that says “At

G (or whatever), if the customer is checking out early, clerk adds a $50 early checkout fee to the total”.

• 4 extra steps for an early checkout– write the regular checkout use case

– write the early checkout as an “extends” and just describe those extra steps in the Customer Checks Out Early use case.

Kate Gregory

Customer Checks out Early Extends Customer Checks Out• A. Clerk and Customer perform steps A-D of Customer

Checks Out.

• B. Somebody does thing 1.

• C. Somebody else does thing 2.

• …

• F. Clerk and Customer perform steps E-J of Customer Checks Out.

• Original diversions in Customer Checks Out are untouched.

• Diversions specific to this use case use these step names

Kate Gregory

Library

Borrow books

Reading booksNewspaper

Member

Supplier

Purchasing Supplies

Inter library loan

extends

uses

uses

Performing research

Return BooksCirculation Clerk

Checking Library Card

Use Case Diagram

What are use cases for?

• Getting requirements from user

• Understanding business rules

• Discovering objects, and their attributes and methods

• Will be test cases when implementation is complete

Kate Gregory

Not User Interface Design

• Business objects like Reservation or Inventory are typically in a business layer

• Objects in a user interface are often form or window with button and text box – designed by a framework author

• In this course we’re focusing on the business layer

• Use cases are also helpful in UI designKate Gregory

Lab Project

• The Campground

• Use each other as resources to establish business rules

• Pay close attention to what is not in the scope of the project

• Sticking with this project all term

Kate Gregory

Are you in a Group?

• Use the workshop hour (now) for a first group meeting

• It is ok to share the work– One person write up what all agreed on– Two people each write half– I expect you all to be familiar with all of it

• Meet in person, use email, IM, phone, whatever works for the group

Kate Gregory

Lab 1

• Due Sept 20 start of class– Hand in paper copy in class (preferred)– Email to kate@gregcons.com (only approach

for late assignments)

• 2 marks out of 10 deducted for each day late (based on timestamp of email)

• Title page• You must be in a group

Kate Gregory

Lab 1 FAQs

• What should we hand in? What layout and format should I use?– See format notes in

KatesClothiersUseCaseExample.doc

• Should we consider electric and ordinary campsites, walk-ins, cabins?

• Are there rules like “diversion must terminate use case” or “diversion must call another use case?”

Kate Gregory

Lab 1 FAQs

• How many use cases should I have?

• Should we consider very rare possibilities?

• How many diagrams should I have?

• Do I have to answer the diversions?

• Can one diversion jump to another?

• Do we include non-computer steps? Why?

Kate Gregory

For Next week

• Hand in Lab 1 before class starts• Lab 2 will be available• Read ahead: CRC cards and collaboration

diagrams

Kate Gregory