Identify the context, examine the recurring problem, and find a recurring exemplar solution. A solution to a more complicated problem may involve multiple patterns. Analyze the target domain to get a clear definition of inputs, outputs (what you are trying to produce), and points of variability (what input should be left to the user and what should the pattern provide). Patterns describe things that have been done before, so gather real examples of the deliverables you want to produce and the best practices.
Determine the best solution to the problem and a natural and realistic entry point for design. Figure out what information is available at the start and what is needed at each stage. Create an outline of what will happen in each stage.
At this point you have a set of design activities defined and know the information content at the entry point and exit points. For each pattern there is a pattern implementation, a type of micro-tool, that can be created to drive individual pattern applications. An invocation environment needs to be established to provide mechanisms that will configure, trigger, and execute applications of the pattern. A key decision point to the pattern implementation is determining whether output will be presented as a model or as text.
Once the pattern implementation is developed, results need to be packaged for distribution, along with documentation suitable for the intended user community. The use of the Reusable Asset Specification (RAS) should be considered in conjunction with the use of a RAS repository.
The choice of technology for a pattern implementation is dependent on the characteristics of the inputs and outputs. The goal is to produce a set of solution artifacts (Java source files, XML files, etc.), using an input model (UML model, XML schema instance, etc.) to guide the customization of the generated artifacts. This goal is often approached incrementally with successive "apply pattern" steps producing intermediate models that are closer to the final solution.
Patterns are by nature technology independent, so there is no restriction on the technologies that could be used to implement a pattern. The vision is to build micro-tools that can be:
Reused across communities
Distributed as reusable assets and hosted in repositories
Easily integrated into the overall development environment and will work well with other tools
A number of meta-tooling technologies are available to suit different requirements.
Rational Software Architect and Rational Software Modeler (RSx) build on an Eclipse base to provide a rich environment for more specialized pattern-based micro-tool development. Rational Software Architect provides built-in frameworks that bring automation to design and construction.
Rational Software Architect Patterns Framework: Author patterns by easily defining the pattern, the pattern parameters, and implementing the code. Applying patterns in a single model and within the same level of abstraction is easy and done visually through drag, drop, and binding pattern arguments. Rational Software Architect also provides the Pattern Explorer View, which allows you to connect to other pattern repositories to import additional patterns.
Rational Software Architect Transform Framework: Author your own transform. Transforms differ from patterns in that transforms are applied across metamodels, models, and different levels of abstractions and transform into other artifacts (code, script, other models). Rational Software Architect includes transforms for you to extend (UML to Java, UML to EJB, Java to UML).
Pluglets, modeling framework, RAS framework
Find out more about software development tools from Rational.
Inputs are typically treated as models. In cases where a text file without a corresponding model must be used as an input, it will need to be parsed first and placed into an appropriate model. The key decision point is determining what artifacts or outputs the pattern implementation will generate.
Model: Modifies the input model or generates a new model from the input model
Text: Generates artifacts such as code, scripts, descriptors, data files from the input model
Use RSx patterns with simple, interactive, drag-and-drop, graphical interface for your pattern if in-place pattern expansion, where the problem and solution domains are the same UML model. Used to add details to a model.
Use RSx transformations if input parameters can't be represented in the RSx Patterns framework or if performing other model-to-model patterns across models or metamodels. RSx transformations can create more detailed software artifacts from more abstract artifacts in a standard way (including UML to UML, UML to Java, UML to EJB).
If graphical modeling capability is required, add Graphical Modeling Framework (GMF)/Eclipse Modeling Framework (EMF). Graphical model editing is more complex than a text-based approach and benefits from the productivity features available in RSx.
RSx transformations support Model2Text but is not recommended due to complexity and doesn't facilitate reuse. Use RSx with JET1 when DPTK is not acceptable.
By default, artifacts should be treated as text (rather than models) and generated/manipulated with JET2.
If your input model is already in text form, or in form of an EMF model already close to that required by the transform, choose JET2.
If the input model is UML or an EMF model with significant content not required by the transform, then develop an RSx transform to extract the appropriate information from the input model into an intermediate text or EMF model which directly matches the transform requirements, and use JET2.
An important aspect of patterns development is a standard way to organize, describe, and package assets. The Reusable Asset Specification (RAS), adopted as an OMG standard in 2004, defines a standard way to describe and package reusable software assets. A reusable asset provides a solution to a problem for a given context and can have variability points that can be customized by the asset consumer.
