The Visualisation of Symbolic Transition Systems

(1)

The Visualisation of Symbolic Transition Systems

Bas Meesters

15th July 2015

(2)

Abstract

Testing is one of the activities to ensure high quality in software systems. It can be quite the exhaustive task to test with enough quality certainty. Model based testing is a method in which the testing can be done automatically, while still being thorough. First a model of the software under test needs to be created. These models can grow enormously, and are hard to understand without proper tooling. Visualisations can be used to get this insight in the model because of the capabilities of the human system. Visualisations are often done with either presentation or exploration of the data in mind. The research described in this thesis is done at the company Axini and nds solutions to the visualisation problems manifested in their model based testing tool. This tool uses symbolic transition systems as modelling technique. To nd answers to the research questions a prototype was implemented using both presentative and explorative visualisation techniques. Verication was done by analysing the visual syntax of the prototype. Validation was done by conducting and analysing the results of usability questionnaires.

Master Thesis Univeristy of Amsterdam

Supervisors Dr. Vadim Zaytsev (UvA)

(3)

Introduction

Introduction. One of the most important activities during software development to ensure high quality is testing [1]. Since doing this well can be quite exhaustive and a complex task, dierent paradigms have been created to do this systematically and thorough. A quite novel and popularity gaining technique nowadays is model based testing [2]. During this activity a lot of automation takes place, making the process less of a laborious task. This, while still having the guarantee that the system under test or SUT is tested thorough. First a model of the SUT is created based on the specications of this system. As a result, test oracles and test cases can be generated automatically, and are provably valid [2]. Naturally, the model needs to be modelled correctly and conform to the actual implementation for generating valid test cases.

Dierent techniques can be used for modelling these systems, each with its own purposes, advantages and disadvantages. Often the modelling is done using a variation of state transitions systems. These transition systems can grow enormously and without proper tooling do not provide a lot of insight on their own. Visualisations can be used to eectively and eciently get this insight because of the capabilities of the human visual system [3]. Often it is easier to comprehend information compared to textual or oral representations of the same data. The biggest challenge in visualizing data is usually that the information present is too much to visualize everything, and thus is still not insightful without providing proper abstraction mechanisms. Visualisation is often done with either presentation or exploration in mind [3]. The rst focuses on commu-nicating the structure of the information to the viewer, giving a general insight in the whole data. Whereas the latter focuses on giving the viewer opportunities to nd patterns or properties earlier unknown. It allows users to form hypotheses about the data visualized, and gives possibilities to go stepwise through this data to get a deeper understanding of individual parts.

Motivation. Axini is a company which created a model based testing tool. The tool called Test Manager provides a modelling feature, and allows analysis of the automatically created and executed tests. The model visualization of Test Manager encounters some common problems seen in information visualization, and is in need of improvement. The research described in this thesis nds answers on how to solve these visualisation problems in Test Manager.

(6)

Modellers using Test Manager can have dierent goals in mind. It is possible that the modeller wants to communicate the model to other people. The visualisation then needs to be easy to comprehend. But it can also be used by the modellers themselves to get a deeper understanding of the inner workings of the software they modelled. In this case, the visualisation needs to help in nding relationships unknown before. The main hypothesis of this thesis is that both presentative and explorative visualisations can be used together to get an even more pleasing result.

In order to conduct the research, Axini allowed me access to Test Manager, and provided me with the knowledge needed to use this tool successfully. To nd answers to the research questions, a visualisation prototype was created, which makes use of the available software assets and resources.

Outline. The thesis is structured as follows. In the second chapter the relevant work needed to start this research is described in detail. Model based testing, the modelling technique used in Test Manager, and visualisation are discussed. The dierence between presentative and explorative visualisation will be made clear, and how both can be realized using various techniques.

The third chapter is about the scope of the research. This includes the technologies and techniques already present in Test Manager, and an example system to show how the modelling is done. In the fourth chapter this line of thought is continued and the research approach is presented. First the required improvements for the visualisation in Test Manager are listed, after which the research approach creating a prototype and validation method are shown. As mentioned above, the main research question is concerned with the combination of presentative and explorative visualisation methods. The other sub questions are related to this main question and look at possible techniques in more detail. A last point of interest is interaction. What are intuitive ways that a user can manipulate viewpoints and nd relevant information?

The fth chapter will show the results of creating the prototype. These results will be supported with a lot of images, using the example system to show the workings of this prototype, and how they try to solve the challenges. After the results are shown the validation of the prototype will be explained in Chapter 6. The validation is split into validation of the correctness of the visualisation, and the validation of the usability. The last two chapters will discuss the results and conclude this work. At the end a bibliography, and an appendix can be found to which will be referenced throughout the thesis.

(7)

Chapter 2

Related work

In this chapter the relevant information found for the research conducted is described. It contains three parts. First the notion of modelling and how it is done at Axini is explained. To understand what should be visualized, it rst needs to be made clear what information is actually present in such models. Afterwards visualisation in general will be discussed. When does visualisation add value, and what kind of patterns are used often in amplifying cognition? Lastly, visualisation techniques considered for the prototype will be shown.

2.1 Modelling of software systems

Model based testing is a way to automatically create and execute tests for the SUT based on a model created beforehand [2]. Dierent techniques to model the SUT can be used depending on what parts of the system need to be tested and how. Axini makes use of symbolic transition systems from now on called STSs which are a extended variant on labelled transition systems [4]. This testing is a form of formal, specication-based, active, black-box, functionality testing. This means that the functionality of the SUT what the system should do is tested in a controlled manner without any knowledge of the inner workings, and solely based on the specication of the system [2]. The specications are used to create a model, and using this model test cases can be generated automatically.

2.1.1 Labelled Transition Systems

Labelled transition systems are a variant on the well-known state transition systems. Structures consisting of states (nodes) and transitions (edges) between them and be formalised in the following formula [2]: < S, S0, L, T >

Where

• S is a countable set of states. • S0∈ S is the initial state.

(8)

• T ⊆ S × (L ∪ {τ }) × S with τ /∈ L is the transition relation. τ is the unobservable action, an action of which the eects can be seen, but not the contents of the action itself. It can simply be seen as an empty label. The transition relation is thus a subset of all possible combinations of states and transitions between them.

