1. Modelling an Examination System in a Medical College
Preface
Developing the Model
Identifying Classes Developing Sequence
Diagram, looking at the
scenario, using objects
(from classes)
Consolidating Sequence
Use Case analysis Diagram, creating child
of given scenario diagram
The techniques of Rumbaugh et al, Reingruber and Gregory were applied for identifying the classes. Based on the relative importance of certain
classes (frequency of occurrence), a high level Class diagram was developed with 14 classes. This was modified in the second (detailed) Class
diagram to include all possible classes in the scenario. A data dictionary was developed, defining the classes and identifying their attributes,
operations and associations. The classes were structured using inheritance, access paths for likely queries were verified and the diagrams were
iteratively refined.[1]
The Parent-Child Hierarchy
MRCCI Exam System (Class Diagram) MRCCI Part B Exam (Sequence Diagram)
Parent Parent
Child
MRCCI Part B Schedule (Sequence Diagram) MRCCI Exam System (Use Case Diagram)
Parent Parent
Child
MRCCI Part B Schedule (Use Case Diagram)

2. CLASS DIAGRAM – High Level
RCCI College Overview (Class)
System Architect Educational Version
Sun Sep 25, 2005 21:04
Comment
Created by Sanjoy; Unit 6 Final Assignment; Unit Tutor: Robin
1..* AssessHistory Timetable Location ClinicalEncounterStation
History - date - venue - patient
- assessmentId
- assessmentType - startTime 1..* Include 1..* - specimen
- assessmentNumber - endTime Schedule Venue - investigationResult
- date
Has - venue createSchedule ()
- startTime
1..* Station
- endTime 1..* Schedule
-# update () Has
1..* Exam
1..* Examiner Examination Assessment
1..* Conduct 1..* Has
Examiner
Examiner Exam - mrcciPartA - mcq
- mrcciPartB 1..* Has 1..* - osce 1..*
1..* 1..* - frcci - written
conductWrittenExam () Exam Osce - viva Osce
Examiner correctPaper () Examiner - criticalAppraisal
conductOsce ()
followMarkingScheme () 1..* Exam 1..* Exam
prepareResult () 1..* Osce
1..* Examiner
Conduct Generate
Give
Examine
1..* Result
1 Rcci
ResultSummary
1..* Student 1..* Student College MarkingScheme
Student - dateMarkObtained
1..* 1 - grade
Has 1..* Follow 0..*
Student - percentage
Rcci
- comment Result Scheme
- passFailStatus
- internalExternalStatus
1 rcci - finalResult
- markingScheme
1..* Student - /assessmentId
Maintain 1..* Has 1..* AssessmentReport
# includeResult () Result Assess report
- assessmentId
1..* Report - assessmentType
CandidateReport - assessmentNumber
1 Database - date
Detail in
PersonDatabase - venue
- gmcNumber <<refines>> - startTime
1 Update 1..* - surname Determine - endTime
1 - dob - /gmcNumber
Database Report - mrcciPartADate
Database - mrcciPartBDate
- frcciDate -# update ()
CLASS DIAGRAM – Detailed

