SynapSync – Social Media Marketing Platform

By:

Vlad Filip Mares 100685968

Apurva Saini 100718285

Supervisor: Professor Schramm

A report submitted in partial fulfillment of the requirements

of SYSC-4907 Engineering Project

Department of Systems and Computer Engineering

Faculty of Engineering

Carleton University

April 7, 2010
Abstract

SynapSync is a web based Social Media Marketing Platform for small to

medium sized businesses (SMB). From the SynapSync website, SMBs

can publish promotional campaigns to multiple online sources such as

a SynapSync personal profile page, social networks (Twitter and

Facebook), email newsletters and mobile devices. Our clients can

monitor customer response and then chose to engage them on the

topic. The website will save our clients the time required to publish and

retrieve content from the multiple online sources. Small business

owners will get better exposure by entering the social media space.

Additionally, clients can analyze customer perceptions and

demographics which can help the company evaluate its customers’

needs and expectations. SynapSync is a direct link to communicate

with customers online to put a more personal face on your small

business.

Page | 2
Acknowledgements

Throughout the process of completing the SynapSync project we have

had help and guidance in two areas. The first was the technical and

project management area. Professor Schramm has been there every

step of the way helping us see the next steps needed to be taken in

our project. We have learned a lot about project management and

software documentation from her in the past 8 months. Professor

Muegge was our mentor for the entrepreneurship competitions. He

helped us pinpoint the business need for our project and proper

business plan writing. We owe our final results to the great guidance of

both Professor Schramm and Professor Muegge.

Page | 3
Table of Contents

Abstract............................................................................................................ 2

Acknowledgements .....................................................................................3

Table of Contents.............................................................................................4

........................................................................................................................ 6

List of Figures...................................................................................................7

Introduction .....................................................................................................9

Market Trends ..............................................................................................9

Problem ........................................................................................................ 9

Solution ......................................................................................................10

The Engineering Project.................................................................................11

Health and Safety........................................................................................11

Engineering Professionalism........................................................................11

Project Management...................................................................................11

Individual Contributions...............................................................................13

Project Contributions................................................................................13

Report Contributions................................................................................14

1.Overview .................................................................................................... 15

Website ...................................................................................................... 15

Email Newsletters .......................................................................................17

Mobile Devices ...........................................................................................18

Analytics .....................................................................................................20

Background ...................................................................................................20

Google App Engine .....................................................................................20

App Engine Services Used by SynapSync ...................................................22

Page | 4
 Database Design .....................................................................................22

Webapp Framework and Django .............................................................23

Twitter Integration ......................................................................................25

Authentication..........................................................................................26

Twitter API ...............................................................................................29

Facebook Integration...................................................................................29

Authorization and Authentication ............................................................30

Facebook API............................................................................................32

Requirements ...............................................................................................32

2.Design......................................................................................................... 38

Website ...................................................................................................... 38

Configurations Section.............................................................................40

The User Interface Section.......................................................................43

Code-behind.............................................................................................49

Sessions and Authentication.......................................................................51

Datastore Interface.....................................................................................53

Datastore.....................................................................................................54

Implementation .............................................................................................56

Social Networks ..........................................................................................56

Twitter Implementation............................................................................56

Facebook Implementation........................................................................60

Conversations..........................................................................................62

Email ..........................................................................................................64

Mobile Client................................................................................................66

Posting content...........................................................................................68

Testing ..........................................................................................................69

Page | 5
Business Achievements .................................................................................70

Conclusion ....................................................................................................72

References ....................................................................................................74

Appendix A – Use Case Actor Descriptions.....................................................77

Appendix B – Use Case Descriptions..............................................................79

Appendix C – Use Case Scenarios...................................................................81

Appendix D – Class Diagrams

EmailProcessor Diagram................................................................................88

Appendix E – Sequence Diagrams..................................................................89

Page | 6
List of Figures

Figure 1 Control Panel....................................................................................15

Figure 2 Profile Page......................................................................................16

Figure 3 Android Mobile Client.......................................................................19

Figure 4 Post View Count...............................................................................20

Figure 5 Overview of Google App Engine Services [4]....................................22

Figure 6 webapp framework...........................................................................25

Figure 7 Twitter Account Authentication........................................................28

Figure 8 SynapSync Authorization for Facebook............................................30

Figure 9 Permission for offline access............................................................31

Figure 10 - The use case diagram for SynapSync...........................................35

Figure 11 Overall Class Diagram....................................................................38

Figure 12 Website general architecture.........................................................39

Figure 13 app.yaml contents..........................................................................42

Figure 14 _base.html Master page.................................................................44

Figure 15 Error reporting................................................................................45

Figure 16 profiles.html source code...............................................................48

Figure 17 Request Handlers...........................................................................50

Figure 18 User entities and session................................................................52

Figure 19 Datastore Interface Controllers......................................................54

Figure 20 SynapSync Datastore.....................................................................55

Figure 21 Twitter accounts can be added by clicking on the Twitter icon in the
Admin Tools....................................................................................................57

Figure 22 The newly published post is retrieved from Twitter........................58

Figure 23 New post shown on Twitter............................................................59

Page | 7
Figure 24 The full content of the post on SynapSync.....................................60

Figure 25 After verifying the credentials, extended permissions must be

provided to complete authorization...............................................................61

Figure 26 Association between Sessions, OAuth and Facebook.....................62

Figure 27 Replying to a Social Network comment .........................................63

Figure 28 Comment replies on Facebook.......................................................63

Figure 29 Replying to comments....................................................................64

Figure 30 Contact Company...........................................................................65

Figure 31 Mobile Client Access.......................................................................67

Figure 32 Publishing Content.........................................................................69

Page | 8
Introduction

This report is submitted as a requirement of the SYSC 4907 fourth year

project course. The purpose of this report is to present our work

completed on the project. The project was supervised by Professor

Cheryl Schramm and spanned over the period of September 16th 2009

to April 7th 2010. Our project team is Group #1 and is comprised of

Apurva Saini and Vlad Filip Mares.

Market Trends

In a recent trend large businesses and organizations have started

utilizing social networks and social media to promote their brand

online and interact with customers. A successful example of a large

company is Dell. Dell has recently turned to Twitter to increase

sales of clearance merchandise in their warehouse. Currently, the

company attributes over $6.5M in revenue as a direct result of their

account on Twitter which they began in 2007. By announcing

products and discounts they generate discussions around their

brand and manage to get a sense of how they should align their

business to better suit their customers. [1]

Problem

Citibank conducted a survey in 4Q of 2009 on small businesses and

their use of social media. The results showed that 63% of small

Page | 9
 businesses are currently not employing any means of Social Media

into their business model. Small to medium sized businesses (SMBs)

are intimidated by the learning curve of social networks. As soon as

a new one appears and becomes popular they have to learn how to

interact with it. Mainly, SMBs do not recognize the importance of

