OBJECT ORIENTED SOFTWARE ENGINEERING

Software vs. Program

• A set of instructions written for a specific purpose, including comments for readability.
• Software includes one or more programs, documentation, and operating manuals.
• We write programs but develop software as a complete product.

Software Documentation
Essential for software projects to ensure usability and maintainability.
Key documents:
1. Requirements & Specification – Defines system needs.
2. Design Document – Describes architecture and design.
3. Test Plan & Test Suite – Covers testing strategy and cases.
4. Source Code – The actual program implementation.

Operating Procedure Manuals

Delivered with software to guide users and customers.
• Help users install, operate, and maintain software.
• Delivered with the software at release.
Key manuals

• Installation Manual – Guides software setup.

• System Administration Manual – Provides system management instructions.
• Beginner’s Guide Tutorial – Helps new users understand the software.
• System Overview – Gives a high-level description of the system.

Characteristics of Software
These are extras the more imp are given below

• Reliability – Must function correctly and consistently under various conditions.

• Efficiency – Should use system resources optimally for better performance.
• Maintainability – Must be easy to update, debug, and enhance over time.
• Portability – Can run on different hardware and software environments with minimal changes.
• Security – Must be protected against unauthorized access and threats.
Software Does Not Wear Out
• Software does not age like hardware; it does not wear out over time.
• Hardware failures occur due to aging parts, leading to malfunctions.
• Software remains functional unless modified or affected by external factors.
This is a hardware lifecycle figure .

• Burn-in Phase: Initially high failure rate due to detected faults; fixes reduce failure rate.
• Stabilization: After sufficient testing, failure rate stabilizes, and the product is released.
• Useful Life Phase: Failure rate remains constant; the product functions reliably.
• Wear-out Phase: Failure rate increases due to environmental effects and aging of hardware parts.

We do not have the wear-out phase in software.

Software improves over time through testing and fault correction, increasing reliability.
Software does not wear out but may become obsolete(mtlb ki lack the feature that others have) due to:
• Technological changes
• Evolving user expectations
• Poor response time
• Deteriorating code structure
• Increasing complexity

A stakeholder is a person who is having direct or indirect interest in the software system, including
customers, software developers, managers, users, testers and so on
Flexibility of Software
• Basically matlb hai ki , software is flexible par stakeholders misunderstand its limitations. They think
ki software mai kuch change karna is quite easy, n isse issue hota hai ki expectations badh jati hai
and theory failne lagti hai ki “any change possible at any time without much difficulty”

• Changing code is easy, but it can impact other parts of the software.
• Adding new features late can make development harder and reduce quality.
• Software changes are easier than hardware changes but require proper analysis to avoid issues.

Reusability of Software
Basically pre-made components (eg motherboard) ko apne new manufactured products mai use karna taaki
paisa n time bache n quality standards bhi maintained rahe.

Software Development
Reasons why not mostly used :
Most software projects are built for specific customers with unique requirements.
Reusability is rarely used, leading to higher costs and longer development time.
When used :
Reusability integrates well-tested components into new software, reducing development effort, cost, and
testing time.

Object-oriented software development (as such kaam ka nhi hai !!!)

• Object-oriented versions of existing software are emerging to meet modern challenges.
• Traditional software engineering approaches are considered outdated for handling complex
systems.
• The strength of object orientation lies in its ability to represent real-world situations using models,
improving visualization and understanding.
• Key building blocks of object-oriented programming (OOP) include objects, classes, messages,
interfaces, inheritance, and polymorphism.

Classes and Objects

• Objects are fundamental entities that model a system and contain data (attributes) and operations
(behavior). Examples of objects: Book, student, faculty, employee, etc.
• Class: A blueprint that groups objects with similar attributes and behaviors.
• Objects are instances of a class
• Example: A class ‘Book’ can have attributes like title, author, and publisher, and operations like
issue, return, renew, etc.
Classes and Objects
• A class represents a group of similar objects and has three parts:
1. Class name
2. Attributes (data/information)
3. Operations (behavior/actions)
• Access Specifiers (private, public, protected) control data visibility:
o Private: Only accessible within the class (supports data hiding).
o Public: Accessible by other classes.
o Protected: Accessible within the class and its derived classes.

An instance is a specific object created from a class.

The class defines its structure (data and behavior), while the instance's state changes based on the
operations performed on it.

Messages, Attributes, and Methods

• Messages:
o Objects communicate by passing messages, showing the dynamic behavior of a system.
o A message consists of the target object, operation to perform, and necessary data.
• Attributes:
o Attributes store the state of an object.
o Defined within a class n Usually private, accessible only within the class.
 • Methods:
o A method is a set of operations that perform specific tasks.
o Example: Book class methods include addBook(), deleteBook(), updateBook(), and
viewBook().
o Methods, functions, and operations sab same cheeze hai.

Encapsulation (Information Hiding)

• Encapsulation combines data and operations into a single unit, restricting direct access to data.
• Data is only accessible through specified operations (methods), ensuring security and preventing
accidental modifications.
It means that the internal representation of an object is generally hidden from view outside of the object’s
definition.
Example: In a Library Management System, all attributes in the Book class are private, and only class
methods (e.g., addBook()) can modify them.

5
Inheritance
• Inheritance allows a class to inherit attributes and operations from another class.
• Helps in reusing code and reducing redundancy in object-oriented systems.
• Helps in code organization, reusability, and maintainability.

Polymorphism
• Definition: "Polymorphism" means "many forms," where the same instruction can produce different
responses depending on the object.
• Example: If we say "come fast" to different mammals:
o Animals may run, birds may fly, and humans may walk or drive.

• Types of Polymorphism:
1. Function Overriding:
2. Operator Overloading: The same operator can behave differently based on context.
▪ Example: The + operator is used for addition in numbers but for string concatenation
in programming.
Abstraction
• Abstraction Concept:
o Abstraction means hiding irrelevant details and focusing on essential features.
o Example: We can drive a car without needing to understand the engine mechanics.
o Helps in managing complexity and improving understanding of a system.
• Key Takeaway:
o Using the right level of abstraction helps in solving complex problems efficiently.

Object Composition
• Using objects as data members in another class is called object composition.
• Concept: It represents a "has-a" relationship between classes.
• Example:
o Class B has-a member Oa of type class A (object of class A is a data member in class B).
• Difference from Inheritance:
o Object Composition → "Has-a" Relationship (e.g., a car has-a engine).
o Inheritance → "Is-a" Relationship (e.g., a car is-a vehicle).