3. MRCCI Exam System (Class)
System Architect E ducati onal V ersi on May become
Mon Sep 26, 2005 21:19 IDDetai l
Commen ContactDetail
- surname 1..* 1..*
Created by Sanjoy; Unit 6 Fi nal Assignment; T utor Robin
- name Member Associate
- houseNo
- dob
- streetName
- gender - postCode
<<i nterface>> - gmcNumber - city
PersonDatabase
- country
Update - phone
Realise
- mobil e
confirmStudentS tatus ()
locateExami ner ()
May become
1..* 1..*
1..*
1 Database 1 Database Status Fel low
T utor
Status
Play role
Is i n 1..*
Role
Person
Candi dateReport
1..* 1..*
Has rol e
- gmcNumber 1..* Role
1..* Has
- surname Report {Incomplete ProspectiveExami nee
Person 1..*
- dob Overlappi ng}
- mrcciPartA Date
- mrcciPartB Date
- frcciDate 1..* Person
Mai ntai n
+ refi ne ()
-# updateInDatabase ()
Examinati on <<actor>>
1Rcci 1 Rcci Student
May become
<<actor>>
Coll ege - mrcciPartA 1..*
1..*
1 Rcci Associated with - mrcciPartB
{addOnly} - frcci applyForMrcci PartB ()
payExamFee ()
checkForS tatus () 1..*
sitWrittenExam ()
grantExamPermi ssion () 1..*
appearForOsce ()
allocateAssessmentId () 1..* Exam applyForResit ()
searchForExami ner () 1 System
appraiseExaminer () <<metacl ass>> Conduct and appear
sel ectExami ner () 1
ExamSystem Has
initiatePreparation () Exami ne <<actor>>
System Examiner
informS chedule ()
1..*
updateCandidateReport ()
1 createSchedul e ()
informResult ()
System inti mateSchedule () 1..* Osce
denyResit () conductWrittenE xam ()
congratul ate () conductWrittenE xam () Assessment 1..*
1..*
1..* 1..* correctPaper ()
updateInDatabase () conductOsce ()
conductOsce ()
prepareResult () - mcq Cli nicalEncounterStati on foll owMarki ngScheme ()
- osce prepareResult ()
1 System - wri tten - pati ent
- viva 1..* Has 1..* - specim en
Resul tSummary - cri tical Apprai sal Osce Station- investigationResult 1..*
1..* Generate 1..*
Detail in database
Resul t Has Osce
- dateMarkObtai ned {Complete
- grade 1..* Osce Overlappi ng}
- percentage 1..* Schedul e 1..* Station
- comment <<i nterface>>
- passFail Status T im etable
- internalExternalS tatus 1..*
- finalResul t Fol low
- date
- markingScheme Schedul e
- startT i me
- /assessmentId - endT ime MarkingScheme
GeneralDetail AssessHi story
0..*
# incl udeResult () createSchedul e () Fol low
Scheme - gmcNumber - assessmentId
- surname - assessmentT ype
1..*Resul t - gi venName - assessmentNumber
1..* Resul t T im etable variabl e
- dob - date
{Complete
- qualificati on - venue
Overlappi ng}
- startT i me
- endT ime
<<refines>>
Determi ne
-# update ()
ExaminerStatus
Has
Date Location RoomNumber Capabil ity 1..*
- external
Room102 - internal
- beginT ime - venue - mrcciPartA
- endT ime - osceExami ner Has
conductExamination ()
1..*
Assess report - whol eMrcci PartB
AssessmentReport - whol eFrcci
1..*
T rai ni ng
- assessmentId deviseM cq ()
- assessmentT ype revi ewM cq ()
<<refines>> - trainingCourse
{Complete deviseOsce ()
- assessmentNumber Determi ne - refresherCourse
Overlappi ng} conductOsce ()
- date - peerRevi ew
- venue revi ewE xamPaper ()
- startT i me conductViva ()
Room201 Room113 Room105 conductApprai sal () -# undertake ()
- endT ime
- /gmcNumber
-# update ()
1. College is the hub of the entire model. One college (RCCI) can have >one student(s) / examiner(s), maintains one database, conducts >one
exam(s) and prepares >one report(s). The ‘College’ forms a ternary relationship with >one ‘Person(s)’ and an ‘Exam system’. All three have
strong associations. Therefore, instead of the ‘weak entity’ technique described by Database Design Studio[2], the Visual Paradigm technique of
ternary relationship was employed.[1]
2. ‘Person’ refers to all people associated in any capacity with the college (lecturer, fellow, member, student, examinee etc). They have different
roles (e.g. lecturer can be examiner, student can be prospective examinee). All are subclasses of ‘Status’; and they constitute recursive
relationship (play role) within ‘Status’. Anybody applying to undertake an examination (first or re-sit) is a ‘Prospective examinee’, who may be
a student of RCCI or an external candidate.
3. Comprehensive details of all of these people are maintained in one ‘Person database’, which is modelled as an Interface, realized by several
classes, one of which is ‘Status’.
4. ‘Exam system’ is an abstract superclass (Stereotype metaclass). We cannot instantiate the abstract class ‘Exam system’. It acts as a repository
of shared operation signatures for its subclasses.[1] One ‘Exam system’ is associated with >one ‘Examination(s)’ (e.g. MRCCI PartB), which
includes >one ‘Assessment(s)’ (e.g. OSCE), the three forming a ternary relationship.

