B215 Practical exercises – Week 7
ICT283 Assessed exercise 1
Objectives:
To learn
· Extraction of specifications from requirements
· OO Design
· To do code maintenance
· To do testing
It is very important not to fall behind with these exercises.
This is an assessed exercise. Sub-tasks 5 and 6 are the specific ones being assessed and these tasks also incorporate all prior changes needed, so do not skip anything. Attempts at these would need to be demonstrated by internal students and submitted by external students.
It is due at the next teaching week (session).
Internal students need to demonstrate it to their tutor during class. Trimester mode students are also internal students.
External students would submit their solution into LMS. Zip up everything and submit the zip file. Submission area will be visible later. On Windows, Right click and send to compressed folder.
If you want to work on you own computer, install graphviz first, then install doxygen.
Exercise
Do not start coding until you have worked out exactly what is required. Do this on paper. Draw a UML diagram illustrating how the classes are connected and being used. You need to read all the sub exercises (sub tasks) below first to work out what is needed and then plan the best way to tackle each of the sub tasks listed. You may need to read the specifications more than once to understand what is really needed.
Follow the sub-tasks listed below – in order. There are no shortcuts. You will waste more time fixing bugs if you try to take short cuts.
For now, follow the class relationships as specified in the exercises. Later you will have to opportunity to re-design everything.
Make sure you document all class specification code (i.e. in .h files) using doxygen style comments. Class implementation code and main program code (i.e. in .cpp files) will have normal comments. Do not put doxygen comments in implementation .cpp files.
Think about the test data you will use to demonstrate that your program works. You can assume that the input data file contains data in the correct format. This means that you must create the data file correctly using a text editor.
1. Modify the previous topic’s practical exercise (topic 3) so that every class has the full complement of set and get methods. Unit test each class
to ensure that the set, get and other methods work. You will need to follow this approach for all classes that you create/modify from now onwards – all classes must have a full complement of set and get methods; are fully unit tested before being used in an application.
2. Move the body of methods into the corresponding implementation files (.cpp). Only class declarations and method declarations are in .h files. This is the approach that you will use for all future work except when you are working with template classes (template classes will be covered later). Run the unit tests to make sure all changes are working.
3. Modify exercise 2 (above) so that instead of using C style strings, the string class from #include
In the previous lab exercise, the unit name had “_” between words to simplify the reading of the unit name from the data file. Normally, names like “Data Structures And Abstractions” have spaces between the words. You may want to restructure the data file to reflect this but this might create a problem if you try to read in a std::string using the “>>” operator as only one word is read in each time.
One way around this is to have the unit name on a line by itself in the data file and use the getline(…)to read the entire line, composed of a number of words into one std::string object. Alternatively, you may want to read the unit name in with the “_” between words and replace the “_” with a space character when storing the values in your data structure. A better way is to have the data related to one record on one line separated by a delimiter (usually a comma) and use the getline(…) with the delimiter parameter to read the data in (see lecture notes for topic 3, Lec-09.ppt, first and then more details if necessary at http://en.cppreference.com/w/cpp/string/basic_string/getline). For now, use any approach that you like, but you will have to eventually (very soon) use the comma delimiter in CSV files as CSV files are needed for the assignment. Web search “csv format”.
4. You need to draw a UML diagram to see the relationships between the classes before attempting any code change.
Create a new class call Date. Date will contain the date stored as day of the month, month and the year. Provide appropriate set and get methods for the class.
Think about how the class will be used. Modify the input data file to cater for dates. The date in the data file refers to when the mark for the unit was obtained. Unit test the date class.
The output
operator for Result should output the unit information, the marks and the date these marks were obtained. The output for registration in the output data file will contain the Student ID, Semester, unit information, date and marks for each unit. The output should be in a similar format as the output in the previous exercise except it will have the date information as well and there will be no “_” in the unit name. A sample run is shown at the end.
5. *Once the above exercises are completed (includes testing everything), convert all I/O operators (operator<< and operator>>) so that they are no longer friends (see Lec-12.ppt for why) and they are not methods of the class. You will need to make use of the set and get methods from exercise 1 above. Run the unit tests to make sure all changes are working. This modification should not affect the main program (client program that makes use of the classes). A sample run is shown at the end.
6. *Run doxygen and examine the output to see that your initial UML design matches the design as shown in doxygen.
Sample Run:
Student ID: 12345678
Semester: 1
Unit ID: ICT283
Unit Name: Data Structures and Abstractions
Credits: 3
Marks: 90
Date: 30 June 2016
Unit ID: ICT289
Unit Name: Computer Graphics
Credits: 3
Marks: 97
Date: 30 December 2016
Number of Units = 2
Total Credits = 6
� Not doing the unit test for each class is not going to save time. You will end up wasting a lot of time when you try to incorporate into your application classes that have been tested. Trying to debug in a much larger application is going to be particularly frustrating.
� A better way to do output is to provide access (get) methods which return strings and the client program processes these strings, including output. For the purposes of this particular exercise, use the output operator as specified, then modify as required by the next question.
PAGE
2