BULE HORA UNIVERISTY

COLLEGE OF INFORMATICS
DEPARTMENT INFORMATION TECHNOLOGY
PROGRAM: SUMMER
PROPOSAL OF INDUSTRIAL PROJECT I
TITLE: ONLINE STUDENT REGISTRATION SYSTEM FOR SHASHAMANE
POLYTECHNIC COLLEGE

BY:   
NAME    ID NUMBER
1.    BAHIR EDEO                                                                                          0617\09
2.    MILKI DAME                                                                                        0640\09
3. MESERET HIRKISA   
4. DABASO KUTICHA    ADVISOR: JARA M. (MSC)
     0638\09                             
                                              0622\09

BULE HORA UNIVERSITY, ETHIOPIA

November, 2021
Contents
Chapter One: Introduction ............................................................................................................... 1

1.1 Background............................................................................................................................. 1
1.2 Statement of the Problem ........................................................................................................ 2
1.3 Objectives ................................................................................................................................ 3
1.3.1 General Objective of the System ..................................................................................... 3

1.3.2 Specific Objectives of the System ................................................................................... 3

1.4 Methodology ........................................................................................................................... 4

1.4.1 Data Collection Methods ................................................................................................. 4

1.4.2 System Development Methods ........................................................................................ 4

1.4.3 System Development Tools............................................................................................. 4

1.4.4 System Testing Methodology .......................................................................................... 5

1.5 Feasibility Analysis ................................................................................................................. 5

1.5.1 Operational/ Organizational Feasibility .......................................................................... 6

1.5.2 Technical Feasibility ....................................................................................................... 6

1.5.3 Economic Feasibility ....................................................................................................... 6

1.5.4 Ethical /Legal Feasibility................................................................................................. 7

1.6 Scope and Limitation of the Project ........................................................................................ 8

1.6.1 Scope of the Project ......................................................................................................... 8

1.6.2 Limitation of the project .................................................................................................. 8

 1.7 Significance of project ............................................................................................................ 8
1.8 Beneficiaries Groups ............................................................................................................... 9
1.8.1 Who will benefit from this System? ................................................................................ 9

1.9 Project Plan ............................................................................................................................. 9

1.9.1 Project Time Schedule..................................................................................................... 9

1.9.2 Cost Breakdown ............................................................................................................ 11

Chapter Two: System Analysis ..................................................................................................... 12

2.Introduction................................................................................................................................. 12
 2.1 Existing System ..................................................................................................................... 12
2.1.1 Description Existing System ......................................................................................... 12

2.1.2 Business Rules ............................................................................................................... 12

2.2 New System (Proposed System) ........................................................................................... 13

2.2.1 Functional Requirements ............................................................................................... 14

2.2.2 Non-functional Requirements and Constraints ............................................................. 14

2.3 Use case Diagram .................................................................................................................. 15

2.3.1 Use case Documentation/ Description .......................................................................... 16

2.4 Sequence Diagram ................................................................................................................. 22

2.5 State chart Diagram ............................................................................................................... 29
2.6 Activity Diagram ................................................................................................................... 49
2.7 CRC (Class Responsibility Collaboration) Diagram ............................................................ 58
2.8 Conceptual Modeling: Class Diagram .................................................................................. 59
2.9 User Interface Prototyping .................................................................................................... 60
Chapter Three System Design ....................................................................................................... 61

3 Introduction................................................................................................................................. 61

3.1 Purpose and Goals of Design ................................................................................................ 61

3.1.1. Overview of System Design ......................................................................................... 61

3.2 Design Class Modeling ......................................................................................................... 62

3.3 System Architecture .............................................................................................................. 63
3.3.1 Proposed Software Architecture .................................................................................... 63

3.4 System Decomposition .......................................................................................................... 64

3.4.1 Subsystem Decomposition ............................................................................................ 64
3.5 Class Collaboration Modeling ............................................................................................... 66
3.6 Layering Class Model ........................................................................................................... 67
3.7 Component Modeling ............................................................................................................ 69
3.8 Deployment Modeling ........................................................................................................... 69
3.9 Persistence Model ................................................................................................................. 72
3.10 Access Control and Security ............................................................................................... 73
3.11 User Interface Prototype Development ............................................................................... 73
Lists of Figures   
Figure 1 Use Case Diagram ........................................................................................................... 16
Figure 2 Login Sequence Diagram ................................................................................................ 22
Figure 3 Edit Profile Information Sequence Diagram ................................................................... 23
Figure 4 Manage User Sequence Diagram .................................................................................... 24
Figure 5 Remove User Sequence Diagram .................................................................................... 25
Figure 6 Add User Sequence Diagram .......................................................................................... 26
Figure 7 Change User Password Sequence Diagram ..................................................................... 27
Figure 8 Edit Student Profile sequence Diagram ........................................................................... 28
Figure 9 Remove Subject from Student Selection ......................................................................... 29
Figure 10 Create New Subject ....................................................................................................... 30
Figure 11 Edit Existing Subject ..................................................................................................... 31
Figure 12 Delete Subject Sequence Diagram ................................................................................ 32
Figure 13 Generate Report Sequence Diagram .............................................................................. 33
Figure 14 Create New Subject list Sequence Diagram .................................................................. 34
Figure 15 Credit Adjustment Sequence Diagram .......................................................................... 35
Figure 16 Publish Time Table Sequence Diagram ........................................................................ 36
Figure 17 Update Time Table Sequence Diagram ......................................................................... 37
Figure 18 View Subject Sequence Diagram .................................................................................. 38
Figure 19 Select Subject Sequence Diagram ................................................................................. 39
Figure 20 Remove Subject from List Sequence Diagram .............................................................. 40
Figure 21 Registration Sequence Diagram .................................................................................... 41
Figure 22 Course Registration Sequence Diagram ........................................................................ 42
Figure 23 Add/Drop Sequence Diagram ........................................................................................ 43
Figure 24 Department Registration Sequence Diagram................................................................. 44
Figure 25 Withdrawal Sequence Diagram ..................................................................................... 45
Figure 26 Login State Chart Diagram ............................................................................................ 46
Figure 27 Registration State Diagram ............................................................................................ 47
Figure 28 Create Account State Diagram ...................................................................................... 48
Figure 29 Activity diagram for Registration .................................................................................. 49
Figure 30 Activity Diagram for Create Account ........................................................................... 50
Figure 31 Login Activity Diagram ................................................................................................. 51
Figure 32 Delete Activity Diagram ................................................................................................ 52
Figure 33 Update profile Activity    Diagram .................................................................................. 53
Figure 34 View Profile Activity Diagram ...................................................................................... 54
Figure 35 Activity diagram for Search .......................................................................................... 55
Figure 36 Activity diagram for Approve ....................................................................................... 56
Figure 37 Activity diagram for Generate Report ........................................................................... 57
Figure 38 Activity diagram for Request ........................................................................................ 58
Figure 39 Conceptual Class Diagram ............................................................................................ 60
Figure 40 Design Class modelling ................................................................................................. 62
Figure 41 Proposed System Architecture ....................................................................................... 63
Figure 42 System Decomposition Diagram ................................................................................... 66
Figure 43 Login Collaboration Diagram ........................................................................................ 67
Figure 44 Layering Class Diagram ................................................................................................ 68
Figure 45 Component Diagram ...................................................................................................... 69
Figure 46 Deployment Diagram .................................................................................................... 71
Figure 47 Persistence Diagram ...................................................................................................... 72
Figure 48 Home Page User Interface ............................................................................................. 74
Figure 49 Student Registration page interface. .............................................................................. 75
Lists of Tables   

