Cognitive science emphasizes the strength of visual formalisms for human learning and problem solving. In software engineering, a clear, visual presentation of a system's architecture can significantly reduce the effort of comprehension. Yet, all too often the documentation of complex software systems lacks clear identification of the architectural constituents and insufficiently relates them to the source code. It is our contention that visualization of the architectural constituents within the source code model is an indispensable aid for the guided evolution of large-scale software systems. In this paper, we present a prototype tool for visualizing both published, generic design patterns as well as well-thought, ad-hoc design solutions, given the reverse-engineered source code of some system. We discuss the architecture and core functionality of this tool, addressing source code reverse engineering, design repository, design representation, and design clustering. Then, we present our visualization objectives and detail our techniques for pattern visualization. A case study example helps explicate and illustrate our work. Keywords: Design visualization, software comprehension, design pattern, design component, software architecture, object-oriented design, tool support. Software comprehension is strongly related to the ability to reason about a system's architecture [14] . Knowledge about the environment and the culture in which a system was built and embedded is a prerequisite for architectural reasoning. In civil engineering, for instance, deep understanding of the design of buildings and towns demands prior understanding of the geography, the culture, and the living circumstances of its inhabitants [1] . This example may well be adapted to fit many other engineering disciplines including software engineering; yet, there is a subtle difference between classical engineering and software engineering. Whereas in classical engineering architectural styles are often perceivable just by looking at the outwards visible form and behavior of a system, software engineering lacks such mapping between external appearance and internal structure. In software engineering, all to often, reasoning about the architecture of a system is based on the system's input/output behavior, leading to wrong maintenance decisions, which finally break the conceptual integrity [5] of the architectural design. To allow the developers to make more informed decisions, we are working on a process and a tool that can preserve the history of both the initial design and the subsequent evolution of software. We believe that knowledge about the culture and the development process is a prerequisite for the guided evolution of software. Documenting the design and change decisions on a system's evolution path, and how these decisions relate to its basic constituents (such as classes, attributes, methods, and relationships), is an indispensable aid to understanding the subtle trade-offs inherent in software systems. It is our contention that for effective system comprehension, such documentation must be rendered by appropriate visualization techniques. We agree with Harel that "successful system development in the future will revolve around visual representations" [11] . Our approach to a more principled process of software construction [15, 16] is based on patterns, such as architectural patterns, design patterns, idioms, and protopatterns ("patterns in waiting that are not yet known to recur" [2] a compositional development process in which software is constructed by specialization, adaptation, assembly, and alteration of more basic design components. A main contribution of this approach is that it provides complete patterns (that is, not only their structure, but equally important, their intent, applicability, motivation, and all other more informal constituents) as tangible software design artifacts. A further contribution is that such design components can serve as the foundation for a compositional software development process, in which basic design components are assembled to composite components, which in turn may serve as basic components for a more complete or more complex design. Finally, a third contribution is that the evolution of design components can be traced, allowing looking back into the history of a system and its architectural evolution. For further details on this approach, refer to [15, 16] . In this paper, we focus on the visualization of patternbased software design and its rationale, and discuss a prototype tool we have been developing to this end. As a motivation, section 2 of the paper presents a case study example. Section 3 describes the core functionality and architecture of our tool. Specifically, four aspects are covered: source code reverse engineering, design repository, design representation, and design clustering. Then, section 4 details the visualization aspect of design pattern engineering. Section 5 addresses related work, and finally, section 6 rounds up the paper with a conclusion and a discussion of ongoing work. Gamma et al. [9] motivate their design pattern catalogue with a case study in which they apply some of their design patterns to Lexi, a simplified version of the Doc editor [6] . Lexi allows for the editing of documents comprising text, graphics, charts, and the like, supports multiple formatting algorithms for text layout, and exhibits a graphical user interface. Gamma et al. describe seven design problems when building such a document editor and use eight patterns for their solution (Table 1) . In this paper, we are using Lexi as a case study, since it has a limited scope, yet is complex enough to communicate all major issues of our design visualization approach. Figure 1 illustrates Lexi as a cluster of interrelated classes and class hierarchies. Looking at Lexi from this perspective, one may well understand its class structure, but still, it will take even a professional designer quite some effort to fully comprehend the responsibilities embodied in the Lexi design, and to understand how these responsibilities are scattered over the various classes. In essence, Figure 1 does not convey the design problems and solutions that go beyond classes and class hierarchies. Figure 2 , in contrast, shows the same class diagram, but overlaid with additional design information. It illustrates the complex mechanisms that hold Lexi together, and shows those classes in which these mechanisms collaborate to carry out the system's responsibilities. In Lexi, these mechanisms are based on well-known, well-proven design patterns, which further increases the expressiveness of the diagram. Design patterns are the vehicles that convey to the reader of the diagram not only the structure, behavior, and dynamics of the design, but equally important, the 1 The tool uses colored outlines around classes to distinguish among patterns; for this black/white presentation we chose to use enclosing polygons instead. design rationale and the trade-offs that were made when opting for a certain form of implementation [9] . Information on the conceptual architecture is indispensable for the guided evolution of software, yet hardly available and imprecisely communicated to the developer in traditional software development environments. This lack of information makes it difficult to pinpoint those classes that are most appropriate to incorporate responsibility for new or changed system requirements. With pattern-based visualization, we aim at increasing the information content in diagrams and providing for more insight into the conceptual architecture of software. The above example should be motivation enough to envision techniques and tools that organize software around patterns, visualize them, and allow for zooming in and out of both formal and informal pattern constituents. In this section, we discuss the core functionality and the architecture of the prototype tool we have developed to support these activities. The purpose of this tool is to help understand software by its organization around patterns. The tool addresses four main issues: source code reverse engineering, design repository, design representation, and design clustering (see Figure 3 ).  The purpose of source code reverse engineering is to extract a model from source code. At this time, we support only C++. Using the C++ source code analysis system GEN++ [7] , our tool generates an intermediate AS-CII-based representation of the relevant source code elements: classes, attributes, methods, generalization relationships, association relationships, and instantiation relationships. An import utility parses this intermediate representation and stores the source model in a central repository, referred to as design repository. Our intent for this ASCII-based intermediate format was to make the tool independent from any particular programming language. In an upcoming version, we will support CDIF (CASE Data Interchange Format) as the intermediate representation, for better compatibility with commercial CASE environments. The purpose of the design repository is to provide for centralized storage, manipulation, and querying of the source model, the abstract design patterns ("off-the-shelf" design patterns as found in the literature and described in template format [9] ), and the implemented design patterns within the source model. The schema of the design repository is based on the UML metamodel 1.1 [22] . Currently, the object-oriented database management system Poet50 [19] serves as the backend. The schema is represented as a Java 1.1 class hierarchy; the classes within this hierarchy constitute the models of the MVC-based graphic editors of the tool. Using the precompiler of Poet50's Java Tight Binding, an object-oriented database can be generated from this class hierarchy. The purpose of design representation is to provide for interactive visualization and refinement of source code models, abstract design patterns, and implemented patterns. This component is implemented based on Java 1.1 and the graphic editor application framework jKit/GO [13] . At the current stage of development, we have implemented class diagrams based on the UML notation 1.1 [22] . The informal constituents of design patterns are described with HTML. For visualizing the HTML code, the ICEBrowser tool [12], a JavaBeans component, is being used.
Schauer & Keller REF developed a tool for documenting software systems.
Pattern visualization for software comprehension
Proceedings. 6th International Workshop on Program Comprehension. IWPC'98 (Cat. No.98TB100242)
Proceedings. 6th International Workshop on Program Comprehension. IWPC'98 (Cat. No.98TB100242)
Computer Science