CSCI 2300: Object-Oriented Software Design

The Object-Oriented Modeling (part 2)

Chapter Topics

• Identifying Classes
• Identifying Responsibilities
• Relationships Between Classes
  
• Use Cases
  
• CRC Cards
• UML Class Diagrams
• Sequence Diagrams
• State Diagrams
  
• Using javadoc for Design Documentation
  
• Case Study: A Voice Mail System

Object and Class Concepts

• Object: Three characteristic concepts
  • Entity
  • Boundary
  • Control
• Class: Collection of similar objects

Identifying Classes

• Player
• Board
• Game piece
• Menu
• Score board

Identifying Classes

• Board stores the current positions of game pieces
• Board shows the current state of the game
• Board is used by both players to make their moves
• Don't worry yet how the Board is implemented
  

Categories of Classes

• Tangible Things
• Agents
• Events and Transactions
• Users and Roles
• Systems
• System interfaces and devices
• Foundational Classes

Identifying Responsibilities

• Stores
• Shows
• Tests if a given position is empty

Responsibilities

• OO Principle: Every operation is the responsibility of a single class
• Example: Add game piece to the board
• Who is responsible: Board or Player?

Class Relationships

• ("uses")
• Aggregation ("has")
• Inheritance ("is")

Relationship

• C  depends on D: Method of C manipulates objects of D
• Example: Player depends on Board
• If C doesn't use D, then C can be developed without knowing about D

Coupling

• Minimize dependency: reduce coupling
• Example: Replace
  

  void print() // prints to System.out
  

  with
  

  String getText() // can print anywhere
  

• Removes dependence on System, PrintStream

CRC Cards

• CRC = Classes, Responsibilities, Collaborators
  
• Developed by Beck and Cunningham
• Use an index card for each class
• Class name on top of card
• Responsibilities on left
• Collaborators on right

CRC Cards

• Responsibilities should be high level
• 1 - 3 responsibilities per card
• Collaborators are for the class, not for each responsibility

CRC Cards

Use Cases

• Analysis technique
• Each use case focuses on a specific scenario
• Use case = sequence of actions
• Action = interaction between actor and computer system
  
• Each action yields a result
• Each result has a value to one of the actors

Sample Use Case

Take your turn

1. A player selects a board position for that player's game piece
2. Board checks if selected position is available
   • If not available, start over
3. Board updates its game pieces

1. Board presents a list of available board positions
2. A player selects a board position (from the list of available) for that player's game piece
3. Board updates its game pieces OR Player updates the board

Use Cases

Design these use cases in class

• Play one round of the game
• Determine the winner

From Use Cases to CRC Cards

UML Diagrams

• UML = Unified Modeling Language
• Many diagram types
• We'll use three types:
  • Class Diagrams
  • Sequence Diagrams
  • State Diagrams

Class Diagrams

• Rectangle with class name
• Optional compartments
  • Attributes
  • Methods
• Include only key attributes and methods

Class Diagrams

Class Relationships

Composition

• Special form of aggregation
• Contained objects don't exist outside container
• Example: Game has two players

Association

• More general association relationship
• Association can have roles

• Some associations are bidirectional
  Can navigate from either class to the other
• Example: Course has set of students, student has set of courses
  
• Some associations are directed
  Navigation is unidirectional
• Example: BoardPosition doesn't know about Board containing it
  

Interface Types

• Interface type describes a set of methods
• No implementation, no state
• Class implements interface if it implements its methods
  
• In UML, use stereotype «interface»

Tips

• Use UML to inform, not to impress
  
• Don't draw a single monster diagram
• Each diagram must have a specific purpose
• Omit inessential details