virtual enterprises robotics and manufacturing section computer supported ... - moodle · 2012. 8....

Virtual Enterprises

Robotics and Manufacturing Section

Computer Supported Collaborative Teaching

Final Report

June 2006


Robotics and Manufacturing Section, June, 2006 2 Monte da Caparica, Portugal



Abstract

In the scope of the course of Virtual Enterprises the development and integration of a

Computer Supported Collaborative Teaching, (CSCT), tool was made.

The purpose of this tool was to achieve a better interaction between teachers, students

and even industry companies. Molding courses in the light of market and student necessities, and

enhancing student teacher relationship.

With Collaboration-driven software as a base, (Egroupware) and applying an optimized

ICE model (Interface Contents and Editor), a number of task force groups formed by graduate

students started to develop and integrate multiple modules into a comprehensive and accessible

CSCT tool.



Index

ABSTRACT ......................................................................................................................3 INDEX .............................................................................................................................4 PREFACE .........................................................................................................................7 SECTION 1: OVERVIEW ...................................................................................................8

1.1. INTRODUCTION ............................................................................................... 8 1.2. THE ICE MODEL ............................................................................................... 9 1.2.1 THE INTERFACE LAYER ................................................................................... 11 USER INTERFACE (UI) .............................................................................................. 11 ASYNCHRONOUS USER INTERFACE (ASUI) ............................................................... 11 SYNCHRONOUS USER INTERFACE (SUI) ................................................................... 11 1.2.2 THE CONTENT LAYER ..................................................................................... 11 BLOGER MANAGER (BL) .......................................................................................... 12 CONTENT EDITOR (CE) ............................................................................................ 12 COLLABORATION MANAGER (COLM) ...................................................................... 12 BUSINESS PROJECT MANAGER (BPM) ..................................................................... 12 BUSINESS PLAN EDITOR .......................................................................................... 12 BUSINESS PLAN EXECUTION.................................................................................... 12 BUSINESS PLAN WIZARD ......................................................................................... 12 MULTIMEDIA CONTENT EXPERT (MCE) ................................................................... 13 1.2.3 THE ENTITY LAYER ......................................................................................... 13 DATABASE INTERFACE (DBI).................................................................................... 13 USER/GROUP MANAGER (UMAN) ........................................................................... 13 CONTENT MANAGER (CMAN) ................................................................................. 13 SESSION MANAGER (SMAN) ................................................................................... 13 MODULE MANAGER (MMAN) ................................................................................. 13 DATABASE MANAGER (DBM) .................................................................................. 13

SECTION 2: THE MODULES ........................................................................................... 14 2.1 USER INTERFACE MANAGER .......................................................................... 14 OVERVIEW .............................................................................................................. 14 IMPLEMENTATION ................................................................................................. 14 SIGN IN INTERFACE ................................................................................................. 14 GROUPS SELECTION ................................................................................................ 17 CONCLUSIONS ........................................................................................................ 23 2.2 SYNCHRONOUS USER INTERFACE .................................................................. 24 OVERVIEW .............................................................................................................. 24 INTERACTION ......................................................................................................... 25 IMPLEMENTATION ................................................................................................. 26 CONCLUSIONS ........................................................................................................ 33 2.3 ASYNCHRONOUS USER INTERFACE ............................................................... 34 OVERVIEW .............................................................................................................. 34 INTERACTION ......................................................................................................... 34 IMPLEMENTATION ................................................................................................. 36



CONCLUSIONS ........................................................................................................ 41 2.4 MULTIMEDIA CONTENT EDITOR .................................................................... 42 OVERVIEW .............................................................................................................. 42 INTERACTION ......................................................................................................... 43 IMPLEMENTATION ................................................................................................. 45 CONCLUSIONS ........................................................................................................ 45 2.5 BLOG MANAGER ........................................................................................... 46 OVERVIEW .............................................................................................................. 46 INTERACTION ......................................................................................................... 46 USER INTERFACE..................................................................................................... 47 DATABASE .............................................................................................................. 48 IMPLEMENTATION ................................................................................................. 49 FUNCTIONS PROVIDED ........................................................................................... 51 CONCLUSIONS ........................................................................................................ 52 2.6 COLLABORATION MANAGER ......................................................................... 53 OVERVIEW .............................................................................................................. 53 INTRODUCTION ...................................................................................................... 53 MOTIVATION .......................................................................................................... 54 METHODS ............................................................................................................... 54 FORUM................................................................................................................... 56 MESSENGER ........................................................................................................... 61 DISCUSSION ............................................................................................................ 63 2.7 CONTENT EDITOR .......................................................................................... 64 OVERVIEW .............................................................................................................. 64 INTERACTION ......................................................................................................... 65 IMPLEMENTATION ................................................................................................. 67 CRITICAL ANALYSIS ................................................................................................. 70 CONCLUSIONS ........................................................................................................ 71 2.8 BUSINESS PROJECT MANAGER ...................................................................... 73 OVERVIEW .............................................................................................................. 73 INTERACTION ......................................................................................................... 75 IMPLEMENTATION ................................................................................................. 75 BP EDITOR .............................................................................................................. 75 BP EXECUTOR ......................................................................................................... 82 BP WIZARD ............................................................................................................. 87 CRITICAL ANALYSIS AND FUTURE WORK ................................................................. 90 CONCLUSIONS ........................................................................................................ 91 2.9 DATABASE INTERFACE MODULE ................................................................... 92 OVERVIEW .............................................................................................................. 92 INTERACTION ......................................................................................................... 92 IMPLEMENTATION ................................................................................................. 93 FUNCTIONS PROVIDED ........................................................................................... 93 DATABASE. THE INPUT IS THE NAME OF THE DISCIPLINE. ....................................... 97 CONCLUSIONS ...................................................................................................... 104 CRITICAL ANALYSIS ............................................................................................... 105 FUTURE WORK ..................................................................................................... 106 2.10 DATABASE MANAGER ................................................................................. 107



OVERVIEW ............................................................................................................ 107 INTERACTION ....................................................................................................... 107 COORDINATION .................................................................................................... 108 IMPLEMENTATION ............................................................................................... 110 CONCLUSIONS ...................................................................................................... 110

SECTION 3: CONCLUSIONS ......................................................................................... 111 3.1 CONCLUSIONS ............................................................................................. 111 3.2 FUTURE WORK ............................................................................................ 112 3.3 WEB REFERENCES ........................................................................................ 112 3.4 BOOK & ARTICLE REFERENCES..................................................................... 113 3.5 AUTHOR REFERENCES ................................................................................. 114



Preface

This report covers a collaborative network project. Being this a modular project each the

task force work group was charged with a report outline for his own module. Those modules are

treated individually as they cover specialized work.

The different module reports are placed in section 2, by chapters corresponding to module

names. The only thing that has been altered is the report template and nothing was altered in

the report itself.

The non module specific chapters are in section 1 and 3 and are of the coordinator’s group

responsibility.



Section 1: Overview

A collaborative network (CN) is constituted by a variety of entities (e.g., organizations and people)

that are largely autonomous, geographically distributed, and heterogeneous in terms of their: operating

environment, culture, social capital, and goals. Nevertheless these entities collaborate to better achieve

common or compatible goals, and whose interactions are supported by computer network. Unlike other

networks, in CN collaboration is an intentional property that derives from the shared belief that together

the network members can achieve goals that would not be possible or would have a higher cost if

attempted by them individually.

A large variety of collaborative networks have emerged during the last years as a result of the

challenges faced by both the business and scientific worlds. Advanced and highly integrated supply chains,

virtual enterprises, virtual organizations, professional virtual communities, value constellations, and

collaborative virtual laboratories, represent only the tip of a major trend in which enterprises and

professionals seek complementarities and joint activities to allow them participate in competitive business

opportunities, in new markets and/or reaching scientific excellence for innovative developments. Similar

trends can be found in the none-profit/social-oriented contexts, e.g., in incident management, time bank,

elderly care networks, etc.) (Camarinha-Matos et al., 2005a).

1.1. Introduction

This project aimed at developing a Computer Supported Collaborative Teaching tool in the

scope of the course of Virtual Enterprises.

If it’s true that a lot of w ork has been in the last few years Computer Supported

Collaborative Learning, (CSCL), the same is not true for CSCT.

The general idea of this research project was to find out what is being done elsewhere,

creating a suitable framework with a number of functionalities useful this specific area.

Also for many of the participants this was the first time a cooperative, common goal

modular work was done.The first phase of this project evaluated a number of solutions and

options for a tool of this type. In the end a number of functionalities were chosen to be

implemented in an already existing platform, Egroupware.



This is an open source platform that allowed the implementation of new modules to create

the desired framework tool.

All existing task force groups that in the first phase conducted R&D on Wiki-like CSCT tools

were reassigned to work in different modules

The second and third phases of this project were the development of the different modules

and their final integration with the Egroupware to create a viable working tool.

1.2. The ICE Model

Having chosen a suitable platform work started on the definition of a suitable work

model.

In creating such a model attention had to be taken to try to maintain the task force work

groups as unchanged as possible and not to overstress any work group.

After some discussion an initial ICE model was achieved. This model is divided in three main

layers.

Figure 1.1: The initial ICE Model.



The main idea was to allow that all the task force groups implemented their modules as

they seemed fit, but maintaining communication with the other modules through objects and

object references. So there would no real need for any given group to known the working of

another module but their own. The only aspect required was to know how to call or how to send

any given object.

As work progressed in the various modules there was the need to revise the initial

model.

Some modules found the need to work closely with the database, this lead to a new

design for the contents and editor layer.

The revised model added new editor modules and supplied a more comprehensive system

architecture.

Figure 1.2: The final ICE Model.



1.2.1 The Interface Layer

All the interaction w ith the “real w orld” (hum an) users w as to be made here; one can

say that this was the visible part of the CSCT tool.

For this layer three modules were deem necessary; User Interface, Asynchronous User

Interface and Synchronous User Interface.

User Interface (UI)

This module was responsible for general system design, skins, menus, general

appearance and ergonomics.

Asynchronous User Interface (ASUI)

Development of the graphical component referent to the modules and Asynchronous

system functionalities

Synchronous User Interface (SUI)

Development of the graphical component referent to the modules and synchronous

system functionalities

1.2.2 The Content Layer

This was the layer were all of the functionalities available to the CSCT tool were made.

Any future tool functionality would be placed here; of course that interaction with the other two

layers would always be required.



Bloger Manager (BL)

This group developed the blog functionality as well as all the modules that integrated

the user with the content such as the synchronous and asynchronous message system.

Content Editor (CE)

This group was tasked to develop a yellow (whiteboard/blackboard) feature. This

feature included image and/or text collaboration.

Collaboration Manager (ColM)

Collaboration manager provided information on the ability of users to collaborate either

synchronously or asynchronously at a given time.

This group developed the video conference functionality, as well as VoIP and Webinar.

Business Project Manager (BPM)

This module grouped another three smaller modules that referred to Business project

manager.