Object-Oriented Methodologies
A methodology is a structured set of methods, principles, and techniques used to develop a system
systematically.
1. Object-Oriented Analysis (OOA) Coad and Yourdon
2. Object-Oriented Design (OOD) by Booch
3. Object Modelling Technique (OMT) by Rumbaugh et al
4. Object-Oriented Software Engineering (OOSE) by Jacobson et al
Coad and Yourdon Methodology (Object-Oriented Analysis - OOA)
Focuses on analyzing and modeling a system before development.
Five Key Steps of OOA:
1. Identification of Classes and Objects – Determine objects in the system based on the application
domain.
2. Identification of Structures – Establish relationships between objects, including:
o Is-a relationship (class inheritance).
o Whole-part relationship (object composition).
3. Definition of Subjects – Group related classes and objects into meaningful categories.
4. Definition of Attributes – Identify and define attributes (data members) for each class.
5. Definition of Services (Methods) – Identify object operations and define how objects communicate
through messages.

Limitations:
• No structured approach to identifying classes and objects.
• Does not clearly define interfaces between objects.
Booch Methodology (Object-Oriented Design - OOD)
Focuses on designing object-oriented systems by combining analysis, design, and implementation into an
iterative and incremental development process.
Two Main Processes:
1. Macro Process (High-Level Development Process)
This defines the overall development life cycle and consists of:
• Requirements Phase – Establishes system requirements using context diagrams and prototypes.
• Analysis Phase – Captures and understands requirements (focuses on “what” the system does).
• Design Phase – Develops system architecture by:
Identifying horizontal layers. Mapping classes to subsystems. Addressing risks from analysis.
• Evolutionary Phase – Implements the system in iterative releases, adding functionality gradually.
• Maintenance Phase – Handles post-deployment improvements and bug fixes.

2. Micro Process (Detailed Object-Oriented Design Process)

This process is recursive and follows four key steps:
1. Identification of Classes and Objects – Determine system components at different levels of
abstraction.
2. Identification of Semantics – Define object attributes and operations (behavior).
3. Identification of Relationships – Establish relationships like inheritance, usage, and instance-of.
4. Specification of Interfaces and Implementation – Define data types, method signatures, and
interactions between objects.

Limitations:
• No formal notations for visual diagrams.
• Heavy reliance on iterative design, which may be challenging for large projects.
The Booch methodology provides a structured, yet flexible approach to object-oriented system
development, making it well-suited for complex and evolving projects.
Rumbaugh Methodology (Object Modelling Technique - OMT)
It provides a structured approach to system development by focusing on three key models: Object Model,
Dynamic Model, and Functional Model.

Four Phases of OMT:

1. Analysis Phase (Understanding System Requirements)
The analysis phase consists of three sub-models that define different aspects of the system:
• Object Model: Captures the static structure of the system, including classes, attributes, and
relationships.
• Dynamic Model: Describes the behavior of objects, including state changes and events.
• Functional Model: Represents the functionality of the system using Data Flow Diagrams (DFDs) to
map inputs, processes, and outputs.
Key Activity: Identify classes, relationships, states, and functions from the problem statement.

2. System Design Phase (High-Level Design)

• Develops a high-level system architecture, considering factors like database management systems
(DBMS), communication protocols, and hardware/software requirements.

3. Object Design Phase (Detailed Object Specification)

• Defines detailed object structures, attributes, and methods.
• Specifies algorithms and interactions for object behaviors.
• May introduce new objects to optimize system design.

4. Implementation Phase (Coding & Development)

• Implements classes, functions, and database operations according to design specifications.

Key Features of OMT:

Comprehensive – Covers analysis, design, and implementation.

Supports System Evolution – Allows refinement of design through different phases.

Limitation: Can be complex due to multiple models and detailed analysis.

Conclusion:
The Rumbaugh methodology (OMT) is a powerful object-oriented software development approach that
ensures a clear and structured system design by integrating static, dynamic, and functional models.
Jacobson Methodology (Object-Oriented Software Engineering - OOSE)
It is unique because it is the first use-case-driven methodology, focusing on how users interact with the
system.

Five Models of OOSE:

1. Requirement Model (Gathering Requirements)
• Identifies use cases (interactions between users and the system) N Defines actors
• Helps in understanding the functional requirements.

Key Concept: Use case diagrams to represent system functionality.

2. Analysis Model (Building an Ideal Structure)

• Focuses on designing a robust, modifiable system independent of implementation details.
• Identifies three types of objects:
o Interface Objects → Handle user interactions.
o Entity Objects → Represent data stored in the system.
o Control Objects → Manage interactions between interface and entity objects.
• Groups related objects into subsystems.

Key Concept: Builds an ideal architecture without considering the actual technical environment.

3. Design Model (Refining for Implementation)

• Adapts the analysis model to fit the technical implementation.
• Converts objects into "blocks" for practical implementation.

Key Concept: Objects identified in the analysis model are refined to match the real-world development
environment.

4. Implementation Model (Coding & Development)

• Transforms design blocks into software modules.
• Focuses on programming, database integration, and external system communication.

Key Concept: Converts design models into actual working code.

5. Test Model (Validation & Verification)

• Ensures the system meets functional and non-functional requirements.
• Conducts unit, integration, and system testing.

Key Concept: Validates that the implemented software functions correctly.

Evolution of UML
Three key methodologies—Booch (design), Rumbaugh (analysis), and Jacobson (behavioral modeling)—
were combined into Unified Modeling Language (UML).
UML is a visual modeling language used to specify, visualize, construct, and document software systems.
It includes:
1. Static Modeling (structure) – Class, Object, Component, and Deployment Diagrams.
2. Dynamic Modeling (behavior) – Sequence, Activity, State, and Use Case Diagrams.
Why Use UML?

Standardized software design approach

Improves communication among stakeholders
Enhances maintainability and scalability
UML remains the leading modeling language for clear, well-documented system development.

Customers, Developers, and Users

• Customers – Individuals or organizations that request, approve, and fund the system.
• Developers – Professionals ,responsible for designing and building the system.
• Users – End-users who interact with and operate the system.
Example: Library Management System
• Customer: University (requests and funds the system).
• Developer: Software team (builds the system).
• Users: Library staff (operates the system).

Product and Process

• Product – The final deliverable given to the customer, which may include:
Software Requirement Specification (SRS) document
Source code
Test reports
 User manuals
