Chapter -1

Object Oriented Fundamentals

Object oriented System

The system where overall architecture is perceived as a collection of objects that are assigned
specific responsibilities and hence exhibit their behavior based on the type of responsibility
assigned to them.

Steps in object oriented system

I. Identification of objects existing in a domain

II. Assigning responsibilities to these objects
III. Seek collaboration between these objects for fulfilling the goal of the system

Elements of object oriented system

I. Objects
- An object is an instance of a class.
- Example: student, Teacher, Patient, Doctor, Bank account etc.
II. Attributes

They describe information about the object.

III. Class

A class encapsulates the data and its behavior.

IV. Method

Methods determine the behavior of a class. They are nothing but an action or operations that
an object can perform.

V. Message

A message is a function call or procedure call from one object to another. They are information
sent to object to trigger method.
Features of Object Oriented System

a. Encapsulation

Encapsulation is a process of information hiding. It is simply the combination of process and

data into a single entity. Data of an object is hidden from the rest of the system and available
only through the services of the class. It allows improvement or modification of methods used
by object without affecting other parts of a system.

b. Abstraction

It is the process of taking or selecting necessary method and attributes to specify the object. It
focuses on essential characteristics of an object relative to perspective of users. Example: If you
wish to withdraw money from ATM, the only concern is to receive money and not the internal
working of ATM.

c. Relationships
All the classes in the system are related with each other. The object do not exist in isolation,
they exist in relationship with other objects.

There are three types of object relationships

Aggregation
It indicates relationship between a whole and its parts.
Association
In this two classes are related or connected on some way such as one class works with another
to perform a task ir one class acts upon other class.
Generalization
The child class is based on parent class. It indicate that two classes are similar but have some
differences

d. Inheritance

Inheritance is a great features that allows to create sub – classes from an existing class by
inheriting the attributes and operations of existing classes.

e. Polymorphism

Polymorphism is the ability to take on many different forms. It applies to both object and
operations. A polymorphic object is one who true type hides within a super or parent class.

In polymorphic operation, the operation may be carried our differently by different classes of
objects. It allows is to manipulate objects of different classes by knowing only their common
properties.
Structured Approach Vs Object – Oriented Approach

Structured Approach Object – Oriented Approach

It works with Top – Down approach. It works with Bottom – up approach.
Program is divided into number of Program is organized by having number of
submodules or function. classes and object.
Function call is used. Messaging passing is used.
Software reuse is not possible. Reusability is possible.
Structured design programming usually left Object oriented design programming done
until end phases. concurrently with other phases.
Structured design is more suitable for It is suitable for in – house development.
offshoring.
It shows clear transition from design to Not so clear transition from design to
implementation. implementation.
DFD and E – R diagram model the data. Class diagram, sequence diagram, state
diagram, use case diagram etc all contribute.

Decomposition

It is the process of partitioning the problem domain into smaller parts so that the overall
complexity of the problem can be comprehended and tackled easily (divide and conquer
approach)

Basically there are two types of decomposition

- Algorithmic / Functional decomposition

Dividing the problem domain into smaller parts by focusing on the functionalities that the
system provides. For example functionalities of a Library Management System may include
issue_book, return_book, search_book

- Object Oriented Decomposition

Dividing the problem domain into smaller parts by focusing on the objects with specific
responsibilities that form the system. For example, objects in a Library Management System
may include IssueManager, Book, Librarian.

What is Analysis and Design?

Analysis emphasizes an investigation of the problem and requirements, rather than a

solution. For example, if a new computerized library information system is desired, how will
it be used?
 Design emphasizes a conceptual solution that fulfills the requirements, rather than its
implementation. For example, a description of a database schema and software objects.

What is object – oriented Analysis and object – oriented Design?

Object – oriented Analysis

- During object-oriented analysis, there is an emphasis on finding and describing the objects—
or concepts—in the problem domain.
- For example, in the case of the flight information system, some of the concepts include plane,
flight and pilot.
- OO analysis is to identify objects of a system to be designed.
- It is a method of analysis that examines requirements from the perspective of the classes and
objects found in the vocabulary of the problem domain.
- Object oriented analysis can be defined as a structured process of investigation and in – depth
investigation of the problem domain is done during this phase by asking the WHAT questions
(rather than HOW solution is achieved).

Object – oriented Design

