II-se Lab Manual

Mailam Engineering College
Mailam, Villupuram (Dt.) Pin: 604 304

(Approved by AICTE, New Delhi, Affiliated to Anna University, Chennai
& Accredited by TCS)
Department of Information Technology
SOFTWARE ENGINEERING LABORATORY

LAB MANUAL
II YEAR-IV SEM
IT6413 SOFTWARE ENGINEERING LABORATORY

OBJECTIVES
To understand the software engineering methodologies for project development.
To gain knowledge about open source tools for Computer Aided Software
Engineering.
To develop an efficient software using case tools.
SOFTWARE REQUIRED:
Open source Tools: StarUML /UMLGraph /Topcased
Prepare the following documents for each experiment and develop the software using
software engineering methodology.
1. Problem Analysis and Project Planning
Thorough study of the problem
Identify Project scope, Objectives and Infrastructure.
2. Software Requirement Analysis
Describe the individual Phases/modules of the project and Identify deliverables.
3. Data Modeling
Use work products
Data dictionary, use case diagrams and activity diagrams, build and test class
diagrams, sequence diagrams and ad interface to class diagrams.
4. Software Development and Debugging
Implement the design by coding
5. Software Testing
Prepare test plan, perform validation testing, coverage analysis, memory leaks,
develop test case hierarchy, Site check and site monitor
TABLE OF CONTENTS
S.NO
DATE
TITLE OF PROJECT
1.
Case Study of Software engineering and
2.
Course Registration System
3.
Student marks analyzing system
4.
Online ticket reservation system
5.
Expert system to prescribe the medicines
6.
Remote computer monitoring
7.
ATM system
8.
Stock maintenance
9.
Quiz System
UML Notation
for the given symptoms
SIGNATURE
10.
Ex No : 1
E-mail Client system
CASE STUDY OF SOFTWARE ENGINEERING AND UML NOTATION
Date :
Aim:
To understand the software engineering methodologies for project development.
To gain knowledge about open source tools for Computer Aided Software
Engineering.
To develop an efficient software using case tools.
1. Introduction to Software Engineering:

1.1 Software engineering is the application of a systematic, disciplined, quantifiable
approach to the development, operation, and maintenance of software, and the study
of these approaches; that is, the application of engineering to software.
1.2 Software development process is a structure imposed on the development of a
software product.
1.3 Software life cycle model
A software life cycle model is either a descriptive or prescriptive characterization of
how software is or should be developed. A descriptive model describes the history of
how a particular software system was developed
1.4 Software development activities
2. Introduction to UML (Unified Modeling Language):

UML
Unified Modeling Language (UML) is a standardized general-purpose modeling
language in the field of software engineering. The Unified Modeling Language (UML) is
used to specify, visualize, modify, construct and document the artifacts of an objectoriented software intensive system under development.
UML diagrams to be developed are:
1. Use Case Diagram.
2. Class Diagram.
3. Interaction Diagram
3. 1 Sequence Diagram.
3.2 Collaboration Diagram.
4. State Diagram
5. Activity Diagram.
6. Component Diagram
7 Deployment Diagram
2.1 UseCase Diagrams:

A usecase diagram shares the common properties as all diagrams. It distinguishes in
the contents of use cases, actors, dependency, and generalization relationships.
2.2 Class diagrams:

A class diagram is that which represents a set of classes, interfaces, and
collaborations and their relationships, graphically a class diagram is a collection of
vertices and arcs.
It consists of three compartments.
2.3 Interaction Diagrams:

An Interaction diagram shares the same common properties as all other diagrams. It
differs in its contents
Objects
Links
Messages
It includes two diagrams Sequence and Collaboration

2.3.1 Sequence Diagram.
A sequence diagram emphasizes the time ordering of messages. Sequence diagrams

have two features that distinguish them from collaboration diagrams.
(i)Object life time
(ii)The focus of control
2.3.2 Collaboration Diagram.
A collaboration diagram emphasizes the organization of the objects that participate in
an interaction
Collaboration diagrams have two features that distinguish them from sequence
diagrams.
(i)Path
(ii) The Sequence number
2.4 State Diagram

State: A state is a condition during the life of an object or an interaction during which
it satisfies some condition, performs some action, or waits for some event. It is
represented by a rounded rectangle.
Symbol:
2.5 Activity Diagram

It represents the different activities in the system. Action State: An action state
represents the execution of an atomic action, typically the invocation of an operation.
2.6 Component Diagram
A component represents a modular, deployable, and replaceable part of a system that
encapsulates implementation and exposes a set of interfaces
2.7 Deployment Diagram

Node:
A node is a run-time physical object that represents a computational resource,
generally having at least a memory and often processing capability as well, and upon
which components may be deployed
Symbol:
Conclusion:
Thus a detailed case study of software engineering and UML notation was
studied successfully.
Ex No: 2
COURSE REGISTRATION SYSTEM
Date:
AIM:
To develop a software for course registration system
Phase 1: Problem Analysis and Project Planning
(i) Problem Statement:
Queue Problem:
In order to register for a course a customer needs to wait in long queues
Transport Problem:
A customer has to travel a long distance from far away places to where the
University or the Colleges are located.
Loss of Money:
A lot of money is spent for the journey and for refreshments by the customer
while travelling to the University or College.
Employees Problem:
A lot of Employees has to be recruited in order to handle the large number of

customers.
Need for Branches:
The University or the Colleges needs to open many branches at many places in
order to cover the customer.
Maintenance of Data:
Difficulty in handling large amount of data, as everything is done manually. So,

misplacement of forms and other errors are possible.
Timing not Flexible:
The customer could not register for a course at his/hers feasible timings, as the
University or the College is open only during the office hours.
(ii) Identification of Project scope, Objectives and Infrastructure
To develop an Online Course Registration System with the objective of enabling

students to register for a course from any part of the world through internet
Hardware Interfaces:
There must be a minimum of 128 MB RAM, 40 GB HDD
Software Interfaces:
The operating system used is windows XP or higher version and Open source
UML Tool ArgoUML.
Operating Environment:
The system works in Windows XP or higher versions.
ArgoUML Tool
Design and Implementation Details:
Hardware limitations: There must be at least 64 MB on-board memory.
Control function: in case of errors and service problems, proper error handling
and data recovery mechanism must be included.
Interface to other applications: not applicable
Parallel operations: not applicable
Signal handshake protocols: not applicable
Reliability
requirements:
data
redundancy
and
use
of
special/blank
characters must be avoided.
Safety/security constraint: The application must be excited always normally.
Higher order language requirements: C++ or Java
Phase 2: Software Requirement Analysis
The main purpose of the Software Requirement Analysis is to maintain all

functions and specifications of Online Course Registration System
(i) Software Requirement Specification (SRS):
The purpose of the Software Requirement Specification document is to maintain

the functions and specifications of a particular system. Besides it contains the
detailed descriptions of all the requirements specified
(ii) Modules/phases of the project:

1. User should be able to:
Sign-Up if not an already registered user.
Login to the system using a Login-ID and password.
Change the password after logging in, if necessary.
See the vacancy for the courses.
View course details.
Choose the desired and the available course.
Confirm the choice by registering for the course
2. A mail should be sent to the concerned persons e-mail ID about the confirmation
of registration.
3. The Login ID and the Password should be sent to the mentioned e-mail address if a
new account is created.
4. System should automatically show the course details after registering for the
particular course
Phase 3: Data Modeling

(i) Data Dictionary:
The data dictionary is a database that is used to record the complete business
requirement for any system, and the implementation of those requirements into
the various computer systems to service the business needs.
(ii) Product Perspective:
The product is independent of other applications but dependent on registration

websites where the user need to login. This dependency exists because of the
need for accessing the users details and course details.
(iii)Product Functionality:
Signing up and becoming an authenticated User: The user has to give some
personal details to sign up and to become an authenticated user in order to use
the system
Login to the system: Login to the system using his/her Login ID and Password
date. The Server then validates the Login ID and Password and allows the user
access the system.
Check Availability of the course: User could check the availability of the
desired course and then go for the registration of the course.
Selection of course: Based on the availability of the courses the user chooses
the desired course.
Registration: After selecting a particular course the user needs to fill a form to
register for the course.
View course details: After registering for the course, the course details are
displayed to the user.
(iv) USE CASE DIAGRAM:
Use case diagrams describe what a system does from the standpoint of an
external observer. The emphasis is on what a system does rather than how. Use
case diagrams are closely connected to scenarios. A scenario is an example of
what happens when someone interacts with the system.
Use Case Scenario:
A Use Case Scenario shows the flow of events of use case diagram.
The flow of events are basic flow and alternate flow.
Identifying use-cases and actors:

Use-Cases:
1. Sign-Up
SIGN-UP
2. Login
3.
Check
LOGIN
Availability
4. Course
Selection
5.
Payment
User
COURSE SELECTION
6.
7. Logout
8. Course Details
REGISTRATION
COURSE DETAILS
Server
Registration
Fig: Use Case Diagram
Actors:
1. Student
2. Server
3. Administrator
Use-case scenario:
1. Sign-Up:Description:
The main purpose of using this use case is to get the details of the User before
he/she uses the system. The details asked would include the Name, E-mail ID, Mobile
No. etc.
Flow of Events:
Basic Flow-B:
1. User clicks the Sign-Up button and enters the Sign-Up page.
2. User fills all the details asked.

3. The Submit button is clicked.
4. All the details are sent to the Server for verification.
5. Details are verified and Success page is displayed.
Alternate Flow-A1:
1. User clicks the Sign-Up button and enters the Sign-Up page.
2. User fills all the details asked.
5. The Server compares the already existing User names.
6. User name already exists, Error page displayed.
Alternate Flow-A2:
i.
User clicks the Sign-Up button and enters the Sign-Up page.
ii.
User fills all the details asked.
iii.
The Submit button is clicked.
iv.
All the details are sent to the Server for verification.
v.
Mandatory details are not entered, Error page is displayed.
Pre-Condition:
User should have all the mandatory details of the student.
Post-Condition:
Details are sent to the Server and User enters the Log-In page.
2. Login:The main purpose of using this use case is to check authentication of the User
going to use the system.

