Allen School



Design Doc

Team: Whiteboard Interview

----------------------------------------------------

Design Decision Rationale (The High Level Architecture)

----------------------------------------------------

We considered 2 main systems of Whiteboard Interviewer.

1) Logistics: steps users must complete before getting to interview page.

This includes account creation, session association, identification, settings, etc.

2Client program: This is what runs when the client is using the program.

It includes client side code, and server side code that will handle syncing 2 client programs.

----------------------------------------------------

A word on high-level design vs actual implementation

----------------------------------------------------

These aspects provide a basis for modules. However,the

implementation may decompose components even more. Certain

aspects that are intuitively to group at a high-level

may involve different implementations, constrained by

our program language, platform, etc. Moreover, there may

be particular design patterns that necessitate components

not accounted for on a Requirements analysis based architecture.

Our UML is far from formal, and it doesn’t make sense to speak

of “classes”. We are going with PHP and Javascript, and speaking

of components, we speak of code that does a particular job.

A .php page, is an object in itself. We can provide an API to

said “object” that accepts parameters and return values.

As you can see in the database / data access analysis below,

the developers / implementors have domain specific knowledge

about certain areas of the implementation that the management

part of the team knows vaguely about. This is currently not part

of our UML, because we want to emphasis the relationship between

the Requirements aspects and corresponding architecture.

We do not want to be bogged down with very specific implementation

details / class complexity, at least at this stage. In the next iteration,

we will include said details.

Finally, note we indicate our analysis of the systems are at "near UML level".

They do not specify the data communicated between modules. We leave

the UML to speak for itself...

----------------------------------------------------

Logistics Systems: (Near UML Level)

----------------------------------------------------

What logistics exactly are we handling? One feature of

Whiteboard Interviewer is allowing users to create or join

an "Interview". Interviews are associated with a unique URL

and also a password to enter them. This password, based on

our requirements doc, is emailed to the user when they

create the room. Aspects of this system:

- Setting up interview. Client side program (form) a

server side processing. Server side code interacts with a

database.

- Joining an interview session.

- User email notification & One-time-password

- Retrieving interview credentials (lost password, etc)

----------------------------------------------------

Client Program System: (Near UML Level)

----------------------------------------------------

Our decomposition of the UML for the client program will change alot.

t involves communication between 2 client programs, with a server in between

There are issues of concurrency, and real time communication.

We are prototyping various APIS, and with it, design patterns.

So, be aware that our UML for the client program is tentative and

not as close to the final product as the Logistics systems. Aspects:

- Chat Client. See below for more thorough analysis.

- Video communication. (See below).

- Collaborative Text Editor. (See below)

- Syntax Highlighting. (Subcomponent of text editor)

-----Video.js

This creates a video stream with another person in the same uniqueUrl Room. We are still researching implementations of video communication. But, we believe a server will be needed to initiate a video stream. Once that has been done, the two client programs communicate directly. Our plan is to have a prototype of video communication by next week, so we can finalize the design from the client program extending outward from video.js

-----chat.js

This component has 2 aspects. Submitting data user types to the server, to sync with all clients on the unique URL. Second, the component pings the server for

new chat data. Albeit similar to the collaborative text editor, the architecture and design pattern for this component is much simpler.

The idea Tuan had in mind was an array of messages, and submitting a message

is appending a message to the end of the array. Syncing the client chat data

with the servers version is ensuring that they have the same number of messages. However, the developer implementor this feature will have a more insightful thought about this when the time comes.

----editorsync.js

This component synchronizes communication with the server.

This is a more challenging problem than chat.js because people can delete text...

Moreover, an interviewer might edit an interviewee content, etc.

We have to deal with issues of concurrency on the server program.

We are still researching implementations for this as well, so our diagram may change.

----------------------------------------------------

Some Notes

----------------------------------------------------

We are still implementing a prototype for the colloborative text editor and video

communication. The choice of implementation will drastically alter the second diagram.

So, this is tentative.

----------------------------------------------------

Regarding Design Tips

