[SOLVED] C GUI software Author

Author
Date Written Handed to Students Hand In Date Return to Students
Introduction
CHS2546 Distributed and Client-Server Systems Coursework Specification 2
: Gary Allen
: September 2018
: Term 2, Week 4
: By noon on Friday 5th April, 2019 : After examination boards
This document describes the second coursework for module CHS2546 Distributed and Client- Server Systems. As stated in the module handbook, this module is assessed by 2 equally weighted courseworks. This assignment involves the design and development of a client-server application based upon the Corba middleware. This coursework assesses learning outcomes 1.1, 1.2, 1.3, 1.4, 2.1, 2.2, 2.3.
Background
Car parking is big business in the UK. Owners of car parks seek to ensure all drivers who use their facilities are charged fully and correctly. Some car parks have only one entrance, one exit, and one pay station, but others may have multiple entry and exit points and multiple pay points. The ParkHere company have recently purchased a number of car parks of various sizes and layouts throughout the UK, and they are looking for a software system that could be used at all sites, ensuring all drivers pay the correct rates, reporting any who default on their payments, and collecting data on the number of users at each site, the amount of money collected, and other useful management data. You have been employed by the company to design and prototype a suitable solution based on the Corba middleware technology.
Each car park will have:
One or more Entry Gates, equipped with Automatic Number Plate Recognition cameras.
These gates will signal to a Local Server whenever a car enters the car park, passing the
date, time, and registration number of the vehicle.
One or more Exit Gates, also equipped with Automatic Number Plate Recognition cameras.
These gates will signal to a Local Server whenever a car exits the car park, passing the date,
time, and registration number of the vehicle.
One or more Pay Stations, where the driver (or passenger) will pay to use the car park.
ParkHeres policy is that a driver must pay in advance for their parking ticket. Having arrived at the car park the driver must enter their registration number into the Pay Station, which will then check with the Local Server to ensure the car has been recognised as having entered the car park. The user must then pay 1 for every hour that they wish to park. The machine will then dispense a ticket with the date, time, registration number, amount paid, and time by which the vehicle must leave the car park. The Pay Station will also maintain a log of how much money has been taken that day.
One Local Server. This will be a hidden, headless computer without a screen or keyboard. It receives data from the Entry and Exit Gates and the Pay Stations, and maintains a log of how many vehicles are currently in the car park, how many have been paid for, how many have not yet been paid for, how many spaces are available, and the total cash taken that day. The Local Server also uploads data to the Company HQ, and can be queried remotely by the Company HQ. In particular, whenever a car leaves the car park without paying for a ticket (after a 5 minute grace period has elapsed) or leaves the car park more than 5 minutes after the expiry of their ticket, the Local Server notifies the Company HQ of the event, passing the number plate and other details to HQ so that enforcement action can be taken.

Note that the above information does not specify how to deal with error conditions such as faulty devices, full pay stations, drivers trying to pay for cars that have not been recognised by the Entry Gates, etc. It is proposed that the initial prototype concentrates on the core functionality, but it would be sensible to design the system in such a way as to enable additional functionality to be added incrementally in the future. Another possible extension would be a display board, showing the current number of free spaces. This could be added if time permits.
Coursework
A CORBA-based client-server system is required.
The requirements of the system can be broken down into a number of separate systems which will need to communicate in a client-server manner to solve the overall requirements.
1. The Entry Gate
The Entry Gate is a stand-alone monitoring system, to be prototyped as a CORBA server, that supports the following functionality at least:
Register itself with a Local Server upon initial activation Can be switched on
Can be switched off
Can be reset
Can report to the Local Server every time a vehicle enters the car park.
Note that, for this prototype implementation, there is no expectation that real cameras be used. Instead a (simple) GUI is envisaged as representing the state of the device.
A preliminary IDL starting specification might be: interface EntryGate {
readonly attribute string machine_name; void turn_on();
void turn_off();
void reset();
};
2. The Exit Gate
The Exit Gate is similar to the Entry Gate, reporting when a vehicle leaves the car park. It will have much the same functionality as the Entry Gate above.
3. The Pay Station
The Pay Station is where drivers pay for their parking. It is to be prototyped as a CORBA server that supports the following functionality at least:
Register itself with a Local Server upon initial activation Can be switched on
Can be switched off
Can be reset
Can (via a suitable GUI) allow the user to enter a registration number and then check that the vehicle is currently in the car park. The user can then indicate how long they wish to park for, and the Pay Station will print (i.e. display) a suitable ticket while the Pay Station reports the payment to the Local Server.
Can maintain (and return upon request) a total of cash received that day.

A preliminary IDL starting specification might be: interface PayStation {
readonly attribute string machine_name; void turn_on();
void turn_off();
void reset();
long return_cash_total(); };
4. The Local Server
The Local Server is the centre of the system, receiving entry and exit notifications and payments. It maintains the current state of the system (how many vehicles are currently in the car park, how many have been paid for, how many have not yet been paid for, how many spaces are available, and the total cash taken that day). When a vehicle leaves the car park without paying, or after the expiry of a payment (always allowing 5 minutes grace), the Local Server will notify HQ. It is to be prototyped as a CORBA server that supports the following functionality at least:
Receives requests to register Entry and Exit Gates and Pay Stations, and maintains a list of connected devices
Receives notifications from connected Entry and Exit Gates and Pay Stations, and maintains a log of these events and updates the internal state of the system (as above) Returns the log upon request
Can maintain (and return upon request) a total of cash received that day. Triggers an alarm at the Company HQ when a vehicle exits owing money
A preliminary IDL starting specification might be: struct VehicleEvent {
long time;
long date;
string registration_number;
};
Typedef sequence Log_of_vehicle_events;
interface LocalServer {
readonly attribute string location;
readonly attribute Log_of_vehicle_events log;
void vehicle_in(in VehicleEvent event);
void vehicle_out(in VehicleEvent event);
boolean vehicle_in_car_park(in string registration_number);
long return_cash_total();
void add_entry_gate(in string gate_name, in string gate_ior);
void add_exit_gate(in string gate_name, in string gate_ior);
void add_pay_station(in string station_name, in string station_ior);
};
3. The Company HQ
The Company HQ is to be prototyped as a CORBA server that supports the following functionality at least:
Receives details of vehicles leaving a car park while owing money
Alerts the operator when such an event is received
Maintains a list of connected Local Servers
Retrieves the log from a selected Local Server and displays this to the operator.

