Tigerstripe Template Design

Phases

• The implementation will be delivered in phases:
  • Phase I for the Alize Release
  • Phase II for the Bora Release

Phase I

• Template-based wizards with only 1 single page (no look-ahead into the series of actions for the template)
• No UI editor for templates. We will rely on an XML file that will be registered through an Extension Point, which will fix the use of templates in the UI
• Built-in types to be created thru built-in templates (ie. use the same mechanism throughout)

Phase II

• UI for Template creation (i.e. not editing XML file)
• Ability for users to register/define their own templates unless the Ext. pt (above) is used

High Level Design Notes

• A TemplateFactory to be driven by the content of an XML file, either stored in the Tigerstripe install of the user or registered through an Ext. pt.
• "ArtifactTemplates" will apply to an "Artifact" as the top level element (i.e. no "attribute template" by itself, only artifact templates that may contain attributes to be created)
  • "PatternTemplates" may be considered in the future as a composition of ArtifactTemplates
• ArtifactTemplates have a "plop" method that will lead to a set of "ArtifactRequests" to be passed down to the Artifact Manager.
  • In the case when the Template is used from a Class diagram, the plop(..) method call would only lead to creating the artifact in the model, but wouldn't include it on the diagram. So it should be followed by a "DnD" operation of the newly created artifact on the diagram.
• Artifact Templates are made of
  • a top level Artifact Creation Request
  • and a set of "other" Requests (set, etc...)
  • Template should allow to create Annotations instances as part of them
• There are 2 types of Artifact templates:
  • Node Templates (required a name and a package name). (AssociationClasses should be considered a Relationship template as the association ends are required to create it).
  • Relationship Templates (requires all that Node templates require + 2 end types)
• Custom Auditors will be used to determine the "validity" of the created items, rather than trying to enforce additional controls in the creation phase

UI Aspects

• Through the Extension Point, it should be possible to disable the "built-in" (standard) templates.
• All templates held in the TemplateFactory should be visible from
  • The tigerstripe menu (Node & Relationship). We need to consider what the "top level" or default menu button looks like.
  • a right-click on the Pacakge Explorer (new->...) (Node & Relationship)
  • as a creation Tool on the Class Diagram Palette (Node)
  • after a drag operation between valid node types (Relationship)
• All templates will need to identify an icon and label for the UI usage.
• All wizards should be replaced by a single generic wizard that would be driven by the content of a template
  • If information is required to be captured, then the wizard will be used. (When accessed via a Diagram, Wizard should be minimal)
  • only the necessary info for the initial creation request should be presented by the wizard
  • default names should be provided in the Wizard (as in the class diagram).