Class Diagram

Class diagram is the basically classical representation of the static view of the
system and represents different aspects of the application.
A collection of class diagrams represent the whole system.
The following point should be remembered while drawing class diagram.
1) The name of the class diagram should be meaningful to describe the aspects of
the system.
2) Each element and their relationship should be identified in advance.
3) Responsibility (attributes and methods) of each class should be clearly
identified.
4) For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.
5) Use notes whenever required to describe some aspect of the diagram. At the end
of the drawing it should be understandable to the developer/coder.
6) Finally, before making the final version, the diagram should be reanalyzed and
reworked as many times as possible to make it correct.
 Relationships and type of Relationship

1) Generalization / Inheritance

Generalization are use to show an inheritance relationship b/w two classes.

e.g,

Parent

Child 1 Child 2

How to draw a class diagram

Class Name

Attributes

Operations / Function

Student Data Type

Name : String
Address : String
DOB : String or Date Return type
Phone No.: Integer
Register() : void
Login() : void
Fill_details(): void
 Association:

1 Exactly one
(0……*) zero or more
(1……*) one or more
(0……1) zero or one
(5……7) 5 to 7 mean 5, 6, 7
(4, 6) 4 or 6

1 (4,6) One student can

Student Books take 4 or 6 books.

1 (0….*) One student can

Student Books take zero or more
books.

1 (1….*) One student can

Student Books take one or more
books.
 Example: Online Shopping

Customer Admin
C.ID : Number Admin_ID : String
C.Name : String Admin.Name : String
C.Psw : String Admin_psw : String
C.address : String Admin_email : String
C.Pho No : Number 1  Add_Product() : void

(0.....*)
View Product() : void  Confirm_order() : void
 Add_to_cart() : void  Change_prod() : void
1  Payment() : void  Login() : void
 Login() : void
 Register() : void
1
(1.....*) (1.....*)
Order
(1.....*) Order_ID : Number
Order_status: boolean
Product
Order_date : String
P_Name : String (1.....*)
P_ID : Number  Find_detail() : void
P_price : Number (1.....*)
 availablestock() : void
1
 get_product() : void

(1.....*) 1
Payment
amount : Number
(1.....*) date : date
Payment_no : Number
Cart
Cart.ID : Number  Payment_detail(): void
Date : String  Slip_generation():void
1
 delete_cart() : void
 update_cart() : void
Generalization

Online Payment Offline Payment

Card no : Number Address : String
A/C : Number
 Bank () : void

(No Association in generalization)

Another Example:

Hospital Management

Aggregation example

Hospital

Doctor Patient

➢ Doctor is a part of hospital

➢ Patient is a part of hospital
Both patient & hospital can exist independently even if both have no relation.
Similarly, with doctor & hospital can exists independently so, Aggregation
Relation exist b/w them.
 Package Diagram

A package diagram is a unified modeling language depicts the dependencies b/w

the packages that makeup a model.
Package diagrams show the arrangement and organization of model elements in
middle to long scale project.
Package diagrams can also show both structure and dependencies b/w sub-systems
and modules.

UML Package Symbols

1) <<a>> 2) {}
Access Constraint

3) Dependency 4) Generlization

5) <<i>> Import 6) <<m>> Merge

Note Package

<< R >> Realization

Subsystem
 UML Package Symbols Description

Access: An element import is defined as a directed relationship b/w an

importing namespace and a package element.

Dependency: A dependency is a relationship that signifies that a single

or set of model elements requires other model elements for their specification or
implementation.

Import: a package import is defined as a directed relationship that

identifies a package whose numbers are to be imported by a namespace.

Merge: A package merge is direct relationship b/w two packages that

indicate that the contents of the two packages are to be combined.

Package: A package is use to group elements, and provides a namespace

for the grouped elements. A package is a namespace for its members, and many
contain other packages.
➢ Owned Members of a package should all be package elements.
➢ Package can also be merge with other package, thus provide the
hierarchical organization of package.
➢ Different types of elements are allowed to have the same name.
➢ The members of the package may be shown within the boundaries of the
package.
➢ The elements that can be referenced to within a package sing non-
qualified names are: Owned elements, imported elements and elements
enclosing namespace.
➢ Owned and imported elements may have a visibility that determines
whether they are available outside the package.
➢ Package members are not shown inside the package

