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

2. DateWeekTopicHand OutDue BackTest 6-Sep-131Administrivia / Overview / Motivation, benefits of OO 13-Sep-132Use CasesLab 1: Use cases 20-Sep-133CRC Cards, collab graphsLab 2: CRC cardslab 1 5% 27-Sep-13 4start class diaglab 2 5% 4-Oct-135Finish class diag, AssociationsLab 3: Class Diag 11-Oct-136Inh & Polymorphism / midterm reviewlab 3 5% 18-Oct-137midtermMidterm 25% 25-Oct-13Reading Break 1-Nov-138Interaction diag / Design PatternsLab 4: Interaction Diag 8-Nov-139Good Design / Modules & Packages / Deployment and component diagrams /Metrics / SOLID Lab 5: Critiqueslab 4 5% 15-Nov-1310State diagrams / Activity diagrams / Summary and Conclusion / The Future 22-Nov-1311Critiquescritique lab (before class) 15% 29-Nov-1312Critiques TBDFinal ExamFinal 40%

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

20. Kate Gregory Polymorphism

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

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

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

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

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

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

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

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

29. Concept Reviews What is an object –a clump of related information –also related behaviour Encapsulation Polymorphism Reuse Kate Gregory

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

54. Kate Gregory Use Case Diagram

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

56. 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 design Kate Gregory

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

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

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

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

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

62. For Next week Hand in Lab 1 before class starts Lab 2 will be available Read ahead: CRC cards and collaboration diagrams Kate Gregory