Business Parking

Kevin Allen, Ismael Arafath, Bryan Avila and Jesus Ortha

Abstract—The abstract goes here. XI Activity Diagram 4

XI-A Diagram . . . . . . . . . . . . . . . . . 4
C ONTENTS
XI-B Description . . . . . . . . . . . . . . . . 4
I Introduction 2
I-A Purpose . . . . . . . . . . . . . . . . . . 2 XII Object Diagram 4
I-B Scope . . . . . . . . . . . . . . . . . . . 2
XII-A Diagram . . . . . . . . . . . . . . . . . 4
I-C Overview . . . . . . . . . . . . . . . . . 2
XII-B object diagram: as shown in figure The
II General Description 2 system already has variables assigned,
II-A Product Perspective . . . . . . . . . . . 2 the operation basically works in this
II-B Product Functionality . . . . . . . . . . 2 way the employee registers the vehicle
with its respective data after this he
III Constraints 2 makes a record of the entry and exit
date, the reason for the visit and is
IV Assumptions and Dependencies 2 assigned an access ID . . . . . . . . . . 4
V Foreseeable System Evolution 3
XIII Component Diagram 4
VI Functional Requirements 3 XIII-A Diagram . . . . . . . . . . . . . . . . . 4
VI-A Functional Requierment 1 . . . . . . . . 3 XIII-B component diagram: the first diagram
VI-B functional Requierment 2 . . . . . . . . 3 shows the vehicle entry activity where
VI-C functional Requierment 3 . . . . . . . . 3 the safe simulates the system or where
VI-D functional Requierment 4 . . . . . . . 3 the actions are carried out, initially the
VI-E functional Requierment 5 . . . . . . . . 3 employee arrives at the parking lot and
VI-F functional Requierment 6 . . . . . . . 3 requests to enter the parking lot, and the
security checks the system your access
VII Non-Functional Requirements 3 credential, after that the entry of the em-
VII-A Non Functional Requierment 1 . . . . . 3 ployee and the vehicle data are recorded. 5
VII-B Non functional Requierment 2 . . . . . 3
VII-C Non functional Requierment 3 . . . . . 3
VII-D Non functional Requierment 4 . . . . . 3 XIV State Diagram 5
VII-E Non functional Requierment 5 . . . . . 3 XIV-A Diagram . . . . . . . . . . . . . . . . . 5
VII-F Non functional Requierment 6 . . . . . 3 XIV-B State diagram: In the same way as the
VII-G Non functional Requierment 7 . . . . . 3 previous diagram, the action to be car-
VII-H Non functional Requierment 8 . . . . . 3 ried out is to enter the parking lot, hav-
VII-I Non functional Requierment 9 . . . . . 3 ing as a difference the different states
VII-J Non functional Requierment 10 . . . . 3 in which the entry process is carried
out, we begin with the subsequent en-
VIII Use case Diagram 3 try request and the employee’s data is
VIII-A Diagram . . . . . . . . . . . . . . . . . 3 checked. The data is verified and ap-
VIII-B Description . . . . . . . . . . . . . . . . 3 proved as valid to enter, it is processed
to register the vehicle and it passes to
IX Class diagram 4 the registered status, finally the entry
IX-A Diagram . . . . . . . . . . . . . . . . . 4 record and the reason are created and
IX-B description . . . . . . . . . . . . . . . . 4 they end up as registered. . . . . . . . . 5
X Secuence Diagram 4
X-A Diagram . . . . . . . . . . . . . . . . . 4 XV Colaboration Diagram 5
X-B Description . . . . . . . . . . . . . . . . 4 XV-A Diagram . . . . . . . . . . . . . . . . . 5
 XV-B Collaboration diagram: This diagram C. Overview