Table 1 Work Breakdown Schedule .............................................................................................. 10

Table 2 Hardware Requirement Cost ............................................................................................. 11
Table 3 Software Requirement Cost .............................................................................................. 11
Table 4 Use case description for Create Account. ......................................................................... 17
Table 5 Use case description for login. .......................................................................................... 17
Table 6 Use case description for Registration. .............................................................................. 18
Table 7 Use case description for Delete ......................................................................................... 18
Table 8 Use case description for Update. ...................................................................................... 19
Table 9 Use case description for View Profile .............................................................................. 19
Table 10 Use case description for Search. ..................................................................................... 20
Table 11 Use case description for Approve ................................................................................... 21
Table 12 Use case description for Generate Report. ...................................................................... 21
Table 13 Use case description for Request .................................................................................... 22
Table 14 Access Control and Security ........................................................................................... 73
Chapter One: Introduction   
1.1 Background   
Information and Communications Technology (ICT) systems have taken a vigorous trend
especially in schools, institutions, businesses; health centers such as hospitals as a standard for
solving issues more effectively and efficiently that are done by humans for example issues to do
with loads of paper work and others. ICT systems have successfully been used in schools
especially in universities in the accounting departments in order to track the financial statuses of
Students, amounts paid, balances and other dues from the university.     

In schools and institutions, ICT systems are time saving for example during admission, they can
enable a huge amount of students to register online at the same time without any interferences.
They have enabled to reduce human errors since they always operate as they were programmed
depending on the duty which was assigned to them.   

Several registration systems are used in universities and colleges, some of them support the online
registration features and some do not. Some of these    systems were    purchased by    local or
international software companies each in the relevant university or college.   

Today’s business environment is very    dynamic    and undergoes rapid changes as a    result    of
technological innovation, increased awareness    and demands from customers. Business
organizations, especially the banking industry operates in a complex and competitive environment
characterized by these changing conditions and highly unpredictable economic climate. ICT is at
the center of this global change curve.   

The    faculty    of    Information Technology    comprises of students who are    engaged    in Computer
Science    and Information Technology. The procedure for registration of both new students and
continuing students has been bureaucratic, hectic and time consuming as a result of the manual
method of registering students that was being used. As a result of this, a lot more time has been
consumed by students making queues at the dean of faculty office in order to obtain registration
forms which have to be handed back to the dean which eventually causes a workload to the staff   
in charge of collecting those forms and keeping the records intact.   

