Last updated: June 27, 2001
 email: jyw
Home | MAPView

The Design Process:
The process for designing a system using the Unified Process as expressed through the Unified Modeling Language (UML) begins by identifying the users of the system. The design process is iterative, leaving a useable prototype at the end of each design cycle and remains user-centered by returning at the beginning of the next design cycle to the fundamental question, who uses the system and how.

Users/Actors:
A user, or actor in UML ( the Unified Modeling Language), is anyone, or strictly speaking anything that can be said to be a beneficiary of a system. In other words this describes a user interacting with the system to gain some benefit for themselves.
One final note before leaving the idea of actor. The word actor describes the rôle a user plays in the system. It is therefore possible, as in real life, for the same person to in turn play the role of Lecturer, Question Author and Examiner.

Use Cases:
Each type of interaction a user undertakes with a system, for example writing a question, is described as a use case. The collection of use cases for a system constitutes a description of the set of requirements for that system.

Actors: [ System design ]
Lecturer Question Author
Question Reviewer Examiner
Demonstrator Student
Exam Board  
Lecturer: [ other Actors ] [ System design ]
Use cases
1. Sets learning objectives: Determine from the syllabus description the aims and objectives of the course and arrange them hierarchically.
2. Authors notes: Creates a set of notes complementary to the lectures for the course and using the learning objectives for guidance.
3. Authors practicals: Creates a set of practicals to augment the lectures and meet the appropriate learning objectives for the course.
Question Author : [ other Actors ] [ System design ]
Use cases
1. Writes a question: Writes a multiple choice question and options according to certain heuristics and explicitly tied to one or more of the course's learning objectives
Question Reviewer : [ other Actors ] [ System design ]
Use cases
1. Reviews a question: Reviews questions submitted for inclusion in the question bank.
2. Analyses question performance: Analyses a question's performance in tests and recommends changes where appropriate.
Examiner: [ other Actors ] [ System design ]
Use cases
1. Sets a test: Selects from the question bank a set of appropriate questions and "publishes" them as a formative/summative test.
2. Monitors test results: Monitors test results for the appropriate discrimination across the set of tested students.
3. Informs the student of their result:

Email the student details of the results from any test the student is set.
4. Analyses Test Performance Analyses the results of test for individual question performance.
Demonstrator: [ other Actors ] [ System design ]
Use cases
1. Signs off a practical: "Signs off" a practical by inspection and if satisfied, records the time and any comments submitted by the demonstrator or student.
Student: [ other Actors ] [ System design ]
Use cases
1. Submits finished practical: Submits practical after a satisfactory inspection from a demonstrator.
2. Takes a test: Students take from time to time subjective/formative objective tests in mulitple choice form.
3. Receives test result: Receives, either on request or automatically, the results of a test including topical feedback.
4. Reviews learning material: Follows pointers from feedback towards resources and materials for "self repair".
5. Reflects on learning/performance: Interacting with review materials allows reflection on currently held cognitive models.
6. Takes up "affordances" Takes up available strategies best matching the student's learning style.
Exam board : [ other Actors ] [ System design ]
Use cases
1. Recieves student assessments: Receives from the system the results recorded from tests.
Special use case: the "support " use case attach learning objectives [ System design ]
Use cases
1. Attach learning objectives: Learning objectives as an expression of intent with respect to the published syllabus remain central to the system. Learning objectives are explicitly attached to the artefacts produced by several actors in the system as an adjunct to the their carrying out other use cases.
Lecturers and Question Authors attach learning objectives to lecture notes, practicals and objective questions.