The coursework for this module comprises two assignments related to one central exercise.
This is the specification for the second assignment.
This assignment constitutes 50% of your overall assessment for this module. It is marked in three parts, weighted as follows. See Sec. 2.3 for the detailed breakdown.
- Programming and design: debugging, refactoring and extension of the application.
- Software engineering practices: application of principles, techniques and tools towards
delivering high quality, professional software.
Report: a guided precis of your work on the above.
Each part is informed by this exercise as a whole (including CW1). For example, the required structured of your report (Sec. 2.3) indicates the key items of work you must carry out in the first and second parts. Read all of this document (and CW1) carefully to understand all of the requirements and deliverables before diving in – as for any software project!
Reminder: This is an individual assessment.
3Deliverables – Your Submission
Coursework #1 is the precursor to this assignment. You are expected to have completed CW1, and therefore be familiar with both the given code and the description of the prototype Client application, particularly the Specification.
Your tasks are divided into three parts, weighted as stated at the top of this document.
2.1 Programming and Design (40%)
a) Refactoring and redesign.
Debug, refactor and redesign the Client to address the issues raised in your code review (CW1). Focus on the key design issues that will hinder your subsequent work on the features required by the Specification, namely the Todo list and Roadmap. To do so, rework your client as follows:
Refactor the Client to use the Command Pattern. This pattern uses objects to represent instances of a command, e.g., by encapsulating a method call and its specific argument values. This allows the execution of such commands to be deferred and passed between classes without tightly coupling them. It also facilitates recording a history of executed
Restructure your Client to further decouple its core components: the fundamental data structures, the
user interface, and the application logic that binds everything together. To this end, you are strongly
recommended to consider the basic Model-View-Controller (MVC) framework included in the
provided code (the sep.mvc package). See the accompanying Javadoc and the Appendix for further
General reminder: Any disciplined approach to debugging and refactoring requires a solid level of test
support to prevent regressions (i.e., breaking existing functionality) – you are advised to pay up-front
attention to the Testing item in Sec. 2.3.
Exercise and refine your Client design by implementing all the extensions described in the Todo list and Roadmap of the Specification. As mentioned in the fourth Specification item, you do not need to implement a graphical UI, but your design is expected to offer appropriate support for adding alternative UIs as future work. Hint: For Undo, first consider which data structure may be best suited to the task before implementing the overall behaviour. Hints on i18n: As a CLI application, you do not need to consider issues such as culturally sensitive images or colours. However, the Client is littered with hardcoded strings written in English. In addition to the lecture and tutorial, the Java i18n Trail is recommended: https://docs.oracle.com/javase/tutorial/i18n/index.html. Another Hint: Your design in part a) can be judged on how well it supports your work in this part and the potential for further extensions (e.g., additional states and commands, and the alternative UIs).
Again, be sure to add appropriate tests throughout the development of these new features to verify their functionality, especially when you encounter bugs. When your tests are green, continue the cycle of refactoring and re-testing to maintain a good level of code quality. Regarding i18n, you may find it helpful to create another ResourceBundle with a specific Locale resource (e.g., fr-FR) just to test you have implemented your solution correctly.
Note on assessment: This assignment examines your ability to develop software towards a professional level of quality (i.e., beyond just “coding” or “hacking”). The assessment criteria thus include:
functional correctness w.r.t. the specification, and internal consistency. Appropriate use of language features and style (e.g., indentation and whitespace, comments, etc.) Design – in terms of the requirements specified above, and software engineering principles in general.
Bonus extensions. The following are an optional source of bonus marks. It is possible to attain maximum marks for the assessment without undertaking them.
Note: The server already supports messages for the above command.
- Client-side caching of previously fetched seets during the current client instance (not across client instances). The drafting mode UI should display any cached seets (for the “primary” topic), in addition to the seets in the current draft. The user should also be able to display the list of currently cached topics.
You will be assessed for good software engineering practices. We visit these topics over the course of this module!
You are required to maintain your project as a private GitHub repository. Be sure to continuously commit your changes, and push your commits to your GitHub repository. You will additionally be required to demonstrate the use of Git branches for working on a specific tasks.
Testing is a fundamental element of the software design process, not an optional afterthought. As your review will have found, the prototype Client is buggy and incomplete – be sure to add appropriate tests to the project that clearly expose the bugs identified so far, and any further bugs you may discover, and use them to verify your fixes. You are required to provide evidence of appropriate testing using JUnit/NetBeans. This should include:
o Acceptance tests: “user-perspective” tests that feed the overall application user-level input, and verify that the outcome is acceptable to the user, for some notion of acceptable.
Hint: You will have played with the prototype client as part of CW1, essentially conducting ad hoc acceptance testing by hand. You can formally code your actions up as initial acceptance tests! You may find the following snippet helpful:
For starters, your initial tests may simply check that your program does not crash. As your work progresses, options will open up for more precise verification of outputs. Remember, code should be written to facilitate testing!
o Unit tests: for focused (sets of) operations and classes – i.e., units – you may adopt systematic approaches such as black-box testing techniques. The point is to be able to justify the design of your test cases: which inputs are you testing (or not testing) and why?
o Code coverage: white-box testing complements black-box testing by quantifying the adequacy of a test suite in terms of various code coverage metrics. The target for your Client package tests is 70% instruction coverage and 50% branch coverage, as measured using the JaCoCoverage NetBeans plugin.
Static code analysis. A variety of effective code analysis tools for many languages and platforms are available (often freely) to modern software developers. You are required to apply the static code analysis tools used in CW1 to your own Client code. As a reminder:
o FindBugs – no configuration beyond the default is needed. Check that you are running the FindBugs Source Inspector on the whole of your Client package (i.e., all your classes).
o EasyPmd – the default rulesets are basic.xml, imports.xml and unusedcode.xml. You are highly encouraged to include further rulesets – as a suggestion: empty.xml, unnecessary.xml, strings.xml, strictexception.xml and design.xml.
Documentation. Successful teamwork in any industry requires professional communication practices. You will likely have found the Javadoc in the server/message/etc. packages helpful. Now, it is your turn to document your code in a way that would be helpful to your teammates on the server side, for developers working on your client after you, or perhaps to the community if your project were to be open sourced – or simply the future you who will have forgotten most of the details in three months time. In general, your documentation should centre on the public interfaces of your code, and what outsiders should know to run, modify or extend it. (Consider which information you found most important in the provided packages.) Conversely, bad comments are a code smell – good code must be readable, and comments explaining what should be directly understandable from the code indicates both bad coding and bad documentation practices.
You are required to include:
o a user README in your GitHub repository (e.g., compilation instructions, execution parameters, etc.);
o Javadoc for your Client package to facilitate future maintenance/extensions (e.g., additional commands, alternative views);
o your report, as detailed in the next subsection.
Holding a PhD degree in Finance, Dr. John Adams is experienced in assisting students who are in dire need...
55 - Completed Orders
Canada, Toronto I have acquired my degree from Campion College at the University of Regina Occuption/Desi...
52 - Completed Orders
Even since I was a student in Italy I had a passion for languages, in fact I love teaching Italian, and I...
102 - Completed Orders
To work with an organization where I can optimally utilize my knowledge and skills for meeting challenges...
109 - Completed Orders
JOB OBJECTIVE Seeking entry level assignments in Marketing & Business Development with an organization...
202 - Completed Orders
Current work profile Project manager- The Researchers Hub (2nd Jan 2016 to presently working) Researc...
20 - Completed Orders
Sales Assistant, Mito Marina Assigned to the Stationery dept – assisted in merchandising, stock taking...
100 - Completed Orders