-TR-007 iii List of Figures Figure 1-1 Steps of the Architecture-Based Development Process 2 Figure 2-1 Eliciting the Architectural Requirements 3 Figure 2-2 A Scenario-Elicitation Matrix 5 Figure 3-1 Architecture Design 9 Figure 4-1 Architecture Documentation 15 Figure 5-1 Architecture Analysis 19

middleware intended to support software architecture-based development of applications in the Prism setting. The middleware provides implementation-level support for the key aspects of Prism application architectures: components, connectors, architectural configurations, and communication events

an approach to reinforcing the productivity and reliability benefits provided by architectural patterns across the lifecycle. The approach is based on a catalog of precise pattern specifications, and is supported by runtime monitoring and architecture exploration tools. We describe the basic elements

directly leverages the principles and solutions from the emerging body of work on software architectures. We refer to software development in this setting as programming in the small and many (Prism), in order to distinguish it from the commonly adopted software engineering paradigm of programming

Components have increasingly become the unit of development of software. In industry, there has been considerable work in the development of standard component interoperability models, such as ActiveX, CORBA and JavaBeans. In academia, there has been intensive research in developing a notion

Software architecture has been widely advocated as an effective abstraction for modeling, implementing, and evolving complex software systems such as those in distributed, decentralized, heterogeneous, mobile, and pervasive environments. Typically, however, architectural abstractions have not been

Software architectures shift the focus of developers from lines-of-code to coarser-grained architectural elements and their overall interconnection structure. Architecture description languages (ADLs) have been proposed as modeling notations to support architecture-based development. There is

Continuous availability is a critical requirement for an important class of software systems. For these systems, runtime system evolution can mitigate the costs and risks associated with shutting down and restarting the system for an update. We present an architecture-based approach to runtime

A fleet of unmanned air vehicles undertakes a mission to disable an enemy airfield. Pre-mission intelligence indicates that the airfield is not defended, and mission planning proceeds accordingly. While the UAVs are en route to the target, new intelligence indicates that a mobile surface-to-air missile launcher now guards the airfield. The UAVs autonomously replan their mission, dividing into two groups—a SAM-suppression unit and an airfield-suppression unit—and proceed to accomplish their objectives. During the flight, specialized algorithms for detecting and recognizing SAM launchers automatically upload and are integrated into the SAM-suppression unit’s software. In this scenario, new software components are dynamically inserted into fielded, heterogeneous systems without requiring system restart, or indeed, any downtime. Mission replanning relies on analyses that include feedback from current performance. Furthermore, such replanning can take place autonomously, can involve multiple, distributed, cooperating planners, and where major changes are demanded and require human approval or guidance, can cooperate with mission analysts. Throughout, system integrity requires the assurance of consistency, correctness, and coordination of changes. Other applications for fleets of UAVs

The World Wide Web has succeeded in large part because its software architecture has been designed to meet the needs of an Internet-scale distributed hypermedia system. The Web has been iteratively developed over the past ten years through a series of modifications to the standards that define its