The Unified Modeling Language
(UML)
Class Diagrams
Unified Modeling Language
• A standardized modeling language for the
conceptualization and design of software
systems
• Two types of diagrams: structure diagram and
behavior diagram
• There are a lot of diagram types in the UML
(14 types!) but we will focus only on a few in
this class
Common Structure Diagrams
• Class Diagram
– Illustrates classes, with attributes and methods, along with their
relationships
– We will focus primarily on class diagrams, since they are by far
the most commonly used
• Component Diagram
– Illustrates how components (each with an API or similar
connecting interface) interfaces with other components
• Object Diagram
– Illustrates the objects instantiated in a system at a single point in
time
• Package Diagram
– Illustrates the packages in a system and their dependencies
Common Behavior Diagrams
• Activity Diagram
– A “flow chart” of sorts
• Interaction Diagram
– The message sequence chart is one type of
interaction diagram
• Use Case Diagram
– Represents dependencies among use cases
• State Machine Diagram
– Displays states and transitions
UML Diagrams are related
• Each diagram is a different view of a system
Twisted
Internet
Protocol
Reactor
<<import>>
These classes belong to those packages.
<<import>>
Echo Example
A Class
Class/Object Name
Attributes
Methods/Operations
• A class name should be descriptive (Italic if abstract)
• The attributes of a class defines its properties, what
data the class stores
• The methods/operations of a class specify what the
class does
Visibility of Attributes and
Methods
Associations
Specific Associations: Aggregate
• Aggregations – “has a” relationships
– A class is a container of other classes
– Does not imply ownership, (ie. when the “parent”
gets destroyed, the aggregates do not)
– Ex: A magazine has articles, but if the magazine
goes out of business, the articles don’t necessarily
disappear (they may live on as part of another
publication)
Specific Associations: Composite
• Composition – combining simple objects into
a more complex whole
– Can have multiple objects composed into one
– Implies an “owns a” relationship
– If the parent is destroyed, all its composites are
typically destroyed
– Ex: If we delete the article we no longer care
about Facebook comments on the article
Difference between
Composition and Aggregation
• Composition:
– Composed of multiple parts
– Parts have no independent existence
– The structured whole makes the object
• Aggregation:
– Does not imply ownership
– Parts have independent existence
– May be called a composition if the distinction is
not important
Generalization/Specialization
Generalization:
“a parent”
Specialization:
“a child”, inherits from a
general class
Realization (Implementation)
• Relationship where one class (the client)
implements another (the supplier)
• Represented with a dashed line from the
implemented class to the implementation
Dependencies
• A “using” relationship specifying that a change in
the specification of one thing may affect another
thing that uses it
• Common when the client class:
–
–
–
–
Uses a supplier class that has global scope
Uses a supplier class as a parameter
Uses a supplier class as a local variable
Sends a message to the supplier
UML Examples
• This level of detail is usually reserved for the
Design and Implementation phases
– Deliverable 3: design
– Deliverable 4: implementation
• You will not need to add all of these details in
your Deliverables 2 or 3
Source: bigelow.ch
Combinations of UML Diagrams
• A class might have behavior attached to it
• Behavior specified usually through a UML
activity diagram or a UML state diagram