Chapter - 5

Detailed Design

5.1: Introduction:
Detail design starts after the system design phase is completed. The goal of this phase
is to develop the internal logic of each of the models identified during the system design.
Before deciding on the logic of the module, formal specification of the module maybe
developed. The specification should be such that they are complete, unambiguous and precise
and they do not suggest any particular implementation. Two modules units are frequently
chosen for formal specification .Functional modules and data abstraction modules.
Every system requires not only data, but also the structure of that data. A database
management system (DBMS) collects and structures related files so that many users can
retrieve, manipulate and store data. Here we use MS-SQL as the DBMS. Database is a
collection of inter related data stored with minimum redundancy to serve many users quickly
and efficiently. Database designs are designed to manage large bodies of information and also
for easy and flexible retrieval of data.

5.2 COMPONENT DESCRIPTION:

User Creation Module: This module is used to add users.

 Input: Username, Password, Confirm Password, UserType.

 Output: A new user is created.
 Processing: If the required information is incorrect, appropriate error message
will be displayed.
Registration: This module allows the user to register.
 Input: Name, Date of Birth, Address, Phone, Email, Gender, Nationality, State,
City, Pincode, Username, Password, Confirm Password.
 Output: New user will be created.
 Processing: If the required information is incorrect, appropriate error message
will be displayed.

License Category: This module contains the category of the license which the user wants.
  Input: License Type.
 Output: Details of license category will be displayed.
 Processing: If the required license category is not selected, error message will
be displayed.
Muncipal Master: This module accesses all the requests sent by the user and it will
processed by the municipal staff and will send it to the Police station for further processing.
 Input: Municipal Name, Address, Phone.
 Output: Access the requests received.
 Processing: Redirects to respective page.
Police Master: This module accesses all the requests sent by the Municipal Staff Members
and it will be processed by the Police staff by taking respective action.
 Input: Police Name, Designation, Phone.
 Output: Police can access the requests sent.
 Processing: Displays the authorized page.
Spot Verification: In this module, depending on the License or Permission type requested
by the User, it helps the Police Staff members to carry out Spot Verification or Character
Enquiry based on which the License and the Permission will be Approved or Cancelled.
 Input: Registration Id, License Number, Name, License Type, Spot Address, Phone,
Verification Date, Description, Approve License, Staff ID.
 Output: The verification can be done by police.
 Processing: Various kinds of verification can be done.
Character Enquiry: In this module, the investigation regarding the requested
license is done.
 Input: Registration Id, License Number, Name, Address, Phone, License Type,
Enquiry Date, Background Check, Description, Approve License, Staff ID.
 Output: The investigation about the requested license is done by the
police.
 Processing: If any of the mandatory field is left blank it throws an error.
Request License: This module helps the user to apply for the New License.
  Input: Name, Address, Phone, DOB, Gender, Trade Address, Category Name.
 Output: Request will be stored in the database.
 Processing: Request sent to the admin who will then either confirm/reject the
request after enquiry.
Complaint: The users can lodge complaint on various issues.
 Input: Complaint Type, Complaint Description1, Local Address, City, Pincode,
Registration Id, Name1, Address1, Phone1, Email, Complaint Date1, Status, Staff ID..
 Output: Complaint Request will be stored in the database.
 Processing: Request stored in the database will be viewed by admin and the Staff
and complaint will be dealt with.
Permission: Requesting for permission for Social, Religious or Political type.
 Input: Registration ID, Name, Address, Phone, Trade Address, Permission Type,
Description, Valid From, Valid To, Status.
 Output: Request will be stored in the database.
 Processing: Request stored in the database will be viewed by admin and the Staff
and Permission will be Approved or Deleted.
Renew License: Helps the user to apply for the New License.
 Input: Registration ID, License Number, Name, Address, Renewal Date, License
Type, Phone, Status, Renewed Date, Expiry Date.
 Output: Renewal of the submitted License number.
 Processing: Checks the input License number that has to be renewed and if it is
incorrect relevant message should be displayed.
 Chapter - 6
CODING

6.1 INTRODUCTION
The goal of coding or programming phase is to translate the design of the system
produced during the design phase into code in a given programming language, which can be
executed by a computer and that performs the computation specified by the design. The
coding phase affects both testing and maintenance profoundly. The goal during this phase is
not to simplify the job of the programmer. Rather, the goal should be simplify the job of the
tester and the maintainer.
There are many different criteria for judging a program, including readability, size of
the program, execution time and required memory. Having readability and understanding as a
clear objective of the coding activity can itself help in producing software that is more
maintainability.

6.2 PROGRAMMING STYLE

It is impossible to provide an exhaustive list of what to do and what not to do produce
simple readable code. Being able to do this will amount to providing an algorithm for writing
good code. Next we will list some general rules that usually apply.

