CS3773
Software Engineering
Lecture 07
Software Architecture Design
Software Design
Software design transforms software requirements
specification into a description of the solution

–
Architecture design
–
Detail design
algorithms, data structures, etc
Software design should satisfy all the requirements


2
–
Functional requirements
–
Nonfunctional requirements
Software design process is iterative
UTSA CS3773
Decomposition and Modularity
The essence of software design is making decisions about
the logical organization of the software

3

There are different ways of software design

Every design method involves some kind of decomposition
–
Modular decomposition: functional description
–
Data-oriented decomposition: external data structures
–
Event-oriented decomposition: events and states
–
Outside-in design: user inputs
–
Object-oriented design: classes and their interrelationships
UTSA CS3773
Software Architecture
Software architecture is the structure of a software
system – like the blue prints in building architecture

–
Software components
Details (data structure and algorithms) hidden
Services (how they use, are used by, relate to, and interact
with other component) displayed
–
Relationships among the components
Data flows
Control flows
4
UTSA CS3773
Abstraction - I

5
One characterization of progress in software development
has been the regular increase in abstraction levels, i.e., the
conceptual size of software designer's building blocks
UTSA CS3773
Abstraction - II
1950s: software was written in machine language

6
–
Instructions and data were placed individually and explicitly in
the computer's memory
–
Machine code programming problems were solved by adding a
level of abstraction between the program and the machine:

Symbolic Assemblers

Macro Processors
UTSA CS3773
Abstraction - III
Late 1950s: the emerging of the first high-level
programming languages.

–
7
Well understood patterns are created from notations that are
more like mathematics than machine code
 evaluation of arithmetic expressions
 procedure invocation
 loops and conditionals
 followed with higher-levels of abstraction for representing
data (types)
UTSA CS3773
Abstraction - IV
Late 1960s and 1970s: programmers shared an intuition that
good data structure design will ease the development of a
program
This intuition was converted into theories of modularization
and information hiding


–
–
8
Data and related code are encapsulated into modules
Interfaces to modules are made explicit
UTSA CS3773
Software Architecture Design



9
As the size and complexity of software systems increases,
the design problem goes beyond algorithms and data
structures
Designing and specifying the overall system structure
(Software Architecture) emerges as a new kind of
problem
One way to organize a software system is based on the
theory of abstract data types
UTSA CS3773
Software Architecture Issues







10
Organization and global control structure
Protocols of communication, synchronization, and data
access
Assignment of functionality to design elements
Physical distribution
Composition of design elements
Scaling and performance
Selection among design alternatives
UTSA CS3773
Other Architecture Disciplines
Look at several architectural disciplines in order to
develop an intuition about software architecture

–
–
–
11
Hardware Architecture
Network Architecture
Building Architecture
UTSA CS3773
Hardware Architecture


12
RISC (Reduced Instruction Set Computer ) machines
emphasize the instruction set as an important feature
Pipelined and multi-processor machines emphasize the
configuration of architectural pieces of the hardware
UTSA CS3773
Software vs. Hardware Architectures
Differences:

–
–
Similarities:

–
13
Relatively (to software) small number of design elements.
Scale is achieved by replication of design elements.
We often configure software architectures in ways analogous
to hardware architectures
e.g., we create multi-process software and use pipelined
processing
UTSA CS3773
Network Architecture
Networked architectures are achieved by abstracting the
design elements of a network into nodes and connections
Topology is the most emphasized aspect:


–
–
–

14
Star networks
Ring networks
Ethernet
Unlike software architectures, in network architectures
only few topologies are of interest
UTSA CS3773
Building Architecture



15
Multiple views: skeleton frames, detailed views of
electrical wiring, etc.
Architectural styles: Classical, Romanesque, and so on
Materials: one does not build a skyscraper using framing
lumber and plywood
UTSA CS3773
Software Architecture Styles
An architectural style defines a family of systems in
terms of a pattern of structural organization
It determines:


–
–
The vocabulary of components and connectors that can be
used in instances of that style
A set of constraints on how they can be combined
For example, one might constrain:


16
The topology of the descriptions, e.g., no cycles
Execution semantics, e.g., processes execute in parallel
UTSA CS3773
Software Architecture Styles
We can understand what a style is by answering the
following questions:

–
–
–
–
–
–
17
What is the structural pattern? (i.e., components,
connectors, constraints)
What is the underlying computational model?
What are the essential invariants of the style?
What are some common examples of its use?
What are the advantages and disadvantages of using that
style?
What are some of the common specializations of that style?
UTSA CS3773
Software Architecture Styles


