Campus Management System: Submitted By: Name Registration No

Campus Management System
Submitted By:
Name Registration No.

Ahsan Shabbir 2014-UKT-0002
Ahsan Ajaz 2014-UKT-0020
Tuba Waris 2014-UKT-0026
Supervised By:
Mr. Zaheed Ahmed
Lecturer
Department of CS & IT
University of Kotli Azad Jummu and Kashmir
Department of Computer Sciences & Information Technology
Faculty of Computing & Engineering
University of Kotli AJ&K

Session: 2014-2018
APPROVAL CERTIFICATE
It is certified that the project work presented in this report entitled “Campus Management
System” submitted by Ahsan Shabbir (2014-UKT-0002), Ahsan Ajaz (2014-UKT-0020),
Tuba Waris (2014-UKT-0026) of Session (2014-18) supervised by Mr. Zaheed Ahmed our
opinion is fully adequate in scope and quality of Bachelor of Science (Computer Science).
Committee
Supervisor
Mr. Zaheed Ahmed
Lecturer,
Department of Computer Science & Information Technology
External Examiner
Chairman
Mr. M. Adnan Arif
Lecturer,
Department of Computer Science & Information Technology
Dean
Mr.Iftikhar Ahmed
Assistant Professor,
Dean Faculty of Computing and Engineering
ii | P a g e
ABSTRACT
____________________________________________________
Project need encompasses the overall need of the system under consideration in the business
domain it is to be marketed or delivered, and how the organization would cope without this
system.
The actual objective of designing the system is to make organizational process to get speed up.
The system acts as a bridge to perform function that is necessary for the Campus Management
process. The project can be used by the University of Kotli AJ&K.
Methods of study is a formal study to decide what type of system can be developed which meet
the needs of the organization and it is the comparison between the old system and the new
system.
The Campus Management System is a web based system where all information and services
that University of Kotli need can be found in one place.
Development of this software also provides knowledge about the latest technology used in
developing web enabled application and client server technology that will be great demand in
future.
iii | P a g e
UNDERTAKING
We declare that this system, neither as a whole nor as a part has been copied from any other
source. It is further declared that we have completed our project entirely on the basis of
our personal effort made under the sincere guidance of our teachers. No portion of the
work presented in this report has been submitted in support of any application for any other
degree or qualification of this or any other university or institute of learning. If any part of this
project and write up is proved to be copied out or there is any duplication of code then I will
be responsible for the consequences.
We declare that research/project work titled “Campus Management System” is my own
work. The work has not been presented elsewhere for assessment. Where material has
been used from other sources it has been properly acknowledged / referred.
Ahsan Shabbir _____________
Ahsan Ajaz________________
Tuba Waris________________
iv | P a g e
ACKNOWLEDGEMENTS
All the praise to Allah, who has blessed us with the courage and knowledge to achieve my goal.
We can never thank Him enough for His countless blessings upon me.
Salam to Prophet Mohammad (S.A.W), who is and will always be a source of guidance and
knowledge for humanity.
For us, a mile stone of this nature would never have been possible to achieve without the
support of galaxy of some truly loving and kind people in my life. No words can fully describe
my feelings of respect and gratitude for my affectionate parents, supporting sibling and friends,
whose love, encouragement and prayers invariably buoyed me up. Their concern, love and
support can never be paid back.
We owe a lot of sincere gratitude to my respected supervisor Mr. Zaheed Ahmed, whose true
guidance, positive criticism and sincere encouragement made me to get to my destination. She
became a source of inspiration for me and kept me moving in the right direction towards my
goal.
Ahsan Shabir
Ahsan Ajaz
Tuba Waris
v|Page
“A TEACHER should inspire a child to reach academic success;
A PARENT should inspire their child to use that success in
a way that influences Positive change in the world.”
Dedicated to
Beloved Parents,
Respected Teachers
&
Lovely Friends.
vi | P a g e
Table of Contents
UNDERTAKING ............................................................................................................................... iv
ACKNOWLEDGEMENTS ............................................................................................................... v
Chapter 1 ................................................................................................................................................ 1
1.0 INTRODUCTION........................................................................................................................... 1
1.1 Purpose....................................................................................................................................... 1
1.2 The Organization ........................................................................................................................ 1
1.3 Project .......................................................................................................................................... 2
1.4 Existing System ........................................................................................................................... 2
1.4.1 Existing System in Brief .......................................................................................................... 2
1.4.2 Drawbacks of Existing System ................................................................................................ 2
1.5 Proposed System ......................................................................................................................... 3
1.6 How will it work? ............................................................................................................................ 3
1.6 Software Process Model.................................................................................................................. 3
Chapter 2 ................................................................................................................................................ 5
2.1 System Conception .......................................................................................................................... 5
2.2 Who is the application for? ............................................................................................................ 5
2.3 What problems will it solve? .......................................................................................................... 5
2.4 Where will it be used?..................................................................................................................... 5
2.5 Why is it needed? ............................................................................................................................ 5
2.6 How will it work? ............................................................................................................................ 6
Chapter 3 ................................................................................................................................................ 7
3.0 PROPOSED SYSTEM ................................................................................................................... 7
3.1 Purpose......................................................................................................................................... 7
3.2 Scope ............................................................................................................................................ 7
3.3 Specific Requirements ................................................................................................................ 8
3.4 Functional Requirements ............................................................................................................... 8
3.4.1 Online Admission ................................................................................................................. 8
3.4.2 Auto merit lists ..................................................................................................................... 8
3.4.3 Auto generate fee challan ........................................................................................................ 8
3.4.4 Add Registration ...................................................................................................................... 8
3.4.5 Delete Record ........................................................................................................................... 8
3.4.6 Update Record.......................................................................................................................... 8
vii | P a g e
3.4.7 Generate results ....................................................................................................................... 8
3.5.1 Registrar Office ........................................................................................................................ 8
3.6 Operating Environment ................................................................................................................. 9
3.7All constraints of a CMS System will be follow............................................................................. 9
3.7 External Interface Requirements .................................................................................................. 9
3.7.1 User Interfaces ............................................................................................................................. 9
3.7.2 Hardware Interfaces .................................................................................................................... 9
3.7.3 Software Interfaces ...................................................................................................................... 9
3.8 System Features ............................................................................................................................ 10
3.9 Other Non-functional Requirements ........................................................................................... 10
3.9.1 Performance Requirements ...................................................................................................... 10
3.9.2 Safety Requirements .................................................................................................................. 10
3.9.3 Security Requirements .............................................................................................................. 10
3.9.4 Business Rules ............................................................................................................................ 10
3.10 Product Requirements ................................................................................................................ 10
3.11 Organizational Requirements .................................................................................................... 11
3.12 External Requirements ............................................................................................................... 11
3.13 System Architecture.................................................................................................................... 11
3.14 System Evolution ......................................................................................................................... 12
3.14.1 How CMS copes with Evolution Issues .................................................................................. 12
Chapter 4 .............................................................................................................................................. 13
4.0 SYSTEM DESIGN ........................................................................................................................ 13
4.1 System Design ................................................................................................................................ 13
4.2 Design Approach ........................................................................................................................... 14
4.3 Database Design ............................................................................................................................ 14
4.4 Conceptual Schema ....................................................................................................................... 14
4.4.1 Class Diagram ............................................................................................................................ 14
4.4.2 Object Diagram .......................................................................................................................... 15
4.4.3 Data Dictionary .......................................................................................................................... 15
4.5 Interaction Model.......................................................................................................................... 17
4.5.1 Use Case Model .......................................................................................................................... 17
4.5.1.1 Actors ....................................................................................................................................... 17
4.5.1.2 Use Cases.................................................................................................................................. 17
4.5.1.3 Use Case Diagrams ................................................................................................................. 17
4.7 Dynamic view or Behavioural view ............................................................................................. 19
4.7.1 Interaction Model....................................................................................................................... 19
viii | P a g e
4.7.2 Use Case Diagram ...................................................................................................................... 20
4.7.3 Use Case Summaries .................................................................................................................. 21
4.7.4.1 Use Case for Login .................................................................................................................. 21
4.7.4.2 Use Case for sign up ................................................................................................................ 22
4.7.4.3 Ad Generate............................................................................................................................. 23
4.7.4.4 Apply for admission ................................................................................................................ 23
4.7.4.5 Verify Student ......................................................................................................................... 24
4.7.4.6 Merit list................................................................................................................................... 24
4.7.4.7 Add course ............................................................................................................................... 24
4.7.4.8 Set Fee Schedule ...................................................................................................................... 25
4.7.4.8 Register student, Register Teacher........................................................................................ 26
4.7.4.9 Register Course ....................................................................................................................... 26
4.7.4.10 Time table .............................................................................................................................. 27
4.7.4.11 Take attendance .................................................................................................................... 28
4.7.4.11 Upload Result ........................................................................................................................ 28
4.8.2 Sequence Diagram for Add Course .......................................................................................... 29
4.8.3 Sequence Diagram for Add Degree Program .......................................................................... 30
4.8.4 Sequence Diagram for Add Generate ...................................................................................... 30
4.8.5 Sequence Diagram for Allocate Time Table ............................................................................ 31
4.8.6 Sequence Diagram for Apply for Admission ........................................................................... 32
4.8.7 Sequence Diagram for Verify the Student ............................................................................... 32
4.8.8 Sequence Diagram for Fee Schedule ........................................................................................ 33
4.8.9 Sequence Diagram for Register Teacher ................................................................................. 33
4.8.10 Sequence Diagram for Course Registration .......................................................................... 34
4.8.11 Sequence Diagram for Attendance ......................................................................................... 34
4.8.12 Sequence Diagram for Merit List ........................................................................................... 35
4.8.13 Sequence Diagram for Result Card ........................................................................................ 35
4.8.13 Sequence Diagram for Upload Result .................................................................................... 36
4.8.14 Sequence Diagram for Print Result ........................................................................................ 36
4.9 Activity Diagram ........................................................................................................................... 37
4.9.1 Activity Diagram for Department ............................................................................................ 37
4.9.3 Activity Diagram for Registrar Office ..................................................................................... 38
4.9.4 Activity Diagram for Teachers ................................................................................................. 40
4.10.1 Chosen Architectural Design .................................................................................................. 41
4.10.2. Presentation tier (UI) .............................................................................................................. 41
4.10.3 Business tier (BAL) .................................................................................................................. 41
ix | P a g e
4.10.4 Data Access Layer (DAL) ........................................................................................................ 41
4.10.5 Advantages of Three-tier Architecture: ................................................................................. 41
4.10.6 Two-tier architecture ............................................................................................................... 41
4.10.6.1 Disadvantages ........................................................................................................................ 42
4.10.7 one-tier architecture ................................................................................................................ 42
4.10.7.1 Disadvantages ........................................................................................................................ 42
4.10.8 Chosen software architecture ................................................................................................. 43
4.10.8.1 Pipes-and-Filters Architecture............................................................................................. 43
4.10.9 Conceptual Design ................................................................................................................... 43
4.10.10 User Mapping ......................................................................................................................... 43
4.11 Physical Schema .......................................................................................................................... 47
4.11.1 Data types and Variable Lengths ........................................................................................... 48
4.11.1.1 Association of Classes & their attributes ............................................................................ 48
4.12 Database Diagram ....................................................................................................................... 51
Chapter 5 .............................................................................................................................................. 53
5.0 SYSTEM IMPLEMENTATION ................................................................................................. 53
5.1 Login Page ..................................................................................................................................... 53
5.2 Dashboard...................................................................................................................................... 53
5.3 SQL Store procedure .................................................................................................................... 54
5.3.1Benefits of using stored procedures ................................................................................... 54
5.3.1.1Ad Generate.......................................................................................................................... 55
5.3.1.2Add Course ........................................................................................................................ 55
5.4 Data Access Layer ......................................................................................................................... 57
CHAPTER 6 .............................................................................................................................. 74
6.0 SYSTEM TESTING AND EVALUATION ................................................................................ 74
6.1 Testing ............................................................................................................................................ 74
6.2 Development Testing .................................................................................................................... 74
6.2.1 Unit Testing ................................................................................................................................ 75
6.2.2 Components Testing .................................................................................................................. 75
6.2.3 System Testing............................................................................................................................ 76
6.3 User Testing ................................................................................................................................... 76
6.4 Test Cases ...................................................................................................................................... 77
6.4.1 Test Case 1: Log In .................................................................................................................... 77
6.4.2 Test Case 2: Add Staff ............................................................................................................... 78
6.4.3 Test Case 3: Apply for Admission ............................................................................................ 79
6.4.4 Test Case 4: Set fee schedule............................................................................................. 81
x|Page
6.4.5 Test Case 5: Course Registration ............................................................................................. 81
6.4.6 Test Case 6: Attendance ............................................................................................................ 82
6.4.7 Test Case 7: Exam sheet ............................................................................................................ 83
Chapter 7 .............................................................................................................................................. 85
7.0 FUTURE EXTENSION................................................................................................................ 85
7.1 Conclusion ..................................................................................................................................... 85
7.2 Future Improvements ................................................................................................................... 85
Chapter 8 .............................................................................................................................................. 86
8.0APPENDICES AND ABBREVIATIONS .................................................................................... 86
Appendices ........................................................................................................................................... 86
Glossary ............................................................................................................................................... 86
REFERENCES .................................................................................................................................... 87
xi | P a g e
List of Figure
Figure 1Waterfall Process Model [Sommerville-2009] ............................................................. 4

