4.

Class Diagram
Objects

• Object Diagram
• Class Diagram

• Ref.: chapter 4

Analysis and Design of IS 2

What is an Object?

• Informally, an object represents an entity,

either physical, conceptual, or software
 Physical entity

Truck

 Conceptual entity

Chemical Process

 Software entity
Linked List

Analysis and Design of IS 3

A More Formal Definition

• An object is a concept, abstraction, or thing

with sharp boundaries and meaning for an
application
• An object is something that has:
 Identity
 State
 Behavior

Analysis and Design of IS 4

Representing Objects

• An object is represented as rectangles with

underlined names
: Professor
a + b = 10

ProfessorClark
Class Name Only
Professor Clark

ProfessorClark : Object Name Only

Professor

Class and Object Name

Analysis and Design of IS 5

What is a Class Diagram?

• A class is a description of a group of objects

with common properties (attributes), behavior
(operations), relationships, and semantics
 An object is an instance of a class
• A class is an abstraction in that it:
 Emphasizes relevant characteristics
 Suppresses other characteristics

Analysis and Design of IS 6

Sample Class

Class
Course

Properties
Name a + b = 10
Location
Days offered
Credit hours
Start time
End time Behavior
Add a student
Delete a student
Get course roster
Determine if it is full

Analysis and Design of IS 7

Representing Classes

• A class is represented using a

compartmented rectangle

a + b = 10

Professor Class

Analysis and Design of IS 8

Class Compartments

• A class is comprised of three sections

 The first section contains the class name
 The second section shows the structure
(attributes)
 The third section shows the behavior (operations)

Class Name Professor

Attributes + empID: number

+ Name: text(50)
Operations + Create()
+ Save()
+ Delete()
+ Update()

Analysis and Design of IS 9

• Access Control
 public (+): a public element (attribute or service) of a class can be
accessed from anywhere.
 private (-): a private element can be accessed only from within the
class itself, i.e. that element can be accessed only from within
instances of that class.
 package (~): Elements denoted with package scope are accessible
