Automatic Abstraction Management in Information Visualization Systems

Automatic Abstraction Management in Information Visualization Systems Marcelo Campo - Ricardo Orosco* - Alfredo Teyseyre Univ. Nacional del Centro Pro...
Author: Mark Sullivan
0 downloads 0 Views 155KB Size
Automatic Abstraction Management in Information Visualization Systems Marcelo Campo - Ricardo Orosco* - Alfredo Teyseyre Univ. Nacional del Centro Prov. Bs. As - Fac. Ciencias Exactas ISISTAN- Grupo de Objetos y Visualización, San Martín 57, (7000) Tandil, Bs. As., Argentina E-Mail: [email protected] [email protected] * also Universidad Autónoma de Madrid, Depto. Ingeniería Informática Campus Cantoblanco, Mod. I-V, 28049, Madrid, España Comisión Investigaciones Científicas (CIC) Prov. Buenos Aires, Argentina Abstract The construction of information visualization systems is a difficult task. However, there are few works in the provision of software architectures for visualization systems, in order to reduce this difficulty. Particularly, systems that provide a reusable support for the automatic management of the different levels of abstraction in which complex data can be observed are not found in current visualization systems. In this work, Telescope, an objectoriented architecture for visualization systems is presented. Its main goal is to provide a customizable infrastructure to develop visualization systems allowing the automatic management of the different levels of abstraction in which the visualized information can be observed. Telescope is based on the concept of abstractor objects which provides the generic behavior to support visualizations with semantic zoom capabilities controlled externally through abstraction scales. CityVis, a visualization system for city data, developed using the Telescope architecture, is also described.

1. Introduction Data visualization is a powerful tool to facilitate the analysis and understanding of complex information. Although its increasingly importance, both in research and commercial communities, the process of creating these visualizations is still quite complex. In most cases, visualizations tend to be hand-crafted, each one different

from the previous, making difficult to reuse implementations from one visualization to another. Several factors contribute to this difficulty: • there are a great variety of domains that can be visualized, each one with its own requirements and characteristics. • the analyzer may perform distinct types of visualization processes [4]: exploratory, analytical or descriptive. • users can perform visualizations with different goals, and/or use distinct visualization techniques according to their purposes. • there is a low reusability degree of previous visualizations, as a consequence of the handcrafted nature of visualization systems or because their designs are oriented to particular domains. However, in spite of this difficulty, the way in which visualizations can be implemented has received relatively little attention. Most of current works on information visualization are focused on the development of new visualization techniques (e.g. [11], [19], [7], [1], [13]), or in the provision of assistance to the user in the data exploration process (e.g. [18], [14], [2]), but little research have been reported about software architectures that make simpler the construction of visualizations of complex data. Particularly, systems that provide a reusable support for the automatic management of the different levels of abstraction in which complex data can be observed are not found in current visualization systems. The management of abstraction levels is one of the main features in any data visualization. However, the construction of techniques

that perform an automatic control of the abstraction or detail level is not simple task. In addition, most of current implementations has little reusability, because the knowledge about this management is hard-coded into the visualization system. In this work, Telescope, an object-oriented framework for the construction of visualizations of information is presented. The main goal behind the design of Telescope is to provide a customizable infrastructure to develop visualization systems allowing the automatic management of the different levels of abstraction in which the visualized information can be observed. Telescope is based on the concept of abstractor objects which provides the generic behavior to support visualizations with semantic zoom capabilities controlled externally through abstraction scales. With this support complex visualizations can be implemented independen-tly from the management of the detail level that can be shown in different stages of the visualization. This aspects greatly helps to reduce the complexity of imple-menting new visualizations, promoting cleaner designs which increase, in consequence, the reusability of such visualizations. The paper is organized as follows. Section 2 discusses the architectural requirements for visualization systems from the abstraction management point of view, introducing the concept of abstractor objects and abstraction scales. Section 3 presents a brief description of the Telescope framework, emphasizing the design and implementation of the abstraction management layer. In section 4, CityVis, an application developed with Telescope are described. Finally, in section 5 some preliminary conclusions and future work are outlined.

2. Visualization Systems Architectures and Abstraction Management According to [8], a visualization process consists of three phases, each one corresponding to one of the major transformations performed over the visualized data: 1. ‘Data Access’: accessing and structuring of the visualized data (generally stored in a database); 2. ‘Mapping’: conversion of data in a graphical representation, and the assignment of visual properties to the graphical objects (e.g. color, texture, etc.); and 3. ‘Rendering’: creation of the presentation. Most of current visualization systems, such as AVS [20] and Iris Explorer [9], present components for each of these phases. However, in order to provide an adequate support for the full visualization process, others components must be identified. - In most cases, a visualization process often has a semantic processing of the data to be visualized, such as a

