Design Pattern Toolkit

Overview

Requirements

Download

FAQs

Forum

Reviews

Update: April 24, 2007

What is the Design Pattern Toolkit?

Design Pattern Toolkit has been re-engineered and republished as the open-source Eclipse Modeling Framework Technology (EMFT) JET Eclipse project. EMFT JET, in turn, is available as part of Rational® Application Developer 7 and Rational Software Architect 7. Design Pattern Toolkit will continue to be available on alphaWorks for the benefit of those who are unable to migrate to EMFT JET.

This version of Design Pattern Toolkit contains two patterns that help migrate other Design Pattern Toolkit patterns to EMFT JET. One pattern takes a Design Pattern Toolkit pattern as input and puts out a new EMFT JET transform that performs the same transformation as the original Design Pattern Toolkit pattern. The second pattern modifies Design Pattern Toolkit projects so that they can be run either as Design Pattern Toolkit patterns or as EMFT JET transforms.

This tool runs on Windows® and Linux®.

How does it work?

The model is an implicit XML schema that describes the information that is unique to the application being generated (such as property names used in a J2EE application's Java™ beans, HTML input forms, and HttpRequest parameters). While each application has its own unique application definition (appdef), the appdefs for a class of applications all adhere to the schema that exactly describes what information is required in order to build an instance of that class of applications. An important feature of this toolkit is that the model's "schema" definition is completely under the control of the transformation developer, so that he can both minimize the information that users must put in in order to use the transformation and ensure that it is captured in a way most natural to the target developers. This control allows each development community to develop its own streamlined method for gathering requirements and developing the associated applications.

The view is a collection of templates that contain the static common content of the Eclipse resources to be generated. Embedded in each template are template tags that direct the generation and insert data from the appdef into the generated output. There is no limit to the kind of resources that can be generated, and it is possible to decompose a template into multiple parts that are composed during the generation process. This unique feature makes it possible to develop separate "subtemplates" associated with different aspects of the target application. For example, generation of parameters for methods (in both their declaration and their usage in code) follows a similar transformation and is repeated throughout many different templates. With this toolkit, it is possible for the transformation developer to create a substructure in the model that drives method declarations and calling sequences as separate templates that are included in the appropriate places in the overall resource template.

The controller is specified in a separate component through a set of special XML tags that control when and how each transformation template is applied. These tags can be embedded in a template file as well, enabling detailed control over the generated artifacts (even down to the delimiters that are generated between text strings). The controller also has tags that allow data from multiple appdef files to be merged, enabling users of the transformation to "separate the concerns" and get a high degree of reuse of their input data. For example, the transformation developer can build a transformation that separates the basic flow of the architecture from the naming conventions used in a particular organization. The specific requirements for the application will change from project to project, while the naming conventions may change only from organization to organization.

Users of a transformation provide an application definition that conforms to the transformation's model(s) and apply the transformation to generate an end-to-end application consisting of a number of Eclipse resources across multiple Eclipse projects. The model is usually implemented as an XML file, but it can take other formats (such as Java source). Once the generation is complete, the appropriate building and validation actions are performed automatically. Depending on the transformation, it may be necessary to manually edit some of the generated resources in order to get a running application. Because of the possibility for manual edits, the toolkit supports "round tripping", where sections of the artifacts can be marked such that they are not changed during the generation process.