0% found this document useful (0 votes)
96 views95 pages

Se-Final Lab Manual

Uploaded by

Satish Babu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
96 views95 pages

Se-Final Lab Manual

Uploaded by

Satish Babu
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 95

Department of Computer Science and Engineering

B.Tech III-year-I-Semester-CSE

Lab Manual

Academic Year 2022-2023

CS505PC-Software Engineering Lab (R-18)

Verified by HOD-CSE

JYOTHISHMATHI INSTITUTE OF TECHNOLOGY & SCIENCE


(Approved by AICTE, New Delhi, Affiliated to
JNTUH, Hyderabad)
NUSTULAPUR,KARIMNAGAR- 505481,
TELANGANA, INDIA
R18 B.Tech. CSE Syllabus JNTU HYDERABAD
CS505PC: SOFTWARE ENGINEERING LAB

III Year B.Tech. CSE I-Sem


LTPC
0 0 3 1.5
Prerequisites
1. A course on “Programming for Problem Solving”
Co-requisite
1. A Course on “Software Engineering”
Course Objectives:
To have hands on experience in developing a software project by using various software
engineering principles and methods in each of the phases of software development.
Course Outcomes:
Ability to translate end-user requirements into system and software requirements
Ability to generate a high-level design of the system from the software requirements
Will have experience and/or awareness of testing problems and will be able to develop a simple
testing report
List of Experiments
Do the following 8 exercises, for any two projects given in the list of sample projects or any
other projects:

1. Development of problem statement.


2. Preparation of Software Requirement Specification Document, Design Documents and Testing
Phase related documents.
3. Preparation of Software Configuration Management and Risk Management related documents.
4. Study and usage of any Design phase CASE tool
5. Performing the Design by using any Design phase CASE tools.
6. Develop test cases for unit testing and integration testing
7. Develop test cases for various white box and black box testing techniques.

Sample Projects:
1. Passport automation System
2. Book Bank
3. Online Exam Registration
4. Stock Maintenance System
5. Online course reservation system
6. E-ticketing
7. Software Personnel Management System
8. Credit Card Processing
9. E-book management System.
10. Recruitment system

TEXT BOOKS:
1. Software Engineering, A practitioner’s Approach- Roger S. Pressman, 6th edition, Mc Graw
Hill International Edition.
2. Software Engineering- Sommerville, 7th edition, Pearson Education.
3. The unified modeling language user guide Grady Booch, James Rambaugh, Ivar Jacobson,
Pearson Education.
1 How To: Write A Problem Statement

OUTLINE

A problem statement is usually one or two sentences to explain the problem your process
improvement
project will address. In general, a problem statement will outline the negative points of the
current situation and explain why this matters. It also serves as a great communication tool,
helping to get buying and support from others.

BACKGROUND

One of the most important goals of any problem statement is to define the problem being
addressed in a way that's clear and precise. Its aim is focus the process improvement team’s
activities and steer the scope of the project.

Creation of a problem statement is an activity that is best completed in a small group (46 people).
It is helpful to have a couple of people who are involved in the process and a process owner
involved in the activity.
1. Get each person to write his or her own problem statement without conferring. Compare
each of the sentences/ looking for common themes and wording.
2. Start to write an improved statement using the common themes.
3. Ensure that the problems include the customer’s perspective
4. Ensure that the statement focuses on existing problems.
5. Try to include the time frame over which the problem has been occurring.
6. Try to quantify the problem. If you do not have the data to hand, defer writing the final
problem statement until you have been able to quantify the problem.

You should be able to apply the 5 'W's (Who, What, Where, When and Why) to the problem
statement.

A problem statement can be refined as you start to further investigate root cause.

Finally, review your new problem statement against the following criteria:
● It should focus on only one problem.
● It should be one or two sentences long.
● It should not suggest a solution.

An example problem statement:


The staffing model in the Process Improvement Unit (PIU) has changed (we have more staff, and
some of the staff have different working patterns) we need to have a clear way of recording
status and stage of our business activities (projects, workshops and training) that will be used by
all PIU staff, so that we can work effectively and provide good service to our customers. A
member of staff is due to go on annual leave in two weeks time and we have no visibility or way
of easily sharing information about their work, this will make it hard for the rest of the team to
cover the work during staff absence.
2 Software Requirement Specification (SRS)

Objectives
Gain a deeper understanding of the Software Requirement Specification phase
and the Software Requirement Specification (SRS).
Learn how to write requirements and specifications.
Gain exposure to requirements management using RequisitePro.

Outline
Review of the requirements engineering process.
Write requirements and specifications.
Requisite Pro tutorial.
Software Requirement Specification (SRS).

Background
A requirement is a statement of a behavior or attribute that a system must possess for the
system to be acceptable to a stakeholder.
Software Requirement Specification (SRS) is a document that describes the requirements of a
computer system from the user's point of view. An SRS document specifies:
The required behavior of a system in terms of: input data, required processing, output data,
operational scenarios and interfaces.
The attributes of a system including: performance, security, maintainability, reliability,
availability, safety requirements and design constraints.
Requirements management is a systematic approach to eliciting, organizing and documenting
the requirements of a system. It is a process that establishes and maintains agreement between
the customer and the project team on the changing requirements of a system.
Requirements management is important because, by organizing and tracking the
requirements and managing the requirement changes, you improve the chances of completing
the project on time and under budget. Poor change management is a key cause of project
failure.
Requirements Engineering Process
Requirements engineering process consists of four phases:
Requirements elicitation: getting the customers to state exactly what the requirements are.
Requirements analysis: making qualitative judgments and checking for consistency and
feasibility of requirements.
Requirements validation: demonstrating that the requirements define the system that the
customer really wants.
Requirements management: the process of managing changing requirements during the
requirements engineering process and system development, and identifying missing and extra
requirements.

2. WRITING REQUIREMENTS
Recommendations When Writing Requirements
Never assume: others do now know what you have in mind.
Use meaningful words; avoid words like: process, manage, perform, handle, and support.
State requirements not features:
Feature: general, tested only for existence.
Requirement: specific, testable, measurable.
Avoid:
Conjunctions: ask yourself whether the requirement should it be split into two requirements.
Conditionals: if, else, but, except, although.
Possibilities: may, might, probably, usually.

Writing Specifications
Specification is a description of operations and attributes of a system. It can be a document,
set of documents, a database of design information, a prototype, diagrams or any combination of
these things.
Specifications are different from requirements: specifications are sufficiently complete ─ not
only what stakeholders say they want; usually, they have no conflicts; they describe the system
as it will be built and resolve any conflicting requirements.
Creating specifications is important. However, you may not create specifications if:
You are using a very incremental development process (small changes).
You are building research or proof of concept projects.
You rebuilding very small projects.
It is not cheaper or faster than building the product.
Software Requirement Specification (SRS)
Remember that there is no “Perfect SRS”. However, SRS should be:
Correct: each requirement represents something required by the target system.
Unambiguous: every requirement in SRS has only one interpretation
Complete: everything the target system should do is included in SRS (no sections are marked
TBD-to be determined).
Verifiable: there exists some finite process with which a person/machine can check that the
actual as-built software product meets the requirements.
Consistent in behavior and terms.
Understandable by customers.
Modifiable: changes can be made easily, completely and consistently.
Design independent: doesn't imply specific software architecture or algorithm.
Concise: shorter is better.
Organized: requirements in SRS are easy to locate; related requirements are together.
Traceable: each requirement is able to be referenced for later use (by the using paragraph
numbers, one requirement in each paragraph, or by using convention for indication requirements)

3. What is Software Configuration Management?


OUTLINE
In Software Engineering, Software Configuration Management(SCM) is a process to
systematically manage, organize, and control the changes in the documents, codes, and
other entities during the Software Development Life Cycle. The primary goal is to
increase productivity with minimal mistakes. SCM is part of cross-disciplinary field of
configuration management and it can accurately determine who made which revision.
BACKGROUND
The primary reasons for Implementing Technical Software Configuration Management
System are:
There are multiple people working on software which is continually updating
It may be a case where multiple version, branches, authors are involved in a software
configuration project, and the team is geographically distributed and works concurrently
Changes in user requirement, policy, budget, schedule need to be accommodated.
Software should able to run on various machines and Operating Systems
Helps to develop coordination among stakeholders
SCM process is also beneficial to control the costs involved in making changes to a
system, any change in the software configuration Items will affect the final product.
Therefore, changes to configuration items need to be controlled and managed.
Tasks in SCM process

