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.
To fulfill the demand for quickly locating and searching documents.
It is intelligent file search solution for home and business.
Related download
Related searches
- ichael anthony allen fisher
- west creek glen allen va
- glen allen va 23060
- hotels glen allen va
- city of glen allen virginia
- zillow glen allen va
- zillow glen allen va 23060
- apartments in glen allen va
- marriott hotels glen allen va
- homewood suites glen allen va
- robert allen marriott
- allen bradley overload heaters chart