System guide
• Process – The methodology and steps followed to develop the software.
o It consists of a series of activities aimed at producing a high-quality and maintainable
product.
A well-structured process ensures a high-quality product that meets customer expectations.

Actor, Use Case, Use Case Model, and Use Case Scenario
• Actor: Represents a role that interacts with the system (e.g., Administrator, Student, Library Staff).
• Use Case: Describes who (actor) interacts with the system, what they do, and why, without focusing
on internal system details.
• Use Case Model: A diagram that shows actors, use cases, and their relationships in the system.
• Use Case Scenario: A specific instance of a use case, representing a complete path through the
system.
o The basic flow is the main scenario.
o Alternative paths create additional scenarios.

Example (Library Management System):

• Actor: Student
• Use Case: Borrow Book
• Scenario:
Student logs in
Searches for a book
Selects the book to borrow
System checks availability
Student borrows the book

System and Subsystems

• System:(as a whole)
o A well-organized structure with interrelated procedures, processes, and methods.
o Consists of inputs, outputs, feedback mechanisms, and boundaries.
• Subsystem:
o A smaller part of a larger system that helps reduce complexity.
o Example: In a company, Accounts, Sales, and Marketing are subsystems.

Key Benefit: Subsystems help manage complexity by breaking down large systems into smaller, more
manageable units.
Measures, Metrics, and Measurement
• Measure: A quantitative value representing an attribute of a product or process (e.g., number of
failures during testing).
• Measurement: The act of collecting and recording a measure (e.g., tracking failures in a log).
• Metric: A quantitative measure that describes how well a product or process meets a given attribute
(e.g., average failures per hour).

Software Quality and Reliability

• Software Reliability:
o Probability of failure-free operation for a specified time in a specified environment.
o Unlike hardware, software does not age; it changes only when modified or upgraded.
• Software Quality:
o Determines how well software is designed (quality of design) and how well it conforms to
that design (quality of conformance).
o Includes non-functional requirements like understandability, maintainability etc.

Reliability is just one aspect of quality. A high-quality software product requires continuous validation and
verification throughout development

Verification vs. Validation

Verification (Static Testing)
• Definition: Evaluates whether products of a development phase meet predefined conditions.
• Method: Manual inspection & reviews (documents, design, source code).
• Activity Type: Static (no code execution).
• Goal: Catch errors early in development.

Validation (Dynamic Testing)

• Definition: Evaluates whether the final system meets specified requirements.
• Method: Actual program execution (functional and non-functional testing).
• Activity Type: Dynamic (requires a running system).
• Goal: Identify defects and ensure correct behavior.

Key Difference:
• Verification ensures we are building the product right (correct process).
• Validation ensures we are building the right product (correct outcome).
 Testing = Verification + Validation
Both activities complement each other, ensuring a robust and high-quality software system.

Fault, Error, Bug, and Failure

Error/Mistake/Defect
• A human-made mistake in coding or design.
• Example: A developer miswrites a formula in a function.

Bug (Fault in Code)

• When an error is introduced into the source code, it’s called a bug.
• Example: A syntax mistake or incorrect logic.

Fault
• A representation of an error in various forms (e.g., diagrams, source code).
• Example: A missing condition in an if-statement.

Failure
• When a fault gets executed, leading to an incorrect output.
• Example: The software crashes or gives the wrong result.

States & Events

State: A specific condition of an object/system at a given time.
• Example: A library book can be in Available, Borrowed, or Reserved states.

Event: A trigger (input/message) that causes a state transition.

• Example: "Book Borrowed" → Changes book state from Available to Borrowed.
Last is operation n maintenance
Phases of Object-Oriented Software Development Life Cycle
1. Object-Oriented Requirement Analysis
• Uses use case approach to capture customer requirements.
• Produces Software Requirement Specification (SRS) with use case descriptions.

2. Object-Oriented Analysis
• Identifies objects and their relationships within the system.

3. Object-Oriented Design
• Refines objects with implementation details.
• Ensures objects from the analysis phase are properly mapped to the design phase.

4. Object-Oriented Programming & Testing

• Implements objects, their functions, and interactions in source code.
• Supports code reusability by integrating existing well-tested components.
• Uses object-oriented testing techniques to validate system functionality.

Fountain Model Summary

Unlike the Waterfall Model, where phases are strictly sequential, the Fountain Model allows
different stages to overlap, meaning that design, implementation, and testing can happen in
parallel.
• Represents iterations and overlapping phases in software development.
• Emphasizes reusability of source code.
• Uses circles to depict overlapping phases and arrows for iterations within them.
• The smallest circle represents maintenance, indicating it is the least extensive phase.
Flexible Requirements: Changes can be made easily between class specification and requirement
specification, so early requirement freezing is unnecessary.

Class-Based Development: The software development life cycle applies to individual classes rather than
the entire system.

Potential Drawback: The model may lead to an undisciplined approach, where developers move
randomly between phases.

The Fountain Model offers flexibility and reusability, but requires careful management to avoid
disorganization.
Rational Unified Process (RUP) Model – Explained for Semester Exams
Rational Unified Process (RUP) is a software development model that follows an iterative and incremental
approach. It was developed by Rational Software and is designed to provide a structured, disciplined, and
flexible process for software development.

Key Features of RUP

1 Iterative Development
• Software is developed in multiple iterations (mini-projects) instead of a single sequence.
• Helps in continuous customer feedback and improves software quality.
• Allows changes to be made during development rather than at the end.

2 Use Case Driven Approach

• Uses Use Cases to gather and define user requirements.
• Each use case represents a feature or functionality from the user’s perspective.

3 Component-Based Development
• Encourages reuse of pre-built and well-tested software components.
• Promotes modularity, making systems more manageable and scalable.

4 Visual Modeling Using UML

• Uses Unified Modeling Language (UML) to design system architecture.
• UML diagrams like Class Diagrams, Use Case Diagrams, Sequence Diagrams, etc., help in
understanding the system better.

5 Focus on Quality
• Defect detection is done early to reduce cost and effort.
• Continuous testing is performed throughout the development cycle.

Phases of RUP
Four phases, each with multiple iterations:

1 Inception Phase
• Goal: Define project scope, business case, and feasibility.
• Identify key requirements, risks, and possible solutions.
• Deliverables: Project Plan, Risk Assessment, Use Case Model.
2 Elaboration Phase
• Goal: Refine architecture, define major system components, and mitigate risks.
• Create prototypes and validate technical feasibility.
• Deliverables: Architecture Description, UML Diagrams, Updated Risk List.