protecting their brand on the internet and believe that interacting

online compromises their security. Citibank concludes that this is

due to a lack of resources and time. [2]

Solution

Our 4th year project, SynapSync, is a web based Social Media

Marketing Platform for small to medium sized businesses. From the

SynapSync website, SMBs can publish promotional campaigns to

multiple online sources such as a SynapSync personal profile page,

social networks, email newsletters and mobile devices. SynapSync

clients (the SMBs) can monitor the response of their customers to

the promotional campaign and then choose to engage them on the

topic.

Page | 10
The Engineering Project

Health and Safety

Due to the software nature of our project we did not face the

regular health and safety hazards that most projects due. We did

however employ regular breaks to combat fatigue and Carpal

Tunnel syndrome. This allowed our minds and energy to stay

refreshed.

Engineering Professionalism

A more serious concern with the nature of our software were

privacy concerns. Users information had to be secure and our

datastore safe from attacks. We put in place safety measure such

as hashing passwords in the datastore instead of storing them in

plain text. For access to critical parts of the site, we implemented

authorization and session checks to make sure the person accessing

the Settings page or Control Panel was authorized to do so. For both

Facebook and Twitter we do not store the passwords for the

accounts added. We use secure protocols of interacting with the

online systems such as OAuth and Facebook Connect.

Project Management

Due to the large scale project we took on as our fourth year project

we had to employ project management techniques to maintain our

Page | 11
proposed deadlines. When starting the project we drafted our

proposal document which outlined a timeline of milestones for our

many components of the SynapSync project. To achieve this we had

to figure out our critical path. After doing so we realistically chose

dates and deadlines for each milestone.

To maintain our source code we used industry standard services

such as SVN. This allowed us to have our code in one central

location and check code in or out. We avoided plenty of accidents

when working on source code concurrently by locking out only the

files needed for our individual task. This not only helped us in the

consistency of our code, but also in rolling back code. When certain

design decisions proved to be unsuccessful, we successfully

reverted to earlier versions and started again. This process saved us

lots of time and effort.

Other than code maintenance we also kept a Google Sites page

which allowed us to document our progress and served as our

central hub for knowledge sharing. There, we documented all our

accounts on Twitter, Facebook and SynapSync. We also kept track

of bugs and the status on each of them. This allowed us to stay

organized and know the status of our overall system. As a way of

sharing our leaned technologies we also maintained a blog in which

we shared common practice for implementing certain features on

Page | 12
 Google App Engine. Google Sites also allowed us to store our

documentation and collaborate on it concurrently with the help of

Google Docs. The tool saved us a lot of time by acting a central hub

for our documentation.

Individual Contributions

Project Contributions

Contributor: Contributions:
Filip Mares Web Design

Android Mobile Client

Email Newsletter Component

DataStore design

Overall architecture design

URL shortening

Click-through Traffic Tracking

Image file storing and

manipulation

Competition Work
Apurva Saini Sessions and Authentication

Facebook Implementation

Twitter Implementation

Page | 13
Report Contributions

Contributor: Contributions:
Filip Mares Abstract

Introduction

Engineering Project

Overview

Design(website, datastore)

Implementation (email, Mobile

client, posting content)

Business Achievements

Conclusion
Apurva Saini Background

Requirements

Design (Code-behind, Sessions

and Authentication)

Implementation (social networks)

Testing

Page | 14
1. Overview

Website

Our website will allow clients to publish promotional material

through a page called the Control Panel. The website allows for

multiple contributors per company to publish promotional material

and collaborate on it. A sample screenshot is displayed in Figure 1.

On this page the company employee enters the title and content for

the promotional update as well as the choice to attach an image

file. The employee can either ‘Save’ the post for publishing it at a

later time or ‘Post’ the update which publishes the promotional

update to the subscribed services.

Figure 1 Control Panel

Page | 15
Our clients will be provided with a personalized profile page

displaying their published content. A sample screenshot of the

profile page is displayed in Figure 2. The page displays

chronological promotional updates published by the small business.

Here, company followers can retrieve contact information such as

business location, phone number and email address. Additionally,

the website visitor can subscribe to email updates from the small

business.

Figure 2 Profile Page

The learning curve to social networks such as Twitter and Facebook

is very steep. Social networks are a great place to start

conversations around shared content and interest. Conversations on

such social networks follow a certain protocol that most do not

Page | 16
 understand at first. Unlike email, which has a standardized method

of conversing (to, from, subject, email body), Twitter and Facebook

vary in format and require the user to learn both social network

protocols. Our site helps users to converse with social network users

on their products, services and industry. Our SynapSync users can

post content to multiple social network accounts with the simple

click of a button. As seen in Figure 1, the sidebar in the Control

Panel contains comments from social network users. From the

sidebar, our users can reply to the comments and engage social

network users.

Email Newsletters

Additionally to publishing promotional material to the profile page

and social networks our users can send their updates to email

newsletters. Email Newsletters are key to providing consistent

customer satisfaction as our product will keep the users up to date

with informative content and use real-time delivery. Users can

subscribe to these newsletters via the small business’ profile page.

This is a great opportunity for the small business owner to reach its

customers by email and communicate with them through a familiar

communication method.

Page | 17
Mobile Devices

A lot of the traffic on the internet currently is driven by an increase

in mobile device users. We have developed a personalized mobile

application displaying the latest updates published by the small

business. We have chosen to develop the application for the Google

Android mobile operating system to allow our clients to reach their

customers on mobile devices. We chose the Android environment

due to its extensive documentation and support on the Google Code

website. Customers of our small business users can install the

application on their Android device and receive updates from the

company. Customers will be able to receive updates from one of

their favourite SMBs. A sample screenshot of the mobile application

is displayed in Figure 3.

Page | 18
Figure 3 Android Mobile Client

Page | 19
Analytics

All the above service allow for our clients to get greater exposure

online and interact with online customers in hassle-free way. To

help them better analyze their impact online we have implemented

the ability to see the number of unique visitors that view each

update. To track this information we use a link shortening service

called BitLy. This service monitors click through activity. A sample

screenshot of our displayed view count is displayed in Figure 4.

Figure 4 Post View Count

Background

Google App Engine

The development and hosting of a web application generated the

need for a platform and a cloud computing technology. Some

examples of this type of technology are Amazon Web Services,

Google App Engine, and Microsoft Windows Azure. The Google App
Page | 20
Engine is the platform that SynapSync makes use of and it is the

heart of the application’s backend. The advantage of using App

Engine is that it offers many free services such as the Google

Account services for user authentication, multiple language

support, URL Fetch API for communicating with other internet hosts

(via HTTP requests), and many more [3]. An overview of all the key

features that the App Engine offers to developers can be seen in

Figure 5. These services make web applications like SynapSync

easy to build, maintain, and scale depending on the traffic on the

website. Additionally, developers are not required to maintain any

