Chapter 7

Implementation and
Deployment
The Mapping Problem
 Implementation is the one phase of software engineering
that is not optional
 Architecture-based development provides a unique twist on
the classic problem
 It becomes, in large measure, a mapping activity

Design
Design Implementation
Implementation
Decisions
Decisions Artifacts
Artifacts

 Maintaining mapping means ensuring that our architectural

intent is reflected in our constructed systems

2
Common Element
Mapping
 Components and Connectors
 Partitions of application computation and
communication functionality
 Modules, packages, libraries, classes,
explicit components/connectors in
middleware
 Interfaces
 Programming-language level interfaces
(e.g., APIs/function or method
signatures) are common
 3
Common Element Mapping
(cont’d)
 Configurations
 Interconnections, references, or dependencies
between functional partitions
 May be implicit in the implementation
 May be externally specified through a MIL and
enabled through middleware
 May involve use of reflection
 Design rationale
 Often does not appear directly in
implementation
 Retained in comments and other documentation
4
Common Element Mapping
(cont’d)
 Dynamic Properties (e.g., behavior):
 Usually translate to algorithms of some sort
 Mapping strategy depends on how the behaviors
are specified and what translations are available
 Some behavioral specifications are more useful
for generating analyses or testing plans
 Non-Functional Properties
 Extremely difficult to do since non-functional
properties are abstract and implementations are
concrete
 Achieved through a combination of human-
centric strategies like inspections, reviews, focus
5
One-Way vs. Round Trip
Mapping
 Architectures inevitably change after implementation
begins
 For maintenance purposes
 Because of time pressures
 Because of new information
 Implementations can be a source of new information
 We learn more about the feasibility of our designs
when we implement
 We also learn how to optimize them

Design
Design Implementation
Implementation
Decisions
Decisions Artifacts
Artifacts

6
One-Way vs. Round Trip
Mapping (cont’d)
 Keepingthe two in sync is a difficult
technical and managerial problem
 Places where strong mappings are not
present are often the first to diverge
 One-way mappings are easier
 Must be able to understand impact on
implementation for an architectural design
decision or change
 Two way mappings require more insight
 Must understand how a change in the
implementation impacts architecture-level
design decisions
7
Architecture Implementation
Frameworks
 Idealapproach: develop architecture
based on a known style, select
technologies that provide OO Class
implementation support for each
architectural element
Design
Design Software
Decisions
Decisions Library

Database

8
Architecture Implementation
Frameworks
 This is rarely easy or trivial
 Few programming languages have
explicit support for architecture-level
constructs
 Support infrastructure (libraries,
operating systems, etc.) also has its own
sets of concepts, metaphors, and rules
 Tomitigate these mismatches, we
leverage an architecture
implementation framework
9
Architecture Implementation
Frameworks
 Definition: An architecture implementation
framework is a piece of software that acts as a
bridge between a particular architectural style and
a set of implementation technologies. It provides
key elements of the architectural style in code, in a
way that assists developers in implementing
systems that conform to the prescriptions
F
and
OO Class
constraints of the style. r
a
m
Design
Design e Software
Decisions
Decisions w Library
o
r
k Database
10
 Canonical Example

 The standard I/O (‘stdio’) framework

in UNIX and other operating systems
 Perhaps the most prevalent framework
in use today
 Style supported: pipe-and-filter
 Implementation technologies supported:
concurrent process-oriented operating
system, (generally) non-concurrent
language like C

11
are Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; ｩ 2008 John Wiley & Sons, Inc. Reprinted with perm
Evaluating Frameworks
 Can draw out some of the qualitative
properties just mentioned
 Platform support
 Target language, operating system, other
technologies
 Fidelity
 How much style-specific support is provided by
the framework?
▪ Many frameworks are more general than one target
style or focus on a subset of the style rules
 How much enforcement is provided?

12
Evaluating Frameworks
(cont’d)
 Matching Assumptions
 Styles impose constraints on the target
architecture/application
 Frameworks can induce constraints as well
▪ E.g., startup order, communication patterns …
 To what extent does the framework make too many (or
too few) assumptions?
 Efficiency
 Frameworks pervade target applications and can
potentially get involved in any interaction
 To what extent does the framework limit its slowdown
and provide help to improve efficiency if possible
(consider buffering in stdio)?

