FriendBook (Done)

FRIENDBOOK
FRIENDBOOK
CONTENTS
DOS IN COMPUTER SCIENCE 1

FRIENDBOOK
CHAPTER 1 ABSTRACT………………………………………......………5
CHAPTER 2 INTRODUCTION…………………………………......….….6
2.1 Why we choose this topic…………………………………………………………....…….7
CHAPTER 3 LITERATURE SURVEY.........................................................9
3.1 EXISTING SYSTEM………………………………………………...…..……..9
3.2 LIMITATIONS OF THE EXISTING SYSTEM………………………...…….…...9
3.3 PROPOSED SYSTEM………………………………………………....……….9
3.4 ADVANTAGES OF PROPOSED SYSTEM……………………………...………10
CHAPTER 4 SYSTEM DESIGN…………………………………...……...11
4.1 MODULES DESCRIPTION………………………………………………...….11
4.2 USE CASE DIAGRAM…………………………………………………......…14
4.3 DATABASE DESIGN…………………………………………………..…......18
4.4 ENTITY RELATIONSHIP DIAGRAM (ER Diagram)…….....………….….…......19
4.5 ER DIAGRAM...............................................................……………………………20
4.6 DATA FLOW DIAGRAM..................................................................................21
CHAPTER 5 SOFTWARE REQUIREMENT SPECIFICATION….….25
5.1 FUNCTIONAL REQUIREMENTS………………………………………….…..25
5.2 NON-FUNCTIONAL REQUIREMENTS………………………………………..25

FRIENDBOOK
5.3 HARDWARE REQUIREMENTS……………………………………………….28
5.4 SOFTWARE REQUIREMENTS………………………………….…………....28
CHAPTER 6 TECHNOLOGY SPECIFICATION……………………....29
6.1 INTRODUCTION……………………………………………………………..29
6.2 JAVA IMPLEMENTATIONS………………………………………………..…30
6.3 JAVA J2EE…………………………………………………………………...33
6.4 MYSQL………………………………………………………………………35
CHAPTER 7 IMPLEMENTATION………………………………………..37
7.1 CODE SNIPPET OF CLASSES…………………………………………………38
CHAPTER 8 TESTING………….…………………………………………..43
8.1 PURPOSE OF TESTING……………………………………………………….43
8.2 OBJECTIVE OF TESTING……………………………………………………..43
8.3 TYPES OF TESTING…………………………………………………………..44
8.4 LEVELS OF TESTING…………………………………………………………
45
8.5 REGRESSION TESTING………………………………………………………47
CHAPTER 9 SNAPSHOTS…………………………...……………………48

FRIENDBOOK
9.1 Home_Page……………………………………………………………………48
9.2 Admin_Page…………………………………………………………………...49
9.3 Friend_Page…………………………………………………………………...50
9.4 About us_page…………………………………………………………………51
9.5 DataBase of Questions…………………………………………………………51
9.6 DataBase of Answers…………………………………………………………..52
CHAPTER 10 CONCLUSION AND FUTURE ENHANCEMENTS……53
10.1 CONCLUSION ………………………………………………………………53
10.2 FUTURE ENHANCEMENT…………………………………………………...53
CHAPTER 11 BIBLIOGRAPHY (REFERENCES)……………………...54
11.1 REFERRED BOOKS…………………………………………………………54
11.2 ONLINE REFERENCES………………………………………………………54
CHAPTER 1

FRIENDBOOK
ABSTRACT
Existing social networking services recommend friends to users based on their social
graphs, which may not be the most appropriate to reflect a user’s preferences on friend selection
in real life. In this paper, we present Friendbook, a novel semantic-based friend recommendation
system for social networks, which recommends friends to users based on their life styles instead
of social graphs. Friend book discovers life styles of users from user-centric shared data and
configuration, measures the similarity of life styles between users, and recommends friends to
users if their life styles have high similarity. Inspired by text mining, we model a user’s daily life
as life documents, from which his/her life styles are extracted by using the shared data and user
configuration. We further propose a similarity metric to measure the similarity of life styles
between users, and calculate users’ impact in terms of life styles with a friend-matching graph.
Upon receiving a request, Friendbook returns a list of people with highest recommendation
scores to the query user. Finally, Friendbook integrates a feedback mechanism to further improve
the recommendation accuracy. The results show that the recommendations accurately reflect the
preferences of users in choosing friends.
CHAPTER 2

FRIENDBOOK
INTRODUCTION
Twenty years ago, people typically made friends with others who live or work close to
themselves, such as neighbors or colleagues. We call friends made through this traditional
fashion as G-friends, which stands for geographical location-based friends because they are
influenced by the geographical distances between each other. With the rapid advances in social
networks, services such as Facebook, Twitter and Google+ have provided us revolutionary ways
of making friends. One challenge with existing social networking services is how to recommend
a good friend to a user. Most of them rely on pre-existing user relationships to pick friend
candidates. For example, Facebook relies on a social link analysis among those who already
share common friends and recommends symmetrical users as potential friends. Unfortunately,
this approach may not be the most appropriate based on recent sociology findings. According to
these studies, the rules to group people together include:
1) Habits or life style;
2) Attitudes;
3) Tastes;
4) Moral standards;
5) Economic level; and
6) People they already know.

