Logo

10.1 The Entity

The MooseEntity is the basic representation of an entity in a model. Thus, the MooseEntity class is meant to be subclassed by any specific meta-model entity.

It provides two main generic services.

First, it holds a reference to the parent MooseModel . This does lead to a cyclic dependency between the entity and the model. However, given the tight connection between these two concepts, it is unproblematic in practice while it provides a particularly handful feature for creating queries that require more information than the current entity provides.

For example, suppose that we intend to create a query that given a method entity checks whether another method with the same name appears in the rest of the model. For this, we need to traverse all methods in the model. Having the reference to the model allows us to install a simple method without parameters (i.e., unary method) directly in FAMIXMethod:

otherMethodsWithTheSameName
^ self mooseModel allMethods select: [:each | each name = self name]

The second important feature of an entity is the mechanism for state management and extension achieved through the EntityState hierarchy.

Following our example, we might want to cache the result of otherMethodsWithTheSameName to not require a new traversal of all methods every time we ask for it. To achieve this, the simplest solution would be to add an instance variable to store the result. However, extension methods like otherMethodsWithTheSameName are placed typically in a separate package (other than the package of the class), and thus the instance variable should also belong to the same package. This is not cleanly possible in Smalltalk.

EntityState solves the situation, by offering for each entity an extensible dictionary that simulates instance variables. For example, we could store the result of our query in a cache:

otherMethodsWithTheSameName
^ self privateState
cacheAt: #otherMethodsWithTheSameName
ifAbsentPut: [
self mooseModel allMethods select: [:each | each name = self name]]

Every entity can access its EntityState through the privateState message. There are three dictionaries offered:

  • attributes — for variable extensions that are meant to extend the basic structure of the entity. This typically happens when we want to extend the meta-model with an extra relationship between two entities, we would store it as an attribute. For example, if you would have extra information about which author worked on which method, we could add an author attribute in the Method entity.
  • cache — for storing the result of queries. For example, our example query is meant to be stored in the cache, and not as an attribute.
  • properties — for storing simple values. For example, metrics are typically stored as properties.

Add a Note