Object and Data Modelling: Functional and Non-Functional Requirements, Use Case Modeling, UML Domain Model Class Diagram, Activities of SDLC

This article discusses the functional and non-functional requirements, use case modeling, UML domain model class diagram, and activities of SDLC for Collin's Parking Car Park System. It also includes a bibliography.

Running head: OBJECT AND DATA MODELLING
Object and Data Modelling
Name of the Student
Name of the University

1OBJECT AND DATA MODELLING
Table of Contents
1. Functional and Non-Functional Requirements: 2
1.1 Functional Requirements: 2
1.2 Non-Functional Requirements: 3
2. Use Case Modeling: 4
3. UML Domain Model Class Diagram: 8
Activities of SDLC: 9
Bibliography: 11

2OBJECT AND DATA MODELLING
1. Functional and Non-Functional Requirements:
1.1 Functional Requirements:
i. Message Showing: The system will need to show various messages and responses
to the customer request through the display, installed in the pillars. When the user
will appear at the pillar, the system will sense the presence of the car and show
relevant messages and options.
ii. Authentication: The authentication is process of verifying a user. The system will
read the ticket and retrieve the details from the database. If the ticket is valid then
only the customer will be authenticated to enter the parking area.
iii. Authorization: The authorization is the process of validating the user request. The
system will have various authorization levels which will separate the fixed
customer requests from the ordinary customer requests. All these authorizations
will be done within the core of the system. The customer identification will be
done using the ticket.
iv. Payment handle: The system will handle the payment process. In case of fixed
customers, the system will be taking all the charges for the ticket at the time of
generating. The card is provided to the ticket reader device and the payment will
be deducted. In case of ordinary customers, the system will calculate the charge
and the payment needs to be done through card or cash.
v. Report Generating: The system will be generating reports based on the stored
data and information. These reports can be accessed by the organization’s
executive management only. The system will create report weekly, monthly and

3OBJECT AND DATA MODELLING
yearly basis. This reports will be stored in the system for a long time so that it can
be available to the management for a long period.
vi. Data Storing: The system will collect input from the customer and various
hardware devices and store those input data into the system database. The data
storing will be done through various checks and validation processes.
1.2 Non-Functional Requirements:
i. Availability: The system will be available for providing service 24*7. The
customers can come to park their cars at any hour of the day. In order to maintain
the system availability, the organization will be appointing an expert to maintain
the system functionality.
ii. Recoverability: The system will be equipped with a disaster recovery technique.
In case all the data and the magnetic tapes are destroyed, the organization will be
able to collect all the data from the disaster recovery approach.
iii. Scalability: Scalability refers to the capability of the system coping with the
business requirements. The system will be using resources based on the frequency
of the car appearing. In order to boost the profit, the system will be generating
forecasting reports that will allow the management to identify when more
resources are required. Through proper scalability, the system will be ready for
providing services to the customer.
iv. Security: In modern world, securing an ICT system is a major factor. The system
will not be accepting any peripheral devices. This will any type direct injection of
viruses or Trojans. The system will be secured using three layered approach so
that no one can access the database unauthorized way.

4OBJECT AND DATA MODELLING
v. Usability: The usability of the system will be of high quality. The customer will
be performing tasks as per the instructions appearing on the display.
2. Use Case Modeling:
Figure 1: The Use Case Diagram of Collin’s Parking Car Park System
(Source: Created by Author)
Brief Descriptions of Use Cases: The following section presents the brief descriptions of
use cases shown the figure 1.

