Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Models in Model-Based Engineering (MBE) are graph structures and as such they are typically expressed using graph-based representations; e.g., class and object diagrams are represented as nodes and edges in a graph. This sort of representation permits a natural, faithful and comprehensive description of the models and of their views, and its operation by theories and tools. However, graph-based descriptions of large systems can become cumbersome and difficult to understand, query and analyze by human users due to their size and complexity [4, 8].

Fig. 1.
figure 1

Example interaction as UML communication diagram.

Full size image
Fig. 2.
figure 2

Example interactions as spreadsheet.

Full size image

The modelling world has few connections to the spreadsheet world, despite the fact that spreadsheets provide a widely used description technique. Spreadsheets are able to represent complex information in a clearly structured way in tabular form. Together with relational databases, now they probably constitute the most used way of presenting and manipulating information.

This paper explores the use of table-based representation for artifacts occurring in MBE, as opposed to their traditional graph-based representation. As an example, we show how object interaction diagrams that are traditionally represented as UML sequence or communication diagrams [9, 12], can be naturally expressed in tabular form; and how views on such models can be easily realized by spreadsheet queries. In principle, the table-based representation we show here can be used for all other UML-like models as well, hence facilitating the creation of views and their representation in a more appropriate manner for many purposes.

2 Preliminaries

The context of our work is the UML tool USE (Uml-based Specification Environment) [5] that allows the developer to describe (a) system structure with a class diagram incorporating OCL (Object Constraint Language) invariants and (b) system behavior with OCL contracts, UML state machines and operation implementations in the language SOIL (Simple Ocl-like Imperative Language) that combines OCL expressions with control flow. Models can be executed by means of scenarios that can be documented with UML sequence and communication diagrams. These two diagrams are the UML form of showing object interactions.

Our running example is a simple variant of a toll collecting system for trucks moving on a road layout described in more detail in [5]. Figure 1 shows (a) the class diagram, (b) a communication diagram for a scenario with 15 major messages involving three towns (Hamburg hh, Berlin b, Munich m) connected by roads and one travelling truck as well as (c) an object diagram reflecting the system state after one particular message (number 12). Messages possess submessages indicated by structured numbers, e.g., 12.1, 12.2, 12.2.1, 12.2.2, 12.2.3.

The challenge for us was: how can we achieve a comfortable view mechanism on complex interactions consisting of message exchanges among objects? Different views may want to filter the interactions along different aspects like message kind (e.g., creating or destroying objects or inserting or deleting links), message order (through the numbering system) or involved object types.

3 Representing Interactions in Spreadsheets

We now want to explain how the graphically displayed message exchanges from the communication diagram in Fig. 1 can be given in table-based form. Figure 2 shows (part of) the object interactions in a spreadsheet. The columns describe (1) the structured message number, (2) the message in instantiated form, (3) the message in generic form, (4) the message kind, (5) a flat message number, and (6) the message call depth. The distinction between columns (2) and (3) can be explained best by message 12.2.3 having flat number 34: the generic form shows the SOIL statement from the “move” implementation “self.debt := self.debt+1” whereas the instantiated form shows concrete, substituted values “self.debt := 2”. The table-based representation contains even more details than Fig. 1, as attribute initializations and operation result values are shown. Every present information on messages is stated in the table. Apart from the depicted attributes, the table could contain further information, such as the sender and receiver of each message.

Fig. 3.
figure 3

Example query on interaction as spreadsheet query.

Full size image

4 Views on Interactions as Spreadsheet Queries

Let us now turn to the question how complex interactions as present in Fig. 2 can be viewed and filtered for particular purposes. The developer will not be interested in all messages with all details, but will like to see only messages relevant in a particular context. For example, the developer might want to achieve a rough overview on the creation of the road layout and the operation calls in the later part of the scenario.

The spreadsheet query in the upper, grey-shaded part of Fig. 3 serves this purpose. The result of the query is stated in the lower part.

Fig. 4.
figure 4

(from [9]).

UML interaction metamodel

Full size image
Fig. 5.
figure 5

(from [5]).

Send message event as an instance of the UML metamodel

Full size image

Thus, by expressing spreadsheet queries that can be formulated in the spreadsheet itself and that can use present constants and simple, but effective operators, the developer is able to interactively formulate requirements on the desired view and to satisfy the current information needs.

In order to compare this approach with similar queries on the UML metamodel, Fig. 4 shows the fragment on the UML metamodel that deals with Interactions. As we can see, every message requires the specification of several instances of class MessageEnd and of separate objects in case of arguments. For example, Fig. 5 shows how only one of the 41 messages in the Interaction is represented as an instance of the UML metamodel, namely the “enter(hh)” message. This illustrates the complexity required for navigating through these kinds of instances for expressing queries that can be easily specified in a spreadsheet.

5 Conclusion

So far, most efforts for connecting the spreadsheet and Model-Based Engineering worlds have focused on representing spreadsheets as models [10] in order to make use of MBE concepts, mechanisms and tools to improve the specification, development, debugging, maintenance, and evolution of spreadsheets—see, e.g., [1, 2] and many of the SEMS workshop series papers [6, 7].

In this paper we have discussed an example that aims at showing the benefits of using a tabular representation of a model as opposed to its graph-based representation. In fact, models of non-trivial systems can become very complicated and their representation as spreadsheets can be quite simple and straightforward. In this manner queries can be formulated in a natural and user-oriented way, too. Furthermore, we can use all the powerful operations provided by spreadsheets to implement some operations on the views, or even make use of advanced features for querying spreadsheets [3]. We could also keep them in sync, so that certain changes in the views (the spreadsheets) are propagated to the models, updating them accordingly.

Of course, each notation is more apt for particular goals, and probably the best approach consists of combining table- and graph-based representations, using one or the other depending on the kind of user querying the model [11], and on the operation we want to perform on the model. In the USE context we already count on graph- and table-based representations for object diagrams and interactions. Counting on spreadsheet-based representation of other aspects, such as complete object diagram evolution, would be desirable too.