FRIENDBOOK
Apparently, rule #3 and rule #6 are the mainstream factors considered by existing
recommendation systems. Rule #1, although probably the most intuitive, is not widely used
because users’ life styles are difficult, if not impossible, to capture through web actions. Rather,
life styles are usually closely correlated with daily routines and activities. Therefore, if we could
gather information on users’ daily routines and activities, we can exploit rule #1 and recommend
friends to people based on their similar life styles. In this paper, we use the word activity to
specifically refer to the actions taken in the order of seconds, such as “sitting”, “walking”, or
“typing”, while we use the phrase life style to refer to higher-level abstractions of daily lives,
such as “office work” or “shopping”. For instance, the “shopping” life style mostly consists of
the “walking” activity, but may also contain the “standing” or the “sitting” activities. First, how
to automatically and accurately discover life styles from noisy and heterogeneous data? Second,
how to measure the similarity of users in terms of life styles? Third, who should be
recommended to the user among all the friend candidates? To address these challenges, in this
paper, we present Friendbook, a semantic-based friend recommendation system based on shared
data and configuration.
2.1 Why we choose this topic:
 To the best of our knowledge, Friendbook is the first friend recommendation system
exploiting a user’s life style information discovered from shared data and configuration.
 Inspired by achievements in the field of text mining, we model the daily lives of users as
life documents and use the probabilistic topic model to extract life style information of
users.

FRIENDBOOK
 We propose a unique similarity metric to characterize the similarity of users in terms of
life styles and then construct a friend-matching graph to recommend friends to users
based on their life styles.
 We integrate a linear feedback mechanism that exploits the user’s feedback to improve
recommendation accuracy.
 We conduct both small-scale experiments and large scale simulations to evaluate the
performance of our system. Experimental results demonstrate the effectiveness of our
system.

FRIENDBOOK
CHAPTER 3
LITERATURE SURVEY
3.1 EXISTING SYSTEM
Existing social networking services recommend friends to users based on their social
graphs, which may not be the most appropriate to reflect a user’s preferences on friend selection
in real life. In existing system friends’ suggestions are based on the user profile details such as
school, college, living location etc.
3.2 LIMITATIONS OF THE EXISTING SYSTEM
 Less Efficient
 Suggestions are based on user profile
 Unable to find the users of same mindset
3.3 PROPOSED SYSTEM
In this paper, we present Friend book, a novel semantic-based friend recommendation
system for social networks, which recommends friends to users based on their life styles instead
of social graphs.

FRIENDBOOK
3.4 ADVANTAGES OF PROPOSED SYSTEM
Our proposed system has several advantages
 User friendly interface
 Fast access to database
 Less error
 More Storage Capacity
 Search facility
 Look and Feel Environment
 Quick transaction.

FRIENDBOOK
CHAPTER 4
SYSTEM DESIGN
There are two actors in this project.
 Administrator:
Administrator is a business entity who has full authority over the application. Administrator
maintains the entire application, thus we call him Application owner.
 Member:
Member or customer is the persons who receive the services by getting registered.
4.1 MODULES DESCRIPTION
1. User class – Administrator:
The administrator has the following modules.
 Login module
In this module, the administrator can login to this application by providing credentials like
username and password.
 Manage Category

FRIENDBOOK
The admin can add different categories of topics and update or delete the same.
 Manage Questions
The admin can add different questions under each categories which are displayed for the user to
answer.
 Manage Answers
The admin can add the different choices of answer for the user to select when questions are
displayed for them.
 Change Password
The admin can update his own profile like changing the password, etc.
2. User Class – Member
The members have the following functionalities
 Registration Module
Any visitor can login to this application by getting registered as a member.
 Login Module
In this module users can get login to the application by specifying their credentials such as user
id and password and can make use of application services.
 Find Friend

FRIENDBOOK
Here users can search for friends based on school name, college, profession, city wise, area wise,
user name, Email Id and can send the friend request, once the request is approved .
 Add Friend
In this module, any member can add friends by accepting others friend request.
 Change Cover Photo
In this module, the member can change their cover photo.
 Manage Lifestyles
In this module the member will answer the questionnaire about their lifestyles. At any point, they
can update or change their answers. Based on their answers, lifestyles are set for any member.
 Share Information
The main objective of the application is to share the information. Here website users can share
the information such as text messages, pictures and videos with others.
 Friend Recommendation
This is the core module of the project where the system suggests the friends for the website users
based on the user life styles and user configurations (area of interest), and user feedbacks.
 Manage Friend Request
In this module, the member can send friend requests to others. In the same way, members can
accept others friend requests.
 Profile Updation

FRIENDBOOK
In this module users can update their profile details such as general profile details, contact
details, area of interest (life styles), personal details, and professional details etc.
 Post Comments
Here users of the website can post the comments for the postings in their walls and can share
their opinions regarding the postings such as text messages, pictures, and videos.
 Change Password
Here in this module the member can change their password of this application.
 Logout
In this module the member can close this application securely, by logout.
4.2 USE CASE DIAGRAM
Use case diagrams model the functionality of a system using actors and use cases. Use
cases are services or functions provided by the system to its users. Use case diagrams are usually
referred to as behavior diagrams used to describe a set of actions (use cases) that some system or
systems (subject) should or can perform in collaboration with one or more external users of the
system (actors). Each use case should provide some observable and valuable result to the actors
or other stakeholders of the system.

FRIENDBOOK
Actors:
An actor is a person, organization, or external system that plays a role in one or more
interactions with your system. Actors are drawn as stick figures.
 An Actor is a role of an object or objects outside of a system that interacts directly with it
as part of a coherent work unit
 One physical object (or class) may play several different roles and be modeled by several
actors
Use cases:
A use case describes a sequence of actions that provide something of measurable value to
an actor and is drawn as a horizontal ellipse.
 A Use Case captures some actor-visible function
 Achieves some discrete (business-level) goal for that actor
 May be read, write, or read-modify-write in nature
Associations:
Associations between actors and use cases are indicated in use case diagrams by solid
lines. An association exists whenever an actor is involved with an interaction described by a use
case.
System boundary boxes:
You can draw a rectangle around the use cases, called the system boundary box, to
indicates the scope of your system. Anything within the box represents functionality that is in
scope.

FRIENDBOOK
Use Case Diagram – Admin:
Fig: Use Case Diagram of the admin

FRIENDBOOK
Use Case Diagram – Member:
Fig: Use Case Diagram of the member

FRIENDBOOK
4.3 DATABASE DESIGN
4.4 ENTITY RELATIONSHIP DIAGRAM (ER Diagram):

FRIENDBOOK
Entity–relationship model(ER model) is a data model for describing the data or
information aspects of a business domain or its process requirements, in an abstract way that
lends itself to ultimately being implemented in a database such as a relational database. The main
components of ER models are entities(things) and the relationships that can exist among them,
and databases. ER Diagram is a graphical representation of entities and their relationships to
each other, typically used in computing in regard to the organization of data within databases or
information systems. An entity is a piece of data-an object or concept about which data is stored.
A relationship is how the data is shared between entities. There are three types of relationships
between entities:
 One-to-One: One instance of an entity is associated with one other instance of another
entity.
 One-to-Many: One instance of an entity is associated with zero, one or many instances
of another entity, but for one instance of entity B there is only one instance of entity A.
 Many-to-Many: One instance of an entity (A) is associated with one, zero or many
instances of another entity (B), and one instance of entity B is associated with one, zero or
many instances of entity A.

FRIENDBOOK
4.5 ER DIAGRAM

FRIENDBOOK
4.6 DATA FLOW DIAGRAM
A data flow diagram (DFD) is a graphical representation of the "flow" of data through
an information system, modeling its process aspects. Often they are a preliminary step used to
create an overview of the system which can later be elaborated. DFDs can also be used for
the visualization of data processing (structured design). A DFD shows what kinds 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 processes, or
information about whether processes will operate in sequence or in parallel.
DFD shows how the information moves through the system and how it is modified by a
series of transformations. It is a graphical technique that depicts information flow and the
transformations that are applied as data moves from input to output.
A DFD may be used to represent a system at any level of abstraction. DFD may be partitioned
into levels that represent increasing information flow and functional detail.
Data flow processes:
A data flow represents the flow of information, with its direction represented by an arrow
head that shows at the end(s) of flow connector.
It will define the direction i.e., the data flow from one entity to another entity.
Process:
A process is a business activity or function where the manipulation and transformation of
data takes place. A process can be decomposed to finer level of details, for representing how data
is being processed within the process. Process defines the source from where the output is

FRIENDBOOK
generated for the specified input. It states the actions performed on data such that they are
transformed, stored or distributed.
Data store:
A data store represents the storage of persistent data required and/or produced by the
process. Here are some examples of data stores: membership forms, database table, etc.
It is the place or physical location where the data is stored after extraction from the data source.
External Entity:
An external entity can represent a human, system or subsystem. It is where certain data
comes from or goes to. It is external to the system we study, in terms of the business process. For
this reason, people used to draw external entities on the edge of a diagram

FRIENDBOOK
Data Flow Diagram – Admin
Fig: Data Flow Diagram of Administrator

FRIENDBOOK
Data Flow Diagram – Member
Fig: Data Flow Diagram of the member

FRIENDBOOK
CHAPTER 5
SOFTWARE REQUIREMENT SPECIFICATION
5.1 FUNCTIONAL REQUIREMENTS
Functional requirements capture the intended behavior of the system. This behavior may
be expressed as services, tasks or functions the system is required to perform.
It is a description of the facility or feature required. Functional requirements deal with
what the system should do or provide for users. They include description of the required
functions, outlines of associated reports or online queries, and details of data to be held in the
system.
In software engineering, a functional requirement defines a function of a software system
or its component. A function is described as a set of inputs, the behavior, and outputs (see also
software). Functional requirements may be calculations, technical details, data manipulation and
processing and other specific functionality that define what a system is supposed to accomplish.
5.2 NON-FUNCTIONAL REQUIREMENTS
It a description and, where possible, target values of associated non-functional
requirements. Non-functional requirements detail constraints, targets or control mechanisms for
the new system. They describe how, how well or to what standard a function should be provided.