3 Construction Phase
• Goal: Develop the actual system through coding and testing.
• Iterative development with testing in each cycle.
• Deliverables: Working Software, Test Cases, User Documentation.

4 Transition Phase
• Goal: Deploy the system to users and get feedback.
• Perform beta testing, user training, and bug fixes.
• Deliverables: Final Software Release, Maintenance Plan.

Advantages of RUP

Flexible and Adaptable – Can handle changing requirements.

Risk Reduction – Iterative development helps identify risks early.
Continuous Testing – Ensures high-quality software.
Improved Communication – Uses UML diagrams for better documentation.

Remember the four phases (Inception, Elaboration, Construction, Transition) and their key goals!
 Software Requirements Elicitation and Analysis
1. Feasibility Analysis:
o Before developing software, it's crucial to assess whether the project is technically,
financially, and practically feasible.
o If a project is not feasible, it's better to realize it early to avoid time and cost wastage.

2. Requirement Gathering Challenges:

o Most requirements exist in the minds of stakeholders, making it difficult to extract them.
o Proper documentation of requirements in a structured format is essential.

3. Importance of Clear Requirements:

o Defining requirements is the hardest part of software development.
o Poorly defined requirements can cripple the system and be difficult to fix later.

4. Use Case Approach & SRS:

o The Use Case Approach is widely used in Object-Oriented Software Engineering for
requirement analysis.
o The Software Requirement Specification (SRS) document is prepared after requirement
gathering to serve as a blueprint for development.
Case Study: Library Management System
The problem statement for a Library Management System (LMS) case study is presented in this section. The
examples from this case study are used to illustrate object-oriented analysis and design techniques
throughout this book. The problem statement is prepared by the customer who gives us broad outline of
the expectations from the proposed system. The problem statement of the LMS as prepared by the
customer is given here.

What is Software Requirement?

• A requirement is a condition or capability that a system must conform to.
• Focus: It describes what the system should do, not how it should do it.
• Source of Requirements:
o If the project is an enhancement or automation of an existing system, then:
▪ The existing system itself can provide information.
▪ The people involved in the system can also provide insights.
Who Provides Requirements?
Stakeholders include: Customers End-users Business Analysts Developers Testers
Identification of Stakeholders(Not much IMP)
Identifying stakeholders is crucial in software development, as they influence system requirements and
expectations.
1. Internal People of Customer’s Organization –
Includes customers (who request, approve, and pay for the system) and users (who operate the
system after deployment).
2. External People of Customer’s Organization –
Includes consultants, domain experts, maintenance personnel, and external agencies providing
rules, regulations, and guidelines.
3. Internal People of Developer’s Organization –
Includes all individuals involved in system development, such as developers, testers, project
managers, use case writers, and designers.
4. External People of Developer’s Organization –
Includes consultants, third-party testers, external domain experts, and external agencies
responsible for development and testing standards.

Proper identification of stakeholders ensures effective requirement gathering and system development.

Functional and Non-Functional Requirements

1. Functional Requirements
Describe what the software will do, specifying expected functionalities and features of the system.
They are collected from stakeholders and focus on system operations.
They also define what the software will not do.

2. Non-Functional Requirements –
Define how well the software performs its functions, representing quality attributes such as reliability,
usability, maintainability, availability, portability, flexibility, and testability.

3. Known and Unknown Requirements

• Known requirements are explicitly stated by stakeholders and, if implemented correctly, meet user
expectations.
• Unknown requirements are often overlooked due to lack of immediate necessity, domain expertise,
or technology limitations. Identifying and incorporating them can enhance system value and
sustainability.

Both functional and non-functional requirements can be either known or unknown.

Requirements Elicitation Techniques
Capturing requirements from stakeholders is challenging due to differences in mindset, background,
vocabulary, and communication skills.
Misunderstandings can lead to conflicts and ambiguities. Successful requirements elicitation relies on a
strong customer-developer partnership.
Since a single technique may not be sufficient to capture all requirements, multiple techniques are often
used.
Prototyping in Requirements Elicitation
Prototyping is a powerful but expensive technique used to capture and refine requirements. A prototype
is a simplified version of the system that allows customers and users to visualize how the final system
will look and function.
Key Benefits of Prototyping:
• Enhances Understanding: Helps developers understand user expectations.
• User Feedback: Customers can identify missing or ambiguous requirements.
• Bridges the gap between users and developers.
• Refines Requirements

Types of Prototyping Approaches:

1. Throwaway Prototyping:
o The prototype is built to understand requirements and is later discarded.
o Helps finalize requirements before actual development.

2. Evolutionary Prototyping:
o The prototype evolves into the final system instead of being discarded.
o Saves development effort but requires structured design.

Prototyping is a valuable tool in requirements elicitation, enabling early validation of user needs and
reducing the risk of misunderstandings in software development.

Initial Requirements Document (IRD)

The Initial Requirements Document (IRD) is a formal document used to capture and list the initial set of
requirements gathered from various stakeholders.
It serves as the foundation for further refinement of requirements and acts as a reference for system
development.
Purpose of IRD:
• Documents early-stage requirements.
• Helps in communication between stakeholders and developers.
• Identifies functional and non-functional requirements.
The IRD is not the final document but serves as a working draft to refine and finalize the software
requirements.
Use Case Approach in Software Engineering
The Use Case Approach is a systematic way to model functional requirements of a system, primarily used in
object-oriented software development but applicable to traditional systems as well. It helps in
understanding user expectations and interactions with the system.

Key Concepts in the Use Case Approach:

1. Use Case:
o A structured template that describes what the system is expected to do, not how it will be
implemented.
o Captures functional requirements of the system.
o Written in natural language (e.g., English).
2. Use Case Scenario:
o A specific instance of a use case.
o Represents one possible path through the use case.
o Example: A user successfully logging into a system is one scenario; an incorrect password
attempt is another.
3. Use Case Diagram:
o A graphical representation of use cases and their interactions with actors (users or external
systems).
o Actors: Entities that interact with the system (e.g., users, administrators, external
databases).
o Relationships: Represented using arrows, showing associations between actors and use
cases.

Benefits of Use Case Approach:

• Provides a clear, structured representation of system functionalities.
• Bridges the communication gap between stakeholders and developers.
• Forms the basis for test case generation during software testing.

Use case diagrams, scenarios, and descriptions work together to create a comprehensive view of system
functionality and user interactions.

