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 program 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

Pre-Existing Parts
This is a bit more complex, but will be very useful for the users. Rather than add the detail for each part, the program should maintain a list of all parts added. When the user wants to add a part, they can select it from a searchable list, and the details (name, price per unit, and weight) are added in. If the part has already been added, they have the option to edit the existing record rather than creating a new one. If they can't find the part in the list, adding the new part also adds it to the list for next time.
Note that even if a part is deleted, the details of the type of part should remain.
Use case: John opens up the program to add a Victor Motor Controller. First, John clicks on "find part" and a window appears listing all of the current types of parts that have been entered. He types in "Vic" into the search box, and Victor Motor Controller shows up. Selecting that, it asks if John would like to edit the existing record, or create a new one. John chooses to edit the existing record, and the existing record is displayed for editing.
Use case: Jo opens up the year's data, and goes through the same process as John to add a new 12 volt relay. She discovers that one has already been added, but it has been added as "mechanical", and she wants to add it as "pneumatics". So she says no to editing an existing record. Instead a new part record is displayed, with part name, weight per unit, and cost per unit already filled in. She then adds "1" to the number of units, and selects "pneumatics" as the category.
Use case: John decides that they don't need a Jaguar Motor Controller, so he removes the part for the list of parts in the robot. However, later one of the Victors breaks down, so he edits that entry to have one fewer part, and goes to add a new part. Following the same process as before, he finds "Jaguar Motor Controller" - even though it is not currently being used, because it was used in the past it still appears as an option. From then it takes him directly to adding new part, with the basic data already filled in.
Import and Export Parts List
Most parts used by the different teams are sourced from the same company, so there is a common list of parts that all teams are likely to use.
Create an option for the user to download all of the parts in a catalogue and import them as potential parts. Similarly, if one team builds up a collection of parts, they can export that collection and pass it on to another team.
Use case: At the beginning of the build, Paula visits the website of the main supplier and downloads their parts list in the necessary format.
She then imports that list into the program. When Sam goes to add "6 inch Mecanum Wheel" she finds that it is already there, as it was included in the list of parts Paula imported. So she selects it, the new record is created, and the basic data (name, weight and cost) has already been completed.
Use case: During the build, one of the other Australian teams offers to provide them with their parts list. They email to Paula, who selects the "import parts list" option. The program goes through and adds any new parts, ignoring parts which are already in the program with the same name and details. In cases where the part has the same name but different details (such as different price), Paula is given the option to keep the old details or replace them with the new.
Pictures and description
To make it easier to recognise parts, uses can add a user-defined picture and description to the part. These should be included in the import and export parts option.
Use case: Jo wants to add a bolt, but isn;t sure what type of bolt it is. She types in bolt" when entering the part name, and a list of bolts is returned. By selecting each one she can see the description and photo.
Use case: Paula decides to add some of the parts they are likely to use in advance, so she starts entering them as part types, including a photo and description where it is available.
Other Speci?cations
You must use C# as the programming language
Do not use a dedicated external database. Databases will be included in the third assignment.
Assignments must be developed with Visual Studio.NET 2010 (both Professional and Express editions are fine)
The completed code needs to be able to be run in a lab.
You need to specify user tests for the UI classes.
This is an Agile programming assignment. So coding in order to allow for refactoring later is essential.
Saving data can be through object serialisation or a different means, as you see fit.
Deliverables
You will need to provide:
Working code as a zipped archive containing all source files
Version of the provided code rewritten in C#
500 word reflective report on the process. There is no mark attached to this - it is just your thoughts on extreme programming as
attempted for the project.
Marking Scheme
The marking scheme is based on:
Does it work: 40%
How well does it meet the requirements: 20%
How well is it written: 40%
The marking sheet is available for download
Last modified: Monday, 24 April 2017, 9:10 AM