SAVITRIBAI PHULE PUNE UNIVERSITY

A PRELIMINARY PROJECT REPORT ON

Enabling identity based Integrity auditing and

data sharing with sensitive information hiding for
secure cloud storage

SUBMITTED TOWARDS THE

PARTIAL FULFILLMENT OF THE REQUIREMENTS OF

BACHELOR OF ENGINEERING (Computer Engineering)

BY
student name Exam No:
student name Exam No:
student name Exam No:
student name Exam No:

Under The Guidance of

Prof.Guide name

.png

DEPARTMENT OF COMPUTER ENGINEERING

college name
college address

ii
 .png

college name
DEPARTMENT OF COMPUTER ENGINEERING
CERTIFICATE

This is to certify that the Project Entitled

Enabling Identity based Integrity for secure cloud storage

Submitted by

student name Exam No:

student name Exam No:
student name Exam No:
student name Exam No:

is a bonafide work carried out by Students under the supervision of Prof. Prof. and
it is submitted towards the partial fulfillment of the requirement of Bachelor of En-
gineering (Computer Engineering) Project.

Prof. Mr.Naved Raza Prof. HOD Name

Internal Guide H.O.D
Dept. of Computer Engg. Dept. of Computer Engg.

iii
 Abstract
Remote information integrity checking (RDIC) allows a data
storage server, say a cloud server, to sway a friend that it is
truly storing an information owners data honestly. To date,
a number of RDIC protocols are projected within the lit-
erature, but most of the constructions suffer from the diffi-
culty of a fancy key management, that is, they believe the
valuable public key infrastructure (PKI), which could hinder
the readying of RDIC in follow. during this paper, we tend
to propose a brand new construction of identity-based (ID-
based) RDIC protocol by creating use of keyhomophobic cryp-
tographic primitive to cut back the system complexity and
also the price for establishing and managing the general pub-
lic key authentication framework in PKI based mostly RDIC
schemes. We formalize ID-based RDIC and its security model
as well as security against a malicious cloud server and nil in-
formation privacy against a 3rd party friend. The projected
ID-based RDIC protocol leaks no info of the keep information
to the verified throughout the RDIC method. The new con-
struction is tried secure against the malicious server within
the generic cluster model and achieves zero information pri-
vacy against a friend. Extensive security analysis and imple-
mentation results demonstrate that the projected protocol is
incontrovertibly secure and sensible within the real-world ap-
plications.

I
 Acknowledgments

We would like to extend my sincere gratitude and thanks to my guide ...... for his
invaluable guidance and for giving us useful inputs and encouragement time and
again, which inspired us to work harder. Due to his forethought, appreciation of
the work involved and continuous imparting of useful tips, this report has been suc-
cessfully completed. We are extremely grateful to...... Head of the Department of
Computer Engineering, for his encouragement during the course of the project work.
We also extend our heartfelt gratitude to the staff of Computer Engineering Depart-
ment for their cooperation and support. We also take this opportunity to thank all
our classmates,friends and all those who have directly or indirectly provided their
overwhelming support during our project work and the development of this report.

student name
student name
student name
student name
(B.E. Computer Engg.)

II
 CONTENTS

LIST OF FIGURES IV

LIST OF TABLES iv

1 INTRODUCTION v
1.1 BACKGROUND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 PROBLEM STATEMENT . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 PURPOSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.4 SCOPE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2

2 LITERATURE SURVEY 3
2.1 PRESENT WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.2 PROPOSED WORK . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3 SOFTWARE REQUIREMENTS SPECIFICATION 7

3.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1 PROJECT SCOPE . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.2 USER CLASSES AND CHARACTERISTICS . . . . . . . . . 8
3.1.3 OPERATING ENVIRONMENT . . . . . . . . . . . . . . . . 9
3.1.4 DESIGN AND IMPLEMENTATION CONSTRAINTS . . . . 9
3.1.5 ASSUMPTIONS AND DEPENDENCIES . . . . . . . . . . . 11
3.2 EXTERNAL INTERFACE REQUIREMENTS . . . . . . . . . . . . . 11
3.2.1 USER INTERFACES . . . . . . . . . . . . . . . . . . . . . . . 11
3.2.2 HARDWARE INTERFACES . . . . . . . . . . . . . . . . . . 12
3.2.3 SOFTWARE INTERFACES . . . . . . . . . . . . . . . . . . . 12
3.2.4 COMMUNICATION INTERFACES . . . . . . . . . . . . . . 12
3.3 NON FUNCTIONAL REQUIREMENTS . . . . . . . . . . . . . . . . 12
3.3.1 PERFORMANCE REQUIREMENTS . . . . . . . . . . . . . 13
3.3.2 SAFETY REQUIREMENTS . . . . . . . . . . . . . . . . . . 13
3.3.3 SOFTWARE QUALITY ATTRIBUTES . . . . . . . . . . . . 13
3.4 OTHER REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . 14
3.4.1 DATABASE REQUIREMENTS . . . . . . . . . . . . . . . . . 14
3.4.2 LEGAL REQUIREMENTS . . . . . . . . . . . . . . . . . . . 14
3.5 ANALYSIS MODEL . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.5.1 DATA FLOW DIAGRAMS . . . . . . . . . . . . . . . . . . . 15

III
 3.5.2 MATHEMATICAL MODEL . . . . . . . . . . . . . . . . . . . 17
3.6 SYSTEM IMPLEMENTATION PLAN . . . . . . . . . . . . . . . . . 18

4 SYSTEM DESIGN 19
4.1 SYSTEM ARCHITECTURE . . . . . . . . . . . . . . . . . . . . . . 20
4.2 UML DIAGRAMS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.2.1 USE CASE DIAGRAM . . . . . . . . . . . . . . . . . . . . . 26
4.2.2 DEPLOYMENT DIAGRAM . . . . . . . . . . . . . . . . . . . 27
4.2.3 ACTIVITY DIAGRAM . . . . . . . . . . . . . . . . . . . . . 28
4.2.4 SEQUENCE DIAGRAM . . . . . . . . . . . . . . . . . . . . . 29
4.2.5 CLASS DIAGRAM . . . . . . . . . . . . . . . . . . . . . . . . 30

5 TECHNICAL SPECIFICATION 31
5.1 ADVANTAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.2 DISADVANTAGES . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
5.3 APPLICATIONS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

6 RESULTS 33
6.1 EXPECTED RESULTS . . . . . . . . . . . . . . . . . . . . . . . . . 34

7 CONCLUSION 35

REFERENCES 38

A GLOSSARY 40

B ASSIGNMENTS 42
B.1 Test Cases: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

LIST OF FIGURES

3.1 DFD Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3.2 DFD Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

4.1 System Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

4.2 System Flow Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
4.4 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.5 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.6 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

IV
4.7 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

B.1 Relation between Classes of Problems . . . . . . . . . . . . . . . . . . 46

