W10_EWS_Code_Orange_Detailed Design_FINAL.docx

ohiofulvousΛογισμικό & κατασκευή λογ/κού

15 Αυγ 2012 (πριν από 4 χρόνια και 10 μήνες)

540 εμφανίσεις





Code
Orange






Electronic Whiteboard System


Detailed Design Document

for



































January 31
, 2010

Prepared For:


Mr. Frederick Dixon,

Blindside Networks


Mr. Edmund Strange,

Algonquin
College


Prepared By:

Derrick Krishn, Project Leader

Tristan Bali

Nouh El
-
Masri

Wei Warren Hoang

Carl Johnson

Adam Wiacek

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
2

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



List

of Figures

Figure 1: Electronic
Whiteboard System Context Diagram

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

8

Figure 2: Calibration System Diagram

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

10

Figure 3: Electronic Whiteboard System High Level ERD

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

13

Figure 4: Detailed ERD

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

14

Figure 5: Architectural Diagram

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

21

Figure 6: UML Overall Class Diagram

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

23

Figure 7: Drawing Class Diagram

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

24

Figure 8: Module Class Diagram

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

24

Figure 9: Pen Class Diagram

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

25

Figure 10: Whiteboard Class Diagram

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

26

Figure 11: BigBlueButton Login Diagram

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

28

Figure 12: Calibration Program

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

29

Figure 13: Calibration points Diagram

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

30

Figure 14: Calibration Save To Diagram

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

30

Figure 15: Save To Box Diagram

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

31

Figure 16: Electronic Whiteboard Interface Diagram

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

32



List of Tables

Table 1: Architectural Design Narrative

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

22


List of Report Sections

1.0 I
ntroduction

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

5

1.0.1

Project Initialization

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

5

1.0.2

Purpose of the Project

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

5

1.0.3

Users of the Product

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

5

1.1 Application and Development Environments

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

6

1.1.1

Application Environment of the Proposed System

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

6

1.1.1.1

Hardware Requirements

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

6

1.1.1.2

Software Requirements

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

6

1.1.1.3

Data Requirements
................................
................................
................................
....

6

1.2 Develo
pment Environment of the Proposed System

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

7

1.2.1

Hardware Requirements
................................
................................
................................
..

7

1.2.2

Software Requirements

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

7

1.
2.3

Data Requirements

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

7

1.2.4

Research Requirements

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

7

1.3 Functional Requirements

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

8

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
3

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.
3.1

The Scope of the Work


Proposed System’s Context Diagram

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

8

1.3.2

Functions Provided by the Project

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

11

1.3.2.1

Hardware Requirements

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

11

1.3.2.2

Software Requirements

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

12

2.0 Data Design

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

13

2.0.1

Electronic Whiteboard


High Level ERD

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

13

2.0.2

Electronic Whiteboard


ERD

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

14

2.0.2.1 Session variable

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

15

2.0.2.3 Global Data Structures

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

18

2.0.3 Record Layout Description

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

20

3.0 Architectural and Component
-
level design

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

21

3.0.1


Program Structure and Architecture Diagram

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

23

3.0.2

Object Oriented Design


Individual class diagrams

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

24

3.1 Software Interface Description

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

27

3.1.1

External Machine Interfaces

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

27

3.1.2

External System Interfaces

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

28

3.1.3

Human Interfaces

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

29

4.0 Restrictions, Limitations, and Constraints

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

33

4.1 Deadline

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

33

4.2 Solution Con
straints

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

33

4.3 Look and Feel Requirements

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

33

4.4 Usability Requirements

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

33

4.5 Personalization and internationalization Requirements

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

34

4.6 Ease of Learning

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

34



Li
st

of
Appendices

Appendix A: Data Dictionary

Appendix B: Coding Standards

Appendix C: Project Gantt Chart

Appendix D: Detailed Design Phase


Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
4

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



Contact Information




Client




Mr. Frederick Dixon






Blindside Networks



246 Queen Street, Suite 200



Ottawa, Ontario



K1M 1P6




(613) 695
-
0264



ffdixon@blindsidenetworks.com




Project Group Members





Derrick Krishn, Project Leader




derrick.krishn@gmail.com





Tristan Bali




bali.tristan@gmail.com





Nouh El
-
Masri




nouh.elmasri@gmail.com





Wei Warren Hoang




wei.warren.hoang@gmail.com





Carl Johnson




johnson.h.carl@gmail.com





Adam Wiacek




adam.wiacek2@gmail.com





Project Advisor




Edmund Strange, Professor



Algonquin College


Woodroffe Campus



1385 Woodroffe Avenue



Ottawa, Ontario



K2G 1V8




(613) 727
-
4723 Extension 3483

edmund.strange@gmail.com

strange@algonquincollege.com



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
5

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.0

I
ntroduction

The initialization of the project and the understanding of the driving forces behind the client’s
request for a product
are

important to understand at the very onset of the project.


1.0.1

Project Initialization

This is a
s
tatement of
s
cope prepared by Code Oran
ge for
t
he Electronic Whiteboard System
sponsored by Mr. Fred Dixon, Blindside Networks. The project group leader is Derrick
Krishn, and the project team members are Tristan Bali,
Nouh El
-
Masri, Wei Warren Hoang,

