CHAPTER 4
SOFTWARE DESIGN DESCRIPTION
4.1 INTRODUCTION
The Software Design Document provides transcript which will be used to aid in the software development phase of this project by providing the details for how the software should be built. Within the Software Design Document are narrative and graphical documentation of the software design for the project including use case models, sequence diagrams, object behaviour models, and other supporting requirement information. The requirements in SRS will be fully addressed in this software design document or alternative solution should be given.
4.2 DESIGN OVERVIEW
The purpose of this software design document is to provide insight into the structure and design of each component in the Friend recommendation system. Topics covered include the following:

Class hierarchies and interactions
Data flow and design (DFD)
User interface design
Test cases and expected results

In short, this document is meant to equip the reader with a solid understanding of the inner workings of the Friend recommendation system.
The modules, as can be perceived from figure [ ], are as follows:

Collect_Data_From_Sensors

Data Collection
Data preprocessing
Activity Recognition
Friend-matching graph construction
Friend query and Feedback control

These modules will be described in detail in the next section on System Design.
4.3 SYSTEM DESIGN
This section provides a modular structure of the proposed system and explains each subsystem along with the relationships between the subsystems and the interfaces between the modules.

Figure 4.1: The Architecture Diagram
4.4 DESIGN CONSTRAINTS:

The server should be multithreaded.
The Android application at the client side should have a retry mechanism to connect to server.
Software System Attributes

The software will be embedded in a website. It should be scalable designed to be easily adopted by a system.

The system should have accurate results and fast response to user’s changing habits.

The system uses GPS location information to find friends within some distance. In order to provide privacy, a region surrounding the accurate location will be uploaded to the system.
4.5 MODULE STRUCTURE
The below is the structure of modules:
Username/password
User’s Credentials

User Data
User Data

Query for Processed data
Friends
Send
FeedbackFriend ListFriend List
Figure 4.2 : The Module design
4.4.1 DESCRIPTION OF MODULES
This section describes each of the above modules in brief.

This module contains login or registration in order to register the user with Friendbook application. If the user has already registered, then he/she can directly login and start using the application. If he/she is not registered then he/she has to register with friendbook application.

Module: Authenticate Users

This module compares the entered Username and Password with the respective records among the database entries. If a match is found, then redirects the user to his/her profile page. Else, an appropriate message is thrown and the user is redirected to the registration page.
For registration, compares the Username entered with the ones in the database to check its availability. If unavailable, then asks for a different Username, else create a new record in the database and save the entered details. Redirects the user to his/her profile page on registration with appropriate message, if the Username is not already present. If the Username entered during registration is not unique, then an appropriate message is thrown.
Name and Usernames should start with an alphabet and Password should contain at least one alphabet and one numeric character and one special character.

Module: Collect_Data_From_Sensors

Smartphone (e.g., iPhone or Android-based smartphones) are equipped with a rich set of embedded sensors, such as GPS, accelerometer, microphone, gyroscope, and camera. On the client side, each smartphone records data of its user from the sensors such as accelerometer, and GPS information.
This collected data is further sent to the server for further processing.

Module: Data Collection and Pre-processing

This module collects the data sent from the client side. The raw data collected will be in format {time ,latitude ,longitude ,accx ,accy ,accz }. The collected raw data is further pre processed to remove outliers. Median filtering technique is used for outlier detection and removal. An unsupervised learning technique is applied on the preprocessed data to form clusters known as Kmeans clustering algorithm. The resulting clusters forms a list of activities carried out by a user, where each cluster representing an activity.

Module: Activity Recognition

Now that the k clusters are formed, each represents an activity, lifestyles are further extracted from these activities using LDA algorithm. A library called LAML is used*. It provides a convenient API to get topic structures for an array of input strings.The extracted lifestyles are used to find the similarities between the users.
Once the similarity is calculated, the user who has highest similarity is suggested as a friend.

Module: User Query and Feedback Control

This module performs two tasks, it accepts and responds to user queries (eg, query for friend list) and collects feedback from users in order to improve the accuracy of the friend recommendation system.
4.6 INTERFACE DESCRIPTION:
The following is the list of external interfaces:

SOCIAL NETWORK PORTAL: A portal where the users can do registration by entering their details and also provide a feedback on the recommendations to improve the accuracy of the system. It is implemented using JSP and HTML.
MOBILE INTERFACE: It continually sends the daily activities to the server via network using TCP connection. The daily activities are characterized by walking, sitting and GPS location.
RECOMMENDATION SYSTEM : This is the interface in which the friend recommender algorithm works in the background. This interface will be used by the users. Customer cannot do many operations, but their feedbacks or ratings are very important to create a relevant recommendation. End users can only provide feedback and view recommendations.