Figure 2 Class Diagram of CMS .............................................................................................. 15
Figure 3 Deployment Diagram ................................................................................................ 19
Figure 4 Use Case Diagram ..................................................................................................... 20
Figure 5 Sequence Diagram for Login..................................................................................... 29
Figure 6 sequence for add course............................................................................................. 29
Figure 7sequence for add degree programme .......................................................................... 30
Figure 8 sequence for ad generation ........................................................................................ 31
Figure 9 sequence for allocate time table ................................................................................ 31
Figure 10 Sequence for apply admission ................................................................................. 32
Figure 11 Verify the student ................................................................................................... 32
Figure 12 sequence for set fee schedule .................................................................................. 33
Figure 13 sequence for register teacher ................................................................................... 33
Figure 14sequence for register course ..................................................................................... 34
Figure 15 sequence for check attendance ................................................................................ 34
Figure 16 sequence for merit list ............................................................................................. 35
Figure 17 sequence for result card ........................................................................................... 35
Figure 18 sequence for upload result card ............................................................................... 36
Figure 19 sequence for print result card .................................................................................. 36
Figure 20Activity Diagram for Department ............................................................................. 37
Figure 21Activity Diagram for Admission ................................................................................ 38
Figure 22Activity Diagram for Registrar................................................................................... 39
Figure 23 Mapping diagram ..................................................................................................... 44
Figure 24 Physical structure for person ................................................................................... 48
Figure 25Physical structure for applicant ................................................................................ 49
Figure 26Physical structure for Student ................................................................................. 49
Figure 27 Physical structure for course ................................................................................... 49
Figure 28 Physical structure for Ad ......................................................................................... 50
Figure 29 Physical structure for teacher ................................................................................. 50
Figure 30Physical structure for faculty ................................................................................... 50
Figure 31 Physical structure for merit list ............................................................................... 51
Figure 32 Database Diagram for CMS .................................................................................... 52
Figure 33 Login Page ............................................................................................................... 53
Figure 34 Dashboard ................................................................................................................ 54
Figure 35 verify student .......................................................................................................... 54
xii | P a g e
List of Table
Table 1 List of Risks with their alternative ................................................................................ 6
Table 2 Data dictionary for CMS classes ................................................................................ 16
Table 3 Use Case Summaries .................................................................................................. 18
Table 4 Deploymnet Discription .............................................................................................. 19
Table 5 Test Case for Log ........................................................................................................ 78
Table 6 Test Case for Add staff record to CMS ....................................................................... 79
Table 7 Test Case Add Customer Record ................................................................................ 80
Table 8 Test Case for delete..................................................................................................... 81
Table 9 Test Case for search .................................................................................................. 82
Table 10 Test Case for Update Record .................................................................................... 83
Table 11 Test Case for Searching based on Account Number of a Customer ......................... 84
xiii | P a g e
Chapter 1
__________________________________________________________________________________
1.0 INTRODUCTION
__________________________________________________________________________________
This chapter describes the existing system and the proposed system in details. What
problems we were facing in the existing system, due to which we are going to atomize our
system, are described here? What functionality our system will provide, is described here.
1.1 Purpose
The existing system for Campus Management System is completely manual, the problems with
manual system are obvious that it’s more time taking and tiring. It requires a lot of space for
placement of files stock and searching from that huge volume of files is extensively time taking.
The data could be damaged in case of any accident like fire, flood and files misplacement.
The advantages of computerized over manual systems are obvious and unbeatable. Currently
most of the systems are moved towards computerized system to have a compatibility with
current generation and trends of evolving technologies and working techniques.
Campus Management System for University of Kotli is proposed to be developed for tackling
above mentioned problems. It’ll let the University of Kotli to get rid of the huge volumes of
files with separate backup facility, providing with the facility to be able to insert, delete and
modify records with minor efforts and in less amount of time.
We are going to make a web based system to solve the problems. This application is named
as Campus Management System. Now we have no need to maintain registers because of
database and searching record would be easy. Updating, deleting, and generating documents
will also be easy.
1.2 The Organization

Currently system in University of Kotli AJ&K is manual, physical record keeping and paperwork
is being done.
Even with prolific resources, achieving good results and optimal use of resources is quite a
challenge.
Drawback of the existing system is the wastage of a lot of effort of institute’s personnel, which
otherwise can be used for the accomplishment of some other important task.
1.3 Project
Current system of UOK AJ&K is manual it involves paperwork and use of dispersed information
from different sources. This is cumbersome and time consuming with a waste of personnel
effort.
We intend to upgrade the system and computerize it. The new system would be automated;
it will reduce personnel effort and would save time.
1.4 Existing System

Campus management system of an educational institute with not an ample supply of
resources is admittedly a very difficult task, and to do it manually would take a lot of time and
effort. So, in this section, drawbacks of existing system are discussed.
1.4.1 Existing System in Brief

Existing system refers to the system that is being followed currently. Current system of
management in UOK is manual; it involves paperwork and use of dispersed information from
different sources. This is cumbersome and time consuming with a waste of personnel effort.
 Admission are completely manual.

 Merit list are manual.
 Fee Management are manual
 Attendance management are also manual
1.4.2 Drawbacks of Existing System

 They say ‘Time is Money’ – and yes it is which is very generously and without much
thought is being wasted away in the existing manual campus management system.
 Another very important drawback of the existing system is the wastage of a lot of effort
of institute’s personnel, which otherwise can be used for the accomplishment of some
other important task.
 There is no central repository of information.
 It was time consuming as well as all was manual.
 Much place was required to store data in paper file.
2|Page
 Searching information and difficult task.
1.5 Proposed System

Current process of developing system is very tedious and time consuming process in which
each and every work is being done on paper and each of the process like admission, merit
list, Fee management and attendance they may also arise after the process is complete, so
we can feel the need to computerize the system.
There are certain disadvantages of the current system they are:
 Time Consuming
 Great amount of paper work needed
 Decentralized system
 Complex and difficult to solve clashes
Advantages of the “CMS”:
 Computerized application
 Centralized repository of information
1.6 How will it work?

As the system is a web application, so first we will host system on the web. After its hosting
administrator and user will be login to admin panel to perform their required actions. Admin
will be able to make login for add records, update records, search records, delete records, and
lot of other functions related to University’s purpose.
The system will cover all the aspects of the existing manual system with some extra and
advanced features facilitating the targeted users.
1.6 Software Process Model

Software process model is an abstract representation of a software process, which is a set of
activities that leads to the production of a software product. Some of the generic process models
are waterfall model, evolutionary development and component based software engineering.
For this project, we will follow iterative waterfall process model, because of clear and
unchanging business requirements. The iterative waterfall show in figure 1.
3|Page
Figure 1 Iterative Waterfall Process Model [Sommerville-2009]
4|Page
Chapter 2
__________________________________________________________________________________
2.0 EXISTING SYSTEM ANALYSIS

__________________________________________________________________________________
The existing system of the university is completely manual, the problem with manual system
are quite obvious that it’s more time taking are tiring. It requires a lot of space for placement
of files stock and searching from that hug volume of files is extensively time taking. The data
could be damaged in case of any accident like fire, flood and files misplacement.
2.1 System Conception

Most of the systems start as vague ideas that need more substance. Existing system
analysis become more clear and obvious when we go deep in the answers of these questions.
A good system concept must answer the following question as our system does:
2.2 Who is the application for?

This application is made for University of Kotli Azad Jammu & Kashmir. The stake
holders for this application are University of Kotli AJ&K. The End users for this application is
University of Kotli AJ&K.
2.3 What problems will it solve?

As the existing system is file based system so the problems with that system are obvious such
as huge file volume, security and backup issue, slow searching etc. These issues would be
tackled in this application and some additional features are also provided to make this system
more efficient.
2.4 Where will it be used?

This application would be used in University of Kotli.It’s a kind of new capability that I can
deploy without disrupting the workflow. By providing fundamental and additional features that
will complement the existing system.
2.5 Why is it needed?

This system is needed to make university system more effective and efficient in context
of both cost and time. Searching that record is a hectic routine so if a computerized system is
used instead, search would be better and efficient, on the spot rectification, adaptation of billing
5|Page
process would be possible and its holder will be identified. Possible risks with their alternatives
are listed below:
1. Personnel Risk The other group members will overtake.

2. Schedule Risk Our project is already scheduled we have to deploy this system as soon
as possible and we have supposed to do this project in 2 months and our
schedule will complete this project in 1 and half month if any latency
issue occur we can manage it.
3. Technical Risk We can using prototyping and performing user acceptance test on every
step which assures that the system will be accepted in the end.
4. Technological We proposed system which is a web application and it will work on any
Risk type of PC or laptop.
Table 1 List of Risks with their alternative
2.6 How will it work?

This application would have a multi- tier architecture consisting of three layers of
independence. It would be a web application which would be published. It will have an admin
and user view. The Administrator and User is restricted for updating and deletion of records,
according to business needs, by asking for extra security details like password etc.
6|Page
Chapter 3
_________________________________________________________________________________
3.0 PROPOSED SYSTEM

__________________________________________________________________________________
System requirements are more detailed descriptions of the software system’s functions,
services, and operational constraints. The system requirements document (sometimes called a
functional specification) should define exactly what is to be implemented. It may be part of the
contract between the system buyer and the software Product Perspective
The existing system is manual, the problems with manual system are obvious that is its more
time taking and tiring. It requires a lot of space for placement of files etc. and searching from
that huge volume of files is extensively time taking. The data could be damaged in case of any
accident like fire, flood and files misplacement. The advantages of computerized over manual
systems are obvious and unbeatable. Currently most of the systems are moving towards
computerized systems to have a compatibility with current generation and trends of evolving
technologies and working techniques. Computerized System called Campus Management
System is proposed to be developed for tackling above mentioned problems.
3.1 Purpose
Purpose of this document is to describe the behaviour of the system being developed, its
functional and non-functional requirements, design constraints and other miscellaneous
factors affecting the project. So the document serves as a guide to designers, developers and
testers who are responsible for the engineering of the Campus Management System UOK
project. It should give the engineers all of the information necessary to design, develop and
test the software.
3.2 Scope
This document contains a complete description of the functionality of the CMS project. It
consists of use cases, functional requirements and non-functional requirements, which, taken
together form a complete description of the software.
7|Page
3.3 Specific Requirements
This section of document describes the functional and non-functional requirements of the
system in detail. It describes what compulsory functionality the system would have and what
other features it might support.
3.4 Functional Requirements