Carl Johnson, and
Adam Wiacek
. The project
will proceed according to the project plan
annotated in the Appendi
x A Gantt charts
and have a completion date of
April 23rd
, 2010.


1.0.2

Purpose of the Project

Code Orange will address the business requirements of Blindside Networks by designing and
implement
ing
t
h
e Electronic Whiteboard System
to be migrated into BigBlueButton. Hybrid
classes have become a more common means of teachi
ng and allowing abroad students

access
to lectures. This creates an opportunity for remote students to participate in live lectu
res
through BigBlueButton. BigBlueButton is an expanding project focused on making a more
interactive environment for teachers and students. The
Electronic Whiteboard System

will be
incorporated to this project to further enhance to interactivity of the Bi
gBlueButton.


1.0.3

Users of the Product

The users of this system will include all students and professors who use BigBlueButton
software. Students vary in expertise of computing knowledge; however basic internet surfing
skills are required to use BigBlueButton

and the Electronic Whiteboard System.



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
6

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.1

Application and Development Environments

This section addresses the hardware and software requirements for the development and
implementation of the project.


1.1.1

Application Environment of the Proposed System

This
section identifies both the hardware and the software that must be in place in the
operational (non
-
testing) environments and configuration details.


1.1.1.1

Hardware Requirements

The client agrees to reimburse
C
ode
O
range 100% of all hardware costs releva
nt to setup,
deployment, and testing of the Electronic Whiteboard System within the BigBlueButton
environment. This reimbursement does not cover any cost associated with
notebooks/netbooks, or network infrastructure.


1.1.1.2

Software Requirements

BigBlue
Button is an open source project which requires no additional software to be
mandated. BigBlueButton software is already in place, and its current iteration has no
limitations or requirements that need to be fulfilled.


1.1.1.3

Data Requirements

The clien
t must ensure that the shared object
which

resides within
BigBlueButton
-
apps
remains available and accessible; Non
-
compliance with this data requirement will pose a
high
-
risk situation for
the
design analysis
. This would result in a
medium risk situation

w
hich
could jeopardize the acceptance testing schedule for the remote communications
aspects of the project.




Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
7

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.2

Development Environment of the Proposed System

The Linear Sequential Software Engineering paradigm, coupled with prototyping has been
chosen for
this project because the client’s requireme
nts are well known.

1.2.1

Hardware Requirements

The client will supply the following hardware development system to the project group
within one
week
1

of

the signing of the
s
tatement of
s
cope:




Four

Nintendo Wii remotes



Four Wii Remote Tripods Adapter



Two

Bluetooth adapte
r



Twelve AA Rechargeable batteries



One AA and AAA charger



Two

I
nfrared

Pen




Four Wii Remote Tripods



One Mini Projector



One iMac Computer


1.2.2

Software Requirements

The system will be developed using the current versions of Microsoft Visual Studio, Adobe
Flex Builder,
Actionscript 3, Java Netbeans, and C #
. The project documentation will be
developed using the current versions of Microsoft
Project, Visio, and

Word
. Si
nce the project
group h
as licensed copies of all of this

software and is
familiar with its use, these CASE tools
are

considered low risk.


1.2.3

Data Requirements

The client will supply documentation to inform Code Orange of any modifications made to
the
BigBlu
eButton
-
apps shared object, at any given stage of development of the Electronic
Whiteboard System.



1.2.4

Research Requirements

The project group will have to research the operation of

BigBlueButton using the client
-
supplied website and forums. Research will al
so include device functionality with
BigBlueButton server and configuration details which pertain to web browsers talking to
hardware devices.






1

Hardware may be provided earlier, but no later th
an the week of February 1.

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
8

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.3

Functional Requirements

Functional requirements are functions or features that must be included in the system
to satisfy
the project needs and

to be acceptable to

the client.


1.3.1

The Scope of the Work


Proposed System’s Context
Diagram

The Electronic Whiteboard System context diagram depicted in Figure 1 contains all of the
external entities that produce or consume
data and an external entity that represents inter
-
system communication. As such, the context diagram assists in bounding the scope of the
software requirements and also assists in determining the system interfaces.


0
-------
Electronic
Whiteboard
System
Professor
Session Information
New Whiteboard
Drawing Points
Pen Properties
Undo Drawing
Redo Drawing
Clear Canvas
Whiteboard
Updated Canvas
Updated Pen Properties
BigBlueButton
Server
Query Drawing List
Drawing List
Context Diagram


Electronic Whiteboard System
(
EWS
)



Figure
1
:
Electronic Whiteboard System Context Diagram




Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
9

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



The
Electronic Whiteboard System

is the software system that will be developed to meet the
requirements of the
Electronic Whiteboard System

statement of scope
.


There are t
wo exter
nal entities that both

play an integral role in the operation of the
Electronic Whiteboard System
, briefly described as follows:




Professor:

Allows teachers to draw, create, undo, redo, and clear the Electronic
Whiteboard.



BigBlueButton
Server:
















Sends and receives information from external system.





Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
10

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



0
-------
Calibration
System
ITS
Technician
Calibration Coordinate
Calibration Coordinate
BigBlueButton
Server
File Write Confirmation
Write Calibration File
Context Diagram


