Design of a Flexible and Adaptable LMS Engine in Conformance with PoEML

This paper describes the support of the Structural, Functional, Order and Temporal perspectives in PoEML. PoEML is a modeling language devoted to support a broad range of pedagogical approaches, from contentbased, to collaborative and practical oriented. At this point, a main issue is to provide a good level of adaptability and flexibility. The final goal is to support changes in the educational process development, enabling the provision of different learning experiences depending on the learning goals, the learner needs and features, the previous results, etc. The introduced solution is based on the separation of concerns principle adopted in PoEML. Basically, the solution facilitates the use of a set of educational resources in different ways by separating the form in which such resources are organized (Structural perspective) from the decisions of what has to be done (Functional perspective) and when (Order and Temporal perspectives).


I. INTRODUCTION
During our university lives, both as learners and teachers, we have found several times ourselves in front of an impressive and voluminous book involving a very large amount of contents.The human knowledge in some areas is quite impressive and these books try to provide a broad (in some ways "biblical") compilation of such knowledge.Nevertheless, the contents provided are usually excessive for the common academic needs of a one semester subject.This situation is so common that this kind of "biblical" books usually contains a description of several paths or itineraries along the book chapters focused in certain specific topics.For example, in a book about software engineering we could find itineraries such as: structured analysis and programming; software development process; error control and testing; etc.In addition, the book description may also include some constraints, requiring that before initiating a certain chapter another chapter should be read.Eventually, when this kind of book is used in a university subject, it is quite common that a professor performs a selection of chapters in order to fulfill the subject goals, satisfying more or less some of the suggested itineraries and constraints.In addition, the teacher usually performs a temporal planning of the selected chapters.
Currently, the e-learning domain does not involve the management of large compilations of resources, as in those large academic books.Nevertheless, it involves reusability and adaptability requirements that demand similar solutions.Reusability and adaptability are two main concerns in the development of e-learning solutions.In accordance with the SCORM specification [2] reusability is defined as the flexibility to incorporate instructional components in multiple applications and contexts.Meanwhile, adaptability is defined as the ability to tailor instruction to individual and organizational needs.Therefore, from our point of view, these concerns are demanding similar solutions to the itineraries, constraints and professors' plans using large academic books.The common requirements are: (i) to support the aggregation of numerous contents; (ii) to enable the description of itineraries and constraints through the contents; and (iii) to enable the temporal planning of contents during the educational practice.Our proposal is focused on supporting these requirements in a computational context, both during the design-time of the materials and during their execution in the run-time.
This proposal is developed in the context of a larger work based on the PoEML modeling language [1].This language is focused on the computational support of educational units in accordance with different kinds of pedagogical approaches, in special practice and collaborative-based ones.Anyway, reusability and adaptability are a common need in the e-learning domain independently of the pedagogical approach.The PoEML solutions are based on the separation of concerns involved in the computational description and support of educational units.This separation facilitates both reuse and adaptation of e-learning resources, as basically, the different concerns can be managed separately in a more or less controlled way.
The rest of the paper is organized as follows.Next section introduces the general approach to the modeling of educational units in accordance with PoEML, but focusing on the concerns considered in this paper.Then, it is described the logic of a computational system that supports the management and control of the previous concerns.The paper finishes with some conclusions and a description of future works.