These are statements of services the system should provide, how the system should
react to particular inputs, and how the system should behave in particular situations. In some
cases, the functional requirements may also explicitly state what the system should not do. The
functional requirements for a system describe what the system should do. [Sommerville-2009]
3.4.1 Online Admission

Student will be able to apply for admission.
3.4.2 Auto merit lists

Department will generate the merit list of students.
3.4.3 Auto generate fee challan

Student will generate the fee challan for his semester fee.
3.4.4 Add Registration

User will be register data.
3.4.5 Delete Record

User will also be able to delete Students records.
3.4.6 Update Record

User will be able to update the results record of Students.
3.4.7 Generate results

User will be able to issue a results card to a applicant.
3.4.8 Print results card
User can print all the results card.
3.5 User Classes
3.5.1 Registrar Office

Registrar office admin will generate the admission ad for new admission.
3.5.2 Department
8|Page
Department will verify the student, generate the merit list, set fee schedule, course
register etc.
3.5.3 Student
Student will apply in new degree program, generate fee schedule, register course etc
3.5.4 Teacher
Teacher will take the attendance for his student under his course and upload the result
3.6 Operating Environment

Microsoft windows 10
SQL Server
Visual studio
Design and Implementation Constraints
3.7All constraints of a CMS System will be follow.

Assumptions and Dependencies
We assume full support of our supervisor.
Dependencies includes IIS Server, LAN Drivers.
3.7 External Interface Requirements
3.7.1 User Interfaces

UI will be designed in HTML, CSS(Boot strep, JavaScript) using visual studio.
3.7.2 Hardware Interfaces

Client server architecture will be used.
3.7.3 Software Interfaces

Web browser
Communications Interfaces
Part of the system will be using LAN while some feature will require WAN interface(like
online admission)
9|Page
3.8 System Features
 Online Admission
 Auto merit lists
 Auto generate fee challan
 Student Registration
 Teacher Registration
 Examination System Management
3.9 Other Non-functional Requirements
3.9.1 Performance Requirements

System will run 24/7. There will query parallelism.
3.9.2 Safety Requirements

System will be bereft of any possible damage.
3.9.3 Security Requirements

Security will be provided by MAC binding, Data Encryption and Decryption to prevent SQL
injection.
3.9.4 Business Rules

All business rules will be followed.
3.10 Product Requirements

These requirements specify or constrain the behavior of the software. Examples include
performance requirements on how fast the system must execute and how much memory it
requires, reliability requirements that set out the acceptable failure rate, security requirements,
and usability requirements. [Sommerville-2009]
In mine system, minimal navigation through will make its performance better. It is not an
embedded system so memory is not a big issue for mine system, as memory has become very
cheap now days. We are providing a user-friendly interface and mine system will be guiding
the user at every step of performing some task. Mine system will be reliable as I am handling
exceptions in my system. To deal security issues we are using user name and password for
security purposes.
10 | P a g e
3.11 Organizational Requirements
These requirements are broad system requirements derived from policies and
procedures in the customer’s and developer’s organization. Examples include operational
process requirements that define how the system will be used, development process
requirements that specify the programming language, the development environment or process
standards to be used, and environmental requirements that specify the operating environment
of the system. [Sommerville-2009]
For development, we are using these tools:
Database Tool: SQL Server 2012
Development Tools: visual Studio 2012
Programming Language: C sharp, Asp.net
I am using Windows 10 as operating environment. For system usage, the application will be
published.
3.12 External Requirements

This broad heading covers all requirements that are derived from factors external to the
system and its development process. These may include regulatory requirements that set out
what must be done for the system to be approved for use by a regulator, such as a central bank;
legislative requirements that must be followed to ensure that the system operates within the
law; and ethical requirements that ensure that the system will be acceptable to its users and the
public. [Sommerville-2009]
I am developing this system by the demand of University Of Kotli Azad Jammu and Kashmir.
So, department will approve this project as it is their demanding software. Mine application is
being developed for the facilitation of the department; it will not hurt the ethical values of
department.
3.13 System Architecture

System architecture or systems architecture is the conceptual model that defines
the structure, behavior, and more views of a system. An architecture description is a formal
description and representation of a system, organized in a way that supports reasoning about
the structures and behaviors of the system.
11 | P a g e
System architecture can comprise system components, the externally visible properties of those
components, the relationships (e.g. the behavior) between them. It can provide a plan from
which products can be procured, and systems developed, that will work together to implement
the overall system. There have been efforts to formalize languages to describe system
architecture; collectively these are called Architecture Description Languages (ADLs). [Blaha
M, Rumbaugh J-2005]
3.14 System Evolution

This section describes the fundamental assumptions on which the system is based, and
any anticipated changes due to hardware evolution, changing user needs, and so on. This
section is useful for system designers as it may help them avoid design decisions that would
constrain likely future changes to the system. [Sommerville-2009]
3.14.1 How CMS copes with Evolution Issues

CMS documentation will be helpful for coping with any evolution process in billing process
of District Kotli, so I’ve no fear for the evolution of technology and process of billing
12 | P a g e
Chapter 4
__________________________________________________________________________________
4.0 SYSTEM DESIGN

__________________________________________________________________________________
4.1 System Design

Design is the first step in the development phase for any engineered product or system. The
designer’s goal is to produce a model or representation of a class that will later be built.
Beginning, once system requirement has been specified and analysed, system design is the first
of the three technical activities -design, code and test that is required to build and verify
software. This document details out the overall software design.
The importance can be stated with a single word “Quality”. Design is the place where quality
is fostered in software development. Design provides us with representations of software that
can assess for quality. Design is the only way that we can accurately translate a customer’s
view into a finished software product or system. Software design serves as a foundation for all
the software engineering steps that follow. Without a strong design, we risk building an
unstable system that will be difficult to test, one whose quality cannot be assessed until the last
stage.
During design, progressive refinement of data structure, program structure, and procedural
details are developed reviewed and documented. System design can be viewed from either
technical or project management perspective. From the technical point of view, design is
comprised of four activities – architectural design, data structure design, interface design and
procedural design.
The development team devise a high-level strategy, the system architecture, for solving the
application problem. They also establish policies that will serve as a default for the subsequent,
more detailed portions of design. The system designer must decide what performance
characteristics to optimize, choose a strategy of attacking the problem, and make tentative
resource allocations. For example, the system designer might decide that changes to the
workstation screen must be fast and smooth, even when windows are moved or erased, and
choose an appropriate communications protocol and memory buffering strategy.
13 | P a g e
We find it useful to model a system from three related but different perspectives, each
capturing important aspects of the system, but all required for a complete description. The class
model represents the static, structural, “data” aspects of a system. The state model describes
the temporal, behavioural, “control” aspects of a system. The interaction model represents the
collaboration of individual objects, the “interaction” aspects of a system. A typical software
incorporates all the three aspects: it uses data structures (class model), it sequences operations
in time (state model), and it passes data and control among objects (interaction model). [Balaha
M, Rumbaugh J-2005]
A class model captures the static structure of a system by characterizing the objects in
the system, the relationships between the objects, and the attributes and operations for each
class of objects. The class model is the most important of the three models.
4.2 Design Approach

Design approach for this software is conventional, that is, database model used is relational
and on the other side Object Modelling Technique (OMT) is used.
4.3 Database Design

This system would have a database as its data store, so the design of the database is very
important. We chose relational database model for our database. Database design includes
conceptual, logical and physical design phases, which are discussed in this section.
4.4 Conceptual Schema

Conceptual design is about understanding the organization, the real-world modelling; it
captures the essence of the real-world scenario. In this phase, all the important classes of the
system are extracted with their essential attributes and the relationship between them are
established. This results in class diagram.
4.4.1 Class Diagram

Class diagrams provide a graphic notation for modelling classes and their relationships thereby
describing possible objects. Class diagrams are useful both abstract modelling and for
designing actual programs. They are concise, easy to understand, and work well in practice.
We will use class diagrams throughout this book to represent the structure of applications.
14 | P a g e
4.4.2 Object Diagram
We will also occasionally use object diagrams. An object diagram shows individual objects
and their relationships. Object diagrams are helpful for documenting test cases and discussing
examples. A class diagram corresponds to an infinite set of object diagrams. [Balaha M,
Rumbaugh J-2005]
Person
-name
-fatherName RegistratOfficeAdmin
-cnic -username
-address -password
-phoneNo 1
+registerDepartment()
-photo ad * +registerFaculty()
-dateOfBirth +postAd()
-state -adNo
1
-district -lastDate *
-tehsial -entryTestDate
-city -fee
-domicile -fdtionalFee AddmissionScehdule
+crudOpertion() -listNo
ReqClass Programm
-lastDate
-class -ProgramName -displayDate
-subject +crudOpertion() +setAdmissonSchedule()
-reqMarks +updateAdmisstionSchedule()
Application
1 +crudOpertion()
-catageory * 1
-ammount
-year 1
1
-date 1 EntryTestReport
-status -obtainMarke
+apply() 1 Class -totalMark
+updateInformation() -avg
+deleteInformation() * -class
-listNo
+login() -subject
-status
+logout() -obtainMark
-totalMark +crudOpertion()
+crudOpertionl()
1
Teacher
0.1 * -postion
-regNo
-qalification
Course
+takeAttendance()
-courseCode +login()
-courseName +logout()
-lab +checkAttendance()
Student -crh +uploadResult()
-rollNo -proId
-regNo TimeTable
+crudOpertion()
+registration() -roomNo 1
CouserRegistration
+update() -day
-semester 1 -time
+delete()
-date -date
+manageRegisterCourse()
+checkAttendance() +crudOpertion() +crudOpertion()
+genrateFeeChallan()
Department
1
* * -depName *
-userName Attendance
-password -status
* -date
+addDepartment()
+registerCourse() +takeAttendance() *
+verifyStudent() +checkAttendance()
1 +genrateMeritList()
+registerTeacher()
+manageTimeTabel() 1
Session Faculty
+manageCourse()
1 -crudOpertion
-session 1
+crudOpertion() * +registerFaculty()
* FeeSchedule
-tuitionfee
-other
-self
-lastDate *
-semester
+manageFeeschedule()
Figure 2 Class Diagram of CMS
4.4.3 Data Dictionary

Data dictionary for all modelling elements help designers to understand the meaning and
purpose of all modelling elements. Figure below presents a data dictionary for CMS classes:
Description
Class: A class defines the methods and variables in an object, which is a specific
entity in a program or the unit of code representing that entity.
15 | P a g e
Notations
Class Name: The name of the class appears in the first partition. For example,
Person etc.
Class Attributes:
Attributes are shown in the second partition.
The attribute type is can be shown after the colon. But we didn’t show the attribute
type.
Attributes map onto member variables (data members) in code.
Class operations or Methods:
Operations are shown in the third partition. For example, Register () and Login ()
etc.
They are services the class provides.
The return type of a method can be show after the colon at the end of the method
signature. But we didn’t used it.
The return type of method parameters is shown after the colon following the
parameter name. But we didn’t used it into our class diagram.
Operations map onto class methods in code.
Class Relationships: A class may be involved in one or more relationships with
other classes. A relationship can be one of the following types:
Inheritance (or Generalization):
Represents an "is-a" relationship.
An abstract class(Person) name is shown in italics.
Application and Teacher are specializations of Person Class.
A solid line with a hollow arrowhead that point from the child to the parent class.
Simple Association:
We used simple association to link the Teacher class with the inheritance line to
represent that teacher class are also inheriting the Person Class.
Visibility of Class attributes and Operations
+ denotes public attributes and operation.
- denotes private attributes and operation.
# denotes protected attributes and operation.
~ denotes package attributes and operation.
Table 2 Data dictionary for CMS classes
16 | P a g e
4.5 Interaction Model
The interaction model describes how the objects in a system cooperate to achieve
broader results. The interaction model starts with use cases that are then elaborated with
sequence and activity diagrams. A use case focuses on the functionality of a system that is,
what a system does for users. A sequence diagram shows the objects that interact and the time
sequence of their interactions. An activity diagram elaborates important processing steps.
[Balaha M, Rumbaugh J-2005]
4.5.1 Use Case Model

