Transcript Architectural Styles

Designing
Architectures
Software Architecture
Chapter-4
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
How Do You Design?
Where do architectures come from?
Creativity
1)
2)
3)
4)
Fun!
Fraught with peril
May be unnecessary
May yield the best
1)
2)
3)
4)
Efficient in familiar terrain
Not always successful
Predictable outcome (+ & - )
Quality of methods varies
Method
2
Software Architecture: Foundations, Theory, and Practice
Objectives



Creativity
 Enhance your skill set
 Provide new tools
Method
 Focus on highly effective techniques
Develop judgment: when to develop novel (original)
solutions, and when to follow established method
3
Software Architecture: Foundations, Theory, and Practice
Engineering Design Process




Feasibility stage: identifying a set of feasible concepts
for the design as a whole
Preliminary design stage: selection and development
of the best concept.
Detailed design stage: development of engineering
descriptions of the concept.
Planning stage: evaluating and altering the concept to
suit the requirements of production, distribution,
consumption and product retirement.
4
Software Architecture: Foundations, Theory, and Practice
Potential Problems




If the designer is unable to produce a set of feasible
concepts, progress stops.
As problems and products increase in size and
complexity, the probability that any one individual can
successfully perform the first steps decreases.
The standard approach does not directly address the
situation where system design is at stake, i.e. when
relationship between a set of products is at issue.
As complexity increases or the experience of the
designer is not sufficient, alternative approaches to the
design process must be adopted.
5
Software Architecture: Foundations, Theory, and Practice
Alternative Design Strategies





Standard
 Linear model described above
Cyclic
 Process can revert (go back) to an earlier stage
Parallel
 Independent alternatives are explored in parallel
Adaptive (“lay tracks as you go”)
 The next design strategy of the design activity is decided
at the end of a given stage
Incremental
 Each stage of development is treated as a task of
incrementally improving the existing design
6
Software Architecture: Foundations, Theory, and Practice
Identifying a Viable (feasible)
Strategy

Use fundamental design tools: abstraction and
modularity.


Inspiration, where inspiration is needed. Predictable
techniques elsewhere.


But how?
But where is creativity required?
Applying own experience or experience of others.
7
Software Architecture: Foundations, Theory, and Practice
The Tools of “Software
Engineering 101”

Abstraction
 Abstraction(1): look at details, and abstract “up”
to concepts
 Abstraction(2): choose concepts, then add detailed
substructure, and move “down”
 Example: design of a stack class

Separation of concerns
8
Software Architecture: Foundations, Theory, and Practice
A Few Definitions… from the OED
Online




Abstraction: “The act or process of separating in thought, of
considering a thing independently of its associations; or a substance
independently of its attributes; or an attribute or quality
independently of the substance to which it belongs.”
Reification: “The mental conversion of … [an] abstract concept
into a thing.”
Deduction: “The process of drawing a conclusion from a principle
already known or assumed; spec. in Logic, inference by reasoning
from generals to particulars; opposed to INDUCTION.”
Induction: “The process of inferring (concluding) a general law or
principle from the observation of particular instances (opposed to
DEDUCTION, q.v.).”
9
Software Architecture: Foundations, Theory, and Practice
Abstraction and the Simple
Machines



What concepts should be chosen at the outset (start) of
a design task?
 One technique: Search for a “simple machine”
that serves as an abstraction of a potential system
that will perform the required task
 For instance, what kind of simple machine makes a
software system embedded in a fax machine?
 At core, it is basically just a little state machine.
Simple machines provide a plausible (possible) first
conception (idea) of how an application might be built.
Every application domain has its common simple
machines.
10
Software Architecture: Foundations, Theory, and Practice
Simple Machines
Domain
Simple Machines
Graphics
Pixel arrays
Transformation matrices
Widgets
Abstract depiction graphs
Word processing
Structured documents
Layouts
Process control
Finite state machines
Income Tax
Software
Hypertext
Spreadsheets
Form templates
Web pages
Hypertext
Composite documents
Scientific computing
Matrices
Mathematical functions
Banking
Spreadsheets
Databases
Transactions
11
Software Architecture: Foundations, Theory, and Practice
Choosing the Level and Terms of
Discourse (discussion)




Any attempt to use abstraction as a tool must choose a level of
discourse, and once that is chosen, must choose the terms of
discourse.
Alternative 1: initial level of discourse is one of the application as
a whole (step-wise refinement).
Alternative 2: work, initially, at a level lower than that of the
whole application.
 Once several such sub-problems are solved they can be
composed together to form an overall solution
Alternative 3: work, initially, at a level above that of the desired
application.
 E.g. handling simple application input with a general parser.