II. MODELS OF EDUCATIONAL UNITS IN POEML
PoEML stands for Perspective-oriented Educational Modeling Language.EMLs [3] [4] have been proposed several years ago with the purpose to support the creation of models of educational units enabling the representation of different pedagogical approaches.The main feature of PoEML is its separation of concerns approach.Instead of trying to support the modeling of educational units with a complete set of elements and relationships, PoEML considers the different concerns involved in educational units and offers separated sets of elements and relationships to model each concern.The complete PoEML proposal is quite extensive, as it involves 17 dif- Perspectives and aspects are two different kinds of orthogonal concerns.While perspectives are focused in issues with a specific purpose, aspects are about issues that do not have a specific purpose on themselves, but that affect to other concerns.Anyway, despite the large number of perspectives and aspects, a main property of the PoEML proposal is that perspectives and aspects can be used in a modular way.In practice, there exists just one perspective that needs to be considered always in any educational unit.Meanwhile, the other perspectives and aspects are optional and they can be used when required.
The solution introduced in this paper involves just 4 of the PoEML perspectives.In addition to the Structural perspective, it also involves the "Functional", "Order" and "Temporal" perspectives.Next, it is provided a brief description of them: The Structural perspective is about the structure of the elements involved in educational units.A basic building block is identified and defined as an Educational Scenario (ES).The ES enables the inclusion of the several elements that may be involved in an educational unit.In addition, it also enables the hierarchical aggregation of sub-ESs.
The Functional perspective is about what has to be done in the educational unit.It involves the description of the goals, the input requirements to allow the attempt of the goals, the output requirements to determine the satisfaction of the goals, the input data and output data, and the relationships among goals.Each ES needs to involve at least one goal.
The Order perspective is about the order in which the several sub-ESs of a certain ES have to be performed.Main issues in this perspective are the performance of several sub-ESs in parallel and the synchronization of their conclusion.
The Temporal perspective is about the specific time at which the several sub-ESs of a certain ES have to be performed.For each sub-ES it is possible to introduce temporal points or constraints that determine when it has to be initiated and finished.These temporal specifications can be used alternatively or complementarily to the order ones.
PoEML supports the modeling of educational units through the use of different elements and relationships corresponding with each one of the perspectives and aspects.Next sections show the structure of the ES as basic building block and the modeling of educational units as the hierarchical aggregation of ESs.

A. The Educational Scenario
The ES is the basic building block to create models of units of learning.Basically, an ES is an entity involving Elements, Specifications and Expressions (Figure 1 shows a representation of the ES elements considered in this paper): • 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 Their purpose is the same one described in the corresponding perspectives.• Expressions involve descriptions corresponding with the aspects.They represent issues that can affect to the features or behaviour of Elements and Specifications.For example, Condition Expressions determine their result in accordance with the value of certain data elements.
This structure enables to describe the issues involved in ESs.It is important to signal that each one of the issues involved in an ES is included 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 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.In addition, 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 runtime in accordance with Expressions.In this way, there is a great degree of adaptability.

B. The Modeling of Educational Units
The modelling of educational units is conceived through the hierarchical aggregation of ESs.Basically, any educational unit is composed by a root ES which con-iJET -Volume 4, Special Issue 1: "SIIE'2008", March 2009 The Attempt Dependencies among Goals and the Order Specifications may seem to duplicate their purpose.Nevertheless, they have clear defined aims.The attempt dependencies are proposed to model compulsory dependencies, which must be satisfied always.By the contrary, Order Specifications and Temporal Specifications are introduced to enable the description of orderings and plannings that can vary, depending on the decision of a teacher, for example.
There are two fundamental design terms that can be of aid in explaining the system's behavior at run-time: they are the concepts of Functional Flow and Control Flow.The Functional Flow is intended to support content dependencies, whilst the Control Flow deals with ordering and temporal planning of Educational Scenarios.It can be said that the Functional Flow depends on the very structure of the learning content, whilst Control Flow depends on the will of the teacher and/or temporal constraints.So, in conclusion, once an Educational Scenario hierarchical structure is defined, the Goal hierarchical structure lays directly on it.
In other words, the Functional Perspective can serve as a modeling tool to represent prerequisites that need to be satisfied in all cases.Meanwhile, the order specification enables an optional arrangement that may be changed.

III. THE LEARNING MANAGEMENT SYSTEM
This section shows a view of the main elements of a LMS proposed to support the development of learning experiences in accordance with the PoEML separation of concerns.

A. Logical Architecture
The system architecture is structured as a three-tier application: • LMS presentation tier: this is the top most level of the application.The presentation tier displays the information to be presented to the participant (learner or teacher).It may be a list of pending tasks for a certain participant, an administration interface, etc.
• LMS logic tier (hereafter, LMS Engine): the logic tier is pulled out from the presentation tier.The LMS engine controls the application's functionality by performing detailed processing.• LMS data tier (hereafter, LMS Infrastructure): this tier consists on database servers.Here information is stored and retrieved.