B.2 DFD Level 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.3 DFD Level 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
B.4 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
B.5 Deployment Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
B.6 Activity Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
B.7 Sequence Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
B.8 Class Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

V
 LIST OF TABLES

3.1 System Implementation Plan Phase-I . . . . . . . . . . . . . . . . . . 18

3.2 System Implementation Plan Phase-II . . . . . . . . . . . . . . . . . 18

B.1 Project Canvas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

iv
 CHAPTER 1
INTRODUCTION
LATEX CHAPTER 1. INTRODUCTION

1.1 BACKGROUND
Cloud computing is an information technology (IT) paradigm, a model
for enabling ubiquitous access to shared pools of configurable resources (such as com-
puter networks, servers, storage, applications and services), which can be rapidly
provisioned with minimal management effort, often over the Internet. Cloud users
are provisioned and release recourses as they want in cloud computing environment.
This kind of new computation model represents a new vision of providing comput-
ing services as public utilities like water and electricity. Cloud computing brings a
number of benefits for cloud users. For example, (1) Users can reduce capital expen-
diture on hardware, software and services because they pay only for what they use;
(2) Users can enjoy low management overhead and immediate access to a wide range
of applications; and (3) Users can access their data wherever they have a network,
rather than having to stay nearby their computers. However, there is a vast variety of
barriers before cloud computing can be widely deployed. A recent survey by Oracle
referred the data source from international data corporation enterprise panel, showing
that security represents 87 percent of cloud users’ fears1. One of the major security
concerns of cloud users is the integrity of their outsourced files since they no longer
physically possess their data and thus lose the control over their data. Moreover,
the cloud server is not fully trusted and it is not mandatory for the cloud server to
report data loss incidents. Indeed, to ascertain cloud computing reliability, the cloud
security alliance (CSA) published an analysis of cloud vulnerability incidents. The
investigation [2] revealed that the incident of data Loss and Leakage accounted for 25
percent of all incidents, ranked second only to ”Insecure Interfaces and APIs”. Take
Amazon’s cloud crash disaster as an example2. In 2011, Amazon’s huge EC2 cloud
services crash permanently destroyed some data of cloud users. The data loss was
apparently small relative to the total data stored, but anyone who runs a website can
immediately understand how terrifying a prospect any data loss is. Sometimes it is
insufficient to detect data corruption when accessing the data because it might be
too late to recover the corrupted data. As a result, it is necessary for cloud users to
frequently check if their outsourced data are stored properly.

1.2 PROBLEM STATEMENT

The client should be able to efficiently perform periodical integrity verifi-
cations even without the local copy of data files.There should be secure de-duplication
and the duplication of data files should be avoided.Customer always want to encrypt
their data before uploading, for reasons ranging from personal privacy to corporate
policy, system introduce a key server into SecCloud as with and propose the Sec-
Cloud+ schema. Besides supporting integrity auditing and secure deduplication,
SecCloud+ enables the guarantee of file confidentiality.

AISSMS COE, PUNE 2017-18 1

LATEX CHAPTER 1. INTRODUCTION

1.3 PURPOSE
The aim of the project is to identify the data security on cloud by Third
party auditing

1.4 SCOPE
The new construction is proven secure against the malicious server in the
generic group model and achieves zero knowledge privacy against a verifier. Extensive
security analysis and implementation results demonstrate that the proposed protocol
is provably secure and practical in the real-world applications.

AISSMS COE, PUNE 2017-18 2

 CHAPTER 2
LITERATURE SURVEY
LATEX CHAPTER 2. LITERATURE SURVEY

2.1 PRESENT WORK

1. Reclaiming Space from Duplicate Files in a Serverless Distributed File
System
Authors : John R. Douceur

The Farsite distributed file system provides availability by replicating each file onto
multiple desktop computers. Since this replication consumes significant storage space,
it is important to reclaim used space where possible. Measurement of over 500 desk-
top file systems shows that nearly half of all consumed space is occupied by duplicate
files. We present a mechanism to reclaim space from this incidental duplication to
make it available for controlled file replication. Our mechanism includes 1) conver-
gent encryption, which enables duplicate files to coalesced into the space of a single
file, even if the files are encrypted with different users’ keys, and 2) SALAD, a Self-
Arranging, Lossy, Associative Database for aggregating file content and location in-
formation in a decentralized, scalable, fault-tolerant manner. Large-scale simulation
experiments show that the duplicate-file coalescing system is scalable, highly effec-
tive, and fault-tolerant.

2. DupLESS: Server-Aided Encryption for Deduplicated Storage

Authors : MihirBellare

Cloud storage service providers such as Dropbox, Mozy, and others perform dedupli-
cation to save space by only storing one copy of each file uploaded. Should clients
conventionally encrypt their files, however, savings are lost. Message-locked encryp-
tion (the most prominent manifestation of which is convergent encryption) resolves
this tension. However it is inherently subject to brute-force attacks that can re-
cover files falling into a known set. We propose an architecture that provides secure
deduplicated storage resisting brute-force attacks, and realize it in a system called
DupLESS. In DupLESS, clients encrypt under message-based keys obtained from a
key-server via an oblivious PRF protocol. It enables clients to store encrypted data
with an existing service, have the service perform deduplication on their behalf, and
yet achieves strong confidentiality guarantees. We show that encryption for dedupli-
cated storage can achieve performance and space savings close to that of using the
storage service with plaintext data

3. Message-Locked Encryption and Secure Deduplication.

Authors : MihirBellare

We formalize a new cryptographic primitive, Message-Locked Encryption (MLE),

where the key under which encryption and decryption are performed is itself de-
rived from the message. MLE provides a way to achieve secure deduplication (space-
efficient secure outsourced storage), a goal currently targeted by numerous cloud-

AISSMS COE, PUNE 2017-18 4

LATEX CHAPTER 2. LITERATURE SURVEY

storage providers. We provide definitions both for privacy and for a form of integrity
that we call tag consistency. Based on this foundation, we make both practical and
theoretical contributions. On the practical side, we provide ROM security analy-
ses of a natural family of MLE schemes that includes deployed schemes. On the
theoretical side the challenge is standard model solutions, and we make connections
with deterministic encryption, hash functions secure on correlated inputs and the
sample-then-extract paradigm to deliver schemes under different assumptions and for
different classes of message sources. Our work shows that MLE is a primitive of both
practical and theoretical interest.

4. CD Store:Toward Reliable,Secure,and Cost-Efficient Cloud Storage via

Convergent Dispersal
Authors :Mingqiang Li

We present CD Store,which disperses users’backup data across multiple clouds and

