Details (Internal students)
Assignment 2
The aim of the second assignment is to refactor the first, in order to take it from a product that is mildly useful but not ideal, to one that is of far more value to the end users. While the third assignment will be on a different topic, one additional major iteration should be enough to make something that is potentially viable.
The assignment is to be done in pairs for internal students, but individually for those studying externally. Accordingly there is an alternative version of the assignment for external students. In working in pairs you are expected to try the paired programming approach from Extreme Programming, and in both cases to work to the principles of XP. That means:
Clear and concise code, removing the need for documentation
Code designed to be easy to refactor
User tests should be designed prior to starting (Unit testing won’t be required until the third assignment)
No planning for future iterations – focus on meeting these requirements, rather than pushing further
Code using the principles of SOLID, as covered in the lectures
If you have contacted me previously about who you want to work with, you will have been paired with that person. Otherwise pairs have been assigned based on a combination of factors that should match practical groups, and emails will be sent out informing everyone as to who they are working with.
Requirements
The first task is to convert the attached code from VB.NET to C#. This code is a rough version of what was expected from the first assignment.
It has been lightly commented, but the code should be clear overall.
Although you will be expected to refactor, initially it would be worth just handling the conversion as is, rather than recoding from scratch or trying to modify the code while you convert it. You will need to submit the C# version of the provided code as part of your assignment.
Refactoring
The code will need to be extensively refactored. Not all of these features are required to pass, but all of these will be required to get maximum marks.
Persistence
A few people did this in the first assignment, but it is certainly necessary in the second. You’ll need to save the data. When a user enters or edits parts, the data should be saved so that it is there next time.
Note this should not be automatic – it should be possible for the user to maintain multiple sets of parts. Thus they should be allowed to save to more than one file.
Use case: Sam opens the prog
ram and adds three parts to get things started. She then selects save, and saves her data as “FRC2014”. The next
time she opens the program, she selects load, chooses “FRC2014”, and her data is loaded into the program for additional editing.
Categories and Suppliers
Each new part should be able to be added to a user-defined category, such as “electronics” or”pneumatics”. There is no need to provide multiple categories per part, but the user-defined aspect is important. The user should also be able to add a supplier (eg Bunnings) in the same way that he or she would add a category.
Use case: John is part of the electronics team. When John opens the program, he loads the team’s data for this year (FRC2014), and starts adding some new parts. He want’s to tag them as belonging to his team, so he adds a new category of “Electronics”, and selects that category for each new part he adds.
Deleting
This wasn’t included in the last assignment, but again some people added it because it makes a lot of sense. Allow the user to delete a part from the list.
Use case: Jo realised that they won’t be able to get the fifth motor installed in time, so she opens up the data for this year, and goes to the “Jaguar motor controller”, which is no longer needed, and deletes it.
Sorting
The list is going to get very long, so a few sorting functions would help. Specifically: sort by category, sort by weight, sort by cost, sort by name.
Use case: Sam loads the data to edit the entry for M5 50mm bolts. Finding it hard to spot, she selects “sort by mechanical” (a user-defined category) to find the item on the list.
Use case: John notes that the robot is now overweight. By selecting “sort by weight” he quickly identifies that the heaviest part is one of the motors, and that by replacing it with a different motor the robot would meet the target.
Reporting
The users will need to export all of the parts into a CSV file. The CSV file should be a list of records, with each row specifying item name, number of items, unit weight, unit cost, category, total weight, and total cost.
Use case: Paula, the team treasurer, needs to generate a report for FIRST listing all of the parts on the robot, and providing total cost and total weight. She opens the file, and selects “File -> Export as CSV”. She saves the file as “FRC2013.csv” and opens it in Excel, where she tidies it up before printing it out to include in the robot’s documentation.
BACK TO TOP