Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-1

Orchestrating Groupware in Engineering Education

Roberto Perez-Rodriguez, Manuel Caeiro-Rodriguez, Jorge Fontenla-Gonzalez, and Luis Anido-Rifon Telematics Engineering Department, University of Vigo, rperez@gist.det.uvigo.es, {mcaeiro, jfontenla,

lanido}@det.uvigo.es

Abstract – Engineering Education usually involves a big amount of practical work, such as simulations, programming, circuits design, etc, that may be carried out individually or in groups. Usually, laboratories count with materials and equipment, including theoretical books in a shelf, and an experiment is proposed to students organized in pairs/groups, who must compose a report of the experiment/practice. In regard to ICT support of Engineering Education scenarios a plethora of online simulators, e-books, wikis and other social software are usually scattered in multiple web sites. To solve this issue, we present an architectural approach based in two main points: a central EML engine, and a middleware for the integration of third-party tools. Index Terms – Orchestration, groupware, and workflow

INTRODUCTION

ICT support to Engineering Education increased dramatically in recent years. From basic web sites with theoretical documents such as powerpoint presentations to sophisticated remote laboratories that simulate equipment, the spectrum of available electronic materials to carry on online learning and teaching in Engineering Education is quite big nowadays. Composition of online courses that involve groups of users carrying on practical experiences is challenging task because of the scattering of third-party tools running on different servers. Usually, these tools need to be configured manually for each use case. Our architectural approach to solve this drawback is composed by two main points:

• A central engine that runs course scripts written with an Educational Modeling Language (EML). The EML enables the design of courses in which students and teachers have to perform a series of tasks.

• A middleware to enable the integration of third-party tools in courses.

Figure 1. Orchestrating collaboration in a lab.

In the workflow field, this solution is usually referred to as orchestration, that is, a central component (workflow engine) acts as the orchestra director, and controls the behavior of multiple musicians (groupware tools), in accordance with a previously composed partiture (process definition). Figure 1 illustrates this metaphor, applying it to people carrying on a lab practice in groups. The main contribution of this paper is the description of the components of our architectural approach to the orchestration of groupware tools in accordance with a PoEML (Perspective-oriented Educational Modeling Language) [1] course file. The rest of this paper is structured as follows: section 2 is about the PoEML modeling language (the partiture), section 3 briefly describes the design of the central engine (the intelligence of the orchestra director), section 4 deals with the middleware for integrating groupware tools (the baton), section 5 presents a prototype with a presentation part that integrates in Moodle as a new course type, section 6 reviews some related work, and, finally, section 7 extracts some conclusions.

Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-2

POEML

The life-cycle of a collaborative practice in Engineering Education is typically composed of the following stages: the design-time stage, in which the teacher creates the roadmap of the practice, including the number of participants per scenario; the instantiation-time stage, in which the teacher communicates the assignment of people to groups and the collaborative practice starts; and the run-time stage, in which participants collaborate following the instructions in the roadmap, at the same time that the teacher monitors the progression of groups. We use PoEML for designing educational scenarios. In design-time, the creator of the collaborative practice uses a graphical authoring tool that produces a XML file with a computer-understandable description of the practice. Figure 2 shows a screenshot of a design in the JPoEML authoring tool.

I. The Language.

The PoEML specification divides the language in a set of 13 perspectives and 4 aspects, following thus a separation-of-concerns approach: different concerns in the modeling of educational scenarios are treated independently. The two most important perspectives are the structural (that defines structures of scenarios and sub-scenarios) and functional (that defines what has to be performed in each educational scenario). The Educational Scenario (ES) is the basic building block to create models of units of learning. Basically, an ES is an

entity involving Elements, Specifications and Expressions in accordance with the perspectives and aspects:

• Elements represent the entities contained in the ESs. For the purpose of this paper it is enough to take into account that an ES needs to include: (i) one or several Goals that indicate what has to be performed in a declarative way; (ii) one or several Roles that indicate the functions of the participants to perform their work. Each one of these elements may include other elements, such as Data Elements, representing properties, parameters or variables. In addition, an ES can include other ESs arranged hierarchically, namely: sub-ESs. Moreover, it is very important to indicate that the Goals of an ES can be related with the Goals of its sub-ESs.

• Specifications represent controls that have to be applied during run-time to manage the elements involved in the ESs. The main specifications are the Temporal and Order ones.

• Expressions involve descriptions corresponding with the aspects. They represent issues that can affect to the features or behavior of Elements and Specifications. For example, Condition Expressions determine their result in accordance with the value of certain Data Elements, and they can be used to determine the mandatory/optional character of a Goal.

Each one of the issues involved in an ES is represented as a separate entity. In this way, it is facilitated the modification of ESs by replacing specific elements, specifications or expressions, thus facilitating reusability. In addition, during run-time it is necessary to create instances of the ESs and

Figure 2. Design of a collaborative practice in JPoEML.

Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-3

