Software Engineering & Testing Methodologies

Experiment no 2

Software Requirements Specification (SRS) for Passport Automation System

1.1 Objective
The purpose of this document is to specify the requirements for the Passport Automation
System (PAS). This system aims to streamline the process of passport application, renewal,
and management by automating manual tasks and improving efficiency.

1.2 Scope
The PAS will automate the following processes:
 Application submission
 Document verification
 Payment processing
 Status tracking
 Printing and distribution of passports

1.3 Definitions, Acronyms, and Abbreviations

 PAS: Passport Automation System
 API: Application Programming Interface
 UI: User Interface
 DBMS: Database Management System

1.4 References
 ISO/IEC 27001: Information security management systems
 National Passport Guidelines [Country-specific guidelines]

2. Overall Description
2.1 Product Perspective
The PAS will be a web-based application integrated with a backend database and document
management system. It will provide interfaces for applicants, administrative staff, and
government officials.

1
2.2 Product Functions
The system will support the following functions:
 User registration and authentication
 Passport application submission and tracking
 Document upload and verification
 Payment gateway integration
 Passport issuance and printing

2.3 User Classes and Characteristics

 Applicants: Individuals applying for new passports or renewals. They need a user-
friendly interface to submit applications and track their status.
 Administrative Staff: Responsible for verifying documents, processing applications,
and managing records.
 Government Officials: Review and approve applications and ensure compliance with
regulations.

2.4 Operating Environment

 Client: Web browsers (Chrome, Firefox, Edge)
 Server: Linux-based server environment
 Database: SQL-based DBMS (e.g., MySQL, PostgreSQL)

2.5 Design and Implementation Constraints

 Compliance with local data protection regulations.
 Integration with existing government databases and systems.

2.6 Assumptions and Dependencies

 Availability of reliable internet access for users.
 Integration with external verification services.

3. Specific Requirements
3.1 Functional Requirements
3.1.1 User Registration and Authentication
 Users must be able to register with personal information and verify their identity.
 The system should support password recovery and multi-factor authentication.

2
3.1.2 Passport Application Submission
 Users can fill out and submit passport applications online.
 The system should allow users to upload required documents in various formats.
3.1.3 Document Verification
 Administrative staff should be able to review and verify uploaded documents.
 Integration with third-party verification services for authenticity checks.
3.1.4 Payment Processing
 Integration with a secure payment gateway for processing fees.
 Users should receive confirmation of payment.
3.1.5 Status Tracking
 Applicants should be able to track the status of their application in real-time.
 Notifications via email or SMS for status updates.
3.1.6 Passport Issuance and Printing
 System-generated passport documents must meet government standards.
 Integration with printers for passport issuance.

3.2 Non-Functional Requirements

3.2.1 Performance
 The system should handle up to 10,000 concurrent users.
 Response time for user actions should be less than 2 seconds.
3.2.2 Security
 Data encryption for user information and documents.
 Regular security audits and compliance with data protection regulations.
3.2.3 Usability
 The UI should be intuitive and accessible to users with varying technical skills.
 Support for multiple languages as required.
3.2.4 Reliability
 The system should have an uptime of 99.9%.
 Regular backups and disaster recovery plans.
3.2.5 Maintainability
 The code should follow best practices for documentation and modularity.
 The system should be easily upgradable to accommodate future enhancements.

3
4. External Interface Requirements
4.1 User Interfaces
 Web-based user interface with responsive design.
 Admin dashboard with tools for managing applications and user accounts.
4.2 Hardware Interfaces
 Integration with passport printers.
 Scanners for document verification.
4.3 Software Interfaces
 APIs for payment gateway integration.
 Integration with existing government databases.
4.4 Communications Interfaces
 Support for email and SMS notifications.
 Secure communication protocols for data exchange.

5. Other Requirements
5.1 Legal and Regulatory Requirements
 Compliance with national and international passport regulations.
 Adherence to data protection laws and standards.
5.2 Documentation
 User manuals for applicants and administrative staff.
 Technical documentation for system maintenance and upgrades

4
 Software Engineering and Testing Methodologies - (R1UC502B)

B.Tech (CSE) 2022-23 Sem : V

Lab Experiment 1:
Prepare a Software Requirement Specification (SRS) document in line with the IEEE
recommended standards for Airline Reservation System.

