Please keep in mind the Collaboration Policy. If you have any questions regarding the assignment, do ask the course staff. For this milestone, we will select 5 teams with which we will discuss the design in more detail. Both team members should both know the design, the reasons behind the design decisions and the high-level details about every class.
The total number of points for this milestone is 100.
The points are awarded as follows:
- 5 points - functional ant build file. If the build fails, the functionality will not be tested further.
- 50 points - implementation completeness
- 10 points - pass test cases for replaying a game
- 10 points - program does not fail on bad-input testing.
- 5 points - pass the regression test suite. The improved program has to successfully run the test cases you provided together with the TA-developed test cases for the FriendFinder milestone.
- 10 points - finding a bug and fixing it, in a colleague's FriendFinder application.
- 8 points - design documentation
- 2 points - filling in an online form that provides us information on how much time is required for this BuddySuite milestone
- 20 points - optional extra functionality
For this milestone, you will implement the Chess Game UI. The UI functionality that is required contains the following:
Remember, we are aiming for a realistic software development process. The requirements are not final, and whenever you are in doubt of what is actually required, do ask on the discussion list.
In the coming weeks you will have to implement the entire Chess Game. Think now about how you will implement the logic, i.e. validating chess moves, and how you will communicate with the server.
The following requirements refer to both the FriendFinder and Chess Game UI, unless otherwise specified. Each team will develop a JavaDoc-produced design document, i.e., there must be an "ant doc" target in the build.xml that produces the documentation on demand, containing the following:
- For each class in program, provide:
- If the class extends another class explain the reason. Explain why containment is not a better solution. This requirement does not apply if your classes only implement interfaces.
- For each public method, explain:
- If the method overrides an inherited method argue how Liskov's Substitution Principle is preserved. This requirement does not apply for classes that implement an interface method. The requirement does apply if you override a method that implements an interface method.
- What is the method supposed to do
- Checks for input validity and input sanitization, in case of improper inputs
- Why is the method not private
- For each switch statement in the code of the method explain why polymorphism is not a better alternative, and when using polymorphism explain why switch statements are not a better alternative
- A program statement that has not been run during testing, does not work in production. Describe how you designed your classes to be easily tested. Furthermore, describe what measures you took to minimize the amount of time needed to debug an error in your program. Do you check that the assumptions you made about the environment hold?
- Class diagram. The diagram should be a PDF file. You can find a tutorial about class diagrams here.
Note: The current design document should extend the previous design document. You do not have to write a new one for FriendFinder. You have to extend the previous one to incorporate the new requirements: inheritance, assert statements, method overriding and switch statements. If you rewrote FriendFinder, then your previous design document is not valid anymore, and a new one conforming to the new requirements has to be produced.
The design of your Chess Game UI will be assessed against the following properties:
- Minimal complexity - 1 point
- Ease of maintenance. The UI is the first contact of a user with your program, so be prepared to change it fast, and frequently- 2 points
- Loose coupling - Every class should communicate with as few other classes as possible - 1 point
- Extensibility - 1 point
- Reusability - 1 point
- High fan-in/Low fan-out - 1 point
- Leanness - 1 point
The maximum number of points a team can receive is 8.
Classes and interfaces design
Your code will be checked against the principles presented in Lecture 3. For each violation of the guideline, you will lose 0.5 points:
- God classes
- More than seven data members in a class
- Inconsistent level of abstraction
- Non-private data member
- Incorrectly paired methods names. For example, if you have a method called beginCommunication, then its paired method must be called endCommunication
- Inheritance level higher than three
You will have to hand in:
- The code for Chess Game UI + Friend Finder
- ant build file that
- compiles the code
- creates the apk file
- installs Chess Game UI on a running emulator
- runs the two test cases from the previous milestone, FriendFinder
- generates the design documentation by running javadoc
- A functionally complete build file will be rewarded with 10 points. If your build file does not do all of the required actions, you will get 0 points. Furthermore, your project will not be evaluated.
- Note: The code you deliver must run on the client's machine. A client is not going to be happy if the developers tell him/her that the program worked on the developers' machines. The computers in the BC07-08 laboratory are the client's machines. Your code must run on the BC machines.
- You should use the script check_structure.bat on the BC machines to check that your build system complies with the requirements. Download the attached check_structure.ba_ and rename it to check_structure.bat. Open the script to see how to run it.
Finding a bug and debugging the program
Debugging is the process of identifying the root cause of an error and correcting it.
As presented in Lecture 4, debugging is a systematic process. The steps that you have to take are:
- provide a consistent way of reproducing the bug. It can be a test, or it can be a description of the steps needed to reproduce the bug.
- locate the bug and explain it
- fix the bug
- prove that the bug was fixed by rerunning exactly the same test or following exactly the same steps
- look for similar bugs in the same program
To exercise your debugging skills, you have to find one bug in a colleague's FriendFinder code. Your colleague cannot be your teammate.
To get the points for this requirement, you have to prove you took all the steps. You have to provide a document that details the actions you took at each step. Additionally, you have to provide the project of your colleague and the fixed version of your colleague's project.
- How to replay PGN games knowing that this requires some logic to disambiguate moves?
We don't expect you to replay the game correctly for this milestone, just that your pieces moves according to some input from the PGN file. Whenever you run into a situation where the PGN notation is ambiguous, you are *not* required to follow the rules of chess.
A couple examples:
1) Assume your board is in the start position. If you parse '1. e4' from the PGN file, we don't require you to do e2-e4 (i.e. the valid move according to chess rules). You could do a2-e4, b2-e4, etc. Any pawn movement is fine.
2) Assume you have your bishop in position f1 and you parse '10. Bg3' from the PGN file. Clearly, this move would be invalid. However, it doesn't matter: moving your bishop to g3 is fine.
Alternatively, you could move your other bishop there (assuming it's still in the game of course).
Again, we don't expect anything from this game replay other than seeing the pieces move (the correct piece that is - please don't move the Queen on '5. Ng3'! - and the correct color).
In addition, if your replay strategy results in an impossible move (for instance, having to move the Queen, but it was captured by a previous invalid move), you may end the replay, skip the move or even move randomly another piece.
The idea really is for you to implement a replay framework that will be extended to provide valid game replays during the Chess Logic milestone.
Your replay strategy will not be graded. Only the fact that pieces move on your board following *more or less* a PGN game.
This is also the occasion for you to anticipate future improvement of your application and to "prepare the terrain" for this as well as you can.
- Will you use bad input or invalid moves on our PGN replay engine?
Most definitely: invalid moves, invalid PGN format, non-existing file, etc. You name them. We will however use complete games (i.e. games that start from the start position).
- What can we assume about PGN file format and what should we parse (e.g. player names, etc.)?
You should at least parse and display the names of the players. The rest is optional, however you parser shouldn't
crash if we add comments (i.e. lines between [ ])
You may assume line breaks between each comment and between each game.
You may assume there is at least one space (space here is to be taken in a broad meaning - whitespaces,
tabulations, end-of-lines, etc.) between each move (though there could be more than one), i.e. "1.e4 e5 2.f4 d6".
This will simplify parsing.
Don't assume anything about line breaks, i.e.
"1.e4 e5\n2.f4 d6"
"1.e4\ne5 2.f4 d6"
are both valid. It could also be that there is no EOL for a specific game sequence
(i.e., "1 ... 2 ... 3 ... ... 43. Qg7#" could be all in one single line). Note however that the following is considered invalid:
"1.e\n4 e5 2.f4 d6"