Project Number: LLP-LdV-ToI-09-CY-167919
Task 2.1 and 3.1 – Architectural Synthesis and System Design v2
WP Number:
WP Lead:
Task Lead:
Task Title:
3
UCY
UCY
Task 3.1 – Architectural Synthesis and System Design v2
Partners Involved:
Author:
InTraCoM, UCY, WebRelations
Marios Tziakouris, Andreas Zagos, Polydwros Kyriakoullis
Status:
X
X
Start date of project:
Duration:
Preliminary result (for use within the WP)
Final (for use within the Project)
Public (Homepage or interested parties)
2009-10-01
24 months
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Project Number: LLP-LdV-ToI-09-CY-167919
This project has been funded with support from the
European Commission. This report reflects the views only
of the author, and the Commission cannot be held responsible
for any use which may be made of the information
contained therein
Task 2.1and 3.1
Page 2 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Table of Contents
1. Introduction ...................................................................................... 4
2. System Architecture ......................................................................... 7
2.1. General Architecture ................................................................................... 7
2.2. System Considerations ................................................................................ 9
2.3. Logical Architecture ................................................................................... 10
2.4. Presentation Layer ..................................................................................... 12
2.5. Application Layer ....................................................................................... 15
3. System Design ............................................................................... 18
3.1. Introduction ............................................................................................... 18
3.2. Application Layer Components Design ...................................................... 19
3.3. Data Layer Design ...................................................................................... 25
4. Implementation Plan ...................................................................... 29
4.1. Introduction ............................................................................................... 29
4.2. Implementation order ............................................................................... 29
5. Security Mechanisms ..................................................................... 31
5.1. Software system security........................................................................... 31
6. Conclusions ................................................................................... 34
Task 2.1and 3.1
Page 3 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Attention: This document is the evolution of Task 2.1 - Architectural Synthesis and System
Design v1 (listed as Result No.5 in Interim Report) deliverable with additions regarding section
3 (System Design). The rest of the document contains only minor changes.
1. Introduction
The purpose of this section is to define the aims and objectives of the deliverable in a
clear and concise manner. Additionally in this section a brief analysis and description
of the outline of the document will be provided along with short explanations as to
the purpose of each section. The purpose and overview of the deliverable will be
included in this section along with the definitions, acronyms and abbreviations mentioned throughout the deliverable.
The scope of this document is to describe the Overall System Architecture and specify the architecture environment of the SEILING platform (available at
http://www.thejobgame.eu). This architecture provides the organisation structure of
the system in terms of its components and interactions with other systems as well as
the necessary user interfaces. Based on the analysis of the user requirements and the
content of the learning scenarios (WP1) the consortium will provide a detailed architecture of the system that will guarantee availability, responsiveness, expandability
and security. The design will also emphasize on the usability of the system having in
mind the education and skills of the platform’s potential users. System architecture
will include the logical views of the various components of the system such as database, middleware, interfaces with other systems and network connectivity.
The document describes the general architecture of the SEILING platform under a
layered approach that has been adopted by the project. It provides an overview of
the technologies that are utilized in SEILING architecture, in terms of methodologies,
development environments, technologies etc. It describes in detail the physical and
logical architecture of the SEILING platform and its components and distinguishes
between those that will be developed within the project framework and those that
will be integrated in order to complement the functionality envisioned for this platform. For each functional component of SEILING their role in the overall system architecture is presented along with a short description of the data handled.
This deliverable has been based on the results obtained in the user requirements
procedure of WP1 and more specifically on Task 1.2 deliverable (Technology Framework) and Task 1.3 deliverable (User Requirements). This deliverable along with Task
3.1 (Detailed Design and Implementation) will form the basis for the implementation
of the SEILING platform.
This document is organized as follows:

Section 1 contains the purpose of the document.
Task 2.1and 3.1
Page 4 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919



SEILING
Architectural Synthesis and System Design
Section 2 describes the Architecture of the SEILING platform. Specifically, it
describes:
o
The high-level architecture of the SEILING platform and the system
considerations for an on-line training system enriched with a “gaming” aspect.
o
The logical architecture environment. This section defines the system
infrastructure, the logical infrastructure and additional critical components for the successful implementation of the SEILING platform.
It explains how it is divided in the presentation, application and persistent storage tiers, provides an overview of the technologies that
are used to realize the described architecture and concludes describing how the architecture is formed when applying the necessary security mechanisms.
Section 3 describes the SEILING System final design. This section describes in
detail the following:
o
the specification and design of the main functional components operating in the SEILING Platform, as they have been identified in section 2 (Architectural Synthesis) based on the requirements captured
during work package WP1 of the project. The methodology that is
used consists of two phases: the analysis, part of which was covered
during WP1, which aims to investigate the problem and specify what
the platform should offer; and the design, which specifies how the
previously identified requirements would be achieved. Due to the iterative development methodology adopted by the project, the analysis and design will be refined and enlarged at the end of the implementation phase. These adaptations will be presented in revised version of this deliverable which will be made available prior to the
evaluation phase (WP4)
o
the analysis and design of SEILING database. This section intends to
provide as much detailed view of the SEILING system’s data model as
possible, e.g. the structures used to persist information and data
necessary for the successful operation of the system.
Section 4 describes the Implementation Plan for the SEILING implementation
phase. In detail it describes the order in which the various components will
be developed and how they will be integrated together to build the SEILING
platform.
Task 2.1and 3.1
Page 5 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919

SEILING
Architectural Synthesis and System Design
Finally, section 5 provides general information regarding the Security Infrastructure of the SEILING environment, focusing in software security, network
security as well as user security. The described security infrastructure should
be followed within the development process.
Task 2.1and 3.1
Page 6 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
2. System Architecture
The purpose of this section is to describe SEILING platform Architecture under a multi-tiered perspective. Initially, the General Architecture is described in detail along
with the overall approach we have followed to derive the architecture. Additionally
the overall High Level Architecture of the SEILING platform is presented in detail.
2.1. General Architecture
The following figure provides an overall description of the path followed during the
design of SEILING architecture.
Technology
Framework
(Task 1.2)
Scenarios
Definition
(Task 1.1, 2.2)
SEILING
architecture
Functional
Requirement s
(Task 1.3)
NonFunctional
Requirements
(Task 1.3)
Figure 1 – Path for deriving SEILING architecture
In deriving the architecture, input from all the previous tasks has been sought. Specifically the analysis of technologies that can be used in such a project has been thoroughly reviewed along with the recommended technologies for each specific requirement deriving from the project proposal.
Additionally, the initial scenarios definition was taken into consideration since the
scenarios (courses) represent the main component of the platform and thus the architecture needs to be capable of supporting them. Furthermore, the outcomes from
the analysis of the user requirements provided a significant input to the derivation of
the SEILING architecture.
Both functional and non-functional requirements of the users are considered. Some
of the non-functional requirements have been derived form the consortium experience in developing internet applications whereas almost all of the functional re-
Task 2.1and 3.1
Page 7 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
quirements were derived from the analysis of the questionnaires submitted by selected users.
The high-level architecture of the SEILING platform is illustrated in figure 2.
Figure 2 – High-Level Architecture
The high-level architecture is divided in two areas, the back-end and the front-end.
The back-end will host all major functionality and data whereas the front-end will
handle all user interactions.
More specifically, the back-end will include all the data necessary for the operation of
the system as well as the data access methods that will be used to store and retrieve
data from the database. Data such as registered users, registered trainers, courses,
forum information, and scenarios’ details will be hosted in the selected database
system. Additionally the courses development and hosting environment will be part
of the back-end along with all the logic functions that is included with every
course/game. The functionality of the System to allow other trainers to upload content in the form of courses/games will also be provided by the back-end systems.
Finally the back-end will also host all the necessary data and functionality for the
supporting tools such as forum, chat, Q&A as well as the reporting and grading functions (evaluation).
Task 2.1and 3.1
Page 8 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
The front-end is entitled with the task of accommodating all user interactions and in
general allows the users to utilize the functionality and data offered by the back-end.
It is very important, given the target group of our platform, to design and implement
a user-friendly and robust user interface in order to ensure that our System will make
ground among the community of our users. The primary function of the front-end is
to run the game-play, which in essence is the presentation to the user of the scenarios of the courses/games. The front-end is also responsible to handle all user interactions in going through the courses and collect/send all the relevant information to
the back-end for further processing. It will keep track of the progress of the user
within a course as well as provide to the user the necessary information to complete
the course and obtain the results. Other functions to be included in the front-end is
the presentation of the various tools such as chat, forum and the various management capabilities which will be available to the users as well as to the trainers.
2.2. System Considerations
The primary purpose of the SEILING platform is to provide eLearning training to a
specific group of users, enriched with a “gaming” flavour in order to entice these
people to use the platform and educate themselves.
For that reason one of the primary considerations of the SEILING platform is to utilize
a “gaming” engine that will allow the consortium to develop the scenarios designed
in WP1 and WP2 into targeted interactive courses/games. The “gaming” engine must
be capable of being integrated with the rest of the functions envisioned for the
SEILING platform as well as be capable of supporting basic programming logic and
relevant data access functions.
A second consideration is the user interface. Given the unwillingness of our target
group to use computers, the user interface must be such that will not panic the users
the first time they are going to use the system. The user interface needs to be attractive, simple and with a human touch rather than a strict desktop type interface with
textboxes and buttons. It shall give the impression that the user is about to a play a
game on a TV or a gaming console than a software program that asks the user to
accomplish some tasks. On top of that, the user interface needs to be aligned with
the relevant internet standards and if possible account for the various disabled accessibility requirements.
Another consideration is the flexibility/openness of the platform. It is envisioned that
the platform not only will support external trainers in uploading their courses/games
in the SEILING platform but also it will allow for the quick and streamlined integration
of collaboration and other tools in order to complement the services initially offered
by the SEILING platform. Example of such tools can be recruiting and job seeking
tools, advanced chat functions etc. The overall architecture, and process of delivering
it, will need to accommodate changes as new tools definitions are completed. The
architecture of the platform must follow an approach from the onset that does not
Task 2.1and 3.1
Page 9 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
rely on a ‘fixed’ set of functionalities provided by a certain technical solution/module,
which subsequently will require much effort and time to modify.
A last consideration of the System architecture is the localization. The SEILING platform is simultaneously targeting six different markets (Cyprus, Greece, Italy, Germany, Slovenia, Ireland) and therefore there is an inherent need to customize not only
the content and supporting tools of the eLearning platform but also the courses/games. The platform architecture must be such that support multilingual content
and further customization from the onset since it is envisioned that more EU markets
will join this effort.
2.3. Logical Architecture
The purpose of this section is to describe SEILING logical architecture under a multitiered perspective, present an overview of the used technologies and describe the
security schema that will applied in SEILING, as well as how this schema affects the
system’s architecture. The architecture of SEILING under the tiered perspective is
presented in the next figure and it is described below in more detail. SEILING platform is based on a traditional 3-tier architecture that includes a Presentation Layer,
an Application Layer and a Data Layer.
Task 2.1and 3.1
Page 10 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Figure 3 – SEILING logical architecture
Before deriving the final architecture of the SEILING system, the technology partners
decided to investigate further the ability of our chosen LCMS system (MOODLE) to be
integrated with FLASH which is our chosen gaming engine. This is because there were
some concerns among the partners that although the specification of MOODLE mentions specifically that FLASH integration is inherently supported, in reality this is only
possible for simple animations and video playback.
For that reason all the technology partners were engaged into further research for
indications to reinforce the previous decision for using an LCMS system. The research has expanded into the building of prototype models integrating Moodle and
FLASH. Those models were further enriched to include the possibility of database
interaction from the integrated environment of FLASH and MOODLE.
The result was that the integration of FLASH with MOODLE is possible. However, the
complexities faced for building those models along with the absence of existing examples that make use of this possibility, forced the technology partners to make a
decision not to follow the integration path. Although the benefits of using an LCMS
are numerous (see deliverable for Technology Framework Definition), the risk of be-
Task 2.1and 3.1
Page 11 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
ing involved into difficult technical tasks (i.e. immature integration paths) was
deemed as very high and the consortium decided not to take it.
With that decision in place, the technology partners further investigated ways to
replace the functionality to be offered by the LCMS with other components. The decision was that the necessary functionalities for the SEILING system can be built using
our chosen programming platforms which is FLASH for gaming and PHP/MySQL for
the rest. The combination of both can effectively provide all the functionalities promised for the SEILING system. Definitely not to the extent of what an LCMS would do
but to the extent that the SEILING system is attractive, usable, open and above all
free from any unnecessary complexities. In any way, not all the functionalities of
LCMS systems are necessary for SEILING and even if the integration was to take
place, many of them would go unused.
The functionalities envisioned to be delivered by the LCMS system are now branded
as supported applications in the overall system architecture and it include the following:








User’s forum
User’s chat application
Evaluation component (grading, feedback)
Reporting
Courses depository
User Management
Administrator Management
Other tools
2.4. Presentation Layer
The presentation layer is of prime importance for the SEILING platform. Given the
peculiarities of our user group it is expected that their computer literacy and in general their relationship with the Internet and application will be at very low level.
Therefore, the consortiums will place significant efforts in selecting the technologies
to be used for the user interface and in general designing the presentation layer so
that it will reflect the special needs and requirements for our target user group.
Although there are various options for creating advanced user interfaces such as
Windows Forms, WPF (Windows Presentation Foundation), Java Swing in our case
and based on the Users requirement analysis the option is to go with a web-based
user interface. The reason for this is better explained in the User Requirements deliverable (WP1). Having this in mind there two options available: the HTML/CSS based
option and the FLASH based option.
Flash and HTML/CSS both have their place on the internet. One needs to understand
the strengths and weaknesses of each to choose which one is the right choice.
Task 2.1and 3.1
Page 12 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
FLASH is best suited for animated multimedia demonstrations.
 Advantages

o
Freedom of Design: Flash allows you to place media elements anywhere on the page without the restrictions of CSS positioning.
o
Greater Interactivity: Flash allows you to combine animations,
sounds, and video to create a rich, interactive experience for the user.
o
Better Media Integration and Display: Flash permits the integration
of all forms of media and ensures that it is displayed uniformly on all
compatible browsers. This includes uniform font handling, graphics
rendering, etc
Disadvantages
o
Limited Compatibility: Flash requires a Macromedia Flash plug-in.
This is available only on select browsers and operating systems, and
is not compatible with most mobile platforms including the iPhone.
Many institutions and companies do not allow the installation or use
of such plug-ins. Furthermore, it is not handicap accessible and cannot be modified to assist those with poor eyesight. All of these factors will reduce the number of users capable of viewing your site, potentially cutting out a valuable client base.
o
Search Engine Problems: Because flash is multimedia (not text) oriented, its content does not organically enter major search engine databases like Google and Yahoo. This means that our site will not be
fully indexed by search engines, significantly decreasing organic traffic and lowering if not eliminating your site from many keyword
searches.
o
Print Problems: For the same reason that flash sites cannot be indexed by search engines, they cannot be easily saved or printed. The
text content of a flash site cannot be separated from the site for use
by a viewer.
HTML/CSS are best suited for content based websites.
 Advantages
o
Task 2.1and 3.1
Universal Compatibility: HTML and CSS are the standard for all
browsers, operating systems, and hardware platforms. They will ap-
Page 13 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
pear largely the same on PCs, Macs and mobile devices alike. They
require no additional plu-gins, and demand extremely low system
requirements. This ensures that all users who visit your site will be
able to access your site’s content.

o
Greater Accessibility: A site created with HTML and CSS will be fully
accessible to the handicapped, hard of seeing, and non-english
speakers. The text based content allows for your site to be enlarge,
spoken aloud, and translated into other languages. It also allows your
content to be saved and printed by users.
o
Search Engine Optimized: A HTML/CSS website is ideal for search engine optimization. A fully text-based site allows for full indexing of all
content on your site so to connect your site to the most relevant
keywords and phrases.
o
Easily Updated and Upgraded: The simple structure of a HTML/CSS
website allows for it to be easily updated to meet ever changing web
standards. Even more importantly, the universal nature of these sites
allows for the seamless integration of APIs and third party frameworks such as open source blogs and behind the scenes web applications and CMS panels.
o
Flash Element Compatible: While a Flash oriented site cannot include
HTML and CSS inside of flash elements, HTML and CSS oriented sites
can include flash elements. If any pages on your site require the multimedia capabilities of Flash you can simply include the appropriate
flash element on that page.
Disadvantages
o
o
Limited Animations and Interactive Multimedia Effects: Although
HTML/CSS sites allow for the integration of many simple Javascript,
jQuery, and other DOM animations and effects, it cannot rival the
power of Flash animations. Flash simply has the ability to be more
flashy.
Limited Design Options: While HTML/CSS sites can create a rich variety of effects using Javascript, jQuery, AJAX, and others languages,
there are multimedia platforms that can match the design flexibility
of Flash.
o
Task 2.1and 3.1
Page 14 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Given the above analysis and the requirements of the SEILING platform it appears
both technologies are suitable and especially in our case it seems that the one can
complement the other. As such, the SEILING user interface will be based on the following:
1. HTML/CCS will be used for the introductory parts of the platform as well as
for most of the supporting applications i.e. chat, forum, user management,
reporting etc
2. FLASH will be used in delivering all the training material (i.e. the games) to
the users. The superiority of FLASH in representing and delivering these
types of formats is un-parallel and it cannot be ignored. FLASH will allows us
in significantly leveraging the training scenarios into a well designed and
presented game, something that would be very difficult to achieve only with
HTML/CSS.
Therefore architecturally wise the user will first be confronted with HTML/CSS pages
that will cover all introductory parts of their training as well as several information
about the SEILING project in general. User management and most of the supporting
applications will also be delivered in HTML/CSS. Finally, the administration component, for both the users and administrators will also be built using HTML/CSS for the
user interface.
2.5. Application Layer
The Application Layer is the most important component of our platform. It includes
all the important structural elements of the platform as well as all the business logic
for both the training scenarios and the rest of the supporting applications.
The Application Layer will receive input from the Presentation Layer, process it accordingly and then return back to the user the relevant output. The components
envisioned for the Application Layer are categorized as follows:
1. Game-Play:
The game-play is actually the conversion of our training scenarios into games. It will
include all the images, animations, interactions necessary to transform our scenarios
into a well-developed, attractive game-play that will entice users of our target group
of using it to accomplish their tasks. The game-play will assume the highest portion of
our development efforts and thus it needs to be well planned and designed so that
any development inefficiencies are accounted for and development effort is optimized promoting at the same time flexibility and openness for the various evaluation
iterations that are necessary for perfecting the game-play and satisfying the our user
requirements.
The game-play will be developed entirely in FLASH. As already noted in the Presentation Layer section, FLASH is the ideal candidate in developing such applications since
Task 2.1and 3.1
Page 15 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
it highly supports animations and user interactivity. Any logic related with the gameplay will be developed using ActionScript which is a scripting language developed by
Adobe to complement FLASH and allow it to be expanded into the Rich Internet Applications arena.
2. PHP modules
PHP modules will handle the rest of the business logic of the SEILING platform such
as any logic related to the introductory parts of the platform as well as any logic related to the connection of the various game-plays between them. On top of that, PHP
modules will handle all data interactions with the data layer and thus will be responsible for accessing and populating the SEILING database.
PHP is a well-proven platform for developing web applications and is the preferred
choice for many applications especially in the e-Training sector. In addition, PHP
complements perfectly our database engine selection which is MySQL. PHP/MySQL is
a combination that will offer us development speed, stability and ability to integrate
various other components within our platform.
Finally, PHP/MySQL is a technology that is well-known to the technical partners of
this consortium. This will allow the consortium to move forward the development
quickly without having to spend time for staff training and/or outsourcing of these
tasks.
3. Supporting Applications
The Supporting applications are separate components that are needed to complement the rest of the functionalities offered by the system. It aims in promoting the
collaboration among our users as well as the collaboration between the users and
their trainers. Additionally, the supporting applications will handle all the evaluation
requirements (user grading, feedback) of the platform as well as the various reporting requirements that are necessary for these types of applications. Finally, the supporting applications will include the user management module that will handle all the
users and courses registrations for both the trainees and the trainers. Also the necessary functionality for the administrators of the platform will be developed within the
supporting applications.
In general it is envisioned that the supporting applications will offer the following
functionality:




User’s forum
User’s chat application
Evaluation component (grading, feedback)
Reporting
Task 2.1and 3.1
Page 16 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919




SEILING
Architectural Synthesis and System Design
Courses depository
User Management
Administrator Management
Other tools
The supporting applications will mainly be based on the PHP/MySQL development
platform. In any case, the PHP/MySQL paradigm allows integration with a range of
components and therefore if there is a need to integrate a component that is developed in another platform but based on web standards, we believe that PHP/MySQL
will be able to accommodate this need accordingly.
Task 2.1and 3.1
Page 17 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
3. System Design
3.1. Introduction
Following the definition of the overall architecture of the system, the next step is the
finalization of the System Design. The System Design refers to the detailed definition
of the various components of the system that have been identified during the architecture phase and the de-composition of these components into smaller modules.
Also the design includes the possible interactions between these modules as well as
their impact to the data layer. It goes without saying that the primary focus of the
design is on the application layer and the data layer. For the presentation layer the
design (decomposition into smaller components) is of lesser importance.
Figure 4 – SEILING functional components
Figure 4 illustrates the functional components of system and their decomposition to
smaller modules. The components have been grouped into three (3) major domains:
Task 2.1and 3.1
Page 18 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919



SEILING
Architectural Synthesis and System Design
Games Manager
Administration
Communication Manager
The illustration also shows the interaction between the major components as well as
the interactions between the 3-tier layers. These have been extensively discussed in
the Architecture part of this document. Following is a brief description of the design
scope and technologies involved of each module as well as the considerations for the
relevant database design.
3.2. Application Layer Components Design
Games Manager
Game manager is the most important and most complex component of the system. It
will be the placeholder for all the games included in the system and it will include not
only the functionality of the games (animations, images, fonts, audio) but also their
interaction with the other components of the system such as the evaluation, the
communication and of course the data access components for the storing of the data. Five games are envisioned for this project. A detailed description of the games can
be found in the Scenario definition v3 (Design and evaluation of learning scenarios). A
summary of the technical considerations for each game can be found in the following
sections.
Apart from the games, the Game Manager includes the Courses Manager, which will
be responsible for the uploading and management of new games, the Supplementary
Manager, which will be responsible for all the supplementary material of the games
such as tips, directions, illustrations and references. Additionally the Games Manager
will hosts the Evaluation Manager component which handles the evaluation part of
each game, if any. Evaluation can contain tests, quizzes or any ranking/grading algorithm provided by the trainer. It is envisioned that for this system most of the games
will include an evaluation component.
Career Choice Game
The Career Choice game will be the one with possibly the lowest technical considerations. There are no animations, thus the game is clear from FLASH and basically is
based on a PHP module that will handle the series of images to be displayed to the
Task 2.1and 3.1
Page 19 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
user, the ranking of the images and the grading/scoring system. The algorithm for the
scoring system is thoroughly described in the Scenarios deliverable and is calculated
according to the choices of the users. The game will be basically two separate games
(one for the interests and one for the skills) under the same philosophy.
There will also be a completion tracker which indicates to the user his progress towards completion of the game. All user selections will be stored in the database, thus
there will be continuous communication with the data layer. The scores of the user
will also be stored in the database and based on the score the relevant supplementary material will be displayed. Finally a validation component is envisioned where
the user will be alerted for any errors.
CV Builder
The CV Builder game is one where the full range of technologies planned for the implementation of the system will be used. It will consists of a series of highly interactive FLASH animations, AJAX for the validation part in order to avoid unnecessary
page refreshes, and a PHP module that handles the communication with the data
layer. The game is characterized with a lot of interactions with the database since
the user will be asked at all times to enter his/her own data. The data will be saved at
each user step in order to ensure that none of the data is lost.
As before a progress bar will show to the user the progress of the game. Upon game
completion the user will be presented with a number of options such as to preview
his CV, to download his in the Europass format, to get more tips for preparing a successful CV and finally instructions as to how to produce a Functional CV. The CV will
be outputted in MS Word Format so that the user will be able to edit his CV later. Of
course this entails retrieving all the user data from the database and adding the data
in a pre-specified Word template (Europass).
Job Search
The Job Search game will be heavily based on FLASH for its functionality. The game
will consists of a series of advertisements where the user will call up to review and
then the system will ask the user several questions about the advertisements. The
questions will be random and will be retrieved from a pool of pre-defined set of
questions. Upon selection of the user, the right answer will be displayed so that the
user knows what is right and what a wrong answer is. Contrary to the other games,
this game has no database interactions since there is no need to store the user responses for future references. The user will be able to run the game multiple times so
that the whole range of questions is asked. Upon game completion the user will be
greeted with a document with tips regarding Job Search and a summary of things to
notice for each separate advertisement.
Task 2.1and 3.1
Page 20 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Interview
In terms of technologies involved the Interview game is the same as the CV Builder
game. It will include FLASH animations, AJAX for the validation and a PHP module
that handles the communication to the data layer. Again, data persistence is of paramount experience and all the steps of the user will be saved in the database. In that
way, the user can stop the game at any time and restart again at the same point
without any data loss. A progress bar will also be provided and upon completion of
the game, the user will be greeted with a MS Word document that will include all the
data he has entered for the interview as well as a document with additional tips of
how to successfully face an interview.
Time Management
The time management game is similar to the Career Choice game. It will not include
any FLASH animations, but it will include move and drag functionality for re-arranging
the various tasks and ranking them in the correct execution order. A PHP module at
the back end will evaluate instantly the ordering of the activities and a result will be
presented to user about reordering all of the activities. No database interactions are
envisioned since the number of activities will be random and the reordering will not
be always the same. The result will be calculated based on the algorithm described in
the respective section in the Scenarios Definition deliverable. Upon completion the
user will be allowed to view the correct ordering of activities as well as to download
some useful tips regarding time management.
Courses Manager
The Courses Manager component will be responsible for the uploading and management of new games. The System allows trainers and other interested parties to
publish and make available to the SEILING users their training modules (games). The
System will specify the technical requirements that the new training modules need to
follow and after the uploading of the games, the administrators will review and authorize if possible the publication of the games. All this are done electronically and
only thing that the prospective trainer/publisher has to do is to prepare the games
according to the technical guidelines listed on the System (Gamebox area).
Supplementary Manager
The Supplementary Manager module will simply allow for the management of supplementary materials for all the games. This will include only static material such as
Task 2.1and 3.1
Page 21 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
tips, instructions, sample etc. All other supplementary material, such as the Europass
CV in MS Word format are not handled by this module since these supplements require more complex handling than the static documents. Supplementary manager
can be seen as a very simple document management repository.
Evaluation Manager
We have already touched upon the Evaluation Manager during describing the various
games modules. The Evaluation manager is the module that will keep all the algorithms for the scoring of the games and will also allow for the storing of the scores to
the database where appropriate. Additionally, for the games that the supplementary
material depends of the scoring, the evaluation manager will inform the system
which are the correct supplementary materials to be displayed to the user.
Last but not least, the Evaluation Manager will also host any tests or quizzes which
are used for the evaluation of users. Two quizzes are planned, one for the interview
game and one for the CV game. Effort will be taken so that the module will be highly
modular so that it will allow for the automated generation of quizzes for any future
games that will be later on listed on the SEILING platform. This will be an added service for the trainers that will want to use our platform to upload their trainings based
on alternative content.
Additionally, the Evaluation Manager will also host the questionnaire for the overall
evaluation of the system. This will be a long questionnaire with numerous questions
about the usefulness of the SEILING platform and of course it will be present only
during the user’s evaluation of the System.
Administration
The administration component is also one of the core components of the system. It
primarily includes the user management module, which feeds with information all
the other components and modules of the system, as well as some other supportive
modules such as the News Management, the Articles Management, the Uploads
Manager and the Languages Manager.
The administration module is not for the users of the system, but primarily for the
administrators of the system. Certain modules of the component such as the registration of a user will also be exposed to the System users. Following is a brief description of the design principles and technologies involved for each module of the
Administration component.
Task 2.1and 3.1
Page 22 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
User Management
User Management is a core component of every application which is exposed to the
Internet. The same goes for the SEILING system. User Management will provide all
the necessary functionalities for the registration, maintenance and security of the
various users of the SEILING system. Users can be trainers or trainees. It will include
screens for user registration, login to the system, update of user information and will
handle the permissions of the users to the various modules of the system (i.e. a user
needs to login to play the games). User Management stores all the necessary user
information to the common MySQL database of the system.
Apart from the common user information (username, password, address etc), the
user management module will handle also the grading of each user (i.e. the collection of the grading for each game). For the time being the grading part of this module
will be simple enough to hold only the relevant grades for each game/course but in
the long run this part can be expanded and offer a grading system such as the ones
we have at the various universities or a custom grading as decided by the administrators of the System.
Finally this module we also cover the reporting needs of the system. This will include
reports with the grades and progress of each user as well as aggregate information
across users and courses/games. Initially a very basic reporting is envisioned that will
list the grades for each user for each course.
The module will be developed entirely using PHP.
News Management
The News Management module will deal with the publication of news to the main
page of the SEILING platform. Specifically, it is expected to be source of information
for the Learn More About section of the System’s frontpage.
Obviously the News Management will be only available to the administrators of the
System for which an interface will be provided for uploading news regarding issues
related to the SEILING concept. The interface, except from the usual news information will also support the uploading of images associated with the news.
All information will be stored to the database and therefore communication with the
data access component is needed.
The module will be developed entirely using PHP.
Task 2.1and 3.1
Page 23 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Articles Management
Articles management goes along the same lines with News Management, but this is
for populating with articles the “Good Practices Corner” section of the System. Again
it is targeting only the administrators of the system and all the information will be
stored in the database and displayed accordingly. Functionality to handle displaying
will also be provided i.e. (ordering of articles)
Upload Manager
The Upload Manager module will be responsible for all the uploads related to the
system. It will provide the necessary classes for uploading documents, images, games
to the System in a user-friendly and secure way. The functionality provided by Upload Manager will be used by the Courses Manager, by the News Management and
by the Articles Management modules.
Languages Manager
Languages Manager module is another important module of the System. As has been
previously stated, the SEILING system will be offered in 5 languages. This module will
provide the necessary functionality for offering of the various languages of the System. Apart from the functionality, it will also host the various translation files with
the translated texts which form the basis for the multi-language nature of the site.
Effort will be undertaken, so that the introduction of a new language to the system is
as seamless as just adding a text file with all the necessary translations.
Communication Manager
The Communication Manager is primarily responsible for all the collaboration aspects
of the system. Collaboration is viewed as a very important aspect of the SEILING system since it will allow for the development of the SEILING community and it will allow greatly assist to the enticement of many users to the SEILING platform. Communication manager include the forum and chat modules as well as the contact module
which will allow for the communication of the user’s requests, queries to the administrators of the System.
Forum
The Forum module is the main collaboration tool of our platform. It is not a task of
this project to develop a forum application. Rather, the consortium aims to seek for a
ready-made application that will be integrated with the customized for the SEILING
platform. It is envisaged that both systems will share the same user management
Task 2.1and 3.1
Page 24 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
framework and the same database in order to minimize maintenance effort. The
ready-made system shall also offer a customizable appearance so that it can be
pleasantly co-exist with the rest of the SEILING presentation principles. Additionally
the ready-made system shall be capable of defining topics and sub-topics, must have
multi-language support and shall be secure enough to prevent spammers and hackers from disturbing the normal operation of the System.
A potential forum ready-made application for integrating with SEILING is phpBB, a
free flat-forum bulletin board software solution that can is very widely used and has
been so far integrated with various systems.
Chat
Chat is another module aimed for the communication/collaboration of the users.
Chat will allow for the real-time communication of the users whilst taking their training. The same way as with the forum module, a ready-made application will be
sought and be integrated with the SEILING platform. The requirements are the same
as with the forum, however in the chat case, effort will be made so that the chat
application does not consume a lot of CPU resources (since it is real-time) and also
that it includes security and recording features that it will allow real-time monitoring
of the users using the chat.
Contact
The contact module will be responsible for the communication of the users with the
System administrators. This will consists of a communication form with various fields
necessary to record the users’ requests or queries.
This module will require access to the database in order to store the communication
with the users. Functionality for the management of the requests shall also be provided within this module.
3.3. Data Layer Design
Although the SEILING system requires a database to provide the full range of its functionality, the design of its database is nowhere as complex as the development of the
“gaming” aspects of the system. The database follows a conventional design and
most tables and relationships are self-explained. Stored procedures will be used for
the execution of all queries in order to speed up processing but also for data input
validation and data access security.
Communication with the database is achieved through a data access component that
will handle all the interactions with the database. The data component will receive
the request from the modules requiring information from the database, will validate
the request, transform the input if necessary and send the query to the database
Task 2.1and 3.1
Page 25 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
engine for execution. The data component will also be responsible to receive the
results from the database and pass them to requested module for further processing
and displaying to the user. The usage of a data access component will allow for developing the application layer modules with a high level of abstraction, hiding all the
database complexities from the developer. The data access component will include
all the methods necessary for inserting, updating, deleting and retrieving data from
the database and as it is customary it will return a reference to objects complete with
its attributes instead of a row of fields from a database table.
Following is an illustration with the preliminary design of the SEILING database along
with a brief description of the scope of the major tables.
Figure 5 – Database design 1
Task 2.1and 3.1
Page 26 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Figure 6 – Database design 2
All tables with the “game” prefix refer to the tables needed to store the data necessary for the operation of the games. The following is the matching between the
games and the tables:



Game0 table refers to the Career Choice game. It is split into Game0a and
Game0b tables one for each part of the game i.e. Game0a table is for the interests parts and Game0b is for the skills part.
Game1 table refers to the CV Builder game. It consists of a primary table
(Game1) and some secondary tables (game1_language, game1_education)
which are linked with a primary/foreign key relationship.
Game2 table refers to the Interview game and it is also consists of a primary
and secondary tables link with a primary/foreign key relationship
Task 2.1and 3.1
Page 27 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919


SEILING
Architectural Synthesis and System Design
Game 3 table refers to the Job Advertisement game.
Game 4 refers to the Time Management game.
Other important tables are the users table, which stores all the necessary data for
user management, the languages tables that store all the relevant information for
the multi-language support of the system (note that the translations will be kept in
separate text files and not in the database) and the score tables which essentially
relates to the users tables and keeps the grading of the users for each course they
take. Additionally another important table is the Results table which will store the
results from the evaluation questionnaire.
Task 2.1and 3.1
Page 28 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
4. Implementation Plan
4.1. Introduction
This section describes in detail all the aspects related to the implementation plan
which will be followed towards the development phase. More specifically, this section describes the order with which the various components of the SEILING system
will be developed, the philosophy behind it and more importantly the integration
plan with which all the components will be integrated into a holistic system.
The basic model that will be followed for the implementation plan is guided by the
incremental development process engineering methodology. This means that the
final system is not fully approached in the beginning of the project, but that the understanding of the necessities of the system will grow as components are built, tested and feedback is collected from the users of the system. Therefore, following the
mentioned approach, we will face in a first step the implementation of a limitedscope architectural prototype with the most major components to validate the architectural design and the initial design of its relevant components. Finally a new iteration of re-design and implementation activities will take place, taking into account
both the evaluation results of the initial prototype and the changing requirements of
the business environment, leading to the final implementation of the SEILING platform.
The implementation plan for each separate component has four main steps, which
are:




To define the organization of the code in terms of the implementation subsystems organized in layers
To implement classes and objects in terms of components
To test the developed components as units
To integrate into an executable system the results produced by individual
implementers or teams
4.2. Implementation order
The components that are foreseen to be developed for the SEILING platform are the
same as the ones detailed in the design section. The order with which the development team plans to implement them is such that it will allow for efficient work allocation as well as quick validation of the core components of the platform at the early
stages of development.
With that in mind, the first component to be build is the gaming engine that will provide the transformation of the scenarios into animations/games. The gaming engine
represents the more important part of the SEILING platform not only in terms of
functionality but also in terms of the effort required to be developed. The selection
Task 2.1and 3.1
Page 29 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
of FLASH as our gaming engine allows us to separately develop this component without many worries about the integration with the rest of the system. FLASH can be
very well integrated into web applications since all browsers inherently support
FLASH which actually can be embedded into a web application/page.
In addition to the animations the gaming engine needs to have access to the database through the data management layer. This is because at the time a user is “playing” the game, the system is asking him to provide information necessary for the
current/next step of the game. This information are recorded as well as evaluated in
order to the provide feedback to the user. As already mentioned this functionality
will be provided through the scripting engine of FLASH (ActionScript) as well as the
PHP modules that will handle all the data access to the database. The ActionScript
scripting parts that will pass/accept data to the PHP module will also be developed at
this stage. The development tool for FLASH allows for the separation of the animations design and scripting, thus it is envisioned that these two elements of the gaming engine will be developed mostly in parallel.
The next component to be developed is the PHP modules that will handle the data
management tasks. This is necessary in order to allow for a quick and initial evaluation of the core component of the platform which is the gaming. Of course, part of
this task is the setting up of the database with all the necessary tables for the games
to run. The database will be further enriched with the tables necessary for the rest of
the platform functionality such as the supporting applications.
Once the core components of the platform are built, the partners will be asked to
provide a first iteration of comments and suggestions in order to further enhance the
experience of the users. The aim of this first iteration is to validate the initial technological capability through trials performed by the users. This will validate that the
designed architecture along with the implemented SW & HW components can satisfy
the business model requirements.
While the users are evaluating the gaming aspect of the platform the development
team will start working on the other components of the system such as the supporting applications and the introductory parts of our web site. User management is
probably the most important component from the supporting applications and thus
emphasis will be placed so that it is completed right after the development of the
gaming engine. User management is tightly coupled not only with the gaming engine
but also with the rest of the platform. Thus, the integration of the user management
with the gaming engine will be evaluated and tested at the very early stages of the
system development.
In parallel with user management, the team will start preparing the web site that will
host the SEILING platform. This is expected to act as a “wrapper” to the rest of the
components and the development of it, is not expected to be of any difficulty since it
Task 2.1and 3.1
Page 30 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
is based on HTML/CSS technologies with which the technology partners of the consortium have a lot of expertise.
Following this, the development team will start implementing the rest of the supporting applications which are course management, grading (evaluation), and reporting. All these are going to be build using PHP and their aim is to provide support to
the rest of the platform.
Another task of the implementation plan is to integrate the collaboration tools such
as forum and chat. As already mentioned, It is not expected that the team will build
these supporting tools from scratch. Rather, the consortium will utilize ready-made
components that are available in the Internet and will attempt to customize and integrate those with the rest of the platform.
Finally the last task of the implementation plan is a thorough internal testing that will
be performed by the partners of the consortium. This will allow for the isolation and
the fixing of any problems regarding the functionality of the system as well as the
optimization and streamlining of the users experience.
5. Security Mechanisms
This section of the deliverable presents all security related aspects of the SEILING
platform and of the corresponding infrastructure. This section elaborates on the security mechanisms employed to ensure Data and Message Integrity, Authentication,
Non repudiation and Confidentiality. The security schema that will be applied in
SEILING, as well as how this schema affects the system’s architecture will be covered
as well in this section of the deliverable.
SEILING platform is not one of those systems that are considered as hard on security.
Although being a web-based system implies exposure to the general internet attacks,
the information handled by the system is not such that would attract any kind of
attacks. Nevertheless the necessary precautions for an application exposed to the
Internet need to be taken so that the platform is protected from un-authorized access and Denial of Service attacks.
As such the SEILING platform has its own security requirements which are categorized below:
 Software system security needs
 Network security
5.1. Software system security
The security of the software system revolves around four different axons:
Task 2.1and 3.1
Page 31 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919




SEILING
Architectural Synthesis and System Design
Identity/authenticity of the users: This is simply referred as AAA functions
(Authentication, Authorization, Accounting) in the security experts jargon
and it merely refers to who perform the action, does he/she has the proper
permissions to perform it and can we track who has perform a certain action.
Non Repudiation: This refers in having a mechanism which provides sufficient
proof that a user has actually performed a certain action without possibly
denying it.
Data Integrity: This refers to ensuring that the information exchanged between users, processes and devices are not altered en route and thus resulting in false information being exchanged.
Confidentiality: Ensuring that information is not disclosed to unauthorized
parties.
Most of the security needs of the SEILING platform will be implemented directly in
the software. For example the identity/authenticity of the system will be based on a
custom authentication system (forms-based) which constitutes in keeping users,
roles and permissions in the back-end database and utilize them upon need. In that
respect a user will supply his/her credentials and the system will check in the database whether this is a legitimate user and will report back to the system the privileges that this user has in the system. Additionally, as a second level of security for this
axon, the inherent back-end database (MySQL) security mechanisms can be utilized
to enforce the security rules described before. This constitutes in defining the level of
access that each user will have in the respective tables and views of the database. As
far as the 3rd part of the AAA function (accounting), this should be done manually by
the software developers. Each user action must be logged in a protected log file
along with a standardized description of the user action in order to facilitate search
and retrieval. Again, the database security schema can act as backup mechanism for
accounting, recording all actions that occur on the database level (tables and views).
Regarding non-repudiation, this will be covered from the accounting function of the
previous axon. Non-repudiation is better served by the use of digital signatures but
the security needs of the SEILING platform are not such that would justify the complexity of implementing digital signatures.
As far as data integrity, again this axon is better served by the use of digital signatures. Since this is not a viable option for the needs of the SEILING platform, the data
integrity will be covered at the network level of the application by providing mechanisms such as Secure Sockets Layers (SSL) which guarantee that the messages exchanged between users, processes and devices are not altered en route. Additionally
the data integrity will be guaranteed through the deployment of firewalls and other
security perimeter devices such as IPS, IDS that will protect the web server deployment zone as well as the database which is expected to be hosted into a higher security zone.
Task 2.1and 3.1
Page 32 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
Finally regarding the confidentiality axon, this will be handled by the custom authentication/authorization system to be built. System developers must ensure through
coding that no user will be able to view/edit/delete information which belong to
another user. Additionally the system must ensure that a third party will not be able
to access the system either with brute-force or dictionary-based password attacks by
implementing mechanisms such as minimum password length, frequent password
expirations, combinations of letters, digits and punctuation symbols etc.
Task 2.1and 3.1
Page 33 of 34
SEILING Consortium©
LLP-LdV-ToI-09-CY-167919
SEILING
Architectural Synthesis and System Design
6. Conclusions
This document describes the Overall System Architecture and specifies the architecture environment of the SEILING platform. IT describes the general architecture of
the SEILING platform under a layered approach that has been adopted by the project
and it provides an overview of the technologies that are utilized in SEILING architecture, in terms of methodologies, development environments, technologies etc.
In addition the document provides a detailed design of the SEILING platform and its
components as well as the implementation plan to be followed for the development
of the system. The consortium is adopting an iterative approach for the system development where the core components are built and tested first and then the rest of
the functionality (supporting applications) is integrated in subsequent stages.
Task 2.1and 3.1
Page 34 of 34
SEILING Consortium©