Pattern Visualization for Software ComprehensionAbstractCognitive science emphasizes the strength of visualformalisms for human learning and problem solving. Insoftware engineering, a clear, visual presentation of asystem’s architecture can significantly reduce the effort ofcomprehension. Yet, all too often the documentation ofcomplex software systems lacks clear identification of thearchitectural constituents and insufficiently relates themto the source code. It is our contention that visualizationof the architectural constituents within the source codemodel is an indispensable aid for the guided evolution oflarge-scale software systems. In this paper, we present aprototype tool for visualizing both published, generic de-sign patterns as well as well-thought, ad-hoc design solu-tions, given the reverse-engineered source code of somesystem. We discuss the architecture and core functionalityof this tool, addressing source code reverse engineering,design repository, design representation, and design clus-tering. Then, we present our visualization objectives anddetail our techniques for pattern visualization. A casestudy example helps explicate and illustrate our work.Keywords: Design visualization, software comprehen-sion, design pattern, design component, software archi-tecture, object-oriented design, tool support.1. IntroductionSoftware comprehension is strongly related to theability to reason about a system’s architecture [14].Knowledge about the environment and the culture inwhich a system was built and embedded is a prerequisitefor architectural reasoning. In civil engineering, for in-stance, deep understanding of the design of buildings andtowns demands prior understanding of the geography, theculture, and the living circumstances of its inhabitants [1].This example may well be adapted to fit many other engi-neering disciplines including software engineering; yet,there is a subtle difference between classical engineeringand software engineering. Whereas in classical engineer-ing architectural styles are often perceivable just bylooking at the outwards visible form and behavior of asystem, software engineering lacks such mapping be-tween external appearance and internal structure.In software engineering, all to often, reasoning aboutthe architecture of a system is based on the system’s in-put/output behavior, leading to wrong maintenance deci-sions, which finally break the conceptual integrity [5] ofthe architectural design. To allow the developers to makemore informed decisions, we are working on a processand a tool that can preserve the history of both the initialdesign and the subsequent evolution of software. We be-lieve that knowledge about the culture and the develop-ment process is a prerequisite for the guided evolution ofsoftware. Documenting the design and change decisionson a system’s evolution path, and how these decisionsrelate to its basic constituents (such as classes, attributes,methods, and relationships), is an indispensable aid tounderstanding the subtle trade-offs inherent in softwaresystems. It is our contention that for effective systemcomprehension, such documentation must be rendered byappropriate visualization techniques. We agree with Harelthat “successful system development in the future willrevolve around visual representations” [11].Our approach to a more principled process of softwareconstruction [15,16] is based on patterns, such as archi-tectural patterns, design patterns, idioms, and proto-patterns (“patterns in waiting that are not yet known torecur” [2]). The basic idea is to reify patterns as compo-nents. These design components constitute the artifacts ofRudolf K. KellerDépartement IROUniversité de MontréalC.P. 6128, succursale Centre-villeMontréal, Québec H3C 3J7, Canada+1 (514) [email protected] SchauerDépartement IROUniversité de MontréalC.P. 6128, succursale Centre-villeMontréal, Québec H3C 3J7, Canada+1 (514) 343-6111, [email protected] research was supported by the SPOOL project organized by CSER(Consortium for Software Engineering Research) which is funded byBell Canada, NSERC (National Sciences and Research Council of Can-ada), and NRC (National Research Council of Canada).a compositional development process in which software isconstructed by specialization, adaptation, assembly, andalteration of more basic design components. A main con-tribution of this approach is that it provides completepatterns (that is, not only their structure, but equally im-portant, their intent, applicability, motivation, and allother more informal constituents) as tangible softwaredesign artifacts. A further contribution is that such designcomponents can serve as the foundation for a composi-tional software development process, in which basic de-sign components are assembled to composite components,which in turn may serve as basic components for a morecomplete or more complex design. Finally, a third contri-bution is that the evolution of design components can betraced, allowing looking back into the history of a systemand its architectural evolution. For further details on thisapproach, refer to [15,16].In this paper, we focus on the visualization of pattern-based software design and its rationale, and discuss aprototype tool we have been developing to this end. As amotivation, section 2 of the paper presents a case studyexample. Section 3 describes the core functionality andarchitecture of our tool. Specifically, four aspects arecovered: source code reverse engineering, design reposi-tory, design representation, and design clustering. Then,section 4 details the visualization aspect of design patternengineering. Section 5 addresses related work, and fi-nally, section 6 rounds up the paper with a conclusion anda discussion of ongoing work.2. Motivating ExampleGamma et al. [9] motivate their design pattern cata-logue with a case study in which they apply some of theirdesign patterns to Lexi, a simplified version of the Doceditor [6]. Lexi allows for the editing of documents com-prising text, graphics, charts, and the like, supports multi-ple formatting algorithms for text layout, and exhibits agraphical user interface.Table 1. Design problems and design patterns in Lexidocument editor (adapted from [9])Design Problem Design Pattern1. Document structure Composite, Iterator2. Formatting Strategy3. Embellishing the user interface Decorator4. Multiple look-and-feel standards Abstract Factory5.