Introduction TO

UML

— Chapter 2 —

Sisay N.
 What is UML
◼ UML -Unified Modeling language and a blue print of
source code.
◼ It is a modeling language, not a methodology or process
◼ For visualizing, specifying, constructing and documenting the
artifacts of software systems.
◼ Visualizing - a picture is worth a thousand words; a
graphical notation articulates and unambiguously
communicates the overall view of the system (problem-
domain).
◼ Specifying - It provides the means to model precisely,
unambiguously and completely, the system in question.
 What is UML
◼ Constructing - models built with UML have a
“design” dimension to it; these are language
independent and can be implemented in any
programming language.
◼ Documenting -every software project involves a lot of
documentation -from the inception phase to the
deliverables.
◼ It provides the notations for documenting some of
these artifacts such as Requirements, Design, Tests
etc.
 Advantages of UML
◼ Most-Used and Flexible
◼ It is a highly recognized and understood platform for
software design.
◼ It is a standard notation among software developers.
◼ The Software Architecture Must Be Communicated
Effectively
◼ The software architecture is the blueprint of the system.
◼ It is the framework on which the efficiency of the system and
its processes depend.
◼ Effective if it is communicated properly to all those using
it and working on it.
◼ Can be used to model not just object-oriented software
engineering,
◼ But application structure and behavior, and business processes too.
 UML in OOP concept
◼ UML can be described as the successor of object-
oriented (OO) analysis and design.
◼ An object contains both data and methods that control
the data and this data represents the state of the object.
◼ A class describes an object and they also form a
hierarchy to model the real-world system.
◼ Objects are the real-world entities that exist around us
◼ It represent an entity and the basic building block.

◼ Class − Class is the blue print of an object.

 UML STRUCTURE
UML

Building blocks Common mechanisms Architecture

▪ Building blocks ▪ Architecture

▪ Things ▪ Use-case view
▪ Relationships ▪ Logical view
▪ Diagrams ▪ Process view
Implementation view
▪ Common mechanisms ▪

▪ Deployment view
▪ Specifications
▪ Adornments
▪ Common divisions
▪ Extensibility mechanisms
 Building block of UML
◼ The building blocks of UML can be defined as Things,
Relationships and Diagrams
I. Things
◼ Things are the most important building blocks of UML. It
can be Structural, Behavioral, Grouping or Annotational.
 Structural Things
◼ Structural things define the static part of the model and represent
the physical and conceptual elements.
◼ Following are the brief descriptions of the structural things.
◼ Class − Class represents a set of objects having similar
responsibilities.
◼ Interface − Interface defines a set of operations, which specify
the responsibility of a class.
◼ Collaboration −Collaboration defines an interaction between
elements.
◼ Use case −Use case represents a set of actions performed by a
system for a specific goal.
◼ Component −Component describes the physical part of a
system.
◼ Node − A node can be defined as a physical element that exists
at run time.
 Behavioral Things
◼ The verbs of UML models; usually the dynamic parts
of the system in question.
◼ Interaction -some behaviour constituted by messages
exchanged among objects; the exchange of messages
is with a view to achieving some purpose.
◼ State machine -a behaviour that specifies the
sequence of “states” an object goes through, during
its lifetime.
◼ A “state” is a condition or situation during the
lifetime of an object during which it exhibits certain
characteristics and/or performs some function.
 Grouping Things
◼ The organizational part of the UML model; provides a
higher level of abstraction (granularity).
◼ There is only one grouping thing available −
◼ Package -a general-purpose element that comprises
UML elements -structural, behavioral or even
grouping things.
◼ It used for gathering structural and behavioral
things.
◼ Used to group semantically related modeling
elements into a single cohesive unit.
 Annotational Things
◼ Annotational things can be defined as a
mechanism to capture remarks, descriptions, and
comments of UML model elements.
◼ Note - It is the only one Annotational thing
available.
◼ A note is used to render comments, constraints, etc. of
an UML element.
◼ It is like a note, which may be written to the model to
capture some vital information.
◼ It is similar to the yellow sticky note. Here is an example
for annotation things in UML:
 II. Relationship
◼ Relationship is another most important building
block of UML.
◼ It shows how the elements are associated with
each other and this association describes the
functionality of an application
◼ Articulates the meaning of the links between
things.
 Dependency
◼ In UML, a dependency relationship is a relationship
in which one element, the client, uses or depends
on another element, the supplier.
◼ (arrow-head points to the independent thing)
◼ For example, the Person class might have a
hasRead method with a Book parameter that
returns true if the person has read the book
(perhaps by checking some database).
 Association
◼ Association: a structural relationship that describes the
connection between two things

◼ Here are some rules for Association:

▪ Association is mostly verb or a verb phrase or noun or
noun phrase.
▪ It should be named to indicate the role played by the
class attached at the end of the association path.
▪ Mandatory for reflexive associations

◼ 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:
 Association

◼ A single student can associate with multiple

teachers:

◼ The example indicates that every Instructor has

one or more Students:

◼ We can also indicate the behavior of an object in

an association (i.e., the role of an object) using
role names.
 Aggregation and Composition
◼ Aggregation and Composition are subsets of
association meaning they are specific cases of
association.
◼ In both aggregation and composition object of
one class "owns" object of another class. But
there is a subtle difference:
◼ Aggregation implies a relationship where the
child can exist independently of the parent.
Example: Class (parent) and Student (child).
Delete the Class and the Students still exist.
 Composition
◼ Composition implies a relationship where the
child cannot exist independent of the parent.
Example: House (parent) and Room (child).
Rooms don't exist separate to a House.
 Generalization
◼ Generalization -a relationship between a general thing
(called “parent” or “superclass”) and a more specific
kind of that thing (called the “child” or “subclass”),
such that the latter can substitute the former.

◼ (arrow-head points to the superclass)

 III. Diagrams
◼ The graphical presentation of the model.
◼ Represented as a connected graph -vertices (things)
connected by arcs (relationships).
◼ UML includes nine diagrams -each capturing a
different dimension of a software-system architecture.
◼ Class Diagram
◼ Object Diagram
◼ Use Case Diagram
◼ Sequence Diagram
◼ Collaboration Diagram
◼ State chart Diagram
◼ Activity Diagram
◼ Component Diagram
◼ Deployment Diagram
 Use case
• Use case Modeling could be
– Essential
• Used at requirement elicitation stage
• Technology free
• Just to understand what users need to
see on the system from functions point
of view
– System
• Is a continuation of essential use case
• Adding implementation related details
 Components
