Software

Dilip

Architecture
Soni, Robert

L. Nerd,

{ dsoni, rnord,

Applications

and Christine

chofmeister}

Siemens
755 College

in Industrial

Corporate

Hofmeister

@scr.siemens.com
Research

Road East, Princeton,

Inc.
NJ 08540

In order to examine the pragmatic

Abstract

related to the role of architecture

To help us identify

and focus on pragmatic

and concrete

and concrete issues

in the design and devel-

opment of large systems, we conducted a survey of a variety of industrial

software
systems
to understand

issues related to the role of software architecture in large

systems, we conducted a survey of a variety of software
systems used in industrial applications. Our premise, which
guided the examination of these systems, was that software
architecture is concerned with capturing the structures of a
system and the relationships
among the elements both

architecture as it is practiced in the real world. The systems we surveyed included several image and signal prooperating
system,
real-time
cessing
systems,
a
communication
systems, and instrumentation
and control
systems [9, 13, 17]. These systems are listed in Table 1.

within and between structures. The structures we found fell

Our premise, which guided the examination

into

tems, was that software

several

broad

categories:

conceptual

architecture,

module interconnection

architecture,

code architecture,

and

execution architecture.
engineering concerns.

These categories address different

The separation of such concerns,

capturing

architecture

with

the structures of a system and the relationships

among the elements both within

Following

of these sys-

is concerned

and between structures.

this premise, we interviewed

system architects

combined with specialized

implementation
techniques,
decreased the complexity of implementation, and improved
reuse and reconfiguration.

and designers, and examined design documents and code

to look for important system structures and their use.
Details of the survey process are described in Appendix A.

1.

tion between architecture

We observed that most of the systems made a distinc-

Introduction

and architecture
Software architectures

describe how a system is decom-

platform

for the product-specific

for the platform

software provided

a virtual

posed into components, how these components are interconnected, and how they communicate and interact with

structure for the product-specific

each other.

ware, different

When

poorly

understood,

For both the application

these aspects of

design are major sources of errors.

software

software. Intuitively,

the

machine or an infra-

software.

software and the platform

structures were used at different

soft-

stages of

ing one with little agreement over the definition of architecture. The only consensus seems to be that architecture is

the development process. The structures we found fell into

several broad categories: conceptual architecture, module
interconnection
architecture, execution architecture, and
code architecture. Within each category, the structures

related to the structure

describe the system from a different

The research area of software architecture

among its components

on building

of a system and the interactions

[14, 25]. Some of the work focuses

theory and models of architecture

an emphasis on taxonomy, description

fication

of architectural

is an emerg-

properties.

[2, 31], with

efforts

perspective:

describes the system in

terms of its major design elements and the relation-

languages, and veriSeveral

The conceptual architecture

ships among them.

have

been made to generate code based on parts of architecture

The module

interconnection

passes two orthogonal

[13, 27]. In general, the literature relies heavily on informal

encom-

architecture

structures: functional

decompo-

sition and layers.

examples

and anecdotes, and most of this work has not

been proven to be scalable for large systems. Also missing
from prior work is the focus on the pragmatic role of architecture in software development activities [1 O, 33].

The

execution

architecture

describes

the

dynamic

structure of a system.

Permission to copy without fee all or part of this material is

granted provided that the copies are not made or distributed for
direct commercial advantage, the ACM copyright notice and the
title of the publication and its date appear, and notice is given
that copying is by permission of the Association of Computing
Machinery. To copy otherwise, or to republish, requires a fee
and/or specific permission.
ICSE 95, Seattle, Washington USA
@ 1995 ACM 0-89791 -708- 1/95/0004 ...$3.50

By architects,

we mean those who designed

the software

architecture,

2, We will refer to the module interconnection

module architecture

196

architecture

for brevity and ease of reading.

as

System

Application

Domain

Size

Important

System Characteristics

user interface

small

window

B*

signal processing

medium

monitoring,

image and signal processing

medium

high throughput

D*

signal processing

medium

monitoring,

E*

image and signal processing

very large

high throughput

F*

computing

medium

management of distributed

environment

management
real-time

real-time,

safety-critical

information

