INM 330: Software Systems Design Coursework 2018/19
1 Specification of a design model for an expense management system
This part of the coursework requires you to specify a design model for an EXpense MAnagement System (EXMAS). This system is described in Section 2 below. The design model that you are required to construct must include an architecture model for EXMAS, and a detailed design model consisting of design class and object interaction diagrams for the some of the use cases of EXMAS.
2 System Overview
EXMAS will be developed to support the management (i.e., recording, reviewing, clearing, monitoring and auditing) of expenses, which are made by the employees of different organisations and are related to the business activities of their organisations.
In particular, EXMAS should support:
- Recording of expense claims – EXMAS should support the recording of expenses made by different employees of an organisation (e.g., travel costs, hospitality expenses etc.) and the uploading of documentation (e.g., scanned copies of receipts, invoices, tickets etc.) that provides evidence of the occurrence of these expenses.
- Reviewing and handling of expense claims – EXMAS should support the reviewing of recorded expenses by employees of an organisation, who have appropriate authorisation rights for this, and the recording of decisions regarding the handling of such expenses (e.g., their approval, rejection or referral).
- Recording of expense claim payments – EXMAS should support the recording of any payments made for approved expense claims.
- Audit of the expense management process of an organisation – EXMAS should support a full audit of the expense management process within an organisation. This capability should be available to different users who participate in the expense management process depending on their role. Individual claimants should, for instance, be able to view the full trace of the steps through which each of the expense claims that they have submitted has been processed; claim approvers should be able to view the full trace of the processing of each of the expense claims that they have dealt with, and claim authorization and payment confirmation signatories should be able to view and audit aggregate reports regarding expense claims (e.g., the total amount of expenditure for claims of a given type, for claims related to individual organization units or cost codes etc.). The same capability should also support the provision of paper reports for external auditors.
A more detailed description of the functionality of EXMAS is given by the use case model specified in Appendix A.
3 Your tasks
Your tasks for the coursework will be to develop:
(i) An architecture model for EXMAS. In developing this model, you should consider ALL the use cases of EXMAS.
(ii) A detailed design model for EXMAS, including a design class diagram and a design sequence diagram covering ONLY the use case Authorise Claim (Use Case: 08). Note that it WILL NOT BE NECESSARY to specify sequence diagrams for any additional use cases which may be included in or extend the above use case.
Before developing the above models, you should read carefully the marking scheme of the coursework that is given in Appendix B.
All the above models must be submitted as Magic Draw models in Moodle by the following deadlines:
• The architectural Model that you are required to develop under (i) above must be submitted by 17.00pm on 11/11/2018
• The detailed structural and behavioural design models, that you are required to develop under (ii) above must be submitted by 17.00pm on 09/12/2018
In creating and submitting the Magic Draw models for your coursework, you must ensure the following:
- (a) The model that you will submit for (i) and (ii) must be created using Magic Draw Personal Edition v18.5, as a UML project, with the option “Create Directory for Project and Related Data” selected as shown in Snapshot 1 below.
- (b) The perspective selected for these models should be “Software Architect” as shown in Snapshot 2 below.
- (c) The models that you submit for (ii) must be created as part of the same Magic Draw project that you created for (i) (hence, your final submission for (ii) will also include your submission for (i)).
- (d) The file that you submit in Moodle must be the .mdzip file generated by Magic Draw for the UML project that you created for (i) and (ii).
Snapshot 1
Snapshot 2
The detailed marking scheme for the coursework is given in Appendix B.
Appendix A: Use Case Model for EXMAS EXMAS: Use Case Descriptions
Name: Login |
ID: 01 |
Actor: User |
Preconditions: |
Flow of events: 1. REPEAT 1.1. The system prompts the user to enter his/her username and password. 2. IF user is authenticated THEN ELSE 2.2 The system displays an error message to indicate that maximum number of wrong login attempts has been reached. END IF |
Post conditions: |
Name: Authenticate |
ID: 02 |
Actor: |
Preconditions: User name and password are available to check |
Flow of events:
2.1 The user is authenticated ELSE 2.2 The user is not authenticated END IF |
Post conditions: |
Name: Employee Registration |
ID: 03 |
Actor: Administrator |
Preconditions: |
Flow of events:
|
|
Post conditions: The user is registered. |
Name: Record claim |
ID: 04 |
Actor: User |
Preconditions: The user is logged in |
Flow of events: 1. The system asks the user to provide a name for the new expense claim 2. The user provides the requested information 3. The system creates an empty expense claim and prompts the user to specify the individual items of expenditure that will be covered by it. 4. REPEAT to confirm whether he/she wants to edit, save or delete the claim. IF the user wishes to edit the claim THEN 4.2 DO EXTEND Edit Claim 4.3 The system discards the claim. ELSE 4.4 The system saves the claim. END IF ELSE 6. The system informs the user that he/she is not eligible to submit an expense claim END IF |
Post conditions: |
Name: Edit Claim |
ID: 05 |
Actor: User |
Preconditions: The user is logged in; a claim is selected; the user is eligible to submit an expense claim |
Flow of events: REPEAT
|
system to record it, or requests to close the claim. 3.1 The system checks the compliance of the provided information against the policy (e.g., that the amount for the item is within the expected boundaries etc) WHILE the information provided is not compliant and no request to close the claim has been made DO 3.2 The system highlights the information element(s) that need to be amended and prompts the user to fix them. 3.3 The user amends the information elements and asks the system to record it, or requests to close the claim. END WHILE 3.4 The system saves the information provided. END IF END IF UNTIL no request to close the claim has been received. |
Post conditions: Claim items are recorded |
Name: Review claims |
ID: 06 |
Actor: User with claim authorisation rights |
Preconditions: The user is logged in |
Flow of events:
|
Post conditions: |
Name: Review claim |
ID: 07 |
Actor: User with claim authorisation rights (authorization signatory) |
Preconditions: The user is logged in; a claim has been selected for review |
Flow of events: 1. The system presents the items of the claim to be reviewed. 2. REPEAT 2.1 The user selects a claim item or closes the claim. IF an item is selected THEN 2.2. The system presents the details of the claim item. 2.3 The user may select the option of recording an enquiry about the item, approve it, or close it. 2.4 IF the item enquiry option is selected THEN |
save it. 2.4.3 The system saves the enquiry and informs the owner of the claim that there is an enquiry for the item. 2.5 ELSE IF the item is approved THEN 2.6 ELSE ENDIF ENDIF UNTIL the user selects the option to close the claim 3. The system closes the claim. |
Post conditions: |
Name: Authorise Claim |
ID: 08 |
Actor: User with claim authorisation rights |
Preconditions: The user is logged in |
Flow of events:
|
Post conditions: |
Name: Pay Claim |
ID: 09 |
Actor: User with claim payment rights; |
Preconditions: User is logged in |
|
END IF |
Post conditions: |
Name: Claimant audit |
ID: 10 |
Actor: User |
Preconditions: User is logged in |
|
Post conditions: |
Name: Claim signatory audit |
ID: 11 |
Actor: Claim signatory user |
Preconditions: User is logged in |
|
Post conditions: |
Appendix B: Marking Scheme
Marking criterion |
Mark |
Out Of |
|
Part (i): Architecture model (40 marks) |
Specification of system components |
— |
12 |
Specification of component interfaces |
— |
12 |
|
Specification of realisation relationships between components and interfaces |
— |
5 |
|
Specification of usage relations between components and interfaces |
— |
5 |
|
Description of the architectural style used in the architectural model and clear identification of the roles that the individual components of the model have in reference to the style. |
— |
6 |
|
Part (ii): Structural Design Model (25 marks) |
Specification of all the entity, boundary and control classes required for realising the components of the architectural model |
— |
13 |
Correctness of
|
— — — — |
3 3 3 3 |
|
Behavioural Design Model (Sequence diagrams) (35 marks) |
Coverage of system functionality specified in relevant use cases |
— |
10 |
Correctness of flow of control
|
— — — — — — — — |
5 2 5 3 2 3 3 2 |
|
Total Mark |
— |
100 |