To illustrate what a labelled transition system looks like a simple example can be seen in Figure 2.1. The model shows a simple coee and tea vending machine, in which the user start in the initial state named start. After putting 50 cents in the machine, the system translates to the state contain 50 cents. From here, the user can choose for pressing a dispense tea, or dispense coee button. After the chosen drink is dispensed the process is nished, and the system enters the nal state done. If the user would be able to dispense another drink, an arrow from done to start should be drawn as well to create a cycle. When cycles occur, systems have an innite amount of traces which should kept in mind for selecting test cases. Though the amount of traces is innite, each trace has nite length. In practice, a smart selection of test cases needs to be found to test the system with a desirable degree of coverage.

Figure 2.1: Example labelled transition system of a vending machine.

As can be seen from the gure, transitions accompanied with question marks show that the system accepts user input, and transitions marked with a exclamation mark show responses from this system. The model is simplied as only correct inputs are taken into account. Throwing in other money values, or pressing a button without throwing in money, are no valid actions and therefore not modelled.

(9)

2.1.2 Symbolic Transition Systems

When the specication of the software makes use of data structures with very large or innite data domains this can lead to what is known as state space explosion [4]. Every value in these large domains can lead to another state from a new transition, resulting in an enormous amount of states and transitions. Taking the example again from Figure 2.1, a simple extended version allowing for other coins added in any order has as consequence that the model grows many times over. Using coins of 0.05, 0.10, 0.20, and 0.50, there are already ten dierent money values each creating a new state and many new transitions below 0.50. If an excessive amount of money is accepted as well, the amount of states and transitions grows even innite. Since most software systems have much bigger data domains than displayed in the example, it is of great importance to tackle this problem. It can be countered by extending the denition of labelled transition systems with an explicit notion of data and data ow by using variables, constraints and update functions to create symbolic transition systems in the following manner [4]:

< S, S0, L, V, i, I, T >

Where

• S, S0, and L remain the set of states, the start state, and the set of transitions.

• V is a nite set of location (global) variables used throughout the whole model. • I is an initialization of the location variables.

• I is a nite set of interaction (local) variables disjoint from V, of which each variable is used only at one transition.

• T is again the transition relation, only extended with new information. For each relation a restriction, a gate, and an update function are added. The restriction is a boolean function using the location an interaction variables for determining if the transition is allowed to proceed. If not, remain at the same state. The gate contains the label of the transition, and a set of interaction variables used in the restriction. The update function is used to update the location variables after the transition is allowed to proceed.

An STS is thus very similar to a labelled transition system, only location and interaction variables are usable to get from one state to another through a transition. An extended version of the vending machine can be seen in Figure 2.2. The only location variable in here is _total, representing the total amount of money in the machine, and it is initialized on 0. The interaction variable is _x, the amount of the coin thrown in last. Now, coee or tea is only dispensed if the amount of money is sucient. And if so, the _total variable will be changed accordingly. Finally, the remaining amount of money is dispensed and the system enters done. With only the help of one extra state and two extra transitions, the system is able to handle all variations in money amount.

Both modelling techniques are simplied regarding the formula for an easier understanding. A more strict formalization and a sound and complete test derivation algorithm of both of these modelling techniques can be found in the work of Tretmans and Frantzen [2, 4]. This is out of the scope of this research and further not relevant for the visualisation of STSs.

(10)

Figure 2.2: Example symbolic transition system extending the vending machine with data.

2.2 Information visualisation

In this section various interesting points on information visualisation will be explained. Why the use of visualisations is a suitable technique for transmitting information, the value visualisation can have, and the dierent types of visualisation will all be described below.

Visual perception system. According to information theory the use of the visual canal of the human perceptions is best suited to transfer knowledge to the brain [3, 7]. It is easier to see the overview of the system, recognize patterns, reduce search eort for information, enable perceptual inference operations, and memorize the data present compared to textual or oral presentations of the same data [5]. This is because one of the features of this human visual system is pre-attentive processing, which allows some visual patterns and properties to be processed very fast and accurately [5]. Around 25% of our brain is devoted to vision, more than the other senses combined [7]. Examples of these patterns are symmetry, similarity, closure, relative size, proximity, and continuity. Examples of properties are shapes, colours, motion, spatial position, and texture [6]. Each of these can be exploited to help users make sense of data actually visualized. An example of pre-attentive processing is shown in Figure 2.3. The black circle in (a) can be detected by using pre-attentive processing, whereas the black circle in (b) cannot because there are no distinct visual features compared to the other elements [8].

(11)

Figure 2.3: Example of pre-attentive processing [8].

Value of visualisation. Though certain visualisation techniques have proven to help in the understanding of data in general, it is hard to give an exact value of a visualisation [5]. It becomes even harder to give a good estimated guess of this value when dealing with domain specic information already present in the minds of the users. Also, when no interesting relations can be found in the visualisation, it is hard to pinpoint if it is the lack of a good visualisation, or simply because there is no relation to be found.

The denition of what a visualisation is should be made more explicit in determining its value [5]. In this sense, it will be seen as the technology and techniques used to get a visual result. It has to be a correct representation of the data used in an ecient and eective manner. When a user creates a mental map of the data it should not conict from the actual data being visualized. Optimally, users should not be able to arrive to wrong conclusions using the visualisation. Especially in interaction based visualisations it is possible to keep changing the visualisation until a desired result comes out. The visualisation has to give some new insight to the user in a better or quicker way than with an alternative representation to be ecient [3].

Visualisation types. Visualisations can roughly be grouped into one of two categories regarding their goal. Presentation trying to understand and share the already available information or exploration, trying to nd new information [5]. The rst allows users to quickly get insight in the structure and overview of the data presented. It should be relatively easy to understand what the data is about, and how the bigger parts are related. The latter allows users to go stepwise through the contents of the data without any particular direction in mind and nd information unknown beforehand. It helps in forming new hypotheses about the data rather than answering them [5].

Another view on visualisation proposed by Chen et al is that visualisation is trying to visualize data, in-formation, and / or knowledge, which indicate dierent levels of abstraction and understanding [9]. Data visualisation is used to get a general insight in what data is actually telling. Information visualisation is concerned with data mining extracting interesting patterns or attributes in the data and knowledge discovery [9]. Knowledge visualisation takes into account the knowledge of the user already present, and provides mechanisms to share this knowledge among users. Since the models created for model based testing are carefully constructed, they do contain little to no noise data. Information and knowledge visualisation is therefore interesting for visualizing STSs. How can the knowledge actually modelled be visualized intuitively and provide value in understanding the model and test case results even better?

(12)

2.3 Graph visualisation

