COLLEGE OF TECHNOLOGY

DEPARTEMEN OF INFORMATION TECHNOLOGY

Title: - Automated of student cost sharing system in

debre Markos University
PREPARED BY:

Name: Esubalew Anteneh

IDNO: TEE/212/03 E.C

Advisor Name:
Mr.Fasika T.

January 2006 E.C

DEBRE MARKOS, ETHIOPIA

0
Contents
CHAPTER ONE:.............................................................................................................................................6
1. INTRODUCTION...................................................................................................................................6
1.1 Background of the organization...................................................................................................6
VISION.................................................................................................................................................6
Mission................................................................................................................................................7
1.2 Statement of the problem...........................................................................................................7
1.1 Objective of the project...............................................................................................................8
1.1.1 General objective:................................................................................................................8
1.1.2 Specific objectives................................................................................................................8
1.4 Significance of the system..........................................................................................................8
1.5 SCOPE AND LIMITATION OF THE PROJECT...................................................................................9
1.5.1 Scope of the project.............................................................................................................9
1.5.2 Limitation of the project......................................................................................................9
1.6 Methodology...............................................................................................................................9
1.6.1 SYSTEM DEVELOPMENT METHODOLOGY.......................................................................9
1.6.2 Development environment and programming tools......................................................10
1.6.3 Data Collection..................................................................................................................11
1.6.3.1 Observation (primary method)..........................................................................................11
1.6.3.2 Interview (supplementary method)...................................................................................11
1.6.3.3 Document Analysis (supplementary method)....................................................................12
1.7 Feasibility of the study.............................................................................................................12
1.7.1 Economical Feasibility:.......................................................................................................12
1.7.1.1 Project budget plan (Costs)................................................................................................12
1.7.2 Technical feasibility............................................................................................................13
1.7.3 Operational feasibility........................................................................................................13
1.7.4 Political feasibility..............................................................................................................13
1.7.5 Schedule Feasibility............................................................................................................14
CHAPTER TWO...........................................................................................................................................15
COST SHARING RECORDING AND REPORTING SYSTEM IN DMU...............................................................15
2. Introduction.......................................................................................................................................15
2.1 Data Recording..........................................................................................................................15

1
 2.2 Data Storage..............................................................................................................................16
2.3 Analyzing and reporting the current system..............................................................................16
CHAPTER THREE........................................................................................................................................16
REQUIRMENT ANALYSIS............................................................................................................................16
3. Introduction.......................................................................................................................................16
3.1 Software requirements..............................................................................................................17
3.2 Functional requirements...........................................................................................................17
3.3 Non functional requirements.....................................................................................................18
3.4 Description of the current system.............................................................................................19
3.4.1 Problems identified on the current system............................................................................20
3.4.1.1 Performance problems......................................................................................................20
3.4.1.2 Information problems........................................................................................................20
3.4.1.3 Business problems.............................................................................................................20
3.4.1.4 Efficiency problems............................................................................................................21
3.4.1.5 Usability problems.............................................................................................................21
3.4.2 Alternative solutions for the current system.....................................................................21
3.5 Automating the system..............................................................................................................21
3.6 Essential use case description....................................................................................................22
3.7 Domain Modeling Using Class Responsibility Collaborator........................................................24
3.8 Essential user interface prototyping..........................................................................................25
CHAPTER FOUR..........................................................................................................................................33
OBJECT ORIENTED ANALYSIS.....................................................................................................................33
4. INTRODUCTION.................................................................................................................................33
4.1 Use case description..................................................................................................................34
4.2 Sequence diagram.....................................................................................................................39
CHAPTER FIVE............................................................................................................................................46
SYSTEM DESIGN.........................................................................................................................................46
5. Introduction.......................................................................................................................................46
5.1 Class diagram.............................................................................................................................47
5.2 Activity diagram.........................................................................................................................48
5.3 User interface diagram...............................................................................................................58
CHAPTER SIX..............................................................................................................................................63

2
6. IMPLMENTATION...............................................................................................................................63
6.1 Algorithm development.................................................................................................................63
6.2 Conclusion.................................................................................................................................67
REFERENCE............................................................................................................................................67

3
 ACKNOWLEDGMENT

First and most I would like to thank every one of you who have been involved in helping us throughout
the entire process of completing our project, especially DMU cost sharing workers in providing of ground
information of how the manual system is currently operating to visualize what would be the proposed
system to improve problems faced on the existing system, Secondly I would like to thank my Advisor Mr
Fasika T. his also help me different things in my place of work, Finally, I would like to special thank for
my friends who have been participating in providing us with constructive suggestions and unlimited
moral support throughout our study.

4
Abstract

Initially I am focus on this area of problem by observing problems caused by due to the manual working
of the system. Most explicitly occurred problems by the manual system are data redundancy, high
manpower requirement, time wastage, unavailability of data, and tedious nature of the working system.
Typically, the project is aimed with the general objective of designing an automated student cost sharing
working system with an assistance objective of designing student database.

CHAPTER ONE:

1. INTRODUCTION
1.1 Background of the organization
Debar Marko’s University is one of the thirteen new university which wear established by
the federal democratic republic government of Ethiopian. Its foundation stone was laid in

5
1997 E.C/2005, as a newly opened higher governmental education institute by ministry of
education and hosting around 760 students as a beginner in 1997 E.C/2005.

In debre markos university student cost sharing has been organized in 1997 E.C/2005,
when the university started its function with one college and eight departments the office is
responsible for managing the academic record of students and is committed to serve
students. The student cost sharing started its function when the universities look off with
the first batch 760 students.

Debre markos university campus provides services like student’s registration, library
servicing, student cafeteria, store system, management servicing, cost sharing system and
internet access sing (resonate) servicing to the students etc.