- The next step after completing the analysis of the requirement is to translate it to the design
of the proposed system.
- During object-oriented design, there is an emphasis on defining software objects and how
they collaborate to fulfill the requirements.
- For example, a plane software object may have a tailNumber attribute and a getflightHistory
method
- After the introduction of OO design, the consideration for the reusability has got high focus.
- With the popularity of the OO language like c++ and java the code with which the design and
the code can be mapped with each other increased manifold creating the way for automatic
code generation from the design itself.
- A in - depth investigation of the problem domain is done during this phase by asking the HOW
question (How solution is achieved?)
Difference between Object – oriented analysis and Object – oriented Design

Object – Oriented Analysis Object – Oriented Design

Methodology with an emphasis on finding and Methodology with an emphasis on defining
describing the objects or concepts in the software objects and how they collaborate to
problem domain. fulfill requirement.
Elaborate a problem Provide conceptual solution
WHAT type of question asked “What the HOW type of question asked. “” How the
problem is about and what the system must problem is solved and how are the system
do?” goal achieved.
Performed by Performed by
Use Case Interaction Diagrams
Domain Model Design Class Diagram (DCD)
System Sequence Diagram (SSD)
What is required in the Library Information How is Authentication in the Library
System? Information System achieved.
Ans: Authentication Ans: Smart card or fringer print
 Models in OODM

We describe these above modules by giving simple example of a “dice game” in which software
simulates a player rolling two dice, It the total is seven they win otherwise they lose.

I. Define Use Case

- Requirement analysis may include stories or scenarios of how people use the application,
these can be written as use cases.
- Use cases are pictorial representation of the scenarios for clearly capturing the system
requirements.
- Use – cases model captures the goal of the user and the responsibility of the system to its
users

For example

Play a Dice game use case

- Player request to roll the dice.

- System presents results: if the dice face value total seven, players wins otherwise player loses.
-
II. Define a Domain Model
- Object oriented analysis is concerned with creating description of the domain from the
perspective of object.
 - There is an identification of the concepts, attributes and associations that are considered
noteworthy.
- The result can be expressed in a domain model.

For example

Note

A domain model is not a description of software objects. It is a visualization of the concept or

mental model of a real world domain. Thus, it has also been called a conceptual object model.

III. Define Interaction Diagram

- Object oriented design is concerned with defining software object their responsibilities and
collaborations.
- A common notation to illustrate these collaborations is the sequence diagram ( a kind of UML
interaction diagram)
- It shows the flow of message between software objects and thus the invocation of methods.
 - The sequence diagram in above figure illustrate an OO software design by sending message
to instances of the DiceGame and Die classes.

IV. Define Design class Diagram

- In addition to a dynamic view of collaborating object shown in interaction diagram, a static
view of the class definition is usefully shown with a design class diagram.
- This illustrate the attributes and methods of the classes.
- For example, in the dice game, an inspection of the sequence diagram lead to the partial
design class diagram. Since play message is sent to a DiceGame object, the DIceGame class
requires a play method, while class Die requires a roll and getface value method.

Note

The design class diagram is not the same as the domain model class names and content are
similar.
Requirement

Capabilities and conditions to which the system and more broadly, the project must conform a
prime challenge of requirements work (fact finding) is to find, communicate, and record what is
really needed, in a form that clearly speaks to the client and development team members.

Types of requirements:

Functional (Behavioral)

calculations, technical details, data manipulation and processing and other specific functionality

Non - Functional (EVERYTHING ELSE)

It is also known as quality requirements, which impose constraints on the design or

implementation (such as performance requirements, security, cost and reliability).

Types of requirements

FURPS +

An acronym representing a model for classifying software quality attributes (functional &

non-functional requirement)

Functionality—features, capabilities, security.

Usability—human factors, help, documentation.

Reliability—frequency of failure, recoverability, predictability

Performance/ Productivity—response times, throughput, accuracy, availability, resource usage

Supportability—adaptability, maintainability, internationalization, configurability.

The "+" in FURPS+ indicates ancillary and sub-factors, such as:

Implementation—resource limitations, languages and tools, hardware, ...

Operations—system management in its operational setting.

Packaging Legal—licensing and so forth.

Requirement Process

1. Fact Finding and Requirements Elicitations

In order to identify all relevant requirements analysts must use a range of techniques:-

• Fact-Finding Overview
– First, you must identify the information you need
– Develop a fact-finding plan

Fact finding can be done through Document review, observation, questionnaire, surveys,
sampling, research.