12
Software Architecture: Foundations, Theory, and Practice
Separation of Concerns (matters)





Separation of concerns is the subdivision of a problem
into (hopefully) independent parts.
The difficulties arise when the issues are either actually
or apparently intertwined (entangled).
Separations of concerns frequently involves many
tradeoffs
Total independence of concepts may not be possible.
Key example from software architecture:
separation of components (computation) from
connectors (communication)
13
Software Architecture: Foundations, Theory, and Practice
The Grand Tool: Refined
(developed)Experience




Experience must be reflected upon and refined.
The lessons from prior work include not only the lessons
of successes, but also the lessons arising from failure.
Learn from success and failure of other engineers
 Literature
 Conferences
Experience can provide that initial feasible set of
“alternative arrangements for the design as a whole”.
14
Software Architecture: Foundations, Theory, and Practice
Patterns, Styles, and DSSAs
15
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Domain-Specific Software
Architectures



A DSSA is an assemblage of software components
 specialized for a particular type of task (domain),
 generalized for effective use across that domain, and
 composed in a standardized structure (topology) effective
for building successful applications.
Since DSSAs are specialized for a particular domain they are
only of value if one exists for the domain wherein the
engineer is tasked with building a new application.
DSSAs are the pre-eminent (greatest) means for maximal
reuse of knowledge and prior development and hence for
developing a new architectural design.
16
Software Architecture: Foundations, Theory, and Practice
Architectural Patterns


An architectural pattern is a set of architectural design
decisions that are applicable to a recurring (returning)
design problem, and parameterized to account for
different software development contexts in which that
problem appears.
Architectural patterns are similar to DSSAs but applied
“at a lower level” and within a much narrower scope.
17
Software Architecture: Foundations, Theory, and Practice
State-Logic-Display: Three-Tiered
Pattern

Application Examples
 Business applications
 Multi-player games
 Web-based applications
18
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Model-View-Controller (MVC)



Objective: Separation between information,
presentation and user interaction.
When a model object value changes, a notification is
sent to the view and to the controller. So that the view
can update itself and the controller can modify the view
if its logic so requires.
When handling input from the user the windowing
system sends the user event to the controller; If a
change is required, the controller updates the model
object.
19
Software Architecture: Foundations, Theory, and Practice
Model-View-Controller
20
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Sense-Compute-Control
Objective: Structuring embedded control applications
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
21
Software Architecture: Foundations, Theory, and Practice
The Lunar Lander: A Long-Running
Example


A simple computer game that first appeared in the
1960’s
Simple concept:
 You (the pilot) control the descent rate of the
Apollo-era Lunar Lander (LL)
 Throttle setting controls descent engine
 Limited fuel
 Initial altitude and speed preset
 If you land with a descent rate of < 5 fps: you
win (whether there’s fuel left or not)
 “Advanced” version: joystick controls attitude &
horizontal motion
22
Software Architecture: Foundations, Theory, and Practice
Sense-Compute-Control LL
23
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Architectural Styles





An architectural style is a named collection of architectural
design decisions that
 are applicable in a given development context
 constrain architectural design decisions that are specific
to a particular system within that context
 elicit beneficial qualities in each resulting system
A primary way of characterizing lessons from experience in
software system design
Reflect less domain specificity than architectural patterns
Useful in determining everything from subroutine structure to
top-level application structure
Many styles exist and we will discuss them in detail in the
next lecture
24
Software Architecture: Foundations, Theory, and Practice
Definitions of Architectural Style



Definition. An architectural style is a named collection of
architectural design decisions that
 are applicable in a given development context
 constrain architectural design decisions that are specific
to a particular system within that context
 elicit beneficial qualities in each resulting system.
Recurring organizational patterns & idioms
 Established, shared understanding of common design
forms
 Mark of mature engineering field.
 Shaw & Garlan
Abstraction of recurring composition & interaction
characteristics in a set of architectures
25
 Taylor
Software Architecture: Foundations, Theory, and Practice
Basic Properties of Styles




A vocabulary of design elements
 Component and connector types; data elements
 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
Possible analyses of systems built in a style
26
Software Architecture: Foundations, Theory, and Practice
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 analysis
 Enabled by the constrained design space
Visualizations
 Style-specific depictions matching engineers’ mental models
27
Software Architecture: Foundations, Theory, and Practice
Style Analysis Dimensions







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?
28
Software Architecture: Foundations, Theory, and Practice
Some Common Styles

Traditional- Language
Influenced Styles




Data-flow Styles



Virtual machines
Client-server
Batch sequential
Pipe and filter
Shared Memory Styles


Interpreter Styles



Layered Styles


