Social Networks DOC

7/25/2019 Social Networks DOC

1/129

Extracting Social Networks



2/129


INDEX

1. Introduction

2. System Analysis

a. Existing System

b. proposed System

3. Feasibility Report

a. Technical Feasibility

b. perational Feasibility

c. Economical Feasibility

!. System Re"uirement Speci#ication $ocument

a. %er%ie&

b. 'odules $escription

c. (rocess Flo&

d. S$)* 'ethodology

e. So#t&are Re"uirements

#. +ard&are Re"uirements

,. System $esign

a. $F$


3/129


b. E-R diagram

c. ')

d. $ata $ictionary

/. Technology $escription

0. *oding

. Testing $ebugging Techni"ues

. utput Screens

14. Reports

11. Future Enhancements

12. 5ibliography


4/129


INTRODUCTION


5/129


SYSTEM ANALYSIS

EXISTING SYSTEM

Existing System $oes not support the intranet mail

communication it &ill support only message transmission only.

It does not support #ile trans#er.


6/129


Existing system does not support group system.

ROOSED SYSTEM!

This system supports the intranet mailing system

The system also supports the #ile trans#er system

+ere &e maintain the groups #or adding the #riends &ith in the

intranet.

This system maintain inbox #or recei%ed mails and also maintain sent

#older #or storing the sending mails.


7/129


"EASI#ILITY REORT

TEC$NICAL "EASI#ILITY!

E%aluating the technical #easibility is the tric6iest part o# a #easibility study.

This is because7 at this point in time7 not too many detailed design o# the

system7 ma6ing it di##icult to access issues li6e per#ormance7 costs on 8on


8/129


account o# the 6ind o# technology to be deployed9 etc. A number o# issues

ha%e to be considered &hile doing a technical

analysis.

i% Un&erstan& t'e &i((erent tec'nologies in)ol)e& in t'e *ro*ose&

s+ste,!

5e#ore commencing the pro:ect7 &e ha%e to be %ery clear about &hat

are the technologies that are to be re"uired #or the de%elopment o# the

ne& system.

ii% "in& o-t w'et'er t'e organi.ation c-rrentl+ *ossesses t'e

re/-ire& tec'nologies!

o Is the re"uired technology a%ailable &ith the organi;ationA spiral

'odel o# So#t&are $e%elopment and Enhancement. This model &as not

the #irst model to discuss iterati%e de%elopment7 but it &as the #irst model

to explain &hy the iteration models.

As originally en%isioned7 the iterations &ere typically / months to 2 years

long. Each phase starts &ith a design goal and ends &ith a client

re%ie&ing the progress thus #ar. Analysis and engineering e##orts are


17/129


applied at each phase o# the pro:ect7 &ith an eye to&ard the end goal o#

the pro:ect.

The steps #or Spiral 'odel can be generali;ed as #ollo&s

The ne& system re"uirements are de#ined in as much details as

possible. This usually in%ol%es inter%ie&ing a number o# users

representing all the external or internal users and other aspects o#

the existing system.

A preliminary design is created #or the ne& system.

A #irst prototype o# the ne& system is constructed #rom the

preliminary design. This is usually a scaled-do&n system7 and

represents an approximation o# the characteristics o# the #inal

product.

A second prototype is e%ol%ed by a #our#old procedure

1. E%aluating the #irst prototype in terms o# its strengths7

&ea6ness7 and ris6s.

2. $e#ining the re"uirements o# the second prototype.