(_&#

instrumentation

and control

large

fault tolerance, multi-processing,

instrumentation

and control

large

multi-processing

operating system

large

real-time

communication

very large

multi-processing

K*

communication

very large

distributed,

heterogenous,

safety-critical

multi-processing

small: fewer than 100 KLOC; medium: 100-500 KLOC; large: 500-1 MLOC; very large: more than 1 MLOC

* These systems were selected for detailed study.

----lable

1: Summary

.,.

ot the surveyed

The code architecture describes how the source code,

binaries, and libraries are organized in the development

.-

Systems

ties. However,

the focus of this paper is to describe the

software architectures we found. We will examine the role

of software architecture in the software development process in more detail in a subsequent paper.

environment.
As shown in Table 2, not all of the systems have explicitl y described architectures for each category: in several
cases, the architectures are implicit in text, code, or one of

For this paper we describe portions of three of the systems surveyed: one was chosen as a prototypical example,

the other architecture

and the others were chosen for the richness of the architec-

descriptions.

We also found architec-

tures that were a hybrid or that mirrored

they did make a distinction
separation of engineering
ized implementation
of implementation,
tion,

among these architectures,

from these examples,

the

and improved

decreased the complexity

to actual systems.

We first give a prototypical

reuse and reconfigura-

details

and changed the names of the sys-

tems to remove any connection

concerns, combined with special-

techniques,

example

of one of these

systems, System B, in Section 2. This system provides a

good overview of the kinds of structures found in the software architectures, and of typical ways the architecture
was used.

Code

Module

Execution

+C

full

describes portions

edge in their use of software architecture. These systems

demonstrate the advantages to be gained frolm the separa-

+
+a,b

tion of concerns

System

Conceptual

tures they used. We have removed the proprietary

each other. When

+
+b

+C

+o,b

K
a. mirrors conceptual,
c. mirrors execution,
Table

is a good intro-

of

the

architecture

we

found.

Section 3

of two systems that are ut the leading

as realized

in different

structures,

and

that arise when the structures

are combined.
The final section summarizes the description
techniques that were used to describe the software architectures.

b. mirrors module,

2.

d. combined with execution

2: Explicitly Described Architectures

Surveyed Systems

variety

how to avoid the problems

+b

While System Bs software architecture

duction to the state of the practice, it does not include the

in the

Four

Distinct

Software

Architectures

Before giving a detailed description

of the four kinds of

software architectures we found, we first put them in context by relating them to the historical development of software and offering examples of why they are needed and
how they are used (Table 3).

We also observed that software architecture played an

important role throughout the development process, and in
achieving desired levels of non-functional
system proper-

197

Examples of Influencing

Examples of Uses

Software
Architecture

Code

configuration

management,

system building,

programming

OEM pricing

Factors

language, development

tools and envi-

ronment, external subsystems (e.g., X windows)

Architecture
Module

management and control of module interfaces,

Architecture

analysis, consistency

enabling software technologies,

change impact

checking of interface constraints,

organization

struc-

environment

perfor-

ure, design principles

config-

uration management
Execution

performance

Architecture

configuration

and schedtdability

hardware architecture,

analysis, static and dynamic

of the system, porting systems to different

mance criteria,

exe-

run-time

communication

mechanisms

cution environments
Conceptual

design using domain-specific

Architecture

formance estimation,

components

and connectors,

safety and reliability

standing the static and dynamic configurability

Factors of Software Architectures

real-time

Initially, only the source code existed. Then interfaces

were introduced for type checking by compilers or other

and

systems
with

building
a flexible

techniques [22]
product

structure

were

manipulate

the file level organization

information

belongs in the code architecture.

of source code. This

[35], PIC [37], and NuMIL

to the module architecture

tation of other structures.

Although
the conceptual
architecture of System B is not documented explicitly, the

(e.g.,

system architect drew informal

system components
tual architecture

needed

Recently a number of interconnection languages have been

introduced that address the issue of allocating components
in a distributed environment.
These include Conic [21],

tional components

[29], Polylith

architecture

[27],

categories,

when describing

and UNAS

model of its concepwith the sys-

and through
extensive
studies of the
and code. This model is informally

described in Figure

1; the rounded boxes represent funcwhile

the rectangular

boxes represent

[28].

these issues are

addressed in the execution architecture.

Now research is progressing to higher abstraction levels.
Software

engineers

would

like

to be able to compose

soft-

ware systems using communicating

objects [1, 30] or
assemblies of components and connectors [4,6,8,23,31]. We
place these concerns in the conceptual architecture.

Data Acquisition
Connector

The remainder of this section describes System B, which

is a good example of typical practices regarding the
description

and use of software architectures.

OCompone.t

System B col-

mConnector

lects data from remote sensor groups for a number of sites

and generates reports

of the monitored

data. Safety

and

Figure

198

major

the system to us. We

based on these discussions

tem architect
documentation

In our software

diagrams depicting

have derived a component-connector

to consider dynamic structure and communication,

coordination,
and synchronization.
Functional
components
needed to be allocated within the dynamic structure [16].

Durra [3], Enterprise

structure of the sys-

In most of the systems we surveyed, conceptual architectures were implicit and embedded within the documen-

in our categorization.
programmers

the system in

tem, using design elements and relationships specific to

the domain. Conceptual architectures are independent of
implementation
decisions and emphasize interaction protocols between design elements.

[24]). This corresponds

When systems became distributed,

describes

among them. This is a very high-level

structures for programming-in-the-large

was first recognized by DeRemer and Kron [7]. Several variants of module interconnection
languages [26] have been defined that
support various features of programming-in-the-large

architecture

terms of its major design elements and the relationships

As systems became even larger and multiple programmers worked on a project, abstraction mechanisms, modinterconnection
structures
were
ules,
and
module
introduced.
The importance
of module interconnection

Intercol

system

Architecture

The conceptual

and

are some of the important

for System B.

2.1 Conceptual

introduced

to describe

performance

characteristics

tools, As software became larger it became useful to divide

source code into files and introduce information
hiding
techniques. Make[ 12], configuration
management[11 ],
along

domain, abstract software paradigms,

design methods

of the system

3: Uses and Influencing

Table

application

per-

analysis, under-

1: Conceptual

Architecture

of System B

Connection
RequestlAck
1

System B

...

...
1
...

Data
Acquisition

...

Logging
Service

Clock
Service
1
F&

Report
Generator
2: Decomposition

Figure

of the Data Acquisition

Connector in System B
connectors
nents.
Both

(i.e. interfaces

and protocols)

components

Figure

and connectors

2 demonstrates

connector in Figure

3: Functional

Decomposition for Application

Software of System B

between compo-

how

the

and connec-

data

a data acquisition

tion modules are assigned to the top two layers (Figure 4).
The layers in the architecture represent allowable inter-

decom-

can be further

components

faces among the application

acquisition

1 can be further decomposed

of a connector representing

in terms

protocol

modules as well as the mod-

ules implementing the platform software. Modules within

a layer can communicate with each other. Modules in dif-

and

using state

ferent layers can communicate

tables for the client and servers. Typical message

respective layers are adjacent.

other components.
transition

Display
Manager

The layer structure of System B shows how the applica-

posed in terms of more primitive

tors.

Figure

Database
Manager
1

This protocol

is described

flows are described using extended sequence charts. Details

of message formats complete the description of the protocol .

2.2 Module

Data Acquisition, Report Generator, etc.

Logging Service, Clock Service, Database Mgr,
Display Manager, etc.

Architecture

The module architecture

supports programming-in-the-

large [7]. It encompasses two orthogonal

tional decomposition

structures:

and layers. Functional

func-

decomposition

of a system captures the way the system is logically

ma

decom-

posed into subsystems, modules, and abstract program

units. It captures the components
interrelationships
in

terms of exported and imported interfaces. Layers reflect

design decisions based on allowable import/export relations
and interfacing

constraints.

nal (e.g., hardware

I Interrupt

Device Service Moclules

Figure

Service Modules

4: Layer Structure of System B

They reduce and isolate exter-

and operating

dependencies, and facilitate

system)

bottom-up

The dominant

and internal

building

relationship

the module architectures

and testing

Unlike the conceptual architecture,

and

a component

architecture

may be imple-

mented by one or more modules in the module architec-

the module architec-

ture. The implementation

ture reflects implementation

decisions. These implementaindependent
of
any
tion
decisions
are general] y
language. Thus this architecture