FRIENDBOOK
Example: levels of required service such as response times; security and access requirements;
technical constraints; required interfacing with users' and other systems; and project constraints
such as implementation on the organization’s hardware/software platform.
Service level requirements are measures of the quality of service required, and are crucial
to capacity planning and physical design. Identify realistic, measurable target values for each
service level. These include service hours, service availability, responsiveness, throughput and
reliability. Security includes defining priority and frequency of backup of data, recovery,
fallback and contingency planning and access restrictions. Access restrictions should deal with
what data needs protected; what data should be restricted to a particular user role; and level of
restriction required, eg physical, password, view only. Non-functional requirements may cover
the system as a whole or relate to specific functional requirements. Non Functional Requirements
includes aspects like:
 Usability
 Reliability
 Interoperability
 Scalability
 Security
 Performance

FRIENDBOOK
EFFICIENCY
Efficiency in general describes the extent to which time or effort is well used for the
intended task or purpose. It is often used with the specific purpose of relaying the capability of a
specific application of effort to produce a specific outcome effectively with a minimum amount
or quantity of waste, expense, or unnecessary effort. "Efficiency" has widely varying meanings
in different disciplines.
SCALABILITY
Scalability, as a property of systems, is generally difficult to define and in any particular
case it is necessary to define the specific requirements for scalability on those dimensions that
are deemed important. It is a highly significant issue in electronics systems, databases, routers,
and networking. A system, whose performance improves after adding hardware, proportionally
to the capacity added, is said to be a scalable system.
INTEROPERABILITY
Interoperability is a property referring to the ability of diverse systems and
organizations to work together (inter-operate). The term is often used in a technical systems
engineering sense, or alternatively in a broad sense, taking into account social, political, and
organizational factors that impact system to system performance.

FRIENDBOOK
RELIABILITY
Reliability (systemic def.) is the ability of a person or system to perform and maintain its
functions in routine circumstances, as well as hostile or unexpected circumstances.
USABILITY
"The extent to which a product can be used by specified users to achieve specified goals
with effectiveness, efficiency, and satisfaction in a specified context of use." The word
"usability" also refers to methods for improving ease-of-use during the design process.
5.3 HARDWARE REQUIREMENTS
 Processor : Pentium IV or above.
 RAM : 2 GB or more.
 Hard Disk Space : Minimum of 80 GB.
 Android Mobile
5.4 SOFTWARE REQUIREMENTS
 Operating System : Windows XP, Windows 7
 Language : Java, J2EE
 Java Software : JDK 1.6 or above
 Tool : Eclipse IDE
 Database : MY-SQL
 Web Server : Apache Tomcat Server

FRIENDBOOK
CHAPTER 6
TECHNOLOGY SPECIFICATION
6.1 INTRODUCTION
When we come to technology we are using java JDK 1.6 version , Java is a programming
language originally developed by James Gosling at Sun Microsystems (which is now a
subsidiary of Oracle Corporation) and released in 1995 as a core component of Sun
Microsystems' Java platform. The language derives much of its syntax from C and C++ but has a
simpler object model and fewer low-level facilities. Java applications are typically compiled to
byte code (class file) that can run on any Java Virtual Machine (JVM) regardless of computer
architecture. Java is a general-purpose, concurrent, class-based, object-oriented language that is
specifically designed to have as few implementation dependencies as possible. It is intended to
let application developers "write once, run anywhere". Java is currently one of the most popular
programming languages in use, and is widely used from application software to web
applications. Java is a platform independent language. JDK is the Java Development Kit which
includes the Java Runtime Environment (JRE). JDK is for programmers to write Java programs
and applets. Applets are java executable code that runs in a web browser for example a lot of
broadband speed tests use a java applet that loads in the web browser.JRE must be installed on
the client PC to support the running of the applet. Java is used a lot on the web and also in
mobile phones and consumer devices because java is versatile and platform independent

FRIENDBOOK
One characteristic of Java is portability, which means that computer programs written in
the Java language must run similarly on any supported hardware/operating-system platform. This
is achieved by compiling the Java language code to an intermediate representation called Java
byte code, instead of directly to platform-specific machine code. Java byte code instructions are
analogous to machine code, but are intended to be interpreted by a virtual machine (VM) written
specifically for the host hardware. End-users commonly use a Java Runtime Environment (JRE)
installed on their own machine for standalone Java applications, or in a Web browser for Java
applets.
Standardized libraries provide a generic way to access host-specific features such as
graphics, threading, and networking.
A major benefit of using byte code is porting. However, the overhead of interpretation
means that interpreted programs almost always run more slowly than programs compiled to
native executables would. Just-in-Time compilers were introduced from an early stage that
compiles byte codes to machine code during runtime.
6.2 JAVA IMPLEMENTATIONS

Sun Microsystems officially licenses the Java Standard Edition platform for Linux, Mac
OS X, and Solaris. Although in the past Sun has licensed Java to Microsoft, the license has
expired and has not been renewed. Through a network of third-party vendors and licensees,
alternative Java environments are available for these and other platforms.
Sun's trademark license for usage of the Java brand insists that all implementations be
"compatible". This resulted in a legal dispute with Microsoft after Sun claimed that the Microsoft
implementation did not support RMI or JNI and had added platform-specific features of their

