Introduction
Arab Open University specializes in distance learning courses that people can take from the comfort of their home. Each course has several modules for which the students need to pass the assessments and give examinations at the exam center. The examination process is managed through a system that is looked by an administration officer. The administration officer books the exam venue by giving an initial deposit for securing the exam venue.
The payment of the security deposit for the exam venue is authorized by the administration officer. The students receive the examination venue list three months before the exam, and they can pick their choice of venue.
After the confirmation of venue choices by the students the administrator allocates some exam invigilators for each of the venue based on the student strength. On examination day and exam venue, the student needs to register by showing a proof of identity to the Invigilator.
The invigilator checks the student identity and records it for audit purpose. On exam completion, an invigilator matches the students present and the scripts submitted. The scripts are then sent to the Administration Officer. The administration officer then sends the scripts to a relevant examiner for marking. The marked scripts are then sent back to the Administration Officer by the examiner. After receiving the marked scripts Administration Officer publishes the result list on the examination board.
Actors: Students, Administration Officer, Invigilator, Examiner
Use Cases: Student Enrolment into Course Modules, Course Assessments, Course Examination, Administration Officer Sends Exam Centre List, Student Picks Exam Venue, Exam Day Student Registration at Venue, Student Identity Verification by Invigilator, Invigilator Records Student Identity Proof, Student Submits Exam Script, Invigilator sends Script to Administration Officer, Administration Officer publishes result, Student views Exam Result
Figure 1: UML Use Case diagram
Figure 1 depicts a UML Use case diagram with four actors namely Student, Invigilator, Administration Officer and Examiner. The actor is the instigator of a system or process. The use cases are all in respect of an actor of a system. The use case descriptions help in further analyzing and designing a system architecture for use case implementation (Eriksson, and Penker, 2000). The Use Case diagram depicts all the major use cases that occur in the flow of the learning courses that a Student takes, the Assessment and Examination use case and the relation of all the four actors with each of the use cases. Some of the use cases interact with other use cases like ‘Course Assessment’ and ‘Course Examination’ use cases are linked to the use case ‘Enroll Course Modules’ which is instigated by the Student Actor. Similarly ‘Course Exam Script’ use case is related to ‘Course Examination’ and ‘Exam Day Venue’ modules instigated by the actors Student and Invigilator. Likewise, the Administration Officer and Examiner actors have their respective relations with other use cases.
Figure 2 depicts a class diagram for the Student exam workflow. The classes are part of use cases defined for student examination process. Class diagrams are expressions of patterns that a system is going to follow (Berardi, Calvanese, and De Giacomo, 2005). The Figure 2 class diagram depicts multiplicity, relationships along with candidate classes.
The use case model is followed by the class diagram where concrete classes are identified based on the identified use cases and a relationship between each of the classes is established. Figure 2 shows the classes and their respective relationships. The ‘Student’ class has a composition of ‘Course’ which has a further composition of ‘CourseModules’ class. The relationship between ‘Student’ class and ‘Course’ class is one-to-many which means that a student can have more than one courses. Similarly, a ‘Course’ class can have more than one ‘CourseModules’. The ‘CourseAssesment’ and ‘CourseExam’ classes are inherited from ‘Course’ class, so their relationship is of inheritance or a parent-child relationship. The ‘CourseExamScript’ class is further inherited from the ‘CourseExam’ class. The ‘ExamResult’ has a dependency relationship with the ‘CourseExamScript’ class and is depicted by a dotted line. Similarly, the ‘Student’ and ‘ExamCenterList’ have a dependency relationship as Student must choose an exam venue to proceed. The ‘StudentVerificationRecord’ class is inherited from the ‘ExamCenterList’ class and has an association with ‘Invigilator’ and ‘Student’ class through their respective primary keys (StudentId and InvigilatorId). The ‘ExamResults’ class has an association with ‘ExaminerMaster’ and ‘AdministratorMaster’ classes represented by straight lines linking each of the classes and also a presence of their primary keys.
Figure 2: Class Diagram
Figure 3: Sequence Diagram Student Examination Flow
Sequence Diagrams is by a revised meta-model adopting its useful features (Harel and Maoz, 2008). Figure 3 represents a sequence diagram that represents the workflow of the student enrolment, course assessment and examination process. The sequential flow of events that represent the complete process for a student to take the examination and subsequently view results along is depicted in the above diagram.
Figure 4: Sequence Diagram Invigilator Flow
Figure 4 represents a sequence diagram depicting the workflow of the invigilator at the exam center for student verification, student id record, and sending the exam script submitted by the student. The sequential flow of events that represent the verification and exam script submission process by the invigilator at the exam venue is depicted in the above diagram.
Scenario 2:
The objective is to implement a file system that consists of files and folders where the folder can have more than one files and even folders. The files and folders can be acted upon by different operations like renaming, creating, deleting or copying. The file system must be implemented as a tree structure with branches and nodes.
The most appropriate design pattern for this scenario is the composite design pattern. The composite design pattern composes objects into tree structure representing hierarchies and it allows to treat individual objects separately and also as a composition of uniform objects (Gamma, Helm, Johnson and Vlissides, 1994).
Figure 5: FileSystem Class Diagram
References
Berardi, D., Calvanese, D. and De Giacomo, G., 2005. Reasoning on UML class diagrams. Artificial Intelligence, 168(1), pp.70-118.
Eriksson, H.E. and Penker, M., 2000. Business modeling with UML.Business Patterns at Work, John Wiley & Sons, New York, USA.
Gamma, E., Helm, R., Johnson, R. and Vlissides, J., 1994. Design patterns: elements of reusable object-oriented software. Pearson Education.
Harel, D. and Maoz, S., 2008. Assert and negate revisited: Modal semantics for UML sequence diagrams. Software & Systems Modeling, 7(2), pp.237-252.