As state transition systems are basically an extended version on directed graphs, the same techniques may be used for visualizing them. Often the visualisation of directed graphs is a variation of node-link diagrams, nodes and directed edges connecting them [6]. This form of visualisation is mostly used for presentation of the data visualized. When done well, it gives insight in which components topologically belong together, how you get from one node to the other, and the general structure of the data. Examples of such node-link diagrams will be shown in Section 2.3.1.

Other approaches for the visualisation of graphs are attribute diagrams and analysis diagrams [19, 20]. In each of these, it is harder to create a mental map of the data, but easier to nd relationships between entities. Therefore these are more suitable for exploration of data. Both of these approaches will be shown in Section 2.3.2.

2.3.1 Visual presentation of graphs

The biggest problem in node-link diagram visualisation is often the amount of data that needs to be presen-ted. As Herman et al have shown in their work, there are various techniques to deal with this overload of data representation [10]. Obvious desirabilities are reducing of overlaps, reducing of edge crossings, distrib-uted edge lengths, evenly distribdistrib-uted node locations, and predictability. Similar graphs should give similar representations, and it should be clear which components are connected to which other components. Next to the presentation, Herman et al also recognized navigation and interaction as very important aspects of information visualisation [10]. Zooming and panning are popular techniques used in various elds. Zooming can be done geographically in which literally the whole visualisation is blown up and only part of it is visible or semantically, in which details are shown depending on the zoom level. This requires an upfront selection of detail hierarchies to be displayed on the dierent zoom levels. The most natural way of abstracting is by clustering groups of states based on certain attributes. A well-known clustering technique is the grouping of nodes on certain attributes, such as the connectivity between states (also called the node distance). See Figure 2.4 for an example of graph clustering. The clustering can also be used in combination with semantic zooming, by showing a cluster as a single node until a certain zoom level is reached where after the contents of the cluster become visible again [25].

Focus and context. Another general solution for dealing with an overload of information is focus and context [10]. Again this can be done by literally blowing up part of the graph while showing the overview in less detail (Figure 2.5), or by semantically showing more details on part of the graph in context of the whole. The advantage of this technique is that specic information can be more easily found and understood, while still being able to place the new found information in context of the whole [10].

Edge bundling. Often in graphs, there are many more edges than nodes and as a result the visualisation becomes unreadable because of edge crossings. A way to counter that too many edge crossings happen is by edge bundling [12]. As the name suggests, it simply bundles edges going in the same direction (Figure 2.6). Research has shown that it does improve reaction times in understanding high level connectivity [12]. However, it has also shown that it reduces accuracy in path tracing tasks, so it has to be taken in careful consideration before applying it.

(13)

Figure 2.4: Example clustering in a node-link diagram based by node distance [10].

Figure 2.5: Focus and context example using the well-known sh eye technique [11].

(14)

Force layout. Nowadays a popular approach for graph layout visualisation is force layout. It simulates gravity and forces between nodes in such a way that nodes repel each other, but edges try to be as short as possible. The simulation of force goes on until a balance is found. Clusters are formed as well since highly connected nodes will attract each other and push other groups of nodes out. It has shown to give pleasing results, though it also has a high unpredictability factor since the same graph can be displayed in many ways using this simulation [13]. If interaction is supported, a small repositioning can highly eect the new layout. Furthermore a small change in the graph can also result in a dierent looking visualisation.

Spritzer and Freitas countered this by using a layout algorithm rst and thereafter use the force layout simulation on the resulting graph [13]. They added boundaries and magnets in such a way, that the graph was more predictable and less likely to change the structure after interaction. On top of the normal presentation they were able to assign attributes to the magnets so the user could analyse, and change the graph, to their liking. This is also an example of a visualisation combining presentative and explorative techniques to get a more pleasing result.

Layered graph drawing. In 1981 Sugiyama added a big contribution to graph layout algorithms by publishing his rst work on hierarchical layering and displaying of graphs, after which many approaches followed using this as a basis [14]. Using a four step approach the nodes and edges are placed according to their hierarchy with as least edge crossings as possible [15]. A variation on this layout algorithm can be seen in Figure 2.7. As the hierarchy of nodes plays a big role, this technique is most useful when the data has such a natural hierarchy. STSs for example have a clear order and are naturally layered by this. This graph layout algorithm is therefore a big contender for a possible solution for visualizing STSs.

Visualizing transition systems. Big contributors in the area of visualizing state transition systems are Van Ham, Van der Wetering, Pretorius, and Van Wijk. Around a decade ago they did a lot of research and came up with multiple solutions and prototypes to visualize and analyse state transition systems. The rst and most forward approach they took was based on the layered graph drawing of Sugiyama (Figure 2.7). They created a tree-like structure in the form of a backbone for the transition system. The main idea is that states further from the root will appear deeper into the tree. States which are at the same depth can be clustered in one group to reduce the overhead for rendering and understanding [16].

On top of this backbone approach Van Ham et al focused on cognitive attributes pre-attentively processable such as symmetry and proximity. Similar sub-graphs should be easy to recognize, and states and transitions belonging together should be visualized together. The biggest advantage of this technique is that you have a clear data ow in your graph and certain patterns can be recognized quickly and accurately. The execution paths have a clear direction and similar parts in the program will also have similar branches. Important states like the root and the terminating states can be found quickly as well. With the help of some more case studies Van Ham et al could indeed conclude that using their visualisation tool was an eective way to get insight in the data presented [17].

A few years after this Ploeger and Tankink improved the tool further by reducing overlaps and adding a simulation feature as well, as can be seen in Figure 7 [18]. Left the visualisation of a state transition system can be seen, and right a sub menu can be used for navigating and understand detailed information. They make use of 3D structures to be able to put more information in a smaller plane and use 3D interaction to navigate. Considering Figure 2.8, the circle A shows the current state in the simulation. The cyan coloured

(15)

Figure 2.7: The Sugiyama based approach by Van Ham et al [16].

(16)

states show possible next states, also highlighted in circle B. The yellow coloured circle in C is the current selected next state, and all magenta coloured states are states visited earlier, also highlighted in circle D. Circle E gives an overview with a list of states which can also be used for navigation between states. Refer to their papers for more details on the exact workings of their prototypes[16, 17, 18].

2.3.2 Visual exploration of data

Attribute based visualisation. The approach shown in the previous section did help in understanding how a system is structured but failed in helping users answer certain questions about these systems. For example: whether, when, and why undesirable states are reached? [19]. The reason traditional directed graph representations fail in this is mostly because of all the amount of states is (still) overwhelming. Additionally, transition graphs describe system behaviour at a low abstraction level, while analysts possess deep domain knowledge [19]. Pretorius and Van Wijk came up with another approach to deal with this semantic gap, where states are not clustered on topological structure, but on the attributes they actually contain.