HARDWARE INTERFACES :
The recommendation system can work on any smartphone device. These devices should have some limit requirements to make the application run effectively. The processor speed and internet speed are expected to be high.
SOFTWARE INTERFACES:
This system can work on any platform. Internet connection is a must to reach the system. Moreover, most of the application will be coded by Java. Java APIs of database management tools such as Netbeans, which is a standalone workbench application to interact with database management tools.
4.6.1 Use Case Diagrams And Key Features
A use case diagram is a kind of behavioral design, which is constructed from an analysis. It presents a graphical synopsis of the capabilities provided by a system in terms of actors, aims and dependencies between use cases.
Friend book user can perform following activities:

Install the application in their mobiles
Login/Register with the application
View the list of most similar friends
Upload feedback for improving accuracy of the system.

The Use Case diagram in Figure 4.3, shows the different functionalities a friendbook user can perform.

Figure 4.3 : Friendbook User Use Case
The System can perform following activities:

Collect raw data from users
Pre-process the data
Perform Activity Recognition and extract the lifestyles using LDA
Find the list of friends based on similarity between users
Handle Feedback

Figure 4.4 : The Server Part Use Case
4.8 Class Diagram
Top Level Client-Side Class Diagram:
The client side class diagram, mainly consists of UI(user interface) required
for a user to register with the application by providing user’s information, after which user will be able to login and start the service. Once the application starts, it continually records the values from sensors in the format:
The above values are to the server at regular intervals (say 3secs). In order to send the values to server a TCP connection is setup. Once the connection is setup, the device will start sending the data. The users can also provide a feedback on the recommendation results given to them.

Top Level Server-Side Class Diagram:
The server-side class diagram, consists of classes that are executed in a sequential manner. Firstly, ActivityClustering class collects the data sent from the android device, and pre-processes it using median filtering technique. After the data is filtered, the processed data is then partitioned into k clusters using k-means algorithm. Next, a class known as ConvertToActivitySeq is invoked, which maps the activities to cluster they are close to and produces a list containing sequence of activities i.e,. the life document. This document is further given as an input to LifeStylemodelling class, which computes p(word/document) i.e, it calculates probability of word given the document matrix. This matrix is then decomposed to produce two matrices, called p(word/lifestyle) and p(lifestyle/document). Finally, p(lifestyle/document) matrix is used to calculate the similarities of the lifestyles between users.

4.8 DATA FLOW DIAGRAM
The data flow diagrams are pictorial representation of data flowing in the system. DFD’s are used for the purpose of viewing the data processing in the system. In a data flow diagram, the data elements flow from external or an internal data source, through an internal process.
Level 0 Data Flow Diagram
A level 0 DFD or a context level design represents the intercommunication between the system and external sources, which act as data sinks. In Level 0 DFD, the interaction between the system and external entity are designed in terms of data flows across the system boundaries. This level diagram shows the complete system as a single procedure.
In the DFD diagram shown in Fig*, the lifestyle information are the sensor values sent from the client i.e., android phone to the server. The data sent from client are processed to produce a list of potential friends.

Figure 4.* : Level 0 DFD of Lifestyle based friend recommender
Level 1 Data Flow Diagram
The level 1 DFD, exhibits how the system is split into sub components, where each component represents one or more data flows to or from an external source. And when combined, it provides the complete functionality of the system as a whole. It represents the inter components data flows in a specific sequence and also the data flow between the components of the system.
The proposed application consists of the components as shown in the figure 5.*. It first performs data collection, raw data pre-processing by noise removal, Activity recognition where each cluster represents an activity and finally calculates similaties between users to suggest a friend.

Figure 5.* : Level 1 DFD of Lifestyle based friend recommender
4.9 OBJECTS AND ACTIONS (SEQUENCE DIAGRAM)
The sequence diagrams shows below.
Sequence for Setup Connection:
This sequence is to set up FOR TCP connection between user and the server. Also monitors GPS and Accelerometer by collecting the data from them.

Sequence for Monitor Result to the server:

The raw data, that is sent from the client is collected by server. And the collected raw data is pre-processed for outlier removal.
Sequence for Finding Friends:
When the user queries for the friend list, the server accepts the request from the client and responds by sending the potential list of friends.

Sequence for Data Collection:

The data collection module collects life documents from users’ smartphones. The life document is collection of users activities. The life styles of users are extracted by the life style analysis module with the probabilistic topic model(by using a library for LDA ). Then the life style indexing module puts the life styles of users into the database in the format of (life- style, user) instead of (user, life-style). As the packet arrives , these packet will be store in files.
Sequence for Preprocessing:
The user sends data, and preprocesses to make the data consistent, by remove irrelevant data.The preprocessed data is converted into archive and upload to the database.

Sequence for Database Connection:

Data base connection is established when a friend request query is posed. A TCP connection will be established between user and server. Server will process this request and respond with the extracted information from the database i.e, the list of potential friends.
4.10 PSEUDO CODE
MOBILE END:

SERVER SIDE PSEUDO CODE: