ISI is an off-campus research center in the University of Southern California's School of Engineering. The Institute engages in a broad set of research and application oriented projects in the computer sciences, ranging from advanced research efforts aimed at producing new concepts to operation of a major Arpanet computer facility.

We outline our approach to developing, a distributed capability to achieve shared situation awareness of mission status and trust relationships, anticipate and diagnose cyber threats, and respond strategically and tactically to those threats.

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.

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.

Over the years, our group, led by Bob Balzer, designed and implemented three domain-specific languages for use in real applications. Each was invented to "showcase" DSL language design and implementation technology that was the focus of our then-current research. Each of these was actually a prototype for what would have taken more time to engineer and polish before putting into practice. Although each effort was essentially successful, none of the languages was ever followed up with the subsequent engineering efforts that we expected or at least hoped for. Herein I elaborate where these language efforts succeeded and where they failed, gleaning lessons for others who take the somewhat risky step of committing to develop a DSL for a particular user community.

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.

Although each application of self-management techniques encounters problems and solutions unique to the application domain, there are several cross-cutting "patterns of self-management" that can be discerned. Much like programming patterns, these patterns can occur in a variety of different guises, but having a fundamental set of such patterns can be useful for designers beginning to design a self-managed system or to those adapting a system not previously capable of managing itself. Herein I sketch some of these patterns using an "architectural style" designed to express common element types used for self-management, such as probes, gauges, and "effectors."

An underlying assumption in even using the phrase "component certification and system prediction" is that an understanding of individual components' properties will lead to an understanding of a system's properties by some form of compositional reasoning. Unfortunately, standard analytical composition techniques suffer from two problems: (1) they require that the internal structure of components be revealed in order to reason about them and (2) they deal clumsily with properties that require analysis of patterns of interaction. Here, based on the observation that a formal software architecture description itself is a constructive composition mechanism, I illustrate how the use of software architecture styles can sometimes alleviate the first problem and solve the latter.

A successful technique in modern Software Engineering practice is to develop 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, legacycode 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. The relationships between concrete syntax and abstract syntax are quite regular; this is not to say that they are trivial. Herein, those relationships are explored and a transformation process is described that software engineers can use to produce a good abstract syntax specification (e.g. in C++) from a low-level concrete syntax specification (e.g. in YACC). Some details of how the heuristic process has been automated in the author's language processing system, Popart, are presented to introduce software engineers to the practical usage of automatic program generation concepts. Examples from the concrete syntax for CORBA’s IDL are used to illustrate the process. Index Terms Abstract syntax, concrete syntax, domain-specific languages, program transformation, grammars, object-oriented models, reverse engineering, program generation. PROBLEM DOMAIN LANGUAGES AND MODELS + In recent years, programming language design and implementation technology have taken on a role of newfound relevance to software engineering practice. The development of Fourth Generation Languages and, more generally, domain-specific specification languages to characterize formally the idioms of discourse and jargon of specific problem domains, has lead to productivity increases of as much as two orders of magnitude [1, 2, 5, 8]. The emerging interest in languages by such practical people as the USENIX group indicates that language manipulation techniques are indeed evolving into tools for a broader class of software engineering problems. Many modern tools have been developed for language processing to aid the software engineer in analyzing, simulating, measuring and synthesizing programs. These in turn are implemented using attribute grammars, recursive descent techniques, abstract interpretation, partial evaluation, etc. These tools rely on an abstract syntax representation of the domain-specific language, a representation that just captures the fundamental underlying concepts in the + Sponsored by the Advanced Research Projects Agency under contract no. F30602-93-C-0240. 1 USENIX Conference on Domain-Specific Languages, to be held in Santa Barbara, CA, October 15-17, 1997. Final paper will reference the proceedings. language, stripped of its “syntactic sugar.” Such an abstract representation is the goal for producers of object-oriented models as well [3], and the two are invariably closely related [7]. Syntax-directed systems like the Cornell Synthesizer Generator [11], Mentor [6], and Gandalf [9] advocate designing the abstract syntax together with the concrete syntax; the Booch method also advocates finding the key abstractions of a domain early in the process. However, there are common situations where a language already exists in concrete form, but an abstract syntax has not yet been designed for it. In order to use modern language processing tools on such a language it is desirable to convert the existing concrete syntax into an appropriate abstract syntax. One situation where such conversion in necessary is when a problem domain already has a significant amount of formalism ingrained, and all that is desired is to characterize the existing intuitive concepts in an abstract way. Reverse engineering is another arena in which adapting existing concrete syntax is desirable. Many “dusty decks” have unfathomable YACC code characterizing corporation jargon and everyday practice. If these are to be adapted, for example, to modern object-oriented techniques, some way to convert the concrete syntax into an abstract syntax is needed, e.g., into a set of C++ class declarations. Present-day technologies in actual use in software engineering practice for developing concrete syntax and mapping it into an abstract syntax are rather primitive. YACC appears to be the tool of choice for specifying concrete TRANSFORMING CONCRETE SYNTAX INTO ABSTRACT SYNTAX syntax with an accompanying program to map it into abstract syntax. (Actually, there is little discipline here programmers can do all kinds of semantic manipulations during the parse, perhaps circumventing the invention of an abstract syntax altogether!) Hence, the technique presented in this report can be used as a step in the disciplined development of support tools for language manipulation. The process of converting from concrete to abstract actually is quite straightforward. One can argue that much of the technique presented below actually represents a way to improve existing abstract syntaxes. Hence, as a side-benefit, this paper can be used to examine existing abstract models for clumsiness of expression. The process is described in enough detail that software engineers can apply the process manually and produce good results. The process is indeed heuristic. However, with a little “advice” from the software engineer, a fully automatic version of the process can be implemented to convert concrete syntax into a tasteful abstract syntax design. Indications of how this was done in the author's language processing system, Popart, are presented below. Examples from the concrete syntax for CORBA’s IDL [10] are used to illustrate the process. RELATIONSHIPS BETWEEN ABSTRACT AND