their elements. The number of instances to create can be determined statically during design-time or dynamically during run-time in accordance with the result provided by specific Expressions. Moreover, an ES may include several Order and Temporal specifications, but the use of one or several ones of them can also be determined statically during design-time or dynamically during run-time in accordance with Expressions. In this way, there is a great degree of adaptability.

II. An Example of Collaborative Practice.

We propose an example of a collaborative practice in the context of a course on Java programming to illustrate the PoEML modeling language. The practice is as follows: the participants are asked to make groups of two, then they have to code a Java program using a development environment and to compose a text file with a summary of the work, finally the program and the summary are evaluated by a teacher. Communication facilities for groups of participants and for teacher’s feedback must be also made available. The elements of the practice are:

• Scenarios: a root scenario that represent the entire class, and a scenario for each group.

• Goals: the objective and roadmap of the practice. • Environments: the programming environment, the

feedback environment, the delivering environment, the evaluation environment.

• Tools: the programming IDE, a chat for communication between peers, a text editor, a forum for feedback.

• Participants: grouped in groups of two. This practice entails to create instances of the tools that will be used by participants. For example, the number of IDE instances to be created depends on the number of groups of participants, so as the number of text editor instances to compose the summary. Tool instances must be configured prior to be used by participants.

EXECUTION ENGINE

The execution engine is the core component of the system, as shown in Figure 3. The engine stores information on structures, participants, ordering, timing, and rest of elements in an educational scenario; and makes the state of the system to evolve depending on events. Inside the learnflow execution engine, we can distinguish two subcomponents: the models manager, and the instances manager.

• The models manager deals with the designs of educational scenarios. This subcomponent maintains the versions of the models, and it also updates models when required by an authorized user. Communication from the exterior of the models manager is made by making use of the authoring interface, which provides the needed methods for authoring learnflow models.

• The instances manager is in charge of managing running instances of collaborative practices. Communication from the client applications is made by making use of both the information retrieval interface as well as the events interface. Presentation subcomponents are able to access the execution engine in a passive way using the information retrieval interface, just to get information on structures, participants, ordering, timing, and rest of elements. In a similar way, the execution engine has to manage the events from the events interface. An event that is external to the learnflow engine, such as the finishing of an activity, may trigger several events that are internal to the execution engine, such as to update the to-do list of all participants in that process. In summary, the interaction between presentation subcomponents and the learnflow instances manager may be passive information retrieval as well as communication of events generated by participants.

MIDDLEWARE FOR INTEGRATING GROUPWARE APPLICATIONS

The GTA (Generic Tool Adapter) [2] (see Figure 3) is a comprehensible mechanism to extend the functionalities of an e-learning system by integrating tools in a “tight” way. Unlike other integration solutions that only allow the LMS to import functionalities from external third-party tools, additional aspects are covered:

• Authorization granting. A single sign-on mechanism, named Reverse OAuth [3], included as part of the GTA, has been developed in order to authorize users (e.g. learners and teachers) to access the third-party tool without requiring additional sign-ins.

• Instances management. The GTA includes resources devoted to control the instances of the tool. We understand by instance of a tool a working environment along with a graphical user interface, associated to several files to manipulate and a set of users allowed to access it. Several methods are included to control the creation and deletion of concrete instances, and to add and remove users to instances.

• Data transfer. Another feature included in the GTA is a simple mechanism to exchange data between the execution engine and the tool, either single data values or full backups of the data of a user. This functionality allows the execution engine, for example, to read and post messages to a forum tool or to transfer the wordings of an exercise.

• Permissions assignment. Additional functionalities are included in order to set access permissions to specific users over concrete parts of the tool. These mechanisms provide a

Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-4

straightforward mechanism to differentiate the different roles of teachers and students (e.g. in a forum tool students may be allowed to read old posts, and additionally teacher may have permissions to delete them).

• Event subscription. This feature of the GTA allows the execution engine to subscribe to particular events triggered by the tool in response to specific actions carried out by its users. This feature is especially useful in e-learning environments, where the external system must be “in touch” with what happens inside the tool in order to track, evaluate and help students.

• Specific methods management. Finally, the GTA provides mechanisms to alter the workflow of the tool. This category includes all those methods that do not fit well in the previous five categories for providing functionalities that are very specific and dependent on the type of tool (e.g. in the case of an online conference tool we could think of a method to change the codecs).

PROTOTYPE

We developed a fully functional prototype to test the architectural approach presented in this paper. The database was implemented in Oracle 10g. The execution engine is a java web app running on Tomcat. The execution engine provides three SOAP interfaces to enable the integration of presentation components. It follows the description of a presentation component that we have developed as a Moodle extension.

I. Integration of a Presentation Component with the Execution Engine

The presentation component is composed of three subcomponents, each one dealing with a specific view of the

system: authoring, monitoring, and delivering. The authoring component provides the view for creating new process definitions, which are incorporated in this way to the models schema in the database. The monitoring component provides the view for following the progression of participants through the collaboration structures. Finally, the delivering component provides the working view for participants, including a to-do list that provides links to the pending assignments.