Use case model consists of three things: actors, use cases, use case diagram
4.5.1.1 Actors
An actor is a direct external user of a system, an object or set of objects that
communicates directly with system but that is not part of the system. Each actor represents
those objects that behave way towards the system. [Balaha M, Rumbaugh J-2005]
4.5.1.2 Use Cases

A use case is a coherent piece of functionality that a system can provide by interacting
with various actors. Each use case involves one or more actors as well as the system itself. The
actor needs not all be the persons.
A use case involves a sequence of messages among the system and its actors. Some use
cases have a fixed sequence of messages. More often, however, the message sequence may
have some variations. [Balaha M, Rumbaugh J-2005]
4.5.1.3 Use Case Diagrams

A system involves a set of use cases and a set of actors. Each use case represents a slice of the
functionality the system provides. The set of use cases shows the complete functionality of the
system at some level of detail. Similarly, each actor represents one kind of object for which the
system can perform behaviour. The set of actors represents the complete set of objects that the
system can serve. Objects accumulate behaviour from all the systems with which they interact
as actors. [Balaha M, Rumbaugh J-2005]
17 | P a g e
The system involves a set of use cases like add record, search record, update record, delete
record and some other mention in use diagram with actors like Administrator and User. Simply
use cases define; in how many ways a system can be used or in how many ways a system can
act. Use cases show the complete functionality of the system that it provides.
Use case summaries briefly describe the purpose and working of each use case. Figure given
below presents a use case summary for CMS.
Table 3 Use Case Summaries

4.6 Deployment Diagram
A deployment diagram in the Unified Modeling Language models the physical deployment
of artifacts on nodes.
Login. Administrator and User can login to his respective panels to access his related
functionalities/services.
Logout. Administrator and Users can logout from the system after performing his required
functions and operations.
Add Record. Administrator and User can add a customer record to the system’s database
Search Record. Admin can login to search a record based on account no and CNIC.
Record. Admin can delete a specific record by the permission of the related authority.
Update Record. Admin can update a record from the database by login into the system.
Generate Bill. Admin can generate bill of the customer
Print Bill. Administrator and User can print the bill.
18 | P a g e
Figure 3 Deployment Diagram
Description
In the Deployment diagram shown above showing hardware components ("nodes") and
artifacts. Deployment diagram is showing which software components ("artifacts") run on
each node and how the different pieces are connected incoming network requests over
the HTTP protocol (and several other related protocols). Deployment diagram
includes web server, an application server, and a database server.
Client will open any browser access the website that is deployed on web server perform
different operation and according to his request application server will fetch data from the
database server and send it back to web server. Then web browser will show the result of
user’s query on the user’s node after translated the contents in HTML5.
Table 4 Deployment Description
4.7 Dynamic view or Behavioural view

Behaviour diagrams show the dynamic behaviour of the objects in a system, which can be
described as a series of changes to the system over time. It includes state Model and interaction
Model.
4.7.1 Interaction Model

Interaction diagrams are models that describe how a group of objects collaborate in some
behaviour - typically a single use-case. The diagrams show a number of example objects and
19 | P a g e
the messages that are passed between these objects within the use-case. It includes the Use case
diagram, Sequence diagrams and Activity diagram.
4.7.2 Use Case Diagram

Use case diagram is used to capture the dynamic nature of a system. It consists of use cases,
actors and their relationships. It is used at a high level design to capture the requirements of a
system.
Use Case For CMS
Upload Result Manage Program
Manage Admision ad
Take Attendance
Manage Department
Check Attendance Registrar office
logout
Teacher
Login
Verify Student
Manage Merit list
Apply for
Addmission Manage Teachers
Register Course
Manage fee
Schedules
Student
Check attendance
Manage Courses
Check Result
Manage Timetable
Print result card
«extends» Department
Verify Result
Verify Result
DMC
Reports
<<include>>
Examination Admin Update result <<include>> Result Card
login
logout
Figure 4 Use Case Diagram
20 | P a g e
4.7.3 Use Case Summaries
Login: Registrar office, Department, Examination System teachers and Students will be able to
login to their respective panel.
Logout: Registrar office, Department, Examination System teachers and Students will be able to
logout to their respective panel side by pressing the logout button.
Add Programs: Registrar Office will be able to add the degree program.
Ad Generation: Registrar Office will be able to Post the ad to website relevant to Admission in any
degree program.
Register Department: Registrar Office will be able to register the departments.
Apply for Admission: First of all students create his/her account in the respective panel then he/she
will be able to register himself/herself into any degree program for admission purpose.
Verify Student: Department will be able to verify the student record after checking the necessary
requirements.
Generate Merit List: Department will be able to generate the merit of their students after taking
entry test.
Fee schedule: Department will be able to set the fee scheduling.
Register teacher: Department will be able to register the teacher.
Add Course: Department will be able to add the courses of every degree program.
Course registration: Student will be able register themselves into the courses that they will be
studied in the specific semester.
Allocate Time table: Department will be able to allocate the time table for every degree program.
Take Attendance: teacher will be able to take attendance on daily basis of their relevant course.
Check Attendance: Department, Teacher and students will be able to check attendance.
Upload Results: Teacher will be able to upload the result of their relevant course.
Verify Result: Examination Department and department will be able verify the result.
Result Card: Examination Department and department will be able to generate the result card.
Update Result Card: Examination Department and department will be able to update the result.
4.7.4.1 Use Case for Login

Use Case Login
Summery Admin, teachers and Students will be able to login to their respective panel side
by using his user name and Password.
Actor Admin, teachers and Students
21 | P a g e
Pre-Condition Admin, teachers and Students will be able to login to their respective panel to use
the website
Description Admin, teachers and Students login to their required page in order to perform their
task
Exception Wrong username or Password: if the admin, teachers and Students enter the wrong
user name or password the system ask for valid username and password.
Canceled: If admin, teachers and Students press the cancel button instead of save
button the add degree program will canceled.
Sign out: If the admin, teachers and students press the sign out button the add
degree program will be canceled and the system return back to the login page.
Missing filed: If any text box field is empty the system will ask to enter the data
in all mandatory fields.
Exit: If the admin, teachers and Students press the button exit or ALT+F4 from
keyboard during insertion process without pressing the “Save” button system will
be closed and record will not be inserted.
Post Condition After successfully login to the system admin, teachers and Students enter into
their respective panels.
4.7.4.2 Use Case for sign up

Use Case Register Department
Summery Registrar admin will register the departments.
Actor Registrar admin
Pre-Condition The Registrar office must be login for register the department.
Description The registrar admin will register the departments.
Exception Wrong username or Password: if the registrar admin enter the wrong user name
or password the system ask for valid username and password.
Canceled: If the user press the cancel button instead of save button the register
the department will canceled.
Sign out: If the registrar admin press the sign out button the register new
department will be canceled and the system return back to the login page.
Exit: If the Register admin press the button exit or ALT+F4 from keyboard
during insertion process without pressing the “Save” button system will be
closed and record will not be inserted.
22 | P a g e
Post Condition After successfully add degree program the system prompted a successfully
message.
4.7.4.3 Ad Generate
Use Case Ad Generate
Summery Registrar admin will generate the admission ad
Actor Registrar admin
Pre-Condition The Registrar office must be login for generate the admission ad. The admin office
must define the criteria for every program.
Description The registrar admin will generate the ad for accouenment for the new admistion.
Exception Schedule: if admission schedule is not set the system prompted for set the schedule
like last date for admission, merit list date etc.
Wrong username or Password: if the registrar admin enter the wrong user name or
password the system ask for valid username and password.
Canceled: If the user press the cancel button instead of save button the ad Generate
program will canceled .
Sign out: If the registrar admin press the sign out button the ad generate will be
canceled and the system return back to the login page.
Exit: If the Register admin press the button exit or ALT+F4 from keyboard during
insertion process without pressing the “Generate Ad” button system will be closed
and record will not be inserted.
Post Condition After successfully Generate the add system prompted a successfully message.
4.7.4.4 Apply for admission

Use Case Apply for admission
Summery Student will apply for admission in different degree programs.
Actor Student
Pre-Condition The student must register and enter the academic information.
Description The student will apply for admission in different degree program. The system
match the criatera s
23 | P a g e
Canceled: If the user press the cancel button instead of save button the ad Generate
program will canceled.
Sign out: If the registrar admin press the sign out button the ad generate will be
insertion process without pressing the “Generate Ad” button system will be closed
Post Condition After successfully Generate the add system prompted a successfully message.
4.7.4.5 Verify Student

Use Case Verify Student
Summery Department will able to verify the student under his program.
Actor Department
Pre-Condition The Registrar office must be login.
Description The Department will able to verify the students who are apply for admission. List
of student show for every degree program the department checked the check box
for verify the student
Exception N/A
Post Condition After Verify the student the system will prompt the successfully message.
4.7.4.6 Merit list

Use Case Merit list
Summery Department will able to generate the merit list for admission.
Actor Department
Pre-Condition The department must enter the entry test marks every student for merit list.
Description The department will generate the merit list for new admission. Before generating
the merit list the department must enter the entry test marks.
Exception N/A
Post Condition After generating the merit list new window will open and show the merit list.
4.7.4.7 Add course

Use Case Add course
24 | P a g e
Summery Department will able to add the course for every degree program respective
semester.
Actor Department
Pre-Condition The department must login for adding new course.
Description The Department will add course for every degree program. The Course also
update and delete.
Canceled: If the user press the cancel button instead of save button the add course
will canceled.
Sign out: If the registrar admin press the sign out button the add course will be
insertion process without pressing the “Add course” button system will be closed
4.7.4.8 Set Fee Schedule

Use Case Fee Schedule
Summery Department will able to set the fee schedule for every degree program respective
semester.
Actor Department
Pre-Condition The department must login for set the fee schedule.
Description The Department will set the fee schedule for every degree program respective
semester.
Canceled: If the user press the cancel button instead of save button the set fee
schedule will be canceled.
insertion process without pressing the “Save” button system will be closed and
record will not be inserted.
25 | P a g e
4.7.4.8 Register student, Register Teacher
Use Case Name: Register Student, Register Teacher
Summary: The department will login and from menu bar he can Register student/register teacher
record holder by using register teacher or register student.
Actor: Department
Precondition: The Department will be on his panel main page for using the option of register
teacher/register student.
Post condition: After the Successful registration operation Users will be prompted with a success
message, and returned to the dashboard Panel.
Description: First the user will login and he will be on the main screen of the department panel, from
there he can select the “register teacher/register student” option and will navigate
through different form inserting data into mandatory fields as guided by the interface
being provided to him, after filling data in all forms he will click the button “Register”,
a new Record will be inserted into the database.
Exceptions: Wrong user name or password: If the department enters a wrong password or user name
the systems will ask for valid user name and password.
Cancelled: If the department presses the cancel button instead of submitting details of
the new Record processing will be stopped.
Missing Field: If the department leaves some mandatory fields empty, system will ask
him to enter data in all mandatory fields.
Sign Out: If department presses the sign out button during entering the data about the
registration to be stored, the insertion will fail and system will return back to its general
main page.
Back to main menu: If the department presses the back to main menu button without
entering the details to be stored, system will return to main menu cancelling the insertion
operation.
Exit: If the department presses the button exit or ALT+F4 from keyboard during Record
Insertion process without pressing the “registration” button system will be closed and
4.7.4.9 Register Course

Use Case Name: Register course
Summary: The students register course for every semester that allocated in his degree program.
Actor: Student
26 | P a g e
Precondition: Thee student must login through his account. The department must add the course for
every degree program.
Description: First the user will login and he will be on his panel. Student click the register course
button a new window is opened. He select his semester and a list of course show in table
for his degree program and current selected semester and then he/she click on register
button. After register course system will prompt a successfully message .
Exceptions: Sign Out: If student presses the sign out button during entering the data about the
registration to be stored, the insertion will fail and system will return back to its general
main page.
Back to main menu: If the student presses the back to main menu button without
entering the details to be stored, system will return to main menu cancelling the insertion
operation.
Exit: If the student presses the button exit or ALT+F4 from keyboard during Record
Insertion process without pressing the “registration” button system will be closed and
4.7.4.10 Time table