describes step by step the activity to be This system is being developed to be user-friendly and
carried out in this case, the assignment straightforward, providing a complete atomatization between
of a role, mainly the administrator is the users and this software and the users that will be interacting
only one with the level to perform this with it. We will provide a easy to analize and use interface that
action, first start the system, select the will show all information from vehicular access and users that
role interface, assigns the role id, the are inside each one of them, this preventing from non-intended
role name and the permissions it will users or people that a risk the company.
have and registers the necessary role. . 5
II. G ENERAL D ESCRIPTION
XVI Binnacle 5
A. Product Perspective
XVI-A Purpose . . . . . . . . . . . . . . . . . 5
The Buissness Parking Manager System is a predefined soft-
XVII Screens 5 ware, that it’s designed to be the solution for non-authorized
XVII-A Log in . . . . . . . . . . . . . . . . . . 5 people in the facilities, as well, as managing all information
from users entering the parking. This software is susceptible
XVII-B Main Screen . . . . . . . . . . . . . . . 6
to improvements in future periods
XVII-C Access . . . . . . . . . . . . . . . . . . 6
XVII-D Record . . . . . . . . . . . . . . . . . . 6 B. Product Functionality
XVII-E Rol . . . . . . . . . . . . . . . . . . . . 6 This software will check the entries and exits from the
XVII-F Exit . . . . . . . . . . . . . . . . . . . . 6 parking, this will be implemented by a code scanner or a card
XVII-G Continuous Improvement . . . . . . . . 6 reader , which will send the information of the user to a data
base, as follow the information is stored on the database for
XVIII Data Base 6 futher checking into non-authorized personal.
XVIII-A Collection . . . . . . . . . . . . . . . . 6
III. C ONSTRAINTS
I. I NTRODUCTION • Programming Languages: Since the application will be
developed exclusively for computer usage, we will be

I N this document we have intended to present our first

progress through this subject class that is Programming in
Client-Server Environment. The pourpose of this document is
to detail the funtional and non-functional requierments of the
software we will develope through this course. The software
that in this case will be presented is automatic buissnes parking
manager, that will help with the entrys at the buissnes in all
means.
A. Purpose
For the purpose of this software, it will be registiring vehicle
information, as well as the person in the vehicle entering the
parking, this implementing a credential per employee. We
will also implement a database that will be containing all
the information will be provided for secure management and
reporting all the vehicles at this buissnes.
B. Scope
• Improvment on vehicular access control: This way, we
prevent unauthorized entry.
• Facilitating visitor management.
• History and auditing: A complete history is available that
can be audited if necessary regarding vehicular access
activities.
• Maintaining order within the facilities.
• Improvement on the automatization between the entry and
the information from the vehicle and person in it.
•
using Python as our principal languaje.
Hardware: The system will operate exclusively on a
singular interface, machine to computer interaction, an
employee will check on the computer database for infor-
mation recovery as well, as detailed information of the
service.
• Operating System: The application should be compatible
with recent and popular versions of windows, it’s made
intentionally for windows 10 and foward.
• Specific Standards: All transactions and storage of per-
sonal data must comply with data protection regulations
such as GDPR and other local privacy laws.
• Development Methodologies: An agile methodology,
such as Scrum, will be adopted for software development,
with regular iterations and reviews.
• Platform Limitations: Since Python will be used, the
inherent limitations of our python knowledge platform
must be considered, also as system permissions, and the
variety of devices and screen sizes.
IV. A SSUMPTIONS AND D EPENDENCIES
• Operating System Availability: It’s assumed that the most
recent versions of the mentioned operating systems will
be available and dominant in the market during the
software’s development and release.
• Network Infrastructure: It is presumed that the parking
has a stable and secure network infrastructure, essential
for real-time operations like information consultation.
 • Third-Party Providers: The system might rely on third-
