# Learn-CIAM: A Model-Driven Approach for the Development of Collaborative Learning Tools
## 3 The Learn-CIAM Proposal: Supporting Model-Driven Development of Collaborative Learning Tools
### Methodological Framework
#### 3.3.2 Phases  
The methodological proposal consists of two different phases. In the first phase (Figure 6), we enumerate the stages to be followed in the elaboration of an Eclipse-based graphical editor. In the second phase (Figure 7), we list the stages required to model, validate, and generate a collaborative tool. The basis of this second phase is the graphical editor, Learn-CIAT, which was also created and generated by applying the first phase of the method. Figure 6: Phase 1: Generation of a single-user/collaborative graphical editor. First Phase: Elaboration of a Graphical Editor Using Eclipse Technology  
The first phase consists of a total of five stages. This process is similar to that of generating graphical editors, which uses Eugenia technology and Epsilon core languages, except for the third stage, in which it is possible to provide collaborative functionality to the generated single-user editor through its integration with SpacEclipse. The stages and the users involved are listed below. * Stage 1--Informal specification: in the first stage, the domain experts must generate a first \"sketch\" of the graphical editor, specifying their working domain. For instance, a graphical editor could be generated for modeling digital circuits, network topologies or use cases, among many other domains. * Stage 2--Domain modeling: during this stage, the domain experts, with the help of the software engineer, must proceed to model the domain defined previously. For this task, the software engineer must be an expert in the chosen technology, identifying and relating each of the parts of the graphical editor \"sketch\" with the proper meta-modeling components. Specifically, it must generate the Ecore representation. After that, since Eugenia was the chosen technology, it is also necessary to add the adequate annotations. All this information (Ecore meta-model + Eugenia annotations) must be included in a unique Emfatic file. * Stage 3--Graphical editor customization: in the third stage, the collaboration between the domain expert and the software engineer is very important. This stage is not mandatory; nonetheless, when the desired editor is more complex than what Eugenia technology can provide/generate by using its basic annotations, it will be necessary to modify the figures and relationships that it generates by default to adapt them to the editor's needs. To this end, it is necessary to generate (or reuse) an EOL template which contains the appropriate modifications. This template will be detected and applied by Eugenia automatically during the generation process. In addition, the restrictions that are automatically generated from the meta-model will sometimes not be sufficient; therefore, it will be necessary to add more manually. With this aim, one or more EVL templates must be generated and they must contain the restrictions or advices that the editor must support additionally. Furthermore, the users can also provide collaboration functionality to the editor. To achieve that, the SpacEclipse plug-in must be used. This plug-in contains the basic code in order to receive single-user editors and provide them with collaborative functionality, generating a collaborative graphical editor for Eclipse automatically. This is possible by simply pressing a button that applies a prepared script, which adds the necessary collaborative functionality to  
Figure 7: Phase 2: Modeling, validation and generation of collaborative learning tools. the editor. Another interesting option provided by the technology is the possibility of modifying the final code generated by Eugenia, using EGL/EGX (EGX files are EGL templates which coordinate the generation of the final code (generating the code in the corresponding path)) templates. This step is usually necessary in those cases in which, despite having made some visual modifications, the generated editor still does not meet expectations (e.g., it may be necessary to bring the nodes closer to the label of one of their attributes).