DELHI TECHNOLOGICAL UNIVERSITY

(Formerly Delhi College of Engineering)

Shahbad Daulatpur, Bawana Road, Delhi 110042

DEPARTMENT OF SOFTWARE ENGINEERING

SE202: Object Oriented Software Engineering
Practical Lab File

Parking Management System

Submitted To: Submitted By:

Ms. Anjali Bansal Madhur Gupta
2K22/IT/97
 INDEX

S.No. EXPERIMENT DATE SIGNATURE

Write the problem statement of Parking

1.
Management System 17-01-2025

Write the Initial Requirements Document (IRD)

2.
of Parking Management System 17-01-2025

Write the Software Requirement Specification

3.
Document of the case study 24-01-2025

Design use case diagram of Parking

4.
Management System 24-01-2025

Write use case description of Parking

5.
Management System 31-01-2025

Draw Class Diagram of Parking Management

6.
System 31-01-2025

Draw Sequence diagram of Parking Management

7.
System 7-02-2025

Draw Collaboration diagram of Parking

8.
Management System 21-03-2025

Draw Activity diagram of Parking Management

9.
System 21-03-2024

Design Test Cases of Parking Management

10.
System 28-03-2024
 EXPERIMENT-1
Aim: Write the problem statement of the case study, i.e., Parking Management System.
Theory:
Title: Development of an E-Parking Management System
Problem Statement:
Since the globe is becoming more and more urbanized, there is an exponential increase in the
need for parking places, which exacerbates traffic, wastes space, and pollutes the
environment. The increasing intricacies of contemporary urban landscapes are too much for
human, error-prone traditional parking management systems to handle. A sophisticated
electronic parking management system (e-parking) is therefore desperately needed in order to
effectively manage parking spots, optimize operations, improve user experience, and support
sustainable urban development.

Key Challenges:
1. Space Utilization Optimization: The poor space distribution in many modern parking
systems results in either excessive or insufficient usage of parking resources. It is
essential to design algorithms and techniques that optimize space use while taking
location, demand patterns, and vehicle sizes into account.
2. User Convenience and Experience: Customers have trouble paying for parking,
locating spaces, and getting into parking lots. It is crucial to create user-friendly
mobile applications and interfaces that make reserving, paying, and navigating
parking lots easy.
3. Integration with Emerging Technologies: Evolving technology like data analytics,
machine learning algorithms, and Internet of Things sensors can improve parking
management's efficacy and efficiency. Nonetheless, there are technological issues that
must be resolved in order to properly incorporate these technologies into the system
architecture.
4. Security and Data Privacy: Robust security measures are necessary for handling
sensitive user data, such as payment information, location data, and vehicle
information, in order to prevent unwanted access and guarantee data privacy. It is
essential to implement access controls, encryption, and compliance with data
protection laws.
5. Scalability and Adaptability: The system should be scalable to accommodate varying
parking demands in different locations and adaptable to evolving urban environments.
 Designing a flexible architecture that can easily accommodate future expansions and
modifications is paramount.
6. Revenue Management: Efficient revenue management is crucial for the sustainability
of parking operations. Implementing dynamic pricing models, optimizing pricing
strategies based on demand patterns, and integrating with payment gateways securely
are essential components of the e-parking management system.
7. Environmental Impact: Parking management systems should contribute to
environmental sustainability by reducing traffic congestion, carbon emissions, and
fuel consumption. Incorporating features such as real-time traffic monitoring,
promoting alternative transportation modes, and encouraging carpooling can mitigate
the environmental impact of parking activities.
Overall, the development of an e-parking management system entails addressing these
challenges comprehensively to create a solution that not only optimizes parking operations
but also enhances the overall urban living experience while promoting sustainability.
 EXPERIMENT-2
Aim: Draw the Initial Requirements Document (IRD) of the case study i.e. “Parking
Management System (HPMS)”.

Initial Requirement Document:

Title of Project Parking Management System

Stakeholders Management Team, Developers, System Administrators, Parking

Attendants, End Users (Vehicle Owners), Regulatory Authorities

Techniques ● Interviews with stakeholders

Used
● Surveys and feedback collection

● Analysis of existing parking management systems

● Review of industry standards and best practices

Name of 1. HEAD ADMIN

Person/
2. PQR/Developer
Designation
3. ABC/Customer
4. XYZ/Parking Assistant
Date 13th April, 2024

Version 1.0.0

Consolidated 1. User Management:

List of Initial
Requirements ● Registration and authentication for users (admins,
attendants, vehicle owners).
 ● Role-based access control to manage permissions.

2. Parking Space Allocation:

● Visualization of available parking spaces.

● Reservation system for users to book parking slots.

3. Vehicle Entry and Exit Management:

● Automated vehicle detection at entry/exit points.

● Issuance of digital tickets upon entry for exit validation.

4. Payment Processing:

● Support for multiple payment methods (cash, cards, mobile

wallets).

● Real-time processing and issuance of digital receipts.

5. Real-time Monitoring and Reporting:

● Dashboard for administrators to monitor occupancy,

revenue, and system health.

● Automated alerts for system failures or anomalies.

● Comprehensive reporting tools for analysis.

6. Security and Compliance:

● Robust encryption and authentication mechanisms.

● Compliance with data privacy regulations.

7. Usability and Accessibility:

● Intuitive user interfaces for easy navigation.

● Accessibility features for users with disabilities.

8. Scalability and Reliability:

● Ability to handle large volumes of users and parking

spaces.

● High availability and uptime to minimize disruptions.

9. Integration and Compatibility:

● Integration with existing hardware (entry/exit gates, ticket

dispensers).

● Compatibility with mobile applications for user

convenience.
10. Training and Support:

● Provision of training materials and sessions for system

administrators and users.

● Ongoing technical support and maintenance services.

EXPERIMENT-3
Aim: Write the Software Requirement Specification Document of the case study i.e.
‘Parking Management System’.

Theory:
SOFTWARE REQUIREMENT SPECIFICATION:
TABLE OF CONTENTS FOR SRS DOCUMENT:

1. Introduction
1.1. Purpose
1.2. Scope
1.3. Definitions, Acronyms and Abbreviations
1.4. References
1.5. Overview

2. Overall Description
2.1. Product perspective
2.1.1. System Interfaces
2.1.2. User Interfaces
2.1.3. Hardware Interfaces
2.1.4. Software Interfaces
2.1.5. Communication Interfaces
2.1.6. Memory Constraints
2.1.7. Operations
2.1.8. Site Adaptation Requirements
2.2. Product Functions
2.3. User Characteristics
2.4. Constraints
2.5. Assumptions for dependencies

1. Introduction
 E-Parking management system for keeping track of vehicles entering and leaving a
parking garage.
It's an easy way for Admin to retrieve the data if the vehicle has been visited through
number, he can get that data.
Vehicle parking is a major issue in many public venues these days, including malls,
multiplexes, hospitals, offices, and markets. The vehicle parking area offers numerous
lanes/slots for cars. To park a vehicle, one must search for all lanes. Furthermore, this
requires a significant amount of manual labor and investment. Instead of being towed, the
vehicle can be parked safely and securely for a modest payment.
The parking control system has been designed in such a way that it includes a variety of
secure devices such as parking control gates, toll gates, time and attendance machines, and
automobile counting systems. These elements are therefore extremely important nowadays
to safeguard your vehicles and to assess the charge structure for each vehicle's entry and
leave.
The goal of this project is to create a Vehicle Parking Management System that allows for
the time management and control of automobiles through number plate recognition. The
system that tracks car entry and exit, keeps a list of cars in the parking lot, and determines
if the parking lot is full or empty. It will calculate the cost of each car based on its time
usage.