Flow of Events:
Basic Flow-B:
i.
User enters the Login ID and Password into the specified text box.
ii.
Sign-Up button is clicked.
iii.
Login ID and Password are sent to the Server for verification.
iv.
Login ID and Password is verified, Success page is displayed.
Alternate Flow-A:
i.
User enters the Login ID and Password into the specified text box.
ii.
Sign-Up button is clicked.
iii.
Login ID and Password are sent to the Server for verification.
iv.
Login ID or Password is wrong, Error page is displayed.
Pre-Condition:
User should have both Login ID and Password.
Post-Condition:
User enters the Course Selection page.
3. Course Selection:Description:
The main purpose of this use case is to select the available course.
Flow of Events:
Basic Flow-B:
i.
User chooses a course.
ii.
The chosen course is sent to the Server and it checks for availability.
iii.
Availability of course is displayed to the User.
iv.
Confirmation of course is made.
Alternate Flow-A:
1. User chooses a course.
2. The chosen course is sent to the Server and it checks for availability.
3. Course not available, Error page is displayed.
Pre-Condition:
The User should know which course to select.
Post-Condition:
User enters the registration page.
4. Registration:Description:
The main purpose of this use case is to get the required details for the selected course
from the User.
Flow of Events:
Basic Flow-B:
i.
User enters all the details asked.
ii.
The Register button is clicked.
iii.
All the details are sent to Server for verification.
iv.
A registration number is generated and displayed to User.
Alternate Flow-A:
i.
User enters all the details asked.
ii.
The Register button is clicked.
iii.
All the details are sent to Server for verification.
iv.
Mandatory details are not entered, Error page is displayed.
Pre-Condition:
User should have all the details of the student.
Post-Condition:
Course details are displayed.
5. Course Details:Description:
The main purpose of this use case is to display all the details about the course
to the user like fees structure etc.
Flow of Events:
Basic Flow -B:
All the details about the course are displayed.
Post Condition: User logs-out of the system
(v) ACTIVITY DIAGRAM:

An Activity Diagram shows sequential and parallel activities in a process. They are
useful for modeling business processes, workflows, data flows, and complex
algorithms
Description:
The activity diagram for Online Course Registration System is drawn as shown
in the Figure below. It consists of eight activities and five decisions.
In the first activity the user sign-ups followed by a decision which checks
whether the user name is available. If yes it proceeds to the next step, if no
the above activity is performed again. The next step consists of a decision which
checks whether all mandatory details are entered. If yes it proceeds to the next
step, if no the above activity is performed again.
The next step consists of an activity where the user enters the login page,
followed by another activity where user enters Login ID and Password. The next
step consists of a decision where it checks whether Login ID and Password are
authentic. If yes it proceeds to the next step, if not the above activity is
performed again.
The next step consists of an activity where the user enters course selection page
followed by another activity where user selects a course. The next step consists
of a decision where it checks whether the selected course is available or not. If
available it proceeds to next step, if not the above activity is performed again.
The next step consists of an activity where the user enters registration page
followed by another activity where user enters the details of the student. The
next step consists of a decision where it checks whether all mandatory details
are entered or not. If yes it proceeds to next step, if no the above activity is
performed again.
The next step consists of an activity where the user views the course details.
The Activity is terminated finally.
Fig: Activity Diagram
No
User Sign-up's
No
Us er name
available
Yes
Mandatory
Details Entered
Yes
Enters Login
Page
Types Login ID and

Pass word
No
Login ID and
Pass word Authentic
Yes
Enters Course
Selection Page
Selects Course
No
Course Available
Yes
Enters Registration
Page
Enters Student
Details
No
Mandatory
Details Entered.
Yes
Views Cours e
Deatils
(vi) CLASS DIAGRAM:
User
name : String
login_id : String
password : String
age : Integer
sex : String
email_id : String
course_name : String
Server
login_id : String
password : String
course_fees : Integer
course_name : String
reg_no : Integer
login()
sign_up()
course_selection()
course_confirm()
register()
Figure (a)
signup_verify()
login_verify()
check_availability()
verify_details()
display_details()
generate_regno()
Figure (b)
Description:
The class diagram for the Online Course Registration System consists of two
classes User and Server as shown in Figure (a) and Figure (b) respectively.
The User class consists of the following attributes and operations:

Attributes:
name, login_id, password, sex, email_id and course_name which are of data type
String and age which is of data type Integer.
Operations:
login(), sign_up(), course_selection(), course_confirm() and register().
The Server class consists of the following attributes and operations:
Attributes: l
Login_id, password and course_name which are of data type String and course_fees
and reg_no which are of data type Integer.
Operations:
signup_verify(),
login_verify(),
check_availability(),
verify_details(),
display_details(), generate_regno().
(vii) SEQUENCE DIAGRAM:
A Sequence Diagram is a picture that shows, for one particular scenario of a

use case, the events that the external actors generate, their order, and intersystem events. All systems are treated as a black box; the emphasis of the
diagram is events that cross the system boundary from actors to systems.
signup-:
Sign-Up
Screen:
: User
: Server
User enters the details

Details sent to Server for verification
Verification
Details verified and Sucess page displayed
login-:
Login Screen:
: User
: Server
User enters Login ID and Password

Login ID and Password sent to Server for verification
Verification
Login ID and Password verified, Success page is displayed
course selection-:
Screen:
: User
: Server
User chooses a course

Availability of course is checked
Check Availability
Availabilty Displayed
User confirms choice of selection
Confirmation sent to server
Registration-:
Screen:
: User
: Server
User enters all the details

All details sent to server for verification
Verification
Registration number generated and displayed
course details-:
screen:
: user
: server
1: user request course details

2: course details displayed
Phase 4: Software Development and Debugging

Code generation:
The Code Generation generates the code for the process using
some programming languages like java, C++ etc.

