GMF Project Requirements
Note: This document is deprecated but maintained for historical reference. The requirements listed here now have corresponding Bugzilla entries, which are linked next to each item below. To see a list of all GMF plan items in Bugzilla, use this link.

• Extensibility
  • GMF must adhere to the extensibility best practices of Eclipse.  The generated plug-ins, the runtime framework, the genmodel, generator, wizards, etc. should all be designed/implemented with extensibility in mind.
• Interoperability
  • GMF has the potential to interoperate with a number of other Eclipse projects and, potentially, support external standards and tooling frameworks. See the Interoperability section below.
• Compatibility
  • GMF should leverage the latest (pure) version of platform and dependent projects, Java edition, utilize MANIFEST.MF files, etc.
• Testing
  • Unit tests will be written and maintained for appropriate code segments.
  • GMF should support and be tested on all the platforms supported by Eclipse or, minimally, by the EMF and GEF projects.
• Documentation
  • Standard help, exsd files, tutorials, and samples will be provided.
• Internationalization/Localization
  • GMF should be localized to the main locales supported by the platform or, minimally, by EMF and GEF.
• Performance
  • The GMF runtime, designer, and generated components should be tested for performance characteristics and follow published guidelines.

• A diagram definition may be mapped to zero or more domain models. In other words, a digram may contain elements which represent information from multiple domain models. [H][M1][114175]
• A diagram may contain multiple references to a single domain model element, potentially with each having a different diagram representation. [M][M1][114179]
• A diagram may have elements added from other referenced diagram definitions. [M][M1][114178]
• Metamodels
  • A diagramming metamodel will be provided to allow for diagram definitions. [H][M1][114177]
  • A mapping metamodel will be provided to allow for diagram to domain model mapping definitions. [H][M1][114107][114174]
• Diagram groups
  • Diagram definitions should support a logical grouping of diagrams, as required by the UML, for example. [M][M1][114180]
• Wizards
  • GMF Project [H][M1][114107]
    • Creates a project containing one or more domain models and associated diagram definition(s). The domain models may already exist and be referenced from other projects in the workspace.
    • The domain models may be created from scratch or imported *.ecore, *.emf, xsd, etc. files.
    • The required mapping models will be created.
  • Diagram Definition [H][M1][114181]
    • Creates a new diagram definition model and mapping model(s) based on selected domain model(s).
    • Provides an option to create a default set of diagram elements for selected domain elements in an "interview" format, where the toolsmith is walked through each and is allowed to select from common diagram definition options.[M+][114182]
    • It should be possible to create a diagram definition which is not yet tied to any particular domain model.[M1]
  • Domain Model [H][M+][114183]
    • Allows for the creation of a new EMF model using a graphic editor, leveraging an ECore modeling surface provided by GMF.
  • Diagram Generation Model [H][M1][114184]
    • Creates a new generation model from existing Diagram Definition.[M1][114184]
  • Diagram Mapping Model [H][M1][114186]
    • Allows an existing diagram definition to be mapped to another domain model.
• Notation Definition
  • An editing environment for diagram notation definition will be provided, to specify:
    • Nodes [H][M1][114188]
      • Shape definitions, including geometric, custom, and image file.
    • Links [H][M1][114188]
      • Connector elements to indicate relationship/flow/etc.
    • Decorators [M][M1][114188]
      • Text and icons for Node and Link elements.
    • Properties [H][M1][114188]
      • Attributes of an element to be displayed in a properties view.
  • A graphical surface for diagram definitions will be provided (bootstrapped). [M][M+][114185]
    • Provide a WYSIWYG capability for diagram definition. [L][M+][114187]
  • A graphical surface for mapping definitions will be provided (bootstrapped). [L][M+][114199]
• Tooling Definition
  • Along with diagram defintion and domain model mapping, the designer should allow for the definition of those runtime options supported (as listed below), such as palette configuration, overview support, etc. [H][M1][114197]