filtering phase. In consequence, may be necessary to add an ‘Abstraction’ component, before the creation of the graphical objects (Mapping). - An information visualization system can be described as a graphical presentation of data, and direct manipulation tools for exploring relationships among these data [10]. Therefore, an ‘Interaction’ component must be included in every visualization architecture. - Finally, due to the fact that the visualization system must support data exploration processes, it is necessary to keep information about the user operations and the current state of the visualization process: a ‘Visualization State’ component must be included. In general, current visualization systems present some of these components, although not necessarily all of them. The target of the majority of these systems are only one or two of these components. For example, SDM [7] is focused on manipulation aspects, Visage [14] on presentation construction, Galaxy of News [18] on data structuring, and Pad++ [3] on the provision of continuos zooming capabilities.

2.1 Abstraction Management Most of current tools providing direct-manipulation visualizations are based on some variant of the ModelView-Controller (MVC) architectural model [12]. This model promotes the independence between the data representation (Model) and its the visual presentation (View), assigning to the View component the responsibility of producing the visual presentation of data contained in its Model. This approach, although ensuring the independence between data representation and its possibly multiple visualizations, presents two major limitations: • Semantic Analysis: From a design perspective, MVC does not promotes the implementation of mechanisms of semantic analysis of the information, independently of classes representing information or views. That is, data analysis algorithms must be implemented in classes implementing either the information representation or visualizations. When new algorithms need to be added, this solution forces the modification of existent classes with behavior related to specific applications. That is, MVC can induce designs hard to extend and adapt. • Abstraction level filtering: In general, complex information defines several levels of abstraction that can be visualized or hidden according to detail level desired by the user. Using MVC, the filtering of different detail

levels of the data to be visualized, must be implemented for each particular visualization. This complicates the programming of alternative visualizations, reducing also its reusability. These limitations, obviously, can be solved in different alternative ways. In our work we introduce the concept of abstractor objects. Abstractors represent a generic architectural component of visualization tools, through which different analytical algorithms and selection criteria can be located, without the need of modify either classes of the information representation or classes implementing visualizations. Following the conventional communication mechanism among views and models in MVC, views request their model the information to be visualized through direct messages. An abstractor substitutes a model and decides whether to ask the original model for the requested information. Essentially, abstractors behave as proxies of the objects contained in the model, controlling the access to these objects by visualization classes. In this way, abstractors can be hierarchically composed to provide independent control over each object contained in the model. Also, they can be dynamically composed to combine different functionality, as for example, filtering on a specific selection of the visualized information. This powerful feature enables the combination and reuse of different algorithms for abstraction recognition with different visualizations styles. Also, it provides the basis for the automatic management of the detail level of visualizations through the explicit support of abstraction scales. An abstraction scale is an ordered t-uple naming the order in which information should be visualized. For example, an abstraction scale for the different items of information that can be observed in a city map can be defined as follows: (regional (mainStreet, freeway, route, cityBound items)) (globalCity (avenue, mainStreet, freeway, places, park items)) (detailedCity (street, avenue, mainStreet, freeway, route, place park items))

An scale can have its own user-interface control (e.g. a slider) through which the user can interactively vary the level of abstraction of the visualization (i.e. showing or hiding dynamically details). The visualizations, in turn, only have to worry about what must be shown according to the data that abstractors pass to them, in the current abstraction level.

Data Representation

Database

Data Objects

Data Abstraction Abstractor1

Abstractor2

Abstractorn

Visualization State Visualized Data Objects Data Objects Graphical Objects Mapping Mapping1 Mapping2

Selected Items Mappingn User Model

Interaction Model

Graphical Objects

Visualization

Presentation

Interaction

Fig. 1 - Telescope global architecture The next sections presents the actual materialization of this concepts in an object-oriented reusable software architecture, named Telescope.