5OBJECT AND DATA MODELLING
i. Interact with Display: The customer will approach at the parking entry area. The
display in the pillar will show various messages to the customer. The customer
will choose the desired function.
ii. Buy Ticket: Both the customer will buy ticket; it is just that the ticket types are
different. The fixed customer will ask for a fixed ticket. The ordinary customer
will buy an ordinary ticket.
iii. Exit Area: The customer will exit from the parking are by showing the ticket. The
ticket will be entered into the exit pillars. The pillar will allow customer to exit
from parking area after some processes are completed.
iv. Make payment (Ordinary Customer): Ordinary customer will make payment
while leaving the parking area. After inserting the ticket into the parking area, the
display on the pillar will show the amount to be paid. The customer will pay the
amount and leave. The customer can make payment through cash or card.
v. Make Payment (Fixed Customer): The fixed customer will pay at the binging, at
the time of buying ticket. Based on the lifetime of the ticket such 12 months, 2
weeks or many others, the ticket cost is calculated. The customer will make
payment by card.
vi. Renew Ticket: The fixed customer will renew their ticket by selecting the
duration and making payment. The customer can another duration time after the
ticket validity expires.
Use Case Name Provide Personal Details
Scenario The fixed customer data will be stored in the database. The

6OBJECT AND DATA MODELLING
customer who buy fixed tickets will be providing their
information. The system will take the information through
input forms and verify before storing.
Triggering event The customer wants to buy a fixed ticket
Brief description The system has a display, installed in the pillars, that shows
the messages to the user. The customer will choose the fixed
ticket. The system will show a form that the customer will fill
and save. After saving the system stores the data.
Actors Fixed Customer
Related Use Case Buy Ticket
Stakeholders Fixed Customer and Collin’s car park system
Preconditions There must be at least a single parking space free
The system form is properly visualized
The customer must not be already registered
Postconditions The data provided by the customer must be verified
The customer must provide all the required data
Flow of activities Actor System
1. Customer sleets fixed
ticket
3. Customer fills the form and
2. The system visualizes a
form to the user that has input

7OBJECT AND DATA MODELLING
save it
6. The customer will input the
desired data again
fields for each labels
4. System check the inputted
data
5. If any data is missing or
not verified then the system
will again ask the customer to
enter valid data
Exception Condition Customer data is similar to another customer
The parking area becomes free as soon the customer lefts the
area
The system connection with the database is damaged

8OBJECT AND DATA MODELLING
3. UML Domain Model Class Diagram:
Figure 2: The Domain Model Class Diagram of Collin’s Parking Car Park System
(Source: Created by Author)
The representation of the Collin’s car parking system has been done properly. All the
classes have been designed to support the business operations. As the system will be interacting
with the customer only, the customer has been considered as only class diagram who represent
external entity. The system will identify each customer by their id. The customer details like
name, address, phone number, emergency contact inflation and few more are store. The class has
two operations such as creating a customer and deleting a customer. As only the fixed customer

9OBJECT AND DATA MODELLING
data will be stored into the database, the class for ordinary customer has been designed. Ticket
class has all the relevant information. Each ticket has unique id. Both the ticket will have
creation date and time. For the fixed ticket only, the duration of the ticket will be present.
Payment type will indicate whether payment has been done through cash of card.
Activities of SDLC:
SDLC stands for software development life cycle is nothing but a process which is used
by software industry for proper design and developing of quality of software. SDLC aims to
provide high quality software, which ultimately meets the expectation of various customers.
There are mainly five stages in SDLC model namely planning, designing, building, testing and
lastly deployment.
Planning phase: In this phase various necessary equipment for Collin car park system
has been analyzed. The analysis for the requirements has been performed by senior members of
the planning team of Collin car parking system. Quality assurance of requirements and
associated risk in the project has been in the planning phase (Alshamrani & Bahattab, 2015). A
proper plan has been made by which the entire car parking system can be designed.
Design phase: In this phase all the architecture requirement of Collin car parking system
has been done. The PCB board required for car parking system has been designed in this phase.
After that the overview of system will be provided and will documented in DDS (Design
document specification) (Karim, Saba & Albuolayan, 2017). The DSS will be analyzed by
various important stakeholders. The stakeholders of this car parking system will do an analysis
on following areas like risk, robustness of product, modularity design, required budget for this
system. Various electronic engineers are hired for providing the best kind of design.