Org.hibernate

Org.hibernate

➢ Package org. hibernate contains session factory and session.

➢ Package member are shown inside the package.

Org.hibernate

<< Interface >> << Interface >>

Session factory Session
 ➢ Members of the package may be shown outside of the package by
branching lines.
➢ Package org. hibernate contains interfaces session and session factory.

Org. hibernate

Sub System Symbol

<< Interface >> << Interface >>

Session factory Session

Nested Packages:

➢ Packages are useful for simplify this kind of diagram

➢ Nested packages
➢ Qualifies for graphics class is
Java:: Utilities:: Graphics

Java
Utilities
Graphics File Handling
 Java is a package which contains other packages inside Java like,
Utilities, Graphics and File handling etc. this is above is couple of nested
packages.
➢ Visibility of Owned and import element “+” for public and “-” for private
class all elements of library domain package are public except for
account.

Library Domain

+ Catalog

+ Patron

+ Librarian

- Account

Library domain is package and catalogue, and patron, librarian, account are the
members of the package library domain.

Packageable element

➢ A package able element is a named element that may be owned directly

by a package.
➢ Owned member of the package should all be package able element.
➢ If a package removed from the model, so are all the elements owned by
the package, Package by itself is package able element, so any package
could be also a member of the other package
Above line explain that a package contains a member element. When package is
removed all his element are also removed automatically.
 Relationships

➢ Dependency
➢ Generalization
➢ Refinement

1) Dependency
One package depend on another package

Fish Water

Fish depends on water

2) Generalization

Animal

Fish

Fish is a kind of animal.

Animal is a general package sub-packages many be fish, horses, dogs, cats etc.
these all belong to the general package animal.
 3) Refinement

Refinement shows different kinds of relationship between packages.

One package refines other package, if it contains same elements but offer more
details about those elements

<< refines >>

Rehearsal Performance

Performances refine rehearsals.

Model
Model is a package which captures view of a system.
View of system defined by its purpose and abstraction level. Model is notated
using the ordinary package symbol (a folder icon) with a small triangle in an upper
right corner of the large rectangle business layer model.

Business Layer
 ➢ If contents of the model are shown with in the large rectangle, the triangle
may be drawn to the right of the model name in the tab.
➢ Service layer model contains service interfaces and message types.

Service Layer

Service Message
Interfaces Types

Package Relationship:

➢ A relationship between two packages is called a package dependency.

➢ Dependency is not transitive.
➢ The dependency relationship between packages is consistent with the
associative relationship between classes.

e.g;

If changing the contents of a package P2, affects the contents of another package
P1, has a package dependency on P2.
Package dependency diagram:-

Client Service

• •
• •
• •
• •
Client Service

• •
• •
• •
• •
Package client Package service:
Import service Public class service {
Public class client { ………...
Private service –s; …………
………… }
}
Two types of relationship: unidirectional and Bi-directional:

Unidirectional Diagram:

A A

B
C

Bidirectional Diagram:

A
A

B
B A,

C
A,

,
Bidirectional means from A, we can move to B and A as well.
 Use Case Package Diagram:

ATM System ATM System

Banker
Withdraw cash

Deposit Funds
Transition
Customer
Transfer Funds Withdraw Cash Transfer Funds

Customer
Banker
Check Balance
Deposit Funds Check Balance

Login
Maintenance

Login
Problem
Maintenance
person Maintenance
person Problem

Use case diagram Use case Package Diagram

From the above use case diagram, we have made two packages, (1) Transition and
(2) Maintenance.

Transition and maintenance have relationship. Transition depends on the

Maintenance.
 When to use Package Diagram?

➢ A large complex project can have hundred of classes. Without some

way to organize those classes, It becomes impossible t make sense of
them all.
➢ Packages create a structure for your classes or other UML element by
grouping related elements.
➢ Package diagrams represent a compile time grouping mechanism.
➢ When you want to show the high level view of the system.
➢ To keep track of dependencies.
➢ With the large system to show its major element and how they relate to
one another.
➢ To divide a complex system into module.
➢ Package diagrams can use packages that represent the different layers
of a software system to illustrate the layered architecture of a software
system.