Docstoc

ARD

Document Sample
ARD Powered By Docstoc
					     BEN GURION UNIVERSITY




         ARD Document




SOCIAL NETWORK INFORMATION CONSOLIDATION


 AUTHORS:
   YARON NISIMOV
   TOMER KLASQUIN
   EREZ RABIH
TABLE OF CONTENTS

1.     Introduction ...........................................................................................................................................................4

     1.1.       Vision ............................................................................................................................................................4

     1.2.       Problem Domain ..........................................................................................................................................4

     1.3.       Stakeholders.................................................................................................................................................5

       1.3.1.       Customers ................................................................................................................................................5

       1.3.2.       Experts .....................................................................................................................................................6

       1.3.3.       Users ........................................................................................................................................................6

     1.4.       Software Context .........................................................................................................................................6

     1.5.       System Interfaces: ........................................................................................................................................7

       1.5.1.       Hardware Interfaces: ...............................................................................................................................7

       1.5.2.       Software Interfaces:.................................................................................................................................7

       1.5.3. Events .........................................................................................................................................................9

2.     Functional Requirements: ...................................................................................................................................10

     2.1.       Users management ....................................................................................................................................10

     2.2.       Social Data Management ...........................................................................................................................10

     2.3.       Single shared database ..............................................................................................................................10

     2.4.       Analyzing Data............................................................................................................................................11

     2.5.       Gathering information from social networks websites ..............................................................................11

     2.6.       Generic .......................................................................................................................................................12

3.     Non Functional Requirements .............................................................................................................................12

     3.1.       Performance constraints: ...........................................................................................................................12

       3.1.1.       Speed .....................................................................................................................................................12

       3.1.2.       Capacity .................................................................................................................................................12

       3.1.3.       Reliability ...............................................................................................................................................12

       3.1.4.       Safety & Security ....................................................................................................................................13

       3.1.5.       Portability ..............................................................................................................................................13
       3.1.6.       Usability .................................................................................................................................................13

       3.1.7.       Availability .............................................................................................................................................13

     3.2.       Platform constraints: ..................................................................................................................................14

     3.3.       SE Project constraints:................................................................................................................................14

     3.4.       Special restrictions & limitations: ..............................................................................................................14

4.     Usage Scenarios ...................................................................................................................................................14

     4.1.       User Profiles ...............................................................................................................................................14

       4.1.1.       SNiC Unregistered User .........................................................................................................................15

       4.1.2.       Registered SNiC User .............................................................................................................................15

     4.2.       Use-Cases: ..................................................................................................................................................15

     4.3.       Special Usage Considerations ....................................................................................................................24

5.     Appendices ..........................................................................................................................................................24

     5.1.       Appendix I - Glossary:.................................................................................................................................24

     5.2.       Appendix II – Risks:.....................................................................................................................................27

     5.3.       Appendix III – Future versions:...................................................................................................................27
1. INTRODUCTION

 1.1.VISION

    Social networks have become a large part of people’s life and they are an inexhaustible source
    of information on different people, communities, relations between them, their interests,
    events they participate in and more. Many users of social networks are active members of
    several networks. Activity in various social networks creates a situation where on one hand
    there is duplication between relations and activities a user manages in the various networks
    and on the other hand information about people, events and communities is spread across
    multiple social networking sites. For example, a user that is active on Facebook social network
    primarily for social needs may have a LinkedIn account in order to manage his professional
    needs. Such a user may find himself maintaining the same information, such as Email
    addresses, phone numbers, groups of friends, etc… in two or more networks simultaneously.
    In the majority of the cases part of the information that is held on the various social networks is
    replicated in more than one social network and other parts of the information is held only on
    one of the social networks.
    Our project goal s to write software that will allow users to review the social networks in which
    he is active on, and collection the information on his circle of friends, communities to which he
    belongs and events in which he participated.
    The information will be stored on a single shared database. The database will allow the user to
    unite details and information about people, events and communities ,which is spread among
    the various networks he belongs to, and access the information conveniently using a uniform
    interface.


 1.2.PROBLEM DOMAIN

           Social networks hold high capacities of information on users. Each user is a member of
           various social networks which leads to a situation in which a user has to maintain his
           information on the separate networks, deal with ambiguities and inconsistencies within
           his data.
        In general, social networks are not willing to share their data outside of the web site
        since their main purpose is that users will stay connected to their site getting their data
        as long as possible. Thus, getting this data from the social network to an outside
        application is not an easy task to perform.
        Our solution suggests that a web crawler will fetch that information out of the social
        networks in which the user is a member without the need of his interaction with the
        web site. By visiting the various sites and parsing their HTML data it analyzes and
        fetches the relevant data for the user. After getting the data it sends it to a shared
        database. This way the data is collected automatically for the user and can be merged
        into one big snapshot of the user’s social data. Having the raw data in our hands, we can
        analyze it to our needs and present it according to various parameters.




