Designing a Component-Based Framework for Visualization in Software Engineering and Knowledge Engineering Casey Best
Margaret-Anne Storey
Jeff Michaud
University of Victoria
University of Victoria
University of Victoria
[email protected] [email protected] [email protected] ABSTRACT This paper describes our experiences reengineering a visualization tool (SHriMP) into a component-based framework for visualizing software engineering and knowledge engineering projects. The framework is domain independent, customizable and supports multiple methods of integration with other tools. We share with the reader the successes and failures we encountered throughout this reengineering endeavor. We also describe how we have integrated the SHriMP framework with a knowledge management tool called Protégé and with other software engineering environments. We believe that these lessons will be valuable to tool designers in many domains wishing to use a component-based framework architecture. By using a framework of reusable components, we have been able to reap the benefits of the shared insights in visualization from these two closely related domains.
1. INTRODUCTION This paper describes our experiences designing a componentbased framework for visualizing software engineering and knowledge engineering projects. The tool under consideration, SHriMP Views [18, 19], was originally designed for visualizing software. Over the past few years we have been evaluating SHriMP through several user studies [21]. The feedback and initial results from these studies have been positive, but a clear result from these observations is that SHriMP needs to be integrated as part of a software development environment if it is to be truly useful. Another research avenue we have been pursuing is to use SHriMP as a visualization front-end for a knowledge management tool called Protégé [14, 20]. Unfortunately SHriMP’s original architecture was not flexible enough to allow us to easily integrate our tool with Protégé. Consequently we needed to redesign SHriMP so that it could be easily integrated with other tools and Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, or republish, to post on servers or redistribute to lists, requires prior specific permission and/or a fee. SEKE '02 , July 15-19, 2002, Ischia, Italy Copyright 2002 ACM 1-58113-556-4/02/0700$5.00.
customized for new domains while reusing as much code as possible. We chose to reengineer the SHriMP tool into a componentbased framework that could be extended and customized for visualizing and navigating hierarchically structured information. A framework is an architectural pattern that provides a set of extension points where the behavior can be changed and customized to other domains [2]. Components are reusable parts of a framework that provide a service by way of a set of interfaces. A component-based framework, if designed carefully, can increase productivity and improve the quality of the system by reusing code that has been tried and tested [9]. In this paper, we describe how we reengineered SHriMP using a component-based design that enabled us to integrate with Protégé. The framework was proven by a subsequent integration with a software development environment called Eclipse [4, 15]. In this paper we particularly focus on how SHriMP could be integrated as part of a knowledge engineering tool while still maintaining its role as a software visualization tool. We provide an overview of SHriMP and Protégé in Section 2 and outline the requirements for the new design in Section 3. Section 4 provides a short overview of the framework and its main components. In Section 5 we discuss how we applied the framework to other projects and how the framework design addresses the requirements we set in Section 3. Finally, we conclude the paper and describe our future work in Section 6.
2. SHRIMP VIEWS AND PROTÉGÉ The SHriMP (Simple Hierarchical Multi-Perspective) Views software visualization tool was originally designed to enhance how programmers understand programs [24]. Although originally designed for visualizing software, the underlying visual metaphors used in SHriMP can enhance how people browse, explore, model and interact with any complex hierarchical information space. SHriMP uses a nested graph view to present hierarchically structured information. The tool combines a hypertext following metaphor with animated panning and zooming motions over the nested graph to provide continuous orientation and contextual cues for the user. These features result in an environment where the user can interact directly with the information space enhancing their understanding of the information structures, thus promoting further exploration. The SHriMP tool has been evolving continuously since 1995 [19]. The Java version of SHriMP went through several evolutionary cycles that are common in research tools: rapidly try out a new idea, throw it out, try another, keep it and so on. Over
- SEKE '02 - 323 -
time the visualization requirements began to stabilize (in part due to several user studies). However, a visualization tool, if it is to be useful as part of a software development process, needs to be integrated with the software development environments used by developers. This requirement became very evident during our second user study in Spring 1999 [22] and in our most recent user study in Summer of 2001. Around the same time we started a collaboration with the Medical Informatics group at Stanford University. Our proposed project was to integrate the SHriMP visualization tool with the Protégé knowledge management tool. Protégé allows domain experts to build knowledge-based systems by creating and modifying reusable ontologies and problem-solving methods, and by instantiating ontologies to construct knowledge bases. Moreover it allows developers to easily “plug-in” components to add new functionalities to the Protégé tool. Knowledge modeling and acquisition can be a cognitively challenging task. Most current knowledge modeling tools make limited use of visualization. Our hypothesis is that the visualizations provided in SHriMP could provide cognitive support for both knowledge engineers constructing ontologies and for end users browsing and populating a knowledge base. In the next section we describe the requirements for redesigning SHriMP to support integration with the Protégé tool and other software engineering tools. Section 4 describes the design of the new architecture.
leading to flexible and customizable architectures. Using this as our goal, we attempted to create a framework design for SHriMP. The reengineering of SHriMP was split into reverse engineering the old architecture, designing the new architecture, and implementing the new architecture Reverse engineering of the original architecture led to the extraction of the system’s key features which resulted in eight independent components in the new architecture: Data, Display, Selector, Filter, History, Persistent Storage, Search, and Hotbox. Figure 1 demonstrates how they interact with each other through the use of adapters. The design process included creating collaboration diagrams for the system’s key features, which were used to create class diagrams. Once we had our initial design, we embarked on implementing the new design using a “chicken little” approach [3]. The majority of the process was accomplished over the course of 6-8 months by one programmer (the first author of this paper). More details on this process are available in [1].
3. REQUIREMENTS FOR REDESIGN Several key requirements were desired for the new architecture for SHriMP. The first was tool interoperability via data integration, control integration and presentation integration [25]. One of the largest benefits we’ve seen from this reengineering endeavor is the ability to easily integrate SHriMP as the front-end of or a plug-in to any information system. In addition to extending SHriMP for integration with other tools, we have to support customization for different domains of knowledge and for individual users. Another large benefit from reengineering SHriMP is the ability to easily customize SHriMP in order to better visualize a new domain. As SHriMP is being designed to be able to view large, complex data repositories and software programs, scalability is an important issue. The new design has allowed developers to address scalability issues by replacing generic components with more efficient domain specific components. Since SHriMP is a research tool and has a high turn over of student programmers, another requirement we had to consider was maintainability. We also have several collaborations where other researchers who would like to extend our tool or use just some of the features in our approach. The new design provides simple interfaces for third parties to quickly integrate SHriMP with other tools, as was demonstrated in a collaboration with an IBM tool (see Section 5) [4, 15].
4. COMPONENT-BASED FRAMEWORK To aid in our redesign, we adopted the framework approach as described by Roberts and Johnson: “Frameworks are reusable designs of all or part of a software system described by a set of abstract classes and the way instances of those classes collaborate” [17]. Thus frameworks are easy to generalize,
Figure 1: The components in the new architecture. The arrows represent adapters between the components. The first two components (Data and Display) are wrapper components. Each component wraps an outside resource for use in the internal system. Wrapper components allow similar resources (such as a new data model or new graphical engine) to replace the current ones without reengineering the entire system. The other components are support components and provide certain services to the first two. Both wrapper and support components can be replaced to customize SHriMP or improve the scalability of SHriMP for a particular domain. All of the components use two common structures: artifact and relationship. An artifact represents the data used to create a node, where a node is the visual box displayed on the screen. Likewise, a relationship is the data used to create an arc that is visually displayed on the screen as a line connecting two nodes. These two data structures provide the only common medium for data transfer between components, ensuring the independence of each component and increasing the ease of maintainability. The Data Component is the largest component, and contains all of the hierarchical data for the domain. Through its interface, the data hierarchy can be traversed and manipulated. The internal structure of the Data Component will be very different for each domain. The Display Component is the second largest component as it holds all of the display related information. We predicted that many people would write their own Data Components to support their specific domain, but not many would need to change the Display Component. Based on this assumption, we made the
- SEKE '02 - 324 -
interface to the Display Component simple, yet flexible enough to cover a wide range of domains. The rest of the components are as follows: Each Persistent Storage Component handles all of the input and output of artifacts/relationships to a specific file format. To support a new file format, a developer can implement the Persistent Storage Component interface and plug the new component into the rest of the system. The Selector Component holds a list of global information. It was created for efficient access by all adapters. The Filter Component is responsible for managing the filters for the system. The Filter Component provides a service to determine whether an artifact or relationship should be filtered. The History Component provides an undo/redo service. The Search Component provides a simple but powerful interface for searching through the artifacts and relationships for information. The Hotbox Component is based on the Hotbox menu widget, developed by Kurtenback et al [8], providing rapid access to commands through a popup menu. Adapters are used to tie the components together and to handle all of the actions in SHriMP (see Fig. 4). Adapters are simple classes used to catch an event (a notification an action has happened) from one component and call one or more actions in the appropriate component. For simplicity a single action is mapped to a single adapter. By using adapters we provide flexibility and customization in the system. When integrating with other tools, functionality can be added, disabled or tweaked without modifying the components.
Figure 2: Visualizing Eclipse flow diagrams in SHriMP
5. DISCUSSION The framework described in this paper has so far been applied to two domains: software visualization and knowledge visualization. The latter was done initially using data integration (by importing Protégé data into SHriMP) and extended a second time by adding control and presentation integration (by nesting SHriMP with Protégé). In order to validate the framework further, we needed to integrate SHriMP with even more tools and in new domains. Therefore, as a first step in this evaluation, we have also been integrating SHriMP with IBM’s MQSI (Message Queue System Integrator) product via the IBM Websphere Studio Workbench described at www.eclipse.org [15]. We have customized and
retargeted SHriMP for visualizing flow diagrams (Figure 2). Flow diagrams are used in an eBusiness project to model the dynamic aspects of a system, such as the main activities and the movement of information and data in a business process. Flow diagrams can be hierarchically composed, thus leveraging the key features of SHriMP that allow a user to navigate hierarchically composed information spaces. To achieve this integration developers at IBM exported the required information to the RSF file format and made use of our RSF Persistent Storage Component. Although this integration required some changes to be made to the visual components, overall the framework enabled the IBM team to do this integration quite easily. More recently we have integrated SHriMP with the Java development environment that is central to the IBM Websphere Workbench. Figure 3 shows a picture of how SHriMP has been integrated with this development environment. To do this integration, we created a new Data Component to pull information from Eclipse. All of the other components did not need to be changed in any way. Many other plugins are available in the Eclipse framework (such as CVS and Rational Rose). Our future work is now to integrate with these other plugins and evaluate if the SHriMP framework supports their visualization requirements.
Figure 3: This view shows how SHriMP integrated with the IBM Websphere Java development environment. Now that SHriMP has been integrated with a knowledge management tool such as Protégé, and an industrial strength software development environment, the need to display larger projects is a pressing requirement. The new design positions us to address issues of scalability by adding new ways of visualizing large numbers of nodes. For example, for a node that has thousands of children we can add a different view in the Display Component (there would be little point in showing a graphical view of thousands of nodes, but showing how “connected” they are by way of a “glyph” could be beneficial). There may be some overhead incurred through use of the adapters and this was a concern when we embarked on the new design. Fortunately, we have not seen any performance degradation by using the components and adapters. This is
- SEKE '02 - 325 -
something we may have to revisit in the future. At the moment the biggest barrier appears to be limitations with the graphical operations provided by Java. To date the new design has been easier to maintain. As new people have joined our group they have been able to understand the code and participate in our project. However, we need to get feedback from other groups as they try to extend SHriMP. We currently have several interested parties in extending the source code. We will use their feedback to help improve the architecture of SHriMP and the documentation of our framework.
6. CONCLUSION AND FUTURE WORK In this paper we described a component-based framework for visualizing large, complex information spaces. This framework has been applied in several contexts, demonstrating that the resulting tool (SHriMP) can be extended and customized to suit other domains and tools. The architecture is still being refined as we do further integrations and customizations, but so far, our initial experiences with this design have been encouraging. Many visualization tools are still highly domain dependent, where the underlying model of information being visualized is encoded (sometimes implicitly) in the user interface. Some visualization tools do allow customization according to a schema in a database (such as the Polaris tool [13]), but most visualization tools cannot be easily extended to other domains. Our future plans are to continue improving the architecture of our framework by applying it to other domains and extending the functionality within those domains. Scalability of the architecture, as well as scalability of the visualizations, is a big concern. We will address both as we broaden our scope. Applying visualization techniques developed for software engineering to a knowledge engineering tool has so far been very interesting. The integrations with different sets of tools have resulted in ideas that have benefited both toolsets. By using a framework of reusable components, we are able to reap the benefits of the shared insights in visualization from these two closely related domains.
7. ACKNOWLEDGEMENTS This research was supported in part by CSER, NSERC, IBM, Stanford University, the University of Victoria, the University of Texas at Austin and the Space and Naval Warfare Systems Center San Diego. The content of the information does not necessarily reflect the position or the policy of any of the universities nor the US or Canadian and no official endorsement should be inferred. Special thanks to all the development teams involved with the third party integrations. Also a special thanks to the SHriMP development team.
8. REFERENCES [1] Best, C. Master’s Thesis, University of Victoria, To be published fall 2002. [2] Booch, G. The Unified Modeling Language User Guide, Addison Wesley, Reading, MA, 1998. [3] Brodie, M., and Stonebraker, M. Migrating Legacy Systems: Gateways, Interfaces and the Incremental Approach, Morgan Kaufmann Publishers, 1995.
[4] Eclipse. http://www.eclipse.org. [8] Kurtenbach, G., Fitzmaurice, G., Owen, R., and Baudel, T. The Hotbox: Efficient Access to a Large Number of Menuitems, Proceeding of the CHI 99, May 1999. [9] Larsen, G. Designing Component-Based Frameworks Using Patterns in the UML. Communications of the ACM, Volume 42, Issue 10, pages 38 – 45, New York, New York, 1999. [13] Polaris: A System for Query, Analysis and Visualization of Multi-dimensional Relational Databases by Chris Stolte and Pat Hanrahan: http://graphics.stanford.edu/papers/polaris/ [14] Protégé project, Stanford University, http://protege.stanford.edu. [15] Rayside, D., Litoiu, M., Storey, M., and Best, C. Integrating SHriMP with the IBM Websphere Studio Workbench, Proceedings of CASCON'2001, Toronto, Canada, November 2001. [17] Roberts, D., and Johnson, R., Evolving Frameworks: A Pattern Language for Developing Object Oriented Frameworks, Proceedings of the Third Conference on Pattern Languages and Programming, Montecillio, Illinois, 1996. [18] Shrimp Views. http://www.shrimpviews.com. [19] Storey, M., and Müller, H. Manipulating and Documenting Software Structures using SHriMP Views. In Proceedings of the 1995 International Conference on Software Maintenance (ICSM ’95), Opio (Nice), France, pp. 275-284, October 1995. [20] Storey, M., Musen, M., Silva, J., Best, C., Ernst, N., Fergerson, R., and Noy, N. Jambalaya: Interactive visualization to enhance ontology authoring and knowledge acquisition in Protégé, appeared in Workshop on Interactive Tools for Knowledge Capture, K-CAP-2001, October 20, 2001, Victoria, B.C. Canada. [21] Storey, M., Wong, K., Fong, P., Hooper, D., Hopkins, K., and Müller, H. On designing an experiment to evaluate a reverse engineering tool, in Proc. Of the 3rd Working Conference on Reverse Engineering (WCRE '96), pp. 31-40, November 1996. [22] Storey, M., Wong, K., and Müller, H. How Do Program Understanding Tools Affect How Programmers Understand Programs? Science of Computer Programming, vol. 36 (23), pp. 183-207, March 2000. [24] Wu, J., and Storey, M. A Multi-Perspective Software Visualization Environment, in Proc. of CASCON’2000, pp. 41-50, November 2000. [25] Wasserman, A. Tool Integration in Software Engineering Environments. In F. Long (ed.) Software Engineering Environments, International Workshop on Environments Proceedings, Lecture Notes in Computer Science, No. 467, pp. 137 – 149, Springer-Verlag, Sep 1989.
- SEKE '02 - 326 -