Software Requirements Specification (SRS) Document

1. Introduction

1.1 Purpose
The purpose of this Software Requirements Specification (SRS) document is to provide a
comprehensive description of the Airline Reservation System (ARS). This document will serve
as a guide for the development, validation, and maintenance of the ARS, ensuring all
stakeholders have a clear understanding of the system's requirements.

1.2 Scope
The Airline Reservation System is designed to manage flight reservations, ticketing, and
passenger information. It will support functionalities for booking flights, checking flight
availability, managing user accounts, and generating reports. The system will be used by airline
staff and passengers.

1.3 Definitions, Acronyms, and Abbreviations

- **ARS**: Airline Reservation System
- **UI**: User Interface
- **API**: Application Programming Interface
- **DBMS**: Database Management System
- **CRUD**: Create, Read, Update, Delete

1.4 References
- IEEE Std 830-1998: IEEE Recommended Practice for Software Requirements Specifications
- Airline industry standards and guidelines

1
1.5 Overview
This document is organized into the following sections:
- Introduction
- Overall Description
- Specific Requirements
- Appendices

2. Overall Description

2.1 Product Perspective

The ARS will be a web-based application accessible from both desktop and mobile devices. It
will interact with external systems for payment processing and flight data synchronization. The
system will be built using a three-tier architecture comprising a presentation layer, application
layer, and data layer.

2.2 Product Functions

- **Flight Booking**: Allow users to search for flights, select seats, and book tickets.
- **Flight Management**: Enable airline staff to manage flight schedules, seat availability,
and cancellations.
- **User Management**: Provide functionalities for user registration, login, and profile
management.
- **Payment Processing**: Integrate with payment gateways to process transactions.
- **Reporting**: Generate various reports related to bookings, cancellations, and revenue.

2.3 User Classes and Characteristics

- **Passengers**: Individuals who book flights and manage their bookings.
- **Airline Staff**: Employees who manage flights, seat allocations, and handle customer
support.
- **Administrators**: Users who manage system configurations, user permissions, and overall
system maintenance.

2
2.4 Operating Environment
- **Client**: Web browsers (Chrome, Firefox, Safari, Edge)
- **Server**: Web server (Apache, Nginx), Application server (Java EE, .NET)
- **Database**: Relational DBMS (MySQL, PostgreSQL, Oracle)

2.5 Design and Implementation Constraints

- Compliance with data protection regulations (e.g., GDPR)
- Integration with existing airline databases and payment systems
- Scalability to handle peak loads during high-demand periods

2.6 Assumptions and Dependencies

- Users have access to the internet and a compatible web browser.
- Payment gateway services are available and operational.
- Flight data synchronization with external systems is reliable.

3. Specific Requirements

3.1 Functional Requirements

3.1.1 Flight Booking

- The system shall allow users to search for available flights based on origin, destination, and
date.
- The system shall provide a list of available flights with options for seat selection.
- The system shall enable users to book seats and generate a booking confirmation.

3.1.2 Flight Management

- The system shall allow airline staff to add, update, or delete flight schedules.
- The system shall allow staff to view and manage seat availability and booking status.

3.1.3 User Management

- The system shall provide user registration, login, and password recovery functionalities.
- The system shall allow users to view and update their profile information.

3
3.1.4 Payment Processing
- The system shall integrate with a payment gateway to handle transactions.
- The system shall provide secure payment processing and generate payment receipts.

3.1.5 Reporting
- The system shall generate reports on bookings, cancellations, and revenue.
- Reports shall be available in various formats (e.g., PDF, CSV).

3.2 Non-Functional Requirements

3.2.1 Performance
- The system shall support up to 10,000 concurrent users.
- Response time for flight search queries shall be under 3 seconds.

3.2.2 Security
- The system shall implement SSL encryption for data transmission.
- User data shall be stored securely with access control mechanisms in place.

3.2.3 Usability
- The system shall have an intuitive and user-friendly interface.
- The system shall provide help documentation and customer support features.

3.2.4 Reliability
- The system shall have an uptime of 99.9% and provide backup and recovery solutions.

3.2.5 Maintainability
- The system shall be designed for easy maintenance and updates.
- Code shall follow standard coding practices and be documented thoroughly.

