Back to Peyman Oreizy's home page
Appeared at the Proceedings of the International Conference on the Principles of Software Evolution (IWPSE 1). Kyoto, Japan. April 20-21, 1998.
Developers frequently confront a dilemma that may be characterized by the following:
As a result, a relatively small change in functionality necessitates a disproportionately large amount of effort, and curtails the opportunity for software reuse. This undesirable outcome may have been avoided if the off-the-shelf application supported decentralized software evolution, which we define as the ability to evolve software independent of the original software vendor.
Decentralized software evolution (hereafter abbreviated DSE) provides a means for third-party software vendors to customize existing applications for particular domains and customers. This capability benefits everyone involved: the original application vendor sells more product since customization constitutes use; the third-party developer delivers a product in less time and with lower cost by reusing software instead of starting from scratch; and the customer receives a higher quality product in less time and with lower cost.
Although reliable, rapid, and cost effective software evolution has been a principal concern of software research since the 1970's, results to date do not directly address DSE. The principles and techniques of software evolution--anticipation of change, separation of concerns, modularity, information hiding , object-oriented design , mediator-based design , adaptive object-oriented design , design patterns , aspect-oriented design , etc.--help design evolvable software systems. Unfortunately, the flexibility attained using these techniques is lost when the application is compiled for use. The compilation process solidifies the plasticity of a design, making it exceedingly difficult to accommodate a change that would otherwise be easy to make. The objective of DSE is to preserve the design's plasticity in the deployed system, thereby enabling third-party evolution.
The rest of the paper is organized as follows. Section 2 characterizes DSE within the broader context of software evolution. Section 3 surveys existing techniques for supporting DSE. Section 4 presents our approach to DSE, and section 5 summarizes our experience in applying our approach to several example applications. Section 6 discusses some open issues.
Table 1 categorizes common software evolution technologies based on when they can be applied and by whom. Software can either be evolved by a centralized authority, such as the software vendor (top row), or by a decentralized group, such as multiple independent software vendors (bottom row). Software can also be evolved during the design phase (left column), or after it has been deployed to customers (right column).
|Design-time evolution||Post-deployment evolution|
Design notations, methods, and tools; process systems; group communication and collaboration tools; configuration management tools
Release management systems; software patch files
Same as above with an emphasis on distributed development
Software plug-ins, scripting languages, developer APIs
Table 1: This 2x2 matrix
categorizes different techniques used to support software
based on who can evolve the system and when evolution can take place.
Centralized, design-time evolution:
The degree of flexibility afforded by different approaches to DSE is depicted in Figure 1.
Figure 1: The trade-off between flexibility (on the left) and application consistency (on the right) made by different decentralized software evolution mechanisms.
At the extreme left of the spectrum, the software vendor deploys the application's source code, enabling anyone with sufficient expertise to modify any aspect of the application's functionality. Although this is rare in the commercial software market, numerous free-ware applications adopt this approach, including the Linux OS, the Apache Web server, and the GNU tools (e.g., gcc, emacs). Netscape's Communicator is among the first commercial products to distribute source code for independent extension. Although the types of changes that can be made are unrestricted, it is extremely difficult to combine independently developed add-ons. This is because determining whether or not two changes conflict requires careful analysis of the source code and cannot be automated. The problem is analogous to merging several branches of a software revision tree in a software configuration management system.
At the extreme right of the spectrum, the software vendor deploys the application as a monolithic entity, with a fixed set of user-selection options. A large majority of commercial software applications adopt this approach because (1) application consistency may be assured since a single software vendor has exclusive control over its evolution, and (2) a software vendor can protect their intellectual property rights by making it extraordinarily difficult for others to reverse engineer the application.
Applications in between these two extremes support some form of software evolution by trading-off assured consistency (right-end) for flexibility (left-end). These systems enable end-users or third-party software vendors to customize or extend the application's functionality independent of the original application vendor. A relatively small but growing number of software applications lay between these two extremes. Some examples include Microsoft's Office Suite, Adobe Photoshop, and Qualcomm's Eudora. The most common techniques for supporting DSE are briefly described below.
All of the these techniques, except for source code, generally preserve only a small portion of the design's flexibility in the deployed system. Not only does this restrict the set of potential changes, but it precludes changes unanticipated by the original developers. Composition of software add-ons is also poorly supported by existing techniques. Most existing techniques circumvent the composition problem by preventing interaction between add-ons. This is indeed the approach advocated by Szyperski .
Our approach to decentralized, post-deployment software evolution overcomes many of the limitations exhibited by previous approaches. Our approach is based on evolving applications at the software architectural-level [15,16]. Our approach to DSE is unique in following ways:
We augment the abstractions provided at the architectural level with stylist rules that further facilitate DSE. We require all components to communicate through connectors, which are preserved as explicit entities in the implementation and act as communication routers. Furthermore, connectors encapsulate and localize the binding decisions between components, which makes it possible to change binding decisions without altering the components.
We include the application's architectural model and a mechanism to maintain the consistency between this model and the implementation with the deployed system. The deployed architectural model describes the interconnections between components and connectors, and their mappings to implementation modules. The mapping enables changes specified in terms of the architectural model to effect corresponding changes in the implementation.
We deploy an architecture evolution manager (AEM) with the application. The AEM maintains the correspondence between the architectural model and the implementation as changes are made. If a change violates application consistency, the AEM can reject the change.
Our approach enables software add-ons to leverage the architectural model's rich semantics to guide changes. This avoids many of the accidental difficulties incurred by existing approaches. Since the application's entire architecture is exposed and remains malleable in the deployed system, the design's plasticity is preserved and made accessibly to third-party add-on vendors. This overcomes the limited scope of change exhibited by existing approaches. Software add-ons can inspect and modify the system's architectural model in order to achieve the necessary semantics. This, for example, greatly simplifies the problem of interposing a new component between two existing components since the architectural model can be queried to locate the affected components and connectors. As independently developed software add-ons are installed and removed, the architectural model can be analyzed to detect inconsistencies. The availability of the architectural model can also be used to detect conflicts between independently developed add-ons.
We have implemented a prototype tool suite, called ArchStudio, that implements our approach for applications implemented in the C2 architectural style . ArchStudio's conceptual architecture is depicted and briefly described in Figure 2.
|Figure 2: A conceptual architecture of the ArchStudio tool suite. Software add-ons evolve an application by inspecting and changing its architectural model. Changes may include the addition, removal, or replacement of components and connectors, or changes to the configuration of those components and connectors. The Architecture Evolution Manager is notified of changes and has the opportunity to revoke changes that violate system integrity. The Architecture Evolution Manager may utilize external analysis tools to determine if changes are acceptable. The lower portion of ArchStudio is deployed with each application. When a user downloads a new software add-on using their Web browser, the add-ons installation script is located and executed.|
We have used ArchStudio to implement two applications with several add-ons each. More details regarding ArchStudio and a sample application implemented using it are described in .
We have implemented a simple end-user tool for installing and removing software add-ons, called the Extension Wizard, that is also deployed with the application. End-users use a Web browser to display a list of downloadable software add-ons, e.g., provided by the software vendor on their Web site. When the user selects the file representing the add-on, the Web browser downloads the file and invokes the Extension Wizard. The software add-on file is a compressed archive containing new implementation modules and an installation script. The Extension Wizard uncompresses the file, locates the installation script it contains, and executes it. The software add-on's installation script may query and modify the architectural model as necessary. The installation script an exception if the AEM detects a violation of application invariants. If the installation succeeds, the Extension Wizard notifies the end-user and provides an option to un-install the add-on.
Our results to date are encouraging, but several difficult issues remain. A general framework for ensuring application consistency is needed. Our current architecture evolution manager only enforces C2-style rules, which do not, by themselves, guarantee that changes will leave the application in a consistent state. Some aspects of the style do facilitate this type of in-the-field analysis. We are currently investigating the suitability of graph grammars, architectural constraints, and event-based resource models for representing application invariants. While these techniques hope to address software compositionality, new techniques are needed to address the problems of ``composing'' documentation and product support in a decentralized environment.