代写EL2311、代做SQL编程设计

日期：2024-03-29 08:33

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 <insert name and email address of your subject

Mr. Neil Marshal <NMarshall7@uclan.ac.uk> or <SubjectLibrarians@uclan.ac.uk>. 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 <i>, 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.