–
–
–
–
–

–
–
–
–
18
Software architectures are represented as graphs
Nodes represent components:
procedures
modules
processes
tools
databases
Edges represent connectors:
procedure calls
event broadcasts
database queries
pipes
UTSA CS3773
Pipe and Filter


19
Suitable for applications that require a defined series of
independent computations to be performed on ordered
data
A component reads streams of data on its inputs and
produces streams of data on its outputs
UTSA CS3773
Pipe and Filter


20
Components: called filters, apply local transformations to
their input streams and often do their computing
incrementally so that output begins before all input is
consumed
Connectors: called pipes, serve as conduits for the
streams, transmitting outputs of one filter to inputs of
another
UTSA CS3773
Pipe and Filter
21
UTSA CS3773
Pipe and Filter



22
Filters do not share state with other filters
Filters do not know the identity of their upstream or
downstream filters
The correctness of the output of a pipe and filter network
shall not depend on the order in which their filters
perform their incremental processing
UTSA CS3773
Pipe and Filter Specializations


23
Pipeline: restricts topologies to linear sequences of
filters
Batch sequential: a degenerate case of a pipeline
architecture where each filter processes all of its input
data before producing any output
UTSA CS3773
Pipe and Filter Examples
Unix Shell Scripts: provides a notation for connecting
Unix processes via pipes.
e.g., cat file | grep Erroll | wc
Traditional Compilers:
compilation phases are
pipelined, though the phases are not always incremental.
The phases in the pipeline include:


–
–
–
–
24
Lexical analysis
Parsing
Semantic analysis
Code generation
UTSA CS3773
Pipe and Filter - Advantages


25
Easy to understand the overall input/output behavior of a
system as a simple composition of the behaviors of the
individual filters
They support reuse, since any two filters can be hooked
together, provided they agree on the data that is being
transmitted between them
UTSA CS3773
Pipe and Filter - Advantages



26
Systems can be easily maintained and enhanced, since new
filters can be added to existing systems and old filters
can be replaced by improved ones
They permit certain kinds of specialized analysis, such as
throughput and deadlock analysis
The naturally support concurrent execution
UTSA CS3773
Pipe and Filter - Disadvantages


27
Not good for handling reactive systems, because of their
transformational character
Excessive parsing and unparsing leads to loss of
performance and increased complexity in writing the
filters themselves
UTSA CS3773
Object-Oriented Style




28
Suitable for applications in which a central issue is
identifying and protecting related bodies of information
(data)
Data representations and their associated operations are
encapsulated in an abstract data type
Components: are objects
Connectors: are function and procedure invocations
(methods)
UTSA CS3773
Object-Oriented Style
29
UTSA CS3773
Object-Oriented Invariants


30
Objects are responsible for preserving the integrity (e.g.,
some invariant) of the data representation
The data representation is hidden from other objects
UTSA CS3773
Object-Oriented Specializations


31
Distributed Objects
Objects with Multiple Interfaces
UTSA CS3773
Object-Oriented Advantages


32
Because an object hides its data representation from its
clients, it is possible to change the implementation without
affecting those clients
Can design systems as collections of autonomous interacting
agents
UTSA CS3773
Object-Oriented Disadvantages

In order for one object to interact with another object (via
a method invocation) the first object must know the identity
of the second object
–
–

Objects cause side effect problems:
–
33
Contrast with Pipe and Filter Style
When the identity of an object changes it is necessary to
modify all objects that invoke it
e. g., A and B both use object C, then B's affect on C look like
unexpected side effects to A
UTSA CS3773
Implicit Invocation Style


Suitable for applications that involve loosely-coupled
collection of components, each of which carries out some
operation and may in the process enable other operations
Particularly useful for applications that must be
reconfigured on the fly:
–
–
34
Changing a service provider
Enabling or disabling capabilities
UTSA CS3773
Implicit Invocation Style (Cont’d)

Instead of invoking a procedure directly ...
–
–
–
35
A component can announce (or broadcast) one or more events
Other components in the system can register an interest in an
event by associating a procedure with the event
When an event is announced, the broadcasting system
(connector) itself invokes all of the procedures that have been
registered for the event
UTSA CS3773
Implicit Invocation Style (Cont’d)

36
An event announcement “implicitly” causes the invocation of
procedures in other modules.
UTSA CS3773
Implicit Invocation Invariants



37
Announcers of events do not know which components will be
affected by those events
Components cannot make assumptions about the order of
processing
Components cannot make assumptions about what processing
will occur as a result of their events (perhaps no component
will respond)
UTSA CS3773
Implicit Invocation Specializations

