Page 224 -

OO-METHOD 209
OO-Method usually refers to these dynamic logic axioms as valuations, which relate a variable
attribute a of a class with a given event s so that upon the occurrence of s, and if f holds, a will
take the value determined by f´.
Presentation Model

Finally, user interaction has to be considered. If we want to build a complete system description,
the way in which users will perceive the system when interacting with it needs to be incorporated
into the constructed system specification, which is the conceptual model. Therefore, a presentation
model is provided to complement the three previous system views.
To specify user interaction properties, the presentation model creates an abstract user-interface
(UI) specification built from a set of UI patterns belonging to a predefined catalogue of patterns
provided by OO-Method. These patterns collect the different situations that have to be considered
for UI specification purposes (for instance, selection criteria for looking for specific class instances,
a display set to fix which attributes should be shown to give more information about a selected
object, a set of available actions to determine which actions can be executed within the scope of
a given class service, etc.).
These UI patterns are structured in three different levels as shown in Figure 11.4. The first level
of the hierarchy, called Hierarchical Action Tree, defines the first level of interaction. It groups
the set of second-level interaction units, which are:

• The Service Interaction Unit, which is intended to represent the IU components involved in
the execution of a service.
• The Class Population Interaction Unit, which is oriented to determine how to access (subsets
of) the population of a class, including potential filter conditions, attributes to be viewed,
potential class services available when in a particular class instance, and so on.
• The Instance Interaction Unit, which is in charge of applying a similar idea but which focuses
on how to present a selected instance of a class.

Other complex interaction units can be built by composing the three previous types to deal
with more sophisticated kinds of user interactions (for instance, a Master-Details Interaction
Unit).
Finally, the third level of the UI pattern hierarchy is constituted by the set of UI patterns that
fix the lower-level rules that guide the final specific interaction to be executed. Depending on the
interaction unit type, this includes, for example: whether a service argument is to be introduced
and/or to be selected using a condition built on prespecified class attributes; how to group service
arguments; which attributes will be seen; what specific set of services can be activated when ac-
cessing an instance, and so on.
When all the components of the conceptual model are specified, it is time to proceed with the
model transformation process that will convert every conceptual primitive into its corresponding
projection in the target software development environment where the final software product is to
be built. To do that, an execution model must be defined.

Execution Model

Having introduced the conceptual primitives that allow the creation of a model to describe an
information system in an abstract yet accurate and precise way, the execution semantics of each