Professional Documents
Culture Documents
Bla Bla Nbla
Bla Bla Nbla
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: Students 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
CHAPTER THREE
3.1.0 Students 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
1.1.0 INTRODUCTION
2 | Page
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:
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.
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.
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.
Student
Register for courses.
Professor
Registrar
Maintain curriculum.
5 | Page
6 | Page
A brief description is created for each use case. These descriptions are shown below:
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 professor information.
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.
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.
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.
7 | Page
8 | Page
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.
9 | Page
11 | P a g e
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
12 | P a g e
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.
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.
14 | P a g e
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,
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 students registration.
15 | P a g e
16 | P a g e
17 | 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
18 | P a g e
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).
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.
20 | P a g e
Add/DropForm: Form which provides the capability for a student to modify a course
schedule.
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.
2.
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.
21 | 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.
22 | P a g e
Hunt J. (2000). The unified process for practitioners: object-oriented design, UML and
java london: Springer Publications
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
4 th
august
2010
from:
23 | P a g e