Chapter 1

INTRODUCTION

This project “Student Information System” provides us a simple interface for maintenance
of student information. It can be used by educational institutes or colleges to maintain the records
of students easily. Achieving this objective is difficult using a manual system as the information
is scattered, can be redundant and collecting relevant information may be very time consuming.
All these problems are solved using this project. Throughout the project the focus has been on
presenting information in an easy and intelligible manner. The project is very useful for those who
want to know about Student Information Management Systems and want to develop
software’s/websites based on the same concept. The project provides facilities like online
registration and profile creation of students thus reducing paperwork and automating the record
generation process in an educational institution.

The Student Information System (SIS) is a business critical system for the collection,
storage and management of student data. The SIS provides capabilities for entering current and
potential student’s personal data, assessment scores, qualifications, applications, and managing
many other student-related data needs for the institute.

Interest in Student Information System has increased during the recent years not only in
education but also in all areas where resources are managed. Student Information System has
always been a difficult task, but it is more so today than ever before, where administrators uses the
traditional way of filling records on a cabinet. As the population of the students goes up, it is
becoming more complex. Data should be stored in safer places, and can be retrieved easily and
fast when someone needs it. Administrator’s task has becoming more complex, there have been
sfforts to improve the effectiveness of problems solving central to this are quantitative techniques
and electronic devices such as computers. In the field of education, researchers and theorist have
focused intensively in recent years on examining the concepts and use of information to assist
administrators, teachers, principal, hod, students and parents. The emerging needs in most schools
or colleges for accurate and relevant data reliable information strengthen the information system.
As of today information technology is the goal of all programmers because it will lead to a better
and stable life. Information technology is flexible it has many use, discovering, developing,
transforming the world until the technology continue is the importance of system information
system.

To access the Student Information System complete the Student Information System
Access Request form, have it authorized by the relevant individual and return it to Registry:
Student data via internal post for final approval and processing. Note that the form requires you to
enter your name, register number, password, branch and other personal details. All the fields are
compulsory filled by the user of the Student Information System. The common functions of the
Student Information System are

• Handling the admissions process

• Enrolling new students and storing teaching option choices
• Handling records of examinations, assessments, marks, grades and academic progression
• Maintaining records of absences and attendance.
 Chapter 2
SYSTEM ANALYSIS

Object-oriented analysis is concerned with developing software engineering requirements

and specifications that expressed as a system's object, as opposed to the traditional data or
functional views of systems. It is the process of defining the problem in terms of objects: real-
world objects with which the system must interact and candidate software objects used to explore
various solution alternatives. The natural fit of programming objects to real-world objects has a
big impact here.

2.1 SOFTWARE REQUIREMENT SPECIFICATIONS

Software Requirement Specification is the starting point of the software developing activity. As
system grew more complex it became evident that the goal of the entire system cannot be easily
comprehended. Hence the needs for the requirement phase arise. The software project is initiated
by the client needs. The Software Requirement Specification is the means of translating the ideas
of the minds of clients (the input) into a formal document (the output of the requirement phase.)

2.1.1 Purpose:
The document is meant to delineate SYSTEM INFORMATION SYSTEM. So as to serve
sa a guide to the developers on one hand and a software validation document for the prospective
client on the other.
2.1.2 Scope:
We describe what features on in scope of the software and what are not in the scope of the
software to be developed.
In Scope
a) Manage the total system by the system administrator which would include Maintaining the
student details.
b) Giving alerts to the user, if he requests for unauthorized operation.
c) User can access all the files if the corresponding permissions are there.
d) User authentication.
Out of Scope:
a. Feedbacks can’t be given.
2.1.3 Definitions, Acronyms:
 a. SRS: Software requirements specification
b. SIS: STUDENT INFORMATION SYSTEM.
DEFINITIONS:
User:
User capable of carrying out some of the actions. He should be able to view the details of
student and staff.
Administrator:
The administrator must able to login and browse ‘relevant’ details of student and staff. He
must able to check the status of new student and staff and also keeps on monitoring the details of
student and staff.
2.1.5 Overview:
The system will provide an interface to the user view the details of student and staff.

2.1.6 OVERALL DESCRIPTION:

Product Perspective:
SIS is maintain the details of student and staff. document is meant to delineate the features
of SIS, so as to serve as a guide to the developers on one hand and a software validation document
for the prospective client on the other.SIS should be user-friendly, quick to learn, and reliable
software above purpose.SIS is intended to be a stand-alone product and should not depend on the
availability of other software. It should run windows based platform.
Product Function:
SIS should support the following use cases:

Class of Use cases & Description of use cases

Use-cases identified for our system are:
Login:
Login into SIS. Use cases related to user authorization.

User Management:
Users can view their information and search for the details.
DB Management:
The administrator maintains the database of the details of all the users.

User Characteristics:
 The user should know the details of how to connect with system through user id/password.
Principal Actors:
The two principal actors in SIS are “User” and “Administrator”.
2.2 Functional Requirements:
We describe the functional requirements by giving various use cases. A flow of events is a
sequence of truncations (or events) performed by the system. They typically contain very detailed
information, written in terms of what the system should do, not how the system accomplishes the
task. Flow of events are created as separate files or documents in your favorite text editor and then
attached or linked to a use case using the files tab of a model element.

• A flow of events should include:

• When and how the use cases starts and ends.
• Use case/actor interactions.
• Data needed by the use case.
• Normal sequence of events for the use case.
• Alternate or exceptional flows.
2.3 Hardware Requirements:
1. Processor : P-IV
2. Ram : 512 MB.
3. Hard Disk : 80 GB.
2.4 Software Requirements:

1. Operating system : windows XP

2. Web server :Apache Tomcat
3. Web technologies :HTML
4. Scripting languages :JSP
5. Database :MS Access
2.5 Design Constraints:
1. Performance: It should quickly respond to user requests.
2. Reliability: databases should be protected from all types of crashes.
3. Cost: the cost of product development, installation and maintains should be minimum.
2.6 Future Extensions: SIS is intended to be a administrator client software. A possible future
extension would be to make it multi user.

Chapter 3
SYSTEM DESIGN
 Object-oriented design is concerned with developing an object-oriented model of a
software system to implement the identified requirements. It is the process of defining the
components, interfaces, objects, classes, attributes, and operations that will satisfy the
requirements. I am typically start with the candidate objects defined during analysis, but add
much more rigor to their definitions. Then I am adding or change objects as needed to refine a
solution.

3.1 UML Design:

The Unified Modeling Language is a general purpose visual modeling language that is used
to specify, visualize, construct, and document the artifacts of a software system. It captures
decisions and understanding about systems that must be constructed. It is used to understand,
design, browse, configure, maintain, and control information about such systems. The Unified
Modeling Language is very important parts of developing object oriented software and the
software development process. The Unified Modeling Language uses mostly graphical notations
to express the design of software projects. Using the Unified Modeling Language helps project
teams communicate, explore potential designs, and validate the architectural design of the
software. The primary goals in the design of the Unified Modeling Language are:

• Provide users with a ready-to-use, expressive visual modeling language so they can
develop and exchange meaningful models.
• Provide extensibility and specialization mechanisms to extend the core concepts.
• Be independent of particular programming languages and development processes.
• Provide a formal basis for understanding the modeling language.
• Encourage the growth of the object oriented tools market.
• Support higher-level development concepts such as collaborations, frameworks, patterns
and components.
Each Unified Modeling Language diagram is designed to let developers and customers view a
software system from a different perspective and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include.
1. Use Case Diagram
 2. Class Diagram
3. Sequence Diagram
4. Activity Diagram
5. Component Diagram
Use Case Diagram

A use case diagram shows a set of use cases and actors (a role of a class) and their
relationships. Use case diagrams address the static use case view of a system. These diagrams are
especially important in organizing and modeling the behaviors of a system.
A use case diagram commonly contain

• Use cases
• Actors
• Dependency, generalization and association relationships.
A Use case diagram may also contain packages, which are used to group elements of the model
into larger chunks.

Use case diagram is used in one of two ways.

• To model the context of a system.

• To model the requirements of a system.

Modeling Procedures:

1. Identify the actors that surround the system by considering which groups require help from
the system to perform their tasks; which groups are needed to execute the systems
functions, which groups interact with external hardware or other software systems; and
which groups perform secondary functions for administration and maintenance.
2. Organize actors that are similar to one another in a generalization\ specialization
hierarchy.
3. Where it aids understandability, provide a stereotype for each such actor.
4. Populate a use case diagram with these actors and specify the paths of communication from
each other to the systems use cases.
5. In it’s simplest form, a use case can be described as a specific way of using the system
from a user’s(actor’s)perspective.
A more detailed description might characterize a use case as:

• A pattern of behavior the system exhibits

• A sequence of related transactions performed by an actor and the
• Delivering something of value to the actor.

Use case provide a means to:

• Capture system requirement

