Scribd
Upload
27 views

UML Class Diagrams

The document discusses UML class diagrams and their use in software design. It covers: 1) The purpose of class diagrams is to specify the structure of a software system by showing classes, fields, methods, and relationships between classes. 2) Class diagrams show classes, attributes, operations, and relationships like generalization, association, aggregation and composition. 3) UML class diagrams are useful for discovering system entities, relationships between objects, and spotting dependencies, but not for understanding algorithmic behavior or overall control flow.

Uploaded by

naomikoyana099
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
27 views

UML Class Diagrams

The document discusses UML class diagrams and their use in software design. It covers: 1) The purpose of class diagrams is to specify the structure of a software system by showing classes, fields, methods, and relationships between classes. 2) Class diagrams show classes, attributes, operations, and relationships like generalization, association, aggregation and composition. 3) UML class diagrams are useful for discovering system entities, relationships between objects, and spotting dependencies, but not for understanding algorithmic behavior or overall control flow.

Uploaded by

naomikoyana099
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/ 22

Design and UML Class Diagrams

Suggested reading:
Practical UML: A hands on introduction for developers
http://dn.codegear.com/article/31863
UML Distilled Ch. 3, by M. Fowler
1
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
– ...
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 – Unified Modeling Language
• Union of all Modeling Languages
– Use case diagrams
– Class diagrams
– Object diagrams
– Sequence diagrams
– Collaboration diagrams
– Statechart diagrams
– Activity diagrams
– Component diagrams
– Deployment diagrams
– ;.
• Very big, but a nice standard that has been
embraced by the industry.
UML class diagrams
• UML class diagram: 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
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 (= fields)
• 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
• “specification fields “ from CSE 331

– 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 between classes
• generalization: an inheritance relationship
– inheritance between classes
– interface implementation

• association: a usage relationship


– dependency
– aggregation
– composition
Generalization (inheritance) relationships
• hierarchies drawn top-down
• arrows point upward to parent
• line/arrow styles indicate whether parent is
a(n):
– class:
solid line, black arrow
– abstract class:
solid line, white arrow
– interface:
dashed line, white arrow

• often omit 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 (also written as “3..”)

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

Association types 1
aggregation
• aggregation: “is part of” 1
Engine
– symbolized by a clear white diamond

• composition: “is entirely made of” Book

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 Random
that object's state Ticket
Composition/aggregation example

If the movie theater goes away


so does the box office => composition
but movies may still exist => aggregation
Class diagram example
No arrows; info can
flow in both directions

Aggregation – Order class


contains OrderDetail
classes. Could be
composition?
UML example: people

Now add the visibility attributes


Class diagram example: video store
Multiplicity

Customer
1 Simple
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: student

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

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

+ toString() : String
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/
– (nearly) direct download link:
http://www.visual-paradigm.com/vp/download.jsp?product=vpuml&edition=ce

(there are many others, but most are commercial)


Class diagram pros/cons
• 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.)

You might also like