CSC 213 – Large Scale Programming

1. CSC 213 –Large Scale Programming Lecture 3: Object-Oriented Analysis

2. Today’s Goal • Discuss how to refine proposed designs • Illustrate a design using a language called UML • Converting between UML and Java • Test to see if the design works and makes sense • Debugging methods when a design does not work

3. 3 “Types” of Classes • Unified Process concept to simplify designs • Entity classes hold the long-lived data • Boundary classes defined for input & output • Control classes do complex processing in the program • “Types” exist only for purposes of design • Within Java, a class is a class is a class • Noun extraction simplest way to find classes • Select from nouns in requirements document

4. Designing Elevator Controller 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.

5. Testing A Design • How to know if design is logical & will work • Illustrate using Unified Markup Language (UML) • UML does not do any checking • Provides “language” to investigate design and draw conclusions • Once design is put into UML, can ask • Does this make sense? • Can I make it simpler? • Is a class clearly responsible for each action?

6. UML Class Diagrams • Each class is drawn as a 3-part box • Class name written in top portion of box • Fields written in middle portion of box • (public) Methods written in bottom portion of box

7. Relationship Between Classes • Also draw relationships between classes • Relationships are lines connecting classes • Mark at end of line denotes “type” of relationship • Lines labeled with multiplicity -- number of objects involved in relationship • Examples of relationships • Aggregation & Composition • Generalization (“inheritance”) • Association

8. UML Class Diagram for Elevator Controller • Button objects currently serves two purposes • Buttons in elevator directing travel to a floor • Buttons on a floor requesting travel • Solution: Make 2 specializations of Button

9. UML Class Diagram for Elevator Controller • Floor Buttons talk to all n Elevators? • Need another class to handle this

10. UML Class Diagram for Elevator Controller • All communication now 1-to-many • Can also see where requests might fit

11. UML Class Diagram for Elevator Controller

12. Class Diagram Notes • Advanced multiplicity relationships possible • * used when relationship requires 0 or more • + used when relationship requires 1 or more • “1..4” when may have 1 to 4 instances of object • Move functionality to superclass whenever possible • No reason to code something more than once

13. Class Diagram Notes • Iterative process that should not be rushed • Remember, good designs yields easy coding • Do not need worry about implementation yet • Ignore details that do not involve multiple classes • Should define all fields & public methods • Must explain changes needed in implementation • This will happen, so do not sweat it

14. Daily Activity Illustrate and refine design for tic-tac-toe controller: Game is played on a board. The board is a 3-by-3 grid of squares. Game has 2 players alternately making a move. For a move, a player selects a square. If the selected square is not empty, the player loses. Otherwise, the square is marked for the player. A player wins if they mark a line of 3 squares. If the entire board is marked without a player winning, the game is a tie.

15. For Next Lecture • Will start discussing methods of testing code • What preconditions and postconditions are • How to thoroughly document methods • Ways to use documentation to develop test cases • Tools to automatically test your code