Published in the Proceedings of the International Conference on the ..... Object-Oriented Application Frameworks (edited by Lewis T.), Manning Publications.
R. Weinreich, J. Pichler
An Integrated Approach for Documenting, Exploring and Building Framework-Based Software
TR-SE 00.05
Copyright 2000 IEEE. Published in the Proceedings of the International Conference on the Technology of Object-Oriented Languages and Systems (TOOLS-37, 2000), Nov. 20-23, 2000, Sydney, Australia. Personal use of this material is permitted. However, permission to reprint/republish this material for advertising or promotional purposes or for creating new collective works for resale or redistribution to servers or lists, or to reuse any copyrighted component of this work in other works, must be obtained from the IEEE. Contact: Manager, Copyrights and Permissions / IEEE Service Center / 445 Hoes Lane / P.O. Box 1331 / Piscataway, NJ 08855-1331, USA. Telephone: + Intl. 908-562-3966.
A-4040 Linz (XURSH Altenberger Straße 69
An Integrated Approach for Documenting, Exploring, and Building Framework-Based Software Rainer Weinreich, Josef Pichler Software Engineering Group Department of Business Informatics Johannes Kepler Universität Linz, A-4040 Linz, Austria {weinreich, pichler}@swe.uni-linz.ac.at Abstract The use of well-designed class libraries and frameworks is a key element of object-oriented software development. However, while frameworks may significantly reduce development time and cost, they are difficult to understand and therefore hard to learn to use. We present an environment that supports documenting, browsing and editing of selected aspects of frameworks and framework-based applications on an abstraction level that is not available through static or dynamic program analysis. The main ideas of this environment are a specialized desktop metaphor for visualizing and browsing software architectures, the support of framework-based development by means of architecture templates, and an open tool architecture that supports the integration of any additional tools for visualizing and editing application and framework parts.
1. Motivation and overview Object-oriented and component-based programming focus intensely on software reuse. Reusing large libraries and frameworks leads to reduced development time and cost. In addition, welldesigned frameworks may lead to higher flexibility and better overall maintainability [1]. The drawback of a heavily reuse-oriented approach is the effort that is involved in finding and understanding the reusable assets. Many libraries and frameworks are large and complex. A significant amount of time has to be invested in learning and understanding classes, responsibilities and their collaborations. One way to aid in understanding class libraries and frameworks is to provide various forms of documentation (linear documentation, hypertext cookbooks, tutorials, active cookbooks, diagrams, etc.). Another way is to examine the source code using dedicated tools called browsers. Browsers extract information about a system’s architecture and implementation directly from the system itself (source code, run-time information) and present it to the user from a particular viewpoint. Examples of browsers provided by many object-oriented environments are class hierarchy browsers, search engines, import/export analyzers and cross-reference tools. Most software development environments provide moderate to good support for browsing and editing source code, but they lack high-level tools for investigating and manipulating framework and application architectures. We follow a hybrid approach that includes elements from both manual creation of documentation and browsing source code. We present the Architecture Explorer, an environment that supports documenting, browsing and editing of certain aspects of a software system’s architec-
ture on an abstraction level that is not available from just inspecting the system itself. The main ideas of this environment are a specialized desktop metaphor for visualizing and browsing software architectures, the support of framework-based development by means of architecture templates, and an open tool architecture that supports the integration of any additional tools for visualizing and editing application or framework parts. The remainder of this paper is structured as follows. In Section 2 we present various approaches for documenting and browsing object-oriented software. Section 3 describes the main ideas of our approach. In Section 4 we show how these ideas are supported by our environment; the section includes an overview of the environment’s main functionality and sample scenarios for working with architecture templates and documenting framework-based applications. The paper concludes with a short summary.
2. Approaches to understanding object-oriented software In this section we comment on two major approaches for learning and understanding objectoriented frameworks and applications: documentation and browsing. Documentation is especially important in the case of black-box reuse, i.e., if the source code of a library or an application is not available. This is often the case when we reuse third-party components or component frameworks for building new software systems. Browsing tools extract information from the actual system itself. They are important when documentation is either missing or incomplete, and for reverse engineering and maintenance tasks, which require more detailed information about architecture and implementation of a system. 2.1. Documentation Many object-oriented systems consist of hundreds of classes and interfaces. Object-oriented frameworks in particular (pre)define complex object interrelationships for various different application scenarios and types. A simple enumeration of classes and responsibilities or any other form of linear documentation cannot suffice for such software systems. Therefore many approaches to software documentation in the last decade are based on the principle of hypertext [2]. Hypertext-based approaches support nonlinear navigation through documentation by means of hyperlinks. The most prominent representative of hypertext systems is the Hypertext Markup Language (HTML) [3]. Hypertext-based documentation may be created either manually with hypertext editors or automatically. Automatic generation requires information about a system that is saved elsewhere (e.g., in repositories of CASE tools). An approach that is supported by nearly all development environments is the generation of HTML-based API reference documentation from source code that is augmented with special formatted comments (e.g., JavaDoc Tool [4]). This approach is related to browsing, which is investigated in the next section. Special forms of hypertext-based documentation for object-oriented software systems are hypertext cookbooks or tutorials. Instead of systematically describing the complete functionality of the underlying system, cookbooks and tutorials provide recipes for solving concrete problems. Although cookbooks are also useful in exploring and understanding frameworks, their primary intent is to support framework reuse, i.e., the construction of framework-based applications. A very popular HTML-based cookbook is the Java Tutorial (http://java.sun.com/tutorial). An early example of a hypertext cookbook for the application framework ET++ [5] has been described in Gamma et al. [6]. The ET++ cookbook integrates source code with cookbook recipes (i.e., documentation) by providing direct links from recipes to framework source code. The cookbook approach for supporting framework-based software development has been explored further else-
where [7, 8, 9, 10, 12]. Patterns [7], motifs [8] and application patterns based on the pyramid principle [9] are proposals for structuring recipes and cookbooks. Active cookbooks [10, 11] semi-automate recipes by integrating code generators for specific tasks. However, the idea of active cookbooks has only been sketched and still lacks adequate tools. SmartBooks [12] extends the idea of active cookbooks further and provides flexible and automatically generated recipes based on user-defined problem descriptions and automatic user task planning. Like most specification-driven approaches, SmartBooks suffers from the lack of a sufficiently accurate nonformal notation for describing the problems that a framework user wants to solve. 2.2. Browsing Browsing tools facilitate exploring software systems. Browsers display textual and graphical information about software components and their relationships and provide means for filtering and navigation. They are important means for understanding the functionality and interrelationships in large object-oriented libraries. The first comprehensive browsing environment for object-oriented systems was provided by Smalltalk [13]. In the meantime, most programming environments provide browsing support, although sometimes to a considerably lesser extent. An environment with extensive browsing support is SNiFF [14, 15]. The environment offers browsers for exploring classes and interfaces, inheritance relationships, usage relationships, etc. Other environments generate graphical representations in some kind of design notation. Examples include Together [16], which creates UML [17] diagrams from source code, and EiffelCase [18], which uses the BON notation. Browsers extract information either from source code (static program analysis) or from a running system (dynamic program analysis) or from both. The challenge of dynamic program analysis is to reduce a huge amount of data that is generated at run time and to provide meaningful filters for extracting information. Approaches for filtering run-time information about an object-oriented system on an architectural level have been described by Sefika et. al. [19] and by Walker et. al. [20]. Lange and Nakamura [21, 22] present a system combining static and dynamic program analysis to reduce the search space for extracting dynamic program information and creating appropriate visualizations of program behavior. Browsing tools based on static program analysis are especially useful for restructuring and reengineering tasks, but also for building applications and understanding frameworks (provided that the source code is available). Browsing dynamic program information requires an executable program, which may be a problem with frameworks unless a significant number of sample applications is available. The concept of browsing is also a promising approach for exploring manually created documentation. Rettig [23] states that even documentation that has been finely crafted by professional authors is seldomly read by users. Instead people prefer to explore a system and only refer to documentation if a system does not behave as expected. Similarly, Brockman [24] suggests that we “encourage active exploration of a system via intentionally incomplete information” as an approach for system documentation.
3. Main concepts of the Architecture Explorer The Architecture Explorer is an integrated approach combining hypertext-based documentation, browsing, and building support for frameworks and framework-based applications. The basic idea is to enable a software architect to specify architectural elements and relationships that are important to understand a framework or a complete application. As in creating the documentation for a particular software system, the architect is completely free in choosing an appropriate
abstraction level. In addition, the architect can specify links to source code and tools for visualizing and editing individual components, component relationships or whole application parts. These tools may be simple editors for entering configuration data, or more complex tools such as editors for user interfaces, automata and event-handling relationships. The result is hierarchically structured documentation that can be browsed and that contains references to source code and various browsing and editing tools. 3.1. Describing Architectures The desktop metaphor [25] provides users a familiar way to organize and manipulate data on a computer. As with an office desktop, data is stored in places like folders and can be viewed and manipulated using various tools. Most modern user interfaces that use this metaphor provide files, folders, applications (tools) and aliases as main elements. Files are containers for data and may be put into folders. Folders may be used for organizing information hierarchically and may contain files, other folders, and applications. The top-level folder in the resulting hierarchy is usually called the desktop. We use a kind of specialized desktop metaphor in combination with hyperlinks for describing, visualizing and browsing framework and application architectures. The basic elements for describing software architectures in our environment are not folders and files but architectural elements. Each architectural element either represents a (logical) component of the application, its responsibilities, or its relationships to other components. An architectural element may contain other architectural elements and additional textual and graphical documentation. As an example, consider the architecture of a text editor application on a Windows™ or Apple Macintosh™ platform. Such an application typically offers the possibility to edit a number of documents. Each document manages some kind of data (text) and uses other elements (windows, views) for visualizing and editing the data. Further responsibilities of a document are loading and saving the data. In our environment this architecture would be described by a hierarchy of architectural elements and hyperlinks between some of these elements. On the top level of the hierarchy, the application would be presented to the user as a single architectural element. The element representing the complete application could be decomposed into further elements representing its relevant parts (e.g., documents, dialogs, menus, etc.) and responsibilities. A document could be further decomposed into elements representing the data to be managed, views and windows for visualizing the data, command handlers, elements representing the functionality of loading and storing data, and so on. 3.2. Source code integration and building support Documenting frameworks and applications using our approach means finding the appropriate architectural elements and decomposing these elements into constituent parts, responsibilities, and links representing relationships to other elements. The resulting documentation is structured hierarchically and reflects important structural relationships of a framework or application architecture. Two additional features of our environment that are especially important for building and maintenance tasks are integration of source code and integration of additional tools. Integration of source code. Each architectural element that is used for describing a part of an application can be associated with the corresponding source code fragments. Such fragments can be individual classes and methods or even a single line of code. Integration of tools. Dedicated editors can be provided for manipulating those aspects of an application that are described by an architectural element. There may be several different editors
providing different editing capabilities for the same aspect. For example, a dialog box can be edited using a source-code editor or a user-interface editor. However, additional tools might handle specific elements or tasks. The tools for the various parts of an application’s architecture are selected at run time based on the aspect to be viewed or modified. This is similar to selecting tools based on document types in the desktop metaphor. However, since multiple tools may be available for editing a certain application part, the final decision for selecting a tool is left to the user. The abstraction level of the tools may differ considerably, and different domains may need specialized domain-specific tools that are integrated with the rest of the environment. For this reason, the environment needs a flexible and open architecture that allows easy integration of new tools for specific architectural aspects. The current implementation of the Architecture Explorer is based on the Combo framework [26], which provides a trading mechanism for finding appropriate tools at run time. 3.3. Architecture templates One of the main ideas that drive the development of our toolset is the support of frameworkbased software development. A framework is a reusable, semicomplete application that can be specialized to produce custom applications [27]. The essential point is that frameworks predefine component interactions. Framework users reuse not only individual components but also a particular software architecture. Of course, predefined component interactions limit the solution space. Thus frameworks are generic solutions for a particular class of problems or applications. How well a framework supports the construction of applications in particular domain depends on the framework’s design. Frameworks with a rigid architecture are easier to learn and use, but harder to adapt to specific requirements. Frameworks with a flexible architecture support a larger solution space, but they are harder to develop and understand. We support framework-based software development by means of architecture templates. Architecture templates are semifinished framework configurations for particular tasks. For each framework an arbitrary number of architecture templates may exist. Each template narrows the solution space supported by a framework and provide guidelines for documenting and building a particular kind of application using the framework. Ideally, architecture templates are created by framework developers and shipped with a particular framework. However, architecture templates may be created by framework users also. An architecture template in our environment consists of certain architectural elements, predefined relationships among these elements, links to source code, and integrated documentation. It may also contain dedicated building tools for those parts of a framework that are represented by an architectural element.
4. Architecture Explorer by example In this section we provide an overview of our environment and illustrate its main ideas. As an example, we use the DBCBrowser [29], a concrete framework-based application for browsing assertions in the programming language Python. After providing a basic understanding of the DBCBrowser in Section 4.1, in Section 4.2 we show how a documentation of this sample application might look in our environment. In Section 4.3 we describe the creation of architecture templates and in Section 4.4, we give an impression of how documentation and building support is provided based on architecture templates.
4.1. DBCBrowser - The sample application The DBCBrowser [29] supports the idea of Design by Contract [28] applied to Python. It can be used for adding assertions (class invariants, preconditions and postconditions) to Python code and for browsing, editing and removing existing assertions. The implementation of the DBCBrowser application is based on the application framework ET++ [5]. The main structure of many ET++ applications can usually be described in terms of a small set of application framework building blocks. These building blocks are chosen according to the type of applications that are to be supported by the framework. The main building blocks of ET++ are applications, documents, views and commands. (We comment on the structure of an ET++ application in more detail when describing architecture templates in Section 4.3) The DBCBrowser can manage multiple projects simultaneously. Each project is implemented as a special ET++ document, which holds the project-specific data and manages one or more views for visualizing the data. The main window of the application is the browser window shown in Figure 1.
Figure 1. DBCBrowser and type expression dialog The browser window is divided into three main parts. The upper part shows a list of all available classes (class view) and a list of all methods of the selected class (method view). The middle part of the browser displays the assertions of the selected class or method (assertion view). The icon associated with an assertion indicates its kind. Possible kinds are precondition, postcondition, and type expressions. Type expressions enable dynamic type checking in Python (the language is not statically typed). By default, all kinds of assertions are listed for the selected class and all of its superclasses. Three different filters can be applied to assertions, as shown in the lower part of the browser window. The hierarchy filter allows selection of assertions of specific classes along the inheritance path of class. The method filter can be used to display only specific kinds of assertions for a selected method. Similarly, the class filter is used for selecting from class-specific assertions such as invariants and type expressions. Existing assertions are edited using special dialogs, also shown in Figure 1. Depending on the kind of assertion, a dialog contains controls that enable manipulation of the assertion or creation of a new one. The dialog in Figure 1 supports editing of type expressions and shows names and
types of the instance variables of a class Person. The type of an instance variable can be changed simply by dragging one of the types from the type list to the respective instance variable. 4.2. Browsing documentation Figure 2 gives an impression of how the architecture of the DBCBrowser application is mapped to architectural elements and hierarchical relationships in the Architecure Explorer. The tree view in the left part of the window displays the structure of the documentation, which corresponds to a hierarchical view on the application architecture. As described in the previous section, the DBCBrowser consists of a specialized ET++ document (the DBCDocument) and a set of views for presenting the data to a user in a browser window. The document contains data structures holding application-specific data. This includes various lists containing symbol information about Python classes, methods and assertions. In addition, the DBCDocument contains a command processor and a set of possible commands. The description of the browser window (see tree view in Figure 2) contains a number of views for displaying the content of the lists managed by the DBCDocument and an element describing the different kinds of filters. All dialogs of the application can be found in the Dialogs section of this documentation.
Figure 2. Main window and views on architectural elements The workspace on the right side of the main window in Figure 2 contains several windows, each providing a specialized view of one of the architectural elements of the tree to the left. The Architecture Explorer initially uses a desktop view for displaying the internal structure of an architectural element. The desktop view of a DBCDocument in Figure 2 shows the elements constituting a DBCDocument and additional elements representing links to external API documentation. The desktop view of the Change Type command contains a short annotation that hints where instances of this command are created. Such descriptions may be placed anywhere in a desktop view and may contain hyperlinks to other parts of the documentation or to the source code as
well. For example, the hyperlink assertion dialog refers to the architectural element representing the dialog for editing type expressions in the DBCBrowser. The desktop view is one of four standard views on architectural elements; additional views are the tree view, the source view, and the property view. The source view shows how a part of an application that is described by an architectural element is represented in source code. Each architectural element may be mapped to one piece of code or to multiple source code fragments, which we call code sections. How an element is mapped to the appropriate points in source code is determined by the person creating the documentation. Note that the source view visualizes the actual source code. External changes to the source code are reflected in our environment. In addition, the source view can be used for editing code. This is important for maintenance and building tasks. In Figure 2 the source view of the Add Assertion command of the DBCBrowser application is shown. The view shows two code fragments, one containing the code for performing the command and one for the reversing command execution. The tree view shows hierarchical relationships of an architecture element. The property view can be used for specifying named properties for each architectural element. Such properties might be useful for dedicated builder tools. In addition to these standard views, our environment provides a mechanism for plugging in custom views for individual architectural elements. We use the Combo component trader [26] for finding appropriate view components for an architectural element. A typical example of a custom view is a graphical user interface editor. The top of the window in Figure 2 shows a list of icons representing tools that can be applied to the selected architectural element. While such tools may also be used for documentation, their main purpose is to support application building and modification as described in Section 4.4. Similar to views on architectural elements, tools may also be provided as plugable components and are selected at run time using the underlying component trader. 4.3. Creating architecture templates Architecture templates are semifinished framework configurations for particular tasks. An architecture template provides constraints for the structure of an application built on top of an existing framework as well as guidance and support for extending the framework towards a working application. A template in the Architecture Explorer consists of concrete and semi finished architectural elements, predefined relationships among these elements, links to source code and integrated documentation. In this section, we show how to define a simple architecture template for a particular kind of ET++ applications. ET++ [5] is an application framework for applications with highly interactive user interfaces; it was implemented in C++. The framework supports applications such as drawing editors, text editors and browsers. Typical characteristics of such applications include: • Documents are used as data containers and for loading and storing data. Users may open multiple documents with different contents. • Views are used for displaying document data in windows. • Commands are initiated by the user through direct-manipulation, menus, and keyboard shortcuts. The framework maps this application model onto a number of building blocks (i.e., classes) with self-documenting names. An instance of a specialized Application class stores global application data (such as the types of documents that can be opened) and manages a list of documents. Each document is an instance of an application-specific Document class. Document objects hold the application-specific data and provide services for loading and storing data in multiple formats.
The data of a document is displayed and edited in one or more views (i.e., instances of special View classes). Modifications triggered by the user are performed by special command objects. A global command processor executes individual commands and also controls an undo mechanism. 4.3.1. An ET++ specific architecture template
A simple architecture template for ET++ consists of architectural elements for describing the main ET++ building blocks. This includes elements such as Application, Document, View and Command. Simple relationships can be defined between these elements (see Figure 3). For example, an element of type Application must contain a Document. A Document must contain at least elements describing data, event handling, menu handling and command processing. It may, however, not contain an element of type Application.
Figure 3. Defining relationships between architectural elements These relationships define fundamental structural constraints on the application architecture. They are checked on creation and modification of documentation for frameworks and applications in our environment. As we show in Section 4.4 architecture templates provide guidance for both the process of documentation and application building activities. 4.3.2. Architecture templates and building tools
An application framework developer providing architecture templates may also provide dedicated building tools for specific architectural elements. Tools are provided as plugable components and can be seamlessly integrated by means of a trader. Every time an architectural element is selected, the trader searches for appropriate tools. Tools are selected by the trader if they are able to edit the selected element (see [26]). External tools can be integrated by means of tool links, which are plugable components functioning as a bridge to external applications. For our example, we implemented a simple tool for the generation of subclasses of the ET++ Document class. The generator can be parameterized with the class name and the names of the C++ files to be generated. A user may also select whether to create method frames either for event handling or for menu-handling or for both. If the menu-handling option is selected, a list of C++ constants identifying the appropriate ET++ command codes can be specified. Since this tool can be used for specifying both event-handling and menu-handling, the tool has been registered for the architectural elements MHandler and EHandler, which describe these aspects of a Document in Figure 2. Whenever either MHandler or EHandler is selected in the Architecture Explorer, the class generator is shown in its tool bar. It is conceivable that various building tools might be provided by framework producers. In fact, generator tools for general application aspects are already provided as part of commercial programming environments. However, our approach provides satisfactory support for applica-
tion building and maintenance only if a myriad of sometimes very small tools for generating, configuring and editing application parts is available. We need to support framework producers in producing such tools efficiently and even enable framework users to construct their own tools. Supporting the construction of such tools with a code-generation back-end will be a topic of future work. 4.4. Documentation and building support Finally, we provide a small step-by-step example of documenting an application based on a simple architecture template for ET++ applications. The procedure for building frameworkbased applications is similar, except that the source code associated with an architectural element is created and modified using the source-code view and framework-specific building tools. For documentation purposes, first a new project based on an existing architecture template is created. We use the template for a typical ET++ application as described in the previous section. The template contains a number of predefined architectural elements that can be used for building the documentation. In the case of ET++ these elements are Application, Document, View and Command. In fact, these predefined elements act as types for creating new architectural elements. The first element that is created for the description of the DBCBrowser is of type Application. Two main elements of a simple ET++ application are documents for managing data and views for visualizing data. For this reason, the desktop view of the newly created DBCBrowser depicted in Figure 4-1 already contains elements representing a Document and a View. This indicates that these elements have to be included in the description of an application. The icons of both Document and View are semitransparent, indicating that their documentation is not yet finished. After the documentation of an element is finished, its icon changes from semitransparent to solid. This is illustrated in Figure 4-2, which shows the desktop view of the architectural element describing the DBCDocument. The figure shows two solid elements describing the document’s data and other elements whose documentation is not yet finished. The icon of a higher-level element turns solid only if all required parts of its documentation are finished. If all elements of the DBCDocument’s desktop-view in Figure 4-2 are documented, the icon for the DBCDocument changes from semitransparent to solid (see Figure 4-3).
1: Incomplete application
2: Semifinished document
3: Semifinished application, finished document
Figure 4. Creating template-based documentation The documentation of an architectural element like the DBCDocument includes textual and graphical descriptions, links to external documentation, and links to source code (see Section 4.2). The person creating the documentation decides when the documentation of an architectural
element is finished. However, an architectural element on a higher level can only be finished if all of its mandatory parts are finished. These mandatory parts are defined by the architecture template. Thus an architecture template guides the documentation process by providing a predefined structure for the documentation. It also defines constraints on the structure. For example, adding an element representing an Application to a Document is not possible, since an application manages documents and not vice versa. The result of the documentation process is hierarchically structured documentation of the main parts of an application, which resembles main structural relationships of an application architecture. This documentation can be browsed by application developers and maintenance staff and can be used as an integrating shell for application building activities.
5. Conclusion We have presented an integrated approach and environment for documenting, exploring and building framework-based software. The environment is targeted at three main types of users: framework developers, application developers and application maintenance staff. Framework developers can use it for documenting frameworks and for creating architecture templates. Application developers might use it for browsing through semifinished applications (by means of architecture templates) and for creating and documenting framework-based applications. Application maintenance staff can use it for browsing through applications and for performing simple modifications. The environment is not an alternative to other tools supporting object-oriented or componentbased software development. It cannot replace tools for browsing source code of large software projects, nor can it substitute for cookbooks or tools for forward and reverse engineering. However, it can serve as a valuable addition to a repertoire of tools for framework-based software development.
6. Acknowledgements Early versions of the Architecture Explorer [26, 30] were implemented in C++/ET++ based on the Combo framework. The environment described in this paper is a newer version that was implemented in Java using Sun’s Java™ 2 SDK. The authors thank all persons that were involved in implementing the various versions of the Architecture Explorer, most notably Wolfgang Hartl, Alexander Bergsmann and Matthias Schillhuber.
7. References [1]
Gamma E., Helm R., Johnson R., Vlissides J. (1995). Design Patterns, Elements of Reusable Object-Oriented Software, Addison-Wesley.
[2]
CACM (1988, 1990). Special issues on hypertext, Communications of the ACM, Vol. 31 No 7 (July 1988) and Vol. 33 No 3 (March 1990).
[3]
W3C (2000). HTML Home Page (http://www.w3.org/MarkUp/).
[4]
SUN Microsystems (2000). JavaDoc Tool Home Page (http://java.sun.com/javadoc).
[5]
Weinand A., Gamma E. (1995). “ET++: A Portable Homogenous Class Library and Application Framework”, Object-Oriented Application Frameworks (edited by Lewis T.), Manning Publications.
[6]
Gamma E., Weinand A., Marty R. (1989). “Integration of a Programming Environment into ET++, A Case Study”, Proceedings ECOOP’89 (Nottingham, UK, July 10-14), Cambridge University Press (S. Cook, ed.), 283-297.
[7]
Johnson R.E. (1992). “Documenting Frameworks Using Patterns”, Proceedings OOPSLA’92 (Vancouver, Canada, Oct. 18-22, 1992), 63-76.
[8]
[9]
[10]
[11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[21] [22] [23] [24] [25] [26] [27] [28] [29] [30]
Lajoie R., Keller R.K. (1994). “Design and Reuse in Object-Oriented Frameworks: Patterns, Contracts, and Motifs in Concert”, Proceedings ACFAS 1994, Colloquium on Object-Orientation in Databases and Software Engineering, Montreal, Canada, 94-105. Meusel M., Krzystof C., Köpf W. (1997). “A Model for Structuring User Documentation of Object-Oriented Frameworks using Patterns and Hypertext”, Proceedings ECOOP'97, Lecture Notes in Computer Science, Springer Verlag. Schappert A., Sommerlad P., Pree W. (1995). “Automated Support for Software Development with Frameworks”, Proceedings Symposium on Software Reusability (SSR’95), ACM Software Engineering Notes, August 1995. Pree W. (1995). “Framework Development and Reuse Support”, Visual Object-Oriented Programming (edited by Burnett M., et. al), Manning Publications. Ortigosa A. and Campo M. (1999). “SmartBooks: A Step Beyond Active Cookbooks to Aid in Framework Instantiation”. Proceedings TOOLS-29 (Nance, France, June 7-9), IEEE Computer Society Press. Goldberg A. (1984). Smalltalk-80, The Interactive Programming Environment, Addison-Wesley, Reading, MA. Bischofberger W. (1992). “Sniff—A Pragmatic Approach to a C++ Programming Environment”, Proceedings USENIX C++ Conference (Portland, USA), USENIX Assoc., El Cerrito, 67-81. Windriver (2000). SNiFF Home Page (http://www.windriver.com/sniff). TogetherSoft (2000). Together Home Page (www.togethersoft.com). Booch G., Rumbaugh J., Jacobson I. (1999). The Unified Modeling Language User Guide, Addison-Wesley. Interactive Software Engineering (2000). Eiffel Home Page (www.eiffel.com). Sefika M., Sane A., Campell R.H. (1996). “Architecture-Oriented Visualization”, Proceedings OOPSLA’96, 389-408. Walker J.R., Murphy G.C., Freeman-Benson B., Wright D., Swanson D., Isaak J. (1998). “Visualizing Dynamic Software System Information through High-level Models”, Proceedings OOPSLA'98 (Vancouver, Canada), 271-283. Lange D.B., Nakamura Y. (1995). “Program Explorer: A Program Visualizer for C++”, Proceedings USENIX COOTS'95 (Monterey, California, USA), June 1995. Lange D.B., Nakamura Y. (1997). “Object-Oriented Program Tracing and Visualization”, IEEE Computer, May, 1997, 63-70. Rettig M. (1991). “Nobody Reads Documentation”, Communications of the ACM, Vol. 34 No 7, July 1991. Brockmann R.J. (1990). “The Why, Where and How of Minimalism”, Proceedings ACM SIGDOC’90, 111-119. Johnson J., Roberts T.L., Verplank W., Smith D.C., Irby C., Beard M., Mackey K. (1989). “The Xerox ’Star’: A Retrospective”, IEEE Computer, September 1989. Weinreich R. (1997). “A Component Framework for Direct-Manipulation Editors”, Proceedings TOOLS-25 (Melbourne, Australia, Nov. 24-28, 1997), IEEE Computer Society Press, 1998. Fayed M.E., Schmidt D.C. (1997). “Object-Oriented Application Frameworks”, Communications of the ACM, Vol. 40 No 10, October 1997. Meyer B. (1997). Object-Oriented Software Construction, Second Edition, Prentice-Hall. Plösch R. (1998). “Tool Support for Design by Contract”, Proceedings TOOLS-26 (Santa Barabara, USA, Aug. 3-7, 1998), IEEE Computer Society Press, 1998. Hartl W. (1997). A Tool for the Visualization of Framework-Based Software Architectures (in German), masters thesis, C. Doppler Laboratory for Software Engineering, Department of Business Informatics, University of Linz.