• Communicate with the end users and domain experts
• Test the system.

3.1.1 CONSTRUCTION OF USE-CASE DIAGRAM

Use case diagrams graphically depict system behavior (use cases).These diagrams present
a high level view of the system is used as viewed from an outsider’s(actor’s) perspective. A use
case diagram may depict all or sum of the use cases of a system.
A use case diagram can contains :
Actors (“things” outside the system)
Use cases (system boundaries identifying what the system should do)
Interactions or relationships between actors and use cases in the system include the
associations, dependencies, and generalizations.
USES ASSOCIATIONS:

The uses association occurs when we are describing our use-cases and notice that some of
them have sub flows in common. To avoid describing a sub flow mare then once in several use-
cases, you can extract the common sub flow and make it a use-cases of its own. This new use-case
then can be used by other use-cases.The relationships among the other use-cases and this new
extracted use-case are called uses association.

EXTENDS ASSOCIATION:
 Ann extends association is a stereotyped association that specifies how the functionality of
one use case can be inserted into the functionality of another use case. Extend relationships
between use cases are modeled as dependencies by using the Extend stereotype.

INCLUDE ASSOCIATION:

An includes association is a stereo typed association that connects a base use case to an
inclusion use-case.

MAIN USE CASE DIAGRAM:

login

student
adduser

hod
deleteuser
administrator

principal details

staff changepassword

logout

Fig3.1.1. Use case diagram for student information system

SUB USE CASE DIAGRAM:

adddetails
student

administrator

viewdetails
hod

updatedetails database
principal

faculity modifydetails

Fig4.1. 2. Sub use case diagram for details

3.1.2 IDENTIFICATION OF RELATIONSHIPS OF CLASSES

Class Diagram

A class diagram shows a set of classes, interfaces, and collaborations and their
relationships. These diagrams are the most common diagrams found in modeling object-oriented
systems. Class diagrams address the static design view of a system. Class diagrams that include
active classes address the static process view of a system. Component diagrams are variants of
class diagrams.
Class diagram commonly contains the following things:
• Classes
• Interfaces
• Collaborations
• Dependency, generalization and association relationships
Class diagrams may also contain packages or sub systems both of which also contain packages or
subsystems, both of which are used to group elements of the model into layer chunks.
Class diagrams are used in one of 3 ways:
To model the vocabulary of system.
To model simple collaborations
To model a logical database schema.

Modeling Procedures:
When creating a class diagram, just model a part of the things and relationships that make
up system design view. For this reason, each class diagram should focus on, one collaboration at
time.
Identify the mechanism that would like to model. A mechanism represents some function
or behavior of the part of the system which are modeling results from the interaction of a society
of classes, interfaces and other things.
For each mechanism, identify the classes, interfaces, and other collaborations that
participate in this collaboration. Identify the relationships among these things as well.
Be sure to populate these elements with their contents. For classes, start with getting a good balance
of responsibilities. Then, overtime, turn these into concrete attribute and operations.
Class Diagram:

3.2.1. class diagram for student information system

3.1.3 CONSTRUCTION OF SEQUENCE DIAGRAM:

A sequence diagram is graphical view of scenario that shows object interaction in a time-
based sequence what Happens first, what happens next. Sequence diagrams establish the roles of
objects and help provide essential information to determine class responsibilities and interfaces.

The following tools located on the sequence diagram toolbox which enable to model
sequence diagrams.

➢ Object: an object has state, behavior, and identity. The structure and behavior of similar
objects are defined in their common classes. Each object in a diagram indicates some
instance of the same class. An object that is not named is referred to as a class instance.
➢ Message Icons: A message icon represents the communication between objects indicating
that an action will follow. The message icon is a horizontal, solid arrow connecting two
lifelines together.
➢ Focus of Control: Focus of control (FOC) is an advanced notational technique that
enhances sequence diagrams. It shows the period of time during which an object is
performing an action, either directly or through an underlying procedure.
➢ Message to Self: A message to self is a tool that sends a message from one object back to
the same object. It does not involve other objects because the message returns to the same
object. The sender of a message is the same as the receiver.
➢ Note: A note captures the assumptions and decisions applied during analysis and design.
Notes may contain any information, including plain text, fragments of code, or references
to other document.
➢ Note Anchor: A note anchor connects a note to the element that it affects.
Sequence Diagrams:

details marks attendence database

student
view details
1: 2: verification

3: verified
4: success/failure

5: view marks 6: verification

7: verified
8: success/failure

9: view attendence 10: verification

11: verified