2. Interviewing
The analyst starts by asking context-free questions;
- a set of questions that will lead to a basic understanding of the problem, the people who
want a solution, the nature of the solution desired, and the effectiveness of the first
encounter itself.
Structured Questioning Techniques usually lead by software engineer :
- why are we building this system
- who are the other users
- determine critical functionality

3. Open – ended questions

- useful when not much is known yet , broad-oriented, free of context.
- examples "describe X " tell me what you do

4. Closed – ended questions

- when enough about the system is known try to ask specific questions
- example "how often should sales reports be generated?”

Try to proceed from open-ended to closed-ended questions!!

Find out who else to interview

– who else uses the system

– who interacts with you
– who will agree / disagree with you

5. Facilitated Application Specification Technique (FAST)

Facilitated Application Specification Techniques (FAST), this approach encourages the creation of
a joint team of customers and developers who work together to identify the problem, propose
elements of the solution, negotiate different approaches, and specify a preliminary set of
requirements.

The idea is to overcome we/them attitude between developers and users team-oriented
approach

Guidelines

– participants must attend entire meeting

– all participants are equal
– preparation is as important as meeting
– all pre-meeting documents are to be viewed as “proposed”
– off-site meeting location
– set an agenda and maintain it
– don’t get mired in technical detail

Unified Process

A software development process describes an approach to building, deploying and possibly

maintaining software. The unified process has emerged as a popular iterative software
development process for building object – oriented systems. In particular, the Rational Unified
Process or RUP, a detailed refinement of the Unified Process has been widely adopted.

Because the Unified Process (UP) is a relatively popular iterative process for projects using OOA/D
and because some process must be used to introduce the subject, the UP shapes the book’s
structure. Also, since the UP is common and promotes widely recognized best practices, it’s
useful for industry professionals to know it, and students entering the workforces to be aware of
it.

The UP is very flexible and open and encourages including skillful practices from other iterative
methods such as from Extreme Programming (XP), Scrum and so forth.

Summarize

1. The UP is an iterative process. Iterative development influences how this book introduces
OOA/D and how it is best practiced.
2. UP practices provides an example structure for how to do – and thus how to explain – OOA/D.
That structure shapes the book structure.
3. The UP is flexible and can be applied in a lightweight and agile approach that includes
practices from other agile methods.

Phases of UP

1. Inception
 Approximate vision, business case, scope, vague estimate.
 Inception is not a requirement phase; rather it is a feasibility phase, where just enough
investigation is done to support a decision to continue or stop.
 During the inception phase, the basic idea and structure of the project is determined. The
team will sit down and determine if the project is worth pursuing at all.
 It establishes business cases system, all the external entities people and system that will
interact with the system are identified and define these interactions.
 Based on the proposed purpose of the system, the estimated costs and what resources will
be required to complete the project once the green light is given.

2. Elaboration
 Refined vision, iterative implementation of the core architecture, resolution of high risks,
identification of most requirements and scope, more realistic estimates.
 Elaboration is not the requirements or design phase; rather, it is a phase where the core
architecture is iteratively implemented and high – risk issues are mitigated.
 This phase develop an understanding of the problem domain, establish an architectural
framework for the system develop the project plan and identify key risks.
 The purpose of the elaboration phase is to analyze the requirements and
necessary architecture of the system.
 The success of this phase is particularly critical, as the final milestone of this phase signifies
the transition of the project from low – risk to high - risk.

3. Construction
 Iterative implementation of the remaining lower risk and easier elements and preparation for
deployment.
 The construction phase is essentially concerned when the design, coding and testing of all
application features will take place.
 This period is also where integration with other services or existing software should occur.
The end of the construction phase is measured by the completion of the initial
operational capability milestone, which is based on these criteria:

 Is this product release stable and mature enough to be deployed in the

user community?
 Are all stakeholders ready for the transition into the user community?
 Are the actual resources expenditures versus planned expenditures will acceptable?

4. Transition
 Beta tests, deployment
 This phase is concerned with moving the system from development community to user
community and making it work in real environment.
 However, the transition phase is more than just the process of deployment; it
must also handle all post – release support, bug fixes, patches and so forth.
 The product release milestone signals the end of the transition phase and is based on a few
simple question:

 Is the user satisfied?

 Are the actual resources expenditures versus planned expenditures still acceptable?

UP Disciplines
There are several discipline in the UP; some artifact in the following three:
 Business Modeling: The Domain Model artifact, to visualize noteworthy concepts in the
application domain.
 Requirement: The use case model and supplementary specification artifacts to capture
