As per wikipedia, a model is a pattern, plan, representation (especially in miniature), or description designed to show the main object or workings of an object, system, or concept. In the case of software engineering, models are used to represent specific aspects of the software system, such as static structures, communication paths, algorithms, etc.
Models can be created along two axis:
Abstraction level
C code – assembler code.
Both representation describe a sequence of operation in an imperative way, but C is much more expressive than assembler.
Java code – sequence diagram.
Both representations describe the run-time behavior of the system. The sequence diagram does however frequently omit details of the call flow.
A meta-level (and meta-model) is way to highlight the properties – the nature – of a particular set of elements. A meta-model describes then the constraints or the semantics to any set of such elements.
Object – class.
In OO technologies, object and classes belong to two different meta-level. The class is a representation of the structure (constraints) that any of the instance will fulfill.
XML – DTD.
An XML file can be validated against a DTD, which is not a representation of the particular file, but of the structure (constraints) that the file must fulfill.
Tower of models
Models themselves can be refined towards either higher abstraction level or meta-levels.
Component diagram – class diagram – Java code.
All three artifacts are representations of the same reality at various level of refinement and reasoning.
XML – Schema – Meta schema.
In this case, each model is meta description of the underlying one. XML Schema themselves must conform to the schema http://www.w3.org/2001/XMLSchema.
| Level \ Technology |
Language |
UML | ||
| L0 | Object | Object diagram, Sequence diagram | ||
| L1 | Class | Class diagram | ||
| L2 | – | Stereotype | ||
Examples where meta-models are useful
Having three meta-level provides one extra level of indirection that can be very practical in some cases:
|
Level |
XML transformation |
OO refactoring |
Annotation processing |
| L0 – information | Data | Object | Class annotation (e.g. @Entity) |
| L1 – model | Schema | Class | Annotation processor (e.g. JPA) |
| L2 – meta-model | Meta schema | Metaclass | Classloader |
Here are three common examples which actually leverage the strength of meta-model.
XML transformation
The success of XML is related to the existence of a meta-model which makes it a semi-structured format. Structured data are interpretable only by their host application which is the only one to know the model. Unstructured data (plain text, image, etc.) have not model and are not interpretable at all. Semi-structured data have a model which is itself understandable by any other application which knows the meta-model. Due to this extra-level, reusable parser, validator, encryptor or even arbitrary transformer (think XSLT) could be created. The schema could also be extended without necessary breaking backward compatibility (think XPath).
OO refactoring
Refactoring rules is a typical example of the usage of the OO meta-model: refactoring rules are proved to preserve the validity of the model against the meta-model, and are reusable for any model.
Annotation processing
Annotation processing is yet another example where a meta-model is used under the hood. Just like the class-loader knows how to load a class because of the meta-model of any class, it is also able to load the corresponding annotations. This reliefs the application from storing application-specific semantics in separate files (think deployment descriptor). The application (annotation processor) can then query the annotation at run-time to refine the behavior of the system. The annotations enrich classes with additional constraints and behaviour in a resuable way: the same annotation processor can be used for arbitrary class sets.
://ewernli 