Introduction to
Software Architecture
Sam Malek
CS 795 / SWE 699
Spring 2010
George Mason University
Software Architecture Definition
Definition. A software system’s
architecture is the set of principal
design decisions about the system.
Software architecture is the blueprint
for a software system’s construction
and evolution.
© Malek
2
Design Decisions
Design decisions encompass every
aspect of the system under development
This includes design decisions related to
Structure
Behavior
Interaction
Non-functional properties
© Malek
3
Defining “Principal”
•
“Principal” implies a degree of importance that
grants a design decision “architectural status”.
•
It also implies that not all design decisions are
architectural, that is, they do not necessarily
impact a system’s architecture.
•
How one defines “principal” will depend on what
the stakeholders define as the system goals.
© Malek
4
Software Architecture
as a Field of Study
•
Software architecture is a field of study that
is characterized by an unusual diversity of
views and understandings of some
fundamental concepts.
•
A quick search of the internet will yield
many definitions of architecture for
example.
© Malek
5
Other Definitions of Software
Architecture
Perry and Wolf
Software Architecture = { Elements, Form, Rationale }
what
how
why
Shaw and Garlan
Software architecture [is a level of design that] involves
•
•
•
•
the description of elements from which systems are built,
interactions among those elements,
patterns that guide their composition, and
constraints on these patterns.
Kruchten
Software architecture deals with the design and
implementation of the high-level structure of software.
Architecture deals with abstraction, decomposition,
composition, style, and aesthetics.
© Malek
6
Temporal Aspect
Design decisions are (un)made over a
system’s lifetime
 Architecture has a temporal aspect.
