Module I

Object-Oriented Analysis and Design (OOAD) is a methodology for analyzing, designing, and
developing software systems using objects as the fundamental building blocks. It focuses on
modeling real-world entities and their interactions in a structured, reusable, and maintainable
way.

1. Object-Oriented Analysis (OOA)

Goal: Understand what the system should do.

Key Activities

 Identify objects from the problem domain

 Define classes, attributes, and behaviors

 Understand relationships between objects

 Capture functional requirements as use cases

Key Concepts

 Object: Real-world entity (e.g., Customer, Order)

 Class: Blueprint of objects

 Attributes: Properties of a class

 Methods: Actions a class can perform

Comparison between algorithmic decomposition and object oriented decomposition

Algorithmic Decomposition

Divides system into smaller functions or modules that perform a specific task

Emphasizes on the functions that operate on the

Functions can be independent or dependent on each other

A program that calculates the sum of two numbers by calling a function

Object-Oriented Design Decomposition

Divides system into objects that represent entities or concepts with properties and
behaviors .

Emphasizes on the objects that hold the data and their behavior

s
 Objects that contain data and their associated methods

Objects can be dependent on each other through inheritance or composition

A program that represents a bank account object with methods like deposit, withdraw,
and check balance

Object-Oriented System Development Life Cycle (Use-Case Driven)

The Object-Oriented System Development Life Cycle (OOSDLC) is an approach to

software development where the entire process is driven by use cases.
Use cases describe how users interact with the system and guide analysis, design,
implementation, and testing.

A Use Case Driven Approach in OOAD (Object-Oriented Analysis & Design) centers
development around Use Cases, which are user-centric descriptions (scenarios) of
how Actors (users/external systems) interact with the system to achieve a goal, forming
the blueprint for requirements, design, and testing, ensuring the system built matches real
user needs

Phases of Use-Case Driven OOSDLC

1. Requirements Analysis (Use Case Modeling)

Goal: Understand what the system must do.

Activities:

 Identify actors (users or external systems)

 Identify use cases

 Write use case descriptions

 Create Use Case Diagram

Example Use Cases:

 Login

 Place Order

 Make Payment

s
2. Object-Oriented Analysis (OOA)

Goal: Analyze the problem domain using objects.

Activities:

 Identify analysis classes from use cases

 Define attributes and responsibilities

 Model interactions using sequence diagrams

 Create conceptual class diagrams

3. Object-Oriented Design (OOD)

Goal: Define how the system will be built.

Activities:

 Refine classes with methods and data types

 Apply design patterns

 Define interfaces

 Design system architecture

4. Implementation (Object-Oriented Programming)

Goal: Convert design into code.

Activities:

 Implement classes and methods

 Follow design models

 Integrate components

5. Testing (Use-Case Based Testing)

Goal: Verify system functionality.

Activities:

 Create test cases from use cases

s
  Unit testing of classes

 Integration testing

 System testing

6. Deployment & Maintenance

Goal: Deliver and improve the system.

Activities:

 Deploy system

 Fix defects

 Enhance features by adding new use cases

Advantages of Use-Case Driven OOSDLC

 Clear focus on user requirements

 Better communication with stakeholders

 Traceability from requirements to code

 Easier testing and maintenance

 Supports iterative and incremental development

Example (ATM System)

Actor:Customer
Use Cases: Withdraw Cash, Check Balance

 Withdraw Cash → sequence diagram → classes (Account, ATM, BankServer)

 Same use case used for design, coding, and testing

s
Module II

Unified Approach (UA) in Object-Oriented Analysis and Design

The Unified Approach (UA) is an object-oriented software development methodology

proposed-by-AliBahrami.
It integrates Object-Oriented Analysis (OOA), Object-Oriented Design (OOD), and Object-
Oriented Programming (OOP) using UML and a use-case driven process.

The Unified Approach is an object-oriented methodology that combines analysis, design,

and implementation using use cases, UML modeling, and iterative development.

Objectives of the Unified Approach

 Capture user requirements clearly

 Model real-world problems using objects
 Provide a smooth transition from analysis to design
 Improve software quality and maintainability
 Support reuse and scalability