4. 5. Objective Structured Clinical Examination (OSCE) includes a patient/specimen/investigation result in a ‘Clinical encounter station’. This is
different from only a Standardized Patient used by Kessler in its OSCE program.[3] One or more ‘OSCE’ is associated with >one ‘Clinical
encounter station(s)’. One or more ‘Examiner(s)’ / ‘Student(s)’ may be related to >one ‘Examination(s)’ / ‘Assessment(s)’ (quaternary
association), with ‘Clinical encounter station’ as an Association class.
6. ‘Timetable’ is an Interface within the ambit of ‘Exam system’, and directly related to it. One or more ‘Assessment(s)’ and ‘Station(s)’ may
be related to >one ‘Schedule(s)’ (ternary relationship). Timetable is realized by ‘Date’, ‘Location’ and ‘Room number’.
7. Examiner details, including those in Examiner Training Record Folder, are modelled under ‘Examiner’ and included as subclass of ‘Status’,
which in turn realizes the ‘Person Database’ interface. Thus all details automatically get included in the database. Details of assessment they
are capable of assessing and additional duties are grouped under ‘Capability’, which in turn is dependent on the ‘Training’ that the examiner
undergoes.
8. All Inheritances are labelled with a discriminator (variable that forms the basis for differentiation between subclasses). Constraints
(Complete/Incomplete; Overlapping/Disjoint) are specified.[4]
9. Result may have >zero ‘Marking scheme(s)’, and >one ‘Examiner(s)’ can follow it, if it exists. ‘Marking scheme’ is an Association class in
the ‘Assessment’-‘Station’ relationship. Where a marking scheme exists, it is an attribute in ‘Result Summary’. Thus in the resulting Result
Summary table, marking scheme is a field. Each Result Summary goes on to constitute a record in the ‘Assessment Report’ table. Depending
on the assessment report, the ‘Candidate Report’ is refined (dependency), and finally the status is realised in the ‘Person Database’.
SEQUENCE DIAGRAM – Parent (Exam system)

5. Rectangle_1
sd mrcci part b exam (MRCCI Exam MRCCI Part B Exam (Sequence)
System pakage) System Architect Educational Version
Sun Sep 25, 2005 21:22
Comment
Message naming = Target style Created by Sanjoy, Unit 6 Final Assessment, Tutor Robin
baguley:Student rcci:College
Apply_for_mrcci_part_b rcci:PersonDatab
ase
Check_for_status
Confirm_student_status
Grant_exam_permission
Pay_exam_fee
Allocate_assessment_id
Search_for_examiner
Locate_examiner
sanyal:Examiner
Appraise_examiner
Select_examiner mrcciPartB:Exa mrcciPartB:Time
mSystem table
Initiate_preparation
sd Create_schedule
Interaction fragment attached as child to current SD
Intimate_schedule
Inform_schedule Inform_schedule
Sit_w ritten_exam Conduct_w ritten_exam
Correct_paper
Appear_for_osce
Conduct_osce
Follow _marking_scheme X
baguley:ResultS baguley:Assess
ummary mentReport
baguley:Candidat
eReport
Prepare_result Prepare_result
Include_result
X
Notify_result Refine
X
Update_candidate_report X X
Inform_result
Alt
[If fail </=2]
Loop
[While still failed]
Apply_for_resit
[If fail >2]
Deny_resit
[If pass]
Congratulate
Update_candidate_report
Update_in_database Update_in_database
SEQUENCE DIAGRAM – Child (Schedule)