4
3.3 Interface Requirements

3.3.1 User Interfaces

- The system shall provide a web-based UI for both passengers and airline staff.
- The UI shall be responsive and accessible on various devices.

3.3.2 Hardware Interfaces

- The system shall be compatible with standard server hardware and network configurations.

3.3.3 Software Interfaces

- The system shall interface with external payment gateways and flight data services.
- The system shall use RESTful APIs for integration with other services.

3.3.4 Communication Interfaces

- The system shall support HTTP/HTTPS for communication between clients and servers.
- Email notifications shall be sent for booking confirmations and updates.

4. Appendices

4.1 Glossary
- **Booking Confirmation**: An email or notification sent to users confirming their flight
reservation.
- **Seat Allocation**: The process of assigning a specific seat to a booked flight.

4.2 Analysis Models

- **Use Case Diagrams**: Illustrating the interactions between users and the system.
- **Data Flow Diagrams**: Depicting the flow of information within the system.

5
4.3 Issues
- Potential issues related to integration with third-party systems.
- User feedback and system performance monitoring.

This SRS document provides a comprehensive outline of the Airline Reservation System's
requirements. Each section ensures that all stakeholders have a clear understanding of
the system's capabilities, constraints, and interfaces.

6
Lab Experiment 4:

Draw the data flow diagrams at level 0 and level 1 for GU Examination Board.

Tools:
 Microsoft Visio

DFD
 In Software engineering DFD (data flow diagram) can be drawn to represent the system
of different levels of abstraction.
 It is a graphical representation of data flow in any system.
 It is capable of illustrating incoming data flow, outgoing data flow and store data.
 Data flow diagram describes anything about how data flows through the system.

Levels in Data Flow Diagram (DFD)

DFDs can be divided into different levels, which provide varying degrees of detail about the
system.
Level 0 Data Flow Diagram (DFD)
 Level 0 is the highest-level Data Flow Diagram (DFD), which provides an overview of
the entire system.
 It shows the major processes, data flows, and data stores in the system, without
providing any details about the internal workings of these processes.
1-Level Data Flow Diagram (DFD)

 1-Level provides a more detailed view of the system by breaking down the major
processes identified in the level 0 Data Flow Diagram (DFD) into sub-processes.

2-Level Data Flow Diagram (DFD)

 2-Level provides an even more detailed view of the system by breaking down the sub-
processes identified in the level 1 Data Flow Diagram (DFD) into further sub-
processes.

1
 3-Level Data Flow Diagram (DFD)
 3-Level is the most detailed level of Data Flow Diagram (DFDs), which provides a
detailed view of the processes, data flows, and data stores in the system.

Session management

Exam management course management

Examination
management
system
Student management System user
management

Login management

Zero level DFD Exam management system

2
Student management Generate Student
report

Class management Generate class report

Examination
management
system
Branch management Generate branch
report

login management Check user login

details

System user Generate system user

management report

First level DFD Exam Management System

3
4
 Experiment No:5
Title Design the Use case diagram, Class Diagram, Activity diagram, Sequence diagram for
ATM Operations.
Objective To draw Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project assigned to you.
Software Online Visual Paradigm/ IBM Rational Rose XDE
Algorithm/ A use case diagram in UML helps to show the various ways in which a user could interact with
Theory a system. For ATM, the use case diagram helps visualize the interactions between users (actors)
and the system’s functionalities (use cases). This diagram provides a clear, simplified way to
understand how the system operates and what it offers to its users.

What is a Use case diagram?

Use Case Diagram, referred to as a Behavior model or diagram. It simply describes and displays
the relationship or interaction between the users or customers and providers of the application
service or the system. It describes different actions that a system performs in collaboration to
achieve something with one or more users of the system. A use-case diagram is used a lot
nowadays to manage the system.

Use Case Diagram Notations

Use Case Diagram consists of the following components:

1. Actor: Actors are external entities that interact with the system. These can include users,
other systems, or hardware devices. In the context of a Use Case Diagram, actors initiate
use cases and receive the outcomes.
2. Use Case: Use cases are like scenes in the play. They represent specific things your
system can do.
3. System Boundary: The system boundary is a visual representation of the scope or limits
of the system you are modeling. It defines what is inside the system and what is outside.

