COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.

The desirability of maintaining multiple stakeholders' interests during the software design process argues for leaving choices undecided as long as possible. Yet, any form of underspecification, either missing information or undecided choices, must be resolved before automated analysis tools can be used. This paper demonstrates how constraint satisfaction problem solution techniques (CSTs) can be used to automatically reduce the space of choices for ambiguities by incorporating the local effects of constraints, ultimately with more global consequences. As constraints typical of those encountered during the software design process, we use UML consistency and well-formedness rules. It is somewhat surprising that CSTs are suitable for the software modeling domain since the constraints may relate many ambiguities during their evaluation, encountering a well-known problem with CSTs called the k-consistency problem. This paper demonstrates that our CST-based approach is computationally scalable and effective-as evidenced by empirical experiments based on dozens of industrial models

Software architecture descriptions can play a wide variety of roles in the software lifecycle, from requirements specification, to logical design, to implementation architectures. In addition, execution architectures can be used both to constrain and enhance the functionality of running systems, e.g. security architectures and debugging architectures. Along with others from DARPA's DASADA program we proposed an execution infrastructure for so-called self-healing, self-adaptive systems - systems that maintain a particular level of healthiness or quality of service (QoS). This externalized infrastructure does not entail any modification of the target system - whose health is to be maintained. It is driven by a reflective model of the target system's operation to determine what aspects can be changed to effect repair. We present that infrastructure along with an example implemented in accord with it.

Engineers wield various "calculi" to help determine solutions to their problems, calculation tools varying in power from tensile strength tables to the differential calculus. A calculus is normally based on induction over an algebraic structure. Here the author explores how architecture styles can be used to describe such structures. An example calculus based on an "integration" style is presented, which is intended for use as a substyle of other architecture styles. Calculation rules in terms of the architectural elements can be used to compute non-functional attributes of artifacts described in such styles. Naturally, computerized support for calculi will help to automate the tasks of software engineers.

Monitoring running systems is a useful technique available to requirements engineers, to ensure that systems meet their requirements and in some cases to ensure that they obey the assumptions under which they were created. This report studies relationships between the original requirements and the monitoring infrastructure. It postulates that the monitored requirements are in fact just compilations of original requirements, called residual requirements. Dynamic architectural models have become important tools for expressing requirements on modem distributed systems. Monitoring residual requirements will be seen to involve architectural residues, skeletal run-time images of the original logical architecture. An example sales support system is used to illustrate the issues involved, employing modest extensions to the Acme architecture description language to reason about architectural dynamism.

Software development is a constant endeavor to optimize qualities like performance and robustness while ensuring functional correctness. Architecture Description Languages (ADLs) form a foundation for modeling and analyzing functional and non-functional properties of software systems, but, short of programming, only the simulation of those models can ensure certain desired qualities and functionalities. The paper presents an adaptation to statechart simulation, as pioneered by D. Harel (1987). This extension supports architectural dynamism: the creation, replacement, and destruction of components. We distinguish between design-time dynamism, where system dynamics are statically proscribed (e.g., creation of a predefined component class in response to a trigger), and run-time dynamism, where the system is modified while it is running (e.g., replacement of a faulty component without shutting down the system). Our enhanced simulation language, with over 100 commands, is tool-supported.

No abstract available.

The language AML (Architecture Meta-Language) is used to specify the semantics of architecture description languages (ADLs). It is a very primitive language, having declarations for only three constructs: elements, kinds and relationships. Each of these constructs may be constrained via predicates in temporal logic. The essence of AML is the ability to specify structure and to constrain the dynamic evolution of that structure. Dynamic evolution concerns arise with considerable variations in the time scale. One may constrain how a system can evolve by monitoring its development lifecycle. Another approach to such concerns involves limiting the systems' construction primitives to those from appropriate styles. One may wish to constrain what implementations are appropriate; concerns for interface compatibility are then germane. Finally, one may want to constrain the ability of the architecture to be modified as it is running. AML attempts to provide specification constructs that can be used to express all of these constraints without committing to which time scale will be used to enforce them.

Modem Software Engineering practice advocates the development of domain-specific specification languages to characterize formally the idioms of discourse and jargon of specific problem domains.With poorly-understood domains it is best to construct an abstract syntax to characterize the domain concepts and abstractions before developing a concrete syntax.Often, however, a good concrete syntax exists a priori: sometimes in sophisticated formal languages characterizing (often mathematical) domains but more often in miniature, legacy-code languages, sorely in need of reverse engineering.In such cases, it is necessary to derive an appropriate abstract syntax -or its first cousin, an object-oriented model -from the concrete syntax.This report describes a transformation process that produces a good abstract representation from a low-level concrete syntax specification.

Current work on data structure encapsulation and abstraction focuses attention on individual structures and permits separate local optimizations, of these structures. We extend this work by developing the beginnings of an algebra for aggregating individual data types into larger more coordinated structures which can be more effectively optimized. The present work can well be viewed as the data equivalent of cross-procedural optimization. We believe aggregations of pure abstract types are both common and essential in practical programs and that techniques for building and manipulating them must be developed before abstract specification and program transformation can become a practical programming paradigm.

This paper is concerned with the need for computer-based tools which help human designers formulate formal process-oriented specifications. It first determines some attributes of a suitable process-oriented specification language, then examines the reasons why specifications would still be difficult to write in such a language in the absence of formulation tools. The key to overcoming these difficulties seems to be the careful introduction of informality based on partial, rather than complete, descriptions and the use of a computer-based tool that uses context extensively to complete these descnrptions during the process of constructing a well-formed specification. Some results obtained by a running prototype of such a computer-based tool on a few informal example specifications are presented and, finaliy, some of the techniques used by this prototype system are discussed.