Main program and
subroutines
Object-oriented

Implicit Invocation Styles




Interpreter
Mobile code
Event-based
Publish-subscribe
Peer-to-Peer Styles
“Derived” Styles


C2
CORBA
Blackboard
Rule based
29
Traditional,
Language-influenced Styles
Main-program & Sub-program
Object Oriented
The styles are discussed with a
common running example of LUNAR
LANDER (LL) application
30
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Main Program and Subroutines LL
Main program displays greetings and instructions, then
enters a loop in which it calls the three subroutines in turn.
31
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Main Program and Subroutines
32
Software Architecture: Foundations, Theory, and Practice
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 (flexibility)” of object internals
 System decomposition into sets of interacting agents
Disadvantages
 Objects must know identities of servers
33
Software Architecture: Foundations, Theory, and Practice
Object-Oriented LL
The object-oriented design of the Lunar Lander game has three
encapsulations: the spacecraft, the user’s interface, and the
environment (essentially a physics model that allows calculation of
the descent rate)
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
34
Software Architecture: Foundations, Theory, and Practice
OO/LL in UML
Some details of the object-oriented design
are apparent in figure which is a Unified
Modelling Language characterization of the
objects.
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
35
Layered Style
Virtual Machine
Client - Sever
36
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Layered Style





Hierarchical system organization
 “Multi-level client-server”
 Each layer exposes an interface (API) to be used by
above layers
Each layer acts as a
 Server: service provider to layers “above”
 Client: service consumer of layer(s) “below”
Connectors are protocols of layer interaction
Example: Operating Systems
Virtual Machine Style results from fully opaque (unclear)
layers
37
Software Architecture: Foundations, Theory, and Practice
Layered Style (cont’d)

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
38
Software Architecture: Foundations, Theory, and Practice
Layered Style (cont’d)


Disadvantages
 Not universally applicable
 Performance
Layers may have to be skipped
39
Software Architecture: Foundations, Theory, and Practice
Layered Systems/Virtual Machines
40
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Layered LL
A five-level version of
the lunar lander game is
shown in Figure 4-11.
The top layer handles
inputs received from the
user through the
keyboard; it calls the
second layer to service
those inputs,
41
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Layered LL
The second layer
includes all the details of
the lunar lander that
pertain to the game logic
and the environment
simulator.
It calls the third layer to
begin the process of
displaying the updated
Lander state to the user.
42
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Layered LL
The third layer is a
generic, two-dimensional
game engine.
Such a layer is capable of
supporting any of a wide
variety of games that
only require twodimensional graphics.
The fourth layer is the
operating system, which
provides, among other
things, platform-specific
user interface (UI)
support.
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
43
Software Architecture: Foundations, Theory, and Practice
Layered LL
The bottom layer is
provided by firmware or
hardware, and
44
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Client-Server Style






A kind of two layer virtual machine style with network
connections
Server is a virtual machine that is below the Client
Components are clients and servers
Servers do not know number or identities of clients
Clients know server’s identity
Connectors are RPC-based network interaction
protocols
45
Software Architecture: Foundations, Theory, and Practice
Client-Server LL
46
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Client-Server LL





In the system shown, three players simultaneously and
independently play the game.
All game state, game logic, and environment simulation
is performed on the server.
The clients perform the user interface functions.
The connectors in this example are Remote Procedure
Calls (RPC), which are procedure call connectors
combined with a distributor,
A distributor identifies network interaction paths and
subsequently routes communication along those paths.
47
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Data-Flow Styles
Batch-Sequential
Pipe and Filter
48
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Data-Flow Styles
Batch Sequential
 Separate programs are executed in order; data is
passed as an aggregate (collective) from one
program to the next.
 Connectors: “The human hand” carrying tapes
between the programs, a.k.a. “sneaker-net ”
 Data Elements: Explicit, aggregate elements passed
from one component to the next upon completion of
the producing program’s execution.
 Typical uses: Transaction processing in financial
systems.
49
Software Architecture: Foundations, Theory, and Practice
Batch-Sequential: A Financial
Application
50
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Batch-Sequential LL
This is obviously not a highly interactive, real-time game!
Each functional processing step of the game is performed by a separate
program.
Upon performing the step’s function, the program produces an updated version
of the game state, which is then handed off to the next program in the process.
After the final step of displaying the game state is performed, the produced tape
is carried back to the first program for another pass.
51
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
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
Style invariants
 Filters are independent (no shared state)
 Filter has no knowledge of up- or down-stream filters
Examples

UNIX shell
signal processing

Distributed systems
parallel programming
Example: ls invoices | grep -e August | sort
52
Software Architecture: Foundations, Theory, and Practice
Pipe and Filter (cont’d)

Variations
 Pipelines — linear sequences of filters
 Bounded pipes — limited amount of data on a pipe
 Typed pipes — data strongly typed
53
Software Architecture: Foundations, Theory, and Practice
Pipe and Filter (cont’d)

Advantages

Intermediate files unnecessary, but possible. File system
clutter is avoided and concurrent execution is made possible.

Flexibility by filter exchange. It is easy to exchange one filter
element for another with the same interfaces and functionality.

Flexibility by recombination. It is not difficult to reconfigure a
pipeline to include new filters or perhaps to use the same filters
in a different sequence.
54
Software Architecture: Foundations, Theory, and Practice
Pipe and Filter (cont’d)

Reuse of filter elements. The ease of filter recombination
encourages filter reuse. Small, active filter elements are normally
easy to reuse if the environment makes them easy to connect.

Rapid prototyping of pipelines. Flexibility of exchange and
recombination and ease of reuse enables the rapid creation of
prototype systems.

Efficiency by parallel processing. Since active filters run in
separate processes or threads, pipes-and-filters systems can
take advantage of a multiprocessor.
55
Software Architecture: Foundations, Theory, and Practice
Pipe and Filter (cont’d)

Disadvantages

Sharing state information is expensive or inflexible. The
information must be encoded, transmitted, and then decoded.

Efficiency gain by parallel processing is often an
illusion. The costs of data transfer, synchronization, and context
switching may be high.

Data transformation overhead. The use of a single data
channel between filters often means that much transformation of
data must occur, for example, translation of numbers between
binary and character formats.

Error handling. It is often difficult to detect errors in pipes-andfilters systems. Recovering from errors is even more difficult.
56
Software Architecture: Foundations, Theory, and Practice
Pipe and Filter LL
•
GetBurnRate runs continuously on its own, prompting the
user for a new burn rate.
• In this design the Compute new values determines how
much time has passed.
57
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Shared memory
Blackboard
Rule-based
58
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
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
See other PPT file for more …
* Interlisp was a popular Lisp development tool for AI researchers
59
Software Architecture: Foundations, Theory, and Practice
Blackboard LL
A single connector regulates access from the various experts in manipulating
the information on the blackboard.
The blackboard maintains the game state; the experts perform the
independent tasks of (1) updating the descent engine burn rate based upon input
from the user, (2) displaying to the user the current state of the spacecraft and
any other aspect of the game state, and (3) updating the game state based upon
a time and physics model.
60
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Rule-Based Style
Inference engine parses user input and determines
whether it is a fact/rule or a query. If it is a fact/rule, it
adds this entry to the knowledge base. Otherwise, it
queries the knowledge base for applicable rules and
attempts to resolve the query.
61
Software Architecture: Foundations, Theory, and Practice
Rule-Based Style (cont’d)





Components: User interface, inference engine,
knowledge base
Connectors: Components are tightly interconnected,
with direct procedure calls and/or shared memory.
Data Elements: Facts and queries
Behavior of the application can be very easily modified
through addition or deletion of rules from the knowledge
base.
Caution: When a large number of rules are involved
understanding the interactions between multiple rules
affected by the same facts can become very difficult.
62
Software Architecture: Foundations, Theory, and Practice
Rule Based LL
With regard to the user interaction model,
the user enters the value of burn rate as a
fact:
burnrate(25)
To see what the status of the spacecraft is,
the user can switch to the goal mode and
asks whether the spacecraft has landed
safely:
landed (spacecraft)
To handle this query, the inference engine
queries the database, If the existing facts
and other production rules satisfy the
conditions “altitude <= 0” and “velocity <
3 ft/s,” then the engine returns true to the
user interface. Otherwise, it returns false
63
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Interpreter Style
Basic Interpreter
Mobile Code
64
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Interpreter Style




Interpreter parses and executes input commands,
updating the state maintained by the interpreter
Components: Command interpreter, program/interpreter
state, user interface.
Connectors: Typically very closely bound with direct
procedure calls and shared state.
Highly dynamic behavior possible, where the set of
commands is dynamically modified. System architecture
may remain constant while new capabilities are created
based upon existing primitives.
Superb for end-user programmability; supports
dynamically changing set of capabilities
65
Software Architecture: Foundations, Theory, and Practice
Interpreter Style

Care should be taken to make the interpreter as
flexible as possible, so that the implementation can
be changed at later stages without having tight
coupling.