A preliminary IDL starting specification might be: interface CompanyHQ {
void raise_alarm(in VehicleEvent event);
void register_local_server(in string server_name, in string server_ior); };
DO NOTE that all of the above IDL has been given as a starting point. It could be incomplete, it could be better structured, it definitely contains a few errors, and it does require further development.
To make these tasks easier, you may make the following assumptions:
1. Only one event can be serviced at a time.
2. Two Local Servers is a reasonable starting point for the purpose of testing the full functionality
of your simulation.
3. Two Entry Gates, two Exit Gates, and two Pay Stations connected to each Local Server is a
minimally sensible start, but for full testing more may be needed.
4. Dates can be treated as simple integer day numbers, and times can be treated as simple integer
minutes. Registration numbers can be treated as simple strings such as A1, A2, etc.
5. Any user interfaces need not be very sophisticated (this is NOT a GUI intensive application
there are NO MARKS for a flash GUI with no functionality!).
6. Any ambiguities may be resolved to your own satisfaction as long as they are clearly justified.
The focus of this assignment is to encourage you to construct a software model of the Car Park scenario in which functionality is achieved by using the services provided by different classes of software objects.
Hand In
You are required to hand in a report containing the following components:
1. System Design (to include as a minimum a use case diagram, a class diagram, and at least 2 relevant and non-trivial sequence diagrams, along with approximately half a page of supporting discussion and justification of the design decisions made).
2. All final IDL specifications (be wary of auto-generated IDL files and highlight the relevant parts, if appropriate).
3. All source code (you need NOT include the auto-generated stubs and skeletons).
4. Evidence of system behaviour and a detailed evaluation of the extent to which you have been able to implement the features required. This analysis should highlight not only your successes but also any outstanding incomplete, incorrect, or awkward features.
5. A critique of the work undertaken, which MUST include a critical evaluation of the chosen architecture, and a discussion of at least one alternative solution to the given problem, identifying the advantages and disadvantages of each. For example, you could compare your solution to another, alternative CORBA architecture, or you could compare your CORBA solution to a Web Services solution. You should seek to highlight advantages and disadvantages of each approach. This report should be approximately one to two sides of A4.
It is very difficult to give a word count for a programming assignment, but I would expect the design to run to about 4 5 sides, including diagrams, and the testing should also be around 4 -5 sides. If the code meets the minimum specification (above) then it can gain an A grade. To get an

A+ you need to add some extra features, ensure the system is highly robust, and generally make a high quality product.
The report will be submitted to the TurnItIn plagiarism checking service via the modules Brightspace page. Further details of how to submit the work will be provided closer to the due date. You must also hand in all code developed along with instructions for running the code. Full details of how to submit the code will be provided closer to the hand in date.
You might also be asked to demonstrate your system, in order to allow the functionality and reliability of the software to be assessed, but note that the presentation itself will not contribute to the grade.
Assessment
Your work will be marked on the quality of the design of the software (30% of the marks, assessed from the quality of the documentation produced and from examination of the code), the quality of the code handed in (including completeness, correctness, layout, comments, selection of variable names, etc., and worth 30% of the marks), the quality of the testing carried out (20% of the marks), and the quality of the evaluation/critique produced (20% of the marks).
The list shown below gives a rough idea of the grade to be awarded to the differing standards of work which might be submitted.
A Grade A well presented piece of work, well structured program code implementing an appropriate design, thorough testing with well chosen test data, and a thoughtful evaluation/critique of what has been achieved.
B Grade Similar to an A grade but with deficiencies in one or two areas.
C Grade A competent piece of work with a good (but not ideal) design, code that mostly works but is incomplete or contains a few bugs, a reasonable attempt at testing, and a reasonable evaluation/critique.
D Grade A poor but mostly usable design, code which compiles but does not work fully, poor or incomplete testing, and an evaluation/critique which lacks depth.
E/F Grade Poor design, faulty code, little testing.
NOTE that this is entirely an individual assignment. Collusion is cheating and will be dealt with severely. If I have any doubts as to the originality of any work submitted I will report this to the Academic Integrity Officer who will hold a full investigation.
Hints and Tips
The following may help you to undertake this assignment:
1. Understanding is essential.
You cannot build a system until you understand what is required. Take time to draw a map of all of the different parts of the system, identify which are the clients and which are the servers, identify the information flow from class to class. Allocate functions to each class as required. Once you have a clear idea of what you are trying to do you can then start to implement it.
2. The incremental approach to software construction.

An advantage of the object-oriented approach is that you do not need to write a full working system at the outset. Development can be on a step-by-step basis. Utilise functions that do nothing. As you add each function to the class definition, you also add the corresponding code to your client program to use the function and make sure it works sensibly.
You are strongly advised to take the incremental approach so that you achieve the bare bones of a working system at a relatively early stage.