The students cost sharing system works along with the registrar office. The government
incurs (invite) an over estimated expenses to gratify students need towards getting
services from the institutes on the pre requirements of the students to share the cost they
used in their time of duration in the campus. Ignored to compensate these costs, the
government of the Ethiopia designed student cost sharing regulation policy by house of
people representative and come to in action in 1996 E.C.

These regulations recommended that the students in their duration must share the cost
either in cash or in kind after graduated from. In order to apply this policy in action, an
automated student cost sharing system is required which enables to control the student’s
who does not share the cost and to understand the amount of resources spent for each
department.

VISION
• To see the customers when getting an access from the proposed system.

• To overcome the usual problems and see the customers pleasure

•To use computerized system in the student cost sharing systems

Mission
In debre markos university student cost sharing mission is creating suitable environment
make enables the user to interact with the system and introduce customer to the system.
The student cost sharing system is committed to render quality service to satisfy its
customers use an automating the office with advanced software of the customers.

1.2 Statement of the problem

In debre Markos University I observed the student cost sharing system most of its work is
done in manual system. Manual based documented system takes more time to find

6
students information. And also needs more workers, and leads to problem. In this project I
designed a system that can solve those problems, because the manual system cannot fulfill
the need of the recorder.

So the following problems are listed, it includes that:

 There is no full use computerized system student information.

 Manual documented system is time taking than computerized documented system.
 It is not easy to find students data in short period of time.
 Students’ information recorded document may be lost
 The retrieval of student cost sharing system record consumes use much time.
 Difficult to search student’s data as required when the numbers of Student s are
increased.
 Time wastage to the students as well as the customers.
 Tedious and complex data when the numbers of students are unbalanced with the
workers recording system.

The problem above is some of the problems are available due to the manual works and
there are described in the greater detail on the existing system analysis part of the project.

It is expected from us to develop or to recover the manual one by automated student cost
sharing system.

If the system is not automated the aforementioned problem may aggravated and the
government may not get the expected cost from the beneficiaries effectively at the right
time

1.1 Objective of the project

1.1.1 General objective:
The general objective of this project is to design and develop a database student cost
sharing system and that computerized the existing manual system would permit recorders
and other stockholders to get reliable and summarized information about the student on
time.

1.1.2 Specific objectives

Following are specific objectives

 Analyzing the existing system

 To produce the different reports
 study the existing system of the organization

7
  Identifying problems of the existing system
 testing the implementation of the system
 Designing student cost sharing system
 Develop student cost sharing system
 Produce documentation about the system and use the other specific objective.

1.4 Significance of the system

The project has a great benefit for the student cost sharing system and their workers of the
administrative center in case of solving the problems.

The benefits are listed below:

 Reduce the amount of resources that are wasted.

 Keeping information safely about DMU cost sharing.

 Faster decision making due to the report generation functionality.

 Giving work satisfaction for workers as well as the customers.
 Faster decision making due to the report generation functionality.
 Users will be allowed to interact with the system.
 Accessing information’s in fast way.
 Increased the speed to perform activities.

1.5 SCOPE AND LIMITATION OF THE PROJECT

1.5.1 Scope of the project
The project is designed or proposed to meet the functionalities of recording students
information in the database when they get the form ,generating report identify student in
accordance with their batch or registration date.

The implementation phase and the system support an automated data handling
mechanism, like database in order to keep the data in secured and consistence way without
any alteration, modification and unauthorized access. Finally this project is aimed to design
and develop a database student cost sharing system for Debre Markos University students.
Hence, the system is limited to the development of a database recording and reporting
student cost sharing system in DMU.

8
 1.5.2 Limitation of the project

To accomplish the project if I have more time, I can do the proposed analyses and design
and implementation the system more efficient their shortage of time.

The materials that are limited in my project are:

 Time
 Budget
 Hardware limitations
 Software limitations
 Un experienced way of data gathering techniques
 References and research manuals etc.

1.6 Methodology
1.6.1 SYSTEM DEVELOPMENT METHODOLOGY
System development methodology in system developing refers to the frame work that is
used to structure plan and control the flow of developing an information system there are
different system development methodologies that are suitable for different projects based
on the values technical organizational project and team consideration. Each of the available
methodologies is best suited to specific kinds of projects, based on various project,
technical and organizational

In my project I used object oriented software development methodology. The reason why
we are selected OOSD (object oriented system development) is because it has the following
advantages:

 Objects/classes or models are used to represent real world problems in simplified

form.
 Object based models appeal to the working of human cognition and hence the
human input in to the development of a system is likely to be more natural and less
error prone.
 Object oriented systems tend to be based up on stable forms that are more
resilient to change.

9
  Allow full exploitation of the power of object based and object oriented
programming languages.
 Encourages re-use not only modules but also entire design.
 Object-oriented systems tend to be based upon stable forms (i.e. the objects and
classes) which are more flexible to change

 This means that object-oriented systems are more likely to be

allowed to develop over time, rather than have to be abandoned or
completely re-designed in response to major changes in the
customer(s) / user(s) requirements

1.6.2 Development environment and programming tools

In this project I used to the visual basic.net 2010 programming language as a front end and
the SQL Server 2008 or MS-Access as a back and or database tool to develop the new
computer based on the system.

In addition to the programming and database tools our team used additional software to do
different application.

Different tools are used to accomplish this project. They includes:-

 EDRAW software
- This is used to draw different UML (unified modeling language) that are
necessary to structure the system.
 Microsoft word 2007 software
- This is used to write the documentation of the proposed system from the
starting to the end of the project
 SQL Server 2008 software

- This is used to store data and reduce time and cost of development and
management of applications.

 Visual basic.net 2010 software

10
 - In this Visual basic.Net programming language use to the code and interface of
the web based develop and Allows sql server database integration with wide
variety of applications

1.6.3 Data Collection

For the purpose of primary data from Debre Markos University has been collected and analyzed
through structured interview, and observation.

1.6.3.1 Observation (primary method)

