Week 2

1. Week 2 • Concepts normally in week 1 • Software Development Life Cycle • Use Cases • Lab project • Lab 1 Kate Gregory

3. “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

4. 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

5. 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

6. 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

7. 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

8. 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

9. 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

10. 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

11. 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

12. Kate Gregory

13. 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

14. 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

15. 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

16. Aggregation • Objects many contain references to other objects. • Example, a Car object may contain: • 4 wheel objects • 1 engine object • 1+ seat objects Kate Gregory

17. Motor Vehicle -colour -price -model +go() +stop() +turn left() +turn right() Bus Truck Car Hierarchy and Inheritance Kate Gregory

18. 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

19. 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

20. Polymorphism Kate Gregory

21. 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

22. 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

23. 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

24. 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

25. 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

26. 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

27. 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

28. 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 Kate Gregory

29. Software Development LifeCycle • Requirements • Analysis • Design • Implementation • Testing and Acceptance • Revisions and Enhancements Kate Gregory

30. 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

31. LifeCycle Models • Waterfall • what managers believe • Fountain • reality • Recursion • only really possible with OO • Agile • Compatible with OO Kate Gregory

32. How to Save Time • Prototyping • paper • disposable • evolutionary • Component Based Programming • Rapid Application Development • Reuse: ideas, classes, code Kate Gregory

33. The Course Project A 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.

34. 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

35. 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

36. 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 features Kate Gregory

37. 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

38. 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? Use cases provide comprehensive documentation of the system under study, using the language of the customer. Kate Gregory

39. 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

40. 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

41. 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

42. Use Cases Have Names • Customer Makes Reservation • Clerk Finds Available Room • Customer Checks In • Customer Checks Out • … Kate Gregory

43. 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

44. 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

45. Use Case Key Concepts • Use case. Each use caseis 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

46. 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

47. 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

48. 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 Roomis a use case of its own that is used in Customer Checks In as well. Kate Gregory

49. 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

50. 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