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

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

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

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?

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

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

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

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

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

UML Class Diagram for Elevator Controller

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

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

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.

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