38
Often connectors in an implicit invocation system also
include the traditional procedure call in addition to the
bindings between event announcements and procedure calls
UTSA CS3773
Implicit Invocation Examples

Used in programming environments to integrate tools:
–
–
39
Debugger stops at a breakpoint and makes that announcement
Editor responds to the announcement by scrolling to the
appropriate source line of the program and highlighting that
line
UTSA CS3773
Implicit Invocation Examples (Cont’d)


40
Used to enforce integrity constraints in database
management systems (called triggers)
Used in user interfaces to separate the presentation of
data from the applications that manage that data
UTSA CS3773
Implicit Invocation Advantages


41
Provides strong support for reuse since any component can
be introduced into a system simply by registering it for the
events of that system
Eases system evolution since components may be replaced
by other components without affecting the interfaces of
other components in the system
UTSA CS3773
Implicit Invocation Disadvantages

When a component announces an event:
–
–
–
42
it has no idea what other components will respond to it
it cannot rely on the order in which the responses are invoked
it cannot know when responses are finished
UTSA CS3773
Client-Server Style


Suitable for applications that involve distributed data and
processing across a range of components
Components:
–
–

43
Servers: Stand-alone components that provide specific services
such as printing, data management, etc.
Clients: Components that call on the services provided by
servers
Connector: The network, which allows clients to access
remote servers
UTSA CS3773
Client-Server Style
44
UTSA CS3773
Client-Server Style Examples

File Servers:
–
–
–
45
Primitive form of data service
Useful for sharing files across a network
The client passes request for files over the network to the file
server
UTSA CS3773
Client-Server Style Examples (Cont’d)

Database Servers:
–
–
–
–
–
46
More efficient use of distributing power than file servers
Client passes SQL requests as messages to the DB server
results are returned over the network to the client
Query processing done by the server
No need for large data transfers
Transaction DB servers also available
UTSA CS3773
Client-Server Advantages




47
Distribution of data is straightforward
transparency of location
mix and match heterogeneous platforms
easy to add new servers or upgrade existing servers
UTSA CS3773
Client-Server Disadvantages

48
No central register of names and services -- it may be hard
to find out what services are available
UTSA CS3773
Layered Style



49
Suitable for applications that involve distinct classes of
services that can be organized hierarchically
Each layer provides service to the layer above it and serves
as a client to the layer below it
Only carefully selected procedures from the inner layers
are made available (exported) to their adjacent outer layer
UTSA CS3773
Layered Style (Cont’d)


50
Components: are typically collections of procedures
Connectors: are typically procedure calls under restricted
visibility
UTSA CS3773
Layered Style (Cont’d)
51
UTSA CS3773
Layered Style Specializations

Often exceptions are be made to permit non-adjacent
layers to communicate directly
–
52
This is usually done for efficiency reasons
UTSA CS3773
Layered Style Examples


Layered Communication Protocols:
–
Each layer provides a substrate for communication at some
level of abstraction
–
Lower levels define lower levels of interaction, the lowest level
being hardware connections (physical layer)
Operating Systems
–
53
Unix
UTSA CS3773
Layered Style Advantages



54
Design: based on increasing levels of abstraction.
Enhancement: since changes to the function of one layer
affects at most two other layers
Reuse: since different implementations (with identical
interfaces) of the same layer can be used interchangeably
UTSA CS3773
Layered Style Disadvantages


55
Not all systems are easily structured in a layered fashion
Performance requirements may force the coupling of highlevel functions to their lower-level implementations
UTSA CS3773
Repository Style



56
Suitable for applications in which the central issue is
establishing, augmenting, and maintaining a complex central
body of information
Typically the information must be manipulated in a variety
of ways
Often long-term persistence of information is required
UTSA CS3773
Repository Style (Cont’d)


Components:
–
A central data structure representing the correct state of the
system
–
A collection of independent components that operate on the
central data structure
Connectors:
–
57
Typically procedure calls or direct memory accesses
UTSA CS3773
Repository Style (Cont’d)
58
UTSA CS3773
Repository Style Specializations
59

Changes to the data structure trigger computations

Data structure in memory (persistent option)

Data structure on disk

Concurrent computations and data accesses
UTSA CS3773
Repository Style Examples
60

Information Systems

Programming Environments

Graphical Editors

AI Knowledge Bases

Reverse Engineering Systems
UTSA CS3773
Repository Style Advantages
61

Efficient way to store large amounts of data

Sharing model is published as the repository schema