servers, but simply upload the application and immediately have

the ability to share it with the world [3]. This not only saves time for

developers, but it also lets them focus all of their development

efforts specifically on the application features. More details about

some of the useful App Engine services can be found later in this

section.

The supported languages by App Engine are Python and Java. Both

have dedicated runtime environments which are built in a way so

that web applications can run smoothly without having to deal with

interference from other applications within the system [3]. Using

Python’s runtime environment it is also possible to take advantage

of a high level Python web framework known as Django.

Page | 21
 Figure 5 Overview of Google App Engine Services [4]

App Engine Services Used by SynapSync

This section provides details of how and why SynapSync makes use

of particular features offered by the App Engine platform.

Database Design

Because a vital feature of SynapSync involves saving user

information along with their company profiles and their posts, a

database is required to store these contents for later use or

modifications. For example, if a representative of a company

registers onto a website, then some type of database is needed

in order for him or her to be able to log into the website at a later

time by providing their credentials. The Datastore service that is

Page | 22
 offered by App Engine is known as BigTable, which is a high

performance database system based on various Google

programs. The datastore is designed mainly for web applications

and performs queries on certain objects that are known

as entities. Unlike relational databases however, entities in the

datastore don’t conform to a schema [5]. This means that it is

possible to have two entities of the same kind, but with

completely different properties. Further information on the App

Engine datastore is available in the Design section.

Webapp Framework and Django

Through the use of web application frameworks like Django and

the webapp [6], developing Python web applications becomes

much simpler as developers are not required to maintain a

server. Django is a framework provided by Python's runtime

environment and does not require the Google App Engine

platform for developing web applications. However, SynapSync

makes use of the webapp framework provided by Google as it

simplifies details particularly when designing the user interface

and handling HTTP requests. The web design of SynapSync

makes use of this framework in order to handle events as seen in

web design section.

The webapp framework contains a class known

as WSGIApplication [6], an instance of this class represents the

Page | 23
web application as a whole and would thus be instantiated in

the main() method of any Python application using this

framework. A sample code snippet below shows how a web

application would be instantiated.

application = webapp.WSGIApplication('/profile.html',

ProfileHandler, '/.*', MainHandler, debug=True)

As seen in the code, the parameters passed to the

WSGIApplication constructor are a set of URL mappings. Each

URL provided will invoke the corresponding python script to

handle the HTTP GET request. As seen in the class diagram

below, the WSGIApplication within a framework instantiates an

object of type RequestHandler. Because the RequestHandler

class is an abstract class, a handler that is a subtype of

RequestHandler is created. The type of handler instantiated

depends on the mapping of the URL. Within this class, GET

requests can be handled using python code and rendering an

HTML document.

Page | 24
 Figure 6 webapp framework

Twitter Integration

The first step towards successful communication and integration of

SynapSync with social networks is to get the application authorized

by the social network account. This is necessary in order to allow

third party websites to be able to retrieve and publish information

to and from the authenticated social network accounts. In the case

of Twitter, authorization and authentication is achieved using the

OAuth protocol, which allows users to share all their content stored

in Twitter with another application (in this case, SynapSync) without

having to provide their username and password each and every

time.

Page | 25
Authentication

Page | 26
Through the OAuth protocol, the user is first prompted with

Twitter's webpage (Figure 7), which asks the user to provide

their credentials. By doing so, the user authenticates and

validates their identity on Twitter. A request token is also

provided to the user at this point of time in the URL parameters

along with other OAuth fields. The request token has an expiry

time and is short-lived, and if the user fails to authenticate within

the time, a new request token is provided. After providing the

credentials, the Twitter account is then authenticated and the

application is immediately authorized in the same step,

exchanging the request token for an access token. An access

token grants the application to make direct requests to Twitter's

API without having to provide the credentials each time.

Page | 27
 Figure 7 Twitter Account Authentication

If the user of the application, however, is already logged into a

Twitter account, then he or she is simply asked to authorize the

application. The user does not have to provide the credentials

Page | 28
 and thus, authentication is not required. Once authorization has

been granted and the access token is given to the application,

Twitter immediately redirects the user to a callback URL, which is

specified by the application developer, though it is usually

somewhere within the application domain.

Twitter API

The functionality Twitter uses to expose its data is a REST API

[7], in which a client initiates a request to Twitter, and Twitter

processes the request and returns an appropriate response. The

API consists of a large number of methods that allows the client

to make requests to retrieve mentions, retrieve direct messages,

update status, etc [7]. Any application can make successful calls

to the REST API given that the access token is provided. As

mentioned in section 4.2.2, the fetch() function in Google App

Engine's URL Fetch API is used as an interface to the REST API.

This makes communicating back and forth between Twitter and

SynapSync much more simplistic. More details on this are

provided in the Design section of this report.

Facebook Integration

Facebook, much like Twitter, requires authentication and

authorization in order to grant a third-party application to publish

and retrieve content from a registered Facebook account.

Page | 29
Authorization and Authentication

Unlike Twitter, Facebook uses its own open protocol for

authenticating user accounts and authorizing third-party

applications. However, the steps involved are very similar. The

application user is asked to provide their credentials and

authenticate their account. After doing so, the authenticated

user is then asked to authorize the application as shown in

Figure 8.

Figure 8 SynapSync Authorization for Facebook

Even after following these steps, the application still does not

have the permission to publish to a stream or retrieve content

from a Facebook account due to Facebook's Privacy Policy. In

order to gain access to these, the authenticated user must

further grant extended permissions to the application. An

Page | 30
example can be seen in Figure 9 where a prompt dialog asks the

user to allow SynapSync 'Offline Access' and a permanent

session key. Session keys work very similarly to OAuth's access

tokens, however the session key is only temporary and will

expire after an extended period of time. By granting the

extended permission in Figure 9, the session key which the

application has access to becomes permanent and the user will

no longer have to provide their credentials after the application

has been authorized. (Facebook)

Figure 9 Permission for offline access

Page | 31
Facebook API

Fortunately, Facebook also uses a REST API to expose its data

[8]. However, there is also the alternative of using the Facebook

Connect API, which is just as powerful. The difference is that

Facebook Connect implementation is done on the front-end web

design using HTML and JavaScript, and not in Python. The

drawback is that this path can prove to be very inconsistent with

the implementation of Twitter integration, and it also causes

many discrepancies between web browsers like Firefox and

Internet Explorer. Therefore, SynapSync makes use of the REST

API in order to be consistent with the Twitter implementation and

also to reuse App Engine's URL Fetch API.

Requirements

The requirements for the SynapSync system were broken down into

functional requirements and non-functional requirements learned

through our 4th year Software Engineering course. All the functional

requirements are defined in the use case diagram below and entail

what SynapSync is supposed to accomplish. All the cases where the

system uses the functional requirements are captured through use

cases. These functional requirements are further supported by the

