Mary Shaw

The architecture of a software system defines that system in terms of components and interactions, or connections, among those components. In addition to specifying the structure and topology of the system, the architecture shows the correspondence between the system requirements and elements of the constructed system. It addresses system-level properties such as capacity, throughput, consistency, and component compatibility. Architectural models clarify structural and semantic differences among components and their connectors. Architectural definitions can be composed to define larger systems. Elements are defined independently so they can be re-used in different contexts. The architecture establishes specifications for individual elements that may be written in a conventional programming language. A number of commonly-used patterns, or idioms, are in widespread informal use; these architectural styles can be captured as general templates for families of related systems expressed as constraints on the structure. This holds particular promise for domain-specific systems.

My current primary concerns are selecting, identifying, and supporting architectural abstractions; localizing and codifying the ways components interact; and distinguishing among the various packagings of components that require different forms of interaction. A major thrust of the research is identifying suitable abstractions for architectural styles and connectors, together with language to describe them. My focus is largely pragmatic. The first goal of the work has been to identify, classify, and support a variety of components and their connections. A prototype tool, called UniCon, now supports nine component types and nine connector types. We are now focusing on complete suites of elements for an application domain, with emphasis on interoperability and use of off-the-shelf elements.

Research questions of interest include:

• What abstractions are useful for structures, systems, and subsystems? How are the abstractions related to each other?
• How can we handle partial and incremental specifications? How can we make the benefit of a (partial) specification commensurate with the effort invested in creating it?
• How do you cope when you must build a system with parts that make incompatible assumptions about their mutual interaction?
• What kinds of checking and analysis can we support?
• How can we support good architectural design decisions, especially choices among architectural styles?

In addition to developing notations, models, and tools, we actively disseminate the results. The UniCon prototype is now available for trial use; information is available on the World Wide Web at http://www.cs.cmu.edu/~UniCon. We also develop and present educational materials on software architecture. This has to date resulted in a course, a tutorial presented at ICSE 93, SIGSOFT 93, SIGSOFT 94, and the 1996 CMU summer school, and a videotape for distribution.