School of Engineering
Module
Code
Title
Module Leader
EL2311
Software development 2
Carl Berry
Assessment
Title
Weighting
Data storage and retrieval
50%
Submit to:
Deadline
Post-box
Blackboard
Other
11.59pm 29/03/20
Late submissions will incur a penalty according to University regulations
Additional submission details:
Total word count for this submission should not exceed 2000 words.
In this assessment, the student will demonstrate the ability to:
• 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.
Feedback Arrangments
Feed back will be given within the University’s 15 working day policy for feedback and will be avaiable on 21/4/19
Assessment Brief
• Overall Aim
To implement a multi-threaded software system in C#, that can read data and write in standard XML, store and retrieve data from an SQL database in a user friendly manner.
• Assignment Aims
Students will be provided with the following software (on blackboard) :
A SQLite 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 (writing threaded code, reading standard data format (XML), database access and storage, user interface design).
• The Problem
A company makes and sells robots of varying types, they need to keep track of what they make and who they sell them two. The company has a database (cwkdb2020.db – on blackboard) that consists of two tables :
robots
model : text (primary key)
price : real
type : text
current : integer
stock : integer
customers
orderNo: integer (primary key)
name : text
postcode : text
model : text (foreign key)
quantity : integer
orderDate : date
In the robots table :
• model – This is the model name of a robot, it’s stored as a text string and is used as the primary key as each model is a unique value.
• price – This is the retail price of the robot and is a floating point value.
• type – This is the type of robot that the model is and refers to the type of activity the robot does, this is stored as text and is left to the student to come up with suitable examples (two are included in the database already, see later)
• current – This is an integer acting as a Boolean that states whether the company is currently producing this type of robot. 0 means the robot is not currently made, 1 means it is.
• stock – An integer value that states how many robots of a type the company has in stock. Note even if a robot is not currently being made there may still be stock left of it.
In the customers table :
• orderNo – A unique integer value that identifies the order made by a customer. Each order refers to a single model of robot. If a company were to order two different models of robot at the same time two orders would be created. Used as the primary key for the table.
• name – A text field that identifies the company name that bought the robot.
• postcode – A text field that contains the postcode address of the buyer.
• model – The model name of the robot bought (text field). This attribute references the model attribute of the robot table as a foreign key (refer to lecture notes if you don’t remember what this means).
• quantity – Integer value that states how many robots the customers bought in this order.
• orderDate – Date field that specifies when the order was fulfilled.
Each table currently has three example entries in them
robots:
driveRob01
3999.95
autonomousMobile
0
15
driveRob02
4999.95
autonomousMobile
1
25
noseDive
350.99
manualDrone
0
6
Here we can see the driveRob01 cost 3999.95 pounds was of type autonomousMobile and is no longer in production, the company still has 15 left in stock. driveRob02 cost 4999.95 pounds is of type autonomousMobile is currently in production and that the company have 25 in stock. Finally noseDive cost 350.99 pound, was a manualDrone and is no longer in production, the company have 6 left in stock.
customers:
1
Bob Smith & Sons
BB1 1QT
driveRob01
15
2014-05-16
2
CompuDrive
BB10 7ZY
driveRob02
35
2017-07-01
3
Robo Fly Ltd
BB5 1AB
Nosedive
7
2020-01-16
Here we see that order 1 was for Bob Smith & Sons, their postcode was BB1 1QT they bought 15 driveRob01 robots and this was completed on the 16th May 2014. Etc.
• The Task.
Part 1 : Software Development (70%).
The student is required to write a C# program that performs the following actions :
• Creates new XML files that allow the company to plan new robots and create new orders. The program should store and save these files.
• Loads and Parses the XML files for robots and orders (created in point 1). The program should be able to handle badly formed files or errors in the data in a suitable manner without crashing the program. Students should create their own mis-formed files for testing purposes.
• 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)
• Allow the GUI to remain responsive whilst loading and storing the XML files by implementing threaded code.
• All code should be fully documented and should use appropriate Object Oriented Programming techniques covered in the course.
There are two types of user that you need to account for when writing this program.
• 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 :
• Bring back a list of all robots currently being produced.
• Bring back a list of all robots over a user defined stock value. E.G. bring back all robots that we have more than 5 of in stock.
• Bring back the name of all companies that have bought a robot that is currently in production.
• Bring back the total worth of all the robots that we have in stock.
• Bring back the order numbers of all orders between two user defined dates. E.G. All orders fulfilled between 2001-01-01 and 2013-01-01.
• 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 without supplying an admin password.
Students are heavily advised to get the program to work using single threaded methods first and to attempt multithreaded solutions once a working single threaded version is produced.
Part Two : Documentation (30%).
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, explanation of algorithms used etc.
• Testing plans. How the student tested the program including creating XML files for testing program input.
• 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.
• Word Count
The word count for this report (Part Two) should not exceed 2,000 words.
• Submission of assignment work
Students should post the completed work by the deadline to the TurnItIn page on the EL2311 section on Blackboard.
• Late work
Work submitted electronically may be submitted after the deadline to the same Turnitin assignment slot and will be automatically flagged as late.
Penalties for late submission
Except where an extension of the hand-in deadline date has been approved lateness penalties will be applied in accordance with University policy as follows:
(Working) Days Late Penalty
1 – 5 maximum mark that can be achieved: 40%
more than 5 0% given
• Plagiarism
During the induction and via your student handbook, you were informed of the serious consequences of using or attempting to use unfair means to enhance performance. This includes plagiarism. The work submitted must be your own and any information and material used properly identified and acknowledged.
The University operates an electronic plagiarism detection service where your work may be uploaded, stored and cross-referenced against other material. The software searches the World Wide Web and extensive databases of reference material to identify duplication
For detailed information on the procedures relating to plagiarism, please see the current version of the University Academic Regulations.
Marking Criteria
Grade
Mark
Descriptor – Data Storage and Retrieval.
100
Flawless work.
Exceptional 1st
94
Impressive treatment of all requirements as outlined in section 4, multi-threaded code.
High 1st
87
Excellent treatment of all requirements as outlined in section 4, multi-threaded code.
Mid 1st
80
Very good treatment of all requirements as outlined in section 4, multithreaded code.
Low 1st
74
Consistently good or better treatment of all requirements as outlined in section 4, good quality working code using OOP techniques throughout, single threaded code.
High 2.1
68
Good treatment of all requirements, good review of challenges with solutions as outlined in section 4, , good quality working code using OOP techniques throughout, single threaded code.
Mid 2.1
65
Good treatment of most requirements as outlined in section 4, good quality working code using OOP techniques throughout, single threaded code.
Low 2.1
62
Generally a good treatment of requirements as outlined in section 4, good quality working code using OOP techniques throughout.
High 2.2
58
Generally a good treatment of requirements as outlined in section 4, straight forward working code using some OOP techniques.
Mid 2.2
55
Generally a good treatment of most requirements as outlined in section 4, straight forward working code using some OOP techniques.
Low 2.2
52
Adequate treatment of most requirements as outlined in section 4, straight forward working code using some OOP techniques.
High 3rd
48
Adequate treatment of some requirements as outlined in section 4, simple working code using a poor design.(EG. Non use of classes etc.)
Mid 3rd
45
Patchy treatment of requirements as outlined in section 4, simple working code using a poor design.(EG. Non use of classes etc.)
Low 3rd
42
Limited treatment of requirements as outlined in section 4, working simple code using a poor design (EG. Non use of classes etc.).
Marginal Fail
35
Superficial treatment of requirements as outlined in section 4, 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.