----------------------------------------------------

Parallel

You can see how we can split the team between the logistics system and the client

program. Moreover, you can also see how different components of the client program

can be developed simultaneously.

Even in the logistics program, we can implement a Join Session without implementing

a create session component. We can just add data to the DB manually for

implementation....

Model Independent of View

For the .html / .php pages, we can seperate the DOM / JS / and CSS.

On the server side, most of it is service calls. At any rate, we have the data stored

on the server. We just need to specify our database such that the DB implementor

and coders are on the same page.

Simplicity

We will be merging some components. Right now, we redirect from one page to another

. Essentially, a state change. We can refactor later on to have ajax calls, and update

the page the user is currently on.

----------------------------------------------------

Database Design

----------------------------------------------------

Currently we have a design (See image Database #0) that is pretty parse where there are

two tables(validations and schedules) that refer to 'interviews' table.

Realizing that both of those tables are also a main attribute of an interview,

we decided to merge those two table into 'interview' table instead.

Other than that we notice one part that might gone wrong in the first schema,

where the 'participants' (relation) table might have a many-to-one relation,

while we want a exactly one-to-one relation. We don't want an interview session

map to two or more sessions. In order to change that, we also merge the

table's attribute into the interview and gain an exactly one-to-one relation.

Having that in mind, we decided to create just two tables which are called

interviews and users in our new schema (database #1).

These are the description for each attribute:

Database: Interviews tables

----------------------

Interviews tables stored all the data that only relate about an interview.

id

This attribute will uniquely identify an interview. Id is represented as an

integer in the table, and it increase automatically as we add new interviews.

If we don't delete any interviews then it does mean we can only have 2^31

interviews stored but as a new web application having that much interview is

still a long way to go.

date_created

This attribute will store the data when the interview was created.

date_scheduled

This attribute will keep track of when the interview going to held such that no one

can enter to the interview session before the assigned time, and to make expiration

of the interview session.

title

The title of interview where create can create any title he wants to describe the

interview.

description

While title only have a little space, we have a description field to store as many as

the creator wants to describe his/her interview sessions or specification.

password

This attribute will store the password to the corresponding interview. Password will

be given to each participant by email and it will be asked when entering interview session.

interviewee_id

The user id that will act as an interviewee in this interview session

interviewer_id

The user id that will act as an interviewer in this interview session, and also the creator

of the interview.

Database: Users table

----------------------

This table store the data of all users that use our application

id

Just like id in interviews table, however this one is separate to the id in the

interview table and only uniquely identify a user.

email

This will one important attribute in users table where each user also uniquely identified

by email.

name,gender, phone

are just complementary data that we will gather to make future statistic analysis

--------------------------------------------

Query Scenarios

--------------------------------------------

Using this schema, we will store our data efficiently, and get an interview data

easily and it will be fast.

For example:

I want to find who are the participant with the interview id 54367.

Our query will be just:

Select name

from interviews i

join users u1 on i.interviewee_id = u1.id

join users u2 on i.interviewer_id = u2.id

where i.id = 54367;

* it looks like that our query will be in O(n^3) but it will not be because we have indexes,

that will speed up the query process!

I want to get the password for that interview:

Our query will be just:

Select password

from interviews

where id = 54367;

--------------------------------------------

Extra stuff for our database (UML Database Helper)

--------------------------------------------

In our opinion, that are still not pretty convenient for people in the group that are using

the database but not really know about query stuff. We have that under control!

We created two helper PHP programs to achieve that:

- DBConnectionHelper.php

- QueryHelper.php

Currently, they are pretty simple but they will grow as much as the need of our project.

For DBConnectionHelper:

- it helps to connect to our database

- run query on the database

- auto quoting

In the other hand we have QueryHelper and its only purpose is to run core query, such as;

- createSession(title,date,password,interviewer_id,interviewee_id)

This function will automatically insert a new tuple into interviews tables without having

someone know about query

- addUser(id,name,...,email)

Will add a new tuple into users table while checking if same one exists.

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download