The general idea behind the BPM is to allow a dynamic interaction between the courses

thee students and the industry.

Business Plan Editor

Development of functionalities to allow administrators to edit BP's

Business Plan Execution

BPEX created instances of BP's

Business Plan Wizard

BPW created templates of new courses based on enterprises' /institutions'

/students' preferences profiles.



Multimedia Content Expert (MCE)

Provided access to all kinds of multimedia placed on the system.

Integrated the necessary multimedia players into the system.

1.2.3 The Entity Layer

Database Interface (DbI)

Handled the entire interface between the content layer and the database.

Routed requests to the corresponding modules.

User/Group Manager (UMan)

Managed user and group referred data. Implemented user calendar and contacts; group

news, mailing lists, etc.

Content Manager (CMan)

All content related aspects passed through here.

Session Manager (SMan)

Module charged of managing the on going sessions.

Module Manager (MMan)

All module-related aspects were treated here.

Database Manager (DbM)

Build the database as required. Supplied and handled all the queries with the database.



Section 2: The Modules

2.1 User Interface Manager

Overview

UIM, User Interface Manager, is the module responsible for interact with the user itself. Our

objective is to construct interfaces that be useful, easy and to the user.

This module is the most important to the user. Whit him, the user can start new sessions,

continue older sessions and interact with others users and groups. In addition, we also made the

interface of sign in and create and remove groups.

Since this is a module that will interact with the user, an effort was made to improve the

view of the tree. The amount of information that she had to show was placed in strategic places,

making attractive to the user. For example, if a user is offline the tree will show his icon on red

but if is online; his icon will be in green.

Also for the sign in form and create groups form it had to have the same worries.

Implementation

Sign In Interface

The first thing that it will appear is the image shown in the next figure. At this time, it will

be ask to the user to insert his private information, like the name and last name, his title, role,

email address, city, country, birth date and nationality.



As we can see there is another part. This is the Account information. In this part, the user

will be asked to insert his user ID and the password. It will be necessary to insert the password

twice and both must be the same. This will be checked by the system and it will return an error

message if passwords are different.

After to insert all the data, the user only has to press the Create Account button so that

the registration process is complete.

In many cases, the user can choose from a role of choices. This is the case of his title, role,

birth date and country.

So, in the case of title, the user can opt to choose one of the following options:



If we scroll the role options, we will see the following options:

In function of the made option, it will appear diverse different options. For example, in the

case of the chosen role to be teacher, will appear the following options shown in the next

picture:

As can be seen, the user must insert the Maxim Working Hours. It represents the maxim

hours that the user can work to the group. It must input also the Maxim Available Hours, that is,

the maxim hours that the user can to excuse.

It will also appear the areas that the user can teach. Just check the box correspondent.



If the made option is student, the following picture will be shown. Note that this is only an

example since this depends of the information collected from the DB.

The enterprise option will show the following choices. Like the student option, this is only

an example since the information shown is collected from the DB.

In both student and enterprise choices will appear the areas that the user can choose. In

this case we have the ola, ola2 and ola4 as an example of areas. Checking the box will choose

that area and can be chosen as many as the user want.

Groups Selection

This page allows to select in which groups the user wants to belong and it also permits to

add new groups to the existent ones.



How to add a group?

The user can add the group that he wants to belong selecting it from a list. As you can see

in the following picture:

After the selection the user press the add group button (see picture above) and all the

selected groups will be added.



The chosen groups will appear as shown in the next picture:

How to create a group?

If the user wants to create a new group he must write the groups name in the box that

says Create Group as shown in the next picture:

And after that press the button create group (see picture below):

And the new group w ill appear in the user’s group list:



How to remove a group?

If the user wants to remove a group from the ones he has added he must select the group

that he wants to remove from the list (see next picture) and press the button remove group.

How to submit the groups the user belongs?

After choosing all the groups the user wants to belong he must submit his options. To do

that it’s only necessary to press the button subscribe (see next picture) and all the selected

groups will be subscribe.

This page was not added to the final project due to the incapability to integrate PHP with

Javascript. This happened because the code that allows to add groups was done in Javascript

and the code that returned the groups was done in PHP. The problem was not solved in time

because this function was requested to be done in the same day that was to deliver it (the

work).



The Tree

This is the tree where each user has the possibility to interact with other users. The

structure is divided by groups of interest:

Associated to the groups are the users of that group and the respective sessions of the

group.

Users

Each user will have the Status (online, offline):



Inside of each user it is possible to verify the sessions that each one has opened (Business

Process, Publishing Content, Blog, etc.), send mail directly and open a window Chat.

Sessions

It is possibility to create general sessions for the group:



And see the sessions that determined group has running:

Conclusions

In this project we felt the difficulties that is work in group. Only excellent coordination

allowed reaches the objective. We can have an idea of the difficulties existing in a world-wide

project…

This module interacts with all the others modules at content layer. Therefore it is very

important for this project.



2.2 Synchronous User Interface

Overview

SUI , Synchronous User Interface, this module is responsible for being the intermediate

between the user and data base going through other modules, showing the desired data at

user’s need and editing data at user’s w ill.

The design of a user interface affects the amount of effort the user must expend to provide

input for the system and to interpret the output of the system, and how much effort it takes to

learn how to do this. Usability is the degree to which the design of a particular user interface

takes into account the human psychology and physiology of the users, and makes the process of

using the system effective, efficient and satisfying.

Usability is mainly a characteristic of the user interface, but is also associated with the

functionalities of the product. It describes how well a product can be used for its intended

purpose by its target users with efficiency, effectiveness, and satisfaction, also taking into

account the requirements from its context of use. These functionalities or features are not

always parts of the user interface (e.g. are you able to reverse with your car or not), yet they are

key elements in the usability of a product.

Being synchronous we have some responsibilities, this module will provide services to

synchronous features of our platform, transferring data out of the interface, input of the user,

into functions called for the desired purpose, functions that operate over the data base, and

then transferring data out of functions, functions that provide the desired result, into the

interface responding the user’s need.



Interaction

This, is responsible for being the intermediate between the user and other modules,

w itch operate over the database w ith their functions, show ing the desired data at user’s need

and editing data at user’s w ill.

Fig. 2.1: part of the global architecture

This module is responsible for the data exchange between the user interface and the

other modules functions. We can see it as messages, when the user wants something a message

is sent to the desired module, the module receiving this responds with another message. This

module is responsible for exchanging these messages and showing results.

This module interacts with three other modules:

Content Editor

Forum

UIM Tree View



Implementation

The implementation of this module was done following a tutorial given by eGroupWare.org.

Following the tutorial we can perceive that an eGroupWare application is organized around

3 application layers:

1. The storage layer, m anaged by a “Storage Object” (so). This object is responsible for

handling all access to the storage engine.

2. The business layer, m anaged by a “Business Object” (bo). This object is responsible for

all the business logic.

3. The user interface layer, m anaged by a “User Interface” (ui) object. This object is

responsible for all interaction with the user, including displaying and gathering data to

and from the user.

The eGroupWare platform provides an easy way to implement the different interfaces

Fig. 2.2: eGroupW are’s tem plate building m odule



Fig. 2.3: eGroupW are’s object selection m odule

Fig. 2.4: an example of an eGroupWare interface template



In this implementation some problems were found mostly because of some issues over

eGroupWare different versions. These problems were solved by changing some code lines

adapting to our version.

First and foremost an interface had to be agreed by both parties, SUI module and the

other dependent m odule. This part didn’t present problem s, guided by eGroupWare’s tutorial

and eGroupWare’s references the result w as as desired, resulting in an interface capable of

responding to the user’s need.

And the results were the following :

Content editor interface

Fig. 2.5: the three templates built for the module

Fig. 2.6: the interface for creating a new file



Fig. 2.7: the interface for editing a file

Fig. 2.8: the interface for selecting a file



Forum interface

Fig. 2.9 the interface of the recorded posts

Fig. 2.10 the interface showing the existing forums and respective posts



UIM Tree View interface

Fig. 2.11: the interface showing the view tree

The next step was the integration of the interface with the functions implemented by

the other module. The execution of this part was done mostly by working on the user interface

layer, in this layer (described earlier) a link between the interface and the functions supplied had

to be done. With the aid of the eGroupWare’s references, actions over the interface’s objects

were known. From this step on all effort was dedicated to data transfer. With this said, we have

to explain and go through some coding aspects, in the appointed layer we created a class, and in

it some callback functions.

The class created first described all the public functions as depicted bellow. We can

perceive that first the other m odule’s functions have to be included so that they can be called

and used.



2.12: example of the declaration of public functions

Next a constructor had to be declared, here is where all the global variables were

declared, these variables are responsible for the data exchange between the interface and the

other m odule’s functions, and different interfaces objects are created, and the declaration is

depicted bellow.

2.13: example of the declaration of a constructor

Next the callback functions that link the interface with the other m odule’s functions had

to be done. Here apart from all the other variables we have to pay special attention to the

variable $content this variable is set whenever an action over the interface is made, it passes



the interface active object’s nam e. Several callback functions are made, considering every

possible action, with every possible condition. Whenever necessary a different interface can be

called using the operation exec that executes an object (created in the constructor) that

represents a different interface window.

2.14: example of a callback function

With this made all left to do is to enable the module over eGroupWare and test it !

Conclusions

The implementation had some issues of several reasons, namely bad scheduling, inner

group interaction, organization and an exceeding work load. The integration phase proved to be

the most complicated phase.

At the end the overall collaboration and cooperation was very well organized by the

responsible parties.

Overall we can say that we learn with our mistakes, and that collaboration and

cooperation between different processes is a very difficult thing to reach without the proper

organization.

For future im provem ent w e can suggest early scheduling, testing first if it’s possible and

then propose, and point to point scheduled goals with a proper advisory.



2.3 Asynchronous User Interface

Overview

ASUI , Asynchronous User Interface, this module is responsible for being the

intermediate between the user and data base going through other modules, showing the

desired data at user’s need and editing data at user’s w ill.

The design of a user interface affects the amount of effort the user must expend to

provide input for the system and to interpret the output of the system, and how much effort it

takes to learn how to do this. Usability is the degree to which the design of a particular user

interface takes into account the human psychology and physiology of the users, and makes the

process of using the system effective, efficient and satisfying.

Usability is mainly a characteristic of the user interface, but is also associated with the

functionalities of the product. It describes how well a product can be used for its intended

purpose by its target users with efficiency, effectiveness, and satisfaction, also taking into

account the requirements from its context of use. These functionalities or features are not

always parts of the user interface (e.g. are you able to reverse with your car or not), yet they are

key elements in the usability of a product.

Being asynchronous we have some responsibilities, this module will provide services toa

synchronous features of our platform, transferring data out of the interface, input of the user,

into functions called for the desired purpose, functions that operate over the data base, and

then transferring data out of functions, functions that provide the desired result, into the

interface responding the user’s need.

Interaction

This, is responsible for being the intermediate between the user and other modules,

witch operate over the database w ith their functions, show ing the desired data at user’s need

and editing data at user’s w ill.



Fig. 2.1part of the global architecture

This module is responsible for the data exchange between the user interface and the

other modules functions. We can see it as messages, when the user wants something a message

is sent to the desired module, the module receiving this responds with another message. This

module is responsible for exchanging these messages and showing results.

This module interacts with three other modules:

BP – Business Process

o Edit

o Execute

o Wizard

Blogger Manager

Multimedia



Implementation

The implementation of this module was done following a tutorial given by eGroupWare.org.

Following the tutorial we can perceive that an eGroupWare application is organized around

3 application layers:

1. The storage layer, m anaged by a “Storage Object” (so). This object is responsible for

handling all access to the storage engine.

2. The business layer, m anaged by a “Business Object” (bo). This object is responsible for

all the business logic.

3. The user interface layer, m anaged by a “User Interface” (ui) object. This object is

responsible for all interaction with the user, including displaying and gathering data to

and from the user.

The eGroupWare platform provides an easy way to implement the different interfaces



In this implementation some problems were found mostly because of some issues over

eGroupWare different versions. These problems were solved by changing some code lines

adapting to our version.



First and foremost an interface had to be agreed by both parties, ASUI module and the

other dependent m odule. This part didn’t present problem s, guided by eGroupWare’s tutorial

and eGroupWare’s references the result was as desired, resulting in an interface capable of

responding to the user’s need.

And the results were the following :

BP – Business Process



Blogger Manager



Multimedia

The next step was the integration of the interface with the functions implemented by

the other module. The execution of this part was done mostly by working on the user interface

layer; in this layer (described earlier) a link between the interface and the functions supplied had

to be done. With the aid of the eGroupWare’s references, actions over the interface’s objects

were known. From this step on all effort was dedicated to data transfer.



Conclusions

The implementation had some issues of several reasons, namely bad scheduling,

organization and an exceeding work load. The integration phase proved to be the most

complicated phase.

At the end the overall collaboration and cooperation was very well organized by the

responsible parties.

Overall we can say that we learn with our mistakes, and that collaboration and

cooperation between different processes is a very difficult thing to reach without the proper

organization.

For future im provem ent w e can suggest early scheduling, testing first if it’s possible and

then propose, and point to point scheduled goals with a proper advisory.



2.4 Multimedia Content Editor

Overview

The main function of Multimedia Content editor is to provide means, for the user, to be able

to play every kind of multimedia content, in other words, the goal of this module, is to provide

the ability to play several types of multimedia files, like music, pictures and videos. These file are

asked from the upper module, and supplied from the MCE one.

When a user needs to consult a file, if it is considered a multimedia file, the MCE module,

received the request from the above module, and provides it with the necessary functions, so

that, the user can use them to see what he is looking for.

In this report, the most important thing is to explain, how the MCE module works. When a

request is sent to the MCE module, it asks the hierarchically inferior module, a list of all

multimedia files, stored in the database. This question is a selective question, as the user, needs

to select the type of file he is asking for.

Figure 4.1 - MCE user interface



Interaction

When a user wants to see a multimedia file, he just needs, to select one of the three radio

buttons, depending on the type of file. Then, after pressing the “Accept” button, a list of files,

corresponding to the asked type, is shown in the “File List”, com bo box. Finally the user has to

select a file present in the File List, and press the “Show File” button. W hen the “Show File”, is

pressed a players is shown, in order to play the selected file.

Depending on the selected file type, the executed players is:

Video files – Windows media player.

Images – inline frame.

Documents – a link is shown, and the browser handles it,

In a little example if the user requests a video file, the following screen is shown:

Figure 4.2 - Playing a video file



If the requested is a document, then a link, is shown and the user only has to click it, as

shown.

Figure 4.3 - Request of a document

Other feature implemented, by the MCE module, is the possibility given to the user, to

upload files to the database. This issue is done using the “upload” button, present in the

multimedia area and the user only has to click it. After clicking the button, a popup window is

shown, containing a interface to browse for the file to upload, and a button to send the file.

After sending the file, the popup window, automatically disappears.

Figure 1.4 - Upload interface



Implementation

Functions provided by other modules

function getFile($filename).

function listDir($dir_name).

function putFile($filename, $extension, $group_host_name, $final, $visible).

function deleteFile($filename).

Conclusions

All the objectives in this MCE module creation were achieved. For further improvements in

the MCE module there is a suggestion that can be made. The MS Office documents instead of

being shown in a new Microsoft® window, it could be converted into a pdf file, in order to make

it impossible for the user to edit the document. During the creation of this module, there was a

try to implement this issue, but there were a problem to load COM objects through php

language.



2.5 Blog Manager

Overview

This module consists in implementing a blog engine and integrating it with database and

users interface, allowing a new way of publishing articles.

This module is the most used by users or groups for communication and publication of

any kind of information. It allows exchange of intelligence and feedback. We can figure out by

the results that this is one of the most important modules in this project. It represents the most

collaborative and simple way of group working and making business.

Blog is a recent term, it appears in 1994 with the exponential growing of internet

adepts, since that time is utilization grows, independently of whatever the objective is, for

example entertainment or business. The utilization of a blog in any business area, can improve

the communication between collaborators, meaning an increase of performance.

The used approach was based in a simple way of implementing a simple module with a

huge utility.

Interaction

This module has interactions with:

- User Interface

- Database



User Interface

Approaching the user interface, the result was obtained by conferencing with our

partners and developers of the interface:

Figure 5.1 – User Interface

It as been chosen the simpler as possible interface, dealing with the user-friendly

requirement.

The information shown by the user interface, is supplied by the Database and arranged

by this module.



Database

This interaction was the first to be studied, dealing to its importance. It means that a

good developed database returns a simpler solution to many problems that can be found.

Figure 5.2 – Database structure

Blog Manage

r



The overall interactions existent:

Figure 5.3 – Global interactions

Implementation

W hat’s left to be developed is the integration and com m unication betw een de tw o

interactions, resuming the module blog manager.

The result of the two well thought and argued interactions are a simpler way of getting

the following solution.



Figure 5.4 – Module functioning

The following screenshots represents user interactivity:

Figure 5.5 – Posting sequence



Figure 5.6 – Comment sequence

Functions provided

For interaction with the Database, were supplied the following functions:

function getBlogName($GroupName)

returns an array with blog name and creation date

$BlogName = $this->bo->getBlogName('pandilha');

function getPostCount($BlogName)

returns the number of posted articles

$PostCount = $this->bo->getPostCount($BlogName[0]);

function getPosts($BlogName)

returns the articles posted

$Posts = $this->bo->getPosts($BlogName[0]);



function getPostComments($PostTitle)

returns the comments of a specified post

$PostComments = $this->bo->getPostComments($Posts[$i][0]);

function SetPostComment($UserName, $BlogName, $PostTitle, $CommentTitle, $Text,

$PostRating)

Writes a comment to a specified post

$this->bo->SetPostComment($CurrentUser,$BlogName[0],$PostTitle,$CommentText);

function CreatePost($BlogName, $UserName, $PostTitle ,$Text)

Writes a post

$this->bo->CreatePost($BlogName[0],$CurrentUser,$PostTitle,$PostText);

Conclusions

We had some difficulty to implement the final solution, because some of the modules

didn’t have accom plished the established objectives in the specified dates, but in the end, all

worked out.

The programming language used was also new to us, so we had to lose more time to

understand it and to integrate the module in the chosen platform - egroupware.

Summarizing, considering that there w asn’t m uch tim e to w ork in this project, w e are

glad by the final result. The team spirit was very good so the communication between the

modules that concerned us was achieved and the integration in the platform was a success.



2.6 Collaboration Manager

Overview

Nowadays, collaboration is a very important issue evolved in all business areas. No one

can work alone anymore, since the complexity of projects is increasing, especially in research and

development area, so people tend to get together in order to simplify work, by matching and

using all competences of the group.

Professor’s com m unity is one field w here collaboration can be applied, as all Professors’

knowledge can be fitted, and this will guarantee a better teaching, not only to students, but also

to Professors themselves.

So, because of this, it’s im portant to create a fram ew ork w hich Professors can m ake use

of resources and forms of collaboration, improving their possibilities to make knowledge reach

students.

Introduction

The module Collaboration Manager is designed to promote more effective and efficient

group decision-making by removing barriers between people, data and processes. It provides

the contextual framework and collaboration tools, including discussion forums, live meetings,

and interactive polls, to enable group members to share information and participate in

processes to facilitate group decision-making. These tools help organizations speed time to

market, reduce costs, and enhance employee productivity and customer satisfaction.

Most of the time, the terms collaboration and cooperation are confused. Cooperation

refers to the practice of people or greater entities working in common with commonly agreed-

upon goals and possibly methods, instead of working separately in competition. Instead of this,

Collaboration is the right mix of people, refers abstractly to all processes wherein people work

together - applying both to the work of individuals as well as larger collectives and societies. In



certain political contexts (such as a state of war) the term "collaboration" or "collaborator" may

refer to individuals who are claimed to have been working with an outside entity against their

own societies.

Motivation

The major issue of this task is to create several forms where content providers can work

in a collaborative manner and where they can interact together, discussing and helping each

other on their problems and issues. Some examples for these features are, for instance, an

instant messenger, chat, live meetings or discussion forum. And finally share documents with

different kind of groups or users.

Methods

Initially, there was a research phase in which we try to come across the most important

features that could be implemented in order to reach the key objectives of this task.

The first consideration was based on instant messenger and, so we attempt to idealize

the essential resources and functionalities required. These ideas were organized as use-case and

illustrated in the following diagram of use-cases.



Figure 6.1 – Messenger Feature

Another idea that came out was to try to integrate in the framework a program, in

which all this kind of functionalities could be found and which were, for instance, MSN Windows

or Skype. These programs consists basically on software that people employ to communicate

with each other and they are widely established, which could be very useful to integrate these

features in our platform.

After some research, we noticed that this could be implemented using a M SN W indow s’

API and matching with a set of classes found on the research. The script executed by these

classes was already developed in PHP language and it permits us, given a valid account, to login

in the server and to receive messages from anyone. This was a very simple version, as it w asn’t

set up to maintain a normal conversation, since in response to any message, the script sent the

same message straight back.



Due to some difficulties trying to develop this script to integrate it in the framework

with all functionalities of M SN, w e realize that this w asn’t the best and m ost viable solution. So,

we start focusing our attention to Forum and Messenger available in E-Groupware. The idea was

to extend these modules with extra features in order to add new value on those modules.

Forum

W e decide to study the forum ’s m odule from the platform eGroupWare. That way, the

classes class.boforum.inc.php, class.soforum.inc.php and class.uiforum.inc.php where carefully

analysed to understand how this forum works.

After doing some tests, som e “bugs”, that this forum has, w ere discovered and w e tried

to resolve them. Initially, the forum has the category (like Virtual Enterprises, for example) and