FRIENDBOOK
own. Sun sued in 1997 and in 2001 won a settlement of US$20 million, as well as a court order
enforcing the terms of the license from Sun. As a result, Microsoft no longer ships Java with
Windows, and in recent versions of Windows, Internet Explorer cannot support Java applets
without a third-party plug-in. Sun, and others, have made available free Java run-time systems
for those and other versions of Windows.
Platform-independent Java is essential to the Java EE strategy, and an even more rigorous
validation is required to certify an implementation. This environment enables portable server-
side applications, such as Web services, Java Servlets, and Enterprise JavaBeans, as well as with
embedded systems based on OSGi, using Embedded Java environments. Through the new
GlassFish project, Sun is working to create a fully functional, unified open source
implementation of the Java EE technologies. Sun also distributes a superset of the JRE called the
Java Development Kit (commonly known as the JDK), which includes development tools such
as the Java compiler, Javadoc, Jar, and debugger.
6.2.1 Java Performance
Programs written in Java have a reputation for being slower and requiring more memory
than those written in C. However, Java programs' execution speed improved significantly with
the introduction of Just-in-time compilation in 1997/1998 for Java 1.1 the addition of language
features supporting better code analysis (such as inner classes, String Buffer class, optional
assertions, etc.), and optimizations in the Java Virtual Machine itself, such as Hotspot becoming
the default for Sun's JVM in 2000. Currently, Java code has approximately half the performance
of C code.

FRIENDBOOK
Platforms offer direct hardware support for Java; there are microcontrollers that can run
java in hardware instead of a software JVM, and ARM based processors can have hardware
support for executing Java byte code through its Jazelle option.
6.2.2 Automatic Memory Management
Java uses an automatic garbage collector to manage memory in the object lifecycle. The
programmer determines when objects are created, and the Java runtime is responsible for
recovering the memory once objects are no longer in use. Once no references to an object
remain, the unreachable memory becomes eligible to be freed automatically by the garbage
collector. Something similar to a memory leak may still occur if a programmer's code holds a
reference to an object that is no longer needed, typically when objects that are no longer needed
are stored in containers that are still in use. If methods for a nonexistent object are called, a "null
pointer exception" is thrown.
One of the ideas behind Java's automatic memory management model is that
programmers can be spared the burden of having to perform manual memory management. In
some languages, memory for the creation of objects is implicitly allocated on the stack, or
explicitly allocated and deallocated from the heap. In the latter case the responsibility of
managing memory resides with the programmer. If the program does not deallocate an object, a
memory leak occurs. If the program attempts to access or deallocate memory that has already
been deallocated, the result is undefined and difficult to predict, and the program is likely to
become unstable and/or crash. This can be partially remedied by the use of smart pointers, but
these add overhead and complexity. Note that garbage collection does not prevent "logical"
memory leaks, i.e. those where the memory is still referenced but never used.

FRIENDBOOK
Garbage collection may happen at any time. Ideally, it will occur when a program is idle.
It is guaranteed to be triggered if there is insufficient free memory on the heap to allocate a new
object; this can cause a program to stall momentarily. Explicit memory management is not
possible in Java.
Java does not support C/C++ style pointer arithmetic, where object addresses and
unsigned integers (usually long integers) can be used interchangeably. This allows the garbage
collector to relocate referenced objects and ensures type safety and security.
As in C++ and some other object-oriented languages, variables of Java's primitive data
types are not objects. Values of primitive types are either stored directly in fields (for objects) or
on the stack (for methods) rather than on the heap, as commonly true for objects (but see Escape
analysis). This was a conscious decision by Java's designers for performance reasons. Because of
this, Java was not considered to be a pure object-oriented programming language. However, as
of Java 5.0, auto boxing enables programmers to proceed as if primitive types were instances of
their wrapper class.
Java contains multiple types of garbage collectors. By default, Hotspot uses the
Concurrent Mark Sweep collector, also known as the CMS Garbage Collector. However, there
are also several other garbage collectors that can be used to manage the Heap. For 90% of
applications in Java, the CMS Garbage Collector is good enough.
6.3 JAVA J2EE

The Java 2 Platform, Enterprise Edition (J2EE) defines the standard for developing
multitier enterprise applications. The J2EE platform simplifies enterprise applications by basing
them on standardized, modular components, by providing a complete set of services to those

FRIENDBOOK
components, and by handling many details of application behaviour automatically, without
complex. The J2EE platform takes advantage of many features of the Java 2 Platform, Standard
Edition (J2SE), such as "Write Once, Run Anywhere" portability, JDBC API for database
access, CORBA technology for interaction with existing enterprise resources, and a security
model that protects data even in internet applications. Building on this base, the Java 2 Platform,
Enterprise Edition adds full support for Enterprise JavaBeans components, Java Servlets API,
Java Server Pages and XML technology.
The J2EE standard includes complete specifications and compliance tests to ensure
portability of applications across the wide range of existing enterprise systems capable of
supporting the J2EE platform. In addition, the J2EE specification now ensures Web services
interoperability through support for the WS-I Basic Profile.
6.3.1 Making Middleware Easier
Today's enterprises gain competitive advantage by quickly developing and deploying
custom applications that provide unique business services. Whether they're internal applications
for employee productivity or Internet applications for specialized customer or vendor services,
Quick development and deployment are keys to success. Portability and scalability are also
important for long term viability. Enterprise applications must scale from small working
prototypes and test cases to complete 24 x 7, enterprise-wide services, accessible by tens,
hundreds, or even thousands of clients simultaneously. However, multitier applications are hard
to architect. They require bringing together a variety of skill sets and resources, legacy data and
legacy code. In today's heterogeneous environment, enterprise applications have to integrate
services from a variety of vendors with a diverse set of application models and other standards.

