Higher Order Connectors

A critical issue for architectural design is the nature of the glue, or connectors, with which a system's parts are combined. Thus an important first step toward improving our ability to compose parts is to make to make connectors explicit semantic enties, where they can be documented, analyzed, and (sometimes) used to generate code. A number of notations for software architecture do precisely this. However, a key second step is to understand operations over connectors. In principle, such operations would permit one to produce new connectors out of old ones, adapt existing connectors to new contexts of use, and factor out common properties of connectors so they can be reused. In this paper we argue that the use of "higher order connectors" is one way to achieve this goal

Evolution Styles - Formal foundations and tool support for software architecture evolution

Architecture evolution is a central feature of virtually all software systems. As new market opportuni-ties, technologies, platforms, and frameworks become available systems must change their organiza-tional structures to accommodate them, requiring large-scale and systematic restructuring. Today arc-hitects have few tools to help them plan and execute such evolutionary paths. In particular, they have almost no assistance in reasoning about questions such as: How should we stage the evolution to achieve business goals in the presence of limited development resources? How can we reduce risk in incorporating new technologies and infrastructure required by the target architecture? How can we make principled tradeoffs between time and development effort? What kinds of changes can be made independently, and which require coordinated system-wide modifications? How can an evolution plan be represented and communicated within an organization? In this report we outline first steps towards a formal basis for assisting architects in developing and reasoning about architectural evolution paths. The key insight behind the approach is that at an architectural level of abstraction many system evolu-tions follow certain common patterns – or evolution styles. By taking advantage of regularity in the space of common architectural evolutions, and by making the notion of evolutions styles a first-class entity that can be formally defined, we can provide automated assistance for expressing architecture evolution, and for reasoning about both the correctness and quality of evolution paths

Flexible unparsing in a structure editing environment

Computer Science Departmen

The Role of Software Architecture in Requirements Engineering

Problem Space versus Solution Space Requirements engineering is concerned fundamen tally with the shape of the problem space. Its primary goal is to determine the dimensions of the problem that the software system is to solve. In contrast, software architecture is concerned with the shape of the solution space. Its primary goal is to determine the structure of a solution to a problem posed by a set of requirements. Thus, understanding the role of software architecture in requirements engineering is largely a matter of understanding the dynamic relationship between identification of a problem to be solved and a description of its solution

What is Style?

A central aspect of architectural design is the use of recurring organizational patterns and idioms- or architectural styles. Examples include generic system organizations such as those based on dataflow or layers, as well as specific organizational structures such as the classical decomposition of a compiler, the OSI communication stack, and the MVC user interface paradigm. The principled use of architectural styles has a number of practical benefits. First, it promotes design reuse: routine solutions with well-understood properties can be reapplied to new problems with confidence. Second, it can lead to significant code reuse: often the invariant aspects of an architectural style lend themselves to shared implementations. Third, it is easier for others to understand a system's organization if conventionalized structures are used. For example, even without giving details, characterization of a system as a "client-server" organization immediately conveys a strong image of the kinds of pieces and how they fit together. Fourth,use of standardized styles supports interoperability. Examples include CORBA object-oriented architecture, and event-based tool integration. Fifth, by constraining the design space, an architectural style often permits specialized,style-specific analyses. For example, it is possible to analyze pipe-filter systems for schedulability, throughput, latency, and deadlock-freedom. Such analyses might not be meaningful for an arbitrary, ad hoc architecture - or even one constructed in a different style. Sixth, it is usually possible to provide style-specific visualizations: this makes it possible to provide graphical and textual renderings that match engineers' domain-specific intuitions about how their designs should be depicted

Formalizing design spaces: Implicit invocation mechanisms

An important goal of software engineering is to exploit commonalities in system design in order to reduce the complexity of building new systems, support large-scale reuse, and provide automated assistance for system development. A significant roadblock to accomplishing this goal is that common properties of systems are poorly understood. In this paper we argue that formal specification can help solve this problem. A formal definition of a design framework can identify the common properties of a family of systems and make clear the dimensions of specialization. New designs can then be built out of old ones in a principled way, at reduced cost to designers and implementors. To illustrate these points, we present a formalization of a system integration technique called implicit invocation. We show how many previously unrelated systems can be viewed as instances of the same underlying framework. Then we briefly indicate how the formalization allows us to reason about certain properties of those systems as well as the relationships between different systems

A Case Study in Software Architecture Interchange

An important issue for the specification and design of software architectures is how to combine the analysis capabilities of multiple architectural definition languages (ADLs) and their supporting toolsets. In this paper, we describe our experience of integrating three ADLs: Wright, Rapide, and Aesop. We discovered that it is possible to achieve interoperability in ADL tools for a non-trivial subset of the systems describable by these languages, even though the languages have different views about architectural structure and semantics. To carry out the integration we used the Acme architectural interchange language and its supporting tools

Software Development Assignments for a Software Architecture Course

As software systems grow in size and complexity their design problem extends beyond algorithms and data structures to issues of system design. These issues|the software architecture level of software design|are becoming increasingly important to the practicing software engineer. Consequently, it is important to nd eective ways to teach this material. To meet this need we developed a course, \Architectures for Software Systems," and have taught it four times. In this paper we describe the principal software development assignments that this course uses to develop skill at applying architectural principles to the design and implementation of software systems. The major challenges in designing such assignments are (1) making sure that students spend their time on architectural issues rather than coding, and (2) helping students establish and maintain a desired architectural style. We address these issues by providing working examples as starting points. These examples are usable in other courses

Architecture-Based Performance Analysis

A software architecture should expose important system properties for consideration and analysis. Performancerelated properties are frequently of interest in determining the acceptability of a given software design. In this paper we show how queueing network modeling can be adapted to support performance analysis of software architectures. We also describe a tool for transforming a software architecture in a particular style into a queueing network and analyzing its performance

Formal Modeling and Analysis of the HLA RTI

The HLA RTI is a complex artifact, supporting several classes of interaction (e.g., federation management, object management, time management). A critical challenge in producing an RTI architectural framework (and its associated simulation interface specifications) is to develop confidence that its specification is well-formed and complete. In this paper we describe on-going work in formally modelling the HLA both to document the standard more precisely, as well as to analyze it for anomalies, omissions, inconsistencies, and ambiguities. The technical basis for this work is the use of a formal architectural description language, called Wright, and its accompanying toolset