1) The LMS Engine
The LMS engine offers the services required by the presentation layer.Basically, the LMS engine is designed following the separation of concerns approach.The engine is composed of a set of components, each one providing the needed functionality to execute the associated perspective.
Following the principles of Component-based Architecture, the LMS engine is designed as a set of logical components with well-defined interfaces used for communication by message-passing.The system architecture is a specification of the components and communication among them.
Each subcomponent has its own API.The most important component is the Structural Component, as it provides through its API the key object-structures to access the other components APIs.This approach to the development of a LMS engine is consistent with PoEML philosophy and is a hot research topic in the area of Workflow Management Systems [5].As the LMS engine is designed accordingly with PoEML, there exists an engine subdivision into four components, as shown in Figure 3.Each component encapsulates the functionality of its associated perspective.The Functional Component deals with the relationships among Goals, instantiation and changes in Goal states, etc.The Order Component resolves the precedence relationships among Educational Scenarios and changes ESs states accordingly to its accessibility.Finally, the Temporal Component permits to schedule the Educational Scenarios to be performed at a given day and hour.

B. System Behaviour
This section describes the system behaviour at run-time.It is exposed the composition of the LMS Engine tier and communication among components, as well as the Goal and ES instantiation process. 1

) The engine perspectives interacting at run-time
In Figure 5 we can see two user actions and its implications for the Presentation layer, LMS engine and LMS infrastructure.When a user logs into the system via an internet browser she/he can see a list of available Educational Scenarios.Each of them is presented to the user as a typical tree view.So, when the user clicks to expand the hierarchical view a request to the Presentation layer is produced.We can observe how this procedure is performed at the server side through a series of invocations and messages-passing: • The Structural perspective receives the first invocation from the Presentation layer requesting a certain Educational Scenario.• The Structural perspective retrieves the Educational Scenario from the Data Access layer (LMS infrastructure) and delivers it to the Presentation layer.So, in this example we can see the three tiers of the application collaborating among them in order to accomplish a simple task like delivering an Educational Scenario.
The next action in Figure 3 is a bit more complex than the previous one.This time the user wants to start the Educational Scenario, which is the same thing that to attempt a Goal contained in such an ES.To accomplish this action it is necessary the participation of more perspectives: namely, the Structural, Functional, Order and Temporal perspectives.
So, following with the second interaction example shown in Figure 3, when the user tries to start an Educational Scenario: • The Structural perspective communicates with the Functional perspective with the purpose of refreshing the Functional Flow: the Functional Perspective propagates the changes resulting from starting an Educational Scenario.• Next step is to instantiate the appropriate sub-ESs: the ones containing at least a Goal in a state different from Not proposed.
Finally, the Order perspective refreshes the Control Flow: it is necessary to do that because the previous changes in Goal states may affect the states of related Educational Scenarios.

C. Execution states of an Educational Scenario instance
The PoEML description of an Educational Scenario has to be instantiated in order to become executable.Making an analogy: in Object Oriented Programming (OOP), a class definition has to be instantiated (this refers to the declaration of an object) in order to make use of it.This case is very similar to the OOP one: the ES definition has to be instantiated in order to become usable.Each instance has its own execution state, its own values for variables, etc.
At times, it is necessary to create a given number of instances of a certain ES description.It depends on the quantity of resources that have to be made available.For example, in a laboratory class it may be needed to create as many instances as there are learners participating in the class.So, the multiplicity of instances depends on factors such as the number of participants, the number of participant groups to be made, etc.
The execution states of an ES instance are shown in Figure 4. "Transition 1" (Not Created -> Not Accessible) represents an instance creation.It happens when its "parent" ES is accessed.It is an on-demand approach to the instantiation process: ES instances are created when they are needed, being thus a scalable approach.
iJET -Volume 4, Special Issue 1: "SIIE'2008", March 2009 When a given ES is accessed, the instances of its sub-ESs are created.But, it is not all, the sub-ESs need to satisfy another constraint: only sub-ESs having at least a Goal instance in a state different from Not Proposed can be instantiated.
An instanced ESs cannot be immediately accessed.When the instance is created, it is at the Not Accessible state.Thus, the instance cannot be provided to be accessed by a participant (learner or teacher).It is "Transition 2" (Not Accessible -> Accessible) that enables the instance to be accessed by a participant, and this transition is directly dependent on the Order and Temporal Perspectives.
The other possible states are Initiated (with the substates Active and Suspended) and Finished.An Educational Scenario becomes Active when a participant enters it, and becomes Suspended when the last participant leaves it.When all the Goals at the Educational Scenario are completed, the ES instance is switched to the Finished state.
Following with the Software Engineering book example, we could say that each one of the book subdivisions (e.g., chapters) is instantiated when the "father" subdivision (e.g., sections) is accessed and at least one of its Goals is at a state different from Not proposed.
Moreover, a chapter becomes Accessible if it is the right time to be performed.Chapters into sections can be arranged in accordance with a predefined order.In addition, it is possible to explicit the day and hour in which the chapter has to be performed.
With our example we start to foresee some dependencies that may arise among • the reader's chosen itinerary, • the arranging order of chapters into sections, and • the temporal planning of sections and chapters.

