代写EL2311、代做SQL编程设计

日期：2024-03-30 06:26

School of Enginering
UCLan Coursework Assessment Brief
Academic
Year
Module Title: Software Development 2
Module Code: EL2311
2023/2024
Recording and analysing UAAV
movements with a database.
This assessment is worth
50% of the overall module
mark
THE BRIEF/INSTRUCTIONS
The following Learning outcomes will be assessed in this assessment
• 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.
Assessment Criteria Weighting (%)
Software Development 70
Report 30
Total 100
Introduction and background
Students will be provided with the following software (on blackboard) :
An SQL-Lite database file.
A client program that generates an XML file with data.
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 standard data format (XML), database
access and storage, user interface design).
The System.
The UCLan autonomous all-terrain Vehicle (UAAV) is in testing phase, the UAAV has been
designed to navigate extremely remote and hazardous locations and as such there will be many
times when direct communication will not be possible. With this in mind a system has been
designed that monitors various metrics around the vehicle and saves the data to a file. The
system saves a snapshot of readings once every 5 minutes whilst operating and saves the result
to an XML file for analysis (The client software simulates this by producing an XML file with all
the readings for that day).
You have been given the task of writing a software system that can take the readings file, save its
contents to a database and allow engineers to access the data.
The XML file contains data on when the readings took place, the UAAV’s speed at the time, its
internal cabin temperature, its engine compartment temperature, its fuel level, its battery charge
level and shock absorber wear.
The database file (Readings.db) contains a single empty table (UAAVData) that has the following
structure :
Day RunningTime Speed CabTemp EngTemp Fuel Battery ShockWear
Where :
• Day is the day the readings took place, this is an integer value set by the user in the client
program (note the UAAV is only ever tested once a day).
• RunningTime is the time the UAAV has been running, all tests run over a 5 hour period,
this is an integer value showing the time (in minutes) since the tests started.
• Speed is a double indicating the speed in miles per hour that the vehicle is travelling at the
time. After the initial start, a value of 0 indicates that the vehicle has stopped and
therefore a fault has occurred.
• CabTemp is a double indicating the internal temperature of the UAAV (in degrees Celsius).
• EngTemp is a double indicating the Engine Temperature (in degrees Celsius).
• Fuel is a double indicating how much fuel is left. The value is a percentage of remaining
fuel.
• Battery is a double indicting how much battery charge is left. The value is a percentage of
remaining battery charge.
• ShockWear is a double, this indicates how much stress and strain the UAAV’s shock
absorbers have sustained during the test. The value generated is a unitless metric
designed by an unknown engineer who has since left the project.
The databases table has a composite primary key consisting of Day and RunningTime.
Part One - Software development.
The student is required to write a C# program that performs the following actions :
• Reads in an XML file generated by the client program, it should do this cleanly without
errors and should be able to handle a malformed or non XML file being selected with an
error to the user but without a program crash.
• Permanently stores the data in the database file.
• Allows a novice user to run some basic queries on the database. (See below)
• Allows expert users to run custom SQL queries on the database. (See below)
There are two types of user that you need to account for when writing this program.
1) Novice Users. These users know no SQL or database theory at all, they need to be able to
retrieve simple information out of the database. The information your program should
allow them access to is as follows :
i) For a user selected day, the maximum and average readings of the following
sensors (Speed, CabTemp, EngTemp, ShockWear)
ii) For a user selected day, the minimum readings of the following sensors
(Fuel, Battery)
iii) For a user selected day, all the readings (along with time) if the UAAV
breaks down (see later)
iv) A report showing all successful runs, all runs that resulted in a breakdown
and all runs that completed successfully but were considered a failure (see
later).
2) Expert User. These users should be allowed to write any SQL query they wish and have it
run against the database. The program should return sensible errors any time the SQL
written is not valid. The expert users should NOT be allowed to add, modify or delete data
from the database.
Break Downs.
The UAAV never stops moving in the test once it starts, any value of 0 in the speed
attribute indicates a failure (all subsequent values for speed after that for the test will also
be 0, the UAAV can not self repair).
Things that can cause a break down are :
• Running out of fuel.
• Draining the battery.
• The engine overheating.
• Excessive shock wear.
For the latter two the value at which the system breaks is currently unknown.
Although it does not cause a break down (I.E. the UAAV will continue moving) if the
internal cabin temperature exceeds 30 degrees Celsius the test is considered a failure, due
to it being an unsuitable environment to transport people.
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 program. This may include diagrams showing data / process flow and
control, UML etc., any necessary assumptions made, testing details, explanation of
algorithms used etc.
• Testing plans to ensure the software is working correctly, this include (but is not limited
to) XML file loading, database queries, and database protection.
• 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.
• The student should also provide an estimate on the working limits of the UAAV’s engine
temperature and shock wear and explain how they estimated these figures.
• Brief discussion section that include how a system such as this could operate in real-world
conditions with autonomous vehicles.
Software should be appropriately commented (in English) 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.
Word count for the report (not including tables, diagrams and code) should not exceed
2000 words.
PREPARATION FOR THE ASSESSMENT
• All elements of the coursework have been covered in lectures and labs, all labs between the release of
the coursework and the coursework deadline will be dedicated to allow students to complete their
coursework.
RELEASE DATES AND HAND IN DEADLINE
Assessment Release date: 15
st February 2024 Assessment Deadline Date: 11.59pm 7
th April 2024