between the conceptual

is implemented_by:

or connector in the conceptual

of various subsystems.

programming

with each other only if their

of a conceptual

connector

is

usually distributed across several modules, and may be

included in the implementations of components connected

can also be

In System B, as in most of the systems we studied, the

module architecture is the most developed aspect of the sys-

to it. For example, implementation of the data acquisition

connector is distributed across both the remote sensor
groups and the data acquisition module. A conceptual connector also imposes the interface requirements between its

tem. The application

implementation

thought of as the ideal implementation

into a collection

software of System B is decomposed

of modules for the major functions

system (Figure 3). The platform

decomposed

into

structure.

software

system modules

of the

and the implementations

of its connecting

components.

of the system is

such as the real-time

2.3 Execution

operating system, file management, and the device drivers.

Details of the interfaces between pairs of modules are
described in the architecture specification.

Architecture

The execution architecture

is used to describe the
dynamic structure of a system in terms of its run-time elements (e.g., operating system tasks, processes, address
spaces), communication mechanisms, assignment of func-

199

v
ksk====
~ --!2 E!iiYi!m
.-q
System B

include
files

@@

Printer

Report
Generator
Task

Database
Manager
Task

Service
Task

Rm

Display Service Task

OS task

3 queue
5: Execution

Figure

Architecture

of System B

tionality to run-time elements, and resource allocation. It

also describes design decisions related to location, migration, and replication
The driving

forces behind the structuring

decisions here

requirements,

are performance,

distribution

time environment,

which includes the under] ying hardware

implementation

and the run-

ing system

architecture

is a prominent

a simple but typical

architecture

(Figure

run-time elements in the execution architecture. In addition, each of the run-time elements in the exespecific modules in
cution architecture is implemented_by
the module architecture.

part of the
2.4 Code Architecture

module from the

The code architecture

from

the detailed

More information

environment

diagram

to reference

accompanying

architecture.

installation,
to minimize

the

(or its implementation)

element

relation

as~igned_to,

in the execution

can be related to a
architecture

Second, the communication

nisms selected in the execution

architecture

dependencies

include files and libraries

using the

soft ware are separated.

mecha-

constrain

and the

system

building,

management.
(e.g.,

as part

that the major

compilation)

Other

uses are

among

constraints

use

system

sub-

specified

For System B, the organization of the source code mirrors the functional decomposition of the module architecture of the application. The code architecture (Figure 6)
consists of directories for include files (defining interfaces), common library functions and source code. The

The relationship between the conceptual and execution

architectures is two fold. Fh-st, each conceptual component
or a connector

is to facilitate

and configuration

not described

We found

projects and to enforce import/export

in the module architecture.

order of communication
among the tasks. These diagrams
are similar to object interaction diagrams used in object-oriented analysis [18].

run-time

management),

it is generally

architecture.

of this architecture

among the tasks is

text that describes

systems,

of the software

shown using control and data flow diagrams. The paths are
numbered

(e.g., configuration

the surveyed

and asynchro-

of the execution

files, and

structure of the project (e.g., inter-corporation)

and the
organization. Although this architecture is explicit in all

to exchange data. Figure 5 is derived

about the interactions

the source

directories,

libraries. This architecture is influenced by the choice of

the programming
language, the development tools and

sensor group. The real-time operating system provides the

queues, semaphores, and mailboxes that are used for interprocess communication between tasks. Tasks, acting as prouse both synchronous

is used to organize

code into language level modules,

task, and sometimes a module is replicated by having mttltiple instantiation

of its associated task. For example, the
Data Acquisition
task is replicated once for each remote

nous communication

constrains

assigned_to

is assigned to its own operating system

ducers or consumers,

mechanisms

connector is implemented.

example of an execution

5). Each application

module architecture

and connec-

The relationship between module and execution architectures is similar. Modules in the module architecture are

of all of the surveyed systems. System

B illustrates

components

and communication

how the data acquisition

ogy of the hardwarelsoftware

platform changes frequently.
Execution architectures are used for performance analysis,
monitoring, and tuning as well as for debugging and service
maintenance. The execution architecture is sometimes trivial, as for example when the system is a single process.
The execution

of conceptual

of System B

tors. In System B, for example, the selection of the operat-

and software platform. Thus, the execution architecture is

likely to change more often because the underlying technol-

software architecture

6: Code Architecture

Figure

of a systems run-time elements.

the

200

for the application

and system

The relationship

characterized

abstract program

unit in the module architecture

mented_by

