Skip to main content

Persisting Bigraphs

The framework itself provides simple means for storing and loading bigraphical metamodels and instance models using the capabilities of Eclipse EMF.

Therefore, the utility class org.bigraphs.framework.core.BigraphFileModelManagement within the bigraph-core module comprises methods for persisting bigraphical models to the filesystem. Basically, BigraphFileModelManagement is a simple file-based model management utility class that serializes (deserializes) to (from) XMI and Ecore:

  • Serializes/Exports Ecore-based bigraph model objects (EObject and EPackage) to *.xmi and *.ecore, respectively.
  • Deserializes/Imports Ecore files (*.xmi and *.ecore) to Ecore-based bigraph model objects (EObject and EPackage)

XMI provides an XML representation for Ecore constructs.

Both operations are provided by the inner classes Load and Store of org.bigraphs.framework.core.BigraphFileModelManagement to easily distinguish and use them.

Note: For a more sophisticated persistence solution, we refer the reader to Eclipse Connected Data Objects (CDO) Model Repository and the corresponding implementation Spring Data CDO for working with the Spring framework.

Output format​

For the metamodel the file extension *.ecore is used and for the instance model *.xmi.

The instance model includes a direct reference to its metamodel which can be used for validation. This information can also be changed (or manually edited afterwards). This is described in Storing an instance model to the filesystem

Bigraphical Metamodel​

To only store the meta-model of a concrete bigraph (i.e., an abstract bigraph over a signature, also called meta model over a signature), we call the method BigraphFileModelManagement.Store.exportAsMetaModel(). Several overloaded methods exist that support, for example, also input streams.

Storing a metamodel to the filesystem​

For demonstration, we create a simple signature and afterwards a bigraph


import static org.bigraphs.framework.core.factory.BigraphFactory.*;

void storing_a_metamodel_to_the_filesystem() throws IOException { 
	DefaultDynamicSignature signature = pureSignatureBuilder().newControl("Building", 2).assign().newControl("Laptop", 1).assign().newControl("Printer", 2).assign().create();
	createOrGetBigraphMetaModel(signature);
	PureBigraphBuilder<DefaultDynamicSignature> bigraphBuilder = pureBuilder(signature);
	PureBigraph bigraph = bigraphBuilder.createBigraph();
	BigraphFileModelManagement.Store.exportAsMetaModel(bigraph, new FileOutputStream("meta-model.ecore"));
}

As shown above, the metamodel data must be passed to a special method available from org.bigraphs.framework.core.factory.BigraphFactory. The method exportAsMetaModel(EcoreBigraph, OutputStream) is used then to output the Ecore representation to the filesystem.

Loading a metamodel from the filesystem​

Note that various overloaded methods exist:

BigraphFileModelManagement.Load.bigraphMetaModel(...);
BigraphFileModelManagement.Load.signatureMetaModel(...);

Example: Loading the Bigraph Meta-metamodel​

Bigraph Framework also contains a bigraph "meta-metamodel" which can be acquired at any time by calling:

EPackage bigraphMetaModel=BigraphFileModelManagement.Load.internalBigraphMetaMetaModel();

This metamodel is used to dynamically create bigraphs over user-defined signatures, thus, representing the meta-metamodel of every metamodel created by a builder instance.

Changing the Metadata of a Metamodel​

We can also pass some additional meta data to the bigraph builder. This gives us the option to specify the namespace and the URI for the metamodel. Therefore, the following data structure is needed:

EMetaModelData.builder().setName("sample")
        .setNsPrefix("bigraph").setNsUri("org.example.bigraphs");

located in the package de.tudresden.inf.st.bigraphs.core.datatypes of the bigraph-core module.

[//] # (Its purpose should be self-explanatory from the above example (see also below).)

Some BigraphFactory methods accept the metadata object.

Note: Changing the metadata of a metamodel introduces problems concerning model validation. When modified metamodels are imported again, validation may fail.

Bigraphical Instance Model​

Storing an instance model to the filesystem​

To store an instance model (i.e., a concrete bigraph over a signature):

// create some bigraph via the builder
PureBigraph bigraph=...;
BigraphFileModelManagement.Store.exportAsInstanceModel(bigraph,new FileOutputStream("instance-model.xmi"));

To change the namespace location of the corresponding metamodel, you can provide this information as follows:

BigraphFileModelManagement.Store.exportAsInstanceModel(
        bigraph, // the bigraph to export
        new FileOutputStream("instance.xmi"), // the file location
        "./path/to/meta-model.ecore" // the new namespace location of its metamodel
);

Signatures are also supported for export:

exportAsInstanceModel(EcoreSignature signature, OutputStream outputStream)

Loading an instance model from the filesystem​

Instance models can be loaded directly from the filesystem like this:

List<EObject> eObjects = BigraphFileModelManagement.Load.bigraphInstanceModel("instance.xmi");

In the example above, the validity of the instance model is only performed against the bigraph meta-meta-model. However, when providing a meta-model, the instance model is validated against it:

EPackage metaModel = BigraphFileModelManagement.Load.bigraphMetaModel("meta-model.ecore");
List<EObject> eObjects = BigraphFileModelManagement.Load.bigraphInstanceModel(
        metaModel, // the metamodel
        "instance.xmi" // the file location of the instance model
);

Note: If the metadata of the metamodel was changed, this may produce errors and validation may fail.