non-functional requirements.

Page | 32
The non-functional requirements of SynapSync are not reflected in the

use case diagram or descriptions. However, the non-functional

requirements for this system are the following:

• To enhance security and protection of information and data -

fulfilled using User Authentication and Sessions.

• High maintainability - fulfilled by distinguishing boundary,

control, and entity classes to make classes more cohesive

(see Appendix D for class diagram).

• Easy to Use - fulfilled by creating a robust user interface

through proper web designing, which allows users to navigate

through the website in a seamless environment.

Further details on how these non-functional requirements are fulfilled

are explained in the Design section of the report. The following use

case diagram covers all of the functional requirements of SynapSync.

Page | 33
Page | 34
 SynapSync System

Mobile Access
Company Profile

Subscribe to
Email
Mobile Client

Contact
Company
Synapsync DataStore

Access
Company Profile

Company Follower

Login
Logout

Access Control Synapsync DataStore

Panel

Publish
Company Representative Content

Social Network API

Reply to
Comment
Facebook Twitter

Edit Company
Info

Add Twitter Synapsync DataStore

Account

Company Administrator
Add
Facebook Social Network API
Account

Facebook Twitter

Figure 10 - The use case diagram for SynapSync

The scenario for the use case ‘Publish Content’ is shown below. Some

others can be seen in Appendix C.

Page | 35
Publish Content

Brief Company Representative posts content to SynapSync

and to added Social Network accounts.
Description:
Precondition Company Representative is Logged in and has
accessed the Control Panel
Primary Actor Company Representative, SynapSync DataStore, Social
Network API
Basic Flow <Post Content>
Steps Action
1 Company Representative uploads an image
2 Company Representative types content into the title and the body
3 IF Company Representative chooses to 'Post', THEN the system
gets the name of the company from SynapSync DataStore
The system stores the content to SynapSync DataStore and
4 shortens the URL (using BitLy) to the content of the post on
SynapSync
The system sends an announcement to all Company Followers
5
through email about the post
The system retrieves all of the added social network accounts from
6
SynapSync DataStore
The system publishes the post to all Social Network accounts as a
7
status update through Social Network API
8 Company Representative is redirected to the Control Panel
Postcondit Post is published to SynapSync and all added social network
accounts of the company, and Company Representative is
ion:
redirected to the Control Panel without any notifications

Specific Alternative Flow: <Company Representative chooses to 'Save'

content>
RFS <Post Branching Action
Content>
ELSE
RFS Basic Step #
Page | 36
Flow 3 1) The system gets the name of the company from

SynapSync DataStore
2) The system stores the content to SynapSync DataStore
3) Company Representative is redirected to the Control

Panel
ENDIF
Postcondit Post is stored into SynapSync DataStore but NOT published, and

ion: Company Representative is redirected to the Control Panel without

any notifications

Page | 37
2. Design

Figure 11 Overall Class Diagram

Website

Page | 38
The SynapSync website is comprised of a number of webpages.

There is the main page, registration page, profile page, contact

page, control panel and settings page. Some of the pages are

visible to anonymous users who visit the site and others are

available to only authorized users. The components that deal with

the web front end are composed of the WebHandlers package, the

RequestHandler and the WSGIApplication. To maintain simplicity we

have divided our web frontend into 3 sections: The Configurations

section, the User Interface section and the Code-behind section.

These are displayed in Figure 12.

Figure 12 Website general architecture

Page | 39
Configurations Section

Page | 40
When creating a web application on Google App Engine there

needs to be a specification document that specifies how to

run the application on the web server. The specifications file

is called app.yaml. YAML stands for Yet Another Markup

Language. Our app.yaml file is displayed in Figure 13. In the

YAML file we can specify the location of the main Python

script for running the application requested by the URL. in

our case when any URL from our application is requested the

main.py will be the script to run. In the main.py the

WSGIApplication has a reference to all other handlers of the

application. The WSGIApplication framework will be

discussed in the Code-behind section. Multiple entries can be

added in the handlers section for a multi-page application.

This is however not common practice as App Engine allows

developers to register multiple applications and there is no

need to run them under one entry. The '/static' handler

refers to the folder where we store the CSS and Javascript.

Page | 41
Figure 13 app.yaml contents

The 'application' field represents the name of your

application and should match the name on App Engine when

deploying to the platform. The 'version' field represents the

current version of your application. The 'runtime' field is the

run-time used for running your application on the App Engine

servers. The 'api version' entry is the version of App Engine

that Google is currently running on the Google servers.

Page | 42
The User Interface Section

The visual layout displayed in the browser is specified by the

Cascading Style Sheet (CSS). These semantics can be either

written in the containing HTML file or, for maintainability,

common practices specify that a separate CSS file should be

written if more than one HTML page require the same formatting.

This allows for a seamless experience throughout the site. The

CSS file is linked to in the head part of the HTML file.

To maintain this seamless experience throughout the site, we

used DJANGO templates. The templates allow us to define certain

frames in the website wireframe to be interchangeable. What

this allows us to do is maintain the same toolbar and sidebar

throughout the site and edit it once to change the layout of our

entire application. We have a basic wireframe which we

reference in each HTML page. We called this file “_base.html". A

good way to think about this is as a Master Page which is

inherited by all our web pages contained within our application.

Our Master Page is split up into a Navigation section, a content

section, right column section and a footer section. These serve

as place holders for content which will populate in on different

web pages. In Figure 14 we see a screenshot of homepage

(main.html). Represented in this screenshot we have the menu

bar displayed in the 'Navigation Section', a welcome message in

Page | 43
the 'Content Section', the login pane in the 'Right Column' and a

copyright message in the 'Footer Section'. These placeholders

allow us the flexibility of changing the layout on certain pages

from a 2 column design to a single or multiple column page

design.

Figure 14 _base.html Master page

We also used place holders for content retrieved from the

datastore. We not only use place holders for datastore content

but also error reporting. A sample screenshot of the error prompt

is displayed in Figure 15. This now displays a new section which

in Figure 13 was not present.

Page | 44
 Figure 15 Error reporting

Displayed in Figure 16 is the source code for the Profiles Page

(profiles.html). Place holders in the HTML fille are represented by

'{{ }}'. The tag contained within the double swirly brackets is

passed from the Code-behind Python file. In this particular case

we have 'company' as the tag which contains the name of the

company, 'posts' which contains a list of formatted updates from

the user and 'info' which is the formatted version of the company

contact information. With the use of DJANGO we can also iterate

through the 'posts' list with standard Python right in line with

Page | 45
HTML. The 'block' containers refer to their respective sections of

Page | 46
the Master Page highlighted in figure 13.

Page | 47
Figure 16 profiles.html source code

Page | 48
Code-behind
As mention in the Background section 4.2.2, SynapSync uses App

Engine's webapp framework to handle HTTP requests. Each time

