University Politehnica of Bucharest

Faculty of Engineering in Foreign Languages

Live Support

Architectural Design Document

Version:29.10.2017

Group name : Team Valor 1242E

Team members : Neagu Iuliana

Vlad Ana-Maria-Nicoleta
Dibl Radu
Isac Dan

Coordinator: Oana Ferche

Summary Table of contents

1. Introduction ...3

1.1. Purpose of the document...3

1.2. Definitions, acronyms and abbreviations. 3
1.3. References.3

2. Projection objectives .4

3. System architecture ...4

3.1. General presentation .4

3.2. Subsystems ...5
3.3.Subsystems Distribution on Hardware/Software
Platform6
3.4. Persistent Data Management.....7
3.5. User Control of Access......7
3.6. Global Flow of Control..7
3.7. Limit Conditions...8

4. Internal assignments ..9

 1. Introduction

1.1 Purpose of the document

This document provides a more detailed architectural overview of the

system, using a range of different architectural views to describe certain
components of the system. Its purpose is to capture and paint the significant
architectural decisions which have been made on the system.

Live Support is an application whose purpose is to exchange real time

messages. The messages, usually short, are transmitted bidirectional between
interlocutors and they can be viewed almost instantly. This chat applications can
be run on computers at distance of hundreds of kilometres, operating at optimal
speed.

The program is like Pc Garages Live Support Feature. One of the

advantages of our app is that we offer the option to request assistance at any
moment. If the users problem has already been solved it can be found in the FAQ
section, therefore the live chat box will not be needed. This will decrease the time
needed to solve new issues.

1.2 Definitions, Acronyms and Abbreviations

Live Support name of the application.

Live Support form of real time direct text based communication between
two or more people using personal computers or other devices, along with shared
software clients.

Peer-to-Peer- software architecture without a central authority that

manages all the communication between modules.

Client-server model software architecture with a central authority that

manages communication between modules.

Microsoft SQL is a relational database management system developed

by Microsoft. As a database server, it is a software product with the primary
function of storing and retrieving data as requested by other software
applications.

1.3 References
Software Requirements Specification Document.
 2. Projection objectives

The application will be able to do the following: create an account, login,

logout, request support, end session, submit feedback, search FAQ (optional),
view support requests and update FAQ (optional).

We want to deliver a stable and easy to maintain version of the application

so that users will have as few problems as possible using the software. The
application would be similar with Pc Garages Live Support Feature, but it would
be faster and easier to interact with.

3. Proposed Architecture Model

3.1. General Presentation

The main architecture of the application is represented by the client-server

model and then the clients would communicate using a peer-to-peer model. One
or more subsystems called servers provide services to one or more clients.

The demand for a service is done usually through a mechanism named

remote procedure call. The flow of control in client and the one in server are
independent, except the synchronization to respond to requests and to receive
results.

To enable the communication between 1 user and 1 admin who are online,
we will use the Peer-to-Peer model. The Peer-to-Peer architecture is a
generalization of the client-server architecture. The flow of control in each
subsystem is independent, except the synchronization to respond to requests. This
architecture model complicates the flow of control at the level of each subsystem
(peer).

3.2. Subsystems

The application is divided in the following subsystems:

Server

Client

Database

The responsibilities of each subsystem are the following:

the clients receive inputs or demands from users, check the data
entered and call the server services. Also the clients have the role of server when
1 user and 1 admin who are connected and try to communicate

the server responds to the demands of clients by performing

transactions with the database

the server authenticates the users, adds new users to the database,
connects 1 user and 1 admin who are online to communicate directly

the database stores users data and ensures the the integrity and the
security of it and avoid redundancy
 3.3. Subsystems Distribution on Hardware/Software Platforms

The application is designed to offer minimal functionalities with minimal

system requirements. The Asp.Net Framework helps in creating an user-friendly
app, secured and web based that will fulfil the needs of the clients.
 3.4. Persistent Data Management

For our application the following data will have to be persistent:

login credentials (username and password)

contact information
message history(optional)

The login credentials will be kept apart from the message history in order
to provide security and prevent accidental unrestricted access to sensitive
information. The persistence of the message history will enable users to access
previous conversations at a later time(optional).

3.5. User Control of Access

Only users that have created an account and have logged in can access
the services offered by our application.

When an user enters his password, his credentials are send to the server,
where they are verified. If the password matches the username, the server allows
access to the conversation interface.

3.6. Global Flow of Control

Firstly, a user would have to register to be permitted to use the application

(he completes some data like the wanted username, the password and some
identifications details like the first name, second name).

After registering, he would be able to login,connect and start chating.

Fig. Global flow of control

 3.7 Limit Conditions

Client

A user should be able to have just one role, so he should be a normal user
or an admin , not both in the same time.

Server

The server would need to be online all the time to serve the clients. It
should also need to have a fast response time (ideally, no latency) such that there
is no delay between giving a specific command from the client and the server
processing that command and returning the result.

Database

The database would have a slow response time if there exists a big
number of entries in it, since a login or a request for the history would need to do
an iterative search through all the users (the matching would be done on the
username).

Also another shortcoming is that the database would not be distributed

and the search would be done in a bigger time.

Fig.Structure of the database

4. Internal assignments
 For the implementation, each one of the team members will be
responsible as follows:

Vlad Ana-Maria-Nicoleta -> frontend client: design the

graphical interface for the client component make it appealing and user
friendly for the users

Neagu Iuliana -> backend client: implement the software

components required for the exchange of messages between clients or
between clients and server

Isac Dan -> backend server: implement the methods designed

to communicate with the client and the connection with the database

Dibl Radu -> database management: design the database

and create the tables inside it with specific columns such that information
is found in an optimal fashion

Entire team : interconnect all components and solve any

underlying bugs.