• Semantic Definition
  • Constraints [?]
    • Diagram and/or domain models may have constraints added which need to be manifested as feedback in the graphical editor. For example, a constraint indicating that circular relationships are not allowed should be indicated in the UI while attempting to make such a connection. [M][M+][114192]
    • Constraints may be defined in the diagram and/or domain models that are more appropriately checked in a batch mode, as is done with the EMF validation framework. GMF should allow for constraints to be enforced using this or similar framework. [M][M1][114189]
    • Provide support for the Object Constraint Language (OCL). [M][M+][114193]
  • Expressions
    • Diagram elements may not map directly to domain model elements, but rather be a derived value of some expression or query. For example, a hierarchical or flat view representation of a UML class as defined in "The UML Profile for Framework Architectures" requires information from an entire class hierarchy for representation on a diagram. [M][M+][114194]
  • Validation
    • Diagrams which may be well-formed may also need to be checked for certain best practices or style considerations. GMF will provide an extensible means by which to define audit and metric rules/constraints to be run on model instances. [M][M+][114196]
  • Multiple constraint/query/expression languages (e.g. XPath/XQuery, BSH, Groovy, Java, OCL, etc.) should supported through well-defined interfaces and/or extension points. [?] [L][M+][114190]
• Templates
  • A number of templates should be provided to jumpstart Graphical DSL development. [L][114195]
• Model synchronicity
  • In order to maintain synchronicity between linked models, refactoring-like support to span designer definition, mapping, and domain models should be provided. [H][M+][114198]
  • Lightweight transaction support will allow for consistent changes to multiple models. [H][M+][114188]

• Generation Model
  • Runtime Definition
    • A generator model should allow for the definition of those code generation options supported, such as package namespace, RCP option, etc. [H][M1][114191]
• Generation
  • Generation of code from model definition(s) should maximize plug-in extensibility. [H][M+][114201]
  • Generation option to target RCP application. [L][M+][114200]
  • Generation option to target an Eclipse view, in addition to editor. [H][M+][114202]
  • Utilize EMF.Edit commands (and others) to greatest extent possible. [H][M1][114204]
  • Undo/Redo functionality should be respected. [H][M1][114205]
  • Regeneration of code should not overwrite customizations. [H][M1][114203]
  • Unit tests for the plug-in should be optionally generated. [L][M+][114206]
  • Eclipse builders should be utilized as appropriate to generate incrementally. [L][M+][114209]
  • When working with domain models, the generation of EMF model, edit, and editor plug-ins should optionally accompany diagram plug-in generation. [L][M1][114208]
  • Method of generation should be flexible. [?]
    • Default JET option. [H][M1][114207]
    • Alternative template engine. [L][M+][114207]

