[3] and Open USS [4] offer added functionalities like QCM,. Tracking, Music Editor, Exercise ...... (LMO'04), Lille, Mars 2004. [35] Desmond Francis D'SOUZA and ...
> MCETECH’2005 Conference submission, paper n°26
MCETECH’2005 Conference submission, paper n°26< administrative tasks as well as student participation in elearning courses. This term describes a wide range of systems that organize and provides access to online education services for students, teachers, and administrators. These services usually include access control, provision of learning content, communication tools, and administration of user groups. 2) Common features Both CMS and LMS applications usually use three-tier architecture. Three-tier architecture establishes a separation between the following parts: client tier or user interface, middle tier or business logic, data storage tier. When it comes to web applications these three logical tiers usually correspond to the devices or hosts used: browser or GUI application, web server or application server, database server (often a Relational Database). LMS and CMS often use some “light” technology, like HTML, PHP, and MYSQL to implement a tree-tier architecture. These technologies are more accessible to the non-expert user. Public providers usually offer these solutions. These applications use the term “brick” to refer to a component that takes care of a specific task. Components are independent from one another; they can be plugged into the environment. For example, LMSs like Ganesha[2], Claroline [3] and Open USS [4] offer added functionalities like QCM, Tracking, Music Editor, Exercise editor in the form of plugins. For CMS like Postnuke [5], Spip [6], and Mambo [7] many plug-ins are available: Chat, Shoutbox, Calendar, News, and Forum. To summarize, LMSs and CMSs are composed of foundational components and extension Components (plugins). B. Benefits of component approach in LMS 1) Using pedagogical methods within computerized context The choosing of a particular CMS or LMS will have a strong influence on the ease with which a pedagogical methodology will be developed.. Or a teacher doesn't easily change the way s/he teaches. Besides, one way of influencing a teacher is to change his framework [8]. Teachers would like to find components on a learning platform that support his/her manner of teaching. The purpose of this part is to show in computerized context the influence of pedagogical theory on the different usages of learning platform, being some components better suited to a specific pedagogical model than others. The Behaviorism is founded on the idea that there is training whenever a student gives a correct answer. This theory is based on the observation of the student’s behavior and on their responses [9] . The direct consequence of this theory is to give particular interest to the transferred knowledge and not to the cognitive guiding process. This model presents the brain as a passive container that needs to be filled in. On e-learning systems, the main characteristic of this model is to single out components that allow teachers to upload documents and to measure knowledge acquisition. The Cognitivism is defined by a set of activity and inner
2 processes inherent to knowledge acquisition [10]. Training is felt as a knowledge building process and not only as a simple knowledge transfer. The e-learning version of this model privileges components which allow for a precisely scheduled document delivery to students. Every document has a determined order in a sequence considered coherent, logical and progressive by the teacher. This method is implemented by components that allow feedback during the learning process and that assess students along the learning process. Some components enable document upload by a teacher and by a student. This functionality introduces unpredictable, complex and real elements into the courses therefore allowing the building of knowledge from real context. Thus, the construction of new knowledge can occur only in the context of the real life and this is a fundamental element of Constructivism [11]. This model improves knowledge coconstruction by the students. Components allowing the discovery and the exploration of problems usually suit this model of which Active and dynamic geometry [12] and Simulators [13] are good examples. These components stir up the rising and the solving of cognitive conflicts. Within the framework of the Mediational theory, learning follows interaction between different actors. Vygotsky[14] describes important points which enhance knowledge acquisition: Guided participation Scaffolding Apprenticeships Peer interaction This model uses CMS components of different categories. First category is constituted of social awareness components [15]. These components allow for the actors’ awareness and thus supporting the emergence of a community of practice. Second category of component arouses confrontation and the mise-en-scène of socio-cognitive conflicts[16]. 2) Modularity: trading ad-hoc components From what we have presented so far, we are now able to construct taxonomy of reusable components. Applying the same taxonomy to the functionalities of the learning platform would permit the mapping between functionalities and components. Another benefit of this logical separation is to allow component activation and deactivation on the fly. Any platform allowing for this concept should be able to implement a core of collaboration and teaching tools, which would make it more convenient for the rooster. Theses steps are recommended by Schneider, Syntéta and al[17]. Upon demand, new tools can be added, being their number and their diversity constituting an indicator of the vitality of the community. According to the Pragmatic Aspect Theory [19][20], [21] teachers are encouraged to build and rebuild their lesson from a finite set of object and schemes. Applying the above mentioned logical separation to this finite set of components within a platform would allow the teacher to describe his course as a list of components [22].
> MCETECH’2005 Conference submission, paper n°26< In case one has to migrate to another teaching platform, one would like to find components that present about the same functionalities one his used to. There are many component repositories for both CMSs and LMSs, but they hardly make use of classification schemes concerning e-learning concepts. In France, a research group proposes a taxonomy for elearning platform components to be used by researchers in the field [23] 3) Evolution: designing missing and needed components To take advantage of the component-based approach, an elearning community has to classify and describe the existing components and to explicit the teaching scenario in terms of its abstract component functionalities. To be easily reusable in different teaching platforms these scenarios must include smart reference to usual component functionality. It is necessary to elaborate simple mechanism allowing course reusability and sharing. It seems that this mechanism would be better performed with the elaboration of an abstract scenario and an abstract description of the components. But a difficulty we can not overlook would be to export abstract components to a specific platform. Another need is to conceive components which solve pedagogic obstacles and not only easy-to-do components (QCM, Forum, etc). This has already been done with in Argue Graph for PostNuke, « Tour de table » for Accel, and others. A platform devoted to e-Learning researchers, for example, would be used to federate different skills among peers. On this platform it would be possible to find component repository, example of scenario for benchmarking, essential tools for communication and mediation, bug list, etc. The French platform ASP, above mentioned, aims this objective. C. Problems about component design The main problem about the reuse of components is the tangling of business logic during implementation. Porting a component to another platform requires separation of concerns (business, technical). Component designing demands a deep knowledge on interfacing to the chosen platform and requires the studying of existing components – despite black-box-like implementations. Some platforms warrant separation of business logic from cross-cutting concerns. However business remains deeply dependent of a particular implementation language. This implies two main problems: further porting requires the mastering of the target language and components may become "unreachable" if underlying technology becomes deprecated. One of LMS’s strong features is its underlying developer open communities. Design is thus often cooperative and in the distance. There is no approach that provides these communities with enough rigors to support such cooperation. III. MODEL DRIVEN APPROACH TO ADDRESS LMS COMPONENT ISSUES
The NOCE team aims to address problems concerning computerized learning environments [24] [25][26]. Separation
3 of concerns, platform mastering and subcomponents study characterise typical difficulties to functionally populate a LMS. They are critical because they constitute barriers to 'pedagogical evolution' of computer science. Our previous works about meta-modelling [27] [28] naturally led us to adopt Model Driven approach1 [29] to address these problems. If the MD approach is a smart solution for 'software design', it remains an approach. It has to be adapted on each type of software (like LMS), and this process is generally not trivial. This part first describes Model Driven approach principles. Then it proposes what could probably be the basic theory of model-driven LMS components design. Finally, it focuses on an aspect which is generally omitted and which is fundamental for the adaptation to the LMS context: the methodology. We hope to demonstrate the importance of the LMS design context and its main repercussion: the (future) propositions of LMS components model-driven design must be build on one (or several) methodology(ies). Our proposition of methodology will be described in the following part. A. Main features of Model Driven Approach The MD approach exists since tools like Rational Rose provide code generation from models (usually business models). In recent years, this approach has aroused great interest since the adoption of the Model Driven Architecture by the OMG. Broadly speaking, Model Driven approach/architecture consists in separating business or application logic from underlying platform technology [31]. This conducts to several benefits: Software programmers/engineers read and understand the business/application logic easier. That improves group work which is inherent in all software development projects. As business logic is defined independently from a technologic context, it is not subject to frequent technologic changes (causes may be platform evolution, economic choices, adoption of technology in fashion) and has a longer life expectancy. Thanks to technology-independent business model, cost of (partial) migration of the application in another technology decreases. 1) programmers/engineers do not have to master the origin implementation technology. 2) They do not have to extract the business logic from origin implementation. Code generation and models transformation are the two fundamental MD Approach mechanisms. With its association to elaborated models, code generation brings considerable advantages: Generic part of software – connection between components, GUI templates, persistence … – may be automatically generated according to business logic. According to detail level of logic model, a more or less important part of business implementation may be
> MCETECH’2005 Conference submission, paper n°26
MCETECH’2005 Conference submission, paper n°26< the LMS component logic and finally on the implementation. This may be a good sequence. Reusability is still present: the business logic may serve to other use context, the component model to other type of component platform, the LMS component model to all LMS components. According to our experience and to reusability needs, the previous models sequence may benefit from the insertion of an additional step in the previous sequence. Indeed, as it exists different LMS classes (group oriented, document oriented, activity oriented…), it may be interesting to work on a model related to a specific LMS before code generation. In addition to increase reusability, behaviour of component in different contexts will help other developers to grasp nature of it. Figure 1 summarizes what could be application of MD approach to LMS component design. C. MD approach and the need of a rigorous method Concerning LMS components, we think that Model Driven Approach is mainly relevant for design and reuse processes rather than composition one. We did not define an abstract LMS component metamodel, because it is currently out of our skill area. In the other side, we assume there will be soon such a metamodel. But we have focused our works on the methodology related to modelling process. This fundamental aspect because the LMS components design context is strongly cooperative and distant. In an effectiveness perspective, this implies that developers have to adopt a rigorous method. In other words, to just use an abstract component metamodel is not sufficient (because it is probably not initial goal of such metamodel): Low expression power: an abstract component model is not very significant about real behaviour. During design, discussions concerning this aspect are not easy with such formalism. Formal definition of contextualisation, sequence… will remain few detailed and few useful for design and reuse. Instructions for use (Guidelines, best practices): Where to begin ? Modelling process is like every tools, it needs instructions to use. These instructions are rarely proposed for new metamodels. For instance, abstract component metamodel do not have one. Repercussion: In a cooperative context it is important to lead repercussions of changes (for instance, just by listing repercussion rules).
5 IV. COMPONENT BASED MODEL DRIVEN APPROACH FOR LMS We propose to adapt Unified Process [38] to provide a structured guide to component based model driven design, supported by an architecture of technological independent models. The purpose of this approach is to support easiness, flexibility, robustness and especially re-usability. We adapt Unified Modelling Language [38] to explicit the concept of component during all the software development life cycle. There already exist component based approaches [35], [36], [37]. Each one uses or customizes a succession of UML diagrams addressing different concerns. However these models remain relatively independent between them. Moreover the formalism that we propose includes a notion of logical component that is omnipresent. Some of the classical UML model as Use Case Model does not include the concept of logical component and standard approaches only consider component for deployment concern. We claim that the possible detection of existing component must be early. Finally some of classical approaches do not cover a complete Model Driven Architecture process and so don't profit its benefits. In particular, they do not provide mappings towards different technological platform based on component to build Learning Management Systems for instance. CUP Metamodel
InteractionViewMetamodel describe by
ComponentViewMetamodel
UsecaseViewMetamodel
AssemblyViewMetamodel
describe by
describe by describe by
1 PIM
PIM
UsecaseView
PIM
AssemblyView ComponentView PIM
InteractionView
Component-based design usually misses a methodology or a method when it adopts model driven approach. If this may be eventually annoying in "pure" software engineering, it becomes fundamental in context of LMS component design. The next part presents our proposition related the three previous problems: it focuses on the starting approach and not a successive refinements and a abstract LMS component metamodel.
2
CUP Model
3 4
PSM J2ee
PSM LMS
PSM …
Figure 2 Logical Component Model This part proposes an architecture of design models named “Logical Component Model” (Figure 2). First we present this
> MCETECH’2005 Conference submission, paper n°26< model as an extension of UML meta-model with the concept of component, that links strongly each meta-model. Second, we present the process itself, which unlike Unified Process is adapted to consider early identification of conceptual component. The “Component Unified Process” guide the use of the logical component model to deal with low expression, instructions for use and repercussion. A. Logical component model This section presents the formalism used to model information system with the omnipresent concept of component and that provides 4 views about a system. To do that, we define the notion of LogicalComponent introduced to deal with difficulties to use notion of component specified inside UML 1.4. The notion of logical component is present in the 4 views. Each view is formalized by a sub-meta-model that is presented below and address one concern. The technology independent formalism, as a MDA Platform Independent Model, is used in the 4 views. The 4 views together constitute the entire model of the system.
6 Each use case is realized by a set of architecture elements. UML collaboration and sequence diagrams allow to represent roles and messages between these elements during execution of a scenario. An element can play role in several use cases, but it does not inevitably play the same role. CUP meta-model introduces standard analysis roles: Control role encapsulates processing due to a scenario and manages all the steps described in the scenario. Entity role is a kind of business objects, easily identified in written specifications and documents. It contains information of the system as well as the business processes. Actors interact with the system through Boundary roles. If an actor is a human, a boundary often corresponds to a Graphical User Interface. Otherwise, a boundary encapsulates the protocol which is necessary to communicate with another system. We introduce a new analysis role, the ExternalControlRole which represents the use of control roles from another component.
Figure 5 Component view design meta-model Figure 3 Use case view meta-model 1) The Use case view is like the UML use case diagram with adding of the notion of logical component. This first CUP UseCaseMetamodel (Figure 3) concerns the use cases. We propose to associate the concept of component with a collection of use cases. They are gathered, and owned within the same component, according to the services they offer. We add the externalUse relation to standard relations between use case. ExternalUse allows to express that a use case owned by a component includes some steps of a use case owned by another component. This relation allows to reveal interactions between components.
3) The Component Design view (Figure 5) allows to describe the software architecture elements, their structure and the relations supporting their interactions are described in the interactions model. One component offers services and needs services provided by other ones. A component provides interfaces that provide its business methods. They define a set of component behaviors. A component has several interfaces, which allow organizing the business methods according to points of view of the client components.
Figure 6 Assembly view meta-model 4) The Assembly view (Figure 6) gives a representation of the components which compose the system. It gives a black box view of the component, representing its ports (provided interfaces, and required interfaces) and connections between components. Figure 4 Interaction view meta-model 2) The Interaction view (Figure 4) shows contextual interactions between elements of the component architecture.
B. Component unified process As presented below, logical component is presented in each view of the model. The activities and thus, roles taking in charge by collaborative project members are so define by these
> MCETECH’2005 Conference submission, paper n°26< views. In each one, the use of one view allows to take care about one concern but coherence between them is ensure by the meta-model and omnipresence of logical component. This section presents the different activities due to the logical component meta-model illustrated by a study case presented below: The "ArgueGraph" [40], [41], [42] is a ComputerSupported Collaborative Learning script which allows bringing together in discussion group participants with strongly divergent opinion. Each student answers individually interactive quiz. The system proposes a graph to indicate the position of members of a group. As a follow-up, the teacher asks system for producing pair of students. On the basis of their position in the graph, students are paired in a way that maximizes the average distance between them or other strategy. By pair, students have to answers quiz and to agree on a single answer for each question. The system displays a synthesis of answers and the list of all arguments used by individuals and pairs. The teacher uses this Web page for debriefing. chat
7 use case and so a component that owned that use case. The component trading tools should be based on categorization of use case (text description and category property) . The activity requirements realization consists in modeling the internal behavior of the system during the execution of each use case. The internal behavior of the system corresponds to the interactions between elements of its software architecture. A use case is executed by its scenarios. The realization of use case consists in two steps searching architectural elements and relations belong them from business object analysis, as describe below and instantiating them to play a role in the use case scenarios and find their features (attributes and methods). As the use cases are processed, the interactions view is enriched with instances of the component design view. We use UML sequences diagram (Figure 8) to represents interactions to realize nominal scenario of the use case: “to define duets” by the actor Teacher. This scenario consists in define duets from results of previous quiz. The teacher has to choose a strategy to evaluate the maximal distance between students. The system thus opens conference between pairs of students to continue the script.
To discuss
To answer the questionary
quizz
Student To define duet
:TeacherGui
:DefineDuetManager
:Questionary
:Strategy
:GraphDesign
:Chat
To create a conference
graphDesigner
askForResults askForResults() askForResults() compileResults()
sendCoordinates() To generate a graph
askForStrategy()
To fill a quizz
To create a quizz
Teacher
argueGraph
chooseStrategy
To watch results
To create questionary
chooseStrategy(strategy) create(strategy) formDuets() initiateConferences()
Figure 7 Use case view
Teacher
One activity of the CUP process is the requirements specification. It consists in expressing the functionalities that the system must offer to its end-users. For that, the concept of actor categorizes end-users and use cases express interactions between actors and the system. To simplify specifications read, each use case must have only one main actor. It initiates interactions described in the use case. Other actors of the use case are secondary. They provide data or processing, needed to execute the use case. Always for simplicity, each use case must has one nominal scenario and may have several alternative scenarios. The specification of a component is described by its use cases. Advantages of this are: in one hand, specifications of prefabricated components in this formalism can thus be integrated in the system’s model by use of externalUse relation, on the other hand, the impact of the requirements evolution will be localized at once. We propose a graphic representation derived from UML notation with addition of ExternalUse relation (Figure 7). Next activity is the existing or new component identification. To do that, we added the Use Case category attribute that is an enumeration that allows to select easily a
Figure 8 Interaction view The activity component design allows to represent the concepts of component and its definition. In the study case, the component has three provided interfaces. They correspond to the three control roles described in the sequence diagram, from the scenarios of the use case model (Figure 7). Component implements its provided interfaces. The component designer must choose if the provided interface is implemented by one or more. In the study case, each provided interface is implemented by one part. As defined before, component’s parts contain the business processing and information due to the respect of the component functional contract. The Entity roles of the analysis model are good candidates to become EntityParts of component. For example, the entity manages persistence of the strategy. Some Parts may need data or processing from part owned by another component. To do that, they delegate to required ports like GraphDesign.
> MCETECH’2005 Conference submission, paper n°26
MCETECH’2005 Conference submission, paper n°26< [21] La pratique pédagogique entre l'improvisation réglée et le bricolage http://www.unige.ch/fapse/SSE/teachers/perrenoud/php_main/php_198 3/1983_01.html [22] Scneider and al tecfa seed catalog http://tecfa.unige.ch/proj/seed/catalog/net/catalog-eng.pdf [23] http://www.univ-lille1.fr/aspf/ [24] Derycke A., Hoogstoel F., Le Pallec X., The reciprocity project: a p2p approach of collaborative environments for life-long learning, FIE 2003, Frontiers in Education Conference, Boulder, Coloradao-USA, 5-8 November 2003 [25] Laroussi Mona, Derycke Alain, New e-learning services based on mobile and ubiquitous computing: Ubi-learn project, December 02, 2004, CALIE’04, Grenoble France [26] Vantroys Thomas, Peter Yvan, COW, a Flexible Platform for the Enactment of Learning Scenarios, International Workshop on Groupware CRIWG 2003, Lecture Notes on Computer Science, Springer-Verlag [27] Le Pallec X., Vantroys T., A Cooperative Workflow Management System with the Meta-Object Facility, EDOC 2001, Entreprise Distributed Object Computing, IEEE, Seattle, Washington USA 4-7 Septembre 2001, Proceedings pp 273-281 [28] Le Pallec X., Derycke A., RAM3: towards a more intuitive MOF metamodelling process, SCI 2003, Systemics, Cybernetics and Informatics, Orlando, Florida – USA, 27-30 Juillet 2003. [29] Rodrigues G. N., A Model Driven Approach for Software Systems Reliability, 26th International Conference on Software Engineering, proceeding - Volume 00, pages: 30 – 32 [30] Raphaë Marvie, Philippe Merle, Jean-Marc Geib, "Separation of Concerns in Modeling Distributed Component-based Architectures", in Proceedings of the 6th IEEE International Enterprise Distributed Object Computing Conference (EDOC 2002), EPFL, Lausanne, Suisse, September 2002 [31] Object Management Group, Model Driven Architecture: The Architecture Of Choice for a Changing World, 2001, www.omg.org/mda/ [32] Rutherford M. J., Wolf A. L., A case for test-code generation in modeldriven systems, second international conference on Generative programming and component engineering, Lecture Notes In Computer Science archive, proceedings pages 377-396, Erfurt, Germany, 2003 [33] Bruneton E., Coupaye T., STEFANI J.B.. The Fractal Component Model, version 2.0-3, February 2004. Online documentation http://fractal.objectweb.org/specification/ [34] Xavier Blanc, Olivier Caron, Arnaud Georgin, Alexis Muller, Transformations de modèles: d'un modèle abstrait aux modèles EJB et CCM, Conférence francophone Langages et Modèles à Objets (LMO'04), Lille, Mars 2004 [35] Desmond Francis D’SOUZA and Alan Cameron WILLS. Objects, Components, and Frameworks with UML - The Catalysis Approach. Addison-Wesley, 1998. [36] John CHEESMAN and John DANIELS. UML Components - A Simple Process for Specifying Component-Based Software. Addison-Wesley, 2001. [37] Peter HERZUM and Oliver SIMS. Business Component Factory - A Comprehensive Overview of Component-Based Development for the Enterprise. Wiley Computer Pub., 2000. [38] OMG. UML1.4 - chapter 6 -Object Constraint Language. Object Management Group, Septembre 2001. OMG formal/01-09-77. [39] Grady BOOCH, Ivar JACOBSON, and James RUMBAUGH. RUP Software Engeneering. 1997. [40] An analysis of learner arguments in a collective learning environment, Patrick Jermann, Pierre Dillenbourg, page 265 Computer Support for Collaborative Learning 1999 http://sll.stanford.edu/projects/CSCL99/papers/wednesday/Patrick_Jerm ann_265.pdf [41] Conception et mise en place d'un module pédagogique pour portails communautaire PostNuke , CHAKROUN Mourad http://tecfa.unige.ch/proj/seed/catalog/docs/ArgueGraph.pdf [42] Argue Graph script by Pierre Dillenbourg and Patrick Jermann, pour l'action MOSIL (Kaléidoscope) http://craftsrv1.epfl.ch/mosil/htdocs/files.html
9