from within any element defined within the same package.
 protected (#): implies that the element can be accessed from within
instances of that class an instances of any subclass, but not from
within an object which is not an instance of the class or one of its sub-
classes.

Analysis and Design of IS 10

Mapping class and object diagrams onto Java

//Class //Class
public class Client {} public class Account {}

// Object
// Object
Client sam = new Client();
Account acc1 = new Account();
Client jill = new Client();

Analysis and Design of IS 11

Mapping UML methods onto Java

public class Date

{
public int getDayOfMonth() {...}
public int getMonth() {...}
public int getYear() {...}
public void setDayOfMonth(int day) {...}
public void setMonth(int month) {...}
public void setYear(int year) {...}
...
}

Analysis and Design of IS 12

Classes of Objects

• How many classes?

Analysis and Design of IS 13

The Relationship Between Classes and Objects

• A class is an abstract definition of an object

 It defines the structure and behavior of each
object in the class
 It serves as a template for creating objects

• Objects are grouped into classes

Objects Class

Professor Smith Professor Mellon

Professor Jones
Analysis and Design of IS 14
What is an Attribute?

Object
Class

Attribute Value
Course101
Attribute
No = 101
: CourseOffering StartTime = 900
EndTime = 1100
+ No: number
+ StartTime: number
+ EndTime: number Course104
+ …() No = 104
+ …() StartTime = 1300
EndTime = 1500

Analysis and Design of IS 15

What is an Operation?

Class
: CourseOffering
+ No: number
+ StartTime: number
Operation + EndTime: number
+ AddStudent()
+ DeleteStudent()
+ GetStartTime()
+ GetEndTime()

Analysis and Design of IS 16

What is Polymorphism?

• The ability to hide many

different
implementations behind
a single interface

Java code
Analysis and Design of IS 17
What is an Interface?

• Interfaces formalize polymorphism

• Interfaces support “plug-and-play”
architectures

Realization relationship
Analysis and Design of IS 18
Relationships

• Association
 Aggregation
 Composition

• Dependency
• Generalization
• Realization

Analysis and Design of IS 19

Relationships: Association

• Models a semantic connection among

classes
Association Name

Association
Class
Role Names

Analysis and Design of IS 20

Relationships: Aggregation

• A special form of association that models a

whole-part relationship between an
aggregate (the whole) and its parts

Whole Part

Aggregation

Analysis and Design of IS 21

Aggregation – a whole-part relationship

• Identified by - 'consists of', 'has a', or 'is a

part of‘
• Wheels, doors and engine are ‘part’ of a car

Analysis and Design of IS 22

• A Personal Computer includes CPU, Hard Disk, Monitor, and
Keyboard as parts. But, these parts can exist without being
installed into a computer. The open diamond indicates
aggregation, but not composition

Analysis and Design of IS 23

Relationships: Composition

• A form of aggregation with strong ownership

and coincident lifetimes
 The parts cannot survive the whole/aggregate
Whole Part

Composition

Analysis and Design of IS 24

Composition – tighter aggregation

• the whole object has exclusive ownership of

its parts i.e. the part object can only
participate in one aggregation;
• the parts live and die with the whole

Analysis and Design of IS 25

 (a) Class diagram
Closed diamond indicates
composition. The room
cannot exist without the
building

(b) Object diagram

Analysis and Design of IS 26

Association: Multiplicity and Navigation

• Multiplicity defines how many objects

participate in a relationships
 The number of instances of one class related to
ONE instance of the other class
 Specified for each end of the association

• Associations and aggregations are bi-

directional by default, but it is often desirable
to restrict navigation to one direction
 If navigation is restricted, an arrowhead is added
to indicate the direction of the navigation

Analysis and Design of IS 27

Association: Multiplicity

• Unspecified
• Exactly one 1
• Zero or more (many, unlimited) 0..*

*
• One or more 1..*
• Zero or one 0..1
• Specified range 2..4
• Multiple, disjoint ranges
2, 4..6

Analysis and Design of IS 28

Example: Multiplicity and Navigation

Multiplicity

Navigation

Analysis and Design of IS 29

Relationships: Dependency

• A relationship between two model elements

where a change in one may cause a change
in the other
• Non-structural, “using” relationship
:Client :Supplier Component
Class

Package Client Supplier

Dependency
relationship

ClientPackage SupplierPackage
Dependency
relationship
Analysis and Design of IS 30
Relationships: Generalization

• A relationship among classes where one

class shares the structure and/or behavior of
one or more classes
• Defines a hierarchy of abstractions in which a
subclass inherits from one or more
superclasses
 Single inheritance
 Multiple inheritance

• Generalization is an “is-a-kind of” relationship

Analysis and Design of IS 31

Example: Single Inheritance

• One class inherits from another

Ancestor

Superclass
(parent)

Generalization
Relationship

Subclasses
(child)

Descendents

Analysis and Design of IS 32

Example: Multiple Inheritance

• A class can inherit from several other classes

Multiple inheritance

Use multiple inheritance only when needed, and

always with caution !
Analysis and Design of IS 33
What Gets Inherited?

• A subclass inherits its parent’s attributes,

operations, and relationships
• A subclass may:
 Add additional attributes, operations, relationships
 Redefine inherited operations (use caution!)

• Common attributes, operations, and/or

relationships are shown at the highest
applicable level in the hierarchy

Inheritance leverages the similarities among classes

Analysis and Design of IS 34
Example: What Gets Inherited

Superclass
(parent)

generalization

Subclass
(child)

aggregation

Analysis and Design of IS 35

Addition

http://creately.com/blog/diagrams/class-diagram-relationships/
Analysis and Design of IS 36
Class Diagram for the Sales Example

Sale

seller buyer item sold shipping mechanism

Salesperson Customer Product Vehicle

Corporate Individual Truck Train

Analysis and Design of IS 37

• Ref.

Analysis and Design of IS 38

Additional Class Diagrams

• Additional class diagrams are added as

needed
• They show additional “views” of the packages
and classes in the model
• Examples:
 View of classes participating in a scenario
 View of the “private” classes in the package
 View of one or more classes and their attributes
and operations
 View of an inheritance hierarchy

Analysis and Design of IS 39

Additional Ref.: Displaying Visibility

Analysis and Design of IS 40

Additional Ref.: Class Relationships

Unidirectional

Bi-directional

Analysis and Design of IS 41

Additional Ref.:

Analysis and Design of IS 42

Package Relationships

Analysis and Design of IS 43

A Sample Database Application
• The COMPANY database keeps track of a company’s
employees, departments, and projects.
 The company is organized into departments. Each department has a
unique name, a unique number, and a particular employee who
manages the department. We keep track of the start date when that
employee began managing the department. A department may have
several locations.
 A department controls a number of projects, each of which has a
unique name, a unique number, and a single location.
 The database will store each employee’s name, Social Security
number, address, salary, sex (gender), and birth date. An employee is
assigned to one department, but may work on several projects, which
are not necessarily controlled by the same department. It is required to
keep track of the current number of hours per week that an employee
works on each project, as well as the direct supervisor of each
employee (who is another employee).
 The database will keep track of the dependents of each employee for
insurance purposes, including each dependent’s first name, sex, birth
date, and relationship to the employee.
Analysis and Design of IS 44
The COMPANY conceptual schema in UML
class diagram notation

Analysis and Design of IS 45

Analysis and Design of IS 46