• Editor
  • The runtime environment should support the following capabilities:
    • Palette
      • Palette customizer [L][M+][114217]
      • Sticky tool [M][M1][114220]
    • Properties [H][M1][114246]
    • Overview (bird's eye view) [H][M1][114213]
    • Zoom +/- [M][M1][114215]
    • Navigator [M][M+][114214]
    • Outline [H][M1][114211]
    • Decorators [M][M1][114212]
    • Keyboard bindings [L][M+][114216]
    • Direct editing [H][M1][114219]
      • Text validation/parser plug-in [H][M1][114219]
      • Marker support [H][M1][114226]
      • Content assist [L][M+][114235]
    • Drag and drop [H][M1][114224]
    • Layout [L][M1][114238]
      • A number of layout strategies may be appropriate for a particular diagram and the runtime framework should provide for this and for the addition of layout plug-ins to be added via extension point.
    • Alignment [L][M1][114236]
      • Align selected nodes to top, bottom, right, left, center. [M1][114236]
      • Set width, height of elements. [M1][114237]
    • Support standard graphical editor facilities (actions, rulers, guides) provided by GEF. [L][M1][114221]
    • Provide support for compartments/subcompartments. [M][M1][114228]
    • Feedback (in status line) for constraint violation, advice, etc. [M][M+]
    • Filter views [L][M+][114225]
      • Filter by element type, property, or regular expression. [M][M+][114225]
      • Hide/Show individual elements. [M][M1][114232]
• Persistence
  • Diagrams are stored in files using XML/XMI capability of EMF. [H][M1][114230]
    • Alternative persistence mechanisms should be made available via extension points. [L][M+][114233]
• Delete behavior (diagram, domain, both?) [L][M1][114231]
• Export
  • Printing [M][M1][114222]
  • Image [M][M1][114227]
    • Raster: jpeg, gif, bmp, etc.
    • Vector: emf, wmf, svg, eps, etc.
  • General transformation
    • Interchange
      • UML via Diagram Interchange Specification [L][M+][114229]
• Team integration [M][M+][114223]
  • Diagrams should provide team support extensions. [M][M+][114223]
  • Diagram updates based on domain model changes should be minimized. [M][M1][114239]
• The runtime should provide functionality for use with non-generated editors. [H][M1][114241]

• This application of GMF will provide a visual diagramming capability for the UML2 metamodel implementation in Eclipse. 

• To allow for visual domain model (DSL) creation using ECore as a metamodel, a GMF-generated diagram surface is planned.  This capability will serve as a reasonable first implementation for GMF and ease the development of EMF models.

• BPEL4WS has a defined XSD which can be imported to EMF.  There is no associated notation provided, while mappings exist from BPMN and BPDM.  One of these or a proprietary notation could be mapped to the XSD, possibly combining aspects of WSDL to provide a rich BPEL4WS modeling environment.

• Business rules have no standard notation, although many examples exist.  Furthermore, many rule engine models are possible for implementation in EMF, as one is shown here .

• EMF models are planned to be the primary source of mapped domain models for use in defining diagrams in GMF.  Furthermore, diagram definitions and mapping models are themselves to be based on EMF.
• Diagram persistence is to leverage EMF's XML/XMI mechanism, while alternative persistence may be desireable.  Persistence to a relational database is likely to be required, as found in MDR, and as possible using CDO.  SDO capabilities are already available in EMF.
• EMF currently has no facility for model constraint definition, using OCL for example.  This is a known limitation and a discussion item on the EMF newsgroup.  On this topic, the University of Kent has an EMF facility for their OCL library.
• EMF currently employs just the JET (Java Emitter Template) engine for code generation.  A goal of GMF is to provide a flexible means by which alternative template engines may be used.

• The GEF project will serve as the base of GMF's Runtime Framework and be the target for the generator.  It is likely that work done in GMF will be donated to the GEF project.

• The UML2 project represents one popular domain model requested for use in GMF.  This project will require the use of the Diagram Interchange Specification for diagram persistence, which is also under consideration as the general diagram definition model for GMF.

• The GMT project may provide the necessary means by which to transform models, should it be determined such capabilities are required for GMF.

• There has been interest expressed in the newsgroup in providing WYSIWYG capabilities in GMF using the VE project.
• The VE project team has expressed interest in working with GMF, as they have developed capabilities that are similar in function to what GMF requires, including a common diagram model.  This will require further investigation, and is planned.

• The ECF project already supports the shared editing of EMF/SDO models, which should potentially be leveraged as an option in GMF.

• The MDDi project aims to introduce dynamic aspects to EMF models, it can potentially be leveraged by GMF for required semantic descriptions.
• GMF is already referenced by the MDDi project as complementing its "methodological integration view" where generation of MDDi-specific elements could be provided by GMF.

• It is conceivable that the Mylar degree-of-interest (DOI) model can extend beyond the navigation views of a model and to the graphical (GEF-based) models as well. This will require further investigation.

In addition to interoperability with other Eclipse projects, a number of other interchange/integration possibilities exist for GMF, such as:

• A number of specifications are likely to be adhered with in GMF and its associated projects. The UML, OCL, DIS, etc. all provide an opportunity for GMF to promote OMG specifications.

• A potential to transform and leverage diagram and domain model definitions in both GMF and Microsoft's DSL Tools exist.