Introduction

ModelPro is a facility for the MDA provisioning of arbitrary technical artifacts from EMF Models:

Using concise, readable, compact specifications.
Producing large quantities and varieties of technical artifacts.
Aligning with OMG model and relevant W3C specifications
Utilizing open source implementations of underlying technologies.

ModelPro exists within an Eclipse IDE environment. All provisioning is initiated from a model. Generated artifacts become resources within the workspace, and may be further processed by IDE tooling. A common ModelPro project will consist of one or more source models from which other projects are provisioned.

A. Provisioning

An overview of the MDA provisioning vision may be found at (MdaVisionForGov). Some highlights from that article:

· “The basic tenants of MDA are simple – to move the focus of systems development from software artifacts to high-level models. High level models are tuned to the problems being solved, resonating with domain experts. Provisioning processes are used to automate much of the process of producing the system in terms of technology artifacts, documentation and process support. These high-level models and provisioning processes are supported by open standards and COTS tooling. In MDA the heart of the system is models, not code.”

· Domain modeling and implementation will be largely independent of the infrastructure development and refinement. Both teams will be able to iterate on their own schedule, using the provisioning capability to build and validate revisions.

· In addition to producing implementation components, the same provisioning technology will be used to automate the production of test cases and documentation. Requirements, models, documents and the system are always synchronized, traceable and consistent.

· MDA Automated provisioning is based on models provided be both domain experts (with easy to use user interfaces) and systems engineers providing the technology and infrastructure specification. Automated MDA provisions most of the execution artifacts, test artifacts, documentation, integration specifications and runtime configuration policies and processes that produce and drive the system.

· The provisioning engine is the core technology that makes MDA work.

The overall provisioning process automates the generation of product from high level models. Within that provisioning process, ModelPro serves as the bridge between high level models and COTS tooling, as shown in Figure 1 Provisioning Process.

Figure 1Provisioning Process

ModelPro is neutral to both the source meta model (e.g., UML, BPMN, SCHEMA, WSDL, …) and to the set of possible target artifacts/products. The ModelPro target artifacts generally include all artifacts necessary to enable automated use of downstream tools and consequent generation of final products. The 3^rd party tools typically include IDE’s, with their tailored technology-specific plug-ins.

The set of 3^rd party tools may also include other MDA provisioning tools which are typically tuned for fine-grained, platform-specific models. In this case, the role of ModelPro would be to produce the required PSM models from the more abstract CIM/PIM models which normally characterize the source models used in conjunction with ModelPro.

1. Recommended Technical References

ModelPro is based upon many specifications and technologies. This document is oriented towards explaining the application of those specifications and technologies to the ModelPro provisioning environment. For a comprehensive understanding of those underlying specifications and technologies, it is recommended to consult the following on-line reference materials:

· apache ant.

· apache velocity.

· eclipse ganymede.

· MdaVisionForGov.

· Saxon.

· W3C XML Schema Definition Language (XSD) 1.1 Part 1: Structures.

· W3C XML Schema Definition Language (XSD) 1.1 Part 2: Datatypes.

· XML Path Language (XPath) 2.0.

· XQuery 1.0 and XPath 2.0 Data Model (XDM).

· XQuery 1.0 and XPath 2.0 Functions and Operators.

· XSL Transformations (XSLT) Version 2.0.

B. ModelPro

The ModelPro provisioning engine is driven by two forms of specification, as illustrated in Figure 2 ModelPro:

· The selection of a model element which is to provide the context for artifact generation. This is called the Binding Specifiction.

· A Template which specifies the content of the artifact, given the selected model element context.

Figure 2ModelPro

The artifact evaluation context is defined with a Model-to-Template Binding Specification. The Binding Specification defines how to navigate the model in order to select a model element which serves as the evaluation context for a Template.

A Template defines how to populate a textual target artifact, based on the provided evaluation context. A Template looks like the target textual target artifact, with the addition of textual substitution variables. The value of substitution variables are obtained directly from the model or may be massaged using macros. The Template also specifies the target location for storage of the generated artifact.

Binding Specification