• Diagram with the following components
▪ Actors, Use cases, Boundary
▪ Relationship (Associations, include or use,
Extend) and Documentation
▪ For each use case using the standard template
 Use Case Diagram
• Captures the system’s functionality and
requirements by using actors and use cases.
• Use Cases model the services, tasks, function
that a system needs to perform.
• Use cases represent high-level functionalities and
how a user will handle the system.
• Use-cases are the core concepts of Unified
Modeling language modeling.
 WhyUse-Case diagram?
▪ Use case diagrams capture the dynamic behavior of
a live system.
▪ It models how an external entity interacts with the
system to make it work.
▪ Are responsible for visualizing the external
things that interact with the part of the system.
▪ Purpose
▪ Used to gather the requirements of a system.
▪ Used to get an outside view of a system.
▪ Identify the external and internal factors influencing
the system.
▪ Show the interaction among the requirements are
actors
 use-case
• use cases are used to represent high-
level functionalities and how the user will
handle the system.
• a use case represents a distinct
functionality of a system, a component,
a package, or a class.
• it is denoted by an oval shape with the
name of a use case written inside the
oval shape.
• a use case is a typical sequence of actions
that a user performs in order to
complete a given task Use-case diagram notations
• The notation of a use case in UML …right
side
 Actor

• the actor is an entity that interacts with

the system.
• a user is the best example of an actor.
• an actor is an entity that initiates the use
case from outside the scope of a use
case.
• it can be any element that can trigger an
interaction with the use case.
• one actor can be associated with
multiple use cases in the system.
• the actor notation in UML is .. Right side.
• A use case should
• Cover the full sequence of steps from the beginning of
a task until the end.
• Describe the user’s interaction with the system
🞄 Note: the computations the system performs.
◦ Be written so as to be as independent as possible from
any particular user interface design.
◦ Only include actions in which the actor interacts with
the computer.
How to draw a use-case diagram?
• Analyze the entire system carefully.
• Find out every single function that is provided by
the system.
• These functionalities are converted into various
use cases which will be used in the use case
diagram.
• Enlist the various actors or things that are going
to interact with the system.
• These actors are responsible for invoking the
functionality of a system.
• Actors can be a person or a thing.
 cont..
• After the actors and use cases are enlisted, then you have to
explore the relationship of a particular actor with the use
case or a system.
• One must identify the total number of ways an actor could
interact with the system.
• A single actor can interact with multiple use cases at the
same time.
❖ When we are planning to draw a use case diagram, we
should have the following items identified.
▪ Functionalities to be represented as use case
▪ Actors
▪ Relationships among the use cases and actors.
 cont..

• Following rules must be followed while drawing use-

case for any system:
▪ The name of an actor or a use case must be
meaningful and relevant to the system.
▪ Interaction of an actor with the use case must be
defined clearly and in an understandable way.
▪ Annotations must be used wherever they are
required.
▪ If a use case or an actor has multiple relationships,
then only significant interactions must be displayed.
 Use Case Diagram Relationships

• Relationships between actors and use cases

– are represented by directional or
nondirectional edges
– May be annotated by stereotypes
– May relate two use cases
– May relate two actors, or
– May relate a use case and an actor
 Cont…

• There can be 5 relationship types in a use case

diagram.
▪ Association between actor and use case
▪ Generalization of an actor
▪ Extend between two use cases
▪ Include between two use cases
▪ Generalization of a use case
 Cont..
Association Between Actor and Use Case
• This one is straightforward and present in
every use case diagram.
• Few things to note.
• An actor must be associated with at least one
use case.
• An actor can be associated with multiple use
cases.
• Multiple actors can be associated with a single
use case.
cont..
 Generalization of an Actor

•Generalization of an actor means that one actor can

inherit the role of the other actor.
•The descendant inherits all the use cases of the
ancestor.
•The descendant has one or more use cases that are
specific to that role.
•Let’s expand the previous use case diagram to show
the generalization of an actor.
cont...
Extend Relationship Between Two Use Cases
•As the name implies it extends the base use case and
adds more functionality to the system.
•Here are a few things to consider when using the
<<extend>> relationship.
•The extending use case is dependent on the extended
(base) use case. In the below diagram the “Calculate
Bonus” use case doesn’t make much sense without the
“Deposit Funds” use case.
•The extending use case is usually optional and can be
triggered conditionally. In the diagram, you can see that
the extending use case is triggered only for deposits over
10,000 or when the age is over 55.
•The extended (base) use case must be meaningful on its
own. This means it should be independent and must not
rely on the behavior of the extending use case.
Cont..
 Include Relationship Between Two Use Cases

▪ Include relationship show that the behavior of the included

use case is part of the including (base) use case.
▪ The main reason for this is to reuse common actions across
multiple use cases.
▪ In some situations, this is done to simplify complex behaviors.
▪ Few things to consider when using the <<include>>
relationship.
▪ The base use case is incomplete without the included use
case.
▪ The included use case is mandatory and not optional.
Cont..
Example of use case diagram
 System boundary
▪ The use case describes the functionality of a system
from an outside point of view – from the users point of
view.
▪ Only the interaction between actors and system are
shown, what happens inside the system is hidden.
▪ This boundary is clarified by the system boundary
▪ Defines the scope of what a system will be.
▪ A system boundary of a use case diagram defines the
limits of the system.
▪ The system boundary is shown as a rectangle spanning all
the use cases in the system
 When to use a use-case diagram?
• A use case is a unique functionality of a system
which is accomplished by a user.
• A purpose of use case diagram is to capture core
functionalities of a system and visualize the
interactions of various things called as actors
with the use case.
In general use case diagrams are used for:
▪ Analyzing the requirements of a system
▪ High-level visual software designing
▪ Capturing the functionalities of a system
▪ Modeling the basic idea behind the system
▪ Forward and reverse engineering of a system
using various test cases.
 Flow of Events

• Specify the behavior of a use case by describing

the flow of events in text clearly enough for an
outsider to understand it easily.
• Include
– How and when the use case starts and ends

– When the use case interacts with the actors

– What objects are exchanged

– The basic flow and alternative flows of the

behavior
 Flow of Events

• Introduction: Describe a quick background of the use case.

