learn

UML class diagrams

What is a UML class diagram?

• A UML class diagram is a picture of

• the classes in an OO system
• their fields and methods
• connections between the classes that interact or
inherit from each other
• Not represented in a UML class diagram:
• details of how the classes interact with each other
• algorithmic details; how a particular behavior is
implemented

13
Diagram of a single class

Rectangle

• Class name - width: int

- height: int
• write «interface» on top of interfaces' names / area: double
• use italics for an abstract class name
+ Rectangle(w: int, h: int)
• Attributes (optional) + distance(r: Rectangle): double
• fields of the class
• Operations / methods (optional) Student
• may omit trivial (get/set) methods - name: String
• but don't omit any methods from an interface! - id: int
• should not include inherited methods - totalStudents: int

# getID(): int
~ getEmail(): String

14
Class attributes (fields, instance variables)

visibility name : type [count] = default_value Rectangle

- width: int
- height: int
• visibility / area: double
+ public
+ Rectangle(w: int, h: int)
# protected + distance(r: Rectangle): double
- private
~ package (default)
Student
/ derived
- name: String
• derived attribute: not stored, but can - id: int
be computed from other attribute values - totalStudents: int
• “specification fields” from CSE 331 # getID(): int
• underline static attributes ~ getEmail(): String

15
Class operations / methods

visibility name(parameters) : return_type Rectangle

- width: int
- height: int
• visibility / area: double
+ public
+ Rectangle(w: int, h: int)
# protected + distance(r: Rectangle): double
- private
~ package (default)
Student
• parameters listed as name : type - name: String
• underline static methods - id: int
- totalStudents: int
• omit return_type on constructors and
when return type is void # getID(): int
~ getEmail(): String

16
Comments

Represented as a folded note, attached to the

appropriate class/method/etc by a dashed line

Cloneable is a tagging
interface with no
«interface»
Cloneable
methods. The clone()
methods is defined in
the Object class.

17
Relationships between classes

• Generalization: an inheritance relationship

• inheritance between classes
• interface implementation
• Association: a usage relationship
• dependency
• aggregation
• composition

18
Generalization relationships «interface»
Shape
+ getArea(): double

• Hierarchies drawn top-down

RectangularShape
• Arrows point upward to parent
- width: int
• Line/arrow styles indicate if parent is a(n): - height: int
• class: solid line, black arrow / area: double
• abstract class: solid line, white arrow + contains(x: int, y: int): boolean
• interface: dashed line, white arrow + getArea(): double

• Often omit trivial / obvious generalization

relationships, such as drawing the Object class
Rectangle
as a parent
- x: int
- y: int

+ Rectangle(x: int, y: int)

+ distance(r: Rectangle): double

19
Associational (usage) relationships

Class A Class B
1..* k
contains

20
Associational (usage) relationships

1. Multiplicity (how many are used)

• * (zero or more) 1 1
• 1 (exactly one) Class A Class B
• 2..4 (between 2 and 4, inclusive) 1..* k
• 3..* (3 or more, * may be omitted) contains

20
Associational (usage) relationships

1. Multiplicity (how many are used)

• * (zero or more) 1 1
• 1 (exactly one) Class A Class B
• 2..4 (between 2 and 4, inclusive) 1..* k
• 3..* (3 or more, * may be omitted) contains
2. Name (what relationship the objects have)
2

20
Associational (usage) relationships

1. Multiplicity (how many are used)

• * (zero or more) 1 1
• 1 (exactly one) Class A Class B
• 2..4 (between 2 and 4, inclusive) 1..* k
• 3..* (3 or more, * may be omitted) contains
2. Name (what relationship the objects have)
3 2
3. Navigability (direction)

20
Association multiplicities

• One-to-one Car
1 1
Engine
• Each car has exactly one engine.
• Each engine belongs to exactly one car.
• One-to-many Book Page
1 *
• Each book has many pages.
• Each page belongs to exactly one book.

21
Association types

Car Engine
1 1

22
Association types

• Aggregation: “is part of” Car

1 1
Engine
• symbolized by a clear white diamond

22
Association types

• Aggregation: “is part of” Car

1 1
Engine
• symbolized by a clear white diamond
• Composition: “is entirely made of”
• stronger version of aggregation Book Page
1 *
• the parts live and die with the whole
• symbolized by a black diamond

22
Association types

• Aggregation: “is part of” Car

1 1
Engine
• symbolized by a clear white diamond
• Composition: “is entirely made of”
• stronger version of aggregation Book Page
1 *
• the parts live and die with the whole
• symbolized by a black diamond
• Dependency: “uses temporarily”
• symbolized by dotted line Lottery RNG

• often is an implementation detail, not

an intrinsic part of the object's state

22
Aggregation / composition example

• If the cinema goes away

• so does the box office: composition
• but movies may still exist: aggregation

Cinema BoxOffice
1 1

*
Movie

23
Class diagram example: video store

Multiplicity
Customer 1
Class
Aggregation

Rental Invoice
Abstract class
Rental Item 1..*
1 0..1
Generalization Composition
Association

Checkout Screen
DVD VHS Game

24
Class diagram example: people

Let’s add visibility

attributes.

25
Class diagram example: student

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

26
Tools for creating UML diagrams

• Violet (free)
• http://horstmann.com/violet/
• Rational Rose
• http://www.rational.com/
• Visual Paradigm UML Suite (trial)
• http://www.visual-paradigm.com/
• There are many others, but most are commercial

27
What (not) to use class diagrams for

28
What (not) to use class diagrams for

• Class diagrams are great for:

• discovering related data and attributes
• getting a quick picture of the important entities in a system
• seeing whether you have too few/many classes
• seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
• spotting dependencies between one class/object and another

28
What (not) to use class diagrams for

• Class diagrams are great for:

• discovering related data and attributes
• getting a quick picture of the important entities in a system
• seeing whether you have too few/many classes
• seeing whether the relationships between objects are too
complex, too many in number, simple enough, etc.
• spotting dependencies between one class/object and another
• Not so great for:
• discovering algorithmic (not data-driven) behavior
• finding the flow of steps for objects to solve a given problem
• understanding the app's overall control flow (event-driven?
web-based? sequential? etc.)

28
Summary

• A design specifies the structure of

how a software system will be written
and function.
• UML is a language for describing
various aspects of software designs.
• UML class diagrams present a static
view of the system, displaying classes
and relationships between them.

29