Computer Supported Collaborative Teaching Final Report · Computer Supported Collaborative Teaching Robotics and Manufacturing Section, June, 2006 3 Monte da Caparica, Portugal Abstract

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 Preface................................................................................................................................. 7 Section 1: Overview............................................................................................................ 8

1.1. Introduction......................................................................................................... 9 1.2. The ICE Model ................................................................................................. 10

................................................................................................................................... 11 1.2.1 The Interface Layer................................................................................... 12

User Interface (UI)........................................................................................ 12 Asynchronous User Interface (ASUI)........................................................... 12 Synchronous User Interface (SUI)................................................................ 12

1.2.2 The Contents Layer................................................................................... 12 Bloger Manager (BL).................................................................................... 12 Content Editor (CE) ...................................................................................... 12 Collaboration Manager (ColM) .................................................................... 13 Business Project Manager (BPM)................................................................. 13 Multimedia Content Expert (MCE) .............................................................. 13

1.2.3 The Editor Layer ....................................................................................... 13 Database Interface (DbI)............................................................................... 13 User/Group Manager (UMan)....................................................................... 13 Content Manager (CMan) ............................................................................. 13 Session Manager (SMan).............................................................................. 14 Module Manager (MMan) ............................................................................ 14 Database Manager (DbM)............................................................................. 14

Section 2: The Modules .................................................................................................... 15 2.1 User Interface.................................................................................................... 16 2.2 Synchronous User Interface.............................................................................. 18

Abstract ..................................................................................................................... 19 Overview................................................................................................................... 19

Computer Supported Collaborative Teaching - Phase II ...................................... 19 Implementation ......................................................................................................... 21 Conclusions............................................................................................................... 29 References................................................................................................................. 29

2.3 Asynchronous User Interface............................................................................ 31 2.4 Multimedia Content Editor ............................................................................... 33

Abstract ..................................................................................................................... 34 Overview................................................................................................................... 34 Interaction ................................................................................................................. 35 Implementation ......................................................................................................... 37

Provided functions from other modules................................................................ 37 Conclusions............................................................................................................... 38

References..................................................................................................................... 38 2.5 Blog Manager.................................................................................................... 40

Abstract ..................................................................................................................... 41 Overview................................................................................................................... 41



Interaction ................................................................................................................. 41 User Interface........................................................................................................ 41 Database................................................................................................................ 42

Implementation ............................................................................................................. 44 Functions provided................................................................................................ 46

Conclusions................................................................................................................... 47 2.6 Collaboration Manager ..................................................................................... 49

Abstract ..................................................................................................................... 50 Introduction............................................................................................................... 50 Motivation................................................................................................................. 51 Methods..................................................................................................................... 51 Forum........................................................................................................................ 53 Messenger ................................................................................................................. 57 Discussion ................................................................................................................. 59 References................................................................................................................. 59

2.7 Content Editor................................................................................................... 61 Overview................................................................................................................... 62 Interaction ................................................................................................................. 62 Implementation ......................................................................................................... 64 Critical Analysis........................................................................................................ 67 Conclusions............................................................................................................... 68 References................................................................................................................. 69

2.8 Business Project Manager................................................................................. 71 Overview................................................................................................................... 72 Interaction ................................................................................................................. 73 Implementation ......................................................................................................... 74

BP Editor............................................................................................................... 74 BP Executor .......................................................................................................... 82

Critical Analysis and Future Work ........................................................................... 87 Conclusions............................................................................................................... 88 References................................................................................................................. 89

2.9 Database Integration Module............................................................................ 91 Overview................................................................................................................... 92 Interaction ................................................................................................................. 92 Implementation ......................................................................................................... 93

Functions Provided ............................................................................................... 93 database. The input is the name of the discipline. .................................................... 95 Conclusions............................................................................................................. 102 Critical Analysis...................................................................................................... 103 Future Work ............................................................................................................ 103 References............................................................................................................... 104

2.10 Database Manager........................................................................................... 106 Abstract ................................................................................................................... 107 Overview................................................................................................................. 107 Interaction ............................................................................................................... 109 Implementation ....................................................................................................... 110



Functions provided.............................................................................................. 110 Conclusions............................................................................................................. 111

Section 3: Conclusions.................................................................................................... 112 3.1. Conclusions.................................................................................................... 113 3.2. References...................................................................................................... 114



Preface

José Santos, Paulo Bonifácio, Pedro Silva, Rui Henriques, Rui Milagaia, Robotics and Manufacturing Section, Faculty of Science and Technology, New University of Lisbon, PORTUGAL.

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 as 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



1.1. Introduction 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).

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 work 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 the 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 with the “real world” (human) users was 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 Contents 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 Editor 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





2.2 Synchronous User Interface

Daniel Silva Nº. 13869 [email protected]

José Higino Nº. 14290 [email protected]

mailto:[email protected]