3. (lanning an designing the second prototype.

!. *onstructing and testing the second prototype.

At the customer option7 the entire pro:ect can be aborted i# the ris6

is deemed too great. Ris6 #actors might in%ol%ed de%elopment cost

o%erruns7 operating-cost miscalculation7 or any other #actor that


18/129


could7 in the customers :udgment7 result in a less-than-satis#actory

#inal product.

The existing prototype is e%aluated in the same manner as &as thepre%ious prototype7 and i# necessary7 another prototype is

de%eloped #rom it according to the #our#old procedure outlined

abo%e.

The preceding steps are iterated until the customer is satis#ied that

the re#ined prototype represents the #inal product desired.

The #inal system is constructed7 based on the re#ined prototype.

The #inal system is thoroughly e%aluated and tested. Routine

maintenance is carried on a continuing basis to pre%ent large scale

#ailures and to minimi;e do&n time.

T'e (ollowing &iagra, s'ows 'ow a s*iral ,o&el acts like!


19/129


"ig 1234S*iral Mo&el

AD5ANTAGES!

Estimates8i.e. budget7 schedule etc .9 become more relistic as &or6

progresses7 because important issues disco%ed earlier.


20/129


It is more able to cope &ith the changes that are so#t&are

de%elopment generally entails.

So#t&are engineers can get their hands in and start &oring on thecore o# a pro:ect earlier.

ALICATION DE5ELOMENT

N4TIER ALICATIONS

C-Tier Applications can easily implement the concepts o# $istributed

Application $esign and Architecture. The C-Tier Applications pro%ide

strategic bene#its to Enterprise Solutions. ?hile 2-tier7 client-ser%er can help

us create "uic6 and easy solutions and may be used #or Rapid (rototyping7

they can easily become a maintenance and security night mare

The C-tier Applications pro%ide speci#ic ad%antages that are %ital to the

business continuity o# the enterprise. Typical #eatures o# a real li#e n-tier may

include the #ollo&ing

Security

A%ailability and Scalability

'anageability

Easy 'aintenance

$ata Abstraction


21/129


The abo%e mentioned points are some o# the 6ey design goals o# a

success#ul n-tier application that intends to pro%ide a good 5usiness

Solution.

DE"INITION

Simply stated7 an n-tier application helps us distribute the o%erall

#unctionality into %arious tiers or layers

(resentation )ayer

5usiness Rules )ayer

$ata Access )ayer

$atabaseG$ata Store

Each layer can be de%eloped independently o# the other pro%ided that it

adheres to the standards and communicates &ith the other layers as per the

speci#ications.

This is the one o# the biggest ad%antages o# the n-tier application. Each

layer can potentially treat the other layer as a D5loc6-5ox.

In other &ords7 each layer does not care ho& other layer processes the data

as long as it sends the right data in a correct #ormat.


22/129


N4Tier Arc'itect-re

12 T$E RESENTATION LAYER

Also called as the client layer comprises o# components that are

dedicated to presenting the data to the user. For example

?indo&sG?eb Forms and buttons7 edit boxes7 Text boxes7 labels7 grids7

etc.

62 T$E #USINESS RULES LAYER

This layer encapsulates the 5usiness rules or the business logic o# the

encapsulations. To ha%e a separate layer #or business logic is o# a great

ad%antage. This is because any changes in 5usiness Rules can be

easily handled in this layer. As long as the inter#ace bet&een the layers

remains the same7 any changes to the #unctionalityGprocessing logic in

this layer can be made &ithout impacting the others. A lot o# client-


23/129


ser%er apps #ailed to implement success#ully as changing the business

logic &as a pain#ul process.

72 T$E DATA ACCESS LAYER

This layer comprises o# components that help in accessing the

$atabase. I# used in the right &ay7 this layer pro%ides a le%el o#

abstraction #or the database structures. Simply put changes made to

the database7 tables7 etc do not a##ect the rest o# the application

because o# the $ata Access layer. The di##erent application layers send

the data re"uests to this layer and recei%e the response #rom this

layer.

82 T$E DATA#ASE LAYER

This layer comprises o# the $atabase *omponents such as $5 Files7

Tables7 Hie&s7 etc. The Actual database could be created using S)

Ser%er7 racle7 Flat #iles7 etc.

In an n-tier application7 the entire application can be implemented in

such a &ay that it is independent o# the actual $atabase. For instance7

you could change the $atabase )ocation &ith minimal changes to $ata

Access )ayer. The rest o# the Application should remain una##ected.


24/129


SO"T9ARE RE0UIREMENT


25/129


SO"T9ARE RE0UIREMENTS

perating System ?indo&s J(G2443 or )inuxser Inter#ace +T')7 *SS

*lient-side Scripting Ka%aScript

(rogramming )anguage Ka%a