functional and non functional requirement.
 Design: The design model artifact, to design the software objects.
 In above figure, during one iteration work goes on in most or all disciplines. The relative effort
across these disciplines changes over time. Early iteration naturally tend to apply greater
relative emphasis to requirements and design and later one less.

Relationship between the disciplines and phases

 Relating disciplines to the UP phases illustrate the changing relative effort with respect to the
phases.
 Here in elaboration, the iteration tend to have a relatively high level of requirements and
design work, although definitely some implementation as well.
 During construction the emphasis is heavier on implementation and lighter on requirements
analysis.
Use cases: Describing processes

 Use case is a collection of related success and failure scenarios that describe an actor using a
system to support a goal.
 It is a narrative document that describes the sequence of events of an actor (an external
agent) using a system to complete a process.
 The essence is discovering and recording functional requirements by writing stories of using
a system to help fulfill various stakeholder goals.

Actor

 It is an entity that is external to the system, who in some way participates in the story of Use
Case.
 An actor physically stimulates the system with input events or receives something form it.
 An actor is anything with behavior, including the system under discussion itself when it call
upon the services of other systems. Eg, a cashier
 Actors are represented by the role they play in the Use Case.

Actors can include

 Roles that people play

 Computer system
 Electrical or Mechanical Devices
Types of actor

a. Primary Actor: has user goals fulfilled through using services of the system under discussion.

E.g Cashier

These are identified to find user goal that drive the use cases.

b. Supporting Actor: provide service or information to the system.

E.g Automated Payment Authorization

These are identified to clarify external interfaces and protocols.

c. Offstage Actors: has interest in the behavior of the use case.

E.g Government Tax Agency.

These are identified to ensure all interests are identified and satisfied.

Scenario:

 A scenario is a specific sequence of actions and interactions between actors and the system
under discussion; it is also called a use case instance.
 A use case is a collection of related success and failure scenarios that describes an actor using
system to support a goal.
 Use cases are functional or behavioral requirements that indicate what the system will do.
 For example, the scenario of successfully purchasing items with cash or the scenario of failing
to purchase items because of a credit payment denial.

Handle Returns

Main Success Scenario

A customer arrives at a checkout with item to return. The cashier uses the POS system to record
each returned item……

Alternate Scenarios

If the customer paid by credit and the reimbursement transaction to their credit account is
rejected, inform the customer and pay them with cash.
If the item identifier is not found in the system, notify the cashier and suggest manual entry of
the identifier code.

If the system detects failure to communicate with the external accounting system……

Now that scenario (use case instance) are defined, an alternate, but similar definition of a use
case provided by the RUP will make better sense:

A set of use – case instances, where each instance is a sequence of actions a system performs
that yields an observable result of value to a particular actor.

Types: Essential VS Concrete / Real Use cases

Essential Use cases

 All expanded use cases, remain relatively free of technology and implementation details
 Design decisions are deferred and abstracted. That is only essential activities and motivations.
 High level use cases are always essential in nature due to their brevity and abstraction.

Actor Action System Response

1 The customer identifies themselves 2 Present options
3 and so on 4 and so on

Concrete / Real Use cases:

 Concretely describes the process in terms of its real current design, committed to specific I/O
technology etc.
 This helps the designer to identify what task the interaction diagram may fulfill, in addition
to what is in contract.

Actor Action System Response

1 The customer inserts their card 2 Prompts for PIN
2 Enter PIN on key pad 3 Display options menu
5 and so on 6 and so on
For Example

Essential Use Case

Actor Action System Response

1 The Cashier records the identifier. If there 2 Determines the item price from each item
is more than one of the same item, the Cashier and adds the item information to the running
can enter the quantity as well. sales transaction
3 and so on 4 and so on

Concrete / Real Use Case

Actor Action System Response

1 For each item, the cashier types in the 2 Displays the item price adds the item
Universal Product Code (UPC) in the UPC input information to the running sales transaction.
field of window1. They the press the “Enter The description and price of the current item
item” button with the mouse OR by Pressing are displayed in Textbox2 of windows.
the key.

Process Sale:

A customer arrives at a checkout with items to purchase. The cashier uses the POS (point of sale)
system to record each purchased item. The system presents a running total and line – item
details. The customer enters payment information, which the system validates and records. The
system updates inventory. The customer receives a receipt from the system and then leaves with
the items.

Use Case Formats

Use cases can be written in different formats and levels of formality.

- Brief
- Casual
- Fully Dressed

