Modeling in Webgme¶
OK, so in webgme you can make a (meta-)model that describes how models can be composed. That’s all sounds pretty neat, but in order for that to work in practise some more concepts are needed.
- How do nodes (model elements) relate to each other in general, what are the restrictions?
Before going into the details of the data-model let’s first have a look at the default GUI of webgme…
Leaving the adaptive UI on the side, it is completely possible to construct models using webgme’s APIs that do not adhere to any specific meta-model. Below are the built-in concepts of the webgme data-model listed. Note that they are tightly coupled with concepts of the meta-models.
- “first class object”, “object”, “thing” every node is derived from this (except the ROOT)
- Single tree rooted at the FCO. Every node has a base, except the FCO and ROOT. Inheritance is a strong relationship: If the base is removed so are all derived nodes. Webgme uses prototypal inheritance.
- Single tree rooted at ROOT. Every node has a parent except the ROOT. Inheritance is a strong relationship: If the parent is removed so are all children nodes.
- A one-to-one named association. The equivalent in UML is Directed Association.
- A one-to-many named association. Similar to pointers but the owner can associate with more than one target. Also similar to containment by it is not a strong relationship. The equivalent in UML is Aggregation. In webgme sets can store data about their members.
- Textual or numerical information stored at the nodes. Attributes adhere to the meta-model, whereas registries can hold any type data without meta-violations.
Restrictions Beyond the Meta-model¶
The data-model itself does set some restrictions on models in addition to the meta-model - these are mainly stemming from
how prototypal inheritance is implemented in webgme. Consider a meta-type
A that can contain instances of meta-type
Consider two instances of
a'. (Yes in webgme creating instances is not restricted to meta-types,
and it’s perfectly fine to create a new instance from any node.)
One immediate restriction (that should not be very surprising) is that node
a cannot contain itself - a node can only
exist in once place in the containment hierarchy.
In this scenario it is not possible to move
a, nor the other way around even though either case would
not a violate the meta-rules.
- Nodes cannot contain any of its instances
- Prototypal inheritance in webgme also includes structural inheritance - an instance inherits the nodes contained by its base.
a'were contained in
ait would mean that
a'would inherit an instance of itself as a child. This child would in turn inherit yet another instance of itself as a child, and so on until the people in the white lab enters…
- Nodes cannot contain any of its bases
- This is due to how nodes are loaded in webgme. If you remember from the introduction, all nodes do not have to be loaded
in webgme - instead subtrees are loaded on demand. Before a node is loaded all its parents and bases are loaded. In the case
a'were to contain
athis look-up would result in a loop. To load
a'would have to be loaded first and to load
a', its base
awould have to be loaded..
In general the graph formed by the intersection of the nodes and union of the edges from the containment- and intersection-tree must form a tree (a graph with no loops). Luckily the webgme UI and the API ensures that this won’t happen.