This document outlines the requirements for modeling a toll system. It includes:
1. A domain analysis section with a glossary and domain class diagram defining the main concepts and their relationships.
2. Functional requirements including activity diagrams for the basic workflows, a use case diagram identifying the main actors and use cases, and detailed descriptions of 5 use cases.
3. Non-functional requirements related to performance, hardware needs, and customer satisfaction.
4. Acceptance test fit tables simulating test cases for the 5 use cases to validate the requirements.
The document provides all the necessary information to model the toll system, including its domain, functionality, quality attributes and tests. This will form the basis for
Advantages of Hiring UIUX Design Service Providers for Your Business
Report 09
1. 1
02291 SYSTEM INTEGRATION
Final Project
Toll System
Ioannis Oikonomidis (s083928)
Laura-Ariadna Stroe (s131185)
Nanna Gudrun Hjaltalin (s131044)
Alexandru Malus (s131188)
Dimitrios Kosmadakis (s131200)
May 7, 2014
2. 2
Contents
1 Introduction...................................................................................................................................... 3
2 Requirements ................................................................................................................................... 4
2.1 Domain Analysis............................................................................................................................ 4
2.1.1 Glossary .................................................................................................................................. 4
2.1.2 Domain Class Diagram........................................................................................................... 5
2.2 Functional Requirements........................................................................................................... 6
2.2.1 Basic Workflow ................................................................................................................. 6
2.2.2 Use Case Diagram............................................................................................................ 10
2.2.3 Detailed Use Cases .......................................................................................................... 11
2.3 Non Functional Requirements................................................................................................. 14
3 Acceptance Test Fit Tables............................................................................................................ 15
3.1 Check-in....................................................................................................................................... 15
3.2 Check-out ................................................................................................................................ 17
3.3 Buy Toll Tag ........................................................................................................................... 18
3.4 Show reports............................................................................................................................ 23
3.5 Change Rates........................................................................................................................... 24
4 Design ................................................................................................................................................. 25
4.1 Component Design....................................................................................................................... 28
4.2 Class Design............................................................................................................................ 34
4.3 Behavior Design...................................................................................................................... 36
5 Validation............................................................................................................................................ 38
5.1 Use Case Realization ................................................................................................................... 38
6 Conclusions.................................................................................................................................... 47
7 Who did what................................................................................................................................. 47
3. 3
1 Introduction
Modeling plays a vital role in determining the success of a certain project. It can accelerate the
understanding of a system describing it in a more efficient way than writing behavioral and
requirement descriptions. It is of high importance that the models are coherent and they agree since
they are all describing the same system.
The goal of this project is to model a toll system that handles the toll charge for cars, motorbikes
and trucks entering and leaving the motorways present in this scenario. The process includes the
checking in and out of the vehicles, and all the possible interactions. It also includes the stations
existent in the scenario, and the managers participating.
In order to complete the project we considered splitting the tasks so that every group member
would participate in the making of this project, as it is to be seen in the “who did what section”. We
started by drawing the domain class diagram. Then, each member of the team picked up a use case and
for every use case and worked on the correspondent detailed use case description, activity and use case
diagram. After that we had an overview of how the system should function. We then had a small brain
storming that helped us design the CRC Cards of the components of the system and later on we built
the system’s component diagram. After we draw the detailed class diagram and moved on with
modeling every communication interface as a protocol. Sequence diagrams where used to validate that
the system is actually functional.
Being five members, we detailed only five use cases, but we added the last two in the use case
diagram. We met almost every week to proof read the work of our team members and help answering
questions as best we could, so that all of us could have full knowledge of the parts present in the
project. Besides the individual tasks we also had tasks that required the entire group to participate in.
We created a glossary consisting of the words or phrases used during the making of this project.
CRC cards were also used for a better understanding of the use case diagram.
4. 4
2 Requirements
2.1 Domain Analysis
2.1.1 Glossary
Authentication - the validation of a user’s credentials during login
Barrier - object that restrains access to the lanes
Vehicle - anything that has wheels and runs on combustible, in our case we had cars, trucks and
motorbikes
Check-in lane - the lanes used by customers to enter the motorway
Check-out lane - the lane used by customers to leave the motorway
Check in - the process of receiving access to enter a lane leading to the motorway
Check out - the process of leaving a motorway
Credit card reader - a mechanism that can be used to validate and charge a credit card
Customer - a person that uses the lanes and the motorway
Enterprise - the company responsible for the administration of the toll system
Enterprise client - the enterprise manager’s computer
Enterprise manager - person with write access to the rates and read access to enterprise reports
Enterprise report - a document that has information related to the use of one or more toll station in a
period of time
Express lane - the lanes with antennas that are used for customers with toll tags.
Express Check-in - check-in that occurs in an express lane
Motorway - the road used for fast moving traffic
Normal lane - the lanes without antennas that are used for customers without toll tags.
Normal Check-in - check-in that occurs in a normal lane
Ticket Printer - machine able to print a single ticket
RFID antenna - mechanism situated on every express lane and used to identify a toll tag
Sensor - mechanism able to understand when a vehicle crosses a barrier and to recognize the type of a
vehicle
Single ticket - one way ticket in and out of the motorway. It can be bought using credit card or cash at
normal lanes
Station client - the station’s manager computer
Station server - person with read access to station reports
Station manager - the person responsible for the administration of the stations
Ticket reader - a mechanism able to read map the barcode of a ticket with a ticketID
Toll lane - a lane on which access to the motorway is granted after a certain fee has been paid
Toll lane computer - a computer used for controlling the toll lane
Toll rate - the fee that should be paid in order to cross a motorway. It depends on the check in lane
(normal or express).
Toll station - area that includes one or more toll lanes, a station server and a station client
Toll station report - a document which has the information related to the usage of the station it
belongs too.
Touchscreen - a toll lane computer client on which a cashier can operate.
5. 5
2.1.2 Domain Class Diagram
Figure 1 displays the domain class diagram of the Toll System.
Figure 1, Domain Class Diagram
6. 6
2.2 Functional Requirements
2.2.1 Basic Workflow
In order to capture the dynamic behavior of the system, the activity diagrams are displayed below
Figure 2, Check-in Activity Diagram
10. 10
2.2.2 Use Case Diagram
In order to gather requirements for the system and get an outside view of it identifying external and
internal factors influecing the system, the use case diagram is displayed below.
Figure 6, Use Case Diagram
11. 11
2.2.3 Detailed Use Cases
We start building the requirements of the project by describing five use cases in details. This will help
us later on to validate those with sequence diagrams.
Name Check-in
Description A customer arrives at the beginning of a motorway, where he interacts
with the tolling system
Actor Customer
Precondition Customer enters either an express or a normal lane
Main Scenario 1. The customer is situated at a normal lane and buys a single ticket using
credit card
The customer arrives at a normal lane
The customer inserts a credit card
The customer reads the rate from the credit card reader screen
The customer inserts the credit card pin
The customer crosses the barrier when it is raised
2. The customer is situated at a normal lane and buys a single ticket using
cash
The customer arrives at a normal lane
The customer pays in cash the cashier
The customer receives a single ticket
The customer crosses the barrier when it is raised
3. The customer is situated at the express lane and with the help of the toll
tag and the antenna, the system identifies the customer and records the
start point of its travel
The customer arrives at an express lane
The customer crosses the barrier when it is raised
Alternative scenario 1a. The credit card transaction is declined and the check in fails
2a. The customer does not have enough money and the check in fails
3a. The toll tag is invalid, and as such the customer is not allowed to pass.
Post condition Customer passed through
System logged customer info
Table 1, Detailed Check-in Use Case
Name Check-out
12. 12
Description A customer inserts its single ticket or uses a bought toll tag, interacting
with the toll system.
Actor Customer
Precondition The customer must have passed through the check-in process.
Main Scenario 1. The customer is situated at a normal lane and inserts a valid single
ticket into the single ticket reader.
The customer arrives at a normal lane
The customer inserts a valid ticket
The customer crosses the barrier when it is raised
2. The customer arrives at an express lane and with the help of the toll
tag and the antenna; the system then identifies the customer, and updates
its account details.
The customer arrives at an express lane
The customer crosses the barrier when it is raised.
Alternative scenario 1. The customer inserts an invalid ticket. The checkout fails.
2. The customer has an invalid toll tag. The checkout fails.
3. The customer does not have enough money and is not allowed to pass.
Postcondition Customer passed through.
Single ticket is invalidated or a fee is placed on the customer’s account.
Table 2, Detailed Check-out Use Case
13. 13
Name Buy toll tag
Description Customer buys a toll tag so that he has the right to check in and check out from toll
enterprise without interacting with a cashier.
Actor Customer
Precondition Customer should have a valid bank account.
Main Scenario 1. The customer buys a toll tag by filling in a form in toll lane.
Customer enters in toll check-in and interacts with the cashier.
Customer declares he wants to buy a toll tag,
Customer fills out a form with personal, vehicle and bank account
information. Customer signs.
Cashier fills an internet form with client's information
2. The customer buys a toll tag by filling in a form via internet
Customer accesses the internet page responsible for buying toll tags.
Customer fills out a form with personal, vehicle and bank account
information.
Customer confirms
Alternative
Scenario
1a. The customer enters false information in the paper form
2a. The customer enters false information in internet form
2b. The customer hasn't got enough money in his bank account.
Postcondition Customer receives an email with toll tag information
Table 3, Detailed Buy Toll Tag Use Case
Name Show reports
Description A manager wants to interact with the tolling system by seeing the reports
for the station/s from the client. The station manager is able to see the
reports for the station from the station client. The enterprise manager is
able to see the reports for all the stations.
Actor Manager (station manager and enterprise manager)
Precondition A manager has to be registered in the system.
Main Scenario 1. The manager logs in to the system providing valid username and
password. He can access the reports for the toll station/s.
Alternative scenario 1a. The manager provides invalid username and password. The manager
cannot access the reports. He provides his email and gets username and
password sent to his email.
Postcondition The manger gets access to the reports.
Table 4, Detailed Show Reports Use Case
14. 14
Name Change rate
Description The enterprise manager logs in with the administrator account and
modifies the rates for single tickets or toll tags
Actor The enterprise manager
Precondition The enterprise manager must have a valid account
Main Scenario The enterprise manager logs in the enterprise server
The enterprise manager modifies the rates for either the single
tickets or the toll tags
The modifications are being sent to the stations
Alternative scenario The enterprise manager introduces an invalid username or
password.
The login fails and the manager cannot access the server
Postcondition The new toll rates are now available at all the stations.
Table 5, Detailed Change Rates Use Case
2.3 Non Functional Requirements
In order to have a realistic implementation, the following non-functional requirements must be
met:
The system is capable to identify the type of car which is approaching the toll system with
speeds from 5 to 100 mph.
The network controller which is responsible for synchronizing the servers, workstations and
local lane controllers must have a transmission tolerance of maximum 1000 ms in delay.
The tolling system can support 10 and 100 megabit Ethernet environments.
As minimum hardware requirements we include:
Toll lane computer: Microsoft SQL Server v 7.0 or greater; Connectivity through a highly
reliable LAN connection; Operation system of Microsoft Windows 2000 or greater;
Toll server: 512 KB bytes L2 cache memory; Magnetic disk storage system with sufficient
capacity to store the necessary lane transactions and violation information for a minimum of
two months; High-performance SVGA controller (2 megabyte VRAM); [1]1
Regarding customer satisfaction, the antenna which picks up data from the toll tags must have
a reaching rate of at least 10 meters to allow customers to remain in their cars when they reach
the check-in, as well as check-out.
1
Oklahoma Turnpike Authority, part 3 rev 1.
15. 15
3 Acceptance Test Fit Tables
Testing is a vital part of software development and it is important to start it as early as possible and
make it a part of the deciding requirements process. A very famous technique the last years is TDD
where the developer first writes the test before the actual code. Below we simulate a test suit that could
be used as requirements for our five use cases.
3.1 Check-in
ActionFixture
Start Check In
Enter Vehicle Type “car”
Enter Rate 100
Enter Insert Credit Card “visa”, “1111222233334444”
Check Validate Credit Card TRUE
Enter Insert Pin 1234
Check Credit Card Charged TRUE
Check Customer Details Logged TRUE
Check Ticket Printed TRUE
Press Remove Ticket
Check Barrier Raised TRUE
Press Vehicle Crossed Barrier
Check Barrier Lowered TRUE
Check Check In Successful TRUE
FIT Table 1, Normal Check-in / Credit Card Payment (Main Scenario)
ActionFixture
Start Check-in
Enter Vehicle Type “car”
Enter Rate 100
Enter Validate Credit Card FALSE
Check Ticket Printed FALSE
Check Customer Details Logged FALSE
Check Barrier Raised FALSE
Check Check In Successful FALSE
FIT Table 2, Normal Check-in / Credit Card Payment (Alternative Scenario)
16. 16
ActionFixture
Start Check-in
Enter Vehicle Type “car”
Enter Rate 100
Enter Pay In Cash 100
Check Ticket Printed TRUE
Press Remove Ticket
Check Barrier Raised TRUE
Press Vehicle Crossed Barrier
Check Barrier Lowered TRUE
Check Check In Successful TRUE
FIT Table 3, Normal Check-in / Cash Payment (Main Scenario)
ActionFixture
Start Check-in
Enter Vehicle Type “car”
Enter Rate 100
Enter Pay In Cash 90
Check Ticket Printed FALSE
Check Customer Details Logged FALSE
Check Barrier Raised FALSE
Check Check In Successful FALSE
Check Ticket Printed FALSE
FIT Table 4, Normal Check-in / Cash Payment (Alternative Scenario)
ActionFixture
Start Check-in
Press Receive Valid Toll Tag
Check Validate Toll Tag TRUE
Check Customer Details Logged TRUE
Check Barrier Raised TRUE
Press Vehicle Crossed Barrier
Check Barrier Lowered TRUE
Check Check In Successful TRUE
FIT Table 5, Express Check-in (Main Scenario)
ActionFixture
Start Check-in
Press Receive Invalid Toll Tag
Check Validate Toll Tag FALSE
Check Customer Details Logged FALSE
Check Barrier Raised FALSE
Check Check In Successful FALSE
FIT Table 6, Express Check-in (Alternative Scenario)
17. 17
3.2 Check-out
ActionFixture
Start Check Out
Press Insert Valid Ticket
Check Validate Ticket TRUE
Press Ticket Invalidated
Check Barrier Raised TRUE
Check Vehicle Crossed Barrier TRUE
Check Barrier Lowered TRUE
Check Check Out Successful TRUE
FIT Table 7, Normal Check-out (Main Scenario)
ActionFixture
Start Check Out
Press Insert Invalid Ticket
Check Validate Ticket FALSE
Check Barrier Raised FALSE
Check Check Out Successful FALSE
FIT Table 8, Normal Check-out (Alternative Scenario)
ActionFixture
Start Check Out
Press Receive Valid Toll Tag
Check Validate Toll Tag TRUE
Press Register Fee
Check Account Info Updated TRUE
Check Barrier Raised TRUE
Check Check Out Successful TRUE
FIT Table 9, Express Check-out (Main Scenario)
ActionFixture
Start Check Out
Press Receive Invalid Toll Tag
Check Validate Toll Tag FALSE
Check Barrier Raised FALSE
Check Customer Details Logged FALSE
Check Check Out Successful FALSE
Check Check Out Incomplete TRUE
FIT Table 10, Express Check-out (Alternative Scenario)
18. 18
3.3 Buy Toll Tag
ActionFixture
Start Buy toll tag
Press Toll tag form
Enter Customer's First
Name
String “George”
Enter Customer's Last Name String “Papadopoulos”
Enter Customer's Address String “Folehaven 22, 2400,
Valby, Copenhagen”
Enter Customer's Telephone
Number
Integer 71878012
Enter Customer's Vehicle
type
Vehicle_type Truck
Enter Customer's Vehicle
Plate Number
String “AB 123231”
Enter Email address String “foo@gmail.com”
Enter Customer's Bank's
IBAN
String “DK101-2432-2342-
11112-019”
Enter Starting Date Date_type 04/02/14
Enter Customer's Signature
Press Receive Toll tag form
Check IBAN exists true
Check IBAN corresponds to
name and surname
true
Check Money of bank
account are more or
equal to fee price
true
Check Starting date exists true
Check Email address exists true
Press Create Toll tag
number
Tolltag_type 123123321
Press Create record with toll
tag number, customer
data, vehicle data,
starting date, bank
account information
Press Add Toll tag in list
with active toll tags
Press Send email with toll
tag
FIT Table 11, Customer fills out a form physically, at toll's check-in (Main Scenario)
19. 19
ActionFixture
Start Buy toll tag
Press Access toll tag form
Enter Customer's First
Name
String “George”
Enter Customer's Last
Name
String “Papadopoulos”
Enter Customer's Address String “Folehaven 22, 2400,
Valby, Copenhagen”
Enter Customer's Telephone
Number
Integer 71878012
Enter Email address String “foo@gmail.com”
Enter Customer's Vehicle
type
Vehicle_type Truck
Enter Customer's Vehicle
Plate Number
String “AB 123231”
Enter Customer's Bank's
IBAN
String “DK101-2432-2342-
11112-019”
Enter Starting Date Date_type 04/02/14
Press Confirm Validity
Press Receive toll tag form
Check IBAN exists true
Check IBAN corresponds to
name and surname
true
Check Money of bank
account are more or
equal to fee price
true
Check Starting date exists true
Check Email address exists true
Press Create toll tag number Tolltag_type 123123321
Press Create record with toll
tag number, customer
data, vehicle data,
starting date, bank
account information
Press Add toll tag in list
with active toll tags
Press Send email with toll
tag
FIT Table 12, Customer fills out an internet form (Main Scenario)
20. 20
ActionFixture
Start Buy toll tag
Press Hand out toll tag form
Enter Customer's First
Name
String “George”
Enter Customer's Last Name String “Papadopoulos”
Enter Customer's Address String “Folehaven 22, 2400,
Valby, Copenhagen”
Enter Customer's Telephone
Number
Integer 71878012
Enter Customer's Vehicle
type
Vehicle_type Truck
Enter Customer's Vehicle
Plate Number
String “AB 123231”
Enter Email address String “foo@gmail.com”
Enter Customer's Bank's
IBAN
String “DK101-2432-2342-
11112-019”
Enter Starting Date Date_type 04/02/14
Enter Customer's Signature
Press Create toll tag form
Check IBAN exists true
Check IBAN corresponds to
name and surname
false
Press Create record with
personal information
as possible violator.
Press Send email with non
acceptance due to
false information
FIT Table 13, Customer fills out a form physically with false data, at toll's check-in (Alternative Scenario)
21. 21
ActionFixture
Start Buy toll tag
Press Access webpage toll
tag form
Enter Customer's First
Name
String “George”
Enter Customer's Last Name String “Papadopoulos”
Enter Customer's Address String “Folehaven 22, 2400,
Valby, Copenhagen”
Enter Customer's Telephone
Number
Integer 71878012
Enter Email address String “foo@gmail.com”
Enter Customer's Vehicle
type
Vehicle_type Truck
Enter Customer's Vehicle
Plate Number
String “AB 123231”
Enter Customer's Bank's
IBAN
String “DK101-2432-2342-
11112-019”
Enter Starting Date Date_type 04/02/14
Press Button of acceptance
Press Receive toll tag form
Check IBAN exists false
Press Create record with
personal information
as possible violator.
Press Send email with non
acceptance.
FIT Table 14, Customer fills out an internet form with false data (Alternative Scenario)
22. 22
ActionFixture
Start Buy toll tag
Press Access web page toll
tag form
Enter Customer's First
Name
String “George”
Enter Customer's Last Name String “Papadopoulos”
Enter Customer's Address String “Folehaven 22, 2400,
Valby, Copenhagen”
Enter Customer's Telephone
Number
Integer 71878012
Enter Email address String “foo@gmail.com”
Enter Customer's Vehicle
type
Vehicle_type Truck
Enter Customer's Vehicle
Plate Number
String “AB 123231”
Enter Customer's Bank's
IBAN
String “DK101-2432-2342-
11112-019”
Enter Starting Date Date_type 04/02/14
Press Confirm Validity
Press Receive toll tag form
Check IBAN exists true
Check IBAN corresponds to
name and surname
true
Check Money of bank
account are more or
equal to fee price
false
Create Record with personal
information, bank
account.
Press Send email with non
acceptance
FIT Table 15, Customer's bank account has less money than the price of the standard toll tag (Alternative Scenario)
23. 23
3.4 Show reports
ActionFixture
Start Show reports
Enter Username Station1
Enter Password Password1
Check Authenticate Account TRUE
Check Manager Type Station manager
Check Show Toll Station Report TRUE
Check Show Enterprise Reports FALSE
FIT Table 16, Show Station Reports (Main Scenario)
ActionFixture
Start Show reports
Enter Username Station
Enter Password Password
Check Authenticate Account FALSE
Enter Email manager@toll.dk
Check Valid email TRUE
Press Send username and password
Enter Username Station
Enter Password password
Check Manager Type Station manager
Check Show Toll Station Report TRUE
Check Show Enterprise Reports FALSE
FIT Table 17, Show Station Reports (Alternative Scenario)
ActionFixture
Start Show reports
Enter Username Enterprise1
Enter Password Password1
Check Authenticate Account TRUE
Check Manager Type Enterprise manager
Check Show Toll Station Report FALSE
Check Show Enterprise Reports TRUE
FIT Table 18, Show Enterprise Reports (Main Scenario)
24. 24
ActionFixture
Start Show reports
Enter Username Enterprise
Enter Password Password
Check Authenticate Account FALSE
Enter Email manager@toll.dk
Check Valid email TRUE
Press Send username and password
Enter Username Enterprise
Enter Password password
Check Manager Type Enterprise manager
Check Show Toll Station Report FALSE
Check Show Enterprise Reports TRUE
FIT Table 19, Show Enterprise Reports (Alternative Scenario)
3.5 Change Rates
ActionFixture
Start Change rate
Enter Username enterprise_mng
Enter Password Mng007
Check Authenticate Account TRUE
Enter Change Single Ticket Rates 100
Check Single Ticket Rates Updated TRUE
Enter Change Toll Tags Rates 100
Check Toll Tags Rates Updated TRUE
Check Retrieve Rates From Stations TRUE
FIT Table 20, Change Single Ticket or Toll Tag Rates (Main Scenario)
ActionFixture
Start Change rate
Enter Username Enterprise
Enter Password mng01
Check Authenticate Account FALSE
Check Single Ticket Rates Updated FALSE
Check Toll Tags Rates Updated FALSE
FIT Table 21, Invalid Credentials (Alternative Scenario)
25. 25
4 Design
We made the assumption that there is a sensor component in our all normal check-in lanes that allows
the toll lane computer to know when a vehicle crossed the barrier and is able to identify the vehicle
type of the vehicle entering a normal check-in toll lane.
In order to properly develop our classes we brainstormed and drew some CRC cards.
Sensor
Can identify vehicle type of a vehicle
entering a normal check-in lane
Customer (Vehicle)
Can verify that a vehicle crossed a barrier Customer (Vehicle)
Toll Lane Computer
Can validate credit card Credit Card Reader
Can charge credit card Credit Card Reader
Can rise barrier Touchscreen
Can lower barrier Touchscreen
Can create toll tags Station Server
Can validate toll tags Antenna
Can handle inserted tickets Single Ticket Reader
Can handle transactions Station Server
Can print tickets Printer
Can open the cash register Cash register
Can handle transactions with the bank Bank
Station Server
Can show station report Station Client
Can authenticate Station Client
Can get rates Toll Lane Computer
Can handle check-ins Enterprise Server
Enterprise Server
Can change single ticket rates Enterprise Client
Can change toll tag rates Enterprise Client
Cab request credentials Enterprise Client
Can show enterprise report Enterprise Client
Can login Enterprise Client
Can tag fees Bank
26. 26
Enterprise Manager
Has an account
Knows username
Knows password
Can login Enterprise Server
Can logout Enterprise Server
Can request email to recover credentials Enterprise Server
Can change single ticket and toll tag rates Enterprise Server
Can request enterprise reports Enterprise Server
Can notify customers Enterprise server
Customer
Can check-in Station Server
Can check-out Station Server
Can buy single ticket Cashier/Bank
Can buy toll tag Enterprise Server
Can pay with cash Toll lane cashier
Can pay with credit card Bank
Customer
Can check-in Station Server
Can check-out Station Server
Can buy single ticket Cashier/Bank
Can buy toll tag Enterprise Server
Can pay with cash Toll lane cashier
Can pay with credit card Bank
Toll lane cashier
Can handle cash payment Customer
Can authenticate Station Server
Can print single ticket Station Server
Can print toll tag Station Server
Can raise barrier Station Server
Can lower barrier Station Server
Can log into the server Station Server
27. 27
Station Manager
Request toll station report Station Server
Can authenticate Station Server
Single Ticket
Has a unique ID
Knows if it is valid
Can be paid with credit card Station Server
Can be paid with cash Toll lane cashier
Toll Tag
Has a unique ID
Knows its vehicle type
Knows the travelled distance
Can be ordered on the internet Enterprise Server
Can be ordered at the toll station Toll lane cashier
Knows if it is valid Antenna
Bank
Can authenticate customers Enterprise Server
Knows the amount paid Enterprise Server
Can collect Toll Tag fees Customer
Can collect single ticket fees Customer
28. 28
4.1 Component Design
The component diagram is displayed below.
Figure 7, Component Diagram
For the component diagram presented above, the protocol state machines are as follows:
Figure 8, Toll Lane Computer to Station Server protocol
29. 29
Figure 9, Toll Lane Computer to the Touchscreen protocol
Figure 10, Toll Lance Computer to Credit Card Reader protocol
30. 30
Figure 11, Toll Lane Computer to the Antenna protocol
Figure 12, Toll Lane Computer to Single Ticket Reader
Figure 13, Toll Lane Computer to Barrier protocol
31. 31
Figure 14, Station Server to Station Client Protocol
Figure 15, Toll Lane Computer to Sensor Protocol
Figure 16, Toll Lane Computer To Printer Protocol
32. 32
Figure 17, Cash Register to Toll Lane Computer Protocol
Figure 18, Printer To Toll Lane Computer Protocol
Figure 19, Sensor to Toll Lane Computer Protocol
Figure 20, Station Server to Toll Lane Computer Protocol
33. 33
Figure 21, Station Server to Enterprise Server Protocol
Figure 22, Enterprise Server to Enterprise Client Protocol
Figure 23, Enterprise Server to Station Server Protocol
34. 34
4.2 Class Design
Having everything we need we can now build the class diagram and identify all interfaces.
Figure 24, Detailed Class Diagram
35. 35
Some OCL constraints can be found below:
In order to print a ticket there should be either a successful credit card or cash payment
context TollLaneComputer::printTicket()
pre: self.creditCardReader.chargeCreditCard() or self.touchscreen.cashInvoice()
On handleTicketRemoved(), the barrier should be lowered. After the operation the barrier
should be raised.
context TollLaneComputer::handleTicketRemoved()
pre: self.barrier.status = Status :: LOWERED
post: self.barrier.status = Status :: RAISED
For every express check-in there may not exist any express check-in of the same tag ID with status
open. After an express check-in there should be exactly one check-in with the same tag ID status open.
For an express check-out there should be a corresponding express check-in with status open. The date
of the operation should be maximum 24 hours after the express check in occurred. After the express
check-out operation there may not exist any express check-in of the same toll tag with status open.
context EnterpriseServer::expressCheckin(tagID)
pre: self.checkIn->select(tollTagID = tagID)
->select(status = Check In Status :: OPEN).size() = 0
post: self.checkIn->select(tollTagID = tagID)
->select(status = Check In Status :: OPEN).size() = 1
context EnterpriseServer::expressCheckout(tagID)
pre: (self.checkIn->select(tollTagID = tagID)
->select(status = Check In Status :: OPEN).size() = 1) and
(today - self.checkIn->select(tollTagID = tagID)
->select(status = Check In Status :: OPEN).first().date <= 1)
post: self.checkIn->select(tollTagID = tagID)
->select(status = Check In Status :: OPEN).size() = 0
In order for the station manager to see a station report he should be logged in.
context StationServer:: showStationReport()
pre: self.login()
36. 36
4.3 Behavior Design
Below we model the behavior diagrams of the three most important classes in our system in order to
get an overview of how they function
Figure 25, Toll Lane Computer Behavior Diagram
37. 37
Figure 26, Station Server Behavior Diagram
Figure 27, Enterprise Server Behavior Diagram
38. 38
5 Validation
5.1 Use Case Realization
Figure 28, Check-in Normal Lane Credit Card Sequence Diagram
47. 47
6 Conclusions
In the present project we created a complete model of a scenario using a motorway with toll
stations. We tried to make a complete model by taking all situations in consideration, so that the
process would go smoothly and realistic. We considered the negative situations as well, for example,
when a customer doesn’t have enough money to pay at the check-out, or when a credit card is invalid
or when the ticket had been lost or deteriorated.
7 Who did what
Introduction Laura, Nanna, Ioannis
Requirements
2.1 Domain Analysis
2.1.1 Glossary All
2.1.2 Domain Class Diagram Ioannis, Alex
Functional Requirements
Basic Workflow
Figure 2, Check-in Activity Diagram Ioannis, Alexandru
Figure 3, Check-out Activity Diagram Ioannis, Alexandru
Figure 4, Buy Toll Tag Activity Diagram Dimitrios
Figure 5, Change Rates and Show Reports Activity Diagram Laura, Nanna
Use Case Diagram All
Detailed Use Cases
Table 1, Detailed Check-in Use Case Ioannis, Alexandru
Table 2, Detailed Check-out Use Case Ioannis, Alexandru
Table 3, Detailed Buy Toll Tag Use Case Dimitrios
Table 4, Detailed Show Reports Use Case Nanna
Table 5, Detailed Change Rates Use Case Laura
Non Functional Requirements Alexandru
Acceptance Test Fit Tables
3.1 Check-in Ioannis, Alexandru
Check-out Ioannis, Alexandru
Buy Toll Tag Dimitrios
Show reports Nanna
Change Rates Laura
48. 48
4 Design Nanna, Laura
4.1 Component Design
Figure 7, Component Diagram
Figure 8, Toll Lane Computer to Station Server protocol Laura
Figure 9, Toll Lane Computer to the Touchscreen protocol Laura
Figure 10, Toll Lance Computer to Credit Card Reader protocol Laura
Figure 11, Toll Lane Computer to the Antenna protocol Laura
Figure 12, Toll Lane Computer to Single Ticket Reader Nanna
Figure 13, Toll Lane Computer to Barrier protocol Laura
Figure 14, Station Server to Station Client Protocol Nanna
Figure 15, Toll Lane Computer to Sensor Protocol Ioannis, Alexandru
Figure 16, Toll Lane Computer To Printer Protocol Ioannis, Alexandru
Figure 17, Cash Register to Toll Lane Computer Protocol Ioannis, Alexandru
Figure 18, Printer To Toll Lane Computer Protocol Ioannis, Alexandru
Figure 19, Sensor to Toll Lane Computer Protocol Ioannis, Alexandru
Figure 20, Station Server to Toll Lane Computer Protocol Ioannis, Alexandru
Figure 21, Station Server to Enterprise Server Protocol Ioannis, Alexandru
Figure 22, Enterprise Server to Enterprise Client Protocol Ioannis, Alexandru
Figure 23, Enterprise Server to Station Server Protocol Ioannis, Alexandru
Class Design
Figure 24, Detailed Class Diagram All
OCL Constraints Ioannis, Dimitrios
Behavior Design
Figure 25, Toll Lane Computer Behavior Diagram Ioannis, Alexandru
Figure 26, Station Server Behavior Diagram Dimitrios, Nanna
Figure 27, Enterprise Server Behavior Diagram Dimitrios
5 Validation
5.1 Use Case Realization
Figure 28, Check-in Normal Lane Credit Card Sequence Diagram Ioannis, Alexandru
Figure 29, Check-in Normal Lane Cash Sequence Diagram Ioannis, Alexandru
Figure 30, Check-in Express Lane Sequence Diagram Ioannis, Alexandru
Figure 31, Check-out Normal Lane Sequence Diagram Ioannis, Alexandru
Figure 32, Check-out Express Lane Sequence Diagram Ioannis, Alexandru
Figure 33, Show Reports Sequence Diagram for Enterprise Manager Nanna
Figure 34, Show Reports Sequence Diagram for Station Manager Nanna
Figure 35, Change Rates Sequence Diagram Laura
Figure 36, Physically Buy Toll Tag Sequence Diagram Dimitrios
Figure 37, Electronically Buy Toll Tag Dimitrios
Conclusions Laura, Nanna