the above categories. The challenge, as we see it, is to pre-

between the module and code architec-

tures is simply

cisely describe these architectures,

Each

by implemented_by.

tions

is imple-

to manage complexity,

between

concrete program units in the code architecture.

the

There is also a relationship between run-time elements

in the execution architecture and elements such as executa-

manipulation

ble and configuration

3.

files in the code architecture.

descriptions,

and

of the descriptions

Separation

separate their descrip-

establish

correspondences

facilitate

analysis

and

[32].

of Concerns

It has long been recognized by hardware designers that

2.5 Summary

separation

of concerns

has powerful

advantages

when

have also described the relationships among the conceptual,

module, execution, and code architectures; these relation-

developing large, complex systems. They have reached

agreements about separating design artifacts into levels
(e.g., architecture,
logic design, physical
layouts and
masks) describing different concerns, and about the pre-

ships are summarized

cise description

In this section, we have described the four categories of

software architectures found in the surveyed systems. We

in Figure 7.

The four kinds of architectures address different

inter-related engineering concerns:

Each contains the results of engineering

at different

times

Separation of concerns
[20].
reflective
systems

though

decisions taken

in the development

design time, implementation

process

time, build

time,

(e.g.,

Each is developed
different

and used for different

teams (e.g., system architects,

The degree to which

each architecture

The degree to which

each architecture

purposes by

reflects imple-

exploitation

is expected to

category can be characterized

by

from resource management.

systems we studied:
of commonalities

in product families,

faster turn around time for enhancement of application

functionality,

tecture.
their interconnections,

systems [ 1]. Concur-

the task of programming

Separation of engineering concerns facilitated the three

architecture-related objectives that are common among the

Each architecture

simplify

indepen-

in orcler to facili-

approach is used to deal

of concurrent

by separating functionality

programmers,

change varies. For example, the execution architecture

is likely to change more often than the conceptual archi-

set of components,

A similar

is defined

separating design concerns such as locality and synchronization. The separation of design concerns is accomplished
by using abstractions to specify coordination patterns, and

mentation decisions varies.

an object
environment,

rency abstractions

system builders, or service personnel).

system [38] for example,

with the complexity

Each is influenced by different engineering and organizational factors such as clarity, reducing dependencies
among programming tasks, evolution, or performance.

is also used to advantage in

In the Apertos
operating

dently from its execution

tate object migration.

or run

time).

of these design artifacts [5, 19].

evolution

and

due to evolving

hardware and software tech-

nologies.

using a

Our observation

and the criteria

is that the use of different

kinds of

for evaluating them. Table 4 gives examples of typical com-

architectures

ponents and interconnections

tives, Many of the reported successes of the surveyed sys-

for architectures

in each of

I Conceptual

components,

Architecture

Execution
Architecture
+4
subsystems, modules,
exports, imports, ...

,
*
implemented_by

tasks,
threads,
IPC, RPC,

~
assigned_to
Architecture

files, directories, libraries

includes, contains, ...
H

Source

+
conjigured_by

.,.
,,

located_in

Code

Figure

7: Relationships

among the Software Architectures

201

+
LHardware

Architecture

resourc e_resides_on

assigned_to

implemented_by
Code

II

implemented_by
Module

arose in part to address these common objec-

processors,
networks,

memory,,
disks,...

Components

Interconnections

Engineering

Conceptual

domain-specific

domain-specific

constraints

Architecture

components

interconnections

Module

systems, subsystems,

component_of,

Architecture

modules, layers

export_to

Execution

processes, tasks, threads,

inter-process

Architecture

clients, servers, buffers,

remote procedure call

criteria for priority assignment, constraints imposed by

run-time environment

member_of,

includes, contains,

compilation

linked_with,

compiled_into,

management

Software

Criteria

Architecture

import_from,

functional

on cycles, requirements

decomposition

on throughput

methods, criteria such as

information hiding and abstraction, when to use mukiple interfaces, constraints imposed by layering strategy
communication,

message queues
Code

files, directories,

Architecture

libraries,

linker

packages,

with clause, use clause

program libraries

4: Characterizations

Table

terns resulted from allowing the different

develop independently while maintaining

and build time, criteria related to project

and configuration

the development

management tools and

environment

of the Software Architectures

areas of measurement

architectures to
the relationship

closed loop control

of control

variables,

of devices. Each functional

and open/
diagram

between them. Similarly,

some of the problems they
reported were a direct result of merging or intermingling

consists of a small number of interconnected basic functional blocks (Figure 8). These functional blocks are the

these architectures.

basic

In Section 2, we described the typical software architectures found

in the surveyed

systems. Next

we describe

some of the more elegant examples of software

The architecture
architecture.

a well-

are the most complex

architecture, it uses two kinds of components, a Group

Module, and a Run-time Environment. A Group Module is

of System G has an explicit

tion that both serves as documentation

by engineers

each performing

System G explicitly distinguishes between the conceptual and execution architectures. To organize the execution

conceptual

a group of functional

One of the design goals for this system is to

verification

functionality,

parts of the software.

Architectures

have a formal (i.e., complete and unambiguous)

allows

of

and fault tolerance; these protocols

architec-

tures, and the advantages of separating them.

3.1 Conceptual and Execution

in System G

units

defined mathematical or control function. The conceptual

architecture also includes protocols for synchronization

tual

representa-

diagrams that are executed on a vir-

provided

Each Group Module

for the users, and

of various

machine

by the Run-time

Environment.

is assigned to the Run-time

Environ-

ment on a single processor (Figure 9). The local execution

disciplines.

architecture

Such verification may include verification against the system requirements, checking syntactic consistency, and validation with a system simulator.

for each processor is separately described in

