Registration Use Case

advertisement
CHAPTER ONE
1) Introduction
As there are many problems face human being throughout his/her life, it is obvious to solve these
problems using computers. This problem solving process using computer requires knowing
computer application, ability to develop software, having concept of program and applying
modern technology to solve problem.
The project we have prepared Haramaya University Online Student Registration System
(HUOSRS) is also aimed to solve some problems occurred in the Haramaya university registrar
office. The office perform students registration manually which has some short comes such as
consuming time, resource and requires much employers power. So, to reduce these short comes
we have proposed a project Student Online registration. After the automation of this system both
students and office are beneficial.
The project includes background of the registrar and also the systems performed in the office are
described. In addition to these conditions like the problems in the office, objective of the project,
scope of the project, proposed system, system design and detailed design studies are clearly
specified.
Finally, the tools and techniques we use and the schedule is summarized as much as possible to
finish the project in the given time by using our own methodologies.
1|Page
1.1)
Background
Office of registrar of Haramaya University was established for performing basic activities being
carried out in the university. Among these activities registering students, keeping students’ files,
marks and assigning department for fresh students are the major kind of activities related with
the student registration. While doing these activities they depend on rule and regulation adopted
by the campus. Office of Registrar was founded as the Campus established with the help of
Oklahoma State University (OSU), accepting its first students in 1954, and the new campus was
opened in January 1958 by Emperor Haile Selassie. For many years the office had been limited
to register students of agriculture department, but in 1996 while the university was given
permission to open other faculties and departments, the registrar also increases its registration
scope to the opened departments.
The office is an independent, non political and fully secular which is formed and governed by the
university. The primary objective of the office is to work for the academic education. There are
different workers, employers and professionals with their specific job who take part in this office
activity.
All these workers are aimed to serve students in different services. Among these services the
major once are:Registering students for courses
Enabling students to use add and drop forms
Correcting grade errors and CGPA
Enabling fresh students to select their department
Posting information
These activities are being performed in manual process. So, those huge activities will consume
much more resources and times. Indeed this situation is the case for the raise of students online
registration system to solve those problem.
2|Page
1.2)
Problem Definitions
As starting point for problem definition we try to identify how registration of students was being
carried out and we get some information about the system from the registrar office. From our
observation of the student registration process we have collected data and identified the
following problems.
Lack of online registration system
The office consumes manpower, time and resources because of manual service of
student registration system.
students also consume time and resources for registration
Lack of organized data for screening student’s service documents and relevant
information.
Inaccuracy of information (loss of data)
Reports are not processed on time.
Redundant flow of student information.
1.3)
Objective of the project
1.3.1) General objectives
The general objective of the project is changing manual registration process to
automated way of registration.
1.3.2) Specific Objectives:In addition to the general objective of the project it will also contains the following specific
Objective. These are:Assigning department and registering for fresh students
Enabling students to view their grade and CGPA secretly.
Enabling all department heads to send students mark to registrar.
Accelerating user requirement and benefits.
Supplies timely information for the students.
Minimizing data redundancy.
Minimizing loose of data.
Secured means of storing files.
Improved planning and management.
3|Page
1.4)
Scope the project
When we say scope it is about the size of the project and how much works it contains. So, the
scope of online student registration of Haramaya University focuses on registering all students of
the main campus, Harar campus and Chiro campus. In general speaking, the scope of the project
is specific to the main and its sub campuses.
In addition to this scope can be defined as the sum of the products, services, and results provided
from the project. So, the project is capable of performing the following scenario. These are:Assigning department and registering for fresh students
Enabling students to view their grade and CGPA secretly.
Enabling all department heads to send students mark to registrar.
Adding, Updating and searching student information
Generating necessary information.
Data Collection
Before implementation and design requirement analysis is the first step. So, this data collection
method is a precondition for requirement analysis. Knowing this fact we have collected
information from the existing system and used it for proposed system. There are many methods
used to collect data. Among them we have used two methods:
1. Interview
2. Observation
Interview:
We have used this method to gather information by asking the head and employers of the
registrar some basic questions.
Some questions that we asked the registrar are:
How registration process is going on?
During registration time what are there any problems? If there are what are they?
What requirements are needed for the process?
Observation:
This is by observing:
Written documents and procedural manuals
Registration form,
Add and drop form
Withdrawal form
Grade recording mechanism and
Other activities.
4|Page
Benefit of the project
For user:To get timely information.
To save their time and money.
To access accurate and fast information
For HUR office:To easily retrieve user information.
To improve management system.
To solve problem of manual work.
To save time and money and manpower
For developers
Requirement for the partial fulfillment of the Bachelor degree in computer science.
To be familiar on solving real life problems.
To expand knowledge gained from lessons.
5|Page
CHAPTER TWO
2) Proposed System
After observing and identifying the current (existing) system, it is mandatory to develop
proposed system. This proposed system should solve the problem of the existing system and
must be advanced. So, the key solution to avoid all the problems mentioned previously is to find
a unified way to solve the problems mentioned earlier. The only unified way is by
computerization. The various entities that interact with the system are identified. In addition to
this, the work flows, functional, non-functional requirement, activities performed by man and by
machine and procedure within the system are being examined to understand and visualize the
system.
2.1) Functional Requirements
These requirements describe the interactions between the system and its environment
independent of its implementation. The environment includes the user and any other external
system with which the system interacts.
This requirement document is prepared with some balance of scope, time, cost and quality
considerations. Operations of the system, which can be realized under the time and resource
limits, are included in the requirements document.
Functional requirements that must be included in the system are listed below:
A. User requirement
The users interface language is English.
Personal Computer with both a standard keyboard and a mouse are required.
The user interface consists of menus and navigations that can be dictated by
user’s responses.
B. Hardware Requirement
The other part of the external interface is hardware interface, this interface describe the hardware
part of the system. So the system needs:Computer
Printer
Network cables
Hub (16 port or more)
512 or more MB RAM
Additionally it also needs the use of a computer equipped with a mouse and a standard keyboard.
A monitor with not less than 800 x 600 resolutions and with 256 color capability.
6|Page
C. Software Requirement
The product requires:1) Browsers such as:Mozilla fire fox
Google chrome
Opera
Internet explorer and others
2) Operating systems such as:Windows 7
Window XP
In general, the functions of the proposed system are:Create account and login
Showing student their grade and CGPA
Sending request to registrar for grade and CGPA errors
Filling add, drop and withdrawal forms.
Student registration
Head of departments send grade and grade change request to registrar and receive
CGPA from.
Placement: - enables students to select department and then register.
Report for students, Head of departments and registrar
Operations such as add, delete, edit and search for all users according to their
authority.
2.2) Non-functional Requirements
Even though these requirements do not directly affect the performance of the system, they are
important. They are concerned with security, performance, usability, maintainability, reliability,
modifiability, efficiency, portability (across operating systems) testability, understandability. The
non functional requirements of the system are presented below:
A. Security requirements
The system must be secured and protected by only the office of registrar. Every user of the
system is not allowed to access data or modify all files in the database without having correct
username, password and their security key. Each member can manipulate the necessary operation
that allowed for them on the database.
7|Page
In addition to these, since the system runs on the internet environment, there are a lot of security
treat on the system. Therefore, the system should be secure from the malicious and hackers by
developing security key.
B. Performance requirements
The software performs different operations when data types are numeric, text, date and time.
And it also gives an error messages when an authorized person tries to perform some operation
without entering inputs.
C. Maintainability
The system shall be distributed with independent modules or classes for the databases. This
independency bring to easily testability, maintainability, flexibility and easy to use.
In general after the system has been produced, change or improvement may be needed. This
could happen because user need, change of the office plan and need of adding function to the
system.
D. Accuracy
Users need an accurate and correct data from the system that they use for the registration
process.
We can easily imagine the consequences of any decision that made inaccurate and incorrect data
on their basis. We expect to address this major issue through implementing a number of validity
checks such as every fields going to be entered in to the data base of the system.
2.3) System models
The system model is composed of three individual models: 1) Functional model: represented by use case and Scenario
2) System object model: represented by classes and objects diagrams and
3) Dynamic model: represented by state chart and sequence diagram.
In this section we try to analyze the overall activity of the proposed system by using use
case description, use case diagram, sequences diagrams, activity diagrams and class
diagram scenarios.
8|Page
2.3.1) Use cases and Actors
2.3.1.1)
Use Cases
Essential use cases that the proposed system consists are:1) Login
2) Registration
3) Registration slip
4) Placement
5) Exam result
6) Send grade
7) Grade error
8) Application form
9) Registration report
10) Download course
11) Upload files
12) Update news
2.3.1.2)
Actors
The proposed system consists of three major actors for the accomplishment of the system.
These are:1) Students
2) Registrar
3) Department head
9|Page
2.3.1.3)
Use case Diagram
Figure 2.1 Essential use case of proposed system
10 | P a g e
2.3.1.4) Use case and actor description
Login Use Case
Use case name
Login
Use case identifier
UC#1
Actor(s)
Students, department head and registrar
Description
Students, department head and registrar want to use the webpage
Precondition
Students, department head and registrar should create account
Post condition
Students, department head and registrar use the webpage
Basic course of Actions
1. Students, department head and registrar want to use the site
2. They have an account
3. They enter their user name, password and security key
4. Press login button
5. The entered fields are correct
6. They logged into the site
7. Use case ends
Alternate of courses of Action
Alternative course A: 2) If they have no an account
2.1) click create account button
2.2) fill all fields
2.3) get your security key
2.4) go to step 3
11 | P a g e
Registration Use Case
Use case name
Registration
Use case identifier
UC#2
Actor(s)
Students
Description
Students register for course
Precondition
The students have an account and security key to login
Post condition
Student registration is success full.
Basic course of Actions
1. Students want to be registered for courses
2. Students login to the page
3. Fill all required field on the page
4. Students previous mark is above or equal to the passing mark
5. Registration is successful
6. Students get registration message
7. Use case ends
Alternate of courses of Action
Alternative course A: 3) If the students do not fill each fields correctly
3.1) Message (fill each field with correct data) will be displayed.
3.2) Use case loops to itself
Alternative course B: 4) If students previous mark is less than passing mark
4.1) Use case ends.
12 | P a g e
Registration slip Use Case
Use case name
Registration slip
Use case identifier
UC#3
Actor(s)
Student
Description
The registered students want to take registration slip
Precondition
The student must be registered
Post condition
Both of them get and print registration slip.
Basic course of Actions
1. Students want to get registration slip
2. Student registration is success
3. Print registration slip tag will appear
4. Students click on print button
5. Registration slip is printed
6. Use case ends
Alternate of courses of Action
Alternative course A: 3) If the students registration is not success
3.1) use case ends
Department placement Use Case
Use case name
Placement
Use case identifier
UC#4
Actor(s)
Student and registrar
Description
Every students are assigned to their department
Precondition
The students should have entrance point
Post condition
Every students with entrance point are assigned to their
department
13 | P a g e
Basic course of Actions
1. Fresh students want to assign to their department
2. Students fill all their information
3. Students enter their entrance point
4. Student select each department orderly
5. Registrar enter number of students for each of departments
6. The system compare every students’ point and check their first choice
7. Students’ point and first choice is ok
8. Assign students to their department
9. Students click show me department button to see their department
10. Use case ends
Alternate of courses of Action
Alternative course A: 7) If the students’ point and first choice is not ok
7.1) the students’ point and second choice is ok
7.2) go to step 8
Alternative course B: 7.1) If the students’ point and second choice is not ok
7.1.1) the students’ point and third choice is ok
7.1.2) go to step 8
Alternative course C: 7.1.1) If the students’ point and third choice is not ok
7.1.1) assign department randomly
7.1.2) go to step 9
14 | P a g e
Exam result Use Case
Use case name
Exam result
Use case identifier
UC#5
Actor(s)
Student
Description
Every students are able to see their exam result, grade and CGPA
Precondition
The students should have to took exam
Post condition
Every students can correct error if any
Basic course of Actions
1. Students want to see their exam result
2. They enter their ID No, course code and security key
3. They click show button
4. The entered values are correct
5. Display their exam result
6. Students print their result
7. Use case ends
Alternate of courses of Action
Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
15 | P a g e
Grade error Use Case
Use case name
Grade error
Use case identifier
UC#6
Actor(s)
Student and registrar
Description
Every student is able to correct their result.
Precondition
The students exam result has an error
Post condition
Every students get the correct result
Basic course of Actions
1. Students want to correct their grade
2. They enter their ID No, course code and security key
3. The entered values are correct
4. Select course which has error and write their idea
5. They click send error button to registrar
6. Registrar see grade error message
7. Registrar check students result
8. Registrar found error
9. Correct error and update students result
10. Sent error correction message to students
11. Use case ends
Alternate of courses of Action
Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
Alternative course B: 7) If registrar not found error
7.1) send no error message to students
7.2) use case ends
16 | P a g e
Application form Use Case
Use case name
Application form
Use case identifier
UC#7
Actor(s)
Student
Description
Students fill add, drop and withdrawal forms
Precondition
The students face some problems
Post condition
Students can continue their lesson
Basic course of Actions
1. Students want to fill application form
2. They enter their ID No and security key
3. They click show form button
4. The entered values are correct
5. Application form will be displayed
6. Students fill the application form
7. All application form fields are filled correctly
8. Filling application form is success
9. Use case ends
Alternate of courses of Action
Alternative course A: 4) If entered values are not correct
4.1) error message will be displayed
4.2) go to step 2
Alternative course B: 7) If all application form fields are not filled correctly
7.1) fill all fields error message will be displayed
7.2) go to step 6
17 | P a g e
Download courses Use Case
Use case name
Download courses
Use case identifier
UC#8
Actor(s)
Student, department head and registrar
Description
Student, department head and registrar download courses that the
student registered for
Precondition
The students is registered for courses
Post condition
Student, department head and registrar can have the courses on
their hand
Basic course of Actions
1. Student, department head and registrar want to download course
2. Students were registered for courses
3. They enter their ID No and security key
4. They click on download link
5. The entered values are correct
6. They get the downloaded courses and print it
7. Use case ends
Alternate of courses of Action
Alternative course A: 2) If student was not registered for grade
2.1) go to step 7
Alternative course B: 5 ) If entered values are not correct
5.1) error message will be displayed
5.2) go to step 3
18 | P a g e
Registration report Use Case
Use case name
Registration report
Use case identifier
UC#9
Actor(s)
department head and registrar
Description
department head and registrar able to see report when students
register
Precondition
The students is registered for courses
Post condition
Department head and registrar can identify who registered, how
many students registered
Basic course of Actions
1. Department head and registrar want to get registration report
2. Students were registered for courses
3. Message was sent to department head and registrar
4. Department head and registrar login
5. They see received message symbol on the message tab
6. They click the tab and see the message
7. Use case ends
Alternate of courses of Action
Alternative course A: 2) If student were not registered
2.1) use case ends
19 | P a g e
Send grade Use Case
Use case name
Send grade
Use case identifier
UC#10
Actor(s)
department head and registrar
Description
department head send students’ grade to registrar for CGPA
calculation
Precondition
Teachers have submit students’ grade to head of department
Post condition
Department head and registrar use the calculated students’ CGPA
Basic course of Actions
1. Department head wants to gate students’ CGPA
2. The department head collected students’ grade
3. Department head send student’s grade to registrar
4. The system calculate CGPA
5. The registrar receive message for the calculated CGPA
6. Print the CGPA
7. The registrar sent the grade and CGPA back to department head
8. The department head receive message for the calculated CGPA from registrar
9. Print the CGPA
10. Use case ends
Alternate of courses of Action
Alternative course A: 2) If department head not collected students’ grade
2.1) department head try to collect students’ grade
2.2) go to step 3
20 | P a g e
Upload files Use Case
Use case name
Upload files
Use case identifier
UC#11
Actor(s)
Registrar
Description
The registrar upload files and information for students and
department head
Precondition
Registrar wants to distribute information for students and
department head
Post condition
Department head and students read the uploaded and get
information
Basic course of Actions
1. Registrar wants to upload files
2. The registrar logged into the site
3. Select the post information tag
4. Select upload button
5. Write information on the text area
6. Click upload button
7. System upload information
8. Uploaded successfully message will be displayed
9. Use case ends
Alternate of courses of Action
Alternative course A: 2) If not logged into the website
2.1) use case end
21 | P a g e
Update news Use Case
Use case name
Update news
Use case identifier
UC#12
Actor(s)
Registrar
Description
The registrar update news and post it for users
Precondition
Registrar wants to distribute information for students and
department head
Post condition
Department head and students read the uploaded and get
information
Basic course of Actions
1. Registrar wants to update news for users
2. The registrar logged into the site
3. Select the post information tag
4. Select update news button
5. Write information on the text area
6. Click update button
7. System update information
8. Uploaded successfully message will be displayed
9. Use case ends
Alternate of courses of Action
Alternative course A: 2) If not logged into the website
2.1) use case end
22 | P a g e
2.3.2) Class Diagram
Online Registration System
1
*
1
1
*
User Interface
-interfaceType
-secured
+getInterfaceType()
+isSecuredInterface()
+platformSupported()
*
*
Interface Component
-ok
-cancel
-other
+isOk()
+isCancel()
+isOther()
*
*
*
*
*
Account Administratoin
-account
-dbHandle
+isValidAccount()
+manageAccount()
+accessDB()
1
Login
-username
-password
-securitykey
+isnewUser()
+isLoggedin()
+forgotPassword()
*
1
Database Management
-adminId
-dbAccessKey
+isValidAccount()
+manageAccount()
+accessDB()
*
*
*
*
*
Account
-accountId
-accountOwner
-accountInfo
+login()
+getAccountInfo()
+updateAccount()
*
Student
-fullName
-idNo
-age
-sex
-classYear
-nationality
-state
-region
-woreda
-fucalty
-depratment
-email
-phoneNo
+login()
*
+register()
+fillForms()
+checkGradeError()
Transaction System
-transaction
+manageTransaction()
+isValidTransaction()
*
Execute Order
-userId
-order
+isValidOrder()
+updateOrderStatus()
+notifyUser()
*
*
*
Cancel Order
-userId
-order
+iscancellable()
+cancelOrder()
+notifyUser()
Department Head
-name
-idNo
-position
-age
-sex
-phoneNo
-email
+login()
+sendGrade()
+prepareSlip()
+getReport()
*
Registrar Office
-name
-idNo
-position
-age
-sex
-phoneNo
-email
-fax
+login()
+getReport()
+uploadFiles()
+updateNews()
+getCourses()
+setplacement()
1
Fig 2.2 Class Diagram
23 | P a g e
2.3.3 Sequence Diagram
Student
Registrar
Registration Subsystem
Database
FillApplication
Determine Classification
Open Registration Page
Enter Data
Check Duplication
Validated
Check Old Results
Validated
Calculation
Save Data
Confirm Save
Issue Registration Report
Print Report
Fig 2.3 Sequence Diagram for Registration
24 | P a g e
Registrar
Student
System
Database
Fill Form
Enter Stud No for departments
perform opreration
show students' department
accepted
save student information
Confirm Save
registration report
show students' department
print
Fig 2.4 Department selection sequence Diagram
25 | P a g e
System
Database
login
check Account
validate
display grade view page
Id,securitykey & course code
check security
validate
Request search grade
Displaye Grade
Displaye Grade
Print
Fig 2.5 Grade View sequence Diagram
26 | P a g e
Registrar
Department Head
System
Database
Send Grade
Enter grade & cr.hrs
calculate
Display Result
validated
Save
Confirm Save
Report
Send CGPA
Print
Fig 2.6 Calculate CGPA sequence Diagram
27 | P a g e
Student
Registrar
Department
System
grade error message
check grade
send corrected
Enter grade
update grade
Updated & saved
update CGPA
Updated & saved
Update Report
Updated Grade & CGPA
Updated Grade & CGPA
Print
Fig 2.7 Grade Error sequence Diagram
28 | P a g e
2.4
Interface
2.4.1 Form
2.4.1.1 Home page interface
Click on your faculty then on your
department. Then login form will
appear as follows.
29 | P a g e
2.4.1.2 Login Form Interface
Fill the login fields and
login to the page
If you have no account Click here
and fill the following create
account field
30 | P a g e
2.4.1.3 Create Account Form Interface
Fill all fields and click create button. This will create your account so that you can use the system
with your access control.
31 | P a g e
2.4.1.4 Add and Drop Form Interface
This interface enable students to fill add and drop form online. Students fill all their personal
details, course to be added, dropped and click submit button.
32 | P a g e
2.4.2 Activity Diagram
Fill Login Form
[Department]
[Student]
[Registrar]
[No]
[Yes]
Browse Page
Department
Send Grade
Student
Registrar
Grade Error
View Grade
Post Info
CGPA
Check Grade
Correct
[Yes]
Students
Forms
Fill Placement Fields
[ Yes]
Get thier dept
[No]
[No]
Register
Fig 2.8 Activity Diagram
33 | P a g e
CHAPTER THREE
SYSTEM DESIGN DOCUMENT (SDD)
3.1) Purpose of the System
Registration office is one among offices of Haramaya University that perform student
registration process for more than 30,000 students.
The registration still uses manual registration system that is difficult to perform the activity in
efficient manner, consumes resources and time of both the registrars and students.
The purpose of this new system (Student Online Registration System) will reengineer the current
system, bringing new technology for the office so that students of the campus can be registered
being online without contacting the registrar and check their point online secretly. These
minimize loss of resource such as transport and time.
3.2) Design Goals
The design goals represent the desired qualities of Student Online Registration System and
provide a consistent set of criteria that must be considered when make design decisions. Based
on the non functional requirements the following design goals will have to be achieved in order
to qualify the system as successful.
1. Dependability criteria:
Robustness: The system has to be robust enough to manage any invalid input
from the users.
Reliability: The system has to perform all operations of the registrar with no
errors.
Security: This is one of the most important nonfunctional requirements for
securing all information and data of the office.
2. Cost Criteria:
Deployment cost: The system has to be easy enough to have a cheap training
cost.
3. Maintenance Criteria:
Extensibility: the system must support that new functionalities can be added.
Modifiability: The system has to be highly modifiable to maintain.
Readability: The system has to be readable to assure its modifiability.
Traceability of Requirements: the code should be easy to be mapped to specific
requirements.
4. End User Criteria:
34 | P a g e
Utility: The system has been conceived specifically to support the students and
employers.
Usability: The system will be designed in a user friendly fashion, both for
students and employers of registrar.
3.3) System Design Model
3.3.1) Subsystem Decomposition
During the subsystem decomposition we divide the system into smaller subsystem. Each
subsystem is strongly coherence and loosely coupled.
The system will be decomposed based on the use case and different actors defined in the system.
The decomposition shows the existence of the following subsystems.
User management subsystem
Account management subsystem.
Transaction management subsystem.
Storage subsystem.
Database subsystem.
The database subsystem will be implemented by the relational database management system
(RDMS) used to store the persistent data. The storage subsystem will encapsulate the database,
providing a common interface to the other three high level subsystems.
The following figure shows relationship between subsystem decomposition.
35 | P a g e
3.3.2) Hardware /Software Mapping
Student online registration system will be web-based so that students and employers access
through the internet. All functionality will be performed in the main host and will be accessed
through Haramaya University website (www.haramaya.edu.et) by all users.
The system will run on windows 7, windows XP and UNIX operating system. The web server
will run over wamp web server version 2. 0.
The programming language used to develop this product will be PHP version 5.2.6 and some
scripting language such as hyper text markup language (HTML), Java script (JS) and we have
used MYSQL version 5.0.51b as the database management system.
The following diagram illustrates software and hardware mapping of the system.
Fig 2.10 Hardware/Software Mapping
36 | P a g e
This figure shows relationships between subsystem decomposition with class.
3.3.3) Persistent Data Management
The followings are persistent data objects based on the requirement analysis document.
Person: this is information about all the system users. It can be system administrator and
user.
Account: It is information about the registration accounts. It includes the account holder’s
information.
Transaction: Detail information about database transaction when different students
registered at the same time in the same table
This persistent information will be stored in a relational database management subsystem. We
have selected MYSQL as RDBMS due to its versatility, high performance and integration with
the other products that constitute the new platform.
3.3.4) Access Control
The access control for the system is implemented through the capabilities list. This
representation comes up to be more compact and efficient for the system. A capability associates
a class, operation paired with an actor. A capability allows an actor access to an object of the
class. Denying access is another word for denying capability.
37 | P a g e
Registrar Capability List:
Class
Select Menu
Create Login Menu
Create Student Login Form
Create Department Login Form
Create Login Report
Operation
createAccount(),
updateLogin(),
Login()
CreateStudentLogin(),
CreateDepartmenttLogin()
Create(), Update(), Login()
Create(), Update(), Login()
Show(),Print(),Exit()
The above table indicates that Registrar can create account for departments, students and give
them access control.
Students Capability List:
Class
Select Menu
Create Login Report
Operation
createAccount(),
updateLogin(),
Login()
Show(),Print(),Exit()
The above table indicates that Students can create account with the help of registrar, edit their
account and print information
Department Head Capability List:
Class
Select Menu
Create Login Report
Operation
createAccount(),
updateLogin(),
Login()
Show(),Print(),Exit()
The above table indicates that Head of Department can create account with the help of registrar,
edit their account and print information
38 | P a g e
3.4) Detailed Design
Introduction
Haramaya University Student Online Registration is a system to be developed to change the
manual system into automated system. The system will be uploaded on a central server to be
accessed by multiple users. It will have user-friendly interfaces to interact with the users easily.
User will type their user name and password on the login form and the system will check the
validity of the user in the database. If a match is found the user will be allowed to access the
system with the privilege level assigned to him/her. If a match is not found in the database the
system will display a message telling the user to re-enter the user name and password or else
service will be denied
3.4.1) Object Design Model
1. Performance criteria
Response time. Refers to the time delay the user wait for accessing the page. It is
mainly depend on the connection type of our internet.
Throughput. Refers to the number of tasks/operations that can be done at a time.
Memory: This is the required memory size, so as to run the application properly. The
proposed system will need minimum of 512MB of Memory for client machines and 1
GB for server. And internet connection is the first step of processing. Offline users
don’t have the opportunity to use the site.
2. Durability versus platform dependence
This software product is designed to platform independent software in order to run meeting
the following hardware specifications.
2 GHz processor speed
256 MB RAM
50 GB hard disk
39 | P a g e
3. Dependability criteria
Availability. It refers to the degree to which the system is found doing normal
task. The system works as long as connection is available.
Fault Tolerance- ability to operate under erroneous conditions. The system back
up data to avoid loss of data when system crash or damage.
3.4. 2) Database Design
The overall objective in the development of database technology has been to treat data as an
organizational resource and as an integrated whole. Database Management System allows data to
be protected and organized separately from other resources.
Entity Relation Ship Diagram
CreateAccount
PK
IdNo
FK1
Image
FirstName
LastName
Email
Password
Flag
PasswordRecovery
UserName
PK
Login
PK
UserName
Password
Security
Flag
DepartmentSelection
Department
FirstChoice
SecondChoice
ThirdChoice
ForthChoice
FivethChoice
SixthChoice
SeventhChoice
FreshRegistration
PK,FK2
IdNo
FK1
FK3,FK4
FirstName
MiddleName
LastName
Sex
Age
Region
Zone
Woreda
HighSchool
AveragePoint9
AveragePoint10
AveragePoint11
AveragePoint12
EnterancePoint
Email
Phone
Photo
Department
CourseCode
Add and Drop
SeniorRegistration
PK
IdNo
FK1,FK2
FK3
FirstName
MiddleName
LastName
Sex
Age
Nationality
Faculty
Department
year
Semister
AccadamicYear
Photo
CourseCode
UserName
PK
CourseCode
CourseTitle
CreditHour
Instractor
AdvisorName
Sign
Courses
PK
CourseCode
CourseTitle
CreditHour
Instractor
AdvisorName
Sign
40 | P a g e
3.5) Definitions, Abbreviations, Acronym
3.5.1) Definition
Haramaya University Student Online Registration System: is a system going to proposed in
order to give services for students of the campus and to serve Haramaya Registrar office.
Registrar Office: an office that performs student registration process and related activities.
Students: A customers that enrolled in registration activities.
Department Heads: Are actor plays a great role in student registration by submitting student
grades to registrar.
41 | P a g e
3.5.2) Abbreviations
CGPA: - Cumulative Grade Point average
GB: - Giga Byte
GHz: - Giga Hertz
HURO: - Haramaya University registrar Office
HUSORS: - Haramaya University Student Union.
HUR: - Haramaya University Registrar
HTML: - Hyper Text Markup Language
JS: - Java Script
MB: - Mega Byte
MySQL: - My Structured Query Language
OSU: - Oklahoma State University
PHP: - Personal Home Page
RAM: - Random Access memory
RDBMS: - Relational Database Management System
UC:-Use Case
UNIX: - Universal Network Information Exchange
Windows XP: - Windows Extreme Programming
42 | P a g e
3.6) References
1. Internet
http://www.docstoc.com/docs/20179356/BANKING-SYSTEM-SYSTEM-DESIGNDOCUMENT
http://www.docstoc.com/search/subsystem-decomposition
http://www.haramaya.edu.et
2. MySQL Cookbook author O'Reilly 1st Edition
3. PHP & MySQL author Vikram Vaswani 2nd Edition
4. Advanced PHP for Web Professionals Christopher Cosentino
5. CSS Pocket Reference author O’Reilly 2nd Edition
43 | P a g e
Download
Study collections