NAMES
Selecting module and variable names often not considered important by novice
programmers. Only when one starts reading programs written by other where the variable
names are cryptic and not representative does one realize the importance of selecting proper
names. Most variables in a program reflect some entity in the problem domain, and the
modules reflect some process. Variable names should be closely related to the entity they
represent, and module name should reflect their activity. It is bad practice to choose cryptic
names just to avoid typing or totally unrelated names. It is also bad practice to use the same
name for multiple purposes.
 CONTROL CONSTRUCTS
It is desirable that as much as possible single-entry, single exit constructs be used. It is
also desirable to use the few standard control constructs rather than using a wide variety of
constructs, just because they are available in the language.

INFORMATION HIDING
Information hiding should be supported where possible. Only the access function for
the data structures should be made visible while hiding the data structure behind these
functions.

USER-DEFINED TYPES
Modern languages allow users to define types like the Enumerated type. When such
facilities are available, they should be exploited where applicable. For example, when
working with dates, the type can be defined for the day of the week.

NESTING
The different control constructs, the if-then-else, can be nested. If the nesting becomes
too deep, the programs become harder to understand. In case of deeply nested if-then-else, it
is often difficult to determine then if statement to which a particular else clause is associated.
Wherever possible, deep nesting should be avoided, even if it means a little inefficiency.

MODULE SIZE
We discussed this issue during system design. A programmer should carefully
examine any routine with very few statements (say fewer than 5) or with too many statements
(say more than 50). Large modules often will not be functionally cohesive and too small
modules might incur unnecessary overhead. There are can be no hard-and-fast rule about
module sizes the guiding principle should cohesion and coupling.
 MODULE INTERFACE
A module with a complex interface should be carefully examined. Such modules
might not be functionally cohesive and might be implementing multiple functions. As a rule
of thumb, any module whose interface has more than five parameters should be carefully
examined and broken into multiple modules with simpler interface if possible.

PROGRAM LAYOUT
How the program is organized and presented can have great effect on the readability
of it. Proper indentation, blank spaces, and parentheses should be used to enhance the
readability of programs. Automated tools are available to “pretty print” a program, but it is
good practice to have a clear layout of programs.

SIDE EFFECTS
When a module is invoked, it sometimes has side effect of modifying the program
state beyond the modifications of parameters listed in the module interface definition, for
example, modifying global variables. Such side effects should be avoided where possible,
and if a module has side effects, they should be properly documented.

ROBUSTNESS
A program is robust if it does something planned even for exceptional
conditions. A program might encounter exceptional conditions in such forms as incorrect
input, the incorrect value of some variable, and overflow. In general, a program should check
for validity inputs, where possible, and should check for possible overflow of the data
structures. If such situations do arise, the program should not just “crash” it should produce
some meaningful message and exit gratefully.
6.3 CODING
Registration:

Chapter - 7
Testing

7.1 INTRODUCTION:
Software testing is the process used to help identify the correctness,
completeness, security and quality of developed computer software. This includes the process
of executing the program or application with the intent of finding errors. Quality is not an
absolute; it is value to some person. With that in mind testing can never completely establish
the correctness of arbitrary computer software; testing furnishes a criticism or comparison
that compares the state and behaviour of the product against a specification.
The testing phase consists of evaluating the software that has been developed in order
to conform that it produces the output required in a safe and efficient manner. In this phase
inherent errors that occur, have to be handled and the user should be informed so that he/she
can follow the guidelines and instructions and get around the error and obtain the output.
 During testing, the program to be tested is executed with a set of test cases and the
output of the program for the test cases is evaluated to determine if the program is performing
as expected. Due to its approach, dynamic testing can only ascertain the presence of errors in
the program the exact nature of the errors is not usually decided by testing.
Testing forms the first step in determining the errors in a program. Clearly the success
of testing in revealing errors in programs depends critically on the test cases. Because code is
the only product that can be executed and whose actual behavior can be observed, testing is
the phase where the errors remaining from all the previous phases must be detected.
The program to be tested is executed with a set of test cases and the output of the
program for the test cases are evaluated to determine if the programming is performing as
expected. Testing forms the first step in determining errors in a program. The success of
testing in revelling errors in programs depends critically on the test cases.

7.2 OBJECTIVES OF TESTING

The objectives of testing are
 Testing is a process of executing a program with the intent of finding
errors.
 A successful test case is one that discovers an as of yet and discovered
error. System testing is a stage of implementation which is aimed at
ensuring that the system works accurately and efficiently as per the user
need, before the live operation commences as stated before, testing is vital
to the success of a system system testing makes a logical assumption that if
all parts of system are correct the goal will successfully be achieved. A
series of tests are performed before the system is ready for the user
acceptance test.