party hardware, that can help with streamline the flow of
information itself.
• User Adoption: It is expected that users (like security
personal), to adopt this system, for easy managment, and
numerous task inside the system.
V. F ORESEEABLE S YSTEM E VOLUTION
• Expansion to Other Locations: If the system y well imple-
mented as well, being functional at it’s work enviroment,
it can be implemented in various facilities from the same
buissnes or reach for other companies.
• Possible to upgrade: We will keep the software managable
for future upgrades, that could be implemented to auto-
mate the process through diferent modes.
VI. F UNCTIONAL R EQUIREMENTS
A. Functional Requierment 1
User Registration: The system must allow users to register
and create personal or company accounts, providing informa-
tion such as name, contact and vehicle details.
B. functional Requierment 2
Entry and Exit: Must be able to efficiently record vehi-
cle entry and exit, whether through key cards, license plate
recognition, or other methods.
C. functional Requierment 3
Access control: It must ensure that only authorized users
have access to the parking facilities, using secure methods
such as access cards.
D. functional Requierment 4
Availability management: It should maintain a real-time
record of available parking spaces and display this information
to users.
E. functional Requierment 5
Reports and Statistics: It should generate reports on park-
ing usage, including data such as average occupancy, generated
revenue, and usage trends.
F. functional Requierment 6
Event registration: the case or event to which the external
authorization was given will be recorded.
VII. N ON -F UNCTIONAL R EQUIREMENTS
A. Non Functional Requierment 1
Security: The system must ensure the security and protec-
tion of user information. It must comply with applicable data
privacy regulations.
B. Non functional Requierment 2
Availability: The system should be available 24/7 to ensure
constant access to the parking area.
C. Non functional Requierment 3
Performance: The system should handle a high volume of
entry and exit transactions without performance degradation.
D. Non functional Requierment 4
Scalability: It should be scalable to accommodate an in-
crease in the number of users and vehicles.
E. Non functional Requierment 5
Usability: The user interface must be intuitive and user-
friendly for both users and administrators.
F. Non functional Requierment 6
Maintenance and Support: There should be a plan for on-
going maintenance and support to address issues and perform
updates.
G. Non functional Requierment 7
Compatibility: The system should be compatible with
various card reader devices.
H. Non functional Requierment 8
Energy Efficiency:If applicable, the system should mini-
mize the energy consumption of the devices used.
I. Non functional Requierment 9
Legal Compliance: The system must comply with local
laws and regulations related to parking and personal data
management.
J. Non functional Requierment 10
Data Backup: Regular data backups should be performed
to prevent the loss of important information.
VIII. U SE CASE D IAGRAM
A. Diagram
B. Description
In the first scenario, the employee requests registration, pro-
vides personal information and vehicle details to be registered
in their name. Security records it in the database and assigns
a parking space, allowing entry to the parking area.
In the second scenario, the employee requests access, pro-
vides an access card, waits for confirmation from security,
accepts entry, and proceeds to the parking area to their
assigned parking space. In the third scenario, the employee
hands over the access card, security records the exit, and the
employee exits the parking area.
 IX. C LASS DIAGRAM
