A formal basis for architectural connection

TLDR: The key idea is to define architectural connectors as explicit semantic entities as a collection of protocols that characterize each of the participant roles in an interaction and how these roles interact.

Abstract: As software systems become more complex, the overall system structure—or software architecture—becomes a central design problem. An important step toward an engineering discipline of software is a formal basis for describing and analyzing these designs. In the article we present a formal approach to one aspect of architectural design: the interactions among 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.

Figures

Figure 2: An Architectural Description.

Figure 3: A Simple Client-Server System

Figure 7: A Pipe Connector Augmented with a Trace Speci cation

Figure 4: Several Shared Data Connectors

Figure 1: An Implementation Description.

Figure 5: A Pipe Connector

Full text

AFormal Basis for Architectural Connection
Robert Allen David Garlan
January 1997
School of Computer Science
Carnegie Mellon University
Pittsburgh, PA 15213
This researchwas sp onsored by the National Science Foundation under Grant Number CCR-9357792, by the
Wright Laboratory, Aeronautical Systems Center, Air Force Materiel Command, USAF, and the Advanced Research
Pro jects Agency (ARPA) under grantnumber F33615-93-1-1330, and by Siemens Corporate Research. The views
and conclusions contained in this do cument are those of the authors and should not be interpreted as representing
the ocial policies, either expressed or implied, of Wright Lab oratory, the U.S. Government, or Siemens Corporation.
The U.S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding
any copyright notation thereon.

Keywords:
software architecture, formal models, mo del checking, module interconnection,
software analysis.

Abstract
As software systems b ecome more complex the overall system structure|or software architecture|
becomes a central design problem. An imp ortant step towards an engineering discipli ne of software
is a formal basis for describing and analyzing these designs. In this paper we present a formal
approach to one aspect of architectural design: the interactions between components. The key idea
is to dene architectural connectors as explicit semantic entities. These are specied as a collection
of proto cols that characterize each of the participant roles in an interaction and how these roles
interact. We illustrate how this scheme can be used to dene a variety of common architectural
connectors. We further provide a formal semantics and showhow this leads to a system in which
architectural compatibility can be checked in a way analogous to type checking in programming
languages.

1 Intro duction
For complex software systems the overall system structure|or software architecture|emerges as
a critical design problem. Design issues at this level include gross organization and control struc-
ture, assignment of functionality to computational units, and high-level interactions between these
units [SG96].
The importance of software architecture for practicing software engineers is highlighted by the
ubiquitous use of architectural descriptions in system do cumentation. Most software systems con-
tain a description of the system in terms such as \client-server organization," \layered system,"
\blackboard architecture," etc. These descriptions are typically expressed informally and accom-
panied bybox-and-line drawings indicating the global organization of computational entities and
the interactions between them.
While these descriptions may provide useful documentation, the current level of informality
limits their usefulness. It is generally not clear precisely what is meantby such architectural
descriptions. Hence it may be impossible to analyze an architecture for consistency or determine
non-trivial properties of it. Moreover, there is no waytocheck that a system implementation is
faithful to its architectural design.
Evidently, what is needed is a more rigorous basis for describing software architectures. At
the very least we should be able to say precisely what is the intended meaning of a box-and-
line description of some system. More ambitiously,we should b e able to check that the overall
description is consistent in the sense that the parts t together appropriately. More ambitiously
still, wewould like a complete theory of architectural description that allows us to reason about
the behavior of the system as a whole.
In this paper we describ e a step towards these goals by providing a formal basis for sp ecifying
the interactions b etween architectural components. The essence of our approachis toprovide a
notation and underlying theory that gives architectural connection explicit semantic status. Specif-
ically,we describe a formal system for sp ecifying architectural
connector types
. The description
of these connector types is based on the idea of characterizing the proto cols of interaction b e-
tween architectural components. The formal underpinnings for proto col denition are provided by
CSP [Hoa85].
Of course the use of proto cols as a mechanism for describing interactions b etween parts of a sys-
tem is not new. However, as we will show, there are three imp ortant innovations in our application
of this general idea to architectural description. First, we showhow the ideas that have tradition-
ally b een used to characterize message communication over a network can be applied to description
of software interactions. This allows us to apply existing theory and analytical techniques to a new
practical domain. Second, unliketypical applications of protocols we distinguish connector types
from connector instances. This allows us to dene and analyze architectural connectors indep en-
dent of their actual use, and then later \instantiate" them to describ e a particular system, thereby
supporting reuse. Third, we showhow a connector sp ecication can be decomposed into parts that
simplify its description and analysis. This allows us to lo calize and automate the reasoning about
whether a connector instance is used in a consistent manner in a given system description.
We b egin by motivating the need for a theory of architectural connection by examining the
1