1.3.STAKEHOLDERS


  1.3.1. CUSTOMERS
          The SNiC application is developed for Deutsche Telekom Labs at Ben-Gurion University.


  1.3.2. EXPERTS

          The system is designed and implemented for Ms Ofrit Lesser in accordance to her
          requirements and monthly reviews. Ofrit is the decision maker in all matters of system
          design.
          Also contributing as a technical advisor: Mr. Rami Puzis of Deutsche Telekom Labs.


  1.3.3. USERS

          In our vision SNiC will perform as a public application which forces us to make an
          application which is easily accessible and user-friendly, while maintaining a worthwhile
          functionality.


1.4.SOFTWARE CONTEXT

  Both of the client and web crawler applications will operate as cross platform applications which
  may be run from any operating systems that includes the JVM environment.
  The web crawler application communicates with the various social networks which operates as
  external applications and are not aware of its existence. Because of the fact that each social
  network has its own attributes and ways of operation the web crawler must have modules
  specific to each social network.
  The database will be deployed on a standalone remote server which gets information from the
  web crawler and supplies information to the client program and Data Analyzer.
  1.4.1.The Client (UI) – the Client will be a separated application which may access the data
        specific to the user. Its responsibilities include getting identification data from the user,
        connecting to the database and fetching the data off of it.
  1.4.2.Data Analyzer – the data analyzer is a part of the client application. Its responsibilities
        include getting the raw data from the database and parsing it to a more suitable view in
        order to serve the user needs.
  1.4.3.Shared Database – The database will be a standalone component which from one hand
        may be connected by users that want to get their data from it, and on the other hand may
        be connected by the web crawler component in order to insert relevant data into it.
  1.4.4.The Web Crawler
     1.4.4.1.       HTTP Connection Manager - this component’s main task is to make the actual
             connection the various social networks sites and get the necessary pages from which
             we want to get the data. It then passes on the pages to the HTML parser.
             The HTTP Connection Manager also performs login operations for the user, given the
             right credentials.
     1.4.4.2.       HTML Parser – The HTML Parser gets HTML pages from the HTTP Connection
             Manager and parses them according to specification unique to the social network it
             parses. Its main responsibility it to omit unneeded data from the pages it gets from
             the HTTP Connection Manager and to organize the HTML page into a more structural
             view of the specific data we’re interested on. After parsing the page it passes the
             data on to the Data Adapter.
     1.4.4.3.       Data Adapter – This component’s main task is to get the structured data from
             the HTML Parser, and save the relevant data into the shared database.


1.5.SYSTEM INTERFACES:


  1.5.1. HARDWARE INTERFACES:

         The system does not interact with any hardware interface.


  1.5.2. SOFTWARE INTERFACES:

      1.5.2.1 The Web Crawler – each social network has its own attributes, HTML structure and
                 ways of operations, it is necessary to customize a web crawler to every social
                 network.
         The web crawlers implement common interface for crawling social networks and we
         supply with an API in order to support more social networks in the future.
         The Web Crawler Interface will support the following operations:
         Operation: Login – Establish a connection to the SN with the client’s ID.
         Used By: Crawling Manager, Client.
         Parameters:
         -      Username: The username of the client in the specific social network.
   -   Password: The password of the client in the social network.

   Return Values: Answer if the connection succeeds or not.

   Operation: getFriends – Get a list of all friends of a current SN profile.

   Used By: Crawling Manager.

   Parameter:

   -   User ID: The account ID of the user in the social network.

   Return Value: List of friends of the current profile account.

   Operation: getEvents – get the Events from the current profile account.

   Used By: Crawling Manager.

   Parameters:

   -   User ID: The account ID of the user in the social network.

   Return Value: List of the last amount of events.

