Tool support

  In our context, a tool is an executable program that supports some well-defined task, and which manifests itself to the user via a concrete interface (windows, menus, and the like). As mentioned in the introduction to the paper, we are interested in tools which support the tasks of building, exploring and analyzing dynamic models. All together we think of the tools as a dynamic medium through which dynamic models may be handled in a much better way than constructing and reading diagrams on a sheet of paper.

At the outset, it may be relevant to ask if and how the set of tools for dynamic modeling is different from a tool set, which constitutes a programming environment (or a similar environment). After all, we need tools for the rather well-known and common activities such as editing, checking, interpretation, and administration. The answer is that there are both differences and similarities. The main difference is the nature of the model exploration tool, which is unique for our purpose, and central for the approach. As a similarity, the proposed tool set may be seen as a structure-oriented environment in the tradition of systems such as Mentor [5], The Cornell Program Synthesizer [10], Gandalf [6], PSG, [1], and IPSEN [4]. We will now describe the characteristics of the three tools in separation. Afterwards we will address the issue of integration. Finally we will briefly discuss the underlying tool representation.

Model building is an editing activity. The purpose of the model builder is to support the designer in creating and modifying a dynamic model. To the extent that a dynamic model can be seen as expressions in a formal language, the well-known range of editing techniques can be applied. In the one extreme, the model can be formulated as text, which conforms to the language, using a text editor. Let us call this the textual-linguistic approach. In the other extreme a model may be formulated using an interaction, which is customized especially to this particular task. The result of this interaction is an internal data structure which represents the model. Of that reason we call this the interaction-datastructure approach.

Of the following reasons, the textual-linguistic approach is not attractive in our setting:

1. Due to the requirements of both a formal and an informal element of the language (see section 2) it is attractive to be able to emphasize either the one or the other of these elements in a description. At a given time it may be ``too much'' to face the full degree of redundancy in the model.

2. By using the textual-linguistic approach we are locking ourselves to one particular means of expression (the textual one). As discussed in section 2 we want to be open towards different means of expressions, such as graphs, diagrams, browsers, as well as text. The interaction-datastructure approach supports this well.

3. The interaction-datastructure approach lends itself better towards a tight integration among the model building, exploration and analysis activities than does the textual-linguistic approach. The reason is that the underlying data structures easily can be shared among the tools in the tool set. If we base ourselves on the textual-linguistic approach, an incremental processing style is necessary in order to obtain a satisfactory integration.

Model exploration is the central and unique activity of this work. The purpose of `exploring' is to consolidate the understanding of the dynamic behavior of the object system. It may, to some degree, be possible to gain such an understanding by simply reading the model (using some linguistic or diagrammatic presentation). However, we do not think that ``simple reading'' is enough. We have a number of proposals which we hypothesize complements and enhance the designer's understanding of the object system and its temporal development.

1. The first is animation of the interaction among the set of objects. The animation may take several forms. The simple form is a textual tracing, during which the mutual interaction among objects is presented in a structured manner. As a more elaborate proposal, the interaction may be shown using an evolving graph, where the nodes are object, and where the edges are messages. The evolution of the graph reflects the temporal sequence of object births, object deaths, and message passings.

2. In the second, which may be called model querying, the designer retrieves information about the model by asking questions. Typical questions may be ``which objects are alive now?''; ``what is the interaction history of object X?''; And ``which classes are represented on the scene now?''. Some answers may be easily retrieved from the data structure which represents the model. Other answers require a more careful analysis of the model, and as such we see the need for integration with the model analysis tools.

3. The third and final proposal is interaction browsing together with scene browsing. In this context a browser is a tool that allows the user to explore a hierarchical structure in a disciplined manner [8]. The interaction browser presents the object interaction in a concise and structural form which allows the designer to dive into sub-interactions if he or she wants to. Each interaction is presented with some ``context'' in terms of the sender object and the sub-interactions. The scene browser presents the set of objects on the scene relative to a given point in the interaction. On each object, shown in the scene browser, it is possible to ask for further information, such as the intuitive explanation of the role of object in the dynamic model.

Model analysis is concerned with extraction of derived properties from the dynamic model. The derived properties need to be computed based on the information which is directly available in the model. As discussed above, we have seen that the model explorer depends on information which stems from the model analysis. In addition the model analysis tool is used to to check for inconsistencies in the model and to extract a partial static model from the dynamic model. Recall, that in our context a static model is concerned with the structural relationships among the classes in an object-oriented design, whereas the dynamic model is concerned with the interaction-oriented relationships among concrete objects. The extraction of static model information from the dynamic model information is based on the dualities between objects and classes, messages and methods, and between aggregation of objects and aggregation of classes.

The key to the generation of a static model from the dynamic model is that all objects are augmented with the class (in terms of a class name), to which they belong. The sole purpose of this is to identify sets of objects with common properties (protocols). If, for instance, object O1 has properties p1, p2 and p3 and object O2 has properties p2 and p4, and if, in addition, O1 and O2 belong to the same class C, then we can conclude that class C has the properties p1, p2, p3, and p4. In that way be can collect properties of classes by collecting properties of objects, which are augmented by the same class. The result is a partial static model; Partial because of the following observations:

1. We cannot be sure that the scenarios, on which the dynamic model is based, cover the total number of properties of a class.

2. There are some important, structural relationships among classes which cannot easily be derived from the instances of the classes, namely the specialization-generalization relationships.

The extracted elements of a static model may be pretty printed with respect to a given programming language, and may as such also serve as a rough starting point for the forthcoming implementation process.

As already mentioned, the integration among the model builder, explorer and analyzer is very important for the success of the system. During model exploration it is natural to modify og extend the model if and when a need for that is identified; This is model building. Similarly, the model exploration depends on information which is the result of an analysis rather than just direct presentation of information from the underlying model representation. From a conceptual point of view we think that the entire dynamic medium (or system) is best understood as a number of separate, but tightly integrated tools. From an implementation point to of view the three tools presented above may rather be realized as one single tool.

We represent a dynamic model as a data structure which is quite similar to an abstract syntax tree (an AST). Each node in the tree is an instance of a class in the implementation language, which for the current prototype is CLOS [2]. The generalization-specialization hierarchy among the classes make up the alternation structure in the underlying abstract grammar. The non-abstract classes aggregate grammatical concepts, and as such they make up the constructors of the abstract grammar. Seen in this way, we can talk about a dynamic modeling language, which we grammatically have defined at the abstract level.

We have not, until now, defined any concrete, linguistic presentation of models in the dynamic modeling language. As discussed above, we are working with non-textual-linguistic means of expressions, via browsers. However, with the purpose of saving models on files, we have defined an ad hoc ``constructor format'', in which a model data structure (an AST) is linearized, and in which each node is represented as a constructor expression. When evaluated, such a constructor expression directly creates the internal data structure.