Figure 8 shows a sketch of their approach. Using this approach, the user is able to select a subset of node attributes, where after the system clusters the graph according to this selection. The root contains all the nodes, and further down the tree-like structure the nodes split on values for the selected attributes in the specied order (Figure 8a). Behind this tree-like structure a bar chart is placed to show the size of each cluster (Figure 8b). A last step is adding additional edges between individual states at the leaves to show how they are topologically connected (Figure 8c).

Analysis based visualisation. A second approach of Pretorius and Van Wijk is also focused on the attributes states and transitions contain, and has very little attention for the topological structure of the system. The dierence with the above approach is that states are not structured according to selected attributes, but based on relationships between states and transitions beforehand, as these contain information interesting for analysts [20]. Questions which should be answerable lay more in the category of how to get from one state to another. Which labels are used the most, and what kind of states do they connect? An example of this approach can be seen in Figure 9. The centre of the approach shows a list of all labels, or actions possible in the system (Figure 9a). For each source state a line is drawn to its target state through the transition it crosses. States which share actions with other states can in such a way easily be recognized. Again, attributes can be chosen according to which the states are divided in the specied priority (Figure 9b and Figure 9c). Important labels can be more easily recognized, patterns can be more easily found, and states can be easily grouped based on selected attributes. This is of course a simplied view, refer to their papers for more detailed information [19, 20].

(17)

Figure 2.9: A sketch of attribute-based clustering approach of Pretorius and Van Wijk [19]

(18)

Chapter 3

Visualisation in Test Manager

In this chapter the details about the scope and setting of the research conducted will be displayed. The rst section will show how STSs are implemented in Test Manager, and what purposes the visualisation of those STSs serve. The second section will list the requirements for improving this visualisation. In the last section an example system will be shown to clarify how the common visualisation problems manifest themselves in the visualisations of Test Manager. In Chapter 5, this example will also be used to show possible solutions to these visualisation problems. In the last section the required improvements on Test Manager are listed.

3.1 Implementation and visualisation of STSs

The implementation of modelling in Test Manager comes very close to the theory of STSs. There is a collection of states with transitions between them. As is normal in STSs, the transitions contain a label, a kind (stimulus or response), a constraint, and an update function. Axini added processes, channels, and behaviours sub routines on top of the normal attributes to create a more hierarchically structured model. Processes are the highest form of elements and normally contain one or multiple behaviours connected to each other. Channels are a way to have dierent parts of the model communicate with each other. And behaviours allow for similar parts to be modelled once, and create a more comprehensible layered model. The behaviours can be divided in non-terminating and terminating behaviours. Though, not strictly necessary, non-terminating behaviours are used often as the second highest level of elements and contain at least one cycle to the start of the behaviour. Terminating behaviours are a lower level routine often used multiple times and contain no cycles to the start of the behaviour.

Test Manager's current visualisation makes use of a variant on layered graph drawing style of Sugiyama [14]. The start of the model is visualized on top where after levels of states are added according to their distance to the root. An example image of their current visualisation tool can be seen in Figure 3.1. The gure is split in two, to show the whole visualisation, and a more detailed part of the visualisation.

States are drawn as circles with arrows representing the transitions. The square grey blocks show a collapsed behaviour hiding the contents of the behaviour itself. Each of these behaviours contains a visualization similar as shown in Figure 3.1. The transitions show their kinds, labels, constraints, and channels just as plain text next to the transition lines themselves.

(19)

Figure 3.1: Test Manager's visualisation

The visualisation serves three main purposes currently. The rst is the check if the textually modelled STS complies with the view of the modeller and communicate the results to other users. So, for a visualisation to succeed in this matter it has to comply with the mental model of the creator. It also has to be easy to understand and share this view with ones who did not create (parts of) the model. Secondly, when tests fail the visualisation is the foremost used tool to get insight in what went wrong and how to improve it. What were values of variables during execution, and how did they inuence the execution path? Lastly, it serves as a way to analyse the model. Common questions asked in this category are: Where can states and transitions be found? and Does it comply with the specications given?. For this, the visualisation needs some mechanism for users to search and quickly understand deeper relationships between parts of the model.

(20)

3.2 Visualisation requirements for Test Manager

The current visualisation in Test Manager encountered some of the general visualisation problems mentioned in the second chapter. There is too much information to display at once and as such Axini decided that the behaviours should be collapsed initially. The contents of the behaviour are viewable in a separate window on clicking. There is no ability of zooming or panning, as the technology used does not provide such functionalities. The graph rendered is not interactively changeable to show or hide information. States and transitions are always displayed with the information they contain. The consequence of displaying all this data is that a lot of text is displayed and sometimes overlapping as well. See Figure 3.2 for an example image of the visualisation tool.

As the current visualisation is not ideal, Axini is interested to know in how this can be improved. Having the daily task and current setting in mind they could construct a non-prioritized list of requirements:

• One visualisation in which zooming, panning and abstraction mechanisms are provided so the user can switch between a general overview and detailed information about certain parts of the model. Sub graphs should not as it is now be opened in a separate window, as context of the whole is lost. • Information should only be visible when needed, also automation in this process is desirable. For

instance, state and transition labels should show relevant information and not overlap. The information should be hidden when not required and easily accessible when required.

• Users should be able to nd specic states and transitions quick and easy, and preferably able to nd relationships or interesting attributes in the model when present.

• Now, how variables inuence execution paths is tested using a textual approach, this should be included in the visualisation. The change of value should be clear, where it changes and what the consequences are.

• The nding, ltering and / or highlighting of certain attributes associated with states or transitions such as most visited transitions, or states where after no actions are possible anymore should be supported. Another functionality aligning with this requirements would be the support of asking questions to the visualisation. Questions can be concerned with any of the the attributes in Test Manager's take on STSs.

• Test Manager is a Software-as-a-Service (SaaS) application with Ruby in the back-end. The STS are thus written in Ruby and visualized in the web browser. A similar approach or at least an approach suited to work with the existing technology is desired.

Even more requirements could be determined, but because of pragmatic reasons, they are not listed and not taken into account during construction of the nal prototype.

3.3 Running example: SCRP system