13
Evaluating Frameworks
(cont’d)
 Other quality considerations
 Nearly every other software quality can affect
framework evaluation and selection
▪ Size
▪ Cost
▪ Ease of use
▪ Reliability
▪ Robustness
▪ Availability of source code
▪ Portability
▪ Long-term maintainability and support

14
Middleware and Component
Models
 This may all sound similar to various kinds of
middleware/component frameworks
 CORBA, COM/DCOM, JavaBeans, .NET, Java Message
Service (JMS), etc.
 They are closely related
 Both provide developers with services not available in
the underlying OS/language
 CORBA provides well-defined interfaces, portability,
remote procedure call…
 JavaBeans provides a standardized packaging
framework (the bean) with new kinds of introspection
and binding

15
Middleware and Component
Models (cont’d)
 Indeed,
architecture implementation
frameworks are forms of middleware
 There’s a subtle difference in how they emerge
and develop
 Middleware generally evolves based on a set of
services that the developers want to have
available
▪ E.g., CORBA: Support for language heterogeneity,
network transparency, portability
 Frameworks generally evolve based on a
particular architectural style that developers
want to use
 Why is this important?
16
Middleware and Component
Models (cont’d)
 By focusing on services, middleware developers often
make other decisions that substantially impact architecture
 E.g., in supporting network transparency and language
heterogeneity, CORBA uses RPC
 But is RPC necessary for these services or is it just an
enabling technique?
 In a very real way, middleware induces an architectural
style
 CORBA induces the ‘distributed objects’ style
 JMS induces a distributed implicit invocation style
 Understanding these implications is essential for not
having major problems when the tail wags the dog!

17
Resolving Mismatches

 A style is chosen first, but the middleware selected for

implementation does not support (or contradicts) that style
 A middleware is chosen first (or independently) and has
undue influence on the architectural style used
 Strategies
 Change or adapt the style
 Change the middleware selected
 Develop glue code
 Leverage parts of the middleware
Use the middleware
as the basis for
and ignore others
a framework
 Hide the middleware in components/connectors

18
Hiding Middleware in
Connectors
Comp 1 Architecture Comp 1

(thread)

Async Event RPC

(thread)

Implementation

Comp 2 Comp 2

19
Building a New
Framework
 Occasionally, you need a new framework
 The architectural style in use is novel
 The architectural style is not novel but it is being
implemented on a platform for which no framework
exists
 The architectural style is not novel and frameworks
exist for the target platform, but the existing
frameworks are inadequate
 Good framework development is extremely difficult
 Frameworks pervade nearly every aspect of your
system
 Making changes to frameworks often means changing
the entire system
 A task for experienced developers/architects
20
New Framework
Guidelines
 Understand the target style first
 Enumerate all the rules and constraints
in concrete terms
 Provide example design patterns and
corner cases
 Limit
the framework to the rules and
constraints of the style
 Do not let a particular target
application’s needs creep into the
framework
21
New Framework Guidelines
(cont’d)
 Choose the framework scope
 A framework does not necessarily have to
implement all possible stylistic advantages
(e.g., dynamism or distribution)
 Avoid over-engineering
 Don’t add capabilities simply because they
are clever or “cool”, especially if known
target applications won’t use them
 These often add complexity and reduce
performance
22
New Framework Guidelines
(cont’d)
 Limit overhead for application developers
 Every framework induces some overhead
(classes must inherit from framework base
classes, communication mechanisms limited)
 Try to put as little overhead as possible on
framework users
 Develop strategies and patterns for legacy systems
and components
 Almost every large application will need to
include elements that were not built to work with
a target framework
 Develop strategies for incorporating and
wrapping these
23
Concurrency
 Concurrency is one of the most difficult concerns to
address in implementation
 Introduction of subtle bugs: deadlock, race conditions…
 Another topic on which there are entire books written
 Concurrency is often an architecture-level concern
 Decisions can be made at the architectural level
 Done carefully, much concurrency management can be
embedded into the architecture framework
 Consider our earlier example, or how pipe-and-filter
architectures are made concurrent without direct user
involvement

24
Generative Technologies
 Witha sufficiently detailed architectural
model, various implementation artifacts can
be generated
 Entire system implementations
▪ Requires extremely detailed models including behavioral
specifications
▪ More feasible in domain-specific contexts
 Skeletons or interfaces
▪ With detailed structure and interface specifications
 Compositions (e.g., glue code)