Actor:
o Any external user or system interacting with the software.
o Can be a person, organization, or another software system.
o Example: In a Library Management System (LMS):
 ▪ A Librarian (Actor) interacts with the system to issue books (Use Case).
▪ A Student (Actor) interacts with the system to search for books (Use Case).

Understanding Use Cases:

• Initiated by an actor with a specific goal.
• Successfully completes when that goal is achieved.
• Clarifies how the system responds to different interactions.

Why Use Cases Are Important:

• Improves system clarity by defining interactions between users and the system.
• Helps stakeholders understand functionality without technical complexities.
• Ensures completeness in requirement gathering.
• Guides developers and testers in system design and validation.

A well-structured use case is written in simple language to be easily understood by all stakeholders.

The real value of a use case is the dynamic relationship between the actor and the system. A well written
use case clarifies how a system is used by the actor for a given goal or reason.
If there are any questions about what a system does to provide some specific value to someone or
something outside the system, including conditional behaviour and handling conditions of when something
goes wrong, the use case is the place to find the answer.

Identification of Actors in a System

An actor is an external entity (person or system) that interacts with the software system for a specific
purpose.
Key Points about Actors:
• Actors are NOT devices. A device (e.g., printer, keyboard) helps the user interact but is NOT an actor.
• Actors can be human users or external systems.
• They define who interacts with the system and what role they play.
Types of Actors:
1. Primary Actors – Direct users who actively use the system (e.g., customers, students, employees).
2. Secondary Actors – People who maintain or monitor the system (e.g., administrators, support staff).
Example: Actors in a Library Management System (LMS)
1. Administrator (Secondary) – Manages system settings.
2. Data Entry Operator (Primary) – Enters book records.
3. Librarian (Primary) – Manages book inventory.
4. Library Staff (Primary) – Assists in library operations.
5. Faculty (Primary) – Borrows and requests books.
6. Student (Primary) – Searches, borrows, and returns books.
7. Employee (Primary) – Uses the library for research.

Identification of Use Cases in a System

A use case defines how an actor interacts with a system to achieve a specific goal. It focuses on functional
requirements, describing what the system should do, not how it is implemented.
Guidelines for Creating Use Cases:
1. Each functional requirement should have a use case.
2. Assign a unique and meaningful name to each use case.
3. One or more actors can interact with a use case.
4. Clearly state the goal of the use case.
5. Specify the role of actors in each use case.
6. Ensure that the use case represents a complete and meaningful flow of events.

Use Cases for a Library Management System (LMS)

Based on the Initial Requirements Document (IRD), the following use cases can be identified:
1. Maintain book details – Adding, updating, and deleting book records.
2. Maintain student details – Managing student records and memberships.
3. Maintain faculty/employee details – Handling faculty/employee membership.
4. Maintain login details – User authentication and role management.
5. Issue book – Checking out books for students and faculty.
6. Return book – Processing book returns and updating records.
7. Fine calculation – Computing overdue penalties.
8. Reserve book – Allowing users to request books.
9. Query book – Checking availability and status of books.
 10. Search book – Finding books by title, author, or category.
11. Report generation – Creating reports on issued books, fines, and user activity.

Identifying use cases helps define system functionality by focusing on user interactions. This ensures that
the software meets stakeholder expectations and covers all essential processes effectively.

Use Case Relationships: Extend and Include

1. Extend Relationship
The Extend relationship is used when an optional, alternative, or special behavior needs to be added to a
base use case under certain conditions.
How It Works:
1. The main use case runs normally.
2. When a specific condition occurs, the extended use case is executed.
3. After execution of the extended use case, the main use case continues.

Example (Library Management System - LMS):

• Base Use Case: Return Book
• Extended Use Case: Fine Calculation (executed only when a book is returned after the due date)

Represented as dashed arrow with "<<extend>>" notation.

This means that the "Fine Calculation" use case is only triggered if the book is returned late. Otherwise, it is
not executed.
2. Include Relationship
The Include relationship is used when a common functionality is required in multiple use cases.
Instead of writing the same functionality multiple times, it is separated into an independent use case and
included wherever needed.
How It Works:
1. The main use case executes and calls the included use case.
2. The included use case is always executed whenever the main use case runs.
3. Control returns to the main use case after execution.

Example (LMS):
• Base Use Cases: Issue Book & Return Book
• Included Use Case: Maintain Book Details (since book details need to be updated in both cases)
• "Issue Book" includes "Maintain Book Details"
• "Return Book" includes "Maintain Book Details"
• Represented as dashed arrow with "<<include>>" notation.
This ensures that book details are updated whenever a book is issued or returned, preventing redundancy
in defining the same functionality separately.

Summary:
• Extend Relationship (<<extend>>) → Optional or conditional behavior (e.g., Fine Calculation is only
triggered if a book is returned late).
• Include Relationship (<<include>>) → Mandatory shared behavior (e.g., Updating book details must
always occur when issuing or returning a book).
Use Case Diagram for Library Management System (LMS)
Actors
• Primary Actors:
o Student (Borrows and returns books)
o Faculty (Borrows books)
o Librarian (Manages books, users, and fines)
• Secondary Actors:
o Administrator (Manages system settings)
o External Database (Stores book details)
Use Cases

✔ Maintain Book Details

✔ Maintain User Details
✔ Issue Book
✔ Return Book
✔ Fine Calculation (<<extend>> Return Book)
✔ Search Book
✔ Reserve Book
✔ Generate Reports

Example Relationships:
• Librarian → Issue Book
• Student → Return Book (<<extend>> Fine Calculation)
• Both Faculty & Students → Search Book
• Issue Book → (<<include>>) Maintain Book Details
• Return Book → (<<include>>) Maintain Book Details
Use Case Description
A use case description is a structured format that documents how an actor interacts with the system to
achieve a specific goal
Key Elements of a Use Case Description

1. Actors
o List of all entities (users, external systems) that interact with the use case.

2. Preconditions
o Conditions that must be true for the use case to execute.
o If these conditions aren't met, the use case cannot start.

3. Postconditions
o The expected state of the system after the use case completes.
o Defines what changes in the system after execution.

4. Basic Flow
o The main sequence of steps executed by the system.
o No reference to alternative flows.
o Should be clear, complete, and self-contained.

5. Alternative Flow
o Describes what happens when things don’t go as planned.
o Triggered by specific conditions and executed separately from the basic flow.
o Knows when and where it applies and inserts into the basic flow only when necessary.