Your feedback and mark for this assessment will be provided within the University’s 15 working day policy for
feedback. Written feedback will be available on Blackboard on or before 29th April 2024.
SUBMISSION DETAILS
Submit a single zip file containing the report and all software written to the Turnitin page on Blackboard.
HELP AND SUPPORT
• For support with using library resources, please contact Mr. Neil Marshal or . You will find links to lots
of useful resources in the My Library tab on Blackboard.
• If you have not yet made the university aware of any disability, specific learning difficulty, long-term health
or mental health condition, please complete a Disclosure Form. The Inclusive Support team will then
contact to discuss reasonable adjustments and support relating to any disability. For more information,
visit the Inclusive Support site.
• To access mental health and wellbeing support, please complete our online referral form. Alternatively,
you can email wellbeing@uclan.ac.uk, call 01772 893020 or visit our UCLan Wellbeing Service pages for
more information.
• If you have any other query or require further support you can contact The , The Student Information
and Support Centre. Speak with us for advice on accessing all the University services as well as the Library
services. Whatever your query, our expert staff will be able to help and support you. For more information,
how to contact us and our opening hours visit Student Information and Support Centre.
If you have any valid mitigating circumstances that mean you cannot meet an assessment submission
deadline and you wish to request an extension, you will need to apply online prior to the deadline.
Disclaimer: The information provided in this assessment brief is correct at time of publication. In the unlikely
event that any changes are deemed necessary, they will be communicated clearly via e-mail and a new
version of this assessment brief will be circulated.
Version:
1.0
Marking Criteria
Grade Mark Descriptor – Data Storage and Retrieval.
100 Flawless work.
Exceptional
1
st 94 Impressive treatment of all requirements as outlined.
High 1st 87 Excellent treatment of all requirements as outlined.
Mid 1st 80 Very good treatment of all requirements as outlined.
Low 1st 74
Consistently good or better treatment of all requirements as outlined, good quality
working code using OOP techniques throughout.
High 2.1 68
Good treatment of all requirements, good review of challenges with solutions as
outlined, good quality working code using OOP techniques throughout, includes extra
analytical functions that can determine under what exact conditions the UAAV tests
fail.
Mid 2.1 65
Good treatment of most requirements as outlined, good quality working code using
OOP techniques throughout, includes extra analytical functions that can determine
under what exact conditions the UAAV tests fail..
Low 2.1 62
Generally a good treatment of requirements as outlined, good quality working code
using OOP techniques throughout, includes extra analytical functions that can
determine under what exact conditions the UAAV tests fail.
High 2.2 58
Generally a good treatment of requirements as outlined, straight forward working
code using some OOP techniques.
Mid 2.2 55
Generally a good treatment of most requirements as outlined, straight forward
working code using some OOP techniques.
Low 2.2 52
Adequate treatment of most requirements as outlined, straight forward working
code using some OOP techniques.
High 3rd 48
Adequate treatment of some requirements as outlined, simple working code using a
poor design.(EG. Non use of classes etc.)
Mid 3rd 45
Patchy treatment of requirements as outlined, simple working code using a poor
design.(EG. Non use of classes etc.)
Low 3rd 42
Limited treatment of requirements as outlined, working simple code using a poor
design (EG. Non use of classes etc.).
Marginal
Fail 35 Superficial treatment of requirements as outlined, non-working code.
Mid Fail 30 Inadequate treatment of requirements, little if any evidence of understanding.
Low Fail 25 Largely incomplete or very poor treatment of requirements.
Fail 10 Very limited treatment of topic.
Non
submission 0 No work submitted by deadline or work plagiarised.