Category:Service Usage Models

Overview
A Service Usage Model (SUM) models an existing or proposed e-assessment subsystem.

It describes a generic implementation-neutral design to address a particular e-assessment task (e.g “Implement summative assessment”). A SUM leads the user from design through to implementation, by identifying interrelated FREMA components i.e. use cases, service descriptions and software components - which support the overall functionality of the SUM.

Consider an application developer who wishes to implement a new web services based e-assessment application. Without SUMs, he or she would need to not only identify potentially many individual web services, but also need to design and implement the workflow(s) amongst them. In contrast, an appropriate SUM will have already identified candidate services, together with their workflow logic.

A typical SUM includes


 * Usage guidance – why, when, where and how you would use this SUM
 * Use case(s) – gleaned from actual e-assessment practice - which collectively support the SUM's overall functionality
 * Service Descriptions – these are derived from the use cases
 * Software - these components (e.g. web services) implement the behaviour described by the service descriptions
 * Workflow(s) – high level models of how the software components interact.

It is expected that SUMs will form the first "port of call" for many users of the reference model.

Note that SUMs are core components of the JISC E-Framework (and therefore are supported within JISC Reference Models); for more details click here.

Internal Components of a SUM
A Service Usage Model component comprises the following internal sections (which you must specify when creating a new SUM).

Description of the Service Usage Model
This section gives a high level overview of the SUM. It should clearly scope the functionality supported (if appropriate, explicitly state what is not covered). Provide details of how the SUM was originally generated (e.g. who carried out the work, how the use cases were collected etc).

Use Case Diagram
The Use Case Diagram is the "big picture" - it is a high level representation of the functionality covered by the SUM. Each of its component use cases should be defined as a separate FREMA Use Case component. Note the inclusion of actors - you should provide a text description of each of these too.

Component Use Cases
If you look at an existing SUM (e.g. Summative Assessment), you will see a list of its component use cases underneath the use case diagram. This list is generated by the following query

Is decomposed from:: < name of SUM >

where the name of the SUM in question appears as indicated above. This retrieves all use cases which have been defined as being decomposed from the top level use case.

Service Descriptions
This section identifies the FREMA service description which have been mapped against the use case(s) of the SUM. This mapping exercise will have been conducted by the authors of the SUM, who will have either chosen existing or created new service descriptions.

It is recommended that these services descriptions are depicted using SRC Cards in this section of the SUM.

Interaction Diagrams
A crucial aspect of the SUM is its specification of how the component web services interoperate.

The SUM should depict the workflow amongst these services. The recommended way to illustrate this is via Service Interaction Diagrams (SIDs).

Attributes
A SUM does not currently have any attributes.

Related Components and Associations
The following table identifies the other components to which Service Usage Model is associated. Click on an association below to find out more information.

Usage
Create a new SUM to represent a design describing a high level subsystem of e-assessment.