1) Execution states of a Goal instance
The execution states of a Goal are shown in Figure 5. "Transition 1" represents the creation of a Goal instance and it happens when a "father" Goal is attempted.This means that when a participant attempts a Goal, all the Goals that have Completion dependencies with it have to be instantiated.The Goal instantiation process is therefore very similar to the ES instantiation process, creating instances when they are needed.
In a way similar to the Educational Scenario instantiation process, a newly created Goal instance is not automatically ready to be attempted by a Participant.There are certain Attempt dependencies that have to be satisfied in order to reach the Attemptable state.When a participant attempts a Goal, its state is set to Pending.This means that somebody has attempted the Goal but its achievement has not yet been evaluated.Once it is evaluated, the Goal possible states are: • Failed, when the Output Constraints are not satisfied • Satisfied, when the Output Constraints are satisfied • Not Satisfied, when the Output Constraints are not satisfied and there is not chance to attempt the Goal another time.
In our "biblical" Software Engineering example book, some analogies with the previous exposition of Goals in PoEML can be proposed.It could be said that an itinerary means nothing more than to attempt a Goal of the top most level, a root Goal.Once the itinerary is chosen, it only remains to attempt its associated Goal.
Goals are arranged into a hierarchy: from root Goals to partial Goals.In a way similar to the ES instantiation process, a certain Goal is instantiated when the participant attempts a "father" Goal.It is also an on-demand approach.Using PoEML terminology, it can be said that there is a Completion Dependency between them: in order to accomplish a "father" Goal, some "child" Goals should be satisfied first.
But, there is still one key point remaining to be considered: precedence relationships among Goals.Going back to our example, let us consider a set of chapters (each one with its related Goal).It is possible to explicit that a certain chapter's Goal has to be performed before another one.This is called an Attempt Dependency, and it means that in order to attempt a chapter Goal other "brother" Goals have to be completed before.

D. Dependencies
Perspectives are not isolated concerns: it is necessary to consider possible dependencies that may arise among them.In the first place, we have to decide what kind of navigation is more suitable, whether a goal-driven navigation or an ES-driven one.
For example, if we want to model that a certain ES (called ES_1) must be performed before another ES (called ES_2) we have at least two valid alternatives: • to model the precedence relationship at the Functional level with a Goal Attempt Connector, or • to model at the Order level with an Order Connector, particularly the Strict Sequence connector.

DESIGN OF A FLEXIBLE AND ADAPTABLE LMS ENGINE IN CONFORMANCE WITH POEML
So, what happens if the modeler by mistake does a bad modeling work and, at the same time that he models the precedence relationship ES_1->ES_2 with a Goal Attempt Connector, he models ES_2->ES_1 with an Strict Sequence Order Connector?.In this situation, a deadlock is produced.The resulting Educational Scenario is impossible to be completed.It results obvious that we have to check the validity of the model at some point before deploying it: the system has to perform a validity check at build-time in order to avoid possible inconsistencies among perspectives, and deadlocks.
The Functional Perspective lays directly on the Structural Perspective, which is the key perspective and acts like a solid foundation to the other perspectives.So, the hierarchical composition of Educational Scenarios must be the first thing to be done in a modeling work, as it is the ground for the other perspectives.Consequently, the Structural and Functional Perspectives are tight coupled.
On the other hand, the Order Perspective is not so dependent on the Structural Perspective.Indeed, an Order Specification only works with Education Scenarios belonging to the same aggregation level.In a similar way, the Temporal Perspective is not very dependent on the Structural Perspective.Only sub-ESs at the same aggregation level can be planned by a Temporal Specification.
With PoEML we reach a very important objective: the flexibility in precedence relationships.It is possible to design a set of compatible Order Specifications for a given Educational Scenario.In conclusion, it should be possible to change the Order Specification for a given Educational Scenario at run-time.This is what we call a hot-pluggable Order Specification.Furthermore, the Order Specification for a given Educational Scenario can be switched on and off.This is a key point both for flexibility and adaptability.

