Student Course Registration System

Bangsar International College of Technology IT Infrastructure Upgrade

TABLE OF CONTENT List of Figures Figure I: New Bangsar International College Client-Server Architecture……………………….3 Figure II: Student Registration Use Case Diagram using ArgoUml…………………..…………6 Figure III: A Three (3) Tier Class Diagram………………………………………………….…..8 Figure IV: Student Type Package Class Diagrams (Tier 1)……………………………………..9 Figure V: Course Detail Package Class Diagram (Tier 2)……………………..……………….10 Figure VI: Course Registration Package Class Diagram (Tier 3)………………………………11 Figure VII: Student Course Registration Activity Diagram with Swim Lane………………….14 Figure VIII: Student Registration Activity Diagram without Swim-Lane……………..………16 Figure IX: Student’s Registration Sequence Diagram…………………………………….……18

CHAPTER ONE 1.1.0 Introduction……………………………………………………………………….....…….3 1.2.0 Problem statement………………………………………………………..……………….4 1.3.0 Tools used……………………………………………...………………………………….4

CHAPTER TWO 2.1.0 Analysis and design…………………………………………………….…………………5 2.2.0 Definition of actors…………………….……………...…………………………………..5 2.3.0 Definition of use cases…………………….…………………..…………………………..5 2.4.0 Drawing use case diagram using ArgoUML…………………...…………………………6 2.5.0 A three (3) tier class diagram…………………………………………….…….……….8 1|Page


2.5.1 Student type package class diagrams (tier 1)……………………………..….………...9 2.5.2 Course detail package class diagram (tier 2)………………………………………….10 2.5.3 Course registration package class diagram (tier 3)…………………………….……..11 2.6.0 Flow of events: course registration use case………………………………………….12 2.7.0 Student course registration activity diagram with swim lane……………..…………14 2.8.0 Student registration activity diagram without swim-lane……………………...…….16

CHAPTER THREE 3.1.0 Student’s registration sequence diagram…………………………….………..……..18 3.2.0 Creating “Real World” classes………………….……………………….……………19 3.3.0 Assumptions and problem encountered……………….…………………….………20 3.4.0 Conclusion……………………………………………….……………………………21 References………………………………………………………….………………………..22

CHAPTER ONE 2|Page


1.1.0 INTRODUCTION This project is aimed to design an online based course registration system for Bangsar International College of Technology. Prior to this project, Bangsar International College of Technology uses Oracle Relational Database, running on its old Legacy IBM Mainframe Server System to store/retrieve data. The institution recently decided to upgrade its IT resources to a much more recent technology applying the online Client-Server architecture, in order to save/store and retrieve data from its database. Since full funding of this project is an issue, the institution has decided to continue to use its Legacy IBM Mainframe Server and oracle Database at the back end and incorporating an open SQL at its front end interface. This architecture is shown in the diagram below:

Billing/Bursar System

Students System

Request Response Switch

Unix Server running Open SQL Interface

Request Response Professors’ System Registrars’ System

IBM Server running Oracle Relational Database

Figure I: New Bangsar International College Client-Server Architecture The database can be accessed and managed from any authorized client machine through the local intranet. This new system has helped to enhance the speed of retrieval of data from the database and hence improve quality of service. 3|Page


Prior to this initiative, Course registration at the college is done by hand. Students fill out forms that contain their course selections and return the forms to the registrar. Clerks then enter the selections into a database and a process is executed to create student schedules. The registration process takes from one to two weeks to complete. The university decided to investigate the use of an online registration system. This system would be used by professors to indicate the courses they would teach, by students to select courses, and by the registrar to complete the registration process.

1.2.0 PROBLEM STATEMENT At the beginning of each semester students may request a course catalogue containing a list of course offerings for the semester. Information about each course, such as professor, department, and prerequisites will be included to help students make informed decisions. The new on-line registration system will allow students to select four course offerings for the coming semester. In addition, each student will indicate two alternative choices in case a course offering becomes filled or canceled. No course offering will have more than ten students. No course offering will have fewer than three students. A course offering with fewer than three students will be canceled. Once the registration process is completed for a student, the registration system sends information to the billing system, so the student can be billed for the semester. This system is designed in such a way that Professors must be able to access the on-line system to indicate which courses they will be teaching. They will also need to see which students signed up for their course offering. For each semester, there is a period of time that students can change their schedules. Students must be able to access the on-line system during this time to add or drop courses. The billing system will credit all students for courses dropped during this period of time.