With an automated registration system this will enable both the new and continuing students of the
faculty of Information Technology at SHASHAMANE POLYTECHNIC COLLEGE to register
their personal information as required by the College, register the course units they are offering
1
during that particular semester, retakes where necessary, check the semester’s timetable, check for
results and all    this has to be    done    under the condition that a    student has cleared 60%    of that
semester`s dues.   

Our project explains about the Online Student Registration System. This project mainly explains
the various actions related to student details. This project shows some ease in adding, editing and
deleting the student details. It also provides a less time-consuming process for viewing, adding,
editing and deleting the marks of the students. Our project includes: Student Registration, Subject
Allocation, Branch selection, Semester wise selection, Examination marks entry and Displaying
branch and semester wise result.   

Online Student Registration System is software which is helpful for students as well as the school
authorities. In the current system all the activities are done manually. It is very time consuming
and costly. Our Online Student Registration System deals with the various activities related to the
students. There are mainly 3 modules in this software: User module, Student Module and Mark
management Module.   

In the Software we can register as a user and user has of two types, student and administrator.
Administrator has the power to add new user and can edit and delete a user. A student can register
as user and can add edit and delete his profile. The administrator can add edit and delete marks for
the student. All the users can see the marks.   

1.2 Statement of the Problem   

System Analysis is a detailed study of the various operations performed by a system and their
relationships within and outside of the system. Here the key question is- what all problems exist
in the present system? What must be done to solve the problem? Analysis begins when a user or
manager begins a study of the program using existing system. During analysis, data collected on
the various files, decision points and transactions handled by the present system. The commonly
used tools in the system are Data Flow Diagram, interviews, etc. Training, experience and common
sense are required for collection of relevant information needed to develop the system. The success
of the system depends largely on how clearly the problem is defined, thoroughly investigated and
properly carried out through the choice of solution. A good analysis model should provide not only

2
the mechanisms of problem understanding but also the frame work of the solution. Thus, it should
be studied thoroughly by collecting data about the system. Then the proposed system should be
analyzed thoroughly in accordance with the needs.   
System analysis    can be    categorized into four    parts. System planning    and initial    investigation,
Information Gathering, Applying analysis tools for structured analysis, Feasibility study and Cost/
Benefit analysis.   

In the current system we need to keep a number of records related to the student and want to enter
the details of the student and the marks manually. In this system only, the teacher or the school
authority views the mark of the student and they want to enter the details of the student. This is
time consuming and has much cost.   

1.3 Objectives     
1.3.1 General Objective of the System       
The general objective of this project is to develop Web based system that is reliable, secured, and
easily    manageable Online    Student Registration System for SHASHAMANE    POLYTECHNIC
COLLEGE.     

1.3.2 Specific Objectives of the System       

In order to achieve the general objective stated above the team identified the following specific
objectives.     

 To Register student     
 To allow students to fill add and drop     
 To enable withdrawal   
 To enable readmission   
 To select field or subject   
 To enable student to view their result     
 To add new subject or course       
 To authenticate students       
 To notify students   
 To allocate course   
 To display semester wise result   

3
1.4 Methodology     
1.4.1 Data Collection Methods     
To collect relevant information so as to understand the existing system and also to identify the new
system requirements the project team will made excessive effort by interviewing, Observing and
document revising, but the deepest takes brainstorming    (since    it    help to make    the part of the
Solution).         

Interview:    This is one    of data collection method    that enables to gather information from the
organization directly in the form of asking question and getting answers for those questions. So,
we    will    use    this    method to gather information by    asking    student and    employer some basic
questions.   
Observation: This is also another data collecting method. In fact, we    will use this observation
method to gather data.    This method will enable us observing and understanding how the current
student registration system is work.   
1.4.2 System Development Methods   
For this system we    will    use    Object Oriented System Analysis    and Development methodology
(OOSAD) which have two phases:   

Object Oriented Analysis (OOA): During this phase the team will use to analyze the function of
the system, find and identify    the business objects, organize    them and identify    the relationship
between them and finally has modeled the behavior of the objects.     

Object Oriented Design (OOD): During this phase the team will use to refine the analyzed object into
design that reflects the implementation environment, model object interactions and behaviors
that support the analysis scenario and finally update object models.   

1.4.3 System Development Tools   

Software: - for this project the team will use the following development software’s:
 Notepad++  for editing code   
 CSS  for system layout   
 PHP  for backend (server-side coding)   
 HTML  for client-side coding   
 MYSQL  as DBMS   

4
  Apache  as a Web Server   
 Mozilla Firefox, IE, Google Chrome, Opera  as a Web Browser     
 MS Office word  for Documentation   
 MS Office Power Point  for Presentation   

Hardware: - the following are required peripherals for this system:   

 External Hard disk- 500GB   
 DVD-RW   
 Flash Drive 32GB   
 Printer   
 Desktop computer     
 Deployment Server   
 Transmission media (cable)   
1.4.4 System Testing Methodology   
In order to deliver this system as well operated system we will test this project at implementation
phase by using different types of testing methodologies. Those testing methods are   

I. Unit testing: -we are going to test the independent module using this mechanism of
testing.   
Integration testing: - using this type of testing method we are going to test the modules
II. which are independent and dependent to each other.   
III. System    Testing: -using    this method we    will    test the functionality    of all    modules
considering as a single system.   
1.5 Feasibility Analysis       
Whatever we think need not be feasible. It is wise to think about the feasibility of any problem we
undertake. Feasibility    is the study    of impact,    which happens in the organization by    the
development of a    system. The    impact can be    either positive    or negative. When the positives
nominate the negatives, then the system is considerably feasible. Here the feasibility study can be
performed in five    ways such as technical feasibility, Economical Feasibility    and Operational/
Organizational Feasibility.     
5
1.5.1 Operational/ Organizational Feasibility     
Our proposed automated system may take time to be fully operational but consistent support from
the development team and the training of users will surely deliver a system that will solve the
current system problems and take benefit of different prospect. It might not be possible to see fully
operational system within the given limit of time for System development. However, with great
cooperation of the project teams the system can developed and address over all problems of the
current manual/file system in Shashamane Polytechnic College.     

1.5.2 Technical Feasibility     

The new system doesn’t need any ideal technology in order to operate properly. Such systems have
been tried and succeed in many national and international organizations. We can strongly say that
it is technically feasible, since there will not be much difficulty in getting required resources for
the development and maintaining the system as well.     

            We can strongly say that it is technically feasible, since there will not be much difficulty in
getting    required    resources for    the    development    and maintaining    the system as well. All the
resources needed for the development of the system as well as the maintenance of the same is
available in the organization here we are utilizing the resources which are available already.   
Therefore, we can be concluding that the system is technically feasible.   

1.5.3 Economic Feasibility     

          Development of this application is highly economically feasible. The only thing is to be done
is making an environment for the development with an effective supervision. If we are doing so,
we can attain the maximum usability of the corresponding resources. Even after the development,
the organization will not be in condition to invest more in the organization.     

BENEFITS

A. Tangible benefit: is a benefit that can easily be known or visible. Our system will provide
tangible benefits such as increasing the online student registration activities.     
Tangible benefits will fit the following classes:     

 Improve providing service for the Students, instructors.     

 Decrease the activities that cause problem or errors by validating input before inserted to
database.     
 Improvement of management in the Shashamane Polytechnic College registrar.     

6
  Used to promote the services provided by the Shashamane Polytechnic College Registrar
online.                     
B. Intangible benefits: - refers to items that cannot easily be measured in terms of money and
with certainty. It cannot be determined the exact amount of money consumed.     
Intangible benefits are as follow:     

 It minimizes the work load of the instructors, employees of the Shashamane Polytechnic
College Registrar   
 Improvement of employee moral because it is easy to work huge amount of job in short
period of time.     
 Improve    accuracy    in critical operations means it is easy    to load information of many
number of students, instructors and staff without error (accurately)     
 Improve management mechanism between the Shashamane Polytechnic College Registrar
and students, instructors, staffs.     
Intangible    costs    are    consequent from the design    of an automated system that cannot be    easily
considered as cost.       

 Time requires for adapting new system.     

 Requiting or train staffs who operates the new system.     
 Organizing the office with the new organization that may the new system requires.     
Therefore, we can surely say that the system is economically feasible.         

1.5.4 Ethical /Legal Feasibility     

Ethical feasibility is a test to determine if the project is ethical, or even legal. Ethical feasibility
should be tested from both the organizational perspective, as well as the developer’s perspective.
The    organization has a    vested interested to develop applications that show they    are    both
professional and ethical. Ethics can also affect the way developers work, how they feel about the
project, and how they interact with other developers throughout the development process of the
project. And also, the project we will develop considers the copy right and legal that protects us
from using the resource of another person as our own. Therefore, our project keeps all legal and
ethical of the country and the society.   
7
1.6 Scope and Limitation of the Project       
1.6.1 Scope of the Project       
The    Scope    of the    System is to automate    the    working    environment of the    Registrar    Office    of
Shashamane Polytechnic College activities.

The system includes       

 Automate student registration system     

 Giving detailed information about students.     
 Detail information about subject, student and Department.     
 Search information by inserting texts and then displays the desired information.     
 Generating    reports about, passed and failed students, Withdrawals list, Transcripts,
Temporary    Certificates, Registration and graduate, Admission, Readmission, Document
Registration, Statistics, top point list, and so on       
 Handling of exceptional cases when rules change.       
In another way, the scope of the System is limited to Shashamane Polytechnic College.     

1.6.2 Limitation of the project       

The System doesn’t include any other functional part of the Colleges/Institutes. The system is only
limited to Online Student Registration.       

1.7 Significance of project       

The system that we are going to develop will have direct social value by its impact on facilitating
the working activities of Registrar Office.       

 It will provide efficient working environment to the Registrar Office.     

 It will facilitate preparation of timely and reliable reports, and also minimize delays and
error in preparing documents.       
 The system will initiate other part of the Colleges/Institutes to have modern computerized
information system that cope up with the Office of the Registrar New System.       
 The College/Institute will have good working environment that can attract skilled labor
force and to process good teaching and learning.       
 It replaces paper work   
 Solve problem of data redundancy and typical error   
 Easy and safe record management   

8
1.8 Beneficiaries Groups   
1.8.1 Who will benefit from this System?       
Shashamane    Polytechnic    College    /Institute    will    be    the major    beneficiary    of the    System, The
Ministry of Education, Regional Bureau of Education and Zone Education Department will be
benefited from the system indirectly.    Students, teachers, department and other workers those who
have direct or indirect interaction with student registration will be benefited from this system.   

1.9 Project Plan   

1.9.1 Project Time Schedule     
Concerning the project schedule, it will be based on strict timing so it must be delivered within the
time bound given over the table. Our intention is to finalize it hopefully implement it and start
operation in the real environment before the end of this academic year. And while we define the
specific objective, the task may not accomplish during the stated schedule due to many risks. We
will try to resist problems as much as we can or amend the schedule if possible and finish our
project as scheduled. The system will be above 90% feasible to be delivered on time if all the risks
are minimized.   
9
                                                                                     Time
given for the task

Task to
be
performe
d Sep Feb Mar App Ma
        Oct         Nov       Dec Jan

Impleme
ntati on

Selection
of the
project Testing
title

Understa
ndi
ng      the
existing   
system
Require
ment
gatherin
g and
analysis
Analysis,
system
and
Interface
design
 WWWWWWWWWWWWWWWWWWWWWWWW
W W W W W1      2    3    4      1    2      3    4    1      2      3    4      1    2      3    4      1    2    3      4    1    2      3    4      1    2    3      4
W W W W W1      2      3    4      1    2   

Table 1 Work Breakdown Schedule

10
 1.9.2 Cost Breakdown   
1) Cost of the project
A. Hardware Requirements cost   
No      Materials Required   

Amount    Price Per Unit    Total Cost   

1    Toshiba Computer    2    12000    24000   
2    Pen    10    4    40   
3    A4 Size Paper    1 Destin    110    110   
4    Print      100    1    100   
5    Flash Disk    1(8G)    120    120   
6    CD-ROM    2    7    14   
Total
24384   
Table 2 Hardware Requirement Cost
B. Software Requirements Cost     
No      Materials Required    Price Per Unit   
1    Microsoft Word 2013    Free     
2    Notepad++    Free   
3    Microsoft Office Visio 2007    Free   
4    SQL Server    120   
5    Mozilla Firefox    Free     
Total                                                                                                                                                      120   
Table 3 Software Requirement Cost
11
 Chapter Two: System Analysis

2.Introduction   
This chapter    deals with analysing    the proposed    system by    using    different UML    analysis    modelling
techniques such as use case diagrams, the use case descriptions (scenarios), sequence diagrams, activity
diagrams, analysis class diagram, and user interface prototype

After identifying the actors and use cases, the use cases are developed and textual descriptions (scenarios)
are stated. The Sequence diagram id depicted based on the use cases which are developed for the proposed
system. Activities will be represented by the activity diagrams.

2.1 Existing System

2.1.1 Description Existing System   
The current system of the Student Registration system performs different tasks. The most popular tasks
that can be performed in the current system of the Student Registration System are: Students registration,
subject allocation, branch selection, semester    wise    selection, examination mark entry, displaying
semester wise result and generating report. This task utilizes considerable number of employees and also
it is manual. In this case, the students have to go to the Registrar office and check their result and register
manually. Then, the employee checks the Student ID and allows the member to check out the students
results and information the employer then updates the student result    based on the teacher result    that
summited to the office. This takes at least thirty minutes to one hour to get the service. In this system
data manipulation, redundancy, error, data loss and resources extravagating are significant problem.     

2.1.2 Business Rules

A business rule is effectively an operating principle or policy the software must satisfy.    It often pertains
to access control issues,    business calculations, or operating    polices and    a    principle    of the registrar.
Therefore, our new system has the following business rules.   
BR#1: student must register. To be register they must fulfill the criteria of registration
BR#2: The student should fulfill the following requirements if they want to be register for level   
 A student who want to learn in the college.
 Student who take grade 10 ECGE   
 should have valid transcript in grade 10.
BR#3:    The    student should fulfill the following    requirements if they    want to be    register for    degree
program   

12
  a student who want to learn in the college.
 Student must complete all level training
 Student must pass all level COC competency
 If Student have degree in other department they must bring their degree official.
BR#4: A student can have one or many Methods of Payment.
BR#5: Only students who pay can be registered

2.2 New System (Proposed System)

The    Online Student Registration System deals mainly    with hardware    devices and installed software
components on devices. The System performs many tasks. It consists of web-based system used by Super
Users, Administrators and Students of the college.    The system helps to record students’ personal details,
publish time table, preview student result, select subjects for the semester. Therefore, the web-based part
is expected to run on various operating system platforms. The client server architecture of the system
requires to remotely connecting with client and server through the internet connection.   

The system has two nodes such as the Web server and Clients. The nodes can represent specific instances
(workstations) or a class of computers (web server), which is a virtual machine. The applications of the
system will    run on the    web server connected    to the database    server. Internet is the worldwide
interconnection of all smart communication devices that have a valid IP.   

There should be installed browser software to access internet. If the user accesses the system, directly
through the internet connection the user has to install dongle or modem or relevant device and Wi-Fi or
etc.… to connect with the system. If the user accesses the system through the intranet connection, the
server should install the relevant software. Most of intranet accessing modes refer to the website of the
organization which can only be accessed by its employees who have a user name and password.   

So, considering that type of security purposes, it is better to access this Student Registration through the
intranet, but it should be accessed through the internet directly also. When generating reports such as
students’ result and subject’s details there should be installed the crystal report software. And also, to
print the generated reports the user machine should be installed the software relevant to its connected
printer.
13
Our proposed system has several advantages

 User friendly interface

 Fast access to database
 Less error
 Centralized database
 Search facility
 Look and Feel Environment
 Quick transaction

All the manual difficulties in managing the student details in a college have been rectified by
implementing computerization.

2.2.1 Functional Requirements

The functional requirements of the system are concerned about the major activities that the system has to
perform. The functional requirement describes the major functionality of the system which is generalized
as the reasons for the existence of the system from the user point of view. It addresses the specific function
that the proposed system will    perform and is dedicated to describe    the    possible interaction between
Student Registration System (SRS) and the environment. The new system is required to help the Office
of the Registrar in different manner and aspects. The basic functions that the system should carry out are:   
The    system should retrieve    stored data according    to the specific    Query.    The    system should register
students, courses and other related Academic and Training data. The system should generate necessary
information that the Office of the Registrar need. The system should provide more than one ways to
search. Generate the desired reports.
2.2.2 Non-functional Requirements and Constraints   
The    non-functional requirement deals with    the user-visible aspect of    the system    that
is not directly related with the functional requirement. It also deals with the quality of the application
system needed from different evaluation point of view and quantitative constraints like the response time
of the application to give user queries, the user friendly of the application, accuracy and other.   
The non-functional requirement of the proposed system refers to user visible aspect. Some of them are:
besides the functional requirements, our system possesses other nonfunctional requirements that reflect
the quality    of    the system such as accuracy, reliability, performance,    no redundancy, availability,
efficiency, user friendly and security.
14
Accuracy: The level of accuracy in the proposed system will be better due to reduction of error. All
operation can be done correctly and it ensures that whatever information is coming from the data base is
accurate.
Reliability: The reliability of the proposed system will be better due to proper storage of information
when users access the application.
Performance: The system gives service 24 hours in a day with maximum response time.
No redundancy: In the proposed system can be avoided reputation of data anywhere in the database but
there    may    reputation is case    of data backup.    This would assure    economic use    of storage    space    and
consistency of the data stored in the database.
Availability: All data in the system will be available all the time.
Efficiency: The system must ensure allocation and use of services being requested for the patient by
using minimum memory storage, cost, time and human power.
User friendly interface: Users can easily input and retriever patient profile and history.
Security: The system has to be well protected unauthorized access.   
 Encrypted Password.
 Administrator has more rights than the sub user.
2.3 Use case Diagram
Use    case    diagram show the functionality    of your    system using    use    case    diagram and how the actors
interact with the system. Also show use case reusability by including <<include>>, <<extend>>, and
<<inherit>> relationships between use cases.   
15
Figure 1 Use Case Diagram
2.3.1 Use case Documentation/ Description   
This is step by step description of the actions performed by each use case. It should contain preconditions,
post conditions, main course of action, and alternate course of action.
1. Use case description for Create Account.
Use case name Create Account
Actor(s) Admin
Pre-condition The Actors is not create account.
Post-condition The Actors should be create account.
Description When the Actors enter user name and password, it stores the input
information in to the database.   
Typical course of action:    Actor Action System Response

16
UCI 01
-

D
 Step1: This use case is initiated Step2: The system displays
when the actors clicks on the create the create account page.
account option Step4: The systems checks
Step3: The actor enter the required the information is correct or
information. not.   

Alternative course of Step5: If the actor does not fill the required information then the
action: system display error message and return to step 2.
Table 4 Use case description for Create Account.
2. Use case description for login.
Use case name Login
Actor Student, Admin
Pre-condition The Actor is    not      login the system
Post-condition The Actor should be login in to the system
Description When the students enter id and password, it checks the inputs from
the database. If it is valid, it allows the user to access and if not it
display authorization message.
Typical course of action:    Actor Action System Response

Step1: This use case is initiated Step2: The system displays

when the actors clicks on the login log in form
option Step4: The systems checks
Step3: The actor enter the id and authorization. If she/he is
password authorized system displays
the main page if not display
unauthorized message.
Alternative course of Step5: If the actor does not fill the id and password then the
action: system display error message and return to step 2.
Table 5 Use case description for login.

3. Use case description for Registration.

Use case name Pre-condition
Actors Post-condition
 Description Registration
Students
The Actors not    to register
The users registers to the system
This use case allows users to register in to the system
Typical course of action:    Actor Action System Response
UCI 02
-

17
UCI 03
-

D
 Step1: The user wants to register Step2: The system displays
in to the system.             
Step3: The user enters the Step4: The system validates
necessary information in to the whether the information
form in registration page. submitted is correct or not.               
Step5: The system register and
displays registration
confirmation page and leads to
home page.
Alternative course of Step5: If the actor does not fill the id and password then the
action: Step6: The use case ends
Alternative course of system display error message and return to step 2.
action If the input information invalid or empty
Step4.2: The use case continues Step2 of the basic course of
action.
Table 6 Use case description for Registration.

4. Use case description for Delete.

Use case name Delete
Actor(s) Administrator
Pre-condition The Actors are not authorized and login in to the system
Post-condition The administrator delete the record from the database.
Description The use case allows the administrator to delete record of students
from database.
Typical course of action:    Actor Action System Response

Step1: This use    case    is    initiated Step2: The system displays
when the actor on delete option the delete form page.
Step3: The    actors enter    the id for delete
 data from the data base. Step4: The system verifies
whether the existence of the
data base.
Step5: The system displays
confirmation message.

Alternative course of If the input information invalid or empty

action
Step4.2: The use case continues Step2 of the basic course of
action.
Table 7 Use case description for Delete
5. Use case description for Update.
Use case name Update profile

18
UCI 04
-

D
U

05
C

-
I
 Actor(s) Students Admin
Pre-condition The Actors cannot be Update profile
Post-condition The Actors will have update their account information
Description This use case allows users to update the user account.
Typical course of action:    Actor Action System Response

Step1: The actors can request to update Step2: The system

his/her information. The    system will displays user account
display the current customer update page.
information to the users.
Step3: The    user    enters    the necessary validates information is
information to update.
Step5: The system
displays confirmation
page and save the update
information of user.

Alternative course of If the input information invalid or empty

action
Step4.2: The use case continues Step2 of the basic course of
action.
Table 8 Use case description for Update.
6. Use case description for View Profile
Use case name View Profile
Actor(s) Students
Pre-condition The Actors not seen profile.
Post-condition The Actors has been viewed his/her profile.
Description This use case allows users request to view his/her profile.
Typical course of action: Actor Action System Response

Step2: The system displays view

Step1: The actors wants to option page.
 View his/her profile.                                    Step4: The system process
Step3: The actor selects the selection.                                                         
view profile option. Step5: The system displays the
actor profile.
Step6: The use case ends.
Alternative course of
action If the input information invalid or empty

Step4.2: The use case continues Step2.

Table 9 Use case description for View Profile

19
UCI 06
-

D
 7. Use case description for Search.
Use case name Search
Actor(s) Administrator
Pre-condition The actors cannot search.
Post-condition The Actors has been searched the selected record.
Description This actors requests to search someone’s information.
Typical course of action: Actor Action System Response

Step2: The system displays user view

Step1: The actors wants option.                                                                                             
to search some record. Step4: The system process the
Step3: The user enters selection.                                                                                       
the information to Step5: The system displays the
search from database selected record.
option. Step6: The use case ends.

Alternative course of If the input information invalid or empty

action
Step4.2: The use case continues Step2 of the basic course of
action.
Table 10 Use case description for Search.

8. Use case description for Approve.

Use case name Description
Actor(s)
Pre-condition
Post-condition
Approve The actors should be approved the information.
Admin    The actor to be approve if they get request some information
The actors cannot Approve. from different corners.
Typical course of Actor Action System Response
action:
Step2: The    system displays the
Step1: The actor wants to approve option.
submit.                                                                                    Step4: The    system process the
Step3: The user selects the selections.
approve option. Step5: The    system    displays
UCI 07
-

Step6: The use case ends.

D

20
UCI 08
-

D
 Alternative course of If the input information invalid or empty
action
Step4.2: The use case continues Step2 of the basic course of action.
Table 11 Use case description for Approve
9. Use case description for Generate Report.
Use case name Generate Report
Actor(s) Admin
Pre-condition The actor cannot be Generate Report.
Post-condition The Actors should be generate the report.
Description The actor wants to report how many students are clear from the
university.
Typical course of Actor Action System Response
action:
Step1: The    actor wants to Step2: The    system displays the
generate report. report
Step3: The    user selects the Step4: The    system process the
generate report option. selections.                                                       
Step5: The    system display    the all
information’s of the students.   
Step6: The use case ends.

Alternative course of If the input information invalid or empty

action
Step4.2: The use case continues Step2 of the basic course of action.
Table 12 Use case description for Generate Report.

10. Use case description for Request.

Use case name Pre-condition
Actor(s) Post-condition
 Description Request
Student
The actor cannot Request the information.
The Actors will be Request.
The actor wants to request what they want.
Typical course of Actor Action System Response
action:
Step1: The    actor wants to Step2: The system displays the
request.                                                                                      request option.
Step3: The    user selects the Step4: The system process the
request option. selections action.                                                       
Step5: The system send
UCI 09

information’s to the other page.                           

-

Step6: The use case ends.

D

21
UCI 10
-

D
 Alternative course of If the input information invalid or empty
action
Step4.2 The use case continues Step2 of the basic course of action.
Table 13 Use case description for Request
2.4 Sequence Diagram
Sequence    diagrams show the interaction between participating    objects in a    given use    case. They    are
helpful to identify the missing objects that are not identified in the analysis object model.

Sequence diagram for login.

Figure 2 Login Sequence Diagram

22
Figure 3 Edit
Profile
Information
Sequence
Diagram
23
Figure 4
Manage User
Sequence
Diagram
24
Figure 5
Remove User
Sequence
Diagram
25
Figure 6 Add
User
Sequence
Diagram
26
Figure 7
Change User
Password
Sequence
Diagram
27
Figure 8 Edit
Student
Profile
sequence
Diagram
28
Figure 9
Remove
Subject from
Student
Selection
29
Figure 10
Create New
Subject
30
Figure 11
Edit Existing
Subject
31
Figure 12
Delete
Subject
Sequence
Diagram
32
Figure 13
Generate
Report
Sequence
Diagram
33
Figure 14
Create New
Subject list
Sequence
Diagram
34
Figure 15
Credit
Adjustment
Sequence
Diagram
35
Figure 16
Publish Time
Table
Sequence
Diagram
36
Figure 17
Update Time
Table
Sequence
Diagram
37
Figure 18
View Subject
Sequence
Diagram
38
Figure 19
Select Subject
Sequence
Diagram
39
Figure 20
Remove
Subject from
List Sequence
Diagram
40
Figure 21
Registration
Sequence
Diagram
41
Figure 22
Course
Registration
Sequence
Diagram
42
Figure 23
Add/Drop
Sequence
Diagram
43
Figure 24
Department
Registration
Sequence
Diagram
44
Figure 25
Withdrawal
Sequence
Diagram
2.5 State
chart
Diagram
A state chart
diagram
shows the
behaviour of
classes in
response to
external
stimuli. This
diagram
models the
dynamic flow
of control
from state to
state within a system.
45
Figure 26
Login State
Chart
Diagram
46
Figure 27
Registration
State
Diagram
47
Figure 28
Create
Account State
Diagram
48
2.6 Activity Diagram
Activity diagram used to emphasize the flow of control from activity to activity or to model the flow of
an object as it moves from state at different points in the flow of control.

1. Activity Diagram for Registration

Students

Registration    Form

Fill information
re-enter correct information

di
Selecte the "Registration" option sp
la
y
co
nf
ir
Incorrect m
System indicate wrong    information at
io
n
m
correct es
 sage

Figure 29 Activity diagram for Registration

49
Fi
Ac
D
C
Ac
50
Fi
Ac
51
Figure 32
Delete
Activity
Diagram
52
Fi
U
Ac
D
53
Figure 34
View Profile
Activity
Diagram
54
Fi
di
Se
55
Fi
Ac
fo
56
 di
re
co
n
    Admin

Fi
Ac
Generate Report Form di
G
Re

View report file

Selecte the "Report" option

57
Figure 38 Activity diagram for Request
2.7 CRC (Class Responsibility Collaboration) Diagram
A collaboration diagram    describes interactions among    objects of our system in terms of sequenced
messages. Collaboration diagrams represent a combination of information taken from class, sequence,
and use case diagrams describing both the static structure and dynamic behaviour of a system.

58
2.8 Conceptual Modeling: Class Diagram
 It represents the properties of entities, their operations and relationships. Also it drives use case
diagrams from use case.   
 The class diagram is the main building block in our project modelling.   
 It is used both for general conceptual modelling of the systematic of the application and for
detailed modelling translating the models into programming code.   
 The classes in a class diagram represent both the main objects and or interactions in the
application and the objects to be programmed.   
 Generally, the project is including the following class in the class diagram the over view of the
class diagram is: -

59
Figure 39 Conceptual Class Diagram
2.9 User Interface Prototyping
The Proposed system has several user interfaces to communicate easily with the User. Our team attempt
to illustrate this interface in general as follows: -

♠ The system user interface should be consistent with all other program.
♠ The caption and the test of user interface should be self-descriptive and clear to understand.
♠ The user interface should be easy to understand.
♠ The user interface should be customized.
♠ The user interface should be accompanied with help files that describe the usage of each user
interface.
♠ The user interface should be designed in the way that they can be extended easily to support
localization.

60
 Chapter Three System Design

3 Introduction
3.1 Purpose and Goals of Design
This is the second phase of our project entitled Online Student Registration System. In this phase we
are    going    to verify    brief    aspect of phase    one, and describe    the    phase    two parts; detail description of
chapter four which focused on Object-Oriented design and system containing class diagram, deployment
diagram, state diagram, and relational persistence modeling diagrams, and chapter five which focuses on
System implementation. In general, in this phase    we    will    describe    detail of our system design and
implementation.

3.1.1. Overview of System Design

After the determination of the requirements, it is the design that follows. The design is all about stating
the design goals of the system and subdividing the system into smaller parts so as to tackle the problem
in a modular approach. This phase includes description of each subsystems and the deployment of the
subsystems. Not only had these, the database related concepts such as relational schema as well as the
normalization of the database are also included. For database purpose, a class diagram is used instead of
ER diagram in the object oriented approach.

3.1.2. Design Goal al

The design goals are derived from the non-functional requirements of the system. They describe the
qualities of the system. These goals consider the following designing considerations.

Reliability: The    system should be    reliable. That means it    performs a    required function under stated
condition.
Error handle: The system should be able to give response (error message) when the    user enter incorrect
input. This recommends the user to enter correct input.   

Extensibility: The system should enable the addition of new functionality without any restriction. This
constraint enables the system to have the acceptance of users, for it does not restrict the future expansion
of the system.   
61
Portability: The system should work in different platforms, for there could be platform shifting in the
future and the work to have the acceptance of different institutes having the different platforms. It is
important to have this constraint attempted.   

Security: The system does not allow non-authorized users using a form based authentication. I.e. Access
limitation is the means of security for the system.   

Usability: The question of usability is considered as one of a determining factor for users’ acceptance of
a given system. Hence the system is easy to use with the user interface provided which have correct
audience with its action.

3.2 Design Class Modeling

Design Class Modeling is design level that introduces changes to analysis class model based on
implementation technologies. It focuses on the solution domain instead of the problem domain. It
shows static nature of how the software is built.
Figure 40 Design Class modelling
Class diagram

62
3.3 System Architecture
3.3.1 Proposed Software Architecture

Figure 41
Proposed
System
Architecture
63
3.4 System Decomposition
3.4.1 Subsystem Decomposition
Subsystems of the design and interrelationship between them: For the ease of understanding, we have
divided the system into sub systems or sub components. These are the administrative subsystem, the user
subsystem or the subsystem involved with the day to day activities of the system, the reporting subsystem
and finally the database subsystem.

 The administrative sub system   

This subsystem enables the administrator to manage user accounts and some sort of data manipulation.
The management includes creation of new accounts, removing the existing accounts, modification of the
information, removal of information and modification of accounts. The management of user account is
the responsibility of the account class. The account class is the one that creates displays and modify the
user account. This class has provided its service to interact with the admin class.
 The user/worker subsystem   
This subsystem enables the users of the system or workers of the bus station to perform different day to
day    tasks. The    tasks include registering    buses and associations, adjusting    turns or schedules, display
information to passengers, associations, and other workers, checking maintenance records for each bus,

64
assigning    tariffs to buses, and approve    membership requests    of associations. All of these    tasks    are
performed by users who will not be given full privilege to manipulate the entire system.   
 The reporting subsystem
Reports are generated when certain situations related with legal issues are raised by certain associations
or bus drivers. They are generated by the workers of the bus station to the manager. While criminal issues
occurred those are above the responsibilities of the bus station workers, they will report them in order for
the transport system manager to take the appropriate measures. Otherwise, reports will not be generated
for all routine tasks that could be undertaken by the workers.
 The database subsystem
Most of the permanent data involved under the bus station will be stored into the database. In addition to
this, different data can be retrieved for manipulation. Basically, there will be two different databases.
These databases will be:
 The original bus station database: this is the database that would store the necessary
information of employees, buses, associations and user account information’s.
 The backup database: this database is concerned with storing the data that are removed from
the original database. This is important since permanent deletion of data is not advised
The general structure is shown as the following diagram:
65
Figure 42 System Decomposition Diagram
3.5 Class Collaboration Modeling
A collaboration diagram    describes interactions among    objects of our system in terms of sequenced
messages. Collaboration diagrams represent a combination of information taken from class, sequence,
and use case diagrams describing both the static structure and dynamic behaviour of a system.

66
Figure 43 Login Collaboration Diagram

3.6 Layering Class Model

3.6.1 User Interface Layer: - This layer is the in which users used to access your system. There are two
categories of interface class-user interface (UI) classes that provide people access to external system to
tour system.

3.6.2 Domain Layer: - This Layer implements the concepts relevant to your business domain such as
student focusing on the data aspects of the business objects, plus behaviours specific to individual objects.
3.6.3 Process Layer: - This process layer implements business logic that involves collaborating with
several domain classes or even other process classes.

3.6.4 Persistence    Layer: - This layer encapsulates the capability to store, retrieve, and delete objects
without revealing details of the underlying storage technology.   

3.6.5 System Layer: -    System classes provide    operating    system specific    functionality    for    your
application, isolating your software from the operating system (OS) by wrapping OS specific feature,
increasing the portability of your application.   

67
Figure 44
Layering
Class
Diagram
68
3.7 Component Modeling
In this modelling the diagram describes the organization of the physical components in a system.
Figure 45 Component Diagram

3.8 Deployment Modeling

UML deployment diagram show physical view of system, taking software into real world by showing
how software gets assigned to hardware and how communicates. The deployment diagram shows how
the software components, processes, and objects are deployed into the physical architecture of the
system. It shows the configuration of the hardware units (e.g. Computers, communication devices, etc.)
and how the software components are distributed across the units.

Online Student Registration System is server client structure architecture, where clients access services
offered by server. The deployment diagram is shown as follows.   

69
Client Machine Central Data Base

:Chrome
:MYSQL
TCP/IP
Web Server
:Opera Admin

:X
:Mozilla AM
PP

:Torch

PHP
70
Figure 46
Deployment
Diagram

Description
of the
architecture
of the system
is described
as follows.

Clients are
responsible
for: -

Provide
user
interface
to the user
enabling
to get
services


Receiving
inputs
from user


Checking
range of
 performance
 Initiating database transactions once all necessary data are collected.
      Server responsible for: -
 Transaction performance
 Guaranteeing the integrity of data.
 Putting backup of the database
71
3.9 Persistence Model
The    relational    database    is    often    used    as    a    mechanism    to    make    your    objects    persistence    because
relational databases do    not support completely    object oriented    concepts persistence    models    are    also
called data models or entity relationship models are used to communicate the design of database to
both our user and other developers.
Figure 47 Persistence Diagram

72
3.10 Access Control and Security
The table below illustrates the different level of access that each actor has in this system
Actor    Use Case/Class

Login, Admission, Registration, Transcript,

Registrar    Exemption,
Certificate, Security

Record Officer    Login, Security

Employee    Login, FPR, Security
System
Administrator Login, Administrator, Security
Table 14 Access Control and Security

3.11 User Interface Prototype Development

User interface design is the specification of the interaction between the system users and a system. The
process involves input mechanism design, output mechanism design, and navigation mechanism.

 Navigation mechanism is part of user interface that takes the user form one part of the system
to the other user system.    That includes menus or links, buttons, icons, dialog boxes etc.
 Input design is about designing a form and its controls for GUI system.
 Output design is about designing reports like detailed, summarized, exceptional, graph, chart,
text document report and extra.
73
Figure 48
Home Page
User
Interface
74
Figure 49
Student
Registration
page
interface.
75