The main data would be gathered through the technique of observation by watching
the workers how they do and what are the resources or materials they used to
perform their recording the information system task currently.

1.6.3.2 Interview (supplementary method)

I use an interview as a data gathering techniques because making an interview with the
intended body makes us to have a full understanding about the problems of the institute on
the proposed system.

For a period time Interviewing I got a variety of essential information from the employees
and users. I will interview cost sharing expert workers how to records the current systems
mainly the major problem of the current systems and how to give the formal processing
student cost sharing system after the final organization in DMU.

1.6.3.3 Document Analysis (supplementary method)

I wrote documents that are available in the student cost sharing system which are
necessary for our system.

Examples:
 To find the organizational structure of the organization.
 To write Mission, vision and purpose and tasks under taken by the
university.
 To understand the current forms used by the organization.
 To develop different forms used on the current system
 In general to understand the current system how the student cost sharing
system work to handle student information.

11
1.7 Feasibility of the study
A feasibility analysis may be conducted for a project with an emphasis a financial viability,
environmental integrity, cultural acceptability or political feasibility. It is the determination
as to the likelihood of success and adscription of how that determination was achieved.

1.7.1 Economical Feasibility:

It is known that the current working system not sufficient in time, reliability of data, man
power, and other high cost incurred services to collect the expected expenses form the
student during their time in the university. The new proposed system is designed to
overcome those problems to as to respond the high economical loss of the current working
system. This economic feasibility is to identify the financial benefits and cost association
with the development project, economic feasibility is referred to us cost benefit analysis.

1.7.1.1 Project budget plan (Costs)

Price per unit(birr) Total price(birr)

Material use Amount birr cent birr cent
computer 1 15,000 - 15,000 -
scanner 1 5,000 - 5,000 -
printers 1 8,000 - 8,000 -
flash 1 140 - 140 -
DVD-RW 2 25 - 50 -
pen 2 3.00 50 7.00 -
paper 60 - 20 120 -
ruler 1 2.00 50 2.50 -
Total 28,319 50
Table 1.1 cost analysis

1.7.1.2 BENEFITS
The benefits of the project are listed below

 Cost reduction (tangible)

 Error reduction (tangible)
 Increased the speed of activity (tangible)
 Reduction in material usage (tangible)
 Faster decision making (intangible)
 Increased accuracy and availability (intangible)

12
 So cost is 28,319.50 birr, since the benefits are larger than the cost that spends to do the
project, I conclude that the project is economically feasible.

1.7.2 Technical feasibility

The purpose of technical feasibility is to gain an understanding of the organization ability
to construct proposed system. In case of technology most probably I use the computers,
and other computer devices to work with. The new system will change the manual based
student record system to computerized system for this it requires a minimum of one
powerful computer for deployment purpose. The system will install on the deployment
computer. So I conclude that the system is technically feasible.

1.7.3 Operational feasibility

The proposed system may take time to be fully operational when it is developed. But, regular
support or follow up from the developer and making the users to be familiar with the system
will ensures that the system will solve the current proposed system problems. It is expected
that the new system can change the current manual based student record
system to computerized based student record system, so it requires skilled
worker and the system will not affect any organizational relationships.

1.7.4 Political feasibility

Developing this type of multipurpose system that may solve numerous problems in the
institute may get a positive outlook by the institute officials. We are working the system for
the government so the team concluded that the project is politically feasible.

1.7.5 Schedule Feasibility

The purpose of assessing schedule feasibility is for you as system analyst, to gain an
understanding of likelihood that all potential time frame and completion date schedule can
be met and that meet this date will be sufficient for dealing with the need of the
organization.

N Task Name Start Finish Duration October Novem December January

o day day ber
1 Proposal 21/2/06 3/3/06 12 Days
2 Analysis 4/3/06 26/3/06 22Days
3 Designing 27/3/06 10/4/06 14Days
4 Implementation 11/4/06 15/5/06 34Days
5 Presentation 2/6/06 6/6/06 3 Days

13
 Table 1.2 Time Schedule

Phase Deliverables

Requirement gathering

 Observed the documented data Proposal

 Preparing questionnaires
 Preparing the general summary for the project

Analysis

Current system- statement of problem Document analysis

New system- possible solution finding

Logical modeling

Design

 Conceptual designing Design document

 Logical designing
 Physical designing
Implementation

 Preparing necessary computers and installing

programming tools
Source code
 Writing, compiling and running the program
Testing Testing document

Testing the functionality of the system

Table1.3 work break down structure

14
CHAPTER TWO

COST SHARING RECORDING AND REPORTING SYSTEM IN DMU

2. Introduction
This chapter mainly concentrates on the issue of how the current system attempts to follow
to record student’s information, what action would the current system takes to store those
information’s, and try to find answers for questions of how to analyze and report
information on the current system.

2.1 Data Recording

The current system of DMU cost sharing is based on manual system composed of different
files and paper based data strategic physical system. There is no always use a database
recording and reporting systems. Every student provided with the cost sharing regulation
form from the department and fills the form, finally returns to the department. Any
information of the student stores on paper as a document without any protection
mechanism. When a new students come to register, another paper would be prepared for
recording purpose and continues in this fashion so as to the institution hosts the student.
When the student shifts from their first batch to the coming batch, another paper required
to register all personal information of the student on that year. So, having in mind this ways
of operation, it is not difficult to predict that the problem of current working system in
terms of time, money or poor utilization of resources with tedious working style.

2.2 Data Storage

All those student information recorded are stored on the forms of physical documents. It is
not difficult to expect the size of the document stored for all students that are hosting by
the university which makes the recording and reporting system difficult from the
physically documented materials. This large size of the document makes searching
student’s data difficult, puts the reliability of the data under quotation mark, makes difficult
to prepare a report when the report is required on time and also it is difficult to update.

2.3 Analyzing and reporting the current system