1.1 Purpose
We can pay to park our vehicle in our own slot.
• There are no issues with towing.
• Our vehicle has been parked securely.
• Vehicle owners are not at risk when parking their cars.
• Parking management will handle claims for car damages and problems.
• As the world is facing many threads dally, robberies are done easily with no track
to trace, bomb blasts occur with the use of vehicle, so if a proper system is
adopted, each record can be saved and anyone can be tracked easily. Therefore, the
main goal is to make a better and faster software, most importantly user-friendly.
• Maintain records in short time of period.
• Determines the parking area is full or not.
• Enhances the visitor's experience

1.2 Document Conventions

• The main Chapter headings are given with font: Times and font size of 18.
• The Subheadings of each chapter are given with font: Times and size of 14.
• Emphasize is given in Italics.
• Critical information in specific scenario is given in Bold Words
• When composing this report, it was acquired that all necessities have a similar
need. First there is introduced a general view about E-PMS and afterward all
elements and capacities are investigated exhaustively.
When composing this report, it was acquired that all necessities have a similar need. First a
general view about E-PMS is introduced and afterwards all elements and capacities are
investigated exhaustively.

1.3 Intended Audience and Reading Suggestions

 This prerequisite record contains general data about E- PMS, capacities, highlights,
and unique advancements. It portrays exhaustively all that E- PMS requires to work
appropriately and with wellbeing.
 Developers: To be sure, they are developing the right project that fulfils requirements
provided in this document.
 Testers: to have an exact list of the features and functions that must respond according
to requirements and provided diagrams.
 Users: to get familiar with the idea of the project and suggest other features that
would make it even more functional.

1.4 Product Scope:

In the modern era. Many people own autos. A vehicle is now a basic requirement. Every
place is in the process of urbanization. There are numerous corporate headquarters, shopping
malls, hospitals, schools, and government agencies. As a result, all of these locations require
a parking area where people can park their cars safely and easily. Every parking lot requires a
system that records the details of the vehicles that use the facility. These systems may be
computerized or non-computerized. We can provide good service to customers who wish to
park their vehicles on the premises of any firm by using a computerized system. Vehicle
parking management systems are automatic systems that handle data at fast speeds in a
systematic manner. The development of this technology is quite useful in this field. We can
sell this solution to any organisation. They may effortlessly manage their records utilizing our
system. Our system covers all aspects of parking management. Vehicle parking management
systems will become increasingly important in the future. Its purpose is to address an issue
that frustrates many sellers today: the management of parking places within a parking story.
As a result, it provides you with a very basic arrangement for managing parking spaces,
allowing you to navigate approaching and active automobiles. Parking Management System
is close to monitoring openings.
1.5 References
 www.google.co.in
 www.w3schools.com
 www.youtube.com
 www.DocFoc.com
 www.SlideShare.com
 www.codeproject.com

2. Overall Description:
2.1 Product Perspective
PMS ought to have the option to give an essential and simple exchange of data.
For example, it ought to have the option to eliminate the correspondence holes between a
representative and the client. It ought to be viable with every one of the working frameworks.

2.2 Product Functions

The PMS login box ought to on the intranet.
• The secret key field ought to be secured
• By tapping on the dropdown box of the choices the worker ought to have the option to
see reports and accessible slots.
• Employee ought to have the option to change the passwords.
• There are a lot of functions in E-PMS. These functions can be placed into broader
categories as follows:
✔ Security over performance

✔ Efficiency over functionality

✔ Accessibility in all aspects

✔ Lightweight and elegant

2.3 User Classes and Characteristics

A client can just have his/her worker ID number as username so assuming he joins the
parking MS then no one but he can login. This forestalls abuse, unapproved access and
hacking of the item.

2.4 Design and Implementation Constraints

