Final Design report

MIDDLE EAST TECHNICAL UNIVERSITY
COMPUTER ENGINEERING DEPARTMENT
Senior Project 2007-2008
Final Design Report
Team Members:
Taha Bekir Eren 1448646
Erdem Karahan 1347616
Mine Karakaya 1395136
1. INTRODUCTION
1.1. Project Title
1.2. Motivation
1.3. Project Definition
1.4. Project Goals
2. REQUIREMENT ANALYSIS
2.1. System Requirements
2.1.1. Hardware Requirements
2.1.2. Software Requirements
2.1.3. Development Environment Requirements
2.2. Functional Requirements
3. USE CASE ANALYSIS
3.1. Use Case Diagrams
3.2. Use Case Scenarios
4. MODELING
4.1. Data Modeling
4.1.1. Entity Relationship Diagrams
4.1.2. Creating IMBO Database
4.2. Functional Modeling
4.2.1. Data Flow Diagrams
4.2.2. Data Dictionary of Data Flow Diagrams
4.2.3. Process Specification of Data Flow Diagram
5. PROJECT SCHEDULE
5.1. Project Milestones
5.2. Gantt Chart
6. CLASS DIAGRAMS AND DESCRIPTIONS
7. SEQUENCE DIAGRAMS
8. TESTING PLAN AND PROCEDURES
8.1. Test Plan
8.2. Unit Testing
8.3. Integration Testing
8.4. Security Testing
8.5. Acceptance Testing
9. SOFTWARE INTERFACE DESCRIPTION
1. INTRODUCTION
1.1. Project Title
IMBO
1.2. Motivation
The communication methods people chose have altered due to the
developments in technology. Internet has become widespread during recent years.
A result of the widespread usage of Internet, Web applications became very
popular. One of the key reasons for Web applications’ popularity is the ability to
update and maintain them without distributing and installing software on
potentially thousands of client computers. Another reason is that web applications
have become faster and more practical for real-world applications. A kind of web
application is instant messaging; a form of real-time communication between two
or more people based on typed text. Modern, Internet wide, GUI-based instant
messengers began to appear in the mid 1990s with ICQ (1996); followed by
followed by AOL Instant Messenger, Yahoo, MSN, Excite, Ubique, IBM, MSN,
AIM and Google Talk. Nowadays, the number of web sites providing their users
instant messaging is increasing. For example, Quick Contacts in Gmail and
Windows Web Messenger are instant messaging web applications on web sites.
Moreover, some web applications provide an integrated environment among instant
messaging systems. For example, Meebo is an in-browser instant messaging
program, which supports multiple IM services, including Yahoo! Messenger,
Windows Live Messenger, Google Talk, AIM, and ICQ by using Jabber protocol.
Other examples are ebuddy (supporting MSN, Yahoo, AIM, and GTalk) and
Communication Tube (supporting ICQ, MSN, IRC, GTalk).
1.3. Project Definition
IMBO will enable users to reach their multiple IM services through IMBO
IM service contemporaneously. So IMBO will be an online, browser based instant
messaging (IM) environment which supports multiple popular IM services; namely
MSN, GTalk, ICQ, Yahoo. IMBO will use Jabber (XMPP) as a technological base
for instant messaging purposes. Following figure shows the context diagram of
IMBO:
1.4. Project Goals
Here are some general features that will be in IMBO:
Visitor is the user of IMBO selecting one of the IM services from MSN,
GTalk, ICQ ,Yahoo and requesting to sign up his/her chosen IM service without
any subscription in IMBO. Visitor will be able to chat with his/her contacts from
his/her chosen IM service. If his /her chosen IM service enables file transfers,
he/she will be able to transfer files with his/her contacts.
Signed-Up User of IMBO is the user subscribed to IMBO IM service;
in addition, has more privileges than the Visitor has. Users can create an IMBO
account, under which they can combine multiple popular instant messaging
accounts; namely MSN, GTalk, ICQ, Yahoo. Signed-Up Users are provided offline
messaging and offline-user tracking feature that gives online-offline information
data of other users to the user. The offline-tracking feature will be beneficial for
curious users who want to check out the status of their contacts, not for a moment
but for a period of time. The simpler but more powerful instances of our extra
features would probably be the group and group wall features, which will enable
users of IMBO to socialize. Users of IMBO account can create groups, and become
members of existing groups. They can also search for groups or invite their
contacts to become a member of an existing group. One of the impressive attributes
of the group is photo sharing. One can upload a photo, which he/she finds relevant
to group. By group wall feature, users can share any kind of information or useful
links related to their groups; which they are familiar with from Facebook. Besides,
users that have an IMBO account will be able to create and maintain user profiles.
If the user gives authorization, other users will be able to make searches among
users of IMBO account using the profile criteria. Otherwise, the unwilling user will
be excluded from the profile search. We will not only settle for profiles created in
IMBO but we will also import profile information from Facebook, which will give
extra power to our service. Moreover, IMBO will be able to export profile
information to third party applications. The striking fact here is that no other web
based instant messaging service provides those like popular and practical features.
2. REQUIREMENT ANALYSIS
2.1. System Requirements
2.1.1. Hardware Requirements
When the number of our users increases, our hardware requirements will
change; therefore strictly defining hardware requirements is not artful. As a
baseline, we need a single Pentium 4 computer with 1 GB of RAM. Nevertheless,
as the number of users increase some enhancements on hardware configurations
must be considered:
Moving to a multi-processor and vast memory (both RAM and durable
Storage) server
Creating a clustered server architecture
Separating DBMS server from the Web Server
Installing a RAID system on the DBMS server
Using a distributed file system
2.1.2. Software Requirements
Windows as the operating system (because of ASP.NET application)
IIS (Internet Information Services)
Openfire (Jabber Server)
MS SQL Server as DBMS
2.1.3. Development Environment Requirements
Microsoft Visual Studio 2005
Eclipse
SQL Server Management Studio
2.2. Functional Requirements
Web Application:
It is the only part of the project, which is directly in touch with the user.
Therefore, it either directly or indirectly interacts with other modules to reflect user
processes in IMBO system. We determined our requirements based on our
market research.
Users can login with their existing instant messaging (IM) accounts without
any subscription in IMBO. This can be achieved by making a connection to the
provided jabber server (e.g. if the user provides a Gmail address, connect to
talk.google.com). Obviously, no database activity is needed for this. Users will be
able to do IM service specific actions. For example; a user login to Msn via IMBO
can send nudge, one login to ICQ via IMBO can make profile search which is
provided by ICQ, and one login to GTalk can use the attribute named “Show
Current Music Track”.
Users can create an IMBO account, under which they can combine multiple
other IM accounts. This relation will be saved in our database.
Users can create groups, become members of existing groups and use group
walls. They can search for groups or invite their contacts to become a member of
an existing group.
Users will be able to send and receive instant messages with their IMBO
account, even if they do not have any other IM accounts. In this case, our jabber
server will be used to send and receive instant messages.
If a user has an IMBO account, he/she will be able to create and maintain a
user profile. If the user gives authorization, other users will be able to make
searches using profile criteria. Otherwise, the user will be excluded from the
search.
Users will be able to send messages even when the recipient is offline (some
current IM systems provide this function, as GTalk and Windows Live Messenger,
some do not).
If the user combines multiple IM accounts in an IMBO account, when he/she
signs in, all his/her accounts will be automatically signed in. All contacts; he/she
has in various IM accounts; can be seen within a single list in IMBO.
A user may track his/her contact(s)'s status while he/she is offline. Changes
in status will be reported when the user signs in next time.
Profile Web Services:
Profile information coming from Web Application Module or from third
party applications is sent to database Services Module by Profile Web Services.
The third party application here is Facebook; meaning we will import profile
information from Facebook.
Profile information coming from Database Services Module is sent to Web
Application Module or to third party applications by Profile Web Services.
Therefore, we will enable exporting profile information in our system to third party
applications.
Profile searching will be available via xml web services. The web service
will query the database by using database classes.
Jabber Plug-in:
The plug-in will send the offline messages to the recipients when they
become online. Sender's login information may be needed to send the messages.
Another alternative is sending the messages in the name of sender with another
address (such as [email protected]).
The plug-in will save contact tracking information to the database to be used
by the web application. In addition, contacts to be tracked information will be read
from the database.
3. USE CASE ANALYSIS
3.1. Use Case Diagrams
Use Case Diagram For Candidate User Of IMBO:
Use Case Diagram For Signed-Up User Of IMBO:
Use Case Diagram For Visitor:
3.2. Use Case Scenarios
Candidate User of IMBO:
Request Sign-Up From IMBO: In order to sign up to IMBO, the candidate
user will have to submit user name and password to web user interface. Optionally,
the candidate user may submit profile information to be a member of the profile
search feature.
Signed-Up User of IMBO:
Login: The signed-up user of IMBO will have to login to IMBO IM
service in order to be able to make operations that are allowed by IMBO IM service
after the validation of login data.
Operations Done From IMBO: The signed-up user of IMBO will have the
ability to chat, send offline messages, transfer files, constitute groups, enrol as a
member of groups, use group walls, give authorization to be searched by other
users via profile search attribute, make profile search, subscribe to offline tracking,
import profile information from Facebook, and export profile information to third
party applications.
Unsubscribe From IMBO: The signed-up user of IMBO may unsubscribe
from IMBO whenever he/she wants.
Visitor:
Login: The visitor will choose one of the IM services from MSN, GTalk,
ICQ, and Yahoo; and will login to that IM service. After the validation of login
information, the visitor will be able to make operations that are allowed by the IM
service he/she has login.
Operations Done From MSN: The visitor will have the ability to chat,
transfer files, send nudge to the contacts he/she has in MSN after he/she signs in
MSN via IMBO.
Operations Done From GTalk: The visitor will have the ability to chat,
transfer files with the contacts he/she has in GTalk, and use “Show My Current
Music Track” attribute after he/she signs in GTalk via IMBO.
Operations Done From ICQ: The visitor will have the ability to chat, transfer
files and use profile search attribute provided by ICQ among the contacts he/she
has in ICQ after he/she signs in ICQ via IMBO.
Operations Done From Yahoo: The visitor will have the ability to chat with
the contacts he/she has in Yahoo after he/she signs in Yahoo via IMBO.
4. MODELING
4.1. Data Modeling
4.1.1. Entity Relationship Diagrams
4.1.2. Entity Descriptions
Entity & Relation Descriptions for Main Database:
Users:
This entity contains information of an IMBO user. It is the central entity of
our data definitions.
user_id: Unique identifier of the user. This field is automatically assigned, and it
is not visible to user. Other entities refer to a user entity by this field.
user_name: Account name of the user. This account name will exist on our jabber
server as an IMBO user.
password: Password of the user. This password will be the same with the one in
the jabber server’s database.
signup date: This is the date and time when the user opened his/her IMBO
account. This information can be used for account expiration and similar things.
Offline Messaging:
message_id: Unique identifier of the offline message. This field is automatically
assigned, and it is not visible to user. Other entities refer to an offline message by
this id.
from: Sender of the offline message. This address will be used when the receiver
becomes online.
to: Receiver of the offline message.
message_date: This is the date/time information, which holds when the user sent
the message. This information can be used to express actual date/time of the
message to the receiver.
message_text: Text of the message.
Contact Tracking:
tracking_id: Unique identifier of the tracking information. This field is
automatically assigned, and it is not visible to user. Other entities refer to tracking
information by this id.
follower: ID of the tracker user. We don’t use the address as the follower because
to use contact tracking feature can be used only by registered users. This
information refers to the user_id of the user entity.
followed: Address of the tracked user.
tracking_date: Date and time part of the tracking information. For example, at
27.05.08 15:00 A is online.
state: State of the tracked user. e.g. online, away, offline.
Profile:
user_id : The id of the user who owns the profile. This data refers to the user_id
information of the user entity.
first_name : First name of the user.
last_name : Last name of the user.
nick_name : Nick name of the user. This can be displayed while the user chats.
birthday : Birthday of the user.
website : Personal web site of the user.
birth_place : Birth place of the user.
occupation : Professional occupation of the user.
gender : Gender of the user.
country : The country where the user is resident.
city : The city where the user is resident.
company : The company user works for.
interests: Interests of the user as plain text. When a profile search is performed and
this field is used, a full text search will be performed over this field.
Groups:
This entity contains information for user groups.
group_id : The unique identifier of the group. Other entities refer to this entity by
this field.
group_name : Name of the group.
group_description : Text description of the group.
Users&Groups:
This entity holds the membership information of users with respect to groups. Since
this is a many to many relation, we needed an extra entity to hold the relation.
group_id : Refers to the group entity.
user_id : Refers to the user entity.
Group_Walls:
This entity contains wall messages of the groups. Each group has a wall and a wall
can contain several messages. Since this design yields to one too many relation, this
entity holds a group_id attribute.
entry_id : Unique identifier of the wall message.
group_id : ID of the group which owns this wall message.
sender_id : Sender of the wall message.
message : Actual data of this entity.
message_date : Date and time of the message.
Group_Pictures:
This entity contains images of groups. An image belongs to a group and a group
can own several images.
picture_id : Unique identifier of the picture.
group_id : ID of the group which owns the picture.
sender_id : Uploader of the picture.
picture : Actual data of the entity.
4.1.3. Data Description
Underlined data means that the data is primary key.
Users:
Data
Type&Size
Format
USER_ID
INT
NUMBER(AUTOINC)
USER_NAME
VARCHAR100
TEXT
PASSWORD
VARCHAR100
TEXT (Encrypted)
SIGNUP_DATE
DATETIME
DATE+TIME
Data
Type&Size
Format
MESSAGE_ID
INT
NUMBER(AUTOINC)
FROM
VARCHAR100
TEXT
TO
VARCHAR100
TEXT
MESSAGE_DATE
DATETIME
DATE+TIME
MESSAGE_TEXT
VARCHAR4000
TEXT
Data
Type&Size
Format
TRACKING_ID
INT
NUMBER(AUTOINC)
FOLLOWER
INT
NUMBER
FOLLOWED
VARCHAR100
TEXT
TRACKING_DATE
DATETIME
DATE+TIME
STATE
SMALLINT
NUMBER
Offline Messages:
Contact Tracking:
Profiles:
Data
Type&Size
Format
USER_ID
INT
NUMBER
FIRST_NAME
VARCHAR50
TEXT
LAST_NAME
VARCHAR50
TEXT
NICK_NAME
VARCHAR100
TEXT
BIRTHDAY
DATETIME
DATE+TIME
WEBSITE
VARCHAR100
TEXT
BIRTH_PLACE
VARCHAR100
TEXT
OCCUPATION
VARCHAR100
TEXT
GENDER
SMALLINT
NUMBER
COUNTRY
INT
NUMBER
CITY
VARCHAR40
TEXT
COMPANY
VARCHAR40
TEXT
INTERESTS
VARCHAR4000
TEXT
Data
Type&Size
Format
GROUP_ID
INT
NUMBER(AUTOINC)
GROUP_NAME
VARCHAR100
TEXT
Groups:
GROUP_DESCRIPTION VARCHAR2000
TEXT
Users&Groups:
GROUP_ID
INT
NUMBER
USER_ID
INT
NUMBER
ENTRY_ID
INT
NUMBER
GROUP_ID
INT
NUMBER
SENDER_ID
INT
NUMBER
MESSAGE
VARCHAR1000
TEXT
MESSAGE_DATE
DATETIME
DATE+TIME
PICTURE_ID
INT
NUMBER
GROUP_ID
INT
NUMBER
SENDER_ID
INT
NUMBER
PICTURE
BLOB
IMAGE
Group_Walls:
Group_Pictures:
4.2. Functional Modeling
4.2.1. Data Flow Diagrams
Level 0 Data Flow Diagram:
Level 1 Data Flow Diagrams:
4.2.2. Data Dictionary of Data Flow Diagrams
Name
Messages
Input To
User, Visitor, Jabber Server,1.0 Web Application
Output From
User, Visitor, Jabber Server,1.0 Web Application
Description
These are the messages communicated through user and
web application module, visitor and web application
module and jabber server and web application.
Format
Instant text messages
Name
Group Information
Input To
User, Jabber Server, Database Server,1.0 Web
Application, 3.0 Database Web Services
Output From
User, Jabber Server, Database Server,1.0 Web
Application, 3.0 Database Web Services
Description
Information about the groups that the user is a member of
Format
Database record(s)
Name
Profile Information
Input To
User,1.0 Web Application, Database Server, 3.0 Database
Web Services, 4.0 Profile Web Services, 3rd party
applications
Output From
User,1.0 Web Application, Database Server, 3.0 Database
Web Services, 4.0 Profile Web Services, 3rd party
applications
Description
Log-in user’s profile information
Format
Database record(s)
Name
Offline Messages
Input To
Database Server,2.0 Jabber Plug-In, Jabber Server, 3.0
Database Web Services
Output From
Database Server,2.0 Jabber Plug-In, Jabber Server, 3.0
Database Web Services
Description
Messages sent when the receiver side user is offline
Format
Instant text messages
Name
Contact Tracking Information
Input To
2.0 Jabber Plug-In, 3.0 Database Web Services, Database
Server
Output From
Jabber Server, 3.0 Database Web Services, 1.0 Web
Application
Description
Online-Offline records of the contacts of a user
Format
Database Record(s)
Name
Send Message
Input To
1.3 Message Operations
Output From
1.1 Visitor Interaction,1.2 User Interaction
Description
Messages sent from login users or from the visitors of the
service
Format
Instant text messages
Name
Receive Message
Input To
1.1 Visitor Interaction,1.2 User Interaction
Output From
1.3 Message Operations
Description
Messages received from login users or from the visitors of
the service
Format
Instant text messages
Name
Search Profile
Input To
1.2 User Interaction
Output From
1.4 Profile Operations
Description
Profile searching results obtained by the profile
operations
Format
Database Record(s)
Name
Save Profile
Input To
1.4 Profile Operations, Database Server, 3.2 Profile
Processor
Output From
1.2 User Interaction,1.4 Profile Operations , 3.2 Profile
Processor
Description
Saved profile information data
Format
Database Record(s)
Name
Search Groups
Input To
1.2 User Interaction, 3.1 Group Processor
Output From
1.5 Group Operations , 3.1 Group Processor
Description
Resulting data obtained from group searching
Format
Database Record(s)
Name
Group Membership Request
Input To
1.5 Group Operations, 3.1 Group Processor
Output From
1.2 User Interaction, 1.5 Group Operations
Description
Group membership request data
Format
Record representing the request
Name
Create Membership
Input To
Database Server
Output From
3.1 Group Processor
Description
User membership saving information recorded to the
database
Format
Record representing the membership
Name
Incoming Messages
Input To
1.3 Message Operations
Output From
-
Description
Branch of the data “Messages” in level 0
Format
Instant Text Messages
Name
Outgoing Messages
Input To
-
Output From
1.3 Message Operations
Description
Branch of the data “Messages” in level 0
Format
Instant Text Messages
Name
Tracking Information
Input To
1.2 User Interactions, 1.6 Tracking Operations, 3.0
Database Web Services, Database Server, 2.0 Jabber
Plugin, 2.2 Tracking Info processor, 3.3 Tracking Info
Processor
Output From
1.6 Tracking Operations, 3.0 Database Web Services,
Database Server, 2.0 Jabber Plugin, 2.2 Tracking Info
processor, 3.3 Tracking Info Processor
Description
Online-Offline information data of the user’s contacts,
formed by the tracking information processor
Format
Database Record
Name
Create Group
Input To
1.5 Group Operations, 3.1 Group Processor, Database
Server
Output From
1.2 User Interaction, 1.5 Group Operations, 3.1 Group
Processor
Description
Data related to creation of a new group
Format
Database Record
4.2.3. Process Specification
Process Specification/Level_1
Since the processes of level_0 are the abstract versions of the ones in
level_1, specification of level_0 processes are meaningless.
1.1 Visitor Interaction
Input of this process is “receive message” and output of the process is “send
message”. This process stands for the operations representing the interaction
between the visitor of the website and the system.
1.2 User Interaction
Inputs of this process are “receive message”, “search profile”, “search
groups” and “tracking info“ and the outputs are “send message”, “save profile”
,”create group” and “membership request”. The process stands for all operations
providing the above features with the interaction between user and the system.
1.3 Message Operations
Its inputs are “send message” and “incoming messages” and outputs are
“receive messages” and “outgoing messages”. It is the layer between the sender and
the receiver which also supports sending the “previously offline” messages
represented by the input “incoming messages” and the “outgoing messages”.
1.4 Profile Operations
Its inputs are “search profile” and “save profile” , outputs are “search
profile” and “search profile” and “save profile”. This process handles all operations
supporting the profile related features.
1.5 Group Operations
Its inputs are “create group”, “search groups” and “membership request” and
outputs are “create group”, “search groups” and “membership request”. This
process unit handles all group related operations.
1.6 Tracking Operations
The input and output of this unit is tracking info which means that this
process unit evaluates the contact tracking information coming to itself and sends it
to the user interaction process unit.
2.1. Offline Message Processor
The data “offline messages” stands for both input and output for this process
unit. The messages for going to the offline users simply marked as offline in this
unit and sent to the database web services unit.
2.2 Tracking Info Processor
The data “tracking info” stands for both input and output for this process
unit. That is, information gained from jabber server is evaluated in this processor
and brought into a form as tracking information; then sent to the database web
services unit.
3.1 Group Processor
Inputs of this unit are “membership request”, “create group” and “search
groups”. Outputs are “create membership”, “create group” and “search group”.
This is the web service unit which provides the communication between the group
operations unit and the system database.
3.2 Profile Processor
Its inputs are “search profile”, ”save profile” outputs are again “search
profile”, “save profile”. This is the web service unit which provides the
communication between profile operations unit and the system database.
3.3 Tracking Info Processor
Its input and output is “tracking info” which means that the information
coming from the tracking info processor is interpreted as a web service and sent to
the system database.
3.4 Offline Message Processor
Its input and output “offline message” which means that the information
coming from the offline message processor is interpreted as a web service and sent
to the system database.
5. PROJECT SCHEDULE
5.1. Project Milestones
These are the work packages of our project:
Project Management:
Project Proposal
System Requirements Specification and Analysis Report
Initial Design Report
Final Design Report
Web Application & Web Services:
Database Design
Database Library (Profile Related) Implementation (Prototype)
Web Application (Visitor Panel) Implementation (Prototype)
Prototype Integration & Testing
Prototype Release
Database Library Implementation (Profile Operations)
Database Library Implementation (Group Operations)
Database Library Implementation (Offline Messages)
Web Application Implementation (Group Operations)
Web Application Implementation (Profile Operations)
Web Application Implementation (User Panel)
Web Application Implementation (Visitor Panel)
Profile Web Services Implementation (Complete)
Integration
Alpha Testing
Beta Testing and Debugging
Web Application & Web Services Release
Jabber Server Plug-in:
Plug-in Implementation (Prototype)
Plug-in Implementation (Sending Offline messages)
Plug-in Implementation (Contact Tracking)
Integration
Alpha Testing
Beta Testing and Debugging
Plug-in Release
5.2. Gantt Chart
6. CLASS DIAGRAMS AND DESCRIPTIONS
Database Layer Module:
Web Application Module:
Profile Manager Module:
Message Handler Module:
Group Manager Module:
Jabber Plugin Module:
Class Descriptions:
DBLayer :
This class corresponds to Database Web Services. Its main function is to
provide a call interface to the database server. With help of this class, no other class
interacts with the database server directly. This provides an abstraction and
modularity.
Descriptions of methods:
executeNameAndPasswordQuery : When a user tries to login, her username and
password should be in the database. This methods looks for the related username
and password in the database.
addUser : Adds a new user to the database.
updateUser : When data of a user changes, such as password, it has to be reflected
to the database. This method performs necessary update query.
searchGroup : Searches the database for groups using provided parameters.
Returns an array of Group objects.
getGroupByID : Returns a single Group object according to its ID. If no rows are
returned from the query, null is returned.
saveGroup : Saves a group class to the database.
deleteGroup : Deletes a group from the database.
addMemberToGroup : Adds a user to a group as a member.
addPictureToGroup : Adds a new picture to the group.
addWallMessageToGroup : Adds a new wall message to group wall.
searchProfile : Searches the database for profiles using provided parameters.
Returns an array of Profile objects.
getProfileByID : Returns a single Profile object according to its ID. If no rows are
returned from the query, null is returned.
saveProfile : Saves a Profile class to the database.
deleteProfile : Deletes a profile information from the database.
getOfflineMessages : Returns the saved offline messages of a user as a Message
array.
addOfflineMessage : Adds an offline message to the database.
saveTrackingInfo : Saves a contact tracking log which is received by the jabber
plugin.
getTrackingInfo : Retrieves contact tracking info(s) from the database. Return value
is a Track_Info array.
getTrackingRegistrations : Returns the tracking registrations of a user as a
Tracking_Registration array. When user X wants to track user Y, she has to register
for contact tracking for user Y.
addTrackingRegistration : Creates a new contact tracking registration in the
database.
deleteTrackingRegistration : Cancels an existing tracking registration and deletes it
from the database.
Profile :
This class represents a profile entity. It has many fields which are parts of a
user profile, such as occupation and gender. There get and set methods for each of
these fields. Other than get and set methods there save and load methods which are
described below.
saveToDB : Saves the data of the class to the database using the saveProfile method
of the DBLayer class.
loadFromDB : Loads a profile information into the Profile object. Uses
getProfileByID method of the DBLayer class.
Profile Manager:
As the name implies, this class manages profiles.
searchProfile : Searchs profiles among the database. Returns the result as a Profile
array. Uses searchProfile method of DBLayer class.
createProfile : Creates a new profile. Uses the saveProfile method of DBLayer
class.
getProfileByID : Gets a profile from the database according to its ID. Uses
getProfileByID method of DBLayer class.
deleteProfile : Deletes a profile. Uses deleteProfile method of DBLayer class.
Group:
This class represents a profile entity. Other than its get and set methods, it
provides saveToDB and LoadFromDB functions which are similar to the related
methods of Profile class.
Group Manager:
This class manages groups.
searchGroup : Performs a search among the groups. Uses searchGroup method of
DBLayer class.
getGroupByID : Gets a group from the database according to its ID. Uses
getGroupByID method of DBLayer class.
createGroup : Creates a new Group. Uses the saveGroup method of DBLayer class
to save the Group to the database.
addMemberToGroup : Adds a user to a group as a member. Uses
addMemberToGroup of DBLayer class.
addPictureToGroup : Adds a new picture to the group. Uses addPictureToGroup
of DBLayer class.
addWallMessageToGroup : Adds a new wall message to the group wall. Uses
addWallMessageToGroup of DBLayer class.
deleteGroup : Deletes a group. Uses deleteGroup method of DBLayer class.
Tracking Info:
This class contains data of a contact tracking result. Each instance of this
class is like an entry in a log which records presence of IM users. Instances of these
classes are created by the jabber Plugin, and saved to the database via DBLayer
class. When the tracker user becomes online, tracking data is pulled from the
database and displayed to user by the web application. This class has no methods
other than get and set methods.
Tracking Registration:
When a user wants to track another user’s presence, she registers for contact
tracking, and an instanced of this class is generated. Jabber Plugin gets these
registrations from the DBLayer class using the getTrackingRegistrations method.
This class has no methods other than get and set methods.
Tracker :
This class detects the packets which are going through the Openfire server. It
saves the presence information when a tracked user’s presence information
changes. It maintains a list of tracking registrations.
Message :
This class represents an instant message entity. Other than get and set
methods, it has a send method which sends the message via its connection property.
This connection property is obtained from the user class, when the message is
created.
Offline Message Handler :
This class detects the packets which are going through the Openfire server,
like the Tracker class. If the packet is a message packet and the receiver is offline,
the message is saved to the database to be sent later in time.
User :
This class represents a user, and is used by User Application and Visitor
Application. It has a connection property which represents a XMPP connection,
and it maintains received messages in a queue. The client via web method calls
pulls these messages over JavaScript. Methods other than the get and set methods
are below.
saveToDB : Adds a newly created user to database.
login : The user logins to system with this method. This method creates and
activates the XMPP connection.
getNextMessage : Returns the next message from the message queue. This method
is called from client JavaScript.
handleIncomingMessage : This is a callback method which is invoked by the
AGSXMPP library when a new message is received.
handlePresenceInfo : This is a callback method which is invoked by the
AGSXMPP library when new presence information is received.
sendMessage : Sends an instant message using the Message class.
Visitor Application :
This class provides services to the visitor. It sends and receives messages
with sendMessage and ReceiveMessage classes respectively. sendXML and
ReceiveXML methods are used to handle XML traffic which carry data other than
messages. This methods make file transfer and nudge (MSN) possible.
User Application :
This class provides services to the registered IMBO user. It provides all
functionality that is provided by the Visitor Application. Below methods provide
the exclusive functionality.
searchGroups : Using the Group_Manager class, groups are searched and results
are displayed to the user.
createGroup : User can create a new group by this method.
addPictureToGroup : User can upload a picture for a group which she is a member
of.
writeToGroupWall : With this method, a user can write a text message to group
wall.
membershipRequest : User can join an existing group.
newTrackingRegistration : When a user wants to track an IM user, she registers to
contact tracking with this method.
getTrackingResults : Presence information is displayed to user like a log.
searchProfile : Using the Profile_Manager class, profiles are searched with respect
to provided criteria. Results are displayed to the user.
saveProfile : User can either create a new profile or update the existing one with
this method.
Profile Web Service :
This class provides services to import and export data from and to third party
applications. It uses an instance of the Profile_Manager class to perform the
necessary operations.
7. SEQUENCE DIAGRAMS
Login and Message Operations of Visitor:
Sign-up and Login Operations to IMBO System for Candidate User:
Profile Manager Operations of IMBO User:
Group Manager Operations of IMBO User:
Tracking Operation of IMBO User:
8. TESTING
8.1. Test Plan
Our group intends to use dynamic testing as we are planning to run IMBO with
a set of test cases in all the development stages. We have decided on that the developer
of each unit of IMBO will conduct unit testing on his/her part in the project; for the
remaining testing phases, we are planning to work together. We will apply white box
test as being testers; us; have access to the internal data structures, code, and
algorithms.
8.2. Unit Testing
Database Layer Module:
Test Case: Can “Create Group” information be saved in Database correctly?
Operation: Groups will be tried to be created via Group Processor Sub module
manually.
Success: Continue testing Group Processor Sub module
Failure: Group Processor Sub module; namely code written in ADO.NET; will be
inspected.
Test Case: Can “Membership Request” be saved in Database as a “Created
Membership” correctly?
Operation: Memberships will be tried to be created via Group Processor Sub
module manually.
Success: Continue testing Group Processor Sub module
Failure: Group Processor Sub module; namely code written in ADO.NET; will be
inspected.
Test Case: Can “Searched Group” information be fetched from Database correctly?
Operation: Created groups will be tried to be fetched via Group Processor Sub
module manually.
Success: Start testing Profile Processor Sub module
Failure: Group Processor Sub module; namely code written in ADO.NET; will be
inspected.
Test Case: Can “Profile to be Saved” be saved in Database correctly?
Operation: Manually created profiles will be tried to be saved in Database via
Profile Processor Sub module manually.
Success: Continue testing Profile Processor Sub module
Failure: Profile Processor Sub module; namely code written in ADO.NET; will be
inspected.
Test Case: Can “Searched Profile” information be fetched from Database correctly?
Operation: Created profiles will be tried to be fetched from Database via Profile
Processor Sub module manually.
Success: Continue testing Tracking Information Processor Sub module
Failure: Profile Processor Sub module; namely code written in ADO.NET; will be
inspected.
Test Case: Can “Tracking Information” be saved in Database correctly?
Operation: Manually created “Tracking Information” will be tried to be saved in
Database via Tracking Information Processor Sub module manually.
Success: Start testing Offline Message Processor Sub module
Failure: Tracking Information Processor Sub module; namely code written in
ADO.NET; will be inspected.
Test Case: Can “Offline Message” be saved in Database and be fetched from
Database via Offline Message Processor Sub module correctly?
Operation: Firstly; manually created offline messages will be tried to be saved in
Database; and then they will be tried to be fetched from Database via Offline
Message Processor Sub module manually.
Success: Start testing Jabber Plugin Module
Failure: Offline Message Processor Sub module; namely code written in
ADO.NET; will be inspected. will be inspected.
Jabber Plugin Module:
Test Case: Can “Tracking Information” be detected from Jabber Server via
Tracking Info Processor Sub module correctly?
Operation: Before sending the information to other modules, tracking information
is detected by printing the session related values we got from sessionListener
interface on the Openfire admin console.
Success: Start testing Offline Message Processor Sub module
Failure: Tracking Information Processor Sub module; namely the code written in
java using eclipse tool; will be inspected.
Test Case: Can user’s instant status be detected from Jabber Server via Offline
Message Processor Sub module correctly for the “Offline Message” feature?
Operation: As in the tracking case, the presence information of the user at an
instance of time is checked by printing the related information to the Openfire
admin console.
Success: Continue testing Offline Message Processor Sub module
Failure: Offline Message Processor Sub module; namely code written in java using
eclipse tool; will be inspected.
Test Case: Can “Offline Messages” be sent to Jabber Server via Offline Message
Processor Sub module correctly?
Operation: This part of the Offline Message processor is related to the transfer of
the message content when the user is offline. The action to be checked is whether
the transfer is successful or not.
Success: Start Integration Testing
Failure: Offline Message Processor Sub module; namely code written in java
related to the transfer of message content; will be inspected.
The remaining modules will be tested during Integration Testing.
8.3. Integration Testing
Test Case: Can Profile Web Services import profile information from Facebook
correctly?
Operation: Using the Facebook API, Profile Web Services will import and save
sample profile(s) to database.
Success: Continue Integration Testing
Failure: Profile Web Services Module; namely code written in C# .NET as an XML
Web Service will be inspected.
Test Case: Can Profile Web Services Module export profile information to third
party applications correctly?
Operation: Since third party applications will be using profile service via web
service calls, a simple client will be created, which will be using methods of Profile
Web Services.
Success: Continue Integration Testing
Failure: Profile Web Services Module; namely code written in C# .NET as an XML
Web Service will be inspected.
Test Case: Can Jabber Plugin Module send offline messages to Database Layer
Module correctly?
Operation: Interoperation via web service will be checked whether the soap packets
are valid and the results are correct.
Success: Continue Integration Testing
Failure: Jabber Plugin Module; namely code written in java (related to web
service); will be inspected.
Test Case: Can Jabber Plugin Module receive offline messages from Database
Layer Module correctly?
Operation: Some offline messages will be inserted to the database manually. When
plugin module pulls offline messages from database services, and prints the output
to the Openfire console.
Success: Continue Integration Testing
Failure: Jabber Plugin Module; namely code written in Java which tracks presence
information and sends the offline messages when the related user becomes online.
will be inspected.
Test Case: Can Web Application Module receive contact-tracking information
from Database Layer Module correctly?
Operation: Sample contact tracking information will be inserted to the database
manually. Using the web application, displayed contact tracking information will
be compared against actual data.
Success: Continue Integration Testing
Failure: Web Application Module; namely code written in C# as an ASP.NET
application will be inspected.
Test Case: Can Web Application Module send profile information to Database
Layer Module correctly?
Operation: A sample profile will be created and saved within the web application.
Results will be checked by viewing the related database table manually.
Success: Continue Integration Testing
Failure: Web Application Module; namely code written in User Application class
will be inspected.
Test Case: Can Web Application Module receive profile information from
Database Layer Module correctly?
Operation: After saving a sample profile, the profile will be reloaded within the
web application and results will be compared.
Success: Continue Integration Testing
Failure: Web Application Module; namely code written in User Application class
will be inspected.
Test Case: Can Web Application Module send messages to Jabber Server
correctly?
Operation: Since the Jabber plugin can receive and process incoming messages, the
messages will be printed to Openfire console as they are received.
Success: Continue Integration Testing
Failure: Web Application Module; namely code written in User Application class
will be inspected.
Test Case: Can Web Application Module receive messages from Jabber Server
correctly?
Operation: Since the Jabber plugin can receive and process incoming messages, the
messages will be printed to Openfire console as they are received. Result will be
compared to the output of the web application.
Success: Continue Integration Testing
Failure: Web Application Module; namely code written in User Application and
User classes will be inspected.
8.4. Security Testing
-We will try to sniff incoming and outgoing data of the web application. If it is
possible, it means a security breach.
-We will try sql injection methods on the forms of web application.
-We will try to connect to database server directly from a remote computer
(Skipping the database web services module).
8.5. Acceptance Testing
It will be the process of making tests on the completed IMBO system. The
tester team and end-users will conduct it. We will use two version of it:
8.5.1. Alpha Testing
Our team members will conduct alpha testing. In this phase of testing, we
will adopt white box techniques in principle.
8.5.2. Beta Testing
IMBO (probably versions of IMBO) will be released to beta testers. As using
IM services is so common all around the world, we think that finding volunteers, as
beta testers will not cause us any problems. We will request from beta testers to
report any bugs that they encounter.
9. SOFTWARE INTERFACE DESCRIPTION
Figure 1: User Interface For Sign-up to IMBO
Figure 2: User Interface for Visitor of IMBO
Figure 3: User Interfaces for Login
Figure 4: User Interface for Creating a Group
Figure 5: User Interface for Group Page