|
|
|
The Model-Driven System Builder
|
|
JeeWiz Architect's Guide
|
|
|
|
Contents >
2. Overview
|
|
|
2.4 Meta-Model 'Inheritance'
This section gives an introduction to the concept of meta-model inheritance.
2.4.1 Meta-Class Inheritance
|
Many meta-classes take part in inheritance relationships.
The way we go about discovering these relationships is the same as in normal modeling:
we look for nouns and key phrases like 'kind of', 'is a'.
For example, in the Java Language Specification, we find "There are three kinds of reference types: class types...".
When we build a meta-model of the Java language, this suggests that the class meta-class should extend from the reference-type meta-class.
(In JeeWiz, we change the name of this meta-class to jwclass so that when we generate the code,
we avoid conflict with Java's Class class.)
This is one inheritance relationship between meta-classes.
In building larger systems, there are often conventions for higher-level meta-classes such as
- using JavaBean conventions,where getters and setters for are used to access attributes rather than making the fields public
- creating an interface for the publicly-available methods and attributes
- splitting the implementation and base classes.
JeeWiz provides such a meta-class, called an internal-class; it is a subclass of the jwclass meta-class.
This is a second inheritance relationship.
Note that we will need more detail in our meta-model to define internal classes,
because will need to define which methods and attributes are to be publicly available.
In other words, this is properly constructed as a meta-class.
Carrying on this approach, we end up with a series of meta-classes that build up from Java to entity EJBs:
|
| reference-type
| The basic Java object type, with features common to class and interface.
|
|
| jwclass
| The Java class (using JeeWiz's rename).
|
|
| internal-class
| A class for software-engineering aficionados, with facilities for defining 'business-methods' that should be exposed via the interface, and the intention to define base/implementation/factory classes and the interface exposing business methods.
|
|
| business-object
| An object that will provide a service to users - including remote access - via business methods, and attributes with additional capabilities like persistence.
|
|
| entity (generic)
| An entity, as in 'entity-relation' model. Most of the logic for entity relation modeling is defined around this object.
|
|
| entity (J2EE)
| The J2EE variant of the entity; this includes specific J2EE features, such as permissioning aspects.
|
As we go down this list, we add more specialised capabilities, both in terms of properties (specified data)
and methods to implement views etc.
The end result of is to construct a 'more logical' level, so business users can model using higher concepts where appropriate.
Most business models will use 'entities' and 'sessions' to model business objects;
they should not need to concern themselves with the lower-level features.
2.4.2 Meta-Model Inheritance
|
We have previously introduced meta-models.
To aid management and chunking of large-scale systems, we introduce the concept of meta-model inheritance,
which are collections of related meta-classes.
In describing the meta-classes in the previous section, we have used terms from Java, business object theory and J2EE.
These are in fact the names of the meta-models we use in JeeWiz;
the meta-classes described above are incorporated into these meta-models as shown in the following diagram:
We now have three meta-models, with a suggestive 'inheritance' notation between the meta-models,
which we use where one of the meta-classes in a higher meta-model inherits from a meta-class in a lower meta-model.
Of course this does not mean every meta-class in the higher meta-model needs to inherit from a class in the lower meta-model: it is important to be able to introduce new concepts.
There are two parts to this idea:
- First, the modularisation implies that we also need to have the ability to use JeeWiz with many meta-models during a build.
There is no point having entities and jwclasses, if we can't pull in the appropriate meta-models for all the concepts used.
- Second, there is the point that we can build meta-models using the features of the inherited meta-models.
Each JeeWiz build can have a different 'stack' of meta-models.
This is constructed by incorporating the jars that hold the Java classes into the build, in the correct order.
JeeWiz then uses this order to search for objects to match given element tags.
An important result of using this search order is that more specialised classes are used instead of the more basic ones.
For example, an <entity> element in the above example will be mapped into the J2EE Entity class rather than the one from the business model meta-model.
This aspect of JeeWiz is called specification polymorphism
2.4.3 Pluggable Meta-Models
|
TBD: this section refers to obsolete features (like the .NET generator): it should be updated to give examples from the V4 and V5 generator systems.
As JeeWiz provides a mechanism to use different stacks of meta-models for different builds,
it opens up the possibility of doing builds using the same model but different meta-model configurations.
It is possible to do this.
In JeeWiz, we build J2EE and .NET applications using different stacks of meta-models.
This are the same style of applications - three-tier web applications - but using different technologies.
We can substitute one or more meta-models with equivalent substitutes from the other technology.
This is demonstrated in the following diagram, which shows more of the meta-models used in building J2EE and .NET applications.
(This reflects JeeWiz as of Version 3: this stack is no longer supported, but this is a good illustration of the mechanism.)
This feature is called 'pluggable meta-models', emphasising that we can reuse some of the complex meta-models -
business object and screen - but plug in environment-specific meta-models to fill the appropriate purpose:
- The language in the J2EE build is Java; we used to support C# for .NET (but no longer do so).
- The application server level needs two meta-models in J2EE:
the general J2EE level and an application-server-specific override to generate the correct configuration XML files.
In .NET, we only need a single meta-model because there is only one vendor of .NET.
At first sight, this stack of meta-models looks quite complicated.
However, it is not the most complex build done in JeeWiz, and in fact there are often many more meta-model levels.
Pluggable meta-models do at the meta-model level what object-orientation and run-time loading in Java systems:
- we can specialise, enhance and override the functionality provided by base objects
- we can create different behaviour (i.e. different generated systems in the meta-model case) by changing configuration information.
We will return to inheritance and pluggability: we also use it on the rendering side of JeeWiz,
as described in Rendering Inheritance.
2.4.4 Which Meta-Model
|
Which meta-model does a particular concept belong in - and so, where should you look for a particular modeling feature?
In general, the principle guiding how to group meta-classes into meta-models should be
to find logical layers that have tightly coupled concepts and create a meta-model for them.
There is no significant run-time overhead in creating meta-models.
Because of the mix-and-match capability described above, extra flexibility can often be gained by having smaller meta-model groupings.
As an example, here is the inheritance structure of the J2EE models:
- The 'Java' meta-model is a mapping of Java onto XML.
All the common features of Java are there.
For example, there are jars, interfaces, methods, fields ... and also jwclass's (unfortunately 'class' would have been too confusing). This is a concrete model: you can create a jar from a specification using the default rendering.
- The Business Object model allows you to describe objects with business processing overtones.
This model derives from the 'object' model and adds the concepts of
- exposing objects and methods to clients
- entity/session functional distinction
- constraints
- logging and tracing
- aggregation objects called data-views (to build up richer objects than simple entities attached to tables
- relations between objects and data-views.
All the class and component diagram features of UML that are relevant to JeeWiz are available in this model. This is an 'abstract' model in that there is no default rendering: it needs to be mapped into J2EE, .NET or a DIY architecture to describe the particular rendering for that model.
- The 'screen' model defines pages and events on the pages, which are rendered into Struts or ASP.NET
- The 'J2EE' model derives from the business object model and allows you to add descriptions of J2EE concepts and deployment information.
It also specialises some of the objects in the business object model, such as entity and session. As EJB is container-based, this also adds the concept of local/remote.
- Above the J2EE model are variants for the particular application servers.
2.4.5 How To Model
|
If there are multiple meta-models, how does a business user/analyst model?
The issue here is that all other modeling environments (to our knowledge) only use a single-level modeling structure.
So how do we reflect the various layers of the meta-models so they can be understood by modelers and used by modeling tools?
First, users should model using logical concepts for the domain being addressed, not physical concepts.
In the context of the meta-model stack above, the Business Object and Screen meta-models are logical meta-models:
they contain no technology/physical concepts.
They define concepts like business-object, entity, session, page, event, wizard-page,
but not technology-specific items such as 'what is the code-behind class' (.NET) or 'bean-managed' (J2EE).
So to observe this principle, the modeler should have at his disposal concepts in the Business Object and Screen meta-models,
not from the J2EE, WebLogic or .NET meta-models.
You may think there's a problem here:
if the models only contain logical information,
aren't we missing the platform-specific information that generated systems will have to contain to use the target platform?
Let us re-affirm: to be useful, modeling must present an abstraction of the target system
so it would be wrong to include physical (platform-specific) information in the model.
Doing so would not only destroy the leverage that modeling can provide (we would just be transferring the coding task to modeling diagrams);
it would also get us into trouble when we try to generate for a different platform.
So, we are not missing anything: the answer is that the rendering must generate this information.
But on what basis does the rendering do the generation? Here are the options:
- The architect decides to fix an aspect of the generated system.
For example, a J2EE architect may decide: 'we use container-managed entity EJBs'.
This means that the rendering can use a 'constant': the J2EE template that creates the EJB configuration can contain 'bean-managed=false'.
- There is a cross-platform specification of the information.
For example, entities in the Business Object meta-model have a specification of the table-name to be used to access information from a database.
This information is used in both J2EE and .NET to generate the target-specific configuration and JDBC/ADO.NET code to access the database table.
If information needs to be provided by the user to complete the specification, it should be handled by this option.
- Another option is that the rendering is not fixed, but that it falls out of the logic of the system being generated.
For example, in generating Java code, should we set the access for classes and methods to 'public', 'protected' or 'private'?
When the model contains an entity, the architect coding the J2EE rendering knows what all the values for the access should be:
it is defined by the EJB specification.
This is an example of cascading a logical concept into various platform-specific specifications.
- Finally, there is a catch-all 'style' feature available in the logical meta-models.
The idea of this is to tag a meta-class with a hint which will be interpreted, or ignored, by the rendering.
For example, the screen representation of relationships can be displayed as a grid or on a tabbed page:
these are selected by styles specified on the page meta-class.
This gives an architect a way of creating various renderings without fixing them in the meta-model.
To continue with the issue of present meta-modeling layers to the modeler:
the second point is that we must convert JeeWiz's multi-meta-model structure to a single meta-model for modeling.
This is done by a subsidiary rendering of the meta-model stack.
It walks the meta-models and selects meta-classes and properties to be presented to the user,
using either configuration present in the meta-models or a filter that is specific to the modeling tool.
This therefore performs the required functions:
- collapsing the multiples levels of the meta-model stack into one
- removing any items that should not be used by the modeler; this allows the local architect control over what can be modeled as well as what can be generated
- creating the plug-in or other driver information for the modeling tool (or DSL environment).
Copyright (c) 2001-2008 New Technology/enterprise Ltd.
| |