1.5.2.2. User Interface - The user interface defines basic actions of viewing
information in social networks, and in addition, a few more actions for consolidating
information.

Operation: View Profile – A user may view his different profiles over the various social
           networks.

Used By: Client.

Operation: View Event/Message – chosen event or message of specific account.

Used By: Client.

Operation: View Friends – View all of the friends of the user from the various social
           networks he is a member on.

Used By: Client.
      Operation: View Current Profile – view the profile information of a selected user containing
                 information from his account on the various social networks.

      Used By: Client.

      Operation: Save Snapshot – saving the relation status of the user in the current time of
                 action.

      Used By: Client.




      Operation: View Relations Graph - graphic presentation of the relations between the user
      and other people on the different social networks, at the current time or chosen snapshot
      time.

      Used By: Client.

      Operation: Unifiy friends from different networks – the ability to inform the system about
      two accounts on different social network that belong to same person.

      Used By: Client.


1.5.3. EVENTS

      Collecting data from the social networks into a single shared database – through the Web
      Crawlers, the system establishes HTTP connection with the social network; collect the data
      from the network and parse it. The data is saved in the database through the Data Adapter.


      Analyzing data - for getting suitable view, in order to serve the user needs, and finding
      relations between the different social networks accounts.


      GUI based events – explicit requests from the user through the web application, including
      graphic presentation of required data from the data base, finding relations between the
      accounts and saving a snapshot of relation status at current time.
2. FUNCTIONAL REQUIREMENTS:

 2.1.USERS MANAGEMENT

    The user interface will be developed as a website.
    A SNIC user is a registered user who can manage his social networks through this single
    website.
    The SNIC website functionality:
   2.1.1.Registration – A new user will be asked to register to the service by selecting username
        and password unique to the SNiC application.
   2.1.2.Login – The user will login to SNIC website. After logging in the user will be identified as a
        registered user on the system and will be able to perform the appropriate actions.


 2.2. SOCIAL DATA MANAGEMENT

   2.2.1.Profile – The user will be able to see all his profiles information from the different
        networks in one page divided by tabs.
   2.2.2.Friends
       2.2.2.1.     View a list of friends over all the social network the user is a member on.
       2.2.2.2.     View a specific profile of a friend on a specific social network.
       2.2.2.3.     View a unified profile of a friend, containing information gathered from multiple
               social networks.
   2.2.3.Messages/Events – The system allows the user to view a list of his messages and events
        over the different social networks.
   2.2.4.Snapshot – The system will allow a user to save a snapshot of his current social data at any
        given time point.
   2.2.5.Social Graph – a graphic presentation of the social relations of the user inside the different
        social networks and between them.


 2.3.SINGLE SHARED DATABASE

   2.3.1.All the data that was gathered from the social networks websites is stored in a single
        shared SQL based database
  2.3.2.The SNIC system is taking its data only from this shared database and not directly from the
        social networks websites.
   The database schema:
      SNIC Users Table: (SNIC_User_ID, SNIC_Username, SNIC_Password)
      Social Network membership Table: (SNIC_User_ID, Network_ID, User_ID, Username,
       Password)
      Social Networks Table: (Network_ID, Network_Name)
      Profiles Table: (Network_ID, User_ID, FName, LName, Age, Email …)
      Friends Table: (Network_ID, User_ID1, User_ID2)
      Messages Table: (Network_ID, User_ID, from_user_id, date, text)
      Events Table: (Network_ID, User_ID, from_user_id, date_sent, place, text, date_occurs)
      Snapshots Table: (Friends) (Network_ID, User_ID1, User_ID2, Date)
      Cross Networks Profiles Table: (Pseudo ID) (Network_ID1, User_ID1, Network_ID2,
       User_ID2).



  Assumption: *user cannot have multiple accounts at the same network.