Centralized management:
–
backup
–
security
–
concurrency control
UTSA CS3773
Repository Style Disadvantages
62

Must agree on a data model a prior

Difficult to distribute data

Data evolution is expensive
UTSA CS3773
Interpreter Style

63
Suitable for applications in which the most appropriate
language or machine for executing the solution is not
directly available
UTSA CS3773
Interpreter Style (Cont’d)


64
Components: include one state machine for the execution
engine and three memories:
–
current state of the execution engine
–
program being interpreted
–
current state of the program being interpreted
Connectors:
–
procedure calls
–
direct memory accesses
UTSA CS3773
Interpreter Style (Cont’d)
65
UTSA CS3773
Interpreter Style Examples



66
Programming Language Compilers:
–
Java
–
Smalltalk
Rule Based Systems:
–
Prolog
–
Coral
Scripting Languages:
–
Awk
–
Perl
UTSA CS3773
Interpreter Style Advantages


67
Simulation of non-implemented hardware
Facilitates portability of application or languages across a
variety of platforms
UTSA CS3773
Interpreter Style Disadvantages
68

Extra level of indirection slows down execution

Some interpreters have an option to compile code
UTSA CS3773
Process-Control Style


69
Suitable for applications whose purpose is to maintain
specified properties of the outputs of the process at
(sufficiently near) given reference values
Components:
–
Process Definition includes mechanisms for manipulating some
process variables
–
Control Algorithm for deciding how to manipulate process
variables
UTSA CS3773
Process-Control Style

Connectors: are the data flow relations for:
–
70
Process Variables:

Controlled variable whose value the system is intended to control

Input variable that measures an input to the process

Manipulated variable whose value can be changed by the controller
–
Set Point is the desired value for a controlled variable
–
Sensors to obtain values of process variables pertinent to
control
UTSA CS3773
FeedBack Control System

71
The controlled variable is measured and the result is used
to manipulate one or more of the process variables
UTSA CS3773
Feedforward Control System

72
Information about process variables is not used to adjust
the system
UTSA CS3773
Process Control Examples

73
Real-Time System Software to Control:
–
Automobile Anti-Lock Brakes
–
Nuclear Power Plants
–
Automobile Cruise-Control
UTSA CS3773
Mobile Robotics
A mobile robotics system is one that controls a manned or partially
manned vehicle, such as a car, a submarine , or a space vehicle. Such
systems are finding many new uses in areas such as space exploration,
hazardous waste disposal, and underwater exploration. A robotics system
must deal with external sensors and actuators, and they must respond in
real time at rates commensurate with the activities of the system in its
environment. In particular, the software functions of a mobile robot
typically include acquiring input provided by its sensors, controlling the
motion of its wheels and other moveable parts, and planning its future
path.
74
UTSA CS3773
Mobile Robotics Functional Requirements

75
Typical software functions
–
Acquiring and interpreting input from sensors
–
Controlling the motion of all moving parts
–
Planning future activities
–
Responding to current difficulties
UTSA CS3773
Mobile Robotics Complications

Several factors complicate the tasks
–
Obstacles may block the robot’s path
–
Sensor input may be imperfect or fail
–
Robot may run out of power
–
Mechanical limitations may restrict the accuracy with which it
moves (movement may diverge from plans)
76
–
Robot may manipulate hazardous materials (water)
–
Unpredictable events may demand a rapid response
UTSA CS3773
Mobile Robotics Design Constraints

77
Evaluation criteria
–
Accommodation of deliberate and reactive behavior: robot must
coordinate actions to achieve assigned objectives with the
reactions imposed by the environment
–
Allowance for uncertainty: robot must function in the context of
incomplete, unreliable and contradictory information
–
Accounting of dangers in the robot’s operations and its
environment: relating to fault tolerance, safety and performance,
problems like reduced power supply, unexpectedly open doors, etc.,
should not lead to disaster
–
Flexibility: support for experimentation and reconfiguration
UTSA CS3773
Mobile Robotics Architecture Designs
78

Closed loop control architecture

Layered architecture

Repository/Blackboard architecture

Implicit invocation architecture
UTSA CS3773
Control Loop Architecture Style
79
UTSA CS3773
Control Loop Architecture Style Evaluation

Accommodation of deliberate and reactive behavior: robot
must coordinate actions to achieve assigned objectives with
the reactions imposed by the environment
Simplicity: problem in more unpredictable environments since
there is basic assumption that changes in environment are
continuous and require continuous reactions. Basic changes in
behavior may be needed when confronted with disparate
discrete events.
80
UTSA CS3773
Control Loop Architecture Style Evaluation