provides a unified multicloud storage solution with reliability,security,and cost- effi-
ciency guarantees. CD Store builds on an augmented secret sharing scheme called
convergent dispersal,which supports deduplication by using deterministic content-
derived hashes as inputs to secret sharing. We present the design of CD Store, and
in particular, describe how it combines convergent dispersal with two-stage dedupli-
cationton achieve both bandwidth than the storage saving sand be robust against
side-channel attacks. We evaluate the performance of our CD Store prototype using
real-world workloads on LAN and commercial cloud test beds. Our cost analysis also
demonstrates that CD Store achieves a monetary cost saving of 70

AISSMS COE, PUNE 2017-18 5

LATEX CHAPTER 2. LITERATURE SURVEY

5. Is Naive Bayes a Good Classifier for Document Classification?

Authors : S.L. Ting, W.H. Ip, Albert H.C. Tsang

In this paper the author has highlighted the performance of implementing Naive
Bayes classifier against several other classifiers such as decision tree, neural network,
and support vector machines in terms of accuracy and computational efficiency. In
their study, Naive Bayes classifier has been discussed as the classifier, which satisfies
the literature result. Through their implementation of different feature selection in
WEKA tool, they have demonstrated that preprocessing and feature selection are im-
portant two steps for improving the mining quality. To test whether Naive Bayes is
the best classifier among other classifiers, they have applied three different classifiers
for testing. In this experiment, a dataset of 4000 documents are used for evaluation.
1200 documents are extracted randomly to build the training dataset for the classi-
fier. The other 2800 documents are used as the testing dataset to test the classifier.
They have summarized that Naive Bayes classifier gave 96.9 percent of accuracy while
classifying.

2.2 PROPOSED WORK

The major goals of our new system are as follows:
1. Timebased system
2. Block level Deduplication
3. Reliabilty
4. Distributed deduplication
5. Data Backup

AISSMS COE, PUNE 2017-18 6

 CHAPTER 3
SOFTWARE REQUIREMENTS
SPECIFICATION
LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.1 INTRODUCTION
Cloud computing [1], which has received considerable attention from re-
search communities in academia as well as industry, is a distributed computation
model over a large pool of shared-virtualized computing resources, such as storage,
processing power, applications and services. Cloud users are provisioned and release
recourses as they want in cloud computing environment. This kind of new computa-
tion model represents a new vision of providing computing services as public utilities
like water and electricity. Cloud computing brings a number of benefits for cloud
users. For example, (1) Users can reduce capital expenditure on hardware, software
and services because they pay only for what they use; (2) Users can enjoy low man-
agement overhead and immediate access to a wide range of applications; and (3)
Users can access their data wherever they have a network, rather than having to stay
nearby their computers.
The size of the cloud data is huge, downloading the entire file to check the integrity
might be prohibitive in terms of bandwidth cost, and hence, very impractical. More-
over, traditional cryptographic primitives for data integrity checking such as hash
functions, authorisation code (MAC) cannot apply here directly due to being short of
a copy of the original file in verification. In conclusion, remote data integrity checking
for secure cloud storage is a highly desirable as well as a challenging research topic.
Objectives:

(a) File level deduplication

(b) Block level Deduplication

(c) Reliabilty

(d) Distributed deduplication

3.1.1 PROJECT SCOPE

We show that the proposed scheme achieves the properties of complete-
ness, soundness and perfect data privacy preserving. Completeness guarantees the
correctness of the protocol while soundness shows that the protocol is secure against
an untrusted server. Perfect data privacy states that the protocol leaks no information
of the stored files to the verifier.

3.1.2 USER CLASSES AND CHARACTERISTICS

This project is meant to offer a brief solution that is faster ,easier,concise
and more convenient than manually analyzing the criminal data to predict type of
crimes and region where crime is likely to happen.Consequently the application will
be able to predict more accurately auditing to usage of system increases that is it

AISSMS COE, PUNE 2017-18 8

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

gathers or analyses more amount of data related to similar type of data crimes.

It is also important that the application be as user friendly as possible, otherwise it

will not be a viable alternative for crime analysis manually by a crime analyst.Most
importantly, the application must be reliable. Regardless of the situation, the ap-
plication must accurately distribute costs. There is zero tolerance for error when
dealing with it as error in such an application may result in inefficient usage of law
enforcement resources deployed as per the results given by system for prevention of
similar data security.so system defines weather data on cloud is secured or not.

3.1.3 OPERATING ENVIRONMENT

The main component of our project is the application that we are design-
ing to ease the process of crime analysis and prediction.It is a desktop based system
along with requirement of internet connection.The application will require to acquire
significant amount of data from the internet so it requires a decent amount of storage
space also it can be used over a network of computers so a standard configuration of
the computers over network required.It will not require any cloud support since the
whole system will work on an individuals desktop based operating system given that
the basic storage requirements is met and we have a good internet connection.The
Application Programming Interface (API) required for this software will be built
using Java so we require an editor with Java support that is will be needing Java
Development Kit(JDK).Also the algorithms that are going to be implemented in the
system will be based on python Implementation.Beyond that, the application is a
self-contained unit and will not rely on any other Desktop O.S related software com-
ponents except for storage space.This software application will be interacting with
user at start to determine the source from which user that is crime analyst wishes
to gather data for prediction of crime type and region and discover a pattern also at
the end for displaying of results as reports generated.While the rest of the time the
application will be running itself and there will be no interaction between software
and user.The result that is generated in the form of report will be stored either in the
database or given as a text file on end user system.Apart form this since the data is
stored in SQL due to its unstructured nature support for SQL DB and SQL server will
be required.The software application will operate on a network of computers having a
internet connection and windows 7/8 or any other new versions as operating system
with 4GB of RAM and minimum 1TB of allocated storage space per computer in
network of computers.

3.1.4 DESIGN AND IMPLEMENTATION CONSTRAINTS

The primary design constraint is the Desktop platform. Since the applica-
tion is designated for Desktop Systems, effective GUI and well user friendliness will be
the major design considerations. Creating a user interface which is both effective and
easily navigable is important. Also as we are utilizing the database for our each of the

AISSMS COE, PUNE 2017-18 9

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

four major steps based on different algorithms so storage space need to be considered
for smooth functioning of system.Other constraints such as memory and processing
power are also worth considering.The analysis and auditing system is meant to be
quick and responsive even when dealing with large amount of data so each feature of
the software must be designed and implemented considering efficiency.As our system
involves algorithms the system must consider the requirements of all techniques for
the format of input and output generated and their individual working efficiency and
its contribution to overall software applications efficiency.The software will give the
desired results only if the specified software requirements are satisfied.

At present only Text File format containing data in the form of database records
of unstructured data or the algorithm’s output format is considered.The system will
accept data as input from the database containing unstructured data as records gen-
erated by crawling through the web content by a web based crawler and we need
active and smooth internet connectivity for effective working of web crawler.
Application software designed must implement the algorithms effectively on the col-
lected data and predict the expected result successfully also the interface of software
must be easy and simple to be understood by crime analyst and no extra efforts
needed by them to understand the usage of software.