Key Features of the Unified Approach

 Use-case driven
 Object-oriented
 Architecture-centric
 Iterative and incremental
 Uses UML as the modeling language

Phases of the Unified Approach

.1 Object-Oriented Analysis (OOA)

2 Object-Oriented Design (OOD)

3 Object-Oriented Programming (OOP)

4 Testing

5 Deployment and Maintenance

s
Concepts of UML

UML (Unified Modeling Language) is a standardized visual modeling language used in

object-oriented software development.
It allows developers to specify, visualize, construct, and document the structure and behavior
of a system.

 Standardized by the Object Management Group (OMG)

 Not a programming language but a modeling language
 Can be used with any object-oriented methodology

Objectives of UML

 Visualize system design

 Understand complex systems
 Communicate ideas among stakeholders
 Document system structure and behavior
 Serve as a blueprint for coding and testing

Why UML is Needed

 Large systems are complex

 Code alone is insufficient for communication
 Provides a standard visual representation
 Bridges the gap between requirements, design, and implementation

UML (Unified Modeling Language) is a standard visual modeling language used in OOAD.
It provides diagrams to represent systems from different perspectives:

UML Diagrams

1. UML Static Diagrams

Static diagrams show the structure of the system — the objects, classes, and relationships.
They don’t show behavior over time.

Types of Static Diagrams

1. Class Diagram – Shows classes, attributes, methods, and relationships.

o Example: Customer, Order, Product classes with ―places‖ or ―contains‖
relationships.
2. Object Diagram – Snapshot of objects (instances of classes) at a point in time.
o Example: John (Customer) → Order #101 → Product: Laptop.
3. Component Diagram – Shows software components and their dependencies.

s
 o Example: UI → Payment Service → Inventory Service.
4. Deployment Diagram – Shows hardware nodes and software deployed on them.
o Example: Web Server runs OnlineStoreApp connected to Database Server.
5. Package Diagram – Organizes classes into packages and shows dependencies.
o Example: UserModule → OrderModule → PaymentModule.

Key Point: Focus on structure, not actions.

2. UML Dynamic Diagrams

Dynamic diagrams show behavior, interactions, and changes over time. They are used to
model how the system works.

Types of Dynamic Diagrams

1. Use Case Diagram – Shows actors and the system functions they interact with.
o Example: Customer → Place Order, Make Payment.
2. Sequence Diagram – Shows interactions between objects over time.
o Example: Customer → System: selectProduct() → addToCart() → checkout() →
processPayment().
3. Activity Diagram – Shows workflow or process logic, including decisions and parallel
activities.
o Example: Start → Select Product → Add to Cart → Checkout → Payment →
End.
4. State Machine Diagram – Shows states of an object and transitions caused by events.
o Example: Order: New → Processing → Shipped → Delivered → Closed.
5. Communication Diagram – Similar to sequence diagrams but emphasizes object
relationships and message flow.
6. Timing Diagram – Shows object states and messages over precise time intervals.

Key Point: Focus on behavior, interactions, and time-based changes.

Class Diagram in Object-Oriented Concepts

A Class Diagram is a UML (Unified Modeling Language) diagram that shows the structure
of a system by modeling:

Structure of a Class Diagram

Each class is drawn as a rectangle divided into three parts: Class Diagram in Object-
Oriented Concepts

A Class Diagram is a UML (Unified Modeling Language) diagram that shows the structure
of a system by modeling:

s
  Classes
 Attributes
 Methods
 Relationships between classes

It represents the static view of an object-oriented system.

Structure of a Class Diagram

Each class is drawn as a rectangle divided into three parts:

-------------------
| Class Name |
-------------------
| Attributes |
-------------------
| Methods |
-------------------

Example

-------------------------
| Student |
-------------------------
| - rollNo : int |
| - name : String |
-------------------------
| + display() : void |
-------------------------

2. Class Members Visibility Symbols

Symbol Meaning
+ Public
- Private
# Protected
~ Package / Default

3. Relationships in Class Diagram

1. Association

Represents a general relationship between classes.

s
Example: Teacher teaches Student

Teacher -------- Student

2. Aggregation (HAS-A, weak relationship)

One class contains another, but both can exist independently.