3. The Telescope framework Telescope is an object-oriented framework designed, and implemented in Smalltalk-80, taking into account the six components identified in the previous section §2, i.e.: Data Representation: storage and access to the data items to be visualized. Additionally, once the data was accessed, they must be organized according to the current visualization tasks and goals, to allow a quick access to the information during the exploration process. Data Abstraction: this level determines which elements will be visualized, and classifies them into sets of related items. It is implemented by abstractors. The input of each abstractor is a set of data objects, organized in a convenient way, and its output is another set of items containing the data to be presented in the visualization. Data Objects - Graphical Objects Mapping: this component performs the association between the data objects (and their properties) and the correspondent graphical objects. These associations are described by the system-designer in a mapping specification, which also can be interactively modified by the user at run-time. Besides, the mapping specification can dynamically change at any time, as a consequence of changes performed by the system (e.g., the presentation of an item may differ according to current zoom level - semantic zooming -).

Visualization: it comprises graphical data presentation and interaction with the user. It is sub-divided into two components: Presentation: it builds data presentation, according to the graphical objects specified in the mapping. Interaction: it implements all the related aspects to the user interaction: item selections and manipulations, user navigation, etc. Visualization State: it contains the current visualization state, which can include the current selected items, user model, interaction model, etc. This state may be accessed by other system components in order to perform their tasks. Each of these components is implemented by abstract classes which provide the corresponding generic behavior. Each visualization application developed using Telescope must implement the particular behavior of each component, which is defined but not implemented in the class (i.e. abstract methods). In fig. 2 the rela-tionships among the main classes of each component are shown. The visualization component consists of a set of Views, hierarchically organized. Each view contains a graphical representation (an instance of a GraphicalObject subclass), and an interactor for each allowed operation on it (e.g., a SelectInteractor to perform item selections). Views have associated a Mapping that performs the conversion between data objects and graphical objects.

4. The Abstraction Management Layer In this section a more detailed description of the abstraction management layer of Telescope is presented. Fig. 3 presents the object diagram of the abstraction layer of Telescope. The abstract class Abstractor [5] defines the generic behavior of abstractors. Each abstractor will have associated an instance of AbstractionLevel, which defines the current abstraction level; a view (generically represented by the class View) and a subject (generically

Visualization State

Data Objects Graphical Objects Mapping Mapping association

VizState

View container mapping model graphicPresent.

TopView state

Abstractor GraphicalObject color size position renderingMode transparency

VizStateControl

stateControl interactionModel selectedItems userModel

s

Visualization

These mappings can be customized by the user at run-time or modified by the system according to changes in the visualization state. The Mapping class can be specialized through subclasses, for example to implement distortionbased visualization techniques. Additionally, each view gets the information to be displayed through an associated abstractor (instances of an Abstractor subclass), which determines the objects and properties that will be effectively visualized. This abstractor has a reference to the data object containing the actual values to be visualized. The visualization state component is mainly implemented by a VizState class, which manages all the information related to the current state of the visualization process. It also contains an instance of VizStateControl class, that allows the user to control and manipulate interactively this state.

Interactor

view graphicObject

subject vizState

DataObject prop1 prop2 prop3

..... Data Representation

Data Abstraction

Fig. 2- Main object model of Telescope

represented by the class Subject ). The abstraction scale mechanism is defined by the AbstractionLevel class. This class provides the support for comparing symbolic levels of abstraction. The Scale-View class implements the user interface of the scale, which can be used interactively by the user to vary the detail level shown in the visualization. Abstractor instances are created through the message on: aSubject, which creates the corresponding instance, sets the subject of the abstractor and triggers the configuration mechanism (configureAbstractor method). The code below shows the creation of an instance of a CityAbstractor class. abstractor := CityAbstractor on: aSubject abstractor abstractionScale: #(regional globalCity detailedCity) cityView:= City3DView new. abstractor view: cityView. cityView model: abstractor.

The configuration mechanism allows the automatic construction of hierarchically composed abstractors which manage the individual abstraction levels corresponding to structured data. For example, an abstractor designed to control a city map visualization may be programmed to associate an abstractor with each topic composing the visualization (e.g. transports, hotels), as shown below. Abstractor subclass: #CityAbstractor ... configureAbstractor | abstractor | subject getTopics do: [:t | components add: (abstractor:= (self abstractorFor: t) on: t). abstractor container: self]

In this way, the setting of a city abstractor will automatically generate the corresponding hierarchy of abstractors on the component topics of that visualization.

View

ScaleView iInterface

view abstractionLevel

AbstractionLevel subject abstractionLevel: aLevel > anAbstractionLevel > anAbstractionLevel

Abstractor configureAbstractor

container

