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

These classes belong to those packages.

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