• Actors: List the actors that interact and participate in this use
case.
• Actor Description/Definition: Define/Describe each actor.
• Pre-conditions: Pre-conditions that need to be satisfied for the
use case to perform.
• Post-conditions: Define the different states in which you expect
the system to be in, after the use case executes.
• Basic Flow: List the primary events that will occur when this use
case is executed.
• Alternative flows: Any subsidiary events that can occur in the
use case should be separately listed. List each such event as an
alternative flow. A use case can have as many alternative flows as
required.
 COMMON MODELING TECHNIQUE

• The most common thing for which you will apply use case
is to model the Functional behavior of an element ; A
system as a whole, a subsystem, or a class
– Focus on what that element does, not how it does Reasons for
applying use cases to elements

1. By modeling the behavior of an element with use cases, you

provide a way for domain experts to specify its outside view
to a degree sufficient for developers to construct its inside
view.
2. Use cases provide a way for developers to approach an
element and understand it.
3. Use cases serve as the basis for testing each element as it
evolves during development.
 Example:

⚫ On-line Bookstore is a web application that can be accessed by

the store’s registered customer, whereby each customer can order
books, review one or more books sold in the book store, and sell
used books to other customers. Before performing any one of
these transactions, the customer must first log-in into the system
using their user id and password kept in their account. The
customer can also take a book he/she ordered.
⚫ Problems:
⚫ Develop a use case model(system use case)-Provide your
reason to pick “one” as a component of your model
⚫ Document one of the use cases you have identified “sell used
book”
 What is Class Diagram?

◼ A Class Diagram in Software engineering is a

static structure that gives an overview of a
software system by displaying classes, attributes,
operations, and their relationships between each
other.
◼ This Diagram includes the class name, attributes,
and operation in separate designated
compartments.
◼ Class Diagram helps construct the code for the

software application development.

 Benefits of Class Diagram

• Class Diagram Illustrates data models for even

very complex information systems
• It provides an overview of how the application is
structured before studying the actual code.
• This can easily reduce the maintenance time
• It helps for better understanding of general
schematics of an application.
• Allows drawing detailed charts which highlights
code required to be programmed
• Helpful for developers and other stakeholders.
Essential elements of UML class diagram are:
▪ Class Name
▪ Attributes
▪ Operations
 Cont…

• Class diagrams are widely used to describe the

types of objects in a system and their
relationships.
• The relationship can be inheritance, aggregation
and association.
• The class model also describes the attributes
and operations of the class along with the
visibility of each.
• Public, private, package and default
 Components class
◼ The upper section encompasses the name of the
class.
◼ Some of rules that should be taken into account
while representing a class are given below.
• Capitalize the initial letter of the class name.

• Place the class name in the center of the upper

section.
• A class name must be written in bold format.

• The name of the abstract class should be

written in italics format
 ...