Normally e.g. in a grocery store a customer arrives at the checkout after which the cashier starts to scan the items manually, and at the end gives a receipt to the customer. The customer pays and the cashier is ready for a new customer. The SCRP takes over the scanning and transaction procedure, so no cashier is needed anymore. On top of this the system is able to maintain article registration journals and create daily turnover reports in the traditional way.

(21)

Figure 3.2: The ve main behaviours of the SCRP system visualized using the current visualisation of Test Manager

The example image used in Figure 3.1 is part of the SCRP (Scan-ow Cash Register Protocol) system. It is a generic interface to a self-scanning checkout machine, and has a publicly available model created by Axini. The model has quite a few undesirable properties, making it a good example for showing how common visualisation problems manifest, and how the prototype created during this research tries to solve those problems. It is a large model, with cycles, big constraints, and is quite dense. Throughout the rest of the thesis it will be used as a running example. For every problem encountered an image will be shown using this model and how the prototype tries to solve this problem. To understand these images better below the specics of this model will be shown.

The SCRP system can be divided into ve overarching meta-states modelled as non-terminating behaviours which contain the actual states and transitions as prescribed by the STS theory (Figure 3.2). As can be seen, all the behaviours belong to the same process called scrp. The system starts in the ss_o behaviour. Basically, the system is non-operational but able to be started. After this, the system can be put in as_idle, meaning that the system is turned on and in a standby modus. It is ready to receive customers but not receiving anything yet. When a customer arrives at the checkout, he starts putting groceries on the machine, and the machine enters the as_open behaviour. The user account is opened or created in the case of an anonymous user and groceries are processed one by one. After all groceries have been scanned and recognized a bill is presented to the customer, and the machine enters the as_closed behaviour. After the payment has been nished the system goes to as_ending. Next, it returns to as_idle, so it can receive a new customer. When the store closes the system can be put in ss_o again from as_idle. Each of these main behaviours consists thus of many more actual states and transitions. Refer to Appendix A to see the whole model visualized without state and transition information. When looking a bit more closely, the ve main behaviours can be clearly recognized in the whole model as ve highly connected clusters.

(22)

Chapter 4

Research

In this chapter the information concerned with research will be explained. First, the improvements listed in Section 3.2 are used in combination with the information described in Chapter 2 to construct a list of research questions. Thereafter, the research and validation methods are explained in the second section.

4.1 Research questions

Considering the information found and listed in the Chapter 2, together with the list of requirements for Test Manager, a list of research questions could be constructed. As foreshadowed a few times already in prior chapters, the main hypothesis is concerned with the combining of both presentative visualisations and explorative visualisations. The research questions are formulated as follows:

1. How can presentative graph visualisation techniques be used alongside explorative based visualisation techniques to get both an insight in the general structure, and a deeper understanding of individual parts?

The work of Van Ham et al has shown that a layered graph drawing is an eective way in visualizing transition systems. The rst part of the research period was meant for recreating their results in the setting of Test Manager. Other work of Pretorius and Van Wijk has shown that for domain experts other visualisation tools are more desirable. Axini conrmed this and desires a way to better analyse created models using visualisations. The second part of the research conducted focuses on presenting such attributes, as well to help users nd answers more easily to specic questions. The following questions are sub questions to help answer the main question of this thesis.

(a) Is semantic focus and context a suitable technique for combining presentative and explorative visualisations?

As made clear in Chapter 2, focus and context is a technique used to place detailed information in context of the whole. Therefore this technique seems perfect for combining both presentative and explorative goals, and will have big part in the implementation of the prototype.

(b) How can abstraction and interaction be used to get an understandable visualisation while still allowing for details to be understood?

The modelling done in Test Manager already makes use of abstraction mechanisms in the form non-terminating behaviours, terminating behaviours, and processes. How can these concepts be

(23)

visualized while not losing sight of the whole? What kind of interaction should be provided to let the user explore these abstractions and gain a deeper insight in the model?

(c) How can pruning, ltering, and highlighting of information be used to support the understanding of the model by users?

Next to the abstraction mechanisms in Test Manager, some other techniques should probably be provided as there is still an excessive amount of information. Filtering allows users to selectively hide information, whereas pruning is a predened abstraction mechanism [22]. Highlighting helps in quickly relating information to an action undertaken. Each of these have proven to help in the understanding of visualisations, but how should they be implemented in the research setting [3, 8]? Also, it is interesting to nd out how presentative and explorative based visualisations can be better combined using these techniques complementary.

(d) How can users eectively search for specic states or transitions, and how should the results of searching be displayed?

One of the ways for users to explore data is by asking questions. Examples of such questions can be, Which transitions make use of parameter x?, Where are the transitions located with label y?. When results are found, how should they be visualized?

4.2 Research and evaluation methods

The creation of a prototype was chosen as the research method in nding the answers to the research questions. Basically, the approach taken aligns very straightforward with the research questions. Semantic focus and context is expected to be a good contender to combine presentative and explorative visualisations. Various approaches can be taken in implementing focus and context, but for pragmatic reasons it was chosen to create a separate visualisation panel for both. It was relatively easy to implement, and various takes on the explorative part of visualisations could be tried incrementally.

First the work of Van Ham et al was partly replicated to create a presentative visualisation. A layered graph in which details are pruned needed to be created rst. Next, using the various techniques listed in Chapter 2, the prototype was extended to support more explorative operations. The abstractions present were taken into account and extended. Interaction in combination with pruning, ltering, and highlighting was implemented to support user understanding. And lastly a search functionality was added to help users get a deeper understanding of the model. In Chapter 5 this prototype and its functionalities will be explained in detail.

The evaluation of the prototype is done on two dierent levels, the verication and the validation of the prototype. The prototype could be veried on its correctness using the ontology of visualisation. Every concept in Test Manager's take on STSs needs to be represented well in the visualisation. The visual syntax used needs to be unambiguous and clear. Using a semi-random model generator the prototype can be veried on properties like scalability and predictability.

The second level of evaluation is concerned with the validation of the prototype. Using questionnaires the potential users of the visualisation were asked to evaluate the usability. General information visualisation evaluation criteria were used to construct to questions in this questionnaire. The results of the verication and validation are presented in Chapter 6. Chapter 7 will use the results and answer the research questions.

(24)

Chapter 5

Prototype: design and implementation

In this chapter all the steps taken to get to the nal prototype created during the research period are explained. The rst section contains the information regarding the design of the prototype. This includes the general architecture, and what technologies are chosen to create the prototype. In the second section the implementation itself is explained, the phases in which it can be divided, and the techniques used in each of them. In the last section the limitations of the prototype are recognized, so they can be taken into account during evaluation.