Calibration System
Calibrated Whiteboard

Figure
2
: Calibration System Diagram

There are two external entities that both play an integral role in the operation of the
Calibration
System, briefly described as follows:




ITS Technician:

Calibrates the Wii Remotes, creates and saves a configuration file to the
BigBlueButton server.



BigBlueButton
Server:

Sends and receives configuration file information.




Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
11

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.3.2

Functions Provided by the
Project

This section explicitly identifies the hardware and software functionality for the project. Each
hardware and software requirement is prioritized as follows:




Essential:

These requirements must be included in the system.



Useful:

These requirements

are those that would reduce system effectiveness if left out.



Desirable:

These requirements are those that are not part of the core, but make the system
more attractive to the users.


In addition, each requirement will be identified using a unique identifier: the letters “HW”
for hardware, “SW” for software, followed by the priority category


“E” for Essential, “U”
for Useful, or “D” for Desirable, and a number representing the order
of priority within the
category. This notation will be used in other documents to cross
-
reference the requirements
back to this statement of scope.



1.3.2.1

Hardware Requirements

The Electronic Whiteboard System has the following essential hardware requi
rements:

HWE1

The Electronic Whiteboard System will use
two

Nintendo Wii Remotes.

HWE2

The Electronic Whiteboard System will use a host computer.

HWE3

The Electronic Whiteboard System will use a Bluetooth receiver.

HWE4

The Electronic Whiteboard System mus
t have a projected surface.

HWE5

The Electronic Whiteboard System must have a calibrated infrared pen.

HWE6

The Electronic Whiteboard System must receive input from
two

Nintendo Wii remotes
;
which will transmit to
a Bluetooth receiver on
the host computer.


HWE7

The Bluetooth device, Wii remotes, and infrared device will all be in range of each other.

HWE8

The Electronic Whiteboard System configuration file must be stored on the
BigBlueButton server
.

HWE9

The Wii remotes will remain stationary.

HWE10

The
i
n
frared pen will have an uninterrupted line of sight with the Wii remote
(
s
)
.






Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
12

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



1.3.2.2

Software Requirements

The Electronic Whiteboard System will provide an electronic drawing surface within a
web conferencing application, any user with sufficient privileges will have access to this
whiteboard. The Electronic
W
hiteboard system will broadcast
information
to
remot
e
users that are

connected
to
the

current

session.


Software

requirements for both systems

are prioritized in the following paragraphs.


Essential Requirements


The Electronic Whiteboard System has the following essential software requirements:


SWE1

The I
TS Technician must calibrate the host computer, used by a Professor, before an
Electronic Whiteboard System can be initialized with the BigBlueButton web
application.

SWE2

To start a new whiteboard module, the professor must login to the BigBlueButton serv
er
;

provide a session ID number, and the associated password. Once validated, the professor
will have access to functionality applicable to their terms of usage.

SWE3

The p
rofessor must be able to draw on the whiteboard and change the drawing properties
of

the pen. Drawing properties in this case means color and thickness of the pen.

SWE4

Professor must be able to clear the
canvas of the
whiteboard.

SWE5

Professor must be able to undo and redo information o
n

the whiteboard.

SWE6

The Electronic Whiteboard
must be pre
-
configured in such a way that the controls are
simplistic when

a Professor chooses to use it.

SWE7

The Electronic Whiteboard must be able to transmit coordinates

of the drawings

to the
BigBlueButton Server. Th
ese

coordinates are then

transmitted to all
user
s

connected with
the same session ID #.


Useful Requirements


The

Electronic Whiteboard System has no useful software requirements.


Desirable Requirements


The Electronic Whiteboard System has no
desirable

software requirements



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
13

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



2.0

Data Design


This section of the document will explain and describe the data structures that will be used in the
Electronic Whiteboard System. Data structures included in
the Electronic Whiteboard System
are
passed among components.
A description of the gl
obal data structures,
the record layout
description, and session variables will be covered.

2.0.1

Electronic Whiteboard


High Level
ERD


The primary purpose of the High Level ERD is to provide a view of the Electronic
Whiteboard System relationship amon
gst the entities,
as depicted in

figure

3

below.



creates
Drawing
Pen
Whiteboard
Module
has
uses

Figure
3
: Electronic Whiteboard System High Level ERD


Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
14

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



2.0.2

Electronic Whiteboard


ERD

The primary purpose of the ERD is to provide a view of the
data required by the Electronic
Whiteboard System and its relationship amon
gst the entities, as depicted in

figure

4

below.