AISSMS COE, PUNE 2017-18 10

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.1.5 ASSUMPTIONS AND DEPENDENCIES

This project will work on the minimum system specifications as follow:

• Windows 7 or 8 or any other new versions with JDK support.

• 1TB storage space as HDD.

• Minimum 4GB ram and i3 processor.

• Internet connection and smooth access to a network of computers of same phys-

ical system configuration.

• Data stored and accessed from MongoDB an unstructured database that is not
SQL.

Time Dependency:

Usability improvements and convenience enhancements that may be added after the
application has been developed. Thus, the implementation of these features is entirely
dependent upon the time spent designing and implementing the core features. The
final decision on whether or not to implement these features will be made during the
later stages of the design phase.

3.2 EXTERNAL INTERFACE REQUIREMENTS

3.2.1 USER INTERFACES
The user interface includes a login window as soon as the application
starts with a text box for user-name and a password box for the password.Once the
application starts we have normal window consisting of basic menus in title bar,
apart from this we have a drop down menu to select the source from where data
is to be collected via the web crawler.Also a progress bar depicting the progress of
our application as what steps of our algorithm is been completed or being currently
executed. The TPA will audit the file details wid current file key and previous upload
key.

AISSMS COE, PUNE 2017-18 11

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.2.2 HARDWARE INTERFACES

The system has following hardware requirements or interfaces:

• System : Pentium IV 2.4 GHz.

• Hard Disk : 40 GB.

• Floppy Drive : 1.44 Mb.

• Monitor : 15 VGA Colour.

• Mouse : Logitech.

• Ram : 512 Mb.

3.2.3 SOFTWARE INTERFACES

• Operating system : Windows XP/7.

• Coding Language : JAVA/J2EE

• IDE : Netbeans 7.4

• Database : MYSQL

3.2.4 COMMUNICATION INTERFACES

A record in the unstructured database stored as a file is used to give input
to the data auditing system also the communication between various computers on
network for achieving concurrent execution is possible via the internet connection
working as a communication interface.

3.3 NON FUNCTIONAL REQUIREMENTS

These requirements don’t affect the system features but play an important
role in deciding other factors that are important for a software application to be
reliable.

AISSMS COE, PUNE 2017-18 12

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.3.1 PERFORMANCE REQUIREMENTS

The system responds to the auditing system and client should be able
to efficiently perform periodical integrity verification’s even without the local copy
of data files.There should be secure de-duplication and the duplication of data files
should be avoided.Customer always want to encrypt their data before uploading, for
reasons ranging from personal privacy to corporate policy, system introduce a key
server into SecCloud as with and propose the SecCloud+ schema. Besides supporting
integrity auditing and secure deduplication, SecCloud+ enables the guarantee of file
confidentiality

3.3.2 SAFETY REQUIREMENTS

The application doesn’t affect any other features on machine and since
no hardware other than system is used there are no specific safety requirements for
handling system.during data collection we have to just take care that system is capable
to scale up the storage space so that data is collected without any data loss. .

3.3.3 SOFTWARE QUALITY ATTRIBUTES

The application software gives justice to important quality attributes such as:

• Flexibility:
Input related to various domains accepted by the system.

• Reliability:
System generates crime report data which includes the expected output as well
as the criminal profiling.

• Usability:
Provides simple user interface easily accessible by the concerned user.

• Scalability:
System can be used for variable data as well as is scalable on multiple systems
over same network.

• Security:
Secure as the system asks for user’s credentials to provide access to system.

AISSMS COE, PUNE 2017-18 13

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.4 OTHER REQUIREMENTS

These are optional requirements which are not of that importance but if
included gives an additive advantage to the application software usage.

3.4.1 DATABASE REQUIREMENTS

Since our application software is going to work with huge amount of un-
structured data it will need an unstructured database that is MySQL one of the
MySQL Database to store such data.Also the output of the system generated in re-
ports can be stored as text documents in such database.So the database must have
a dynamic and scalable schema to avoid any constraint during the working of our
application system.

3.4.2 LEGAL REQUIREMENTS

The system that we are designing is a system to be used by law enforcers
so we need to make sure that our system doesn’t violate any laws and also it is not
accessible to hackers or any other unauthorized person.We need to also take care that
the system is well secured, not compromised and the data is not in any form dis-
tributed over the web, neither the application is available to other people.The other
aspect of such requirement is that we need to make sure system is not exploited by
anybody or in any form discredited as it will be our responsibility.

AISSMS COE, PUNE 2017-18 14

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.5 ANALYSIS MODEL

3.5.1 DATA FLOW DIAGRAMS

Figure 3.1: DFD Level 1

AISSMS COE, PUNE 2017-18 15

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

Figure 3.2: DFD Level 2

AISSMS COE, PUNE 2017-18 16

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.5.2 MATHEMATICAL MODEL

Let the proposed system be defined by set theory as:

Let S be the system object It consist of following

S={U,F,TPA,CSP}

U= no of users

U={u1,u2,u3,. . . ..un}

F= no of files

F={f1,f2,f3,. . . ..fn}

TPA= Third Party Auditor

TPA={C,PF,V,POW}

C=challenge

PF =proof by CSP

V= verification by TPA

POW= proof of ownership

CSP= Cloud Service provider

CSP={PF,F}

PF=proof

F=files

AISSMS COE, PUNE 2017-18 17

LATEX CHAPTER 3. SOFTWARE REQUIREMENTS SPECIFICATION

3.6 SYSTEM IMPLEMENTATION PLAN

Table 3.1: System Implementation Plan Phase-I

SR. NO. TASK NAME DURATION COMPLETION
1. Project Topic Selection 15 days ✓
2. Literature Survey 10 days ✓
3. Study Of Existing System 5 days ✓
4. Synopsis & Abstract Submission 15 days ✓
5. SRS 15 days ✓
6. Design Of System Architecture 5 days ✓
7. Design Of UML Diagrams 5 days ✓
8. Planning Of System Modules & Inter- 8 days ✓
face

Table 3.2: System Implementation Plan Phase-II

SR. NO. TASK NAME DURATION COMPLETION
9. Implementation Of Data Collection 10 Days
and Storage
10. Implementation Of Classifier 10 Days
11. Implementation Of Apriori Algorithm 10 Days
12. Implementation Of Decision Trees 10 Days
13. Output Display 8 Days
5 Days Per
14. Testing Of Above Modules After Com-
Module
pletion of Each Module
15. Project Review 5 Days

AISSMS COE, PUNE 2017-18 18

 CHAPTER 4
SYSTEM DESIGN
LATEX CHAPTER 4. SYSTEM DESIGN

4.1 SYSTEM ARCHITECTURE

Overall system design consists of following modules:

(a) User

(b) Cloud Sever

(c) Third Party Auditor