FRIENDBOOK
Industry experience shows that integrating these resources can take up to 50% of
application development time. As a single standard that can sit on top of a wide range of existing
enterprise systems database management systems, transaction monitors, naming and directory
services, and more the J2EE platform breaks the barriers inherent between current enterprise
systems. The unified J2EE standard wraps and embraces existing resources required by multitier
applications with a unified, component-based application model. This enables the next
generation of components, tools, systems, and applications for solving the strategic
Requirements of the enterprise.
The J2EE specification also supports emerging Web Services technologies through
inclusion of the WS-I Basic Profile. WS-I Basic Profile compliance means that the developers
can build applications on the J2EE platform as Web services that interoperate with Web services
from non-J2EE compliant environments. With simplicity, portability, scalability, and legacy
integration, the J2EE platform is the platform for enterprise solutions.
6.4 MYSQL
MySQL is a database system used on the web. Basically, a MySQL database allows us to
create a relational database structure on a web-server in order to store data or automate
procedures. PHP acts as your queries, and forms are basically web pages with fields in them.
MySQL is also open source in that it’s free and falls under the GNU General Public License.
Interacting with a MySQL database is a little weird. When creating tables, we have to create
them by using SQL Statements, or by using another open-source tool available online called
PHPMyAdmin. PHPMyAdmin gives you an easy-to-use interface that allows you to create tables
and run queries by filling in a little bit of information and then having the tables created for us.

FRIENDBOOK
MySQL is one of the most popular relational databases Management System on the web.
The MySQL Database has become the world's most popular open source Database, because it is
free and available on almost all the platforms. The MySQL can run on Unix, window, and Mac
OS. It is used for the internet applications as it provides good speed and is very secure. It was
developed to manage large volumes of data at very high speed to overcome the problems of
existing solutions. MySQL can be used for verity of applications but it is mostly used for the web
applications on the internet.
6.4.1 Usage of MySQL
 Scalability and Flexibility: Can handle embedded applications and massive data
warehouses.
 High Performance: Unique storage engine architecture.
 High Availability: High speed master/slave replication configurations.
 ACID (atomic, consistent, isolated, durable) transaction support.
 Distributed transaction capability.
 Multi-version transaction support.
 Web and Data Warehouse Strengths.
 High performance query engine.
 Good storage architecture for data warehousing.
 Management Ease
 Automatic space expansion, auto-restart, and dynamic configuration
Suite of graphical management and migration tools

FRIENDBOOK
CHAPTER 7
IMPLEMENTATION
A crucial phase in the system lifecycle is the successful implementation of the new
system design. Implementation simply means converting a new system design into operation.
Implementation is a stage in which the design is converted into working system.
Implementation is the process of bringing the developed system into operational use and
turning it to the user. This stage is considered to be the most crucial stage in the development of
a successful system since a new system is developed and the users are given the confidence of its
effectiveness.
Implementation Phases are as follows:
 First phase includes table design for Database module.
 Second phase includes coding for GUI modules
 Third phase includes the integration of modules
 Fourth phase includes connection establishment between the front-end and back-
end
 Fifth phase includes error handling and message generator.
7.1 CODE SNIPPET OF CLASSES

FRIENDBOOK
Admin_Home Page.jsp
<head>
<title>Friendbook</title>
<meta http-equiv="Content-Type" content="text/html;
charset=ISO-8859-1">
<link href="../css/style.css" rel="stylesheet"
type="text/css" />
<script type="../text/javascript" src="js/jquery-
1.3.2.min.js"></script>
<script type="../text/javascript"
src="js/script.js"></script>
<script type="../text/javascript" src="js/cufon-
yui.js"></script>

FRIENDBOOK
src="js/arial.js"></script>
src="js/cuf_run.js"></script>
<script type="text/javascript"
src="../js/validate.js"></script>
</head>
<body>
<div class="main">
<div class="search">
<form method="get" id="search" action="#">
<span>

FRIENDBOOK
<input type="text" value="Search..." name="s"
id="s" />
<input name="searchsubmit" type="image"
src="../images/search.gif" value="Go"
id="searchsubmit" class="btn" />
</span>
</form>
<div class="clr"></div>
</div>
<div class="header">
<div class="logo">

FRIENDBOOK
<h1><a
href="index.html"><span>FriendBook</span></a></h1>
</div>
<div class="menu_nav">
<ul>
<li class="active"><a
href="../admin/admin_home.jsp">Category</a></li>
<li><a
href="../admin/questions.jsp">Questions</a></li>
<li><a
href="../admin/answers.jsp">Answers</a></li>
<li><a
href="../admin/changepassword.jsp">Change
Password</a></li>

