Abstract: As the design of software architectures emerges as a discipline within software engineering, it will become increasingly important to support architectural description and analysis with tools and environments. In this paper we describe a system for developing architectural design environments that exploit architectural styles to guide software architects in producing specific systems. The primary contributions of this research are:

- A generic object model for representing architectural designs;
- The characterization of architectural styles as speculations of this object model;
- A toolkit for creating an open architectural design environment from a description of a specific architectural style.

We use our experience in implementing these concepts to illustrate how style-oriened architectural design raises new challenges for software support environments.

Abstract: Large software systems require decompositional mechanisms in order to make them tractable. Traditionally, MILs and IDLs have played this role by providing notations based on definition/use bindings. In this paper we argue that current MIL/IDLs based on definition/use have some serious drawbacks. A significant problem is that they fail to distinguish between 'implementation' and 'interaction' relationships between modules. We propose an alternative model in which components interact along well-defined lines of communication - or connectors. Connectors are defined as protocols that capture the expected patterns of communication between modules. We show how this leads to a scheme that is much more expressive for architectural relationships, that allows the formal definition of module interaction, and that supports its own form of automated checks and formal reasoning.

Abstract: A critical issue in the design of a professional software engineering degree program is the way in which formal methods are integrated into the curriculum. The approach taken by most programs is to teach formal techniques for software development in a separate course on formal methods. In this paper we detail some of the problems with that approach and describe an alternative in which formal methods are integrated across the curriculum. We illustrate the strengths and weaknesses of this alternative in terms of our experience of using it in the Master of Software Engineering Program at Carnegie Mellon University.

Abstract: 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.

Abstract: 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.

Abstract: Whatever the long-term impact of software architecture may turn out to be, an appropriate starting point is a concrete appraisal of the current state of the practice in the use of software architecture. It is the purpose of this panel to take a step in this direction. By assembling a panel of experts with a broad base of experience in the area, we hope to provide concrete examples of what is now possible when architectural principles are applied to industrial problems in systematic ways, to consider the potential impact of software architecture over the next few years, and to suggest steps that should be taken to bring this about.

Abstract: As software systems become more complex the overall system structure -- or software architecture -- becomes a central design problem. An important step towards an engineering discipline of software is a formal basis for describing and analyzing these designs. In this paper we present a theory for one aspect of architectural description: the interactions between components. The key idea is to define architectural connectors as explicit semantic entities. These are specified as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact. We illustrate how this scheme can be used to define a variety of common architectural connectors. We further provide a formal semantics and show how this leads to a system in which architectural compatibility can be checked in a way analogous to type checking in programming languages.