Use Case Diagram for ATM System

Automated Teller Machine (ATM) also known as ABM (Automated Banking Machine) is a
banking system. This banking system allows customers or users to have access to financial
transactions. These transactions can be done in public space without any need for a clerk,
cashier, or bank teller. Working and description of the ATM can be explained with the help of
the Use Case Diagram.

We will understand about designing the use case diagram for the ATM system. Some scenarios
of the system are as follows.
• Step-1:
The user is authenticated when enters the plastic ATM card in a Bank ATM. Then enters
the user’s name and PIN (Personal Identification Number). For every ATM transaction,
a Customer Authentication use case is required and essential. So, it is shown as include
relationship.
 Example of use case diagram for Customer Authentication is shown below:

Step-2:
User checks the bank balance as well as also demands the mini statement about the bank
balance if they want. Then the user withdraws the money as per their need. If they want
to deposit some money, they can do it. After complete action, the user closes the session.
Example of the use case diagram for Bank ATM system is shown below:

Step-3:
If there is any error or repair needed in Bank ATM, it is done by an ATM technician.
ATM technician is responsible for the maintenance of the Bank ATM, upgrades for
hardware, firmware or software, and on-site diagnosis.
Example of use case diagram for working of ATM technician is shown below:

Class Diagram for ATM

In Object – Oriented modelling , the main building block generally represents different objects
in a system, their attributes, their different functions, and relationships among objects. These
building blocks are known as Class Diagram.

Class diagrams are generally used for conceptual modeling of static view of a software
application, and for modeling translating models into programming code in a detailed manner.
At time of developing or construction software systems, a class diagram is widely used. They
are also used for data modeling. It is used to show classes, relationships among them, interface,
association, etc. Class in a class diagram simply is a blueprint of an object. It simply describes
and explains different type of objects in system, and different types of relationships that exist
between them.

Class Diagram for ATM:

Class Diagram of ATM:

Activity diagram for ATM

The activity diagram used to describe flow of activity through a series of actions. Activity
diagram is a important diagram to describe the system. The activity described as an action or
operation of the system.

Activity Diagram ATM

Sequence Diagram

A sequence diagram is the most used interaction diagram.

Conclusion: Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project was drawn successfully by following the steps described above.
Lab Experiment 3:
Prepare an entity relationship diagram for any school at Galgotias University.

Tools:
 Microsoft Visio / LucidChart.

ER Model:
 An Entity-Relationship Model represents the structure of the database with the help of
a diagram.
 ER Modelling is a systematic process to design a database as it would require to analyze
all data requirements before implementing the database.

Symbols Used in ER Diagrams

 Rectangles: This Entity Relationship Diagram symbol represents entity types

 Ellipses: This symbol represents attributes
 Diamonds: This symbol represents relationship types
 Lines: It links attributes to entity types and entity types with other relationship types
 Primary key: Here, it underlines the attributes
 Double Ellipses: Represents multi-valued attributes

1
2
1. ER Diagram for Student Management System

3
2. ER Diagram for Examination Process

4
3. ER Diagram for University Management System

5
 Experiment No:7
Title Design the Use case diagram, Class Diagram, Activity diagram, Sequence diagram,
Component diagram, Deployment Model for railway reservation system.
Objective To draw Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project assigned to you.
Software Online Visual Paradigm/ IBM Rational Rose XDE
Algorithm/ A use case diagram in UML helps to show the various ways in which a user could interact
Theory with a system. For our project, the use case diagram helps visualize the interactions between
users (actors) and the system’s functionalities (use cases). This diagram provides a clear,
simplified way to understand how the system operates and what it offers to its users.

What is a Use case diagram?

Use Case Diagram, referred to as a Behavior model or diagram. It simply describes and
displays the relationship or interaction between the users or customers and providers of the
application service or the system. It describes different actions that a system performs in
collaboration to achieve something with one or more users of the system. A use-case diagram
is used a lot nowadays to manage the system.

Use Case Diagram Notations

Use Case Diagram consists of the following components:

1. Actor: Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices. In the context of a Use Case Diagram,
actors initiate use cases and receive the outcomes.

2. Use Case: Use cases are like scenes in the play. They represent specific things your
system can do.