The server limit refers to the number of customers who may access or be online immediately.
The greater the number of clients, the greater the organization's traffic, and the server will
eventually go down. Individual firewall and refreshing are arduous tasks that must be
completed in such a way that they do not impede business flow, slowing down the system.
As an operating system, the major constraint for PMS will be hardware and its performance.
There are several trivial and non-trivial constraints, which are from both development
perspective and context perspective. Some of them are listed as follows;
 Memory of the device
 Cope with boot up procedures of different manufacturers
 Precise exception handling for both hardware and software
 Prevent deadlock during applications execution (Prioritize core tasks

2.5 Assumptions and Dependencies

PMS should work even when the organization's traffic is heavy. Servers should have both
power and data backups. The PMS should be compatible with a wide range of functioning
frameworks, including the previous and most recent ones.
 EXPERIMENT-4
Aim: Design use case diagram of ‘Parking Management System’.
Theory:
A use case diagram is a visual representation of a user's engagement with the system,
demonstrating the relationship between the user and the many use cases in which the user is
involved. A use case diagram represents a system's dynamic behaviour. It captures the
system's functionality by incorporating use cases, actors, and their interactions. It represents
the activities, services, and functions required by a system/subsystem of an application. It
displays the system's high-level functionality as well as how the user interacts with it.

A use case diagram is typically used to portray the dynamic aspects of a system. It gathers the
system needs, depicted external view of system, recognized the internal as well as external
factors that influenced the system and represented the interaction between actors.
This diagram consists of following components –
 Actors: The users that interact with a system. An actor may be a person,
 an organization or an outside system that interacts with application or
 system and they appear outside the rectangle.
 Use Case: It is a list of actions or event steps, typically defining the
 interactions between a role/actor and a system, to achieve a goal. These
 use cases are represented within rectangle providing functionality.
 Relationships: It is basically a solid line that describes the relationship
 between actors and use case or between the use cases.

USE CASE DIAGRAM:

 EXPERIMENT-5
Aim: Write use case description of ‘Parking Management System’.
Theory:
Use case descriptions provide detailed narratives of interactions between actors (users or
systems) and the system being developed, outlined within a use case diagram. They describe
the functionality, preconditions, postconditions, and flow of events for each use case, serving
as a crucial reference for understanding system behaviour and requirements.

Use Case Description:

Use Case: Manage Users and Full Application
Actor: Super Admin
Description: The Super Admin utilizes this use case to manage user accounts within the
parking management system. This includes tasks such as creating new user accounts,
modifying existing accounts, and deactivating or deleting accounts as necessary. The Super
Admin has full administrative privileges and can perform all user management functions.
Preconditions:
1. The Super Admin must be authenticated and authorized to access the user
management functionality.
Postconditions:
1. New user accounts are created, with appropriate permissions assigned.
2. Existing user accounts are modified as per the Super Admin's instructions.
3. Accounts may be deactivated or deleted if deemed necessary.
Flow of Events:
1. The Super Admin accesses the user management section of the parking management
system.
2. The system presents options for managing users, including creating, modifying, or
deactivating accounts.
3. For creating a new user: a. The Super Admin provides necessary details such as
username, password, and permissions. b. The system validates the information and
creates the new user account.
4. For modifying an existing user: a. The Super Admin selects the user account to be
modified. b. The Super Admin updates the account details as required. c. The system
saves the changes to the user account.
5. For deactivating or deleting an account: a. The Super Admin selects the user account
to be deactivated or deleted. b. The system prompts for confirmation. c. Upon
confirmation, the account is either deactivated or deleted, depending on the Super
Admin's choice.
6. The Super Admin exits the user management section, and the system returns to the
main interface.
Exceptional Flows:
1. If the Super Admin enters invalid information when creating or modifying a user
account, the system displays an error message and prompts for correction.
2. If the Super Admin attempts to deactivate or delete a user account that is currently in
use or has associated data, the system displays a warning message and prompts for
confirmation.

Use Case: Manage Cars

Actor: Super Admin
Description:
The Super Admin utilizes this use case to manage cars registered within the parking
management system. This includes tasks such as adding new vehicles, modifying existing
vehicle information, and removing vehicles from the system.
Preconditions:
1. The Super Admin must be authenticated and authorized to access the car
management.
Postconditions:
1. New cars are added to the system with their relevant details.
2. Existing car information is updated as per the Super Admin's instructions.
 3. Cars may be removed from the system if required.
Flow of Events:
1. The Super Admin accesses the car management section of the parking management
system.
2. The system presents options for managing cars, including adding, modifying, or
removing vehicles.
3. For adding a new car:
a) The Super Admin provides the necessary details such as license plate number,
make, model, and owner information.
b) The system validates the information and adds the new car to the system.
4. For modifying an existing car:
a) The Super Admin selects the car to be modified.
b) The Super Admin updates the car details as required.
c) The system saves the changes to the car information.
5. For removing a car:
a) The Super Admin selects the car to be removed from the system.
b) The system prompts for confirmation.
c) Upon confirmation, the car is removed from the system.
6. The Super Admin exits the car management section, and the system returns to the
main interface.
Exceptional Flows:
1. If the Super Admin enters invalid information when adding or modifying a car, the
system displays an error message and prompts for correction.
2. If the Super Admin attempts to remove a car that is currently parked or associated
with any active reservations, the system displays a warning message and prompts for
confirmation.

