| Assessment Details and Submission Guidelines |
| Unit Code | MN611 – T1 2018 |
| Unit Title | System Architecture |
| Assessment Type | Individual Assignment |
| Assessment Title | Assignment1: UML diagrams to illustrate the system architecture |
| Purpose of the assessment (with ULO Mapping) | This assignment assesses the following Unit Learning Outcomes; students should be able to demonstrate their achievements in them. c. Analyse and model system functionality and behaviour. d. Compare and contrast different approaches to system analysis and design, such as object-oriented, agile, and service oriented techniques e. Analyse and model the functional and non-functional requirements of a software system f. Design and deploy functional solutions, such as initiating, analysing and implementing system plans |
| Weight | 15% of the total assessments |
| Total Marks | |
| Word limit | Not applicable |
| Due Date | Week 7, Friday, 11.55 PM |
| Submission Guidelines | · All work must be submitted on Moodle by the due date along with a completed Assignment Cover Page. · The assignment must be in MS Word format, 1.5 spacing, 11-pt Calibri (Body) font and 2 cm margins on all four sides of your page with appropriate section headings. · Reference sources must be cited in the text of the report and listed appropriately at the end in a reference list using IEEE referencing style. |
| Extension | If an extension of time to submit work is required, a Special Consideration Application must be submitted directly through AMS. You must submit this application within three working days of the assessment due date. Further information is available at: http://www.mit.edu.au/about-mit/institute-publications/policies-procedures-and-guidelines/specialconsiderationdeferment |
| Academic Misconduct
| Academic Misconduct is a serious offence. Depending on the seriousness of the case, penalties can vary from a written warning or zero marks to exclusion from the course or rescinding the degree. Students should make themselves familiar with the full policy and procedure available at: http://www.mit.edu.au/about-mit/institute-publications/policies-procedures-and-guidelines/Plagiarism-Academic-Misconduct-Policy-Procedure. For further information, please refer to the Academic Integrity Section in your Unit Description. |
Assignment 1 Specifications
_________________________________________________________________________________
The student must design structural and behavioural UML diagrams for distributed system for an application such as multi-player game or a collaboration tool or a transaction system.
Structural UML diagram must be a class diagram while behavioural diagram can be an activity, sequence and use case diagram. The user interfaces will have to consider interactions between multiple users.
Requirements:
• The system must support multiple, autonomous agents (either human or automated) contending for shared resources and performing real-time updates to some form of shared state.
• The state of the system should be distributed across multiple client or server nodes. – The only centralized service should be one that supports users logging on, adding or removing clients or servers, and other housekeeping tasks.
• The system should be robust
– The system should be able to continue operation even if one of the participant nodes crashes.
– It should be possible to recover the state of a node following a crash, so that it can resume operation.
Since it is difficult to predict just how hard designing a new system will be, you should formulate as a set of “tiers,” where the basic tier is something you’re sure you can complete, and the additional tiers add more features, at both the application and the system level. For example, your system enhancements could include increasing the level of fault tolerance, decreasing the time to recovery, or adding features to increase scalability, security and QoS.
Important, but secondary considerations include:
• How interesting is the application: is it a fun game, a useful tool, or a solution to a real-world problem?
• How nice is the application’s appearance: does it have a nice interface or a compelling visual display?
· The architecture should be well designed, in terms of the overall architecture and the detailed realization.
Some of the application Ideas are as follows but are not limited to.
The following list of projects is intended to spark your imagination. Feel free to come up with something totally different. Contact the lecturer if you are uncertain of the suitability of your ideas.
1. Shared document editing, in the style of Google docs. The system should support real-time editing and viewing by multiple participants. Multiple replicas would be maintained for fault tolerance. Caching and/or copy migration would be useful to minimize application response time.
2. A simulated life game, in the style of The Sims or Farmville. The state of the system would be partitioned spatially, with replication for fault tolerance.
3. A multi-player real-time game, based on shooting, hunting for treasure, etc. There are many possibilities here.
4. An airline reservation system. Each airline would maintain its own collection of servers, with enough state replication to enable automatic fail-over. It would be possible to book travel that involves multiple airlines.
During the 6 th week lab, students should submit and explain the proposal.
This should include:
• A description of the application.
• The overall structure of the implementation.
• How you intend to implement your system as a series of tiers.
• A schedule for how you plan to carry your design and implementation.
Marking criteria:
For example, your system enhancements could include increasing the level of fault tolerance, decreasing the time to recovery, or adding features to increase scalability, security and QoS.
| Questions | Description | Marks
|
| Section 1 Week 6 | Description of the application. Tiers of the system Overall structure of the implementation. | 10 4 5 |
| Section 2 | Class diagram Activity diagram Sequence diagram Use-case diagram User Interfaces design | 10 10 10 10 10 |
| Section 3 | Demonstrate if the design is robust Fault tolerant Minimal recovery time Scalable Secure
| 4 4 4 4 optional |
| Reference style | Follow IEEE reference style (should have both in-text citation and reference list)
| 5 |
| | Total | 90 |
| Grades | Excellent | Very Good | Good | Satisfactory | Unsatisfactory |
| Section -1 | Relevant application selection | Befitting application. Selection | Suitable application selection | Appropriate application | Not relevant application. |
| Section 2 | Precise UML diagram representation | Accurate UML diagram representation | Exact UML diagram representation | Correct UML diagram representation | UML diagrams do not satisfy the requirements. |
| Section 3 | Design that satisfies all requirements of distributed architecture | Design that satisfies partial Requirements of distributed design | Design that satisfies some Requirements of distributed design | Design that satisfies few Requirements of distributed design | Design that does not considers features of distributed design |
| IEEE Reference style | Clear styles with excellent source of references. | Clear referencing style | Generally good referencing style | Sometimes clear referencing style | Lacks consistency with many errors |