We consider three security properties namely completeness, security against a ma-

licious server (soundness), and privacy against the TPA (perfect data privacy) in
identity-based remote data integrity checking protocols. Following the security no-
tions due to Shacham and Waters [7], an identity-based RDIC scheme is called secure
against a server if there exists no polynomial-time algorithm that can cheat the TPA
with non-negligible probability and there exists a polynomial-time extractor that can
recover the file by running the challengesresponse protocols multiple times. Com-
pleteness states that when interacting with a valid cloud server, the algorithm of
ProofCheck will accept the proof. Soundness says that a cheating prover who can
convince the TPA it is storing the data file is actually storing that file. We now
formalize the security model of soundness for identity-based remote data integrity
checking below, where an adversary who plays the role of the untrusted server and a
challenger who represents a data owner are involved.

AISSMS COE, PUNE 2017-18 20

LATEX CHAPTER 4. SYSTEM DESIGN

Figure 4.1: System Architecture

The overall flow for the system is shown in Figure 4.2 that is the flow graph for
our system.

AISSMS COE, PUNE 2017-18 21

LATEX CHAPTER 4. SYSTEM DESIGN

Figure 4.2: System Flow Graph

4.2 UML DIAGRAMS

Definition
The Unified Modelling Language (UML) is a general purpose,developmental,
modelling language in the field of software engineering, that is intended to provide a
standard way to visualize the design of a system. UML was originally motivated by
the desire to standardize the disparate notational systems and approaches to software
design.

Design
The Unified Modelling Language (UML) offers a way to visualize a system’s archi-
tectural blueprints in a diagram including elements such as:

• Any activities.

• Individual components of the system: And how they can interact with other
software components.

AISSMS COE, PUNE 2017-18 22

LATEX CHAPTER 4. SYSTEM DESIGN

• How the system will run.

• How entities interact with others (components and interfaces)

• External user interface

Although originally intended solely for object oriented design documen-

tation, the Unified Modelling Language (UML) has been extended to cover a larger
set of design documentation.

UML System Model

• Static (or structural) view:
Emphasizes the static structure of the system using objects, attributes, op-
erations and relationships. The structural view includes class diagrams and
composite structure diagrams.

• Dynamic (or behavioural) view:

Emphasizes the dynamic behaviour of the system by showing collaborations
among objects and changes to the internal states of objects. This view includes
sequence diagrams, activity diagrams and state machine diagrams.

UML Models
(a) Use case diagram:
To model a system the most important aspect is to capture the dynamic be-
haviour. To clarify a bit in details, dynamic behaviour means the behaviour
of the system when it is running /operating. So only static behaviour is not
sufficient to model a system rather dynamic behaviour is more important than
static behaviour.These internal and external agents are known as actors. So
use case diagrams are consists of actors, use cases and their relationships. The
diagram is used to model the system/subsystem of an application. A single use
case diagram captures a particular functionality of a system. So to model the
entire system numbers of use case diagrams are used.

(b) Deployment Diagram:

Deployment diagrams are used to visualize the topology of the physical compo-
nents of a system where the software components are deployed. So deployment
diagrams are used to describe the static deployment view of a system. Deploy-
ment diagrams consist of nodes and their relationships. The name Deployment
itself describes the purpose of the diagram. Deployment diagrams are used for
describing the hardware components where software components are deployed.
Component diagrams and deployment diagrams are closely related. UML is

AISSMS COE, PUNE 2017-18 23

LATEX CHAPTER 4. SYSTEM DESIGN

mainly designed to focus on software artefacts of a system. But these two dia-
grams are special diagrams used to focus on software components and hardware
components.So most of the UML diagrams are used to handle logical compo-
nents but deployment diagrams are made to focus on hardware topology of a
system. Deployment diagrams are used by the system engineers.

(c) Activity Diagram:

Activity diagram is basically a flow chart to represent the flow form one activity
toanother activity. The activity can be described as an operation of the sys-
tem.So the control flow is drawn from one operation to another. This flow can
be sequential, branched or concurrent. Activity diagrams deals with all type
of flow control by using different elements like fork, join etc. It captures the
dynamic behaviour of the system. Other four diagrams are used to show the
message flow from one object to another but activity diagram is used to show
message flow from one activity to another. It does not show any message flow
from one activity to another. Activity diagram is some time considered as the
flow chart. Although the diagrams looks like a flow chart but it is not. It shows
different flow like parallel, branched, concurrent and single.

AISSMS COE, PUNE 2017-18 24

LATEX CHAPTER 4. SYSTEM DESIGN

(d) Sequence Diagram:

A Sequence diagram is an interaction diagram that shows how processes operate
with one another and in what order. It is a construct of a Message Sequence
Chart. A sequence diagram shows object interactions arranged in time sequence.
It depicts the objects and classes involved in the scenario and the sequence of
messages exchanged between the objects needed to carry out the functional-
ity of the scenario. Sequence diagrams are typically associated with use case
realizations in the Logical View of the system under development. Sequence
diagrams are sometimes called event diagrams or event scenarios. A sequence
diagram shows, as parallel vertical lines (lifelines), different processes or objects
that live simultaneously, and, as horizontal arrows, the messages exchanged be-
tween them, in the order in which they occur. This allows the specification of
simple runtime scenarios in a graphical manner.

(e) Class Diagram:

In software engineering, a class diagram in the Unified Modelling Language
(UML) is a type of static structure diagram that describes the structure of a
system by showing the system’s classes, their attributes, operations (or meth-
ods), and the relationships among objects.The class diagram is the main build-
ing block of object oriented modelling. It is used both for general conceptual
modelling of the systematics of the application, and for detailed modelling trans-
lating the models into programming code. Class diagrams can also be used for
data modelling.In the diagram, classes are represented with boxes which contain
three parts as follows the top part contains the name of the class, the middle
part contains the attributes of the class and the bottom part contains the meth-
ods the class can execute.

AISSMS COE, PUNE 2017-18 25

LATEX CHAPTER 4. SYSTEM DESIGN

4.2.1 USE CASE DIAGRAM

Figure 4.3: Use Case Diagram

AISSMS COE, PUNE 2017-18 26

LATEX CHAPTER 4. SYSTEM DESIGN

4.2.2 DEPLOYMENT DIAGRAM

Figure 4.4: Deployment Diagram

AISSMS COE, PUNE 2017-18 27

LATEX CHAPTER 4. SYSTEM DESIGN

4.2.3 ACTIVITY DIAGRAM

Figure 4.5: Activity Diagram

AISSMS COE, PUNE 2017-18 28

LATEX CHAPTER 4. SYSTEM DESIGN

4.2.4 SEQUENCE DIAGRAM

Figure 4.6: Sequence Diagram

AISSMS COE, PUNE 2017-18 29

LATEX CHAPTER 4. SYSTEM DESIGN

4.2.5 CLASS DIAGRAM