Program code:
class user
{
void login()
{
}
void sign_up()
{
}
void course_selection()
{
}
void course_confirm()
{
}
void register()
{
}
}
class server
{
void signup_verify()
{
}
void login_verify()
{
}
void check_availability()
{
}
void verify_details()
{
}
void display_details()
{
void generate_regno()
{
}
}
Phase 5: Software Testing
Test cases:
A test case is a set of conditions or variables under which a tester will determine
whether a system under test satisfies requirements or works correctly.
Test Plan:
A test plan is a document detailing a systematic approach to testing a system such as

a machine or software. The plan typically contains a detailed understanding of the
eventual workflow.
Validation:
Validation checks that the product design satisfies or fits the intended use (high-level
checking), i.e., the software meets the user requirements. This is done through
dynamic testing and other forms of review.
Code coverage is a measure used to describe the degree to which the source code of a
program is tested by a particular test suite. A program with high code coverage has
been more thoroughly tested and has a lower chance of containing software bugs than
a program with low code coverage.
Deployment:
A Deployment Diagram shows the assignment of concrete software artifacts to
computational nodes. It shows the deployment of software elements to the physical
architecture and the communication between physical elements.
Description:
The deployment diagram consists of a single processor i.e. the SERVER and
three devices i.e. the three CLIENTS which are connected to the SERVER processor
through Wide Area Connection (WAN) and n number of CLIENTS could be connected
to the SERVER through WAN.
Performance Requirements:
More than one user of the system cannot access the system at the same time. The
course selection can be performed under certain constraints or else the system should
behave in a graceful manner. Entering illegal details, accessing personal details of
other users should be prevented.
Safety and Security Requirements:
The User name and Password should match and valid.

The User should provide valid personal information.
Conclusion:
Thus the software for course registration system has been developed and
documentation created successfully.
Ex No: 3
STUDENT MARKS ANALYSING SYSTEM
Date:
Aim:
To develop a software for Student Mark Analysis system
Problem Statement:
A Problem Statement lists out the problems faced by the process before the
development of the System.
(i) Thorough study of the problem:
Maintenance of Student data is a major issue.
FEASIBILITY ANALYSIS
Feasibility is the study of impact, which happens in the organization by the

development of a system. Here the feasibility study can be performed in two
ways such as technical feasibility and Economical Feasibility.
Technical Feasibility:
We can strongly says that it is technically feasible, since there will not be much
difficulty in getting required resources for the development and maintaining the
system as well. All the resources needed for the development of the software as
well as the maintenance of the same is available in the organization here we are
utilizing the resources which are available already.
Economical Feasibility
Development
of
this
application
is
highly
economically
feasible
.The
organization needed not spend much money for the development of t he system
already available. The only thing is to be done is making an environment for the
development with an effective supervision. I f we are doing so, we can attain the
maximum usability of the corresponding resources .Even after the development,
the organization will not be in condition to invest more in the organization.
Therefore, the system is economically feasible.
(ii). Identify Project scope, Objectives and Infrastructure

1. Objectives
The Specifications and the use-case model together capture a complete set of
requirements on the system.
2. Scope
Specification defines the non-functional requirements of the system; such as

reliability, usability, performance, and supportability, as well as functional
requirements that are common across a number of use cases.
The report describes the logical and systematical functions of Student Mark
Analyzing System. The staff and student are the users of the system.
The system will acquire details of student from the faculties and analyzes the
obtained data then declare the results based on the grade criterias of the
institution where student will play vital role of client that is they just acquire
the processed information from the system database.
The staff must be careful while uploading the results.
MODULAR DESCRIPTION
MARK ENTRY MODULE:
This module enables the authenticated users to record the marks and thereby
their respective grades in a database. This is the most important module as it
maintains the details of the marks scored by the students in the database and
it is the first and the foremost step in this system.
GRADE MODULE:
This module permits the respective users to view their grades as and when
necessary after their identification through their login name and password.
This module proves to be the simplest as it does not allow the user to modify or
update any information except viewing them.
UPDATE MARKS MODULE:
This module enables the authenticated users to update the marks of the
students after each and every test in order to update the data to the present
existing grades of the students. This module just allows the user to modify or
update the grades of the students alone but not their personal details. This
module does not allow any user just like that only authenticated users are
allowed to update the necessary data after their identification through their
login name and password.

1. Brief Description
The use case describes how a user logs into the Course Registration System.
2. Flow of Events
Basic Flow
This use case starts when the user wishes to Login to the Course Registration System
1. The System requests that the user enter his/her name and password
2. The user enters his/her name and password
3. The System validates the entered name and password and logs the user into the
System
Alternative Flows
Invalid Name/Password
If, in the Basic flow, the user enters an invalid name and/or password, the system
displays an error message. The user chooses to either return to the beginning of the
Basic flow or cancel the login, at which point the use case ends.
Pre-Conditions
None
Post-Conditions
If the use case was successful, the user is now logged into the system. If not, the
System State is unchanged.
3. Maintain Professor Information

Brief Description
This use case allows the Registrar to maintain professor information in the registration
system. This includes adding, modifying and deleting professors from the system.
Flow of Events
Basic Flow
This use case starts when the Registrar wishes to add, change, and /or delete
professor information in the system.
1. The system requests that the Registrar specify the function he/she would like to
perform (either Add a Professor, Update a Professor, Or Delete a Professor)

2. Once the Registrar provides the requested information, one of the sub flows is
executed.
If the Registrar selected Add a professor , the Add a Professor sub flow is executed.
If the Registrar selected Update a professor , the Update a Professor sub flow is
executed.
If the Registrar selected Delete a professor , the Delete a Professor sub flow is
executed.
USE CASE DIAGRAM:
Fig. Use Case Diagram
CLASS DIAGRAM:
Fig. class diagram
ACTIVITY DIAGRAM:
Fig. Activity Diagram
SEQUENCE DIAGRAM:
Fig. Sequence Diagram

class student
{
public: student()
{
}
void getdata()
{
}
void putdata()
{
}
};
class mrks: public student
{
}
void output()
{
}
void calculate ()
{
}
};
void main()
{

Test cases:
Test Plan:
eventual workflow.
Validation:
Conclusion:
Thus the Student marks analyzing system was successfully analyzed, designed,
implemented, verified and tested successfully.
Ex. No.: 4
Online Ticket Reservation System
Date:
Aim :
To develop a software for an online ticket reservation system
Problem statement:
To list out the problems faced by the process of reservation of railway tickets
before the development of the System.
i. Thorough study of the problem:
Queue Problem:
In order to reserve for a ticket a passenger needs to wait in long queues, as all
the passengers come to the same spot for Reservation.
Transport Problem:
A passenger has to travel a long distance from far away places to where the
Railway stations are located.
Employees Problem:
A lot of Employees has to be recruited in order to handle the large number of
passengers.
Maintenance of Data:
Difficulty in handling large amount of data, as everything is done manually. So,
misplacement of forms and other errors are possible.
Timing Inflexibility:
The passenger could not reserve for a ticket at his/hers feasible timings, as the
ticket counter is open only during the office hours.
ii.Identify Project scope, Objectives and Infrastructure

To develop an online ticket reservation system with the objective of enabling
passengers to reserve for a particular train at the specified time from any part of the
country through internet
The Scope of Online Railway Reservation System is:
1. User should be able to:
Register if not an already registered user.
See current reservations on different rails along with details.
Give details about the credit card.
2. A mail should be sent to the concerned persons e-mail ID about the

confirmation of ticket.
3. The Login ID and the Password should be sent to the mentioned e-mail address
if a new account is created.
4. System should automatically show the fare for the corresponding seat and
amount needs to be pay for selected seats.
The operating system used is windows XP or higher version and the open
source Argo UML and the database management software is Oracle.
ArgoUML Tool
Reliability
requirements:
data
redundancy
and
use
of
special/blank

Online Railway Reservation System has been developed with the objective of enabling
passenger to reserve for rail ticket from any part of the world through internet.
Document Purpose:
The main purpose of the Software Requirement Specification document is to maintain
all functions and specifications of Online Railway Reservation System.
Intended Audience and Document Overview:

SRS includes two sections: overall descriptions and specific requirements,
Overall Description will describe the major role of the system components and
interconnections.
Specific Requirements will describe the roles and functions of the actors
Definitions, Acronyms and Abbreviations:

Definitions:
Passenger: End user, he/she can reserve for a ticket using a personal computer
connected to the internet.
Server: This is the database where all details are sent for storage and later
referred for other purposes.
Product Perspective:
websites where the user need to login. This dependency exists because of the need for
accessing the passengers details and train details.
Product Functionality:
Registering and becoming an authenticated User: The user has to give some
the system
access the system.
Reservation of ticket: choosing the seats which are available to book. Two
weeks advance reservation is available.
Cancel: The passenger can cancel the ticket by PNR.no provided by the server
while reservation.
Ticket status: Mail should be send to the person about the confirmation of
ticket.
Users and Characteristics:

The major user of the system is the passenger. The major user characteristics are:
The end user should have a basic knowledge of internet and Computers.
They shall see the rails information which is belong to current time.
It also needs a Oracle server.
Reliability
requirements:
data
redundancy
and
use
of
special/blank
Assumptions and Dependencies:
The user name and password should match.
The user should have personal details of the passenger who are going to travel.
External Interface Requirements:

User Interfaces:
The user interface of this system is simple and can be understood even by
inexperienced users.
Screen format/organisation: The introductory screen will ask for username

and password. After verification of the details provided by the user, he will be
allowed to access the system and the menu will be displayed.

Window format/organization: Each function will lead to another window.
The user can switch between windows whenever required.

End message: When there are some errors entering invalid data, error
message will be displayed.
Functional Requirements:
The functional requirement of the project includes:
Creating separate account for different Users.
User then logs in to the system using his/her Login ID and Password.
Allowing the Passenger to choose the desired tickets based on availability.
The Passenger then reserve for the ticket by filling a form.
The server then checks the form, to verify if all the mandatory details are
entered.
Finally the Ticket details are displayed to the User by the Server.
Other Functional Requirements:

Performance Requirements:
ticket reservation can be performed under certain constraints or else the system
should behave in a graceful manner. Entering illegal details, accessing personal details
of other passengers should be prevented.
Safety and Security Requirements:
Software Quality Attributes:
Correctness
Flexibility
Interoperability
Maintainability
Portability
Reusability
Testability
Phase 3: Data Modelling

To identify the possible use cases for the Online Railway Reservation System and then
finalize it.
Use Cases:
1. Register
2. Login
3. Train Details
4. Reservation
5. Ticket Status
6. Cancel
7. Print Ticket
8. Logout
Actors:
1. Passenger
2. Server
3. Administrator
USE CASE DIAGRAM
REGISTER
LOGIN
PASSENGER
RESERVATION
CANCEL
TICKET_STATUS
Fig. Use Case Diagram
SERVER
USE CASE SCENARIO

1. Register:
Description:
The main purpose of using this use case is to get the details of the User before
he/she uses the system. The details asked would include the Name, E-mail ID, Mobile
No. etc.
Flow of Events:
Basic Flow-B:
1. Passenger clicks the Register button and enters the Registration page.
2. Passenger fills all the details asked.
5. Details are verified and Success page is displayed.
Alternate Flow-A:
5. The Server compares the already existing User names.
6. User name already exists, Error page displayed.
Alternate Flow-A1:

5. Mandatory details are not entered, Error page is displayed.
Pre-Condition:
User should have all the mandatory details of the Passenger.
Post-Condition:
Details are sent to the Server and User enters the Log-In page.
2. Login:
The main purpose of using this use case is to check authentication of the
Passenger going to use the system.
Flow of Events:
Basic Flow-B:
1. Passenger enters the Login ID and Password into the specified text box.
2. Login button is clicked.
3. Login ID and Password are sent to the Server for verification.
4. Login ID and Password is verified, Success page is displayed.
Alternate Flow-A:
1. User enters the Login ID and Password into the specified text box.
2. Login button is clicked.
3. Login ID and Password are sent to the Server for verification.
4. Login ID or Password is wrong, Error page is displayed.
Pre-Condition:
Passenger should have both Login ID and Password.
Post-Condition:
Passenger enters the Reservation page.
3. Reservation:Description:
The main purpose of this use case is to reserve the ticket in train.
Flow of Events:
Basic Flow-B:
i.
Passenger should click the reservation icon.
ii.
Server provides the reservation form.
iii.
Passenger fills the form and clicks submit button
iv.
Server will verify the details and store it.
v.
Server will now provide the PNR.NO to Passenger
Alternate Flow-A:
i.
Passenger clicks the reservation page
ii.
Server provides the reservation form.
iii.
If the Passenger gives invalid credit card number an error page displays.
Pre-Condition:
The Passenger has to decide about whether he/she is going to travel.
Post-Condition:
Passenger will get the ticket.
4. Cancel:Description:
The main purpose of this use case helps the Passenger to cancel the ticket
which he/she has booked earlier.
Flow of Events:
Basic Flow-B:
i.
Passenger cancels the ticket by typing the PNR.NO on the cancellation form.
ii.
Server requests its database to search for the PNR.NO.
iii.
Server will cancel the ticket and request database to delete the passenger
reservation information.
iv.
Server will send the conformation message about the cancellation.
Alternate Flow-A:
i.
Passenger cancels the ticket by typing the PNR.NO on the cancellation form.
ii.
If the Passenger enters the invalid PNR.NO, an error message will display.
iii.
Server asked the Passenger to enter valid PNR.NO
Pre-Condition:
Passenger should have booked the ticket earlier.
Post-Condition:
Entering the PNR.NO will cancel the ticket.
5. Course Details:Description:
The main purpose of this use case is to know the satus of the ticket by entering
the PNR.NO
Flow of Events:
Basic Flow -B:
i.
Passenger should give the PNR.NO to know the status of the ticket which
he/she booked earlier.
ii.
Server displays the status of the ticket.
Alternate Flow-A:
i.
Passenger had entered invalid PNR.NO which does not exist, an error
message displays.
Pre-Condition:
The Passenger had reserved the ticket in train
Post Condition:
The use case is successful and Passenger logs-out of the system.
CLASS DIAGRAM
PASSENGER
User_Name : string
Password : string
Name : string
Age : integer
Sex : string
Address : string
Contact_no : integer
Login()
Register()
Reservation()
Cancel()
Ticket_status()
SERVER
Date : date
Source : string
Destination : string
Train_name : string
No_of_tickets : integer
*
1
Validate()
Issue_ticket()
Cancel_reservation()
Modify()
Fig. Class diagram for Railway reservation System
Description:
As mentioned earlier the class diagram is the one which plays one of the most
important role in writing the coding for the project. Using this class diagram the
coding for the given project is written with the concept of mapping design to code.
Here in this above class diagram we make use of two classes (i) PASSENGER (ii)
SERVER hence these two classes are first created in the coding. In the class
PASSENGER we make use of the attributes like Username, Password etc are used
and are declared along with its corresponding data types similarly the attributes that
are used in the class diagram are used in their corresponding classes in the coding
now similarly the operations that are used in the class diagrams are used as the
functions in the corresponding classes in the coding.
Program code:
class Passenger
{
void register()
{
}
void log_in()
{
}
void reservation()
{
}
void cancel()
{
}
void ticket_status()
{
}
}
class Server
{
void validate()
{
}
void issue_ticket()
{
}
void cancel_reservation()
{
}
void modify()
{
}
}
Test cases:
Test Plan:
eventual workflow.
Validation:
DEPLOYMENT DIAGRAM:
To visualize the topology of the physical components of a system where the software
components are deployed.
Conclusion:
Thus the online ticket reservation system was successfully analyzed, designed,
implemented, verified and tested successfully.
Ex No: 5
Expert system to prescribe the medicines for the
Date:
given symptoms
Aim:
To develop software for Expert system to prescribe the medicines for the given
symptoms
Problem Statement:
The medical expert provides the user to which they are put, and the relative
positions of the developer, physician, and patient, strict tort liability should adhere to
the developer.
The existing system has few limitations which make it difficult to use. The
limitation of the existing system is that the system is to get treatment only by
consulting the doctors. The system does not have facilities to update. In the existing
system details cannot be modified often. The present system is inefficient and time
consuming. Only one appointment cannot be changed. The prescription is not
specified after consulting in database. The receptionist cannot give proper details of
appointment.
The objective of the present system is that the consultant through the system
by providing sufficient information. New appointments can be added to the database.
The proposed system is used by the hospitals to give the details description of disease
and the treatment with respect to disease. The system is programmed is such a way
that each time appointment time is over the database updates automatically. The
proposed system that is being developed is user friendly system. The processing speed
is very high when compared to the existing system. The space occupied by the
proposed system in the memory is also very less. The doctor details can be known.
There is review of details of disease treatment. The appointment can be made
Hard disk: The database connectivity requires a hardware configuration that is online. This makes it necessary to have a fast database system (such as any RDBMS)
running on high rpm hard-disk permitting complete data redundancy and backup
systems to support the primary goal of reliability.
The system must interface with the standard output device, keyboard and mouse to
interact with this software.
Software interfaces:
ArgoUML Tool

The main purpose of the Software Requirement Analysis is to maintain all functions
and specifications of an ATM System.
Software Requirement Specification (SRS):
The purpose of the Software Requirement Specification document is to
maintain the functions and specifications of a particular system. Besides it contains
the detailed descriptions of all the requirements specified
Modules/phases of the project:

The product is independent of other applications but dependent on the type of ATM
System where the user need to login. This dependency exists because of the need for
accessing the users savings details.

Use Case Diagram:
external observer. The emphasis is on what a system does rather than how. Use case
diagrams are closely connected to scenarios. A scenario is an example of what
happens when someone interacts with the system.
Use Case Scenario:
A Use Case Scenario shows the flow of events of use case diagram. The flow of events
are basic flow and alternate flow.
DESCRIPTION:
EXPLANATION:
In this case the patient informs to the system about symptoms. The use cases used
here are symptoms disease medication and insufficient information. The treatment
can be searched by database stored in medical expert system.
Fig Use Case Diagram
Activity diagram- An Activity Diagram shows sequential and parallel activities in a

process. They are useful for modelling business processes, workflows, data flows, and
complex algorithms
Description:
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of abstraction
that allows easier, faster operation and reduces the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the nave
users.
The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use
this product.
Constraints:
At the time of creating the new account, each user gives a pin number and is
provided with a unique card number that must be used for further
transactions. Hence the user is required to remember or store these numbers
carefully.
At the time of creating the new account, the initial deposit should not be less
than the specified amount
Logical Database Requirements
The system should contain databases that include all the necessary
information for the product to function according to the requirements. These
include relations such as Customer Details and Account Details.
Customer details refer to the customers name and address. Account details of
the customer include the card number, account type, transaction type and the
pin number given by the user to be used at the time of the transaction at the
bank.
EXPLANATION
The first step is to give symptoms. Then the system identifies the disease. After
identifying it gives details of the respected medicine and dosage to the patient if it
unidentified the disease it displays insufficient information
Class diagram:
Description:
The class diagram for the ATM System consists of two classes User and Server
as shown in Figure (a) and Figure (b) respectively.
EXPLANATION:
The detail of both management (reception) and the user (patient and staff) all combine
together to give the details. Generalization is show here. Multiplicity is show between
patient and system
Fig Class Diagram
Sequence diagram: A Sequence Diagram is a picture that shows, for one particular
scenario of a use case, the events that the external actors generate, their order, and
inter-system events. All systems are treated as a black box; the emphasis of the
diagram is events that cross the system boundary from actors to systems.
EXPLANATION
The first step is to give symptoms. Then the system identifies the disease after
identifying it gives details of the respected medicine and dosage to the patient if it
Unidentified the disease it displays insufficient information
Fig. Sequence diagram for Register with Expert System Use Case
Fig. Sequence diagram for Register with Expert System Use Case
Fig. Sequence diagram

Code generation:

Deployment: A Deployment Diagram shows the assignment of concrete software
artefacts to computational nodes. It shows the deployment of software elements to the
physical architecture and the communication between physical elements
Explanation:
The medical expert system software is installed in the hospital server which can
be accessed from anywhere. The external pc can just see the details and user performs
all the operation.
Conclusion:
Thus the software for expert system to prescribe the medicines for the given
symptoms has been developed and documentation created successfully
Ex.No: 6
Remote computer monitoring
Date:
AIM:
To
develop
software
for
remote
computer
monitoring
system
with
documentation.
Traditional Methodologies
The existing system is used to edit the form, update the patient details of the
hospital management system. The retrieving of required data of the patients, staff
details, fees, Expense, drug, admission, income.
Problem Definition:
The main idea of problem analysis is collecting data on the existing system and
performing critical documentation of data and its related information.
The Problem Analysis is conducted with following objectives,
To maintain the patient details of the hospital.
To maintain the details of the staff members.
Retrieving the resulted data.

The Project Hospital Management is done to computerize the hospital details
and to maintain it focus on higher availability. By using this project we can be able to
retrieve all the details of the patient and staff members.

It is fully computerized so it eliminates the problems of existing system. The
system has been developed using Visual Basic as front end and MS Access as back
end. The system is planned to provide more forms and also to satisfy the hospital
management users. The form and also to satisfy the hospital management users.
The form details are as follows
The patient details.
The staff member details ( the staff member varies from higher hierarchy to
lower hierarchy including Doctors, Nurse, House Keeping, Drivers/security).
The admission form for admission of a patient details.
The doctor form displays the details of a doctor.
The drugs form displays the drug details and the stock available in the hospital.
The expense form gives the information that is used to maintain the whole
hospital for per annum.
The income form displays the details of the hospital income for per week, per
month, per annum.
The fees form includes the fees of a doctor ,room, etc.
The driver form displays the details of a driver.
The House keeping form display the details of a house keeper.

SYSTEM DESIGN
Fig Use Case diagram
Fig Activity diagram:
Sequence Diagram:
Fig Sequence diagram

There are two types of software testing
1. Code testing.
2. Specification Testing .
The philosophy of testing is to mind the errors. Test cares are designed. A Test is a set
of data that system will process at normal input.
UNIT TESTING:
The form that made up of system are tested in unit testing
Unit testing is preformed from bottom up starting with the smallest and lowest
level models and processed one at time
The bottom level modules are tested and the next level in the lower one are
tested
SYSTEM TESTING:
System tested is done to find the description between the system and its
original objective, current specification and system documentation.
INTEGRATION TESTING:
Integration testing is a systematic testing the construction of the form structure

while at same time conducting test to remove errors associated within the
interface.
Asking the users about the form required by then test the output generated are
all displayed by system under consideration.
Output testing has not resulted in many corrections in the systems.
Conclusion:
Thus the remote computer monitoring system was successfully analyzed,
designed, implemented, verified and tested successfully.
Ex.No:7
ATM SYSTEM
Date:
AIM:
To develop a software for ATM system with documentation.
Problem Statement:
Banking is one of the common and day to day attribute of life. Nowadays it is
totally different from that existed a few years ago banking has become completely
computerized new facilities such as credit cards, debit cards & ATM has been
introduced. ATM is automatic teller machine which is basically used to withdraw
money from an account.
ATM is another type of banking where the most frequently type of transaction
made is withdrawal. A user may withdraw as much as many amount as he wants until
his account holds a sum greater than his withdrawal amount. ATM is completely
automated and there is no necessity of the ATM center being placed at the bank itself.
It can be placed in the shopping malls, airports, railway stations etc.
This ATM system can use any kind of interface. But it should be user friendly
and not confusing. Help manuals should be provided in case any customer has
problem working with the software.

The system will retain information on the entire customer who has necessity
rights to access the service. It will contain the balance amount in the account, rate of
interest, any special allowance for that customer and most of all pin number of the
customer. Some customer could have availed some special offers on his ATM cards. So
this must be taken care of and the appropriate data should be dealt with.
The ATM should provide easy access to the data for the customer. It should also
have a highly secure interface so that one can take money one behalf of others. So the
security is one of the main aspects in ATM.
The objective of this software is similar to ATM software installed in ATM center.
It should first validate the pin in the ATM card. Then the type of transaction is
enquired and the information from the customer is validated. If it is a withdrawal the
amount is asked. After the money is delivered the transaction just made is updated in
the database where the customers information is stored.
The scope of the project is to design an ATM system that will help in completely
automatic banking this software is going to be designed for withdrawal and deposit of
money and register the transaction in the database where the customers information
is stored.
Hard disk:
The database connectivity requires a hardware configuration that is on-line.
This makes it necessary to have a fast database system (such as any RDBMS) running
on high rpm hard-disk permitting complete data redundancy and backup systems to
support the primary goal of reliability.
The system must interface with the standard output device, keyboard and
mouse to interact with this software.
Software interfaces:
ArgoUML Tool
The main purpose of the Software Requirement Analysis is to maintain all functions
and specifications of an ATM System.

To develop an ATM system to perform the following functions:
The customer logs into the system using card number and pin number. The
system checks for validation.
The system queries the customer for the type of account either fixed deposit or
credit account. After getting the type of account the system shows the balance
left.
The system queries the customer for the transaction type either withdrawal or
deposit and the required amount. The user enters the amount and the
transaction if carries out.
The intended audience is any person who wants
To create account.
To withdraw or deposit either in fixed deposit or credit account
Allow a new user to create an account, either fixed or credit account by entering
the details and by depositing an initial amount.
Allow the existing user to enter his account details like card number, pin
number and account type to view his balance.
Allow the existing user to deposit an amount by entering the amount to be

deposited after the balance had been viewed.
Allow the existing user to withdraw an amount by entering the amount to be

withdrawn after the balance had been viewed.
The primary benefits expected of the system are: user friendly, continuous
connectivity without failure, fault tolerant and involves lesser manpower

The product is independent of other applications but dependent on the type of
ATM System where the user need to login. This dependency exists because of the need
for accessing the users savings details.
Product Functionality:
the system
access the system.
Check Availability of the money: User could check the availability of the
money and then go for withdrawal or deposit.
Selection of account type: Based on the user need chooses the desired
withdrawal or deposit option.
Transaction: After selecting a particular option the user needs to transfer or

deposit or withdraw the needed amount.
View account status: After transaction, the account details are displayed to
the user through a bill.
USE CASE DIAGRAM:

diagrams are closely connected to scenarios. A scenario is an example of what
happens when someone interacts with the system.
Use Case Scenario:
A Use Case Scenario shows the flow of events of use case diagram. The flow of
events are basic flow and alternate flow.
Identifying use-cases and actors:
Creating a New Account
The user should provide his personal details to facilitate the bank clerk to
create a new account.
Identified use cases

i. Login:
Here the user enters the card and the inputs his password to enter into the main
form. If the password is incorrect, the system will display an error message.
ii. Transaction:
This is the important part of the ATM system, where there are two types of
transaction-withdrawal and deposit. While withdrawing the user specifies the amount
and may request for the printed output also.
iii. Maintaining Customer Information:
Here the administrator plays an important role, whose work is to add customer, delete
customer account, update customer account, etc.
Identified Actors
i Administrator:
Administrator plays an important role. He is the system designer. All the updating
works is done by him only like adding, deleting customer accounts.
ii Database:
All the transaction works-withdrawal and deposit are updated in the database.
iii Customer:
He is the external user the ATM system for taking money and depositing money also.
USE CASE DIAGRAM FOR ATM SYSTEM
customer
bank
ask login id()

display error message()
login
transaction (withdrawal) maintain customer information
atm system
database
administrator
Use case scenario:

1. Login
Brief description:
This use case describes how the user logs into the System.
Flow of events:
Basic flow:
This use case starts with the actor wishes to log in to the ATM System.
1. The system requests the user to enter the name and PIN.
2. The actor enters the name and PIN.
3. The system validates the name and the PIN and logs the user into the system.
Alternative flow:
1. If the user enters the wrong name and the PIN then the system displays an
error message.
2. The actor can either return to the basic flow or cancel login at which point use
case ends.
Pre conditions:
None
Post conditions:
User will perform corresponding transaction.
2. Transaction
Brief description:
This describes the transaction that the user is doing.
Flow of events:
Basic flow:
i.
This use case starts after the user has logged on to the system.
ii.
The system requests the user to enter the type of transaction of either
withdrawal or deposit and asks for customer information.
iii.
The actor enters the type of transaction and the customer information.
iv.
The system displays the corresponding transaction screen.
Alternative flow:
If the customer enters any wrong information then the system displays an error
message.
Pre Condition:
The user logs on to the system.
Post Condition:
Based on the transaction he gets the transaction screen.
3. Maintain Information about Customer
Brief description:
This describes how administrator takes care of customer information.
Flow of events:
Basic flow:
This use case starts after the administrator has logged into the system.
1. The system asks the administrator whether he wants to add or delete customer
information.
2. The administrator then enters the type of maintenance.
Alternative flow:
None
Pre Condition:
The administrator logs on to the system before this use case begin.
Post Condition:
Administrator gets the corresponding maintenance screen according to his choice.
Adding Customer
Basic flow:
1. This use case starts when the administrator has chosen to add customers
information.
2. The system asks the administrator to enter customer information.
3. The administrator enters the customer information.
4. The system displays the updated information.
Alternative flow:
If the administrator enters any wrong information the system displays an error
message.
Deleting Customer
Basic flow:
1. This use case starts when the administrator has chosen to delete an existing
customer from the system.
2. The system asks the administrator to enter the customer information.
3. Administrator enters the corresponding user information.
4. The system then displays updated results.
Alternative flow:
If the administrator has entered any wrong information then the system displays
administrator error message.
Updating an existing Customer account
Basic flow:
1. This use case starts when the administrator has chosen to update the customers
information.
2. The system asks the administrator to enter the customer information.
3. The administrator enters the customer information.
4. The system displays the updated information.
Alternative flow:
If the administrator has entered any wrong information then the system displays
administrator error message.
Activity diagram- An Activity Diagram shows sequential and parallel activities in a
process. They are useful for modelling business processes, workflows, data flows, and
complex algorithms
Description:
The intended users of this software need not have specific knowledge as to what is the
internal operation of the system. Thus the end user is at a high level of abstraction
that allows easier, faster operation and reduces the knowledge requirement of end user
The Product is absolutely user friendly, so the intended users can be the nave
users.
The product does not expect the user to possess any technical background. Any
person who knows to use the mouse and the keyboard can successfully use
this product.
Constraints:
At the time of creating the new account, each user gives a pin number and is
provided with a unique card number that must be used for further
transactions. Hence the user is required to remember or store these numbers
carefully.
At the time of creating the new account, the initial deposit should not be less
than the specified amount.
Logical Database Requirements
The system should contain databases that include all the necessary
information for the product to function according to the requirements. These
include relations such as Customer Details and Account Details.
Customer details refer to the customers name and address. Account details of
the customer include the card number, account type, transaction type and the
pin number given by the user to be used at the time of the transaction at the
bank.
initilisation
event(add record)[fullfill bank
req]/rec is added to the datab...
event(delete record)[bank balance

less than request]/ record is dele...
add
delete
update
Class diagram:
Description:
The class diagram for the ATM System consists of two classes User and Server
as shown in Figure (a) and Figure (b) respectively.
1.Login
customer
ask login id()
main window
<< >>
error message.
login window
welcome message
login contooller
2. Transaction:
customer
ask login id()

<< >>
transaction screen
initiate transaction()
provide information()
+1
+1...*
<< >>
generate report
+1
+1
<< >>
update database
+1
+0...*
<< >>
error message.
SEQUENCE DIAGRAM:
use case, the events that the external actors generate, their order, and inter-system
events. All systems are treated as a black box; the emphasis of the diagram is events
that cross the system boundary from actors to systems.
1. Login:
: customer
main window login window
login
controller
welcome
screen
error message
1: run atm()
2: ask login id()

3: provide login id()
4: verification()
5: successful()
6: un successfull()
7: display error message()
Fig Sequence Diagram Login
2. Maintenance:
: administrator
main window
maintanance
window
1: ask type of maintanence

2: provide information
3: add
4: delete
sequence
diagram
5: updete customer information
sequence
diagram
sequence
diagram
Fig Sequence Diagram Maintenance
3. Adding customer:
: administrator
add customer
information
add customer
error message
form
1: request customer information
2: provide customer information

3: verification
4: valid information
5: display error message

6: re-enter
: database
4. Deleting customer:
: administrator
maintenance
window
delete
error message
customer
1: ask customer details
3: valid details
4: remove form database
5: invalid details
updete
database
5. Updating customer:
: administrator
maintain
window
update
database
1: ask customer details
2: enter customer details

3: correct details
4: incorrect details
6. Transaction:
error message
: customer
transaction
screen
update
database
1: initiate transaction
3: correct
4: incorrect
error message

Code generation:

Deployment:
A Deployment Diagram shows the assignment of concrete software artefacts to

architecture and the communication between physical elements
Conclusion:
Thus the software for ATM system has been developed and documentation
created successful
Ex.No:8
STOCK MAINTENANCE SYSTEM
Date:
AIM:
To create a software to perform the Stock maintenance
Problem Statement:
The stock maintenance system must take care of sales information of the
company and must analyze the potential of the trade. It maintains the number of
items that are added or removed. The sales person initiates this Use case. The sales
person is allowed to update information and view the database.
Stock maintenance project mainly used to store the stock details and retrieve
the data. Stock entry forms are used to update the databases. The sale form can be
used to view the sales details. The company return form can be used to show the
details of defective products. Item details can be used to show the current status of
the stock. The exit buttons closes the forms of the project.
To develop a Stock maintenance System with the objective of enabling
companies to maintain current status of the stock.

functions and specifications of a Stock Maintenance System.

Authentication
Stock entry
Sales Details
Order Details
Item Details
MODULE DESCRIPTION:
1. Authentication
Get the username and password validate it accordingly.
2. Stock Entry
Product purchased details are entered through this form. It can be used to enter the
item code name, bought cost, company name and no. of items. The data is then stored
in the database.
3. Stock Details
In this module its used to store the sales product details and also show the sales
details.
4. Order Details
Order details form can be used to generate orders and view previous stored order
details.
5. Item Details
Show the current details of the stock details.
NON FUNCTIONALITY:
SECURITY
It is a source project because it contains user id and password.
MAINTAINABILITY
Authorized user only can access it, thus it is easily maintainable.
AVAILABILITY
It is available for all type of companies (i.e.) large scale or small scale.
FLEXIBILITY
It is a user friendly project. More modules can be easily added, thus it is quite
flexible.

USE CASE DIAGRAM:
Use case diagrams describe what a system does from the standpoint of an external
observer. The emphasis is on what a system does rather than how. Use case diagrams
are closely connected to scenarios. A scenario is an example of what happens when
someone interacts with the system.
Use Case Scenario:
are basic flow and alternate flow.
The functionality of a system can be described in a number of different use-cases,
each of which represents a specific flow of events in a system. It is a graph of actors, a
set of use-cases enclosed in a boundary, communication, associations between the
actors and the use-cases, and generalization among the use-cases.
The use cases used in this system are
1. Product details: Used for placing an order.
2. Purchase details: Used for tracking items that have been ordered.
3. sales details: Used for give the sales particulars about a item.
4. stock details: Used for give the stock detail in a shop.
5. Purchase the product: Used to provide bills for the customer.
6. supply the product: Used to give the order product to customer.
ACTORS
The actors used in this system are
1. Customer: The person who orders for the item.
2. Shopkeeper: The items ordered by the customer are validated.
3. Company: Maintains the stock details after delivering the items to the
customer.
product details
purchase details
customer
shopkeeper
sales details
stock details
purchase the product

company
supply the product
Fig. USE CASE DIAGRAM
(IV) ACTIVITY DIAGRAM

It shows organization and their dependence among the set of components. These
diagrams are particularly useful in connection with workflow and in describing
behavior that has a lot of parallel processing. An activity is a state of doing something:
either a real-world process, or the execution of a software routine.
login
order
product
check
availability
product stock
details
do
payment
if available
if not available
cancle
order
get
payment
recive the
stock
logout
Fig.ACTIVITYDIAGRAM
(V) CLASS DIAGRAM

Description:
A class diagram describes the type of objects in system and various

kinds of relationships that exists among them.
Class diagrams and collaboration diagrams are alternate representations

of object models.
The Stock maintenance system class diagram consists of seven classes:

1. PurchaseDetails: One who takes orders for the product?
2. SalesDetails: The customer make an order for the required products.
3. Product Details: The items that are stored as stock.
purchaseDetails
purcCode : integer
purcDate : date
subid : integer
subname : string
purcQty : integer
purcPrice : float
productDetails
prodCode : integer
prodName : string
prodQty : integer
prodPrice : float
prodAdd()
prodDelete()
prodUpdate()
prodDetails()
save()
delete()
purchasedit()
purchaseDetials()
salesDetails
salId : integer
salDate : date
custCode : integer
custName : string
prodCode : integer
price : integer
qty : integer
sale()
salesDetails()
Fig. CLASS DIAGRAM
(VI)UML INTERACTION DIAGRAMS

It is the combination of sequence and collaboration diagram. It is used to depict the
flow of events in the system over a timeline. The interaction diagram is a dynamic
model which shows how the system behaves during dynamic execution.
1. 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.
o
An event also is considered to be any action by an object that sends

information. The event line represents a message from one object to another, in
which the from 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.
customer
shopekeeper
dealer
database
1. request for item

2. enter the details
3.send for item

4.check for product availability
5.update product details
. 6. product available
7. send for quation
8.request for delivery

9.order item
10.update delivery details

11.product delivery
Fig. SEQUENCE DIAGRAM
2. COLLABORATION DIAGRAM
Collaboration diagram and sequence diagrams are alternate representations of an
interaction. A collaboration diagram is an interaction diagram that shows the order of
messages that implement an operation or a transaction. Collaboration diagram is an
interaction diagram that shows the order of messages that implement an operation or
a transaction. Collaboration diagram shows object s, their links and their messages.
They can also contain simple class instances and class utility instances.
During, analysis indicates the semantics of the primary and secondary
interactions. Design, shows the semantics of mechanisms in the logical design of
system.
1: request for item

8: request for delivery
custome
r
shopeke
eper
enter the details

11: product delivery
2:
7: send for quation
update delivery details

9:
recording sales
10:
send for item

order item
3:
5: update product details
4: check for availability

databas
e
dealer
6: product available
Fig. COLLABORATION DIAGRAM
(VII) DEPLOYMENT DIAGRAM AND COMPONENT DIAGRAM
Fig..DEPLOYMENT DIAGRAM
Deployment diagrams are used to visualize the topology of the physical components of
a system where the software components are deployed.
(VIII) IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL

SERVICE LAYER
//Source file: E:\\10764\\productDetails.java
public class productDetails
{
private integer prodCode;
private string prodName;
private integer prodQty;
private float prodPrice;
/**
@roseuid 5167CD420232
*/
public productDetails()
{
/**
@roseuid 512702DE0128
*/
public void prodAdd()
{
/**
@roseuid 512702E4003E
*/
public void prodDelete()
{
/**
@roseuid 512702EF003E
*/
public void prodUpdate()
{
}
/**
@roseuid 512B3FAC007F
*/
public void prodDetails()
{
}
}//Source file: E:\\10764\\purchaseDetails.java
public class purchaseDetails

{
private integer purcCode;
private date purcDate;
private integer subid;
private string subname;

private integer purcQty;
private float purcPrice;
/**
@roseuid 5167CD4201D4
*/
public purchaseDetails()
{
/**
@roseuid 5127049302DE
*/
public void save()
{
/**
@roseuid 512704970232
*/
public void delete()

{
/**
@roseuid 5127049F00FA
*/
public void purchasedit()
{
/**
@roseuid 512B3FC102C1
*/
public void purchaseDetials()
{
}
}
//Source file: E:\\10764\\salesDetails.java
public class salesDetails

{
private integer salId;
private date salDate;
private integer custCode;
private string custName;
private integer prodCode;
private integer price;
private integer qty;
/**
@roseuid 512840E5009C
*/
public salesDetails()
{
/**
@roseuid 512705AD030D
*/
public void sale()
}
}
Deployment:
A Deployment Diagram shows the assignment of concrete software artefacts to
architecture and the communication between physical elements.
Conclusion:
Thus the software for Stock Maintenance system has been developed and
documentation created successfully
Ex.No: 9
Quiz Systems
Date:
AIM:
To develop a software for online quiz system
Problem Statement:
Conducting a Quiz program involves more maintenance of data and also the
result updating takes more time. More staffs need to be involved.
To develop an Online Quiz Registration System with the objective of enabling
students to register for a Exam from any part of the world through internet
Operating Environment
It also needs a Oracle server.
Design and Implementation Details
Control function: in case of errors and service problems, proper error

handling and data recovery mechanism must be included.
Reliability requirements: data redundancy and use of special/blank

Safety/security constraint: The application must be excited always

normally.
Higher order language requirements C++ or Java
User Interfaces
The user interface of this system is simple and can be understood even by
inexperienced users.
Screen format/organisation: The introductory screen will ask for username

and password. After verification of the details provided by the user, he will be
allowed to access the system and the menu will be displayed.
Window format/organization: Each function will lead to another window. The

user can switch between windows whenever required.
Data Format: The data entered by the users will be alphanumeric.
End message: When there are some errors entering invalid data, error message
will be displayed.
Hardware Interfaces
Software Interfaces
The operating system used is windows XP or higher version and the

database management software is Oracle.

functions and specifications of an online quiz System.

The Scope of Online exam Registration System is:
User should be able to:
Sign-Up if not an already registered user.
View exam details.
Choose the desired and the available exam.
Confirm the choice by registering for the exam.
A mail should be sent to the concerned persons e-mail ID about the

confirmation of registration.
The Login ID and the Password should be sent to the mentioned e-mail address
if a new account is created.
System should automatically show the exam details after registering for the
particular exam.
Functional Requirements
The functional requirement of the project includes:
Creating separate account for different Users.
User then logs in to the system using his/her Login ID and Password.
Allowing the User to view the availability of the desired exam.
Allowing the User to choose the desired exam based on availability.
The User then registers for the exam by filling a form.
The server then checks the form, to verify if all the mandatory details are
entered.
Finally the exam details are displayed to the User by the Server.
Other Functional Requirements

Performance Requirements
course selection can be performed under certain constraints or else the system should
behave in a graceful manner. Entering illegal details, accessing personal details of
other users should be prevented.
Safety and Security Requirements

websites where the user need to login. This dependency exists because of the need for
accessing the users details and exam details.
Product Functionality
the system
access the system.
Check Availability of the course: User could check the availability of the desired
exam and then go for the registration of the course.
Selection of course: Based on the availability of the courses the user chooses the
desired exam.
Registration: After selecting a particular course the user needs to fill a form to
register for the exam.
View course details: After registering for the exam, the exam details are displayed
to the user.
USE CASE DIAGRAM:

diagrams are closely connected to scenarios.
A scenario is an example of what happens when someone interacts with the system.
Use Case Scenario:
is basic flow and alternate flow.
USE CASE DIAGRAM FOR QUIZ SYSTEM
Fig: Use Case Diagram

Use case scenario:
1. LOGIN
Brief Explanation
Login in a authentication or verification used to verify the registered user .Only
registered users can log into the website.

Basic Flow
1. User enters the username and password
2. Click ok
3. Server verifies the user registration
4. Username and password is correct
5. enters into the home page.
Alternative Flow
1. User enters the username and password
2. Click ok
3. Server verifies the user registration
4. Username and password is incorrect, Re-enter the username and password
5. Enter into the login page.
Precondition: Registered user
Postcondition: Enters into the homepage of the website
2 .DISPLAY EXAM DETAILS

Brief Description
It is a function in which exam details are displayed
It will display the amount of fee, exam date ,exam duration etc.
Basic Flow
1. After entering into homepage click ON view exam details.

2. It will display the main page of exam details
3. Each exam may contain separate pages to view exam details
Precondition: Home page of the website
Post condition: Main page of exam details
3. REGISTRATION
Brief Description
In this use case we will enter the users personal details like name, age,
sex, college and also we will select the exam which we are going to register.
Basic Flow
1. After viewing exam details, select the exam which we have to register.
2. Then enter age, name, exam-date, sex.
3. Then click Ok.
4. Entered data is verified with server data.
5. It will display registration is completed.
6. Enter the page to pay money.
Alternative Flow
1. After viewing exam details ,select the exam which we have to register ..
2. Then enter age, name, exam-date, sex
3. Then click OK.
4. Entered data is verified, then it will return entered exam-date is not
Re-enter another date
5. Enter into the page to fill details.
present,
Precondition: Home page of exam details

Postcondition: Enter into the page to pay money by online.
4. ONLINE PAY
Brief Description
It is pay the money by online, we can pay the money by online by using
credit card, Debit card, cheque etc. It is easy to use online payment .
Basic Flow
1. After entering into the page to pay money, we have to close the Credit /Debit.
2. Fill the details credit /Debit like account holder name, pin no ,card no , valid
form.
3. Click OK or Submit.
4. Verify the card details with server.
5. The returns payment completed.
6. Then show the acknowledge (hall ticket)
Alternative Flow: A1
1. After entering into the page to pay money, we have to close credit/Debit.
2. Fill details like account holder name, pin no, card no, valid form .
3. Click OK.
4. Verifies the card with server.
5. Returns card is not valid.
6. Enters into the home page of payment
Alternative Flow: A2
1. After entering into the page to pay money, we have to close credit/Debit.
2. Fill details like account holder name, pin no, card no, valid form.
3. Click Ok.
4. Verifies card is not valid.
5. Returns card no is invalid.
6. Enters into the home page of payment.
Precondition: Home page for payment
Post condition: Acknowledgement will receive
5. LOGOUT
Brief Description
It is used to come out of current website .
Basic Flow
1. After entering into logout page.
2. Click On logout.
3. At last we will come out of website.
Precondition
Logout page.
Postcondition
Closing the website.
ACTIVITY DIAGRAM:
An Activity Diagram shows sequential and parallel activities in a process. They are
useful for modeling business processes, workflows, data flows, and complex
algorithms.
Description
The activity diagram for Online Exam Registration System is drawn as shown in
the Figure. It consists of eight activities and five decisions.
In the first activity the user sign-ups followed by a decision which checks
whether the user name is available. If yes it proceeds to the next step, if no
the above activity is performed again. The next step consists of a decision which
checks whether all mandatory details are entered. If yes it proceeds to the next
step, if no the above activity is performed again.
The next step consists of an activity where the user enters the login page,
followed by another activity where user enters Login ID and Password. The next
step consists of a decision where it checks whether Login ID and Password are
authentic. If yes it proceeds to the next step, if no the above activity is
performed again.
The next step consists of an activity where the user enters exam selection page
followed by another activity where user selects a exam. The next step consists of
a decision where it checks whether the selected exam is available or not. If
available it proceeds to next step, if no the above activity is performed again.
The next step consists of an activity where the user enters registration page
followed by another activity where user enters the details of the student. The
next step consists of a decision where it checks whether all mandatory details
are entered or not. If yes it proceeds to next step, if no the above activity is
performed again.
The next step consists of an activity where the user views the exam details. The
Activity is terminated finally.
CLASS DIAGRAM
Description:
The class diagram for the online quiz System consists of three classes Admin,
User and Compiler respectively.
Description
The class diagram for the Online Quiz System consists of three classes Admin, User
and Compiler respectively.
The Admin class consists of the following attributes and operations:
Attributes:user ID, user password,
Operations:registration(),calculation(),systemmanagement().
The user class consists of the following attributes and operations:
Attributes: user id, password, name.

Operations: plays(),signup().
The compiler class consists of the following attributes and operations:
Attributes: name list, question, answer.
Operations: askquestion(),keepsmark().
SEQUENCE DIAGRAM:
use case, the events that the external actors generate, their order, and inter-system
events. All systems are treated as a black box; the emphasis of the diagram is events
that cross the system boundary from actors to system
Fig Sequence Diagram Login
Fig Sequence Diagram

Code generation: The Code Generation generates the code for the process using some
programming languages like java, C++ etc.
Program code
Class user
{
Public void registration()
{
}
Public void online play()
{
}
Public void signup()
{
}
Public void logout()
{
}
};
Class admin
{
Void display exam details()

{
}
Void register()
{
}
Void calculation()
{
}
Void payment()
{
}
Void centralsystemmanagement()
{
}
};
Class compiler
{
Public string question;
Public string answer;
public string namelist;
Void askquestions()
{
}
Void keepsmark()
{
}
Void compiler()
{
}
}
};
DEPLOYMENT:
A Deployment Diagram shows the assignment of concrete software artifacts to
architecture and the communication between physical elements
Description:
The Deployment diagram for Online Exam Registration System is drawn as
shown in . The deployment diagram consists of a single processor i.e. the SERVER and
three devices i.e. the three CLIENTS which are connected to the SERVER processor
through Wide Area Connection (WAN) and n number of CLIENTS could be connected
to the SERVER through WAN
Conclusion:
Thus
the
software
for
online
documentation created successfully.
quiz
system
has
been
developed
and
Ex.No:10
E-Mail based client recruitment system
Date:
AIM:
To develop software for an E-Mail based client recruitment system with
documentation.
The recruitment system allows the job seekers to enroll their names through
the process of registration. The employee also can get the list of available candidates
and shortlist for their company requirement. Once the applicant enrolls he receives an
id, which helps him in further Correspondence. A fees amount is received from the job
seekers for enrollment. This system makes the task of the job seeker easier rather
than waiting in queue for enrollment. This also reduces the time consumption for both
for the job seeker and employee.

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 recruitment can use this system to reduce
his workload and process the application in a speedy manner.
Provide a communication platform between the applicant and the administrator.
Transfer of data between the Recruitment Issuing Authority and the Local Police for
verification of applicant's information.
Users/Applicants will come to know their status of application and the date in which
they must subject themselves for manual document verification.
Infrastructure
The operating system used is windows XP or higher version and the open
source Argo UML .The database management software is Oracle server.
ArgoUML Tool
Reliability
requirements:
data
redundancy
and
use
of
special/blank

Recruitment Automation System is an interface between the Applicant and
the Authority responsible for the Issue of Recruitment. It aims at improving the
efficiency in the Issue of Recruitment and reduces the complexities involved in it to
the maximum possible extent.
PURPOSE
If the entire process of 'Issue of Recruitment' is done in a manual manner then
it would takes several months for the recruitment to reach the applicant. Considering
the fact that the number of applicants for recruitment 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.
TOOLS TO BE USED
Netbeans IDE (Integrated Development Environment)
Agro UML tool (for developing UML Patterns)
PRODUCT PERSPECTIVE
The PAS acts as an interface between the 'applicant' and the 'administrator'. 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 recruitment.
SOFTWARE INTERFACE
Front End Client - The applicant and Administrator online interface is built using
JSP and HTML. The Administrators's local interface is built using Java.
Web Server - Glassfish application server (SQL Corporation).
Back End - Oracle database.
HARDWARE INTERFACE
The server is directly connected to the client systems. The client systems have
access to the database in the server.
SYSTEM FUNCTIONS
Secure Registration of information by the Applicants.
Schedule the applicants an appointment for manual verification of original
documents.
Panel for Recruitment Application Status Display by the Administrator.
SMS and Mail updates to the applicants by the administrator.
Administrator can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.
USER CHARACTERISTICS
Applicant - They are the people who desire to obtain the recruitment and submit
the information to the database.
Administrator - He has the certain privileges to add the recruitment status and to
approve the issue of recruitment. He may contain a group of persons under him to
verify the documents and give suggestion whether or not to approve the dispatch of
recruitment.
Police - He is the person who upon receiving intimation from the PAS, perform a
personal verification of the applicant and see if he has any criminal case against him
before or at present. He has been vetoed with the power to decline an application by
suggesting it to the Administrator if he finds any discrepancy with the applicant. He
communicates via this PAS.
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.
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.
The Recruitment Automation system use cases are:
Registration
Check status
Process Application
Dispatch Recruitment
Actors:
Actors are as follows:
1. HR Head.
2. Employee.
3. Candidates.
Actors Documentation:
1. HR Head: HR Head is an actor who informs about the vacancy to their employees
and also other regional HR Heads, who in turn informs their respective Employees and
also matches the skills of the referred Candidates with their skills, required for the
vacant position and shortlist them. HR Head is also responsible for Interview
Scheduling.
2. Employee: Employee is an actor who references the Candidates regardless of
his/her region and receives the incentives provided the referred Candidate got selected
3. Candidate: Candidate is an actor who is referred by an Employee of the Company
and applies for the vacancy. If the Candidate gets selected then they informs the HR
Head about the acceptance or rejection of the offer letter.
Use Case: Notify Vacancy
Description: This Use Case is initiated by HR and the Employee. Notifies about the
vacancies to employees of the region.
Flow of Events: HR Head sends Email notification to his/her employees. 2. HR Head
informs about vacancy to other region HR heads. 3. Other HR heads in turn inform
their employees.
Pre-Condition: Vacancy must exist.
Post-Condition: Details about the vacancy are informed.
Use Case: Filling of Forms

Description: This Use Case is initiated by HR and the Employee. Online forms are
filled by the employees. HR head processes the forms and determines eligible
candidates.
Flow of Events: 1. Employees fill out online forms of candidates they want to refer.
2. HR head processes the filled forms.
3. HR heads selects the list of eligible candidates.
Pre-Condition: Online form must exist.
Post-Condition: Forms filled are stored in a Information System for processing. The
filled forms are sent to the HR. The HR head produces the list of eligible candidates.
Use Case: Short Listing of Candidates

Description This Use Case is initiated by Candidate and HR. The Interviews are
conducted by the HR head of the region that has the vacancy. The lists of selected
candidates are obtained after the interview process.
Flow of Events:
1. HR head schedules the interview process.
2. HR head conducts the interview for the candidates via online system.
3. Candidates who clear the interview process are selected.
Pre-Condition: Candidate must meet eligibility criteria. Candidate must be referenced
by the employee of that organization.
Post-Condition Candidate clears interview process. OR Candidate doesnt clear

interview process.
Use CASE: Intimation to the selected candidates.
Description: This Use Case is initiated by the HR Head and the Candidate The
candidate accepts or rejects the offer letter to fill the vacancy. Bonus is awarded to the
employee who referred the candidate.
Flow of Events 1. Candidate is informed about selection the job.

2. Candidate accepts the job offer to fill the vacancy.
3. Bonus is awarded to the employee who referred the candidate.
Alternate Flow 1. Candidate rejects the offer letter.
2. Candidate application is rejected.
3. No Bonus is awarded to the employee who referred the candidate.
Pre-Condition: Candidate is selected for the job.
Post-Condition: Candidate accepts or rejects the offer. Bonus is awarded to the
employee who referred the candidate if he/she accepts the offer.
Fig Use Case Diagram
ACTIVITY DIAGRAM:
Fig. ACTIVITY DIAGRAM

UML CLASS DIAGRAM:
The UML class diagram is to illustrate class interfaces and their actions. They are
used for static object modeling, we have already introduced and used their UML
diagram while domain modeling.
UML SEQUENCE DIAGRAM:

A sequence diagram illustrates a kind of format in which each object interacts via
message. It is generalize between two or more specialized diagram.
POST- FUNCTION AND PRE-FUNCTION:
1. CANDIDATE REGISTRATION:
PRE-FUNCTION: Candidate should sign up by giving username and password.
POST-FUNCTION: Enter into the candidate information form, then candidate should
enter the personal details, qualification etc.
2. ACKNOWLEDGEMENT:
PRE-FUNCTION: Admin sends the reply to the candidate with register numbers.
POST-FUNCTION: Candidate could receive the mail from admin and get the register
no.
3. LOGIN:
PRE-FUNCTION: Candidate should given the register no as user name and same
password which has already given while sign up his/her account

POST-FUNCTION: Enter into the software to attend the aptitude test. It will show the
home page.
4. APTITUDE TEST:
PRE-FUNCTION: Candidate should attend the test which is conducted on online.
POST-FUCTION: Submit the answer sheet to admin.
5. RESULT VERIFICATION:
PRE-FUNCTION: admin should correct the answer sheet which has been sent by
candidate.
POST-FUNCTION: Admin should select the candidate on the basis of his/her process
and send the report to concerned candidate (selected candidate).
6. UPDATE:
PRE-FUNCTION: Admin should update the admin tools and company details to
respective candidates.
POST-FUNCTION:
Update are correctly views on the screen while user (candidate)
browse the particular webpage.
7. DIRECT HR INTERVIEW:
PRE-FUNCTION: Organization should check the certificates (if valid or not).
POST-FUNCTION: Direct questions are shooting out to the particular candidate.
8. JOB CONFORMATION DETAILS:

PRE-FUNCTION:
Organization should send the conformation letter to the selected
candidate.
POST-FUNCTION: Candidate should receive the appointment order with his/her
posting details.
Fig. Sequence Diagram
Fig. Sequence Diagram - Register:
Fig. Sequence Diagram for Admin

IMPLEMENTATION OF DOMAIN OBJECTS LAYER AND TECHNICAL SERVICE
LAYER
//Source file: F:\\student\\recruitment\\RegisterClass.java

public class RegisterClass
{
private string Name;
private integer Age;
private string Phone;

private string Qualification;
private string Percentage;
/**
* @roseuid 4D5CC46B038B
*/
public submit()
{
}}
//Source file: F:\\student\\recruitment\\Status_Class.java

public class Status_Class
{
private integer Id;
private string Name;
private string Response;
/**
* @roseuid 4D5CC46B038B
*/
public get_status()
{ }
}
Test cases:
Test Plan:
eventual workflow.
Validation:
Conclusion:
Thus the software for E-Mail based client recruitment system has been
developed and documentation created successfully.
STOCK MAINTENANCE SYSTEM

PROJECT
Aim: To create software to implement stock maintenance system.

Queries to create STOCK TABLE
CREATE TABLE stock
(
prodid INT PRIMARY KEY,
prodname VARCHAR2(50),
quantity INT,
unitprice INT,
reorder int
);
To View Table
select * from stock;
DESC stock;
Queries to create SALES TABLE

CREATE TABLE sale
(
prodid INT REFERENCES stock(prodid),
prodname VARCHAR2(50),
unitprice INT,
salesqty INT,
datetime VARCHAR2(50)
);
To View Table
Select * from sales;
DESC sales;
Sample Coding:
STOCK ENTRY FORM
CODING: STOCK ENTRY

package conn;
import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.PreparedStatement;
import javax.swing.JOptionPane;
import oracle.jdbc.OraclePreparedStatement;
import oracle.jdbc.OracleResultSet;
public class stockentry extends javax.swing.JFrame {
Connection conn=null;
OraclePreparedStatement pst=null;
OracleResultSet rs=null;
private void btnInsert_clickActionPerformed(java.awt.event.ActionEvent evt) {
// TODO add your handling code here:
try
{
Class.forName("oracle.jdbc.OracleDriver");
Connection
conn
=
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE", "hemesh", "123");
String
sql=
Insert
stock(prodid,prodname,quantity,unitprice,reorder)values(?,?,?,?,?)";
PreparedStatement pst=conn.prepareStatement(sql);
pst.setString(1,txt_prodid.getText());
pst.setString(2,txt_prodname.getText());
pst.setString(3,txt_quantity.getText());
pst.setString(4,txt_unitprice.getText());
pst.setString(5,txt_reorder.getText());
into
pst.execute();
JOptionPane.showMessageDialog(null,"Successfully Inserted");
}
catch (Exception e)
{
JOptionPane.showMessageDialog(null, e);
}
}
private void btnUpdate_clickActionPerformed(java.awt.event.ActionEvent evt) {
try
{
Connection
conn
=
String sql="update stock set prodname=?,quantity=?,unitprice=?,reorder=? where
prodid=?";
pst.setString(1,txt_prodname.getText());
pst.setString(2, txt_quantity.getText());
pst.setString(3, txt_unitprice.getText());
pst.setString(4, txt_reorder.getText());
pst.setString(5,txt_prodid.getText());
pst.executeUpdate();
JOptionPane.showMessageDialog(null,"Successfully Updated");
}
catch (Exception e)
{
JOptionPane.showMessageDialog(null,e);
}
STOCK SALES FORM
CODING: STOCK SALES

package stock;
import java.util.Date;
import java.text.SimpleDateFormat;
import java.sql.ResultSet;
public class stocksale extends javax.swing.JFrame {
/**
* Creates new form stocksale
*/
public stocksale() {
initComponents();
additems();
}
private void btnsell_clickActionPerformed(java.awt.event.ActionEvent evt) {

try{
Date d = new Date();
SimpleDateFormat
DATE_FORMAT
new
SimpleDateFormat("dd-MM-yyyy
'at'
HH:mm:ss a");
String date = DATE_FORMAT.format(d);
int i=Integer.parseInt(txt_salesqty.getText());
Class.forName("oracle.jdbc.OracleDriver")
Connectionconn= DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE",
"hemesh", "123");
String sql="update stock set quantity=quantity-'"+i+"' where prodid=?";
pst.setString(1,jComboBox1.getSelectedItem().toString());
Stringsql1="Insertintosale(prodid,prodname,unitprice,salesqty,datetime)values(?,?,?,?,
?)";
PreparedStatement pst1=conn.prepareStatement(sql1);
pst1.setInt(1,Integer.parseInt(jComboBox1.getSelectedItem().toString()));
pst1.setString(2, txt_prodname.getText());
pst1.setInt(3,Integer.parseInt( txt_unitprice.getText()));
pst1.setInt(4, Integer.parseInt(txt_salesqty.getText()));
pst1.setString(5,date);
pst1.execute();
JOptionPane.showMessageDialog(null, "Sucessfully Inserted");

}
catch (Exception e)
{
}
}
private void jComboBox1ItemStateChanged(java.awt.event.ItemEvent evt) {
try
{
Connectionconn=DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521
:XE", "hemesh", "123");
String sql="select * from stock where prodid=?";
pst.setString(1, jComboBox1.getSelectedItem().toString());
ResultSet rs=pst.executeQuery();
if(rs.next())
{
txt_prodname.setText(rs.getString("prodname"));
txt_unitprice.setText(rs.getString("unitprice"));
txt_salesqty.setText(rs.getString("salesqty"));
}
}
catch(Exception e)
{
}
}
public void additems()
{
try
{
Connectionconn= DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE",
"hemesh", "123");
String sql="select prodid from stock";
while(rs.next())
{
jComboBox1.addItem(rs.getInt("prodid"));
}
}
catch(Exception e)
{
}
Conclusion :
Thus software maintenance system software was successfully implemented.
ONLINE TICKET RESERVATION SYSTEM

PROJECT
Aim: To create software to implement online ticket reservation system.
Queries to create BUS TABLE
TABLE 1: BUS
create table bus (busid INT PRIMARY KEY,
travels VARCHAR2(50),
departure VARCHAR2(20),
arrival VARCHAR2(20),
duration INT,
seats int,
fare int
);
INSERT INTO
bus(busid,travels,departure,arrival,duration,seats,fare)VALUES(1,'VOLVO','11AM','2PM',3,50,0;
INSERT INTO
bus(busid,travels,departure,arrival,duration,seats,fare)VALUES(2,'RATHIMEENA','9AM','1PM',4
,48,350);
INSERT INTO bus(busid,travels,departure,arrival,duration,seats,fare)VALUES(3,'PARVEEN','8

AM','1 PM',5,45,750);
Queries to create BUSBOOKING TABLE

TABLE 2: BUSBOOKING
create table busbooking(busid INT PRIMARY KEY,availableseats INT);
insert into busbooking(busid,availableseats)values(1,50);
MAIN FORM
CODING :MAIN FORM

package e.ticketing;
public class Home extends javax.swing.JFrame {
}
private void jButton1ActionPerformed(java.awt.event.ActionEvent evt) {
this.setVisible(false);
new Reservation().setVisible(true)
}
RESERVATION FORM
CODING: RESERVATION
package e.ticketing;
import java.sql.ResultSet;
public class Reservation extends javax.swing.JFrame { int tbusid,fare,avail;
public Reservation() {
initComponents();
private
void
jrathimeenaActionPerformed(java.awt.event.ActionEvent
evt)

try
{
Connection
conn=DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","hemesh","1
23");
String sql="select * from bus where busid=2";
if(rs.next())
{
tbusid =rs.getInt("busid");
fare =rs.getInt("fare");
}
String sql1="select * from busbooking where busid=2";
ResultSet rs1=pst1.executeQuery();
if(rs1.next())
{
avail =rs1.getInt("AVAILABLESEATS");
availseat.setText(String.valueOf(avail));
}
}
catch (Exception e)
{
}
}
private void jparveenActionPerformed(java.awt.event.ActionEvent evt) {

try{
Connectionconn=
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","hemesh","123");

if(rs.next()){
}
if(rs1.next()){
}
}catch (Exception e)
{
}
}
private void jvolvoActionPerformed(java.awt.event.ActionEvent evt) {
try{
Connectionconn=
DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","hemesh","123");
if(rs.next()){
}
if(rs1.next()){
}
}catch (Exception e)
{
}
}
private void jconfirmseatsActionPerformed(java.awt.event.ActionEvent evt) {

try
{
int noseats=Integer.parseInt(jTextField1.getText());
int tfare=fare*noseats;
JOptionPane.showMessageDialog(null,"Your Booking Fare Amount: "+tfare);
if(avail>noseats)
{
Connectionconn=
String sql="update busbooking set availableseats=? where busid=?";
PreparedStatement pst=conn.prepareStatement(sql); //create a statement
pst.setInt(1,avail-noseats);
pst.setInt(2,tbusid);
JOptionPane.showMessageDialog(null,"Booking Confirmed");
}
else
{
JOptionPane.showMessageDialog(null,"Sorry Seats not Available");
}
}
catch (Exception e)
{
JOptionPane.showMessageDialog(null,e);
}
}
Conclusion:
Thus online ticket reservation software system was successfully implemented.

II-se Lab Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

II-se Lab Manual

Uploaded by

Copyright:

Available Formats

Mailam Engineering College

Mailam, Villupuram (Dt.) Pin: 604 304

Department of Information Technology

SOFTWARE ENGINEERING LABORATORY

IT6413 SOFTWARE ENGINEERING LABORATORY

To understand the software engineering methodologies for project development.

To develop an efficient software using case tools.

Thorough study of the problem

Identify Project scope, Objectives and Infrastructure.

2. Software Requirement Analysis

Describe the individual Phases/modules of the project and Identify deliverables.

Use work products

4. Software Development and Debugging

Implement the design by coding

Case Study of Software engineering and

Course Registration System

Student marks analyzing system

Online ticket reservation system

Expert system to prescribe the medicines

Remote computer monitoring

for the given symptoms

E-mail Client system

CASE STUDY OF SOFTWARE ENGINEERING AND UML NOTATION

To understand the software engineering methodologies for project development.

To develop an efficient software using case tools.

1. Introduction to Software Engineering:

2. Introduction to UML (Unified Modeling Language):

2.1 UseCase Diagrams:

2.2 Class diagrams:

It consists of three compartments.

2.3 Interaction Diagrams:

It includes two diagrams Sequence and Collaboration

A sequence diagram emphasizes the time ordering of messages. Sequence diagrams

2.4 State Diagram

2.5 Activity Diagram

2.7 Deployment Diagram

COURSE REGISTRATION SYSTEM

In order to register for a course a customer needs to wait in long queues

A lot of Employees has to be recruited in order to handle the large number of

Need for Branches:

Difficulty in handling large amount of data, as everything is done manually. So,

Timing not Flexible:

(ii) Identification of Project scope, Objectives and Infrastructure

To develop an Online Course Registration System with the objective of enabling

There must be a minimum of 128 MB RAM, 40 GB HDD

The system works in Windows XP or higher versions.

Design and Implementation Details:

Hardware limitations: There must be at least 64 MB on-board memory.

Interface to other applications: not applicable

Parallel operations: not applicable

Signal handshake protocols: not applicable

characters must be avoided.

Safety/security constraint: The application must be excited always normally.

Higher order language requirements: C++ or Java

Phase 2: Software Requirement Analysis

The main purpose of the Software Requirement Analysis is to maintain all

(i) Software Requirement Specification (SRS):

The purpose of the Software Requirement Specification document is to maintain

(ii) Modules/phases of the project:

Sign-Up if not an already registered user.

Login to the system using a Login-ID and password.

Change the password after logging in, if necessary.

See the vacancy for the courses.

View course details.