?eb Applications K$5*7 Ser%lets7 KS(

I$EG?or6bench 'y Eclipse /.4

$atabase racle 14g

Ser%er $eployment Tomcat ,.x


26/129


$ARD9ARE RE0UIREMENT


27/129


$ARD9ARE RE0UIREMENTS

(rocessor (entium IH

+ard $is6 !4B5

RA' ,12'5 or more


28/129


SYSTEM DESIGN


29/129


ROCESS "LO9


30/129


ARC$ITECTURE DIAGRAM


31/129


DATA "LO9 DIAGRAMS

DATA "LO9 DIAGRAMS!

A graphical tool used to describe and analy;e the moment o# data through a

system manual or automated including the process7 stores o# data7 and

delays in the system. $ata Flo& $iagrams are the central tool and the basis

#rom &hich other components are de%eloped. The trans#ormation o# data

#rom input to output7 through processes7 may be described logically and

independently o# the physical components associated &ith the system. The

$F$ is also 6no& as a data #lo& graph or a bubble chart.

$F$s are the model o# the proposed system. They clearly should sho& the

re"uirements on &hich the ne& system should be built. )ater during design

acti%ity this is ta6en as the basis #or dra&ing the systems structure charts.

The 5asic Cotation used to create a $F$s are as #ollo&s

12 Data(low! $ata mo%e in a speci#ic direction #rom an origin to a

destination.

62 rocess! (eople7 procedures7 or de%ices that use or produce 8Trans#orm9

$ata. The physical component is not identi#ied.


32/129


72 So-rce!External sources or destination o# data7 &hich may be (eople7

programs7 organi;ations or other entities.

82 Data Store!+ere data are stored or re#erenced by a process in the

System.


33/129


Client ClientMail Server

0.0

Request HTML page

Context Diagram ( Zero Level Diagram).

Mail SERVER


34/129


Client

Level 1 Diagram.

Proess

Request!nal"#e

Request

$.0

%.0

Req Req&'P

ClientPrepare

response

(.0

Html

page

Client

Level 2 Diagram.

Retrieve

Req )ea*ersStart a

C)il* pro.

$.$ $.%

Req ReqHea*er

Client

Sen* t)eRequest

T"pe

$.(

+ile

Client ,e- Server *enti/" t)e

Request T"pe

$.(.$

Hea*er 01T Req

Level 3 Diagram.


35/129


Client ,e- Server *enti/" t)e

Request T"pe

$.(.(

Hea*er HTML Page

Req

Level 3 Diagram.

Client ,e- Server

Level 2 Diagram.

Set 1nv.!nal"#e

Request

%.$ %.%

et

Request

2uer"

String

2.S.


36/129


Client ,e- Server

Level 2 Diagram.

Set 1nv.Rea* /rom

STD3

%.( %.4

Post

Request

Data Data

Client ,e- Server

Level 2 Diagram.

Rea* +ile&pen +ile

%.5%.6

HTMLRequest

+ileHea*er

Data

Cae +ile


37/129


Mail Server

Level 2 Diagram.

Retrieve

Req )ea*ersPrepare

Response

(.$ (.%

&'P Data

Client

Sen* t)e

Request

T"pe

(.(

+ile

Sen* t)e

Request

T"pe

(.4

&'P

Data

&'P

Data

&'P

Data


38/129


Extracting Social Networks!

E4R Diagra,!

NEWCOMPOSE

MAILID

MAILFROM

MAILTO

SU! ECT

MAILCC

MAILCC

MAILE"C#

MAILDATA

FOLDER

MAILDATE

MAILSTFILEPAT#

$ROUPNAME

ID

ACTNAME

FNAME

TNAME

FOLDERS

UNAME

FOLDER

ADDRESS

ACTNAME

UNAMENIC%NAME

EMAILID

ADDRESS

P#ONE

SI$NUPDETAILS

UNAME

PASSWD

A$E

SE"

CIT&

STATE

PIN

COUNTR&

ACTI'IT&

ID

ACTNAME

UNAME

NEWFOLDER

MIDMFROM

MTO

SU

MCC

MDATA

FOLDER

MAILST

MAILDATE


39/129


CLASS DIAGRAM

*lass diagrams describe the structure o# the system in terms

o# classes and ob:ects. The ser%let api class diagram &ill be as #ollo&s.

Class Colla:orati)e Diagra,s

!SP( I)*licit O+,ects


40/129


Use Case Diagra,!


41/129


User

Inbox

Compose

Options

Contacts

Sent

Social Network

Folders


42/129


Se/-ence Diagra,!

Add To Social Networks(

Se!t"o!tactso#tio!s"om#ose$!%o&'ser olders Social NetworkA)t*e!ticatio!

Logi!(

"*eck(

ails(

Store Mails(

"om#ose mail(

"om#ose mail wit* +iles(

"*a!ge t*e ,assw ord(

Store "o!tacts(

Store se!t Mails(

"reate +olders(


43/129


Colla:oration &iagra,!

+ol*ers

Sent

Contats options

Compos

e

.n-ox

7ser

Soial

3et8or9

!utenti

ation

$: Login()%: Ce9()

: +ails()

4: Store Mails()

5: Compose mail()6: Compose mail 8it /iles()

;: Cange te Pass8or*()


44/129


User

Tr-e

Fail

Iin+ox Co)*ose O*tions Contacts Sent Fol.ers LogO-t


45/129


TEC$NOLOGY DESCRITION

$TML


46/129


+T')7 an initialism o# +ypertext 'ar6up )anguage7 is the predominant

mar6up language #or &eb pages. It pro%ides a means to describe the

structure o# text-based in#ormation in a document L by denoting certain

text as headings7 paragraphs7 lists7 and so on L and to supplement that text

&ith interacti%e #orms7 embedded images7 and other ob:ects. +T') is &ritten

in the #orm o# labels 86no&n as tags97 surrounded by angle brac6ets. +T')

can also describe7 to some degree7 the appearance and semantics o# a

document7 and can include embedded scripting language code &hich can

a##ect the beha%ior o# &eb bro&sers and other +T') processors.

+yper Text 'ar6up )anguage

+ypertext 'ar6up )anguage 8+T')97 the languages o# the ?orld ?ide ?eb

8???97 allo&s users to produces ?eb pages that include text7 graphics and

pointer to other ?eb pages 8+yperlin6s9.

+T') is not a programming language but it is an application o# IS Standard

07 SB') 8Standard Benerali;ed 'ar6up )anguage97 but speciali;ed to

hypertext and adapted to the ?eb. The idea behind +ypertext is that instead

o# reading text in rigid linear structure7 &e can easily :ump #rom one point to

another point. ?e can na%igate through the in#ormation based on our

interest and pre#erence. A mar6up language is simply a series o# elements7

each delimited &ith special characters that de#ine ho& text or other items

enclosed &ithin the elements should be displayed. +yperlin6s are underlined

or emphasi;ed &or6s that load to other documents or some portions o# the

same document.

.

+T') pro%ides tags 8special codes9 to ma6e the document loo6 attracti%e.

+T') tags are not case-sensiti%e. sing graphics7 #onts7 di##erent si;es7


47/129


color7 etc.7 can enhance the presentation o# the document. Anything that is

not a tag is part o# the document itsel#.

5asic +T') Tags

MN -- --O speci#ies comments

MAOPPP.MGAO *reates hypertext lin6s

M5OPPP.MG5O Formats text as bold

M5$QOPMG5$QO *ontains all tags and text in the +T')

document

MFR'O...MGFR'O Encloses a #ill-out #orm

MFRA'EO...MGFRA'EO $e#ines a particular #rame in a set o# #rames

M+OPMG+O *reates headings o# di##erent le%els8 1 = / 9

M+EA$O...MG+EA$O *ontains tags that speci#y in#ormation about a

document

M+T')OPMG+T')O *ontains all other +T') tags

M'ETAO...MG'ETAO (ro%ides meta-in#ormation about a document

MS*RI(TOPMGS*RI(TO *ontains client-side or ser%er-side script

MTA5)EOPMGTA5)EO *reates a table

MT$OPMGT$O Indicates table data in a table

MTROPMGTRO $esignates a table ro&

MT+OPMGT+O *reates a heading in a table


48/129


A&)antages

A +T') document is small and hence easy to send o%er the net.

It is small because it does not include #ormatted in#ormation. +T') is plat#orm independent.

+T') tags are not case-sensiti%e.

;a)aScri*t

Ka%aScript is a script-based programming language that &as de%eloped by

Cetscape *ommunication *orporation. Ka%aScript &as originally called )i%e

Script and renamed as Ka%aScript to indicate its relationship &ith Ka%a.

Ka%aScript supports the de%elopment o# both client and ser%er components

o# ?eb-based applications. n the client side7 it can be used to &rite

programs that are executed by a ?eb bro&ser &ithin the context o# a ?eb

page. n the ser%er side7 it can be used to &rite ?eb ser%er programs that

can process in#ormation submitted by a ?eb bro&ser and then update the

bro&sers display accordingly

E%en though Ka%aScript supports both client and ser%er ?eb programming7

&e pre#er Ka%aScript at *lient side programming since most o# the bro&sers

supports it. Ka%aScript is almost as easy to learn as +T')7 and Ka%aScript

statements can be included in +T') documents by enclosing the statements

bet&een a pair o# scripting tags

MS*RI(TSO.. MGS*RI(TO.

MS*RI(T )ACBABE >Ka%aScript@O


49/129


Ka%aScript statements

MGS*RI(TO

+ere are a #e& things &e can do &ith Ka%aScript

Halidate the contents o# a #orm and ma6e calculations.

Add scrolling or changing messages to the 5ro&sers status line.

Animate images or rotate images that change &hen &e mo%e the

mouse o%er them.

$etect the bro&ser in use and display di##erent content #or

di##erent bro&sers.

$etect installed plug-ins and noti#y the user i# a plug-in is

re"uired.

?e can do much more &ith Ka%aScript7 including creating entire application.

Ad%antages

Ka%aScript can be used #or Se%er-side and *lient-side scripting.

It is more #lexible than H5Script.

Ka%aScript is the de#ault scripting languages at *lient-side since

all the bro&sers supports it.


50/129


;a)a Tec'nolog+

Initially the language &as called as >oa6@ but it &as renamed as >Ka%a@ in

1,. The primary moti%ation o# this language &as the need #or a plat#orm-

independent 8i.e.7 architecture neutral9 language that could be used to

create so#t&are to be embedded in %arious consumer electronic de%ices.

Ka%a is a programmers language.

Ka%a is cohesi%e and consistent.

Except #or those constraints imposed by the Internet en%ironment7

Ka%a gi%es the programmer7 #ull control.

Finally7 Ka%a is to Internet programming &here * &as to system

programming.

Importance o# Ka%a to the Internet

Ka%a has had a pro#ound e##ect on the Internet. This is because Ka%a

expands the ni%erse o# ob:ects that can mo%e about #reely in *yberspace.

In a net&or67 t&o categories o# ob:ects are transmitted bet&een the Ser%er

and the (ersonal computer. They are (assi%e in#ormation and $ynamic

acti%e programs. The $ynamic7 Sel#-executing programs cause serious

problems in the areas o# Security and probability. 5ut7 Ka%a addresses those

concerns and by doing so7 has opened the door to an exciting ne& #orm o#

program called the Applet.


51/129


Ka%a can be used to create t&o types o# programs

Appl icat ions and Applets An application is a program that runs on our*omputer under the operating system o# that computer. It is more or less

li6e one creating using * or *UU. Ka%as ability to create Applets ma6es it

important. An Applet is an application designed to be transmitted o%er the

Internet and executed by a Ka%a =compatible &eb bro&ser. An applet is

actually a tiny Ka%a program7 dynamically do&nloaded across the net&or67

:ust li6e an image. 5ut the di##erence is7 it is an intelligent program7 not :ust

a media #ile. It can react to the user input and dynamically change.

Features o# Ka%a Security

E%ery time you that you do&nload a >normal@ program7 you are ris6ing a

%iral in#ection. (rior to Ka%a7 most users did not do&nload executable

programs #re"uently7 and those &ho did scan them #or %iruses prior to

execution. 'ost users still &orried about the possibility o# in#ecting their

systems &ith a %irus. In addition7 another type o# malicious program exists

that must be guarded against. This type o# program can gather pri%ate

in#ormation7 such as credit card numbers7 ban6 account balances7 and

pass&ords. Ka%a ans&ers both these concerns by pro%iding a >#ire&all@

bet&een a net&or6 application and your computer.

?hen you use a Ka%a-compatible ?eb bro&ser7 you can sa#ely do&nload Ka%a

applets &ithout #ear o# %irus in#ection or malicious intent.


52/129


orta:ilit+

For programs to be dynamically do&nloaded to all the %arious types o#

plat#orms connected to the Internet7 some means o# generating portable

executable code is needed .As you &ill see7 the same mechanism that helps

ensure security also helps create portability. Indeed7 Ka%as solution to these

t&o problems is both elegant and e##icient.

T'e #+te co&e

The 6ey that allo&s the Ka%a to sol%e the security and portability problems is

that the output o# Ka%a compiler is 5yte code. 5yte code is a highly

optimi;ed set o# instructions designed to be executed by the Ka%a run-time

system7 &hich is called the Ka%a Hirtual 'achine 8KH'9. That is7 in its

standard #orm7 the KH' is an interpreter #or byte code.

Translating a Ka%a program into byte code helps ma6es it much easier to run

a program in a &ide %ariety o# en%ironments. The reason is7 once the run-

time pac6age exists #or a gi%en system7 any Ka%a program can run on it.

Although Ka%a &as designed #or interpretation7 there is technically nothing

about Ka%a that pre%ents on-the-#ly compilation o# byte code into nati%e

code. Sun has :ust completed its Kust In Time 8KIT9 compiler #or byte code.

?hen the KIT compiler is a part o# KH'7 it compiles byte code into executable

code in real time7 on a piece-by-piece7 demand basis. It is not possible to

compile an entire Ka%a program into executable code all at once7 because

Ka%a per#orms %arious run-time chec6s that can be done only at run time.

The KIT compiles code7 as it is needed7 during execution.


53/129


;a)a 5irt-al Mac'ine


54/129


Ka%a Architecture

Ka%a architecture pro%ides a portable7 robust7 high per#orming en%ironment

#or de%elopment. Ka%a pro%ides portability by compiling the byte codes #or

the Ka%a Hirtual 'achine7 &hich is then interpreted on each plat#orm by the

run-time en%ironment. Ka%a is a dynamic system7 able to load code &hen

needed #rom a machine in the same room or across the planet.

*ompilation o# code

?hen you compile the code7 the Ka%a compiler creates machine code 8called

byte code9 #or a hypothetical machine called Ka%a Hirtual 'achine 8KH'9. The

KH' is supposed to execute the byte code. The KH' is created #or

o%ercoming the issue o# portability. The code is &ritten and compiled #or one

machine and interpreted on all machines. This machine is called Ka%a Hirtual

'achine.

*ompiling and interpreting Ka%a Source *ode


55/129


$uring run-time the Ka%a interpreter tric6s the byte code #ile into thin6ing

that it is running on a Ka%a Hirtual 'achine. In reality this could be a Intel

(entium ?indo&s , or SunSAR* station running Solaris or Apple 'acintosh

running system and all could recei%e code #rom any computer through

Internet and run the Applets.

Si,*le

Ka%a &as designed to be easy #or the (ro#essional programmer to learn and

to use e##ecti%ely. I# you are an experienced *UU programmer7 learning Ka%a

&ill be e%en easier. 5ecause Ka%a inherits the *G*UU syntax and many o# the

ob:ect oriented #eatures o# *UU. 'ost o# the con#using concepts #rom *UU

are either le#t out o# Ka%a or implemented in a cleaner7 more approachable

manner. In Ka%a there are a small number o# clearly de#ined &ays to

accomplish a gi%en tas6.

Source

Code

..

..

..

PC Compiler

Macintosh

Compiler

SPARC

Compiler

Java

Byte code

(Platform

Independe

nt)

Java

Interpreter

(PC)

Java

Interpreter

(Macintosh)

Java

Interpreter

(Spare)


56/129


O:=ect4Oriente&

Ka%a &as not designed to be source-code compatible &ith any other

language. This allo&ed the Ka%a team the #reedom to design &ith a blan6

slate. ne outcome o# this &as a clean usable7 pragmatic approach to

ob:ects. The ob:ect model in Ka%a is simple and easy to extend7 &hile simple

types7 such as integers7 are 6ept as high-per#ormance non-ob:ects.

Ro:-st

The multi-plat#orm en%ironment o# the ?eb places extraordinary demands

on a program7 because the program must execute reliably in a %ariety o#

systems. The ability to create robust programs &as gi%en a high priority in

the design o# Ka%a. Ka%a is strictly typed language it chec6s your code at

compile time and run time.

Ka%a %irtually eliminates the problems o# memory management and de-

allocation7 &hich is completely automatic. In a &ell-&ritten Ka%a program7 all

run time errors can =and should =be managed by your program.


57/129


;a)a Data:ase Connecti)it+

?hat Is K$5*

Date post:	25-Feb-2018
Category:	Documents
Upload:	abhinav-garg
View:	217 times
Download:	0 times

Social Networks DOC

Documents