Co-evolving code and design with intensional views: A case study

doi:10.1016/j.cl.2005.09.002

Computer Languages, Systems & Structures

Volume 32, Issues 2–3, July–October 2006, Pages 140-156

https://doi.org/10.1016/j.cl.2005.09.002 Get rights and content

Abstract

Intensional views and relations have been proposed as a way of actively documenting high-level structural regularities in the source code of a software system. By checking conformance of these intensional views and relations against the source code, they supposedly facilitate a variety of software maintenance and evolution tasks. In this paper, by performing a case study on three different versions of the SmallWiki application, we critically analyze in how far the model of intensional views and its current generation of tools provide support for co-evolving high-level design and source code of a software system.

Introduction

Maintaining the source code of long-lived software systems requires an adequate documentation of their intended design. However, due to their constant evolution, it is often hard to keep their source code and design synchronized. This is partly due to the fact that current-day integrative development environments still focus too much on writing code and too little on supporting maintenance and evolution tasks [1].

Intensional source-code views and relations [2], [3], [4], [5] have been proposed as an active documentation technique that addresses some of these problems. They increase our ability to understand and document the code and its design by grouping together structurally related source-code entities. They facilitate software maintenance and evolution, because alternative descriptions of the same intensional view can be checked for consistency and because relations between intensional views can be defined and verified against the source code.

In [2] we explained how to codify software architectures by means of intensional source-code views² and how to check conformance of those architectures with the source code. In [3] we proposed intensional views as an intuitive and lightweight but verifiable means of documenting crosscutting concerns in a software system. In [4] we discussed how intensional views facilitate a variety of software understanding, maintenance and evolution tasks. Finally, [5] emphasized on documenting and verifying high-level relations between intensional views. We also discussed the analogy of testing structural source-code regularities in a software system by means of intensional views and relations with testing the behavior of a software system by means of unit tests.

To define and verify intensional views and their relations we built a tool suite which we called IntensiVE. This ‘Intensional View Environment’ was implemented entirely in and seamlessly integrated with the VisualWorks Smalltalk development environment and comprises, amongst others, the following tools:

The intensional view editor

(Fig. 1) allows us to document relevant concerns in the source code in terms of intensional views and to inspect the source-code entities corresponding to such concerns.

The view consistency checker

(Fig. 2) allows us to verify consistency between different alternative descriptions of an intensional view, with respect to the current source-code base, and to provide fine-grained feedback on the differences between these alternative definitions.

The relation editor

(Fig. 3) allows us to document high-level relationships between intensional views, as well as known deviations of these relationships in the source code.

The relation checker

(Fig. 4) allows us to verify these relations against the current source code, and provides fine-grained feedback on their validity.

Whereas older versions of these tools have been reported on briefly in [5], we have recently re-implemented them entirely to improve their efficiency, persistence and integration with version 2 of the StarBrowser [6], an advanced source code browser for VisualWorks Smalltalk. In addition to having the logic query language Soul [7] as underlying language in which to describe the intensional views and relations, the tools now offer support for using Smalltalk too as query language to reason about source code. Another novel feature is the ability to define nested views, which allows us to create context-specific views. Finally and most importantly, we added support for visualizing intensional views and relations (see Fig. 5), by relying on CodeCrawler [8], a reverse engineering tool which combines software metrics and visualization.

The aim of this paper is to perform a critical evaluation of the current generation of tools, including the new opportunities offered by the visualization tool, to support co-evolution of high-level design and source-code of a medium-sized Smalltalk application. The case we selected for this study is SmallWiki [9], an object-oriented Wiki implementation in Smalltalk. We documented the intended design of an early version of SmallWiki and observed how this documentation helped us in better understanding the software and its implementation structure, as well as in discovering certain structural irregularities in its source code. Then we verified this design documentation against two more recent versions of SmallWiki and discovered some interesting ways in which the source code and its design evolved.

From the experiences gained with this case study, we distilled a list of lessons learned about the model of intensional views and relations and its associated tools, in particular on how they support co-evolution of source code and higher-level design. Amongst others we learned that documenting the design of a software system with intensional views and relations allowed us not only to detect interesting structural inconsistencies introduced in the code upon evolution, but also that the process of documenting itself helped us to better understand the source code and how it evolved. A dedicated visualization which highlights what views and relations have become inconsistent with the code, proved very useful since it allowed us to readily assess the impact of an evolution step and locate potential structural problems. Finally, the ability of using and combining both logic and Smalltalk queries had the advantage that we could always choose the query language most appropriate to our needs, that is, the one that yields the most compact and declarative queries.

