Overall Aim.
To implement a software system in C#, that can read and write data in standard XML, store and
retrieve data from an SQL database in a user friendly manner.
2.0 Assignment
2.1 Assignment Aims
Students will be provided with the following software (on blackboard) :
An Access database file.
The aim of the coursework is to give students practical experience in object oriented software
development by implementing a system in an object oriented language (C#) that involves a number
of real-world engineering applications (reading and writing standard data format (XML), database
access and storage, user interface design).
2.2 The System.
A company has developed an autonomous robot system that has the capability to deliver small to
medium sized objects over a short distance. The robots are to be used in a large warehouse
environment to move small parts, tools, orders etc. An empty robot can travel for 1000m before it
has to re-charge, for each 5kg the robot carries it operates 5% less efficiently E.G.
Empty / lightly laden robot (0 - 5.0kg) can travel for 1000m.
5.1 – 10.0 kg weight the robot can travel 95% of 1000m (1000 * 0.95 = 950m)
etc.
So if a robot moves 500m with 0 – 5.0kg it uses 50% of battery power.
If a robot moves 500m with 5.1 – 10.0kg it uses 55% of battery power.
etc.
The maximum weight a robot can carry is 25.0 kg. It is assumed that size is not an issue.
All robots always move at their maximum speed of 5m/s regardless of cargo weight.
The warehouse is assumed to be a simple square, 100m along each side. There is a re-charging
station in each corner and robots are assumed to be able to move in a straight line at all times and
never collide.
The Access database file supplied is an empty database with a single table. The database schema
is given below :
RobotName StartPos GoalPos CargoWeight ETA BatteryLevel TotalDistanceCovered NoOfJobs
Where :
RobotName is the ID of the robot and is the primary key.
StartPos is the starting position of the robot, at the beginning this is assumed to be at 0,0 but after
each robot’s first job it will be where the last job ended.
GoalPos is the position the robot is being sent to in x,y co-ordinates.
CargoWeight is the weight of the object the robot is carrying.
ETA is when we expect the robot to arrive at the goal position.
BatteryLevel is the level that the battery will be AFTER the job has been completed.
TotalDistanceCovered is how far the robot has moved since the simulation began.
NoOfJobs is how many jobs the robot has completed.
2.3 Part One - Software development.
The student is required to write two C# programs that perform. the following actions :
Program 1.
You are required to write a program that takes input from the user and outputs a valid XML file for
use with the second program.
The program should read in the following :
The robot’s name.
The weight of its cargo.
The goal position it is to go to.
A filename for the resulting XML file. (It is assumed all files will be saved to bin/debug)
The program should warn the user if any information is missing or is invalid. The program should
not crash or terminate abnormally regardless of user input.
Program 2.
Your second program should be able to load an XML file created by the first program, read the
information and update the database.
The program should perform. the following functions.
It should update values for existing robots in the database.
It should create rows for new robots in the database.
To perform. this the program will have to perform. the following calculations (amongst others) :
What effect the current task will have on the battery level.
How long the robot will take to get to the new position.
If a robot runs out of battery during a job the warehouse can send out an emergency crew to
recharge the battery in the warehouse but this task takes a total of 10 minutes (to fully recharge,
robots always fully recharge).
If a robot travels to a charging station in can fully recharge in 20 seconds.
Yo ur program should do the following :
If a file is loaded whilst the requested robot is still moving on another job, this job request
should be rejected and the user told that the robot is busy.
If the requested job will deplete the robot’s battery the system should warn the user that this
will occur and take into account the extra time needed if an emergency crew needs to
recharge it.
o A better solution (for better marks) would route the robot to a recharging station first.
o This requires keeping track of how far robots are away from recharging stations at
any given time.
The program should also, at the user’s request, bring back statistics on :
o Which robot has travelled the furthest.
o Which robot has completed the most jobs.
o All current robot goal positions along with the robot names.
For better marks (as these are a bit trickier).
o How far apart two robots in the system are (at completion or (very tricky) at that
exact moment in time).
o Which robot is nearest to a given location.
The program should also allow experienced users to write SQL statements, in the main GUI,
to query the database but it should prevent the user from being able to modify the contents
of the database in any way.
2.4 Part Two - Documentation
Students are required to produce a report that details their development of the program written for
part one. The report should include the following sections :
Development description. A detailed account of what the student did in order to produce
the submitted programs. This may include diagrams showing data / process flow and
control, UML etc., any necessary assumptions made, testing details, explanation of
algorithms used etc.
Brief discussion on ideas for improving the program, this discussion is theoretical and the
student is not expected to implement changes, therefore the discussion should not be limited
to changes that are either within the student’s ability range or within the time allocated for
the coursework.
3.0 Marking Scheme
This assessment is worth up to 50% of the marks for the module, and covers the following module
learning outcomes :
1. Develop appropriate software solutions to technological problems.
2. Describe and apply features of an object oriented programming language.
3. Effectively exploit the programming language and development environments.
4. Effectively apply software design and development principles.
The breakdown of the marks for the assignment is as follows :
Part One – Software Development (Total 70%)
Part Two – Report (Total 30%)
Software should be appropriately commented and should employ the techniques and principles of
object oriented programming demonstrated in the lectures and labs where appropriate.
Reports should be produced to a professional standard, reports that are badly formatted and/or
contain numerous examples of poor grammar/punctuation/spelling may be penalised.
Students are heavily encouraged to get the basic program working first before attempting higher
value features. Students should consider producing different versions of their software in case an
added feature breaks currently working code.
4.0 Timescales
Both the sourcecode (in the form. of a zipped Visual Studio Project) and the report should be
uploaded to Turnitin on the EL2311 Blackboard space 11:59pm on Sunday 18th Feb. Standard
penalties for lateness apply.
This is an individual assignment, please refer to the student handbook for details regarding fairness
and plagiarism.
5.0 Assessment Criteria
Grade Mark Descriptor
100 Flawless work, all requirements met and e xceeded
Exceptional 1st 96 Impressive treatment of all requirements, thorough analysis and
explanations, insightful comparisons and impressive software design with an
exceptional report.
High 1st 89 Excellent treatment of all requirements, thorough analysis and explanations,
critical comparisons, excellent software design with an outstanding quality
report.
Mid 1st 81 Comprehensive treatment of all requirements, thorough analysis and
explanations, critical comparisons, very good software design and evaluation
with an appropriately structured, grammatically correct, clear and concise
report.
Low 1st 74 Very good treatment of all requirements, sound analysis and explanations,
sound comparisons, very good software design and evaluation, with an
appropriately structured, grammatically correct, clear and concise report.
High 2.1 68 Good treatment of all requirements, sound analysis and explanations,
critical comparisons, good software design and evaluation, with an
appropriately structured, grammatically correct and clear report.
Mid 2.1 65 Good treatment of most requirements, good analysis and explanations,
sound comparisons, with good software design and evaluation with an
appropriately structured, mostly grammatically correct and clear report
Low 2.1 62 Generally a good treatment of most requirements, good analysis and
explanation, some comparisons, good software design and evaluation with
a structured, mostly grammatically correct and clear report.
High 2.2 58 Generally a good treatment of key requirements, some analysis and
explanation, good software design and a structured, mostly grammatically
correct and clear report.
Mid 2.2 55 Generally a good treatment of key requirements, some analysis and
explanations, and a satisfa ctory report with good software design and
evaluation.
Low 2.2 52 Mostly a reasonable treatment of requirements, some analysis and
explanations with software design and evaluation and a satisfactory report.
High 3rd 48 Adequate treatment of require ments, basic analysis and explanations with
software design and evaluation and content structured and quite clearly
presented.
Mid 3rd 45 Patchy treatment of requirements, limited analysis and explanations with
some attempt at evaluation and software design and a generally satisfactory
report.
Low 3rd 42 Limited treatment of requirements, superficial analysis and explanation, with
some attempt at evaluation and software design and some attempt to
structure content as a report.
Marginal Fail 35 Superficial treatment of requirements, poor analysis and explanation with
limited attempt at software design.
Mid Fail 30 Inadequate treatment of requirements, little if any analysis and explanation
with poor software design.
Low Fail 25 Poor treatment of requirements with little work
Fail 10 Limited and incoherent treatment of requirements.
Non submission 0 No work submitted by deadline.