5.1 Design

As described in the previous chapter, the semantic focus and context is the main technique used in the prototype. It allows to create an easy to comprehend overview and use various takes on the focus part for incrementally trying various explorative visualisations.

In the rst subsection the technologies chosen will be listed together with a rationale. Thereafter the architecture of the prototype is explained to serve as a reference for the second section of this chapter. Using the architecture it can be claried how and where dierent techniques are implemented.

5.1.1 Technologies chosen

For the rst part of the implementation a presentative visualisation needed to be implemented. As described in Chapter 2, a node-link diagram is very well suited for creating a presentative based visualisation. As Test Manager is a SaaS application, making use of JavaScript for the visualisation seemed the most appropriate choice. It has specialized libraries for data (graph) visualisation, it works well with current web application of Axini, it has a big community, it is very exible, and it is fast, making data processing easy.

Within JavaScript there were multiple libraries considered. Graphviz the current tool for visualisation -gives quite pleasing results but does not shine in interaction, and therefore was put aside. It is also not deterministic, making the results not fully predictable. The same graph will be displayed using dierent layouts at dierent times.

(25)

Force layout is especially useful when a structure of the data is unknown. The simulation tries to nd an optimal structure out of the data given. As models do not contain unintended data, a lot of their structure is already known beforehand. Force layout is unpredictable and doesn't take into account such a predened structure by default, and therefore the force layout of d3.js, and sigma.js were dropped as well.

Dagre-d3.js is a library created on top of the very popular data visualisation tool D3 , and makes use of a variation on Sugiyama's layered graph drawing. It gives similar pleasing results as Graphviz, but has much more interaction possibilities, and is deterministic. Dagre-D3 is unfortunately less exible than the force layout library of D3, has worse documentation, and a much smaller community. Though, despite this, it provides more functionality out of the box aligning well with the requirements and the research questions. Therefore Dagre-D3 was chosen to be used as the main library for visualisation.

As interaction is one of the main concepts focused on during this research, a library providing a lot of functionality was very desirable. After a quick search, JQuery came out as a good contender, and is chosen as the main interaction technology. As it seemed to provide everything needed and was already used in Test Manager, no other libraries were considered. High quality code is of course a requirement, and testing needed to be done as well. QUnit is a JavaScript library which provides many testing features, is quite popular, and was thus chosen as the testing framework. Again, as everything needed seemed to be provided no other libraries for testing were considered.

Though not strictly necessary, CoeeScript a preprocessor of JavaScript was chosen to replace JavaScript. It is more in style with proper software engineering principles, making the software development process easier. Examples of such principles are stricter hiding of variables and objects, a better object oriented class system, more functional programming features, and having a less verbose syntax. CoeeScript consists of another syntax, but can access the same libraries and core functions as JavaScript can. CoeeScript is compiled to JavaScript beforehand where after the generated les are used in the actual implementation.

5.1.2 Software architecture

As time was one of the bigger constraints during this research some choices needed to be made regarding the architecture of the prototype. Creating a full edged client-server architecture as is normally desirable for web applications seemed to be too much time consuming. A decision was made to separate the prototype from the current client of the application, and not make use of Ruby on Rails to save time. The visualisation now happens in two steps. First, in the back-end the model is translated to a JSON representation, a very popular data format used for exchanging information over the web. Next, the visualisation can be started, which will automatically retrieve the JSON les of the current model selected.

A sketch of the software architecture can be found in Figure 5.1. In the blue block a simplied architecture of Test Manager can be seen. It exists out of a back-end side responsible for processing models and a browser part, responsible for allowing user interaction.

Test Manager was extended with a JSON converter to convert a model to a JSON representation. The sep-arate prototype can afterwards retrieve the created JSON les and start the visualisation. The architecture of the prototype can be seen in the yellow tinted block. In this block the various modules and their most important classes are shown. Each class shows its main purposes and its main technology used in the blue letters on the bottom.

(26)

The main HTML page decorated with CSS calls the by CoeeScript generated JavaScript functions and objects to start the visualisation. The GUI module creates all the dierent visual elements and attaches events on interaction. The renderers both instantiating the same interface are responsible for creating the presentative and explorative visualisations. Both are called from the GUI and the search-engine when interaction happens, where after the visualisations are re-rendered appropriately. Both renderers contain an STS object. This object contains the Dagre data structure and is responsible for all logical operations on the visualisation. This is also the module that reads in the JSON les and creates the Dagre data structure. A separate test module was created to use all other modules on the same level or below to test the code. It contains a parametrized semi-random model creator and unit tests.

(27)

(28)

5.2 Implementation trajectory

There are four main categories in which the implementation phase can be divided. The rst was to integrate the existing software assets in Test Manager with the technologies to be used. As modelling was already provided by Test Manager, only the modelled information needed to be translated in something usable for the visualisation part of the prototype.

As described in Chapter 3, the modelling already makes use of quite some abstraction mechanisms. The second step was using those abstraction mechanisms and visualize them correctly. As expected, there was still an excessive amount of information, so some other abstraction techniques were needed as well.

As concluded by many dierent research projects, interaction is one of the most important aspects of visu-alisation nowadays[3, 5, 9, 16, 22, ?]. This is taken into account in the third step of the implementation. A graphical user interface was created and mainly focused around the semantic focus and context technique. As mentioned, instead of the usual focusing in the visualisation itself, this prototype makes use of two visualisations. One for the overview, and one for the focused details.

The last step is using both the abstraction mechanisms and the interaction possibilities to provide exploration opportunities. In this step the focus and context approach was extend further to also support queries and selective exploring of the model.

5.2.1 Integrating with existing software assets

As is explained in Section 5.1.1, the technologies to be used needed to be integrated in Test Manager. As described in the previous subsection as well, an obvious solution for connecting them was translating the information present in the Ruby object to a JSON graph. This all happens in the JSON converter seen in Figure 5.1.

The conversion is very straightforward. First a separation is made between entities (nodes) and actions (edges). For every process, non-terminating behaviour, terminating behaviour or state, a tuple is created needed for creating a node. Note that states and nodes are not the same, as the rst refers to the visual notation, and the second to the states as described in the STS theory.