10OBJECT AND DATA MODELLING
Building phase: This is the phase were the actual development starts and proper kind of
system is build. If the design of car parking system is provided in detail and organized manner,
then the codes can be generated without any kind of hassle. For building the hired coders and
designers have followed the guidelines which can be defined by various kinds of tools like
debugger and compiler which is used for generation of code (Alshamrani & Bahattab, 2015).
Proper coding language has been chosen with respect this car parking system.
Testing phase: This particular stage is subset of all the stages in SDLC model. The
testing activity generally involves various kinds of stages in SDLC. The designed circuit board
has been tested by hired tester. The hire tester has confirmed the fact that the designed car park
system has no kind of technical issues. In this, each and every stage of development of car
parking system has been properly analyzed by tester. This stage mainly works for fixing and
retesting of this until the system have reached the quality standard set by SRS.
Deployment phase: After the proper testing of this car parking system it will be
deployed. The deployment of this car parking system can also happen in stages which is
considered to part of the strategy of this system (Karim, Saba & Albuolayan, 2017). It can also
have that this car parking can be used for real kind of business environment. Then after the
feedback from various car parker this particular system can be deployed to other parts of the city.
After the release of this car parking system into the market, its maintenance can be easily done
from the revenue which is generated from customers.

11OBJECT AND DATA MODELLING
Bibliography:
Alshamrani, A., & Bahattab, A. (2015). A comparison between three SDLC models waterfall
model, spiral model, and Incremental/Iterative model. International Journal of Computer Science
Issues (IJCSI), 12(1), 106.
Dabbagh, M., & Lee, S. P. (2014). An approach for integrating the prioritization of functional
and nonfunctional requirements. The Scientific World Journal, 2014.
Dennis, A., Wixom, B. H., & Tegarden, D. (2015). Systems analysis and design: An object-
oriented approach with UML. John wiley & sons.
John, S. K., & Swapna, K. (2017). A New SDLC Frame Work for Website Development.
AADYA-Journal of Management and Technology (JMT), 7, 132-142.
Karim, N. S. A., Saba, T., & Albuolayan, A. (2017). Analysis of software security model in
scenario of Software Development Life Cycle (SDLC). Journal of Engineering Technology
(ISSN: 0747-9964), 6(2), 304-316.
Kaur, A., & Kaur, K. (2015). Suitability of Existing Software Development Life Cycle (SDLC)
in Context of Mobile Application Development Life Cycle (MADLC). International Journal of
Computer Applications, 116(19).
Khan, F., Jan, S. R., Tahir, M., Khan, S., & Ullah, F. (2016). Survey: Dealing Non-Functional
Requirements at Architecture Level. VFAST Transactions on Software Engineering, 9(2), 7-13.
Khan, P. M., & Beg, M. M. (2014). Measuring Cost of Quality (CoQ) on SDLC Projects is
indispensible for effective software quality assurance. arXiv preprint arXiv:1405.4824.

12OBJECT AND DATA MODELLING
Khan, S., Babar, M., Khan, F., Arif, F., & Tahir, M. (2016). Collaboration Methodology for
Integrating Non-Functional Requirements in Architecture. the Journal of Applied Environmental
and Biological Sciences (JAEBS), 6, 63-67.
Pandey, A., & Banerjee, S. (2015). Search based software testing: An emerging approach for
automating the software testing phase of SDLC. Proc. ICRCWIP.
Rahman, M., & Ripon, S. (2014). Elicitation and modeling non-functional requirements-A pos
case study. arXiv preprint arXiv:1403.1936.
Rhazali, Y., Hadi, Y., & Mouloudi, A. (2014). Transformation method CIM to PIM: from
business processes models defined in BPMN to use case and class models defined in UML.
International Journal of Computer, Electrical, Automation, Control and Information Engineering,
8(8), 1453-1457.
Shah, S. A. A., Shahzad, R. K., Bukhari, S. S. A., & Humayun, M. (2016). Automated Test Case
Generation Using UML Class & Sequence Diagram. British Journal of Applied Science &
Technology, 15(3).
Yue, T., Briand, L. C., & Labiche, Y. (2015). aToucan: an automated framework to derive UML
analysis models from use case models. ACM Transactions on Software Engineering and
Methodology (TOSEM), 24(3), 13.