Design and UML Class Diagrams
1
Big questions
◼ What is UML?
◼ Why should I bother? Do people really use UML?
◼ What is a UML class diagram?
◼ What kind of information goes into it?
◼ How do I create it?
◼ When should I create it?
2
Design phase
◼ design: specifying the structure of how a
software system will be written and function,
without actually writing the complete
implementation
◼ a transition from "what" the system must do, to
"how" the system will do it
◼ What classes will we need to implement a system
that meets our requirements?
◼ What fields and methods will each class have?
◼ How will the classes interact with each other?
3
How do we design classes?
◼ class identification from project spec / requirements
◼ nouns are potential classes, objects, fields
◼ verbs are potential methods or responsibilities of a class
◼ CRC card exercises
◼ write down classes' names on index cards
◼ next to each class, list the following:
◼ responsibilities: problems to be solved; short verb phrases
◼ collaborators: other classes that are sent messages by this class
(asymmetric)
◼ UML diagrams
◼ class diagrams (today)
◼ sequence diagrams
◼ ...
4
Introduction to UML
◼ UML: pictures of an OO system
◼ programming languages are not abstract enough for OO design
◼ UML is an open standard; lots of companies use it
◼ What is legal UML?
◼ a descriptive language: rigid formal syntax (like programming)
◼ a prescriptive language: shaped by usage and convention
◼ it's okay to omit things from UML diagrams if they aren't
needed by team/supervisor/instructor
5
Uses for UML
◼ as a sketch: to communicate aspects of system
◼ forward design: doing UML before coding
◼ backward design: doing UML after coding as documentation
◼ often done on whiteboard or paper
◼ used to get rough selective ideas
◼ as a blueprint: a complete design to be implemented
◼ sometimes done with CASE (Computer-Aided Software
Engineering) tools
◼ as a programming language: with the right tools, code
can be auto-generated and executed from UML
◼ only good if this is faster than coding in a "real" language
6
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
7
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
8
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
9
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
10
Comments
◼ represented as a folded note, attached to the
appropriate class/method/etc by a dashed line
11
Relationships btwn. classes
◼ generalization: an inheritance relationship
◼ inheritance between classes
◼ interface implementation
◼ association: a usage relationship
◼ dependency
◼ aggregation
◼ composition
12
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
13
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)
14
Multiplicity of associations
◼ one-to-one
◼ each student must carry exactly one ID card
◼ one-to-many
◼ one rectangle list can contain many rectangles
15
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
16
Class diagram example 1
17
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
18
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
19