An example of a JSON node can be seen in Figure 5.2. The tuple exists out of the unique id of the entity, and the value associated with this entity. The value of each node includes the label, an is-covered boolean, the type, and an optional le reference. The is-covered boolean shows if the node is walked upon during testing and is thus prior testing always false. The type shows if the node is a non-terminating behaviour, terminating behaviour, start state, or normal state. In the case of one of the two behaviours, the le reference is set to the le with the information regarding the children of the behaviour. Each model has thus a JSON le for every behaviour, making future client-server communication easier. This was mainly chosen as it was actually easier than to put everything in one le. This because of the structure of the run time STS of Axini. The dierent types of nodes are coloured so the user can see the distinction between them.

(29)

Figure 5.2: Example of a JSON node.

Transitions can be divided in normal transitions, and tau transitions. Both make use as arrowed edges as visual notation. Normal transitions are written down as a four tuple each, containing the source node, target node, name, and again a value object. An example JSON edge can be seen in Figure 5.3. The name is needed as multiple edges between the same two nodes should be possible. The value contains the kind, channel, label, parameters, is-visited boolean, and constraints of the transition. The tau transitions are stroked, and its value only shows that it is a tau transition.

Figure 5.3: Example of a normal JSON edge.

Using the created les after conversion, the visualisation part of the prototype can read the les, and using Dagre-D3 a directed graph can be generated. Nodes and edges only need to be added to the data structure and Dagre-D3 comes up with an 'optimal' layered layout. An example of the rst visualisation can be seen in Appendix B. An advantage already compared to the prior visualisations is that zooming and panning is already provided, and that the visualisation is deterministic.

(30)

5.2.2 Abstractions

In this subsection the dierent abstraction mechanisms implemented will be covered. How the presentation abstraction mechanisms processes and behaviours are taken care of will be shown rst. After that the representation of an STS will be presented. As the information in transitions is too much to show at once, pruning is used to make the visualisation comprehensible. The last abstraction applied is a variant on edge bundling. Each of these will be explained below. All abstraction mechanisms are implemented in the STS module shown in Figure 5.1. Note that all techniques used in this section correlate with the techniques studied in Chapter 2.

Figure 5.4: The initial visualisation of the SCRP system.

Focus and context. After the initial visualisation was created, multiple techniques could be implemented regarding abstraction to let users more easily comprehend the whole model. The most logical form of abstraction was using the abstractions already predened in the model itself. The processes are visualized as light blue boxes surrounding the non-terminating behaviours they contain. On top of each box the name of the process is written in blue bold letters. The non-terminating behaviours are represented as dark grey nodes each, with edges connecting them. Inside these behaviours there are actual states and transitions conforming to the theory of STSs. The initial visualisation of the SCRP system can be seen in Figure 5.4. As the information contained in a non-terminating behaviour is hidden at rst, it needs to be retrievable interactively. In the old visualisation tool each of these behaviours was clickable to show its contents in a separate window. As this approach makes it dicult to place the new found information in context of the whole, another approach was desired. As such, these behaviours are still clickable, but now the node is replaced with its contents in the current visualisation (by double clicking) to create a focus and context technique. A light grey box shows the boundaries of the behaviour, and contains the actual states and transitions. As is with processes, the name of the expanded node is shown on top in the grey box. As behaviours can expand within behaviours, the colour of the bounding box is coloured a darker shade grey in every expanded child behaviour. See Figures 5.5(a) and 5.5(b) for an example on expanding and collapsing.

(31)

Figure 5.5: Showing collapse and expanding of nodes.

(a) A collapsed general

errors node (b) An expanded generalerrors node

STS representation. The states within the expanded behaviours are coloured according to their type. Start states of routines are coloured light red, terminating behaviours are coloured light grey, and normal states are coloured blue. The terminating behaviours can be expanded as well as shown in Figures 5.5(a) and 5.5(b). Behaviours can be collapsed again by double clicking the start states of the behaviours. Transitions are either visualized by continuous lines with arrows, or stroked lines with arrows. The continuous lines show transitions of which their contents are known, and contain the information as described in the previous subsection. The stroked lines are tau transitions (see Section 2) and are unobservable, and as such contain no information. This is also visible in Figures 5.5(a) and 5.5(b).

Pruning and retrieving. Even though the above abstractions are made, an average model used by Axini is still too big to comprehend easily. To handle this overload of information, the information attached to transitions are hidden until specically retrieved again. Labels, kinds, channels, constraints, and parameters are all left out to get a visualisation which ts better on the screen, and is easier to understand the overall structure from. As can be seen in the old visualisation (Figure 3.1), the attaching of this information to the transitions actually takes up more space than the nodes and edges. Since most information is not needed at all times, the visualisation does prune this information until desired. How this information can be retrieved again will be shown in the next subsection.

(32)

Edge bundling. There are quite a lot of transitions between the same two states in most models in Test Manager, making the visualisation harder to read. To counter this, a variant of edge bundling is used which creates one single edge from all transitions between the same two states. To quickly understand how many transitions are approximately represented by this single edge, the shade of blue shows the amount of transitions bundled. A lighter colour blue represents more transitions bundled. The eect of bundling can be seen in Figures 5.6(a) and 5.6(b).

Figure 5.6: Example of edge bundling between the same two states.

(a) Non bundled edges. (b) Bundled edges.

Figure 5.7: The result of all abstraction mechanisms

(a) The overview. (b) The overview with the ss_o expanded.

The result of all the abstraction mechanisms together can be seen in Figure 5.7. Unfortunately the initial structure as is shown in Figure 14 is not preserved when expanding states. Every time the visualisation is changed a new 'optimal' layout is calculated and therefore the structure can change quite a lot1_.

1_{I contacted the original author of the library and asked him if he could give pointers on how to provide this partial static} structure myself. He explained that this is not a simple feat, since it is not possible to provide static or sub graph constraints on the graphs. As such though desirable this did not make the nal version of the prototype.

(33)

5.2.3 Interaction

Figure 5.8 shows the graphical user interface or GUI and all the interaction possibilities for users. The left panel shows the overview visualisation as shown until now. This panel allows users to recursively retrieve the structure of the model by expanding and collapsing behaviours by double clicking the associated nodes. The abstraction mechanisms described in the previous section are applied to get a comprehensible visualisation showing the general structure. As detailed information is still desirable, a second panel is used to get specic information about individual parts of the model. The panels are separated mostly for pragmatic reasons. When detailed information is added to the existing overview visualisation in the right panel, the graph changes structure and orientation is easily lost. The visualisation is therefore split into two, so the overview is always easy to comprehend, and the detail panel gives the information needed. Considering Figure 5.1, the GUI module is responsible for handling all the events associated with buttons. Both the renders get commands for this GUI and re-render the graph with the right information.