Allowance for uncertainty: robot must function in the context
of incomplete, unreliable and contradictory information
Uncertainty is resolved by reducing unknowns through
iteration: problem if more subtle steps are needed.
81
UTSA CS3773
Control Loop Architecture Style Evaluation

Accounting of dangers in the robot’s operations and its
environment: relating to fault tolerance, safety and
performance, problems like reduced power supply,
unexpectedly open doors, etc., should not lead to disaster
Fault tolerance and safety are enhanced by the simplicity of
the architecture.
82
UTSA CS3773
Control Loop Architecture Style Evaluation

Flexibility: support for experimentation and reconfiguration
Major components (supervisor, sensors, motors) can be easily
replaced; more refined tuning must take place inside the
modules.
83
UTSA CS3773
Control Loop Architecture Style Overall Evaluation

84
Appropriate for simple robotic systems that must handle only
a small number of external events and whose tasks do not
require complex decompositions
UTSA CS3773
Layered Architecture Style
85
UTSA CS3773
Layered Architecture Style Evaluation

86
Accommodation of deliberate and reactive behavior: robot
must coordinate actions to achieve assigned objectives with
the reactions imposed by the environment
Nicely organizes components needed to coordinate operation.
However, does not fit the actual data and control-flow
patterns. Information exchange is less straightforward:
exceptional events may force direct communication between
levels 2 and 8, for example. Also, there are really two
abstraction hierarchies that actually exist: a data hierarchy
and a control hierarchy.
UTSA CS3773
Layered Architecture Style Evaluation

Allowance for uncertainty: robot must function in the context
of incomplete, unreliable and contradictory information
Existence of abstraction layers nicely addresses need for
managing uncertainty: things get more certain the higher one
gets.
87
UTSA CS3773
Layered Architecture Style Evaluation

Accounting of dangers in the robot’s operations and its
environment: relating to fault tolerance, safety and
performance, problems like reduced power supply,
unexpectedly open doors, etc., should not lead to disaster
Fault tolerance and passive safety are also served by
abstraction mechanism. Performance and active safety issues
may force the communication pattern to be short-circuited.
88
UTSA CS3773
Layered Architecture Style Evaluation

Flexibility: support for experimentation and reconfiguration
Interlayer dependencies are an obstacle to easy replacement
and addition of components.
89
UTSA CS3773
Layered Architecture Style Overall Evaluation

90
Nice, high-level view of robot control, but breaks down as an
implementation view since the communication patterns are
not likely to follow the orderly scheme implied by the
architecture.
UTSA CS3773
Blackboard Architecture Style
91
UTSA CS3773
Blackboard Architecture Style Evaluation

Accommodation of deliberate and reactive behavior: robot
must coordinate actions to achieve assigned objectives with
the reactions imposed by the environment
Components communicate via the shared repository: modules
indicate their interest in certain types of information; the
database returns relevant data either immediately or when
some other module inserts the relevant data into the database.
92
UTSA CS3773
Blackboard Architecture Style Evaluation

Allowance for uncertainty: robot must function in the context
of incomplete, unreliable and contradictory information
The blackboard helps to resolve conflicts or uncertainty in the
robot’s world view.
93
UTSA CS3773
Blackboard Architecture Style Evaluation

Accounting of dangers in the robot’s operations and its
environment: relating to fault tolerance, safety and
performance, problems like reduced power supply,
unexpectedly open doors, etc., should not lead to disaster
The TCA exception mechanisms, wiretapping and monitoring
roles can be implemented by defining separate modules that
watch the database for exceptional circumstances.
94
UTSA CS3773
Blackboard Architecture Style Evaluation

Flexibility: support for experimentation and reconfiguration
Supports concurrency and maintenance by decoupling senders
from receivers.
95
UTSA CS3773
Blackboard Architecture Style Overall Evaluation

96
Capable of modeling the cooperation of tasks in a flexible
manner thanks to an implicit invocation mechanism based on
the contents of the database
UTSA CS3773
Reading Assignments
 Sommerville’s Book, 8th Edition
–
–
–
Chapter 11, “Architectural design”
Chapter 12, “Distributed System Architecture”
Chapter 13, “Application Architectures”
 Sommerville’s Book, 9th Edition
–
–
–

97
Chapter 6, “Architectural design”
Chapter 18, “Distributed Software Engineering”
Chapter 19, “Service-Oriented Architecture”
David Garlan and Mary Shaw, “An introduction to software
architecture”, Technical Report CMU-CS-94-166, School of
Computer Science, Carnegie Mellon University.
UTSA CS3773