A system’s architecture will change over
time. However, at any given point in
time, the system has only one
architecture.
© Malek
7
Prescriptive vs. Descriptive
Architecture
A system’s prescriptive architecture captures
the design decisions made prior to the
system’s construction.
It is the as-designed or as-intended architecture.
A system’s descriptive architecture describes
how the system has been built.
It is the as-implemented or as-realized
architecture.
© Malek
8
As-Designed vs. AsImplemented Architecture
© Malek
9
As-Designed vs. AsImplemented Architecture
© Malek
10
As-Designed vs. AsImplemented Architecture
• Which architecture is “correct”?
• Are the two architectures consistent with one
another?
• What criteria are used to establish the consistency
between the two architectures?
• On what information is the answer to the
preceding questions based?
© Malek
11
Architectural Evolution
When a system evolves, ideally its prescriptive
architecture is modified first.
Unfortunately often the system and thus its
descriptive architecture is directly modified.
This failure of update happens because of
Developer sloppiness
Perception of short deadlines which prevent thinking through
and documenting
Lack of documented prescriptive architecture
Need or desire for code optimizations
Inadequate techniques or tool support
© Malek
12
Architectural Drift vs. Erosion
Definition. Architectural drift involves architectural
design decisions that are applied directly to a
system’s descriptive architecture, but are not
properly reflected in the system’s prescriptive
architecture.
Definition. Architectural erosion involves
architectural design decisions that are applied
directly to a system’s descriptive architecture, and
that violate design decisions captured by the system’s
prescriptive architecture.
© Malek
13
Architectural Recovery
If drift or erosion are allowed to occur, the
development organization is likely to be
forced to recover the system’s architecture
sooner or later.
Definition. Architectural recovery is the
process of determining a software system’s
architecture from its implementation-level
artifacts.
Implementation-level artifacts can be
Source code
Executable files
Java .class files
© Malek
14
Implementation-Level
View of an Application
© Malek
15
Software Architecture’s
Elements
A software system’s architecture
typically is not (and should not be) a
uniform monolith
A software system’s architecture should
be a composition and interplay of
different elements
Processing
Data, also referred as information or state
Interaction
© Malek
16
Component
Elements that encapsulate processing and
data in a system’s architecture are referred
to as software components.
Definition. A software component is an
architectural building block that encapsulates
a subset of the system’s functionality and/or
data, and restricts access to them via an
explicitly defined interface.
© Malek
17
Connector
In complex systems interaction might become
more important and challenging than the
functionality of the individual components.
Definition. A software connector is an
architectural building block tasked with
regulating interactions among components.
In traditional, desktop software systems,
connectors would have usually manifested
themselves as simple procedure calls or
shared data accesses.
© Malek
18
Multiple Connectors in a Single System
METHOD
CALL
ADT OP
ACCESS
P IPE
REAL-TIME
DATA
STREAM
P IPE
D ATABASE
A CCESS
I MPLICIT
I NVOCATION
© Malek
19
Software Connectors
Architectural element that models
Interactions among components
Rules that govern those interactions
Simple interactions
Procedure calls
Shared variable access
Complex & semantically rich interactions
Client-server protocols
Database access protocols
Asynchronous event multicast
Each connector provides
Interaction duct(s)
Transfer of control and/or data
© Malek
20
Implemented vs. Conceptual Connectors
Connectors in software system implementations
Frequently no dedicated code
Frequently no identity
Typically do not correspond to compilation units
Distributed implementation
• Across multiple modules
• Across interaction mechanisms
Connectors in software architectures
First-class entities
Have identity
Describe all system interaction
Entitled to their own specifications & abstractions
© Malek
21
Reasons for Treating Connectors
Independently
Connector  Component
Components provide application-specific functionality
Connectors provide application-independent interaction
mechanisms
Interaction abstraction and/or parameterization
Specification of complex interactions
Binary vs. N-ary
Asymmetric vs. Symmetric
Interaction protocols
Localization of interaction definition
Extra-component system (interaction) information
Component independence
Component interaction flexibility
© Malek
22
Benefits of First-Class
Connectors
Separate computation from interaction
Minimize component interdependencies
Support software evolution
At component-, connector-, & system-level
Potential for supporting dynamism
Facilitate heterogeneity
Become points of distribution
Aid system analysis & testing
© Malek
23
Software Connector Roles
Locus of interaction among set of components
Protocol specification (sometimes implicit) that
defines its properties
Types of interfaces it is able to mediate
Assurances about interaction properties
Rules about interaction ordering
Interaction commitments (e.g., performance)
Roles
Communication
Coordination
Conversion
Facilitation
© Malek
24
Connectors as Communicators
Main role associated with connectors
Supports
Different communication mechanisms
• e.g. procedure call, RPC, shared data access, message
passing
Constraints on communication structure/direction
• e.g. pipes
Constraints on quality of service
• e.g. persistence
Separates communication from computation
May influence non-functional system
characteristics
e.g. performance, scalability, security
© Malek
25
Connectors as Coordinators
Determine computation control
Control delivery of data
Separates control from computation
Orthogonal to communication,
conversion, & facilitation
Elements of control are in communication,
conversion & facilitation
© Malek
26
Connectors as Converters
Enable interaction of independently developed,
mismatched components
Mismatches based on interaction
Type
Number
Frequency
Order
Examples of converters
Adaptors
Wrappers
© Malek
27
Connectors as Facilitators
Enable interaction of components intended to
interoperate
Mediate & streamline interaction
Govern access to shared information
Ensure proper performance profiles
e.g., load balancing
Provide synchronization mechanisms
Critical sections
Monitors
© Malek
28
Configuration
Components and connectors are composed in a
specific way in a given system’s architecture
to accomplish that system’s objective.
Definition. Architectural configurations, or
topologies, capture architectural structure via
graphs whose nodes represent components
and connectors, and whose edges represent
their interconnectivity.
© Malek
29
An Example Configuration
© Malek
30
Architectural Models, Views, and
Visualizations
Architecture Model
An artifact documenting some or all of the
architectural design decisions about a system.
Architecture Visualization
A way of depicting some or all of the architectural
design decisions about a system to a stakeholder.
Architecture View
A subset of related architectural design decisions.
© Malek
31
Architectural Style
An architectural style is a named set of
constraints (e.g., rules) you put on your
development
Constraints may be topological, behavioral,
communication-oriented, you name it
VS.
© Malek, 2008
32
Basic Properties of Styles
A vocabulary of design elements
Component and connector types
e.g., pipes, filters, objects, servers
A set of configuration rules
Topological constraints that determine allowed compositions of
elements
e.g., a component may be connected to at most two other
components
A semantic interpretation
Compositions of design elements have well-defined meanings
© Malek, 2008
33
Different Aspects of Styles
What is the design vocabulary?
Component and connector types
What are the allowable structural patterns?
What is the underlying computational model?
What are the essential invariants of the
style?
What are common examples of its use?
What are the (dis)advantages of using the
style?
What are the style’s specializations?
© Malek, 2008
34
Some Common Styles
“Basic” styles
Pipe and filter
Object-oriented
Layered
Blackboard
State transition
Client-server
• Many flavors
Peer-to-peer
Event-based (a.k.a. Implicit invocation)
Push-based
“Derived” styles
GenVoca
C2
© Malek, 2008
35
Pipe and Filter Style
Components are filters
Transform input data streams into output data streams
Possibly incremental production of output
Connectors are pipes
Conduits for data streams
Input
Medium
Input
Circular
Shift
Alphabetizer
Output
Output
Medium
Style invariants
Filters are independent (no shared state)
Filter has no knowledge of up- and down-stream filters
Examples
UNIX shell
Distributed systems
signal processing
parallel programming
© Malek, 2008
36
Pipe and Filter (cont.)
Variations
Pipelines — linear sequences of filters
Bounded pipes — limited amount of data on a pipe
Typed pipes — data strongly typed
Batch sequential — data streams are not incremental
Advantages
System behavior is a succession of component behaviors
Filter addition, replacement, and reuse
• Possible to hook any two filters together
Certain analyses
• Throughput, latency, deadlock
Concurrent execution
Disadvantages
Batch organization of processing
Interactive applications
Lowest common denominator on data transmission
© Malek, 2008
37
Object-Oriented Style
Components are objects
Data and associated operations
Connectors are messages and method invocations
Style invariants
Objects are responsible for their internal representation
integrity
Internal representation is hidden from other objects
Advantages
“Infinite malleability” of object internals
System decomposition into sets of interacting agents
Disadvantages
Objects must know identities of servers
Often very tightly coupled systems
© Malek, 2008
38
Layered Style
Hierarchical system organization
“Multi-level client-server”
Each layer exports an “API” to be used by
above layers
L1
L2
L3
Each layer acts as a
Server: service provider to layers “above”
Client: service consumer from layers “below”
L1
Connectors are protocols of layer
L2
interaction
Example: operating systems
L1
L2
L3
L3
Virtual machine style results from fully
opaque layers
© Malek, 2008
39
Layered Style (cont.)
Advantages
Increasing abstraction levels
Evolvability
Changes in a layer affect at most the adjacent two layers
• Reuse
Different implementations of layer are allowed as long as
interface is preserved
Standardized layer interfaces for libraries and frameworks
Disadvantages
Not universally applicable
Performance
Layers may have to be skipped
Determining the correct abstraction level
© Malek, 2008
40
Blackboard Style
Two kinds of components
Central data structure — blackboard
Components operating on the blackboard
System control is entirely driven by the blackboard state
Examples
Typically used for AI systems
Integrated software environments (e.g., Interlisp)
Compiler architecture
Lexer
Parser
Semantor
BLACKBOARD
© Malek, 2008
41
Client-Server Style
Instance of a more general style
Distributed systems
Components are clients and servers
Servers do not know number or identities of
clients
Clients know server’s identity
Connectors are point-to-point interaction
protocols
A number of different flavors of clientserver
© Malek, 2008
42
Peer-to-Peer Style
Similar to Client-Server
Point-to-point communication between
components
There is no distinction between a client
and server
i.e., a client can also be a server
It is almost a “null” style
Not that many constraints
© Malek, 2008
43
Implicit Invocation Style
Event announcement instead of method invocation
“Listeners” register interest in & associate methods with
events
System invokes all registered methods implicitly
Component interfaces are methods and events
Two types of connectors
Invocation is either explicit or implicit in response to events
Style invariants
“Announcers” are unaware of their events’ effects, if any
No assumption about processing in response to events
© Malek, 2008
44
Implicit Invocation (cont.)
Advantages
Component reuse
System evolution
• Both at system construction-time & run-time
Disadvantages
Counter-intuitive system structure
Components relinquish computation control to the
system
No knowledge of what components will respond to
event
No knowledge of order of responses
© Malek, 2008
45
Push-Based Style
Specialization of this style is the Publish-Subscribe style
Distinguished from pull-based (e.g., the Web)
Consumer
Request
Producer
Reply
Subscribe
Consumer
Receive
Push
Infrastructure
Unsubscribe
Announce
Producer
Publish
Examples
employee information systems
maintenance manuals
stock ticker
© Malek, 2008
46
Push-Based Style (cont.)
“Components”
Producer
Receiver
Channel
Broadcaster
Transport system
• Repeater, cache, proxy
• Transparent to all other components
Asymmetric communication model
Producers/Receivers
More receivers than producers
© Malek, 2008
47
The C2 Style
Topological Constraints
All components, connectors have two interfaces,
“top” and “bottom”
Components can be connected to 0-1 connector on
each interface
Connectors can be connected to 0+ components or
connectors on each interface
top
top
Component
bottom
Connector
bottom
© Malek, 2008
48
The C2 Style
Communication Constraints
• Requests go up (“requests rise”)
• Notifications go down
• No passing pointers
Data
Store
GUI
Interpreter
Alarm
© Malek, 2008
GUI
Requests
Components & connectors
communicate asynchronously
• Can send/receive events at any
time
• No blocking!
Notifications
Components & connectors
communicate using only
independent events or messages
49
The C2 Style
Dependency Constraints
Components may make assumptions about services
provided above them
• But not who is providing them
Components may NOT make assumptions about
services provided below them
© Malek, 2008
50
C2 Example
Data
Store
GUI
Interpreter
Alarm
GUI
© Malek, 2008
51
C2 Example
Stores data; emits
notifications whenever
data changes.
Data
Store
GUI
Interpreter
Alarm
GUI
© Malek, 2008
52
C2 Example
Data
Store
GUI
Interpreter
Interprets basic GUI
actions & translates them
into data store operations
Alarm
GUI
© Malek, 2008
53
C2 Example
Rings a bell whenever
value of X changes
Data
Store
GUI
Interpreter
Alarm
GUI
© Malek, 2008
54
C2 Example
Data
Store
GUI
Interpreter
Accept & process
user
actions
Alarm
GUI
© Malek, 2008
55
C2 Example
Data
Store
GUI
Interpreter
Connector
routes
Alarm
messages: requests are
broadcasted up,
notifications are
broadcasted down
GUI
© Malek, 2008
56
What ilities does C2 buy us?
Flexibility and Adaptability
Loose coupling lets you swap out components, interpose
components
Flexible connectors allow run-time changes
Distributability
Since no assumption of shared address space, distributing an
app across machines is easy
Event routing is determined by the configuration of the
architecture
Visibility
Since all messages go through connectors, they are easy to
catch and log
Parallelizability
Since the same event is delivered to multiple components in a
given layer
© Malek, 2008
57
Heterogeneous Styles
FIFO
Queue
t12
s1
t23
s2 t32
Proc
s3 Calls
t31
L1
L2
L3
Subscribe
I/I
BLACKBOARD
© Malek, 2008
Push
58
General Benefits of Using Styles
Design reuse
Well-understood solutions applied to new problems
Code reuse
Shared implementations of invariant aspects of a style
Understandability of system organization
A phrase such as “client-server” conveys a lot of information
Interoperability
Supported by style standardization
Style-specific analyses
Enabled by the constrained design space
Visualizations
Style-specific depictions matching engineers’ mental models
© Malek, 2008
59
The impact of style on software
qualities
In general, styles could have a significant
impact on the properties of a software
system:
Performance
Scalability
Modifiability/Adaptability
Visibility
Portability
Reliability
Simplicity
© Malek, 2008
60
Style Comparison (from Fielding’s paper)
© Malek, 2008
61
Observations
Different styles often result in
Different architectures
Architectures with greatly differing properties
A style does not fully influence resulting architecture
A single style can result in different architectures
Considerable room for
• Individual judgment
• Variations among architects
• Different emphases
– e.g., Imposed by customer
© Malek, 2008
62