=Paper=
{{Paper
|id=Vol-2405/07_paper
|storemode=property
|title=Developing User and Recording Interfaces for Design Time and Runtime Models
|pdfUrl=https://ceur-ws.org/Vol-2405/08_paper.pdf
|volume=Vol-2405
|authors=Martin Gogolla,Nisha Desai,Khanh-Hoang Doan
|dblpUrl=https://dblp.org/rec/conf/staf/GogollaDD19
}}
==Developing User and Recording Interfaces for Design Time and Runtime Models==
https://ceur-ws.org/Vol-2405/08_paper.pdf
Developing User and Recording Interfaces for
Design Time and Runtime Models
Martin Gogolla, Nisha Desai, Khan-Hoang Doan
Computer Science Department, University of Bremen, Bremen, Germany
{gogolla|nisha|doankh}@uni-bremen.de
Abstract. 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 or-
der to provide systematic and uniform access through operation calls to
design time and runtime items. Operation calls can be systematically
recorded in filmstrip 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 de-
rived for documentation and comprehension purposes.
1 Introduction
Recently, design time and runtime models of software as well as their connection
have attracted attention in research and development [3]. Utilizing models has
many advantages over considering mainly code as first class software develop-
ment artifacts, as models are able to abstract away from unneeded technical
details. However, a common agreement about essentials of design time and run-
time models and their relationship is still under discussion. This contribution
discusses one way of defining and using such design time and runtime models.
This paper applies modelling languages as UML (Unified Modeling Lan-
guage) [11, 12], which includes the OCL (Object Constraint Language) [10, 14].
UML and OCL support a wide range of systems. Our underlying assumption
is that UML and OCL are suitable also for specifying design time and run-
time models connected through a correspondence model [6]. In simple cases, the
correspondence consists of associations between design time and runtime items.
Roughly speaking, in comparison to the OMG 4 level MDA architecture, we only
use two levels and map the OMG M2 level to an M1 level (details in Sect. 4).
Assuming a completely specified design time and runtime model has already
been achieved, we propose here to introduce a user interface model and a model
to record design time and runtime development steps within a so-called filmstrip
model [4]. We then derive other standard software models from the recorded
steps and from the recorded model. These models serve for documentation and
comprehension. All examples have been implemented in our tool USE [5].
The rest of this contribution is structured as follows. Section 2 motivates our
approach by studying an overview example. Technical details about the approach
Copyright © 2019 for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
40 Martin Gogolla, Nisha Desai, Khan-Hoang Doan
Fig. 1. Overview Class Models: Design time, Runtime, User interface, Filmstrip model.
Developing User and Recording Interfaces for Design Time and Runtime Models 41
are discussed in Sect. 3. Section 4 shows related work. Section 5 closes the paper
with concluding remarks and future work.
2 Basic Idea: Design Time, Runtime, User Interface,
Filmstripping, Derived Models
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 filmstrip model for recording operation calls from the user
interface model.
Design time model: In the upper center, the figure contains the classes Class
and Assoc. Its purpose is to enable the specification of classes and binary
associations, not general associations. This can be regarded as a dramatically
simplified version of the UML metamodel for UML class diagrams (within
the OMG 4 level architecture).
Runtime model: In the upper right, the figure shows the classes Object and
Link. Its purpose is to make it possible to build objects and links for previ-
ously defines classes and associations. This can be seen as a simplified 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 dur-
ing 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 figure defines the class CLI (Com-
mand 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 defined.
Filmstrip model: In the lower part, the figure defined a filmstrip model for
recording operation calls from the command line interface. Every CLI oper-
ation becomes an OperationCall class so that operation calls are represented
as OperationCall objects.
Figure 2 displays an example execution for the discussed class diagram in
Fig. 1. In the middle bottom part, the USE commands and operation calls that
lead to the main object diagram in the upper part are shown. After three ini-
tialization commands, two classes, one association, two objects and one link are
constructed. In our view, the design time items are Person, Book, Borrows, and
the runtime items are Ada, UML and the Borrows link between Ada and UML.
The filmstrip model is responsible for recording the CLI operation calls and its
effects in a chain of snapshots. Different Snapshot objects represent the system
state at different points in time. The snapshots reflect that, in this case, classes,
associations, objects and links are added. The last snapshot Snapshot7 is dis-
played in more detail in the lower left of the figure and shows the final state
42 Martin Gogolla, Nisha Desai, Khan-Hoang Doan
Fig. 2. Example Filmstrip Object Model with Design-Runtime Model Development.
Developing User and Recording Interfaces for Design Time and Runtime Models 43
Fig. 3. Derived Example Models: Class model, Object model, Interaction model
44 Martin Gogolla, Nisha Desai, Khan-Hoang Doan
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 differently 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 first 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 different visual syntax
that is closer to the purpose of the considered fraction of the object diagram, as
indicated in the right of the figure.
3 Technical Realization
In our view, the architecture and operation mode of our approach can be visual-
ized as shown in Fig. 4. It captures the four different 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
define that an Assoc object (an association) is binary with exactly two im-
plicit association ends. Naturally, also more involved models can be used
as design time models. Please note that the PredSucc associations are part
of the filmstrip 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 filmstrip model.
Developing User and Recording Interfaces for Design Time and Runtime Models 45
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 different parts of a link are modelled by
two different 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 (Co-
mand 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 im-
perative language SOIL (Simple Ocl-like Imperative Language) that is part
of USE.
class CLI
operations
newClass(c:String)
begin
declare v:Class; v:=new Class(c); v.name:=c
end
newAssoc(a:String,fst:String,snd:String)
begin
declare v:Assoc; v:=new Assoc(a); v.name:=a;
insert (self.class(fst),self.assoc(a)) into ClassAssoc;
insert (self.class(snd),self.assoc(a)) into ClassAssoc;
end
newObject(o:String,c:String)
46 Martin Gogolla, Nisha Desai, Khan-Hoang Doan
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 filmstrip model. A filmstrip 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 filmstrip 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
filmstrip 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 exam-
ples 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 filmstrip 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 define a domain-specific 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
figure. We envision that further UML diagram forms like communication or
statechart diagrams may be derived from filmstrip object diagrams. For example,
from a filmstrip 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 Related Work
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
Developing User and Recording Interfaces for Design Time and Runtime Models 47
Fig. 5. Comparison of OMG 4 Level Architecture with Our Approach.
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 significant challenges when developing complex systems [3],
and several works are presented recently in this direction. In [15] the need to
shift model-based assurance cases from design time to runtime is discussed. In
this paper, the authors conclude that runtime assurance cases could be a po-
tential solution for assuring safety-related Cyber-Physical Systems. A solution
introduced in [1] makes executing UML design models directly on embedded mi-
crocontrollers possible thanks to a model interpreter. In [13], a set of modeling
patterns extracted from the literature is introduced. These patterns are orga-
nized in a pattern language and consist of the specification for setting up the
models and the environment for the analysis of runtime behavior utilizing design
models. The authors in [9] introduce ModelPlex, a method which combines offline
verification of Cyber-Physical System (CPS) models with runtime validation of
system executions for compliance with the model. In [7], the authors present a
design pattern, Aggregate Callback, for building DSL-based models in a robust
and flexible way by enforcing constraints in the model so that the consistency of
the output is guaranteed. The approach in [2] discusses the Requirements Mod-
eling Languages (RML) and proposes a conceptual distinction between design
time and run time requirements models. Run time models extend design time
models with additional information about execution of system tasks.
5 Conclusion
The problem discussed in this contribution was how to provide a generic infras-
tructure 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 filmstrip model that is able to record development steps. From this filmstrip
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-specific language for the different layers, namely the design time, the
48 Martin Gogolla, Nisha Desai, Khan-Hoang Doan
runtime and the user interface layer on the basis of the filmstrip model. Tool
support for the different layers must be extended, e.g., layout and view support
for differentiating 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.
References
1. Besnard, V., Brun, M., Jouault, F., Teodorov, C., Dhaussy, P.: Embedded UML
model execution to bridge the gap between design and runtime. [8] 519–528
2. Borgida, A., Dalpiaz, F., Horkoff, J., Mylopoulos, J.: Requirements models for
design- and runtime: a position paper. In Atlee, J.M., Chechik, M., France, R.B.,
Gray, J., Paige, R.F., Rumpe, B., eds.: Proc. 5th Int. Workshop Modeling in Soft-
ware Engineering, MiSE 2013, IEEE Computer Society (2013) 62–68
3. Brunelière, H., Eramo, R., Gómez, A., Besnard, V., Bruel, J., Gogolla, M., Kästner,
A., Rutle, A.: Model-driven engineering for design-runtime interaction in complex
systems: Scientific challenges and roadmap - report on the mde@derun 2018 work-
shop. [8] 536–543
4. Gogolla, M., Hamann, L., Hilken, F., Kuhlmann, M., France, R.B.: From Ap-
plication Models to Filmstrip Models: An Approach to Automatic Validation of
Model Dynamics. In Fill, H., Karagiannis, D., Reimer, U., eds.: Proc. Model-
lierung (MODELLIERUNG’2014), GI, LNI 225 (2014) 273–288
5. Gogolla, M., Hilken, F., Doan, K.H.: Achieving Model Quality through Model Val-
idation, Verification and Exploration. Journal on Computer Languages, Systems
and Structures, Elsevier, NL (2017) Online 2017-12-02.
6. Kästner, A., Gogolla, M., Doan, K., Desai, N.: Sketching a model-based technique
for integrated design and run time description. [8] 529–535
7. Kövesdán, G., Asztalos, M., Lengyel, L.: Aggregate callback - A design pattern for
flexible and robust runtime model building. In Hammoudi, S., Pires, L.F., Desfray,
P., Filipe, J., eds.: Proc. Modelsward 2015, SciTePress (2015) 149–156
8. Mazzara, M., Ober, I., Salaün, G., eds.: STAF 2018 Collocated Workshops. Volume
11176 of Lecture Notes in Computer Science., Springer (2018)
9. Mitsch, S., Platzer, A.: Modelplex: verified runtime validation of verified cyber-
physical system models. Formal Methods in System Design 49(1-2) (2016) 33–74
10. OMG, ed.: Object Constraint Language, Version 2.4. OMG (2014) OMG Docu-
ment, www.omg.org.
11. OMG, ed.: Unified Modeling Language, Version 2.5. OMG (2015) OMG Document,
www.omg.org.
12. Rumbaugh, J., Jacobson, I., Booch, G.: The Unified Modeling Language 2.0 Ref-
erence Manual. Addison-Wesley, Reading (2003)
13. Szvetits, M., Zdun, U.: A pattern language for manual analysis of runtime events
using design models. In: Proc. 23rd European Conf. on Pattern Languages of
Programs, EuroPLoP 2018, ACM (2018) 15:1–15:24
14. Warmer, J., Kleppe, A.: The Object Constraint Language: Precise Modeling with
UML. Addison-Wesley (2003) 2nd Edition.
15. Wei, R., Kelly, T., Reich, J., Gerasimou, S.: On the transition from design time
to runtime model-based assurance cases. In Hebig, R., Berger, T., eds.: Proc.
MODELS 2018 Workshops. CEUR Proceedings, Vol. 2245 (2018) 56–61