◼ Middle Section
◼ This section constitutes the attributes, which
describe the quality of the class.
◼ Attributes have the following characteristics:
◼ The attributes are written along with its visibility
factors, which are public (+), private (-), protected (#),
and package (~).
◼ The accessibility of an attribute class is illustrated by
the visibility factors.
◼ A meaningful name should be assigned to the attribute,
which will explain its usage inside the class.
 …
◼ Lower Section:
◼ The lower section contain methods or operations.
◼ The methods are represented in the form of a list,
where each method is written in a single line. It
demonstrates how a class interacts with data

public class Person {

private String name;
private int age; }
…
 Cont…

• A class is a definition of objects that share the

same properties, relationships and behavior.
• An object is an instance of a class.
• The properties of a class are called attributes
and the behavior is expressed in operations.
 Cont…

• Class diagrams model class structure and

contents using design elements such as
classes, packages and objects.
• Class diagrams are used in nearly all Object
Oriented software designs.
• They are used to describe the Classes of the
system and their relationships to each other.
 Common Uses

• Class diagrams are used to model the static design

view of a system
– supports the functional requirements of the
system
• When we model the static design view of a system,
we will use class diagrams in 3 ways: -
1. To model the vocabulary of the system
• involves making a decision about which
abstractions are a part of the system under
consideration and which falls outside its
boundaries
• Class diagrams are used to specify these
abstractions and their responsibilities
2. To model simple collaborations
• A collaboration is a society of classes, interfaces, and
other elements that work together to provide some
co-operative behaviour that is bigger than the sum of
all the elements
• Class diagrams are used to visualize and specify this
set of classes and their relationships
3. To model logical database schema
• Class diagrams can also be used to model schemas for
databases
used to store persistent information
 Cont…

• To start with class modeling, identify objects

and classes, prepare a data dictionary,
identify associations between objects,
identify class attributes and initial set of
operations and then organize object classes
using inheritance.
• This process can be initiated from CRC model.
Major concepts (Object and
class)
 Objects
• An object is simply a real-world thing or concept
• Three essential aspects of objects are:
– An object has an identity
• Can have a name or can be anonymous
– An object has state
• the names of the various properties that describe
the object (attributes) and also the value of those
attributes
– An object has behaviour
• represented by functions (or methods) that use
or change
the values of the object’s attributes
• An object is an instance of a class
 Classes
• Classes are the most important building block of any object-
oriented system
• Classes are used to: -
• capture the vocabulary of the system you are developing
• represent software things, hardware things, and even things
that are purely conceptual
• Well-structured classes have crisp boundaries and form a part of a
balanced distribution of responsibilities across the system

ClassName
attributes
operations
 Name

• Every class must have a name to distinguish it

from other classes
– can be a simple name, i.e. Student, Door,
etc
– can be a path name
• the class name prefixed by the name of
the package in which that class lives, i.e.
BusinessRecord::Customer,
• A class may be drawn showing only its name

Customer
 Attribute
• An attribute is a named property of a class that describes a
range of values that instances of the property may hold
– represents some property of the thing you are modelling
that is shared by all objects of that class
– At any given moment, an object of a class will have specific
values for every one of it’s class attributes
• A class may have a number of attributes
• Attributes may be drawn showing only their names (a)
• Or, we can further specify an attribute by stating its type and
possibly a default initial value (b)
 Operation

• An operation is the implementation of a service

that can be requested from any object of the class
to affect behaviour
– Often, invoking an operation on an object changes
the object’s data or state
• A class may have a number of operations or no
operations at all
• Operations may be drawn showing only their names (a)
• We can further specify an operation stating its signature (b)
• including the name, type and default value of all
parameters and (in case of functions) a return type

(a)
(b)
 Cont…

• Attributes define the properties of

the objects:
• every instance of the class has the same attributes
• an attribute has a data type
• an attribute has visibility (private, protected, public)
• the values of the attributes may differ among
instances
 Cont…

• Operations define the behavior of the

objects
» action performed on or by an object
» available for all instances of the class
» methods/operations has visibility (private, protected,
public)
» need not be unique among classes
Cont…
 A simple example

• On-line Bookstore Review

– a web application that can be accessed by the store’s
registered customer, whereby each customer can review
one or more books sold in the book store
– The process: -
• Each registered customer has an account that is used
to verify his/her ID and password
• Each registered customer, upon account verification,
can review one or more books based on its title.
• Problem: Come up with a set of classes that can be found in
the above problem
• Things that are found in the problem:
-
– The process: -
• Each registered CUSTOMER has an ACCOUNT that is
used to verify his/her ID and password
• Each registered CUSTOMER, upon ACCOUNT
verification, can REVIEW one or more BOOKS based on
its title.
– Therefore, the things identified are: -
• Account
• Customer
• Book
• Review
 – Account
• Each of these things can form individual classes with responsibilities
• Used to keep the customer’s ID and password for verifying that
the customer is a registered customer
• Also keeps additional information, i.e. e-mail address
– Customer
• Used to keep information about the customer, such as
customer’s name, ID, address etc
– Book
• Used to keep the relevant information on the book that is
crucial to
customer’s review, i.e. book title, author, rating
– Review
• Used to assign ratings to book reviewed (with 1 being the
lowest and 5 the highest)
• Used to compute the average rating for each book that has
been
reviewed
• Translate the responsibilities for each class into attributes and operations
needed to perform those responsibilities (relevant to the given problem)
– Account
• Attributes: emailAddress, ID, password
• Operations: verifyPassword()
– Customer
• Attributes: CustName, CustAddress, CustID etc
• Operations: NONE
• Can choose not to show the attributes when modelling the class as they
are not relevant to the given problem
– Book
• Attributes: title, author, rating
• Operations : NONE
– Review
• Attributes: NONE
• Operations: assignRatings(rating : Int), computeAvgRating() : double
Customer
assignRating(rating : Int)
computeAvgRating() : Double
 Class Relationships

• A relationship is, a general term, covering the

specific types of logical connections found on class
diagrams.
• A Link is the basic relationship among objects.
• It is represented as a line connecting two or more
object boxes.
• A link is an instance of an association. In other
words, it creates a relationship between two
classes.
• When we build abstractions, we will discover that
very few classes stand alone
– most of them collaborate with others in a
number of ways
 Cont…
• Therefore, when we model a system, we must
– identify the things that form the vocabulary of our
system (classes)
– model how these things stand in relation to one
another
• In UML, the ways that things can connect to one
another, either logically or physically, are modelled as
relationships
• In object-oriented modelling, there are three kinds of
relationships that are most important
– Dependencies
– Generalizations
– Associations
 – Dependencies
• represents ‘using’ relationship among classes
– Generalizations
• connects generalized classes to more specialized ones in what
is known as subclass/super-class or child/parent relationship
(inheritance)
– Associations
• represents structural relationships among instances/objects
• Each of these relationships provides a different way of combining our
abstractions (classes)
• The UML provides a graphical representation for each of these kinds
of relationships
– allows us to visualize relationships
– emphasize the most important parts of a relationship: its name,
the things it connects, and its properties
 Dependency
• A dependency is a using relationship that states that
a change in specification of one thing (independent
thing) may affect another thing that uses it
(dependent thing), but not necessarily the reverse
• It is rendered as a dashed directed line

dependent independent
• Dependencies are used in the context of classes to
show that one class uses another class as an
argument in the signature of an operation
– if the used class changes, the operation of the other

class may be affected

• The most common kind of dependency relationship is
the connection between a class that only uses
another class as a parameter to an operation
➢To model dependency
– Create a dependency pointing from the class with the
operation to the class used as a parameter in the
operation
• Example: - A system that manages the assignment of students and
instructors to courses in a university

Course

✓ There’s a dependency from CourseSchedule to

Course, as Course is used in both the add()
and remove() operations of CourseSchedule
 Generalization

• A generalization is a relationship
between a general thing (superclass or
parent) and a more specific kind of that
thing (subclass or child)
• Generalization means that objects of
the child may be used anywhere the
parent may appear, but not the reverse
– the child is substitutable for the parent
•It supports polymorphism
–An operation of the child that has the same name/
signature as an operation in a parent overrides the
operation of the parent
 ParentClass

• Graphically, a generalization is rendered as a solid directed line with a

large open arrowhead, pointing to the parent
• A class may have zero, one or more parent
– A class that has no parent and one or more children is called a
root or base class
– A class that has no children is called a leaf class
– A class that has exactly one parent is said to use single inheritance
– A class that has more that one parent is said to use multiple
inheritance
– A given class cannot be its own parent
• We will often use generalizations among classes and interfaces to
show inheritance relationships.
– can also create generalizations with packages
❖ To model inheritance relationship
➢ Given a set of classes, look for responsibilities, attributes
and operations that are common to two or more classes
➢ Elevate those common responsibilities, attributes and
operations to a more general class. If necessary, create a
new class to which you can assign these elements
➢ Specify that the more-specific classes inherit from the
more-general class by placing a generalization
relationship that is drawn from each specialized class to
its more-general parent
• Example: - The Rectangle, Circle and Polygon classes inherits from
the attributes and operations of the Shape class
Shape
origin
move() resize()
display()

Circle

radius : Float
 Association
• An association is a structural relationship that specifies
that objects of one thing are connected to objects of
another.
• we can navigate from an object of one class to an object
of the other class, and vice versa
• Types of association: -
➢ Unary association
➢where both ends of an association circle back to the same class
➢ Binary association
➢connects exactly two classes
➢ N-ary association
➢connects more than two classes
➢Graphically, an association is shown as a solid line connecting the
same or different classes
• There are 4 adornments that apply to associations: -
– Name
• An association can have a name to describe the nature of the
relationship
• A direction can also be given to the name by providing a
direction triangle that points in the direction intended (to read
t he name)
na m e
name direction
Works for
Person Company

association
– Role
• When a class participates in an association, it has a specific
role that it plays in the relationship
• A role is just the face that the class at the near end of the
association presents to the class at the other end of the
association
• An explicit name can be given to the role a class plays in an

association
association

Person employee Company

employe
r
role name
– Multiplicity
➢ It is important to state how many objects may be connected
across an instance of an association
➢ This “how many” is called multiplicity of an association’s role
➢ It is written as an expression that evaluates to a range of
values or an explicit value
➢ Multiplicity can be written as multiplicity of
– exactly one (1)
• one or more (1..*)
– zero or one (0..1)
– many (*) • exact numbers, i.e 3
multiplicity

Person 1e.m*ployee Company

emplo*y
er
– Aggregation
• is a “whole-part” relationship within which one or more smaller
class are “part” of a larger “whole”
• represents a “has-a” relationship, whereby an object of the whole
class has objects of the part

Company
whole 1
aggregation

part *
Department
• Association Classes
➢ Sometimes in an association between two classes, the association itself
might have properties
➢ In the UML, you’ll model this as an association class, which is a modeling
element that has both association and class properties
• It is used to model an association that has characteristics of its own
outside the classes it connects
• It comes in handy when you have many-to-many relationship that
you would like to break into a set of one-to-many relationships
– Warning: You cannot attach an association class to more than one
association
• UML represents an association class with a regular class box and a dashed line
*association between the other two
that connects the association class to the
classes.
1..
*
• Example: There’s a many-to-many relationship between Author and Book, whereby an
Author may have written more than one book and a Book may have more than one Author.
The presence of the BookAndAuthor association class allows us to pair one Author with
one Book: the role attribute allows us to state whether the Author was the primary, or
supporting author, or editor or etc

* 1..* Book
Author
title: String

BookAndAuthor
role: String
❖To model structural relationship
(association): -
– For each associations, specify a multiplicity
– If one of the classes in an association is structurally or organizationally a
whole compared with the classes at the other end that look like parts, use
an aggregation
– If there’s a many-to-many relationship between two classes, use
association class (if possible)
 Modelling Relationships
• When modelling relationships in the UML
– Use dependencies only when the relationship is not structural
– Use generalization only when the relationship is an “is-a-kind-of” or
inheritance relationship
• Beware of introducing cyclical generalization relationships
– Keep generalization relationships generally balanced where the level of
inheritance should not be too deep
– Use associations only when there are structural relationships among
objects
 A simple example

• On-line Bookstore Review

– a web application that can be accessed by the store’s registered
customer, whereby each customer can review one or more books sold in
the book store
– The process given: -
• Each registered CUSTOMER has an ACCOUNT that is used to verify
his/her ID and password
• Each PASSWORD entered must be more than 8 characters and
consists of a combination of text and numbers
• Each registered CUSTOMER, upon ACCOUNT verification, can REVIEW
one or more BOOKs based on its title
• A REVIEW can either be a customer’s review and editor’s review
• Things that are found in the
problem: -
– Account
– Password
– Customer
– Book
– Review
• can be divided into CustomerReview and
EditorialReview
 Cont…

• Each of these things can form

individual classes with responsibilities
– Account
• Used to keep the customer’s ID and password for verifying
that the customer is a registered customer
• Also keeps additional information, i.e. e-mail address
• The password is of the type PASSWORD
– Password
• Used to check that the password entered is valid (more than 8
characters and consists of combination of text and numbers)
– Customer
• Used to keep information about the customer, such as customer’s
name, ID, address etc
– Book
• Used to keep the relevant information on the book that is crucial
to customer’s review, i.e. book title, author, rating
 Cont…
– Review
• Divided into sub-classes: CustomerReview and EditorialReview
– CustomerReview
• Used to assign ratings to book reviewed (with 1 being the lowest
and 5 the highest) by customer
• Used to compute the average rating for each book that has been
reviewed by customer
– EditorialReview
• Used to store editor’s review
 – Account

• Translate the responsibilities for each class into attributes and operations needed to perform those responsibilities
(relevant to the given problem)

• Attributes: emailAddress(string), ID(string), passwd(Password)

• Operations: verifyPassword(p: Password)
– Password
• Attributes: passwd(string)
• Operations: checkPassword()
– Customer
• Attributes: CustName, CustAddress, CustID etc
• Operations: NONE
• Can choose not to show the attributes when modeling the class as they are not
relevant to the given problem (put NONE for both)
– Book
• Attributes: title, author, rating
• Operations : NONE
 – Review

• Attributes: NONE
• Operations: NONE
– CustomerReview
• Attributes: NONE
• Operations: assignRatings(rating : Int), computeAvgRating()
: double
– EditorialReview
• Attributes: NONE
• Operations: NONE
• The relationship between classes: -
– Dependency
• The operation verifyPassword in Account class has as
parameter a Password class
• Therefore, Account depends on Password
– Generalization
• Review can be divided into customer’s review and editor’s
review
• Therefore, CustomerReview and EditorialReview is the subclass
of Review
– Association
• A customer can open 1 account and an account can be opened by 1
customer
• A customer writes a review and a review can be written by a customer
• 1 customer can write 1 or many reviews, but 1 review can only come
form 1 customer
• A book can have many reviews but a review is for one book
 Object diagrams
•Object diagrams model the instances of things
contained in class diagrams
•An object diagram shows a set of objects and
their relationships at a point in time
•You use object diagrams to model the static
design view or static
process view of a system.
• involves modeling a snapshot of the system at a
moment in time and rendering a set of objects,
their state, and their relationships
• The UML notation for an object takes the same form as that for a class,
except for 3 differences:
– Within the top compartment of the class box, the name of the class
to which the object belongs to appears after a colon :
• The object may have a name that appears before the colon, or it may be
anonymous (no name before the colon)
– The contents of the top compartment are underlined for an object.
– Each attribute defined for the given class has a specific value for
each object that belong to that class.

Object : Class : Class

attribute1 = value attribute1 = value

attribute2 = value attribute2 = value

named object anonymous object

• Object diagrams commonly contain
– objects
– links
– may contain notes and constraints
– may also contain packages or subsystems, both of which are used to
group elements of your model into larger chunks
• You use object diagrams to model the static design view or static
process view of a system just as you do with class diagrams, but from
the perspective of real or prototypical instances
– Supports the functional requirements of a system
Example: From the class diagram given below, you
can get several
instances of it.

Author
wrote
 : Author : Book
wrote

Object diagram
 : Book
wrote

published by

Object diagram
 Sequences Diagram
• In every system, objects do not just sit idle; they interact with one
another by passing messages.
• In the UML, the dynamic aspects of a system is modelled using
interactions
– An interaction sets the stage for its behaviors by introducing
• all the objects that work together to carry out some action,
and
• the messages that are dispatched from object to object
 Definition
• An interaction is a behaviors that comprises a set of
messages exchanged among a set of objects within a
context to accomplish a purpose.
• Interactions can be found wherever objects are linked
to one another, e.g.
– in the collaboration of objects that exist in the context
of a system and subsystem as a whole
– among objects in the implementation of an operation
– in the context of a class in order to visualize, specify,
construct and document the semantic of a class

116
 Messages & Actions
• A message is a communication between two objects,
or within an object,that is designed to result in some
activity.
• This activity involves one or more actions, which are
executable statements that result in
– changes in the values of one or more attributes of
an object, or the return of some value(s) to the
object that sent the message, or both
• There are 5 kinds of actions that the UML explicitly
supports: -
– Call and Return; Create and Destroy; Send
117
• Call action
– A call action invokes an operation on an object
– It is synchronous, meaning that
• the sender assumes that the receiver is ready to accept the message,
• and the sender waits for a response from the receiver before proceeding
– The UML represents a call action as an arrow from the calling object to the
receiving object

: Class Object: Class

A call action that involves
action name two objects

A lifeline
action name
A call action
from an object
to itself
118
• Return action
– A return action is the return of a value to the caller, in response
to a call action
– The UML represents a return action as a dashed arrow from the
object returning the value to the object receiving the value

: Class Object: Class

return value

119
Example :- Call and Return
action

: Customer : CustomerReview
assignRating()

computeAvgRating()

average rating

120
 Example for Call and Return Actions

1.Call and Return Actions:

•Call Action: This is when one object calls an operation (method) of
another object. It’s like invoking a function or procedure.
•Return Action: Once the called operation finishes its task, it sends the
result or acknowledgment back to the caller.
•Example: A User object calls the withdraw() method on an ATM
object, and the ATM object returns the cash or an error message.
• Create action
– A create action creates an object
• It tells a class to create an instance of itself
– In the UML, create action is represented as an arrow with the stereotype <<create>>
from the object that invokes the create action to the created object

Object: Class : Class Object: Class

<<create>> <<create>>
: Class

Alternate Create Action notation

122
• Destroy action
– A destroy action destroys an object
• It tells an object to destroy itself
– An object can perform a destroy action on another object, or on itself
– In the UML, a destroy action is represented as an arrow with the
stereotype <<destroy>> from the object that invokes the action to the
destroyed object. A large X is also added at the end of the destroy arrow to
denote that the object’s lifeline has been terminated

Object: Class : Class

<<destroy>>
X

123
 Example for creation and Destroy

•Create Action:
•This action is responsible for creating a new instance of a class. It
initializes the object and assigns values to its attributes if needed.
•Example: In a bank system, creating a new Account object when a
customer registers.
•Destroy Action:
•This action removes an existing object from the system, often freeing up
memory or closing processes.
•Example: Deleting a Session object when a user logs out.
 • Send action
– A send action sends a signal to an object
– A signal is an asynchronous communication between objects
• One object “throws” a signal to another object that “catches” the signal
• The sender of the signal does not expect a response from the receiver (unlike the
sender of a call action)
• Exceptions are the most common type of signals
– In the UML, a send action is represented as an arrow with a half
arrowhead at the lifeline of the receiving object

: Class Object: Class

action name

Send Action:
•It’s used to send a signal or message from one object to another without waiting for a response. This is often seen in asynchronous
communication.
•Example: An Order object sends a confirmation email to a Customer object.
 Modelling an interaction

• When modelling an interaction, we need to include both objects

and messages
– each object plays a specific role
– each message represents the communication between objects,
with some resulting action
• We can visualize objects and messages in an interaction in two
ways: -
– by emphasizing the time ordering of its message : sequence
diagram
– by emphasizing the structural organization of the objects that
send and receive messages : collaboration diagram
• Both sequence and collaboration diagram are examples of
interaction diagrams

126
 Cont
…
• In the UML, an interaction diagram is used to model the dynamic aspect
of a system.
• These dynamic aspect may involve : -
– the interaction of any kind of instance in any view of a system’s
architecture, including instances of a class, interface, components
and nodes.
– a system as a whole, a subsystem, an operation or a class
•An interaction diagram can be used in two ways: -
–To model flows of control by time ordering
•emphasizes the passing of messages as they unfold over time
•Sequence Diagram is used to model this
–To model flows of control by organization
•emphasizes the structural relationships among the instances in the
interaction, along which messages may be passed
•Collaboration Diagram is used to model this
 Sequence diagram…

• A sequence diagram is an interaction diagram that emphasizes the

time ordering of messages
• A sequence diagram is formed by: -
– Placing the objects that participate in the interaction at the top
of the diagram, along the X-axis
• The object that initiates the interaction is placed on the left
most, and the other subordinate objects are placed to the
right
• Placing the messages that these objects send and receive
along the Y-axis, in order of increasing time from top to
bottom

128
• A sequence diagram has four key elements:
– Objects appear along the top margin
– Each object has a lifeline, which is a dashed line that represent the life and
perhaps death of the object
• Most objects will be in existence for the duration of the interaction
• Objects may also be created during the interaction, or destroyed
– A focus of control, which is a tall thin rectangle that sits on top of an object’s
lifeline
• It shows the period of time during which an object is performing an action,
either directly or through subordinate procedure
• The bottom part of a focus of control can be marked by a return message
– Messages show the actions that objects perform on each other and on themselves

138
 objects

C : Client p : ODBCProxy

<<create>>
: Transaction

setActions(a, d, o)
setValues(d, 3, 4)

time setValues(a, “CO”)

committed

<<destroy>> lifeline
X
focus of control

Example of a sequence diagram

130
• You built sequence diagrams or collaboration diagrams from the use-
case and class diagrams that were built before.
– Each use cases in a use-case diagram has its corresponding
sequence or collaboration diagram
– You model the diagrams from the main flow of events, or the
alternate flow of events, or the scenarios, of each use case
– Every object that you have identified in the sequence or
collaboration diagram, MUST have its corresponding class in the
class diagram

131
• Example: - Modelling a sequence diagram for the log-in use case from the on-line
Bookstore Case Study.
– The main-flow of events that are involved is: -
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The
CUSTOMER clicks the OK button.
4. The system validates the log-in information against the ACCOUNT
table in the database.
5. CUSTOMER is an authorised user; the system displays the Personal
Home Page to the CUSTOMER

132
– Actors: Customer
– Messages and Objects
1. The CUSTOMER clicks the Log-in button on the Home Page.
2. The system displays the Log-in Page.
3. The CUSTOMER enters his/her user ID and password. The
CUSTOMER clicks the OK button.
5. The system validates the log-in information against the
ACCOUNT table in the database.
6. CUSTOMER is an authorised user; the system displays the
Personal Home Page to the CUSTOMER

133
 :Customer :HomePage :Account
:LoginPage

The Customer clicks

clickLogin( )
the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK clickOK( )
validateLogin(userID,
button.
The system password)
validates the login
information against login OK
the persistent
Account data … display( )

… and then returns

the Customer to the Sequence Diagram
Home Page.
134
• Boundary objects
– is an object with which an actor associated with a use case interacts.
• if the actor is human, the boundary object may be a window, screen,
dialog box, or menu
• if the actor is non-human, the boundary object may be application
program interfaces (APIs)

boundary object

135
• Entity objects
– is an object that contains long-lived information, such as that associated with
databases.
• will be mapped to a table (part of the database) in the design phase
– It can also contain transient objects, i.e. contents of lists in windows, or search
results.

entity object

148
• Control objects
– is an object that embodies application logic
– correspond with system actions (not actions taken by actors)
• are often used to handle things such as coordination and sequencing
• are also useful for calculations involving multiple entity objects
– will be mapped to codes during implementation phase
– used as a connecting tissue between boundary objects and entity objects.

control object

137
• Using the previous example (the log-in use case of the Online
Bookstore), we can identify that
– the HomePage and Log-in Page objects are boundary objects,
– whereas the Account object is an entity object.
• Therefore, taking this into account, we can draw a new interaction
diagram.

138
 :LoginPag
:Customer :HomePage e :Account

The Customer clicks

clickLogin( )
the Login button on
the Home Page display( )
The system displays
the Login Page

The Customer enters

enter userID
his or her user ID and password
and password, and
then clicks the OK
clickOK( )
validateLogin(userID,
button.
The system validates password)
the login information login OK
against the persistent
Account data …
display( )
… and then returns the

Customer to the Home

Page.
Sequence Diagram
139
• Use Case: Register
– Main flow of events:
1. The CUSTOMER clicks the REGISTER button on the Home Page.
2. The system displays the Register Page.
3. The CUSTOMER enters all of the required information.
4. The CUSTOMER clicks the SEND button.
5. The system checks that all of the required information were entered. If
yes, the system update the CUSTOMER’s record in the CUSTOMER
and ACCOUNT tables in the database. System displays OK message.
– Objects:-
• CUSTOMER: actor
• CUSTOMER and ACCOUNT: entity objects
• Home Page and Register Page: boundary objects

142
• Case Study: Order Books
– Main Flow of events: -
1. The CUSTOMER enters the keyword for a book and clicks the
SEARCH button on the personal Home Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER chooses the desired book and clicks the ADD TO
SHOPPING CART button on the web page.
4. The system adds the book into the CUSTOMER’s Order table in the
database.
– Objects:
• Customer: actor
• Home Page: boundary object
• Book and Order: entity object

160
161
 • Use case: Sell used books
– Main flow of events: -
1. The CUSTOMER clicks the Sell Used Books button on the Home Page.
2. The system displays the sell used books web page.
3. The CUSTOMER enters the required information on the used books that he/she wants
to sell.
4. The CUSTOMER clicks the SEND button on the webpage.
5. The system displays a confirmation page listing the information that
the CUSTOMER has entered.
6. The CUSTOMER checks that the information displayed are accurate. If yes, the
CUSTOMER clicks the OK button on the web page.
7. The system updates the USED BOOKS table in the database.
– Objects:
• Home Page, Used Books Page and Confirmation Page: boundary objects
• Customer and Used Books: entity objects

162
• Use case: Review
– Main flow of events: -
1. The CUSTOMER enters the keyword to search for a book and then
clicks the SEARCH button on the Personal Web Page.
2. The system displays the matching books on the web Page.
3. The CUSTOMER checks for the desired book and clicks on the
chosen book icon.
4. The system displays the book’s detail in the Book Detail web page.
5. The CUSTOMER clicks the REVIEW button on the web page.
6. The system displays the Review Book web page.
7. The CUSTOMER clicks on the desired star button and the click the
OK button on the web page.
8. The system calculates the overall rating of the book and updates the
Book table in the database.
9. The system displays the Book Detail web pages that have been
updated.
– Objects?
– Diagram?
 Activity Diagram
•Activity diagrams describe the workflow behavior of a system.
•They are typically used for business process modeling, for modeling the logic
captured by a single use case or usage scenario, or for modeling the detailed logic
of a business rule.
•UML activity diagrams could potentially model the internal logic of a complex
operation.
•In many ways UML activity diagrams are the object-oriented equivalent of flow
charts.
•Activity diagrams do not give detail about how objects behave or how objects
collaborate.
•Diagrams are read from top to bottom and have branches and forks to describe
conditions and parallel activities.
•A fork is used when multiple activities are occurring at the same time.
•Activity diagrams show the sequence of activities in a process, including
sequential and parallel activities.
•Symbols are used for activities, decisions and so on.
•Arrows represent events that connect the activities.
 Cont…

• The diagram above shows a fork after activity1.

• This indicates that both activity2 and activity3
are occurring at the same time.
• After activity2 there is a branch. The branch
describes what activities will take place based
on a set of conditions.
 Cont…

• All branches at some point are followed by a

merge to indicate the end of the conditional
behavior started by that branch.
• After the merge all of the parallel activities must
be combined by a join before transitioning into
the final activity state.
Activity Diagram Symbols
 Example to illustrate the activity of
performing selling an item to a customer.
 Creating Activity
Diagrams

• Ask what happens first, second, and so

on.
• Determine if the activities happen in
sequence or parallel.
• Examine all the scenarios for a use case.
 More on Activity Diagrams
– An activity diagram is like a state diagram.
• Except most transitions are caused by internal
events, such as the completion of a computation.
– An activity diagram
• Can be used to understand the flow of work that
an object or component performs.
• Can also be used to visualize the interrelation and
interaction between different use cases.
• Is most often associated with several classes.
• One of the strengths of activity diagrams is the
representation of concurrent activities.
Activity diagrams – an example
Activity diagrams – an example with swimlanes
 Read
• Other diagrams (will be covered in their
respective chapters)
– State machine
– Component
– Deployment
 Read
• Component
• A component notation is used to represent a part of the
system. It is denoted in UML like given below,
 Read
• Node
• A node is used to describe the physical part of a system. A node can be used to
represent a network, server, routers, etc. Its notation is given below.
 Read
• Deployment diagram
• It represents the physical hardware on which system is installed. A
deployment diagram represents the physical view of a system. It
denotes the communication and interaction between various parts of the
system.
• A deployment diagram consists of the following notations:
1. A node
2. A component
3. An artifact
4. An interface
 Read
• State machine:
• It used to describe various states of a single component throughout the
software development life cycle. It is used to capture different states of
a system component.
 Activity diagram:
◼ An activity diagram is used to represent various
activities carried out by different components of a
system. It is denoted the same as that of the
state machine diagram.
◼ Activity diagram mainly contains initial state, final
state, a decision box, and an action notation.
 Interaction diagram:
◼ Interaction diagrams are used to visualize the
message flow between various components of a
system.
◼ Sequence diagram: A sequence diagram shows
interactions between one or more lifelines within real
time. The notation of a sequence diagram is given
below,
 Case Study: Automated Teller
Machine (ATM) System
◼ Banks provide Automated Teller Machines (ATMs) to allow
customers to perform financial transactions without visiting a bank
branch. ATMs are connected to a Bank Server, which verifies user
authentication, processes transactions, and updates records in real
time. The system involves four main actors: Customer, ATM
Machine, Bank Server, and Bank Administrator. A Customer
inserts their card, enters a PIN for authentication, and can then
perform various transactions, such as checking balance,
withdrawing cash, depositing money, fund transfers, and
printing a mini-statement. The Bank Server validates requests,
ensuring sufficient funds for withdrawals or successful deposits and
transfers. A Bank Administrator is responsible for ATM
maintenance, including refilling cash, diagnosing system errors, and
restarting the ATM when necessary. If authentication fails after three
incorrect PIN attempts, the card is blocked. The ATM communicates
seamlessly with the Bank Server to ensure secure and efficient
banking operations.
 Student Task
◼ Based on this case study, students should:
1. Identify the actors and use cases involved in the
ATM system.
2. Draw the following UML diagrams to model the ATM
system:
◼ Use Case Diagram (showing actors and interactions)
◼ Activity Diagram (e.g., for Cash Withdrawal)
◼ Sequence Diagram (e.g., for Fund Transfer)
◼ Class Diagram (showing system components and relationships)
◼ Object Diagram (instances of system components)
◼ State Diagram (ATM states like Idle, Processing, Dispensing
Cash)
3. Write a Java implementation for one of the ATM
functionalities (e.g., cash withdrawal or balance
inquiry).
….. Then

THANKS
 quiz
◼ Amazon is an online shopping platform where
customers can browse products, add items to
their cart, and place orders. Once an order is
placed, Amazon processes the payment and ships
the product to the customer’s address. Customers
can also track their orders and leave reviews for
purchased items.
1. Identify Use Cases:
List at least five major use cases involved in the
Amazon online shopping process.
2. Identify Classes:
Identify and list at least four potential classes
involved in this system.
 quiz
◼ Questions:
1. Identify Use Cases:
List at least five major use cases involved in the Amazon online shopping
process.
2. Identify Classes:
Identify and list at least four potential classes involved in this system.
3. Identify Objects:
From the classes identified above, provide two possible objects for each class.
4. Draw a Use Case Diagram:
Using the identified use cases, draw a use case diagram showing the
interactions between actors and the use cases.
5. Draw a Class Diagram:
Using the identified classes, draw a class diagram. Include attributes,
methods, and relationships between the classes (like association, aggregation,
or inheritance).
6. Draw an Object Diagram:
Choose any two classes and draw an object diagram that shows real-world
instances (objects) and their relationships.
 Some solution
◼ . Identify Use Cases:
Here are at least five major use cases for the Amazon online shopping
platform:
• Browse Products: Customers search and view available products.
• Add to Cart: Customers select products and add them to their virtual
shopping cart.
• Place Order: Customers confirm their cart and initiate the purchase
process.
• Process Payment: Amazon handles customer payment through
different methods (credit card, PayPal, etc.).
• Ship Product: Amazon ships the purchased product to the
customer’s provided address.
• Track Order: Customers monitor the status and delivery progress of
their orders.
• Leave Review: Customers provide feedback and rate purchased
products.
 solution

Identify Classes:
Here are at least four potential classes involved in the system:
•Customer: Represents the user who buys products.
•Attributes: customer_id, name, email, address
•Methods: register(), login(), placeOrder(), trackOrder(), leaveReview()
•Product: Represents items available for purchase.
•Attributes: product_id, name, description, price, stock_quantity
•Methods: getDetails(), updateStock(), addReview()
•Order: Represents a customer’s purchase transaction.
•Attributes: order_id, order_date, status, total_amount
•Methods: createOrder(), cancelOrder(), trackOrder()
•Payment: Handles the payment process for orders.
•Attributes: payment_id, payment_method, amount, payment_status
•Methods: processPayment(), confirmPayment()
 Solution

•ShoppingCart: Represents the customer’s temporary selection of

products.
•Attributes: cart_id, customer_id, products[], total_price
•Methods: addProduct(), removeProduct(), updateQuantity(),
calculateTotal()
•Review: Captures customer feedback on purchased products.
•Attributes: review_id, product_id, customer_id, rating, comment,
review_date
•Methods: submitReview(), editReview(), deleteReview()
 Solutin
•Shipment: Manages the shipping of products to customers.
•Attributes: shipment_id, order_id, tracking_number, carrier, shipment_status,
delivery_date
•Methods: updateShipmentStatus(), trackShipment()
•Admin: Represents system administrators managing the platform.
•Attributes: admin_id, name, email, role
•Methods: manageProducts(), manageOrders(), viewReports(), resolveIssues()
•Category: Organizes products into different groups.
•Attributes: category_id, category_name, description
•Methods: addCategory(), updateCategory(), deleteCategory()
•Address: Stores customer shipping and billing addresses.
•Attributes: address_id, customer_id, street, city, state, postal_code, country
•Methods: addAddress(), updateAddress(), deleteAddress()
•Notification: Manages alerts and updates for customers.
•Attributes: notification_id, customer_id, message, status, timestamp
•Methods: sendNotification(), markAsRead()