Use Case Name: Time table allocation
Summary: The department will login and from menu bar he can allocate the time table to his teacher
and course.
Actor: Department
Precondition: The Department will be on his panel main page for using the option of allocate the
timetable.
Description: The department select the allocate time table form department dashboard then
department select the teacher and select course ,select room, select timing and select
day after the he press the allocate time table button. After allocation the system will
prompt a successfully message.
Exceptions: Teacher clash: If the teacher busy that time is selected in time table the system prompt
error message.
Room clash: If the room is busy that time the system prompt error message.
Student clash: If the student that time the system prompt error message.
27 | P a g e
4.7.4.11 Take attendance
Use Case Name: Take Attendance
Summary: The Teacher will take attendance for his class that is allocated his time table.
Actor: Teacher
Precondition: The teacher will be on his panel main page for using the option of take attendance.
Description: After login teacher he press the button take attendance. After pressing the button a new
window will opened he select the class and show the list of student. He check or
unchecked for present and absent after this he press the submit button. The attendance
is tokened.
Exceptions: N/A
4.7.4.11 Upload Result

Use Case Name: Upload Result
Summary: The teacher will login and from menu bar he can upload the result for his subject
Actor: Teacher
Precondition: The Department will be on his panel main page for using the option of upload result.
Description: Teacher will upload the result under his course

Exceptions: If the result already entered the system will generate error
4.8 Sequence Diagrams
A sequence diagram shows the interaction of a system with its actors to perform all or part of
use case.
28 | P a g e
:User :GUI :Database
Enter username and Password
Click on login button

Verify User
Valid
Login Successfull
Figure 5 Sequence Diagram for Login
4.8.2 Sequence Diagram for Add Course
:GUI :Database
:User
RequestForAddCourse()
display course registration form
Enter data
SendData
Added
AddCourseSuccessfull
Figure 6 sequence for add course
29 | P a g e
4.8.3 Sequence Diagram for Add Degree Program
:User
:GUI :Database
RequestForAddDagreeProgram()
Display form
Enter data
SendData
Added
SuccessfulySaved
Figure7sequence for add degree programme
4.8.4 Sequence Diagram for Add Generate
30 | P a g e
RequestForAddGenrate()
SendData
AdGenerated
SucessfullyAdGenrated
Figure 8 sequence for ad generation
4.8.5 Sequence Diagram for Allocate Time Table
:User
:Database
:GUI
Request for AllocateTimeTable()

display timetable form
SendData
Enter data
Valid
AllocateTimeTableSuccessfully
Figure 9 sequence for allocate time table
31 | P a g e
4.8.6 Sequence Diagram for Apply for Admission
:User :Database
:GUI
ApplyForAddmission()
display student registration form
Enter personal data

SendData
successfully
display panel
Request for enter qualification

SendData
successfully added
Apply for degree program
Send Data
Successfully
Display challan form
Figure 10 Sequence for apply admission
4.8.7 Sequence Diagram for Verify the Student
VerifyStudent
RequestForVerifyStudent()
Display verification form
Select class and verify
Successfully
VerifyStudentSuccessfull
Figure 11 Verify the student
32 | P a g e
4.8.8 Sequence Diagram for Fee Schedule
RequestForSetFeeSchedule()
Display form
Set fee Schedule

SetSchedule
Valid
SetScheduleSuccessfull
Figure 12 sequence for set fee schedule
4.8.9 Sequence Diagram for Register Teacher
:GUI :Database
:User
RegisterTeacher()
SendData
Display form
Enter data
Added
RegisterTeacherSuccessfully
Figure 13 sequence for register teacher
33 | P a g e
4.8.10 Sequence Diagram for Course Registration
:GUI :Database
:User
RequestForCourseRegistration()
Display form
Select semester
SendData
Valid
RegisterCourseSuccessfully
Figure 14sequence for register course
4.8.11 Sequence Diagram for Attendance
:User :Database
:GUI
RequestForCheckAttandance()
Display form
Select course SendData
Valid
return attendance report
Figure 15 sequence for check attendance
34 | P a g e
4.8.12 Sequence Diagram for Merit List
:GUI :Database
:User
RequestForGenereteMeritList()
Display form
Select class and catageory
SendData
Generated
return merit list report
Figure 16 sequence for merit list
4.8.13 Sequence Diagram for Result Card
:GUI :Database
:User
RequestForResultCard()
Display form
Select semester
SendData
Valid
return result card
Figure 17 sequence for result card
35 | P a g e
4.8.13 Sequence Diagram for Upload Result
RequestForUploadResult()
display form
select course and enter marks
Send data
Added
return result sheet
Figure 18 sequence for upload result card
4.8.14 Sequence Diagram for Print Result
RequestForPrintResultCard()
Display form
select semester
SendData
Valid
return result card
Figure 19 sequence for print result card
36 | P a g e
4.9 Activity Diagram
Activity Diagram describe the dynamic aspects of the system. Activity diagram is basically a flowchart
to represent the flow from one activity to another activity. The activity can be described as an operation
of the system. Activity diagrams deal with all type of flow control by using different elements such as
fork, join, etc.
4.9.1 Activity Diagram for Department
Login
[no]
[yes]
verify student genrate merit list Register Teacher Add Course set fee schedule Allocate Time Table Verify result
logout
Figure 20Activity Diagram for Department
4.9.2 Activity Diagram for Admission
37 | P a g e
Login
[no]
[yes]
apply for addmision
Apply for another program Genrate challan form Send failure notice
Figure 21Activity Diagram for Admission
4.9.3 Activity Diagram for Registrar Office
38 | P a g e
Login
[no]
[yes]
Add Programm Ad Genrate Registrar office Register Department
Logout
Figure 22Activity Diagram for Registrar
39 | P a g e
4.9.4 Activity Diagram for Teachers
Login
[no]
[yes]
Take Attendance Check Attendance Upload Result
logout
Figure 23 Activity Diagram for Teacher
4.10 SYSTEM ARCHITECTURAL DESIGN

A system architecture or systems architecture is the conceptual model that defines
the structure, behaviour, and more views of a system.
40 | P a g e
4.10.1 Chosen Architectural Design
The Architecture of most of commercial DBMS are available today is mostly based on this
ANSI-SPARC database architecture. ANSI SPARC THREE-TIER architecture has main three
levels:
Presentation Layer (UI Layer)
These three levels provide data abstraction, means hide the low level complexities from end
users .A database system should be efficient in performance and convenient in use.
Using these three levels, it is possible to use complex structures at internal level for efficient
operations and to provide simpler convenient interface at external level.
4.10.2. Presentation tier (UI)

The Presentation Layer is nothing but a user interface that every user sees on your computer, mobile
and Windows screen. The ASP.NET.aspx file is known as the Presentation Layer.
4.10.3 Business tier (BAL)

The Business Access Layer acts as a mediator layer between the Presentation layer and the Data Access
layer. This layer is used to transfer the data between the Presentation Layer and Data Access Layer. This
layer is mainly used for Validations and calculations purposes.
4.10.4 Data Access Layer (DAL)

This layer only communicates with the Business Access Layer. The Data Access Layer contains the
methods that helps a Business Access Layer. The Business Layer class's methods call the Data Access
Layer Class methods to do some required actions with database such as insertion, deletion, updates and
so on. All database related connection codes are written in this layer only such as SQL query, stored
procedure and so on.
4.10.5 Advantages of Three-tier Architecture:

The main objective of it is to provide data abstraction.
Same data can be accessed by different users with different customized views.
The user is not concerned about the physical data storage details.
Physical storage structure can be changed without requiring changes in internal structure of the database
as well as user’s view.
Conceptual structure of the database can be changed without affecting end users.
Discussion of Alternative Design
4.10.6 Two-tier architecture

A two-tier architecture is a software architecture in which a presentation layer or interface runs on a
client, and a data layer or data structure gets stored on a server. Separating these two components into
41 | P a g e
different locations represents a two-tier architecture, as opposed to a single-tier architecture. Other kinds
of multi-tier architectures add additional layers in distributed software design.
4.10.6.1 Disadvantages
Heterogeneous environments/Business environments with rapidly changing rules and regulations are
not suitable since the database server has to handle the business logic which slows down database
performance.
Since client beholds most of the application logic, problems arise in controlling the software version
and re-distributing of new versions.
Security wise this is complicated as users need to have separate login information for every SQL server.
Client tools and SQL middleware implemented in 2-tier environment is proprietary which remains
cautious on long term feasibility.
Scalability: The 2-tier model lacks scalability as it supports only a limited number of users. When
simultaneous client requests increases application performance degrades rapidly due to the fact that
clients necessitate separate connections and CPU memory to proceed.
Dispersion of Applications: Any change in an application should reflect all clients. If higher number of
users exists in the system, it entails substantial administrative overhead.
Change of Database Structure: Most applications used for interaction is dependent on the database
structure creating an issue when re-designing, as they are intimate with the prevailing structure.
4.10.7 one-tier architecture

One-tier architecture involves putting all of the required components for a software application or
technology on a single server or platform.
4.10.7.1 Disadvantages
Do not support remote/ distributed access for data resources.
The cost of deployment is less.eg-development and management cost.
The cost of the central mainframe is high.
Note: Due to all of the disadvantages of these architectures we preferred the three-tier architecture for
our project.
Software Architecture
The foundational software design activity that evaluates and translates software requirements (both
functional and non-functional) into a collection of design elements that specify structural and
42 | P a g e
behavioural aspects of the major components of the system, together with their provided quality and
interrelationships required to support the detailed design and construction of software systems. The
product resulting from such activity.
4.10.8 Chosen software architecture
4.10.8.1 Pipes-and-Filters Architecture

Pipes and filters architecture has independent entities called filters, which perform transformation on
the data inputs they receive. And pipes are the services through which data is being transformed.
Pipes and filter architecture is given below:
Pipe Data
Data Filter Filter Target
Source Pipe
Pipe
Fig: Pipe Line Architecture
4.10.9 Conceptual Design

A conceptual data model identifies the highest-level relationships between the different entities.
Features of conceptual data model include:
Includes the important entities and the relationships among them.
No attribute is specified.
No primary key is specified.
4.10.10 User Mapping
43 | P a g e
Figure 24 Mapping diagram
Person:
Id Nam fatherName cnic address phone photo dateOfBirth

e
Teacher:
pId Position regNo qualification depId

z(reference (reference Department)
Person)
Program:
44 | P a g e
Id Program
Application:
Id proId personId Categor year Date

(reference Programme) (reference Program) y
Class:
Class subject obtainMark totalMark applicationId

(reference Application)
Student:
rollNo ApplicationId regNo SessionId catageory

(reference (reference
Application) Session)
Session:
sessionId Session
Student :
rollNo ApplicationId regNo SessionId catageory

(reference (reference Session)
Application)
Program:
Id Program
45 | P a g e
Course:
courseCode courseName lab Crh ProId

(reference Programme)
Student:
rollNo ApplicationId regNo sessionId catageory

(reference (reference
Allication) Session)
Course:
courseCode courseName lab crh proId

(reference Programme)
RegisterCourse:
studId course date semester

(reference Student)
RegisterCourse:
Id studId course date semester

(reference
Student)
46 | P a g e
Attendance:
registerCourseId TimeTableId status Date

(reference RegisterCourse)
Teacher:
Pid Positi regno qualification DepId

(reference Person) on (reference department)
Course:
courseCode courseName lab Crh ProId

(reference progremme)
TimeTable:
courseId teachId day roomNo time

(reference Course) (reference
Teacher)
4.11 Physical Schema