Brief

 Terse one – paragraph summary, usually of the main success scenario.

 It describes a process very briefly, usually in two or three sentences.
 It is useful to create this type of use case during the initial requirements and project scoping
in order to quickly understand the degree of complexity and functionally in a system.
 They are very terse and vague on design decision.
 Example: Process Sale

Casual

 Informal paragraph format. Multiple paragraphs that cover various scenarios.

 It is useful during early requirements analysis, to get a quick sense of subject and scope.

Example: Handle Return

Fully dressed

 All steps and variations are written in detail and there are supporting sections, such as
preconditions and success guarantees.
 Fully dressed use cases shows more detail and are structured; they dig deeper.
 In iterative and evolutionary UP requirement analysis, 10% of the critical use cases would be
written this way during the first requirements workshop. Then design and programming
starts on the most architecturally significant use cases or scenarios from that 10% set.

Template of fully dressed use cases

Example

Use Case: Process Sale

Scope: NextGen POS application

Level: user goal
Primary actor: Cashier
Stakeholders and Interests
- Cashier: Wants accurate, fast entry, and no payment error, as cash drawer shortages are
deducted from his/ her salary
- Salesperson: Wants sales commissions updated.
- Customer: wants purchase and fast service with minimal effort. Wants easily visible display
of entered items and prices. Wants proof od purchase to support returns.
- Manager: wants to be able to quickly perform override operations and easily debug cashier
problem.
- Government Tax Agencies: Want to collect tax from every sale. May be multiple agencies,
such as national, state and country.
- Payment: wants to receive digital authorization requests in the correct format and
protocol. Wants to accurately account for their payables to the store.

Precondition: Cashier is identified and authenticated

Success Guarantee (Postconditions): Sale is saved. Tax is correctly calculated. Accounting and
inventory are updated. Commission recorded. Receipt is generated. Payment authorization
approvals are recorded.

Main Success Scenario (or Basic Flow)

1. Customer arrives at POS checkout with goods and/or services to purchase.
2. Cashier starts a new sale
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price and running total.
5. System presents total with taxes calculated.
6. Cashier tells total to customer and ask for payment.
7. Customer pays and system handles payment.
8. Systems logs completed sale and sends sale and payment information to the external
accounting system and inventory system for update.
9. System present receipt.
10. Customer leaves with receipt and goods.
(if any)
Extension (alternative flows)
Technology and Data variation List:
 Item identifier entered by bar code scanner(is bar code is present) or keyboard.
 Item identifier may be any UPC, EAN, JAN or SKU coding scheme.
 Credit account information entered by card reader or keyboard.
 Credit payment signature captured on paper receipt.
 Credit card reader.

Frequency of Occurrence: Could be nearly continuous

Open Issues:
 What are the tax law variations?
 Explore the remote service recovery issue.
 What customization is needed for different businesses?
  Must a cashier take their cash drawer when they log out?
 Can the customer directly use the card reader, or does the cashier have to do it?

Guidelines for Defining Use Cases

Step 1: Choose the system boundary

Step 2: Identify the primary actors

Step 3: Identify goal for each primary actors

Step 4: Define use case

Choose the system boundary

 It is just a software application, the hardware and application as a unit, that plus a person
using it or an entire organization?

For example, The POS system itself is the system under design. If the definition of the boundary
of the system under design is not clear, it can be clarified by further definition of what is outside
(the external actor and supporting actor)

Is the complete responsibility for payment authorization within the system boundary?

 No, there is an external payment authorization service actor.

Identify the primary actor and Identify goal for each primary actor

It is more difficult to identify the primary actors before user goals in a requirement workshop,
people brainstorm and generate a mixture of both. Sometimes, goal reveal the actor or vice
versa.

Here are some questions to identify primary actors and goals

1. Who starts and stops the system?

2. Who does user and security management?
3. Is there a monitoring process that restarts the system if it fails?
4. Who evaluates system activity or performance?
5. Who gets notified when there are errors or failures?

There are two approach to organize actors and goals

 As you discover the results, draw them in a use case diagram, naming the goals as use cases.
 Write an actor – goal list first, review and refine it and then draw the use case diagram.

For example

Actor Goal
Cashier Process sales,
Process rentals,
Handle returns,
Cash in,
Cash out
Manager Start up,
Start down
System Administration Add users,
Modify users,
Delete users,
Manage security,
Manage system tables
Sales Activity System Analyze sales and performance data
Etc,