6. Exceptions
o Special error conditions that may interrupt execution (e.g., system crash, network failure).

7. Special Requirements
o Includes business rules, constraints, or specific execution conditions for flows.

8. Related Use Cases

o Other use cases linked to this one (e.g., "Issue Book" may relate to "Return Book" or "Fine
Calculation").

Use Case Diagram Representation

• Basic Flow → Represented by a straight arrow.
• Alternative Flows → Represented by curved arrows.
• Decision Points → Indicate when alternative flows may occur.
Characteristics of a Good Requirement
1 Correct – The requirement must accurately reflect the actual needs of the system.

• Example: "The system shall allow users to reset their password via email."
o This requirement is correct because it matches the real-world expectation of a password
reset feature.
2 Unambiguous – The requirement should have only one interpretation.

• Example: "The system shall process transactions quickly." (Bad example)

• Fixed: "The system shall process transactions within 2 seconds."

o The first version is vague—how fast is "quickly"? The second version is precise and leaves no
room for doubt.

3 Complete – The requirement should provide all necessary details.

• Example: "The system shall generate a monthly sales report." (Incomplete)

• Fixed: "The system shall generate a monthly sales report including revenue, profit, and total
units sold."
o The improved version specifies what data the report should include.
4 Consistent – There should be no contradictions within the requirements.

• Example:
o "The system shall allow only admins to delete records."
o "Users can delete their own records." (Contradiction)

• Fixed: "Only administrators shall have permission to delete records."

o Ensures clarity and removes any inconsistencies.
5 Verifiable – The requirement must be testable to confirm it has been met.

• Example: "The login page shall load within 3 seconds."

o This can be measured with performance testing. If the page loads within 3 seconds, the
requirement is satisfied.
6 Modifiable – The requirement should be structured so that updates or changes don’t disrupt the whole
system.

• Example: "All error messages shall follow the format: ‘Error [code]: [message]’."
o If error messages need updating, only the format definition needs to change, not the entire
system.
7 Clear – The requirement should be easy to understand, avoiding unnecessary complexity.

• Example: "Users shall receive a confirmation email after successful registration."

o This is straightforward and doesn’t use technical jargon.
8 Feasible – The requirement should be realistic given technical and budget constraints.

• Example: "The system shall support 1 million users simultaneously on a single server."
(Unrealistic)

• Fixed: "The system shall support up to 100,000 concurrent users with load balancing."
o This version considers system limitations and practical implementation.
9 Necessary – The requirement must add real value to the system.

• Example: "The system shall display an animation every time a button is clicked."
o If this doesn’t improve user experience or functionality, it’s unnecessary and should be
removed.

10 Understandable – The requirement should be written in clear language that all stakeholders can
understand.

• Example: "The system shall send an email notification after a transaction is completed."
o Avoids technical terms and keeps it simple for non-technical stakeholders.

FROM 53-61 SRS

The Software Requirements Specification (SRS) document is created after the

Initial Requirements Document (IRD).
• It provides a detailed overview of the system.
• Acts as a legal contract between customers and developers.
• Ensures developers know what to build and customers know what to expect.
• Helps in validating that the built system meets the specified requirements.

The SRS document should address the following key issues:

1. Functionality – Defines the functions the software must perform.
2. External Interfaces – Specifies interactions with external entities, including users, response time,
recovery time, and processing time.
3. Performance – Details performance considerations related to people, hardware, and external
databases.
4. Quality Attributes – Covers non-functional requirements such as availability, correctness,
maintainability, portability, reliability, security, and testability.
5. Design Constraints – Lists implementation constraints, including operating environment limitations,
programming languages, databases, and resource policies.
The document should not include design and implementation details and must be clear, simple, and
unambiguous for both developers and customers.
1. Introduction
This section provides an overview of the system, its purpose, and the scope of the document.
1.1 Purpose
Defines why the system is being developed and the problems it aims to solve. It describes the intended
users and key benefits.
Example (LMS):
The LMS is designed to facilitate book lending, catalog management, and user registration for students and
librarians. It aims to improve efficiency in tracking book availability and borrower details.
1.2 Scope
Defines the boundaries of the system, including its primary functionalities and the intended environment.
Example (LMS):
The LMS will allow users to borrow and return books, maintain borrower records, and generate reports. It
will be used in schools, colleges, and public libraries.
1.3 Definitions, Acronyms, and Abbreviations
Lists important terms, abbreviations, and acronyms used throughout the document.
Example (LMS):
• LMS – Library Management System
 • ISBN – International Standard Book Number
• Admin – Library Administrator
1.4 References
Includes external documents, standards, and sources referenced in the SRS.
Example (LMS):
• IEEE Std 830-1998 Software Requirements Specification
• Library Database Schema Documentation
1.5 Overview
Summarizes the structure of the document and what each section covers.

2. Overall Description
Provides a high-level understanding of the system, its functions, and constraints.
2.1 Product Perspective
Describes how the system fits within existing systems and its dependencies.
Example (LMS):
The LMS will integrate with the school's student database for authentication and will connect to an online
book catalog for ISBN verification.
2.1.1 System Interfaces
Defines how the system interacts with other systems.
• LMS connects with a student management system to retrieve student details.
• Integration with barcode scanners for book identification.
2.1.2 User Interfaces
Describes the graphical or command-line interfaces for users.
• A web-based interface for librarians and students.
• A mobile application for checking book availability.
2.1.3 Hardware Interfaces
Specifies the hardware requirements.
• Barcode scanners for book check-in/check-out.
• Printers for issuing due-date slips.
2.1.4 Software Interfaces
Identifies software dependencies.
• The LMS must run on Windows, Linux, and macOS.
• It should integrate with MySQL for database management.
2.1.5 Communication Interfaces
Specifies network protocols for communication.
• The system should support REST APIs for data exchange.
2.1.6 Memory Constraints
Specifies RAM, storage, and processing limitations.
• The database must handle up to 1 million records.
2.1.7 Operations
Describes operational aspects like system availability.
• The LMS should be available 24/7, except for maintenance.
2.1.8 Site Adaptation Requirements
Describes how the system should adapt to different environments.
• It should support multi-branch libraries with centralized management.
2.2 Product Functions
Lists the key functionalities of the system.
• User Management – Register students, staff, and librarians.
• Book Management – Add, update, and delete book records.
• Borrow/Return – Issue and return books with due date tracking.
2.3 User Characteristics
Describes different user roles.
• Librarians – Manage books and users.
• Students – Search and borrow books.
2.4 Constraints
Lists limitations like legal, regulatory, or technical constraints.
• The LMS must comply with data protection regulations.
2.5 Assumptions and Dependencies
Describes external factors affecting the system.
• The system assumes users have internet access.
2.6 Apportioning of Requirements
Identifies features planned for future updates.
• E-book lending may be implemented in a future version.

3. Specific Requirements
This section provides detailed functional, performance, and design constraints.
3.1 External Interfaces
Details interactions with users, hardware, and software.
• The system will provide an API for mobile applications.

3.2 Functions
Defines system functions and their inputs/outputs.
• Borrow Book: User enters book ID → LMS verifies availability → LMS records transaction.
•
•
 •

3.3 Performance Requirements

Describes response time, capacity, and efficiency.
• The system should process transactions within 2 seconds.
3.4 Logical Database Requirements
Defines data storage structures.
• A relational database will store user and book details.
3.5 Design Constraints
Outlines hardware, software, and industry standards.
• 3.5.1 Standards Compliance: The system must adhere to ISO 27001 security standards.
3.6 Software System Attributes
Defines quality attributes.
3.6.1 Reliability
• The LMS should have 99.9% uptime.
3.6.2 Availability
• The system should support backup and recovery mechanisms.
3.6.3 Security
• The system should encrypt user data using AES-256.
3.6.4 Maintainability
• The LMS should be modular to allow easy updates.
3.6.5 Portability
• The system should be compatible with different OS.
3.7 Organizing the Specific Requirements
Various ways to structure functional requirements.
3.7.1 System Mode
Organizes functions based on operational modes (e.g., Online, Offline).
3.7.2 User Class
Defines different feature sets for students, staff, and admins.
3.7.3 Objects
Organizes requirements based on entities like books and users.
3.7.4 Feature
Describes specific features (e.g., Search Books, Issue Book).
3.7.5 Stimulus
Arranges functions based on events like book requests.
3.7.6 Response
Categorizes requirements by system responses (e.g., Overdue Notifications).
3.7.7 Functional Hierarchy
Uses data flow diagrams to describe system operations.
3.8 Additional Comments
Provides any extra information not covered elsewhere.

4. Supporting Information
Includes references, appendices, and any additional documentation
 Requirements Change Management
Managing changes in software requirements is necessary since changes are inevitable. Change
management involves a systematic approach to handling modifications to ensure minimal disruption.

Example (LMS):
If a request is made to add a book recommendation feature in LMS, the committee evaluates if it's
essential, considering library resources and user needs.

Summary

Why Change Management is Important?

• Helps control requirement modifications efficiently.
• Ensures smooth software evolution.
• Prevents unnecessary changes that might disrupt existing functionalities.

Key Steps in LMS Change Management

1. Analyze Change Necessity – Is the change valuable?
2. Establish Baseline – Record and freeze requirement versions.
3. Traceability – Ensure changes align with software design and testing.
4. Change Control – Approve, implement, test, and document change.
 Summary of Object-Oriented Analysis (OOA)
• To analyze and structure system requirements using real-world objects.
• Process:
o Identifies objects, attributes, and operations.
o Defines relationships between objects.
o Develops an ideal logical model before implementation.
• Advantage: Provides a high-level understanding of system requirements.

Key Takeaways of OOA

• Uses class models to integrate data and functions.
• Prevents accidental data modification with encapsulation.
• Ensures easier modification and maintenance.
• Visual diagrams help:
o Understand customer requirements.
o Develop database schema.
o Identify system operations efficiently.

Types of Classes in Rational Unified Process (RUP):

• Entity Class: Represents real-world objects (e.g., Student, Book).
• Interface Class: Handles user interactions (e.g., LoginScreen, Dashboard).
• Control Class: Manages system logic and workflows (e.g., IssueBookController).
Entity Classes in Object-Oriented Analysis (OOA)
• Definition:
o Entity classes persist long-term in a system.
o Also called domain classes.
o Contain key data needed for system operations.
• Characteristics:
o Stored and maintained throughout the system's lifecycle.
o Identified from use cases and extracted from SRS document data fields.
o Not limited to a single use case (e.g., a Student entity is used in multiple features).

• Example: Entity Classes in LMS (Library Management System)

o Issue Book Use Case requires:
1. Member (students, faculty, employees)
2. Book (details of the book)
3. Transaction (records of issued/returned books)
• Other Examples in Different Systems:
o ATM System: Customer, Account
o Result Management System: Student, Marks, Course

Interface Classes in Object-Oriented Analysis (OOA)

• Definition:
o Interface classes manage interactions between actors (humans or external systems) and the
software.
o Also called boundary classes.
o Model UI elements (windows, buttons) or external communication protocols.

• Characteristics:
o Exist only as long as the use case is active.
o Extracted by analyzing actor interactions in use case scenarios.
o Sensitive to system changes (if UI changes, interface classes must be updated).
 • Example: Interface Classes in LMS (Library Management System)
o Issue Book Use Case requires:
1. IssueBookInterface – Allows library staff to issue a book.
2. BarcodeReader – Scans book and member barcodes.

• Key Difference from Entity & Control Classes:

o Changes in UI affect only interface classes, not entity/control classes.

Control Classes in Object-Oriented Analysis (OOA)

• Definition:
o Control classes manage and coordinate interactions between entity and interface classes.
o They handle business logic and flow of events in use cases.
o Created when a use case starts and deleted when it ends.

• Identification & Usage:

o Identified from use cases (each use case can have a control class).
o Manages sequences of events in a use case.
o Example in LMS (Library Management System):
▪ IssueBookController manages the "issue book" use case.

• Characteristics of Control Classes:

1. Independent of surroundings (not tied to UI or persistent data).
2. Coordinate event flow in a system.
3. Depend on entity classes (changes in entity classes may require updates in control classes).
• Examples of Control Classes:
o TransactionManager – Handles financial transactions.
o LoginController – Manages user authentication.
o SecurityManager – Ensures secure access.
o ExceptionHandler – Deals with system errors.
Identification of Relationships in Object-Oriented Analysis (OOA)
• Definition:
o Relationships define connections and interactions between classes and objects.
o Objects communicate by sending messages through these relationships.

• Types of Relationships:
1. Association:
▪ A general connection between two classes.
▪ Example: A Student "borrows" a Book.

2. Aggregation:
▪ A whole-part relationship where the parts can exist independently.
▪ Example: A Library contains Books, but books can exist outside the library.
3. Composition:
▪ A stronger whole-part relationship where parts cannot exist independently.
▪ Example: A House contains Rooms, and rooms cannot exist without the house.

4. Dependency:
▪ One class depends on another but does not own it.
▪ Example: A Printer depends on a Computer to print documents.

5. Generalization (Inheritance):
▪ Represents an "is-a" relationship (parent-child class hierarchy).
▪ Example: Faculty and Student inherit from Person class.

▪
Multiplicity:
• Defines the number of objects related in an association.
• Examples:
o 1 → Exactly one
o 0..* → Zero or many
o 1..* → One or more
o 3..5 → Specific range (3 to 5)
Identifying Attributes and Operations in Object-Oriented Analysis (OOA)

Attributes represent the information to be stored in an entity class.

They can be identified through:
1. Use Case Descriptions – Extract key data fields mentioned in system flows.
2. User Interface (SRS Document) – Convert form fields into class attributes.
3. Database Schema – Map table fields directly to class attributes.
4. Domain Expertise – Analyst determines additional required attributes.
Example: Attributes in a Book Class
• bookBarcodeID : Integer
• accessionNo : Integer
• subjectDescriptor : String
• ISBN : Long
• bookTitle : String
• language : String
• authorName : String
• publisher : String
• issueStatus : Boolean

Operations modify or retrieve the class instance data. They can be identified by:
• Use Case Flow of Events – Actions like adding or updating records.
• Interaction Diagrams – Shows how objects interact and what messages they send.

Example: Operations in Book Class

• addBook() – Stores book details.
• deleteBook() – Removes a book from the system.
• updateBook() – Modifies book details.
• viewBook() – Retrieves book details.
• getIssueStatus() – Checks if the book is issued.
 Object-Oriented Design (OOD)
After the Object-Oriented Analysis (OOA) phase, the Object-Oriented Design (OOD) phase begins,
refining the identified classes, attributes, and operations for implementation.
1. Class Diagram Refinement:
o Classes are detailed with attributes, operations, and relationships.
o Consideration of implementation aspects (e.g., programming languages, databases,
communication protocols).
2. Interaction Diagrams Creation:
o Defines how objects interact through message exchanges.
o Helps refine class operations, adding, deleting, or updating them as needed.
3. Use Case Refinement:
o Enhancing descriptions for clarity and accuracy.
4. Test Case Generation:
o Test cases are created based on use case scenarios to ensure system correctness.

What is Done in Object-Oriented Design (OOD)?

The Object-Oriented Design (OOD) phase refines the analysis model into a detailed design model that is
ready for implementation. This phase focuses on defining object interfaces, relationships, and operation
semantics while considering the implementation environment.
Why is the Design Phase Needed?
1. Bridging the Gap Between Analysis and Implementation:
2. Refinement of Objects and Relationships:
3. Verification of Class Relationships:

Steps in Object-Oriented Design (OOD):

Creation of Interaction Diagrams for Each Scenario:
a) Sequence Diagram:
o Identify actors, objects, and messages in a use case scenario.
o Define object lifelines, focus of control, and interaction sequence.
o Refine the sequence diagram.
b) Collaboration Diagram:
o Identify objects, links, and messages.
o Define structural relationships between objects.
o Determine the sequence of messages exchanged.
Interaction diagrams illustrate how objects in a system communicate with each other by passing
messages. They model the dynamic behavior of a system for a specific use case scenario.
Key Concepts:
• Interaction diagrams are created for each use case or scenario.
• They help refine operations identified in the OOA phase (adding, deleting, or modifying them).
• Objects identified in OOA are used, and new objects may be introduced based on implementation
needs.

