软件工程代写 INM 330: Software Systems Design

程序代写 CS代考 / 软件工程

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:

  1. (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.
  2. (b)  The perspective selected for these models should be “Software Architect” as shown in Snapshot 2 below.
  3. (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)).
  4. (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.
1.2. The user enters his/her username and password.
1.3. DO EXTEND Authenticate
UNTIL user is authenticated or more than three authentication attempts have been made

2. IF user is authenticated THEN
2.1 The system logs the user in.

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:

  1. The system checks the provided user username and password
  2. IF both the username and password are correct THEN

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:

  1. The user selects the registration option.
  2. The system prompts the user to enter the name, address, telephone numbers, e-mail address (if any) and organizational unit of an employee.
  3. The user enters the requested information.
  1. The system registers the user and creates a login name and creates a password for him/her.
  2. The system notifies the employee of his/her password by sending an email to his/her recorded email address.
  3. The system informs the user of the completion of the registration.

Post conditions: The user is registered.

Name: Record claim

ID: 04

Actor: User

Preconditions: The user is logged in

Flow of events:
IF the user is eligible to submit expense claims THEN

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
4.1 The system presents the items recorded under the claim and asks the user

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
ELSE IF the user wishes to discard the claim THEN

4.3 The system discards the claim.

ELSE

4.4 The system saves the claim.

END IF
UNTIL the claim is saved or deleted

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

  1. The system prompts the user to specify a new item for the claim by indicating: (a) the type of the expenditure item (e.g., travel tickets, hotel expenses, meal expenses); (b) the amount of the incurred expenditure; (c) the currency in which the expenditure has been incurred; (d) the exact date on which the expenditure was made; and (d) evidence of the expenditure by uploading the relevant documentation (e.g., a receipt, an invoice, a ticket etc.) or close the claim.
  2. The user provides any of the information elements (a)-(d) for the item and asks the

system to record it, or requests to close the claim.
3. IF the user has provided new information for the item THEN

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
IF the information provided is compliant THEN

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:

  1. The presents the expense claims under the responsibility of the particular user, and prompts him/her to select one to review.
  2. The user selects an expense claim or exits the process.
  3. IF an expense claim is selected THEN

    3.2 DO EXTEND Review claim END IF

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
2.4.1 The system prompts the user to type in the enquiry about the item. 2.4.2 The user types in the enquiry about the item and asks the system to

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.5.1 The item is recorded as approved.

2.6 ELSE
2.6.1 The item is closed.

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:

  1. The system presents the list of expense claims under the responsibility of the particular user that have all their items approved.
  2. The user selects an expense claim.
  3. The system shows all the items recorded under it.
  4. The user selects one of two options: (a) to authorise the claim for payment, or (b) to review it further.
  5. IF option (a) is selected THEN
    5.1. The system records the authorisation of payment and notifies the accounts

    department.

    ELSE
    5.2 DO EXTEND Review Claim

    END IF

Post conditions:

Name: Pay Claim

ID: 09

Actor: User with claim payment rights;

Preconditions: User is logged in
  1. The system presents the list of expense claims that have been authorised for payment.
  2. The user selects an expense claim from the list.
  3. The system shows all the items recorded under it.
  4. The user selects one of two options: (a) to confirm the claim for payment, or (b) to review it further.
  5. IF option (a) is selected THEN
    5.1 The system records the confirmation of payment and notifies the accounts

    department.

    ELSE
    5.2 DO EXTEND Review Claim

END IF

Post conditions:

Name: Claimant audit

ID: 10

Actor: User

Preconditions: User is logged in
  1. The system presents the list of expense claims made by the user.
  2. The user selects an expense claim from the list.
  3. The system shows the claim enquiry, payment authorisation, and payment confirmation actions recorded against it along with the relevant dates.
  4. The user closes the claim.

Post conditions:

Name: Claim signatory audit

ID: 11

Actor: Claim signatory user

Preconditions: User is logged in
  1. The system presents a list of options for selecting claims approved by the specific signatory. These options allow the selection of claims by: (a) their type, (b) the organization unit they relate to, (c) the cost code they relate to, (d) the claimant that made them, or (e) the period within which they were approved and/or paid.
  2. The user selects one of the options (a)-(e) or quits the process.
  3. The user selects an option.
  4. IF one of the options (a)-(e) is selected THEN

    4.1. The system prompts the user to provide the relevant claim selection information. 4.2. The user provides the criterion.
    4.3. The system retrieves and presents the relevant list of claims.
    4.4. The user may select one of the retrieved claims or quit the process.

    4.5 IF a claim is selected THEN
    4.5.1. The system shows the claim enquiry, payment authorisation, and payment

    confirmation actions recorded against it along with the relevant dates.

    ELSE

    4.5.2. The process is ended.

    END IF ELSE

    4.6. The process is ended.

    END IF

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
(the interfaces should cover all the functional capabilities of the system that have been described in the use cases targeted by the coursework).

—

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

  • Attributes (expression of class properties, correct type, no redundancy)
  • Associations (names, correct multiplicities, assoc. classes if necessary)
  • Operations (sufficient parameters)
  • Generalisation relations

— — — —

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

  • Existence of message activators
  • Messages to show <<includes>> and

    <<extends>> relations

  • Appropriate handling of data storage (where applicable)
  • Plausible interactions with external actors/users
  • Specification of iterations/conditions as necessary

    Messages must correspond to operations in class diagrams developed for A.(ii)

    Messages must have full signatures & sufficient arguments

    The classes of objects in SDs are specified and exist in the class diagrams

— —

— — — —

— —

5 2

5 3 2 3

3 2

Total Mark

—

100

Related Posts