15
When someone wants to analyze the information and claims to have a report from those
information, it is not as such easy to see the report and difficult to analyze those huge
amount of documents in a short time interval.

Generally it is impossible to understand how the current is operating, to know what type of
operation does the system incorporates, in what way the recorders prepare a report and
search a specific information from the large document collection.

CHAPTER THREE

REQUIRMENT ANALYSIS

3. Introduction
When this request gets acceptance by the students and implemented properly, it can plays
a vital role for the reconstruction of other public services in the national level. If the
regulation has such a lot contribution for the growth of one country, developing an
automated higher education cost sharing regulation form are mandatory and significant.

Having this in mind, the goal of the requirement phase is eliciting the requirements from
the user or customer. This is usually achieved by the development of modeling diagrams
and the requirement specifications after discussions with the user. The user then reviews
the modeling diagrams and specifications to determine if the system developer has
understood the requirements. Thus, it is essential that the diagrams and specifications
communicate back to the user the essential aspects required of the software to be
produced.

3.1 Software requirements

Requirement is a condition or capability possessed by a software or system components in
order to solve real problems. It is a description of the services that a software system must
provide and the constraints under which it must operate.
The main different software requirement tools are used to accomplish in this project
includes that:
 Asp.net with Visual basic 2010 software for coding and interfacing
 Rational rose for drawing different artifacts

16
  Use Microsoft sql server 2008 software database
 EDRAW software
 Microsoft word 2007 software etc

3.2 Functional requirements

The functional requirements also known as behavioral requirements that describes the
functionalities or services that software’s should provide. For this, functional requirements
describe the interaction of software with its environment and specify the inputs, outputs,
external interfaces, and the functions that should not be included in the software. Since I
develop an automating services that are given to the users via web, the system will be used
to manage and process data according to the rule & regulations of the organization. It will
also provide report generation facilities and notify the students of the university when
there is an issued case that helps the administration of the University for Decision making.

The database of the system provides the following functionality.

 Data entry:
This is the functionality that data is entered to the systems. The system have
different interface that can be used to perform different tasks and used to
manage data entry mechanisms in the university.

The main data entries are the following:

 Login: to identify the authorized customer to use the system

 Registration: needs to register students in each year

 Data update: needs to update data from the system when it is necessary
 Search information: needs when the user wants to search specific information
about the student information
 Data processing:
The system on input data will provide the following data processing:

17
  New Students registration

 Verify the requested information

 Report generation
 Validate user
 Search user request
 Updating the student
 Report generation:
 Produce report for top managers
 Produce the different reports.
In general the followings are the main functional requirements:

 Allow searching cost sharing records using different parameters

 Register cost sharing information about the students
 Load student cost sharing information from the database
 Generate various reports based on the requirements.
 Update the recorded information when it is needed

3.3 Non functional requirements

The non functional requirements (also known as quality requirements) related to system
attributes such as reliability and response time. These requirements are not related
directly to any particular function provided by the system. It should be accomplished in
software to make its performance more efficient. Non-functional requirements are often
called qualities of a system. Other terms for non-functional requirements are "constraints",
"quality attributes", "quality goals" and "quality of service requirements".

Some of the followings are the main points to express non functional requirements. They
include:-

 The user interface should be user friendly and interactive

 The system doesn’t allow unauthorized users to register and modify records

18
  The system should handle invalid inputs and displays informative error
message to users
 The system provides with an alternative message to operations committed
by users that distort the system

3.4 Description of the current system

Debre Markos University student cost sharing system officially began/organized its work
by engaging its own staff worker as an independent the staff in 1997 E.C. However, since
the staff applies the manual working system, it faces different problems at different time.

Even if the current system is a manual system, it provides the following activities:

 Get list of students

 Enforce that the students fill the form
 Documented students information based on their department
 Generating a manual report as needed
Input
Regulation form with student information
Process
The cost sharing office transfers the form to the department.
The department distributes the form down to the student
The students should fill the form and return back to the department
The department checks the filled form whether the students are fill correctly the
form and return back to the cost sharing office.

Out put
Documented students information

Getting services like training, cafeteria, education, dormitory, medical etc…

19
 3.4.1 Problems identified on the current system
The current manual system, as stated on the statements of the problem, is faced to
numerous (many) problems:

3.4.1.1 Performance problems

 Unable to provide or retrieve student’s information on time
 Wastage of time to organize and integrate fill
 Unreliability of student’s information
 Redundancy of student’s data

3.4.1.2 Information problems

The following are problems most probably related to information’s on the current system.

 Loss of student information

 Difficult to manage the information due to unorganized data
 Difficult to access student’s data
 Difficult to update

3.4.1.3 Business problems

 It incurs high cost for the materials necessary to document the data and
manpower

3.4.1.4 Efficiency problems

 Maximum use of resources
 The speed with which the system executes

3.4.1.5 Usability problems

 Difficult to get easily to used due to the manual working system

20
 3.4.2 Alternative solutions for the current system

Using electronic material

As stated before, the cost sharing officer records student’s information manually
without the aid of any electronic devices. Thus, it results in the recording system so
much more tedious and required more time to complete specifying task. Therefore,
using electronic materials such as computers for storing student data, printers for
generating student’s information can make the recording system easy and can keep
the students information in a reliable manner than documenting manually

3.5 Automating the system

It is not guaranteed to make sure that whether the data is consistence and available on the
time. But, automating the current working system enables to control unauthorized users to
the database, makes possible to take any necessary updates on the database, reduce
manpower and time, increases consistency and reduces the space required

Fig 3.1 Essential use case diagram

3.6 Essential use case description

Use case1: record
Actor: recorder

Description: records the existing students who are available.

21
Precondition: The students filled the regulation form properly.

Post condition: The field form should be available for the records.

Basic course of action