then in a deeply level has the forum ’s nam e (like Project-Final Phase, for example). Inside this,

there are all the posts that the users made and the replies to those posts.

The problem was that all the replies (and the replies from replies) were not organized in

the forum ; they appear w herever they “w ant to”. For exam ple:

Subject

● Subject 2

● Subject 1

● Subject 1.1

● Subject 2.1

● Subject 2.1.1

Analysing the Data Base table and the most important attributes (id, parent, thread and

depth) we understood some issues:

The principle subject is the father and has the value -1 in the attribute parent;



The thread of the parent has the same value of his id;

All the replies to the principle subject (including the replies from replies) have the

same value, in the attribute thread, of their parent;

The value in the attribute depth is increased depending from the reply degree. Witch

m eans that the parent has depth ‘0’, the first reply has depth ‘1’, the reply from this reply has

depth ‘2’ and so on.

W ith all this considerations, this “bug” w as resolved and the forum has the following aspect:

Figure 6.2 – Forum of eGroupWare

The Data Base table is represented in the next figure:



Figure 6.3 – Forum ’s Data Base of eGroupW are

This module interacts with the Data Base Manager, the Data Base Interface and the

Synchronous User Interface. To implement the idea of saving to a file all the posts and replies of

a forum, we needed from the Data Base Manager some queries to select those specific

messages.

The first one returns the category ID of the forum and the forum ID:

SELECT cat.name as category, forum.name as forum

FROM egroupware.phpgw_forum_categories cat, egroupware.phpgw_forum_forums forum

WHERE cat.id = id_category AND forum.id = id_forum;



The second one returns all the information to fill the array Thread[]forum_threads from

forum class:

SELECT th.id as thread_id, th.postdate , gr.name as thread_owner, th.subject as title ,

body.message as message

FROM egroupware.phpgw_forum_threads th, egroupware.phpgw_forum_body body,

egroupware.egw_ev_group gr, egroupware.egw_accounts ac,

egroupware.egw_ev_account_group acg

WHERE th.cat_id = id_category AND th.for_id = id_forum AND

th.id = body.id AND th.thread_owner = ac.account_id AND

ac.account_id = acg.fk_id_account AND acg.fk_id_group = gr.id_group AND gr.grows = 0

AND th.depth = 0;

The next step was to make a function that uses this selects and return an object with

this structure:

Object forum{

String forum_category;

String forum_name;

Thread[] forum_threads;

}

Object Thread{

Datetime postdate;

String owner;

String title;

String message;

Int value;

int id;

int depth;

}



This function was made by the Data Base Interface:

function GetDepth($id_category,$id_forum)

With this function, the collaboration was able to complete their objective. We made a

function to write to a file (html) all the messages and replies of one specific forum:

class write

Finally was needed the collaboration of the Synchronous User Interface to make a

button to the user save the files to the disk:

Figure 6.4 – Save the files in the Current Topic of the Forum

These files, when created, are introduced in the database as content.



Messenger

This module is basically a typical messenger service where a user may send internal

m essages to other users. There’s a simple interface providing this service, containing a table

with all messages received by the user, theirs senders and postdates.

Figure 5 – Inbox, Com pose m essage, Read m essage, …

Once the user clicks on a message, it will appear another table containing all details of

the message, including its body. There is also a set of buttons, giving the possibility to compose

new messages and to reply or to forward or delete it.



Figure 6 – Inbox, Com pose m essage, Read m essage,…

When composing a message, the user has the chance to send it to one individual user,

to various users or even to all users registered in the system. It is not implemented the option to

send message to a determined group.

In case of receiving a new message, it will appear a warning advising the user, that has

received a new message in the home page.

Figure 7 – How much new messages the user has

All these functionalities already exist in the module of E-Groupware, but there are some

others could be implemented, as, for instance, the option to send group messages.



Discussion

After finishing this project, we can state that the key objectives were achieved,

essentially the ones acquired by the whole group. We are referring the experience of working in

a group, and developing this project, having in mind the synchronization that must exist in a

project like this one, with the dependencies of each group and the other ones. This experience

of collaboration w as very im portant, even though, it w asn’t easy to perform this w ay.

Referring the objectives of our group, the major ones was partially not reached, which

means that, initially there were many tasks to accomplish, but unfortunately not all of them

were completed. The main reason for this was, probably a poor time management. We began

working in our tasks a little too late, what leave us with less available time to complete our

work.

It would be very interesting to integrate the feature of the groups in our modules,

permitting to have, for instance, forums restricted to users that don’t belongs to the group that

provide the forum. Besides, it would be useful to send messages to a determined group, without

having to select all the members individually. We also can also point out, that a new module

could be implemented, as the other groups, with resources to, for example, create a place of

instant messaging between users.

In our point of view, the discipline should have been organized in a different way. The

project should have more deadlines between the beginning and the end of it, where the

students could show their dedication and their results.



2.7 Content Editor

Overview

The content editor module integrated in the system allows different users to create textual

content in a collaborative manner. Diverse and disperse users can, together, create content

simply by editing a shared document available to all group users in the system database. In a

wide perspective of the concept, different types of data can be shared and remotely edited,

from text to video, as well as giving a mixture of extra functionalities to custom content.

Due to time constrains, this module provides only text editing. This specific type of online

collaboration is usually known as a blackboard system.

In a traditional approach, a blackboard system, in computer science, is composed of an area

of shared memory, referred to as the blackboard that contains a problem to be solved and a

collection of software agents or processes, often referred to as knowledge sources, which can

access and modify the blackboard. Each agent scans the changes to the blackboard, and posts an

updated partial solution based on the state of the blackboard whenever its own internal

conditions for doing so are met. These partial solutions cause other agents to update their

portions of the solution on the blackboard until eventually an answer is found. In this fashion,

the agents work together to solve the problem.

Being just a module inside a complex collaborative system, it needs to have interactions

with other modules that provide and/or receive information. Since, this was a cooperative lab

work, some work done in this module was supported by other groups functions and interfaces.

In an initial phase, the module runs outside eGroupWare using a simple PHP interface just

for testing, but already with an eGroupWare database connection. In a second phase, with

Synchronous User Interface group help, a standard module will provide all the previous

functionalities, but now in accordance to the global system and allowing a straightforward

integration.



Interaction

In the follow ing figure, it’s possible to situate the Content Editor M odule area betw een tw o

other modules to understand how it is integrated and what services are used in these

interactions.

Content Editor

6/11/2006

Whiteboard featureThis feature provides collaborativetext content creation

File to edit

id_object: int(11)fk_id_group_owner: int(11)fk_id_group_owner: int(11)Name: varchar(100)Locked: tinyint(4)stream_path: textfk_id_group_that_locked: int(11)last_update: datetimefk_id_group_last_update: int(11)

Database Interface

Get CE Content

Get CE Files

UpdateContent Lock

User Interface Manager

egw_ev_ce_object

Figure 6.1: Content Editor Module interactions

The User Interface Manager must provide the file to edit name, as well as the respective

Session ID when wants to execute a Content Editor session, in order to specify which file should

be collaboratively editable.

After that information is conceded, the Content Editor interface allows the user to edit the

chosen file, if it is not currently being edited. The file text content is displayed to the user and, if

he wants to edit the actual content, he locks the file for edition, edits it and saves it again with



the new changes. After that, all the other allowed users can see the changes made to the file

content.

In order to access each file, we need to communicate with the global system database. All

the database interactions were passed into simple function by the Database Interface group and

available for simple database request inside internal module code.

The functions provided the Database Interface group were:

get_ce_content($content_name)

This function returns one egw_ev_ce_object with all information about the file with name

equals to content_name.

get_ce_files()

This function returns all the filenames of editable files.

update_content_lock($new_locked_status,$object_name)

This function sets a new_locked_status in the egw_ev_ce_object which file with name

equals to object_name. It sets “1” to block the file for editing and “0” for unlock it.

The final step to complete eGroupWare system integration is the junction between

developed Content Editor code and the user interface provided by the Synchronous User

Interface group. The final result is an eGroupWare module, easily integrated in the final system

with all Content Editor services available there to the final user.



Implementation

At the beginning, the approach was to develop a stand-alone module that provides all

content editor functionalities, using a custom SQL database. Here, the main objectives were to

select, open, write new content and upload it.

After that, it was changed to communicate with a common eGroupWare database, using the

functions provided by the database interface group. Now, the user needs to lock the file before

he can edit it so that the other “editors” cannot change its content w hile he is editing. After he

finishes his content edition, he unlocks the file so that others can edit afterwards, seeing in the

moment the most actual content.

Finally, the initial user interface was substituted by an integrated one for the entire

eGroupWare collaborative system, provided by the Synchronous User Interface group.

Selection of available files

File is locked?

Yes

No

Open file(Editing mode not available)

Return

No

Start editing file?

Editing File(Lock file)

Upload file

End editing file(Unlock file)

Yes

Open file(Editing mode

available)

Start

Figure 6.2: Content Editor module flowchart



This flowchart can be clarified by the according interfaces (still outside eGroupWare

platform):

… $objectoX = get_ce_content($Name); … $FILE_PATH = $objectoX[2]; $action = "start_edit"; sscanf($FILE_PATH,"http://localhost/%s",

$File_Name); … $all_data = ""; $fp=fopen($FILE_PATH, "r"); while (!feof($fp)) {

$all_data .= fread($fp, 1024); } fclose($fp); …

