Ecore Model

After creating the new GMF Project, the project folder structure in Eclipse Package  Explorer should be seen as the Figure 5.2. 

  Figure 5.2 Project Folder Structure

The first step for GMF project development is to create Ecore Model via Eclipse New Wizard,  which is the meta‐model for the later generated models. The Java codes generated based on  Ecore  model  are  the  implementation  of  EMF,  which  provides  the  fundament  for  GMF  development.  After  generating  EMF  Java  codes,  the  development  of  EMF  is  accomplished. 

GMF implementation starts with establishing Graphical Definition Model, Tooling Definition  Model  and  Mapping  Model  through  Eclipse  New  Wizard.  These  models  support  the  Generator  Model,  which  generates  the  diagram  codes.  In  the  following  Sections,  we  will  introduce the whole Cafe application editor implementation process in details. 

5.2 Ecore Model

5.2.1 Introduction

Ecore  is  a  kind  of  meta‐model  used  to  describe  EMF  model.  Ecore  model  is  also  a  kind of EMF model, so at the same time, Ecore model is also a meta‐meta‐model. In  Ecore  model  there  are  following  components: ^EPackage, ^EClass, ^EAttribute,  EReference, ^EEnum and ^EDataType etc. 

EPackage  is  the  root  of  Ecore  model,  which  defines  the  namespace. ^EClass  represents  a  class,  which  contains  an  arbitrary  amount  of  EAttributes  and  EOperations. ERefference  describes  the  connection  and  relationship  between 

two  ^EClasses.  ^EEnum  is  an  enumeration  type,  in  which  exists  at  least  one  EEnumLiteral. ^EDataType indicates the type of ^EAttribute like ^string, ^int,  float etc. 

EMF  provides  a  graphical  editor  for  the  constitution  of  Ecore  model,  which  can  be  implemented  as  simple  as  drawing  UML  diagram  by  drag  and  drop.  The  XML  file  describing the Ecore model changes automatically according to the modification of  Ecore  diagram.  The  Ecore  model  constitution  process  will  be  introduced  upon  the  requirements of Cafe application in next Section. 

5.2.2 Ecore Model Constitution

First  let’s  look  at  the  constituted  Ecore  model  diagram  and  the  diagram  editor  in  Figure 5.3. 

  Figure 5.3 Ecore Model Diagram and Diagram Editor

In  the  left  zone  of  the  picture  is  a  tooling  palette.  Developer  can  choose  the  appropriate objects or connections, and then put it in the canvas through drag and  drop. The bottom zone shows the property of canvas and canvas components. The  value  of  property  can  be  input.  For  example  the  Name,  Ns  Prefix  and  Ns  URI  of  Epackage  are  set  as  cafeApplication.  The  Ecore  diagram  is  constituted  according to the requirements of Cafe application in the canvas. 

5 Implementation of Graphical Editor 

Application  Template  is  the  canvas  in  Cafe  application  diagram,  which  contains  Components  and  Relations.  The  Application  Template  includes  Application  Name  attribute  and  Application  Description  attribute.  Their  types  are  both  java.lang.String, which is named as ^EString in Ecore. 

Component  contains  three  attributes.  They  are  Component  Pattern,  whose  type  comes  from ComponentParternEEnum, ComponentName  and ComponentType,  which  are  both  ^EString  type.  There  are  three  different  patterns  in  ComponentParternEEnum,  which  are  ^singleInst,  singleConfInst  and  multipleInst. In Chapter 3 we have introduced Deployment Relation to describe  the  dependent  relationship  between  Components.  In  the  Ecore  diagram  it  represents  that  the  Component  can  contain  other  Components.  Each  Component  includes  any  number  of  Requirements,  Implementations,  Visible  Properties  and  at  most one Variability. 

As  discussed  in  Chapter  3,  Requirement  describes  not  only  the  SLA  between  application vendor and application provider but also other information like version. 

Each RequirementKey has any number of Values. For example, one availability key  has 99.9% and 99.99% two values, which indicate that the actual availability can be  any number between them. The version key can be 1.0, 2.0 and 2.2, which represent  the version change during the update of Component. 

Implementation is an important part of Component, which tells how  to implement  the  Component.  Its  attribute  implementationType  represents  the  implementation  methods  like  Java  Web  Application  or  BPEL  Engine.  Every  Implementation  includes  an  arbitrary  amount  of  Files,  whose  attribute ^fileName  represents the path of the file used to implement the Component. Furthermore, this  attribute also decides which files should be packaged in the Cafe archive file. 

Visible  Properties  provide  external  information  about  a      Component,  through  which,  the  Component  can  be  accessed  from  other  Components  or  external  ways. 

The  example  shown  in  Figure  3.2  tells  that,  EPR  provides  the  access  for  Workflow  Component,  while  URL  provides  the  access  for  GUI  Component.  The  Element  component contains the concrete description of interface like URL or EPR address. If 

There  is  another  component  so‐called  Relation  connecting  two  Components  in  the  Application  Template  canvas.  Its  source  is  Variability,  while  the  target  is  Visible  Property. 

5.2.3 Code Generation

After  designing  the  Ecore  diagram,  a  new  EMF  Generator  Model,  which  aims  to  automatically  generate  Model,  Edit  and  Editor  Java  codes,  need  to  be  created  through  Eclipse  New  Wizard.  During  the  creation,  the  Ecore  meta‐model  must  be  loaded manually. 

In the EMF  Generator Model we can configure the parameters like Copyright Text,  Java Code directory, Plug‐in ID etc. In the development of Cafe application graphical  editor,  there  is  no  need  to  change  the  default  generated  Java  code.  Therefore  the  EMF Model development is accomplished. In the    following Sections let’s start the  development of GMF diagram.