Another way to find actors, goal and use cases is to identify external events. What are they,
where from and why? Often, a group of events belong to the same use case. For example

External Event From Actor Goal / Use Case

Enter sale line item Cashier Process a sale
Enter payment Cashier or customer Process a sale

Define Use Cases

In general, define one use case for each user goal. Name the use case similar to the user goal.

For example:

Goal  process a sale;

Use case  Process sale

Start the name of use cases with a verb

A common exception to one use case per goal is to collapse CRUD (create, retrieve, update,
delete) separate goals into one CRUD use case, idiomatically called Manage <X>. For example,
the goals “edit user”, “delete user” and so forth are all satisfied by the Manage Users use cases.

System and their boundaries

A use case describes interaction with the system. Typical boundaries includes

- Hardware/software boundary of a device or computer system.

- Department of an organization.
- Entire organization

The system boundary is important as it identifies:

- What is external versus internal

- The responsibilities of the system

Scenario one:

If we choose the entire store or business as the system then the only customer is an actor not
the cashier because the cashier acts as a resource within the business system.
Scenario two:

If we choose the point of sale hardware and software as the system both cashier as well as
customer may be treated as actors.

Use Case Terminology

(Relationships in use case / Reusing use case)

Include

 When a use case is depicted as using functionality of another functionality of another use
case, this relationship between the use cases is named as an ―include‖ or ―uses‖
relationship.
 A use case includes the functionality described in another use case as a part of its business
process flow.
 The include relationship adds additional functionality not specified in the base use case. The
<> relationship is used to include common behavior from an included use case into a base
use case in order to support re-use of common behavior.
 An include relationship is depicted with a directed arrow having a dotted line. The tip of
arrowhead points to the child use case and the parent use case connected at base of the
arrow.
 The stereotype "<>" identifies the relationship as an include relationship.
Extends

 The extend relationships are important because they show optional functionality or system
behavior. The <> relationship is used to include optional behavior from an extending use case
in an extended use case.
 Indicates that an "Invalid Password" use case may include (subject to specified in the
extension) the behavior specified by base use case "Login Account".
 Depict with a directed arrow having a dotted line. The tip of arrowhead points to the base
use case and the child use case is connected at the base of the arrow.
 The stereotype "<>" identifies as an extend relationship

Generalization

 A generalization relationship is a parent – child relationship between use cases.

 The child use case is an enhancement of the parent use case.
 Generalization is shown as a directed arrow with a triangle arrowhead.
 The child use case is connected at the base of the arrow. The tip of the arrow is connected to
the parent use case.
Example: Library Management System
Fully Dressed use cases of Issue Book use case

Use case: Issue Book

Scope: NextGen Library Application

Level: User Goal

Primary Actor: Librarian

Stakeholders and Interests:

 Student: Wants to borrow a book efficiently, with minimal wait time and receive a due date
remainder.
 Librarian: Wants to issue book for users with accurate record – keeping to avoid disputes or
errors.
 Library System: Ensures book are correctly entered into the students name, want to maintain
accurate inventory records, track borrowed books.
 Fine: Concerned with ensuring fines for late returns or lost

Preconditions:

 The librarian is identified and authenticated.

 The student is registered and has no fines or overdue books.

Success Guarantee (Postconditions):

The book’s status is updated to “issued” in the library system. The borrowing record of the
student is updated. Book’s due date for return is set. The count of the book is adjusted in the
inventory.

Main Success Scenario

 Student arrives at checkout desk with books to issue.

 Librarian start new book renew.
 The librarian checks the student’s account for validity and ensure no books overdue.
 The librarian scan the book’s barcode.
 The system validates the books information.
 The system updates the book’s status including book, user, issue date and due date.
 The librarian hand’s over the book to the student.
 The student leave library with books
Extension

- Student has Fines or overdue books:

 The system notifies the librarian of the fine and overdue.
 The librarian informs the student about the fines or overdue book.
 The student resolves the fine or returns overdue books.
- System Fails to validate books information
 The system encounters an error while validating the book’s information.
 The librarian manually checks the book details and updates the system accordingly.
- System Fails to update book status
 The system encounters an error while updating the book’s status
 The librarian manually records the transaction and updates the system later.
 The librarian confirms the update with the student.

Technology and Data Variations List

 The library system use barcode for quick book identification.

 Student information: ID, borrowing history, fines
 Book information: Title, author, ISBN, current status, due date.

Frequency of occurrence

 Student does not renew books and not pay the fine.
 Handling lost or damaged books during the borrowing period.