The Model-Driven System Builder
JeeWiz Architect's Guide
1.4 Goals and Features
This section is intended for experienced architects and evaluators of system generation tools.
If you are just interested in getting started, you can skip this section.
Architects create or modify model-driven system transformations using the JeeWiz engine features.
The key goal of the JeeWiz engine is to provide tools to quickly automate the vast majority of the software development processes.
The way this works is that a model is transformed into a runnable system,
in the process incorporating specific pieces of specialised business logic.
This requires features in the following broad areas:
The JeeWiz engine support the following goals:
- meta-modeling - to define a range of related technology and business concepts
- model conversion - to import and create models in different formats
- artifact creation - to generate the code, configuration, build jobs and any other artifacts used in the development process
- build coordination - to orchestrate the various processors (such as compilers) to automatically construct the final products of the development process.
- transformations must be re-usable. Transformations can be complex and costly.
To be economically viable, they must be reusable.
JeeWiz makes it possible to support a range of changes to standard transformations,
from the trivial - like changing naming conventions - to the more significant,
where internal technology layers (e.g. the persistence mechanism) are replaced as a module
- it must be possible to automate patterns of arbitrary complexity -
to the point of eliminating manual application programming if there is no specific businss logic
- it should be universal, in the sense that any design information expressed in XML should be usable as an input,
and any type of output should be easily created.
- it should use existing development tools as far as possible, rather than require a completely new development platform.
For this reason, the basic tool component of the JeeWiz engine are XML, Java, Ant and Velocity.
Note that these are features at the JeeWiz engine level. The J2EE generation systems have their own set of features.
1.4.2 JeeWiz Engine Features|
The following diagram summarises the JeeWiz engine features, as explained below. The arrows on the diagram are informal -
they indicate dependency of various forms.
220.127.116.11 XML Models and Meta-Models|
The basis for JeeWiz modeling and meta-modeling is the simplest possible form of XML
In other words, JeeWiz uses XML models
and XML meta-models
Other formats, or more complex XML formats such as Web Service definitions or UML/XMI, are converted into the simple XML form by additional transforms.
This approach means that
- Standard XML tools can also be used to generate, validate and transform JeeWiz models and meta-models
- XML data, models and meta-models can all be processed by the JeeWiz engine.
(In fact, JeeWiz meta-models are simply a form of JeeWiz model: they are read and processed the same way.)
This means that
- there is only one set of concepts to learn
- all the power of JeeWiz can also be applied to data transforms as well as system generation
- it is easy to generate additional models in patterns - most developers now understand the structure of XML.
In some situations, subsidiary models are required in addition to the main model.
For example, the meta-modeling system reads in all the ancestor meta-models to be able to validate base meta-classes.
JeeWiz provides a general-purpose, recursive mechanism to read in multiple models - even a tree of subsidiary models -
and make them available during rendering.
JeeWiz models and meta-models can also incorporate Java implementation code.
This is incorporated into the Java meta-classes, which are created at generate-time by deserialising the input XML model or meta-model.
This means that Java/XML programmers can be easily trained to create meta-models.
At the meta-model level, Java is used to create
- Bespoke queries and views (standard queries and views are created by the meta-model generator)
- Model constraints (validation expressions)
- Property defaults
- Helper functions that aid the writing of generation scripts.
18.104.22.168 Meta-model Inheritance|
JeeWiz allows model objects to be grouped into meta-models and then use model objects from different meta-models during generation.
The JeeWiz structure can support arbitrary levels of meta-models, so this is a flexible, universal and structured approach to creating rich models.
JeeWiz provides features to
- inherit across meta-models (meta-model inheritance)
- plug meta-models together at generate time in various configurations depending on the target system to be generated (pluggable meta-models)
The benefit of this approach is that
- complex domains can be broken down into smaller modules (the individual meta-models), making the whole more manageable
- we can build up higher-level concepts by adding more meta-models -
this allows JeeWiz to address a range of language, platform, technology and business concepts with the same structure.
To see what we mean by this last point, let us look at the key concepts in the stack of meta-models used
to build the standard J2EE application rendering:
||Class, Interface, Method
||Business Object, Entity, Session, Relation, Data-view (a view/transform of inbound or persisted data).
||Page, Wizard-Page, Event
At the level of screen meta-model, pages, wizard-pages and events are high-level concepts:
they generate the program code to define and control lower objects - data-views, sessions, classes etc.
High-level concepts are more powerful and easier to use for modelers,
so this feature means that JeeWiz can incrementally build more and more powerful generation systems.
The ability to plug different stacks of meta-models together for different generations means that the
same model can be used with different meta-model configurations (specification polymorphism
This is how we can build different technologies into enterprise Java systems from the same model -
we plug together different meta-models with their attached renderings.
JeeWiz 'renders' the input model into various outputs using the features described below.
The rendering covers artifact creation and build coordination - both are necessary for automatic system generation.
Text artifacts are generated using the Velocity
Velocity uses a'boiler-plate' approach,
which means that artifacts are generated from a template text file using the structure of the target file
with property values from the models inserted by substitutions.
Velocity has general-purpose logic control structures (if, else, foreach, macros) to further process the model.
The ability to express general-purpose logic here is crucial to the whole meta-programming process:
it is how the meta-programmer quickly encodes the actions that normally a programmer would do manually.
Another benefit of Velocity is its easy access to Java classes. All the functionality of Java
is available to the programmer.
One alternative approach to generation might be to use a more general language like
However, using Velocity's boiler-plate approach makes renderings easier to understand for specialists and non-specialists alike.
This is particularly relevant for XML generation, which is difficult to produce using other approaches.
To make it easier to build complex systems, JeeWiz has made a number of additions to the Velocity language.
The most important of these are Controls and Methods, described below. In addition:
- There are over 200 helper methods,
broadly assisting with access to the model objects,
control of the Velocity process,
string processing and
other specialised processors that are better expressed in Java.
- The ExtraHelperMethods class,
which can be used to add additional Java helper methods locally.
- The #divert() and #revert() directives which allow the current output stream to be diverted to a variable
and then to revert back to the original output stream.
- More legible scripts by allowing additional tabs to
lay out scripts by
discarding leading tabs.
- The ability to use multiple trees of objects as the overall context,
by reading additional specifications.
JeeWiz uses Ant
as its native build facility.
This controls both text artifact generation and also processors like compilers and Jar to create binary targets.
JeeWiz integrates Ant's variable accesses so that values in the model or created by Velocity scripts can also be used.
Large-scale build facilities are also provided by JeeWiz, by running a 'manufacturing assembly' process,
driven by the input model. This allows subcomponents to be assembled into components automatically.
22.214.171.124 Rendering Inheritance|
The facilities that support meta-model inheritance are also used with all the rendering features described above, giving rendering inheritance
This means that parts of the rendering can be overridden to create variants, giving us rendering polymorphism. This is used for example to
- Adapt naming conventions to local conditions by adding a 'customer' rendering layer
- Change the generated language from Java to another language
- Insert a different persistence mechanism, such as changing J2EE's persistence from the default EJB to JDO.
- Add specialised processing to the Ant build for a particular meta-class to support local requirements.
Because meta-models and their associated renderings can be developed and used as a unit,
they need only be developed once.
This is important to the economic viability of the system generation approach.
High-cost or complex meta-models and renderings can be created once, as a capital investment;
per-project or per-company changes will be significantly smaller and cheaper to implement.
Some MDA-style tools have the concept of 'cartridges',
which are a compination of the models objects (compiled coded for the meta-model) with the rendering for the meta-classes.
JeeWiz takes a more "object-oriented" approach by
- separating the meta-classes from the rendering. This allows to
(a) reuse meta-models in different stacks
(b) plug in equivalent meta-models, but with different behaviour
- allowing much finer-grained overriding of rendering without altering or repackaging the original rendering.
This makes it easier to take upgrades of lower-level meta-models or their renderings.
126.96.36.199 Name Management|
A very common requirement is to generate systems using local naming conventions, and conventions for file names and directory structures.
JeeWiz has a special name management
facility to support this, so that all generated names and directory structures can be adapted in minutes.
The same technique also applies to the layout of generated source code,
so that the generated code can be created in the structure most natural to the current user.
The standard renderings provided by JeeWiz use these features to lay out code and other artifacts to look natural.
JeeWiz provides a simple but very powerful pattern facility.
In JeeWiz, we use 'pattern' to mean a form of rendering that produces not output files,
but rather more model information (i.e. more detail in the specification).
This is done by using all the rendering features described here to create XML for the new model fragment.
This approach means there is only one meta-programming environment to learn.
- can be arbitrarily complex by incorporating logic in Velocity
- are recursive - an object created from a pattern can trigger further patterns
- override in exactly the same way as other aspects of rendering described above
- can generate code as part of the methods or classes it creates
- are all resolved in a single build, automatically -
this avoids the cost and risk of manual intervention (as in the 'manually-changed PSM' approach of pure MDA),
and ensures that the architect's intentions are not subverted
- can be decomposed into pipelines for complex patterns,
and can also have included files to make it easier to override individual parts of a pattern.
The combined result of these features is that JeeWiz patterns can create very complicated, multi-tier systems
from simple and incomplete models: the complexity and completeness is added by patterns.
An important aspect of patterns is that the generated objects can change their meaning (via specification polymorphism)
depending on the configuration of meta-models used in the build:
a 'page' created by a pattern will mean different things,
and have a different generate-time Java meta-class, between a J2EE and a .NET build.
Similarly, a single pattern that generates a simple class, like a value object or delegate,
will create classes in Java or another language depending on the build configuration
In other words, a pattern writer uses declarative meta-programming:
he declares his intention in a few lines of code via a generic object,
which is then specialised by the particular meta-model configuration and may render into many files and other objects,
as dictated by the requirements of the target system.
There is no restriction on the type of XML that can be used or the complexity of the patterns generating it.
This allows JeeWiz patterns to express the domain knowledge, which used to have to be inserted by hand - modeling or programming .
In consequence, JeeWiz can build complex multi-tier systems in one automatically-run step.
188.8.131.52 JeeWiz 'Controls'|
In describing Velocity, we mentioned that text substitutions and business logic control could come from the models (either main or subsidiary).
However, there is another dimension to this:
often, substitutions are driven by the configuration rather than the model.
For example, the configuration may request a certain language or database and this needs to be reflected in the rendering.
JeeWiz 'controls' are provided to do this.
They allow the meta-programmer to create Velocity scripts that are completely independent of the particular details of the target configuration.
This applies to
- the target language - there is a standard controls for Java
- the logging environment - a console output logging control is standard, but log4j and bespoke logging controls are easy to implement
- logical datatypes - the datatype controls handle the mapping of a modeled type (a logical type) to a real type
(e.g. the 'int' logical datatype can turn into 'int/Integer' in Java) and the
properties of the datatype. A set of controls for Java is provided as standard
- user interface controls, which map language types to a representation on a user interface -
as one or more UI controls in the target user interface technology - plus the logic to map information between the two forms.
For example, there are two types date control: one displays a text box for a DD/MM/YYYY format; the other displays discrete controls for the day, month and year.
The choice between these, and whether they interface to .NET or Struts, is determined by the configuration, not the meta-program
- database controls, which map language types (e.g. Date) to the database representation (e.g. long).
As well as taking much of the detail out of the meta-programs, JeeWiz controls also
- future-proof meta-programs:
they can be used in environments or languages not envisioned when the meta-programs were written
- make it easy to create minor variations for local needs, such as storing booleans data as '1' or '0' characters on the database.
184.108.40.206 Velocity Methods|
JeeWiz has enhanced Velocity syntax in a number of ways, the most important being the addition of methods
Methods can be defined on JeeWiz model objects or controls:
this means that controls are also fundamentally object-oriented.
Methods take part in 'Rendering Inheritance' described above.
A given object gets its complete complement of methods by aggregating across the various layers of technology in a system,
and also across the various object types. Methods can be overridden and new methods created as layers are added.
This feature makes it easier to plug together different layers of generation technology.
Velocity methods complement the available Java methods: Velocity methods are tried first, and then Java methods are tried.
This means that a programmer can code methods where it is easiest - in Java as part of a meta-model,
or in Velocity.
Methods can also operate as normal language methods - just returning a value - or as Velocity script, sending text to the target file.
JeeWiz is different - to our knowledge - from any other programming tool available today
because it is focussed on automating as much of possible of the overall development process.
In areas where high-level patterns can be recognised and captured in transformations,
JeeWiz can automate over 95% of the development task.
1.4.3 Comparison to Other Generation Systems|
Put another way, JeeWiz is a tool for building software factories.
Software factories require, on the technical side,
highly skilled architects to design the range of products that can be produced and
meta-programmers to define the processes to generate them,
and, on the business side, analysts to specify the company's requirements
that drive the construction process and the detail work - application logic - where it is not economic to build automatic solutions.
This is a different cost model to creating code, configuration and build scripts by hand.
While there are still 'manual' tasks in the JeeWiz approach,
these are much reduced in size from the manual development approach.
The technical side of a JeeWiz development - the meta-programming - is more complex than manual programming,
its overall cost is reduced by re-use:
JeeWiz has specific features to make it possible to quickly adapt an existing 'software factory' to a company's local environment.
Notice that the above description did not discuss any particular technology.
This is because JeeWiz is a universal engine: it can be used across multiple languages, implementation platforms and environments.
Furthermore, we have found JeeWiz to be equally useful in complex XML data transforms (as a sort of 'XSL-T on steroids')
and describing systems that do not use object-oriented underpinnings -
such as XML Schema and WSDL.
The following subsections show how JeeWiz compares to other generation approaches.
220.127.116.11 Simple Generation Systems|
A simple generation system is the first-step approach to advanced 'code generation':
take a 'model' and feed that through a template-driven processor.
For example, some systems propose XML as the model, XSL-T for the templates and an XSL-T engine as the template-driven processor.
For particular areas, simple generation systems offer a data-driven way of creating additional parts of a system.
If the data can to drive the generation can be largely deduced from other artifacts (e.g. from JavaDocs),
then the generation system can produce additional artifacts at minimal cost.
The disadvantage of simple generation systems is that they don't go very far -
it is difficult to achieve high levels of automation.
- representing patterns (design-level transforms) is not possible,
- re-use of templates is difficult or impossible, so variation of a template is done by copying
- the coordination of the build process is done by an external engine, which does not coordinate with the generation process.
The result is a very fragile system: even minor changes become very costly and error-prone.
18.104.22.168 'Pure' Model-Driven Architecture (MDA)|
MDA is the Object Management Group's (OMG's) vision of a higher-level approach to building systems
that makes design models a central part of the development and maintenance process.
This is in contrast to the typical attitude of software engineers:
"We use models to communicate with the business ... and then forget them when real development starts."
However, 'pure' MDA - the set of OMG standards for describing design transformations - has a narrower goal:
transforming designs from a more abstract ('Platform Independent') model to a more concrete ('Platform Specific') model.
This is a necessary first step in automating some of the design process.
Currently there are some issues with this process:
- XMI is not practical as an interchange standard - there are too many variations;
- the insistence on UML (or another MOF-based language) as the design language;
- the delay in defining the standards covering the generation process, which is where the real value is added.
The target of JeeWiz is wider: generating almost all the development artifacts - not just the detailed design - from the model.
This includes mechanisms for specifying patterns that generate large quantities of code, creating configuration and build scripts, and controlling large complicated builds automatically.
The point is that these mechanisms and the MDA model-model transformations can be implemented by the same tool features.
As we will see later, this allows us to build arbitrarily high-level models with controlled mappings to lower level models or artifacts,
that can be easily customised for local architectures and standards.
22.214.171.124 Domain-Specific Languages (DSLs)|
DSLs create higher-level programming 'languages', typically using visual construction paradigms.
These languages are used to create models which will typically have a textual representation in, or a trivial generation to, XML.
The idea that this can be mapped down to lower-level implementation languages by templates.
DSL-based tools provide the visual construction paradigm and means of creating a range of 'languages'.
In the UML world, UML is a base modeling language, which can be specialised by creating domain- or platform-specific profiles.
In most cases, the template facilities are restricted to simple generation systems, as described above.
JeeWiz and DSL-based tools are complementary; a DSL-based tool provides the user interface portion;
JeeWiz can provide a more sophisticated back-end.
The interface between the two is the textual representation of the model.
JeeWiz uses XML dialects for its models that are isomorphic to the XML specifications from DSL tools;
in other words, a JeeWiz model can be automatically transformed to a DSL specification, or vice versa.
JeeWiz can add features to
- the ability to construct DSL 'languages' from a more general-purpose (and powerful) meta-model
- a more powerful generation environment for the code-generation aspect
- the integration of the code generation with the other aspects of the build - configuration and build generation, build staging etc.
Copyright (c) 2001-2008 New Technology/enterprise Ltd.