Model for transformations: Build own

The computation result of the winery yaml parser is a TServiceTemplate.java. Should plugins deal with this model directly or is there a more convenient way for plugin developers to access the TOSCA topology?

Considered Alternatives

  • Inherit from TServiceTemplate and extends it in some way
  • Build own data model
  • Describe metamodel with Eclipse EMF and generate instance model

Decision Outcome

  • Chosen Alternative: Build own data model
  • Comes out best (see below)

Pros and Cons of the Alternatives

Inherit from TServiceTemplate and extend it in some way

A new model with all classes in a different package inheriting from all model classes. Each class gets new methods.

  • + org.eclipse.winery.model.tosca.yaml reused
  • - EMF Resource Set handling is implemented manually
  • - Plugin developers have to deal with the model in an inconvenient way:
    • e.g. types are not expressed via java classes -> OO design is ugly
    • each plugin would have to define own classes of the supported node types, and map the contained elements of TServiceTemplate individually to proper java instances

Build own data model

Build an own data model instead of reusing the TServiceTemplate. While doing this, be more object oriented. I.e., the normative Node Type WebServer is modelled as a java class, and an instance of that class is a NodeTemplate of that Node Type.

The new model should be accessible via a graph (using jgrapht), whereas modeled NodeTemplates are vertices and relationships are edges.

  • + Clean data model
  • + cleaner OO design
  • + As plugin developer: Convenient usage of the model
  • + As plugin developer: Type safety
  • + less code duplication in plugins
  • + central definition of specific supported node types
  • + easier to troubleshoot due to strong typing
  • - both UML diagram and java classes need to be taken care for

Describe metamodel with Eclipse EMF and generate instance model

  • + Resource Sets handling does this transparent solution
  • + UML and code stays synchronized
  • - Changing all the model to EMF causes huge overhead
  • - Getting EMF into non-OSGi projects is hard
  • - Team doesn't know technology -> hard to tell if its suitable for our needs -> high risk