Configuration Identification
Baselines
Change Control
Configuration Status Accounting
Configuration Audits and Reviews
What is Risk Management?

Risk management is the process of identifying, assessing, and prioritizing the risks to
minimize, monitor, and control the probability of unfortunate events.
Risk Management Process:

Risk Management process can be easily understood with use of the following workflow:
Risk Management in Test Life Cycle
Risk Management Practices:

Software Risk Evaluation (SRE)


Continuous Risk Management (CRM)
Team Risk Management (TRM)

4. CASE TOOLS
RequisitePro is a powerful, easy-to-use requirements management tool that helps teams
manage project requirements comprehensively, promotes communication and collaboration
among team members, and reduces project risk. It thereby increases the chances of delivering a
product that the client wants and does so in a timely manner.
RequisitePro offers the power of a database and Microsoft Word and is integrated with other
Rational Suite products.
Outline
Visual modeling.
Introduction to UML.
Introduction to visual modeling with UML.
Use case diagrams: discovering actors and use cases.

Background
Visual Modeling is a way of thinking about problems using models organized around real-
world ideas. Models are useful for understanding problems, communicating with everyone
involved with the project (customers, domain experts, analysts, designers, etc.), modeling
enterprises, preparing documentation, and designing programs and databases
Visual Modeling
Capture the structure and behavior of architectures and components.
Show how the elements of the system fit together.
Hide or expose details appropriate for the task.
Maintain consistency between a design and its implementation.
Promote unambiguous communication.

What is UML?
The UML is the standard language for visualizing, specifying, constructing and documenting
the artifacts of a software-intensive system. UML can be used with all processes throughout the
development life cycle and across different implementation technologies.

History of UML
The UML is an attempt to standardize the artifacts of analysis and design: semantic models,
syntactic notation and diagrams. The first public draft (version 0.8) was introduced in October
1995. Feedback from the public and Ivar Jacobson's input were included in the next two versions
(0.9 in July 1996 and 0.91 in October 1996). Version 1.0 was presented to the Object
Management Group (OMG) for standardization in July 1997. Additional enhancements were
incorporated into the 1.1 version of UML, which was presented to the OMG in September 1997.
In November 1997, the UML was adopted as the standard modeling language by the OMG.

Putting UML into Work: Use Case Diagram


The behavior of the system under development (i.e. what functionality must be provided by
the system) is documented in a use case model that illustrates the system's intended functions
(use cases), its surroundings (actors), and relationships between the use cases and actors (use
case diagrams).
Actors

Are NOT part of the system – they represent anyone or anything that must interact with the
system.

Only input information to the system.


Only receive information from the system.
Both input to and receive information from the system.
Represented in UML as a stickman.

Use Case

A sequence of transactions performed by a system that yields a measurable result of


values for a particular actor
A use case typically represents a major piece of functionality that is complete from
beginning to end. A use case must deliver something of value to an actor.
Use Case Relationships
Between actor and use case.
Association / Communication.
Arrow can be in either or both directions; arrow indicates who initiates
communication.
Between use cases (generalization):
 Uses
 Where multiple use cases share pieces of same functionality.
 Extends
 Optional behavior.
 Behavior only runs under certain conditions (such as alarm).
 Several different flows run based on the user’s selection.

CASE Tools
The Rational Rose product family is designed to provide the software developer with a
complete set of visual modeling tools for development of robust, efficient solutions to real
business needs in the client/server, distributed enterprise and real-time systems environments.
Rational Rose products share a common universal standard, making modeling accessible to
nonprogrammers wanting to model business processes as well as to programmers modeling
applications logic.

5. Performing the design by using any design phase CASE tools

OUTLINE

CASE tools are set of software application programs, which are used to automate SDLC
activities. CASE tools are used by software project managers, analysts and engineers to
develop software system.
BACKGROUND
There are number of CASE tools available to simplify various stages of Software
Development Life Cycle such as Analysis tools, Design tools, Project management tools,
Database Management tools, Documentation tools are to name a few.
Use of CASE tools accelerates the development of project to produce desired result and
helps to uncover flaws before moving ahead with next stage in software development.
Components of CASE Tools

CASE tools can be broadly divided into the following parts based on their use at a
particular SDLC stage:

Central Repository - CASE tools require a central repository, which can serve as a
source of common, integrated and consistent information. Central repository is a central
place of storage where product specifications, requirement documents, related reports and
diagrams, other useful information regarding management is stored. Central repository
also serves as data dictionary.
Case Tools

Upper Case Tools - Upper CASE tools are used in planning, analysis and design stages
of SDLC.
Lower Case Tools - Lower CASE tools are used in implementation, testing and
maintenance.
Integrated Case Tools - Integrated CASE tools are helpful in all the stages of SDLC,
from Requirement gathering to Testing and documentation.
CASE tools can be grouped together if they have similar functionality, process activities
and capability of getting integrated with other tools.
Scope of Case Tools
The scope of CASE tools goes throughout the SDLC.
Case Tools Types
Now we briefly go through various CASE tools
Diagram tools
These tools are used to represent system components, data and control flow among
various software components and system structure in a graphical form. For example,
Flow Chart Maker tool for creating state-of-the-art flowcharts.
Process Modeling Tools
Process modeling is method to create software process model, which is used to develop
the software. Process modeling tools help the managers to choose a process model or
modify it as per the requirement of software product. For example, EPF Composer
Project Management Tools
These tools are used for project planning, cost and effort estimation, project scheduling
and resource planning. Managers have to strictly comply project execution with every
mentioned step in software project management. Project management tools help in
storing and sharing project information in real-time throughout the organization. For
example, Creative Pro Office, Trac Project, Basecamp.
Documentation Tools

Documentation in a software project starts prior to the software process, goes throughout
all phases of SDLC and after the completion of the project.

Documentation tools generate documents for technical users and end users. Technical
users are mostly in-house professionals of the development team who refer to system
manual, reference manual, training manual, installation manuals etc. The end user
documents describe the functioning and how-to of the system such as user manual. For
example, Doxygen, DrExplain, Adobe RoboHelp for documentation.
Analysis Tools
These tools help to gather requirements, automatically check for any inconsistency,
inaccuracy in the diagrams, data redundancies or erroneous omissions. For example,
Accept 360, Accompa, CaseComplete for requirement analysis, Visible Analyst for total
analysis.
Design Tools
These tools help software designers to design the block structure of the software, which
may further be broken down in smaller modules using refinement techniques. These tools
provides detailing of each module and interconnections among modules. For example,
Animated Software Design
Configuration Management Tools
An instance of software is released under one version. Configuration Management tools
deal with –
Version and revision management
Baseline configuration management
Change control management

CASE tools help in this by automatic tracking, version management and release
management. For example, Fossil, Git, Accu REV.
Change Control Tools

These tools are considered as a part of configuration management tools. They deal with
changes made to the software after its baseline is fixed or when the software is first
released. CASE tools automate change tracking, file management, code management and
more. It also helps in enforcing change policy of the organization.
Programming Tools

These tools consist of programming environments like IDE (Integrated Development


Environment), in-built modules library and simulation tools. These tools provide
comprehensive aid in building software product and include features for simulation and
testing. For example, Cscope to search code in C, Eclipse.
Prototyping Tools
Software prototype is simulated version of the intended software product. Prototype
provides initial look and feel of the product and simulates few aspect of actual product.
Prototyping CASE tools essentially come with graphical libraries. They can create
hardware independent user interfaces and design. These tools help us to build rapid
prototypes based on existing information. In addition, they provide simulation of
software prototype. For example, Serena prototype composer, Mockup Builder.
Web Development Tools
These tools assist in designing web pages with all allied elements like forms, text, script,
graphic and so on. Web tools also provide live preview of what is being developed and
how will it look after completion. For example, Fontello, Adobe Edge Inspect,
Foundation 3, Brackets.
6. Develop test CASES for unit testing and integrated testing
OUTLINE
Unit Tests are conducted by developers and test the unit of code( aka module,
component) he or she developed. It is a testing method by which individual units of
source code are tested to determine if they are ready to use. It helps to reduce the cost of
bug fixes since the bugs are identified during the early phases of the development
lifecycle.
Integration testing is executed by testers and tests integration between software modules.
It is a software testing technique where individual units of a program are combined and
tested as a group. Test stubs and test drivers are used to assist in Integration Testing.
Integration test is performed in two way, they are a bottom-up method and the top-down
method.
BACKGROUND
Unit testing is a testing method by which individual units of source code are tested to
determine if they are ready to use, whereas Integration testing checks integration between
software modules.
Unit Testing test each part of the program and shows that the individual parts are
correct, whereas Integration Testing combines different modules in the application and
test as a group to see they are working fine.
Unit Testing starts with the module specification, while Integration Testing starts with
interface specification.
Unit Testing can be performed at any time, on the other hand, Integration Testing is
performed after unit testing and before system testing.
Unit Testing is executed by the developer, whereas Integration Testing is performed by
the testing team.
Unit Testing errors, can be found easily, whereas Integration Testing it is difficult to
find errors.
Unit Testing is a kind of white box testing, whereas Integration Testing is a kind of
black-box testing.
7. Develop test CASES for various white box and black box testing techniques

OUTLINE

White Box Testing is software testing technique in which internal structure, design and
coding of software are tested to verify flow of input-output and to improve design,
usability and security. In white box testing, code is visible to testers so it is also called
Clear box testing, Open box testing, Transparent box testing, Code-based testing and
Glass box testing.
It is one of two parts of the Box Testing approach to software testing. Its counterpart,
Blackbox testing, involves testing from an external or end-user type perspective. On the
other hand, White box testing in software engineering is based on the inner workings of
an application and revolves around internal testing.
The term "WhiteBox" was used because of the see-through box concept. The clear box or
WhiteBox name symbolizes the ability to see through the software's outer shell (or "box")
into its inner workings. Likewise, the "black box" in "Black Box Testing" symbolizes not
being able to see the inner workings of the software so that only the end-user experience
can be tested.
Black Box Testing is a software testing method in which the functionalities of software
applications are tested without having knowledge of internal code structure,
implementation details and internal paths. Black Box Testing mainly focuses on input
and output of software applications and it is entirely based on software requirements and
specifications. It is also known as Behavioral Testing.

BLACK Box Testing image


The above Black-Box can be any software system you want to test. For Example, an
operating system like Windows, a website like Google, a database like Oracle or even
your own custom application. Under Black Box Testing, you can test these applications
by just focusing on the inputs and outputs without knowing their internal code
implementation
BACKGROUND
A major White box testing technique is Code Coverage analysis. Code Coverage analysis
eliminates gaps in a Test Case suite. It identifies areas of a program that are not exercised
by a set of test cases. Once gaps are identified, you create test cases to verify untested
parts of the code, thereby increasing the quality of the software product

There are automated tools available to perform Code coverage analysis. Below are a few
coverage analysis techniques a box tester can use:
Statement Coverage:- This technique requires every possible statement in the code to be
tested at least once during the testing process of software engineering.
Branch Coverage - This technique checks every possible path (if-else and other
conditional loops) of a software application.
Apart from above, there are numerous coverage types such as Condition Coverage,
Multiple Condition Coverage, Path Coverage, Function Coverage etc. Each technique has
its own merits and attempts to test (cover) all parts of software code. Using Statement and
Branch coverage you generally attain 80-90% code coverage which is sufficient.
Following are important WhiteBox Testing Techniques:

Statement Coverage
Decision Coverage
Branch Coverage
Condition Coverage
Multiple Condition Coverage
Finite State Machine Coverage
Path Coverage
Control flow testing
Data flow testing

Black Box Testing Techniques


Following are the prominent Test Strategy amongst the many used in Black box Testing
Equivalence Class Testing: It is used to minimize the number of possible test cases to
an optimum level while maintains reasonable test coverage.
Boundary Value Testing: Boundary value testing is focused on the values at
boundaries. This technique determines whether a certain range of values are acceptable
by the system or not. It is very useful in reducing the number of test cases. It is most
suitable for the systems where an input is within certain ranges.
Decision Table Testing: A decision table puts causes and their effects in a matrix.
There is a unique combination in each column.
WWW.VIDYARTHIPLUS.COM

Ex no:
BOOK BANK SYSTEM
Date:

AIM:
To create a system to perform book bank operation

(I) PROBLEM STATEMENT:

A Book Bank lends books and magazines to member, who is registered in the system.
Also it handles the purchase of new titles for the Book Bank. Popular titles are brought into
multiple copies. Old books and magazines are removed when they are out or date or poor in
condition. A member can reserve a book or magazine that is not currently available in the
book bank, so that when it is returned or purchased by the book bank, that person is notified.
The book bank can easily create, replace and delete information about the tiles, members,
loans and reservations from the system.

(II) SOFTWARE REQUIREMENTS SPECIFICATION:

1.0 INTRODUCTION

Book Bank is the interface between the students and Librarian. It aims at improving
the efficiency in the Issue of books or magazines and reduce the complexities involved in it to
the maximum possible extent.

1.1 PURPOSE

If the entire process of 'Issue of Books or Magazines' is done in a manual manner then
it would take several months for the books or magazines to reach the applicant. Considering
the fact that the number of students for Book Bank is increasing every year, an Automated
System becomes essential to meet the demand. So this system uses several programming and
database techniques to elucidate the work involved in this process. The system has been
carefully verified and validated in order to satisfy it.

1.2 SCOPE

The System provides an online interface to the user where they can fill in their
personal details and submit the necessary documents (may be by scanning). The authority
concerned with the issue of books can use this system to reduce his workload and process the
application in a speedy manner.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

 Librarian - Refers to the super user who is the Central Authority who has
been vested with the privilege to manage the entire system.
 Student - One who wishes to obtain the Books or Magazines.
 HTML - Markup Language used for creating web pages.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

 J2EE - Java 2 Enterprise Edition is a programming platform and it is the part


of the java platform for developing and running distributed java applications.
 HTTP -Hyper Text Transfer Protocol
 TCP/IP - Transmission Control Protocol/Internet Protocol is the
communication protocol used to connect hosts on the Internet.

1.4 REFERENCES

IEEE Software Requirement Specification format

1.5 TECHNOLOGIES TO BE USED

 Visual Basic
 Oracle 11g

1.6 TOOLS TO BE USED

 Visual Basic Tools


 Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW

SRS includes two sections overall description and specific requirements.

Overall description will describe major role of the system components and inter-
connections.

Specific requirements will describe roles & functions of the actors.

2.0 OVERALL DESCRIPTION:

It will describe major role of the system components and inter-connections.

2.1 PRODUCT PERSPECTIVE

The SRS acts as an interface between the 'Students' and the 'Librarian'. This system
tries to make the interface as simple as possible and at the same time not risking the
security of data stored in. This minimizes the time duration in which the user receives
the books or magazines.

2.2 SOFTWARE INTERFACE

 Front End Client - The Student and Librarian online interface is built using
Visual studio.
 Back End - Oracle 11 g database

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

2.3 HARDWARE INTERFACE

The server is directly connected to the client systems. The client systems have access
to the database in the server.

2.4 SYSTEM FUNCTIONS

 Secure Registration of information by the Students.

 Librarian can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS

 Student - They are the people who desire to obtain the books and submit the
information to the database.
 Librarian - He has the certain privileges to add the books and to approval of the
reservation of books.

2.6 CONSTRAINTS

 The Students require a computer to submit their information.


 Although the security is given high importance, there is always a chance of intrusion
in the web world which requires constant monitoring.
 The Students has to be careful while submitting the information. Much care is
required.

2.7 ASSUMPTIONS AND DEPENDENCIES

 The Student and Librarian must have basic knowledge of computers and English
Language.
 The Students may be required to scan the documents and send.

(III)USE-CASE DIAGRAM:
The book bank use cases are:
1. book_issue
2. book_return
3. book_order
4. book_entry
5. search book_details

ACTORS INVOLVED:

1. Student
2. Librarian
3. Vendor

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

USECASE NAME : SEARCH BOOK_DETAILS

The librarian initiates this use case when any member returns or request the book and
checking if the book is available.
Precondition: The librarian should enter all Book details.
Normal Flow: Build message for librarian who search the book.
Post Condition: Send message to respective member who reserved the book.