creates
Drawing
-
drawpoints
:
Vector
<
Point
>
coordinateupdates
):
void
retrieveDrawingCoordinates
():
Vector
<
Point
>
sendDrawingCoordinates
(
Vector
<
Point
>
has
uses
Pen
-
color
:
ColorTransform
-
propterties
:
char
-
thickness
:
int
getPenProperty
():
Pen
handlePenEvent
(
MouseEvent e
):
void
penOn
():
void
setPenProperty
(
ColorTransform color
,
int thickness
):
void
Whiteboard
-
canvaspaper
:
Canvas
-
deleted
:
Vector
<
Drawing
>
-
drawn
:
Vector
<
Drawing
>
-
menu
:
Menu
clearCanvas
():
void
retrieveDrawnItems
():
Vector
<
Drawing
>
initializeMenu
(
Menu menu
):
void
initializeSharedObject
():
void
redoDrawing
():
void
undoDrawing
():
void
updateCanvas
():
void
Module
-
calibrationCoordinates
:
Vector
<
float x
,
float y
>
-
configuration
:
File
-
errorState
:
boolean
-
menuinformation
:
char
-
sessionInformation
:
String
-
sharedObject
:
SharedObject
loadConfiguration
(
File configuration
):
void
getState
():
boolean
parseSessionInformation
(
String sessionInformation
):
String
setState
(
boolean errorState
):
void
startElectronicWhiteboardSession
():
void

Figure
4
:

Detailed ERD



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
15

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



2.0.2.1
Session variable


A
configuration file is needed for the calibration of the Electronic Whiteboard Module. In
this case the session name of the BigBlueButton web application is needed for the use of
the Module class. The session name is copied into the variable sessionInformat
ion and
the Module object will need to parse the session name; then use it to search and retrieve a
configuration file from the file system of the
BigBlueButton
server. A configuration file
c
ontains the calibration requirements

for

each room. This ensures
precision when
drawing with the infrared pen.


2.0.2.2
Internal software data structure


The Electronic Whiteboard System consists of internal software d
ata structures found in
Figure 3 and 4
.
The
Drawing,

Pen
, and Whiteboard

objects are all considered to be
internal.


2.0.2.2.1

Drawing Class


The objects on the canvaspaper will be noted as vector of drawings. The first button press
on the drawing area of the Electronic Whiteboard System by the infrared pen signifies the
starting point of a drawing and when it is depressed it will create a drawi
ng object.


Attributes
:


draw
p
oints:
Vector
<float, float
>

-

a vector of x and y coordinates which combine to form
a drawing.


Private/Public Methods
:


startElectronicWhiteboardSession(): void

This function will create the drawing area for the module cla
ss which will be referred to
as the canvaspaper.

Parameters
: None

Return value:

None


retrieveDrawingCoordinates():
Vector
<Point>


Retrieves the drawing points from the shared object then updates the canvas.

Parameters:

None

Return value:

Vector
<Point>
-

a
vector of point o
bjects that will form a drawing
object


sendDrawingCoordinates (
Vector
<Point> coordinateupdates): void



This function updates the canvas.


Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
16

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



Parameters:

coordinateupdates:
Vector
<Point>
-

used to update and map the
drawing
area region.




Return value:

None


2.0.2.2.2
Pen Class


The Pen class will have two attributes; color and thickness. When the cursor is over the
drawing area, it will change into a pen cursor. This will notify a user that they are on the
surface of a drawing area referred to as canvaspaper. Holding down the mou
se down
button while on the canvaspaper will create a drawing.


Attributes
:


color: ColorTransform


sets the color of a pen object


thickness: int


sets the thickness of a pen object


properties: char


a set of characters to work with the menu item f
ound in the Whiteboard
class


Private/Public Methods
:


getPenProperty(): Pen

Retrieves

the pen properties.

Parameters:
None

Return value:

Returns the current pen properties; color and thickness


handlePenEvent(MouseEvent e): void

The handler for pen event
s.

Parameters:

e: MouseEvent


The Pen inherits its events from the MouseEvent
class. When the button on the infrared pen is being pressed and held
it will act as if the left mouse button is being pressed


this will call
penOn() function.

Return value:

no
ne


penOn(): void

While the button on the infrared pen is being pressed

and
held the drawing points will be
sent to the shared object in the
BigBlueButton

server with its associated session
.

Parameters:

None

Return value:

None






Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
17

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



setPenProperty(ColorTransform color, int thickness): void

S
ets the color and the thickness

properties

of
the

Pen object
.

Parameters:

color: ColorTransform


the color for the current Pen object
.


thickness
: int


the thickness for
the current Pen object
.

Return value:

None


2.0.2.2.3

Whiteboard Class


The Whiteboard object will have functionality similar to a physical whiteboard; it will
have a drawing area referred to as the canvaspaper. A user will have the ability to create
drawi
ngs on the canvas and may choose to undo/redo drawing(s). The associated internal
data structures such as the Pen

class

and Drawing
class
will be used to draw on the
canvas. The Whiteboard object will also allow a user to change th
e properties of the Pen
o
bject.

Attributes
:


File configuration


file object that will contain the configuration that comes from th
e
BigBlueButton

server configuration file.


canvaspaper: Canvas


the drawing area of the whiteboard


deleted: Vector<Drawing>


a vector of drawin
gs that were deleted from the drawing
area of the whiteboard


drawn: Vector<Drawing>


a vector of drawings that are currently on the drawing area
of the whiteboard


menu: Menu


container for the menu items color and thickness


Private/Public Methods
:


clearCanvas():void


C
lears the drawings that are on the drawing area

Parameters:
None

Return value:
None


initializeMenu(Menu menu): void

C
reates the menu item
;

cont
ain
s

all the available colors, thickness, and
sizes as sub
-
menus for the pen properties
.

Pa
rameters:

menu: Menu


used to create a sub
-
menu system for the color and
the thickness of the pen object.

Return value:

None



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
18

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



i
nitializeSharedObject(): void

W
hen the Module creates the Whiteboard object a shared object is initialized and will be
ready
to contain the drawings points
.

Parameters:

None

Return value:

None


redoDrawing(): void

Redraws previously
deleted drawing
and stores it in the drawn vector
.



Parameters:

None



Return value:

None


retrieveDrawnItems():
Vector
<Drawing>


R
etrieves all the

drawings that are drawn on the on the canvas
.

Parameters:

None

Return value:

Returns a vector of drawings and null

if there are no drawings
found.


updateCanvas(): void

Updates

the canvas
;

every time it is being drawn on
.



Parameters:

None



Return value
:

None


undoDrawing(): void

Deletes

the
latest

drawing
and stores it in the deleted vector.

Parameters:

None

Return value:

None

2.0.2.3
Global Data Structures


This section will describe the data structures that are available to major portions of the
architecture in the Electronic Whiteboard System. The Module data structure will be
considered global to the architecture of the
BigBlueButton

perspective as needs a
ccess to
communication and proxy objects found on the
BigBlueButton

server.

2.0.2.3.1 Module Class


Attributes
:


b
oolean errorState


used for error detection of the Electronic Whiteboard Module
.


char menuInformation


used to determine which menu item h
as been selected by the
moderator; whether it is the color or thickness menu item
.


String sessionInformation


will be used as a container for the session name of
BigBlueButton

web application
.


SharedObject
:

sharedObject


acts as a temporary storage for

the drawing points, also
Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
19

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



used by the
BigBlueButton

server to redistribute the moderators drawings to session
viewers


Vector
<float x, float y> calibrationCoordinates


used to store the calibration coordinates
from the file it is being read from


Private
/Public Methods:


g
etState(): Boolean

This function g
ets

the current
error state
of the Electronic Whiteboard Module
.

Parameters:

Non
e

Return value:

Returns the value of the errorState attribute


setState(boolean errorState): void

This function c
hanges the

current

error

state

of the Module class
.

Parameters:


errorState: Boolean


used to change the
errorState attribute

of the




Module class.

T
rue means that there a
re faults that happened




during runtime.

F
alse means that the Module

failed to do

some o
f




its tasks or it has

entered

an erroneous state.

Return value:

None



parseSessionInformation(String sessionInformation):
String

This function p
arse
s

the session name of the
BigBlueButton

web application session
name
to extract the

i
nformation needed
to load

the proper configuration file.

Parameters:

sessionInformation: String


The
session name of the

BigBlueButton

web application session
.

This string contains the

character set that
will match the

proper configuration in a file
located in the
BigBlueButton

server file system.

Return value:

String


returns the

parsed

room number
from

the session
name

that will

be used to load the configuration file off of the
BigBlueButton
.




loadConfiguration(File Configuration): void


O
pens the
config
uration file

associated with the
parsed

character

set from the
BigBlueButton

server file system.



Parameters:


fileConfiguration: file


file object that will be used to extract the





c
alibration coordinates from a file needed by the moderator of the




Electronic Whiteboard System
.



Return value:

None



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
20

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



2.0.3 Record Layout Description

The Electronic
W
hiteboard System will be accessing a configuration file for

the Wii
remotes. This file will be generated and stored by the calibration software. This file will
be located on the BigBlueButton server with the following specifications:


Filename:

<CAMPUS><BUILDING><ROOM NUMBER>.conf


Example:

WT127.conf


Contents:

4{float, float /n}


Example:

3.45523, 4.34332

5.23232, 7.35774

9.32422, 9.43583

6.23245, 8.19383



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
21

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



3.0

Architectural and Component
-
level design


The architectural design defines the relationship between major structural elements of the
software, the "design p
atterns" that can be used to achieve the requirements that have been
defined for the system, and the constraints that affect the way in which architectural design
patterns can be applied. The Electronic Whiteboard System is a module that is a web applicati
on
that resides on a Red5 application server. Any database manipulation that occurs within the
BigBlueButton Application server is handled by its database server, this information is then
transmitted back through the system to the user(s).
Figure 5
depicts

BigBlueButton’s
architectural design model.

Architectural Diagram


C
/
S Database
Store here
1
.
5
in
.

x
1
.
3
in
.
User
Electronic Whiteboard
Presentation
Presentation
Logic
only
executed here
Client PC
Red
5
Application
Server
Application
Logic
only
executed here
Data
Manipulation
Logic
only
executed here
Database Server
Information
and
service
responses
Data
and
Service
requests
Response to Data
manipulation
request
Response to create
,
Read
,
update
,
or
Delete
1
or more records
Unlock records
Updated tables
Records
(
only
)
locked
until
client
releases
table
Read requested
rows and columns
only

from the
tables

Figure
5
:
Architectural Diagram

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
22

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



Architectural Design Narrative

Table
1
:

Architectural Design Narrative




Name

Hardware Functionality

Client PC

Client PC must have internet/intranet capability to connect to the Red5 server,
in which there session is being hosted. These machines must be flash capable.

Red5 Application Server

The Red5 application server contains Bi
gBlueButton and its core elements,
this server will host the Electronic Whiteboard System module. The
Electronic Whiteboard System will reside within BigBlueButton, and is stored
as such on this server, all requests for the Electronic Whiteboard System wil
l
be processed here, and broadcasted too all active session listeners.

Database Server

All database request queries from either Electronic Whiteboard System or
BigBlueButton will be processed and/or returned here. All Session
information, user account
status, and operational constraints for each
electronic whiteboard system, will reside on this server.

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
23

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



3.0
.1


Program Structure and Architecture Diagram

Object Oriented Design


During the analysis of the
Electronic Whiteboard System
, we created an ERD
to help
model what data the system uses and how it interacts with internal and external data
stores. The purpose of this section will be to refine the elementary information from the
analysis ERD into more implementation specific representations that can b
e processed by
the computer based system, into business or domain
-
specific rules.


U
ML Overall Class Diagram

creates
Drawing
-
drawpoints
:
Vector
<
Point
>
coordinateupdates
):
void
retrieveDrawingCoordinates
():
Vector
<
Point
>
sendDrawingCoordinates
(
Vector
<
Point
>
has
uses
Pen
-
color
:
ColorTransform
-
propterties
:
char
-
thickness
:
int
getPenProperty
():
Pen
handlePenEvent
(
MouseEvent e
):
void
penOn
():
void
setPenProperty
(
ColorTransform color
,
int thickness
):
void
Whiteboard
-
canvaspaper
:
Canvas
-
deleted
:
Vector
<
Drawing
>
-
drawn
:
Vector
<
Drawing
>
-
menu
:
Menu
clearCanvas
():
void
retrieveDrawnItems
():
Vector
<
Drawing
>
initializeMenu
(
Menu menu
):
void
initializeSharedObject
():
void
redoDrawing
():
void
undoDrawing
():
void
updateCanvas
():
void
Module
-
calibrationCoordinates
:
Vector
<
float x
,
float y
>
-
configuration
:
File
-
errorState
:
boolean
-
menuinformation
:
char
-
sessionInformation
:
String
-
sharedObject
:
SharedObject
loadConfiguration
(
File configuration
):
void
getState
():
boolean
parseSessionInformation
(
String sessionInformation
):
String
setState
(
boolean errorState
):
void
startElectronicWhiteboardSession
():
void

Figure
6
:

UML Overall Class Diagram

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
24

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx




3.0
.2

Object Oriented Design


Individual class diagrams

This section will provide a detailed description of each class using individual class
diagrams and algorithmic descriptions for complex operations.


3.1.2.1 Drawing

Class


The drawing class contains a vector of x and y coordinates that combine to create
the
drawing.


Drawing

-
drawpoints :
Vector
<float, float>

Drawing()

-
GetDrawingCoordinates () : void

-
sendDrawingCoordinates(
Vector
<Point> coordinateupdates):
void

Figure
7
:

Drawing Class Diagram




3.1.2.2
Module

Class


The
Module class is responsible for initializing primary components of the Electronic
Whiteboard system, setting default properties, setting up session identification, and
lo
cating calibration information.


Module

-
configuration: File

-
errorState: boolean

-
menuI
nformation: char

-
sessionInformation: String

-
sharedObject: SharedObject

-
calibrationCoordinates :
Vector
<float, float>

-
getState(): boolean

-
loadConfiguration(File configuration): void

-
parseSessionInformation(String sessionInformation): String

-
s
etState(boolean errorState): void

-
startElectronicWhiteboardSession(): void

Figure
8
:

Module Class Diagram





Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
25

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



void loadConfiguration(File configuration) {


get filename from sessionInformation


open configuration file


read
coordinates


store in calibrationCoordinates


close configuration file

}


String parseSessionInformation(String sessionInformation) {



String RoomNumbers



parse the last 3 digits from sessionInformation and store in RoomNumbers



return RoomNumbers


}



void startElectronicWhiteboardSession()

{




initialize canvas object



initialize pen object


}



3.1.2.3
Pen

Class


The Pen class is an attribute class, which manages all properties of the pen, such as
colour, thickness, and its default properties.


Pen

-
thickness: int

-
color: ColorTransform

-
properties
: char

-
getPenProperty(): Pen

-
handlePenEvent(MouseEvent e): void

-
penOn(): void

-
setPenProperty(ColorTransform color, int thickness): void

Figure
9
:

Pen Class Diagram


void
handlePenEvent(MouseEvent e) {



IF coordinates of e are on the canvas




Change cursor to pen cursor



ELSE




Change cursor to arrow



IF left click

IF coordinates of e are on the canvas


Call penOn()

return

}



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
26

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



void PenOn() {


While mouse down is
pressed



create drawing



IF cursor leaves the canvas




break


return

}



3.1.2.4 Whiteboard Class


The Canvas class is the surface of the whiteboard. The information for all of the drawing
objects is stored in this class. The canvas also keeps the infor
mation for undone
drawings so they can be redone.




void ClearCanvas() {


move drawings from drawn into deleted


call UpdateCanvas()


return

}

void initializeMenu(Menu menu) {


create the menu with default settings


return

}

void initializeSharedObject() {


create shared object


return

}


void RedoDrawing() {


move last deleted drawing into drawn

Whiteboard

-
canvaspaper : Canvas

-
drawn :
V
ector<float, float>

-
d
eleted : V
ector<float, float>

-
menu : Menu

-
clearCanvas(): void

-
initializeMenu(Menu menu): void

-
initializeSharedObject(): int

-
redoDrawing(): void

-
retrieveDrawnItems(): V
ector<Drawing>

-
undoDrawing(): void

-
updateCanvas(): void

Figure
10
:

Whiteboard Class Diagram

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
27

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx




call UpdateCanvas()


Return;

}


void UpdateCanv
as {



clear the canvas



draw all drawings that are in the drawn vector



return

}


void UndoDrawing {



move last drawn drawing into deleted



call UpdateCanvas()



return

}

3.1

Software Interface Description

3.1
.1

External Machine Interfaces

I
R Pen

The
IR pen has an infrared light where the felt is normally located. It is
important that while using the IR pen you allow at least one of the Wii
remotes to have line of sight on the light bulb. There is a single button
located on the pen. This button acts li
ke a left mouse click when pressed.
By moving the IR pen around the drawing surface, you will move the
cursor as if you were controlling it from a mouse. To draw on the white
board, simply move the cursor over the drawing surface with the pen and
hold down

the button
.

Wii Remotes

Although the Whiteboard can function with a single remote, it is
recommended that at least 2 remotes be used. Place the
Wii

remotes so
that they are facing the drawing surface from two different angles. This
will reduce the chance of both remotes losing line of sight on the IR pen. It
is also important that the remotes are secured so they do not move after the
system has been
calibrated.

Bluetooth Receiver

Make sure the Bluetooth receiver is plugged into the host computer and
the appropriate drivers are installed.

Projector

If you are setting up your own your own projector, make sure the
projected surface is within reach and wi
thin range of the Wii remotes.
Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
28

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



After you have the hardware setup, you will then have

to run the
calibration program


3.1
.2

External System Interfaces





Big Blue Button login


Figure
11
: BigBlueButton Login Diagram



To access the electronic whiteboard, you will have to login to the Big Blue
Button Server. If you intend to start a new whiteboard session, you will
have to login as a moderator by entering “mp” as the password. If you
inte
nd to connect to an already existing session, you can login as an
attendee by entering “ap” as the password.





Starting a whiteboard session

When starting a whiteboard session, you will be prompted to enter a
session name. If you are using a preconfigure
d whiteboard, end the session
name with the room number of the preconfigured room. The whiteboard
will appear within the big blue button environment.



Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
29

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx




3.1
.3

Human Interfaces

Calibration Program


Step 1:
When r
un
ning

calibration software
,
Wii
synchronization

with

the
Bluetooth adapter
must occur
or
an
error

dialogue will appear.

Figure
12
:

Calibration Program


Step 2:
Select the C
alibrate

button to start the calibration
.





Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
30

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



Step 3:

Calibrate the
Electronic Whiteboard

as each target is displayed.
When finished an external file will contain the calibration coordinates
(.
conf
). This file will be written

to the current directory of the calibration
progr
am
.




















Step 4: Select the
Save To…

button

to save the calibration file to the
BigBlueButton server.



















Figure
13
:
Calibration points Diagram

Figure
14
: Calibration Save To Diagram

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
31

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx




Step 5: Enter the server information where the
calibration file will be
saved then press the Ok button.












Figure
15
: Save To Box Diagram

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
32

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



The Electronic Whiteboard Interface



Figure
16
: Electronic Whiteboard Interface Diagram


The
Whiteboard will allow you to do the following things:

-

To draw on the whiteboard, simply mouse over it and hold down the left mouse/pen
button.

-

To
erase the previous

drawing on the whiteboard, simply click the undo button located at
the bottom of the whiteboard module.

-

To redo a drawing, click the redo button located at the bottom of the whiteboard, beside
the undo button.

-

To adjust the thickness, click the drop down
box with the title “Thickness” and select the
desired thickness from the selections.

-

To change the color of the whiteboard pen, click the color palette located at the bottom
right of the whiteboard. This will open the palette to display all of the colors a
vailable.

-

To clear the whiteboard, click on the clear button located on the bottom of the whiteboard
module.




Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
33

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx



4.0

Restrictions, Limitations, and Constraints


4.1
Deadline



The deadline for this project is
April 23
, 2010
.



The Electronic Whiteboard System’s dev
elopment due date will be pending the
outcome of the contract dispute between the

OPSEU

(Ontario Public Service
Employees Union)

and Algonquin

College

management
.


4.2
Solution Constraints



The system must be easy to use

such that the Electronic Whiteboard
System can
be easily interfaced with its hardware components
.



The product will use the user
-
supplied Wii remotes (2), Bluetooth receiver, and
host computer.



The host computer must have internet capabi
lity, and must be flash capable

to
connect to
the

BigBlu
eButton server.



The
Bluetooth
device must be within range, and be capable of receiving signals
from 2 Wii remotes
.



The Wii remote must be:



Within range of Bluetooth device.



Within line of sight of Bluetooth
device
.



Within range of the projected surface



The

projected surface

must be within arm
s

reach.


4.3
Look and Feel Requirements

The Interface

The product must comply with corporate branding standards, and will be
configured within the BigBlueButton configuration file.


4.4
Usability Requirements

Ease of
use



The product must be user friendly, such that controls are simple and easy to
understand.



The product must be able to communicate with the BigBlueButton server, on a
real time basis.

Blindside Networks

Detailed Design

Document

Team: Code Orange


Page
34

of
34


©2010

Algonquin College

Team Code Orange

ohiofulvous_e0e9e6d1
-
789c
-
411d
-
8a18
-
1df450888f81.docx





The product must have a help file, with detailed instructions.



The pro
duct must be able to work on multi
-
platforms.



The
calibration software

must be able to install

and function

on multi
-
platforms.


4.5
Personalization and internationalization Requirements

Language

The Electronic Whiteboard System will be part of
BigBlueButton server, and such
that the configuration of the Electronic W
hiteboard System is dependent on

BigBlueButton. As the predominate region language, English will be use
d.


4.6
Ease of Learning

Training

Since the product will be used by Educational institutes, students, and professors
alike, minimal amounts of training will be required to use this product. ITS
technicians will be setting up and configuring all hardware components local to
educational inst
itute. After receiving 15


30 minutes of training, a professor or
student
should

be able to use the Electronic Whiteboard System with minimal
effort.







Appendix A:


Data Dictionary




Blindside Networks

Detailed Design

Document

Team: Code Orange


A
-
2


Physical

Data Table, Data Flow
or Entity

Functional
Requirement
Number

Type

Size


Allow Null

(ERDs)


Notational Description

Example

Drawing


drawpoints

SWE3

Vector
<Point>


Dynamic


YES

drawpoints =
Vector<float,
float>

Vector

<coordX,coordY>
drawpoints

Module


calibrationCoordinates

SWE6

vector<float,float>

Dynamic

NO

calibrationCoordinates =

Vector<
float, float>

Vector

<x, y>
calibrationCoordinates

configuration

SWE6

File

OS dependent

NO

configuration =
File

File configuration

errorState


SWE 1

SWE 2

SWE 3

SWE 4

SWE 5

SWE 6

SWE 7


boolean

4 bytes

YES

errorState

= boolean

boolean errorState

menuinformation

SWE3

char

1

byte

NO

Menu Information = *
information regarding the menu
*

char menuinformation

sessioninformation

SWE2

String

Dynamic

NO

Session Information = * a
unique number assigned to a
specific
session

*

String sessioninformation

sharedObject

SWE7

SharedObject

Dynamic

NO

sharedObject

= dynamic

SharedObject sharedObject



Blindside Networks

Detailed Design

Document

Team: Code Orange


A
-
3



Physical

Data Table, Data Flow
or Entity

Functional
Requirement
Number

Type

Size (bytes)


Allow Null

(ERDs)


Notational Description

Example

Pen


color

SWE3

ColorTransform

Dynamic

NO

color = 1{pen color}1

ColorTransform color = new
Color
Transform
(255,255,255)

properties

SWE3

char

1

byte

NO

properties = 1 {pen colour +
pen thickness}
1

char properties

thickness

SWE3

int

4 bytes

NO

thickness = 1{pen
thickness}1

int thickness

Whiteboard


canvaspaper

SWE3

SWE4

SWE5

Canvas

Dynamic

NO

canvaspaper = 1{Canvas
Object}1

Canvas

CanvasPaper;

deleted

SWE5

Vector
<Drawing>

Dynamic

YES

deleted = 0
{
Drawing

Object}m

Vector
<drawpoints>
deleted

drawn


SWE3


Vector
<
Drawing>

Dynamic

Yes

drawn =
0
{Drawing Object}m

Vector
<drawpoints>

drawn

menu

SWE3

Menu

Dynamic

NO

menu = 1{ActionScript
Object}1

Menu menu








Appendix B:


Coding Standards




Blindside Networks

Detailed Design

Document

Team: Code Orange


B
-
2


Comments

-

Date of change

-

Name

-

What the Function does

-

Where and When the method is called.

o

Example:

Java/ActionScript

/***************************************************

**

Date:

**

Name:

**

Function Description:

**

Execution Point:

****************************************************/


Function Header

-

Function Name

-

Parameter List

-

Return value

-

Date

-

Purpose

-

Version

-

Revision name

o

Example:

Java/ActionScript

/****************************************************

** Name:

** Parameter List

**

Parameter:

**

Return:

** Function Description:

** Execution Point:

** Date:

** Purpose:

** Version:

** Revision Name:

******************************************************
/


Naming conventions
:


Classes

Functions

Variables

Capitalize first letter of each word

verb Noun

Java Notation

ex. SetProperties

↑ ↑



lowercase uppercase


ex. updateCanvas





Blindside Networks

Detailed Design

Document

Team: Code Orange


B
-
3


Java Coding Standard Reference



ActionScript 3 Coding Standard Reference

Adobe ActionScript 3 Coding Standards


Adobe Acrobat
Document







Appendix C:


Project Gantt
C
hart




Blindside Networks

Detailed Design

Document

Team: Code Orange


C
-
2







Blindside Networks

Detailed Design

Document

Team: Code Orange


C
-
3









Appendix D:


Detailed Design Phase




Blindside Networks

Detailed Design

Document

Team: Code Orange


D
-
2