Symbol: Hollow diamond (◇)

Example: Department ◇── Professor

3. Composition (HAS-A, strong relationship)

Contained object cannot exist without the container.

Symbol: Filled diamond (◆)

Example: House ◆── Room

4. Inheritance (IS-A relationship)

One class inherits another.

Symbol: Hollow arrow (▷)

Example:

Person ◁── Student

5. Dependency

One class depends on another temporarily.

Symbol: Dashed arrow

Example: Order → Payment

4. Multiplicity

Shows how many objects participate in a relationship.

Multiplicity Meaning
1 Exactly one

s
Multiplicity Meaning
0..1 Zero or one
1..* One or more
* Many

Example:
One teacher teaches many students:

Teacher 1 ------ * Student

5. Example: Library Management System

------------------ -----------------
| Library |◇------| Book |
------------------ -----------------
| name | | bookId |
------------------ | title |
| addBook() | | issueBook() |
------------------ -----------------

Member 1 ------ * Book

6. Benefits of Class Diagrams

 Clear system structure

 Better communication among developers
 Easy maintenance and scalability
 Acts as a blueprint for coding

An Object Diagram in UML is a snapshot of the system at a specific point in time, showing
objects (instances of classes) and their relationships.

 While a Class Diagram shows the static structure of classes and relationships,
 An Object Diagram shows actual instances (objects) and their links.

Purpose:

 To illustrate examples of data at runtime.

 To verify class diagrams by showing how instances interact.
 Useful in design and testing to understand real scenarios.

s
Key Components

Object

o Represents an instance of a class.

o Notation: Rectangle with object name underlined.
o Format: objectName : ClassName
o Example:
o john : Customer
o order101 : Order

Links

o Represents a relationship between objects (like association in class diagram).

o Notation: Solid line connecting objects.

Attribute Values

o Can show current values of object attributes.

o Example:
o john : Customer
o - customerID = 1
o - name = "John Doe"

UML Class Diagram (Online Shopping System)

+---------------------------+
| Customer |
|---------------------------|
| - customerID: int |
| - name: String |
| - email: String |
|---------------------------|
| + placeOrder() |
+---------------------------+
|
places
|
+---------------------------+
| Order |
|---------------------------|
| - orderID: int |
| - date: Date |
| - status: String |
|---------------------------|
| + calculateTotal() |
+---------------------------+
|

s
 contains
◇
+---------------------------+
| Product |
|---------------------------|
| - productID: int |
| - name: String |
| - price: float |
+---------------------------+

Note: The diamond (◇) represents aggregation (Order contains Products).

UML Object Diagram

+---------------------------+
| john : Customer |
|---------------------------|
| customerID = 101 |
| name = "John Doe" |
| email = "john@[Link]"|
+---------------------------+
|
places
|
+---------------------------+
| order1 : Order |
|---------------------------|
| orderID = 5001 |
| date = "2025-12-17" |
| status = "Processing" |
+---------------------------+
|
contains
|
+---------------------------+
| laptop : Product |
|---------------------------|
| productID = 301 |
| name = "Laptop" |
| price = $1200 |
+---------------------------+

s
Use Case Diagram

 Definition: A UML diagram that represents the functional requirements of a system.

 Focus: What the system does from a user’s perspective.
 Purpose:
o Capture system functionality.
o Show interactions between actors and the system.
o Useful in the analysis phase of OOAD.

Key Components

1. Actor
o A user or system interacting with your system.
o Notation: Stick figure.
o Example: Customer, Admin, Payment Gateway.
2. Use Case
o A function or process the system performs.
o Notation: Ellipse (oval).
o Example: Browse Products, Place Order, Make Payment.
3. System Boundary
o A rectangle that encapsulates use cases, representing the system.
4. Relationships
o Association: Solid line connecting actor to use case.
o Include: Use case includes another use case (mandatory).
o Extend: Optional behavior extending a use case.
o Generalization: Actor or use case inheritance.

Example: Online Shopping System Use Case Diagram

Actors:

 Customer
 Admin

Use Cases:

 Browse Products
 Place Order
 Make Payment
 Update Inventory (Admin)