… $Names = get_ce_files(); … echo"<select NAME=\"Name\">"; foreach ($Names as $name){

echo "<option VALUE=$name>$name</option>";

echo"</select>"; …



… update_content_lock(1,$Name); …

… sscanf($FILE_PATH, "http://localhost/%s",

$File_Name); $LOCAL_PATH =

"c:/wamp/www/".$File_Name; $fp=fopen($LOCAL_PATH, "w"); fwrite($fp,$NewText); fclose($fp); …

… update_content_lock(0,$Na

me); …



After the first prototype completed and fully operational, the interface needed to be

changed in order to be integrated inside the developed eGroupWare collaboration system. For

that, it was used the user interface developed by the Synchronous User Interface group in a

similar way. The final version module interface is present in that group report area.

Critical Analysis

The initial Content Editor module goals were too extensive, regarding implementation time

available, since it was used PHP (a programming language not experienced before by the group

members).

Another problem was the long time wasted on lab work phase 1 tasks. The lab work

objectives were constantly changing, leaving sometimes the developers unaware about what to

… <a href=http://localhost/Ev_egroup/EscolherFicheiro.php>Return …



do next. For example, the collaboration platform to be used first (PhProjekt) was substituted by

eGroupWare system, leaving some groups with their phase 1 work completely without use.

Since the lab work was fragmented into many groups distributed over two different lab

classes, it w as som etim es difficult to m anage it. Som e groups didn’t know exactly w hat to do,

the architecture took time to its final version what influenced constant changes.

The final objectives should be well defined at start point in order to provide a fast lift off to

implementation phase. The architecture discussion phase is also extremely important, but it

should be shorter and at lab work starting.

In our opinion, the lab work should be executed brick by brick, in small steps, from a very

simple functional system, and then transform it to a more complex one, according to time

constrains. In this approach, we would always have a complete system implemented for

demonstration. The approach used in this lab work was a bit utopian, what resulted in a

delayed, very simple and incomplete system.

Finally, the main objectives were accomplished; however the final result was a bit away

from initial complex goals.

Conclusions

The main Content Editor module objectives were accomplished. The module provides the

necessary functionalities to create text content in a collaborative way between professors. It

was developed a locking mechanism to avoid problems in concurrent editing: who wants to edit

the file, locks it and avoids other remote edition; when finishes, unlocks it and everyone else can

see the changes made, and modify it again, if they want. There is a known flaw for this module

that happens when a user is editing a file and, by mistake, closes the browser window. In this

case, since the user didn’t unlock the file, nobody else can afterw ards edit that file. Once again,

we assume a correct behaviour by the user.



However, the module could provide other functionalities, such as text format, user changes

identification, insertion of images, or even, video edition, but due to delivery time constrains it

was not possible to implement.

Just to end, it was developed a simple, but working, Content Editor module for the

Computer Supported Collaborative Teaching System supported by the eGroupWare platform,

regarding all the main objectives intended for it.



2.8 Business Project Manager

Overview

The Business Process Manager module (BPM) is composed of 3 sub-modules: BP editor, BP

executor and BP wizard.

From the architecture point of view the BPM is located in the C layer of the ICE model that is

guiding the system ’s general architecture.

The BPM is one of the core modules of the computer supported collaborative teaching

system as it is responsible for the creation of courses and disciplines and the validation and

execution of courses. We will now briefly describe the functionalities of the developed work:

BP editor – allows a user to edit either a course or a discipline. In the former case the

discipline is built given a name, the weekly time payload, recommended execution year

and semester, associated scientific area, a set of precedence and finally the scientific

content. The editing of a course is a more complex operation. Firstly the user will create

a template indicating the number of disciplines, years, classes and students. The

previous will generate an interface with empty slots. These slots are to be filled by the

course creator and his own will or with the help of the BP Wizard Module. When editing,

all the actions such as inserting a discipline or removing it have an immediate impact in

the database (DB) meaning that, if for some reason, the computer running the editor

fails the editing can be continued normally afterwards as all the input has been saved in

the DB. This feature similarly allows courses to be created as open running works rather

than one shot ones.



BP executor – verifies whether a given course can be executed and in the case it is

allows the user to execute it. The previous actions suppose that the availability of

teachers has been checked, in term s of tim e, and that all the discipline’s precedence has

been met.

BP wizard - The Business Process Wizard (BPW) module is responsible for the matching

of students and courses. Given the preferences of disciplines from students and

companies, this module gives the complete set of disciplines needed to form a new

course. The courses created by this module are completely independent from the

courses already designed and are only a suggestion. The list of disciplines that compose

the course can be changed by the maker of the course. The opinion of both the students

and the companies are entered in the local database. This module identifies and sorts

their opinions and gives them a ratio to be used to define the importance of each area.

The sum of all these ratios defines what areas are in the one-of-a-kind course.

As an overview of the BPM the reference architecture was the following:

BP Module

Business Process EDITOR

course 1 course 2 course 3

creationcreation

Edition

Business Process Executor

Database

Validation and execution upon finishing

stora

ge w

ithou

t exe

cutio

n

opening for edition

course 1 course 2 course 3

BP wizard

data

analy

sis

suggestion

s

Figure 8.2 – BPM reference architecture



Interaction

As a part of C (middle) layer the BPM must necessarily interact with upper and bottom

layers therefore this work has integrated the manageBP module supplied by the DBinterface

team and an effort was made to fully integrate the code in an e-groupware interface. The

interface integration was coordinated with the interface design team.

Implementation

We will divide this section in BP Editor, BP Executor and BP Wizard implementation.

BP Editor

The BP Editor was tested using a PHP/HTML form. This form has all the required input and

output fields for testing and demonstration purposes.

Working with disciplines

Figure 8.3 – Discipline Editor – test form.



To use this form for creating a discipline one must fill in all the inputs except for the

precedence add hit ADDDISCIPLINE button this will run the following code in bp.php:

if (isset($_POST['ADDDISCIPLINE']))

CreateDisciplineWithContent($_POST['Discipline_Name'],$_POST['time_payload_week_hrs'],$_POST['discipline_year'],

$_POST['discipline_semester'], $_POST['associated_cientific_area']);

The function CreateDisciplineWithContent has the following declaration:

function CreateDisciplineWithContent($name, $time, $year, $semester, $area){

$discipline = array('name' => $name, 'time_payload_week_hrs' => $time, 'discipline_year' =>$year, 'discipline_semester' =>

$semester, 'associated_cientific_area' => $area);

CreateDiscipline($discipline);

}

Basically this function reads all the inputs marshals them into a $discipline variable

afterwards the function CreateDiscipline($discipline) function is called to store the data in the

DB.

Rem oving a discipline is done using the disciplines nam e’s and pressing

REMOVINGDISCIPLINE which will run on:

if(isset($_POST['REMOVEDISCIPLINE']))

removeDiscipline1($_POST['Discipline_Name']);

As seen above the function removeDiscipline1($name) is invoked;

function removeDiscipline1($name){

RemoveDiscipline($name);

}



From the code point of view this calls RemoveDiscipline($name) which removes a certain discipline

by name from the DB.

Regarding the Precedence of a discipline one can either add or remove. Here it should be

empathised that this field is an array meaning that one discipline may have several others as

precedence. Considering this, each time the ADDPrecedence or the REMOVEPrecedence are

stroke the discipline whose name is in the Precedence field will be either added or removed

from the array in the DB. This is achieved in the following code:

if(isset($_POST['ADDPrecendence']))

addPrecedence($_POST['Discipline_Name'], $_POST['precedence']);

Invokes:

function addPrecedence($disciplinename, $precendecename){

addPrecedenceToDisciplineByName($disciplinename, $precendecename);

}

Which calls addPrecedenceToDisciplineByName($disciplinename, $precendecename);

responsible for associating the precedence with the discipline in the DB.

The removing action is analogous:

if(isset($_POST['REMOVEPrecendence']))

removePrecendenceFromdiscipline1($_POST['Discipline_Name'], $_POST['precedence']);

function removePrecendenceFromdiscipline1($disciplinename, $precendecename){

removePrecendeceFromDisciplineByName($disciplinename, $precendecename);

}

Adding contents to a discipline works in the same way as adding precedence. The main

difference in this case is on the interface which presents all the existing content is a listbox. In an



effort to de-attach de core code from the interface code the group has decided do use two lists

for the purpose of displaying information in the form. The referred lists are the following:

global $content;

global $selectedcontent;

The first one contains all the entries of content in the DB while the second has the user

input. We must stress that this information is used only to refresh the data shown in the form

and is loaded every time a change occurs in the form.

The code related to the adding and the removal of content is the following:

if(isset($_POST['ADDContent']))

if ($_POST['content']){

$content1 = GetcontentByNameInAllcontent($_POST['content']);

echo $content1['name'];

SetSelectedcontentInselectedcontent($content1);

AddContentToDiscipline($_POST['Discipline_Name'], $_POST['content']);

}

The functions used in the adding procedure are the following:

$content1 = GetcontentByNameInAllcontent($_POST['content']); - returns a content

out o the $content list given a name.

SetSelectedcontentInselectedcontent($content1); - puts the retrieved content in the

$selectedcontent list.

The third as the following declaration:

function AddContentToDiscipline($disciplinename, $contentname){

addContentToDisciplineByName($disciplinename, $contentname);

}

It simply passes arguments to addContentToDisciplineByName($disciplinename,

$contentname) which working over the DB associates contents with the discipline.

Removing is similar

if(isset($_POST['REMOVEContent']))

if ($_POST['content1']){

DeletecontentInSelectedcontent($_POST['content1']);

removeContentFromDisciplne1($_POST['Discipline_Name'], $_POST['content1']);

}



DeletecontentInSelectedcontent($_POST['content1']) – removes de content entry by name

from the list.

Concerning the database data the code is:

function removeContentFromDisciplne1($discipline_name, $content_name){

removeContentFromDisciplineByName($discipline_name, $content_name);

}

This calls the function that removes content from a discipline given its name.

Next we will explain the course editor.

Working with courses

Figure 8.4 – Course Editor – test form.

The behaviour of the course editor is similar to the one presented for the disciplines.

When New is pressed an entry of a course is created in the DB and according to the number

of years the correspondent free slots are exhibited in the centre of the form. In the right there is

a persistent list with all the disciplines present in the DB.



To create a course the following code is used:

if(isset($_POST['NEW'])){

CreateCourse1($_POST['name'], $_POST['years'], 0, $_POST['students'], $_POST['classes']);

}

function CreateCourse1($name, $year, $execution, $students, $classes){

$course = array('in_execution' => $execution,

'name' => $name,

'max_number_of_students' => $students,

'max_number_of_classes' => $classes,

'duration_years' => $year,

);

CreateCourse($course);

}

As can be seen CreateCourse1($name, $year, $execution, $students, $classes) encapsulated

all the necessary data to create a course. This information is the passed to

CreateCourse($course) which creates an instance of the course in the DB.

The removal is similar and is done by course name. This is achieved in the following code:

if(isset($_POST['REMOVECOURSE']))

RemoveCourse($_POST['name']);

function RemoveCourse($name){

DeleteCourse($name);

}



The code goes straightforward to the DB and removes the course by means of the

DeleteCourse($name) function.

Striking the LoadFromName button will cause the interface to show the disciplines that are

associated with a course.

Adding and removing disciplines from a course works similarly to the operations over the

contents in the disciplines. Again two lists were used:

global $alldisciplines;

global $selecteddisciplines;

The first stores all the disciplines in the DB and the second keeps track of the user input.

Again these two lists are only for showing information in the form. The code associated with this

is the following:

if (isset($_POST['ADD']))

if ($_POST['list1']){

$discipline1 = GetDisciplineByNameInAllDisciplines($_POST['list1']);

$discipline1['discipline_year'] = $_POST['Year'];

$discipline1['discipline_semester'] = $_POST['Semester'];

SetSelectedDisciplinesInSelectedDisciplines($discipline1);

addDisciplineToCourseByName1($_POST['name'], $_POST['list1'], $_POST['Year'],$_POST['Semester']);

}

if (isset($_POST['remove11'])){

DeleteDisciplineInSelectedDisciplines($_POST['list11']);

DeAttachDisciplinefromaCourse($_POST['list11'],$_POST['name']);

}



When adding the first four line only concern transferring the discipline between lists in order

to displays them on the form. The most important functions in this code are

addDisciplineToCourseByName1($_POST['name'], $_POST['list1'],

$_POST['Year'],$_POST['Semester']) and

DeAttachDisciplinefromaCourse($_POST['list11'],$_POST['name']); they call the correspondent

DB functions to add and remove disciplines from a course given its name. Their declaration is as

following:

function addDisciplineToCourseByName1($coursename, $disciplinename, $yearincourse, $semesterincourse){

addDisciplineToCourseByName($coursename, $disciplinename, $yearincourse, $semesterincourse);

}

DeAttachDisciplinefromaCourse($_POST['list11'],$_POST['name']) eliminates the connection

between a discipline and a course e the DB.

BP Executor

As previously said the BP Executor can either validate or/and execute a course. The

validation is relatively complex and takes into account the availability of the teachers and the

precedence of the disciplines.

The following flowchart exemplifies the algorithm used to validate a course:



Free

Teache rs?

y es

no

M ainTe st ($Co u se _name )

SearchTeathe r()

SearchPrecedence s ()

P re cedence sv a lid?

y es

Co u rse V ad id

Co u rse In vad id

no

Figure 8.5 – Testing and validating a course.

The user may choose to validate and immediately put the course in execution this is

achieved in the following manner:



Free Teacher s?

yes

no

MainExecute($Couse_name)

SearchTeather()

SearchPrecedences()

Precedences

valid?

yes

Course Vadid

Course Invadid

no

WriteCourse()(Database Update)

Figure 8.6 – Algorithm for validation and immediate execution of a course

From the previous can be seen that in order to validate a course the algorithm firstly testes

the teachers. In a very general way teacher availability test is performed by locally distributing



the disciplines of a given area by the free teachers of that area. If in this process all the

disciplines are correctly allocated the test is passed. Otherwise if the described process fails

because the available teachers haven’t got the enough free tim e the test fails. This test goes as

follows:

Search Teache r

Ge t co u rse 's d isc ip line

Ge t teache r by

d iscip line 's area

Ge t teache r's to tal bu sy

ho u rs

1) Ge t teache r's to tal bu sy ho u rs - d isc ip line 's h o u rs fo r w eek <= max teache r's h o u rs fo r w eek

