• Unambiguous mapping of objects:model nodes (called asobjects) are mapped to metamodel nodes, formally,∀c∈VM : t(c)∈VM M;
• Unambiguous mapping of links: model edges (called as links) are mapped to associations, formally,∀e∈EM : t(e)∈Assoc;
• Usage of identifiers for objects and links:objects and links are always picked from the model element universe, but they never belong to its unused counterpart, formally,VM ⊆U\UN U, and EM ⊆U\UN U;
• Type conformance of source objects: the direct type of the source object of a link is a descen-dant of the source of the direct type of the same link, formally, ∀e ∈ EM : srcM M(t(e)) ^∗ t(srcM(e));
• Type conformance of target objects: the direct type of the target object of a link is a descen-dant of the target of the direct type of the same link, formally, ∀e ∈ EM : trgM M(t(e)) ^∗ t(trgM(e));
• Multiplicity criterion for many-to-one associations: each object can have at most one link of a given direct type originating from the same many-to-one association. Formally, ∀A ∈ AssocM2O,∀e1, e2 ∈EM : srcM(e1) = a∧trgM(e1) = b∧srcM(e2) = a∧trgM(e2) = c∧A=t(e1) =t(e2) =⇒e1=e2; and
• Non-existence of parallel edges of same type:No parallel edges are allowed, which means that there cannot be any pair of links of the same type leading between the same pair of objects in a given direction. Formally,∀e1, e2 ∈EM : srcM(e1) =srcM(e2)∧trgM(e1) =trgM(e2)∧ t(e1) =t(e2) =⇒e1 =e2.
Small letters from the beginning of the alphabet (e.g.,c, a →e b) will be used for objects and links of the instance model.
In the following, we use termsmany-to-many link(denoted bya →e∗ b), andmany-to-one link (denoted bya→e1 b), if the direct type of the given link is a many association, and a many-to-one association, respectively.
Type definition can be generalized in such way that all ancestors of a direct type are also implied.
Definition 8 Given a metamodel M M, a well-formed instance modelM with a direct type function t, the type of an object c (denoted by t∗(c)) consists of all ancestors of t(c). Formally, t∗(c) = n
C|C∈VM M ∧C ^∗ t(c)o .
Although our presented graph-based model lacks several advanced features (like the three layer node inheritance of graph schemas [75], or the edge inheritance of type graphs [134]), it is still suitable for transforming models used in practice as demonstrated by the running examples.
2.3 Metamodel and model representation in Java
Java 2 Standard Edition 5.0 (J2SE) [128] and Java 2 Enterprise Edition 5.0 (J2EE) [127] are used as underlying implementation platform in order to demonstrate the strong practical links of the theoretical concepts and algorithms presented in this thesis. Java 2 has been selected due to its “write once run everywhere” philosophy, which makes Java programs portable by allowing their execution on a variety of hardware platforms and operating systems.
14 CHAPTER 2. GRAPH MODELS
2.3.1 Java 2 Platform 5.0 Standard and Enterprise Editions
Java 2 Standard Edition enables the development and deployment of Java applications on desktops and servers as well as embedded and real-time environments. It includes the Java Database Connectivity (JDBC) API, which provides universal data access in Java from a large variety of sources including relational databases, spreadsheets and flat files. In this sense, J2SE provides appropriate support, when models are stored and manipulated in main memory, or when models are stored in an underlying rela-tional database, but they are directly accessed and manipulated by low-level SQL commands.
Java 2 Enterprise Edition defines a layered architecture for scalable, distributed application devel-opment including several Java standards and APIs. An enterprise application being developed on the J2EE platform consists of Enterprise Java Beans (EJBs) as its most fundamental building blocks rep-resenting business data and functionality. An enterprise application is deployed to and executed by an application server, which provides many high-level services (such as transactions, security, persistence, etc.) beyond the execution of applications.
The following three types of EJBs have been defined by J2EE.
• Entity beansare persistent objects representing business data, which are kept synchronized with an underlying relational database by means of an object-relational mapping. Entity beans are uniquely identified by their primary key and they can be in relationship with other entity beans referring to each other by direct references (many-to-one or one-to-one relationships) or typed collections (many-to-many or one-to-many relationships).
• Session beansimplement the business functionality of the application. They can be considered as simple collections of business methods. Depending on whether they should preserve any in-formation between consecutive invocations of their methods, stateful and stateless session beans are distinguished. As our approach does not require any transformation related information to be stored, we use stateless session beans.
• Message driven beans are EJBs that provide asynchronous message processing functionality.
They can be considered as listeners to which application clients and other EJBs can send mes-sages.
J2EE is used as an underlying platform, when models are stored in a relational database and they are accessed and manipulated as plain old Java objects through transparent object-relational mapping and persistence layers.
2.3.2 Mapping metamodels to EJB3 entity bean classes
Now I present a method for mapping metamodels to EJB3 entity bean classes. Although the concrete example produces EJB3 entity beans as output, the generated interfaces show high similarity to both (plain old) Java objects (POJOs) with property accessor methods and interfaces specified by relevant modeling frameworks (such as Eclipse Modeling Framework (EMF) [136] and Java Metadata Interface (JMI) [129]). As a result, the presented techniques could easily be adapted to one framework or the other.
Based on the metamodel, entity bean classes are generated by using the standard object-relational mapping of [130], which can be summarized as follows. A class of the metamodel is mapped to an entity bean class. The inheritance relations between classes are maintained accordingly. Each association end with an at most one (arbitrary) multiplicity constraint is mapped to a Java attribute (collection) and two corresponding property accessor (i.e., a getter and a setter) methods in the entity
2.3. METAMODEL AND MODEL REPRESENTATION IN JAVA 15
bean class that represents the metamodel class being located at the opposite end of the association.
A Java attribute id representing the unique identifier and its two corresponding property accessor methods are added to each entity bean class that does not have a superclass.
In order to specify how Enterprise Java Beans are deployed to the application server, we use Java annotations for marking up class declarations, fields, methods, and other program elements in the source code. In this sense, annotations@Entityor@Statelessat class declarations denote that the given class should be handled as an entity bean or a stateless session bean, respectively. Annotation
@Inheritanceinfluences how inherited classes are mapped in the underlying relational database.
Annotations@ManyToMany,@ManyToOne,@OneToMany, @OneToOnemark up getter methods defined for each association end. to specify multiplicity criteria of the corresponding association.
Example 3 The skeleton of the entity bean class representing aFeatureis shown by Listing 2.1.
@Entity // Feature is an entity bean.
@Inheritance(strategy = InheritanceType.JOINED) // A different table is used // for each class
// in the inheritance hierarchy.
public class Feature extends ModelElement { // Attributes
private Class cf;
private Class sft;
private Collection<UniqueKey> uf = new ArrayList<UniqueKey>();
private Collection<KeyRelationship> krf = new ArrayList<KeyRelationship>();
// Property accessor methods
@ManyToOne // Association CF has * multiplicity constraint on its Feature side, // and 1 multiplicity constraint on its Class side.
public Class getCF() { return cf; }
public void setCF(Class cf) { this.cf = cf; }
@ManyToOne
public Class getSFT() { return sft; }
public void setSFT(Class sft) { this.sft = sft; }
@ManyToMany(mappedBy="uf") // Association UF has * multiplicity constraint // on both its Feature and UniqueKey sides, and // class on the other side (i.e., UniqueKey) // is responsible for handling links of type UF.
public Collection<UniqueKey> getUF() { return uf; }
public void setUF(Collection<UniqueKey> uf) { this.uf = uf; }
@ManyToMany(mappedBy="krf")
public Collection<KeyRelationship> getKRF() { return krf; }
public void setKRF(Collection<KeyRelationship> krf) { this.krf = krf; } }
Listing 2.1: Skeleton of theFeatureentity bean class
AsFeatureis a subclass ofModelElement, the identifier attributeidhas not been created. According to the metamodel of Fig. 2.1, theFeatureclass has four incident edges. Consequently, the generated code has four attributes and eight accessor methods.
In order to get an in-memory model space representation, which contains plain old Java objects, only annotations have to be removed from the above specification.
16 CHAPTER 2. GRAPH MODELS
2.3.3 Creating sample models as EJB3 entity bean instances
Instance models representing the system under design are stored in an underlying database of the ap-plication server. By using entity beans, objects of the instance model can be created, accessed and manipulated exactly the same way as traditional (plain old) Java objects with the single exception that these objects have to be explicitly persisted by calling thepersist()method of the entity manager, which in turn, provides the persistence context for the entity beans.
Example 4 The Java code that producesModel 1of Fig. 2.2(b) in an application server is presented by Listing 2.2.
1 @PersistenceContext
2 EntityManager em;
3 // Creating new objects
4 Package p = new Package();
5 Class c1 = new Class();
6 Class c2 = new Class();
7 Association a12 = new Association();
8 AssocEnd e1 = new AssocEnd();
9 AssocEnd e2 = new AssocEnd();
10 // Creating new links
11 c1.setEO(p);
12 c2.setEO(p);
13 a12.setEO(p);
14 e1.setCF(a12);
15 e1.setSFT(c1);
16 e2.setCF(a12);
17 e2.setCF(c2);
18 // Persisting new objects
19 entityManager.persist(p); entityManager.persist(a12);
20 entityManager.persist(c1); entityManager.persist(c2);
21 entityManager.persist(e1); entityManager.persist(e2);
Listing 2.2: Java code for generatingModel 1of Fig.2.2(b)
In Lines 1–2, the entity manager is initialized by the application server by injecting a persistence context (by using the annotation@PersistenceContext) for the method that creates entity beans.
Then 6 objects and 6 links are created by Lines 3–9 and Lines 10–17, respectively. Finally, the new objects are persisted by the underlying database of the application server while executing Lines 18–21.