Object Modelling
11638599 Dilan Indrajith Muthugalage
ITC508
Object Modelling
Assessment Item2
ELABORATION PHASE
Student Name: Dilan Indrajith Muthugalage
Student ID: 11638599
Table of Contents Introduction 2 Identifying the Functional and Non-Functional Requirements of Collins Car Parking System 3 Functional Requirements 3 Non- Functional Requirements 4 Use Case Modelling for Collin’s car parking system 4 Use cases of subsystems 4 Full Use Case Diagram 7 Brief Use Case Description 8 Full Use Case Description of a single Use Case 10 Class Diagram Modelling 12 Some specific tasks required for each of the five SDLC design activities 15 References 19
List of Tables
Table 1- Brief Use case description 9
Table 2- Detailed User Case description 11
Table 3- Architectural Configuration 17
List of Figures
Figure 1- Entry of Ordinary Customer Subsystem 5
Figure 2- Ordinary Customer Exit Subsystem 6
Figure 3- Fixed Customer Entry subsystem 6
Figure 4- Fixed Customer Exit subsystem 6
Figure 5- Bank Payment Gateway Subsystem 7
Figure 6- Security Office Guard Subsystem 7
Figure 9- Entity Relationship Diagram 19
Introduction
This report is based on the Object Modelling techniques. The Collins car parking system which was taken in the assessment 1 needs to be modeled through object-oriented features. The report discusses the requirement gathering. There are two types of requirements for any system- functional and non-functional. Therefore, for Collins car parking system, both requirements have been highlighted in the report. The system’s business model can be drawn out by modeling the system’s actors and identifying the processes of the system. The Modelling diagrams such as UML use case and Class diagrams will be drawn. These diagrams basically explain the business flow of the system. The design activities which will be used to implement the system will also be discussed along with the tasks that are involved in it. It will include the Entity Relationship Diagram and component modeling. Thus, this report will bring forth the basic ideas to model the system.
Identifying the Functional and Non-Functional Requirements of Collins Car Parking System
Functional Requirements
1. The Collins system should be able to address all types of customers.
2. The system should contain the functionalities to store the details of both ordinary and the fixed customers.
3. The car parking system should be able to assess the whole parking space inside the parking area,
4. The car parking system should have the functionality to detect the car coming as it approaches the entry barrier.
5. The Collins system should enable smooth and effective functioning of the control barrier system.
6. The system should enable the ordinary customers to press a button on the control barrier so that the ticket could be generated.
7. The system should produce the correct type of ticket-daily ticket for the ordinary customers and weekly, a monthly or yearly ticket for the fixed customers.
8. The system should be able to facilitate payment for the tickets.
9. The system should be able to validate the tickets of the fixed customers so that there is no fault in the identification of the customers.
10. The system should be able to print a sorry message for the ordinary customers in case the parking is engaged fully and there is no space.
11. The system should be able to calculate the parking fees of the ordinary customer according to the time the vehicle was parked in the garage.
12. The system should check the expiry of the fixed tickets.
13. The system should be able to facilitate the entry of the guards from the security offices.
14. The system should be able to record both the entry time and the exit time for all the customers and the security guards.
Non- Functional Requirements
1. The system should be designed in a way that every customer is able to make the payment easily.
2. The system should be secure and tightly prevented from risks.
3. The system should be effective. For example the time at control barrier to generate the tickets.
4. The system should be scalable (Faheem, Mahmud, Khan, Rahman& Zafar2013).
5. The system should be flexible.
6. The system’s performance should be high.
Use Case Modelling for Collin’s car parking system
Use cases of subsystems
Figure 1- Entry of Ordinary Customer Subsystem
Figure 2- Ordinary Customer Exit Subsystem
Figure 3- Fixed Customer Entry subsystem
Figure 4- Fixed Customer Exit subsystem
Figure 5- Bank Payment Gateway Subsystem
Figure 6- Security Office Guard Subsystem
Full Use Case Diagram
(Examples of UML diagrams, 2018)
Brief Use Case Description
Table 1- Brief Use case description
|
Use Case |
Brief Description |
|
Entry of ordinary customer |
The use case explains the entry in the parking of an ordinary customer. |
|
Pressing of a button on the barrier |
The ordinary customer presses the button on the control barrier to get a ticket. |
|
assessment of space in the parking |
The system assesses the space in the parking. |
|
display "no vacancy when the parking is full" |
If there is no space available, the system denies the ticket and display “no vacancy”. |
|
generates the daily ticket |
If there is space available, the daily ticket is generated. |
|
receives ticket |
The ordinary customer receives a ticket. |
|
record of vehicle details |
The ordinary customer’s vehicle’s number and other information are noted. |
|
entry time recorded |
The entry time of the vehicle is also recorded. |
|
Ordinary customer exits |
This use case explains about the exit of the ordinary customer from the parking. |
|
does payment |
The customer goes for payment. |
|
ticket insertion into exit slot |
For payment and exit, the customer inserts the ticket into the exit slot. |
|
unique identification through barcode |
The ticket’s unique barcode is identified by the system for validation. |
|
calculation of fees |
The total parking fees are calculated by the system. |
|
exit time recorded |
When the customer exits, the exit time is recorded. |
|
entry of credentials |
During payment, the customer can make an entry of the credentials. |
|
facilitate payment |
The Bank payment gateway facilitates the payment. |
|
Entry of fixed customer |
This use case explains the entry of the fixed customer in the parking. |
|
direct ticket insertion in a slot |
The fixed customer directly enters the ticket into the control barrier slot. |
|
ticket and customer validation |
The system carries out the ticket validation to check whether the customer has inserted the right ticket. |
|
checking of expiry |
The ticket’s expiry is also checked. |
|
predefined space parking |
The system allows a predefined space for parking to the fixed customers. |
|
entry time recorded |
The entry time of the fixed customer is recorded. |
|
The exit of fixed customer |
This use case explains the exit of the fixed customer. |
|
insertion of the ticket in the exit slot |
For exit, the fixed customer inserts the ticket into the exit slot. |
|
bar raised |
He does not need to do the payment; the system automatically raises the bar. |
|
exit time recorded |
The exit time of the customer is recorded. |
|
Entry of security guard |
This use case explains the entry of the security guard. |
|
insertion of entry card into the reader |
For entry, the guard needs to insert the card into the card reader. |
|
The exit of a security guard |
This use case explains the exit of the security guard from the parking. |
|
insertion of card again |
The security guard needs to insert the card again at the exit slot for the exit. |
|
record of exit time |
The record of exit time of the security guard is maintained. |
(Brittner, 2003)
Full Use Case Description of a single Use Case
Table 2- Detailed User Case description
|
Use Case |
Entry of ordinary customer |
||||||||||||||||||||||||
|
Goal |
The goal of the use case is to facilitate the entry of the ordinary customer. |
||||||||||||||||||||||||
|
Preconditions |
· The customer uses the Collins car parking for their car park. · The system has predefined specifications for the ordinary customers and the fixed customers. |
||||||||||||||||||||||||
|
Success End Condition |
The customer successfully does the payment and exits the car parking. |
||||||||||||||||||||||||
|
Failed End Condition |
The car parking is full, and the customer couldn’t park the car. |
||||||||||||||||||||||||
|
Primary Actors;
Secondary Actors |
Ordinary Customer
Collins Barrier control system, Bank Payment Gateway |
||||||||||||||||||||||||
|
Trigger |
The customer approaches the entry barrier and the sensor detects the vehicle. |
||||||||||||||||||||||||
|
Description/ Main Success Scenario |
|
||||||||||||||||||||||||
|
Alternative Flows |
|
Class Diagram Modelling
Class Diagram Description
· The customer can have one or more tickets.
· The customer can have only one vehicle to register or park in the system.
· There are three types of customers- Security guard, ordinary and fixed. The entry and exit operations are different for both the types of customers.
· There are two types of Operations, ordinary customer operation, and the fixed customer operation.
· There is security operation too.
· The generalization relation has been used for the two customer types. Also, the generalization relation has been used for the two operations (Dathan& Ramnath, 2015).
· For the fixed customer, the operations are only verification and validation.
· For the ordinary customer, the operations include the pressing the control button, assessing the space, generating the ticket, receiving the ticket, error message display and the payment.
Assumptions
· The customers are availing the service of Collins car parking system.
· The whole layout of the parking system has been fed into the system.
· The customer does not lose his ticket.
Some specific tasks required for each of the five SDLC design activities
The Collins car parking system needs to be planned and designed using design approaches of the SDLC. There are different models that can be used for designing the model. Waterfall model, agile model, iterative model etcetera can be used to model the system. For each model, the tasks for the design activities would be the same.
The tasks for each of the design activities can be:
1. Environment Identification:
The environment for the Collins car parking system should be able to:
· Be compatible with the software.
· Compete with the other systems.
· Provide security to the customer’s data and the transactions.
· Be developed programming languages.
· Support integration with the other languages.
· Support testing for the users.
· Support the unit level testing modules.
· Support the integration level of testing.
Therefore, the tasks required to do in this design module are as follows:
· Identify the requirements of the system.
· Analyse the design and the requirements.
· Gather the requirements.
2. Designing of Application Components
The critical examining of the system helped in designing the application or system components. The functionalities of the system have been considered while designing the application components.
The components have been modeled by designing the Use Case diagram and the Class Diagram.
Table 3- Architectural Configuration
|
Use Cases |
Corresponding Actor |
Class |
Event |
|
Entry of ordinary customer, Ordinary customer exits, does payment
|
Ordinary Customer |
ordinary_customer |
The ordinary customer does entry into the parking, does payment and exits the system. |
|
Entry of fixed customer, direct ticket insertion in the slot, Exit of the fixed customer, insertion of the ticket in the exit slot |
Fixed Customer |
fixed_customer |
The fixed customer and exits. |
|
assessment of space in the parking, display "no vacancy when the parking is full", generates the daily ticket, record of vehicle details, entry time recorded |
Collins Barrier Control System |
OrdinaryCustomerOperation |
The entry operations for the ordinary customer are performed. |
|
unique identification through barcode, calculation of fees, exit time recorded |
Collins Barrier Control System |
OrdinaryCustomerOperation |
The exit operations for the ordinary customer are performed. |
|
entry of credentials, facilitate payment |
Bank Payment Gateway |
OrdinaryCustomerOperation |
The payment by the customer. |
|
ticket and customer validation, checking of expiry, predefined space parking, entry time recorded
|
Collins Barrier Control System |
FixedCustomerOperation |
The fixed customer’s entry is functionalized. |
|
bar raised, exit time recorded |
Fixed Customer, Control Barrier System |
FixedCustomerOperation |
The fixed customer’s exit is functionalized. |
|
The exit of a security guard, insertion of card again, a record of exit time |
Security office guard |
SecurityOpeartion |
The entry and exit of security guards are defined. |
3. User Interface
The user interface should be user interactive and operational part should be easy.
4. Database
The database is the prime requirement. The designing of the database can be done by modeling the Entity-Relationship diagram. The database should be normalized, and the contents of the database should be unique.
Figure 9- Entity Relationship Diagram
5. Software Methods
The software methods should be recognized and implemented. It is a very important task because all the designing would go in vain if there is no proper software implementation.
References
· Faheem, Mahmud, S., Khan, G., Rahman, M., & Zafar, H. (2013). A Survey of Intelligent Car Parking System. Journal of Applied Research and Technology, 11(5), 714-726. http://dx.doi.org/10.1016/s1665-6423(13)71580-3
· Dathan, B., & Ramnath, S. (2015). Object-Oriented Analysis, Design and Implementation: An Integrated Approach. Springer.
· Examples of UML diagrams. (2018). Uml-diagrams. Retrieved from https://www.uml-diagrams.org/index-examples.html.
· Dennis, A., Wixom, B. H., &Tegarden, D. (2015). Systems analysis and design: An object-oriented approach with UML. John wiley& sons.
· Brittner, k. (2003). USE CASE MODELLING (pp.20-50). Boston, MA:AddisionWEasley.
Object Modeling-Assignment 2 1