Toward a Discipline of Scenario-Based Architectural Engineering

Abstract

Software architecture analysis is a cost-effective means of controlling risk and maintaining system quality throughout the processes of software design, development and maintenance. This paper presents a sequence of steps that maps architectural quality goals into scenarios that measure the goals, mechanisms that realize the scenarios and analytic models that measure the results. This mapping ensures that design decisions and their rationale are documented in such a fashion that they can be systematically explored, varied, and potentially traded off against each other. As systems evolve, the analytic models can be used to assess the impact of architectural changes, relative to the system's changing quality goals. Although scenarios have been extensively used in software design to understand the ways in which a system meets its operational requirements, there has been little systematic use of scenarios to support analysis, particularly analysis of a software architecture's quality attributes: modifiability, portability, extensibility, security, availability, and so forth. In this paper we present a unified approach to using scenarios to support both the design, analysis and maintenance of software architectures, and examples from large-scale software development projects where we have applied the approach. We also present a tool, called Brie, that aids in: scenario capture, mapping scenarios to software architectures, and the association of analytic models with particular portions of architectures. The approach that we have devised, and that Brie supports, is a foundation for a discipline of architectural engineering. Architectural engineering is an iterative method of design, analysis and maintenance where design decisions are motivated by scenarios, and are supported by documented analyses.

Adaptive development and maintenance of user-centric software systems

“…Users and designers participate actively in the development process. Scenarios are brief descriptions of a single interaction of a stakeholder with a system -this includes classical use cases, but also maintenance and change activities [11]. Interactive software systems are characterised by dialogues between the user and the system that represent complex processes.…”

“…[11] define a scenario as a brief description of a single interaction of a stakeholder with a system. A more precise definition is given by Alspaugh et.al.…”

“…Scenarios can reflect activities of all stakeholders, including change-related and other maintenance activities in relation to the software system and its specifications. We can distinguish usage scenarios (or simply scenarios) and meta scenarios -called direct and indirect scenarios elsewhere [11]. Meta scenarios provide guidance for the maintenance process; they usually include actions such as evaluation, evolution observation, and analysis activities.…”

“…Infrastructure services that are required predetermine some aspects of the architecture: scheduling and coordination of system activities, how data moves through the system, security, fault propagation, integration of new components, how the system scales, etc. [11].…”

“…These mechanisms determine the internal structure and behaviour of the prototype within the constraints set by the scenario definition. The mechanisms need to be inherently linked to architectural mechanisms and properties, such as architectural styles [11].…”