1)

Las t c our se 's

dis c ipline?

no

y es

The re are teache r to all d isc ip line s

Save the teache r in the

memo ry

A re the re

teache rs?

y es

The re are 'n teacher to a ll dis ciplines

(Cours e inv a lid)

no

no

y es

Figure 8.7 – Teacher availability test



After the previous validation the system w ill validate the course in term s of discipline’s

precedence. This happens according to this flowchart:

1) P recedence_year = D isc ip line_year and P recedence_semeste r < D isc ip line_semeste r

o r

P re cedence_year < D isc ip line_year

Search Precedence s

Ge t co u rse 's d isc ip line

Ge t d isc ip line 's

p recedence

1)

no

Precedence s in valid s

y es

Ar e t her e

dis c iplines ?

y esLast

P recedence ?

y es

no

Precedence s valid s

no

Figure 8.8 – Discipline Validation

The basic idea of this test is, from all the disciplines verify the precedence. This means that if

any of the disciplines analysed are moved behind a precedence the test fails. Otherwise the test

is passed.



Recommended Disciplines

All Disciplines Available

Enterprises Preferences

Existing Course Disciplines

Ponderation Enterprises/Students

Students Preferences

No of Groups

Group

G roup’s P references

BP wizard

The main problem for the elaboration of a course is the lack of external influences beside

the teachers believes. The teachers are, beyond doubts, the main pillar of any learning

structure, but without an orientation towards a technological and dynamic world the courses

may become obsolete. So the main goal of this module is to make sure that none of these

precious information stays out of the game.

After some intense discussion and tries the architecture developed has the following aspect:

Figure 8.9 – BP wizard Structure

1

2



First Module:

The [1] scheme is the actual decision system. The input is the all the disciplines that the

database held, the controllers are the preferences of enterprises and students (each

student/enterprise can have more than one preference and each as is weight based on a

numeric scale for 0 to 10), a ponderation that allows the user to decide the importance given to

enterprises and students ( with ponderation 1 the results reflects only the enterprises

preferences and with ponderation 0 the students preferences), and the disciplines associated to

the course that is being processed, to prevent, when invoked, duplicated disciplines in the

course.

Second Module:

This scheme [1] is appropriate if we consider that the students have well distributed

preferences. Being untrue, it is crucial to get an more homogenic group of students. For

example, in a universe of one hundred and fifty students, certainly there is more than one

nuclear preference. To find more than one nuclear preference, the students have to be divided

in groups.

The first step is to choose how many groups of students are wanted. For the universe

considered before it will be established three groups of students.

Getting all the students and their preferences is the second step. Then the preferences are

added so they can resolve as a distribution of preferences like the figure under.

preferences

0

20

40

60

80

100

120

Electro Maths Geology Robotics Software Economy

preferences

Figure 8.10 – Global preferences



Having this, the most voted preference is taken as the orientation to the formation of the

first group. A query to the database is made in order to get a sorted list of students that have

the chosen preference. For the most interested student of this preference to the (maximum of

students/num ber of groups) interested student, w e add his preferences to a new list (group’s

preferences) and retrieve the same preferences from the original list. When the process of

creating the first group ends, the creation of the second begins. Getting the distribution of the

now modified original list, the process repeats until all the students/groups are covered.

Preferences Group 1

0

5

10

15

20

25

30

35


Figure 8.10 – Group 1 preferences

Global Preferences After the creation of the 1st group

0

10

20

30

40

50

60

70

80


Figure 8.11 – Global preferences without Group 1



Main Functions

GetDisciplineList($course_name) – obtain all disciplines available to fill the course, first fetch

all available disciplines in the database and then removes the ones that are already in the

course.

getAreasfromUsers() – get preferences from students and enterprises without ponderation.

GetNumberFromAll($Students, $Enterprises, $pond) – given de ponderation ($pond) it

calculates one list with the areas sorted from the most preferred to the least preferred.

Critical Analysis and Future Work

Before presenting any consideration on the achieved results it’s of m ajor im portance to

stress out that time was a major constrain along the development phase. Having stated this we

acknowledge that more sophisticated results could have been achieved.

We would like to point out several factors that, in our opinion, delayed the development of

the work:

The first phase of the project took more time than it should have. We fully understand

the need to investigate prior to system development but considering the total time

available this phase should have been shortened.

The system ’s architecture, the platform ’s choice and the definition of the modules

features/objectives took more time than it should throwing the development phase

over the end of the semester – a critical time.

The development programming language was PHP which was barely know to most of

the developers increasing the overall difficulty of the project.

We have implemented several basic features of this module. In future development it would

be interesting to extend this work implementing more complex course templates, more flexible

course and discipline editing features and extending the executor to consider other validating

factors. Concerning the executor it would be interesting to allow users to confirm and/or



changed the professor allocation to disciplines in courses. The implementation does this in a

automatic way which is not applicable in real world scenarios.

In future implementations of this work a special care has to be taken concerning the

resolution of some bugs. In this implementation of the BP Editor it is possible to add disciplines

to a nonexistent year in a course.

Conclusions

As previously noticed the objectives were globally met although more sophisticated

implementations could have been achieved in other circumstances.

Nevertheless the present work proofs the validity of the reference architecture and can be

easily added-on with extra functionalities.

The authors would also like to point out in a positive manner the experience of developing

work in a large team they only regret the lack of commitment of some people that delayed the

final delivery and integration. Nevertheless the overall experience was great!



2.9 Database Interface Module

Overview

The data-base integration module will be responsible for the communication between the

data-base and the upper layer modules. The correct implementation of this module is crucial for

the global functioning of the system.

The upper layers will communicate recurring to parameters passing, being the results

returned inside of matrixes or any other sort of structure, according to the upper layers

preferences or according to our preferences if nothing is asked.

Two groups were assigned for this task. Initially one would be responsible for the user

management and another one responsible for the content management. Both of these groups

have agreed to make a fusion and work as a whole. By doing it this way, it was assured that the

responsibles for each upper layer module communicated with only one team, centralizing the

problem a little bit. According to this, the groups have been developing the necessary modules,

with active participation in the developing of the other modules, in order to facilitate the

integration in the end of this project.

Interaction

The development of this project has been faced since its beginning as a very strong

challenge, having all the groups to work for the same goal. This group has been in contact

especially with the coordination group, who has been developing the SQL queries which would

allow the other modules to communicate with the database. It was our intention to develop

most of the functions immediately, in order to solve only punctual problems in the final stage of

this project. It was obvious since the beginning of this task that final tuning would be necessary,

and tim e shouldn’t be w asted in the end, despite our efforts to overcome this issue, code was

still being created while the project was close to its ending.



In order to get the show on the road, it w as “only” necessary to w ait for the groups to have

clear ideas on the functionalities they desired to implement. Having things cleared, it made it

possible for this group to start developing the necessary functions for the whole task. While

developing functions it was necessary to maintain a good communication with the groups that

requested functions from the database, in order to discuss the implementation, information

exchange, results, among others.

Implementation

Despite the fact that PHP was (is) a totally new language for us, no extreme difficulties

were found while developing this project. As the functions and modules were growing, it

became evident that PHP is a powerful language.

As previously mentioned, it was necessary to wait for other groups to submit us their needs,

which became a problem, as deadlines were not set and groups kept sending new requests as

the project was reaching its deadline. Problems were overcome and we believe everything is

working properly.

Functions Provided

According to the functions requested, separate files were created for each of the modules,

containing the necessary functions. On this section a short description of each file, as well as of

each function will be made.

Blogger.php: This module is responsible for communicating the blog module with the

database.

getUserInfo($userName) : This function returns the information (first name, surname,

nationality, birth date, etc.) about a given user.



getBlogName($GroupName): This function gets information (blog name, creation date and

number of views) from the database about the blog of a given group.

This function is similar to getCreationDate($BlogName), but with a slight difference. Now,

the user will define the name of the blog and database will retrieve information about the given

blog.

getPostCount($BlogName): This function will return the number of posts of a given blog.

getPosts($BlogName): Giving the name of a blog, this function will retrieve information, like

the title of the post, the text and the name of the author of all the posts in a blog.

getPostComments($PostTitle): As in all blogs, every post will be able to get comments from

other users. This function will look for comments of a given post.

SetBlogName($NewBlogName, $OldBlogName): This function will allow a user to replace

the name of a blog by a new one.

CreatePost($BlogName, $UserName, $PostTitle ,$Text): This function is fundamental in

every blog. By invoking this function, the database will be updated with the information of a

new post.

SetPostComment($UserName, $BlogName, $PostTitle, $CommentTitle, $Text,

$PostRating): Very similar to the last described function, this one will allow a user to make a

comment on a post. The comment will contain text and a rating.

getBlogAdmin($BlogName): This function will retrieve the name of the administrator of a

blog.

Multimedia.php: This module will allow the communication between the multimedia

management module and the database.



listDir($dir_name): The aim of this function is to return all the files inside a given directory

or of all directories in the root if no directory is specified.

putFile($fileName): This function allows a user to add a file to the database.