USECASE NAME : BOOK_ISSUE

Initiated by librarian when any member wants to borrow the desired book. If the book is
available, the book is issued.
Precondition: Member should be valid member of library.
Normal Flow: Selected book will be issued to the member.
Alternative Flow: If book is not available then reserved book use case should be initiate.
Post Condition: Update the catalogue.

USECASE NAME : BOOK_ORDER

Initiated by librarian when the requested book is not available in the library at that moment.
The book is reserved for the future and issued to the person when it is available.
Precondition: Initiated only when book is not available.
Normal Flow: It reserved the book if requested.
Post Condition : Mention the entry in catalogue for reservation.

USECASE NAME : BOOK_RETURN

Invoked by the librarian when a member returns the book.


Precondition: Member should be valid member of library.
Normal Flow: Librarian enters bookid and system checks for return date of the book.
Alternative Flow: System checks for return date and if it returned late fine message will be
displayed.
Post Condition: Check the status of reservation.

USECASE NAME : BOOK_ENTRY

The purchase book use-case when new books invoke it or magazines are added to the library.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Precondition: Not available or more copies are required.


Normal Flow: Enter bookid,author information, publication information, purchased date,
prize and number of copies.
Post Condition: Update the information in catalogue.

book_issue

student
librarian

book_return

book_entry

vendor
search book_details

book_order

Fig 3.1 USE-CASE DIAGRAM FOR BOOK BANK SYSTEM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(IV) ACTIVITY DIAGRAM:


Activity diagrams are graphical representations of workflows of stepwise activities and
actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-step
workflows of components in a system. An activity diagram shows the overall flow of control.
An activity is shown as an rounded box containing the name of the operation.
This activity diagram describes the behaviour of the system.

shows id
card

request for
specific book

is book
available? no enquires for
alternative book

yes
if satisfied?
borrows
book yes

no

librarian approves transaction


transaction cancelled

Fig4.1 ACTIVITY DIAGRAM [BORROW BOOK]

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

collects quotation
from vendors

no

if satisfied with
norms?

yes

place order

discount & mode of


payment finalised

takes delivery

bill amt paid

Fig.4.2 ACTIVITY DIAGRAM [ ORDER BOOK]

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.4. 3ACTIVITY DIAGRAM [RETURN BOOK]

shows id and
library card

librarian
makes entry

on or before
return date? no

pays fine

yes

librarian approves
transaction

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(V) CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis
diagram. The main task of object modeling is to graphically show what each object will do in
the problem domain. The problem domain describes the structure and the relationships
among objects.

The ATM system class diagram consists of four classes:


1. Student
2. Book
3. Issue
4. Return
5. Vendor
6. Details

1) STUDENT:

It consists of twelve attributes and three operations. The attributes are enrollno, name,
DOB, fathername, address, dept name, batch and book limits. The operations of this class are
addStInfo(), deleteStInfo(), modifyStInfo().

2) BOOK:
It consists of ten attributes and four operations. This class is used to keep book
information such as author, title, vendor, price, etc

3) ISSUE:
It consists of eight attributes and two operations to maintain issue details such as,
issue date, accno of issued book, name of the student who borrowed book.

4) RETURN:
It consists of eight attributes and two operations to maintain issue details such as,
issue date, accno of issued book, name of the student who borrowed book.

5) STUDENTS:
The attributes of this class are name, dept ,year ,bcode no The operation is display
students().

6) DETAIL:
The attributes of this class are book name, author, bcode no The operations are delete
details().

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.5. CLASS DIAGRAM FOR BOOK BANK SYSTEM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VI) SEQUENCE DIAGRAM:

A sequence diagram represents the sequence and interactions of a given USE-CASE


or scenario. Sequence diagrams can capture most of the information about the system. Most
object to object interactions and operations are considered events and events include signals,
inputs, decisions, interrupts, transitions and actions to or from users or external devices.

An event also is considered to be any action by an object that sends information. The
event line represents a message sent from one object to another, in which the “form” object is
requesting an operation be performed by the “to” object. The “to” object performs the
operation using a method that the class contains.

It is also represented by the order in which things occur and how the objects in the
system send message to one another.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

: issue : return search DB


: student : librarian

1: request book

2: check available book

3: check available book

4: not avilable

5: not avilable

6: not available

7: request for another book

8: check availability

9: check availabilty

10: available

11: avilable

12: avilable

13: provide student details

14: enter issue data

15: update issue status

16: issue status updated

17: updated successfully

18: issue book

19: request to return book

20: enter the book details

21: update return status

22: return status updated

23: updated successfully

24: book returned

Fig. 6.1. SEQUENCE DIAGRAM FOR BOOK ISSUE & RETURN

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

1: request book
7: request for another book 14: enter issue data
13: provide student details
19: request to return book : issue
: librarian 17: updated successfully

6: not available
12: avilable 15: update issue status
18: issue book
: student 24: book returned 16: issue status updated

2: check available book DB


8: check availability
23: updated successfully

20: enter the book details 5: not avilable


11: avilable
3: check available book
21: update return status
9: check availabilty

4: not avilable
22: return status updated
10: available

: return
search

Fig. 6.2. COLLABORATION DIAGRAM FOR BOOK ISSUE & RETURN

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VII) STATE CHART DIAGRAM

It consists of state, events and activities. State diagrams are a familiar technique to
describe the behavior of a system. They describe all of the possible states that a particular
object can get into and how the object's state changes as a result of events that reach the
object

start book issue book return

vendor supplies book to student takes book student returns book to library[
the library from library pays fine if needed]

Fig. 7.1 STATE CHART DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components
of a system where the software components are deployed.

Fig.8.1.DEPLOYMENT DIAGRAM