Other advantage of Interpreter is that you can have
more than one interpreter for the same output and
create the object of interpreter based on the input
66
Software Architecture: Foundations, Theory, and Practice
Interpreter LL
•When the user enters “BurnRate(50),”
the interpreter takes BurnRate as the
command and the parameter as the
amount of fuel to burn.
•It then calculates the necessary
updates to the altitude, fuel level, and
velocity.
•Time is simulated by having t
incremented each occasion the user
enters a BurnRate command.
•When the user enters the CheckStatus
command, the user receives the current
state of altitude, fuel, time, and
velocity.
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
67
Software Architecture: Foundations, Theory, and Practice
Mobile-Code Style



It enable code to be transmitted to a remote host for
interpretation.
This may be due to a lack of local computing power,
lack of resources, or due to large data sets remotely
located.
Mobile code may be classified as:  code on demand,
 remote evaluation, or
 mobile agent
depending on where the code is being transmitted, who
requested the transmission, and where the program
68
state resides.
Software Architecture: Foundations, Theory, and Practice
Mobile-Code Style



Code on demand is when the initiator has resources
and state but downloads code from another site to be
executed locally,
Remote evaluation is when the initiator has the code
but lacks the resources (such as the interpreter) to
execute the code, Thus, it transmits code to be
processed at a remote host, such as in grid computing.
Results are returned to the initiator.
Mobile agent is when the initiator has the code and the
state but some of resources are located elsewhere. Thus
the initiator moves to a remote host with the code, the
state, and some of the resources. Processing need not
return to the initiator.
69
Software Architecture: Foundations, Theory, and Practice
Mobile-Code Style





Summary: a data element (some representation of a
program) is dynamically transformed into a data
processing component.
Components: “Execution dock”, which handles receipt
of code and state; code compiler/interpreter
Connectors: Network protocols and elements for
packaging code and data for transmission.
Data Elements: Representations of code as data;
program state
Variants: Code-on-demand, remote evaluation, and
mobile agent.
70
Software Architecture: Foundations, Theory, and Practice
Mobile
Code LL
One client Web browser
downloads code-ondemand in the form of a
Lunar Lander game applet
via HTTP.
A second browser loads a
JavaScript Lunar Lander;
a third uses some other
form that is not detailed.
71
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Mobile Code LL
•Here, all the game logic moves to the client
machines, freeing the server’s computing resources.
•In the figure as shown, each client machine
maintains the game state independently of other
clients.
72
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Implicit Invocation
Publish-Subscribe
Event-Based
Peer-to-Peer
73
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Implicit Invocation Style

Such styles are characterized by calls that are invoked
(called up) indirectly and implicitly (unconditionally) as a
response to a notification or an event

Ease of adaptation and enhanced scalability are benefits
of the indirect interaction between very loosely coupled
components.
74
Software Architecture: Foundations, Theory, and Practice
Implicit Invocation Style




Event announcement instead of method invocation
 “Listeners” register interest in and 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
 No assumption about processing in response to events
75
Software Architecture: Foundations, Theory, and Practice
Implicit Invocation (cont’d)


Advantages
 Component reuse
 System evolution
 Both at system construction-time & run-time
Disadvantages
 No knowledge of what components will respond to
event
 No knowledge of order of responses
76
Software Architecture: Foundations, Theory, and Practice
Publish-Subscribe

Subscribers register/de-register to receive specific
messages or specific content.

Publishers broadcast messages to subscribers either
synchronously or asynchronously.
77
Software Architecture: Foundations, Theory, and Practice
Publish-Subscribe (cont’d)





Components: Publishers, subscribers, proxies for managing
distribution
Connectors: Typically a network protocol is required.
Content-based subscription requires sophisticated connectors.
Data Elements: Subscriptions, notifications, published
information
Topology: Subscribers connect to publishers either directly
or may receive notifications via a network protocol from
intermediaries
Qualities yielded Highly efficient one-way dissemination
(broadcast) of information with very low-coupling of
components
78
Software Architecture: Foundations, Theory, and Practice
Pub-Sub LL
79
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Pub-Sub LL



In the example, the lunar lander software is deployed to
various network hosts.
Players, who are the subscribers, register their hosts to
a game server that publishes information, such as: new Lunar terrain data, new spacecraft, and the
(Lunar) locations of all the registered spacecraft
currently playing the game.
Once registered, the subscribed hosts receive
notifications when any of the information they have
registered for has been updated.
80
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Event-Based Style







Independent components asynchronously emit and receive
events communicated over event buses
Components: Independent, concurrent event generators
and/or consumers
Connectors: Event buses (at least one)
Data Elements: Events – data sent as a first-class entity
over the event bus
Topology: Components communicate with the event buses,
not directly to each other.
Variants: Component communication with the event bus
may either be push or pull based.
Highly scalable, easy to evolve, effective for highly distributed
applications.
81
Software Architecture: Foundations, Theory, and Practice
Event-based LL
82
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Event-based LL



