FIT3077-S1-2022- Assignment 3 Marking Guide Task1: Design, architectural patterns, and principles. ● Design patterns have been applied appropriately. At least one design pattern should be applied. If there is a strong reason why no new design pattern can be introduced in Assignment 3, discuss it in the design rationale document (5 Marks). ● Design principles have been applied appropriately. At least two design principles should be applied. You may use notes in your UML diagram to show where the design principles have been applied. If you change the way you apply the design principle in Assignment 3 as a result of new requirements, please discuss it in the design rationale document. If there is a strong reason why no new design or package-level principles can be introduced in Assignment 3, discuss it in the design rationale document (2 marks) ● Package level design principles have been applied appropriately. At least 2 package level design principles should be applied. You can use notes in the UML diagram to show where the principles have been applied. If you change the way you apply package-level principles in Assignment 3 as a result of new requirements, please discuss it in the design rationale document. (2 marks) ● The syntax is correct. (1 mark) ● Appropriate architectural patterns are applied. The architectural pattern is correctly refactored (if needed) Architectural pattern is correctly justified. Do the proposed architectural patterns support extensibility (5 marks) ● Appropriate refactoring at code, design and architectural levels are applied where needed and discussed in the design rationale. (5 Marks) Task 2: Design Rationale ( 10 Marks) ● Students must explain WHY their design is as it is, not simply WHAT the design is (the UML documents do that). This explanation must be in terms of the principles and patterns described in lectures, or in other design texts. Patterns and principles must be referred to by name. All sources must be properly cited. ● The advantages and/or disadvantages of the patterns and principles applied must be described explicitly. It is not enough to say something like “we designed it like this because it is good”,
or even “we used the Observer pattern because it is well-known and good”. There should be focus on extensibility. ● Students should discuss how their initial design (developed in Assignment 2) supported the new extensions. If you decided to start from scratch, you should discuss the reason for this, e.g.: “In our initial design we had implemented the Observer design pattern. The new requirements made it clear that we needed a design pattern that can support multiple views, hence we decided to completely change our design and implement MVC.” ● Refactoring techniques applied during the extension of the system must be discussed. ● Refactoring techniques discussed must match with the implementation. Task 3: Implementation (15 Marks) Consistency between design and implementation so the Source code fully matches the design of the system. No disparities between design and implementation. (5 marks) Design patterns are correctly and completely implemented (5 marks) All requirements are implemented, and the code is functionally correct that is no exceptions, errors etc. (5 Marks) System Demonstration (10 marks) ● Start the video by discussing the contribution of each team member (i.e., which team member was responsible for which component in the system). Students should demonstrate a working system covering all requirements of Assignment 3. Teams of 3 should demonstrate the extra requirement. (5 marks) ● Students demonstrate understanding of the system, the relationship between the code and the design documents, and the design principles and patterns applied. Students should point out where in their code the design patterns shown in their design documents are implemented. Students should explain the design principles, patterns, refactoring and architectural changes in code and the UML diagram. (5 marks) Git Usage (5 Marks) ● The log shows a fair allocation of work between partners. There are enough check-ins to evaluate the work allocation. Messages are meaningful and accurately describe the work committed. ● If Git usage is not able to clearly show the real amount of work done by the team members, you can submit a work breakdown structure in your submission.