A Binding Specification defines context selection in 3 stages, as illustrated in Figure 3 ModelPro Context Hierarchy:

o Provisioning context

o Project context

o Artifact context

Figure 3ModelPro Contxt Hierarchy

The navigation expressions used for selection enable access to not only the primary model resource, but also to all model resources which are referenced by the primary model (transitively). These model resources constitute the model resource set. In Figure 3 ModelPro Context Hierarchy, the model resource set is depicted as the “Model Root”. Thus, context selection includes access to all relevant model elements, no matter how the model has been packaged.

The navigation expressions, in general, select a collection of model elements. Each model element within the collection is a context instance used for subsequent selection evaluation. Thus, for example, there may be multiple Provisioning Context instances for a given Provisioning Context selection, each of which may have multiple Project Context instances, each of which may have multiple Artifact Context instances, each of which may have multiple Template instances.

1. Provisioning Context

The Provisioning Context is generally defined as the navigation from the Model Root to a model element which represents a target technical architecture. This definition is somewhat arbitrary, since there is no inherent requirement that a model defines a particular target technical architecture. When an abstract model has no target technology specification, the Provisioning Context may be the same as the model root. An example of a UML model which has target technical architecture definitions (via stereotypes) is illustrated in Figure 4 Model With Explicit Provisioning Context. For this model, each Node with a <<Provision>> stereotype was chosen to be a Provisioning Context.

Figure 4Model With Explicit Provisioning Context

2. Project Context

The Project Context is defined as the navigation from a Provisioning Context to a model element which represents a “project” A project is notionally the same as a project in an IDE such as Eclipse. Associated with a Project Context are:

· A Template “folder” which contains Templates associated with the project kind.

o Each Template within the folder is associated with a named Artifact Context.

o The Artifact Context name of each Template identifies a specific Artifact Context selection expression.

o The Artifact Context selection expression is evaluated in the context of the current Project Context.

o The Artifact Context selection expression defines the collection of model elements used for evaluation of the Template (one evaluation per model element instance).

· A project target folder location which is the root folder for all artifacts generated from Templates within the project kind’s Template folder.

o The location is specified using an expression based on the current Project Context.

o All artifact locations specified by Templates are relative to the project target folder.

Although ModelPro is executed in an eclipse environment, the target environment may include a different IDE (such as NetBeans) or even a non-IDE (such as ant-based build).

In any case, the packaging of artifacts into specific projects is largely dictated by the capabilities of those 3^rd party tools. For eclipse, project organization may be based on the characteristics associated with project natures, such as web service, ejb, ear, java, plug-in, etc.

3. Artifact Context

The Artifact Context is defined as the navigation from a Project Context to a model element.

· The Artifact Context expression is named.

Since the primary function of Artifact Context selection is to select a model element, there may be many Templates which use the same Artifact Context selection to establish initial context. For example, target artifact kinds as divergent as java and WSDL may conceivably use the same named Artifact Context selection.

Template

A Template specifies:

· A project kind, by virtue of being in a project kind folder.

· A named Artifact Context. This associates a Template with a specific Artifact Context selection expression.

· Project path: a file path to the file, relative to the current Project Context target folder. This is the location where the generated artifact is materialized. The project path is specified as an expression based on the current Artifact Context.

· Artifact Content: per the Template evaluation rules, as evaluated in the current Artifact Context.

Each Template will generate one target artifact for each valid selection path combination of provision context/Project Context/Artifact Context (within a common project kind folder).

A Template is often associated with a kind of artifact, such as java, wsdl, xsd, etc. In a provisioning environment in which the target artifacts are all java, it is conceivable that a single Template would suffice to specify the generation of 100’s of java files in satisfaction with the provisioning objective.

Other target environments may have many different kinds of artifacts, such as SOA environments with mixes of java, wsdl, xslt, xsd, xml, deployment descriptors, vendor specific files, ide project/nature files, classpaths, manifests, etc. For these target environments, each kind of artifact would be associated with one (or more) templates.

Launch