s
UML Use Case Diagram, relationships define how actors and use cases interact, and how use
cases relate to each other. Let’s go through them in detail.

1. Association
 Definition: Shows interaction between an actor and a use case.
 Notation: Solid line connecting actor and use case.
 Example:

Customer ——> Place Order

Admin ——> Update Inventory

 Meaning: The Customer participates in ―Place Order‖; Admin participates in ―Update

Inventory‖.

2. Include
 Definition: A mandatory relationship where one use case always includes the
behavior of another.
 Notation: Dashed arrow with the label <<include>> pointing from the base use case to
the included use case.
 Example:

Place Order <<include>> Make Payment

 Meaning: Every time ―Place Order‖ happens, ―Make Payment‖ is also performed.

3. Extend
 Definition: An optional relationship where a use case adds behavior to another under
certain conditions.
 Notation: Dashed arrow with the label <<extend>> pointing from the extending use case
to the base use case.
 Example:

Place Order <<extend>> Apply Discount

 Meaning: ―Apply Discount‖ happens only sometimes, depending on conditions like

promo codes.

4. Generalization (Inheritance)
 Definition: Represents inheritance between actors or use cases.
 Notation: Solid line with a hollow arrow pointing to the parent actor or parent use case.
 Example (Actor):

s
Registered Customer ——|> Customer

 Meaning: ―Registered Customer‖ inherits all interactions of ―Customer‖.

 Example (Use Case):

Premium Checkout ——|> Checkout

 Meaning: ―Premium Checkout‖ is a specialized version of ―Checkout‖.

s
Use case diagram library management system

s
Module III

UML Interaction Diagrams

Interaction diagrams describe dynamic behavior of a system by showing how objects
communicate to accomplish a task (use case).

The two main interaction diagrams are:

1. Sequence Diagram
2. Collaboration (Communication) Diagram

The sequence diagram captures the time sequence of the message flow from one object to another and the
collaboration diagram describes the organization of objects in a system taking part in the message flow.

1. Sequence Diagram

Definition

A Sequence Diagram shows object interactions arranged in time sequence. It emphasizes the
order in which messages are exchanged between objects.

Main Elements

1. Actor/Object
o Placed at the top
o Format: objectName:ClassName
2. Lifeline
o Vertical dashed line
o Represents object existence over time
3. Message
o Horizontal arrow
o Represents method calls
4. Activation Bar
o Thin rectangle
o Shows object is active
o
5. Return Message (optional)
o Dashed arrow
o Shows returned result

s
Advantages of Sequence Diagrams

1. Easy to understand
Sequence diagrams are simple and intuitive because interactions are shown in time order
(top to bottom).
2. Clear visualization of message flow
They clearly show how messages are exchanged between objects during execution.
3. Emphasizes time sequence
The exact order of operations is visible, which helps in understanding system behavior.
4. Useful for modeling use cases
They effectively represent the flow of events in a use case scenario.
5. Helps identify methods and responsibilities
Messages in the diagram often correspond to methods in classes, aiding class design.
6. Improves communication among developers
Designers, developers, and testers can easily understand system interactions.
7. Supports debugging and validation
Helps detect missing interactions or incorrect sequence of operations.
8. Good for documentation
Provides clear documentation of dynamic behavior of the system.

Limitations

 Can become complex for large systems

 Does not show object relationships clearly

s
2. Collaboration Diagram
(Also called Communication Diagram)

Definition

A Collaboration Diagram shows how objects collaborate by emphasizing object

relationships and message flow, rather than time.

Purpose

 Show structural organization

 Identify object links
 Understand responsibility distribution

Main Elements

