U-6_Med Coll Exam Model_C-S-UML Diagrams


Published on

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

U-6_Med Coll Exam Model_C-S-UML Diagrams

  1. 1. Modelling an Examination System in a Medical CollegePreface 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 diagramThe techniques of Rumbaugh et al, Reingruber and Gregory were applied for identifying the classes. Based on the relative importance of certainclasses (frequency of occurrence), a high level Class diagram was developed with 14 classes. This was modified in the second (detailed) Classdiagram 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 wereiteratively 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. 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 OsceExaminer 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. 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 >oneexam(s) and prepares >one report(s). The ‘College’ forms a ternary relationship with >one ‘Person(s)’ and an ‘Exam system’. All three havestrong associations. Therefore, instead of the ‘weak entity’ technique described by Database Design Studio[2], the Visual Paradigm technique ofternary 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 differentroles (e.g. lecturer can be examiner, student can be prospective examinee). All are subclasses of ‘Status’; and they constitute recursiverelationship (play role) within ‘Status’. Anybody applying to undertake an examination (first or re-sit) is a ‘Prospective examinee’, who may bea 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 severalclasses, 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 repositoryof shared operation signatures for its subclasses.[1] One ‘Exam system’ is associated with >one ‘Examination(s)’ (e.g. MRCCI PartB), whichincludes >one ‘Assessment(s)’ (e.g. OSCE), the three forming a ternary relationship.
  4. 4. 5. Objective Structured Clinical Examination (OSCE) includes a patient/specimen/investigation result in a ‘Clinical encounter station’. This isdifferent from only a Standardized Patient used by Kessler in its OSCE program.[3] One or more ‘OSCE’ is associated with >one ‘Clinicalencounter station(s)’. One or more ‘Examiner(s)’ / ‘Student(s)’ may be related to >one ‘Examination(s)’ / ‘Assessment(s)’ (quaternaryassociation), 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)’ maybe 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 theyare capable of assessing and additional duties are grouped under ‘Capability’, which in turn is dependent on the ‘Training’ that the examinerundergoes.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 inthe ‘Assessment’-‘Station’ relationship. Where a marking scheme exists, it is an attribute in ‘Result Summary’. Thus in the resulting ResultSummary table, marking scheme is a field. Each Result Summary goes on to constitute a record in the ‘Assessment Report’ table. Dependingon 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. 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 Robinbaguley: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. 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 X1. There are two Sequence Diagrams (SD’s). One models Baguley (a fictitious student) giving MRCCI Part B, and the other models thetimetable/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 theappropriate class operations in the CD.3. The principle events/messages are between Student, College, Examiner object-classes, which are modeled as actors in the correspondingUse 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 importantindividual 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 havebeen 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. 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. Ifany 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 incorporatesan 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 separateDate but in the same Location (Green Square) as the OSCE. The latter consists of 4 sessions of 45 minutes’ duration each, each sessionoccurring 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 RCCIdatabase, gives permission, Baguley pays the fee and is granted an assessment ID. Thereupon, RCCI searches for and locates Sanyal as examinerfrom RCCI database, entrusts MRCCI Part B exam system with creating the timetable, and subsequently informs Sanyal and Baguley aboutMRCCI Part B timetable. Sanyal conducts the written and OSCE exams, both in Green Square but on different dates and times (staggeredsessions) 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). Inthe meanwhile Baguley’s MRCCI Part B result summary is included in his assessment report, which refines his candidate report, and finallyRCCI updates Baguleys details in RCCI database. USE CASE DIAGRAM – Parent (Exam System)
  8. 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 FeeStudent 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. 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 toan 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/arelinked to >one student(s) through examination(s). All details are maintained in college database. College also receives application forexamination, 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 hadCommunication Associations with several Use cases included in Application, Examination, Result and Database packages respectively. Theuse 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, withactors 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. 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/timetableSchedule is modeled as a separate UCD under the MRCCI Part B Schedule system. Schedule includes two packages, Written and OSCE. TheStudent and Examiner (actors) communicate with the use cases along with Date and Location (actors). Since the venue/location for bothwritten and OSCE are same (but on different dates), there is no need to model the venue/location separately for both. However, since the OSCEhas a number of sessions of 45 minutes’ duration each in successive rooms (in same venue/location), ‘time’ and ‘room numbers’ are modeledindividually for each actor.Parent-childSchedule 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 theobject-classes in the parent SD, and the individual Use Cases themselves match the events/messages in the parent Schedule SD.Reference1. 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 (Accessed25 September 2005)3. Objective Structured Clinical Examination. Kessler Medical Rehabilitation Research and Education Corporation website. © 2000, 2001KMRREC. 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).