6. MRCCI Part B Schedule (Sequence)
System Architect Educational Version
Mon Sep 12, 2005 23:19
sd create schedule Comment
(Timetable package) Created by Sanjoy; Unit 6 Final Assessment;
Tutor Robin
message naming=target style
sanyal:Examiner mrcciPartB:Date greenSquare:Loc
ation
baguley:Student
Conduct_written Conduct_written
9.00 AM to
Sit_written 12.00 noon
Sit_written
Conduct_osce Conduct_osce
9.15 AM
to1.00 PM
Appear_for_osce Appear_for_osce
X Include bagSan:Room102
session room #
Conduct_osce_session1 9.15 AM to
10.00 AM
Appear_osce_session1
X
bagSan:Room105
Conduct_osce_session2
Appear_osce_sesion2 10.15 AM to
11.00 AM
X
bagSan:Room113
Conduct_osce_session3
Appear_osce_session3 11.15 AM to
12.00 noon
X
bagSan:Room201
Conduct_osce_session4
12.15 PM to
Appear_osce_session4 1.00 PM
X
1. There are two Sequence Diagrams (SD’s). One models Baguley (a fictitious student) giving MRCCI Part B, and the other models the
timetable/schedule of the exam. The latter is a child of the former.
2. Though almost all relationships in the Class Diagram (CD) are M:N, the SD’s model a specific instance. All the events/messages map to the
appropriate class operations in the CD.
3. The principle events/messages are between Student, College, Examiner object-classes, which are modeled as actors in the corresponding
Use Case Diagram. Person Database and Timetable have been modelled as interfaces in the corresponding CD.
4. Exam System, a Stereotype metaclass in the CD, has been considered as an additional object-class in this SD because it has important
individual role to play. The other object-classes are Result Summary, Assessment Report and Candidate Report.
5. It is assumed that the applicant (examinee) is already a student of RCCI. Though, if an external candidate applies for exam, there would have
been additional sequences involving adding details to database from data entered in prospective examinee’s application form.
6. Exam system is charged with the responsibility of creating a Timetable. This is represented as an Interaction Fragment (IF) in the SD.

7. 7. While RCCI would decide each re-sit case on its own merits, for this model it has been decided that it would allow a maximum of 2 re-sits. If
any candidate fails thereafter (or requests more re-sits for any reason) it would not be permitted.
8. Re-sit has been modeled as a multiple branching (Alternative) IF in the SD, where RCCI gives permission for upto re-sits. This incorporates
an iterative (Looping) IF where a re-sit candidate follows the same SD. Thus, Loop IF is nested within Alt IF.
9. Timetable (interface in the CD) is realized by Date, Location and Room number. The written exam of three hours occurs on a separate
Date but in the same Location (Green Square) as the OSCE. The latter consists of 4 sessions of 45 minutes’ duration each, each session
occurring in a different Room. All assessments are conducted by Examiner (Sanyal) and sat/appeared by Student (Baguley).
Brief sequence of events: Baguley applies to RCCI for MRCCI Part B exam. The college, after verifying Baguley’s details from RCCI
database, gives permission, Baguley pays the fee and is granted an assessment ID. Thereupon, RCCI searches for and locates Sanyal as examiner
from RCCI database, entrusts MRCCI Part B exam system with creating the timetable, and subsequently informs Sanyal and Baguley about
MRCCI Part B timetable. Sanyal conducts the written and OSCE exams, both in Green Square but on different dates and times (staggered
sessions) and Baguley sits/appears for all.
Sanyal prepares Baguley’s MRCCI Part B result and notifies same to RCCI, which in turn informs Baguley (and permits re-sit if applicable). In
the meanwhile Baguley’s MRCCI Part B result summary is included in his assessment report, which refines his candidate report, and finally
RCCI updates Baguleys details in RCCI database.
USE CASE DIAGRAM – Parent (Exam System)

8. MRCCI Exam System (Use Case)
System Ar chitect Educational Version
Sun Sep 25, 2005 21:54
Comment
Created by Sanjoy, Unit 6 Final Assessment; Tutor Robin
MRCCI Exam System
Application
Apply For
Mrcci Part B
Grant Exam
Permission
College
Pay Exam Fee
Student Allocate
Assessment Id
Apply For Resit
1..*
Database
<<include>>
Examination
Check For
Status
Initiate
pr eparation
<<include>> Search For
Examiner
Infor m Schedule Examine Confirm
<<include>> Student Status
Written Exam
<<include>> Select
<<include>> Examiner
Create
Schedule
Corr ect Paper
<<include>>
Appear Appraise Examiner
Examiner
Osce
1..*
Update Update In
Candidate Database
<<include>> Repor t
Result
<<include>>
Follow Marking <<include>>
Scheme
<<include>>
Prepare Result
Infor m Result Congratulate
Schedule-child
MRCC I Part B Sche dule (Use C ase )
Sy stem Arch ite ct Edu cation al Versio n
Su n Se p 25, 20 05 10 :17
MRCC I Part B Sche dule
Picture attachment
OSCE