a GET request is made to SynapSync's application domain,

RequestHandlers are generated in order to handle each request.

Since a RequestHandler is an abstract class which is provided by

the App Engine, we chose to model it using the Template Pattern

(Figure 17). In the Template Pattern all of the handler classes

inherit from RequestHandler. Every handler overrides the get()

operation from RequestHandler in order to handle the HTTP GET

request. This allows us to load the respective HTML document

requested. For example, if the Control Panel was requested,

‘controlpanel.html’ would be response content. To retrieve

content inputted by a Company Representative we override the

post() operation which has different functionality on different

pages. For example, a post() operation on the Control Panel page

can either save the promotional update or publish the update.

Page | 49
 Figure 17 Request Handlers

To serve the HTML content to the browser we use a static

method named doRender() which holds our session cookie and

place holder tags mentioned in section 6.1.2. The code snippet

below shows part of the internal function of doRender().

outstr = template.render(‘controlpanel.html’, values[])

handler.response.out.write(outstr)
return

The ‘controlpanel.html’ entry is the directory path to the Control

Panel HTML file in the SynapSync folder. The 'values' variable

contains a dictionary of necessary values (such as user "in

session” and tag placeholders). These tags can contain data

Page | 50
 retrieved from the datastore. A Python dictionary is essentially a

hash table that efficiently maps identifiers to its associated

values. Each handler invokes the doRender() function every time

a webpage is requested.

To access the Settings page and the Control Panel page, the

Company Representative needs to be authenticated. This

authentication can be done in place or already existent in a

session.

Sessions and Authentication

In order to keep track of the logged in users of SynapSync sessions

are used. This is implemented in the get() function of each

different handler. When the Company Representative first

navigates to the SynapSync homepage at

http://www.synapsync.com, they are prompted for their credentials.

When the Company Representative attempts to log in, a session is

creted for their user id. If there was another session active on the

same computer it is deleted. Session has its own dedicated class,

which provides functions such as deleting sessions from users,

getting the current Company representative in session, and setting

the user in session. Since a session instance knows of the user that

is logged in, the Session class is directly associated with the User

entity class as shown in Figure 20.

Page | 51
 Figure 18 User entities and session

After authentication, the logged in Company Representative is

redirected to the Control Panel. Here, the get() method of the

RequestHandler checks if the user is currently in session before

rendering the HTML template. The same precondition applies to

the Settings page and any future RequestHandler that would

require authentication. Using sessions allows SynapSync to keep

track of the authenticated Company Representative without

having to ask for his or her credentials every time. It is also

important to note that sessions are temporary and expire after 2

hours. After a limited period of time, the user must re-

authenticate to continue their activity on the website.

Page | 52
 Datastore Interface

We designed and implemented our web application using the MVC

model. Our datastore entities displayed in Figure 18 served as our

Model. Our view was represented by the RequestHandler classes

discussed in the Code-behind section. For our controllers we

designed a number of classes which interact with both the view and

the model. We originally had a large class which served as the

controller, but once our application became more robust we split it

into multiple control classes for the various entities in the model. As

displayed in Figure 19 our controller package contains the

DataStoreUserInterface, DataStoreCompaniesInterface,

DataStoreSocialInterface and DataStorePostsInterface classes.

Contained within these classes are getters and setters for our

datastore. There is very little data computation handled in these

classes as most of our formatting and data manipulation is done in

the handler classes for each our RequestHandlers.

Page | 53
 Figure 19 Datastore Interface Controllers

Datastore

Google App Engine uses the Big Table model for database design as

opposed to the Relational model commonly used for applications.

This is due to their hardware architecture of their cloud system.

Google ensures better performance results when using the Big Table

model on Google App Engine. While the Big Table model does

provide higher performance, it poses challenges when data needs to

be organized and inter-related. In our case, the data store is

comprised for multiple tables. Our table models are displayed in

Figure 18. To relate the tables together when retrieving data stored

in them we made our own 'foreign key' identifier. For instance, to

find the user information for a company we linked the entries with
Page | 54
an identifier. We used the dbProfileName entry as the identifier.

This served as a global id for the company. This is composed of the

company name in lower caps and stripped of spaces.

Figure 20 SynapSync Datastore

Page | 55
Implementation

Social Networks

Twitter Implementation

As mentioned in the Background section, Twitter uses OAuth in

order to authorize third-party applications to use its REST API.

SynapSync makes use of this to allow a Company Administrator

to log in to the website and add a Twitter account by navigating

to the Admin Tools on the Settings page (illustrated in Figure 21).

'Adding a Twitter account' to SynapSync simply means to

authorize SynapSync to communicate directly to Twitter.

Because this feature is only limited to Company Administrators,

Company Representatives do not have the permission to add

social network accounts. A Twitter account is associated with a

company entity. Once the Administrator adds an account to

SynapSync, all Company Representatives will have access to that

account via SynapSync.

Page | 56
Figure 21 Twitter accounts can be added by clicking on the Twitter icon in the

Admin Tools

After going through the authorization procedures described in

section 4.3.1, Twitter automatically redirects to SynapSync. The

access token (refer back to section 4.3.1 for details) is first

passed back to SynapSync. The handler parses out the access

token, and gets the Twitter username through the REST API. This

allows SynapSync to retrieve data on the user. Once the access

token, the Twitter username, and the name of the company have

all been acquired, this information is stored into the datastore.

The entry is stored as a 'UserToken' entity. Therefore, anytime

Company Representative log into SynapSync, all Twitter

Page | 57
accounts under the company name are retrieved from the

datastore.

When the user navigates to the Home page or the Control Panel,

the most recent mentions of the added Twitter accounts are

listed on the right column (Figure 1). Every time this page is

loaded, the GET request handler retrieves the recent mentions

for the registered Twitter accounts. These mentions can be seen

in Figure 22. Figure 22 shows the new post on the Twitter

website itself.

Figure 22 The newly published post is retrieved from Twitter

Page | 58
 Figure 23 New post shown on Twitter

The post only contains the contents of the Title followed by a

BitLy. The link redirects to post on SynapSync (Figure 24). The

entire content is not shown in the post due to Twitter having a

limit of 140 characters per post.

Page | 59
 Figure 24 The full content of the post on SynapSync

Facebook Implementation

Authorizing SynapSync to access Facebook accounts works

similar to Twitter. The Company Administrator navigates to the

Admin Tools section on the Settings page. There they click on the

Facebook icon seen in Figure 21. Doing so will prompt the user

to verify his or her credentials before SynapSync is authorized

and a session key is provided. Facebook will automatically

redirect the browser to its website, where the Company

Administrator will grant SynapSync three extended permissions.

The three extended permissions are:

 To give SynapSync permission to access account

information when Facebook account is not logged in.

 To allow SynapSync to publish content on the Facebook

user's stream.

 To allow SynapSync to retrieve information from the

Facebook user's stream.

