Approach overview

Model serialization in source code

We advocate for a strong coupling between model and source-code, to give architects and developers a way to both interact during the whole development cycle. PAMELA is an annotation-based Java modeling framework providing a smooth integration between model and code, without code generation nor externalized model serialization. The idea is to avoid separation between modeling and code to facilitate consistency management and avoid round-tripping issues.

To do so, we argue that source code is the right artefact to encode the model with metadata information stored in tagged code. This requires an annotation-enabled language. Such language supports the attribute-oriented programming if its grammar allows adding custom declarative tags to annotate standard program elements. Java programming language from version 1.5 is a good candidate with the support of annotations.

The following figure presents the PAMELA approach for storing model in source code. The model is inlined across many source code files, with a set of annotations covering the PAMELA metamodel as presented below.

PAMELA use process

Coupling model and code into the same artefact open new ways of programming. The classical way relies on programmers that produce code reusing pre-existing modeling concepts. These concepts are implemented by modelers that provides the right annotations the programmers use. This is, for instance, the process followed by JEE developers reusing JEE specific annotations. The evolution rhythm between models and code is low. This programming way is still possible with PAMELA, but we allow the ability to reach a high evolution rhythm when the programmer becomes also the modeler. In fact, when a pattern, an abstraction, a generalization is identified by the programmer, s/he can use PAMELA to develop and capitalize on this abstraction by increasing PAMELA metamodel.

The developed metamodels are implemented by annotations that relies on Java/JVM entities and mechanisms. They include consistency checking that constrains their use and help the programmer. We have experimented their use with setter/getter to define POJO entities, with traits to implement multiple inheritance or roles and rules to set security rules on classes.

Our experience shows that introducing and reusing new concepts (1) reduce the size of the code, (2) reduce the risk of errors and (3) improve the code structure. The cycle of development between the model and the code can then be drastically reduced, leading to what we call continuous modeling.

The code size is reduced because each abstraction factorize a recognized pattern and the corresponding legacy code is replaced by the use of the abstraction at the right place. This also reduces the risk since the legacy code is now generated by the PAMELA framework with all the required checks. And finally, the code structure is improved since it matches the way the programmer conceptualizes (models) her/his code.

PAMELA metamodel

The PAMELA metamodel is presented in the following figure. This metamodel is classical and reflects a common class diagram vision such as found in UML.

• A PAMELAModel is defined as a set of references to ModelEntity.
• A ModelEntity reflects a concept and is encoded in a Java interface. The PAMELA metamodel allows multiple inheritance: thus ModelEntity may define a set of parent entities. A ModelEntity also defines some properties, encoded as ModelProperty. Note that reification of ModelEntity is performed in a Java interface (and not a class), which only defines API without any implementation for methods. A partial base implementation can be given using an abstract class (conforming to the implemented interface).
• A ModelProperty is identified by a name, a cardinality (simple or multiple) and a type, which can be a reference to another ModelEntity, or a Java type (a primitive or an arbitrary complex Java type). Depending on its cardinality, a ModelProperty is bound to a set of methods reflecting use of property.
  • A read-only single property defines read-access of its value using a getter (a Java method defined in the Java interface taking no argument and returning desired value).
  • A read-write single property defines a getter and a setter (a Java method taking the new value to be set as unique argument)
  • A read-write multiple property defines a getter, a adder (a Java method taking a new value to be added as unique argument), a remover (a Java method taking a value to be removed as unique argument), and may define additional methods for extended features such as reindexing for example.

A strong interest of the approach is that the model is encoded in Java, and must be compiled. It forces the Java compiler to perform required checks for a PAMELA model encoded in a strong typed program. The execution semantics of models is fully compatible with the Java semantics. Many validation rules are automatically performed by Java compilation, independently of the underlying PAMELA execution semantics.