Physical database design produces the technical specifications that programmers, database
Administrator and Users, and others involved in information systems construction will use
during the implementation phase. Physical database design requires critical decisions that will
affect the performance of the application system like choosing the storage format (called data
type) for each attribute from the logical data model. The format is chosen to minimize storage
space.
47 | P a g e
4.11.1 Data types and Variable Lengths
A data type is a detailed coding scheme recognized by system software, such as a DBMS, for
representing organizational data. The space to store data and the speed required to access data,
related with these data types are of consequence in physical database design.
4.11.1.1 Association of Classes & their attributes

This part describes the relationships between classes and the attributes of the classes
involved in our project.
Person
Figure 25 Physical structure for person
Applicent
48 | P a g e
Figure 26Physical structure for applicant
Student
Figure 27Physical structure for Student
Course
Figure 28 Physical structure for course
Ad
49 | P a g e
Figure 29 Physical structure for Ad
Teacher
Figure 30 Physical structure for teacher
Faculty
Figure 31Physical structure for faculty
Department
Merit List
50 | P a g e
Figure 32 Physical structure for merit list
4.12 Database Diagram

Following is the ERD implemented in SQL Server 2012 after physical design in.
51 | P a g e
Figure 33 Database Diagram for CMS
52 | P a g e
Chapter 5
_________________________________________________________________________________
5.0 SYSTEM IMPLEMENTATION
Implementation is the carrying out, execution, or practice of a plan, a method, or any design,
idea, model, specification, standard or policy for doing something. As such, implementation is
the action that must follow any preliminary thinking in order for something to actually happen.
In an information technology (IT) context, software or hardware implementation encompasses

all the post-sale processes involved in something operating properly in its environment,
including analyzing requirements, installation, configuration, customization, running, testing,
systems integrations, user training, delivery and making necessary changes. The word
"deployment" is sometimes used to mean the same thing.
5.1 Login Page

The user can login by entering his user id and password. The login page is show in fig 34.
Other login like student, department, teacher are same
Figure 34 Login Page
5.2 Dashboard
A dashboard, in website administration, is typically the index page of the control panel for
a website's content management system. Examples include that distributed with the popular
blogging software Word Press, and in the project management website Basecamp.
The dashboard of admin panel is show in fig 35 .
53 | P a g e
Figure 35 Dashboard
Figure 36 verify student
5.3 SQL Store procedure

A stored procedure is a set of Structured Query Language (SQL) statements with an assigned
name, which are stored in a relational database management system as a group, so it can be
reused and shared by multiple programs. Stored procedures can access or modify data in
a database, but it is not tied to a specific database or object, which offers a number of
advantages.
5.3.1Benefits of using stored procedures
A stored procedure provides an important layer of security between the user interface and the
database. It supports security through data access controls because end users may enter or
change data, but do not write procedures. A stored procedure preserves data integrity because
54 | P a g e
information is entered in a consistent manner. It improves productivity because statements in
a stored procedure only must be written once. The store procedure of generate ad are given
below.
5.3.1.1Ad Generate
USE [cms1]
GO
/****** Object: StoredProcedure [dbo].[ad] Script Date: 10/10/2018 2:28:13 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
ALTER proc [dbo].[ad]
@adno varchar(50),
@lastdate varchar(50),
@entrytestdate varchar(50),
@fee varchar(50),
@year varchar(60),
@addtionalfee varchar(50)
as
Declare @num int
Declare @cnt int
begin
select @cnt=COUNT(*) FROM tblAd WHERE adno=@adno
IF(@cnt>0)
BEGIN
set @num=1
END
else
begin
set @num=-1
update tblAd set status='unactive'
insert into tblAd values(@adno,@lastdate,@entrytestdate,@year,@fee,@addtionalfee,'active')
end
select @num as ReturnValue
end
5.3.1.2Add Course
The add new course procedure is given below.
55 | P a g e
USE [cms1]
GO
/****** Object: StoredProcedure [dbo].[addcourse] Script Date: 10/10/2018 2:46:58 PM ******/
SET ANSI_NULLS ON
GO
GO
ALTER proc [dbo].[addcourse]
@program varchar(50),@session varchar(50),
@courseName varchar(50),@courseCode varchar(50),
@lab varchar(50),@crh varchar(50),@semester varchar(5)
as
declare @cnt int
declare @num int
declare @sessionId int
declare @proId int
begin
select @sessionId =session.id from session where session.session=@session
select @proId=tblDegreeProgram.PkId from tblDegreeProgram where program=@program
select @cnt=COUNT(*) from course where courseCode=@courseCode and programId=@proId and
sessionId=@sessionId
if(@cnt>0)
begin
set @num=1;
end
else
begin
set @num=-1;
insert into course values(@courseCode,@courseName,@lab,@crh,@sessionId,@proId,@semester)
end
select @num as returnValues
end
Fee
USE [cms1]
GO
/****** Object: StoredProcedure [dbo].[totalfee] Script Date: 10/10/2018 2:52:34 PM ******/
SET ANSI_NULLS ON
GO
56 | P a g e
GO
ALTER proc [dbo].[totalfee]
@pro varchar(67),
@session varchar(89),
@semester varchar(78)
as begin
SELECT person.*,student.* , studentFee.*, session.*, tblDegreeProgram.*, feeSchedule.*

FROM person INNER JOIN
apply ON person.id = apply.personid INNER JOIN
student ON apply.id = student.applyId INNER JOIN
studentFee ON student.id = studentFee.studentId INNER JOIN
session ON student.sessionId = session.id INNER JOIN
tblDegreeProgram ON apply.proid = tblDegreeProgram.PkId AND student.programId =
tblDegreeProgram.PkId INNER JOIN
feeSchedule ON studentFee.feeId = feeSchedule.id AND session.id = feeSchedule.session AND
tblDegreeProgram.PkId = feeSchedule.proId where studentFee.status='Pay' and tblDegreeProgram.program=@pro and
session.session=@session and feeSchedule.semester=@semester
end
5.4 Data Access Layer