Page | 60
 Figure 9 in section 4.4.1 shows an example of an extended

permission dialog prompt.

Figure 25 After verifying the credentials, extended permissions must be

provided to complete authorization

Upon granting the extended permissions, the application is

authorized by clicking 'Finish'. The Company Administrator is

then redirected to the Settings page. At this point, the session

key is stored into the datastore along with the name of the

company into the 'FbSession' entity of the datastore model.

In order to interact with the added Facebook accounts, a

Company Representative navigates to the Control Panel where

they can update the Facebook account with a new status. All that
Page | 61
 is required to invoke the API methods are the permanent session

key and the Facebook user ID.

Similar to Twitter, SynapSync currently imports comments on

posted content from Facebook. This is displayed in the Control

Panel as see in Figure 22. In order to communicate with the REST

APIs of Facebook and Twitter, two classes are used to abstract

the details of the social network APIs. These classes are

Facebook and OAuthClient (Figure 28). They are placed into a

'Utilities' package which also holds the Session class that is used

to keep track of the SynapSync logged in user.

Figure 26 Association between Sessions, OAuth and Facebook

Conversations
SynapSync takes advantage of the social network interactions

and enables conversations between Company Representatives

and Company Followers. Looking back at Figure 21, the new

Page | 62
 comment by the Company Follower was retrieved by SynapSync

and Company Representatives can reply to this comment by

clicking the 'Reply' link. When doing so, the Company

Representative is redirected to the Reply page (Figure 29). From

this page replies can be sent out to their respective social

networks. This saves the Company Representative from visiting

social network websites in order to reply.

Figure 27 Replying to a Social Network Figure 28 Comment replies on

comment Facebook

The sequence diagram in Figure 31 shows the interaction of a

Company Representative replying to a Facebook comment or a Twitter

mention. As shown, communication and generating requests to

Twitter and Facebook are both very similar. This makes SynapSync

very extensible since adding a new social network such as MySpace or

Hi5 will be a similar process. The sequence diagram will then have

another separate flow for MySpace where “if reply == ‘MySpace’”

while every other step would remain the same.

Page | 63
 Figure 29 Replying to comments

Email
Google App Engine offers a number of APIs that simplify the

implementation of features for web applications. One API we used

for an important feature of SynapSync is the Mail API. This API

allows us to send email to Company Followers. The class diagram of

EmailProcessor is depicted in Appendix D. The scenario in which we

use the EmailProcessor class is when a user wants to contact the

company via the contact page or when posting a promotional

update (section 7.4). The sequence of contacting a company via the

Page | 64
contact page is shown in Figure 32. This sends an email notification

to the Company Administrator.

Figure 30 Contact Company

Page | 65
Mobile Client

The mobile client is implemented in Java using the Google Android

SDK. It acts as a client making an HTTP request on the SynapSync

server. Our MobileHandler in the SynapSync Handlers package is

represented in Figure 17. It receives a request from any client and

responds with the latest update of the company. As seen in Figure

33 the sequence diagram of the Android client access is activated

on the OnCreate() method. What this means is that when the

Android application is run, it requests the response from the

SynapSync server.

Page | 66
 Mobile Access Company Profile

<<boundary >>
Mobile Handler

Company Follower

Create ()
Android

onCreate ()

getCompanyUpdates ()
get ()
Create ()
<<control >>
DataStorePostsInterface

getPosts ()
Query ()

Create () << control >>

StringFormatter

formatPost ()

Figure 31 Mobile Client Access

Page | 67
Posting content

The main functionality of our web application is publishing content.

This is a complex process which interacts with a number of the

services listed throughout this report. The Company

Representatives interact with the Control Panel. Upon calling the

post() method, the boundary creates instances of the datastore

controls, EmailProcessor, BitLy and the social network APIs (Twitter

and Facebook). Upon posting the update, the post is sent to email

newsletter subscribers, social networks and of course stored to the

datastore. The process is displayed in Figure 34.

Page | 68
 Figure 32 Publishing Content

Testing

Verification of SynapSync was performed at various stages of

development. Because requirements and solutions were evolved

through an agile software development methodology, small testing

phases would occur after successfully implementing every new feature

Page | 69
of the system. In order to verify the reliability of SynapSync, proper

design patterns like the Template Pattern and the Model-View-

Controller pattern were used to model the system. Design

methodologies such as responsibility-driven design were also utilized,

by distinguishing boundary classes, control classes, and entity classes.

Although unit test classes were not created, unit testing was still

performed. This was done by verifying that every function and

algorithm was isolated and executed. By doing so, the resulting values

of the functions and algorithms were then compared to the expected

values.

In the event that the system would encounter errors and if verifications

were to fail, Google App Engine’s webapp framework offers a

debugging tool which prints out traces of the runtime stack. This

allows sources of errors to be spotted immediately in Python, and

proper corrections were then made. The Eclipse IDE was used to

develop the application, and this IDE also provides a debugging tool

that offers the ability to step-through the code and note the changes

occurring at runtime.

Business Achievements

As part of the challenge of creating an innovative project, our team

found that applying some business to the product might be beneficial

Page | 70
upon graduation. To validate the product and its need, we developed a

business plan concurrently. This motivated us to get our product out in

the market and get feedback on it. We did this by entering a number of

entrepreneurial competitions.

We first competed in the Ontario Engineering Competition (OEC) in

January 2010 under the Innovative Design category. The competition

took place in Waterloo, Ontario. At the time we had a rough working

prototype of the website and a basic business model. We were

challenged on the application of our software and the need for it. This

was due to little market research into the matter. We received 4th place

in the category. This of course motivated us to develop SynapSync

further and continue researching for potential customers and pain

points.

Our second competition was the Wesley Nicol Entrepreneurship

Competition at Carleton University. Throughout the competition we

had to draft a business plan which covered topics such as customer

acquisition, financial forecast and pricing. This was more in-depth than

the OEC and challenged our knowledge of business. We learned a lot

throughout the process. We researched the size of Ottawa’s small

business market and statistics on the use of social media. This proved

to be very well done as our team advanced to the finals where Filip

Mares presented the company, product and business plan. Our team

Page | 71
faced tough competition with most competitors coming from the Sprott

School of Business. Eventually, in the end SynapSync received 2nd

place and got media exposure in campus news. This motivated us to

pursue this further.

In early March 2010 we entered the Tech Venture Challenge which is

an Ottawa wide competition between Algonquin College, University of

Ottawa and Carleton University. We were named semi-finalist which

allotted us to a mentor in the Ottawa business community. He made

connections with some other business owners in similar market space

which can help us tailor our business plan. We are currently still in the

process of preparing our paperwork for the final.

Conclusion

We have used some of the most cutting edge technologies on the web

including the Twitter oAuth protocol, Google App Engine and the

Android 2.1 SDK. Dealing with all these new technologies we have