deleteFile($fileName): Analogous to the previous function, for removing files from the

database.

ManageBP.php: This module is responsible for establishing the communication between the

Business Process Editor and Executor modules and the database.

The ‘Discipline’ object is defined the follow ing w ay:

Discipline

int id;

int name;

int time_payload_week_hrs;

int discipline_year;

int discipline_semester;

string associated_cientific_area

array of String contents;

array of String precedence;

function CreateDiscipline($discipline): The input of this funtion is a discipline type object,

and the output is void.

function addPrecedenceToDisciplineByName($discipline_name, $precedence_name): This

function adds a discipline precedence to another discipline. The input is the name of the

discipline and the precedence. The output is void.



function addContentToDisciplineByName($discipline_name, $content_name): Similar to

the previous function, but adds a content instead.

function RemoveDiscipline($discipline_name): Removes from the database all references

to a discipline. The input is the name of the discipline. Output is void.

function AttachDisciplinetoCourse($discipline_name,$course_name): Integrates a

discipline in a course. The input is both the name of the discipline and the course. Output is void.

function DeAttachDisciplinefromaCourse($discipline_name,$course_name): Similar to the

previous function, but removes the reference instead.

function addDisciplineToCourseByName($course_name, $discipline_name, $year,

$semester): Similar to AttachDisciplinetoCourse, but adds more information: Year and

Semester.

function SetDiscipline($discipline) Edits a discipline that already exists in a database. The

input is a discipline type object. Output is void.

function removeContentFromDisciplineByName($discipline_name, $content_name):

Similar to addContentToDisciplineByName, but removes instead.

function removePrecendeceFromDisciplineByName ( $discipline_name ,

$precedence_name) : Similar to addContentToDisciplineByName, but removes instead.

function getAllAreas(): Returns every Areas in the database (array of [id,cientific_area])

(int,string)

function getAllContents(): Returns every Contents in the database (array of

[id,name,isFinal]) (int, string, Boolean)

function getAllDisciplines(): Returns every Disciplines in the database (array of Discipline)



function GetDisciplineByName($name): Returns a specific discipline from the

database. The input is the name of the discipline.

function GetDisciplineByCourse($course_name): Returns every disciplines (array of

discipline) in a course. The input is the name of the course.

function GetDisciplinesByYear_Semester_Course($year, $semester, $course_name):

Similar to the previous function, but specific to a semester and year.

function GetDisciplineByYear($year): Returns every disciplines thought in a specific year.

function GetDisciplineByYear_Semester($year,$semester): Similar to the previous function,

but filters the semester.

function getDisciplineYear_SemesterByName_Course( $discipline_name , $course_name) :

Returns only the Year and Semester [year(int), semester(int)] of a specific discipline of a given

course.

function getDisciplineCourseTeacherByYear_Semester($year,$semester): Similar to

GetDisciplineByYear_Semester but returns the Course and Teacher related. Array of

[course_name(string);discipline_name(string);teacher_name(string)]

The ‘Teacher’ object is defined the follow ing w ay:

Teacher

String name;

array of String areas_he_can_teach;

int max_working_hours;

int available_time_for_classes;



function SetTeacher($teacher_name,$working_hours): Sets the working hours of a given

teacher that already exists in the database. Returns void.

function associateTeacherToCourse($teacher_name,$course_name,$work_hours):

Associates a teacher to a course, and specifies the necessary working hours. Returns void.

function dissociateTeacherToCourse($teacher_name,$course_name): Similar to the

previous function, but disassociates instead.

function GetTeacherByName($name): Returns an object of type Teacher given a specific

name.

function getAllTeachers(): Returns every teacher in the database. Array of Teacher object.

function GetTeacherByArea($area_name): Returns every teacher of a certain area in the

database. Array of Teacher object.

The ‘Course’ object is defined the follow ing w ay:

Course

int id;

bool in_execution;

String name;

int max_number_of_students;

int max_number_of_classes;

int duration_years;

array of string all_disciplines;

function CreateCourse($course): The input of this function is a course type object, and the

output is void. The list of disciplines associated to the course is added using

AttachDisciplinetoCourse, explained above.



function DeleteCourse($course_name): Removes from the database all references to a

course. The input is the name of the course. Output is void.

function SetCourse($course): Edits a course that already exists in a database. The input is a

course type object. Output is void.

function lockCourse1($course_name,$account_name_that_locked): Locks a course so that

no one can edit it except the person that locked it. Output is void.

function unlockCourse($course_name): Unlocks the course. Output is void.

function associateGroupToCourse($course_name,$group_name): Associates a group to a

course. Output is void.

function dissociateGroupToCourse($course_name,$group_name): Disassociates a group to

a course. Output is void.

function getAccountAssociatedToGroup($group_name): Returns the accounts associated to

a given group (name). Returns an array of [account_id(int);account_lid(string)].

function getGroupsAssociatedToAccountByName($account_name): Returns the groups

associated to a given account (name). Returns an array of [group_name(string)].

function getCollectiveGroupsAssociatedToAccountByName($account_name): Returns the

collective groups associated to a given account (name). Returns an array of

[group_name(string)].

function getAllExistingGroups(): Returns every groups that exist. Array of

[group_name(string)].

function getCourseLockState($course_name): Returns the lock state of a given group in the

from: [locked(bool), last_lock_change(date), account_lid(string)].



function getAccountsAssociatedToCourse($course_name): Returns every accounts that

have permission th edit the specified course. Should be used for authentication. Returns an

array of Strings.

function getGroupsAssociatedToCourse($course_name): Returns every groups that have

access to the specified course. Returns an array of Strings.

function getNonExecutingCoursesByGroup($group_name): Returns the name of the

courses that are still not in execution. Returns an array of Strings.

function getExecutingCoursesByGroup(group_name): Returns the name of the courses that

are already in execution. Returns an array of Strings.

function getAllCourses(): Returns an array of every Courses that exist on the database (only

the name - Array of Strings).

function GetCourseByName($course_name): Returns the course object specific of the given

name.

ManageBPWizard.php: This module is responsible for establishing the communication

between the Business Process Wizard module and the database.

The ‘Preferences’ object is defined the follow ing w ay:

Preferences

int id;

String name;

String user_type;

Array of string area;

Array of int grade;



function getAllUsersPreferedAreas(): Returns every preferences of existing students and

enterprises. Returns an object of type ‘Preferences’. The grade has a value betw een 0 and 10.

function getUserPreferedAreas($user_name): Similar to the previous function, but specific

to a given username.

function getAllCientificAreas(): Returns the name of every existing scientific areas.

function getDisciplineByCientificArea($associated_cientific_area): Returns every discipline

with a given scientific area associated. Returns in the form of an array of Discipline objects

function getDisciplinePrecedences($discipline_name): Returns the precedences os a given

discipline, in the form of an array of Discipline objects.

function GetDisciplineByCourse($course_name): Similar to a function in BP Editor and

Executor.

function addUserPreferedCientificArea($user_name, $preference): Adds a preference to a

given user. The preference must be in the following form: Area_Grade (example:

“M atem atica_10”)

function getUserPreferenceInfos($cientific_area_name): Returns in decreasing order an

array of [username(string);grade(int)] of a given scientific name. The order is related to the

grade, so that in the first entry is the user that classified best that area.

getForum.php: This module is responsible for establishing the communication between the

Collaboration module and the database.



The ‘forum ’ object is defined the follow ing w ay:

forum

String forum_category;

String forum_name;

Thread[] forum_threads;

The ‘Thread’ object is defined the follow ing w ay:

Thread

Int id;

Datetime postdate;

String owner;

String title;

String message;

int depth;

int value;

function GetDepth($id_category,$id_forum): This function returns the depth of a certain

message, given the id of the category and the id of the forum. The depth is the number of

parent messages that are above it.

function GetValueForId($id_category, $id_forum, $id): Returns the value of a message

given its category, forum, and specific id. The value is a code to identify each message so that

the structure of the forum can be preserved.

function GetForum($id_category, $id_forum): Returns an object of the type ‘forum ’ given

its category and forum id. This function uses the functions presented above, and is the only

function public to the upper modules.

Content Editor Functions (CEfuncs.php)- This module is responsible for establishing the

communication between the Content Editor module and the database.



Get_ce_content($content_name): This function returns the name, path, the lock state, the

lock last update, the group last update;

Update_content_name($new_name, $last_name): This function updates the user name,

fisrt name and last name;

Update_content_lock(bool new_locked_status, string object_name): This function

changes the current status state;

Update_content_lock_group($group_name, $object_name): This function updates the

name of the group that has locked.

Add_user($group_name,$content_name): This function allows a certain group to have

access to existing content;

New_content($group_host_name,$ content_name,$content_extension): This function

creates a new content with a certain name and allows access to it, for a group;

UIM functions: This module is responsible for establishing the communication between the

UIM module and the database.

Get_user_groups($user_group_name): This function returns the name of all groups from

where the user belongs;

Get_group_sessions($group_name): This function returns all “Content Editor” and

“Business Process” sessions that are running for a certain group;



Get_group_users($group_name): This function returns all user names of a certain group;

UIM classes:

There were created three classes, class Individual_Group, Class Collective_Group and Class

Sessions, to support some functions required for UIM. These classes are simple objects that are

used in some functions as well as get_it_all($user_group_name) and

get_individual_groups($group_name), functions that w e’ll be described bellow :

Get_it_all($user_group_name): This function returns all collective groups. For each one of

them returns the name, sessions and users;

get_individual_groups($group_name): This function returns all users names, sessions and

status;

Conclusions

During the development of this project it was possible to see how hard it is to conceal the

interests of 40 people with a same goal and different tasks.

The initial idea of this module was to be divided in 5 different modules:

Figure 9.1 : Relevant ICE model area.



DB interface – This is the module that receives or sends the information to the upper

modules, or to the Database.

User group manager – Treats the information related to the user.

Content manager – Treats the information related to the content posted by the users.

Session manager – Treats the information related to the sessions that users create in some

upper modules.

Module manager – Treats the information related to the module itself.

Instead of using this idea, we thought that it would be easier to create a single php file to

treat each upper module. So, for example, for the Blogger Module, we created a Blogger.php

file.

This work was very useful to learn how to program in PHP, and we think that in that aspect it

fulfilled the objective.

Critical Analysis

The first phase of the work took plenty of time, which could have been useful in the final

stage of this project.

Regarding this group’s goals, it w as necessary to w ait for instructions from other groups.

Some groups took a long time to notify us about their needs, which overloaded us with work in

the final stage. We believe it would be more efficient for this group and the database managers

to make only small changes in the final stage to correct small mistakes, instead of remaking

functions (and the database also) in a rush.



Future Work

Regarding the w ork done so far, it’s easy to conclude all the coding is som ew hat vulnerable

to errors. Making these functions more robust should be done in order to make all the work

done so far more professional, though, as it’s not a plan to sell it, it’s a total w aste of tim e.

As w e still lack som e skills regarding PHP, som e coding w as “ham m ered” w hich m ight m ake

