CHS2546 Distributed and Client-Server Systems
Introduction
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
Environmental monitoring has become increasingly important over recent years. In particular, the
UK's failure to meet EU Environmental Standards for air quality in city centres, caused mainly by
air pollution from petrol and diesel engined vehicles, has led to an increased focus on how to
monitor the level of pollutants in the atmosphere, and how to warn the public of areas of particular
concern. A new company, Environmental Monitor, is looking to develop a low cost system to
monitor air pollution throughout city centres. Starting initially at busy junctions and known traffic
black spots, the company plans to roll out monitoring equipment throughout the UK, collecting real
time readings of a range of pollutants, staring with nitrogen oxides (Nox) levels. The company
would like to have the ability both to retrieve data from monitoring stations (i.e. to use a 'pull'
technology) on a regular basis (typically every hour, but this is subject to further discussion), and
for the monitoring stations to contain sufficient on-board processing for them to be able to raise
alarms (i.e. use a 'push' technology) should extreme or unexpected readings arise. In order to
reduce the possibility of false alarms, two monitoring stations in the same geographical area must
raise an alarm before this is passed on to the Environmental Centre for analysis.
The company is looking to develop a prototype distributed Client-Server implementation, based
around the CORBA architecture. It is envisaged that a monitoring station will eventually contain
sensors to measure various pollutants and indicators of air quality, but initially the company will
focus on nitrogen oxides as a basic proof of concept. The company has decided on an architecture
for the system that comprises: the Monitoring Station, which can be installed wherever required and
communicate with the rest of the system over wireless 4G networks; a Regional Centre, to which all
monitoring stations in a particular geographical area will be connected; and a central Environmental
Centre, to which the regional monitoring stations will report. The idea behind this architecture is
both to distribute the processing and communications within the system, and to provide resilience
should, for example, the central environmental centre become unavailable for some period of time.
The company have asked you to prototype the system, and to make recommendations as to the
suitability of the architecture and the platform. selected.
Coursework
A CORBA-based client-server system.
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 Monitoring Station
The Monitoring Station is a stand-alone monitoring system, to be prototyped as a CORBA server,
that supports the following functionality at least:
Register itself with a Regional Centre upon initial activation
Can be switched on
Can be switched off
Can be reset
Can return, upon request, the current value of the nitrogen oxides sensor
Can identify anomalous or potentially dangerous readings of nitrogen oxides and alert
the Regional Centre immediately.
Note that, for this prototype implementation, there is no expectation that real sensors be used.
Instead a (simple) GUI is envisaged as representing the state of the sensor.
A preliminary IDL starting specification might be:
struct Reading {
long time;
long date;
string station_name;
long reading_value;
};
interface MonitoringStation {
readonly attribute string station_name;
readonly attribute string location;
Reading get_reading();
void turn_on();
void turn_off();
void reset();
} ;
2. The Regional Centre
The Regional Centre is to be prototyped as a CORBA server that supports the following
functionality at least:
Receives requests to register Monitoring Stations and maintains a list of connected
devices
Receives alerts from connected Monitoring Stations, and maintains a log of these
alerts
Triggers an alarm at the Environmental Centre when two alarms happen within a
specified time frame
Returns the log upon request
Polls all connected Monitoring Stations when requested to do so, and returns a set of
readings
A preliminary IDL starting specification might be:
Typedef sequence Log_of_alarm_readings;
Typedef sequence Set_of_readings;
interface RegionalCentre {
readonly attribute string name;
readonly attribute Log_of_alarm_readings log;
void raise_alarm (in Reading alarmReading );
Set_of_readings take_readings();
void add_monitoring_station(in string station_name, in string station_location, in
string station_ior);
} ;
3. The Environmental Centre
The Environmental Centre is to be prototyped as a CORBA server that supports the following
functionality at least:
Receives confirmed alarms from Regional Centres
Alerts the operator when a confirmed alarm is received
Allows agencies (e.g. the Environment Agency, local councils, local pressure groups,
etc.) to register for notifications in case of alarms
Maintains a list of connected Regional Centres
Polls all Regional Centres upon request and displays the results of readings returned,
highlighting readings of concern
A preliminary IDL starting specification might be:
interface EnvironmentalCentre {
void raise_alarm(in Reading alarm_reading);
void register_agency(in string who, in string contact_details,
in string region_of_interest);
void register_regional_centre(in string centre_name)
} ;
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 alarm can be serviced at a time.
2. Two Regional Centres is a reasonable starting point for the purpose of testing the full
functionality of your simulation.
3. Two Monitoring Stations connected to each Regional Centre is a minimally sensible start, but for
full testing more will almost certainly be needed, and support for locations (with one or more
monitoring stations in each location) should be considered.
4. Days can be treated as simple integer day numbers (starting from Jan 1st), times can be treated
as simple integer minutes starting from midnight.
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
Environmental Monitoring 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 module’s UniLearn
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 close 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.