▪ With sufficient data about bindings between two
elements

25
Maintaining Consistency
 Strategies for maintaining one-way or round-trip
mappings
 Create and maintain traceability links from
architectural implementation elements
▪ Explicit links in a database, in architectural
models, in code comments can all help with
consistency checking
 Make the architectural model part of the
implementation
▪ When the model changes, the implementation
adapts automatically
▪ May involve “internal generation”
 Generate some or all of the implementation from
the architecture 26
Recall Pipe-and-Filter

 Components (‘filters’) organized linearly,

communicate through character-stream
‘pipes,’ which are the connectors
 Filters may run concurrently on partial
data
 In general, all input comes in through the
left and all output exits from the right
27
Framework #1: stdio
 Standard I/O framework used in C programming language
 Each process is a filter
 Reads input from standard input (aka ‘stdin’)
 Writes output to standard output (aka ‘stdout’)
▪ Also a third, unbuffered output stream called standard
error (‘stderr’) not considered here
 Low and high level operations
▪ getchar(…), putchar(…) move one character at a time
▪ printf(…) and scanf(…) move and format entire
strings
 Different implementations may vary in details (buffering
strategy, etc.)

28
Evaluating stdio
 Platform support  Matching assumptions
 Available with most, if  Filters are processes
not all, and pipes are implicit.
implementations of C In-process P&F
programming language
applications might
 Operates somewhat
require modifications
differently on OSes with  Efficiency
no concurrency (e.g.,
 Whether filters make
MS-DOS)
 Fidelity maximal use of
 Good support for concurrency is partially
developing P&F up to filter
applications, but no implementations and
restriction that apps partially up to the OS
have to use this style

29
Framework #2: java.io
 Standard I/O framework used in Java
language
 Object-oriented
 Can be used for in-process or inter-process
P&F applications
 All stream classes derive from InputStream or
OutputStream
 Distinguished objects (System.in and System.out)
for writing to process’ standard streams
 Additional capabilities (formatting, buffering)
provided by creating composite streams (e.g., a
Formatting-Buffered-InputStream)
30
Evaluating java.io
 Matching assumptions
 Easy to construct intra- and
 Platform support inter-process P&F
 Available with all Java applications
 Concurrency can be an
implementations on
many platforms issue; many calls are
blocking
 Platform-specific  Efficiency
differences abstracted  Users have fine-grained
away control over, e.g., buffering
 Fidelity  Very high efficiency
 Good support for mechanisms (memory
developing P&F mapped I/O, channels) not
applications, but no available (but are in
restriction that apps java.nio)
have to use this style

31
Recall the C2 Style
 Layered style
with event-based
communication
over two-way
broadcast
buses
 Strict rules on
concurrency,
dependencies,
and so on
 Many frameworks developed for
different languages; focus on two
alternative Java frameworks here

32
 Framework #1: Lightweight C2 Framework

 16 classes, 3000
lines of code
 Components &
connectors
extend abstract
base classes
 Concurrency,
queuing handled
at individual
comp/conn level
 Messages are
request or
notification
objects

33
ware Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; (C) 2008 John Wiley & Sons, Inc. Reprinted with perm
Evaluating Lightweight C2
Framework
 Matching assumptions
 Platform support  Comp/conn main
 Available with all classes must inherit
Java from distinguished
implementations on base classes
many platforms  All messages must
 Fidelity be in dictionary form
 Efficiency
 Assists developers
with many aspects  Lightweight
of C2 but does not framework;
enforce these efficiency may
constraints depend on threading
 Leaves threading and queuing policy
and queuing policies implemented by
up to individual individual elements
34
Framework #2: Flexible C2
Framework

 73 classes, 8500
lines of code
 Uses interfaces
rather than base
classes
 Threading policy
for application
is pluggable
 Message queuing policy
is
also pluggable
35
Framework #2: Flexible C2
Framework

36
Evaluating Flexible C2
Framework
 Platform support  Matching assumptions
 Available with all  Comp/conn main
Java classes must
implementations on implement
many platforms distinguished
 Fidelity interfaces
 Assists developers  Messages can be any
with many aspects serializable object
 Efficiency
of C2 but does not
 User can easily swap
enforce these
out and tune
constraints
threading and queuing
 Provides several
policies without
alternative disturbing remainder
application-wide of application code
37
threading and