FRIENDBOOK
<li><a
href="../home/logout.jsp">Logout</a></li>
</ul>
</div>
</div>
<div class="hbg"><img
src="../images/header_images.jpg" width="970"
height="294" alt="" /></div>
<div class="content">
<div class="mainbar">
<div class="article">

FRIENDBOOK
<h2><span>Category</span></h2>


CHAPTER 8
TESTING
8.1 PURPOSE OF TESTING
Testing the software is the process of validating and verifying of a software program. The
errors are to be identified in order to fix those errors. Thus the main objective of software testing
is to maintain and deliver a quality product to the client. Every software is expected to meet

FRIENDBOOK
certain needs. So when software is developed it is required to check whether it fulfills those
needs. Banking software is entirely different from software required in a shop. The needs and
requirements of both those software are different. Hence it is important to check its potential.
The main goal of software testing is to know the errors of the software before the user finds
them. Software testing is the operating of software under controlled conditions to check whether
the software works well and to rectify the errors, and also to make sure that we are delivering the
correct software what the user intends.
8.2 OBJECTIVE OF TESTING
Software testing helps to make sure that it meets the entire requirement it was supposed to meet.
 It will bring out all the errors, if any, while using the software.
 Software testing helps to understand that the software that is being tested is a complete
success Software testing helps to give a quality certification that the software can be used
by the client immediately.
 It ensures quality of the product.
8.3 TYPES OF TESTING
The two major approaches of software testing are
 White Box Testing

FRIENDBOOK
 Black Box Testing
WHITE BOX TESTING
White box software testing is the testing of the working of the software and its internal
structures. It can detect errors of the implemented parts, but the unimplemented parts go
undetected. In order to implement white box testing, the tester has to deal with the code and
hence is needed to possess knowledge of coding and logic i.e. internal working of the code.
White box test also needs the tester to look into the code and find out which unit/statement/chunk
of the code is malfunctioning. For white box testing, the test cases cannot be determined until the
code has actually been written. Test data are derived from direct examination of the code to be
tested.
BLACK BOX TESTING
Black box testing is the testing of the functionality of the software as opposed to its
internal structure. It can be done at all levels of software testing. Black Box Testing is testing
without knowledge of the internal workings of the item being tested. For example, when black
box testing is applied to software engineering, the tester would only know the “legal” inputs and
what the expected outputs should be, but not how the program actually arrives at those outputs.
In black box testing, the test planning can begin as soon as the specifications are written.
The opposite of this would be glass box testing, where test data are derived from direct

FRIENDBOOK
examination of the code to be tested. Both of these testing techniques have advantages and
disadvantages, but when combined, they help to ensure thorough testing of the product.
8.4 LEVELS OF TESTING
There are four levels of software testing:
1. Unit Testing
Unit Testing is a level of the software testing process where individual units/components of a
software/system are tested. The purpose is to validate that each unit of the software performs as
designed.
2. Integration Testing

FRIENDBOOK
Integration Testing is a level of the software testing process where individual units are combined
and tested as a group. The purpose of this level of testing is to expose faults in the interaction
between integrated units.
3. System Testing
System Testing is a level of the software testing process where a complete, integrated
system/software is tested. The purpose of this test is to evaluate the system’s compliance with the
specified requirements.
4. Acceptance Testing
Acceptance Testing is a level of the software testing process where a system is tested for
acceptability. The purpose of this test is to evaluate the system’s compliance with the business
requirements and assess whether it is acceptable for delivery.
8.5 REGRESSION TESTING
Regression testing is a type of software testing that seeks to uncover new software bugs,
or regressions, in existing functional and non-functional areas of a system after changes such as
enhancements, patches or configuration changes, have been made to them.
The intent of regression testing is to ensure that changes such as those mentioned above
have not introduced new faults. One of the main reasons for regression testing is to determine
whether a change in one part of the software affects other parts of the software.

FRIENDBOOK
Common methods of regression testing include rerunning previously completed tests and
checking whether program behavior has changed and whether previously fixed faults have re-
emerged. Regression testing can be performed to test a system efficiently by systematically
selecting the appropriate minimum set of tests needed to adequately cover a particular change.
This testing is done to make sure that new code changes should not have side effects on
the existing functionalities. It ensures that old code still works once the new code changes are
done.
CHAPTER 9
SNAPSHOTS
9.1 Home_Page:

FRIENDBOOK

FRIENDBOOK
9.2 Admin_Page:

FRIENDBOOK

FRIENDBOOK
9.3 Friend_Page:

FRIENDBOOK
9.4 About us_page:
9.5 DataBase of Questions:

FRIENDBOOK
9.6 DataBase of Answers:

FRIENDBOOK
CHAPTER 10
CONCLUSION AND FUTURE ENHANCEMENTS

FRIENDBOOK
10.1 CONCLUSION
. This application is like a social networking site which is giving us a chance to make new
friends based on the lifestyle. Each person has a different lifestyle, different likings, and different
taste. People can get friends based on their area of living like school, city and college. This
project is suggesting friends who have almost same lifestyles. Based on the answers given by the
users, lifestyle is known and based on that, a friend is recommended or suggested. This project is
very helpful for people to find new friends and make new friends. This project is working as per
designed requirements and working properly without errors.
10.2 FUTURE ENHANCEMENT
This project can have many enhancements in future. Some are listed below.
 We can enhance this project to provide SMS alerts and notifications.
 Using GPRS we can add all the places recently visited to the favorite list. Then we can
