1. CSC 213 – Large Scale Programming

2. Today’s Goal  Improve design skills to make usable designs  Noun extraction & UML class diagram reviewed  Connections to use for fields in diagrams detailed  Describe process to find classes’ public methods  Using textual analysis to start our search for methods  Learn to test designs & find potential errors  Discover reasons for iterative nature of this process  Indentify & fix common errors that occur in designs  Learn about using CRC cards to check design validity

3. Designing Programs  Designing programs just like making music  How do you get to Carnegie Hall?

4. Designing Programs  Designing programs just like making music  How do you get to Carnegie Hall?  How do you get to Carnegie Hall? (old joke)

5. Good News For The Term  Designing program ultimately like any other skill  Get many opportunities at this over term  Why is this important? Why should you care?

6. Good News For The Term  Designing program ultimately like any other skill  Get many opportunities at this over term  Why is this important? Why should you care?

7. First Step In Design: Classes  Find (& underline) nouns in requirements  Go through & eliminate any external to solution entity classes  Select entity classes (main classes in program)  Look at remaining nouns that not abstract & singular boundary classes  Find boundary classes (I/O & recording states)  From options, use singular form of abstract nouns  Adjectives describing entity classes could work, too control classes  Determine control classes (structs. & algorithms)  Needed for any plurals lacking specific number  Important algorithms that do not have a name

8. Next Step: Fields  Look for possessives during reading of text  Should also look for text suggesting data possession  Consider boundary classes; often used for fields  May rely on common understandings: use your brain  Can now publicize design for entire team to use  You’ve done your part: let suckers do the hard work  Use UML class diagrams to avoid writing lots of words

9. UML Class Diagrams

10. Optional Relationships  Aggregation  Used when target instances used outside of source aggregates  Car aggregates CarParts (e.g., tires, engine, lights…)  Composition  Use when objects from target used only within source composes  Chessboard composes Squares  Association  Source object has field of target type  Often used to imply source calls target's methods

11.  Generalization (“inheritance”)  Shows subclass-superclass relationship  Does not involve fields, multiplicities, or anything else  Makes this a different type of connection than others  Must draw all generalizations within the diagram  For implementation to be correct, these are critical  Cannot specify any other way, so vital to be shown Required Connection

12. Elevator's UML Class Diagram

13. Actions Are Verbs  Now need to find methods for all of our classes  At this point in time, many not know all methods  Important public methods described in text, however  To find methods, look for verbs in requirements  Circle each verb since it is a possible method  Since often not helpful, check all “to be” & “has” uses  Circle algorithm names and longer action descriptions  Looking through text, only public methods found  Find more methods later when looking at algorithms

14. Looking for verbs 1. Circle all the verbs in the text Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

15. Looking for verbs 1. Circle all the verbs in the text Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

16. Looking for verbs 2. Double-check all uses of “to be” and “has” Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

17. Looking for verbs 2. Double-check all uses of “to be” and “has” Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

18. Looking for verbs 3. Circle algorithm names & action descriptions Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

19. Looking for verbs 3. Circle algorithm names & action descriptions Buttons in elevators and on the floors control the movement of n elevators in a building with m floors. Buttons illuminate when pressed to request the elevator stop at a specific floor; the illumination is canceled when the request has been satisfied. When an elevator has no requests, it remains at its current floor with its doors closed.

20. Which Class Gets the Method?  Look for SRP violations for path to true laziness

21. Which Class Gets the Method?  Look for SRP violations for path to true laziness

22. Single Responsibility Principle  Goal of every class & method written  Make sure that class represents single concept  Methods perform single action & not “bucket of mud” SRP  Many benefits accrue when code follows SRP  Easier to write code, since design becomes simpler  More focused results make debugging a snap  Modifying design quicker when changes needed

23. No Free Cheeseburgers

24. CRC Cards Explained  Divide 3x5 Card into 3 parts  Class name from UML design document  Responsibilities are the methods class will need  Collaborations are classes it will interact with

25. Responsibilities  Initially you should start with actions you found  Add facts class knows, since these are getter methods  If class should not be responsible, move action  Instead, the action placed in class where makes sense  Make classes collaborators after action moved  Pays off in long run, but may make new classes now

26. Responsibilities  Initially you should start with actions you found  Add facts class knows, since these are getter methods  If class should not be responsible, move action  Instead, the action placed in class where makes sense  Make classes collaborators after action moved  Pays off in long run, but may make new classes now How to know if responsibility logical?

27. Seriously!

28. If the Responsibility Fits  Try each responsibility into following statement  Will find statement is valid only if responsibility fits The (class name) (responsibility) itself  Move actions to class that works in statement The (new class) (responsibility) (old class)

29. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

30. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

31. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

32. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

33. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

34. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

35. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

36. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

37. Let’s Try It For Car  Which of these responsibilities belong to car Starts engine Kills engine Changes tires Gets driven Gets washed Changes oil Warns oil is low Reports on fuel level

38. So Remember

40. For Next Lecture  Reading for Wednesday available on Angel  How can we solve bugs BEFORE we code?  Can we prevent getting trapped and lost?  Prevent your name from becoming swear word!  Weekly assignment problem due in class Wed.  Can be found on Angel as problem #3 for Week #1