- The recorder requests the student list for every batch to record. The recorder inputs
personal information in to the system according to the regulation. The recorder
cheeks then share complete form.
1. The recorder prepares the regulation form.
2. The recorder distributes the form to department.
3. Announced (disclose) the deadline time/date.
4. The recorder follows whether the form is going with time.
5. The recorder should set the filled form from the department.
6. The recorder documented students’ information.
Alternative course of action
2 The recorder may not distribute the form on time.
3 The recorder may not disclose the deadline time/date.
4 The recorder may share low follow up.
5 The recorder may not get the information at the required time.
6 The recorder may take the necessary update if it is required.
Use case2: get service
Actor: student

Description: The students get services from their accepting of the regulation

Precondition: The students get the service

Post condition: The students get their information when it is required for them.

Basic course of action

1. The student wants to accept the regulation form.
2. The student puts his/her information on the form.
3. The student submits the filled form to the department
Alternative course of action

22
 1 The student does not accept the regulation form according to the service they get.
2 The student does not put their information properly/ may losses their forms
3 The students do not submits the filled form as pars the deadline time/date.
Use case3: provide service
Actor: Department

Description: The departments provide service to the student when the students are accepts,
fills and submits the regulation form as far as the rules.

Precondition: The department should have student’s information

Post condition: The student gets on necessary service on side of the department

Basic course of action

1. The department verifies that the students to be register according to their
information.
2. Accepts the form from the cost sharing office manager
3. The department distributes the form to the students
4. The department returns back the filled form to the cost sharing office.
5. The department checks whether the student is filled the form properly
Alternative course of action
3 The department does not distributes the form to the student

5 The department does not check the student’s information

Use case4: prepare the report

Actor: recorder (manager)

Precondition: The recorder has an access on the student’s information.

Post condition: Student information is inputted to the system

Basic course of action

23
 1. The system displays student’s information on the student’s information display
system.
2. The system calculates the overall estimated cost for each student according to the
amount they used in their duration.
3. The system informs validate the student information fits with the cost sharing rule
sack.
Alternative course of action
1 The system does not error to display student information.

2 The system does error to calculate the overall estimated cost during their duration.

3 The system does not inform whether the student accomplishes the regulation
successfully.

4 The system does not provide the student with the conformation statement.

3.7 Domain Modeling Using Class Responsibility Collaborator

A class responsibility collaborator modeling is a collection of standard index cards that
have been divided into three sections.

Class: represents a collection of similar objects.

Responsibility: is something that a class knows or does.

A collaborator: is class that a class interacts with to fulfill its responsibility.

Recorder Student
Recorder ID Stud Id Stud Address
Stud Name Nationality
Recorder name
Age phone
Address Process Sex Region
Phone number 24
Place of birth Woreda Form
Date of birth Zone
Academic year Town
 Semester Kebele
Faculty University
Department

Department
Dep’t Name
Dep’t ID Validate

Fig 3.2: Essential user interface prototyping

3.8 Essential user interface prototyping

An essential user interface prototyping is a low fidelity model, or prototype, of the user
interface for our system. It represents the general idea behind the user interface, but not
the exact details.

25
 Recorder Information

Recorder Id
Input field: used to identify the
recorder.

Recorder Name
Input field: includes Fname,
Mname and Lname.

Display requester
Used to indicate the recorder wants
to display the information.

Student Information
Department Information
Department Name
Input Field: Character only

Department ID
Input Field: Character or Integer

Student Id
Input field: used to identify the student.
Identification number.
26
 Student name
Input field: includes first name, middle
name, last name and etc…

Student address
Input field: includes region, phone No.,
woreda, kebele and house No.etc…

Student status
Display only e.g. graduated, full-time,
part-time.

Payment status Display only e.g. in a good

standing.

Fig 3.3: Essential user interface prototyping

Login Form

27
 User Name
Input field: User Name

Password
Input Field: Password

Login Button
Used to validate users

Cancel Button
Used to close the login screen

Fig 3.4 System User Interface Prototyping for Login Form

Student information form

SID Zone Add Button
Input Field: SID Input Field: Zone Used to add new records
to the data base
28
 Fname Woreda
Input Field: Fname Input Field: Woreda Load Button
Used to load the added
Town data from the data set to
Mname Input Field: Town the data grid
Input Field: Mname
Update Button
Kebele
Lname Used to make some
Input Field: Kebele
Input Field: Lname changes on the database

Sex Phone Search Button

Input Field: Sex Input Field: Phone Used to search data from
the database
Place of Birth
Address
Input Field: Place of Birth Report Button
Input Field: Address
Used to add (Report)
Date of Birth new records to the data
Input Field: Date of Birth University
Input Field: University Close Button
SCID Used to exit from the
Input Field: SCID information screen
Faculity
Nationality Input Field: Faculity Option Button1
Input Field: nationality Used to make the service in
cash
Department
Region
Input Field: Department Option Button2
Input Field: Region
Used to make the service in
kind
DID
Input Field: DID

Fig 3.5: System user interface prototyping for student information form

29
Account form

First name Create account

Input field: First name Used to create an authorized user

Last name
Delete account
Input field: Last name
Used to delete an authorized user
when needed

User name
Input field: User name
Clear
Used to clear the text area of the
form
Password
Input field: Password

Close
Confirm Password Used to exit from the account form
Input field: Confirm
password

Fig 3.6 System User interface prototyping for account form

30
School of preparatory form

Region
SCID
Input field: Region
Input field: SID

Zone
SCName
Input field: Zone
Input field: SCName

Town
Kebele Input field: Town
Input field: kebele

Contact No
woreda Input field: Contact No
Input field: woreda

Update button
Register button
Used to make some changes
Used to register new records
on the database
to the data base

Search button Close button

Used to search data from the Used to exit from the
database information screen

Fig 3.7: System User interface prototyping for school of preparatory

31
Student withdrawal form

WID Sex Region

input field WID input field Sex input field region

SID Place of birth Z one

input field SID input field Place of input field zone etc