learned some of the drawbacks to adopting them early. The

communities were very small and support was limited. A great

example of this was our account authentication implementation. This

area was discussed in detail in section 6.2. We had to develop our own

solution rather than using the Google built authentication system. This

is due to the lack of documentation on the processes of implementing

it.
Page | 72
We however did make a good decision developing on the Google App

Engine platform as it allowed us the flexibility of developing our

application and not worry about setting up a server. Tying into the

Google APIs for mail, sessions and Image manipulation allowed us to

reduce our development time and we can see how in the real world

this would be beneficial. Reducing time to market can be key when

releasing a software product.

By using services such as Google Sites and SVN mentioned in the

Project Management section we were able to collaborate on

documentation and source code. This allowed for few collisions in the

development roadmap. In the future we would like to use a more

integrated solution such as 37Signals’ Basecamp product which allows

for code management and bug tracking in a single solution. This

however went against our initial concern of running a lean project with

minimal funds. [11]

We feel that in the span of 8 months we have achieved a lot. This is

due to countless hours of development work and research in new

technologies. We have developed a great solution for interfacing with

multiple online services. As seen in the documentation of this report

adding further services will be effortless as we have a very flexible

design. Overall we have delivered the proposed project and

maintained our delivery schedule.

Page | 73
References

[1] G. MacMillan, "Dell sales via Twitter leap more than 100% to $6.5m,"

BrandRepublic, [Online], 8 Dec. 2009. [6 April 2010]. Available:

http://www.brandrepublic.com/News/972507/Dell-sales-via-Twitter-leap-100-

65m/.

[2] L. Whitney, "Survey: Do small businesses use social networking?," CNET,

[Online], 14 Oct. 2009. [6 April 2010]. Available: http://news.cnet.com/8301-

1023_3-10374886-93.html.

[3] Google, “What is Google App Engine?”, Google Code, [Online], 2010. [6

April 2010]. Available:

http://code.google.com/appengine/docs/whatisgoogleappengine.html

[4] R. Nadler, “Plunging into Web Development”, Bob on Medical Device

Software, [Online], 07 June 2009. [6 April 2010]. Available: http://rdn-

consulting.com/blog/tag/ec2/

[5] Google, “Datastore Python API Overview”, Google Code, [Online], 2010.

[6 April 2010]. Available:

http://code.google.com/appengine/docs/python/datastore/overview.html

[6] Google, “webapp Overview”, Google Code, [Online], 2010. [6 April 2010].

Available:

http://code.google.com/appengine/docs/python/tools/webapp/overview.html

Page | 74
[7] Twitter, “Twitter API Documentation”, Twitter, [Online], 02 April 2010. [6

April 2010]. Available: http://apiwiki.twitter.com/Twitter-API-Documentation

[8] Facebook Developers, “API”, Facebook Developers, [Online], 29 March

2010. [6 April 2010]. Available:

http://wiki.developers.facebook.com/index.php/API

[9] tav, “tweetapp”, github Social Coding, [Online], 21 May 2009. [6 April

2010].

Available: http://github.com/tav/tweetapp

[10] S. Cormier-Iijima, “pyfacebook”, github Social Coding, [Online], 27

December 2009. [6 April 2010]. Available:

http://github.com/sciyoshi/pyfacebook

[11] 37Signals, “BaseCamp”, 37Signals, [Online]. [6 April 2010]. Available:

http://basecamphq.com/?

source=37signals+home&__utma=1.1640256451.1270595573.1270595573.

1270595573.1&__utmb=1.4.10.1270595573&__utmc=1&__utmx=-

&__utmz=1.1270595573.1.1.utmcsr=%28direct%29|utmccn=%28direct%29|

utmcmd=%28none%29&__utmv=-&__utmk=258283658

Page | 75
Page | 76
Appendix A – Use Case Actor Descriptions

Actor Descriptions

Company Follower

This actor follows and subscribes to a company in order to follow

company updates. By accessing company profile pages, Company
Follower retrieves information from the SynapSync Datastore to
read updates and company information. This actor can also contact
companies by sending an email through SynapSync.

Company Representative

The Company Representative has the ability to interact with the

SynapSync Datastore in order to perform various actions such as
posting content or creating a new account in the SynapSync
Datastore. The User can also interact with social networks through
the server.

Company Administrator

The Company Administrator is a type of Company Representative

with special priveleges. These priveleges involve editing information
about the company, and integrating new social network accounts
under the company name.

Mobile Client

The Mobile Client simply follows company updates by retrieving

information from the SynapSync Datastore into their mobile.

Page | 77
SynapSync DataStore

The SynapSync Datastore represents the model of the system and it

keeps all data required for the Company Representative to interact
with the system such as his or her name, password, email, etc. The
SynapSync Datastore also holds contents posted by Company
Representative.

Social Network API

The Social Network API receives content from the Company

Representative through SynapSync when he or she makes a request
to post content to the desired social network (Facebook, Twitter). It
also sends out content to Company Representative through
SynapSync when he or she makes a request to retrieve content from
the desired social network.

Twitter

A type of Social Network API that uses a special type of protocol

known as ‘OAuth’ for authorizing applications. Company
Administrator needs to verify his or her credentials in order to allow
Twitter to authorize SynapSync to retrieve and post content to
Twitter.

Facebook

A type of Social Network API that requires authentication as well as

special permissions in order to authorize applications. Company
Administrator needs to verify his or her credentials and provide the
special permissions to SynapSync in order to allow Facebook to
authorize SynapSync to retrieve and post content to Facebook.

Page | 78
Appendix B – Use Case Descriptions

Contact Company – Company Follower emails Company

Administrator via the contact page.

Subscribe to Email – Company Follower chooses to follow company

updates from the company’s profile page via email.

Access Company Profile – Company Follower visits the company’s

profile page on SynapSync.

Mobile Access Company Profile – Mobile Client retrieves the latest

update of the company being followed.

Login – Company Representative provides his or her username and

password to authenticate on the SynapSync main page.

Logout – Company Representative logs out of SynapSync.

Page | 79
Access Control Panel – Company Representative visits the home

page of SynapSync after authentication.

Publish Content – Company Representative enters content into the

text field and posts an update on SynapSync and integrated social

network accounts on the home page.

Reply to Comment – Company Representative replies to retrieved

comments of Company Followers on the home page.

Edit Company Info – Company Administrator modifies information

about the company such as name, address, postal code, etc. on the

settings page.

Add Twitter Account – Company Administrator authorizes

SynapSync to interact with a registered Twitter account.

Add Facebook Account – Company Administrator authorizes

SynapSync to interact with a registered Facebook account.

Page | 80
Appendix C – Use Case Scenarios
Contact Company

Brief Company Follower contacts the Company

Description: Administrator by sending an email to the

Administrator's registered account.

Precondition Company Follower has accessed the Company Profile
Primary Actor Company Follower, SynapSync DataStore
Generalizatio None