A data access layer in computer software, is a layer of a computer program which provides
simplified access to data stored in persistent storage of some kind, such as an entity-relational
database. This acronym is prevalently used in Microsoft environments.The code of data
access layer are given below.
using System;
using System.Collections.Generic;
using System.Data;
using System.Data.SqlClient;
using System.Linq;
using System.Text;
using System.Threading.Tasks;
namespace DAL
{
public class Class1
{
57 | P a g e
public class clsdataayer {
public String Teacherlogin(String username, String password)
{
SqlCommand cmd = new SqlCommand("teacherlogin", con);
cmd.CommandType = CommandType.StoredProcedure;
//cmd.Parameters.AddWithValue("@facultyName", Te);
cmd.Parameters.Add("@username", SqlDbType.VarChar, 50).Value = username;
cmd.Parameters.Add("@password", SqlDbType.VarChar, 50).Value = password;
con.Open();
String returncode = cmd.ExecuteScalar().ToString();
return returncode;
}
SqlConnection con = new SqlConnection("Data Source=DESKTOP-6FP74H0;Initial Catalog=cms1;Integrated
Security=True");
//registerCourse
public String adminLogin(String username, String password)
{
con.Close();
SqlCommand cmd = new SqlCommand("adminLogin", con);
con.Open();
con.Close();
return returncode;
}
public String AssignTeachercourse(String regno, String coursecoede, String semester,String session)

{
con.Close();
58 | P a g e
SqlCommand cmd = new SqlCommand("assigncourses", con);
cmd.Parameters.Add("@regNo", SqlDbType.VarChar, 50).Value = regno;
cmd.Parameters.Add("@courseCode", SqlDbType.VarChar, 50).Value = coursecoede;
cmd.Parameters.Add("@session", SqlDbType.VarChar, 50).Value = session;
cmd.Parameters.Add("@semester", SqlDbType.VarChar, 50).Value = semester;
con.Open();
con.Close();
return returncode;
}
public String courseRegister(String courseId, String username, String date)
{
con.Close();
SqlCommand cmd = new SqlCommand("registerCourse", con);
cmd.Parameters.Add("@COUSEID", SqlDbType.VarChar, 50).Value = courseId;
cmd.Parameters.Add("@data", SqlDbType.VarChar, 50).Value = date;
con.Open();
con.Close();
return returncode;
}
public String RegisterTeacher(String fname, String lname, String cnic, String address, String image, String contect,
String gender, String email, String dob, String dis, String teh, String state, String city, String provance, String
domicile,String password,String dep,String reg)
{
con.Open();
SqlCommand cmd = new SqlCommand("RegisterTeacher", con);
59 | P a g e
cmd.Parameters.Add("@cnic", SqlDbType.VarChar, 50).Value = cnic;
cmd.Parameters.Add("@Fname", SqlDbType.VarChar, 50).Value = fname;
cmd.Parameters.Add("@lname", SqlDbType.VarChar, 50).Value = lname;

cmd.Parameters.Add("@address", SqlDbType.VarChar, 50).Value = address;
cmd.Parameters.Add("@image", SqlDbType.VarChar, 50).Value = image;
cmd.Parameters.Add("@contect", SqlDbType.VarChar, 50).Value = contect;
cmd.Parameters.Add("@gender", SqlDbType.VarChar, 50).Value = gender;
cmd.Parameters.Add("@email", SqlDbType.VarChar, 50).Value = email;
cmd.Parameters.Add("@dob", SqlDbType.VarChar, 50).Value = dob;
cmd.Parameters.Add("@distr", SqlDbType.VarChar, 50).Value = dis;
cmd.Parameters.Add("@teh", SqlDbType.VarChar, 50).Value = teh;
cmd.Parameters.Add("@city", SqlDbType.VarChar, 50).Value = city;
cmd.Parameters.Add("@provance", SqlDbType.VarChar, 50).Value = provance;
cmd.Parameters.Add("@domicile", SqlDbType.VarChar, 50).Value = domicile;
cmd.Parameters.Add("@department", SqlDbType.VarChar, 50).Value = dep;
cmd.Parameters.Add("@regNo", SqlDbType.VarChar, 50).Value = reg;

con.Close();
return returncode;
}
public String VerifyFeeSchdule(String clas, String session,String rollNo)

{
con.Close();
SqlCommand cmd = new SqlCommand("varifyFee", con);
cmd.Parameters.Add("@class", SqlDbType.VarChar, 50).Value = clas;
cmd.Parameters.Add("@rollNo", SqlDbType.VarChar, 50).Value = rollNo;
60 | P a g e
con.Open();
con.Close();
return returncode;
}
public String GenrateFeechallan(String Username, String date)
{
con.Close();
SqlCommand cmd = new SqlCommand("GenratefeeClallan", con);
cmd.Parameters.Add("@username", SqlDbType.VarChar, 50).Value = Username;
cmd.Parameters.Add("@date", SqlDbType.VarChar, 50).Value = date;
con.Open();
con.Close();
return returncode;
}
public String loginforStudet(String Username, String password)

{
con.Close();
SqlCommand cmd = new SqlCommand("studentloginportal", con);
cmd.Parameters.Add("@username", SqlDbType.VarChar, 50).Value = Username;
con.Open();
61 | P a g e
con.Close();
return returncode;
}
public String Addcourse(String program, String session, String CourseName, String Coursecode, String crh, String
semester, String lab)
{
con.Close();
SqlCommand cmd = new SqlCommand("addcourse", con);
cmd.Parameters.Add("@program", SqlDbType.VarChar, 50).Value = program;
cmd.Parameters.Add("@courseName", SqlDbType.VarChar, 50).Value = CourseName;
cmd.Parameters.Add("@courseCode", SqlDbType.VarChar, 50).Value = Coursecode;
cmd.Parameters.Add("@lab", SqlDbType.VarChar, 50).Value = lab;
cmd.Parameters.Add("@crh", SqlDbType.VarChar, 50).Value = crh;
con.Open();
con.Close();
return returncode;
}
public String SetfeeSchedule(String program, String session, String tutionfee,String otherfee,String lastDate,String
semester,String Self)
{
con.Close();
SqlCommand cmd = new SqlCommand("setfeeSchedule", con);
cmd.Parameters.Add("@tutionFee", SqlDbType.VarChar, 50).Value = tutionfee;
62 | P a g e
cmd.Parameters.Add("@otherfee", SqlDbType.VarChar, 50).Value = otherfee;
cmd.Parameters.Add("@lastDate", SqlDbType.VarChar, 50).Value = lastDate;
cmd.Parameters.Add("@self", SqlDbType.VarChar, 50).Value = Self;
con.Open();
con.Close();
return returncode;
}
public String RegisterStudent(String session,String applyid,String program)
{
con.Close();
SqlCommand cmd = new SqlCommand("registerStudent", con);
cmd.Parameters.Add("@applyId", SqlDbType.VarChar, 50).Value = applyid;
con.Open();
con.Close();
return returncode;
}
public String Addsession(String session)
{
con.Close();
SqlCommand cmd = new SqlCommand("addsession", con);
63 | P a g e
con.Open();
con.Close();
return "Session Saved";
}
public String meritlist(String applyid, String catagroty, String listno)
{
con.Close();
SqlCommand cmd = new SqlCommand("meritlistgenrate", con);
cmd.Parameters.Add("@applyid", SqlDbType.VarChar, 50).Value = applyid;
cmd.Parameters.Add("@catageory", SqlDbType.VarChar, 50).Value = catagroty;
cmd.Parameters.Add("@meritlisno", SqlDbType.VarChar, 50).Value = listno;
con.Open();
con.Close();
return "Meritlist ";
}
public String entrytest(String applyid,String totalMarks,String obtainMarks)
{
con.Close();
SqlCommand cmd = new SqlCommand("entrytestmarks", con);
cmd.Parameters.Add("@applid", SqlDbType.VarChar, 50).Value = applyid;
cmd.Parameters.Add("@toatlMarks", SqlDbType.VarChar, 50).Value = totalMarks;
cmd.Parameters.Add("@obtainMarks", SqlDbType.VarChar, 50).Value = obtainMarks;
con.Open();
64 | P a g e
con.Close();
return "Saved Entry Test Marks";
}
public String varifyapple(String id)
{
con.Close();
SqlCommand cmd = new SqlCommand("verifyapply", con);
cmd.Parameters.Add("@applyId", SqlDbType.VarChar, 50).Value = id;
con.Open();
con.Close();
return "Verifed";
}
public String deplogin(String username, String password)
{
con.Close();
SqlCommand cmd = new SqlCommand("deplogin", con);
cmd.Parameters.Add("@usernaem", SqlDbType.VarChar, 50).Value = username;
con.Open();
con.Close();
return returncode;
}
public String applyforProgram(String cnic, String program, String catageroy, String date)
{
con.Close();
SqlCommand cmd = new SqlCommand("appl", con);
65 | P a g e
cmd.Parameters.Add("@catageory", SqlDbType.VarChar, 50).Value = catageroy;

cmd.Parameters.Add("@date", SqlDbType.VarChar, 50).Value = date;
con.Open();
con.Close();
return returncode;
}
public String updateapply(String fname, String lname, String cnic, String address, String image, String contect,
String gender, String email, String dob, String dis, String teh, String state, String city, String provance, String domicile)
{
con.Open();
SqlCommand cmd = new SqlCommand("updateapply", con);
cmd.Parameters.Add("@Fname", SqlDbType.VarChar, 50).Value = fname;
cmd.Parameters.Add("@lname", SqlDbType.VarChar, 50).Value = lname;

cmd.Parameters.Add("@address", SqlDbType.VarChar, 50).Value = address;
cmd.Parameters.Add("@image", SqlDbType.VarChar, 50).Value = image;
cmd.Parameters.Add("@contect", SqlDbType.VarChar, 50).Value = contect;
cmd.Parameters.Add("@gender", SqlDbType.VarChar, 50).Value = gender;
cmd.Parameters.Add("@dob", SqlDbType.VarChar, 50).Value = dob;
cmd.Parameters.Add("@distr", SqlDbType.VarChar, 50).Value = dis;
cmd.Parameters.Add("@teh", SqlDbType.VarChar, 50).Value = teh;
cmd.Parameters.Add("@city", SqlDbType.VarChar, 50).Value = city;
cmd.Parameters.Add("@provance", SqlDbType.VarChar, 50).Value = provance;
cmd.Parameters.Add("@domicile", SqlDbType.VarChar, 50).Value = domicile;
con.Close();
return returncode;
}
66 | P a g e
public String login(String username, String password)
{
SqlCommand cmd = new SqlCommand("studentLogin", con);
cmd.Parameters.Add("@userName", SqlDbType.VarChar, 50).Value = username;
con.Open();
return returncode;
public String register(String name,String cnic, String email,String password, String contect)
{
SqlCommand cmd = new SqlCommand("reg", con);
cmd.Parameters.Add("@name", SqlDbType.VarChar, 50).Value = name;
cmd.Parameters.Add("@phone", SqlDbType.VarChar, 50).Value = contect;
con.Open();
if (returncode =="1")
{
return "Schedule Already seted";
}
else
{
return returncode.ToString();
}
67 | P a g e
}
public String meritListSchedule(String adno, String lastdate, String displaydate, String listNo)
{
SqlCommand cmd = new SqlCommand("meritListSchedule", con);
cmd.Parameters.Add("@addno", SqlDbType.VarChar, 50).Value = adno;
cmd.Parameters.Add("@listno", SqlDbType.VarChar, 50).Value = listNo;
cmd.Parameters.Add("@displaydate", SqlDbType.VarChar, 50).Value = displaydate;
cmd.Parameters.Add("@lastdate", SqlDbType.VarChar, 50).Value = lastdate;
con.Open();
int returncode = (int)cmd.ExecuteScalar();
if (returncode == 1)
{
return "Schedule Already seted";
}
else
{
return "Saved";
}
public String adGenrate(String adno,String lastdate,String entryTestate,String year,String fee,String adfee)

{
SqlCommand cmd = new SqlCommand("ad", con);
cmd.Parameters.Add("@adno", SqlDbType.VarChar, 50).Value = adno;
cmd.Parameters.Add("@entrytestdate", SqlDbType.VarChar, 50).Value = entryTestate;
cmd.Parameters.Add("@lastdate", SqlDbType.VarChar, 50).Value = lastdate;
cmd.Parameters.Add("@fee", SqlDbType.VarChar, 50).Value = fee;
cmd.Parameters.Add("@addtionalfee", SqlDbType.VarChar, 50).Value =adfee;
cmd.Parameters.Add("@year", SqlDbType.VarChar, 50).Value = year;
68 | P a g e
con.Open();
{
return "Ad No is Already assign";
}
else
{
return "Saved";
}
public String faculty(String facname)

{
SqlCommand cmd = new SqlCommand("faculty", con);
cmd.Parameters.Add("@facultyName", SqlDbType.VarChar, 50).Value = facname;
con.Open();
{
return "Faculty is already saved";
}
else
{
return "Saved";
}
}
public String seths(String catageory,String num,String clas)
{
SqlCommand cmd = new SqlCommand("catageory", con);
69 | P a g e
cmd.Parameters.Add("@catgeorname", SqlDbType.VarChar, 50).Value = catageory;
cmd.Parameters.Add("@seth", SqlDbType.VarChar, 50).Value = num;
cmd.Parameters.Add("@class", SqlDbType.VarChar, 50).Value = clas;
con.Open();
{
return "Catageory is already saved";
}
else
{
return "Saved";
}
}
public String insertDepartment(String facname, String department,String password)
{
SqlCommand cmd = new SqlCommand("department", con);
cmd.Parameters.Add("@depname", SqlDbType.VarChar, 50).Value = department;
cmd.Parameters.Add("@faclatyname", SqlDbType.VarChar, 50).Value = facname;
con.Open();
{
return "Department is already saved";
}
else
{
return "Saved";
}
70 | P a g e
}
public String reclass(String clas, String sub, String mark)
{
SqlCommand cmd = new SqlCommand("requclas", con);
cmd.Parameters.Add("@clss", SqlDbType.VarChar, 50).Value = clas;
cmd.Parameters.Add("@subject", SqlDbType.VarChar, 50).Value = sub;
cmd.Parameters.Add("@marks", SqlDbType.VarChar, 50).Value = mark;
con.Open();
{
return "Class is already saved";
}
else
{
return "Saved";
}
}
public String clasprogram(String clas, String sub, String degre,String pro)
{
SqlCommand cmd = new SqlCommand("claspro", con);
cmd.Parameters.Add("@clas", SqlDbType.VarChar, 50).Value = clas;
cmd.Parameters.Add("@subject", SqlDbType.VarChar, 50).Value = sub;
cmd.Parameters.Add("@pro", SqlDbType.VarChar, 50).Value = pro;
cmd.Parameters.Add("@degree", SqlDbType.VarChar, 50).Value = degre;
con.Open();
71 | P a g e
{
return "Class is already saved";
}
else
{
return "Saved";
}
}
public String insertprogram(String degreeProgram, String department, String clas)
{
SqlCommand cmd = new SqlCommand("degreeProgram", con);
cmd.Parameters.Add("@depname", SqlDbType.VarChar, 50).Value = department;
cmd.Parameters.Add("@class", SqlDbType.VarChar, 50).Value = department;
cmd.Parameters.Add("@programName", SqlDbType.VarChar, 50).Value = degreeProgram;
con.Open();
{
return "Faculty is already saved";
}
else
{
return "Saved";
}
public String addqalifica(String cnic, String cls, String sub,String obtain,String total,String py,String bord)
{
SqlCommand cmd = new SqlCommand("addqalification", con);
72 | P a g e
cmd.Parameters.Add("@class", SqlDbType.VarChar, 50).Value = cls;
cmd.Parameters.Add("@sub", SqlDbType.VarChar, 50).Value = sub;
cmd.Parameters.Add("@obtain", SqlDbType.VarChar, 50)
}
}
73 | P a g e
CHAPTER 6
_________________________________________________________________________________
6.0 SYSTEM TESTING AND EVALUATION

_________________________________________________________________________________
6.1 Testing
Testing is intended to show that a program does what it is intended to do and to discover
program defects before it is put into use. When you test software, you execute a program using
artificial data. You check the results of the test run for errors, anomalies, or information about
the programs non-functional attributes.
The testing process has two distinct goals:
To demonstrate the developer and the customer that the software meets its requirements. For
custom software, this means that there should be at least one test for every requirement in the
requirements document. For generic software products, it means that there should be tests for
all the system features, plus combination of these features, that will be incorporated in the
product release.
To discover situation in which the behaviour of the software is incorrect, undesirable, or does
not conform to its specification. There are consequences of software defects. Defects testing is
concerned with rooting out undesirable system behaviour such as system crashes, unwanted
interactions with other systems, incorrect computations and data corruption.
6.2 Development Testing

Development testing includes all testing activities that are carried out by the team
developing the system. The tester of the software is usually the programmer who developed
that software, although this is not always the case. Some development processes use
programmer/tester pairs (Casamino and Selby, 1998) where each programmer has an
associated tester who develops tests and assists with the testing process. For critical systems, a
more formal process may be used, with a separate testing group within the development team.
They are responsible for developing tests and maintaining detailed records of test results.
During development, testing may be carried out at three levels of granularity:
74 | P a g e
Unit testing, where individual program units or object classes are tested. Unit testing should
focus on testing the functionality of objects or methods.
Component testing, where several individual units are integrated to create composite
components. Component testing should focus on testing component interfaces.
System testing, where some or all the components in a system are integrated and the system is
tested. System testing should focus on testing component interactions.
Development testing is primarily a defect testing process, where the aim of testing is to discover
bugs in the software. It is therefore usually interleaved with debugging— the process of
locating problems with the code and changing the program to fix these problems.
6.2.1 Unit Testing

Unit testing is the process of testing program components, such as methods or object
classes. Individual functions or methods are the simplest type of component. Your tests should
be calls to these routines with different input parameters.
When you are testing object classes, you should design your tests to provide coverage of all
the features of the object. This means that you should:
test all operations associated with the object;
set and check the value of all attributes associated with the object;
Put the object into all possible states. This means that you should simulate all events that cause
a state change.
6.2.2 Components Testing

Software components are often composite components that are made up of several
interacting objects. For example, in the weather station system, the reconfiguration component
includes objects that deal with each aspect of the reconfiguration. You access the functionality
of these objects through the defined component interface. Testing composite components
should therefore focus on showing that the component interface behaves according to its
specification. You can assume that unit tests on the individual objects within the component
have been completed.
75 | P a g e
6.2.3 System Testing
System testing during development involves integrating components to create a version
of the system and then testing the integrated system. System testing checks that components
are compatible, interact correctly and transfer the right data at the right time across their
interfaces. It obviously overlaps with component testing but there are two important
differences:
During system testing, reusable components that have been separately developed and off-the-
shelf systems may be integrated with newly developed components. The complete system is
then tested.
Components developed by different team members or groups may be integrated at this stage.
System testing is a collective rather than an individual process. In some companies, system
testing may involve a separate testing team with no involvement from designers and
programmers.
6.3 User Testing

User or customer testing is a stage in the testing process in which users or customers
provide input and advice on system testing. This may involve formally testing a system that
has been commissioned from an external supplier, or could be an informal process where users
experiment with a new software product to see if they like it and that it does what they need.
User testing is essential, even when comprehensive system and release testing have been
carried out. The reason for this is that influences from the user’s working environment have a
major effect on the reliability, performance, usability, and robustness of a system.
It is practically impossible for a system developer to replicate the system’s working

environment, as tests in the developer’s environment are inevitably artificial. For example, a
system that is intended for use in a hospital is used in a clinical environment where other things
are going on, such as patient emergencies, conversations with relatives, etc. These all affect the
use of a system, but developers cannot include them in their testing environment.
In practice, there are three different types of user testing:
76 | P a g e
Alpha testing, where users of the software work with the development team to test the software
at the developer’s site.
Beta testing, where a release of the software is made available to users to allow them to
experiment and to raise problems that they discover with the system developers.
Acceptance testing, where customers test a system to decide whether it is ready to be accepted
from the system developers and deployed in the customer environment.
6.4 Test Cases

Testing is expensive and time consuming, so it is important that you choose effective
unit test cases. Effectiveness, in this case, means two things:
The test cases should show that, when used as expected, the component that you are testing
does what it is supposed to do.
If there are defects in the component, these should be revealed by test cases. You should
therefore write two kinds of test case. The first of these should reflect normal operation of a
program and should show that the component works. For example, if you are testing a
component that creates and initializes a new patient record, then your test case should show
that the record exists in a database and that its fields have been set as specified. The other kind
of test case should be based on testing experience of where common problems arise. It should
use abnormal inputs to check that these are properly processed and do not crash the component.
[Sommerville-2009]
6.4.1 Test Case 1: Log In
Test Case ID: 01

Test Case Name: Log in
Test Case Description: This test case will examine the login process of a
user.
Dependency or Database connection is required.
Prerequisite: User should have a proper user name and
password provided by the Admin
77 | P a g e
,Department,Student ,Teacher and User with an
active status.
Expected Input: Valid User Name and Password.
Expected flow of User enters information and click on “Log In”

Events: button.
Alternate flow of System is shut down, leaves some mandatory
Events: details missing or quits the system.
Actual Results: User successfully logs in and can use system
functions accordingly.
Expected Results: Log in is carried successfully.
Actor: Admin,Department, Teacher ,Student
Bugs, Errors: None

Estimated time: Less than 1 second.
Table 5 Test Case for Log
6.4.2 Test Case 2: Add Staff

Test Case ID: 02
Test Case Name: Admission ad Generate
Test Case Description: This case examines the process
of generate the admission ad
for new admission.
Dependency or Prerequisite: Database connection is
required
There should be at least one
existing admin with active
status who can add the all
necessary record.
The existing admin has
successfully logged in to the ad
panel.
78 | P a g e
Expected Input: Ad schedule, Register
department, Add Required
classics , Merit list schedule
Actual Results: Successfully staff record is
entered.
Expected Results: Successfully staff record is
entered.
Actor: Admin
Bugs, Errors: None
Table 6 Test Case for Add staff record to CMS
6.4.3 Test Case 3: Apply for Admission
Test Case ID: 03

Test Case Name: Apply for Admission
Test Case Description: This case examines the process of

apply for admission.
Dependency or Prerequisite: Database connection is required.
The new user must register using
email ,Name and phone no.
Expected Input: Personal Information, Academic
Information, Program details.
Expected flow of Events: User will register first then the
user name and password are send
his mobile phone then the user
will complete his personal
information and academic
information after this process the
user will apply for program. .
79 | P a g e
Alternate flow of Events: If the user is not registered and
not logged in then the user cannot
apply for the program.
Actual Results: After apply the program the
system will generate the bank
challan .
Expected Results: Successfully
Actor: User
Bugs, Errors: None
Table 7 Test Case Add Customer Record
80 | P a g e
6.4.4 Test Case 4: Set fee schedule
Test Case ID: 04

Test Case Name: Set fee schedule.
set the fee schedule for different
degree program.
The user must be in department
panel.
Expected Input: Degree program name, session,
fee information
Expected flow of Events: Department enters the details and
click on “save” button and the fee
information shows in
datagridview.
Alternate flow of Events: Login in the department panel.
Actual Results: The student will generate the fee
challan easily
Expected Results: After the submission of fee the
department will be verify the fee
Actor: Department
Bugs, Errors: None
Table 8 Test Case for set fee schedule
6.4.5 Test Case 5: Course Registration
Test Case ID: 05

Test Case Name: Course Registration
Test Case Description: The student will register course.
81 | P a g e
Expected Input: Fee verification
Expected flow of Events: On the student panel the student will
click on the course registration. The
course are show in table and click
on course register button.
Alternate flow of Events: The student must submit the fee and
submit the challan in department.
Actual Results: The course register in degree

program.
Expected Results: The register course are used for
taking attendance and exam sheet.
Actor: Student
Bugs, Errors: None
Table 9 Test Case for course registration
6.4.6 Test Case 6: Attendance
Test Case ID: 06
Test Case Name: Attendance

taking attendance.

There should be at least one
existing teacher with active status
who can provide accounts to
others.
82 | P a g e
The existing teacher has
successfully logged in to the admin
panel.
Expected Input: Select the course from drop down
list.
Expected flow of Events: After take the attendance the user
click the “Take Attendance”
button. The attendance have taken.
Alternate flow of Events: Teacher logouts from the system,
cancels the transaction, leaves
some mandatory details missing or
quits the system.
Actual Results: Successfully attendance is taken.
Expected Results: Successfully record is and the

message is shown
Actor: Teacher
Bugs, Errors: None
Table 10 Test Case for Update Record
6.4.7 Test Case 7: Exam sheet
Test Case ID: 07
Test Case Name: Exam sheet.
Test Case Description: The teacher enter the marks under his
timetable register course.
Expected Input: Course required.
Actor: Teacher
83 | P a g e
Bugs, Errors: None
Table 11 Test Case for Exam sheet
84 | P a g e
Chapter 7
__________________________________________________________________________________
7.0 FUTURE EXTENSION

__________________________________________________________________________________
7.1 Conclusion
It has been a great pleasure for me to work on this demanded project. As this project proved
good for me as it is need of the University of Kotli and also it provided practical knowledge of
not only programming in C sharp and some extent Windows Application and MS SQL Server.
The proposed system is built successfully and it performs according to the requirements
specified in the requirements specification document. System is satisfactorily tested with
example data, it provides intended results.it is found to be bug free as per the testing standards
that are implemented.
7.2 Future Improvements

Enhancement and can be made to the software, files or procedures to meet the emerging requirements.
Since organization systems and the business environment undergo continual changes, the information
system should keep place.
As the system has a database so in future, it can easily be extended to include a management
system that may contain all records. This extension will help the administration to let go the
paper work and do their work with simple clicks.
85 | P a g e
Chapter 8
_____________________________________________________________________________________
8.0APPENDICES AND ABBREVIATIONS

____________________________________________________________________________________
Appendices
These should provide detailed, specific information that is related to the application being
developed; for example, hardware and database descriptions. Hardware requirements define the
minimal and optimal configurations for the system. Database requirements define the logical
organization of the data used by the system and the relationships between data. [Sommerville-
2009]
Glossary
Below a small list of possible abbreviations and definitions used in this document is
presented:
CMS: stands for Campus Management System.
Admin: Admin is an actor which is Administrator and User and will operate all services of the
system
CNIC: Computerized National Identity Card, used to uniquely identify each person of the country.
Preconditions: The state of the system before an operation.
Post Conditions: The state of the system after an operation.
Exceptions: Erroneous and unusual situation in a process or operation.
Markup Languages: C #, Asp.Net.
Query Language: Language for relational databases.
86P a g e
REFERENCES
__________________________________________________________________________________
[Sommerville-2009] Sommerville I. (2009). Software Engineering. United States of America.

Boston Massachusetts. Pearson Education.
[Balaha M, Rumbaugh J-2005] Balaha M, Rumbaugh J. (2005).Object Oriented Modeling and

Design with UML 2.0:UML2. State of India.Noida.Dorling Kindersley (India) Pvt. Ltd.
[1] http://en.wikipedia.org/wiki/systems architectures
[Access Date: 17-8-2018 & Time, 13:15]
[2] https://www.youtube.com/watch?v=hN9xemJYwos
[Access Date: : 17-8-2018 & Time, 1:15]
[3] http://www.omg.org/spec/UML/2.0/
[Access Date: : 17-8-2018 & Time, 3:15]
[4] https://www.youtube.com/watch?v=kEcenFwdads
[Access Date: : 17-8-2018 & Time, 3:15]
86P a g e

Campus Management System: Submitted By: Name Registration No

Încărcat de

Informații document

Descriere originală:

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Campus Management System: Submitted By: Name Registration No

Încărcat de

Drepturi de autor:

Formate disponibile

Campus Management System

Name Registration No.

Department of Computer Sciences & Information Technology

Faculty of Computing & Engineering

University of Kotli AJ&K

Mr. Zaheed Ahmed

Department of Computer Science & Information Technology

Mr. M. Adnan Arif

Department of Computer Science & Information Technology

Dean Faculty of Computing and Engineering

Ahsan Shabbir _____________

A PARENT should inspire their child to use that success in

a way that influences Positive change in the world.”

Figure 1Waterfall Process Model [Sommerville-2009] ............................................................. 4

1.2 The Organization

1.4 Existing System

1.4.1 Existing System in Brief

 Admission are completely manual.

1.4.2 Drawbacks of Existing System

1.5 Proposed System

There are certain disadvantages of the current system they are:

Advantages of the “CMS”:

1.6 How will it work?

1.6 Software Process Model

2.0 EXISTING SYSTEM ANALYSIS

2.1 System Conception

2.2 Who is the application for?

2.3 What problems will it solve?

2.4 Where will it be used?

2.5 Why is it needed?

1. Personnel Risk The other group members will overtake.

2.6 How will it work?

3.0 PROPOSED SYSTEM

3.4 Functional Requirements

3.4.1 Online Admission

3.4.2 Auto merit lists

3.4.3 Auto generate fee challan

3.4.4 Add Registration

3.4.5 Delete Record

3.4.6 Update Record

3.4.7 Generate results

3.4.8 Print results card

User can print all the results card.

3.5 User Classes

3.5.1 Registrar Office

3.6 Operating Environment

3.7All constraints of a CMS System will be follow.

We assume full support of our supervisor.

Dependencies includes IIS Server, LAN Drivers.

3.7 External Interface Requirements

3.7.1 User Interfaces

3.7.2 Hardware Interfaces

3.7.3 Software Interfaces

3.9 Other Non-functional Requirements

3.9.1 Performance Requirements

3.9.2 Safety Requirements

3.9.3 Security Requirements

3.9.4 Business Rules

3.10 Product Requirements

For development, we are using these tools:

Database Tool: SQL Server 2012

Development Tools: visual Studio 2012