week 2 concepts normally in week 1 software development life cycle use cases lab project lab 1 kate...
Post on 17-Dec-2015
221 Views
Preview:
TRANSCRIPT
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
top related