A. van der Hoek, D. Heimbigner, and A.L. Wolf
Although meant to be relatively stable, the architecture of a software system does, at times, change. This simple yet important observation immediately raises the question of how changes to an architecture should be captured. Current architecture description languages are not well-suited for this purpose, but existing techniques from the discipline of configuration management can be adapted to provide a solution. In particular, we propose a novel representation, called configurable software architecture, that extends the traditional notion of software architecture with the concepts of variants, options, and evolution. We discuss the details of the representation, present an environment that allows the specification of configurable software architectures, and highlight a few of the opportunities that we believe arise once architectural configurability can be precisely captured.
Technical Report CU-CS-895-99, Department of Computer Science, University of Colorado, Decemeber 1999.
Retrieve publication as Postscript.
Judith A. Stafford and Alexander L. Wolf
COTS components are typically viewed as black-boxes; input and output information is supplied in their interfaces. In this paper we argue that interfaces provide insufficient information for many analysis purposes and suggest analysis-related annotations be supplied with components. We center our discussion on static dependence analysis. We use an extensible language to annotate components and perform dependence analysis over these descriptions. We propose that component annotations be certified, thereby providing a base for certifiable analysis.
Submitted for publication. Available as Department of Computer Science, University of Colorado at Boulder, Technical Report CU-CS-896-99, December 1999.
Retrieve publication as pdf.zip, pdf.gz, or ps.gz.
In this research abstract we introduce the Ménage project. Ménage is based on the vision that the notion of software architecture, extended with the concept of versioning, can be used as an organizing abstraction for some of the activities in the software life cycle. In particular, we are investigating how two of those activities, namely configuration management and software deployment, can benefit from the availability of an explicit architectural representation that is enhanced with versioning capabilities.
Proceedings of the ICSE99 Doctoral Workshop, Los Angeles, California, May 1999.
Retrieve publication as Postscript.
A. van der Hoek, D. Heimbigner, and A.L. Wolf
The discipline of software architecture has traditionally been concerned with high-level design. In particular, a variety of architecture description languages have been developed that are used to precisely capture a design. Additionally, analysis tools have been constructed that are used to verify particular properties of a design. However, today's trend towards the development of component-based software seems to suggest a new use of software architecture. Because an architecture captures components and the connections among them, it could potentially be used as an organizing abstraction for many of the activities in the software life cycle. In this paper we present an initial investigation into the feasibility of such use. In particular, we closely examine the role system modeling plays in the fields of configuration management and software deployment, and relate this role to the system modeling capabilities of architecture description languages. The outcome of this investigation is twofold. First, we conclude that, for the specific cases of configuration management and software deployment, the use of software architecture brings opportunities to significantly extend the provided functionality. Second, we present requirements for a number of extensions to typical architecture description languages that are needed to make our approach viable.
Technical Report CU-CS-862-98, Department of Computer Science, University of Colorado, November 1998.
Retrieve publication as Postscript.
J. Stafford and A.L. Wolf
There are many kinds of questions one might want to ask at an architectural level for maintenance purposes as varied as reuse, reverse engineering, fault localization, impact analysis, regression testing, and workspace management. These kinds of questions are similar to those currently asked at the implementation level and answered through static dependence analysis techniques applied to program code. It seems reasonable, therefore, to apply similar techniques at the architectural level, either because the program code may not exist at the time the question is being asked or because answering the question at the architectural level is more tractable than at the implementation level. Our research takes a broad view of dependence relationships that is appropriate to the concerns of architectures and their attention to component interactions. In particular, both the structural and the behavioral relationships among components expressed in current-day formal ADLs, such as Rapide and Wright, are considered. We are developing an architecture-level dependence analysis technique called chaining, and implementing the technique in a tool called Aladdin.
Proceedings of the 3rd International Software Architecture Workshop, Pages 129--132, Orlando, Florida, November 1998.
Retrieve publication as pdf, Postscript or Compressed Postscript.
A. van der Hoek, D. Heimbigner, and A.L. Wolf
In this position paper we introduce a novel use of software architecture. Rather than following the traditional focus on design, we propose to use the notion of versioned software architecture to support other activities in the software life cycle. In particular, we are investigating how the activities of configuration management and software deployment can benefit from the availability of an explicit architectural representation that is enhanced with versioning capabilities. Below, we present some of the initial results of this investigation. We motivate our research into versioned software architecture, present some usage scenarios in the context of configuration management and software deployment, and conclude with an outlook at the future work that remains to be done.
Proceedings of the 3rd International Software Architecture Workshop, Orlando, Florida, November 1998.
Retrieve publication as Postscript.
Proc. of the ASE'98 Doctoral Symposium, Honolulu, HI, Oct 1998.
Retrieve publication as pdf, ps, or ps.gz.
A. van der Hoek, D. Heimbigner, and A.L. Wolf
Over the past few years, research into system modeling has dwindled in favor of other interests in the field of configuration management. Outside influence, in the form of the emergence of the discipline of software architecture, demands that renewed attention is paid to system modeling because it places new requirements on, and offers new opportunities to, system modeling. In this paper we investigate these requirements and opportunities in more detail.
Proceedings of the 8th International Symposium on System Configuration Management, Brussels, Belgium, July 1998.
Retrieve publication as Postscript.
J.A. Stafford, A.L. Wolf, and D.J. Richardson
Software architecture description languages provide a means to formally describe software systems at a high level of abstraction. They capture the high-level structure and/or behavior of the system, thus providing a basis for course-grain static analyses. Dependence analysis has been used as a basis for program optimization, debugging, and testing. We are developing a dependence analysis technique, called chaining, for use with formal architectural descriptions, and implementing the technique in a tool called Aladdin.
Proc. International Workshop on the Role of Software Architecture in Testing and Analysis (ROSATEA), Marsala, Sicily, Italy, July 1998.
Retrieve publication as pdf, ps, or ps.gz.
J.A. Stafford, D.J. Richardson, and A.L. Wolf
The emergence of formal architecture description languages provides an opportunity to perform analyses at high levels of abstraction, as well as early in the development process. Previous research has primarily focused on developing techniques such as algebraic and transition-system analysis to detect component mismatches or global behavioral incorrectness. In this paper, we present Aladdin, a tool that implements {\em chaining}, a static dependence analysis technique for use with architectural descriptions. Dependence analysis has been used widely at the implementation level to aid program optimization, anomaly checking, program understanding, testing, and debugging. We investigate the definition and application of dependence analysis at the architectural level. We illustrate the utility of chaining, through the use of Aladdin, by showing how the technique can be used to answer various questions one might pose of a Rapide architecture specification.
Technical Report CU-CS-858-98, Department of Computer Science, University of Colorado, April 1998.
Retrieve publication as HTML, Postscript or Unix compressed postscript.
A. van der Hoek, D. Heimbigner, and A.L. Wolf
Software architecture, configuration management, and configurable distributed systems are three areas of research that until now have evolved separately. Contributions in each field have focused on their respective area of concern. However, as solutions in the three fields tend to center around some notion of a system model, it is worthwhile to investigate their relationship in detail. In particular, the large amount of overlap among the system models developed in each area, combined with the complementary nature of the differences among them, suggests that an approach based on a common system model is viable. In this paper, we illustrate the benefits of using such a unified system model, identify the commonalities and differences among the existing system models, and present some of our initial experiments that we believe will lead to the development of a single system model that is usable in all three fields.
Technical Report CU-CS-849-98, Department of Computer Science, University of Colorado, February 1998.
Retrieve publication as Postscript.
J.A. Stafford, D.J. Richardson, and A.L. Wolf
The emergence of formal architecture description languages provides an opportunity to perform analyses at high levels of abstraction. Research has primarily focused on developing techniques such as algebraic and transition-system analysis to detect component mismatches or global behavioral incorrectness. In this paper, we describe chaining, a technique similar in concept and application to program slicing, in which the goal is to reduce the portions of an architecture that must be examined by an architect for some purpose, such as testing or debugging. In chaining, links represent the dependence relationships that exist in an architectural specification. Links connect elements of the specification that are directly related, producing a chain of dependencies that can be followed during analysis. We illustrate the utility of chaining by showing how the technique can be used to answer various questions one might pose of a Rapide architecture specification.
Technical Report CU-CS-845-97, Department of Computer Science, University of Colorado, September 1997.
Retrieve publication as Postscript or as Unix compressed Postscript.
P. Inverardi, A.L. Wolf, and Daniel Yankelevich
A critical challenge faced by the developer of a software system is to understand whether the system's components correctly integrate. While type theory has provided substantial help in detecting and preventing errors in mismatched static properties, much work remains in the area of dynamics. In particular, components make assumptions about their behavioral interaction with other components, but currently we have only limited ways in which to state those assumptions and to analyze those assumptions for correctness.
We have begun to formulate a method that addresses this problem. The method operates at the architectural level so that behavioral integration errors, such as deadlock, can be revealed early in development. For each component, a specification is given both of its own interaction behavior and of the assumptions that it makes about the interaction behavior of the external context in which it expects to operate. We have defined an algorithm that, given such specifications for a set of components, performs ``adequacy'' checks between the component context assumptions and the component interaction behaviors. A configuration of a system is possible if and only if a successful way of ``matching'' actual behaviors with assumptions can be found. In effect, we are extending the usual notion of type checking to include the checking of behavioral compatibility.
Second International Conference on Coordination Models and Languages (COORD '97), Lecture Notes in Computer Science 1282, Springer, Berlin, 1997, pages 46-63.
Retrieve publication as Postscript or as Unix compressed Postscript.
D. Compare, P. Inverardi, and A.L. Wolf
When constructing software systems from existing components, the engineer is faced with the problem of potential conflicts in the interactions among the components. Of particular difficulty is guaranteeing compatibility in the dynamic interaction behavior. Using an architectural description of the system and its intended components, the engineer can reason about the interactions early and at a high level of abstraction. In this paper we give a case study of the Compressing Proxy system, which was first investigated by Garlan, Kindred, and Wing. We present architectural specifications and analyses of two versions of the system. One version is a seemingly obvious melding of the components. The other is a solution to deadlock problems uncovered by formal analyses of the first version. We use the Chemical Abstract Machine as an example of an architectural description formalism that can help uncover architectural mismatches in the behavior of components.
Technical Report CU-CS-828-97, Department of Computer Science, University of Colorado, February 1997.
Retrieve publication as Postscript or as Unix compressed Postscript.
This paper argues that with the advent of explicitly specified software architectures, testing can be done effectively at the architectural level. A software architecture specification provides a solid foundation for developing a plan for testing at this level. We propose several architecture-based test criteria based on the Chemical Abstract Machine model of software architecture. An architectural (integration) test plan, developed by applying selected of these criteria, can be used to assess the architecture itself or to test the implementation's conformance with the architecture. This facilitates detecting defects earlier in the software lifecycle, enables leveraging software testing costs across multiple systems developed from the same architecture, and also leverages the effort put into developing a software architecture.
Second International Software Architecture Workshop (ISAW-2), San Francisco, California, October 1996, pages 68-71.
Retrieve publication as Postscript or as Unix compressed Postscript.
P. Inverardi and A.L. Wolf
We are exploring an approach to formally specifying and analyzing software architectures that is based on viewing software systems as chemicals whose reactions are controlled by explicitly stated rules. This powerful metaphor was devised in the domain of theoretical computer science by Banatre and Le Metayer and then reformulated as the Chemical Abstract Machine, or CHAM, by Berry and Boudol. The CHAM formalism provides a framework for developing operational specifications that does not bias the described system toward any particular computational model and that encourages the construction and use of modular specifications at different levels of detail. We illustrate the use of the CHAM for architectural description and analysis by applying it to two different architectures for a simple, but familiar, software system, the multiphase compiler.
IEEE Transactions on Software Engineering, vol. 21, no. 4, April 1995, pages 373-386.
Retrieve publication as Postscript or as Unix compressed Postscript.
D.E. Perry and A.L. Wolf
The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architecture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements---that is, the constraints on the elements. The rationale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system requirements. We discuss the components of the model in the context of both architectures and architectural styles and present an extended example to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, summarizing our contributions, and relating our approach to other current work.
ACM SIGSOFT Software Engineering Notes, vol. 17, no. 4, October 1992, pages 40-52.
Retrieve publication as Postscript or as Unix compressed Postscript.
©1998 Software Engineering Research Laboratory (SERL)