: The Acme project began with the goal of providing a common language that could be used to support the interchange of architectural descriptions between a variety of design tools. It remains useful in that role, but since the project's inception the Acme language and its support toolkit have grown into a solid foundation upon which new software architecture design and analysis tools can be built without the need to rebuild standard infrastructure. The Acme Language and the Acme Tool Developer's Library (AcmeLib) provide a generic, extensible infrastructure for describing, representing, generating, and analyzing software architecture descriptions. They provide three fundamental capabilities: (1) a generic interchange format for architectural designs, allowing architectural tool developers to readily integrate their tools with other complementary tools; (2) an extensible foundation and infrastructure, allowing tool builders to avoid needlessly rebuilding standard tooling infrastructure for describing, storing, and manipulating architectural designs; and (3) a useful architecture description language in its own right, providing a straightforward set of language constructs for describing architectural structure, architectural types and styles, and annotated properties of the architectural elements. (22 refs.)

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.

Self-healing systems generally require reflective models of their own operation to determine what aspects of themselves they can change to effect repair. Architecture models are examples of rather simple models to which health information can be attached and reasoned about, e.g. attaching system state to a process or tracking events across connectors. These models are especially useful when the architecture of the system varies while the system is running, in so-called "dynamic architectures."DARPA's DASADA program is developing an architecture-based infrastructure for self-healing, self-adapting systems. Herein several protocols for dynamic architecture change notification from that program are examined in search of a community standard for such a protocol. Desirable properties of such protocols are suggested based in part on how much constraint checking will be used to proscribe dynamic architecture building activity. Points for discussion are raised.

Abstract: 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. Here we postulate 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 modern 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.

The language AML was designed to specify the semantics of architecture description languages, ADLs, especially ADLs describing architectures wherein the architecture itself evolves over time. Dynamic evolution concerns arise with considerable variation in time scale. One may constrain how a system may evolve by monitoring its development lifecycle. Another approach to such concerns involves limiting systems' construction primitives to those from appropriate styles. One may wish to constrain what implementations are appropriate; concerns for interface compatibility are then germane. And finally, one may want to constrain the ability of the architecture to be modified as it is running. AML attempts to circumscribe architectures in such a way that one may express all of these constraints without committing to which time scale will be used to enforce them. Example AML specifications of the C2 style and Acme are presented.