SOFTWARE ENGINEERING LAB
(NCS-652)
For
B. Tech.-VI SEMESTER
DEPARTMENT OF COMPUTER SCIENCE &
ENGINEERING
DIT SCHOOL OF ENGINEERING
KNOWLEDGE PARK III
GREATER NOIDA, UP
INDEX:
S.
No
EXPERIMENTS
Prepare a SRS document in line with the IEEE
recommended standards.
Computation of Cyclomatic Complexity of a
program.
Analysis of Data Flow Diagrams.
Date
Sign
EXPERIMENT NO. 1
Prepare a SRS document in line with
the IEEE recommended standards.
Objective:
A Software Requirements Specification document basically describes the
intended purpose and environment for software/application under development. It
completely describes the yield, cost, nature of the software/application.
A software requirements specification (SRS) is a description of a software system
to be developed. It lays out functional and non-functional requirements, and may
include a set of use cases that describe user interactions that the software must
provide.
Software requirements specification establishes the basis for an agreement
between customers and contractors or suppliers (in market-driven projects, these
roles may be played by the marketing and development divisions) on what the
software product is to do as well as what it is not expected to do. Software
requirements specification permits a rigorous assessment of requirements before
design can begin and reduces later redesign. It should also provide a realistic
basis for estimating product costs, risks, and schedules.
The software requirements specification document enlists enough and necessary
requirements that are required for the project development. To derive the
requirements we need to have clear and thorough understanding of the products
to be developed or being developed. This is achieved and refined with detailed
and continuous communications with the project team and customer till the
completion of the software.
The IEEE standard format for an SRS document is given below:
IEEE Guide to Software Requirements Specifications:
1. Introduction
1.1 Purpose
1.2 Document Conventions
1.3 Intended Audience and Reading Suggestions
1.4 Project Scope
1.5 References
2. Overall Description
2.1 Product Perspective
2.2 Product Features
2.3 User Classes and Characteristics
2.4 Operating Environment
2.5 Design and Implementation Constraints
2.6 Assumptions and Dependencies
3. System Features.
4. External Interface Requirements
4.1 User Interfaces
4.2 Hardware Interfaces
4.3 Software Interfaces
4.4 Communications Interfaces
5. Other Non-functional Requirements
5.1 Performance Requirements
5.2 Safety Requirements
5.3 Security Requirements
5.4 Software Quality Attributes
SRS of an Airline Database Project as an
Example:
1. INTRODUCTION
1.1 PURPOSE
The purpose of this document is to provide the software requirement specification
report for the airline database.
1.2 DOCUMENT CONVENTIONS
DB
Data base
DDB
Distributed Data base
ER
Entity relationship
1.3 INTENDED AUDIENCE AND READING SUGGESTIONS
This project is the college level project and is implementing under the guidance of
college professors. This project is useful to everyone who travels in flights.
1.4 PROJECT SCOPE
The purpose of the online system is to create convenient and easy-to-use online
system for passengers, trying to buy airline tickets. The system is based on a
relational database with its flight management and reservation functions. We will
have a database supporting dozens of major cities around the world as well as
hundreds of flights by various airline companies. Above all, we hope to provide a
comfortable user experience along with the best pricing available.
2. OVERALL DESCRIPTION
2.1 PRODUCT PERSPECTIVE
A distributed Airline database System stores the following information as shown
below.
THE FLIGHT DETAILS:
It includes the originating flight terminal and destination terminal, along with
stops in between, number of seats booked/available seats between two
destination etc.
CUSTOMER DESCRIPTION:
It includes customer code, name, address and phone number. This
information may be used for keeping the records of customer for any
emergency or for any other kind of information.
RESERVATION DESCRIPTION:
It includes customer code number, flight number, date of booking, date of
traveling.
2.2 PRODUCT FEATURES
The major features of airline data base system as shown in below Schema
diagram
2.3 USER CLASS AND CHARACTERISTICS
Users of the system should be able to retrieve flight information between two
given cities with the given dates/times of travel from the database. A route from
city A to city B is a sequence of connecting flights from A to B such that: a) there
are at most two connecting stops, excluding the starting city and destination city
of the trip, b) the connecting time is between one to two hours. The system will
support two types of user privileges, Customer and Employee. Customers will
have access to customer functions, and the employees will have access to both
customer and flight management functions. The customer should be able to do
the following functions:
Make a new reservation
o One-way
o Round-Trip
o Multi-city
o Flexible Date/time
o Confirmation
Cancel an existing reservation
View his itinerary
The Employee should have following management functionalities:
CUSTOMER FUNCTIONS.
o Get all customers who have seats reserved on a given flight.
o Get all flights for a given airport.
o View flight schedule.
o Get all flights whose arrival and departure times are on time/delayed.
o Calculate total sales for a given flight.
ADMINISTRATIVE
o Add/Delete a flight
o Add a new airport
o Update fare for flights.
o Add a new flight leg instance.
o Update departure/arrival times for flight leg instances.
Each flight has a limited number of available seats. There are number of flights
that go from/to different cities at different dates and time.
2.4 OPERATING ENVIRONMENT
Operating environment for the AIRLINE DATABASE is as listed below:
Distributed database
Client/server system
Operating system: windows xp.
Database: sql+ database
Platform: vb.net
2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS
i) The global schema, fragmentation schema, allocation schema.
Ii) SQL commands for above queries/applications
Iii) How the response for application 1 and 2 will be generated. Assuming these
are global queries. Explain how various fragments will be combined to do so.
Iv) Implement the database at least using a centralized database management
system.
2.6 ASSUMPTION DEPENDENCIES
Let us assume that this is a distributed airline database system and it is used in
the following application: A request for booking/cancellation of flight from any
source to any destination, giving connected flights in case no direct flight between
the specified Source-Destination pair exist.
Calculation of high fliers (most frequent fliers) and calculating appropriate
Reward points for these fliers.
Assuming both the transactions are single transactions, we have designed a
distributed database that is geographically dispersed at four cities Delhi, Mumbai,
Chennai and Kolkata as shown in fig.2 above.
3. SYSTEM FEATURES
DESCRIPTION AND PRIORITY
The airline reservation system maintains information on flights, classes of seats,
personal preferences, prices and bookings. Of course this project has high priority
because it is very difficult to travel across countries without flights.
STIMULUS/RESPONSE SEQUENCES
Search for Airline Flights for two Travel cities
Displays a detailed list of available flights and make a Reservation or
Book a ticket on a particular flight.
Cancel an existing Reservation.
FUNCTIONAL REQUIREMENTS
DISTRIBUTED DATABASE :
Distributed database implies that a single application should be able to operate
transparently on data that is spread across a variety of different databases and
connected by a communication network as shown in below figure.
Distributed database located at four different cities
CLIENT/SERVER SYSTEM
A client/server system is a distributed system in which,
(a) Some Sites Are Client Sites And Others Are Serer Sites.
(B) All Data Resides At The Server Sites.
(C) All Applications Execute At The Client Sites.
The term client/server refers primarily to an architecture, or logical division of
responsibilities, the client is the application (also known as the front-end), and the
server is the DBMS (also known as the back-end).
4. EXTERNAL INTERFACE REQUIREMENTS
4.1 USER INTERFACES
Front-end software:
Back-end software:
Vb.net version
SQL+
4.2 HARDWARE INTERFACES
Windows XP.
Browser which supports CGI, HTML & Javascript.
4.3 SOFTWARE INTERFACES
Softwares used
Description
Operating system
We have chosen Windows XP operating system for its best
support.
Database
To save the flight records, passengers records we have chosen
SQL+ database.
VB.Net
To implement the project we have chosen Vb.Net language for its
more interactive support.
4.4 COMMUNICATION INTERFACES
This project supports all types of web browsers.
We are using simple electronic forms for the reservation forms, ticket booking etc .
5. OTHER NONFUNCTIONAL REQUIREMENTS
5.1 PERFORMANCE REQUIREMENTS
The steps involved to perform the implementation of airline data base are as listed below.
A) E-R DIAGRAM
E-R Diagram constitute a technique for representing the logical structure of a
database in a pictorial manner. This analysis is then used to organize data as a
relation, normalizing relation and finally obtaining a relation database.
ENTITIES: Which specify distinct real-world items in an application.
PROPERTIES/ATTRIBUTES:
Which specify properties of an entity and
relationships.
RELATIONSHIPS: Which
connect
dependencies between them.
entities
and
represent
meaningful
diagram shows the ER diagram of airline database
B) NORMALIZATION:
The basic objective of normalization is to be reduce redundancy which means
that information is to be stored only once. Storing information several times leads
to wastage of storage space and increase in the total size of the data stored.
If a Database is not properly designed it can gives rise to modification anomalies.
Modification anomalies arise when data is added to, changed or deleted from a
database table. Similarly, in traditional databases as well as improperly designed
relational databases, data redundancy can be a problem. These can be
eliminated by normalizing a database.
Normalization is the process of breaking down a table into smaller tables. So that
each table deals with a single theme. There are three different kinds of
modifications of anomalies and formulated the first, second and third normal
forms (3NF) is considered sufficient for most practical purposes. It should be
considered only after a thorough analysis and complete understanding of its
implications.
5.2 SAFETY REQUIREMENTS
If there is extensive damage to a wide portion of the database due to catastrophic
failure, such as a disk crash, the recovery method restores a past copy of the
database that was backed up to archival storage (typically tape) and reconstructs
a more current state by reapplying or redoing the operations of committed
transactions from the backed up log, up to the time of failure.
5.3 SECURITY REQUIREMENTS
Security systems need database storage just like many other applications.
However, the special requirements of the security market mean that vendors must
choose their database partner carefully.
5.4 SOFTWARE QUALITY ATTRIBUTES
AVAILABILITY: The flight should be available on the specified date and
specified time as many customers are doing advance reservations.
CORRECTNESS: The flight should reach start from correct start terminal
and should reach correct destination.
MAINTAINABILITY: The administrators and flight in chargers should
maintain correct schedules of flights.
USABILITY: The flight schedules should satisfy maximum number of
customers needs.
EXPERIMENT NO. 2
Objective: Computation of Cyclomatic Complexity of Greatest Common
Divisor (GCD).
Cyclomatic complexity is a source code complexity measurement that is
being correlated to a number of coding errors. It is calculated by
developing a Control Flow Graph of the code that measures the number
of linearly-independent paths through a program module.
Lower the Program's Cyclomatic complexity, lower the risk to modify and
easier to understand. It can be represented using the below formula:
Cyclomatic Complexity = E - N + P
where,
E = number of edges in the flow graph.
N = number of nodes in the flow graph.
P = number of nodes that have exit points
Example:
IF A = 10 THEN
IF B > C THEN
A=B
ELSE
A=C
ENDIF
ENDIF
Print A
Print B
Print C
Flow Graph:
The Cyclomatic complexity is calculated using the above control flow
diagram that shows seven nodes (shapes) and eight edges (lines), hence
the Cyclomatic complexity is 8 - 7 + 2 = 3
Similarly, for Greatest Common Divisor Program:
#include <stdio.h>
int gcd(int i, int j){
int small, large, remainder;
if (i <= j)
small = i;
else
small = j;
if (i <= j)
large = j;
else
large = i;
while (small > 0){
remainder = large % small;
large = small;
small = remainder;
}
return large;
}
int main(void) {
int i, j;
printf("Enter two positive integers: ");
scanf("%d %d", &i, &j);
printf("GCD of %d and %d is %d\n\n", i, j,
gcd(i,j));
}
return 0;
Here, E=11, N=9 and P=2 hence, 11-9+2=4
The Cyclomatic complexity is 4.
EXPERIMENT NO. 3
Objective: Data Flow Diagrams (DFDs)
Data Flow Diagram or DFDs are a graphical representation of the "flow" of data
through an information system, modelling its process aspects. A DFD is often
used as a preliminary step to create an overview of the system, which can later
be elaborated. A DFD shows what kind of information will be input to and
output from the system, where the data will come from and go to, and where the
data will be stored. It does not show information about the timing of process or
information about whether processes will operate in sequence or in parallel
(which is shown on a flowchart).
A Data Flow Diagram (DFD) is a diagrammatic representation of the information
flows within a system, showing:
how information enters and leaves the system,
what changes the information,
where information is stored.
DFDs show the passage of data through the system by using 5 basic constructs:
Data flows,
Processes,
Data Stores,
External Entities, and
Physical Resources.
Examples of DFD:
