CSE 403

Design and UML Class Diagrams

Reading:
UML Distilled Ch. 3, by M. Fowler

1
 UML class diagrams
 What is a UML class diagram?
 UML class diagram: a picture of the classes in an
OO system, their fields and methods, and
connections between the classes that interact or
inherit from each other

 What are some things that are not represented in a

UML class diagram?
 details of how the classes interact with each other
 algorithmic details; how a particular behavior is
implemented

2
 Diagram of one class
 class name in top of box
 write <<interface>> on top of interfaces' names
 use italics for an abstract class name

 attributes (optional)
 should include all fields of the object

 operations / methods (optional)

 may omit trivial (get/set) methods
 but don't omit any methods from an interface!
 should not include inherited methods

3
 Class attributes
 attributes (fields, instance variables)
 visibility name : type [count] = default_value

 visibility: + public
# protected
- private
~ package (default)
/ derived
 underline static attributes

 derived attribute: not stored, but can

be computed from other attribute values

 attribute example:
- balance : double = 0.00

4
 Class operations / methods
 operations / methods
 visibility name (parameters) : return_type

 visibility: + public
# protected
- private
~ package (default)
 underline static methods
 parameter types listed as (name: type)
 omit return_type on constructors and
when return type is void

 method example:
+ distance(p1: Point, p2: Point): double

5
 Comments
 represented as a folded note, attached to the
appropriate class/method/etc by a dashed line

6
 Relationships btwn. classes
 generalization: an inheritance relationship
 inheritance between classes
 interface implementation

 association: a usage relationship

 dependency
 aggregation
 composition

7
 Generalization relationships
 generalization (inheritance) relationships
 hierarchies drawn top-down with arrows
pointing upward to parent
 line/arrow styles differ, based on whether
parent is a(n):
 class:

solid line, black arrow

 abstract class:

solid line, white arrow

 interface:

dashed line, white arrow

 we often don't draw trivial / obvious

generalization relationships, such as
drawing the Object class as a parent

8
 Associational relationships
 associational (usage) relationships
1. multiplicity (how many are used)
 *  0, 1, or more
 1  1 exactly
 2..4  between 2 and 4, inclusive
 3..*  3 or more
2. name (what relationship the objects have)
3. navigability (direction)

9
 Multiplicity of associations
 one-to-one
 each student must carry exactly one ID card

 one-to-many
 one rectangle list can contain many rectangles

10
 Car

Association types
1
aggregation
 aggregation: "is part of" 1
Engine
 symbolized by a clear white diamond

 composition: "is entirely made of" Book

 stronger version of aggregation composition
 the parts live and die with the whole
1
 symbolized by a black diamond
*
Page
 dependency: "uses temporarily"
 symbolized by dotted line
 often is an implementation
detail, not an intrinsic part of dependency
that object's state
Lottery Random
Ticket
11
Class diagram example 1

12
 Class diagram example 2
Multiplicity

Customer Simple
1
Class Aggregation

Abstract Rental Invoice

Class

Rental Item 1..*

1 0..1

Composition Simple
Generalization
Association

Checkout Screen
DVD Movie VHS Movie Video Game

13
 Class diagram example 3

StudentBody Student
1 100
- firstName : String
+ main (args : String[]) - lastName : String
- homeAddress : Address
- schoolAddress : Address

+ toString() : String
Address
- streetAddress : String
- city : String
- state : String
- zipCode : long

+ toString() : String

14
 Tools for creating UML diags.
 Violet (free)
 http://horstmann.com/violet/

 Rational Rose
 http://www.rational.com/

 Visual Paradigm UML Suite (trial)

 http://www.visual-paradigm.com/
 (nearly) direct download link:
http://www.visual-paradigm.com/vp/download.jsp?product=vpuml&edition=ce

(there are many others, but most are commercial)

15
 Class design exercise
 Consider this Texas Hold 'em poker game system:
 2 to 8 human or computer players
 Each player has a name and stack of chips
 Computer players have a difficulty setting: easy, medium, hard
 Summary of each hand:
 Dealer collects ante from appropriate players, shuffles the deck,
and deals each player a hand of 2 cards from the deck.
 A betting round occurs, followed by dealing 3 shared cards from
the deck.
 As shared cards are dealt, more betting rounds occur, where each
player can fold, check, or raise.
 At the end of a round, if more than one player is remaining,
players' hands are compared, and the best hand wins the pot of all
chips bet so far.
 What classes are in this system? What are their
responsibilities? Which classes collaborate?
 Draw a class diagram for this system. Include relationships
between classes (generalization and associational). 16
Classes:
Player: Represents a player in the game, human or computer.

 Responsibilities:
 Holds a name and chip stack.
 Receives and holds two hole cards.
 Makes betting decisions (fold, check, raise).
 Shows hand if remaining at the end.
Dealer: Manages the game flow.


 Responsibilities:
 Collects antes.
 Shuffles and deals cards.
 Executes betting rounds.
 Compares hands and awards pot.
 Maintains game state information.
Deck: Represents the deck of cards.


 Responsibilities:
 Holds all cards initially.
 Provides cards to Dealer on request.

17
 To develop an Online Bookstore System, we need a clear plan for how
things will work. First, users should be able to register and log in securely.
Once logged in, they can browse books by genre, author, or title.
Customers can add books to their shopping cart and then proceed to
checkout, where they provide shipping and payment details.
 On the management side, administrators oversee user accounts and roles,
while managers handle inventory and sales reports. Books in the system
need to have details like title, author, price, and quantity in stock.
 Orders must be processed smoothly, updating inventory levels as
purchases are made. Low stock alerts should prompt managers to restock
items. Additionally, customers can rate and review books, which
administrators can moderate.
 To represent these functionalities, we can design classes like User, Book,
ShoppingCart, Order, Inventory, and Review. Managers will handle
processes like inventory management and order processing.
Administrators will manage user accounts and reviews. These classes will
interact to create a seamless online bookstore experience.

18
 Hand: Represents a player's hand of cards.
 Responsibilities:
 Holds two hole cards and references to shared cards.
 Evaluates its own poker hand rank.
 Bet: Represents a bet made by a player.
 Responsibilities:
 Holds the amount and player associated with the bet.
 DifficultyLevel: (Optional) Represents the difficulty setting for computer
players.
 Responsibilities:
 Determines the strategy and decision-making logic for computer players.

19
 Collaborations:
 Player interacts with Dealer by receiving cards, making decisions, and
showing their hand.
 Dealer interacts with Deck to draw cards.
 Dealer interacts with all Players during betting rounds.
 Player interacts with Hand to access their cards and evaluate their hand
rank.
 Dealer interacts with Hand to compare hands and determine the winner.
 (Optional) Player interacts with DifficultyLevel (if difficulty is set).
 Generalization:
 ComputerPlayer is a specialization of Player, with additional logic for
decision-making based on DifficultyLevel.
 Associational Relationships:
 Player has many Bet objects.
 Hand references one Dealer and multiple Card objects.
 Dealer references one Deck and multiple Player objects.
20