Presentation for the Frontiers in Education conference 2010

1. Roberto Perez-Rodriguez
Manuel Caeiro-Rodriguez
Luis Anido-Rifon
University of Vigo

2. Introduction
 ICT support to Engineering Education increased in
recent years:
 Big spectrum of online tools and materials
 From basic web sites to online labs
 The implementation of online courses that involve
groups of users is a challenging task due to
 The scattering of third-party tools running on different
servers
 These tools need to be configured manually for each use
case

3. Introduction (ii)
 Our approach to solve this issue is composed by two
main points
 A central engine that runs course scripts written with an
Educational Modelling Language (EML)
 A middleware to enable the integration of third-party
tools in courses
 This solution is usually referred to as orchestration
 A central engine acts as the orchestra director
 And controls the behaviour of multiple musicians
(groupware tools)
 In accordance with a previously composed partiture (the
course script)

4. Introduction (iii)

5. 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
 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

6. PoEML (ii)
 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

7. PoEML (iii)
 We propose an example of a collaborative practice. 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.
 The elements of the practice are:
 Scenarios: a root scenario that represents 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:
 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

8. Execution engine

9. Execution engine (ii)
 The execution engine is the core component of the
system.
 The models manager deals with the designs of
educational scenarios.
 Maintains the versions of the models
 Updates models when required by an authorized user
 Communication from the exterior is made by making
use of the authoring interface
 The instances is in charge of managing running
instances of collaborative practices.
 Communication is made by making use of both the
information retrieval interface as well as the events
interface

10. Integration middleware
 The Generic Tool Adapter (GTA) is a comprehensible
mechanism to extend the functionalities of a e-
learning system by integrating tools in a “tight” way.
The following aspects are covered:
 Authorization granting
 Instances management
 Data transfer
 Permissions assignment
 Event subscription
 Specific methods management

11. Prototype
 We developed a fully functional prototype to test the
architectural approach presented in this paper.
 The database was implemented in Oracle.
 The execution engine is a Java-based web app running on
Tomcat
 The presentation component was developed as a Moodle
extension (new course type)
 The authoring subcomponent provides the view for creating
new process definitions, which are incorporated to the
models schema in the database
 The monitoring subcomponent provides the view for
following the progression of participants through the
collaboration structures
 The delivering subcomponent provides the working view for
participants, including a to-do list that provides links to the
pending assignments

12. Prototype (ii)

13. Related work
 SocialWok adds a social layer over Google Docs
 Simplifies the process of sharing a document with other
people because it is a social network that wraps around
documents
 Provides the capability to define users’ groups
 Limits access to documents to a group of users
 Zoho is a web-based productivity suite that has
integrated its products with Google.
 Google Apps Premier and Education Edition allows to
create and manage groups, and to share documents
 Moodlerooms is a SaaS provider of Moodle, and it
integrates Moodle and Google Apps together with a
single-sign-on

14. Related work (ii)
 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 kind of third-party tools, which are
wrapped and treated as legacy software

15. Conclusions
 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
 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.

16. Thanks for your attention!