limitations of traditional module interconnection languages. We then describe our general mo del
for architectural description and briey characterize the hard problems in developing a theory
of architectural connection to support that model. Next we outline our notation and illustrate
through examples how it solves these problems. Having motivated the approach, we provide a
formal semantics and showhow this leads to a system in which architectural compatibility can b e
checked in a way analogous to type checking in programming languages. Finally,we discuss the key
design decisions on which this work is based, compare the work to other approaches to architectural
description, and outline future directions for research in this area.
2 The Need for a Theory of Architectural Connection
Large software systems require decomp ositional mechanisms in order to make them tractable. By
breaking a system into pieces it b ecomes p ossible to reason about overall prop erties by understand-
ing the prop erties of each of the parts. Traditionally, Module Interconnection Languages (MILs)
and Interface Denition Languages (IDLs) have played this role by providing notations for describ-
ing (a) computational units with well-dened interfaces, and (b) compositional mechanisms for
gluing the pieces together.
Akey issue in design of a MIL/IDL is the nature of that glue. Currently the predominant form
of composition is based on denition/use bindings [PDN86]. In this mo del each module
denes
or
provides
a set of facilities that are available to other mo dules, and
uses
or
requires
facilities
provided by other modules. The purpose of the glue is to resolve the denition/use relationships
by indicating for each use of a facility where its corresp onding denition is provided.
This scheme has many benets. It maps well to current programming languages, since the
kinds of facilities that are used or dened can be chosen to b e precisely those of an underlying
programming language. (Typically these facilities support pro cedure call and data sharing.) It is
goo d for the compiler, since name resolution is an integral part of producing an executable system.
It supports both automated checks (
e.g.
,type checking) and formal reasoning (
e.g.
, in terms of pre-
and post-conditions). And, it is in widespread use.
Given all this, one mightwell ask whyanything more is needed. Indeed, the b enets of describing
a system in terms of denition/use relationships are so transparent that few people question the
basic tenets of the approach.
However, the problem with this traditional approach is that, while it is good for describing
implementation
relationships between parts of a system, it not well-suited to describing the
in-
teraction
relationships that are a central concern of architectural descriptions. Sp ecically, the
distinction b etween a description of a system based on \implements" relationships and one based
on \interacts" relationships is imp ortant for three reasons.
First, the two kinds of relationship have dierent requirements for abstraction. In the case
of implementation relationships it is usually sucient to adopt the primitives of an underlying
programming language {
e.g.
, pro cedure call and data sharing. In contrast, as noted earlier,
interaction relationships at an architectural level of design often involve abstractions not directly
provided by programming languages: pip es, event broadcast, client-server protocols, etc. Whereas
the implementation relationship is concerned with how a comp onentachieves its computation, the
2

Frequently asked questions

Q1. What are the contributions in "A formal basis for architectural connection" ?

In this paper the authors present a formal approach to one aspect of architectural design: the interactions between components. The authors 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. The authors illustrate how this scheme can be used to de ne a variety of common architectural connectors. 

Q2. What is the goal of checking for well-formedness?

The goal of checking for well-formedness is analogous to the use of type checking to guarantee that all uses of procedures are consistent with their de nitions. 

Q3. Why does CSP use global event names?

Because CSP uses global event names (i.e., the k operator uses exact, unstructured name matching), there must be an additional level of structuring to ensure that the descriptions are not falsely combined because of name clashes, and that system parts are not prevented from being combined by not having selected the same name for the same construct. 

Q4. How do the authors determine whether a connector is deadlock-free?

Since a connector is instantiated by substituting speci c ports for the connector roles, the authors would also like to be able to tell whether the result remains deadlock-free after having performed that substitution. 

Q5. What is the key aspect of determining whether parts t together compatibly?

In terms of architectural design, a key aspect of determining whether parts t together compatibly is detecting whether the parts can get stuck during their interactions. 

Q6. What is the motivation for allowing ports to di er from the roles they ll?

An important motivation for allowing ports to di er from the roles they ll is that this scheme permits greater opportunities for reuse of connectors. 

Q7. What is the purpose of the adaptors?

These adaptors have some of the avor of their connectors, but are less general, since purpose is to increase the exibility of object composition|not to provide a separable and explicit de nition of an interaction. 

Q8. What is the goal of independent speci cation of connector types?

The goal of independent speci cation of connector types is analogous to the use of abstract type de nitions in programming languages. 

Q9. Why do developers use the import/export facilities of these languages?

On the other hand, because until recently software developers have had only traditional module notations to describe their systems, they have used the import/export facilities of these languages to de ne architectural structure as well.