terms of its Group

processes executing
communication

Module, its Run-time Environment,

other software modules, buffers, and

mechanisms.

The conceptual architecture is decomposed into a network of several thousand interconnected

functional diagrams. The network organizes functional
diagrams into

Author

Date
Figure

8: Example

Remarks

of a Functional

Planname

Diagram in

Figure

System G

9:

An Overview

of the Execution
System G

202

Architecture

in

one-to-one

many-to-one

Functional

part of

is <c,,

* a

constrains

Figure

Layer

System

relationship

c
~-~

Decomposition

10: Entity -Relationship-Attribute

Structure
lLayer~ll

Notation for

Relationships
System G is the best illustration

for the benefits of sepa-

ration of concerns. It clearly separates the instrumentation

and control

(I&C)

functions

from the complex

protocols

related to fault tolerance and synchronization, and separates

the execution architecture from the rest of the software.
This approach has made the introduction of digital technology both tractable and feasible.
Separation of the conceptual
design, analysis, verification,

architecture

facilitates

the

and update of I&C functions

by process engineers and I&C

~J

is assigned to

engineers. The conceptual

Language Level
Module
-

architecture is preserved and/or traceable in the code, making it possible to update and replace any Group Module at

11: Skeletal Mets-Model

of the
Module Architecture in System K

Figure

build time.
Separating out the complex protocols supporting faulttolerance and synchronization made the protocols amenable

cation software of the system is decomposed into subsystems that are further decomposed into subsystems, until
reaching the lowest level abstract modules called Service

to formal modeling and analysis, and simplified their implementation and verification.
Through the use of extended
finite state machines (e.g. Statecharts [15]), several errors in
the protocols
separation
functional
code

also simplified

the manual

blocks and the Run-time

related

Provision

were caught early in the design phases. This

to

implementation

Environment,

synchronization

and

of

straining the connections between SPUS. The connections

between abstract modules are grouped into system-level

is

located elsewhere.
Finally, separation of the execution architecture

connections

from the

guage elements to provide the designer with larger, more

abstract functional building blocks. These promote software reusability at the level of services by tightly defining

machine that executes functional diagrams also made it easier to change the platform software (e.g. operating system
without

affecting

ware (cf. Chimera [34] with

the application

its multilevel

and restricting

soft-

reconfigurable

Architectures

and execution

tures are notable. To show these architectures,

between

notation.

tionality

decomposition
structure are then assigned to a layer,
thereby constraining the SPUS interfaces and dependen-

we use an

Components

in boxes),

interestarchitec-

(shown

between components

are described with the symbols listed

into

SPUS. The

cies. This assignment

are rep-

resented as entities
in Figure

interplay

layer model is designed before any functional decomposition takes place, and is used to guide partitioning of func-

here the module

entity -relationship-attribute

an interesting

the functional decomposition

and the layers. The layer
structure (Figure 11) consists of a number of layers, each
of which may be further decomposed into sublayers. The

System K is another system with a particularly

ing architecture:

the scope of the SPUS.

System K illustrates

software framework).

3.2 Module and Execution

in System K

at the subsystem level.

An SPU is an abstract module class created by the system architects. SPUS contain a mix of implementation lan-

other architectures facilitated reconfiguration

of functional
diagrams into Group Modules and their processor assignments. The use of a Run-time Environment
as a virtual

and communication)

by an SPU

SPUS can interact

with each other only through these interfaces, thereby con-

since the

fault-tolerance

Units (SPUS). The services provided

are defined by their abstract interfaces.

SPUS from

constrains

the

functional

an SPU to interact only

with SPUS that are assigned to adjacent layers. The separa-

and relationships

tion into layers allows changes to be made to components

of the other
at one layer without affecting the components
layers. It also provides application independence from the
evolving hardware. It also facilitates the bottom-up building and testing of various subsystems.

10.

Like System B and several other systems, the module

architecture of System K encompasses both functional
decomposition and a layer structure (Figure 11). The appli-

203

Processing
platform

Capsule i

I Capsule 1

I
I

Active Element
(e.g. OS process
or task)

Data Element
(e.g. buffer,
disk storage)

Module
Instance
(e.g. SPU
instance)

Other
Resources
h

Figure

Ai.rh
SPU m

IIB

nil.

ISPU1

OS kernel

of the
in System K

Architecture

Communication;

Like System G and several other systems, System K

uses an execution grouping to organize the execution archi-

(see Figure 13). The SPUS that comprise

ability,

cute on the same processor and are allocated a subset of the

resources

sules are then

resource

arated from
tial

mentations
tion

to

changes

grouping

architecture
the

based on CPU

architecture

other

inter-process

Combining

architectures

of capsules

allocation

rather than decisions

based on functional

adaptation

of

Description

Techniques

that most architects

of informal

software

and developers

and semi-formal

architectures.

This

use a

techniques

is not

to

surprising

of architecture. CASE tools are beginning to be used to

construct functional decomposition diagrams. On the other
hand, informal diagrams, tables, and natural language text

of

with naming conventions

module and execution

related

the

execution architectures.

finite state machines are two description techniques that

were extremely useful for describing and modeling aspects

to the code.

decisions

facilitates

communi-

Careful sepa-

since rigorous architecture description techniques are not

available. Entity -relationship-attribute
(ERA) notation and

alternate

can reduce understandability

reflects

related to protocols,

decisions

Architecture

describe

are used to describe many of the

other software structures. Even when a formal notation is

used, it is often supplemented with informal and incom-

architectures can group together functional components that

are not logically related. This reduces understandability
because decomposition

such

combination

Summary

the system. For example, combining

of

We found

to

communica-

and migration

any changes

order

SPU imple-

allows

evolv-