Section snippets

Experimental setup: SmallWiki

A Wiki is a collaborative web application that allows users to add content, but also allows anyone to edit the content. SmallWiki [9] is a fully object-oriented and extensible Wiki framework that was developed entirely in VisualWorks Smalltalk. As opposed to most other Wiki implementations, which are hard to adapt, SmallWiki has been designed from the start with extensibility in mind. It has a clean object-oriented design where all entities that can be stored in web pages (text, links, tables,

IntensiVE

Before describing our experiments in more detail, in this section we give an overview of the model of Intensional Views and Relations, together with its associated tool suite: IntensiVE, or Intensional View Environment. The following five subsections each focus on one of the major sub-tools of the environment namely the intensional view editor, the view consistency checker, the relation editor, the relation checker, and the intensional view displayer. Along the way we explain the underlying

Experiment 1 (documenting the structure of $SmallWiki$ 1.54)

Having explained the IntensiVE toolsuite in detail, we now elaborate on the actual experiments we conducted on SmallWiki. In our first experiment we tried to document the intended design of SmallWiki version 1.54 and investigated how this documentation helped us in better understanding the implementation structure as well as some of the naming and coding conventions that were used. Due to a lack of adequate documentation for this particular version, the approach we adopted was largely manual.

Experiment 2 (Comparing the documentation with $SmallWiki$ 1.90)

In the second experiment we compared the documented design of version 1.54 to the more recent version 1.90 and tried to understand how SmallWiki evolved, and what the consequences of this evolution were on the design documentation. To do so, we loaded the new version and recomputed and visualized all known intensional views and relations with the Intensional View Displayer. As explained in Section 3.5 and illustrated in Fig. 8, all conflicting views and relations were highlighted in red. We

Experiment 3 (Verifying the design structure of $SmallWiki$ 1.304)

In the third and last experiment we reverified our design documentation on yet a more recent version of SmallWiki (the one visually represented in Fig. 5) and drew conclusions about the usefulness of intensional views and relations to document the design structure of an evolving software system over a longer development period. Again, the design documentation appeared to be quite stable, but nevertheless we discovered some interesting inconsistent views and invalid relations, which are

Critical analysis and lessons learned

In this section, based on our experiences gained with the SmallWiki case, we perform a critical analysis of the current generation of tools—including the new opportunities offered by the visualization tool—and of the underlying model of intensional views and relations, to support co-evolution of high-level design and source code of a medium-sized Smalltalk application.

Deviations.

The experiments illustrated the importance of being able to define explicit deviations (inclusions and exclusions) to

Conclusion

This paper investigated how the model of intensional views and relations and the IntensiVE toolsuite can be used to support co-evolution of source code and design of a software system. The evaluation was done by documenting the design of an early version of SmallWiki and checking this documentation against two more recent versions of SmallWiki. Doing these experiments we observed that

$•$
Although building a first version of the design documentation of an unknown system remains a largely manual

References (12)

Ko AJ, Aung HH, Myers BA. Eliciting design requirements for maintenance-oriented ideas: a detailed study of corrective...
Mens K, Wuyts R, D’Hondt T. Declaratively codifying software architectures using virtual software classifications. In:...
Mens K, Mens T, Wermelinger M. Maintaining software through intentional source-code views. In: Proceedings of the...
Mens K, Poll B, González S. Using intentional source-code views to aid software maintenance. In: Proceedings of the...
Mens K, Kellens A. Towards a framework for testing structural source-code regularities. In: Proceedings of the 21st...
Wuyts R, Ducasse S. Unanticipated integration of development tools using the classification model. Computer Languages,...

There are more references available in the full text version of this article.

Cited by (57)

Continuous quality assessment with inCode
2017, Science of Computer Programming
Citation Excerpt :
When it comes to tools for quality assessment we have to distinguish between two categories: standalone QA tools and tools integrated in IDEs [27,14,12]. There are a number of commercial standalone tools like Klocwork Insight [18], Structure 101 [35], as well as dedicated open-source QA tools like PMD [4], Checkstyle [8], FindBugs [10], IntensiVE [26], or JLint [15]. Furthermore, there are also some source code analysis environments like Sonar [36], or ConQAT [7].
In spite of the progress that has been made over the last ten years in the research fields of software evolution and quality assessment, developers still do not take full advantage of the benefits of new assessment techniques that have been proposed by researchers. Beyond social factors, we believe that there are at least two main elements that contribute to this lack of adoption: (i) the insufficient integration of existing techniques in mainstream IDEs and (ii) the lack of support for a continuous (daily) usage of QA tools. In this context this paper introduces inCode, an Eclipse plugin aimed at transforming quality assessment and code inspections from a standalone activity, into a continuous process, fully integrated in the development life-cycle. But inCode not only assesses continuously the quality of Java systems; it also assists developers in taking restructuring decisions, and even supports them in triggering non-standard, complex refactorings. This paper introduces inCode's differentiating features, it presents the design goals that shaped our construction decisions, and describes a controlled experiment designed to validate the usability of the tool. The experiment has indicated that developers using inCode are more efficient in refactoring design fragments affected by design flaws.
Usage contracts: Offering immediate feedback on violations of structural source-code regularities
2015, Science of Computer Programming
Citation Excerpt :
Our motivation for proposing an internal DSL to express structural regularities stems from our prior experience with developing and using an external DSL for that purpose. More specifically, in our earlier work on SOUL [8,32] and the IntensiVE tool suite [4,31,33] we explored how to express structural regularities in a declarative program query language on top of an object-oriented host language. In spite of the good symbiosis of the declarative language and supporting toolsuite with the underlying language and its IDE, the fact that developers had to learn a new declarative language in which to express their regularities, turned out to be a major inhibitor towards adoption.
Developers often encode design knowledge through structural regularities such as API usage protocols, coding idioms and naming conventions. As these regularities express how the source code should be structured, they provide vital information for developers using or extending that code. Adherence to such regularities tends to deteriorate over time because they are not documented and checked explicitly. This paper introduces uContracts, an internal DSL to codify and verify such regularities as ‘usage contracts’. Our DSL aims at covering most common usage regularities, while still providing a means to express less common ones. Common regularities are identified based on regularities supported by existing approaches to detect bugs or suggest missing code fragments, techniques that mine for structural regularities, as well as on the analysis of an open-source project. We validate our DSL by documenting the structural regularities of an industrial case study, and analyse how useful the information provided by checking these regularities is for the developers of that case study.
Verifiable source code documentation in controlled natural language
2014, Science of Computer Programming
Citation Excerpt :
The use of logic to describe and check software architecture has been explored in depth [44,45]. In this context, a number of different tools have been implemented, e.g., Reflexion Models [46], ArchJava [47], Lattix Inc's dependency manager [48], and Intentional Views [49]. However, in contrast to the approach presented here, the resulting formal models of the architecture cannot be read and queried in a natural way and, as far as we are aware of, they have not been used in practice to document software.
Writing documentation about software internals is rarely considered a rewarding activity. It is highly time-consuming and the resulting documentation is fragile when the software is continuously evolving in a multi-developer setting. Unfortunately, traditional programming environments poorly support the writing and maintenance of documentation. Consequences are severe as the lack of documentation on software structure negatively impacts the overall quality of the software product. We show that using a controlled natural language with a reasoner and a query engine is a viable technique for verifying the consistency and accuracy of documentation and source code. Using ACE, a state-of-the-art controlled natural language, we present positive results on the comprehensibility and the general feasibility of creating and verifying documentation. As a case study, we used automatic documentation verification to identify and fix severe flaws in the architecture of a non-trivial piece of software. Moreover, a user experiment shows that our language is faster and easier to learn and understand than other formal languages for software documentation.
Enforcing structural regularities in software using IntensiVE
2010, Science of Computer Programming
The design and implementation of a software system is often governed by a variety of coding conventions, design patterns, architectural guidelines, design rules, and other so-called structural regularities. To prevent a deterioration of the system’s source code, it is important that these regularities are verified and enforced upon evolution of the system. The Intensional Views Environment (IntensiVE), presented in this article, is a tool suite for specifying relevant structural regularities in an (object-oriented) software system and verifying them against the current and later versions of the system. At the heart of the IntensiVE tool suite are (logic) program queries and the model of intensional views and relations, through which regularities are expressed. Upon verification of these regularities in the source code of the system, IntensiVE reports the code entities (i.e. classes, methods, variables, statements, etc.) that violate these constraints. We present IntensiVE and illustrate its application to the verification of an Abstract Factory design pattern in the implementation of a software system.
Codoc: Code-driven Architectural View Specification Framework in Python
2021, Proceedings - 2021 Working Conference on Software Visualization, VISSOFT 2021
Open programming language interpreters
2017, arXiv

View all citing articles on Scopus

¹: Andy Kellens is funded by a Ph.D. scholarship funded by the Institute for the Promotion of Innovation through Science and Technology in Flanders (IWT Vlaanderen).

View full text