1.3.0 TOOLS USED The concept of Unified Modeling Language (UML) is adopted in modeling this project. The Open source ArgoUML is the modeling tool used for modeling the various UML diagrams. The ease of use of ArgoUML has made it a modeling tool of choice for this project. The next section will detail on the various UML modeling diagrams with explanations where necessary.

CHAPTER TWO 2.1.0 ANALYSIS AND DESIGN 4|Page


The first question to address is the need for a new registration system. Does the University have the resources needed to design and implement the new system? In addition to the assessment of need for the system, the risks posed by the new system are elaborated. In the case of an on-line registration system, one of the major risks is the ability to store the information in a manner that is easily and quickly accessible by all. This project tends to provide a one-time answer to the above questions. The next phase is to design Use Case Diagrams. 2.2.0 DEFINITION OF ACTORS The following actors will be used in the Use Case Diagrams and the various roles in which they play are explained.    

Student: someone who is registered to take courses at the College. Professor: someone who is licensed to teach at the College. Registrar: someone who is responsible for the maintenance of the Registration System. Billing System: external system that bills students with respect to course enrolled for per semester.

2.3.0 DEFINITION OF USE CASES The following use cases were elaborated for each actor, the Use cases are represented in bold types.  



Student  Register for courses. Professor  Select courses to teach.  Request course offering roster. Registrar  Generate course catalogue.  Maintain professor information.  Maintain student information.  Maintain curriculum.

2.4.0 DRAWING USE CASE DIAGRAM USING ARGO UML The Use Case diagram shown below illustrates the various actions taken by all of the four (4) Actors during registration of course by student(s). These include the registrations of course by 5|Page


the student(s) to request for class roaster by Professors to the Maintenance of both Prof. and student Information in the database. In the diagram, the Actors are presented as Stickmen while the Use Cases are presented in round Oval Shapes. This is show in figure II below:

Figure II: Student Registration Use Case Diagram using ArgoUml

A brief description is created for each use case. These descriptions are shown below: 6|Page

Bangsar International College of Technology IT Infrastructure Upgrade 













Register for courses  The use case is started by the student. It provides the capability to create, review, modify, and delete a course schedule for a specified semester. All pertinent billing information is sent to the Billing System. Request class roster  This use case is started by the professor. It provides the capability to request a printed list of all students assigned to a specified course offering. Select courses to teach  This use case is started by the professor. It provides the capability to select, review, modify, and delete a list of courses to teach for a specified semester. Maintain professor information  This use case is started by the registrar. It provides the capability to create, review, modify, and delete professor information. Maintain student information  This use case is started by the registrar. It provides the capability to create, review, modify, and delete student information. Maintain curriculum  This use case is started by the registrar. It provides the capability to create, review, modify, and delete a list of course offerings for a given semester. Generate catalogue  This use case is started by the registrar. It provides the capability to generate a catalogue containing a list of course offerings for a specified semester.

2.5.0 A THREE (3) TIER CLASS DIAGRAM As required, a Three (3) Tiered Class diagram Package is drawn to depict the functionality of various segmented Units in a yet well connected system. In a way to properly show the feature of 7|Page


this Three (3) this Class Diagram, the system is divided into Three (3) tiered system, these are the Student Information (Tier 1), Course Details (Tier 2) and Course Registration (Tier ).

Figure III: A Three (3) Tier Class Diagram

2.5.1 STUDENT TYPE PACKAGE CLASS DIAGRAMS (TIER 1)

8|Page


Figure IV: Student Type Package Class Diagrams (Tier 1)

The Student Type Package makes up Tier 1 and is sub-divided into three sub-groups; these are CertificateStudent, DiplomaStudent and DegreeStudent. All these three Sub-Classes directly inhereits the properties of their Super Class (StudentType), hence the Attribute of these classes are Student Name, Department, Identity, and Address. These are the common attributes that is inherited from the Super Class to the Sub-Classes. Subsequently Operations that can be performed on these Classes includes; Admit() and Reject(); this means that a student can either be admitted into the college or rejected.

2.5.2 COURSE DETAIL PACKAGE CLASS DIAGRAM (TIER 2) 9|Page