sep-

of potenIn

architecture,

SPUS. This

capsules

without

in anticipation
architecture.

to the execution
with

K is explicitly

can limit

to change over to

and resource allocation.

reusable components to different

4.

of System

execution

of SPUS into

to other processors
3.3

to processors

use loosely-coupled

for interaction

ration

resources. Cap-

requirements.

its module

changes

facilitate

assigned

architectures
and ability

decisions

cation mechanisms,

and therefore a

need of computational

and timing

The execution

implementation

of SPU instances to capsule is based on

SPUS that have related functions

related cumulative

combining

reconfigurability,

commercial, off-the-shelf technology. This is due to intermingling

the implementation
of the functionality
with

(e.g., address space, memory

pool, timers). The contents of a capsule are defined at build

time. The allocation

system units

13:

In summary,

the capsule exe-

with oth;r

An Overview of the Execution

Architecture in System K

Figure

tecture (Figure 12). System Ks execution group is called a

capsule, and it contains instances of one or more SPUS

grouping

12: Skeletal Mets-Model

Execution

total processing

II

plete diagrams,

to task

in order to enhance the understanding

of

the formal model.

rela-

The disadvantages

tionships.

niques

Combining architectures can also significantly

increase
the cost of porting to a different hardware or software platform, requiring significant rewriting of code. Porting often
requires changes in the execution architecture. When the

are described

out in the surveyed

ity of informal

module architecture is made to mirror the execution architecture, the module architecture must change in response to

systems.

descriptions,

inconsistencies
architecture

changes in the execution architecture. Such changes in the

module interfaces and the process boundaries may result in
reworking of code.

and the code.

tools

based software

204

Among

be used

development

of detecting
between

without

to describe
to support

activities.

tech-

was borne

these are the ambigu-

traceability

In addition,

language

cannot

description
and this

and the problems

and establishing

and an unambiguous
automated

of using informal
in the literature,

the

a rigorous

architectures,
architecture-

We found two other common

ture was described

informally.

problems

when architec-

It is difficult

4.2 Describing Relationships

among
Software Architectures

to recognize

and exploit similarities between architectures of other products within a product family. Conversely, it is easy to blur
the distinction

between quite dissimilar

the descriptions

architectures

For describing
between

when

being

are informal.

used:

hybrid

4.1 Describing

Software

mirroring

structures,

mechanisms

Architectures

When explicitly

described, the conceptual architecture

block diagram depicting

model.

machines

System

uses extended

(e.g. StateCharts [15])

to model

finite

state

using stacked rectangular

between components
have sublayers,

in different

to model

structure

boxes. Adjainterfaces

and the execution

in separate dia-

is often embedded

buffers,

execution
transition

in the code

and communication

nisms. Sometimes the relationship

and these
given rep-

and the relationships

architecture

of the layer

to describe the

among them.

models

(from

architecture).

diagrams are used to better understand the

and their relationships.

Conclusions

mecha-

of execution architecture

In this paper, we have presented a discussion

of soft-

elements to the hardware elements such as processors and

ware architecture

networks

tion was based on a survey of the software architecture

is also described. When the systems use module

and execution architectures

cution

architecture

architecture.
architecture)

that mirror each other, the exe-

is often superimposed

on the module

K is superimposed

Again

a notable exception
of formal

notations

while architecture

uses a

descriptions

and analysis techniques are

a systems software architecture.

to describe

diagrams, Group Modules,

of

systems stud-

a mix of informal and semi-formal, separate architectures

were used to describe the different concerns addressed by

the execution architecture. In the formal notation, Group

Modules are constructed from collections of functional diagrams. The functional

This presenta-

ied in depth. The systems represent a variety of application

on its layer

is System G, which

and informal

applications.

domains, and range in size from small (fewer than 100

KLOC) to very large (more than 1 MLOC). We found that

structure. The actual contents of each of the capsules are

shown using a separate table.
combination

in industrial

a number of systems, with six representative

For example, the capsule structure (execution

of System

the

and the mode

the execution

formal model of the architectures

5.

to combine

It also uses diagrams

the module architectures

diagrams

These informal

of the two architec-

diagrams

and module architectures.

that superimpose

architecture

processes,

the architectures

tures. System G uses informal

architecture or in configuration files used by system building tools. Execution architectures are informally
documented using a variety of techniques, including text, tables,
and informal diagrams. Such diagrams depict operating
system

for

entity-relationship-attribute

grams or described in text.

Execution

architec-

One of the systems using an explicit mechanism to

describe the relationship between architectures is System
G, in which the relationships between the functional diagrams (in the conceptual architecture) and Group Modules
(in the execution architecture) are formally based on the

layers. When the layers

they are either depicted

the func-

its execution

between them. System K uses a combination

relationships

described

For example,

of System B mirrors

That is, each task in the execution

resentations

tion of techniques.
The functional
decomposition
is
described using decomposition
hierarchies
(e.g. trees,
TeamWork process diagrams), tables, and text. Layers are
usually

Several

with respect to another,

In several systems, hybrid structures are used to show

is described using a combina-

cencies between these boxes represents allowable

explicit

the relationship
between two architectures,
hybrid structures can be derived automatically

protocols.
The module architecture

another,

using

ture is assigned a single module from the module architecture.

voter-checker

protocols, and System K uses a similar formalism

methods

after

correspondence

one architecture

tional decomposition
architecture.

several

architecture

often using naming conventions.

is

major system

components and data and control paths between them. A

notable exception is System G, in which the conceptual
architecture is described using precise, application-specific
notation, thus making it possible for tools to check the syntax of the architecture, analyze it for performance, and generate code. This notation is based on an entity-relationshipattribute

one

and

and correspondences

we found

such as assignment of functionality.

systems mirror
usually an informal

the relationship

the architectures,

The various architectures describe the system from different perspectives, they are characterized by different

run-time

needs and goals, and they are used at different

elements (e.g. telegrams, buffers) of the execution architecture, and the hardware architecture are modeled using an
entity-relation ship-attribute model.

times in the

development process. Many of the reported successes of

the surveyed systems resulted from allowing these architectures to develop independently while maintaining the
relationship between the architectures. Similarly, some of

Code architectures are generally described with the help

of make files or equivalent models for system building.

205

[6]

the problems they reported were a direct result of merging

or intermingling
In examining

the components

and interconnections

the systems, we found that the structures

architecture

[7]

used to describe

fall into four broad categories. The conceptual

and the code architecture

describes

how

[8]

definition

[9]

the

we believe that separat-

the use of formal

description

and analysis)

