Unified Modeling Language

(UML)
UNIT 2
 History of UML
§ Developed to standardize and unify object-oriented modeling
notations.
§ Before UML: Different notations → complexity &
inconsistency.
§ Mid-1990s – Created by the 'Three Amigos': Grady Booch, Ivar
Jacobson, James Rumbaugh.
§ Part of Rational Software Corporation.
 Motivation
§ Problem: No standard in object-oriented modeling.
§ Issues: Miscommunication, incompatibility between models.
§ Goal: Integrate strengths of leading methods.
§ Create a single, standard, comprehensive modeling language.
 Booch Method
§ Creator: Grady Booch.
§ Focus: Design & construction of object-oriented systems.
§ Features: Modularity & encapsulation, static & dynamic
views.
§ Supports iterative & incremental development.
§ Example: Banking system with inheritance & polymorphism.
 Object Modeling Technique (OMT)
§ Creator: James Rumbaugh.
§ Focus: Analysis & design phases.
§ Models: Object Model, Dynamic Model, Functional Model.
§ Example: Inventory system with Product, Warehouse,
Supplier.
Object-Oriented Software Engineering
(OOSE)
§ Creator: Ivar Jacobson.
§ Focus: Use Cases – interaction between actors & system.
§ Advantages: User-driven approach, aligns with business goals.
§ Example: E-commerce – Place Order, Add to Cart, Make
Payment.
 Standardization of UML
§ Adopted by Object Management Group (OMG) in 1997.
§ Recognized as an ISO standard.
§ Ensures consistency across tools, platforms, methodologies.
 Introduction to UML
§ General-purpose visual modeling language for object-
oriented systems.
§ Key Characteristics: Standardized by OMG, not a
methodology, platform-independent.
§ Purpose: Visualization, Design, Documentation,
Communication.
 Example: Library System
§ Use Case Diagram: Roles (Member, Librarian).
§ Class Diagram: Book, Member, Loan.
§ Sequence Diagram: Borrow book process.
 Types of UML Diagrams
§ Two Categories:
§ 1. Structural Diagrams (Static aspects).
§ 2. Behavioral Diagrams (Dynamic aspects).
§ Total: 14 standard diagrams.
Aspect Structural Diagrams Behavioral Diagrams
Show the static structure of a Show the dynamic behavior of
Purpose system (how parts are a system (how parts interact
organized). and change over time).
Elements of the system: Interactions, activities, and
Focus classes, objects, components, state changes of objects and
relationships. components.
Static — does not change Dynamic — changes occur
Nature
during execution. during execution.
Understanding system Understanding workflows, use
Used For architecture, data structures, cases, and runtime
and dependencies. interactions.
Use Case Diagram, Sequence
Class Diagram, Object
Diagram, Activity Diagram,
Diagram, Component Diagram,
State Machine Diagram,
Examples Deployment Diagram, Package
Communication Diagram,
Diagram, Composite Structure
Interaction Overview Diagram,
Diagram, Profile Diagram.
Timing Diagram.
During analysis/design/testing
During design phase to define
When Used to model behavior and
the blueprint of the system.
interaction.
Like a building’s blueprint Like a video showing how
Analogy showing walls, rooms, and people move and interact
layout. inside the building.
 Structural Diagrams
Definition:
Structural diagrams in UML describe the static aspects of a system —
essentially, how the system is organized. They show elements, relationships,
and dependencies, but do not depict the changes or interactions over time.

Key Characteristics:
• Represent the architecture and blueprint of the system.
• Do not include the flow of execution or logic.
• Stable across the system’s lifecycle; changes less frequently than behavior.
• Show nouns in the system (e.g., objects, classes, components).

Purpose:
• Document system architecture for developers and stakeholders.
• Define data structures and how they relate.
• Provide a foundation for behavioral diagrams.
Common Structural Diagrams:
[Link] Diagram – Models classes, attributes, methods, and relationships.
Example: Banking system with Account, Customer, Transaction.
[Link] Diagram – Shows instances of classes at a particular moment.
Example: Snapshot of 3 customer objects linked to account objects.
[Link] Diagram – Models physical modules of code or components.
Example: Web module, database module, payment gateway.
[Link] Diagram – Shows the physical hardware and software
mapping.
Example: Web server, application server, database server layout.
[Link] Diagram – Groups elements into packages.
Example: UI, BusinessLogic, DataAccess.
[Link] Structure Diagram – Shows internal structure of a classifier.
Example: Details of how a class contains other parts.
[Link] Diagram – Used for customizing UML for specific domains.

Example:
Like an architectural blueprint of a building showing walls, doors, and wiring
— but not how people move inside.
 Behavioral Diagrams
• Definition:
Behavioral diagrams in UML describe the dynamic aspects of a
system — how the system behaves over time and how its parts
interact during execution.
• Key Characteristics:
• Represent the logic, flow, and interactions.
• Focus on verbs (actions, operations, activities).
• Often changes during execution depending on inputs and states.
• Can model user interactions, workflows, and state transitions.
• Purpose:
• Capture requirements and functionality.
• Model real-time system behavior.
• Aid in simulation, testing, and validating workflows.
• Common Behavioral Diagrams:
• Use Case Diagram – Shows system functionalities from a user
perspective.
Example: For an ATM — Withdraw Cash, Check Balance, Deposit.
• Sequence Diagram – Models message flow between objects over
time.
Example: Steps of placing an online order.
• Activity Diagram – Models workflow of activities and decision
points.
Example: Loan approval process.
• State Machine Diagram – Shows states and transitions of an object.
Example: Order states — Pending, Shipped, Delivered, Cancelled.
• Communication Diagram – Emphasizes message exchange
between objects.
Example: Chat application message passing.
• Interaction Overview Diagram – Combines activity diagram with
sequence diagrams.
Example: High-level e-commerce process.
• Timing Diagram – Shows changes in state or condition over time.
Example: Sensor readings in an IoT device.
 Class Diagram

