Scribd
Upload
6 views20 pages

Lesson 6 - Class

The document provides an overview of UML (Unified Modeling Language) class diagrams, detailing their purpose, structure, and the process of creating them. It discusses the design phase of software development, the identification of classes, and the relationships between them, including generalization and association. Additionally, it highlights tools for creating UML diagrams and emphasizes the importance of UML in both forward and backward design approaches.

Uploaded by

dreamy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
6 views20 pages

Lesson 6 - Class

The document provides an overview of UML (Unified Modeling Language) class diagrams, detailing their purpose, structure, and the process of creating them. It discusses the design phase of software development, the identification of classes, and the relationships between them, including generalization and association. Additionally, it highlights tools for creating UML diagrams and emphasizes the importance of UML in both forward and backward design approaches.

Uploaded by

dreamy
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 20

UML Class Diagrams

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?
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?
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
...
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
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
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
 details of how the classes interact with each other

 algorithmic details; how a particular behavior is


implemented
What are some things that are not represented in a UML class
diagram?
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
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
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
Comments
represented as a folded note, attached to the appropriate
class/method/etc by a dashed line
Relationships btwn. classes
generalization: an inheritance relationship
inheritance between classes
interface implementation

association: a usage relationship


dependency
aggregation
composition
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
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)
Multiplicity of associations
 one-to-one
 each student must carry exactly one ID card

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

1
Association types 1
aggregation

aggregation: "is part of" Engine

symbolized by a clear white diamond

Book
composition: "is entirely made of" composition
stronger version of aggregation 1
the parts live and die with the whole *
symbolized by a black diamond
Page

dependency: "uses temporarily"


symbolized by dotted line dependency
often is an implementation
detail, not an intrinsic part of Lottery
that object's state Random
Ticket
Class diagram example 1
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
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
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)

You might also like