Transforming the Business of Development
JeeWiz is a system generator that automates very high percentages of system development,
expressing patterns of unprecedented complexity.
This section reviews the benefits of this approach
and explains how JeeWiz achieves this.
Some of the benefits of automation are obvious.
If we can generate software from 'models' (i.e. specifications) and templates/patterns, rather than build it by hand,
it will be
These are the well-publicised benefits of MDA.
- faster to change. We commonly find that one reference in a model gets expanded by a factor of 5 to 50 during the generation process
- cheaper. Once the templates/patterns are constructed, running them is virtually free,
so the dilation factor mentioned in point 1 comes into play: models are much quicker to write than the instructions to carry them out.
- we can change the system quickly in two dimensions:
changing the patterns changes the architecture;
changing the model changes the functionality of the system.
This makes the process agile and systems more maintainable.
Here are some of the less obvious benefits of using JeeWiz:
- JeeWiz's high-level modelling concepts make it feasible to model and build systems while talking to the customer,
which is much more efficient than writing descriptive documents.
The model becomes a 'living specification' in that it can be run and demonstrated.
- The architecture and detailed deployment tasks can be committed after the system is built and approved.
This is the reverse of the normal order where the architecture must be agreed and proven upfront -
a costly exercise, which puts pressure on the critical path and is more likely to be thrown away the earlier it is done.
- faster delivery means the business drivers for the project are more likely to still be relevant,
so the net present value of the delivered system is higher.
Till now, the benefits of automation have not been enough to convince most software developers to use system generation
as a strategy.
We believe this has been due to the limitations in functionality and scope of system generation,
caused by technical problems with the process.
This section describes some of these problems and how JeeWiz solves them.
The Semantic Gap
One of the key issues is how to bridge the "semantic gap"
between the high-level concepts we would like to model
and the much lower level facilities of the implementation platform.
For example, JeeWiz allows modellers to use concepts like 'page' and 'event', which
are high-level concepts; these will create large amounts of code, HTML and configuration.
(Note that these high-level 'pages' and 'events' are technology-independent;
the implementation of the concept in a particular technology must be supplied.)
Most generators have not attempted this level of complexity.
Unfortunately, the higher the modelling level, the more value is added by automatic generation,
so this omits the most valuable areas.
The common approach to bridging the semantic gap is to do it in one transformation step, or possibly two,
but this approach is extremely difficult and makes the solution too specialised and brittle.
This is because such a large transformation will incorporate too many aspects -
it ties together too many areas of concern,
such as UI presentation, database management, language and large-scale architectural patterns.
In JeeWiz, we bridge the semantic gap in small steps, building up the concepts and transformations in separate modules.
This way, each step is smaller, and even higher-level concepts can be added by developing new modules.
This approach promotes re-use: lower levels can be used by multiple higher levels by configuring a different build.
Here are the transformation steps in the JeeWiz Struts/J2EE system, mapping the 'page' concept to Java code and XML configuration.
Some system generators require complete specification of models;
others allow developers to change models as the generation process crosses the 'semantic gap' above.
This complicates the development process.
JeeWiz provides a powerful pattern mechanism, which is the most important mechanism in creating the architecture for the generated system.
This same mechanism is triggered when required elements of the model are missing to flesh it out -
such as adding database primary key attributes onto persistent objects, or adding top-level pages in an application.
Furthermore, the pattern mechanism allows enough variation and control that company architects
build special-purpose architectures,
so manual changes are not required.
This means that the JeeWiz process is simple: an incomplete model can be turned into a runnable system in a single step.
This makes it possible to work with users and get early specifications validated by running the generated system, there and then.
Getting a validated model, as a 'live' specification, faster means that the delivered value is higher.
Architects also appreciate the fact that their approved architecture cannot be changed by the whim of a modeller,
which is a recipe for disaster.
The Devil and The Details
Most generator regimes fix a lot of details, such as how data is presented on screens or to databases, in the patterns.
This limits the scope of the generation and makes the patterns difficult to maintain,
which in practice severely restricts the generator's usefulness.
JeeWiz uses an aspect-oriented scheme to feed in these details so
one pattern used in different builds can generate outputs that are quite different in the fine detail.
These aspects are typically attached to the technology layers (Struts, J2EE etc.),
but can be overridden for specialised requirements (e.g. to reflect a local representation of language types in the database).
JeeWiz patterns can therefore address the larger architectural concerns,
decoupled from the fine details of the technical environment they are controlling;
they can be used in environments not envisaged when the patterns were written.
An interesting point is the implementation language itself is an aspect in the J2EE and .NET patterns,
so they can generate detailed code without worrying about the names of collections, String methods and so on.
Coverage and Adaptability
System generators are almost always restricted in one or more ways.
Some have a built-in modelling tool, or can only handle particular types of design information
(e.g. versions of XMI for UML modelling tools);
others require a particular target architecture, or the manufacturer's framework, to generate to.
These restrictions make the generators less useful,
and increase the cost of adapting to new areas.
JeeWiz is designed to be open.
We have already discussed examples of how
JeeWiz can generate from increasingly abstract concepts, using aspects to implement local variations.
Generated code does not require particular framework libraries to operate.
These are examples of how JeeWiz promotes wide coverage and adaptability.
JeeWiz supports a wide range of design imports - UML, XML Schema/WSDL, and simple XML -
with the intent that any design format should be usable with little effort.
In other words, JeeWiz will be able to accept any design input, as long as it is in XML.
This is important as system design information is increasing,
both in the range of formats, and in its volume and complexity.