PRMS Report

From Wiki
Revision as of 09:10, 16 August 2012 by Suhridk (talk | contribs) (→‎User Evaluation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigationJump to search


  • This report developes the idea of a visual graphical editor for Epsilon and the process of developing it.
  • A fully working epsilon workflow builder and visualizer is also presented that helps users to compose Epsilon workflows and construct visual representations from textual ones.

Statement of Ethics

  • Informal user survey for requirements.
  • Formal user survey to evaluate the tool ?



  • Why EWE ? What is the need ?
  • Workflow inherently visual - flow of order of tasks.
  • e.g. BPM tools all provide editors.
  • MDE is essentially a sequence of steps from start to finish.
  • Other model management languages, frameworks tools provide it as well. (Atlas, OpenAW, etc)
  • Therefore Epsilon, needs one too.


  • Documents the process of building such a tool using MDE techniques and Epsilon itself.

Literature Review

  • Introduce ALL concepts and technologies that are critical to understanding the tool.
  • Model driven engineering - tasks involved. Tasks constitute a workflow.
  • Workflows in general - BPM workflows, Model driven engineering workflows.JBPMN
  • Build tools - Visualize Build Tools - ANT, VizAnt, Ant Explorer, Ant Utility
  • Other MDE Workflows - OpenArchitectureWare, ModelBus Atlas MegaModel Management
  • How does Epsilon handle it ? Internal architecture of Epsilon Workflow.
  • Talk about EMC Layer - this will be useful later - to explain how powerful it is to directly use EMF API or DOM API.
  • ANT, Java Modules, Eclipse Launch configuration, Working outside Eclipse.
  • Provide a general introduction to build management, concept of dependency, task ordering, conditional ordering, task failures, transactions.
  • How ANT provides some of these features as a build tool. How Epsilon uses ANT as an architecture - quote from Epsilon ANT paper.
  • Introduce idea of domain modeling. Separate the concern of design and architecture. This is the CORE idea.
  • Eclipse EMF technologies. How EMF supports Domain Modeling. Give a simple Library example.
    • Library domain is expressed. An Editor for the domain is generated - but uses unique architecture. e.g. Adapter, Factory and Command patterns - which WE never specified while modeling the domain.
  • Make sure this concept is well understood. MDE in general and how EMF tools support MDE with practical examples.
  • Eclipse graphical technologies GEF -> SWT, JFace.
  • Eclipse GMF as a bridge between GEF and EMF.
  • How GMF is Model based and Generative
  • How it fits well for Epsilon since both are based on EMF.
  • Introduction to EuGENia.


  • Initial project description
  • Asking Epsilon users to comment on forum
  • Discussion with Supervisor
  • Self proposed requirements


  • Eclipse vs NonEclipse
  • EMF in built editor vs (GMF/Graphiti)
  • GMF vs Graphiti
  • GMF - EuGENia support (Generate GMF vs manual GMF model creation), in house expertise with GMF models, EuGENia authors based in York, customization.
  • EuGENia GMF support for EVL and error/warning markers.

ECore metamodel design

  • Represeting ANT concepts as GMF nodes for e.g. Project, Target.
  • Using concept of depends and follows.
  • Accurate modeling of ANT structure - allows operations to be performed at the higher Task level as opposed to lower levels - such as EOLTask etc.

Scripting design choices

  • Using Java vs using Epsilon languages
  • Epsilon :- reflective features. Easy model navigation.
  • Generate Java Module code ? Or Generate ANT XML Code ?
  • ANT XML - To support legacy use case and avoid complexity of Java module code.
  • EEF Model manipulation - Instead of editing code, was done using EOL scripting.
  • Using EGL:
    • Protected regions: Merge engine
    • XML Formatter
    • Full reflective support.

Editor Design

  • Task to GMF node mapping design choices (Which elements in the metamodel should be visualized)
  • Compartments vs Property views - Too boxy. So rejected.
  • Property Sheet
  • Property Sheet implementation choices : Custom SWT code (rejected/knowledge of SWT - Time constraints: Used by Ecore editor)
  • EEF as the choice.
  • EEF: new technology, never been integrated with GMF before.
  • Challenges in customising EEF - Poorly documented code base.

Parsing Design

  • XML Parsers vs EOL vs ETL


  • Development methodology used ? - Justify.
  • ECore diagram editor was used to specify the metamodels.
  • GMF annotations were made in the editor.
  • What all GMF annotations were used.
  • How GMF models were customized after generation.
  • EEF implementation.
  • How EEF was plugged-in.
  • Customizing code-generation properties - Namespace, package structure, documentation.
  • Generated code customization: For e.g. disabling unwanted creation tools.
  • EGL implementation.
  • EVL implementation.
  • Parsing implementation
    • EOL vs ETL
    • ETL was chosen - why ?
    • ETL implementation choice - Reflective vs Declarative (Balance dealing with future change vs ease of code)


  • Where to list identified enhancements for the project ?
  • EWE itself - support conditional statements.
  • EuGENia enhancements identified - bugs.
  • Integrate EEF within EuGENia MDE process.
  • Contribution of EWE itself <- In Evaluation section ?

Project Description

  • Evaluation will proceed by applying the new contributions to the examples of existing workflows, and demonstrating differences with respect to functionality and development process.
    • Difference in functionality between automated and manual methods.
    • Ease of usability in composing workflows.
    • Ease of modifiability of existing manual workflows using the visual editor.
    • Ease of use for first time users in building workflows and understand Epsilon Workflow language.
    • Development process refers to what ?
  • An analysis of the ways in which Epsilon users construct and use workflows.
  • Three improvements to the prototypical Epsilon workflow language to support visualisation and automatic code generation.
  • A comparison of the prototypical and improved versions of the Epsilon workflow language.

Evaluating the Artefact

  • Test cases as a method of evaluation?
  • Manual testing and verifications against requirements.
  • Black box testing for evaluating against user requirements.
  • Test case with a description against each FR and NFR. Process of executing, screenshots etc.
  • White box testing:
  • Cite EUnit paper about Difficulty in performing white box testing for MDE tasks.
  • Develop some Sample EUnit cases.

User Evaluation

  • Similar to Case Study?
  • Explain why it makes more sense for an actual user evaluation rather than a self performed case study.
    • Self case study : usability aspects difficult to evaluate due to intimacy with tool.
  • Informal live User Evaluation: Perform series of exercises designed to evaluate usability of new tool.
  • Discuss results of experiments ? (Describe experiments/exercies here as well).
  • Ethical considerations.

Evaluating the metamodel design

  • Expectation
  • Result
  • Evaluation

Evaluating the code generator

Evaluating the code visualizer

Evaluating the development process

  • Huge productivity benefits.
  • Understanding complex UI frameworks avoided.
  • No of classes and code gneerated enormous.
  • Focues on higher level abstraction - code gen, viz, validation would not have been possible.
  • Significant time was spent - tweaking model, generating code.
  • Finding out where in code modifications need to take place.
  • Significant time was spent in researching EEF integration with EuGENia generated GMF editor. Trial/error, forum posting


  • Provide a concise summary of the whole project.
  • Making accurate predictions of results that would be obtained by applying the present work in new areas.
    • Extend it as a GMF editor for any complex application that needs to use Ant as a basis..g. JBPM - JBoss.
    • Use it to visualise complex Ant builds within Eclipse IDE.
    • More ?
  • FURTHER WORK here or in Evaluation.
  • Lessons learnt, personal reflection.