YID Search button

Date of birth Used to search data
input field total expense
input field Date of from the database

Exit button
Full Name Nationality
Used to close from the
input field Full Name input field Nationality
information screen

Fig 3.8: System User interface prototyping for student withdrawal

Estimated Cost of the year

32
 YID Add Button
Training Expense
Input field: YID Used to record costs from the beneficiary
input field: Training Expense
Education Expense
Input field: Education Expense Calculate Button
Used to calculate costs Inputted
Food Expense
Input field: Food Expense
Load Button
Dormitory Expense Used to load the added costs on the data
Input field: Dormitory Expense grid

Medical expense Exit Button

Input field: Medical expense Used to exit from the form Board

Total Cost
Input field: Total Cost

Fig 3.9: system user interface prototyping for estimated cost of the year

CHAPTER FOUR

OBJECT ORIENTED ANALYSIS

4. INTRODUCTION
The analysis models of the system are represented with the functional model (Use case
diagram), object model (class diagram) and dynamic model (sequence diagram). A type of
this object oriented analysis model would describe computer software that could be used
to satisfy a set of user-defined requirements.

33
Figure 4.1: System use case diagram

4.1 Use case description

Use case 1: Login
Actor: Recorder

Precondition: The actor (Recorder) must have an account

Post condition: If the system accepts, displays the main form and displays all the necessary information
including reports.

Description: This enables the user to enter (log into) the system.

Flow of events:
1. The actor clicks on login link

2. The system displays the login Page.

3. The actor enters user name and password
4. The system provides page based on their privilege.

34
 5. End use case.

Alternative course of action

3.1 The system displays the login page with error message
3.2 The system resumes at step2.

Use case2: Create account

Actor: System administrator

Precondition: The user should have logged in as an administrator.

Post condition: The administrator manages the user accounts

Description: This is used for managing user accounts

Flow of events
1. The system requests the user name of the new user to be added.
2. The system requests the password of the new user.
3. The system requests the account type of the new user
4. The system searches the record and finds no duplicates.
5. The new user details are added to the recorded.
6. End of the case.

Alternative course of action

1. The system searches the record and finds the username already existing in the record.
2. The system displays error message stating username already exists.
3. The system requests the user to re-enter new username.
4. End use case.

Use case3: Deleting a user accounts.

Actor: System administrator

Precondition: The user should have logged in as Administrator. The user account should already exist
in the record.

Post condition: The user is logout to the system

35
Description: The happens when the user is log out or remove from the system

Flow of events:
1. The Administrator selects the user name which should be removed
from the records
2. The system removes the user details from the record.
3. End use case
Alternative course of action
1. System takes the Administrator to the previous menu.
2. System restores the original access rights for the user.
3. End of the case.
Use case4: Record data
Actor: Recorder

Precondition: The recorder must login.

Post condition: The student record is registered in the system.

Description: Allow recorder to register student cost sharing information.

Flow of events:
1. The recorder selects registration form with respect to their department.
2. The system provides registration form which contains student’s full information and
the regulation requests.
3. The recorder fills student cost sharing information in the form and submits to the
system
4. The system registers the recorded information
5. The system displays acknowledge message
6. The use case ends.
Alternative course of action:

3.1 The system displays an error message

36
 3.2 The system resumes at step 3.
Use case5: Search records

Actor: Recorder, User

Precondition: The student’s data should be available in the data base.

Post condition: If the user or recorder searched the available data and log out to the system.

Description: This is for searching the different type of records under various constraints specified by
the recorder

Flow of events:

1. This is started by clicking the search button.

2. The recorder or user checks the availability of student’s full information.
3. The recorder or user searches the available information
4. The recorder or user exits from the search menu after he gets the required
information.
5. Use case ends
Alternative course of action:

3.1 The recorder checks to the back end

3.2 Error message displays and resumes to back
3.3 Your searching process does not provide full information
3.4 Use case ends

Use case6: update records:

Actor: recorder

Precondition: the updater provided with authentication.

Post condition: The recorder checks and load to the database

Description: This is a way of making any necessary change on the recorded data according to some
conditions.

37
 Flow of events:

1. The recorder identifies the update information.

2. The recorder makes a desired change on the database.
3. The recorder trains the updated information to the user.
4. End use case
Alternative course of action:

3.1 The recorder identifies the update parts significantly.

3.2 The recorder resumes to loading and adding to the current dataset
3.3 End use case

Use case7: Generate report

Actor: Recorder, user, administrator

Precondition: The recorder, user or administrator clicks to the login link page.

Post condition: The manager verifies the consistence and availability of student’s information.

Description: This is to generate various reports of the cost sharing management system. Reports can be
generated under several constraints. This report generates to see either student are filled properly in each
year or general reports

Flow of events:

1. The system displays the form which contains the report menu.
2. The recorder clicks on the statistical menu.
3. The recorder selects the statistical criteria and clicks the report button.
4. The system searches the records and displays the records that match to the
constraints.
5. The system sends the output to the printer to provide with a hard copy of report.
6. The system generates the possible student’s information report and dispatches to
the intended body.
7. The system saves the reports for futures analysis.
8. End of the case.

38
 Alternative course of action

1. The user entered invalid temporal constraints.

2. The system prompts an error message and requests the user to re-enter the constraints.
3. End use case

4.2 Sequence diagram

Sequential diagrams are diagrams that model the sequential logic, in effect, the time
ordering of messages.

A sequence diagram in my system is used to formalize the behavior of the system and to
visualize the communication among objects. It helped us to identify additional objects and
participate in the use case. This phase of the document ties use cases with objects and
shows the behavior of a use case is distributed among its participating objects.

Actor Login Link Login Form Login Control Account Acknowledgement

1. Click ()

2. Fill (User name, Password)

3. Create ()
4. Validate Account ()

5. Create ()
Fig 4.2 Login sequence diagram