(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL


SERVICE LAYER

//Source file: E:\\sruthi\\book.java

public class book1


{
private integer accno;
private string author;
private string title;
private string edition;
private integer publicationid;
private double price;
private date purchaseDate;
private integer vendorId;
private string vendorName;
private integer isReference;
public return1 theReturn1;
public vendor1 theVendor1;

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

/**
@roseuid 51187CA503B2
*/
public book()
{

/**
@roseuid 510F44A7007E
*/
public void viewBookDetails()
{

/**
@roseuid 510F44B50217
*/
public void addbookinfo()
{

/**
@roseuid 510F44BD0063
*/
public void deletebookinfo()
{

/**
@roseuid 510F44C60045
*/
public void modifybookinfo()
{

}
}
/**

void book1.newbookdetails(){

void book1.modify(){

}
void book1.add(){

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

}
void book1.viewBookDetails(){

}
void book1.bookEntry(){

}
void book1.delete(){

*/

//Source file: D:\\vaish\\issue.java

public class issue


{
private date iisDate;
private integer issId;
private integer acno;
private string title;
private integer enNo;
private string name;
private integer deptId;
private integer batId;
public books theBooks;

/**
@roseuid 5100DE750281
*/
public issue()
{

}
}
//void issue.modify(){
//
// }
//void issue.bookissue(){
//
// }

//Source file: F:\\VAISH\\return1.java

public class return1


{
public integer returnid;
public date returndate;

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

public integer accno;


public string titlle;
public integer enrollno;
public string name;
public string dept;
public integer batch;
public book theBook;

/**
@roseuid 50F92E4D0177
*/
public return1()
{

/**
@roseuid 50F91C69005D
*/
public void bookreturn()
{

/**
@roseuid 50F91C6C0000
*/
public void modify()
{

}
}

//Source file: F:\\VAISH\\student.java

public class student


{
public integer enrollno;
public string name;
public date DOB;
public string fathername;
public string address;
public string address2;
public string address3;
public string district;
public string state;
public long pincode;
public integer deptid;
public string depname;

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

public integer batchid;


public integer booklimit;
public issue theIssue;
public return1 theReturn1;

/**
@roseuid 50F92E4D00FA
*/
public student()
{

/**
@roseuid 50F918E6000F
*/
public void add()
{

/**
@roseuid 50F918EB03A9
*/
public void delete()
{

/**
@roseuid 50F918EE029F
*/
public void modify()
{

}
}

//Source file: F:\\VAISH\\vendor1.java

public class vendor1


{
private integer vendorid;
private string name;
private string address1;
private string address2;
private string address3;

/**

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

@roseuid 5118C814009C
*/
public vendor1()
{

/**
@roseuid 5118B75100AB
*/
public void bookOrder()
{

/**
@roseuid 5118B75702BF
*/
public void modify()
{

}
}
//void vendor1.bookorder(){
//
// }

(X) IMPLEMENTATION OF USER INTERFACE LAYER

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

RESULT:
Thus the mini project for Book Bank System has been successfully executed and
codes are generated.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Ex no:
EXAM REGISTRATION SYSTEM
Date:

AIM:
To create a system to perform the Exam Registration system

PROBLEM STATEMENT:

Exam Registration system.is used in the effective dispatch of registration form to all of
the students. This system adopts a comprehensive approach to minimize the manual work and
schedule resources, time in a cogent manner. The core of the system is to get the online
registration form (with details such as name, reg.no etc.,) filled by the student whose testament is
verified for its genuineness by the Exam Registration System with respect to the already existing
information in the database. This forms the first and foremost step in the processing of exam
application. After the first round of verification done by the system, the information is in turn
forwarded to the Exam Controller. The application is then processed manually based on the
report given by the system. The system also provides the student the list of exam dates.The
controller will be provided with fees details to display the current status of application to the
student, which they can view in their online interface. After all the necessary criteria has been
met, the original information is added to the database and the hall ticket is sent to the student.

(I)SOFTWARE REQUIREMENT SPECIFICATION:

1.0 INTRODUCTION
Exam Registration System is an interface between the Student and the Exam Controller
responsible for the Issue of Hall Ticket. It aims at improving the efficiency in the Issue of Hall
ticket and reduces the complexities involved in it to the maximum possible extent.

1.1 PURPOSE
If the entire process of 'Issue of Hall ticket' is done in a manual manner then it would
takes several days for the hall ticket to reach the student. Considering the fact that the number of
students for hall ticket is increasing every year, an Automated System becomes essential to meet
the demand. So this system uses several programming and database techniques to elucidate the
work involved in this process. As this is a matter of National Security, the system has been
carefully verified and validated in order to satisfy it.

1.2 SCOPE
• The System provides an online interface to the user where they can fill in their personal
details and submit the necessary documents (may be by scanning).
• The controller concerned with the issue of hall ticket can use this system to reduce his
workload and process the application in a speedy manner.
• Provide a communication platform between the student and the controller.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

• Students will come to know their status of application and the date in which they must
subject themselves for manual document verification.

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS


• Exam Controller - Refers to the super user who is the Central Authority who has
been vested with the privilege to manage the entire system.
• Student - One who wishes to obtain the Hall Ticket.
• ERS - Refers to this Examination Registration System.
• HTML - Markup Language used for creating web pages.
• J2EE – Java 2 Enterprise Edition is a programming platform java platform for
developing and running distributed java applications.
• HTTP - Hyper Text Transfer Protocol.
• TCP/IP – Transmission Control Protocol/Internet Protocol is the communication
protocol used to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED


• HTML
• JSP
• Javascript
• Java
1.6 TOOLS TO BE USED
• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements - Overall
Description will describe major role of the system components and inter-connections.
Specific Requirements will describe roles & functions of the actors.

2.0.OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
The ERS acts as an interface between the 'student' and the 'exam controller'. This system
tries to make the interface as simple as possible and at the same time not risking the security of
data stored in. This minimizes the time duration in which the user receives the hall ticket.

2.2 SOFTWARE INTERFACE

 Front End Client - The exporter online interface is built using JSP and HTML.
 Web Server – Apache Tomcat Server (Oracle Corporation)
 Back End - Oracle 11g database

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

2.3 HARDWARE INTERFACE


The server is directly connected to the client systems. The client systems have access to
the database in the server.

2.4 SYSTEM FUNCTIONS


• Secure Registration of information by the Students.
• SMS and Mail updates to the students by the controller.
• Controller can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS


• Student - They are the people who desire to obtain the hall ticket and submit the
information to the database.
• Exam controller - He has the certain privileges to add the registration status and to
approve the issue of hall ticket. He may contain a group of persons under him to verify
the documents and give suggestion whether or not to approve the dispatch of hall ticket.

2.6 CONSTRAINTS
• The applicants require a computer to submit their information.
• Although the security is given high importance, there is always a chance of intrusion in
the web world which requires constant monitoring.
• The user has to be careful while submitting the information. Much care is required.

2.7 ASSUMPTIONS AND DEPENDENCIES


• The Students and Exam Controller must have basic knowledge of computers and
English Language.
• The student may be required to scan the documents and send.

(III)USECASE DIAGRAM:

The Exam Registration use cases in our system are:


1. Login
2. View exam details
3. Register
4. Acknowledgement
5. Fee Processing

ACTORS INVOLVED:
1. Student
2. System DB

USE-CASE NAME: LOGIN


The student enters his username and password to login and retrieve the information’.

USE-CASE NAME: VIEW EXAM DETAILS


The student view the details about the exam schedule which contains Date,time,etc...

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

USE-CASE NAME: REGISTER


The student should notify the fee details that only the student can pay the correct amount

USE-CASE NAME: ACKNOWLEDGEMENT


The exam fees should be paid by the student to get the hall ticket from the exam
controller.

USE-CASE NAME: FEE PROCESSING


All the details should be viewed by both the student and the controller to verify whether
all the entered details are correct.

Login

View exam details


System DB
Student
<<include>>
Register
Fee processing

Acknowledgement

Fig. 3. 1. USECASE DIAGRAM FOR EXAM REGISTRATION SYSTEM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(IV) ACTIVITY DIAGRAM:

Enter(uid,pwd)

Search exam
details

Display exam
details

get registration
form

Fill registration
form

Fee payment and


processing

Form
verification

Invalid data
Valid data Enter correct data
Show error
Store student message
details

Display registration no &


acknowledgement

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(V)CLASS DIAGRAM:

The class diagram, also referred to as object modeling is the main static analysis diagram.
The main task of object modeling is to graphically show what each object will do in the problem
domain. The problem domain describes the structure and the relationships among objects.

The Exam Registration System class diagram consists of four two classes of registration
system.

1. Student_details
2. Exam_details
3. Register

1) STUDENT_DETAILS

It consists of six attributes and six operations. The attributes id, password, name, age, sex,
course. The operations of this class are login(), logout(), conformation(), register(),
newfeesdetails().

2) EXAM_DETAILS

It consists of four attributes and six methods. The attributes are userid, password,
examfees, fees due. The methods are login(),logout(), feesdetails(), displayfees(),
conformation(), examcontroller().

3) REGISTER
This class is used to maintain the registered student information such as, subject
registered, date of registration and etc,.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.5.1 CLASS DIAGRAM FOR EXAM REGISTRATION SYSTEM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VI)INTERACTION DIAGRAM:

A sequence diagram represents the sequence and interactions of a given USE-CASE or


scenario. Sequence diagrams can capture most of the information about the system. Most object
to object interactions and operations are considered events and events include signals, inputs,
decisions, interrupts, transitions and actions to or from users or external devices.

An event also is considered to be any action by an object that sends information. The
event line represents a message sent from one object to another, in which the “form” object is
requesting an operation be performed by the “to” object. The “to” object performs the operation
using a method that the class contains.

It is also represented by the order in which things occur and how the objects in the system
send message to one another.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

UI: Internet : Register : Exam _details


Explorer
: Student : System DB

enter(uid,pwd)

Check validation

Store uid,pwd

Successfully stored

View exam details

Get exam details

Get reg form

Fill registration form

Check given data

register

Verify criteria

Store student details

return regid

Acknowledgement & display reg id

Fig. 6.1. SEQUENCE DIAGRAM FOR REGISTRATION SYSTEM

The sequence and collaboration diagram represents that the student enter the information to get
the hall ticket and the exam controller issues the hall ticket after verifying the necessary items
and this data are stored in the database.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

: Exam _details

: System DB

1: enter(uid,pwd)4: Successfully stored 8:


: Student
6: View exam details
10: Get reg form
12: Fill registration form 7: Get exam details
16: Store student details 3: Store uid,pwd
17: return regid
2: Check validation
5: 13: Check given data
9:
11:
15: Verify criteria 19: Acknowledgement & display reg id

18: UI: Internet


Explorer
: Register
14: register

Fig. 6.2. COLLABORATION DIAGRAM FOR REGISTRATION SYSTEM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM

Deployment diagrams are used to visualize the topology of the physical components of a
system where the software components are deployed.

Fig.7.1.DEPLOYMENT DIAGRAM

COMPONENT DIAGRAM

Component diagrams are used to visualize the organization and relationships among
components in a system.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.7.2.COMPONENT DIAGRAM

(VIII) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL


SERVICE LAYER
//Source file: D:\\uma\\examDetails.java

public class examDetails


{
private string examCode;
private string examName;
private string subjectId;
private string subjectName;
private time duration;
private date dateOfExam;
private double fee;
private integer ageLimit;
private string criteria;
private string examCentreName;
private string examCentreCode;
public studentDetails theStudentDetails;
public register theRegister;

/**
* @roseuid 515AA57101B5
*/
public examDetails()
{

}
WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

/**
* @roseuid 515AA448037A
*/
public void addExam()
{

/**
* @roseuid 515AA44F00BB
*/
public void updateExam()
{

/**
* @roseuid 515AA4570280
*/
public void delExam()
{

}
}
//void examDetails.deleteExam(){
//
// }

//Source file: F:\\Vaish\\Register.java

public class Register


{
private int studid;
private String ExamCode;
private String subid;
private int no.ofSubject;
private double fees;
private string regid;
private String ExamCenterCode;

/**
@roseuid 51342F76033C
*/
public Register()

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

/**
@roseuid 51342C88004E
*/
public void getRegister()
{

/**
@roseuid 51342C8E0271
*/
public void cancelRegister()
{

/**
@roseuid 51342CA20109
*/
public void verifyIngormation()
{

}
}
//register.register()
//register.getregister(){
// return null;
// }
//register.cancelreg(){
//
// }
//register.verifyinfo(){
//
// }

//Source file: F:\\Vaish\\StudentDetails.java

public class StudentDetails


{
private string Studname;
private integer Studid;

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

private Date DOB;


private String gender;
private String qualification;
private string Address;
private integer mobileno;
private string emailid;
private string username;
private string password;

/**
@roseuid 51342F7602CE
*/
public StudentDetails()
{

/**
@roseuid 51342B4901E4
*/
public void addStudent()
{

/**
@roseuid 51342B4F03A9
*/
public void updateStudent()
{

/**
@roseuid 51342B58029F
*/
public void getLogic()
{

}
}
/**
void studentdetails.getlogin(){

}
studentdetails.studentdetails()

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

void studentdetails.updatestudent(){

}
void studentdetails.addstudent(){

*/

(IX) IMPLEMENTATION OF USER INTERFACE LAYER

Fig.9.1. REGISTRATION FORM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.9.2 LOGIN FORM

RESULT:
Thus the mini project for Exam Registration system has been successfully executed and
codes are generated.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Ex. No: ONLINE COURSE RESERVATION SYSTEM


Date:

AIM:

To create a system through which students can register to the courses desired by them.

(I)PROBLEM STATEMENT

The system is built to be used by students and managed by an administrator. The


student and employee have to login to the system before any processing can be done. The
student can see the courses available to him/her and register to the course he/she wants. The
administrator can maintain the course details and view all the students who have registered to
any course.

(II) SOFTWARE REQUIREMENT SPECIFICATION

1.0. INTRODUCTION

Course Reservation System is an interface between the Student and the Registrar
responsible for the issue of Course. It aims at improving the efficiency in the issue of Course
and reduces the complexities involved in it to the maximum possible extent.
1.1 PURPOSE
If the entire process of 'Issue of Course' is done in a manual manner then it would
takes several months for the course to reach the applicant. Considering the fact that the
number of applicants for course is increasing every year, an Automated System becomes
essential to meet the demand. So this system uses several programming and database
techniques to elucidate the work involved in this process.

1.2 SCOPE
 The System provides an online interface to the user where they can fill in their
personal details and submit the necessary documents (may be by scanning).
 The Registrar concerned with the issue of course can use this system to reduce his
workload and process the application in a speedy manner.
 Provide a communication platform between the Student and the Registrar.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

1.3 DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

 Registrar
Refers to the super user with the privilege to manage the entire system.
 Applicant
One who wishes to register the Course
 OCRS
Refers to online Course Reservation System.
 HTML
Markup Language used for creating web pages.
 J2EE
Java 2 Enterprise Edition is a programming platform java platform for developing and
running distributed java applications.
 HTTP
Hyper Text Transfer Protocol.
 TCP/IP
Transmission Control Protocol/Internet Protocol is the communication protocol used
to connect hosts on the Internet.

1.4 REFERENCES
IEEE Software Requirement Specification format.

1.5 TECHNOLOGIES TO BE USED


• HTML
• JSP
• Javascript
• Java

1.6 TOOLS TO BE USED


• Eclipse IDE (Integrated Development Environment)
• Rational Rose tool (for developing UML Patterns)

1.7 OVERVIEW
SRS includes two sections overall description and specific requirements
Overall Description will describe major role of the system components and inter-
connections.
Specific Requirements will describe roles & functions of the actors.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

2.0 OVERALL DESCRIPTION


2.1 PRODUCT PERSPECTIVE
The OCRS acts as an interface between the 'Student' and the 'Registrar'. This system
tries to make the interface as simple as possible and at the same time not risking the security
of data stored in. This minimizes the time duration in which the user receives the course.

2.2 SOFTWARE INTERFACE


• Front End Client - The Student and Registrar online interface is built using JSP and
HTML. The Administrators's local interface is built using Java.
• Web Server – Tomcat Apache application server (Oracle Corporation).
• Back End – Oracle 11g database.

2.3 HARDWARE INTERFACE


The server is directly connected to the client systems. The client systems have access
to the database in the server.

2.4 SYSTEM FUNCTIONS


• Secure Reservation of information by the Students.
• SMS and Mail updates to the students by the Registrar
• Registrar can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.5 USER CHARACTERISTICS


• Applicant - They are the person who desires to obtain the course and submit the
information to the database.
• Administrator - He has the certain privileges to add the course status and to
approve the issue of course. He may contain a group of persons under him to verify
the documents and give suggestion whether or not to approve the dispatch of course.

2.6 CONSTRAINTS
• The applicants require a computer to submit their information.
• Although the security is given high importance, there is always a chance of intrusion
in the web world which requires constant monitoring.
• The user has to be careful while submitting the information. Much care is required.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

2.7 ASSUMPTIONS AND DEPENDENCIES


• The Applicants and Administrator must have basic knowledge of computers and
English Language.
• The applicants may be required to scan the documents and send

(III)USE-CASE DIAGRAM:

The course registration system has the following use-cases


1. Login
2. View course details
3. Reserve for course
4. Pay fee
5. Check status

ACTORS INVOLVED:
1. Student
2. Registrar
USE-CASE NAME: LOGIN
The user enters the username and password and chooses if the user is student or Registrar. If
entered details are valid, the user’s account becomes available. If it is invalid, an appropriate
message is displayed to the user.

USE-CASE NAME: VIEW COURSE DETAILS


In this use case, a student can search all the courses available to him and choose the best
course he wants. The student can view the course duration, faculty and department of the
courses he may choose.

USE-CASE NAME: RESERVE FOR COURSE


When a student has successfully chosen a course, he can register to that course. Upon
registration, the student’s details are stored in the database.

USE-CASE NAME: PAY FEE


After registration to any course, the student may see the details of his current course. He may
wish to know details about fees and other information.

USE-CASE NAME: CHECK STATUS


The student tries to check the status in which category applied. The system displays the status
information to the student.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

view course details

Registrar

Student
login

<<include>>
pay fee
reserve for course

check status

Fig.3.USE-CASE DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(IV) ACTIVITY DIAGRAM:

student Registration System

View Display
courses Course

Selects available
Courses
Display Form

Fills up
Form

Submits Form Send for


Registration

Eligibility Retrieve
Confirm Confirmation

Pays Fees

Registers
the Course

Fig.4. ACTIVITY DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(V) CLASS DIAGRAM:


The class diagram is a graphical representation of all the classes used in the system
and their operations, attributes and relationships.
The course registration system makes use of the following classes:
1. Student
2. Course Catalog
3. Reserve Course

1) STUDENT:
It consists of the details of all the students present in the database. The
attributes present in this class are student id, student name, student qualification,
student address1, student address2, student address3, student mobile no, student
emailed,, student dob, student sex. The object of this class is created as soon as the
student registers to a course. The operations available to this class are add details (),
modify details (), del details (), reserve course().

2) COURSE CATALOG:
The course catalog class consist of course id, course name, course duration
course fee, course eligibility, total no of seat, course avail seat. The operations are add
course(), update course(), del course().

3) RESERVE COURSE:
The reserve catalog class consists of student id, course id, date, amt paid, reg
id, DD no. the operation are get course details(), check eligibility(), confirm
registration().

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Fig.5. CLASS DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VI) INTERACTION DIAGRAM:


 A sequence diagram represents the sequence and interactions of a given USE-CASE
or scenario. Sequence diagrams can capture most of the information about the system.
Most object to object interactions and operations are considered events and events
include signals, inputs, decisions, interrupts, transitions and actions to or from users or
external devices.
 An event also is considered to be any action by an object that sends information. The
event line represents a message sent from one object to another, in which the “form”
object is requesting an operation be performed by the “to” object. The “to” object
performs the operation using a method that the class contains.
 It is also represented by the order in which things occur and how the objects in the
system send message to one another.
 The sequence diagram for each USE-CASE that exists when a user administrator,
check status and new registration about course registration system are given.
 Users have to first login to the system before performing any operation. The user has
to provide the necessary details to the system for login.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

: Student UI : ReserveCourse : Course Catalog

Login(username,pwd)

Check Data

View course details

getCoursedetails

Reserve course

View reservation form

Fills up the reservation form

confirmReservation

getCourseDetails

ckeckEligibilityCriteria

Eligible&Seat available

Registers for the course

Fig.6.1.SEQUENCE DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM
: Course
Catalog

: Student 1: Login(username,pwd)
4: View course details
8: Reserve course 12: getCourseDetails
10: Fills up the reservation form

5: getCoursedetails
13: 6:
3:
7:
14: ckeckEligibilityCriteria 9: View reservation form
16: Registers for the course 2: Check Data

15: Eligible&Seat available


: ReserveCourse
UI
11: confirmReservation

Fig.6.2.COLLABORATION DIAGRAM

 After login, the student has to register to a course of his choice. The student can
view all the courses available to him and register to a course suitable to him. The
student may view the course details before registration.
 A student may wish to view course details before registration. For this, the student
has to first login and select the course details he wishes to see.

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VII) STATE CHART DIAGRAM:


Every object undergoes through some state and on receiving some event the state gets
changed. This transition of the state can be represented by the state transition diagram.

Login to course registration View get list of courses Select Enter data Fill form
course course

after clicking

Pay fees Gets Submit


Confirmation form
Eligible sending form to registrar

Gets receipt
not eligible

Reserves
seat

Fig.7. STATE CHART DIAGRAM

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

(VIII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM


Deployment diagrams are used to visualize the topology of the physical components
of a system where the software components are deployed.

Fig.8.1.DEPLOYMENT DIAGRAM

COMPONENT DIAGRAM:
Component diagrams are used to visualize the organization and relationships among
components in a system.

Fig.8.2.COMPONENT DIAGRAM

(IX) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL


SERVICE LAYER

//Source file: coursecatalog.java

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

public class coursecatalog


{
private integer courseid;
private integer coursename;
private integer courseduration;
private double coursefees;
private string courseeligibilitycritiria;
private string totalnoofseats;
private integer courseavailable;
public reservecourse theReservecourse;

/**
@roseuid 512350660128
*/
public coursecatalog()
{

/**
@roseuid 51234FBD005D
*/
public void addcourse()
{

/**
@roseuid 51234FC80138
*/
public void updatecourse()
{

/**
@roseuid 51234FD20251
*/
public void deletecourse()
{

}
}

//Source file: reservecourse.java

public class reservecourse


{
private integer studentid;

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

private integer courseid;


private date date;
private double amountpaid;
private integer registerid;
private string DDno;

/**
@roseuid 512350660167
*/
public reservecourse()
{

/**
@roseuid 51234EE5007D
*/
public void getcoursedetails()
{

/**
@roseuid 51234EF3003E
*/
public void checkeligibility()
{

/**
@roseuid 51234F0102AF
*/
public void confirmreg()
{

}
}

(X) IMPLEMENTATION OF USER INTERFACE LAYER

Home Page

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Login Page

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

Course Catalog

Registration Form

ThanU Page

WWW.VIDYARTHIPLUS.COM V+TEAM
WWW.VIDYARTHIPLUS.COM

RESULT:
Thus the mini project for Course Reservation system has been successfully executed
and codes are generated.

WWW.VIDYARTHIPLUS.COM V+TEAM
TABLE OF CONTENTS

S.NO CONTENTS

1) Aim

2) Problem Statement

3) Introduction

3.1 Purpose

3.2 Scope

4) System Requirements

5) UML Diagrams

5.1 Class Diagram

5.2 Object Diagram

5.3 State Diagram

5.4 Data Flow Diagram

5.5 Use-Case Diagram

5.6 Activity Diagram

5.7 Sequence Diagram

5.8 Component Diagram

5.9 Deployment Diagram


OOAD LAB EXPERIMENTS

OBJECTIVE: - To develop a mini project following the exercises listed below.

S.N EXPERIMENT
O
1. To develop a problem statement.

2. Develop an IEEE standard SRS document.

3. Identify Use Cases and develop the Use Case model.

4. Identify the business activities and develop an UML


Activity diagram.

5. Identify the conceptual classes and develop a domain


model with UML class diagram.

6. Using the unidentified scenario find the interaction


between objects and represent them using UML
Interaction diagram.

7. Draw State Chart diagram.

8. Draw Component and Deployment diagram.

9. Draw Data Flow diagram.

Suggested domain for mini-project: -

 Passport Automation System


“ Passport Automation System “

1. AIM –
To develop Passport Automation System.

2. PROBLEM STATEMENT –
The following problems were faced during the manual process of passport
dispatch system -

 Manual Process: We require a large number of skilled individuals in the


various fields of Passport issuing. Chances of error due to manual work
were much higher; also the workload on each individual was a lot.
 Time Consumption: Engaging more number of people for manual work,
automatically led to more time consumption. Search for particular data
information also led to unnecessary delays in the process of Passport
issuing.
 Database Management: Due to extremely high number of applicants, the
management and the processing of the data was very difficult in hard
copy form. Hard copy format was difficult to maintain and update with
time.
 Database Security: More accessibility to data, made tampering much
easier.
3. INTRODUCTION –
The above problems can be easily eradicated by providing a software solution
which is user friendly, flexible and automated to reduce the manual work, and
time of the applicants.

 The core of the system is to get the online registration form (with details
such as name, address etc.) filled by the applicant whose details and
documents are verified by the Ministry of External Affairs, and after all
the process of verification , make the passport available to the applicant,
in a proper and secure manner.
 The first step is filling of the online Passport application form by the
applicant and payment of the fees.
 After the first round of verification done by the system, the information is
in turn forwarded to the Ministry of External Affairs office.
 The application is then processed manually based on the report given by
the system. The system also provides the applicant the list of available
dates for appointment to 'document verification' in the administrator's
office, from which they can select one.
 The system forwards the necessary details to the police for its separate
verification whose report is then presented to the administrator. The
administrator will be provided with an option to display the current status
of application to the applicant, which they can view in their online
interface.
 After all the necessary criteria has been met, the original information is
added to the database and the passport is sent to the applicant.

3.1 Purpose –

If the entire process of 'Issue of Passport' is done in a manual manner then it


would take several months for the passport to reach the applicant.
Considering the fact that the number of applicants for passport is increasing
every year, an Automated System becomes essential to meet the demand.
As this is a matter of National Security, the system has been carefully
verified and validated in order to satisfy it.
3.2 Scope –

• The System provides an online interface to the user where they can sign up,
fill in their personal details and upload the necessary documents.
• The authority concerned with the issue of passport can use this system to
reduce their workload and process the application in a speedy and secure
manner.
• It provides a communication platform between the applicant and the
administrator.
• Transfer of data between the Passport Issuing Authority, Ministry of
External Affairs and the Local Police for verification of applicant's
information.
• Users/Applicants will come to know their status of application and can
enter the date in which they must subject themselves for manual document
verification.

3.3 Definitions, Acronyms and the Abbreviations –

• PAS - Refers to this Passport Automation System.


• Administrator - Refers to the user who is the Central Authority who has
been assigned to manage the entire system. It can be any higher official in
the Regional Passport Office of Ministry of External Affairs.
• Applicant - One who wishes to obtain the Passport.
• HTML - Markup Language used for creating web pages.
• J2EE – Java 2 Enterprise Edition is a programming platform and it is the
part of the java platform for developing and running distributed java
applications.
• HTTP - Hyper Text Transfer Protocol.
• TCP/IP – Transmission Control Protocol/Internet Protocol is the
communication protocol used to connect hosts on the Internet.
4. SYSTEM REQIREMENTS –
4.1 Hardware Requirements –
 RAM 1Gb, HDD 512Gb
 Scanner – USB 2.0 Interface, 4800dpi Optical Resolution
 Printer – Resolution 360dpi

4.2 Software Requirements –

 Operating System – Windows 7, Linux fedora


 Browser – Chrome 48.0.2564 , Firefox 47.0.1
 Database Management Software – Firebird 2.5
 Java IDE - Eclipse , NetBeans 7.4
4.3 Tools to be Used -
 UMLet
 Star UML
 Argo UML
5. UML DIAGRAM IDENTIFICATION –
The Unified Modelling Language (UML) is general purpose developmental
modelling language in the field of software engineering, that is intended to
provide a standard way to visualise the design of the system.

S. No. UML Diagram

1. Class Diagram

2. Object Diagram

3. State Diagram

4. Data Flow Diagram

5. Use Case Diagram

6. Activity Diagram

7. Sequence Diagram

8. Component Diagram

9. Deployment Diagram
1 . Class Diagram –
In software engineering, a class diagram in the Unified Modelling Language
(UML) is a type of static structure diagram that describes the structure of a
system by showing the system's classes, their attributes, operations (or
methods), and the relationships among objects.
In the diagram, classes are represented with boxes that contain three
compartments:

 The top compartment contains the name of the class. It is printed in bold
and centred, and the first letter is capitalized.
 The middle compartment contains the attributes of the class. They are
left-aligned and the first letter is lowercase.
 The bottom compartment contains the operations the class can execute.
They are also left-aligned and the first letter is lowercase.

The classes in the following class diagram are –

1. PassportAutomationSystem
1.1. Attributes
1.1.1. char Option
1.2. Methods
1.2.1. UserOrAdmin() – Selects whether the actor is USER or ADMIN.

2. User
2.1. Attributes
2.1.1. String LoginId
2.1.2. String Password
2.2. Methods
2.2.1. displayDetails() – Displays the user details
3. AdminLogin
3.1. Attributes
3.1.1. AdminLoginId
3.1.2. AdminPassword
3.2. Methods
3.2.1. login() – Getting access to the admin account.

4. AdminAuthentication
4.1. Attributes
4.1.1. PendingApplications
4.1.2. DispatchedPassports
4.1.3. ApplicationId
4.2. Methods
4.2.1. process() – Processes the requests generated by Admin .

5. NewUser
5.1. Attributes
5.1.1. String Name
5.1.2. String DOB
5.1.3. Char Gender
5.1.4. String EmailId
5.1.5. long MobileNo.
5.2. Methods
5.2.1. submit() – Submits the User information to the Database.
5.2.2. register() – Registers the user to the portal.
5.2.3. cancel() – Discards the user input details.

6. RegisteredUser
6.1. Attributes
6.1.1. String LoginId
6.1.2. String Password
6.2. Methods
6.2.1. UploadDocs() – Uploads the user documents to the portal.
6.2.2. CheckApplicationStatus() – Checks the Application status of the
applicant.
6.2.3. Paymentprocess() – Displays the various modes of fees payments.
6.2.4. SelectApointmentDate() – Provides the list of available dates to
select the appointment date.
2. OBJECT DAIGRAM :-
Object diagrams are derived from class diagrams so object diagrams are
dependent upon class diagrams.
Object diagrams represent an instance of a class diagram. The basic concepts
are similar for class diagrams and object diagrams. Object diagrams also
represent the static view of a system but this static view is a snapshot of the
system at a particular moment.
Object diagrams are used to render a set of objects and their relationships as an
instance.
The purpose of the object diagram can be summarized as −

 Forward and reverse engineering.


 Object relationships of a system

 Static view of an interaction.


 Understand object behaviour and their relationship from practical
perspective
OBJECT DIAGRAM
3. STATE DIAGRAM :-
A State chart diagram describes a state machine. State machine can be defined
as a machine which defines different states of an object and these states are
controlled by external or internal events.

Activity diagram explained in the next chapter, is a special kind of a State chart
diagram. As State chart diagram defines the states, it is used to model the
lifetime of an object.
Following are the main purposes of using State chart diagrams −

 To model the dynamic aspect of a system.


 To model the life time of a reactive system.

 To describe different states of an object during its life time.


 Define a state machine to model the states of an object.
4. DATA FLOW DIAGRAM :-
A data flow diagram (DFD) is a graphical representation of the "flow" of data
through an information system, modeling its process aspects. A DFD is often
used as a preliminary step to create an overview of the system without going
into great detail, which can later be elaborated. DFDs can also be used for
the visualization of data processing (structured design).

A DFD shows what kind of information will be input to and output from the
system, how the data will advance through the system, and where the data will
be stored. It does not show information about the timing of process or
information about whether processes will operate in sequence or in parallel
unlike a flowchart which also shows this information.

LEVEL 0
LEVEL 1
5. USECASE DIAGRAM :-

To model a system, the most important aspect is to capture the dynamic


behavior. Dynamic behavior means the behavior of the system when it is
running/operating.

Only static behavior is not sufficient to model a system rather dynamic


behavior is more important than static behavior. In UML, there are five
diagrams available to model the dynamic nature and use case diagram is one of
them.

The internal and external agents are known as actors. Use case diagrams
consists of actors, use cases and their relationships.
In brief, the purposes of use case diagrams can be said to be as follows −

 Used to gather the requirements of a system.


 Used to get an outside view of a system.

 Identify the external and internal factors influencing the system.


 Show the interaction among the requirements are actors.
6. ACTIVITY DIAGRAM :-

Activity diagram is another important diagram in UML to 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.
The control flow is drawn from one operation to another. This flow can be
sequential, branched, or concurrent.
The purpose of an activity diagram can be described as −

 Draw the activity flow of a system.


 Describe the sequence from one activity to another.

 Describe the parallel, branched and concurrent flow of the system.


7. SEQUENCE DIAGRAM –

 UML Sequence diagrams are used to represent or model the flow of


message, events or action between the objects and components of the
system.
 It is primarily used to design document and validate the architecture,
interfaces and logging to the system.
 Sequence diagrams provide a dynamic view to the system behaviour
which can be difficult to extract from static diagrams or specifications.
 In the sequence diagrams the time is represented in the vertical direction
showing the sequence of interaction of the header element.
8. COMPONENT DIAGRAM –

 It is used to describe the physical artefacts of the system and


implementation perspective.
 Component diagrams are difficult in terms of nature and behaviour.
Because it does not describe the functionality of all systems, but it
describes the components used to make those functionalities.
 Components diagrams can also be used to describe as static
implementation view of the system. Static implementation represents the
organization of the components at a particular moment.

The usages of the component diagram can be described as:


 Model the components of the system.
 Model database schema.
 Model executable of an application.
 Model systems source code.
9. DEPLOYMENT DIAGRAM –

 Deployment diagrams are used to visualize the topology of the


physical component their distribution and association of a system
where the software components are deployed.
 Component diagrams are used to describe the component and
deployment diagram shows how they are deployed in hardware.
 UML is mainly designed to focus on software artifacts of a system.
But these two diagrams are used to focus on software component
and hardware component.
 The nodes appear as boxes, and the artifacts allocated to each node
appear as rectangles within the boxes. Node may have sub nodes,
which appear as nested boxes.
 A single node in a deployment diagram may conceptually represent
multiple physical nodes, such as a cluster of database servers.
 The usage of deployment diagrams can be described as follow:
 To model the h/w topology of a system.
 To model embedded system.
 To model h/w details for a client /server system.
 To model h/w details of a distribution application.
 Forward and reverse engineering.

You might also like