som e functions less efficient than they could actually be. Perhaps, it w ouldn’t be a bad idea to

get someone who knows PHP better than to look at the code and make it more efficient.



2.10 Database Manager

Overview

Database Manager was the initial software experts. Their tasks also included general

project coordination, database construction, update and queries creation.

During phase one of this research two task 6 groups explored the potential of the

original suggested platform, PHProjekt, and researched for alternative platforms and their

potential for development. In the end both groups merged into one which coordinated the

whole project involving two classes. After this process the chosen platform was EGroupWare

mainly based on the documentation available and the simplicity of the mainframe structure

presented.

These two classes combined gave the opportunity to produce a much more complex

project, which resulted in higher level development.

All the database construction and assorted queries were supplied by this cooperative

task force to the upper levels. This group was the lowest level of the project.

Other objectives of this group during the implementation process were to make the task

groups as collaborative as possible, help with the PHP/HTML code implementation if needed,

help to add a graphical and content integration of the modules with EGroupWare and combine

and compile all the module tasks for the final presentation.

Interaction

The figure 10.1 modules were the lowest level modules which interacted with the upper

level Control modules through Database Interface super module (DbI). Beside the Database

Interface module we can also acknowledge the Database Manager module where the database

is actually at.

Requests were made by upper level modules to the Database Interface manager which,

in his turn, requested the database manager for queries to build objects. These objects were

used by the upper level modules to fulfill their needs.



Figure 10.1: Module interaction.

The continued evolution of the different modules lead to an ever-evolving Diagram of

Entities and Relations (DER), the final version of is presented in figure 10.2.

Coordination

The coordination of this project was very hard to achieve because of the dependency of

several inherent factors.

The work process involved two classes with common needs but incompatible working

schedules. Those barriers were transposed by the coordinator task making internal shifts in

order to be present in every class.

Egroupware platform presented an additional difficulty for the groups in terms of

integration and installation of the respective modules. Because of this, everyone made an extra

effort to understand the mainframe working system by searching and reading tutorials about it.

Most of the project staff had no experience with PHP language so, dominating the art of

programming in PHP was another big task for everyone.

In the process of integration of all the modules in the system several problems

appeared. Most of these problems had to do with understanding what parameters are passed in

and out of the module and their compatibility.

The main ideas for each module evolved as time went by because of many aspects of

implementation or functionality. Several times there were deep changes in the modules and in



the worse cases even changes in the initial objectives. One of the groups even changed its

module because the initial idea had no sense in the context of the new and matured project.

Figure 10.2: Implemented DER.



Implementation

It was created a functional database in order to get the system working and start with

the modules implementation. This database contained all the vital data essential to the good

working of the system. It was integrated with the EgroupWare database in order to add more

features to its base functionalities.

As the modules were developed more data tables and parameters were added to the

database in order to support the functions of these modules.

Many SQL queries were created to implement functions that would access the database

content. This w ay higher levels of operation didn’t had to w orry about database content

manage. This group passed the queries to the Database Interface that transformed the data to

objects using functions and passed what was desired to higher levels.

Similarly to the modules development the initial structure of the database suffered

some changes as the project was growing.

Conclusions

The main objective of this project was achieved with a good collaboration between

groups. Since there were two classes working at the same time with the same goal, and most of

the modules had some dependency from one another, the communication and relation of the

groups was essential.

As the project evolved all the groups made an effort to cooperate between them and,

fortunately, none gave up in the middle of the process which was fundamental to the good

health of this project. The reflex of this cooperation and hard work was that all the groups

presented a working module and in the end was possible to do a full integration between them

and EGroupWare to comply as a working tool.

All the project staff did a great work as we can see in the final result of the

implementation.



Section 3: Conclusions

3.1 Conclusions

This was just one of many steps in the collaborative network (CN) world. As time

progressed the interaction between the course of Virtual Enterprises and this research project

became more and more solid.

It’s necessary to take into account that a lot of w ork is still to be m ade in this area of

knowledge. As no solid reference model as yet been widely accepted some aspects of this kind

of research project aren’t totally focused1. The interaction between the enterprise world, the

teachers and courses w asn’t com pletely defined, so m ore w ork should be done in this chapter.

This project started as a local work of research and development (R&D), but rapidly

evolved to a full scale CN. The development of most of the modules was made by each task

force group interacting with each other as much as possible trough the available CSCL tools

(moodle), and trough personal contacts in the class room and elsewhere.

At any given time there were more than 30 people working in the various modules, it

should be taken into account that most of the participants in this R&D project, worked for the

first time in such a large enterprise, so we all took a crash course in the challenges presented in

this kind of work.

This is a real world tool with real world applications, and places the participants of its

development as front runners in the virtual organizations world.

Although the final work tool presented was not fully functional at the time, a

recommendation must be placed; if funding becomes available, by 7th framework funds or other,

this project should be continued with the task force groups.

1 Based on the article: TOWARDS A REFERENCE MODEL FOR COLLABORATIVE NETWORKED ORGANIZATIONS, Luis M. Camarinha-Matos 1; Hamideh Afsarmanesh, In Proceedings of BASYS’06 (Springer) – Niagara Falls,

Canada, 4-6 Sept 06



This is a real world tool with real world applications, and places the participants of its

development as front runners in the virtual organizations world.

3.2 Future Work

Although the final work tool presented was up to specifications, there is room for

improvements, (the already mentioned collaboration with the industry market), and new functionalities could be added.

So ending this report w ithout the follow ing recom m endation w ouldn’t feel right; if funding becomes available, by 7th framework EU funds or other, this project should be continued.

This is a useful and necessary tool that can greatly enhance the teacher-student-work industry working relation creating a defacto virtual organization in the university world.

3.3 Web References

Egroupware

o http://www.egroupware.org/

Egroupware etemplate manual

o http://egroupware.org/egroupware/etemplate/doc/etemplate.html

Egroupware etemplate reference

o http://egroupware.org/egroupware/etemplate/doc/reference.html

W3 Schools

o http://www.w3schools.com/php/

FileNet Team Collaboration Manager

o http://www.filenet.com/English/Products/Team_Collaboration_Manager

MSN Messenger Class

o http://flumpcakes.co.uk/php/msn-messenger.

BlackBoard Software, Inc.

o http://www.blackboard.com

Php Freaks

o http://www.phpfreaks.com/

http://www.egroupware.org/

http://egroupware.org/egroupware/etemplate/doc/etemplate.html

http://egroupware.org/egroupware/etemplate/doc/reference.html

http://www.w3schools.com/php/

http://www.filenet.com/English/Products/Team_Collaboration_Manager

http://flumpcakes.co.uk/php/msn-messenger

http://www.blackboard.com/

http://www.phpfreaks.com/



Software in education revolution

o http://br.news.yahoo.com/060605/25/15fkd.html

Wikipedia – BlackBoard Inc.

o http://en.wikipedia.org/wiki/Blackboard_%28software%29

Wikipedia – BlackBoard System

o http://en.wikipedia.org/wiki/Blackboard_%28computing%29

Wikipedia – Virtual learning environment

o http://en.wikipedia.org/wiki/Virtual_learning_environment

Php Freaks


Php.net

o http://www.php.net

Classes and Objects

o http://pt.php.net/oop

Php Freaks


Integrate a Database with Your Website – MySql and PHP

o http://www.thebook.com/sql.html

MySql

o http://www.mysql.com/

3.4 Book & Article References

Janet Valade, PHP 5 for Dummies ®, Wiley Publishing, Inc. 2004

Camarinha Matos – Elements of a base VE infrastructure (2005a). In J. Computers in

Industry, Vol. 51, Issue 2, Jun 2003, pp. 139-163.

http://br.news.yahoo.com/060605/25/15fkd.html

http://en.wikipedia.org/wiki/Blackboard_%28software%29

http://en.wikipedia.org/wiki/Blackboard_%28computing%29

http://en.wikipedia.org/wiki/Virtual_learning_environment


http://www.php.net/

http://pt.php.net/oop


http://www.thebook.com/sql.html

http://www.mysql.com/



Camarinha Matos – Collaborative networks: a new scientific Discipline. Journal of

Intelligent Manufacturing, 16, 439–452, 2005.

Luis M. Camarinha-Matos 1; Hamideh Afsarmanesh - TOWARDS A REFERENCE MODEL

FOR COLLABORATIVE NETWORKED ORGANIZATIONS. In Proceedings of BASYS’06

(Springer) – Niagara Falls, Canada, 4-6 Sept 06.

3.5 Author References

User Interface Manager:

o Paulo Lima, Nº.12543 ([email protected])

o Ricardo Borges, Nº.12122 ([email protected])

o Bruno Silva, Nº.12972 ([email protected])

Synchronous User Interface

o Daniel Silva, Nº. 13869 ([email protected])

o José Higino, Nº. 14290 ([email protected])

Asynchronous User Interface

o Ricardo Tiago, Nº. 14950 ([email protected])

o Teresa Rebelo, Nº. 12783 ([email protected])

Multimedia Content Editor

o Abilio Abreu, Nº. 14484 ([email protected])

o Diogo Lourenço, Nº. 14840 ([email protected])

o João Martins, Nº. 14841 ([email protected])

Blog Manager

o Hugo Guerreiro, Nº. 13825 ([email protected])

o João Oliveira, Nº. 13753 ([email protected])

http://by13fd.bay13.hotmail.msn.com/cgi-bin/compose?mailto=1&msg=MSG1151320411.4&start=1402417&len=379132&src=&type=x&[email protected]&cc=&bcc=&subject=&body=&curmbox=F000000001&a=e284e1348ffea3c8081f61515e542409970260a8b86edbb36f75ac420bc7770b



mailto:[email protected]











Collaboration Manager

o Diogo Leitão, Nº.14548 ([email protected])

o Sara Granjo, Nº. 15042 ([email protected])

Content Editor

o Filipe Feijão, Nº. 16335 ([email protected])

o Gonçalo Cândido, Nº. 14056 ([email protected])

Business Project Manager

o Luis Ribeiro, Nº. 14074 ([email protected])

o Miguel Pereira, Nº. 16114 ([email protected])

o Nuno Veríssimo, Nº. 14377 ([email protected])

Business Project Wizard

o David Paulino, N.º 12471 ([email protected])

o João Veríssimo, N.º13314 ([email protected])

o Sérgio Gaspar, N.º 12563 ([email protected])

Database Interface Module

o Alexandre Silva, Nº. 14658 ([email protected])

o Carlos Cândido, Nº. 14304 ([email protected])

o Diogo Barreiros, Nº. 14345 ([email protected])

o Pedro Baia, Nº. 14478 ([email protected])

Database Manager

o José Santos, Nº. 12545 ([email protected])

o Paulo Bonifácio, Nº. 13559 ([email protected])

o Pedro Silva, Nº. 10778 ([email protected])

o Rui Henriques, Nº. 10749 ([email protected])

o Rui Milagaia, Nº. 12490 ([email protected])


