The clock component drives the game. Every fraction
of a second, the clock component sends out a tick
notification to the event bus, which distributes that event
to the other components.
The spacecraft component maintains the state of the
spacecraft (its altitude, fuel level, velocity, and throttle
setting).
Upon receiving a predefined number of notifications
from the clock, the spacecraft component recalculates
the altitude, fuel level, and velocity (corresponding to
simulated flight for that number of ticks) and then emits
those values to the event bus.
83
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Event-based LL




GUI component drives the game player’s display.
Receipt of events providing the spacecraft’s altitude,
fuel, and velocity causes the GUI component to update
its display based on those values.
The GUI component also obtains new burn rate settings
from the user; when this happens the component emits
a notification of this new value onto the event bus.
The game logic component, receiving both
information about the state of the spacecraft and the
amount of time that has passed (by counting clock
ticks), determines the player’s score.
84
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Peer-to-Peer (P2P) Style






This architectural style consists of a network of
loosely coupled autonomous peers (nodes) which can
act as either clients or servers
Peers communicate using a network protocol.
Unlike the client-server style where state and logic
are centralized on the server, P2P decentralizes both
information and control.
Peers: independent components, having their own
state and control thread.
Connectors: Network protocols, often custom.
Data Elements: Network messages
85
Software Architecture: Foundations, Theory, and Practice
Peer-to-Peer Style (cont’d)

Topology: Network (may have redundant
connections between peers); can vary arbitrarily and
dynamically

Supports decentralized computing with flow of
control and resources distributed among peers.

Highly robust (strong) in the face of failure of any
given node. Scalable in terms of access to resources
and computing power.
86
Software Architecture: Foundations, Theory, and Practice
Peer-to-Peer LL
In the example of Figure, a
group of lunar lander spacecraft
are on their way to land in
different parts of the moon.
Multiple Landers are used in
this example to highlight that
the P2P architectural style is
designed to support interaction
between highly autonomous
components.
87
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Peer-to-Peer LL
Lunar Lander 1 (LL1) wants to
find out if another spacecraft has
already landed in a specific area,
so that collisions can be avoided.
Each of the spacecraft is
configured to communicate with
the others using a P2P protocol
over a network.
A spacecraft will only be able to
communicate with others that are
within a specified, limited
distance.
88
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
More Complex
Styles
Copyright © Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy. All rights reserved.
Software Architecture: Foundations, Theory, and Practice
Heterogeneous Styles




More complex styles created through composition of
simpler styles
REST
 Complex history presented later in course
C2
 Implicit invocation + Layering + other constraints
Distributed Objects
 OO + client-server network style
 CORBA
90
Software Architecture: Foundations, Theory, and Practice
C2 Style
An indirect invocation style in which independent
components communicate exclusively (entirely)
through message routing connectors.
Strict rules on connections between components and
connectors induce layering.
91
Software Architecture: Foundations, Theory, and Practice
C2 Style (cont’d)




Components: Independent, potentially concurrent
message generators and/or consumers
Connectors: Message routers that may filter,
translate, and broadcast messages of two kinds:
notifications and requests.
Data Elements: Messages – data sent as first-class
entities over the connectors. Notification messages
announce changes of state. Request messages
request performance of an action.
Topology: Layers of components and connectors,
with a defined “top” and “bottom”, wherein
notifications flow downwards and requests upwards.
92
Software Architecture: Foundations, Theory, and Practice
C2 LL
93
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
KLAX
94
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
KLAX in
C2
95
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Distributed Objects: CORBA







“Objects” (coarse- or fine-grained) run on heterogeneous hosts,
written in heterogeneous languages. Objects provide services
through well-defined interfaces. Objects invoke methods across
host, process, and language boundaries via remote procedure calls
(RPCs).
Components: Objects (software components exposing services
through well-defined provided interfaces)
Connector: (Remote) Method invocation
Data Elements: Arguments to methods, return values, and
exceptions
Topology: General graph of objects from callers to callees.
Additional constraints imposed: Data passed in remote
procedure calls must be serializable. Callers must deal with
exceptions that can arise due to network or process faults.
Location, platform, and language “transparency”. CAUTION
96
Software Architecture: Foundations, Theory, and Practice
CORBA Concept and
Implementation
97
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
CORBA LL
98
Software Architecture: Foundations, Theory, and Practice; Richard N. Taylor, Nenad Medvidovic, and Eric M. Dashofy; © 2008 John Wiley & Sons, Inc. Reprinted with permission.
Software Architecture: Foundations, Theory, and Practice
Observations