Create user Create User

Manager Create user User Account
Account Button Account form
Account controller Data base

1. Click ()

2. Call ()
4. Load ()
39
 5. Create user Account ()

Fig 4.3 Account creation activity diagram

Delete user account Delete user Delete user Delete user

Manager button account control Account form account database

1. Click ()
2. Call ()

4. Load ()

3. Filled form () 40
 5. Delete user account ()

6. Return ()

Fig 4.4 Delete user account sequence diagram

41
 Fig 4.5 Recorder sequence diagram

Recorder Register link Registration control Registration form Cost share record Acknowledge

1. Click ()
2. Create ()

3. Create ()

4. Fills cost sharing data ()

5. Submit ()

6. Add cost sharing Data ()

7. Create ()

42
 Update Record Button Update Record Control Update Record Form Student Database
Recorder

1. Click ()
2. Call ()
4. Load ()

3. Fill Form ()

5. Update Record ()

6. Return ()

Fig 4.6 Updating sequence diagram

43
Recorder, user Generate report Generate Recorded Report display
Report button report form
Administrator control Database form
form

1. Click
() 2. Call
() 3. Load
()

4. Fill the form

()
4. Access from the database ()

5. Return ()

6. Load ()

Fig 4.7 Report generation sequence diagram

44
 Exit button Control exit Conformation Login Form Acknowledge
User message
Message

1.
Click
2. Call 3. Display
() ()

4. Click (yes or
no)
5. Return
()
6.[If no] hide
5. Create
() 7. [If yes] display
()
()

Fig 4.8 Exit sequence diagram

45
CHAPTER FIVE

SYSTEM DESIGN

5. Introduction
Object oriented design is an extension of object oriented analysis, continuing to center the
development focus on object modeling techniques. It will represent object oriented techniques for
designing a new system.

In Object oriented analysis we concentrated on identifying Entity objects which represent the
actual data within the business domain. During object oriented design we continue to refine these
entity objects while identifying other type of objects that will be introduced as the result of physical
implementation decisions for the new system.

Two additional types of objects will be introduced during design. These objects are interface
objects, through which the user will interface with the system and control object, which hold
application or business rule logic.

In this document we have represented the basic design through the different basic UML diagrams,
which includes component, Deployment, Sequence, Activity diagrams and also revision of the class
model modification, user interface flow diagram is included in this document.

System design objectives

 To simplify the implementation phase

 Shows the process of data in the form of diagrams

 Designing user interface

 Create database tables which stores information

 To output design specification documents

46
 5.1 Class diagram

Class model (diagram) shows the classes of the system, their interrelationship and the
operations and attributes of the class. This model is involved further to include classes that
address the solution space as well as the problem space.

In design, we model classes to represent the static structure of how the system will be
built. The major difference between the class model in analysis and the class model in
design is that here the focus is on the solution domain & opposed to the problem domain in
analysis

47
 Student<UI>
Recorder SID: String
RecorderId : Number Fname: String
RecorderName : String Mname: String
Address : String Lname:String
Signature : String Age : number
Sex:String
Add() PlaceOFBirth:String
Delete() DateOfBirth: String
1
Update() AccademicYea : Number
Search() Semester : Number
Load() * Nationality : string
Close() *
Region : string
Zone : String
Woreda : String
1 Town : String
*
Kebele : Number
Administrator Phone : String
AdminName : String 1 Address : String
Password : String University : String
Faculity : String
Create() Department : String
Delete()
DisplayReport() Get Info()

Fig 5.1 Class diagram

5.2 Activity diagram

Activity diagram are used to document the logic of a single operation/method, a single use case, or flow
of logic of business operation. In many ways activity diagram are the object oriented equivalent of flow
charts and data flow diagrams (DFD) from structured development. This part of the project
documentation consists of an activity diagram that depicts the flow of action in two main use cases.

48
 Enter User name
and Password

Display error message

Click()

Login Button

False

True
Open Main
Form

Fig 5.2 Login activity diagram

49
Fig 5.3 Account creation Activity diagram

50
Fig 5.4 Account deletion activity diagram

51
 Manager

Fill()
Account
Form

Click()
Delete Account
button

Access()
Database
Error message display

Yes
Account is not present in the DB

Load()
Account deleted successfully
Account is
deleted

52
Figure 5.5 Search information activity diagram

53
 Recorder

Click()
record form

Fill()
Enter the item to be
updated
Click()
Update record
Display the result to
button
updated and then load

Call()
Database
Display information Message

Yes
No present in DB
Successful()

Figure 5.6 Update recorded information activity diagram

54
 Recorder

Create()
Registration
form

Fill()
Cost sharing data

Click()

Add button

Display information error Message

Successfully added
Yes
If not added to DB

Successfuly to add
Load to the
Database

Figure 5.7 Add records activity diagram

55
 Recorder,User and
administrator

Click()
Report
button

choo...
Parametres

Access()
Database

Yes
No

Display()
Report
form

Figure 5.8 Report activity diagram

56
 Recorder

Click()
exit button

Display()
Conformation
message It resumes to the normal state

No

Yes
Exit form

Figure 5.9 Exit activity diagram

57
 5.3 User interface diagram

Fig. 5.10 Login page user interface diagram

The login page contains the user name and password and users should enter the correct username and
password to get the page that he wants.

 The User enter user name

 The User enter password
 Click ok
 Clicks cancel if he wants to exit.

58
Fig. 5.11 Account form interface diagram
This screen is used to validate users by providing authentication to them and to prevent unauthorized
users from getting into the system and enables to discard unwanted users from the system

 The administrator of the system fills user’s first name, last name, user name and
his password position.
 He clicks create Account button to create user account of the system users.
 Create the user name and password for the users of the system
 If he wants to delete the user’s user name and password he clicks on the delete
account button.
 If he wants to clear he clicks on clear button

59
Fig5.12 student information user interface form