IV. CONCLUSIONS AND FUTURE WORK
It is considered that modularity is the key point both for scalability and flexibility [6].The LMS engine is intended to support the e-learning solution of a broad range of pedagogical institutions, from the small ones to the big ones, as it can be a public university, so the solution must be scalable.We propose a distributed object-oriented architecture as the means to develop a scalable and flexible system.Scalability is accomplished by appropriate controlling of execution threads.
The PoEML separation of concerns approach permits to develop a LMS engine incrementally and in a very modular fashion.Each piece of functionality is separated from the rest and has an API of its own.Adaptability and flexibility are the two hottest research topics both in Workflow Management Systems and Learning Management Systems.The lack of flexibility in WfMSs and LMSs is a well-know problem in this kind of systems.We expect that the great modularity of the PoEML specification will be of aid in developing a runtime execution engine supporting the PoEML characteristics of flexibility and adaptability.This approach allows the administrator to make changes into a given ES perspective specification at run-time, as the dependencies between perspectives are explicit and welldefined.

Figure 1 .
Figure 1.Structure of the ES as PoEML basic building block ferent concerns, arranged in 13 perspectives and 4 aspects.Perspectives and aspects are two different kinds of orthogonal concerns.While perspectives are focused in issues with a specific purpose, aspects are about issues that do not have a specific purpose on themselves, but that affect to other concerns.Anyway, despite the large number of perspectives and aspects, a main property of the PoEML proposal is that perspectives and aspects can be used in a modular way.In practice, there exists just one perspective that needs to be considered always in any educational unit.Meanwhile, the other perspectives and aspects are optional and they can be used when required.The solution introduced in this paper involves just 4 of the PoEML perspectives.In addition to the Structural perspective, it also involves the "Functional", "Order" and "Temporal" perspectives.Next, it is provided a brief description of them:The Structural perspective is about the structure of the elements involved in educational units.A basic building block is identified and defined as an Educational Scenario (ES).The ES enables the inclusion of the several elements that may be involved in an educational unit.In addition, it also enables the hierarchical aggregation of sub-ESs.The Functional perspective is about what has to be done in the educational unit.It involves the description of the goals, the input requirements to allow the attempt of the goals, the output requirements to determine the satisfaction of the goals, the input data and output data, and the relationships among goals.Each ES needs to involve at least one goal.The Order perspective is about the order in which the several sub-ESs of a certain ES have to be performed.Main issues in this perspective are the performance of several sub-ESs in parallel and the synchronization of their conclusion.The Temporal perspective is about the specific time at which the several sub-ESs of a certain ES have to be performed.For each sub-ES it is possible to introduce temporal points or constraints that determine when it has to be initiated and finished.These temporal specifications can be used alternatively or complementarily to the order ones.

Figure 2 .
Figure 2. Modeling of educational units as hierarchical aggregations of ESs in PoEML tains several sub-ESs, and each one of these sub-ESs can contain other sub-ESs and so on.Each ES can include the elements, specifications and expressions described in the previous section.In addition to the hierarchical arrangement, the several ESs are related among them in the following ways (see Figure 2): • The Goals of an ES can be related with the Goals of their sub-ES through completion dependencies.These dependencies indicate what Goals have to be completed to complete the parent Goal.Completion Dependencies are the black lines in Figure 2.They serve as a means to express hierarchical relationships among Goals.It can be noticed that "Goal 1" depends on both "Goal 1.1" and "Goal 2.1" to be complete.• The Goals of the sub-ESs can be related among them through attempt dependencies.These dependencies indicate what Goals have to be performed before other Goals.They are shown in Figure 2 as red lines.It can be noticed that, in order to attempt "Goal 2.1", "Goal 1.1" has to be achieved before.Attempt Dependencies are a kind of precedence relationship among Goals.• The sub-ESs of an ES can be related among them through Order Specifications and Temporal Specifications.These specifications indicate the order in which sub-ESs have or should be performed and the moments when they can/have to begin and finish, respectively.

Figure 3 .
Figure 3. Sequencing diagram showing the engine perspectives interacting at run-time

Figure 4 .
Figure 4. Execution states of an ES instance in PoEML

Figure 5 .
Figure 5. Execution states of a Goal in PoEML 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 that have to work towards the achievement of the Goals; (iii) one or several Environments containing the resources that can be used by 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.In addition, 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.For this paper the main specifications are the Order and Temporal ones.