Abstract SUI , Synchronous User Interface, this module is responsible for being the intermediate between the user and data base going trough other modules, showing the desired data at user’s need and editing data at user’s will.

Overview

Computer Supported Collaborative Teaching - Phase II

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, witch operate over the database with their functions, showing the desired data at user’s need and editing data at user’s will.

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, managed by a “Storage Object” (so). This object is responsible for handling all access to the storage engine.

2. The business layer, managed by a “Business Object” (bo). This object is responsible for all the business logic.

3. The user interface layer, managed 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: eGroupWare’s template building module




Fig. 2.3: eGroupWare’s object selection module

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 module. This part didn’t present problems, 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 :

• 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 trough 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 module’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 module’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 module’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 name. 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 improvement we can suggest early scheduling, testing first if it’s possible and then propose, and point to point scheduled goals with a proper advisory.

References

• http://localhost/etemplate/doc/etemplate.html • http://localhost/etemplate/doc/reference.html • http://www.w3schools.com/php/default.asp

http://localhost/etemplate/doc/etemplate.html

http://localhost/etemplate/doc/reference.html

http://www.w3schools.com/php/default.asp





2.3 Asynchronous User Interface





2.4 Multimedia Content Editor

Abilio Abreu Nº. 14484 [email protected]

Diogo Lourenço Nº. 14840 [email protected]

João Martins Nº. 14841 [email protected]





Abstract 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.

Overview 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”, combo box. Finally the user has to select a file present in the File List, and press the “Show File” button. When 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

Provided functions from 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.

References

• http://pt.php.net/manual/pt_BR/function.move-uploaded-file.php

http://pt.php.net/manual/pt_BR/function.move-uploaded-file.php





2.5 Blog Manager

Hugo Guerreiro Nº. 13825 João Oliveira Nº. 13753



Abstract This module consists in implementing a blog engine and integrating it with database and users interface, allowing a new way of publishing articles.

Overview 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.



Blog Manager

Figure 5.2 – Database structure



The overall interactions existent:

Figure 5.3 – Global interactions

Implementation What’s left to be developed is the integration and communication between de two 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 accomplished 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 wasn’t much time to work in this project, we 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

Diogo Leitão Nº.14548 [email protected]

Sara Granjo Nº. 15042 [email protected]





Abstract

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 community is one field where 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 important to create a framework which Professors can make 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 MSN Windows’ 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 wasn’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 MSN, we realize that this wasn’t the best and most 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 We decide to study the forum’s module 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, some “bugs”, that this forum has, were discovered and we 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 name (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 wherever they “want to”. For example:

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 means that the parent has depth ‘0’, the first reply has depth ‘1’, the reply from this

reply has depth ‘2’ and so on.

With all this considerations, this “bug” was 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 eGroupWare 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 messages 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, Compose message, Read message, …

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, Compose message, Read message,…



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 was very important, even though, it wasn’t easy to perform this way. 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.

References

• http://www.filenet.com/English/Products/Team_Collaboration_Manager • http://www.php.net/ • http://www.phpfreaks.com/ • http://flumpcakes.co.uk/php/msn-messenger.

http://www.filenet.com/English/Products/Team_Collaboration_Manager

http://www.php.net/

http://www.phpfreaks.com/

http://flumpcakes.co.uk/php/msn-messenger





2.7 Content Editor

Filipe Feijão Nº. 16335 Gonçalo Cândido Nº. 14056



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 following figure, it’s possible to situate the Content Editor Module area between two other modules to understand how it is integrated and what services are used in these interactions.


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 while 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)) {

… $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,$Name); …



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

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 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 was sometimes difficult to manage it. Some groups didn’t know exactly what 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 afterwards 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.



References

• BlackBoard Software, Inc. o http://www.blackboard.com

• Php Freaks o 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

http://www.blackboard.com/


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





2.8 Business Project Manager

Luis Ribeiro Nº. 14074 [email protected]

Miguel Pereira Nº. 16114 [email protected]

Nuno Veríssimo Nº. 14377 [email protected]






Overview The Business Process Manager module (BPM) is composed of 3 sub-modules: BP editor, BP executor and BP wizard. This report concerns the first two: BP editor and BP executor. 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 terms of time, and that all the discipline’s precedence has been met.


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

BP Module

Business Process EDITOR

course 1 course 2 course 3

creation creation

Edition

Business Process Executor

Database


Validation and execution upon finishing

stor

age w

ithou

t exe

cutio

n

opening for edition

course 1 course 2 course 3

BP wizardsuggestion

s

data

anal

ysis

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 and BP Executor 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.

1. 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. Removing a discipline is done using the disciplines name’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. 2 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:

FreeTeachers?

yes

no

MainTest($Couse_name)

SearchTeather()

SearchPrecedences()

Precedencesvalid?

yes

Course Vadid

Course Invadid

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 time the test fails. This test goes as follows:


Search Teacher

Get course's discipline