Figure 4.7: Class Diagram

AISSMS COE, PUNE 2017-18 30

 CHAPTER 5
TECHNICAL SPECIFICATION
LATEX CHAPTER 5. TECHNICAL SPECIFICATION

5.1 ADVANTAGES
• By using block level deduplication reduce the storage space

• Reliability issue is overcome

• Distributed Deduplication System is performed.

5.2 DISADVANTAGES
• To solve reliability problem by distributed deduplication system the storage
space increase lightly.

5.3 APPLICATIONS
• Data deduplication is a technique for eliminating duplicate copies of data, and
has been widely used in cloud storage to reduce storage space and upload band-
width.

AISSMS COE, PUNE 2017-18 32

CHAPTER 6
RESULTS
LATEX CHAPTER 6. RESULTS

6.1 EXPECTED RESULTS

We determine that our proposed SecCloud framework has accomplished
both integrity auditing and file deduplication. Be that as it may, it can’t keep the
cloud servers from knowing the substance of files having been put away. In other
words, the functionalities of integrity auditing and secure deduplication are just forced
on plain files. In this area, we propose SecCloud+, which takes into account integrity
auditing and deduplication on scrambled files. Framework Model Compared with
SecCloud, our proposed SecCloud+ involves an extra trusted element, to be specific
key server, which is in charge of assigning customers with mystery key (according to
the file content) for encrypting files. This construction modeling is in line with the late
work. However, our work is distinguished with the past work by allowing for integrity
auditing on encoded data. SecCloud+ takes after the same three protocols (i.e., the
file uploading protocol, the integrity auditing protocol and the proof of proprietorship
protocol) as with SecCloud. The main distinction is the file uploading protocol in
SecCloud+ involves an extra stage for correspondence between cloud customer and
key server. That is, the customer needs to speak with the key server to get the merged
key for encrypting the uploading file before the phase in SeeCloud.

AISSMS COE, PUNE 2017-18 34

CHAPTER 7
CONCLUSION
LATEX CHAPTER 7. CONCLUSION

In this system, we investigated a new primitive called identity-based re-

mote data integrity checking for secure cloud storage. We formalized the security
model of two important properties of this primitive, namely, soundness and perfect
data privacy. We provided a new construction of of this primitive and showed that
it achieves soundness and perfect data privacy. Both the numerical analysis and the
implementation demonstrated that the proposed protocol is efficient and practical.

AISSMS COE, PUNE 2017-18 36

REFERENCES
LATEX REFERENCES

[1] P. Mell, T. Grance, Draft NIST working defini-

tion of cloud computing,Reference on June. 3rd, 2009.
http://csrc.nist.gov/groups/SNC/cloudcomputing/index.html.

[2] Cloud Security Alliance. Top threats to cloud computing.

http://www.cloudsecurityalliance.org, 2010.

[3] M. Blum, W. Evans, P.Gemmell, S. Kannan, M. Naor, Checking the correctness

of memories. Proc. of the 32nd Anual Symposium on Foundations fo Vomputers,
SFCS 1991, pp. 90–99, 1991.

[4] S.L. Ting, W.H. Ip, Albert H.C. Tsang, “Is Naive Bayes a Good Classifier for
Document Classification?”, International Journal of Software Engineering and
Its Applications Vol. 5, No. 3, July, 2013.

[5] G. Ateniese, R. C. Burns, R. Curtmola, J. Herring, L. Kissner, Z. N.J. Peterson,

D. X. Song, Provable data possession at untrusted stores. ACM Conference on
Computer and Communications Security, 598-609,2007.

[6] G. Ateniese, R. C. Burns, R. Curtmola, J. Herring, O. Khan, L. Kissner, Z. N.

J. Peterson, and D. Song, Remote data checking using provable data possession.
ACM Trans. Inf. Syst. Secur., 14, 1–34, 2011.

[7] A.Juels, and B. S. K. Jr. Pors, proofs of retrievability for large files.Proc.of CCS
2007, 584-597, 2007.

[8] H. Shacham, and B. Waters, Compact proofs of retrievability. Proc. of

Cryptology-ASIACRYPT 2008, LNCS 5350, pp. 90-107, 2008.

[9] G. Ateniese, S. Kamara, J. Katz, Proofs of storage from homomorphicidentifica-

tion protocols. Proc. of ASIACRYPT 2009, 319-333, 2009.

[10] A. F. Barsoum, M. A. Hasan, Provable multicopy dynamic data possession in

cloud computing systems, IEEE Trans. on Information Forensics and Security,
10(3): 485–497, 2015.

[11] J. Liu, K. Huang, H. Rong, H. M. Wang, Privacy-preserving publicauditing for

regenerating-code-based cloud storage, IEEE Trans. on Information Forensics
and Security, 10(7): 1513–1528, 2015.

[12] H. Shacham and B. Waters, “Compact proofs of retrievability,” in Proceedings

of the 14th International Conference on the Theory and Application of Cryptol-
ogy and Information Security: Advances in Cryp- tology, ser. ASIACRYPT ’08.
Springer Berlin Heidelberg, 2008, pp. 90–107.

AISSMS COE, PUNE 2017-18 38

LATEX REFERENCES

[13] Q. Wang, C. Wang, J. Li, K. Ren, and W. Lou, “Enabling public verifiability
and data dynamics for storage security in cloud computing,” in Computer Secu-
rity – ESORICS 2009, M. Backes and P. Ning, Eds., vol. 5789. Springer Berlin
Heidelberg, 2009, pp. 355–370.

[14] ] J. Li, X. Tan, X. Chen, and D. Wong, “An efficient proof of retrievability
with public auditing in cloud computing,” in 5th International Con- ference on
Intelligent Networking and Collaborative Systems (INCoS), 2013, pp. 93–98.

[15] J. Li, X. Chen, M. Li, J. Li, P. Lee, and W. Lou, “Secure dedupli- cation with ef-
ficient and reliable convergent key management,” IEEE Transactions on Parallel
and Distributed Systems, vol. 25, no. 6, pp. 1615–1625, June 2014.

[16] R. Di Pietro and A. Sorniotti, “Boosting efficiency and security in proof of own-
ership for deduplication,” in Proceedings of the 7th ACM Symposium on Infor-
mation, Computer and Communications Security, ser. ASIACCS ’12. New York,
NY, USA: ACM, 2012, pp. 81–82.

AISSMS COE, PUNE 2017-18 39

APPENDIX A
GLOSSARY
LATEX APPENDIX A. GLOSSARY

RDIC Remote information integrity checking

PKI public key infrastructure
TPA Third Party Auditing
API Application Programming Interface
JDK Java Development Kit
GUI Graphical User Interface
UML Unified Modelling Language
DB DataBase

AISSMS COE, PUNE 2017-18 41