Different styles result in
 Different architectures
 Architectures with greatly differing properties
A style does not fully determine resulting architecture
 A single style can result in different architectures
 Considerable room for
 Individual judgment
 Variations among architects
A style defines domain of discourse
 About problem (domain)
 About resulting system
99
Software Architecture: Foundations, Theory, and Practice
Style Summary (1/4)
Style
Category &
Name
Summary
Use It When
Avoid It When
Application is small and simple.
Complex data structures needed.
Future modifications likely.
Objects encapsulate state
and accessing functions
Close mapping between external
entities and internal objects is
sensible.
Many complex and interrelated
data structures.
Application is distributed in a
heterogeneous network.
Strong independence between
components necessary.
High performance required.
Virtual machine, or a
layer, offers services to
layers above it
Many applications can be based
upon a single, common layer of
services.
Interface service specification
resilient when implementation of
a layer must change.
Centralization of computation
and data at a single location (the
server) promotes manageability
and scalability; end-user
processing limited to data entry
and presentation.
Many levels are required (causes
inefficiency).
Data structures must be accessed
from multiple layers.
Language-influenced styles
Main Program
Main program controls
and
program execution, calling
Subroutines
multiple subroutines.
Object-oriented
Layered
Virtual
Machines
Client-server
Clients request service
from a server
Centrality presents a single-pointof-failure risk; Network bandwidth
limited; Client machine capabilities
rival or exceed the server’s.
100
Software Architecture: Foundations, Theory, and Practice
Style Summary, continued (2/4)
Data-flow styles
Batch
Separate programs
sequential
executed sequentially,
with batched input
Pipe-and-filter
Problem easily formulated as a
set of sequential, severable
steps.
Separate programs, a.k. a.
filters, executed,
pot entially concurr ently.
Pipes route data streams
between filters
[As with batch-sequential] Filters
are useful in mor e than one
application. Data structures
easily serializable.
Blackbo ard
Independent programs,
access and commun icate
exclusively through a
global repository known
as blackbo ard
All calculati on centers on a
common, ch anging data
structure;
Order of processing dynamically
determined and data-driven.
Rule-based
Use facts or rules entered
into the know ledge base
to resolve a query
Problem data and queries
expressible as simple rules over
which inference may be
performed.
Interactivi ty or concurr ency
between compon ents necessary
or desirable.
Random -access to data required.
Interaction between compon ents
required. Exchange of comp lex
data structures between
compon ents required.
Shared memory
Programs deal wi th independent
parts of th e common data.
Interface to common data
susceptible to change. When
interactions between th e
independent programs require
comp lex regulation.
Number of rules is large.
Interaction between rules present.
High-performance required.
101
Software Architecture: Foundations, Theory, and Practice
Style Summary, continued (3/4)
Interpreter
Interpreter
Mobile Code
Interpreter parses and
executes the input stream ,
upd ating the state
maintained by the
interpreter
Highly dynamic behavior
required. High degree of enduser customizability.
High performance required.
Code is mob ile, that is, it
is executed in a remot e
host
When it is more efficient to move
processing to a data set than the
data set to processing.
When it is desirous to
dynamically customize a local
processing nod e through
inclusion of external code
Security of mob ile code cannot be
assured, or sandbo xed.
When tight control of versions of
deployed software is required.
102
Software Architecture: Foundations, Theory, and Practice
Style Summary, continued (4/4)
Implicit Invocation
PublishPublishers broadcast
subscribe
messages to subscribers
Event-based
Peer -to-peer
Independent compon ents
asynchrono usly emit and
receive events
commun icated over event
buses
Peers hold state and
behavior and can act as
both c lients and servers
More complex styles
C2
Layered network of
concurr ent compon ents
commun icating by events
Distributed
Objects
Objects instantiated on
different hosts
Compon ents are very loosely
coup led. Subscription data is
small and efficiently transported.
Compon ents are concurr ent and
independent.
Compon ents heterogeneous and
network -distributed.
When middleware to suppor t highvolume data is unavailable.
Peers are distribut ed in a
network, can be heterogeneous,
and mutu ally independent.
Robust in face of independent
failures.
Highly scalable.
Trustworth iness of independent
peers cannot be assured or
managed.
Resource discovery inefficient
without designated nod es.
When independence from
substrate techno logies required.
Heterogeneous applications.
When support for produc t-lines
desired.
Objective is to preserve illusion
of location-transparency
When high-performance across
many layers required.
When multiple threads are
inefficient.
Guarantees on real -time
processing of events is required.
When high overhead of suppor ting
middleware is excessive. When
network properties are
unm askable, in practical terms.
103
Software Architecture: Foundations, Theory, and Practice
Design Recovery



