Category:Use Cases

Overview
Developing use cases is a well established software engineering technique to model functionality within a particular domain. In FREMA, use case components are high level abstractions which represent generic e-assessment practice.

A use case component specifies
 * a unique name, which describes the area of e-assessment functionality it models
 * a list of players, each of which interacts with some or all internal steps of the use case. Note that an actor may be a human, or a system
 * a list of internal steps which perform the overall functionality of the use case
 * relationships with one or more other use case components, via one of the following predefined semantic relationships
 * decomposition - a use case can be broken down into two or more lower-level use cases, each of which models a particular aspect of the parent use case
 * inclusion - the functionality of the target use case is invoked by the source use case. The reason the target appears as a distinct use case is that it can be shared by two or more source use cases
 * extension - the functionality of the target use case may be optionally invoked by the source use case

Use Case Diagrams
You may encounter a use case diagram within a use case. For example, the Artefact Assessment use case contains the following diagram.



Note a use case diagram is not a use case per se. Instead it pictorially depicts the actors involved and the component use cases within the parent use case. The parent use case (in this case Artefact Assessment is decomposed into many lower level child use cases - each depicted by a "bubble" on this diagram. Each child use case has its own use case component defined within the reference model.

Example of a FREMA Use Case
There is a use case called Reflect (Artefact Assessment). This relates to the process under which a tutor ponders on how his or her teaching practice may be altered in future, based on previous candidates' performance and feedback.

The use case specifies
 * 2 players viz. Tutor and Student (what roles does student play here??)
 * has the following internal eight steps, which describe the linear sequence of actions which make up this Reflect (Artefact Assessment) use case. Note they are expressed in generic high-level notation (not in any computer language).
 * 1. Tutor reflects on if group learning and assessment appropriate
 * 2. Tutor reflects on previous performance
 * 3. Tutor designs support to best ensure successful learning and assessment
 * 4. Tutor collects student feedback
 * 5. Tutor analyses student feedback
 * 6. Tutor researches behaviours and possible improvements
 * 7. Tutor evaluates effectiveness
 * 8. Tutor reflects on this year's performance
 * 2 other related use cases
 * Reflect (Artefact Assessment) is decomposed from Artefact Assessment
 * Reflect (Artefact Assessment) includes Track (Artefact Assessment)

How use cases are used within FREMA
The main objective of use cases is to represent high level generic functionality of e-assessment systems (both existing and proposed).

The FREMA user should approach use cases as follows:


 * Identify a use case whose title appears to be of interest
 * Examine its high level overview i.e. the players involved and the internal steps which comprise the use case
 * Follow the links to the other related use cases (e.g. by inclusion)
 * For each use case, examine the table which shows related service descriptions and software components. Thereby you can judge which (if any) software components exist to support the functionality described by this use case.

For example, a use case U may contain the following table

This usecase is composed of the following usecases:

In other words
 * use case X is decomposed from use case U; use case X is (partially or fully) fulfilled by service description SD1; software component WS1 implements SD1
 * use case U includes use case Y; use case Y is (partially or fully) fulfilled by service description SD2; no software component implements SD2
 * use case U is extended by use case Z; use case Z is (partially or fully) fulfilled by service description SD3; software component WS3 implements SD3

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