12: success/failure

Fig3.3.1. Sequence diagram for student

user marks attendence database

administrator

1: add user
2: verification

3: verified
4: success/failure

5: delete user 6: verification

7: verified
8: success/failure

9: add/view/update marks 10: verification

11: verified
12: success/failure

13: add/view/update attendence 14: verification

15: verified
16: success/failure

Fig3.3.2.Sequence Diagram For Administrator

 details marks attendence database

hod
1: view details 2: verification

3: verified
4: success/failure

5: add/view/update marks 6: verification

7: verified

8: success/failure

9: add/view/update attendence 10: verification

11: verified
12: success/failure

Fig3.3.3.Sequence Diagram For Hod

details marks attendence database

principal

1: view details 2: verification

3: verified
4: success/failure

5: add/view/update marks 6: verification

7: verified
8: success/failure

9: add/view/update attendence 10: verification

11: verified
12: success/failure
 Fig3.3.4. Sequence diagram for principal

details marks attendence database

staff
1: view details 2: verification

3: verified
4: success/failure

5: view marks 6: verification

7: verified
8: success/failure

9: view attendence 10: verification

11: verified

12: success/failure

Fig.3.3.5.Sequence Diagram For Staff

3.1.4 UML ACTIVITY DIAGRAM

An Activity diagram shows the flow from activity to activity. An activity is a going non-
atomic execution within a state machine. An activity results in some action, results in a change of
state or return of a value. Action encompasses calling operation, sending a signal, creating or
destroying objects, or a pure computation such as evaluating some expression. Activity diagram
commonly contains

1. activity states and action states

2. transitions
3. Objects, it may contains nodes and constraints.
Activity states and action states:
An executable atomic computation is called action state, which cannot be decomposed.
They rendered as lozenge shape. Activity state is non atomic, decomposable and take some
duration to execute.
Transition:
It is the path from one state to the next state, represented as simple directed line.
Branching:
When alternate paths exist, branching arises which is represented by open diamond. It has
one incoming transition, two or more out going transitions.
Forking and joining:
The Synchronization bar, when splits one flow into two or more flows is called Fork. When
two or more flows are combined at synchronization bar, the bar is called Join.
Swim lanes:
Grouped work flow is called swing lane. All groups are portioned by vertical solid lines.
Each swim lane specifies locus of activities and has a unique name. Each swim lane is implemented
by one or more classes. Transition may occur between objects across swim lanes.
Activity Diagram:

Start

Yes Register No

Fill the form

Enter Verification
Valid Not valid
Username&password

Not valid Verification

valid

Student Staff

View his/her View Student Hod Principal Administrator

details details

Modify marks
&attendance View student
details

Add/delete Update/add
Student/staff details

Database
Updation

End

Fig3.4.1. Activity Diagram For SIS

3.1.5 CONSTRUCTION OF UML STATE CHART DIAGRAM

State chart diagrams model the dynamic behavior of individual classes or any other kind
of object. They show the Sequences of states that an object goes through, the events that cause a
transaction from one state to another and the actions that result from a state change.

State chart diagrams are closely related to activity diagrams. The main difference between
the two diagrams are state centric, while activity diagrams are activity centric. A state chart
diagram is typically used to model the discrete stages of an objects lifetime, where as an activity
diagram is better suited to model the sequence of activities in a process.

Each state represents a method condition during the life of an object during which it
satisfies some condition or waits for an event. State chart diagram typically contains one start state
and end states. Transactions connect the various states on the diagram.

The following tools are used on the state chart diagram toolbox to model state chart diagrams:

➢ Decisions: A decision represents a specific location on state chart diagram where the
workflow may branch based upon guard conditions.
➢ Synchronizations: Synchronizations visually define forks and joins representing parallel
workflow.
➢ Forks and Joins: A fork construct is used to model a single flow of control that divides
into two of more flows of control that unite into a single flow of control.
➢ States: A state represents a condition or situation during the life of an object during which
it satisfies some condition or waits for some event.
➢ Transactions: A state transaction indicates that an object in the source state will perform
certain specified actions and enter the destination sate when a specified event occurs or
when certain conditions are satisfied.
➢ Start States: A start state (also called an “initial state”) explicitly shows the beginning of
a work flow.
➢ End States: An end state represents a final or terminal state.
State chart Diagram:

registration

login failed

login

login success
enable
connection

connection ok

select required
option

request ok
perform operation failed display error
message

success
view/add/update
details

database

Fig3.5.1. State Chart Diagram For Student Information System