ModelPro is executed within an eclipse environment via an ant script. The ant script executes a Model Pro ant task to invoke the underlying plug-in based ModelPro implementation. Any additional requirements for the provisioning process, such as invocation of down-stream 3^rd party tools, may be implemented either as additions to the ant script or by suitably configuring the eclipse project build sequence via provisioned artifacts.

The ModelPro launch mechanisms may be employed in a number of scenarios: implicit user actions, off-line headless builds, explicit ant script invocations. More information on launch is contained in a subsequent chapter.

C. Prototypical ModelPro Workspace

An eclipse ModelPro workspace for a user may be initially structured as follows:

· •My Eclipse Source Project

o model (directory)

§ source models …

Provisioning actions available via ModelPro or a ModelPro Cartridge plug-in may be performed directly on a source model. Following the provisioning invocation, the workspace may appear as:

· •My Eclipse Source Project

o model (directory)

§ source models …

· Provisioned Target Project

…

For a ModelPro provisioning developer, the source project may be extended to include elements of the provisioning specification. In this scenario, the workspace may be organized as follows:

· •My Eclipse Source Project

o model (directory)

§ source models …

o transform (directory)

§ binding (directory)

· Template.xml (Binding Specification)

§ velocity (directory)

· [project kind] (directory)

o velocity Templates…

o build.xml (ant script for execution)

o build.properties (source/target/transform locations; options)

· Provisioned Target Project

…

This structure assumes that all source artifacts as well as target artifacts are to be located in a single project. Most of the items in the above list may in fact be distributed across multiple projects.

The elements which need to be defined to implement a new provisioning scenario are:

· Binding Specification

· Templates

· Launch

1. Models

Source models are provided by the user, outside the scope of ModelPro. The models must be EMF models and the corresponding (meta-) model plug-ins need to exist on the eclipse platform. Documentation for the (meta-) models is normally provided by the eclipse organization in conjunction with underlying standards from organizations such as OMG.

In cases where models are not natively in EMF format, ModelPro and/or tool providers may provide transformations from a native format to EMF format (such as Magic Draw to EMF/UML).

2. Generated artifacts

As a result of a provisioning execution, the artifacts are typically generated into a workspace-like structure, with sibling projects allocated as per the Project Context specifications. Once generated:

· The artifacts are normally processed with 3^rd party tools to ultimately provision final products.

· Additional processing of artifacts is normally outside the scope of ModelPro, unless the provisioned artifacts are models or Templates intended for bootstrapping downstream ModelPro provisioning machinery.

3. Binding Specification

A single xml file which defines the model context selection and binding to Templates.

· Navigation expressions use XPATH syntax.

· The Binding Specification allows some XSLT constructs.

The Binding Specification and associated X* concepts are defined in more detail in a subsequent chapter.

4. Templates

· The underlying technology is Apache Velocity.

· Conventions are used for specifying location and Artifact Context name within a Template.

· Templates are grouped by project kind. The project kind is the name of the folder for a set of Templates.

· All project kind folders are contained by a top-level template folder

Clarification of Template conventions and the initial evaluation context are provided in a subsequent chapter.

5. Launch

ModelPro provisioning is executed using an ant task within an ant build script. Explanation of the ModelPro ant task is provided in a subsequent chapter.

D. Undocumented Features

While the orientation of this technical reference document is for MDA provisioning applications, the ModelPro plug-in has additional (undocumented) technical features. These include:

· Model XPATH: programmatic access to XPATH for EMF models.

· Model XSLT: XSLT for EMF models.

· Model XQUERY: XQUERY for EMF Models.

· RDF XPATH: programmatic access to XPATH for RDF.

· RDF XSLT: XSLT for RDF.

· RDF XQUERY: XQUERY for RDF.

E. Getting Started

The easiest path to productive use of ModelPro is to begin with an example, then adapt that example for the target requirement. For a provisioning specification developer, start with a working specification example (such as an already developed plug-in cartridge) and adapt as required for the target provisioning scenario. The following user assistance capabilities will facilitate this process:

o Examples. Examples include representative source model projects as well as provisioning development projects.

o Cheat Sheets. Cheat sheets help guide the first-time user through the process of provisioning. This is particularly useful when a target technical architecture utilizes 3^rd party tooling.

[i]