APPENDIX B
ASSIGNMENTS
LATEX APPENDIX B. ASSIGNMENTS

Lab Assignment 01
Aim
Refer Chapter 7 of first reference to develop the problem under consideration and
justify feasibility using concepts of knowledge canvas and IDEA Matrix.

Project
data Analysis and Prediction as an Application of Data Mining.

Table B.1: Project Canvas

Purpose Goals Users
To increase safety& security To audit data on cloud & any organisation
type
To verify data To digitize data auditing data Analysts

Actions Deliverables Risks

Collect audit data SRS & Project Design DB corruption leads to sys-
tem error
Analyze collected data Project Report & Project DB may get compromised

Milestones Constraints Scope

Synopsis, Abstract, Report Input to be stored in DB Concurrent Processing
Coding and Final Software Software must meet mini- Limited to burglary & pick-
mum system requirement pocketing

AISSMS COE, PUNE 2017-18 43

LATEX APPENDIX B. ASSIGNMENTS

Lab Assignment 02
Aim
Project problem statement feasibility assessment using NP-Hard, NP-Complete or
satisfy ability issues using modern algebra and/or relevant mathematical models.

Feasibility Theory
The feasibility of the project can be defined as the measure of our project whether it
is viable or not.It includes various different types of feasibility as follows:

• Performance:
In this we check whether the proposed system is capable of performing all the
functional requirements as mentioned in system features in SRS.If our system
is displaying the functional requirements appropriately then it’s performance is
feasible.Here we also check the accuracy and efficiency of the system based on
their algorithms.

• Technical:
In this we check whether the technical specification provided that is hard-
ware and software requirements are minimum requirements for our application
software to run successfully without any error regarding the system configura-
tion.Also the storage requirements is quite enough and concurrency takes place
effectively.

• Economical:
In this we check the cost per line of code also the cost for storage of data
and cost related to the run time of the system.Apart from this since no extra
hardware is needed apart from minimum system configuration for the computers
on network.

Feasibility on basis of Class of Problem

Complexity classes are one way to talk about how difficult or easy a prob-
lem is. Complexity theory gets very technical but the basics are actually extraordi-
narily intuitive, and it’s possible to understand the P versus NP issue with very little
math background.

If there is a fast solution to the search version of a problem then the problem is said
to be Polynomial time, or P for short. If there is a fast solution to the verification
version of a problem then the problem is said to be Non deterministic Polynomial
time, or NP for short. The question of ”P=NP” is then the question of whether these

AISSMS COE, PUNE 2017-18 44

LATEX APPENDIX B. ASSIGNMENTS

sets are identical.

Some problems can be translated into one another in such a way that a fast solution
to one problem would automatically give us a fast solution to the other. There
are some problems that every single problem in NP can be translated into, and a
fast solution to such a problem would automatically give us a fast solution to every
problem in NP. This group of problems are known as NP Hard.Some problems in NP
Hard are actually not themselves in NP the group of problems that are in both NP
and NP Hard is called NP Complete

Classes of problems
• NP
A lot of programs that don’t (necessarily) run in polynomial time on a regular
computer, but do run in polynomial time on a non deterministic Turing ma-
chine. These programs solve problems in NP, which stands for non deterministic
polynomial time.An equivalent way to define NP is by pointing to the problems
that can be verified in polynomial time.

• NP Hard
If a problem is NP hard, this means I can reduce any problem in NP to that
problem. This means if I can solve that problem, I can easily solve any problem
in NP. If we could solve an NP hard problem in polynomial time, this would
prove P = NP.

• NP Complete
We propose Dekey, a new construction in which users do not need to man-
age any keys on their own but instead securely distribute the convergent key
shares across multiple servers. Dekey using the Ramp secret sharing scheme
and demonstrate that Dekey incurs limited overhead in realistic environments
we propose a new construction called Dekey, which provides efficiency and relia-
bility guarantees for convergent key management on both user and cloud storage
sides. A new construction Dekey is proposed to provide efficient and reliable
convergent key management through convergent key Deduplication and secret
sharing.

Since our system satisfies both problems of data security as well as we

are replacing original data. we are providing time based structure to display data for
specific time on cloud.
Since we have a fast solution to search problem in our project it is said to be P
type problem capable to solve a part in polynomial time also the verification version
doesn’t has a fast solution so it is not a NP complete problem.

AISSMS COE, PUNE 2017-18 45

LATEX APPENDIX B. ASSIGNMENTS

Relation Between Classes of Problems

Figure B.1: Relation between Classes of Problems

Mathematical Model
Let S be the Whole system which consists,
S= {I, P, O}
Where,
I-Input,
P- procedure,
O- Output.
I-{F,U}
F-Filesset of {F1,F2,. . . .,FN}
U- No of Users {U1,U2,. . . . . . ,UN}

Procedure(P):
P={POW, n ,[POW]-B, [POW]-F, i,j ,m , k}.

Where,
POW - proof of ownership.

n - No of servers.

[POW]-B-proof of ownership in blocks.

[POW]-F – proof of ownership in files

0 - tag.

AISSMS COE, PUNE 2017-18 46

LATEX APPENDIX B. ASSIGNMENTS

i- Fragmentation.

j- No of server.

m-message

k- Key.

AISSMS COE, PUNE 2017-18 47

LATEX APPENDIX B. ASSIGNMENTS

Lab Assignment 03
Aim
Use of divide and conquer strategies to exploit distributed/parallel/concurrent pro-
cessing of the above to identify objects, morphisms, overloading in functions (if any),
and functional relations and any other dependencies (as per requirements).

Concept
A divide and conquer algorithm works by recursively breaking down a problem into
two or more sub-problems of the same (or related) type (divide), until these become
simple enough to be solved directly (conquer). So have divided our problem based
on algorithm used and those are:

• Data auditing.

• Deduplication

• time based display limit.

Divide and conquer (D&C) is an algorithm design paradigm based on

multi-branched recursion. So we have to recursively divide our problem into sub-
problems of the same (or related) type (divide), until these sub-problem become
simple enough to be solved directly (conquer). The solutions to the sub-problems are
then combined to give a solution to the original problem.

In our project the TPA challenges the cloud by choosing some indexes of
the blocks and random values. In the proof generation, the cloud server computes
a response using the challenged blocks, obtains the corresponding plain text and
forwards it to the TPA. The details of the proposed protocol are as follows.

AISSMS COE, PUNE 2017-18 48

LATEX APPENDIX B. ASSIGNMENTS

System Specifications and Dependencies

The system comprises of following major components :
•

Figure B.2: DFD Level 1

Figure B.3: DFD Level 2

AISSMS COE, PUNE 2017-18 49

LATEX APPENDIX B. ASSIGNMENTS

Lab Assignment 04
Aim
Use of above to draw functional dependency graphs and relevant Software modelling
methods, techniques including UML diagrams or other necessities using appropriate
tools.