2.4.ANALYZING DATA

  The system may recommend a SNiC user of an unexplored friend on a social network by crossing
  specific data fields between multiple social networks.
   For example: Email address is a unique identification for a user on a social network since it is
   impossible that a social network contains two different users with the same email address. The
   system is able to identify those different profiles and unify between them.
   After the unification, the system may offer a user of a friend of his on another social network.


2.5.GATHERING INFORMATION FROM SOCIAL NETWORKS WEBSITES

   The system will be able to collect information for the different social networks.
   Collecting the information is done using the Web Crawler component. The web crawler
   simulates an interaction between the user and a web browser and by that fetches HTML pages
    from the social network web site. After doing that the HTML parser fetches the relevant data
    from the HTML page. The processed data is then sent to the shared database for storage.


 2.6.GENERIC

    The system should be able to support future additions of web crawlers for new social networks.
    to achieve this target, it was designed with a generic structure and API.


3. NON FUNCTIONAL REQUIREMENTS

 3.1.PERFORMANCE CONSTRAINTS:


   3.1.1. SPEED

              The Client application should give a connections graph not more than 10 minutes.

              The system should perform an update (Crawling) for a single user up to 15 minutes.

              Login process will take less than 5 seconds.




   3.1.2. CAPACITY

           Client Side:

           RAM - The system will function properly on computer with 1GB of RAM or more.

           Users Capacity: No limit.

           Hard Drive Capacity: The system will not require more than 200MB of hard disk space.


   3.1.3. RELIABILITY



               When unexpected system failure occurs, the system will recover all user profiles and
                return to stable mode.
3.1.4. SAFETY & SECURITY




           The passwords of the user's social networks will be saved locally on his H.D. and not on
            the Shared-Database, except to the SNIC-Password.
           All the user passwords will be stored encrypted.




3.1.5. PORTABILITY




          The system should operate on any OS that has both JVM and JRE 1.6 (or higher)
           installed.
          A registered user can access his SNIC account from any computer that have the Client
           (UI) application installed.




3.1.6. USABILITY




          The system GUI should be user-friendly and easy to use.

          Learning how to use the main features will be simple and intuitive. The user will be able
           to explore these features and understand their functionality quickly.




3.1.7. AVAILABILITY
          The system should be able to operate at any time of day and no matter the amount of
           applications running at the background of the Operating System.

          The SQL-Server which holds the SNIC database should be available at 99% of the time.
          The Clients must be connected to the internet in order to perform an update operation.
          The Client GUI should not be freeze.




 3.2.PLATFORM CONSTRAINTS:

          The system should operate on any OS that has both JVM and JRE 1.6 (or higher)
           installed.



 3.3.SE PROJECT CONSTRAINTS:

          The system will be interactive in a way that users will be able to view their social
           networks friends, messages and add new social networks.
          The input for the system will come from the users which provide the initial details and
           from the social networks which located on the internet.



 3.4.SPECIAL RESTRICTIONS & LIMITATIONS:

          The system is not compatible with Social Networks that doesn't have an API and using
           different technology than HTML to view the user data (FLEX, for example).




4. USAGE SCENARIOS

 4.1.USER PROFILES

    The main actor in our system is the SNiC registered user.
  4.1.1. SNIC UNREGISTERED USER

       When a user first runs our system his state in unregistered which means he hasn’t gone
       through the registration process of the SNiC application. In his current state the user
       doesn’t have much functionality offered by the system which makes registering the first
       action a new SNiC user must do before he can actually use the system.


  4.1.2. REGISTERED SNIC USER

       A registered SNiC user is a user that has gone through the registration process of the SNiC
       application. The registered SNiC user is the main actor in the system. Most of the
       operations and functionality our system offers requires the user to be a registered one and
       to supply us with a few necessary details about his membership in the various social
       networks. We assume that the SNiC registered user has read the user manual and knows
       how to interact with the system. The SNiC registered user may do the following
       operations:
              Add a social network membership
              Update his social data.
              Save a snapshot of his social data.
              View friends list across multiple social networks.
              View a friend profile.
              View the list of messages from multiple social networks.
              Unify friends’ profiles from various social networks.
              View his social graph according to a requested date.
              Login/Logout.
              Unregister his SNiC account.
              View the changes in his social data between two different snapshots.