A. Diagram
B. description
The employee is allowed to request access using the pro-
vided access credential, and this same employee, depending
on the situation, provides reasons for the visit, whether it’s an
entry or a visit.
When requesting access, the event is recorded in the system,
including event description and data. Upon entry, the count
of vehicle entries is recorded. The security role, in this case,
security itself, grants or denies access.
X. S ECUENCE D IAGRAM
A. Diagram
B. Description
The employee hands over the access card to the guard,
and the guard checks in the system whether it’s valid in the
database. The system returns the data and either accepts or
denies access, informing the guard. The guard then informs
the employee whether entry has been accepted or not.
XI. ACTIVITY D IAGRAM
A. Diagram
B. Description
In the first activity, The employee arrives at the parking
area. The employee hands over the access credential. Security
scans the card. If access is granted, security informs and allows
entry. If access is denied, the reason is communicated, an event
is recorded, and access is refused.
In the second activity, The employee requests registration.
Security receives the request. Security consults with the com-
pany. If accepted, security requests employee and vehicle
information, assigns a parking space, and issues an access
card. If not accepted, the reason is communicated, access
is denied, and the employee is advised to verify with the
company.
In the third activity, A visitor arrives and requests access.
Security checks if there is a scheduled visit. If there is
a scheduled visit, security asks for the reason, records the
reason, assigns a parking space, and grants access. If there
is no scheduled visit, the visitor is informed, and access is
denied.
XII. O BJECT D IAGRAM
A. Diagram
B. object diagram: as shown in figure The system already has
variables assigned, the operation basically works in this way
the employee registers the vehicle with its respective data after
this he makes a record of the entry and exit date, the reason
for the visit and is assigned an access ID .
XIII. C OMPONENT D IAGRAM
A. Diagram
B. component diagram: the first diagram shows the vehicle
entry activity where the safe simulates the system or where
the actions are carried out, initially the employee arrives at
the parking lot and requests to enter the parking lot, and the
security checks the system your access credential, after that
the entry of the employee and the vehicle data are recorded.
XIV. S TATE D IAGRAM
A. Diagram
B. State diagram: In the same way as the previous diagram,
the action to be carried out is to enter the parking lot, having
as a difference the different states in which the entry process is
carried out, we begin with the subsequent entry request and the
employee’s data is checked. The data is verified and approved
as valid to enter, it is processed to register the vehicle and it
passes to the registered status, finally the entry record and the
reason are created and they end up as registered.
XV. C OLABORATION D IAGRAM
A. Diagram
B. Collaboration diagram: This diagram describes step by
step the activity to be carried out in this case, the assignment
of a role, mainly the administrator is the only one with the
level to perform this action, first start the system, select the
role interface, assigns the role id, the role name and the
permissions it will have and registers the necessary role.
Index Terms—IEEE, IEEEtran, journal, LATEX, paper, tem-
plate.
XVI. B INNACLE
A. Purpose
The purpose is to provide a comprehensive an detailed
information about our process developing this app as well,
showing our incidents and how can we improve futher in
development.This documentation serves as a tool for contin-
uous improvement. By critically analyzing our development
process, we can identify strengths and areas for enhancement.
This introspective approach not only benefits the ongoing
project but also contributes to refining our overall development
practices.
In addition to documenting challenges and successes, this
resource aims to be a reference guide for future projects.
It provides insights into decision-making processes, design
choices, and development strategies, empowering future teams
to make informed decisions based on our experiences.
Week 1 : When designing the login we utilized certain
libraries for the ease of functions. We added a button that
could execute and verify the data in the textboxes, allowing
us to log in and also we used this section to select it from
the folder and place it in that specific part. We placed the
labels on the screen in the same way. For the textboxes,
it was made to show what goes in that textbox to make it
easier for the user, and it disappears when we start typing in it.
Week 2 : When designing the interface, we based it on
a basic registration system for handling this information as
well as immediate query capabilities. Labels were added
to provide context to the user about the actions they can
perform with this application. And the other screens, it
was exactly the same, a reordering and updating of names
and positions, which, likewise, did not cause any incidents.
Instead, it facilitated the programming of them, something
that, once we finish the programming entirely, will probably
have a bit more design added so that they are not so similar,
also adding a background and a more elaborate company logo.
Week 3 : In the creation of the main screen, it shows
6 options, including the option to log out. Clicking on any
button takes us to the corresponding screen, thanks to the call
we make to another file in the same folder.
Week 4 : For the creation of the database, we first
created the eight entities. After this, in each entity, we
created a document and proceeded to fill the entities with
their respective attributes. This process was repeated for each
entity.
XVII. S CREENS
A. Log in
-Incidents: First of all, in order to work on this project, we
had to research how to program with Python using Tkinter,
as we had never done it before or at least not extensively.
The first thing we did was the login, a necessary screen for
most programs to log in with different users. To some extent,
it was easy because the application we used (Visual Studio
Code) indicated when we needed a dependency/library to use
certain functions for program editing.
B. Main Screen
Incidents: The only issue here is that the buttons aren’t fully
displayed depending on the screen resolution where it’s
running. This is resolved by changing the project’s geometry.
C. Access
Incidents: An issue we have here is that when we enter the
data in the text boxes and click the register button, it still
doesn’t show in the viewer we have below the text boxes. We
believe this is due to the lack of a database since we don’t
have a place to register the data.
D. Record
Incidents: The error in creating this screen was that we
first created the content, then attempted to apply the design,
which, upon doing so, wiped out all the content on the screen.
This was resolved by changing the frame of the color we
intended to use.
E. Rol
Incidents: There were no incidents with this screen.
F. Exit
Incidents: There were no incidents with this screen.
G. Continuous Improvement
Lessons Learned: Reflection on incidents and challenges,
extracting key lessons for future projects. Best Practices:
Identification and documentation of successful strategies and
practices employed during development. Feedback Mecha-
nisms: Establishing feedback loops for team members to share
insights, suggestions, and critiques. Design Decisions: Details
on the decisions made during the planning phase regarding the
integration of a database and the overall program architecture.
Database Integration: A step-by-step account of integrating
the database into the application, addressing challenges, and
implementing best practices. User Training: Strategies for user
training to adapt to changes introduced by the integrated
database and refined program design.
XVIII. DATA BASE
A. Collection
The rest of us decided to use mongoDB since it has Data
Schema Flexibility which means that it does not require a
fixed schema like relational databases. This provides flexibility
to adapt to changes in project requirements without needing to
modify the database structure. Another important point why
we selected MongoDB is that it offers a complete set of fea-
tures, such as automatic replication, partitioning, and disaster
recovery, which are essential for client-server environments
seeking high availability and reliability.