Basic Flow
Steps Action
1 Company Follower chooses to send 'Email'
2 Company Follower types email body into the textbox and chooses

to 'Send'
3 The system gets the email of the Company Administrator from

SynapSync DataStore
The system processes the email and sends email to the Company
4
Administrator
SynapSync redirects Company Follower to the Company Profile
5
page
Postcondit Company Administrator has received the email and Company

ion: Follower is on the Company Profile page

Page | 81
Login

Brief Company Representative provides his or her

Description: credentials and logs into SynapSync.

Precondition Company Representative has accessed the main page

of SynapSync
Primary Actor Company Representative, SynapSync DataStore
Generalizatio None

Basic Flow
Steps Action
1 Company Representative types in his or her username and

password and chooses to ‘Login’

2 SynapSync DataStore queries the database to see if the username

and password pair exists

3 IF the user does not exist in the database, THEN the system

redirects Company Representative to the main page notifying that

the authentication failed

ELSE The system stores the user’s session into SynapSync
4
DataStore
SynapSync redirects Company Representative to the Control
5
Panel or the home page
Postcondit Company Representative has successfully logged in and has

ion: acquired an active session, the system redirects Company

Representative to the Control Panel
Publish Content

Page | 82
Brief Company Representative posts content to SynapSync

Description: and to added Social Network accounts.

Precondition Company Representative is Logged in and has

accessed the Control Panel

Primary Actor Company Representative, SynapSync DataStore,

Social Network API

Secondary None

Actors
Dependency None
Generalizatio None

Page | 83
Basic Flow <Post Content>
Steps Action
1 Company Representative uploads an image
2 Company Representative types content into the title and the body
3 IF Company Representative chooses to 'Post', THEN the system

gets the name of the company from SynapSync DataStore

The system stores the content to SynapSync DataStore and

4 shortens the URL (using BitLy) to the content of the post on

SynapSync
The system sends an announcement to all subscribers through
5
email about the post
The system retrieves all of the added social network accounts from
6
SynapSync DataStore
The system publishes the post to all Social Network accounts as a
7
status update through Social Network API
8 Company Representative is redirected to the Control Panel
Postcondit Post is displayed on the company profile page on SynapSync and

ion: all added social network accounts of the company, and Company

Representative is redirected to the Control Panel without any

notifications

Page | 84
Specific Alternative Flow:
RFS <Post Branching Action

Content> <Company Representative chooses to 'Save' content>

<Basic flow

step 3>
ELSE
RFS Basic Step #
1) The system gets the name of the company from
Flow 3
SynapSync DataStore
2) The system stores the content to SynapSync DataStore
3) Company Representative is redirected to the Control

Panel
ENDIF
Postcondit Post is stored into SynapSync DataStore, and Company

ion: Representative is redirected to the Control Panel without any

notifications

Page | 85
Reply to Comment

Brief Company Representative replies to Company

Description: Follower's comment on a social network through

SynapSync
Precondition Company Representative is Logged in and has

accessed the Reply Page

Primary Actor Company Representative, Social Network API
Generalizatio None

Basic Flow <Reply to Facebook comment>

Steps Action
1 Company Representative types content into the reply text field

and clicks 'Post'

2 The system gets the name of the company for the Company

Representative
The system retrieves the social network account to which Company
3
Follower made a comment on
IF the account is on Facebook, THEN the reply is published to the
4
stream on which Company Follower commented on Facebook
5 Company Representative is redirected to the Control Panel
Postcondit The reply is published onto the company's status update stream
where the comment was made on Facebook, and Company
ion:
Representative is redirected to the Control Panel without any
notifications

Page | 86
Specific Alternative Flow:
RFS <Reply to Branching Action

Facebook comment> <Company Representative replies to a Twitter

<Basic flow step 4> mention>

ELSE
RFS Basic Flow 4 Step

#
1) The reply is published to Company Follower's

twitter account as a mention

2) Company Representative is redirected to the

Control Panel
ENDIF
Postcondition: The reply is published onto Company Follower's twitter

account as a mention, and Company Representative is

redirected to the Control Panel without any notifications

Page | 87
Appendix D – Class Diagrams

EmailProcessor Diagram

EmailProcessor

+ isValid (email :String ):Boolean

+sendSupportEmail (recipient :String , subject :String , body :String ):Void
+sendAnnounceEmail (companyName :String , recipient :Strng , subject :String , body :String ):Void

<<boundary >>
<< boundary >>
CPanel Handl er
Contact Handl er

+get () +get ()
+post () +post ()

Page | 88
Appendix E – Sequence Diagrams

Login Process

Login

<<boundary
>> <<entity>> <<boundary>>
MainHandler Users ControlPanelHandler

Company Representative
Get()

Post()

Create()
DataStoreUserInterface

loginUser()
Query()

checkPass()
Query()

opt
Get() If checkPass == ‘false’

[Else]
Create()
Session

appendUser()

Get()

Page | 89
 Load Control Panel

Load Control Panel

<<boundary>> <<boundary>>
CPanelHandler MainHandler

Company Representative

Get()

If ‘user’ not in session Get()

[else]

Create() <<control>>
DataStoreCompaniesInterface

getCompanyProfileName
()

Create()
<<control>>
:DataStoreSocialInterface

getTwitterAccounts
()

getFacebookAccounts
()

loop Create() [# of social accounts]

:OAuthClient
get()

Create()
:Facebook
__call__(‘Stream.get’)

Create()
<<control>>
StringFormatter
getCompanyProfileName
()

Create()
<<control>>
DataStorePostsInterface

getSavedPosts()

render.doRender(‘controlpanel.html’)
Page | 90
 Load Settings

Load Settings

<<boundary>> <<entity>> <<entity>> <<entity>> <<entity>>

SettingsHandler Companies Users UserToken FbSession
Company Administrator
Get()
Create() <<control>>
StringFormatter

getCompanyProfileName
()

getEmail( )

Create() <<control>>
DataStoreCompaniesInterface
getCompanyInfo
()
Query()

Create() <<control>>
DataStoreUserInterface
getUserInfo()
Query()
isAdmin()
Query()

opt
Is Admin Create()
<<control>>
DataStoreSocialInterface

getTwitterAccounts
()
Quey()
getFacebookAccounts
()
Query()

Change Settings

Page | 91
 Access Company Profile

Access Company Profile

<<boundary>> <<entity>> <<entity>>

ProfilesHandler Posts Companies

Company Follower

Get()

Create() <<control>>
DataStorePostsInterface

getPosts()
Query()

getCompanyInfo()
Query()

getCompanyName
()
Query()

Create() <<control>>
StringFormatter

formatCompanyInfo
()

formatPost()

Post()
Create()
<<control>>
DataStoreCompaniesInterface

addEmailSubscriber
()
Put()

Get()

Page | 92