JeeWiz Architect's Guide - Patterns In Practice


	The Model-Driven System Builder

JeeWiz Architect's Guide

Contents > 9. Patterns

9.5 Patterns In Practice

9.5.1	Generation Automation
9.5.2	Pattern Addition and Modularity
9.5.3	JeeWiz Patterns Require Templates
9.5.4	Modelers Use Styles
9.5.5	MegaPatterns

9.5.1 Generation Automation

There are a number of differences between the way patterns are discussed in the software engineering literature and how they are used in JeeWiz.

Patterns in the literature are normally used to advise software architects on how to create architectures, and then to change a design (e.g. the UML model) so that more design features are created. The end result of using a pattern in this way is that the design is permanently changed. This approach has the drawbacks of using a wizard: it is often difficult and time-consuming to reverse the effects of using a design pattern.

In JeeWiz, our goal is automation of the development process, so patterns are applied automatically (by the presence of one of the *includeSpec.vm files, as we saw earlier in this chapter). Furthermore, we want to create the eventual software system, not change the original design. There is a very good reason for this: a different rendering of the system will need different architectural patterns. If we apply patterns at design time and change the model, it precludes automatic re-rendering to address new architectures. So in JeeWiz, architectural patterns operate at generate time, not at design time. Because patterns are applied automatically, as determined by the architect, the modeler can guide the way patterns start by various means (by the stereotypes in UML models, or elements tags used in an XML specification and the various properties the modeler can specify to guide the process), but once started, the process is determined by the architectural patterns.

Finally, the MDA literature talks about multi-stage processes where the specification (logical model, or PIM) is converted to a PSM (platform specific model) which can then be transformed again and so on. A modeler can change the PSM after each conversion. The final stage is to convert the PSM into the final textual products, like code and descriptors. Each conversion step in this process is called a 'transformation'; it is relevant to this discussion, because a transformation operates like a group of coordinated patterns. In JeeWiz, there is no separately accessible PSM: we go from a PIM to final textual products automatically. The final 'PSM' can be produced, but it is typically only used for debugging. This means that patterns and templates completely govern the conversion from the PSM to the final framework, ready for the application programmer to add the specialised business logic.

9.5.2 Pattern Addition and Modularity

What software engineers will think of as "patterns" typically become a *includeSpec.vm for a particular object.

These files occasionally implement patterns themselves. For example, as of this writing (which phrase we will now assume and omit!), the preIncludeSpec.vm for the BOM:entity implements the pattern 'ensure an entity has a primary key':

## If there are no keys or autokeys defined
## then we generate the default primary key here.
#if( $keys.size() == 0 )
         <this>
           <attribute    name="oid"
                            autokey="true"
                            type="Integer"
                            />
         </this>
   ### and we need to reset the key lists because this pattern has changed them
   $this.reset()
#end

This pattern adds the attribute 'oid' into the current model object.

While this is a typical usage of the preIncludeSpec.vm (i.e. slightly massage the definition of an object before other patterns fire), the includeSpec.vm file is normally used as a coordinator for components of the patterns. The includeSpec.vm does this by including other files: by convention these are given a 'inc' extension. For example, the component to create a factory class that manufactures proxies for business objects is called BOMFactory.inc.

This is part of the larger-scale patterns, represented by the includeSpec.vm for a business object:

<parent>
   #parse( "classImpl.inc" )
   #parse( "classProxy.inc" )
   #parse( "BOMInterface.inc" )
   #parse( "BOMFactory.inc" )
</parent>

In other words, for the business object, we will create

The implementation class.
The proxy class
The interface, to expose the business methods support by the business object
The factory class, which creates the proxies.

This grouping of pattern components gives more flexibility than using a single pattern:

The components can be reused in other patterns (by inclusion from other files)
You can create variants of the pattern by changing the .inc components

9.5.3 JeeWiz Patterns Require Templates

JeeWiz patterns leads to an increase in specification, which can be new objects, attributes on existing objects . This does not by itself create extra output: the additional specification objects and attributes must be rendered. Typically, a new object created by a pattern is 'a sort of class'; the templates will render this into a class (or interface) in the target language.

Other types of renderings can of course produce different representations and many output files, depending on what is in the build.xml for the type of object. In the same way that the 'includeSpec.vm' can coordinate multiple pattern components, the build.xml can coordinate many parts of the rendering. This may produce artifacts (e.g. deployment descriptors, second-stage build jobs) or binaries (e.g. jars).

Renderings are typically platform-specific: for Java platforms, Java language files are generated and built using Java tools.

9.5.4 Modelers Use Styles

We noted earlier that modelers cannot specify patterns directly: they are determined by the architect. The implication for the modeler is that he or she should not need to do anything special to trigger the patterns - either by specifying pattern names or by creating special-purpose objects to fire patterns. The modeler should just model (or specify) using the defined stereotypes, which will turn into model objects during the generation process, which will then automatically fire patterns.

However, in real-life the modeler may want to give hints to the build process for a particular object. He does this using the 'style' attribute, which is available on all objects. This can then give hints to the generation process; these hints are interpreted by patterns and templates as the objects are fired. For example, a 'property' modeled in UML could be mapped to an XML element (e.g. <property>value</property> ) or attribute (e.g. property="value").

Styles can be used to guide both patterns and templates.

9.5.5 MegaPatterns

Mega-patterns were introduced in the introduction as a 'big object' in one tier creates another 'big object', where a big object is loosely defined as firing a complex pattern using multiple pattern components (include files).

The current mega patterns are overviews in the following diagram and detailed below:

map-entity-to-dataView - maps entities to corresponding data-views
map-dataView-to-maintenance-session - creates a session to maintain the data-view, incorporating CRUD methods
generateMaintenancePages - generates the pages to go with the maintenance session's CRUD methods. This is an afterthought of map-dataView-to-maintenance-session.
'generatePagesForBusinessMethods' - generates the pages to invoke methods - probably just to get testing started.