Use Case: Manage Parking Slots

Actor: Super Admin
Description:
The Super Admin employs this use case to oversee and control parking slots within the
system. This encompasses tasks such as adding or removing parking slots, modifying slot
configurations, and updating availability statuses. The Super Admin has full authority to
adjust parking slot allocations according to changing requirements, ensuring efficient
utilization of parking resources and optimal user experience.
Preconditions:
1. The Super Admin must be authenticated and authorized to access the parking slot
management functionality.
Postconditions:
 1. Changes to parking slot configurations are saved and reflected in the system.
2. Parking slot availability statuses are updated accordingly.
Flow of Events:
1. The Super Admin accesses the parking slot management section of the parking
management system.
2. The system presents options for managing parking slots, including adding, modifying,
or removing slots.
3. For adding a new parking slot:
a. The Super Admin provides the necessary details such as slot number, location,
size, and availability status.
b. The system validates the information and adds the new parking slot to the
system.
4. For modifying an existing parking slot:
a. The Super Admin selects the parking slot to be modified.
b. The Super Admin updates the slot details as required.
c. The system saves the changes to the parking slot information.
5. The Super Admin exits the parking slot management section, and the system returns
to the main interface.
Exceptional Flows:
1. If the Super Admin enters invalid information when adding or modifying a parking
slot, the system displays an error message and prompts for correction.
2. If the Super Admin attempts to remove a parking slot that is currently occupied or
associated with any active reservations, the system displays a warning message and
prompts for confirmation.

Use Case: Search Parking

Actor: Customer
Description:
Customers utilize this use case to search for available parking slots within the parking
management system. They input search criteria such as location, time, and preferred features.
The system then retrieves and displays relevant parking options, allowing customers to select
and reserve a suitable spot, enhancing convenience and efficiency in finding parking.
Preconditions:
1. The customer must be authenticated and authorized to access the parking search
functionality.
Postconditions:
1. The customer receives search results displaying available parking slots meeting the
specified criteria.
Flow of Events:
 1. The customer accesses the parking search feature within the parking management
system.
2. The system prompts the customer to input search criteria, such as location, time, and
parking preferences.
3. The customer enters the desired search parameters.
4. The system retrieves and displays relevant parking options based on the specified
criteria.
5. The customer reviews the search results and selects a preferred parking slot.
6. The system confirms the selection and prompts the customer to proceed with the
reservation.
7. If the customer chooses to reserve the parking slot, the system initiates the reservation
process.
8. The customer receives confirmation of the reservation.
Exceptional Flows:
1. If no parking slots meet the specified criteria, the system notifies the customer and
suggests alternative options.
2. If there are technical issues or errors during the search process, the system displays an
error message and prompts the customer to try again.

Use Case: Allot Parking

