Introduction to Software Architecture EEE465 2001 Includes material from a lecture by David Garlan a

1
Introduction toSoftware Architecture EEE465
2001Includes material from a lecture by David
Garlan and Mary Shaw References SG96 ch. 1,
2.1, and 2.22.10

• Major Greg Phillips
• Royal Military College of Canada
• Electrical and Computer Engineering
• greg.phillips_at_rmc.ca
• 01-613-541-6000 ext. 6190

2
Software Architecture Theme

• Progress in software development has resulted
  from
• abstraction focus on important qualities
• codification presentation in an operational form
• These techniques will establish an engineering
  discipline for software
• They will guide our study of software architecture

3
What is Engineering?

• Creating cost-effective solutions.
• to practical problems
• by applying scientific knowledge
• to building things
• in the service of humanity.

Engineering enables ordinary people to do things
that formerly required virtuosos.
4
Good Science Good Engineering
Folklore
Ad hoc solutions
Improved practice
New problems
Codification
Models and theories
5
A Common Experience

• Frequently-heard comment at the end of many
  large projects

Things would have gone much smoother if we had
had an architect and agreed on an architecture.
What exactly does this mean? How would the
architecture be communicated?
6
Building a Skyscraper
7
Building Software
8
Building a Skyscraper, Software Style
9
The Problem
Requirements
How to bridge the gap between requirements and
solutions?
???
Implementations
10
Typical Solution
Requirements

• Ad hoc
• Requires gurus
• Unpredictable
• Costly

A Miracle Happens!
Implementations
11
Methodologies
Requirements

• Increased predictability
• Some design guidance
• BUT
• Limited applicability
• Still requires gurus

SADT
JSD
OO
Implementations
12
Role of Software Architecture
Requirements

• Composition of large-scale components
• System-level abstractions
• Reuse of design idioms

Software Architecture
Implementations
13
Typical Architectural Descriptions

• Descriptions of software systems often include a
  section on the architecture of this system
• Usually informal prose plus box-and-line diagram
• Lots of appeal to intuition
• Little precision, very little formality

As dfansd as fdj sdlkjasf adlfja lkjfkj adsfj
lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf The Architecture of this System Qwnxrs
dfansd as fdj sdlkjasf adlfja lkjfkj adsfj
lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf. As dfansd as fdj sdlkjasf adlfja lkjfkj
adsfj lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf. As dfansd as fdj sdlkjasf adlfja lkjfkj
adsfj lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf Dbbd as fdj sdlkjasf adlfja lkjfkj
adsfj lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf. As dfansd as fdj sdlkjasf adlfja lkjfkj
adsfj lasdfkrio iw asdf adfjow cnae adlne adne a
aldjf. As dfansd as fdj sdlkjasf adlfja lkjfkj
adsfj lasdfkrio iw asdf adfjow Next Section
Adlfja lkjfkj adsfj lasdfkrio iw asdf adfjow
cnae adlne adne a aldjf. As dfans sd ad fa adf
adfasljl lkjlj ladd
14
This is Not an Architecture!
15
Component Representation Issues

• What is the nature of the components?
• What is the significance of their separation?
• Do the components run on separate processors?
• Do they run at separate times?
• Do the components consist of processes, programs,
  or both?
• Do the components represent ways in which project
  labour will be divided, or do they describe
  runtime separation?
• Are they modules, objects, tasks, functions,
  processes, distributed programs, or something
  else?

CP
MODP
MODR
MODN
16
Connection Representation Issues

• What is the significance of the links?
• Do the links mean the components
• communicate with each other?
• control each other?
• send data to each other?
• use each other?
• invoke each other?
• synchronize with each other?

CP
MODP
MODR
MODN
17
Configuration Representation Issues

• What is the significance of the layout?
• Why is CP on a separate level?
• Does it call the other three components, and are
  the others not allowed to call it?
• How does the architecture operate at runtime?
• How do data and control flow through the system?

CP
MODP
MODR
MODN
18
Architectural Notation
Adapted from BCK98
label
component of unspecified type
label
passive data
Components
computational component/object
process
label
active data
connector of unspecified type
data flow
Connectors
control flow
data and control flow
19
Typical Architectural Descriptions

• Camelot is based on the client-server model and
  uses remote procedure calls both locally and
  remotely to provide communication among
  applications and servers.
• We have chosen a distributed, object-oriented
  approach to managing information.
• The easiest way to make the canonical sequential
  compiler into a concurrent compiler is to
  pipeline the execution of the compiler phases
  over a number of processors.
• The ARC network follows the general network
  architecture specified by the ISO in the Open
  Systems Interconnection Reference Model.

20
Issues Addressed by an Architecture

• Gross decomposition of a system into interacting
  components
• typically hierarchical
• using rich abstractions for glue
• often using common design idioms/styles
• Emergent system properties
• performance, throughput, latencies, reliability,
  security, fault tolerance, evolvability
• Rationale
• relates requirements and implementations
• Envelope of allowed change
• load-bearing walls
• design idioms and styles

21
Elements of Architectural Descriptions

• The architecture of a system includes
• Components define the locus of computation
• examples filters, databases, objects, ADTs
• Connectors define the interactions between
  components
• examples procedure call, pipes, event announce
• An architectural style defines a family of
  architectures constrained by
• component and connector vocabulary
• topology
• semantic constraints

22
Common Architectural Idioms

• Data flow systems
• batch sequential
• pipes and filters
• Data centred systems (repositories)
• databases
• blackboards
• Call-and-return systems
• main program and subroutines
• hierarchical layers
• object-oriented systems
• Independent components
• communicating processes
• event systems
• Virtual machines
• interpreters
• rule-based systems
• and many others...

23
Next ClassData Flow Architectures