THERE ARE TWO TYPES OF SOFTWARE TESTING:

 Black Box Testing: Internal system design is not considered in this type of
testing. Tests are based on requirements and functionality.
  White box testing: This testing is based on knowledge of the internal logic of
an application’s code. Also known as glass box testing. Internal software and
code working should be known for this type of testing. Tests are based on
coverage of code statements, branches, paths and conditions.
A test case is a software testing document, which consists of event, action, input,
output, expected result and actual result. Clinically defined a test case is an input and an
expected result. This can be pragmatic as ‘for condition x your derived result is y’;
where as other test cases described in more detail the input scenario and what results
might be expected. It can occasionally be a series of steps but one with expected results
or expected outcome. A test case should also contain a place for the actual result.
White box testing is applicable at the unit, integration and system levels of the software
testing.

7.3 TESTING METHODOLOGY

The different types of testing are as follows:
7.3.1 UNIT TESTING:
Unit testing focuses efforts on the smallest unit of software design this is known as
module testing or white box testing, the modules are tested separately. The test is carried out
during the programming stage itself. In this step, each module is found to be working

satisfactorily as regards to the expected output from the module.

7.3.2 INTEGRATION TESTING:

In integration testing the different units of the system are integrated together to form
the complete system. This type of testing checks the system as a whole to ensure that it is
doing what it's supposed to do the testing of an integrated system can be carried out top-
down, bottom-up or Big-Bang. In this type of testing some parts are tested with white box
testing and some with black box testing techniques. This type of testing plays a very
important role in increasing systems productivity. We have checked the system by using
integration testing techniques.

7.3.3 SYSTEM TESTING:

 Apart from testing the system to validate the functionality of software against the
requirements. It is also necessary to test the non functional aspect of the system, some
examples of non functional tools include tests to check the performance data security
usability volume load and stress that we have used in a project to test the various module.
System testing consists of the following steps:
 Program(s) testing
 String testing
 System Testing
 System Documentation
 User Acceptance test

7.3.4 FIELD TESTING:

The special type of testing may be very important in some projects. Here the system is
tested in actual operational surroundings the interfaces with other systems and the real world
are checked. This type of testing is very rarely used so far our project is concerned we haven't
tested a project using field testing.

7.3.5 ACCEPTANCE TESTING:

After the developer has completed all rounds of testing and he is satisfied with the
system, then the user takes over and retest system from his point of view to judge whether it
is acceptable according to some previously identified criteria. This is almost always a tricky
situation in the project because of the inherent conflict between the developer and the user in

this project. It is the job of the developer of the planner to check the system that whether the
system fulfills the goals or not.

7.4 TESTING CRITERIA:

Testing for valid user name:
Test case Input Test description Output
1 User name starts with User name cannot Must Enter
number start with number Characters
2 User name is left User name cannot Must Enter
blank be left blank username
 Testing for valid password:
Test case Input Test description Output

1 Password is left Password cannot be Must Enter

blank blank password
2 Invalid password Valid password Password
entered must be entered mismatch

Testing for valid Email address:

Test case Input Test description Output
1 Email address is Email address Invalid Expression
not in Correct Should have
format Correct format
2 Email address with Email address Invalid Expression
space cannot have space
3 Email is left blank Email cannot be Must Enter Email
blank ID

Testing for data insertion:

Test case Input Test description Output

1 Mandatory fields Mandatory fields Must enter data

left empty cannot be left empty
2 Duplicate entry Duplicate entry not Appropriate error
allowed message
3 Input without above Valid input Record inserted
faults Successfully

Testing for deletion:

Test case Input Test description Output

1 Deletion attempted Entries, if not Select any field

when no entries selected ,cannot be
selected deleted
2 Valid deletion Valid deletion Record deleted
without above faults Successfully

Testing for phone number:

Test case Input Test description Output

1 Phone number Phone number Enter only

entered with Cannot have numbers
alphabets alphabets
2 Phone number Phone number with Invalid phone
entered is more than more than 10 digits number
10 digits cannot be entered

Testing for valid duration:

Test case Input Test description Output

1 Invalid duration “From” date must “Valid from”

be smaller than date must be
“To” date smaller than
“Valid To” date

Testing for change password:

 Test case Input Test description Output

1 Any field left blank All fields are Must enter

compulsory Password

2 Invalid password Valid password must Enter correct

be entered password

Other cases:
Test case Input Test description Output

1 Click on logout Application Will Application closes and

close redirects to login page
2 Click on clear Entering details Record is not submitted
to the database and Text
boxes cleared
3 Click on save Entering details Record is submitted to
 the database
4 Click on save Not entering the Appropriate error
details message is displayed
5 Click on date Selecting date Date is displayed
control
6 Click on Drop Selecting data Data is displayed
down list