tP:
Admin Appendix E(extract): Workflow (after v1.2)
After following the given workflow for at least i.e., until the end of v1.2one iteration, optionally, you may adjust the process rigor to suit your team's pace. Here are some examples:
Switch to a lighter workflow:
Reduce automated tests: Automated tests have benefits, but they can be a pain to write/maintain.
It is OK to get rid of some of the troublesome tests and rely more on manual testing instead. The less automated tests you have, the higher the risk of regressions; but it may be an acceptable trade-off under the circumstances if tests are slowing you down too much.
There is no direct penalty for removing tests. Also note
Reduce automated checks: You can also reduce the rigor of checkstyle checks to expedite PR processing.
If you are unsure if a certain adjustment is allowed, you can check with the teaching team first.
🤔 How much testings is enough? We expect you to decide. You learned different types of testing and what they try to achieve. Based on that, you should decide how much of each type is required. Similarly, you can decide to what extent you want to automate tests, depending on the benefits and the effort required.
There is no requirement for a minimum coverage level. Note that in a production environment you are often required to have at least 90% of the code covered by tests. In this project, it can be less. The weaker your tests are, the higher the risk of bugs, which will cost marks if not fixed before the final submission.
This iteration is your last chance to add features. You are strongly discouraged from adding new features in the following iteration (i.e., v1.4). That iteration (which is shorter than usual) is best reserved for bug fixing and documentation work only.
The version you deliver in this iteration (i.e., v1.3) will be subjected a peer testing (aka PE Dry Run) and you will be informed of the bugs they find (no penalty for those bugs).
As you did in the previous iteration,
v1.3
and v1.3b
.In addition,
Improve upon AB3, design, code, test etc. While not very 'buggy', AB3 is not 'perfect' either (it is not meant to be a 'model solution'). Feel free to improve it in any way you see fit. In particular, find and fix any bugs it has. If you are not sure if something is a bug or an intended behavior, you can post in the forum to check.
While we are on the topic, also note that the architecture of AB3 doesn't suite every kind of application either. As you gain more experience in other application domains, you will learn different types of architectures that you can add to the collection of different architectures that you can consider for future projects. The same goes for the tool chain and the tech stack of AB3. Therefore, do not be tempted to apply AB3 as a template for every other application you come across in the future.
Why the hurry to update documents? Why not wait till the implementation is finalized?
Here are some reasons:
0..1
vs 1
, composition vs aggregation*Command
classes using a placeholder XYZCommand
).ref
frames to break sequence diagrams to multiple diagrams.These class diagrams seem to have lot of member details, which can get outdated pretty quickly:
In this negative example, the text size in the diagram is much bigger than the text size used by the document:
It will look more 'polished' if the two text sizes match.
delete
command
v1.2.1
(or v1.3.trial
). Ensure that the jar file works as expected in an empty folder and using Java 11, by doing some manual testing. Reason: You are required to do a proper product release for v1.3. Doing a trial at this point will help you iron out any problems in advance. It may take additional effort to get the jar working especially if you use third party libraries or additional assets such as images.