B215 Practical exercises – Week 7
ICT283 (not assessed but should be attempted)
Objectives:
· Continue work on assignment 1.
· Preparation for data structures that will be used in assignment 2.
· To learn and practice OO Design.
· To do refactoring and code maintenance.
· To do testing.
It is very important not to fall behind with these exercises.
You should note that even though an exercise is not assessed, not attempting the exercise would make it very difficult for you to understand subsequent material.
If you want to work on your own computer, install graphviz first, then install doxygen.
Exercise
1. (Internal students)
Demonstrate assignment 1 to your tutor at the next class. You do *not* need to have fully completed the assignment if the assignment is not due yet. You may want to explain your design and code when asked.
Please read the QandA file for assignment 1 and the earlier labs if you hadn’t done so. In the past, the QandA file for assignment 1 usually gets a lot of updates nearer the due date, so you need to keep an eye on that. It just depends on when students ask questions.
2. (everyone)
You may want to complete the assignment first before starting on this 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. Make sure you document all code (in header files) using doxygen style comments.
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. The template Vector class from Topic 5 is still being used.
1. Modify your new “future-proofed” design of Lab (Topic) 5, question 2, so that for each student, the student id and associated student name is stored as a map. Student id is the key value in the map.
2. Record (write down) what changes did you have to make to the design.
3. Implement your new design.
4. List (write down) the changes you made to the code? In particular what changes were needed to the main program (client code)? The amount of changes you had to make to the client code indicates how bad your future-proof design was. There should be no changes to the client code of Lab 5, question 2 as the inclusion of the map data structure is not meant to be visible to the client. It is about encapsulation. If you are still struggling
with this concept, please see Chapter 1 “The Object Oriented Paradigm” of the ebook “Design Patterns Explained” (in our library). Link is:
http://prospero.murdoch.edu.au/search~S10?/aShalloway%2C+Alan/ashalloway+alan/-3%2C-1%2C0%2CB/frameset&FF=ashalloway+alan&2%2C%2C2
5. Run doxygen and examine the output to see that your initial design matches the design as shown in doxygen.
From this exercise onwards you should to keep a log of changes in requirements, consequent design change, consequent changes in code and the impact on the client code. This will serve as a record of lessons learnt in design.
NOTE:
It is not about C++, or Java or any other programming language.
The design is independent of programming languages.
The programming languages are only used to implement your design choices. Mess up the design and you create more work for yourself or someone else later.
� Even if you are not struggling, you can consolidate your understanding. You will see why we have changing exercise requirements and aiming for “future-proofing” in our designs.
PAGE
1
LabExcWk07.doc