Through this mechanism abstractors of complex structures can be set with little effort. 4.1.1 Managing abstraction levels The key idea behind abstractors design is the definition of a standard protocol through which visualizations can ask their models for data to be visualized. Each view must ask this information through the standard message getItems. The generic behavior of this message implements the control mechanism of the current abstraction level. If such level is greater than the level represented by the abstractor, the complete infor-mation of the model is returned. Otherwise only the corresponding abstract information is returned: getItems self abstractionLevel > self abstractionRepre-sented ifTrue:[ ^self getFullItemsInformation] ifFalse:[ ^self getAbstractItemsInformation].

The default implementation of getFullItemsInformation method returns the full component list of the abstractor, while getAbstractItemsInformation returns an empty list indicating that there is no information to be visualized at the current level of abstraction. When a user produces a change in the global abstraction scale, the message abstractionLevelChanged is propagated to all the component abstractors to update their current abstraction level. A change in the level of abstraction will produce that the top-level abstractor ask the visualization or the mapping component to update the global visualization through the regenerateVisualPresentation message. In case of hierarchically-composed abstractors, the abstraction level is common to all the component abstractors, and changes produced in the upper levels are automatically propagated to the lower ones. An abstractor can be enabled or disabled. When an abstractor is disabled the default implementation of the protocol returns an empty list indicating that there is no available information to be visualized. This functionality is very useful to visualize the information resulting of a selection process. Enabling the abstractors associated with selected items, those items not selected will no appear in the visualization without the need of programming special mechanisms for this behavior.

add: anAbstractor getItems getFullItemsInformation

5. CityVis

components getAbstractItemsInformation abstractionLevelChanged

Subject

abstractionLevel: anScale

Fig. 3- Object Model of the Abstractors Framework

CityVis [16] was developed using the Telescope framework, incorporating capabilities for city data visualization, through specialized classes for the

management of this kind of data. Its main goal is to support the exploration of city information, providing techniques to assist the user in this process. The CityVis visualization component is implemented by specialized views for each class of visualized data object. Also, several mappings specifications are provided, indicating the associations between data objects and the graphical objects that must be used as their representations. The information displayed on the presentation is determined by means of abstractor objects. CityVis, uses a specialized abstractor (a CityAbstractor class) for the global management of the city information to be shown, and different abstractors for the management of related information (e.g. topics such as hotels, apartments, map, etc.). Additionally, there are other abstractors that manages information revealed during the exploration process (e.g. statistics) Finally, the current state of the visualization is managed by a CityVisState class, that maintains all the information about the current visualization and exploration process. Abstractors greatly facilitates the construction of complex visualization techniques like layered or assistance techniques. These visualization techniques are used to compose different topics of information, based on the ‘transparent paper’ metaphor. For example, in CityVis, there are different layers for the city map, transports, hotels, restaurants, apartments, etc. The user can manipulate these layers, adding and/or removing some of them

at any time during the visualization, to display only the information relevant for the current task. CityVis implements a layering technique through different views for each layer, each one with an associated abstractor (a TopicAbstractor) that determines the visible information in the layer. The management of visible topics at run-time is done automatically by the CityAbstractor (generally in response to user requests), which determines if each TopicAbstractor is enabled or not. AutoFocus [17] is an example of assistance technique that shows the versatility provided by abstractors to generate derived information. Its goal is to assist the user in the exploration process, providing help in the focus specification and using 3D presentations that convey a greater quantity of information. The assistance is implemented by a statistical inference mechanism, that attempts to detect the criteria used by the user in item selections. Once these criteria has been estimated by the system, item presentations are updated accordingly to them, reflecting the relevance of each item with respect to the currently defined focus (using an item opacity proportional to the importance of each item). In this way, a quick approximation to the desired final focus is obtained, facilitating the task and reducing the user workload. This kind of techniques can be implemented through the incorporation of a specialized abstractor (a CriteriaInferenceAbstractor) that performs the inference process. AutoFocus operation consists of two steps: first, the user Abstraction Scale Interface

Statistic Derived Vision

Layered Visions in Different Levels of Abstraction

Fig. 4- Different Visualizations produced by CityVis

criteria are estimated, and then the relevance of each item with respect to the current focus is computed. The first step is performed when a new item is selected (or deselected); in this case, the CriteriaInference-Abstractor computes the user criteria (through a statistical analysis of the selected items), and modifies the criteria list in CityVisState. In the second step, the abstractors deter-mine the current relevance of each item with respect to the current focus, using the criteria deduced in the first step. The current relevance is then mapped to the trans-parency degree of the graphical objects (more relevant items are showed with high opacity, while the less relevant are displayed more transparently).