• Definition:
A Class Diagram is the most common structural
diagram in UML. It shows:
• Classes in the system.
• Attributes & operations of classes.
• Relationships between classes.
• Purpose:
• Acts as a blueprint for system design.
• Used in both analysis (high-level view) and
design (detailed view).
 1. Class
• Definition:
A class is a blueprint for creating objects. It
represents a group of objects with common
attributes, operations, and relationships.
• Notation in UML:
• Drawn as a rectangle divided into three
compartments:
– Name (top compartment)
– Attributes (middle compartment)
– Operations (bottom compartment)
 1. Class

-----------------
Customer
-----------------
+customerID: int
+name: string
+email: string
-----------------
+register()
+placeOrder()
+updateProfile()
 2. Relationship
In UML structural modeling, relationships define how classes are
connected.
Main Types:
[Link] – A basic link between two classes showing they
interact.
Example: Customer — places —> Order.
[Link] – “Has-a” relationship where one class contains another
but both can exist independently.
Example: Department has Professor (Professor can exist without
Department).
[Link] – Stronger “has-a” relationship where one class cannot
exist without the other.
Example: House has Room (Room cannot exist without House).
[Link]/Inheritance – “Is-a” relationship where a subclass
inherits properties and behavior of a superclass.
Example: SavingsAccount is-a Account.
[Link] – A change in one class may affect another.
Example: Invoice depends on TaxCalculator.
Association — plain link between classes
Definition & semantics
• A basic connection showing two classes
“know about” or communicate with each
other.
• No ownership implied. It just says one class
has a reference to another (possibly
bidirectional).
UML notation
• Solid line between classes.
• Optional: a label (verb) and role names at
each end.
• Navigability: add an arrow on one end if
only one direction is traversable.
 Multiplicity

• Multiplicity tells how many objects of one

class can be associated with objects of
another class in an association.
• It’s placed near the class at each end of the
association line.
Symbol Meaning

1 Exactly one

0..1 Zero or one

* Zero or many

1..* One or many

2..4 Between two and four

• Customer (1) —places—> (0..*) Order
• Student (0..*) —enrolls in—> (0..*) Course
• Person (1) —has—> (1) Passport

• Ex. 1 Bank has an account

• 2. Teachers teaches to students
• 3. Student issues book from library
• 4. Student attempted a test
• 5. Country has a capital city
 Aggregation
• A specialized association that expresses a
whole–part relationship, but parts can exist
independently of the whole.

• UML notation
• Hollow (white) diamond at the whole
(aggregate) end:
Generalization
 Qualified Association

1. A qualified association in UML is a special kind of

association between two classes, where a qualifier (an
attribute) is used to uniquely identify a related object (or
set of objects).
2. Instead of linking one class directly to a collection of
objects in another, the qualifier acts like a key or index
that helps narrow down the association.
 Qualified Association
Example 1: Bank and Account

● A Customer may have multiple Accounts.

● To uniquely identify an account, we use account Number as the qualifier.

Example 2: Library and Books

● A Library has many Books.

● Instead of showing a “many” relationship, we qualify it with ISBN.

N-ary association

N-ary association in UML (Unified Modeling Language) represents

a relationship that involves three or more classifiers (typically
classes). Unlike a binary association, which connects two
classifiers, an N-ary association is used when a relationship
inherently links multiple entities in a way that cannot be accurately
or efficiently broken down into simpler binary associations without
losing crucial information.
N-ary Association in UML

● In UML, most associations are binary (between two classes).

● But sometimes, a relationship naturally involves more than two classes → that’s
an n-ary association.
● It’s shown as a diamond (rhombus) connected by lines to the participating classes.
● The diamond is labeled with the association name, and multiplicities can be shown
at each end.

Ex. Employee works on project given by company

Ex. Student has taken the course for a semester
Ex Customer has an account in a branch
 Package Diagram
A Package Diagram in the Unified Modeling Language (UML) is a
structural diagram used to visualize the organization and arrangement
of various model elements within a system.

It provides a high-level view of the system's architecture by grouping

related elements into "packages.

Purpose:
Package diagrams are primarily used to:
1. Organize and manage large, complex systems by grouping related
UML elements (classes, interfaces, components, other packages)
into logical units.
2. Illustrate the dependencies and relationships between these
packages, showing how different parts of a system interact or rely
on each other.
3. Represent the logical architecture of a system, such as a layered
application.
Package Diagram
Dependency → One package uses elements of another.

Import → One package imports all elements of another.

Access → One package allows controlled access to its elements.

Merge → Combines two packages into one.

Composite Structure Diagram

A Composite Structure Diagram is a UML structural diagram that

shows the internal structure of a classifier (like a class, component, or
collaboration) and how its parts interact to achieve some functionality.
It focuses on the runtime decomposition of a system into interconnected
parts.
Key Elements
1. Classifier

○ The main entity being described (e.g., a Class, Component, or Collaboration).

2. Parts

○ Instances of classes or roles that participate inside a classifier.

○ Shown as small rectangles inside the main classifier.

3. Ports

○ Interaction points for communication between a classifier and the external world or
between its parts.

○ Shown as a small square on the classifier boundary.

4. Connectors

○ Lines showing communication paths between parts or ports.

5. Collaboration

○ Defines how roles (parts) work together to perform a function.

Purpose of Composite Structure Diagram

● Shows the internal working of a complex classifier.

● Useful for component-based design and service-oriented

architectures.

● Explains how objects collaborate at runtime inside a system.

● Provides more detail than a class diagram, which only shows static
structure.