USE CASE DIAGRAM

Figure B.4: Use Case Diagram

AISSMS COE, PUNE 2017-18 50

LATEX APPENDIX B. ASSIGNMENTS

DEPLOYMENT DIAGRAM

Figure B.5: Deployment Diagram

AISSMS COE, PUNE 2017-18 51

LATEX APPENDIX B. ASSIGNMENTS

ACTIVITY DIAGRAM

Figure B.6: Activity Diagram

AISSMS COE, PUNE 2017-18 52

LATEX APPENDIX B. ASSIGNMENTS

SEQUENCE DIAGRAM

Figure B.7: Sequence Diagram

AISSMS COE, PUNE 2017-18 53

LATEX APPENDIX B. ASSIGNMENTS

CLASS DIAGRAM

Figure B.8: Class Diagram

AISSMS COE, PUNE 2017-18 54

LATEX APPENDIX B. ASSIGNMENTS

Lab Assignment 05
Aim
Testing of project problem statement using generated test data (using mathematical
models, GUI, Function testing principles, if any) selection and appropriate use of
testing tools, testing of UML diagram’s reliability.

Testing
Testing is an investigation conducted to provide stakeholders with infor-
mation about the quality of the product or service under test. Software testing also
provides an objective, independent view of the software to allow the business to appre-
ciate and understand the risks of software implementation. Test techniques include,
but are not limited to, the process of executing a program or application with the
intent of finding software bugs. Software testing can also be stated as the process of
validating and verifying that a software program or application or product.

Software testing, depending on the testing method employed, can be im-

plemented at any time in the development process. However, most of the test effort
occurs after the requirements have been defined and the coding process has been com-
pleted. As such, the methodology of the test is governed by the software development
methodology adopted.In a more traditional model, most of the test execution occurs
after the requirements have been defined and the coding process has been completed.

Testing types
It describes which testing types we might follow in our testing life cycle. Here we are
using:

• Black Box Testing

Black box testing methods focus on the functional requirements in the software.
That is, black box testing enables us to derive sets of input conditions that will
fully exercise.
All functional requirements of the program Black box testing attempts to find
errors in the following categories:

– Incorrect or missing function

– Interface errors
– Errors in data structure or external job access
– Performance errors
– Initialization and termination errors.

AISSMS COE, PUNE 2017-18 55

LATEX APPENDIX B. ASSIGNMENTS

In the proposed application with the help of this technique, we do not use the
code to determine a test suite; rather, knowing the problem that we are trying
to solve, we come up with four types of test data:
(a) Easy-to-compute data,
(b) Typical data,
(c) Boundary / extreme data,
(d) Bogus data.
But in our application we does not provide any external data, the role of user
is only to give number of nodes for formation of clusters and for the formation
of sink node.
• White Box Testing
White box testing is a set case design method that uses the control structure
of the procedural design to derive test cases. Using white box testing methods,
we can derive test cases that:
– Guarantee that all independent paths within a module have been exercised
at least once.
– Exercise all logical decisions on their true and false sides.
– Execute all loops at their boundaries and within their operational bounds.
– Exercise internal data structures to ensure their validity.
In the proposed application the white box testing is done by the us on the imple-
mented code, we study the code and then determines all legal (valid and invalid)
and illegal inputs and verifies the outputs against the expected outcomes, which
is also determined by studying the implementation code.
• Unit Testing
Unit testing enables a programmer to detect error in coding. A unit test focuses
verification of the smallest unit of software design. This testing was carried out
during the coding itself. In this testing step, each module going to be work
satisfactorily as the expected output from the module. The front end design
consists of various forms. They were tested for data acceptance. Similarly,
the back-end also tested for successful acceptance and retrieval of data. The
unit testing is done on the developed code. Mainly the unit testing is done on
modules.
• System Testing
After performing the integration testing, the next step is output testing of the
proposed system. No system could be useful if it doesn’t produce the required
output in a specified format. The outputs generated are displayed by the user.
Here the output format is considered in to two ways. One in on screen and
other in printed format.

AISSMS COE, PUNE 2017-18 56

LATEX APPENDIX B. ASSIGNMENTS

• Integration Testing
Through each program work individually, they should work after linking to-
gether. This is referred to as interfacing. Data may be lost across the interface;
one module can have adverse effect on the other subroutines after linking may
not do the desired function expected by the main routine. Integration testing
is the systematic technique for constructing the program structure while at the
same time conducting test to uncover errors associated with the interface. Using
integrated test plan prepared in the design phase of the system development as
a guide, the integration test was carried out. All the errors found in the system
were corrected for the next testing step.

• Functional Testing

• GUI Testing

B.1 Test Cases:

Software to be tested:
After implementation of project software will be tested by tester.

Test Cases
Testing of project problem statement using generated test data (using mathematical
models, GUI, Function testing principles, if any) selection and appropriate use of
testing tools, testing of UML diagram’s reliability.

Module-ID:-01
Modules to be tested:-Registration
1. Enter the case insensitive Username click on Submit button.
Expected: It should display error.
2. Enter the case sensitive Username click on Submit button.
Expected: It should accept.
3. Enter the case insensitive Password click on Submit button.
Expected: It should display error.
4. Enter the case sensitive Password click on Submit button.
Expected: It should accept.
5. Enter the case insensitive Mobile Number click on Submit button.
Expected: It should display error.
6. Enter the case sensitive Mobile Number click on Submit button.
Expected: It should accept.

AISSMS COE, PUNE 2017-18 57

LATEX APPENDIX B. ASSIGNMENTS

AISSMS COE, PUNE 2017-18 58

LATEX APPENDIX B. ASSIGNMENTS

Module-ID:-2
Modules to be tested:- Login
1. Enter the correct username and wrong password click on Submit button.
Expected: It should display error.
2. Enter the wrong username and correct password and click on Submit button.
Expected: It should display error.
3. Enter the correct username and password and click on Login button.
Expected: It should display welcome page.
4. After login with valid credentials click on back button.
Expected: The page should be expired.
5. After login with valid credentials copy the URL and paste in another browser.
Expected: It should not display the user’s welcome page.
6. Check the password with Lower case and upper case.
Expected: Password should be case sensitive.

AISSMS COE, PUNE 2017-18 59

LATEX APPENDIX B. ASSIGNMENTS

Module-ID:-3
Modules to be tested:- connect DB
1. Enter the wrong Username and click on Submit button.
Expected: It should display error.
2. Enter the correct Username and click on Submit button.
Expected: It should accept.
3. Enter the wrong Host and click on Submit button.
Expected: It should display error.
4. Enter the correct Host and click on Submit button.
Expected: It should accept.
5. Enter the wrong Database type and click on Submit button.
Expected: It should display error.
6. Enter the correct Database type and click on Submit button.
Expected: It should accept.

AISSMS COE, PUNE 2017-18 60