Types of Interaction Diagrams in UML:

1 Sequence Diagram:
• Represents object interactions over time.
• Objects are placed on the x-axis, while time progresses on the y-axis.
• Messages between objects are shown sequentially from top to bottom.
2 Collaboration Diagram:
• Focuses on object relationships and message exchange.
• Shows how objects are linked and the order in which they communicate.
Key Difference:
• Sequence diagrams emphasize time flow (when messages occur).
• Collaboration diagrams emphasize relationships between objects.
A sequence diagram in UML shows how objects interact in a particular scenario by passing messages in a
time-ordered sequence.

Key Components of a Sequence Diagram:

1 Actors – Represent external entities (e.g., users, systems) interacting with the system.
2 Objects – Instances of classes participating in the interaction.
3 Lifelines – Vertical dashed lines showing the existence of objects over time.
4 Activation Bars – Rectangles on lifelines that indicate when an object is active (performing an operation).
5 Messages – Arrows showing interactions between objects.

Example: "Issue Book" Sequence Diagram for a Library Management System (LMS)
Scenario: A student wants to borrow a book, and the system processes the request.
Steps in the Sequence Diagram:
1. Student requests to issue a book.
2. Librarian verifies the student's credentials.
3. Library System checks book availability.
4. If available, the system issues the book and updates records.
5. The student gets a confirmation message.
Collaboration Diagrams (Communication Diagrams) in UML
A Collaboration Diagram (also known as a Communication Diagram) is a type of interaction diagram in UML
that shows how objects interact with each other through messages to achieve a use case or a system
behavior.

Collaboration Diagram for "Return Book" with "Fine Calculation" (Extend Relationship)
Since the Fine Calculation use case extends Return Book, we need to model this in a Collaboration Diagram
by showing:

• Objects involved in the interaction (e.g., Member, ReturnBookController, Transaction,

FineCalculator).
• Messages passed between objects, numbered in order of execution (e.g., 1: checkFine(), 2:
calculateFine()).
• Conditions using guard conditions (e.g., [if member is a student]).
Key Objects:

• Member
• ReturnBookController
• Transaction
• FineCalculator
Flow of Interaction:
1. Return Book Process
o Member returns a book by calling [Link]().
o ReturnBookController checks if the book was borrowed.
2. Fine Calculation (Extended Use Case - Only for Students)
o [if member is a student] → ReturnBookController calls [Link]().
o Transaction determines if a fine is needed.
o If fine is needed, ReturnBookController calls [Link]().
o FineCalculator computes and stores the fine.
o FineCalculator is then destroyed.

Diagram Notation Explanation

• Objects are represented as rectangles with underlined names (e.g., :ReturnBookController).
• Links between objects show associations.
• Numbered Messages show sequence of interactions.
• Guard Conditions ([if student]) define when a message is sent.