Actor: Customer
Description:
Customers employ this use case to allocate a parking slot for their vehicle within the parking
management system. After selecting a suitable parking option from the search results,
customers confirm the reservation and proceed to allot the parking slot to their vehicle. This
process ensures that customers secure a designated parking space for their convenience.
Preconditions:
1. The customer must have completed the search for available parking slots and selected
a preferred option.
Postconditions:
1. The parking slot is successfully allotted to the customer's vehicle.
2. The customer receives confirmation of the parking reservation.
Flow of Events:
1. After selecting a parking slot, the customer confirms the reservation.
2. The system prompts the customer to provide vehicle details, such as license plate
number.
3. The customer enters the required vehicle information.
4. The system validates the information and assigns the parking slot to the customer's
vehicle.
5. The system confirms the successful allotment of the parking slot.
Exceptional Flows:
1. If there are technical issues or errors during the allotment process, the system displays
an error message and prompts the customer to try again.
2. If the selected parking slot becomes unavailable due to simultaneous reservations, the
system notifies the customer and suggests alternative options.

Use Case: Check Charges

Actor: Customer
Description:
Customers utilize this use case to check the charges associated with their parking reservation
within the parking management system. After parking their vehicle, customers can access the
system to view the accrued charges based on the duration of their parking stay, enabling them
to plan and budget accordingly.
Preconditions:
1. The customer must have an active parking reservation.
Postconditions:
1. The customer receives information about the charges incurred for the parking
reservation.
2. The customer may proceed with payment if required.
Flow of Events:
1. The customer accesses the parking management system to check charges.
2. The system prompts the customer to input reservation details or login credentials.
3. The customer provides the necessary information.
4. The system retrieves the parking reservation details and calculates the charges based
on the duration of the parking stay.
5. The system displays the accrued charges to the customer.
6. The customer reviews the charges and decides whether to proceed with payment.
Exceptional Flows:
1. If there are technical issues or errors during the charge calculation process, the system
displays an error message and prompts the customer to try again.
2. If the customer encounters discrepancies in the displayed charges, they can contact
customer support for assistance.
Associated Use cases: Pay Parking Fees

Use Case: Manage Parking Space

Actor: System User
Description:
System users utilize this use case to oversee and control parking spaces within the parking
management system. This includes tasks such as updating parking availability, modifying
space configurations, and handling maintenance or repairs. Users ensure that parking spaces
are accurately represented and efficiently managed to meet user demand and operational
requirements.
Preconditions: The system user must be authenticated and authorized to access parking space
management functionality.
Postconditions:
1. Changes to parking space configurations are saved and reflected in the system.
2. Parking availability statuses are updated accordingly.
3. Maintenance or repairs are scheduled and executed as required.
Flow of Events:
1. The system user accesses the parking space management section of the parking
management system.
2. The system presents options for managing parking spaces, including updating
availability, modifying configurations, or scheduling maintenance.
3. For updating parking availability:
a) The system user selects the parking space to be updated.
b) The user adjusts the availability status based on changes in occupancy.
c) The system saves the updated availability status.
4. The system user exits the parking space management section, and the system returns
to the main interface.
Exceptional Flows:
1. If there are technical issues or errors during the management process, the system
displays an error message and prompts the user to try again.
2. If the system user attempts to update a parking space that is currently occupied or
reserved, the system displays a warning message and prompts for confirmation.
 EXPERIMENT-6
Aim: Draw Class Diagram of “Parking Management System (PMS)”
Theory:
The class diagram depicts a static representation of an application. It displays the many types
of objects in the system and their relationships. A class is made up of objects and can inherit
from other classes. This diagram is used to represent, describe, and document numerous parts
of the system, as well as to create executable software code.

It stores class names, characteristics, and functions in a distinct compartment, which aids in
software development. A structural diagram is one that consists of classes, interfaces,
affiliations, collaborations, and constraints. The primary goal of class diagrams is to create a
static view of an application. It is the only diagram that is commonly used in construction and
can be mapped to object-oriented languages. It is among the most used UML diagrams.