Figure V: Course Detail Package Class Diagram (Tier 2) The CourseCatalogue Super-Class makes up the Tier 2. It is made up of two offspring’s, these are CourseList and CourseInformation. All the Attributes exhibited by the Parent Class (CourseCatalogue is directly inherited by the offspring’s. For a student to register for a Course or courses, he/she has to browse through the online Course Catalogue. This catalogue has Course List which aids student to display the list of available courses and Course Information, which provides more information about a particular course.

2.5.3 COURSE REGISTRATION PACKAGE CLASS DIAGRAM (TIER 3) 10 | P a g e


Figure VI: Course Registration Package Class Diagram (Tier 3) The Course Registration Package is a much more complex Class diagram; it makes up the Tier 3. The Course Registration Package is made up of Course, CourseMaintenace, CourseSelection, RegistrationForm, Add/RemoveCourseForm, Student, Courseoffering, CourseRoaster and StudentSchedule Classes. Of all the Packages, this Package is much more important because this is where student course registration is carried out as well as add and removal or drop of course as necessary. The individual classes are all self-explanatory in the role they play in the entire system. 2.6.0 FLOW OF EVENTS: COURSE REGISTRATION USE CASE 11 | P a g e


This use case begins when the student enters the student id number. The system verifies that the student ID number is valid and prompts the student to select the current semester or a future semester. The student enters the desired semester. The system prompts the student to select the desired activity:   

Create a schedule. Review a schedule. Change a schedule:  Delete a course.  Add a course.

The student indicates that the activity is complete. The system will print the student schedule and notify the student that registration is complete. The system sends billing information for the student to the billing system for processing. Alternate flow If an invalid id number is entered, the system will not allow access to the registration system. If an attempt is made to create a schedule for a semester where a schedule already exists, the system will prompt for another choice to be made. Create a Schedule The student enters 4 primary course offering numbers and 2 alternate course offering numbers. The student then submits the request for courses. The system then: 1. Checks that prerequisites are satisfied for the requested course. 2. Adds the student to the course offering if the course offering is open. Alternate flow If a primary course offering is not available, the system will substitute an alternate course offering. Review a Schedule The student requests information on all course offerings in which the student is registered for a given semester. The system displays all courses for which the student is registered including course name, course number, course offering number, days of the week, time, location, and number of credit hours.

Change Schedule - Delete a Course 12 | P a g e


The student indicates which course offerings to delete. The system checks that the final date for changes has not been exceeded. The system deletes the student from the course offering. The system notifies the student that the request has been processed. Change Schedule - Add a Course The student indicates which course offerings to add. The system checks that the final date for changes has not been exceeded. The system then: 1. Verifies that the maximum course load for the student has not been exceeded. 2. Checks that prerequisites are satisfied for the requested course. 3. Adds the student to the course offering if the course offering is open.

2.7.0 STUDENT COURSE REGISTRATION ACTIVITY DIAGRAM WITH SWIM LANE

13 | P a g e


Figure VII: Student Course Registration Activity Diagram with Swim Lane

The Activity Diagram shown above details all the sequential steps a student will take to register for courses. As shown, this Activity diagram is modeled with a Swim-lane, each swim-lane has a particular operation that is peculiar to it.

The Activity diagram is made up of four (4) swim-lanes, these are; Student, Course Portal, Registrar and Bursar or Billing system. The operation carried out by a student registering a course is as explained below; 1. The student Login into the Colleges Student Web portal, on successful login he, 14 | P a g e


2. Browses through the Course Catalogue which presents him with various courses for the semester and for which he has to register about four (4) courses. Also in this phase, he has the privilege to Add/Drop courses. 3. On successful selection of four (4) courses, he proceeds to the registrar portal to

register selected Courses. The registered courses are approved in the phase. 4. Students Course registration details is then forwarded to the Bursar or Billing system which then generates and issues the student bill for the course offered for the semester. 5. On Successful payment the student becomes full qualified to attend classes for the

registered courses. This ends the student’s registration.

2.8.0 STUDENT REGISTRATION ACTIVITY DIAGRAM WITHOUT SWIM-LANE

15 | P a g e


Figure VIII: Student Registration Activity Diagram without Swim-Lane

16 | P a g e


In this section, again a similar Activity diagram is show, but this time it is modeled without swim-lanes, but the flow of event are logically represented and carried out. Just like in the Swimlane section all the steps necessary for a student to register for courses are the same hence reference can be made to the illustration for that of the Swim-lane for details.

CHAPTER THREE 17 | P a g e


3.1.0 STUDENT’S REGISTRATION SEQUENCE DIAGRAM

Figure IX: Student’s Registration Sequence Diagram The above Sequence Diagram shows all sequential steps involved in registering courses by students of Bangsar College of technology. The steps involved in doing this as regards this Sequence Diagram are detailed below; 1. The Registrar Opens Course Registration to student’s and this is made available as Registration Form. 2. The students visits the web Registration Portal to Pick and fill up course registration form

3. After filling up course form, they apply for courses through the Registration Manager. 4. The Registration Manager Forwards the List of Registered students to both the Registrar and Bursary or Billing System. 5. The Billing System the Prepares Bill for the registered Students. 18 | P a g e


6. The prepared bills are issued to the registered students. 7. In return the Registered Students Pay up bills. 8. On the conformation of bill payment, the students become qualified and can attend classes. 3.2.0 CREATING “REAL WORLD”CLASSES Objects are discovered by examining the use cases and scenarios and grouped into classes. Each class should have a definition which states the purpose of the class. Packages are created to hold logical groups of classes. Classes and packages are drawn in the Logical View of the tool. The following packages and classes have been created for the registration system: People •

StudentInfo: Information about the student actor needed by the registration system (for example, name, address, phone, idNumber, major, gradDate).

•

ProfessorInfo: Information about the professor actor needed by the registration system (for example, name, address, phone, idNumber, tenureStatus).

CollegeArtifacts •

Course: General information about selections for a semester (for example, name, description, creditHours).

•

CourseOffering: Specific information about selections for a semester (for example, daysOffered, timeOfDay, location).

•

StudentSchedule: Output report containing the list of registered course offerings generated when a student registers for a course.

•

CourseRoster: Output report containing the list of registered students for a specific course offering generated for a professor.

Interfaces •

RegistrationForm: Form which provides the capability for a student to select registration options.

19 | P a g e

Bangsar International College of Technology IT Infrastructure Upgrade •

Add/DropForm: Form which provides the capability for a student to modify a course schedule.

•

CourseSelectionForm: Form which provides the capability for a professor to add/drop courses to teach.

•

StudentMaintenanceForm: Form which provides the capability for the registrar to add/delete/modify student information.

•

ProfessorMaintenanceForm: Form which provides the capability for the registrar to add/delete/modify professor information.

•

CourseMaintenanceForm: Form which provides the capability for the registrar to add/delete/modify course and course offering information.

Class diagrams are created to graphically depict the packages and classes in the model. The Main class diagram typically contains only packages. Each package contains its own class diagrams. The Main class diagram for a package contains the public classes of the package (classes that communicate with classes in other packages). Other class diagrams are created as needed. Class diagrams are contained in the Logical View of the tool.

3.3.0 ASSUMPTIONS AND PROBLEM ENCOUNTERED In this project certain assumptions were made in order to achieve a close to real world scenario as much as possible. These assumptions include: 1. Human related classes: People 2. College related Classes: CollegeArtifacts 3. Interface related classes: Interfaces.

On the other hand the problems encountered during this project include: 1.

Difficulty in identifying the right UML tool

2.

Not being able to demonstrate this project practically

3.4.0 CONCLUSION Bangsar International College of Technology has being given a face lift in the aspect of its IT infrastructure and has joined its competitor in the modern world of IT development. This is in assumption that this project has being practically being implemented in the College. 20 | P a g e


It is worthwhile to conclude that this project has in many ways being educative. More knowledge were gained in the aspect of Client-server Architecture, UML Modeling, Object Oriented Concept and simulation of Real World scenarios, although assumptions were made in order to achieve a close to real world scenario. It is very important to point out that this project is in no way very perfect, hence it leave room for further research, improvement and development.

REFERENCES •

Graham I. (2001). Object-oriented: principles & practice 3rd ed. London: Addison Wesley.

21 | P a g e

Bangsar International College of Technology IT Infrastructure Upgrade •

Hunt J. (2000). The unified process for practitioners: object-oriented design, UML and java london: Springer Publications

•

Larman C. (2001). Applying UML and patterns: an introduction to object-oriented analysis and design and the unified process. 2nd ed. America: Pearson Education.

•

Maciaszek I.(2001). Requirements analysis and system design: developing information systems with UML. New York: Pearson Education.

•

Shalloway a. (2002). Design patterns explained: a new perspective on object-oriented design. London: Addison Wesley.

•

Sommerville I. (2000). Software engineering. : 6th ed. London: Addison Wesley

•

A rational approach to software development th using rational rose 4.0. Viewed and retrieved on 4 august, 2010 from: http://www.augustana.ab.ca/~mohrj/courses/2007.fall/csc220/papers/rational_approach_t o_software_development/rational_approach.htmlewed

•

Overview on UML. Viewed and http://www.globaltechpro.com/uml.pdf

retrieved

on

4th

august

2010

from:

22 | P a g e

Student Course Registration System

Recommend Documents