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.

 

Therefore a robot carrying 5.1 to 10kg

 

100% / 95% = 1000 / x.  x = 950 therefore a robot operating at 95% efficiency could travel 950m

 

At 95% efficiency 1% of battery moves the robot 950 / 100 = 9.5m

Or moving 1m uses 1/9.5 = 0.1053% of the battery (rounded to 4 decimal places)

 

 

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.

 

Your 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 exceeded
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 satisfactory 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 requirements, 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.