approaches

need to be developed

[11]

[12]

[13]

rig-

[14]

test, and re-engi-

[16]

[17]

(eds.). Research
Programming,

[19]

to software

1992.

M.R. Barbacci,

Program-

C.B. Weinstock,

and J.M. Wing.

ming at the processor-memory-switch

of the 10th International
ing, IEEE Computer

[20]

[4]

B.W. Beach. Connecting

[5]

C.G. Bell

[21]

in Software

software components

and A. Newell.

and Examples, McGraw-Hill,

Computer

and KnowG(editors),
New Jer-

for complex

Volume 8, pages

sys-

1987.

D.J. Hatley and I.A. Pirbhai. Strategies for Real-Time Sys-

C.H.

Dorset

Hoogendoorn

House Publishing,

and A.T.

for an ATM

Maher.

universal

New

York,

R.H.

Japan, October

Katz,

Information

G. Kiczales,

[22]

1992.
Software

Management

J. des Rivieres,
Protocol,

[23]

programming

of distributable

International

R. Lange, R.W. Schwanke.

E. Mettala

and M.H.

ware architecture

1971.

206

1992.

for

Engineering

and D.G. Bobrow.

The Art of

- a framework

for

systems, In Proceedings

Conference

on Computer

Sys-

Israel, IEEE, May 1990.

Software

architecture

of the Third

Workshop on Soflware Configuration

Readings

Engineering

The MIT Press, 1991.

J. Kramer. Configuration

heim, Norway, ACM

node,
Sympo-

1985.

A case study. In Proceedings

with declara-

software

Switching

Addison-Wesley,

tems and Soflware Engineering,

1988.

Enhanced

communication

of the 14th International

I. Jacobsen et al. Object-Oriented

of the IEEE

International

Structures:

to software archi-

Engineering

D. Hare]. Statecharts: A visual formalism

the development

Conference on Software Engineer-

tive glue, In Proceedings of the Fourteenth

Conference on Software Engineering, 1992.

pp. 266-

tems, Science of Computer Programming,

the Metaobject

level. In Proceedings

Society Press, pages 19-28, April

German

of Fault-Tolerant

Nurnberg,

D. Garlan and M. Shaw. An introduction

Design, Springer-Verlag,

architectures,
Algorithms,
Software, Architecture,
J. van
Leeuwen (editor), Information
Processing 92, Volume 1,
[3]

system, in Proceedings

A Use Case Driven Approach,

The MIT Press, 1993.

Elsevier Science Publishers B.V. (North-Holland),

9:255-265,

1991.

sium, Yokohama,

approach

computer

and Experience,

Systems, Springer-Verlag,

architecture

A formal

-TR-7, Carn-

1988.

[18]

and D. Garlan.

18-22,

management models in commercial

H.D. Fischer. Special features of a computer-based

tem Specification,

References

R. Allen

19 (3):

1979.

Proceedings

[2]

Notes,

of the

Specification

sey, 1993.

Hsu for valuable suggestions.

Object-Oriented

sys-

Succeeding

on Software

S.1. Feldman. Make - a program for maintaining

231-274,

in Concurrent

in real-time

edge Engineering,
V. Ambriola and G. Tortora
Vohrme 1, World Scientific Publishing Company,

We thank all of the architects and developers of the sys-

Directions

Sof~are

Workshop on Real-Time

Engineering

P. Feiler. Configuration

tecture, in Advances

[15]

and A. Yonezawa

Systems by

Society, May 1993.

Workshop

Software

Computing

effectiveness.

P. Wegner,

Software

architectures

of the First

IEEE Computer

287, September

tems we surveyed for their time and patience. We also thank

Amitava Datta, Paul Drongowski, Igor Gordon, and L1ang

G. Agha,

Software

reactor protection

to describe these

Acknowledgments

[1]

verorr Soft-

on Automating

M.S. Feather and A. van Lamsweerde.

November

but have not

neer a software system based on the rigorous description of

its architecture. Finally, all of these architecture-based
activities need to be incorporated in existing development
processes for maximum

Workshop

programs. Soflware - Practice

software architectures, so that they can be analyzed to predict and assure non-functional
system properties. It then
becomes possible to design, implement,

of an

September

environments. Technical Report CMWSEI-91

egie Mellon University, 1991.

will

readily produced scalable, practical results. Meanwhile,

orous techniques

29-36,

July 1994.