II. Moodle-based GUI We developed a Moodle extension that consists on a new course type: the PoEML course [4]. This Moodle extension queries the execution engine to get the needed information to display Educational Scenarios. Figure 4 shows a screenshot of the course on Java programming that was introduced in the section on the PoEML language. When a participant is enrolled in a course, a course instance is assigned to that participant. At that time, the course structural view is displayed at the browser. The main parts of that page are the navigation bar (Ariadna’s thread), the Goals, the Environments and the Sub-scenarios. The navigation bar or Ariadna´s thread shows at any time the aggregation level in which the participant is. The Goals box shows all the Goals in the current Scenario. The color of each Goal is an indication of its state. The possible states are: Not Proposed, Not Attemptable, Attemptable, Pending, Completed, and Failed. Each Goal box can be expanded in order to see information about input/output constraints, as well as input/output parameters. The learning resources and activities are contained into one Environments box. An Environment contains Moodle-native resources and activities, such as quizzes, forums, wikis, and

Figure 3. Overall Architecture.

Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-5

URLs of third-party tools. At the bottom of the page, the Sub-scenarios are displayed.

RELATED WORK

SocialWok [5] adds a social layer over Google Docs. SocialWok simplifies the process of sharing a document with other people because is a social network that wraps around documents. SocialWok provides the capability of defining users’ groups. In this way, SocialWok limits access to documents to a group of users, instead of having to share a certain document with all users in the social network. Zoho [6] is a web-based productivity suite that has integrated its products with Google. In this sense, Google Apps users can upload their documents to Zoho directly. Google Apps users can log in to Zoho projects using their Google credentials. Google Apps Premier and Education Edition allows to create and manage groups, and enables to create documents that are shared by all members of a group. Moodlerooms [7], a SaaS provider of Moodle, integrates Moodle and Google Apps together with a single-sign-on. Users can collaborate among themselves using Google Apps. Moodlerooms uses SAML 2.0 and OAuth protocols to securely integrate Moodle and Google Apps. As a conclusion, our work differs from those in two main points:

• We use an EML to support the social layer over third-party tools, enabling framed collaboration.

• Since laboratory simulators and other kind of tools in Engineering Education have been developed without integration concerns in mind, we provide a method to integrate these kinds of third-party tools, which are wrapped and treated as legacy software.

CONCLUSIONS

In this paper, we have presented an architectural approach to support an EML layer over groupware tools that are used in Engineering Education. The EML engine automatically configures and instantiates third-party groupware tools following a previously designed course script. In the CSCL (Computer-Supported Collaborative Learning) field, the most popular trend is to divide collaboration in two levels:

• High-level collaboration refers to the design of groups of participants, high-level goals, as well as high-level scenarios. The roadmap for this level is usually termed macro collaboration scripts.

• Low-level collaboration refers to the collaboration in its most detailed form. Usually, this level of collaboration is carried out by using groupware tools, in which the roadmap is reified in the interface of the groupware tool [8].

Our approach is, basically, to formalize macro collaboration scripts as a process definition, whilst micro collaboration scripts are reified in the code of groupware tools.

Figure 4. Screenshot of the course on Java programming in the Moodle extension.

Session F3D

978-1-4244-6262-9/10/$26.00 ©2010 IEEE October 27 - 30, 2010, Washington, DC 40th ASEE/IEEE Frontiers in Education Conference F3D-6

ACKNOWLEDGEMENTS

This work was partially funded by eContentPlus program ECP 2007 EDU 417008 (www.aspect-project.org) and by the Spanish Ministry of Education and Science under grant TIN2007-68125-CO-02.

REFERENCES

[1] Manuel Caeiro-Rodríguez, María José Marcelino, Martín Llamas-Nistal, Luis Anido-Rifón, and António José Mendes, "Supporting the Modeling of Flexible Educational Units. PoEML: a Separation of Concerns Approach," J. UCS, vol. 13, no. 7, pp. 980-990, 2007.

[2] J. Fontenla, M. Caeiro, M. Llamas, E. Sancristobal, and M. Castro, "A Middleware for the Integration of Third-Party Learning Tools in SOA-Based Learning Management Systems. Supporting Instance Management and Data Transfer," in EDUCON 2010, forthcoming publication, Madrid, 2010.

[3] J. et al. Fontenla, "Reverse OAuth - A solution to achieve delegated authorizations in single sign-on environments," Computers & Security, Forthcoming publication.

[4] (2010) PoEML Extension for Moodle. [Online]. http://www.poeml.com/moodle

[5] (2010) SocialWok Website. [Online]. http://www.socialwok.com/

[6] A. Shabdar, "Foundation Zoho: Work and Create Online," Friends of Ed, p. 400, 2009.

[7] (2010) Moodlerooms Website. [Online]. http://moodlerooms.com/

[8] P. Dillenbourg, "Over-scripting CSCL: The risks of blending collaborative learning with instructional design," in Three worlds of CSCL. Can we support CSCL., 2002, pp. 61--91.