Figure 5.8: The GUI of the prototype, showing the initial visualisation of the SCRP system.

Menu. The GUI shows a menu above the visualisation. In this menu (from left to right) the user is able to show and hide the overview visualisation panel. Show and hide the detail view visualisation panel; show and hide the execution path of a test case; show or hide the legend of the visualisation; undo the last action done; and reset the visualisation to its initial state. On the far right a search box is visible, its use will be explained in Section 5.2.4.

Consider the legend in Figure 5.9. The processes show two models. The left shows all dierent types nodes and edges, whereas the left shows a model in trace mode. Each of the labels on nodes, edges and boxes can be hovered over after which the information about the entity will be shown below. The current hovered node is the red start node.

(34)

Figure 5.9: The legend showing in the detail panel.

Navigation through the STS. As explained before, using double clicking on routine nodes (non terminat-ing and terminatterminat-ing behaviours) will result in expandterminat-ing as is shown in Section 5.2.2. Double clickterminat-ing again on the start state of the expanded node will collapse the routine again. As the graph grows when expanding behaviours, it is possible for the visualisation to not t on the screen anymore. The button on the top of the overview panel showing Scale will allow the user to change the zoom level to let the visualisation t. Another way to make the visualisation better t the screen is by hiding the whole detail panel, or resizing the panels by dragging the separation line.

When a user wants to retrieve the pruned information from transitions again, it is possible to single click one of the neighbouring nodes. The overview panel will highlight the edges attached to the clicked node. In the detail panel the list of highlighted edges will become visible. Each of these edges shows the name of the transition, and shows Unobservable in the case of stroked line edges. When one of the edges is an edge representing multiple transitions the list will show Multiple Transitions(x), with x showing the number of transitions contained. The names in this list are clickable after which information about the transition(s) will be displayed and the source node will be centred. See Figure 5.10 for an example. Incoming edges are coloured orange, whereas outgoing edges are coloured yellow. The edges connected to the state are shown in the detail panel, and are collapsible to show all information. In case of expanding multiple transitions each of the transition will be shown in that list. To make it more clear which of the transitions is selected it will highlight in red in the overview panel.

This technique is inspired on the analysis based visualisation of Pretorius and Van Wijk. Though dierent, it also puts transitions as the primary subject in the detailed visualisation. In the future it can be extended by showing transitions not bound by the same state, but by the same attributes, such as constraints and labels. This will make it easier to understand how similar parts of the model are related. Unfortunately, the time did not allow for this functionality to be implemented.

(35)

(36)

5.2.4 Exploration

As explained in prior sections, the visualisation is split into a presentative and explorative panel. The left panel functions as the overview panel, the right panel as the explorative panel. In this panel, there are three types of explorative visualisations. First, it is possible to visualize only part of the model with the desired amount of details in this panel. Secondly, it is possible to visualize test case results. And thirdly, the results of a search can be visualized here. The detail panel module in Figure 5.1 is responsible for showing the visualisations in the right panel. It uses the detail renderer to show the sub graphs.

Partial model visualisation. As shown, the detail panel allows users to retrieve specic transition in-formation by selecting neighbouring nodes in the overview panel. However, it is possible that users want to understand not only individual states and transitions, but also parts of the model they feel need to be explored together. To allow users to decide themselves what they want to explore, the detail panel allows for selectively adding nodes and edges to the detail panel. Users can create a new partial model visualisation by ctrl double clicking a node. Using shift and double click will add nodes to this current partial model visualisation. When both target and source nodes of an edge are present, it will be added to the partial visualisation as well.

The idea behind this functionality is that users can nd deeper relationships in the model, or understand the results of a test case better. The functionality of this feature is now quite limited as users themselves have to think which nodes and edges are interesting. In the future, this can be expanded to rst analyse the model, and then visualize the results. In the detail panel there is a selection button, which on clicking will expand a list of check boxes. Each of these check boxes will show the information required on selection. See Figure 5.11 for an example on how this can be done.

Another way in which users can visualize part of the model in the detail panel is by shift single single clicking a node in the overview panel. Instead of just adding the clicked node, it will also add all its neighbours, and attached edges. Using shift and click on a behaviour node will result in the detail panel showing all the children contained in the associated behaviour. By double clicking any of the nodes in the detail panel it will be deleted again. By single clicking one of the nodes in the detail panel it will highlight and centre around that node in the overview panel. This however only works when the state is in the current overview panel, so when a state is in a collapsed behaviour no action will be undertaken.

Visualizing test cases. As the models visualized are mainly used for testing, an important part of the visualisation is showing test results. Unfortunately, for executing real test cases the actual software and an adapter are needed, which was practically not possible in the available time. As it is still interesting to evaluate the visualisation of test cases, a mock up feature was created. When the user selects the Show Trace button, the prototype will create a random execution path, and colour states and transitions according to coverage. The detail panel shows a selection of the walked on nodes and edges. Figure 19 shows the results of this functionality.

(37)

Figure 5.11: Using of the detail panel.

Figure 5.12: A random path on the visualized part of the overview model. The detail panel shows the nodes and edges walked over.

(38)

Figure 5.13: The visualisation showing the results of the search.

Searching. Another part of exploring is being able to ask questions to the visualisation. Especially since a lot information is pruned, it may be hard to nd the information required. To counter this a search functionality was added. Using the search bar the user is able to type in one of the available keywords and the name of what is being sought. The keywords correspond to the available information and thus are state, transition, constraint, channel, and parameters. While typing the search bar gives all suggestions still corresponding to the search terms. The keywords are not strictly necessary, and partial typing in a query works as well. The search-engine module in Figure 5.1 is responsible for processing searches. It makes use of a hash table for every category with the keyword searchable as key and the information retrievable as value. These tables are created upfront on rendering the initial visualisation.

When selecting one of the given suggestions the overview highlights the states and transitions corresponding to the search. When states or transitions are not visible in the overview because they are still inside one of the behaviours, this behaviour will highlight yellow to show users where to look further. The overview will show the highlighting until the x button in the search bar is pressed. An example of a search result can be seen in Figure 5.13. Corresponding nodes and edges are highlighted red in the overview panel, and shown in the detail panel. Parent behaviours of corresponding nodes and edges are highlighted yellow. By using shift and ctrl double clicking nodes a sub part of the model is visualized in the detail panel. In this panel details can be required as well by using the selection box on top of the visualisation. For clarication, the edges are not bundled in this detail panel.

The Visualisation of Symbolic Transition Systems