OMG - Object Management Group. They made a proposal called MDA (Model-Driven Architecture) to use Model-Driven Engineering to Systems Development. Model-Driven Engineering - Use models for code generation, verification etc. Not just as a way of exchanging information with other engineers.
- Models must be expressed in a well-defined notation - i.e. a definition must exist for the model so everyone knows what the model is saying.
- System specs must be organized around a set of models and associated transformations - mappings and relations between multi-layered models.
- Models must be compliant with metamodels (more on metamodels later).
- Increase acceptance, broad adoption and tool competition for Model Driven Engineering (get more people to use MDE).
Meta = x about x.
e.g. Metadiscussion = discussion about discussion,
Metadata = data about data.
Metamodel = model of a model.
So let's consider the above diagram -
- M1 Layer = Instance of a UML Class / Object Diagram
- M2 Layer = UML Metamodel (i.e. the Model that describes UML itself) - but what is the model is used to describe UML itself then?...
- M3 Layer = MOF Metametamodel (i.e. the Model of the model that describes UML itself) This layer is actually reflexive, so we define MOF in MOF, otherwise we could keep going up until we have a M(Infinity) Layer.
- M0 Layer = Runtime Instance of the model - i.e. the state of the model in our system at the current point of time.
n.b. While UML Object Diagram in M1 Layer represents our Runtime Instance, it is still a model that represents the runtime instances of our objects / model at the current point of time. So the MO Layer is a conceptual one - it is not a iagram or anything.
Let's consider two Metametamodels - MOF and Ecore.
-
MOF - Stands for Meta-Object Facility. Meta-Objects are the components of the metamodel (e.g. the model that describes UML itself (M2 Layer above). So MOF is a model that describes how to make meta-models themselves, so using MOF, we could potentially define our own version of UML (let's call it ImadML) and make actual models that conform to ImadML. MOF is actually the model that we use to define UML.
-
We split MOF into two: eMOF and cMOF:
- eMOF: Essential MOF: is a simple language that defines metamodels. It is intended for people that make metamodels. Iti s bare bones - exactly what you need to make metamodels and no more.
- cMOF: Complete MOF Extends eMof is an extended metametamodel with more features than eMOF - we add more features so that we can make things easier for tool manufacturers - i.e. a more complete metametamodel that tool manufacturers can leverage to make tools that handle models that conform to our meta/metametamodels.
-
Ecore - This one is a little different. MOF is used to define a general metamodel for models that are independent of any Software Language. But: if we could make a metametamodel that has constraints such that metamodels (and thus models) that conform to it, also conform to constraints of, for example, the Java language, then we could generate tools/editors that are Java-based.
- So briely, Ecore took eMOF and edited it so that it conforms to the Java language model too.
This is how we combine modeling and programming.
So basically, we have Ecore which is a metametamodel, that as long as we follow, we can use to generate our own modeling languages that directly conform to the Java language constraints as well.
We leverage this, making straight-forward mapping rules from Ecore to Java (i.e. if we have X in an Ecore model, this translates to some Java code).
We use these mapping rules to take Ecore models as input and generate as an output:
- Java Code
- XML Documents etc.
With this, we can actually also make some of the following:
- Graphical Modeling Framework (i.e. editors to model things as graphs (lots of models are actually just graphs, like UML))
- Model to Model Transformations (M2M) - i.e. define rules that take some model X as an input and output another model Y
- Model to Text Transformation (M2T) - i.e. take a model as an input and spit out some textual representation of that model.
So the EMF gives us editors that allows us to create metamodels, and then model editors, as well as define tools that let us define transformations between models and between models and text.
Below is a flowchart that describes one such process to generate a model language, code to enable you to edit models of this language and an actual implementation of an editor for your model.