4.2.USE-CASES:
4.2.1. ID: 1.
      Name: Register.
      Primary Actors: Unregistered user.
      Description: This usage scenario represents the process of registering as a new SNiC user.
                    When a new user first comes to the system it must register itself in order to
                    perform all other actions that the system supports.
      Trigger: A new user wants to use the system’s abilities. In order to do that he must register
                himself, so the system can gain the information about him.
      Pre-Conditions: The user is an unregistered user.
      Post-Conditions: A new user is created within the system with the appropriate credentials
                         the user chose.
      Main Success Scenario:
                 1. The user clicks the “Register as a new user” button.
                 2. The user is asked to enter a user name and a password.
                 3. The user enters a user name and a password.
                 4. The user is created with the appropriate credentials.


      Extensions/Alternatives:
                 3.a Case: A user with the chosen username already exists in the system.
                 Action: - An explanation message will appear on the user’s screen.
                         - Return to step 2.
                 3.b Case: The chosen password is not strong enough
                 Action: - An explanation message will appear on the user’s screen.
                         - Return to step 2.
4.2.2.ID: 2.
      Name: Login.
      Primary Actors: Registered user.
      Description: The scenario describes a user which tries to login into the system using his
                   credentials.
      Trigger: A registered user attempts to login into the system.
      Pre-Conditions: The user has already performed the registration process.
      Post-Conditions: The user is logged into the system.
      Main Success Scenario:
                 1. The user clicks on the “Log in” button.
                 2. The user is asked to enter his username and password.
                 3. The user enters his credentials.
                 4. The credentials are found valid.
                 5. A “Hello, user” message appears, indicating a successful login.
      Extensions/Alternatives:
                 4.a: Case: The user name does not exist in the system.
                 Action: - An explanation message appears on screen explaining the user the
                 username he has entered does not exist in the system.
                          - Return to step 2.
                   4.b: Case: The password does not match the username.
                   Action: - An explanation message appears on screen explaining the user the
                   username he has entered does not match the password he has entered.
                           - Return to step 2.
4.2.3.ID: 3.
      Name: Add Social Network Membership.
      Primary Actors: Registered user.
      Description: Adding a social network membership allows the users of the SNiC application
                     to inform the system they are members of a certain social network. This
                     allows the application to collect the relevant data about the user from the
                     certain social network. A user may want to add a few social networks
                     memberships in order to consolidate his social data into SNiC.
      Trigger: A registered user which wants to inform the system of a membership in a certain
                social network.
      Pre-Conditions: The user has already logged into the system successfully.
      Post-Conditions: A new association between the logged user and his profile on the social
                          network has been created.
      Main Success Scenario:
                   1. The user clicks “Add a new social network membership” button.
                   2. The system lists the available social networks it offers except for those the
                   user has already informed it.
                   3. The user chooses one of the available networks.
                   4. The system asks the user to enter his credentials in the specific network.
                   5. The user supplies the system with his credentials.
                   6. The system successfully logs into the social network using the user’s
                   credentials.
                   7. A new association between the logged user and his profile on the social
                   network has been created.
      Extensions/Alternatives:
               2.a Case: No more social networks are available for the user.
               Action: - Display an appropriate message to the user.
                       - Return to the main screen.
               6.a Case: The system cannot log into the social network using the user’s credentials.
               Action: - Display an appropriate message to the user.
                       - Return to step 4.
4.2.4.ID: 4.
      Name: View friends list.
      Primary Actors: Registered user.
      Description: One of the main usage scenarios for the system is collecting the user list from
                     the multiple social networks the user has announced his membership on.
      Trigger: A registered user has requested to view his friends list.
      Pre-Conditions: The user has already logged into the system successfully.
      Post-Conditions: A list of all friends of the user over all of the social network memberships
                          he has announced is shown.
      Main Success Scenario:
                   1. The user clicks on “View friends list” button.
                   2. The system displays the list of friends for the user over the multiple social
                   networks.
      Extensions/Alternatives:
               2.a Case: The user did not announce of any membership in a social network.
               Action: - Display message: You have not announced of any social network
               membership so no information could be gathered.
4.2.5.ID: 5.
      Name: View a friend’s profile.
      Primary Actors: Registered user.
      Description: The system allows a registered user to view the profiles of his friends over the
                     multiple social networks he is a member on.
      Trigger: A registered user has chosen to view a friend’s profile.
      Pre-Conditions: The user is logged into the system.
      Post-Conditions: The profile is shown to the user.
      Main Success Scenario:
                   1. The user clicks on “View friends list” button.
                   2. The system displays a list of the user’s friends from the various social
                   networks.
                   3. The user chooses a friend from the list and double clicks it.
                   4. The system displays all profiles of the friend from the various social
                   networks.
      Extensions/Alternatives: None.
4.2.6.ID: 6.
      Name: Unify friends from multiple social networks.
      Primary Actors: Registered user.
      Description: One of the main purposes of the system is the consolidation of data from the
                     multiple various networks the user is a member in. A user may have a friend
                     on social network 1 and the same friend on social network 2. This use case
                     allows the user to flag the system this is the same person and by that unify its
                     profile on social network 2 and social network 1 into one profile.
      Trigger: A registered user which wants to unify a friend from multiple social networks.
      Pre-Conditions: The user is logged in.
      Post-Conditions: The profile of the friend is unified under the multiple various networks.
      Main Success Scenario:
                   1. The user clicks on “Unify a friend from multiple social networks” button.
                   2. The system displays a list of social networks the user is a member on.
                   3. The user chooses one of the social networks.
                   4. The system displays the list of friends of the user under the specified social
                   network.
                   5. The user chooses one friend from the list.
                   6. The system displays a list of social networks the user is a member on.
                   7. The user chooses a different social network.
                   8. The system displays the list of friends of the user under the specified social
                   network.
                   9. The user chooses one friend from the list.
                   10. The friend is now marked to be the same person under the different social
                   networks.
      Extensions/Alternatives:
               2.a Case: The user is a member on only one social network.
               Action: - Display a message: cannot unify a friend from only one social network.
               2.b Case: The user has not announced membership on any social network.
               Action: - Display a message: cannot unify a friend if no social network membership
               has been announced.
               4.a Case: The user does not have any friend under the chosen social network.
               Action: - Display a message: no friends detected under the chosen social network,
               please choose another one.
                       - Return to 2.
               7.a Case: The user chose the same social network as in step 3.
               Action: - Display a message: cannot unify profiles from the same social network,
               please choose another one.
                      - Return to 2.


4.2.7.ID: 7.
      Name: Update social data.
      Primary Actors: Registered user.
      Description: Updating the data is done on a regular basis automatically by the system, but
                     there may be cases in which the user may want to update his data on
                     demand.
      Trigger: A registered user requires data update.
      Pre-Conditions: The user is logged in.
      Post-Conditions: The data of the specified social networks is updated.
      Main Success Scenario:
                   1. The user clicks on the “Update Data” button.
                   2. The system displays a list of social networks in which the user is a member.
                   3. The user chooses the social networks he wants to update the data from.
                   4. The system fetches the data from the social networks and updates the
                   application.
      Extensions/Alternatives:
               2.a Case: The user has not announced membership on any social network.
               Action: - Display a message: No data to update, no social network membership is
               available to update.
               3.a Case: The user does not choose any social network to update.
               Action: - Display a message: No data to update, please choose at least one social
               network.
                      - Return to step 2
4.2.8.ID: 8.
      Name: Save a snapshot.
      Primary Actors: Registered user.
      Description: A user may want to save a snapshot of his current social data in the various
                     social networks in order to view the differences of his social situation
                     between two snapshots later on.
      Trigger: A user performs the save snapshot action.
      Pre-Conditions: The user is logged in.
      Post-Conditions: A snapshot of the current social data for the user has been saved in the
                          system.
      Main Success Scenario:
                   1. The user clicks the “Save Snapshot” button.
                   2. The system saves a copy of the current social data of the user.
      Extensions/Alternatives:
               2.a Case: The user has not announced membership on any social network.
               Action: - Display a message: No data to save as snapshot, no social network
               membership is available. Please create a social network membership first.