suggest friends based on the favorite list.
 During registration, we can send account activation link to the email.
CHAPTER 11

FRIENDBOOK
BIBLIOGRAPHY (REFERENCES)
11.1 REFERRED BOOKS
 Software Engineering, Ian Summerville, Sixth Edition, Pearson Education Ltd, 2001
 Wikipedia, the free encyclopedia
 Java and J2EE -Balgur swamy and Herbert schildt.
 Schildt, “Java 2 The Complete Reference”, 8th Edition ,Tata McGraw-Hill
Herbert education ,2011.
 James Keogh, “J2EE Complete Reference”, 8th Edition, McGraw-Hill/Osborne Media,
2011.
 Phill Hanna, “JSP Complete Reference”, 2nd Edition, Osborne/McGraw-Hill, 2001.
 Phill Hanna, “JDBC Complete Reference”, 2nd Edition, Osborne/McGraw-Hill, 2001.
 Thomas A.Powell, HTML, “CSS: The Complete Reference”, 5th Edition, Tata McGraw-
Hill education, 2010.
11.2 ONLINE REFERENCES

http://download-llnw.oracle.com/javase/tutorial/index.html
http://www.java.com/en/download/faq/what is-java.xml
http://www.tutorialspoint.com/jdbc/jdbc-quick-guide.html
http://www.jdbc-tutorial.com/jdbc-tutorials/jdbc-create-table
http://www.w3schools.com/html/html-elements.jsp

FriendBook (Done)

Uploaded by

Copyright:

Available Formats

You might also like

FriendBook (Done)

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

FriendBook (Done)

Uploaded by

Copyright:

Available Formats

FRIENDBOOK

DOS IN COMPUTER SCIENCE 1

2.1 Why we choose this topic…………………………………………………………....…….7

CHAPTER 3 LITERATURE SURVEY.........................................................9

3.1 EXISTING SYSTEM………………………………………………...…..……..9

3.2 LIMITATIONS OF THE EXISTING SYSTEM………………………...…….…...9

3.3 PROPOSED SYSTEM………………………………………………....……….9

3.4 ADVANTAGES OF PROPOSED SYSTEM……………………………...………10

CHAPTER 4 SYSTEM DESIGN…………………………………...……...11

4.1 MODULES DESCRIPTION………………………………………………...….11

4.2 USE CASE DIAGRAM…………………………………………………......…14

4.3 DATABASE DESIGN…………………………………………………..…......18

4.4 ENTITY RELATIONSHIP DIAGRAM (ER Diagram)…….....………….….…......19

4.6 DATA FLOW DIAGRAM..................................................................................21

CHAPTER 5 SOFTWARE REQUIREMENT SPECIFICATION….….25

5.1 FUNCTIONAL REQUIREMENTS………………………………………….…..25

5.2 NON-FUNCTIONAL REQUIREMENTS………………………………………..25

DOS IN COMPUTER SCIENCE 2

5.3 HARDWARE REQUIREMENTS……………………………………………….28

5.4 SOFTWARE REQUIREMENTS………………………………….…………....28

CHAPTER 6 TECHNOLOGY SPECIFICATION……………………....29

6.2 JAVA IMPLEMENTATIONS………………………………………………..…30

6.3 JAVA J2EE…………………………………………………………………...33

7.1 CODE SNIPPET OF CLASSES…………………………………………………38

8.1 PURPOSE OF TESTING……………………………………………………….43

8.2 OBJECTIVE OF TESTING……………………………………………………..43

8.3 TYPES OF TESTING…………………………………………………………..44

8.4 LEVELS OF TESTING…………………………………………………………

8.5 REGRESSION TESTING………………………………………………………47

DOS IN COMPUTER SCIENCE 3

9.4 About us_page…………………………………………………………………51

9.5 DataBase of Questions…………………………………………………………51

9.6 DataBase of Answers…………………………………………………………..52

CHAPTER 10 CONCLUSION AND FUTURE ENHANCEMENTS……53

10.1 CONCLUSION ………………………………………………………………53

10.2 FUTURE ENHANCEMENT…………………………………………………...53

CHAPTER 11 BIBLIOGRAPHY (REFERENCES)……………………...54

11.1 REFERRED BOOKS…………………………………………………………54

11.2 ONLINE REFERENCES………………………………………………………54

DOS IN COMPUTER SCIENCE 4

preferences of users in choosing friends.

DOS IN COMPUTER SCIENCE 5

these studies, the rules to group people together include:

1) Habits or life style;

5) Economic level; and

6) People they already know.

DOS IN COMPUTER SCIENCE 6

paper, we present Friendbook, a semantic-based friend recommendation system based on shared

data and configuration.

2.1 Why we choose this topic:

DOS IN COMPUTER SCIENCE 7

 We propose a unique similarity metric to characterize the similarity of users in terms of

based on their life styles.

performance of our system. Experimental results demonstrate the effectiveness of our

DOS IN COMPUTER SCIENCE 8

3.1 EXISTING SYSTEM

school, college, living location etc.