Assessment item 3
Validation phase
Value: 25%
Due date: 26-May-2017
Return date: 19-Jun-2017
Length: Word length1800 to 2000
Submission method options
Alternative submission method
Task
In this assignment, you are required to complete the followings to validate your system designs.
You have the following two choices to develop detailed object-oriented design models. You also need to submit a proper documentation describing the different aspect of developed component, within 2000 words.
Task 1: The students who have expertise in object-oriented programming are required to validate their system design through developing a prototype for at least one subsystem of chosen case study. You have an option to use any object-oriented programming language such as C++, Java, C#, etc. to develop this subsystem.
OR
Task 2: The students who have no expertise in object-oriented programming are required to validate their system design using interaction diagrams (i.e., communication diagrams or sequence diagrams) for at least one subsystem of chosen case study. To do this, identify 3 (three) most important use cases for the subsystem and develop communication diagrams or sequence diagrams for these use cases.
Rationale
The purpose of this assessment task is to develop student's skills and knowledge in :
• validating an OO design through the construction of a prototype
• converting design diagrams into program code
• preparing project documentation
• developing presentations, and through peer review to reflect on their own practice and improve their design.
This assessment item links to the learning outcomes (LO) 1,2,3,4,5 and 6.
Marking criteria
Criteria HD DI CR PS FL
Task 1 (70%): The students who have expertise in object-oriented programming are required to validate their system design through developing a prototype for at least one subsystem of chosen case study. You have an option to use any object-oriented programming language such as C++, Java, C#, etc. to develop this subsystem.
OR
Task 2 (70%): The students who have no expertise in object-oriented programming are required to validate their system design using interaction diagrams (i.e., communication diagrams or sequence diagrams) for at least one subsystem of chosen case study. To do this, identify all possible use cases for the subsystem and develop communication diagrams or sequence diagrams for these use cases.
Task 1:
Fully functional prototype using major principles of object-oriented programming such as encapsulation, data abstraction, polymorphism and inheritance. Each variable, function/method, loops, if/else statements, etc are well commented.
OR
Task 2:
All possible use cases of the subsystem are identified; developed communication or sequence diagrams are correctly showing logical flow of the system activities, input/output messages, and accurate symbols/notations.
Task 1:
Mostly fully functional prototype using major principles of object-oriented programming such as encapsulation, data abstraction, polymorphism and inheritance. Each variable, function/method, loops, if/else statements, etc are well commented.
OR
Task 2:
Major use cases of the subsystem are identified; developed communication or sequence diagrams are correctly showing logical flow of the system activities, input/output messages, and accurate symbols/notations.
Task 1:
Mostly fully functional prototype using major principles of object-oriented programming such as encapsulation, data abstraction, polymorphism and inheritance. Each variable, function/method, loops, if/else statements, etc are well commented.
Minor omission only
OR
Task 2:
Major use cases of the subsystem are identified; developed communication or sequence diagrams are correctly showing logical flow of the system activities, input/output messages, and accurate symbols/notations.
Minor omission only
Task 1:
Prototype not always functional using major principles of object-oriented programming such as encapsulation, data abstraction, polymorphism and inheritance. Each variable, function/method, loops, if/else statements, etc are not well commented.
OR
Task 2:
Some use cases of the subsystem are identified; developed communication or sequence diagrams are mostly correct showing logical flow of the system activities, input/output messages, and accurate symbols/notations.
Task 1:
Prototype has major errors and not working.
OR
Task 2:
Few use cases of the subsystem are identified; developed communication or sequence diagrams are wrong.
Task 1 & Task 2 (30%)
Submit a proper documentation describing the different aspect of developed component, within 2000 words.
Task 1 & Task 2:
Comprehensive documentation which describes each component of developed system and has insights and awareness of deeper more subtle aspects of the case study.
Task 1 & Task 2:
Mostly comprehensive documentation which describes each component of developed system and has insights and awareness of deeper more subtle aspects of the case study.
Task 1 & Task 2:
Mostly comprehensive documentation which describes each component of developed system and has insights and awareness of deeper more subtle aspects of the case study.
Minor emission only
Task 1 & Task 2:
Reasonable documentation describes few components of developed system.
Task 1 & Task 2:
Documentation is wrong and not matching with system components.
Presentation
Reports should be submitted is MS Word format, using the CSU referencing style of APA.
Diagrams can be created using any available tools.
Requirements
Students should visit and read the CSU Referencing Policy at http://student.csu.edu.au/study/referencing-at-csu
ITC508 – Case Study 1
XYZ Car Park System
XYZ operates 10 car parks in the centre of city. The City administration has a requirement for a new and innovative system to control its car parks. The new system should therefore be capable to handle the day-to-day operation of each car park, which include:
• Generate tickets (i.e. ordinary, season)
• Accept tickets
• Handle payment
• Control boom gates
• Record problems in a log book
• Manage security
Detailed information on some aspects of the XYZ car parking system is listed below.
1. Types of customers
There are two types of customers: ordinary customers, who pay for their use of each car park at the time they use it; and season customers, who pay a fixed amount in advance for parking for three, six or twelve months in a
specific car park.
Season ticket holders can only park in the designated spaces which are not available to ordinary customers from Monday to Friday. Season tickets are for weekdays only; the designated spaces are available to all customers at weekends.
2. Tickets generation
Depending the type of user, the following types of tickets can be generated.
A season ticket is issued to a named individual or company, and the address and contact telephone number of that person or company is recorded. Each season ticket is valid for three, six or twelve calendar months, and the issue date and expiry date are recorded.
An ordinary ticket is issued for a short term stay at the car park.
3. Parking fees
Parking fees need to be calculated by using the following mechanism.
Season customer
3 months 200 AUD
6 months 375 AUD
12 months 500 AUD
Ordinary customer
Early bird (during weekday’s midnight to 10 AM) hour
2.5 AUD per
Normal rate (during weekdays 10 AM to midnight)
5 AUD per hour
Early bird (during weekend’s midnight to 10 AM)
5 AUD per hour
Normal rate (during weekend’s 10 AM to midnight) 10 AUD per hour
4. Mode of payment
Payment at car park can only be made through the following ways.
Card (Master / VISA / DEBT)
Cash (50c, 1$, 2$, 5$, 10$, 20$, 50$)
5. Access to the Car Park
When a car approaches an entry barrier, its presence is detected by a sensor under the road surface, and a ‘Press Button’ display is flashed on the control pillar.
The ordinary customer must press a button on the control pillar, and a ticket is printed and issued. The ticket must be printed within five seconds. A ‘Take Ticket’ display is flashed on the control pillar. If the car park is full, no ticket is issued, and a ‘Full’ display is flashed on the control pillar. If a vehicle leaves the car park, then the ‘Press Button’ display is activated again where there is a vehicle waiting. When the customer pulls the ticket from the control pillar, the barrier is raised. The ticket issued to each ordinary customer has a bar code on it. The bar code has a number on it and the date (dd/mm/yyyy) and time (hh/mm/ss) of entry to the car park. The number, date and time of entry are also printed on the ticket in human readable form. The details of the ticket are stored: ticket no., issue date, issue time, issuing machine. The number of vehicles in the car park is incremented by 1 and a check is made against the capacity of the car park. If the car park is full, then a display near the entrance is switched on to say ‘Car Park Full’, and no further tickets are issued until a vehicle leaves the car park.
The season ticket holder does not press the button, but inserts his or her season ticket into a slot on the control pillar. A check is made that the season ticket is valid for this car park and has not expired, that it is a weekday and that the season ticket holder is not recorded as having already entered this car park and not left. If all these checks are passed, then the barrier is raised. The checks must take no longer than five seconds. A record is made of the time of entry for that season ticket holder. A sensor on the other side of the barrier detects when the car has passed and the barrier is lowered.
6. Exit the Car Park
When the customer drives up to the exit barrier, the car is detected by a sensor, and an ‘Insert Ticket’ display is flashed on the control pillar. The customer must insert the ticket. The bar code is read and a check is made that no more than 15 minutes have elapsed since the payment time for that ticket. If more than 15 minutes have elapsed, an intercom in the control pillar is activated and connected to the attendant in the car park office. The customer can talk to the attendant, and the attendant can view the details of the ticket on his or her computer. The attendant can activate the barrier remotely, for example if there is a queue to get out and the customer is likely to have been reasonably delayed. If no more than 15 minutes have elapsed, the barrier is raised. A sensor on the other side of the barrier detects when the car has passed and the barrier is lowered.
The number of vehicles in the car park is decremented by 1 and a check is made against the capacity of the car park. If the car park was full, then the display near the entrance is switched to say ‘Spaces’, and a check is made to see if any vehicles are waiting. If they are, then the control pillar for the first waiting vehicle is notified. If the driver of the vehicle waiting there does not press the button (for example, because they have backed out and left), then the control pillar for the next waiting vehicle is notified. At any time, the attendant can view the status of a pay station or a barrier control pillar. Once a connection is made, the status is updated every 10 seconds.
Season ticket holders do not have to go to the pay station, when they are ready to leave the car park, they go to the exit and insert their season ticket into a slot on the exit barrier control pillar. The barrier is raised and a record is made of the time at which the season ticket holder left.
7. Payment handling
When the ordinary customer is ready to leave, he or she must go to a pay station to pay. The ticket is inserted into a slot, and the bar code is read. The ticket bar code information is compared with the stored information. If the dates or times are not the same, the ticket is ejected, and the customer is told (via an LCD display) to go to the office. In the office, the attendant has a bar code reader and can check a ticket. Typically the problem is damage to the bar code on the ticket, and the attendant can use the office system to calculate the charge, take payment and validate the ticket (see below).
At the pay station, if the ticket dates and times are the same as the bar code dates and times, then the current date and time are obtained, and the duration of the stay in the car park is calculated. From this the car park charge is calculated and displayed on the LCD display. Calculation and display of the charge must take no more than two seconds. The customer must then insert notes or coins to at least the amount of the charge. Each note or coin is identified as it is inserted and the value added to an accumulated amount and displayed on the LCD display. Invalid notes are ejected from the note slot. Invalid coins are dropped through into the return tray. A message is displayed on the LCD display. As soon as the amount accumulated exceeds the charge, the ticket is validated. The current date and time are added to the stored data for that ticket (payment date, payment time). If the amount entered exceeds the charge and change is available, then the amount of change is calculated and that amount of change is released into the return tray. Otherwise, no change is given. In either case, a message is displayed on the LCD display. The ticket has the payment date and time printed on it and is ejected from the ticket slot. A message is displayed telling the customer to press the ‘Receipt’ button if they need a receipt. If they press this button, a receipt is printed and ejected into the receipt tray. The receipt shows the City administration address, address of the car park, VAT number, date and amount paid. A message is displayed for the customer telling them to take the ticket back to their car and leave the car park within 15 minutes.
8. Security management
The City administration has a contract with security companies to visit the car parks at regular intervals. The contract specifies the number of visits per day to each car park and the minimum duration of each visit. Each car park has an office to which the security guards have access. In the office is a card reader similar to the one used for reading season tickets in the control pillars. When a security guard arrives in a car park, he or she puts a card into the card reader and the date and time of arrival is recorded. When the security guard leaves, he or she puts the card in again, and the departure time is recorded. (This card also allows security guards to enter and leave the car park in the same way as season ticket holders. However, this is not used to record the arrival and departure of security guards, as they may not be able to enter with a vehicle if there is a queue of cars at the barrier.)
Currently, the City administration uses two security companies, but could use more or only one in the future. Each security company is issued with a specific number of cards, depending on the number of car parks they are responsible for. Each security company is responsible for specific car parks.
9. Fault management
There is a requirement for a fault recording system to be used to record all problems with car parks. Most faults are expected to be with equipment (barriers, card readers, security cameras etc.) although they can include things such as broken windows and doors. Details of the fault and the date and time at which it was reported are recorded. If the fault applies to equipment or some other aspect of the operational system, there is a requirement that the maintenance company must be notified straight away. For other problems, the City administration’s direct labour organisation will be notified. The date and time when faults have been fixed must also be recorded, so that the City administration can monitor the service level agreement with the maintenance company. There is a requirement to be able to produce a monthly statistical report of all faults, which organisation they were allocated to and how long they took to be fixed.