4.2.9.ID: 9.
      Name: View Social Changes.
      Primary Actors: A registered user.
      Description: A user which has saved snapshots of his social data before may want to view
                     the changes to his data over the course of two different snapshots.
      Trigger: A registered user wants to view the evolution of his social data.
      Pre-Conditions: The user is logged in.
      Post-Conditions: The difference between two different snapshots is displayed.
      Main Success Scenario:
                   1. The user clicks on the “View social data difference” button.
                   2. The system shows a list of snapshots that exist for the user.
                   3. The user chooses two snapshots from the list.
                  4. The system calculates the difference between the two selected snapshots
                  and displays it to the user.
     Extensions/Alternatives:
            2.a Case: The user did not save a snapshot of his social data before or the user has
            only one snapshot associated with him.
            Action: - Display a message: “ You must have at least two different snapshot
            instances in order to perform this action”.
4.2.10. ID: 10.
        Name: View social graph.
        Primary Actors: Registered user.
        Description: A social graph is a graphical way to show the user’s social evniroment.
        Trigger: A registered user requests to view his social graph.
        Pre-Conditions: - The user is logged in.
                         - The user has his social data in the system.
        Post-Conditions: The social representation of the user’s most recent social data is
                          displayed.
        Main Success Scenario:
                  1. The user clicks on the “View social graph” button.
                  2. The system displays the social graph of the user.
        Extensions/Alternatives: None.
4.2.11. ID: 11
        Name: Unregister.
        Primary Actors: Registered user.
        Description: An action performed by a registered user which wants to remove his SNiC
                     account and all of his personal data from the system.
        Trigger: A registered user which wants to remove his account.
        Pre-Conditions: The user is logged into the system.
        Post-Conditions: The account is removed from the system.
        Main Success Scenario:
                  1. The user clicks on the “Unregister SNiC”
                  2. A confirmation box appears which validates the request with the user, giving
                  him the opportunity to cancel.
                     3. The user chooses to confirm his request to unregister SNiC.
                     4. The system deletes the account and the corresponding data.


            Extensions/Alternatives:
                3.a Case: The user chooses to cancel his account removal request.
                Action: The system aborts the account removal process.
   4.2.12. ID: 12.
            Name: View messages list.
            Primary Actors: Registered user.
            Description: Allows the user to collect messages from his various social networks.
            Trigger: A registered user has requested to view his messages list.
            Pre-Conditions: The user has already logged into the system successfully.
            Post-Conditions: A list of all messages of the user over all of the social network
                              memberships he has announced is shown.
            Main Success Scenario:
                     1. The user clicks on “View messages list” button.
                     2. The system displays the list of messages for the user over the multiple social
                     networks.
            Extensions/Alternatives:
                2.a Case: The user did not announce of any membership in a social network.
                Action: - Display message: You have not announced of any social network
                membership so no information could be gathered.


 4.3.SPECIAL USAGE CONSIDERATIONS

    None.




5. APPENDICES

 5.1.APPENDIX I - GLOSSARY:
5.1.1. API – An application programming interface (API) is an interface implemented by a
     software program that enables it to interact with other software. It facilitates interaction
     between different software programs similar to the way the user interface facilitates
     interaction between humans and computers. An API is implemented by applications,
     libraries, and operating systems to determine their vocabularies and calling conventions,
     and is used to access their services. It may include specifications for routines, data
     structures, object classes, and protocols used to communicate between the consumer and
     the implementer of the API.


5.1.2. Web API - an API is typically a defined set of Hypertext Transfer Protocol request
     messages, along with a definition of the structure of response messages, which is usually
     in an Extensible Markup Language (XML) or JavaScript Object Notation (JSON) format.
     "Web API" is virtually a synonym for web service.


     The practice of publishing APIs has allowed web communities to create an open
     architecture for sharing content and data between communities and applications. In this
     way, content that is created in one place can be dynamically posted and updated in
     multiple locations on the web.


           Photos can be shared from sites like Flicker and Photobucket to social network sites
            like Facebook and MySpace.
           Content can be embedded, e.g. embedding a presentation from SlideShare on a
            LinkedIn profile.
           Content can be dynamically posted. Sharing live comments made on Twitter. with a
            Facebook account, for example, is enabled by their APIs.
           Video content can be embedded on sites which are served by another host.
           User information can be shared from web communities to outside applications,
            delivering new functionality to the web community that shares its user data via an
            open API. One of the best examples of this is the Facebook Application platform.
            Another is the OpenSocial platform.