Parking Management System Class Diagram helps in describing the structure of a Parking
Management System classes, their attributes, operations (or methods), and the relationships
among objects. The main classes of the Parking Management System include Vehicle,
Parking Ticket, Parking space, Parking Price, Parking Lot, Accounts.

Class Diagram:
 EXPERIMENT – 7
Aim: Draw Sequence diagram of “Parking Management System (PMS)”.
Theory:
A sequence diagram simply displays the order in which things interact with one another. A
sequence diagram may also be referred to as event diagrams or event scenarios. Sequence
diagrams show how and in what order the objects in a system operate. These diagrams are
commonly used by businesspeople and software developers to document and comprehend
requirements for new and current systems.

It aids in visualizing various dynamic circumstances. It depicts communication between any

two lifelines as a time-ordered sequence of events, implying that these lifelines participated
during the run period.

In UML, the lifeline is represented by a vertical bar, whereas the message flow is represented
by a vertical dotted line that extends across the bottom of the page. It incorporates the
iterations as well as branching.
Uses of sequence diagrams –
• Used to model and visualise the logic behind a sophisticated function, operation or
procedure.
 • They are also used to show details of UML use case diagrams.
• Used to understand the detailed functionality of current or future systems.
• Visualise how messages and tasks move between objects or components in a system.

Sequence Diagram:
a) Login

b) Parking slots and Type Management

c) Customer parks vehicle

 EXPERIMENT – 8
Aim: Draw Collaboration diagram of “Parking Management System (PMS)”.
Theory:
A collaboration diagram, also called a communication diagram, depicts the links and
interactions between software objects in the Unified Modelling Language (UML). These
diagrams can be used to depict the dynamic behaviour of a certain use case and to define the
roles of each object. The sequence diagram and the cooperation diagram both convey the
same information, but they do it differently.

Instead, then depicting the flow of messages, it illustrates the architecture of the objects in the
system because it is based on object-oriented programming. An object is made up of several
different aspects. Multiple things in the system are linked to one another.
The collaboration diagram is used to portray the object's architecture in the system.
Following is some of the use cases enlisted below for which the collaboration diagram is
implemented:
1. To model collaboration among the objects or roles that carry the functionalities of
use cases and operations.
2. To model the mechanism inside the architectural design of the system.
 3. To capture the interactions that represent the flow of messages between the objects
and the roles inside the collaboration.
4. To model different scenarios within the use case or operation, involving a
collaboration of several objects and interactions.
5. To support the identification of objects participating in the use case.

Collaboration Diagram

EXPERIMENT – 9
Aim: Draw Activity diagram of your case study i.e. “Parking Management System (PMS)”.
Theory:
An activity diagram is a behavioural diagram, which depicts the behaviour of a system. An
activity diagram depicts the control flow from a starting point to a finishing point,
highlighting the many decision routes that exist while the activity is being performed. An
activity diagram allows us to display both sequential and concurrent processing of activities.
They are used in business and process modelling where their primary use is to depict the
dynamic aspects of a system.
Some of the most common components of an activity diagram include:
• Action: A step in the activity wherein the users or software perform a given task. In
Lucid chart, actions are symbolized with round-edged rectangles.
• Decision node: A conditional branch in the flow that is represented by a diamond. It
includes a single input and two or more outputs.
• Control flows: Another name for the connectors that show the flow between steps in
the diagram.
 • Start node: Symbolizes the beginning of the activity. The start node is represented by a
black circle.
• End node: Represents the final step in the activity. The end node is represented by an
outlined black circle.

a) Login and Manage users and Vehicles

b) Parking Reservation
c) Customer Login and Parking Payment
d) Check Vacancy

e) Reserve For Parking

f) Parking Cancellation

g) Pay Annual Parking Fee

 EXPERIMENT – 10