(such as formal

that are powerful,

P.J. Drongowski.

and Design.

is crucial.

We believe this separation of software architectures

and K. Lee. Modeling

Seventh International

This separation accurately reflects the practice in development of real software systems, and the reasons for the separation become clear upon studying these systems.
facilitate

R. DIppolito

Applications,
[10]

into more than one perspective

specification

pages

F. DeRemer and H. Kron. Programming-in-the-large

tems. In Proceedings

are not the final answer to the

of software architecture,

ing structures

A formal

Software,

Domains, AAAI-92
Design, July 1992.

source code of the system is organized.

these categories

IEEE

sus programming-in-the-small.
IEEE Transactions
ware Engineering, SE-2 (2): 80-86, June 1976.

structure of the system, the execution architecture describes

the dynamic structure of a system in terms of its run-time

While

and D. Garlan.

1990.

in

architecture describes the structure of a system in terms of

its functional
components and interface connectors, the
module architecture describes the ideal implementation

elements,

N. Delisle
oscilloscope,

these architectures.

analysis:

International

Management,

Trond-

Press, June 1991.

Graham.

program,

The domain-specific

Technical

Report,

soft-

CMU/SEI-

92-SR-9, Carnegie Mellon

ing Institute,

[24]

K. Narayanaswamy
tions of evolving

Software

and W. Scacchi. Maintaining

software

.Software Engineering,

[25]

University,

Engineer-

systems. IEEE

SE-13(3),

ware architecture,

ACM

configura-

Transactions

SIGSOFT

Software

and J.M. Neighbors.

languages. The Journal

334, November

[27] J.M. Purtilo.

Transactions

Module

1992.

of Systems and Software,

the study, we talked

6(4):307-

available

as Technical

of Maryland,

IEEE Computer

Computing,

University

distributed
of Alberta,

[30] B. Selic, G. Gullekson,

an object-oriented

applications,

to visit. This questionnaire

Dept.

J, McGee, and I. Engelberg. ROOM:

for developing

real, Canada, July 1992.

of the Ftfth International

cussions lasted several days over several visits.

used the questionnaire

Workshop on

and Design, IEEE Computer

ture the initial

Society,

pages 143-146, May 1989.

architectures,

In Proceedings

Studies of Soflware Design, Baltimore,

IEEE Computer

in Proceedings
on Software

of the Workshop on

approach to soft-

Raleigh, North Carolina,

Specification

and Design,

they are among the systems for which we Ihad the most

1993.

Robots and Systems (IROS

information.

interconnection.
Conference

6. We distilled

In Proceedings

control

92),

Appendix

pages 29-41, IEEE

Computer Society Press, May 1979.

[36] M. Weiser. Source Code, IEEE
November

Computer,

Technical

Massachusetts,

from

these six systems

This template

appears in

C.

pages 66-73,
8. We then sent the technical report to the designers and

1987.

architects of the systems for their comments, and modified it based on these comments. The internal report

[37] A. Wolf. Language and tool support for precise interface

control.

template.

7. We analyzed the distilled information to m-rive at our

findings. Based on this analysis, we restructured the
description of the systems to improve understanding,
and prepared the internal technical report.

based on module

of the Third International

on So@ware Engineering,

the information

using a structured

July 1992.

[35] W. Tlchy. Software development

architectures

systems. These six, annotated with asterisks in Table 1,

represent a wide variety of application domains, and

of the Seventh Interna-

Society, December

on software

5. We selected six of the systems for more detailed study,

and carefully studied the available artifacts for these

[34] D.B. Stewart, R.A. Volpe, and P.K. Khosla. Integration of

software modules for reconfigurable sensor-based control
systems, In Proceedings of 1992 IEEE/RSJ International
Conference on Intelligent

and to gather information.

May 1993 (to appear

[33] D. Soni, R.L. Nerd, L. Hsu. An empirical

Workshop

discussion

We

to struc-

where the architects described and discussed the architecture of their systems.

Many faces of

in LNCS).
ware architectures,

during these interviews

We also held a workshop

[32] D. Soni, R.L. Nerd, L. Hsu, 1? Drongowski.

B.

4. We held extended discussions with the architects and

designers of these systems. In some cases, these dis-

[31] M. Shaw. Larger scale systems require higher level abstractions, in Proceedings

we intended

appears in Appendix

3. We collected and read design documents and, in some

cases, code for the systems,

real-time

systems, In Proceedings of the CASE92 Ft~th International

Workshop on Computer-Aided Software Engineering, Mont-

Software Specification

read

2. We visited the organizations to present our premise

and the objectives of our study.

of

1993.

methodology

and engineers,

questions and sent it to the organizations

[29] J. Schaeffer, D. Szafron, G. Lobe, I. Parsons. The Enterprise

developing

to architects

1. We started with an initial list of questions to guide our

study. The questions were related to how architecture
was described and used in the development of a system. We developed a questionnaire based on these

Report UMIACS-

May 1990.

Society Press, pages 2-11, March 1990.

for

in industry, As a part of

design documents, and, in some cases, read parts of the

source code. The sequence of steps we undertook is as follows:

1986.

University

consists of, they all recog-

and some are at the lealding edge in

their use of software architecture

interconnection

opment of large software systems. In Proceedings oj the

12th International
Conference on Software Engineering,

tional

Study

The software systems we studied were all developed

industrial applications.
Although the designers and

nize its importance,

[28] W. Royce. TRWs Ada process model for incremental devel-

software

forthe

what the software architecture

Engineering

The polylith software bus. To appear, ACM

on Programming Languages and Systems, Jan-

uary 1994. Also

model

Process

developers of the various systems may disagree on exactly

for the study of soft-

Notes, Volume 17, Number 4, pages 40-52, October

[26] R. Prieto-Diaz

for

on

March 1987.

D.E. Perry and A.L. Wolf. Foundations

TR-90-65,

June 1992.

Report COINS-TR-85-23,

University

of

provides the basis for this paper.

1985.

[38] Y. Yokote. The Apertos reflective operating system: the concept and its implementation,
pages 414-434, October

In Proceedings

of 00PSLA

92,

1992.

207