Fig 5.13 school of preparatory user interface form

60
Fig 5.14 student first year form
This form is used to track the estimated cost share of each student in the first year duration in the campus
by considering all necessary operation to calculate the total expense on that year and take considerations
all parameters required then finally create relationship with the main database.

Fig.5.15 student 2nd year form

61
With the same extent with the first year form, this form also provides with the same operations and take
jk

Fig .5.16 student 3rd year form

62
CHAPTER SIX

6. IMPLMENTATION

6.1 Algorithm development

For the login form

If

Username is null or password is null

Error message will be displayed

Else if

Username or password is not correct

Error message will be displayed

Else if

Username or password is correct

Message will be success

End if

63
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
public class SecurityAccessLayer
{
SqlConnection con;
SqlCommand cmd;
SqlDataReader dr;
public SecurityAccessLayer()
{
string cs;
cs = ConfigurationManager.ConnectionStrings["StudentDBcs"].ConnectionString;
con = new SqlConnection(cs);
cmd = new SqlCommand();
cmd.Connection = con;
cmd.CommandType = CommandType.Text;

}
public bool ISUserNameExit(String Uname)
{
cmd.CommandText = String.Format("select count(*)from AcountTable where
UserName='{0}'", Uname);
if (con.State == ConnectionState.Closed)
con.Open();
int count = (int)cmd.ExecuteScalar();
con.Close();

if (count > 0)

return true;
else
return false;

public bool RegisterUser(String Uname, String pwd, String role)

{
if (ISUserNameExit(Uname) == false)
cmd.CommandText = String.Format("insert into AcountTable
values('{0}','{1}','{2}')", Uname, pwd, role);
if (con.State == ConnectionState.Closed)
con.Open();
int count = cmd.ExecuteNonQuery();
con.Close();
if (count > 0)
return true;

64
 else
return false;
}
public bool validateUser(String Uname, String pwd, String role)
{
cmd.CommandText = String.Format("select count(*) from AcountTable where
UserName='{0}'and password='{1}'and Role='{2}'", Uname, pwd, role);
if (con.State == ConnectionState.Closed)
con.Open();
int count = (int)cmd.ExecuteScalar();
con.Close();
if (count > 0)
return true;
else
return false;
}

public bool chnagepassword(String Uname, String npwd, String role)

{
cmd.CommandText = String.Format("update AcountTable set password='{1}'where
UserName='{0}'", Uname, npwd);
if (con.State == ConnectionState.Closed)
con.Open();
int count = cmd.ExecuteNonQuery();
con.Close();
if (count > 0)
return true;
else
return false;
}
public bool RemoveUser(String Uname, String pwd, String role)
{
if (ISUserNameExit(Uname) == true)
cmd.CommandText = String.Format("delete from AcountTable where
UserName='{0}'", Uname);
if (con.State == ConnectionState.Closed)
con.Open();
int count = cmd.ExecuteNonQuery();
con.Close();
if (count > 0)
return true;
else
return false;
}
public SqlDataReader GetAllUsers()
{
cmd.CommandText = String.Format("select * from AcountTable");
if (con.State == ConnectionState.Closed)
con.Open();
dr = cmd.ExecuteReader();
con.Close();

return dr;

}
}

65
public partial class Admin_login : System.Web.UI.Page
{
protected void Page_Load(object sender, EventArgs e)
{

}
protected void Button1_Click(object sender, EventArgs e)
{
string uname, password, role;
uname = txtusername.Text;
password = txtpassword.Text;
role = ddlrole.SelectedItem.Text;
SecurityAccessLayer sal = new SecurityAccessLayer();
if (sal.validateUser(uname, password, role) == true)
{
if (ddlrole.SelectedItem.Text == "Admin")
Response.Redirect("~/Admin/ManageStudent.aspx");
else if (ddlrole.SelectedItem.Text == "User")
Response.Redirect("~/User/Default.aspx");
}
else
lblmsg.Text = "Access Dinied";
}
protected void Button1_Click(object sender, EventArgs e)
{
String Uname, pwd, role;
Uname = txtuname.Text;
pwd = txtpassword.Text;
role = ddlRole.SelectedItem.Text;

SecurityAccessLayer sql = new SecurityAccessLayer();

if (sql.RegisterUser(Uname, pwd, role) == true)
lblmsg.Text = "user register";
else

lblmsg.Text = "user failed register";

}
}

66
 6.2 Conclusion

The project is aimed to develop a computer based student record system.

In the first chapter, to described the background of the cost sharing with the
explanation of how the student cost sharing is organize in terms of the
objectives of the cost sharing ,the problems of the existing system that the cost
sharing faced during accomplished its tasks, the objective of the project, the
scope and limitation of the project, beneficiaries of the project ,feasibility and
work breakdown structure has been discussed including the methodology.

In the other chapter, in requirement analysis the team identified the problems
of the current system, the forms and reports of the existing system. Then we
used an essential use case to model the features of the existing system by
identifying actors and use cases. After requirement analysis I determined the
requirements of the proposed system in terms of functional and non
functional requirements.

Most of the other chapter of the project discussed about object oriented
design which tries to produce the conceptual model of information for the
problem domain that raised on chapter one of the existing system. To
accomplished this task, I used object oriented analysis and design tool
( EDRAW software) and different types of techniques like system use case,
different diagram such as sequence diagram , class diagram and activity
diagram including user interface prototyping that is an extension of the
essential user interface .

67
Finally the project is described clearly theoretically how it was done with
every steps of the system in the manner of the other people can understand
and easy to maintain the system or to modify a particular use case if necessary
or one can add additional functionality on a particular use case.

REFERENCE
1. Citation://www.object oriented analysis and design #object
oriented analysisr.com/
2. Citation:www.sequencediagrameditor.com/uml/seqancediagram.ht
ml.
3. Citation: www.softwere_development_methdology.org

68