5.1.3. WebCrawler – A Web crawler is a computer program that browses the World Wide Web
     in a methodical, automated manner or in an orderly fashion. Other terms for Web crawlers
     are ants, automatic indexers, bots, or Web spiders, Web robots, or Web scutters.


     This process is called Web crawling or spidering. Many sites, in particular search engines,
     use spidering as a means of providing up-to-date data. Web crawlers are mainly used to
     create a copy of all the visited pages for later processing by a search engine that will index
     the downloaded pages to provide fast searches. Crawlers can also be used for automating
     maintenance tasks on a Web site, such as checking links or validating HTML code. Also,
     crawlers can be used to gather specific types of information from Web pages, such as
     harvesting e-mail addresses (usually for spam).


     A Web crawler is one type of bot, or software agent. In general, it starts with a list of URLs
     to visit, called the seeds. As the crawler visits these URLs, it identifies all the hyperlinks in
     the page and adds them to the list of URLs to visit, called the crawl frontier. URLs from the
     frontier are recursively visited according to a set of policies.


5.1.4. Social Network – A social network is a social structure made up of individuals (or
     organizations) called "nodes", which are tied (connected) by one or more specific types of
     interdependency, such as friendship, kinship, common interest, financial exchange, dislike,
     sexual relationships, or relationships of beliefs, knowledge or prestige.
        Facebook – Facebook is a social network service and website launched in February
         2004 that is operated and privately owned by Facebook, Inc. As of July 2010 Facebook
         has more than 500 million active users, Users may create a personal profile, add other
         users as friends and exchange messages, including automatic notifications when they
         update their profile. Additionally, users may join common interest user groups,
         organized by workplace, school, or college, or other characteristics.
        Flicker – Flickr is an image hosting and video hosting website, web services suite, and
         online community created by Ludicorp and later acquired by Yahoo. In addition to
         being a popular website for users to share and embed personal photographs, the
         service is widely used by bloggers to host images that they embed in blogs and social
         media. In September 2010, it reported that it was hosting more than 5 billion images.
   5.1.5. SNIC User – A registered user on the system which is want to view or manage his social
        networks from a single point - the SNIC Client (UI).


   5.1.6. Client (UI) – This application is responsible to identify the SNIC user, get commands, fetch
        and view the data of the specific user from the Shared-DB.


   5.1.7. System – Overall name that refers to all components of this project, which described in
        the Problem-Domain.


   5.1.8. Community – In the scoop of this project the meaning of the word "community" indicates
        a smaller or larger group of internet users signing up to become members of a community
        page/system on internet.


   5.1.9. Snapshot – a snapshot is the state of several social networks at a particular point in time.



5.2.APPENDIX II – RISKS:

   5.2.1. Changes in the login operation or in the HTML design of the social network (Web).
   5.2.2. Prohibition of using the Social Network API (API).
   5.2.3. Most of the Social Networks APIs are limited in terms of amount of data they can access
        and use. In addition, in several Social Networks the users need to authorize the exposing of
        their information to 3rd party (API).
   5.2.4. Usage in new SDK – in order to implement this project correctly we will have to use Adobe
        FLEX which is new and advanced but also have a learning curve. We will need to learn new
        things fast and adapt ourselves for this new technology.




5.3.APPENDIX III – FUTURE VERSIONS:
One of the main goals of the system architecture of this project is to provide a convenience
infrastructure to develop additional functionality in future versions.

       Data analysis between social networks, friends, group, etc…
       Sophisticated visual display.
       The user will be able to send and modify data.

				
DOCUMENT INFO
Shared By:
Categories:
Tags:
Stats:
views:5
posted:7/20/2012
language:
pages:28