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

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