1. Objects
o Represented as boxes
2. Links
o Lines connecting objects
3. Messages
o Labeled arrows on links
4. Sequence Numbers
o Show order of messages (1, 1.1, 2, etc.

Explanation

 Objects are connected based on communication

 Numbers indicate message order
 Focus is on collaboration, not time flow

Advantages

 Compact representation
 Shows object relationships clearly
 Useful for understanding system structure

Limitations

 Less intuitive than sequence diagrams

s
  Message numbering can become complex

Activity Diagram

Activity Diagrams in UML (Unified Modeling Language) are used to model the flow of
activities or actions in a system. They’re especially useful for showing business processes,
workflows, and the logic of operations step by step.

Activity Diagram Shows

 The sequence of actions

 Decisions and branching paths
 Parallel activities (things happening at the same time)
 Start and end points of a process

Think of it as a flowchart, but with UML standards.

Main Components of an Activity Diagram

1. Initial Node

 Solid black circle

 Marks the start of the activity

2. Activity / Action

 Rounded rectangle
 Represents a task or operation
Example: Enter login details

3. Control Flow

 Arrow
 Shows the flow from one activity to another

4. Decision Node

 Diamond shape
 Used for if/else conditions
Example: Is password correct?

5. Merge Node

s
  Diamond
 Combines multiple paths back into one

6. Fork Node

 Thick horizontal or vertical bar

 Splits flow into parallel activities

7. Join Node

 Thick bar
 Synchronizes parallel activities back into one flow

8. Final Node

 Bullseye (circle with a dot inside)

 Marks the end of the activity

s
s
A State Chart Diagram (also known as a State Machine Diagram) is a behavioral diagram in
UML that represents the states of an object and the transitions between those states in response to
events. It is particularly useful for modeling the dynamic behavior of a system or an object over
time.

Key Components and Notations

1. Initial State: Represented by a black filled circle, it indicates the starting point of the state
machine.
2. State: Represented by a rounded rectangle, it shows the condition of an object at a specific
time.
3. Transition: Represented by a solid arrow, it indicates the change from one state to another,
triggered by an event.
4. Final State: Represented by a filled circle within a circle, it marks the end of the state
machine.
5. Fork and Join: Fork is represented by a solid rectangular bar splitting into multiple
concurrent states, while Join merges multiple states into one.
6. Self Transition: A solid arrow pointing back to the same state, indicating that the state does
not change on the occurrence of an event.

Drawing a State Machine Diagram

To draw a State Machine Diagram in UML, follow these steps:

1. Identify the System: Understand what the diagram is representing, whether it's a machine,
process, or object.
2. Identify Initial and Final States: Determine where the system starts and ends.
3. Identify Possible States: Think about all the different situations your system can be in.
4. Label Triggering Events: Identify the events that cause transitions between states.
5. Draw the Diagram: Use appropriate notations to represent states, transitions, initial and final
states.

s
 Module IV

An Implementation Diagram in UML is used to represent the physical aspects of a system,

focusing on how software components are deployed and interact with hardware or other
components. These diagrams are essential for understanding the deployment and organization of
system elements during implementation.

Types of Implementation Diagrams

1. Component Diagram
A Component Diagram illustrates the modular, deployable, and replaceable parts of a system. It
shows how components (e.g., executables, libraries, or databases) interact through interfaces.
These diagrams are often used to model implementation details and ensure that functional
requirements are met.
Example:
 Components like a web server, database, or API are represented as modular units.
 Interfaces are used to show how components communicate with each other.

Elements of a Component Diagram:

1. Components: Represent modular parts of the system, such as classes, subsystems, or
executables.
2. Interfaces: Define the operations a component provides (lollipop symbol) or requires (socket
symbol).
3. Ports: Represent interaction points on a component's boundary for provided or required
interfaces.
4. Relationships: Show dependencies, associations, or connections between components and
interfaces.
5. Artifacts: Represent physical files or data associated with components.
6. Nodes: Represent physical or virtual environments where components are deployed.

2. Deployment Diagram
A Deployment Diagram represents the physical deployment of software artifacts (e.g.,
executables, libraries) onto hardware nodes. It shows the relationship between software and
hardware, making it useful for distributed systems or systems with multiple configurations.
Key elements include:
 Nodes: Represent hardware or execution environments.

s
 Artifacts: Represent software components deployed on nodes.
 Connections: Show communication between nodes.
Example:
 A web application deployed on a server, with a database running on a separate machine.

Example: Deployment Diagram for Online Banking System

Nodes and Artifacts

1 Client Node

 Node: Customer PC / Mobile

 Artifact: Web Browser / Mobile App

2 Web Server

 Node: Web Server

 Artifact: Banking Web Application

3 Application Server

 Node: App Server

 Artifact: Business Logic (.jar)

4 Database Server

 Node: Database Server

 Artifact: Bank Database

s
 UML Meta Model
UML (Unified Modeling Language) metadata refers to the underlying structure and
information that defines the elements, relationships, and rules within UML models. It is a critical
aspect of UML's metamodeling approach, which organizes and standardizes how UML diagrams
are created and interpreted.

UML Metamodeling Hierarchy

UML follows a four-layer metamodeling hierarchy to define its structure:

1. M0 (Instance Layer): Represents real-world objects or instances.
2. M1 (Model Layer): Contains UML models, such as class diagrams or sequence diagrams,
which describe the system's structure and behavior.
3. M2 (Metamodel Layer): Defines the UML language itself, specifying the rules and
constructs (e.g., classes, associations) used to create UML models. UML's metamodel is
based on the MOF (Meta-Object Facility).
4. M3 (Meta-Metamodel Layer): Provides the foundation for defining metamodels, such as
MOF, which is used to define UML and other modeling languages.
The MOF (Meta-Object Facility) acts as the meta-metamodel for UML, ensuring consistency
and extensibility across different modeling languages.

Key Components of UML Metadata

 Infrastructure Library: This defines reusable metaclasses and is self-descriptive. It includes

the Core and Profiles packages, which are foundational for UML and other metamodels.
 Profiles: These extend UML metamodels for specific domains or platforms (e.g., J2EE,
.NET). Profiles are a restricted form of metamodels that adapt UML for specialized use cases.
 Superstructure: This defines the elements and relationships used in UML diagrams, such as
classes, objects, and interactions.

Main Elements of UML Meta model

1. Class
o Blueprint for objects
2. Attribute
o Data members of a class
3. Operation
o Methods/functions
4. Association
o Relationship between classes
5. Generalization
o Inheritance relationship
6. Package
o Groups related elements

s
Practical Applications
UML metadata enables the creation of standardized diagrams that visually represent system
designs. It supports various diagram types, including class diagrams, sequence diagrams, and use
case diagrams, which are essential for software development, system architecture, and
stakeholder communication.

Object Oriented Analysis Classification Theory

The classification theory in Object-Oriented Analysis (OOA) is a systematic approach to

categorizing entities or objects based on common characteristics. This theory is crucial for
identifying generalization, specialization, and aggregation hierarchies among classes.
Proper classification helps in modularization decisions, determining whether to place
classes and objects together in the same module or in different modules, and allocating
processes to procedures based on packaging, performance, or reliability concerns. The
theory emphasizes the dynamic behavior of the system and the importance of
understanding the system's behaviors before assigning them to parts of the system.

Key Concepts in Classification Theory

1Object

 A real-world entity
 Has identity, state, and behavior
 Example: A specific student (Rahul)

2Class

 A blueprint of objects
 Groups similar objects
 Example: Student

3Attributes

 Properties of a class
 Example: name, rollNo

4 Operations
s
  Behavior of a class
 Example: register(), payFees()

Types of Classification
1. Conceptual Classification

 Based on real-world concepts

 Example:
o Student
o Teacher
o Course

2. Specification Classification

 Based on rules and constraints

 Example:
o UndergraduateStudent
o PostgraduateStudent

3. Role-Based Classification

 Based on roles played by objects

 Example:
o Person → Student, Employee

Classification & Generalization

 Uses inheritance
 Subclasses inherit from superclasses

Example:

Person
|
Student
|
Postgraduate

Benefits of Classification Theory

 Reduces complexity
 Improves reusability
 Makes system easier to understand

s
  Helps in accurate class identification

Example (Library System)

 Objects: Book1, Book2
 Class: Book
 Attributes: title, author
 Operations: issue(), return()

Approaches for Identifying Classes (OOAD)

In Object-Oriented Analysis, identifying the right classes is a key step. There are several
commonly used approaches to do this.

1Noun Phrase Approach

 Identify nouns from the problem statement
 Nouns → Candidate classes
 Verbs → Methods

Example:

Statement:
―A student borrows a book from the library.‖

 Nouns: Student, Book, Library → Classes

 Verbs: borrows → Method

2Use-Case Based Approach

 Analyze use case diagrams

 Identify:
o Actors → Classes
o Use cases → Methods
o Data involved → Classes

Example:

Use case: Issue Book

 Classes: Student, Book, Librarian

s
3 CRC Card Approach
 CRC = Class – Responsibility – Collaboration
 Identify:
o Classes
o What they do (responsibilities)
o Who they interact with

Example:

Class: Book

 Responsibility: Maintain book details

 Collaborates with: Student, Library

4 Common Class Patterns

 Reuse known class types:

o User
o Transaction
o Device
o Document

Example:

ATM System:

 User
 Account
 Transaction
 ATM

5Domain Knowledge Approach

 Use expert knowledge of the problem domain

 Identify standard domain classes

Example:

Hospital System:

 Patient
 Doctor

s
  Appointment
 Prescription

6 Event-Based Approach
 Identify classes based on events in the system
 Each event suggests related objects

Example:

Event: Place Order

Object-Oriented Design (OOD) Process

The Object-Oriented Design process converts the analysis model into a design model that can
be directly implemented using OOP languages.

Steps in Object-Oriented Design Process

1 Define System Architecture

 Identify subsystems / layers

 Decide overall structure (e.g., UI, Business Logic, Database)

Example:
Presentation Layer → Application Layer → Data Layer

2 Identify Design Classes

 Refine analysis classes

 Add:
o Boundary classes (UI)
o Control classes (logic)
o Entity classes (data)

3 Define Class Attributes & Methods

 Specify:
o Data members
o Operations
o Visibility (public, private)

s
4 Identify Relationships

 Association
 Aggregation
 Composition
 Generalization (inheritance)

5 Design Interactions

 Create sequence diagrams

 Show object communication and message flow

6 Apply Design Principles

 Encapsulation
 Abstraction
 Modularity
 Low coupling, high cohesion

7 Design Interfaces

 Define interfaces for classes/subsystems

 Helps in loose coupling

8 Persistence Design

 Decide how objects are stored

 Map classes to database tables

9Packaging & Deployment

 Group classes into packages

 Create deployment diagrams

s
 Simple Flow
Requirements
↓
Object-Oriented Analysis
↓
Object-Oriented Design
↓
Implementation
↓
Testing

Design Axioms and Corollaries (Object-Oriented Design)

In Object-Oriented Design (OOD), design axioms are fundamental rules that guide good
design.
Corollaries are supporting guidelines derived from these axioms.

Design Axioms
Axiom 1: Independence Axiom

Maintain independence of components

Each class should have one responsibility

Changes in one class should not affect others

Goal: Low coupling, high cohesion

Axiom 2: Information Axiom

Minimize information content

Choose the simplest design that works

Reduce unnecessary methods, attributes, and relationships

Design Corollaries
Corollaries help apply axioms in practice.

s
1. Uncoupled Design

 Classes should be independent

 Avoid tight dependencies

2. Single Responsibility Principle

 One class → one purpose

3. Use Encapsulation

 Hide internal data

 Access through methods

4. Keep Interfaces Simple

 Fewer methods
 Clear responsibilities

5. Low Coupling, High Cohesion

 Minimize inter-class dependencies

 Maximize related functionality in a class

6. Avoid Redundancy

 Do not duplicate code or data

7. Design for Change

 Use abstraction and inheritance

 Makes system flexible

8. Reuse Design Patterns

 Apply proven solutions

s
Example: UML Class Diagram for Library Management
System
Classes and Details

1Book

 bookId
 title
 author
 issueBook()
 returnBook()

2Student

 studentId
 name
 borrowBook()

3 Librarian

 empId
 name
 issueBook()

UML Class Diagram

+------------------+ issues +------------------+
| Student |-------------------->| Book |
+------------------+ +------------------+
| - studentId | | - bookId |
| - name | | - title |
+------------------+ | - author |
| + borrowBook() | +------------------+
+------------------+ | + issueBook() |
| + returnBook() |

s
 +------------------+

manages
+------------------+
| Librarian |
+------------------+
| - empId |
| - name |
+------------------+
| + issueBook() |
+------------------+

UML Notations Used

 + → Public
 − → Private
 Rectangle → Class
 Lines → Association