You are on page 1of 55

Part3: Class Diagram

Classes

ClassName A class is a description of a set of


objects that share the same attributes,
operations, relationships, and semantics.
attributes
Graphically, a class is rendered as a rectangle, usually including its
name, attributes, and operations in separate, designated
operations compartments.
Class Names

The name of the class is the only required tag in the


ClassName graphical representation of a class. It always appears in
the top-most compartment.

attributes

operations
Class Attributes

Person

An attribute is a named property of a


name : String class that describes the object being modeled.
address : Address In the class diagram, attributes appear in
birthdate : Date the second compartment just below the
ssn : Id name-compartment.
Special properties of attributes and operations

• Visibility
• Public[+].
• Protected[#].
• Private[-].

Toolbar
public #currentSelection protected
#toolCurrent
+pickItem()
+addTool()
+removeTool()
protected +getTool()
#checkOrphans()
private -compact()
5
Visibility
• Public[+]: any outside classifier with visibility to the given classifier can use this feature.
Visibility
• Protected[#]: attributes and operations are specified using the hash (#) symbol and are more visible to
the rest of your system than private attributes and operations, but are less visible than public.
Declared protected elements on classes can be accessed by methods that are part of your class and
also by methods that are declared on any class that inherits from your class
Visibility
• Private[-]: only the classifier itself can use the feature.
Class Operations

Person

name : String
address : Address
birthdate : Date
ssn : Id

Operations describe the class behavior


eat and appear in the third compartment.
sleep
work
play

Software Design (UML)


Possible Classes
When modeling a class in UML, you have a lot of flexibility. The same class can
be modeled in four different ways:
• With no attributes or operations shown
• With only the attributes shown
• With only the operations shown
• With both the attributes and operations shown
The name of the class is always in the first compartment of the class box; in fact, it is the only required
component.
Possible Classes
When drawing a class, you needn’t show attributes and operation in every diagram.

Person Person
Person

name : String
birthdate : Date
Person ssn : Id

name Person eat()


address sleep()
birthdate work()
eat play()
play

Software Design (UML)


Class/object representation
Class/object representation
Relationships
In UML, object interconnections (logical or physical), are modeled as relationships.

There are three kinds of relationships in UML:

 Dependencies

 Generalizations

 Associations
Dependency Relationships
A dependency indicates a semantic relationship between two or
more elements. The dependency from CourseSchedule to Course exists because
Course is used in both the add and remove operations of CourseSchedule.

CourseSchedule

Course

add(c : Course)
remove(c : Course)
Generalization Relationships

Person
A generalization connects a subclass to its superclass.

It denotes an inheritance of attributes and behavior from the superclass


to the subclass and indicates a specialization in the subclass of the more
general superclass.

Student

Software Design (UML)


Generalization Relationships (Cont’d)
UML permits a class to inherit from multiple superclasses, although some
programming languages (e.g., Java) do not permit multiple inheritance.

Student Employee

TeachingAssistant

Software Design (UML)


Generalization Relationships (Cont’d)

Supertype Example: Customer

Regular Loyalty
Customer Customer

Subtype Subtype2
1 or: Customer

Generalization expresses a
relationship among related
classes. It is a class that
includes its subclasses.
Regular Loyalty
Customer Customer
Association Relationships
If two classes in a model need to communicate with each other, there must be link
between them.

An association denotes that link.

Student Instructor
Association Relationships

Two classes can relate to each other with a line and an association name.
Association: Multiplicity
Multiplicity allows us to indicate how many objects of one class relate to one object of another
class. We can add multiplicity on either end of a class relationship by simply indicating it next to
the class where the relationship enters.
Multiplicity

• It specifies the number of instances of one class that may relate to a single
instance of the associated class.
• UML diagrams explicitly list multiplicity at the end of association lines.
Multiplicity
Symbol Meaning
1 One and only one
0..1 Zero or one
M..N From M to N (natural language)
* From zero to any positive integer
0..* From zero to any positive integer
1..* From one to any positive integer
Association: Multiplicity and Roles

Role
“A given university groups many people; some act as students, others as
teachers. A given student belongs to a single university; a given teacher may or
may not be working for the university at a particular time.”
Association: Multiplicity and Roles
Here we see that a Student takes 4 to 6 classes, and a Class has 10 to 30 students.
Association: Multiplicity and Roles
Our class relationships can be further beefed up by adding roles. The use of a role in a class diagram helps
the reader to understand what the first class does for the second.

A role is shown in the same place as the multiplicity, either above or below the line indicating the relationship
where it enters the class.

“ClassOne plays the role of rolename1 for ClassTwo” and “ClassTwo plays the role of rolename2 for ClassOne.”
Association: Multiplicity and Roles
From this class diagram, we can deduct that “A Class has one Teacher who plays the role of the
Instructor” and “A Class has zero or one Teacher who plays the role of the Assistant.”
Association: Multiplicity and Roles
We can indicate the multiplicity of an association by adding multiplicity adornments
to the line denoting the association.

The example indicates that a Student has one or more Instructors:

Student Instructor
1..*

Software Design (UML)


Association: Multiplicity and Roles

The example indicates that every Instructor has one or more Students:

Student Instructor
1..*
Association: Multiplicity and Roles

We can also indicate the behavior of an object in an association (i.e., the role of an
object) using rolenames.

learns from teaches


Student Instructor
1..* 1..*
Association: Multiplicity and Roles

We can specify dual associations.

member of
1..* 1..*
Student Team

1 1..*
president of
Association: Aggregations
We can model objects that contain other objects by way of special associations called
aggregations and compositions.

An aggregation specifies a whole-part relationship between an aggregate (a whole) and a


constituent part, where the part can exist independently from the aggregate.

Aggregations are denoted by a hollow-diamond adornment on the association.

Engine
Car
Transmission
Association: Aggregations
Association: Aggregations

Container Class
Class C
Aggregation implies a relationship where the child can
AGGREGATION
exist independently of the parent.
Class E1 Class E2
Example: Class (parent) and Student (child). Delete the
Class and the Students still exist.
Containee Classes

example of Department and teacher. A single teacher can


not belong to multiple departments, but if we delete the
department, the teacher object will not be destroyed.

We can think about it as a “has-a” relationship.


Association: composition
A composition indicates a strong ownership and coincident lifetime of parts by the
whole (i.e., they live and die as a whole). Compositions are denoted by a filled-
diamond adornment on the association.

Scrollbar
1 1

Window Titlebar
1 1

Menu
1 1 .. *
Association: composition
COMPOSITION
Whole Class Composition implies a relationship where the child cannot
Class W
exist independent of the parent.
Example: House (parent) and Room (child). Rooms don't exist
separate to a House.
Class P1 Class P2

A "owns" B = Composition : B has no meaning or purpose in


Part Classes the system without A.
Example
Composition is again specialized form of Aggregation and we
House
can call this as a “death” relationship.

It is a strong type of Aggregation. Child object does not have its


Setting room Bedroom lifecycle and if parent object is deleted, all child objects will
also be deleted.
Association: composition
Example 1: University Courses
• Some instructors are professors, while others have job title adjunct
• Departments offer many courses, but a course may be offered by >1
department
• Courses are taught by instructors, who may teach up to three courses
• Instructors are assigned to one (or more) departments
• One instructor also serves a department chair
Summary
More examples on Relationships
Window

open() Event
close()

dependency
generalization

ConsoleWindow DialogBox Control

association
40
Generalization
• Relationship between general thing (parent) and more specific thing
(child)
• Child “is-a-kind-of” parent.
• Child inherits attributes and operations of parent.

generalization Shape base class

Rectangle Circle Polygon

Square leaf class


Dependency
• A change in one thing may affect another.
• “Uses” relationship.
• May have a name, but not common.

AudioClip
name
Microphone
record(m:Microphone)
start()
stop()
dependency
Associations (UML)
 Represent conceptual relationships between classes

direction indicator:
how to read relation name
relationship name

Professor teaches Course


* 1..*
teacher class

role names Multiplicity


defines the number of objects
associated with an instance of the
association.
Default of 1;
Zero or more (*);
n..m; range from n to m
Associations
 link is a semantic connection among objects.
 A link is an instance of an association.

association class
class association name
Worker 1..* works for* Company
employee employer
+setSalary( s : Salary)
+setDept( d : Dept)

w : Worker assign(develop
: Company
ment)
Named object link Anonymous object
Associations - Aggregation
- structural association representing “whole/part” relationship.
- “has-a” relationship.

part whole
multiplicity
1..*
Department Company

association
aggregation

45
More Examples on Multiplicity
 An association shows how classes are connected to each other:
– Symbols indicating multiplicity are shown at each end of the association.
*
Employee Company

* 1..*
Secretary Manager

Company BoardofDirectors

0..1 *
Office Employee

0, 3..8 *
Person BoardofDirectors

LEGEND
x..* (the range from x to many).
x..y (the range from x to y).
4
7
 Each association can be labelled, to make explicit
the nature of the association:

Association Association
Role Association Name Role
Class1 Class2

4
8
* Works for →
Employee Company

* has 1..*
Secretary Manager

Company BoardofDirectors

0..1 isAllocated *
Office Employee

0, 3..8 isMember *
Person BoardofDirectors

4
9
Analyzing & Validating Associations
* Works for →
Employee Company

 Many-to-one

– A company has many employees.

– An employee can only work for one company.


• This system is not capable of processing information about more
than one company per employee.

– A company can have zero employees.


• E.g. a ‘shell’ company.

– It is not possible to be an employee unless you work for a company. 8


Analyzing & Validating Associations
* 1..*
Secretary Manager

 Many-to-many
– A secretary can work for many managers.
– A manager can have many secretaries.
– Secretaries can work in pools.
– Managers can have a group of secretaries.
– Some managers might have zero secretaries.
– It is not possible for a secretary to have zero managers.
9
ANALYZING & VALIDATING ASSOCIATIONS

Company BoardofDirectors

 One-to-one

– For each company, there is exactly one board of directors.

– A board is the board of only one company.

– A company must always have a board.

– A board must always be of some company.


10
ANALYZING & VALIDATING ASSOCIATIONS

0, 3..8 isBoardMember *
Person BoardofDirectors

 Many-to-many

– There can be zero people on a board of directors.

– There can be three to eight people on a board of directors.

– A person plays the role of a “board member”.

– A person can be a member of more than one board.

– A person can exist without being a member of any board.


53
Ex: Passenger Reservation System (1)
• From the requirements of the problem, we are given:

• A Booking is always for exactly one passenger:


– Cannot have a booking without a passenger.
– A booking could never involve more than one passenger.

• A Passenger can have any number of Bookings:


– A passenger could have no bookings at all.
– A passenger could have more than one booking.

• Corresponding UML model:

Passenger * Booking

54
Ex: Passenger Reservation System (2)

• From the requirements of the problem, we are given:

 A Booking is always for exactly one SpecificFlight:


– No booking with zero specific flights.
– A booking could never involve more than one specific flight.

 A SpecificFlight can have any number of Bookings:


– A specific flight could have no bookings at all.
– A specific flight could have more than one booking.

Booking * SpecificFlight

55

You might also like