STUdENT Refgistation

STUDENT COURSE REGISTRATION
1.0 PROBLEM DEFENITION
To build software that automates the students course registration.

1.1 This is proposed for automating the students course registration. While the
student joins any educational institution his admission is made on
the basis
of his previous records.

1.2 The students who wish to the institution must be given with the available
course details.
1.3 The student is allotted with a seat in the institution based on the marks that he
scored in the institution he studied previously. After the confirmation of his
joining the student must be given with new identity and records as per the
institution.
2.0 SYSTEM REQUIREMENT SPECIFICATION

2.1 THE OVERALL DESCRIPTION
2.1.1
This is proposed for automating the students course registration. While the
student joins any educational institution his admission is made on the basis
of his previous records.
2.1.2
The students who wish to the institution must be given with the available
course details.
2.2 PRODUCT PERSPECTIVE
2.2.1 Hardware interfaces

2.2.1.1 Hard disk: The database connectivity requires a hardware
configuration that is on-line. This makes it necessary to have a
fast database system running on high rpm hard disk permitting
complete data redundancy and back-up systems to support the
primary goal of reliability.
2.2.1.2 The system must interface with the standard output device,
keyboard and mouse to interact with this software.
2.2.2 Software interfaces
2.2.1.2.1 Back End: MS-Access
2.2.1.2.2 Front End: Microsoft Visual Basic 6.0
2.2.3 Memory Constraints
2.2.1.3.1 No specific constraints on memory.
2.3 FRONT END DESCRIPTION
The Student Course registration system is automated system where the user can
register the student for various courses.
2.4 BACK END DESCRIPTION
The Student Course registration system consists of two tables. One contains the
student details such as the name, id number that is the password, address, and date of
birth. The Course details consist of the title of the course, code of the course, available
seats.
2.5 DATA FLOW DIAGRAM:

Student
Art science
science
Course
Ug/pg.
engg
Ug/pg
ug
pg
register
Enquiries
Source code:
Source
code
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
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:
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
review, modify, and delete student information.
Maintain curriculum
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
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)
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)
Figure V: Course Detail Package Class Diagram (Tier 2)

The CourseCatalogue Super-Class makes up the Tier 2. It is made up of two offsprings, these
are CourseList and CourseInformation. All the Attributes exhibited by the Parent Class
(CourseCatalogue is directly inherited by the offsprings. 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)
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
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
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
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,
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.
2.8.0 STUDENT REGISTRATION ACTIVITY DIAGRAM WITHOUT SWIM-LANE
Figure VIII: Student Registration Activity Diagram without Swim-Lane

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
3.1.0 STUDENTS REGISTRATION SEQUENCE DIAGRAM
Figure IX: Students 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 students 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.
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 WORLDCLASSES

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.
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
6.0 RESULT:
Thus the online student course registration System was implemented using the specified
front end and back end tools.

STUdENT Refgistation

Uploaded by

Copyright:

Available Formats

STUdENT Refgistation

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

STUdENT Refgistation

Uploaded by

Copyright:

Available Formats

STUDENT COURSE REGISTRATION

1.0 PROBLEM DEFENITION

To build software that automates the students course registration.

of his previous records.

2.0 SYSTEM REQUIREMENT SPECIFICATION

2.2 PRODUCT PERSPECTIVE

2.2.1 Hardware interfaces

2.5 DATA FLOW DIAGRAM:

2.4.0 DRAWING USE CASE DIAGRAM USING ARGO UML

Figure II: Student Registration Use Case Diagram using ArgoUml

Register for courses

Maintain professor information

2.5.0 A THREE (3) TIER CLASS DIAGRAM

Figure III: A Three (3) Tier Class Diagram

2.5.1 STUDENT TYPE PACKAGE CLASS DIAGRAMS (TIER 1)

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

2.5.2 COURSE DETAIL PACKAGE CLASS DIAGRAM (TIER 2)

Figure V: Course Detail Package Class Diagram (Tier 2)

2.5.3 COURSE REGISTRATION PACKAGE CLASS DIAGRAM (TIER 3)

Figure VI: Course Registration Package Class Diagram (Tier 3)

Change Schedule - Delete a Course

2.7.0 STUDENT COURSE REGISTRATION ACTIVITY DIAGRAM WITH SWIM

4. Students Course registration details is then forwarded to the Bursar or Billing

2.8.0 STUDENT REGISTRATION ACTIVITY DIAGRAM WITHOUT SWIM-LANE

Figure VIII: Student Registration Activity Diagram without Swim-Lane

Figure IX: Students Registration Sequence Diagram

3.2.0 CREATING REAL WORLDCLASSES

CourseOffering: Specific information about selections for a semester (for example,

StudentSchedule: Output report containing the list of registered course offerings

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

StudentMaintenanceForm: Form which provides the capability for the registrar to

ProfessorMaintenanceForm: Form which provides the capability for the registrar to

CourseMaintenanceForm: Form which provides the capability for the registrar to

You might also like