3.2.5. Putting a model into operation for a PDR installation
To be able to use a model, a user should add the package that contains the models’ types to his PDR installation. That is, he should download the package file from some repository and store it in his local database of packages. The function that takes care of this is addModelToLocalStore from the module Perspectives.Extern.Couchdb. We highlight several facets of this function.
This module makes functions available in the namespace model:Couchdb, as external core functions that can be executed by callExternal and callEffect.
3.2.5.1. Add model instances
As stated before, a package contains (the text of) a CRL file. This file holds a number of instances, usually of the types defined in the package. It must contain an instance of sys:Model, describing the model itself. The embedded CRL file is parsed and the instances are added to the users’ local database.
3.2.5.2. Customize indexed names
A model may both declare and use indexed names (see the text Indexed Names for more detail). Indexed names, such as sys:Me, must be replaced by personalised identifiers before they can be used. We must distinguish the occurrence of an indexed name in the model source text from that in a model instance.
In the type definitions, indexed names only occur in queries (calculated roles and properties, conditions of actions, right hand sides of binding in a let expression, right hand side of an assignment expression). Replacement is done when the query is executed – run time.
However, an indexed name in instances that come with a model, must be replaced before that instance is stored in the users’ local database. As an example, think of a role instance that is filled with sys:Me. Before that instance is stored, its binding should be replaced by whatever identifier is used to identify the user who ‘owns’ the PDR installation.
Moreover, the replacement should be remembered in run time. As the query interpreter executes a step that is, for example, sys:Me, it should look it up and find the unique local replacement for it. How do we set up the lookup table?
This is achieved by the requirement that the modeller should bind an instance of each indexed type in the model description (remember that the model description is an instance of sys:Model, a mandatory instance packaged with a model). Here is an example, take from model:System itself:
sys:Model usr:PerspectivesSystemModel
extern $Name = "Perspectives System"
extern $Description = "The base model of Perspectives."
extern $Url = "http://127.0.0.1:5984/repository/model%3ASystem"
$IndexedContext => sys:MySystem
$Name = "MySystem”
$IndexedRole -> sys:Me
$Name = "Me"
Notice how sys:MySystem (an instance of the indexed context type sys:PerspectivesSystem) and sys:Me (an instance of the indexed role type sys:PerspectivesSystem$User) are bound in usr:PerspectivesSystemModel.
Run time, the PDR retrieves all instances of sys:Model$IndexedContext and sys:Model$IndexedRole from the local database and constructs a table from the indexed names to the customised identifiers (remember that the indexed names themselves have been replaced by unique identifiers before the instances were added to the users’ local database!).
3.2.5.3. Add new indexed names
Indexed contexts and roles introduced by the model will be added to the table of all indexed names that the PDR has compiled on startup.
3.2.5.4. Set me and isMe
The PDR keeps track of a number of computed properties for the sake of efficiency. One of these is the me member of a context instance representation; related is the isMe Boolean property of a role instance representation. The latter is true if the role represents the current (owning) user; the former is the role in the context instance that has an isMe value of true. (for more details, see the text Overview of state change mechanisms).
After parsing the CRL text with instances, the PDR computes the value of me and isMe for each of them.
3.2.5.5. Retrieve dependencies
A model may list other models whose types are used in its definitions. These dependencies should be loaded before the models’ instances are processed. Currently, the PDR supposes that model dependencies are available from the same repository as the model itself. We may need to change that in the future. The most likely way to do so seems to be to store the repository location with the model name as a dependency (the repository name must be known to the PDR of the modeller, as it must have a local copy of each of the dependencies).