9. USE CASE DIAGRAM – Child (Schedule)
MRCCI Part B Schedule (Use Case)
System Architect Educational Version
Sun Sep 25, 2005 10:17
Comment
Created by Sanjoy, Unit 6 Final Assessment; Tutor Robin
MRCCI Part B Schedule
Written
Give Exam
Three Hours
Sit Date
Conduct
Venue
Student
OSCE 45 minutes
Appear 45 Minutes
Give Osce
Session 1
45 Minutes
Appear
Appear 45 Minutes
Appear Give Osce
Session 2 Room 102
Room 105 Location
Examiner Conduct Give Osce
Session 3 Room 113
Conduct
Conduct Room 201
Conduct Give Osce
Session 4
“[A] use case is a description of a set of sequences of actions, including variants that a system performs to yield an observable result of value to
an actor.” (Booch 1993).[5]
The Use Case Diagram (UCD) is a simple overview of the scenario. The college has examiner and student. One or more examiner(s) is/are
linked to >one student(s) through examination(s). All details are maintained in college database. College also receives application for
examination, conducts same and releases result.
Therefore only three key classes were chosen to represent actors; viz Student, Examiner (person(s)) and College. These three actors had
Communication Associations with several Use cases included in Application, Examination, Result and Database packages respectively. The
use cases map to the events/messages/stimuli in the SD and class operations in the CD. The use cases are included in a system boundary, with
actors outside the system as external observers.[6]
<<Include>>
• Create Schedule use case can be factored out to Initiate Preparation and Inform Schedule use cases, all in the Examination package.
• Confirm Student Status use case can be factored out to Check For Status use case (both in Database package), as well as to Allocate
Assessment Id use case in Application package.
• Appraise Examiner use case can be factored out to Search For Examiner and Select Examiner use cases in Database package.

10. • Prepare Result use case in Result package includes Follow Marking Scheme use case (in Result package), Update Candidate Report
and Update In Database use cases (both in Database package).
Generalization
• Update In Database use case is a special kind of Update Candidate Report use case, in Database package.
• Select Examiner use case is also a special kind of Search For Examiner use case, in Database package.
• In the Result package, Congratulate use case is a special kind of Inform Result use case.
In each situation, the ‘child’ use case can be substituted for the base use case towards which it is pointing.
Schedule/timetable
Schedule is modeled as a separate UCD under the MRCCI Part B Schedule system. Schedule includes two packages, Written and OSCE. The
Student and Examiner (actors) communicate with the use cases along with Date and Location (actors). Since the venue/location for both
written and OSCE are same (but on different dates), there is no need to model the venue/location separately for both. However, since the OSCE
has a number of sessions of 45 minutes’ duration each in successive rooms (in same venue/location), ‘time’ and ‘room numbers’ are modeled
individually for each actor.
Parent-child
Schedule UCD is attached as a child to the first UCD, and also to the MRCCI Part B Schedule SD. Thus the actors in the child UCD map to the
object-classes in the parent SD, and the individual Use Cases themselves match the events/messages in the parent Schedule SD.
Reference
1. Structural Modelling and Analysis Chapter 2. Visual Paradigm tutorial. URL: http://www.e-courses.rcsed.ac.uk/mschi/Unit6/oot-ch02.pdf
(Accessed 25 September 2005).
2. Ternary Relationships. Database Design Studio. URL: http://www.chillisource.com/dds/tutorial/TutorialTernary_Relationships.htm (Accessed
25 September 2005)
3. Objective Structured Clinical Examination. Kessler Medical Rehabilitation Research and Education Corporation website. © 2000, 2001
KMRREC. URL: http://www.kmrrec.org/KM/osce/ (Accessed 25 September 2005).
4. Dao M, Huchard M, Libourel T, Pons A. Extending the Notation for Specialization/Generalization – Proposal for a Discussion Group. URL:
http://www.iro.umontreal.ca/~maspeghi/Papers/MASPEGHI03F-04-Dao-et-al.pdf (Accessed 25 September 2005).
5. Use Case Modeling and Analysis Chapter 3. Visual Paradigm tutorial. URL: http://www.e-courses.rcsed.ac.uk/mschi/Unit6/oot-ch03.pdf
(Accessed 25 September 2005).
6. Miller R. Practical UML™: A Hands-On Introduction for Developers. Borland Developer Network website. Last revised December 2003.
URL: http://bdn.borland.com/article/0,1410,31863.html#use-case-diagram (Accessed 25 September 2005).