Aim: Design Test Cases of “Parking Management System (PMS)”.
Theory:
Test cases are essential components of any testing activity. The creation and execution of test
cases when source code is accessible assures that a robust, defect-free, and high-quality
system is built. Testing is an important and ongoing process that occurs throughout the
software development lifecycle.
Commonly used Testing Terminology:
• Test case: A test case may execute a particular path of the program or verify a given
requirement of the system. A test case consists of inputs given to the program and its
expected outputs from the program.
• Test suite: A test suite consists of set of test cases. Test suite may consist of set of
successful test cases and set of unsuccessful test cases.
• Test design and procedure: Test design and procedure consists of detailed set of
instruction for setting, designing and interpreting the results for a given test case.
• Test coverage: Test coverage defines the extent to which the test cases are covered
by a given test for a given use case, class or system.
• Test results: Test results are a repository in which all the results and data produced
during the execution of a program are kept.

Test Cases:
1. LOGIN
 2. Search For Parking Slot

Test Scenario Name and Input 1 Input 2 Expected Remark

Case Description Output
Vehicle Expected
Id
Type Duration
TC1 Scenario 1: Valid Valid Slot
Searched
Search For Parking Slots
Successfully
TC2 Scenario 2: Valid Invalid Duration is Expected
invalid Duration
Search For Parking Slots
is invalid
(Invalid Entry)
TC3 Invalid Valid Vehicle Type of
Type is Vehicle
cannot
Invalid
be
parked
TC4 Invalid Invalid Both vehicle Both
and vehicle
duration is and
invalid duration
is invalid
TC5 Scenario 3: Valid Valid No Vehicle
Available leaves
Search For Parking Slots
Slot the
(Parking full)
system
3. Reserve Parking and Pay Charges
Test Scenario Input 1 Input 2 Input 3 Expected Remark
Case Name And Output
User Vehicle Paymen
Id Description
Name Number t
Details
TC1 Scenario 1: Valid Valid Valid Vehicle
Parked
Park vehicle
Successfully
and pay
charges
TC2 Scenario 2: Valid Invalid Valid Vehicle Invalid
number is vehicle
Park Vehicles
invalid number
and pay
entered
Charges
TC3 (Invalid Invalid Valid Valid User name User
Entry) is does not
exist
Invalid
TC4 Valid Valid Invalid Payment Payment
Details are details
invalid not
verifiable
TC5 invalid invalid valid Both user User
name and does not
vehicle exist
number are
invalid
TC6 valid Invalid invalid Vehicle Vehicle
number number
and entered
payment is wrong
details are and
invalid wrong
payment
details
TC7 invalid valid invalid User name User
and does not
Payment exist
Details are
invalid
 TC8 invalid invalid invalid All data User
entered is does not
invalid exist
TC9 Scenario 3: valid valid valid Transaction Payment
not failed
Park Vehicles
successful
and pay
Charges
(Payment Not
Successful)

4. Manage Users and Parking Space

Test Scenario Input 1 Input 2 Input 3 Expected Remark
Case Name and Output
User Vehicle Expect
Id Description
Name Type ed
Durati
on
TC1 Scenario 1: Valid Valid Valid Verified users
and vacant slots
User list and
displayed
vacant slots
TC2 Scenario 2: Valid Invalid Valid Vehicle type is Invalid
invalid vehicle
User list and
type
vacant slots
entered
(Invalid
TC3 Entry) Invalid Valid Valid User name is User
does not
Invalid
exist
TC4 Valid Valid Invalid Expected Expected
duration is duration
invalid invalid
TC5 invalid invalid valid Both user name User
and vehicle type does not
are invalid exist
TC6 valid Invalid invalid Vehicle type Vehicle
and duration is type
invalid entered
is wrong
TC7 invalid valid invalid User name and User
expected does not
 duration is exist
invalid
TC8 invalid invalid invalid All data entered User
is invalid does not
exist
TC9 Scenario 3: valid valid valid Slots have been
updated
User list and
vacant slots
(Update slots)
TC10 Scenario 3: valid Valid/ Valid/ User
Information has
User list and Invalid Invalid
been updated
vacant slots
(Update user)