Nowadays the OCWInMotion plugin is neither scalable or extendable for no RSS formats. What we try to do with this reengineering is to convert the plugin into an easier extensible plugin for a large variety of formats (like Scorm, atom etc.). In the next points the proposal is explained. This proposal is based on the MVC model.

This redesign is based on the MVC pattern. The MVC pattern consists of separating the data from the user interface and the logic control into three different components. In the following image we can see the basic structure.

Next we are going to explain every layer design and finally we will show the diagram which represents the relations among the layers.

This layer contains all about data management. In the following diagram we can see its structure.

(Comentario de Nuria: yo esta imagen no la pondría, no es uml y no me parece rigurosa).

(Comentario de Nuria: la sustituiría por esta otra:)

For this layer (the model layer) we have used the Factory software pattern, which allows us to create different object families, in this case, every course type is associated with one of these families. Further on we are going to mention some of the different types of courses that we could implement. In the image below the main structure of the pattern can be seen.

Now we are going to define each of the classes which will form this layer (figure 1):

abstract Factory: This is the base class. This class must be abstract and must have an abstract method which should be implemented by the rest of the factories which inherit from it. This method will be able to generate a course from the input data.

Course Factory: This class is concordant with FactoryObjX class shown in the previous image. We will have one class per kind of course that we want to support (RSS, SCORM etc). Every FactoryObjX will be able to generate an object of the ClassX. In our case our FactoryCoursesX will be able to generate CoursesX.

abstract Course: This class is concordant with Abstract Class shown in the previous image. It is the base class for a course. It will contain all the data that are common to different types of courses, for example course name, course description, course link. It will also have the methods which will be common to every course.

CourseX: This class is concordant with ClassX in the previous diagram. There will be a class per type of course that we will support. All of these classes will inherit from the Course class.

abstract Item: Every course will be formed by items. This will be the base class from which the rest of the items will inherit. It will contain the data which all the different types of items will have in common such as name, link, type etc.

ItemX: This class will inherit from abstract Item and there will be one for every course.

This separation into different classes will allow us to process different types of courses (for example Mit courses saved into Scorm format, Ocw Rss courses etc.). This structure will also allow us to enlarge the number of supported course formats without making any change to the software structure. We will only have to add a Factory, a ClassX and an ItemX for the new course type.

This layer contains every thing concerning handling the extract, storage, and deleting information about courses. It also entrusts the users with the management of every course. The layer's structure can be seen in the following image:

This layer is formed by three classes: Course Controller, User Controller and Delete Controller.

Course Controler: This is the main class. It manages every thing related to a course, among its functions we can emphasize the next ones:

• Import a course.
• Generate a course.
• Obtain a course.

User Controller: This layer entrusts the users with the management. It is able to assign and cancel the user´s certain permissions like reading, writing, creating, deleting, etc.

Delete Controller: This class is able to delete completely a course which was created by the Course Controller class.

This layer contains all about the view. In the next imagewe can see the design of this layer.

Every view in the OCWInMotion plugin will be generated by a class.

EntryPoint will be the class which initially generates the view with the three possible options. These options will allow us to import a course, to manage the users or to delete an imported course.

ImportView will generate the import GUI of courses.

ManageCourseView will request the Controller layer to do the necessary operations for importing a course, it will also manage the results of the importation.

Course View will be the class which will generate the course's view.

And the class Error View will show the possible errors that the other layers throw.

In order to understand how layers interact with each other let's see a sequence diagram of the three possible executions. Firstly let's see the sequence diagram of the import course action. Notice that we have marked the three layers:

As you can see the Model layer never communicates with the View and the View never communicates with the Model. They communicate with each other through the Controller layer.

Let's see another example in the next image, an example of an execution of the modification of the user´s permission can be seen.

And the third possible execution is the deletion of a course:

In the next picture we can see the interaction among the layers.

El modelo anteriormente descrito ha sido diseñado a partir de la reingenería que se ha aplicado a la primera versión del plugin OCWInMotion para la DokuWiki. Por tanto la implementación del modelo ha seguido los mismos pasos que el diseño del modelo y ha sido desarrollado a partir de la reingeniería aplicada a la anterior implementación, siguiendo el modelo descrito anteriormente.

Por tanto para la implementación del modelo se ha vuelto a usar PHP, un lenguaje que al estar orientado a objetos en sus últimas versiones nos permite implementar el modelo de forma sencilla. También se ha vuelto a utilizar de base la DokuWiki para aprovechar todas las ventajas que nos ofrece en términos de usabilidad y reusabilidad, ya que gracias a su facilidad para crear y editar contenidos nos ofrece la oportunidad de importar, crear y desarrollar un curso en un nuevo contexto como es internet, añadiendo de este modo un valor añadido como pueden ser las clases a distancia y dando movimiento a curso estáticos.

El código PHP del plugin se puede obtener de: http://harvest.virtua.ua.es/turing/trunk/ocwInMotion/

Para esta implementación se ha decidido añadir solo dos tipos de cursos: Los paquetes Scorm del MIT y los RSS's del OCW de la Universidad de Alicante y de la Universidad de Utah State. El plugin está abierto a nuevos tipos de curso ya que su diseño ayuda al la escalabilidad del mismo.

Para poder importar y generar los cursos hacia la DokuWiki se ha tenido que implementar dos tipos de curso en PHP, CourseRSS.php y CourseScorm.php, ambas con sus respectivas fábricas. Estas dos clases heredan los atributos y métodos de la clase base Course.php, así como sus métodos abstractos los cuales serán implementados por sus clases hijas.

Ahora pasaremos a ver alguna de las vistas del plugin implementado.

Esta es la vista que genera la clase EntryPoint.php con su método render(). Aquí se permite elegir una de entre las tres opciones principales.

• Importar Curso.
• Gestionar Usarios.
• Borrar Curso.

Antes de importar el curso se necesitad una serie de datos básicos como el nombre del curso, la descripción, su link y el tipo de curso que se va a importar.

Una vez introducidos los datos básicos de un curso, se permite al usuario elegir que items desea importar hacia el curso que se va a generar. Se puede importar como enlace externos o añadirlo a la DokuWiki, según se seleccione la primera columna de checkbox o ambas respectivamente.

Aquí se pueden ver unas vistas del resultado final de importar y generar el curso dentro de la DokuWiki.