What happens if a system is already implemented but
has no recorded architecture?
The task of design recovery is
 examining the existing code base
 determining what the system’s components,
connectors, and overall topology are.
A common approach to architectural recovery is
clustering of the implementation-level entities into
architectural elements.
 Syntactic clustering
 Semantic clustering
104
Software Architecture: Foundations, Theory, and Practice
Syntactic Clustering




Focuses exclusively on the static relationships among
code-level entities
Can be performed without executing the system
Embodies inter-component (a.k.a. coupling) and intracomponent (a.k.a. cohesion) connectivity
May ignore or misinterpret many subtle relationships,
because dynamic information is missing
105
Software Architecture: Foundations, Theory, and Practice
Semantic Clustering




Includes all aspects of a system’s domain knowledge and
information about the behavioral similarity of its entities.
Requires interpreting the system entities’ meaning, and
possibly executing the system on a representative set of
inputs.
Difficult to automate
May also be difficult to avail oneself of it
106
Software Architecture: Foundations, Theory, and Practice
When There’s No Experience to Go
On…



The first effort a designer should make in addressing a
novel design challenge is to attempt to determine that it
is genuinely a novel problem.
Basic Strategy
 Divergence – shake off inadequate prior approaches
and discover or admit a variety of new ideas
 Transformation – combination of analysis and
selection
 Convergence – selecting and further refining ideas
Repeatedly cycling through the basic steps until a
feasible solution emerges.
107
Software Architecture: Foundations, Theory, and Practice
Analogy Searching



Examine other fields and disciplines unrelated to the
target problem for approaches and ideas that are
analogous to the problem.
Formulate a solution strategy based upon that analogy.
A common “unrelated domain” that has yielded a variety
of solutions is nature, especially the biological sciences.
 E.g., Neural Networks
108
Software Architecture: Foundations, Theory, and Practice
Brainstorming





Technique of rapidly generating a wide set of ideas and
thoughts pertaining to a design problem
 without (initially) devoting effort to assessing the
feasibility.
Brainstorming can be done by an individual or, more
commonly, by a group.
Problem: A brainstorming session can generate a large
number of ideas… all of which might be low-quality.
The chief value of brainstorming is in identifying categories of
possible designs, not any specific design solution suggested
during a session.
After brainstorm the design process may proceed to the
Transformation and Convergence steps.
109
Software Architecture: Foundations, Theory, and Practice
“Literature” Searching




Examining published information to identify material that
can be used to guide or inspire designers
Many historically useful ways of searching “literature”
are available
Digital library collections make searching extraordinarily
faster and more effective
 IEEE Xplore
 ACM Digital Library
 Google Scholar
The availability of free and open-source software adds
special value to this technique.
110
Software Architecture: Foundations, Theory, and Practice
Morphological Charts



The essential idea:
 identify all the primary functions to be performed by the
desired system
 for each function identify a means of performing that
function
 attempt to choose one means for each function such that
the collection of means performs all the required functions
in a compatible manner.
The technique does not demand that the functions be shown
to be independent when starting out.
Sub-solutions to a given problem do not need to be
compatible with all the sub-solutions to other functions in the
beginning.
111
Software Architecture: Foundations, Theory, and Practice
Removing Mental Blocks

If you can’t solve the problem, change the problem to
one you can solve.
 If the new problem is “close enough” to what is
needed, then closure is reached.
 If it is not close enough, the solution to the revised
problem may suggest new venues for attacking the
original.
112
Software Architecture: Foundations, Theory, and Practice
Controlling the Design Strategy





The potentially chaotic (disordered) nature of exploring
diverse approaches to the problem demands that some
care be used in managing the activity
Identify and review critical decisions
Relate the costs of research and design to the penalty
for taking wrong decisions
Insulate uncertain decisions
Continually re-evaluate system “requirements” in light of
what the design exploration yields
113
Software Architecture: Foundations, Theory, and Practice
Insights from Requirements



In many cases new architectures can be created based
upon experience with and improvement to pre-existing
architectures.
Requirements can use a vocabulary of known
architectural choices and therefore reflect experience.
The interaction between past design and new
requirements means that many critical decisions for a
new design can be identified or made as a requirement
114
Software Architecture: Foundations, Theory, and Practice
Insights from Implementation



Constraints on the implementation activity may help
shape the design.
Externally motivated constraints might dictate
 Use of a middleware
 Use of a particular programming language
 Software reuse
Design and implementation may proceed cooperatively
and contemporaneously
 Initial partial implementation activities may yield
critical performance or feasibility information
115