The University of Melbourne Department of Computing and Information Systems SWEN90007 Software Design and Architecture
Project Specification, Semester 2, 2015 Project Requirements
Congratulations! Your enterprise system is a commercial success. You now have several clients and they are using your system with great success.
Even better, one client is already contracting you to add more features. In Part 3 of the project, you will design and build this new feature for your client. On the downside, it may require you to re-think parts of your architecture.
A New Feature
A text file containing instructions for your new feature, which we will call Feature B, has been pushed to the root directory of the master branch of your BitBucket repository. The file is named Feature-B.txt, and describes a high-level description of the client’s request. This feature extends the previous feature designed and implemented in Parts 1 and 2 of the project, which we will now call Feature A.
Note that your new feature will require authentication and authorisation. That is, some operations are restricted to users playing certain roles.
As part of the project, you are free to make some choices about the exact functionality that fulfils the requirements outlined in the new feature, however, it must be a faithful implementation of what is requested. You may request clarification of the feature from your client (Eman), but the client will not give a detailed specification.
Project Milestones and Deliverables
Following are the project deliverables (submissions) throughout the semester, and the marks asso- ciated with the different submissions (adding up to a total of 30 marks).
1. Submission 3 [8 marks]: Software Architecture Document (SAD) and implementation for Feature B.
Due date: Week 10 — 11:59pm, Sunday, 11 October 2015. Demonstration of feature in labs in week 11.
2. Submission 4 [4 marks]: Performance evaluation.
Due date: Week 12 — 11:59pm, Sunday, 25 October 2015.
Project requirements: Parts 3 and 4
1. Part 3 [8 marks]: This submission must include the following:
- (a) Your group ID, team members and their University of Melbourne usernames
- (b) A detailed use case for Features A and B of your system.
- (c) A domain class diagram for Features A & B, specified in UML.
- (d) The high level architecture for Features A & B – static view only – that presents all relevant architectural design patterns used.
- (e) The new and updated parts of the architecture for Feature B: structural, interaction, and behavioural views of the architectural-level components.
- (f) A description of all architectural design patterns used for Feature B and justification for each of these.
- (g) A system prototype that demonstrates Features A & B.
NOTE: For item 1e, only include the new and updated parts of the architecture for Feature B.
2. Part 4 [4 marks]:
- (a) A performance report that shows the impact of load on the important performance
metric.
- (b) A description of what principles you used for performance in your prototype and justi- fication for each of these.
Criteria
Submissions will be marked on the quality of the system and related artefacts, with a focus on the architectural design. Part of the marks will go towards the detailed design, the code, etc.
Part 3
Criterion
Use case
Domain diagram
High-level model
Structure, interac- tion, and behaviour Design patterns Rationale
Prototype Total
Part 4
Criterion
Report Principles
Total
Submission
Description
Clear, correct, complete, and consistent use cases describing Fea- tures A and B
A clear, correct, complete, and consistent domain diagram for the Features A & B
A clear diagram outlining the architectural patterns and compo- nents for your Features A & B
Correct, complete, and consistent structural, interaction, and behavioural views of the architecture for Feature B
Sound choice of design patterns for Feature B
A clear and convincing rationale for the choice of the architec- tural design patterns used for Feature B
A correct, complete, and demo-able implementation of the ar- chitectural design for your chosen feature
Description
A report demonstrating the correct and complete application of a tool, such as JMeter, to measure the performance of the system Correct choice of principles, including sound justification, for performance used for both features
Marks
1 mark
1 mark
1 mark
1 mark
1 marks 1 marks
2 marks 8 marks
Marks
2 marks 2 marks
4 marks
will be via the LMS, under the Assessment menu. All reports must be NOTE: Include your group ID on the submissions for Parts 3 and 4, as well as details for individual
team members.
For the source code, repositories on BitBucket must be shared with the subject staff, as outlined in the previous submission.
Submission of reports
submitted as a PDF file. Only one member of your pair should submit reports via the LMS.