Get teacher bydiscipline's area

Get teacher's total busyhours

1) Get teacher's total busy hours - discipline's hours fo r week <= max teacher's hours for week

1)

Last course's

discipline?

no

yes

There are teacher to all disc iplines

Save the teacher in thememory

Are thereteachers?

yes

There are'n teacher to all disciplines(Course invalid)

no

no

yes

Figure 8.7 – Teacher availability test

After the previous validation the system will validate the course in terms of discipline’s precedence. This happens according to this flowchart:



1) Precedence_year = Discipline_year and Precedence_semester < Discipline_semester or Precedence_year < Discipline_year

Search Precedences

Get course's d iscipline

Get discip line'sprecedence

1)

no

Precedences invalids

yes

Are there

disciplines?

yesLastPrecedence?

yes

no

Precedences valids

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.




Critical Analysis and Future Work Before presenting any consideration on the achieved results it’s of major importance 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 non existent 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!



References


• Php

o http://www.php.net

• Janet Valade, PHP 5 for Dummies ®, Wiley Publishing, Inc. 2004






2.9 Database Integration Module

Alexandre Silva Nº. 14658 [email protected]

Carlos Cândido Nº. 14304 [email protected]

Diogo Barreiros Nº. 14345 [email protected]

Pedro Baia Nº. 14478 [email protected]







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 time shouldn’t be wasted 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 was “only” necessary to wait 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 following way: 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 following way: 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 following way: 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 following way: 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 between 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: “Matematica_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 following way: forum String forum_category; String forum_name; Thread[] forum_threads; The ‘Thread’ object is defined the following way: 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 we’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 was necessary to wait 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 work done so far, it’s easy to conclude all the coding is somewhat 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 waste of time. As we still lack some skills regarding PHP, some coding was “hammered” which might make some functions less efficient than they could actually be. Perhaps, it wouldn’t be a bad idea to get someone who knows PHP better than to look at the code and make it more efficient.



References

• Classes and Objects o http://pt.php.net/oop


• Integrate a Database with Your Website – mySQL and PHP o http://www.thebook.com/sql.html

http://pt.php.net/oop


http://www.thebook.com/sql.html





2.10 Database Manager

José Santos Nº. 1xxxx [email protected]

Paulo Bonifácio Nº. 13559 [email protected]

Pedro Silva Nº. 10778 [email protected]

Rui Henriques Nº. 10749 [email protected]

Rui Milagaia Nº. 12490 [email protected]




http://by13fd.bay13.hotmail.msn.com/cgi-bin/compose?mailto=1&msg=MSG1151018990.4&start=1305258&len=6632&src=&type=x&[email protected]&cc=&bcc=&subject=&body=&curmbox=F000000001&a=e284e1348ffea3c8081f61515e542409ab87f8242572bccb5794f8db073ed106




Abstract Database Manager were the initial software experts. Their tasks also included general group coordination, database construction, update and queries creation.

Overview

During phase one of this research project two groups worked on different but sympathetic tasks, these were tasks 6 and 7, exploration of the potential of the original suggested platform, phpprojekt, and research of alternative platforms and their potential for development. As those two tasks required such a high level of interaction a merge occurred; so one single super task force was created.

The database manager taskforce was supposed to have a lighter development work for the reaming phases, as this was probably the most work intensive task of phase one. As this group was the platform (Egroupware) experts, most of its work would be a coordination one. All the database construction and assorted queries were to be supplied by this cooperative task force, in top of that, all the need test functions and/or files were also launch in the database here.

The continuing evolution of the different modules leads to an ever-evolving Diagram of Entities and Relations (DER), the final version of is presented in figure 10.1.


Figure 10.1: Implemented DER.



Interaction

This was the lowest level module, the interaction occurred with the database integration super module (DbIM) and with the database itself.

As requested by DbIM, SQL queries were supplied that allowed the significant objects to be recovered or placed in the database.

Figure 10.1: Module interaction.




Implementation A great deal of time was spent bringing the different work groups up to speed with the Egroupware platform, this happened as initial installation of the software was not user-friendly.

Implementation related topics. Main difficulties found. Solution approaches.

Functions provided (When necessary) Description of the supplied functions. Function calls. Object references.



Conclusions

Task force overview of the work. Recommendations.



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 work is still to be made 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 wasn’t completely defined, so more work 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 individually interacting as much as possible trough the available CSCL tools (moodle). At any given time there would be more than 30 persons 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. As always should this project have started now, much more and a much better implementation could have been achieved. Nevertheless tools for CSCT are need and this project proved to be viable.

Although the final work tool presented was not fully functional at the time, a recommendation must be placed; if funding becomes available this project should be continued with key members of the task force groups.

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. 1- Base in 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



3.2. References

• Camarinha Matos – Elements of a base VE infrastructure. In J. Computers in Industry, Vol. 51, Issue 2, Jun 2003, pp. 139-163.

• 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.