Page 225 -

210 PASTOR, MOLINA, AND IBORRA
Figure 11.4 Structure of the Presentation Model

Level 1 Level 2 Level 3

Service Interaction Unit
Hierarchical Introduction
Action Tree
Defined Selection

Arguments Grouping
Dependency
Supplementary
Information

Class Population Filter
Interaction Unit

Order Criterium
Display Set

Instance Interaction Unit Offered Actions
LEGEND
A B Navigation

A uses B
Master-Details
Interaction Unit Master Interaction Unit
Detail Interaction Unit

of the conceptual primitives must be defined. In other words, what will the runtime behavior of
objects of the system (instances of classes of the model that represents the system) be according
to the conceptual primitives that have been used to define the model that represents this system?
The execution model can be seen as an abstract machine that is capable of executing any model
created with the set of conceptual primitives we have described above. It is abstract in that it does
not dictate how to execute models in any given platform and technology. Rather, any set of rules
governing the conversion of a conceptual model into a functionally equivalent software representa-
tion (implementation) in a given platform and technology must be compliant with this execution
model. The execution model per se is aimed at enforcing functional equivalence between (abstract)
conceptual primitives and (concrete) software representations of these primitives, and it also ensures
functional equivalence between different reifications of the same conceptual model.
Therefore, in order to easily implement and animate the specified system, we define a way in
which users can interact with system objects. To achieve this behavior the system has to:

1. Identify the user (access control): log the user onto the system and provide an object system
view to determine the set of object attributes/services that the user can query/activate.