Design time and runtime models may be uniformly described by UML and OCL models connected through correspondence models. We propose to develop a common user interface for both model layers in order to provide systematic and uniform access through operation calls to design time and runtime items. Operation calls can be systematically recorded in lmstrip models so that complete design time and runtime development steps are accessible. From recorded steps, various standard software models (like class, object and sequence diagrams) may be derived for documentation and comprehension purposes.
are discussed in Sect. 3. Section 4 shows related work. Section 5 closes the paper with concluding remarks and future work. 2
The class diagram in Fig. 1 determines the structures of our approach. It contains submodels for particular purposes: a design time model, a runtime model, a user interface model, and a lmstrip model for recording operation calls from the user interface model.
Design time model: In the upper center, the gure contains the classes Class and Assoc. Its purpose is to enable the speci cation of classes and binary associations, not general associations. This can be regarded as a dramatically simpli ed version of the UML metamodel for UML class diagrams (within the OMG 4 level architecture).
Runtime model: In the upper right, the gure shows the classes Object and Link. Its purpose is to make it possible to build objects and links for previously de nes classes and associations. This can be seen as a simpli ed version of the UML metamodel for UML object diagrams (within the OMG 4 level architecture).
In our view, the design time items constitute typical elements needed during system design, and the runtime items are the building blocks occurring during system execution (or system runtime).
User interface model: In the upper left, the gure de nes the class CLI (Command Line Interface). The operations of the class are designed for building up a (simple) class diagram and a (simple) object diagram. The operation parameters are all String-valued and depend on each other. For example, in the operation newAssoc the parameters fst and snd refer to the names of the classes between the new association that is going to be de ned.
Filmstrip model: In the lower part, the gure de ned a lmstrip model for recording operation calls from the command line interface. Every CLI operation becomes an OperationCall class so that operation calls are represented as OperationCall objects. after execution of the command and operation call sequence. In the example execution, design time elements are handled before runtime elements. However, this must not necessarily be the case. In general, calls handling runtime items may also be executed before design time calls.
Figure 3 pictures in the left three derived models that can be regarded simply as views on the larger object diagram in Fig. 2. All items from Fig. 3 occur in Fig. 2, however, they are di erently arranged.
Class model view: In the upper part, a class diagram view is presented. The two classes Person and Book and the association Borrows are shown. These three items are available for the rst time in Snapshot4.
Object model view: In the middle part, three evolving object diagrams are pictured, namely the Person object Ada and the Book object UML. The shown items are taken from the snapshots Snapshot5, Snapshot6 and Snapshot7. Sequence diagram view: In the lower part, the considered items are arranged in a sequence diagram-like style. Four imaginary sequence diagram lifelines are present: (a) the vertically arranged Snapshot objects can be imagined as an actor in the sequence diagram; (b) three lifelines for the object Ada, the object UML and the link between Ada and UML can be imagined. The OperationCall objects represent the messages from the imaginary sequence diagram. Here, the snapshot objects Snapshot4 to Snapshot7 together with their connecting OperationCall objects have been selected and displayed.
When displaying the models in the left of Fig. 3, we have taken the currently available options in USE. Instead, one could choose a di erent visual syntax that is closer to the purpose of the considered fraction of the object diagram, as indicated in the right of the gure. 3
In our view, the architecture and operation mode of our approach can be visualized as shown in Fig. 4. It captures the four di erent layers and makes clear that: (a) the design time model can be used on its own; (b) the design time model and the runtime model can be used together on their own; (c) this analogously holds for the remaining models. This section goes through the four models in Fig. 1 and Fig. 4 and discusses relevant details.
Design time model: We have kept this model rather simple, because our aim in this contribution was to explain our overall approach with a manageable example. The two classes Class and Assoc with their connecting association de ne that an Assoc object (an association) is binary with exactly two implicit association ends. Naturally, also more involved models can be used as design time models. Please note that the PredSucc associations are part of the lmstrip model, not part of the design time model. An analogous statement holds for the runtime model and user interface model: PredSucc associations are part of the lmstrip model.
Fig. 4. Russian Doll Architecture Showing Model Usage.
Runtime model: The runtime model has counterparts for the items occurring in the design time model. The two di erent parts of a link are modelled by two di erent associations. The correspondence model connecting the design time model and the runtime model consists of the two `typing' associations ClassObject DT RT and AssocLink DT RT. These associations specify for an Object its Class and for a Link its Assoc. The runtime model brings the design time model into life by allowing to instantiate classes and associations. User interface model: This model consists of the single class CLI only (Comand Line Interface). It has operations to construct a new class, a new association, a new object and a new link. Classes, associations and objects have unique names. Additional query operations retrieve items when provided names as parameters. For example, the query operation CLI::class(c:String):Class returns the Class object cls for which cls.name=c holds. In Fig. 2, we have for instance CLI6.class('Person') = Class9. The following listing shows how essential operations are implemented in the imperative language SOIL (Simple Ocl-like Imperative Language) that is part of USE. begin declare v:Object; v:=new Object(o); v.name:=o; v.properties:=''; insert (self.class(c),self.object(o)) into ClassObject_DT_RT end ... class(c:String):Class = Class.allInstances->any(e|e.name=c) assoc(a:String):Assoc = Assoc.allInstances->any(e|e.name=a) object(o:String):Object = Object.allInstances->any(e|e.name=o) ...
end Filmstrip model: The user interface model is automatically transformed into a so-called lmstrip model. A lmstrip model consists of snapshots that make system states from the user interface model (and the design time and runtime model) explicitly accessible. The purpose of the lmstrip model is to record a complete sequence of operation calls from the user interface model, so that one can trace the system development in terms of the snapshots and the transitions between the snapshots in form of operation calls. The lmstrip model includes all PredSucc associations that are used to describe the incarnations of a particular object in later snapshots. For example, in Fig. 2 for the object Ada in Snapshot5 its later incarnations are Object1 and Object3 with PredSuccObject links between them.
Object attributes could be handled by the property properties. In our examples we currently do not make use of attributes. The user interface model already provides the operation setProperties for this pupose.
Essential for our approach is the option allowing the developer to derive from the lmstrip object diagram specialized models that help to document and to better comprehend the design time and the runtime structure and behavior. The example models in Fig. 3 show how structural models like class or object diagrams and behavioral models like sequence diagrams may be derived. As future work, we plan to provide the option to de ne a domain-speci c visual syntax in order to make the diagrams in Fig. 3 look like proper UML class, object and sequence diagrams, as we have already indicated in the right of the gure. We envision that further UML diagram forms like communication or statechart diagrams may be derived from lmstrip object diagrams. For example, from a lmstrip object diagram, one may derive a protocol state machine for books specifying that the operations borrow and return alternate between states available and borrowed. 4
In Fig. 5 on the left side (part of the) the well-known OMG 4 level architecture
and on the right side essentials of our approach are shown. Roughly speaking,
we are mapping the M2 level to the M1 level. This has the advantage that the
InstanceOf relationship between M2 and M1 now becomes explicitly available as
an association and is made precise. Bridging the gap between design and runtime
aspects is one of the signi cant challenges when developing complex systems [
The problem discussed in this contribution was how to provide a generic infrastructure in that design time and runtime models can be applied and properties of these models can be retrieved. The goal was to achieve such properties in a semi-automatic fashion. We started from a design time and runtime model, proposed to develop a common user interface and then automatically generated a lmstrip model that is able to record development steps. From this lmstrip model, we were able to extract other models that represented artifacts occurring in the development process and that help in comprehending the development.
As future work, we want to develop language support in form of a visual domain-speci c language for the di erent layers, namely the design time, the runtime and the user interface layer on the basis of the lmstrip model. Tool support for the di erent layers must be extended, e.g., layout and view support for di erentiating between design time and runtime. Furthermore, larger case studies in particular with more advanced correspondence models and a wide range of derived diagram forms must check the applicability and practicability of the proposed approach.