6. Conclusions and Future Work. A framework for visualization systems with automatic management of abstraction levels was presented. Its suitability to the construction of visualization systems was demonstrated through: - development of an application for visualizing city data - implementation of several visualization techniques: distortion-based, layering or assistance techniques were included in the visualizations in a simple way. The concepts of abstractor objects and symbolic abstraction scales enable the construction by composition of complex filtering mechanisms that greatly simply the implementation of visualizations, which is often the more time-consuming task in the development of visualization systems. Using Telescope, the development of new visualizations is simplified, due to the high reusability degree of the main components of the system. Additionally, the extensibility of these systems is high, due to the clear localization of possible changes and extensions. As another feature, Telescope allows the quick prototyping of new visualizations or techniques, with a low cost. Future work in Telescope includes the development of new visualization applications, particularly for WWW visualizing and for numerical data domains. The construction of applications with a high degree of user interactivity are also being explored. Additionally, new visualization techniques are being studied in CityVis.

7. References [1]

[2] [3] [4] [5] [6]

[7] [8] [9] [10] [11] [12] [13] [14] [15]

[16] [17]

[18] [19] [20]

Ahlberg, Christopher. Wistrand, Erik. “IVEE: An Environment for Automatic Creation of Dynamic Queries Applications” Proc. CHI ‘95 Conf. Companion, pp 15-16 05/1995. Andrienko, G. Andrienko, N. “IRIS: a Knowledge-Based System For Visual Data Exploration” Proc. CHI ‘97, 1997. Bederson, B. Hollan, J. “Pad++: A Zooming Graphical Interface for Exploring Alternate Interface Physics” Proc. UIST ‘94, pp 17-26. Bergeron, D. “Visualization reference models”. Proc. of Visualization ‘93. IEEE Computer Society Press, 1993. Campo, M. “Compreensao Visual de Frameworks através da Introspecao de Exemplos” Phd. thesis, UFRGS, Brasil., 1997 (in portuguese) Campo, M. Price, R. Teyseyre, A. “Uma Abordagem 3D para a Visualizacao de Padroes de Projeto” Submitted to the Simposio Brasileiro da Engenharia de Software, 1997 (in portuguese) Chuah, M. Roth, S. mattis, J. Kolojejchick, J. “SDM: Selective Dynamic Manipulation of Visualizations”. Proc. UIST ‘95, pp 61-70, 1995. Duce, D. A. “Visualization” Visualization ‘93 Conf. Edwards, G “Visualization - the second generation” Image Processing, 1992 Fishkin, K. Stone, M. “Enhanced Dynamic Queries via Movable Filters”. Proc. CHI ‘95, pp 415-420. 05/1995. Furnas, George. “Generalized fisheye views” Proc. ACM SIGCHI Conf. on Human Factors in Computing Systems, pp 16-23, 1986. Goldberg, A. “Smalltalk-80: The Language and its Implementation” Reading, Addison-Wesley, 1983 Keim, D. Kriegel, H.P. “VisDB: Database Exploration Using Multidimensional Visualization” IEEE CG&A, 09/94, 1994. Lucas, Peter. Roth, Steven. Gomberg, Cristina “Visage: Dynamic Information Exploration” Proc. CHI 96 Conf. Companion, pp 18-20, 1996. Muthukumarasamy, J. Stasko, J. “Visualizing Programs Executions on Large Data Sets using Semantic Zooming” Georgia Institute of Technology, 1995, Tech. Report GITGVU-95-02. Orosco, R. Moriyon, R. “CityVis: an Intelligent Information Visualiza-tion System for City Data” Tech. Report, Dept. Ing. Informatica, UAM, in preparation. Orosco, R. “AutoFocus: User Assistance in Information Visuali-zation” submitted to Hipertext, Information Retrieval and Multimedia ‘97 (HIM ‘97) Conf., Dortmund, Germany, 1997, 18 pp. Rennison, Earl. “Galaxy of News: An Approach to Visualizing and Understanding Expansive News Landscapes” Proc. UIST ‘94, pp. 3-12, 1994. Robertson,G. Card, S. Mackinlay, J. “Information Visualization using 3D Interactive Animation” Comm. of the ACM, 36(4), 04/93, pp 57-71, 1993. Upson, C. “The Application Visualization System: a computational environment for scientific visualization” IEEE CG&A, 07/1989