3. System Boundary: The system boundary is a visual representation of the scope or

limits of the system you are modeling. It defines what is inside the system and what is
outside.

Below is the use case diagram of a railway reservation system.

Class Diagram for railway reservation system.
Activity diagram for railway reservation system.

The activity diagram used to describe flow of activity through a series of actions. Activity
diagram is an important diagram to describe the system. The activity described as an action or
operation of the system.

Activity Diagram railway reservation

system.

Sequence Diagram for railway reservation system.

A sequence diagram is the most used interaction diagram.

Conclusion: Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project was drawn successfully by following the steps described above.
 Experiment No:6
Title Design the Use case diagram, Class Diagram, Activity diagram, Sequence diagram for GU
library Management System.
Objective To draw Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project assigned to you.
Software Online Visual Paradigm/ IBM Rational Rose XDE
Algorithm/ A use case diagram in UML helps to show the various ways in which a user could interact with
Theory a system. For a Library Management System, the use case diagram helps visualize the
interactions between users (actors) and the system’s functionalities (use cases). This diagram
provides a clear, simplified way to understand how the system operates and what it offers to its
users.

What is a Use case diagram?

Use Case Diagram, referred to as a Behavior model or diagram. It simply describes and displays
the relationship or interaction between the users or customers and providers of the application
service or the system. It describes different actions that a system performs in collaboration to
achieve something with one or more users of the system. A use-case diagram is used a lot
nowadays to manage the system.

Use Case Diagram Notations

Use Case Diagram consists of the following components:

1. Actor: Actors are external entities that interact with the system. These can include
users, other systems, or hardware devices. In the context of a Use Case Diagram, actors
initiate use cases and receive the outcomes.
2. Use Case: Use cases are like scenes in the play. They represent specific things your
system can do.
3. System Boundary: The system boundary is a visual representation of the scope or
limits of the system you are modeling. It defines what is inside the system and what is
outside.

Use Case Diagram for Library Management System

Let us visually map out the relationships and interactions. Below is the textual description of
what the diagram would look like:

1. Actors:
• User (Staff or Student)
• Librarian
2. Use Cases:
 • Register New User
• Issue Library Card
• Request New Book
• Reserve Book
• Renew Book
• Pay Fine
• Fill Feedback Form
• Manage Records
• Delete Records
• Update Database

3. System Boundary:
• The system boundary will encompass all the use cases mentioned above.

Below is the use case diagram of a Library Management System

Explanation of Use Case Diagram of a Library Management System

We will understand the designing use case diagram for the library management system. Some
scenarios of the system are as follows:

1. User who registers himself as a new user initially is regarded as staff or student for the
library system.
• For the user to get registered as a new user, registration forms are available that
is needed to be fulfilled by the user.
• After registration, a library card is issued to the user by the librarian. On the
library card, an ID is assigned to cardholder or user.
2. After getting the library card, a new book is requested by the user as per there
requirement.
3. After, requesting, the desired book or the requested book is reserved by the user that
means no other user can request for that book.
 4. Now, the user can renew a book that means the user can get a new due date for the
desired book if the user has renewed them.
5. If the user somehow forgets to return the book before the due date, then the user pays
fine. Or if the user forgets to renew the book till the due date, then the book will be
overdue and the user pays fine.
6. User can fill the feedback form available if they want to.
7. Librarian has a key role in this system. Librarian adds the records in the library database
about each student or user every time issuing the book or returning the book, or paying
fine.
8. Librarian also deletes the record of a particular student if the student leaves the college
or passed out from the college. If the book no longer exists in the library, then the record
of the book is also deleted.
9. Updating database is the important role of Librarian.

Class Diagram for Library Management System

In Object – Oriented modelling , the main building block generally represents different objects
in a system, their attributes, their different functions, and relationships among objects. These
building blocks are known as Class Diagram.

Class diagrams are generally used for conceptual modeling of static view of a software
application, and for modeling translating models into programming code in a detailed manner.
At time of developing or construction software systems, a class diagram is widely used. They
are also used for data modeling. It is used to show classes, relationships among them, interface,
association, etc. Class in a class diagram simply is a blueprint of an object. It simply describes
and explains different type of objects in system, and different types of relationships that exist
between them.

Class Diagram for Library Management System:

Aggregation and Multiplicity are two important points that need to take into consideration while
designing a Class Diagram. Let us understand in detail.

1. Aggregation – Aggregation simply shows a relationship where one thing can exist
independently of other thing. It means to create or compose different abstractions
together in defining a class. Aggregation is represented as a part of relationship in class
diagram. In diagram given below, we can see that aggregation is represented by an edge
with a diamond end pointing towards superclass. The “Library Management System” is
superclass that consists of various classes. These classes are User, Book, and Librarian
as shown in diagram. Further, for “Account” class, “User” is a superclass. All of these,
share a relationship and these relationships are known as aggregate relationships.

2. Multiplicity – Multiplicity means that number of elements of a class is associated with

another class. These relations can be one-to-one, many-to-many, and many-to-one or
one-to-many. For denoting one element we use 1, for zero elements we use 0, and for
many elements we use *. We can see in diagram; many users are associated with many
books denoted by * and this represents a many-to-many type of relationship. One user
has only one account that is denoted by 1 and this represents a one-to-one type of
relationship. Many books are associated with one librarian and this represents many-
to-one or one-to-many type of relationship. All these relationships are shown in
diagram.

Class Diagram for Library Management System simply describes structure of Library
Management System class, attributes, methods or operations, relationship among objects.
Classes of Library Management System:

• Library Management System class – It manages all operations of Library

Management System. It is central part of organization for which software is being
designed.
• User Class – It manages all operations of user.
• Librarian Class – It manages all operations of Librarian.
• Book Class – It manages all operations of books. It is basic building block of system.
• Account Class – It manages all operations of account.
• Library database Class – It manages all operations of library database.
• Staff Class – It manages all operations of staff.
• Student Class – It manages all operations of student.
Attributes of Library Management System:
• Library Management System Attributes – UserType, Username, Password
• User Attributes – Name, Id
• Librarian Attributes – Name, Id, Password, SearchString
• Book Attributes – Title, Author, ISBN, Publication
• Account Attributes – no_borrowed_books, no_reserved_books, no_returned_books,
no_lost_books fine_amount
• Library database Attributes – List_of_books
• Staff Class Attributes – Dept
• Student Class Attributes – Class
Methods of Library Management System:
• Library Management System Methods – Login (), Register (), Logout ()
• User Methods – Verify (), CheckAccount(), get_book_info()
• Librarian Methods – Verify_librarian(), Search()
• Book Methods – Show_duedt(), Reservation_status(), Feedback(), Book_request(),
Renew_info()
• Account Methods – Calculate_fine()
• Library database Methods – Add (), Delete (), Update (), Display (), Search ()

Class Diagram of Library Management System:

Activity diagram for Library Management System

The activity diagram used to describe flow of activity through a series of actions. Activity
diagram is a important diagram to describe the system. The activity described as a action or
operation of the system.

Activity Diagram Library Management System

Sequence Diagram

A sequence diagram is the most used interaction diagram.

Member-request a book->+ Librarian

Next, the librarian will check the system to see if the book is available. This means an interaction
with the Book object in the library management system. Again, we’ll use a labeled arrow and
the Book object will automatically be created.
Librarian-check availability->Book
If the book is available, the Book object sends a message back to the Librarian object.
Book-available->Librarian

The librarian now needs to validate whether the member can borrow the book from the library.
This is a two-step process of validating membership and also checking the number of books
already issued.
Librarian-validate->Member
Librarian-check no. of issued books->Member
If the member is authorized to borrow the book, the librarian can now issue it.
Librarian-issue a book->Member

The librarian also needs to record the transaction in the library management system, and that
brings us to our final object, Transaction. The Librarian sends a “create” message to Transaction.
The message adds the member and book details to that transaction and it is stored in the database
so that it can be used to check up on the member or book later.
Librarian-<<create>>->Transaction
Librarian-add member and book details->Transaction
The librarian next needs to update the book’s status in the system, so it’s clear that it has been
borrowed and isn’t available until returned. The librarian also needs to update the member’s
record, to indicate that they have borrowed an additional book. That gives us the final lines in
our simple library management sequence diagram.

Final
Conclusion: Use case diagram, Class Diagram, Activity diagram & Sequence diagram of the
project was drawn successfully by following the steps described above.