SOFTWARE

ARCHITECTURE
Lecture2
Architecture Styles

• An architectural style defines a family of such systems in

terms of a pattern of structural organization.

• More specifically, an architectural style defines a vocabulary

of components and connector types, and a set of constraints
on how they combined.
Architecture Styles

• Garlan and Shaw gave a general architectural style

classification (classic software architecture style):
• Dataflow systems: Batch sequential; Pipes and filters
• Call-and-return systems: Main program and subroutine;
OO systems; Hierarchical layers
• Independent components: Communicating process;
Event systems
• Virtual machines: Interpreters; Rule-based systems
• Data-centered-systems(repositories): Databases;
Hypertext systems; Blackboards
Dataflow systems
Dataflow Systems
Batch-sequential
• The batch sequential style is one of the oldest in the design of
computer systems. It arose in the early days of data processing
when the limitations of computing equipment required that large
problems be subdivided into severable components that could
communicate by the transfer of magnetic tapes.

Data transformation

tape tape tape tape report

validate sort Update Report

tape

Data flow
Dataflow Systems

• Batch Sequential
• Processing steps are independent programs
• Each step runs to completion before next step starts
• Data transmitted as a whole between steps
• Because of the above features, there is no need to synchronize
its components
• Because several components can only be run in sequence and
not simultaneously, performance may be worse than programs
that run concurrently on several components
• Software designed using a sequential batch structure is not
suitable for systems that process data in real time
Dataflow Systems

• Batch Sequential
• Typical uses: Transaction processing in financial systems. “The
Granddaddy of Styles”
Dataflow Systems—Batch-sequential
• Summary: Separate programs are executed in order; data is passed as an
aggregate from one program to the next.
• Components: Independent programs.
• Connectors: The human hand carrying tapes between the programs
• Data elements: Explicit, aggregate elements passed from one
component to the next upon completion of the producing program's
execution.
• Topology: Linear.
• Additional constraints imposed: One program runs at a time, to
completion.
• Qualities yielded: Severable execution; simplicity.
• Typical uses: Transaction processing in financial systems.
• Cautions: When interaction between the components is required; when
concurrency between components is possible or required.
• Relations to programming languages or environments: None.
Dataflow Systems
Pipe-and-Filter
• In a pipe-and-filter style each component has a set of inputs and a
set of outputs. This is usually accomplished by applying a local
transformation to the input streams and computing incrementally, so
that output begins before input is consumed. Hence components are
termed filters. The connectors of this style serve as conduits for the
streams, transmitting outputs of one filter to inputs of another.
Hence the connectors are termed pipes.
Dataflow Systems
Pipe-and-Filter
• Filter structure shown in Figure 1. A filter consists of input port, filter
and output port. Input port part is responsible for storing pending
data, filter is responsible for processing data, output port is
responsible for storing the data has been processed.
• The responsibility of the pipeline is to transport data, its structure
shown in Figure 2. The pipeline consists of an Input Stream and an
Output Stream, and the pipe component pipe is responsible for
transferring data from the input stream to the output stream

Figure 1 Figure 2
Dataflow Systems
Pipe-and-Filter
• Filter types are divided into Active Filter and Passive Filter. In
specific applications, depending on the problem, different types
of filters may be selected
• Active filter features include Input data and Pull/Push the
transformed data. At this point the pipeline is passive, and in
order to pull and push provides an I/O mechanism.
• The passive filters give the responsibility for the data to the pipes
that are connected to it. Such a pipe should have the ability to
pull data from the previous filter and push it to the next filter. At
this point, the filter must provide I/O mechanism.
Dataflow Systems
Pipe-and-Filter—Advantages
• Allow the designer to understand the overall input/output behavior of
a system as a simple composition of the behaviors of the individual
filters.
• Support reuse: any two filters can be hooked together, provided they
agree on the data that are being transmitted between them.
• Systems are easy to maintain and enhance: new filters can be added
to existing systems and old filters can be replaced by improved ones.
• Permit certain kinds of specialized analysis, such as throughput and
deadlock analysis.
• Naturally support concurrent execution. Each filter can be
implemented as a separate task and potentially executed in parallel
with other filter.
Dataflow Systems
Pipe-and-Filter-Disadvantages
• Pipe-and-filter systems often lead to a batch organization of processing.
Although filters can process data incrementally, they are inherently
independent, so the designer must think of each filter as providing a
complete transformation of input data to output data.
• They may be hampered by having to maintain correspondences
between two separate but related streams.
• Depending on the implementation, they may force a lowest common
denominator on data transmission, resulting in added work for each
filter to parse and unparse its data. This, in turn, can lead both to loss
of performance and to increased complexity in writing the filters
themselves.
Dataflow—Pipe-and-Filter
• Summary: Separate programs are executed, potentially concurrently; data is passed as
a stream from one program to the next.
• Components: Independent programs, known as filters.
• Connectors: Explicit routers of data streams; service provided by operating system.
• Data elements: Not explicit; must be (linear) data streams. In the typical
Unix/Linux/DOS implementation the streams must be text.
• Topology: Pipeline, though T fittings are possible.
• Qualities yielded: Filters are mutually independent. Simple structure of incoming and
outgoing data streams facilitates novel combinations of filters for new, composed
applications.
• Typical uses: Ubiquitous in operating system application programming.
• Cautions: When complex data structures must be exchanged between filters; when
interactivity between the programs is required.
• Relations to programming languages or environments: Prevalent in Unix shells.
Dataflow Systems
Comparison of Batch Sequential and Pipe-and-Filter

Figure1 Batch Sequential system architecture structure

Figure 2 Pipe-and-Filter system architecture structure

 Dataflow Systems
Comparison of Batch Sequential and Pipe-and-Filter
• The similarity between the two structures lies in the mutual
independence of the processing modules. In batch systems and pipe-
and-filter architectures, the processes are independent of each other,
that is, in a batch system architecture, each process does not call
other processes; in a pipe-and-filter architecture, each filter does not
call other filters.
 Dataflow Systems
Comparison of Batch Sequential and Pipe-and-Filter
• The difference between the two architecture is:
① Data processing is different. In a sequential batch system, only the last
step is done completely, the next step can start, and the data is
transmitted as a block. It is common to have intermediate storage for each
intermediate step. Each process is not working at the same time, and only
when the previous adjacent processing is completed can the process
begin to work. In the pipe-and-filter architecture, the filters incrementally
transform data in a stream-by-stream manner, with each filter working
simultaneously.
② The amount of data processed is different. The amount of data processed
by the batch sequential system is limited, while the amount of data
processed by the pipe-and-filter architecture is infinite.
Call-and-return
Call-and-return
Introduction to unstructured programming
• Unstructured programming technology is the earliest
programming paradigm. A program written in an unstructured
language usually contains a series of ordered commands
(statements), usually one line per statement, with a line number
or label for each line, allowing the program execution stream to
be sorted from one line Jump to other specified lines of the
program.
• Unstructured programming introduces the concept of control
loops such as basic loops, branches and jumps. Subroutines in
unstructured programming allow multiple inlets and multiple
outlets, allowing programs to be transferred to and from
subroutines anywhere.
Call-and-return
Concept of Call-and-return architecture structure
• Software systems designed with a call-and-return style software
architecture use a divide-and-conquer strategy whose main idea
is to break down a complex large system into subsystems in order
to reduce complexity and increase modifiability. The system's
program execution sequence is usually controlled by only a single
thread.
• Each software component is designed to have a unique program
execution starting point and a unique program execution end
point. The program starts executing the code of the component
from the beginning of its execution. The program execution is
completed, and control is returned to the program invoking
component, where the program component is usually called a
subroutine and the control transfer from one component to
another is called a subroutine call.
Call-and-return
Concept of Call-and-return architecture structure

Call-and-return software architecture program control flow diagram

Call-and-return
Main Program and Subroutines
• The main program and subroutines software architecture uses
hierarchical partitioning in design, which uses single control
thread directly supported by the programming language.
• The structure of the subroutine is clear, and the subroutines
usually make up the program module. Subroutine calls appear
hierarchical, and its correctness often depends on the correct
subroutine call.
Call-and-return
Main Program and Subroutines
• The design philosophy of top-down functional method is that the system is
designed from a functional point of view, starting from the top, and
gradually refined into a detailed design. Based on the functional
requirements of the system to be completed, the design divides a whole
problem into several sub-problems first and then considers each sub-
problem to be subdivided into several smaller sub-problems again, and then
continues until it can not be further divided.
• Structured design begins with the data flow diagram and then transforms it
into a program structure diagram. These diagrams need to be described in a
canonical DFD to achieve a well-understood understanding of the system
before it is established. In the design, the development stage needs to be
strictly divided, and the work of each stage should be precisely described by
the standard methods and charting tools. Each stage takes the standardized
documents and materials as the result and finally obtains the system that
meets the needs of users.
Call-and-return

Main Program and Subroutines

Call-and-return
Top-down programming has the following problems:
• Functional evolution is difficult
The top-down approach creates a better software system model that meets
the initial requirements. But as the system changes or adds new demands,
the functional structure becomes more clumsy. Because software is designed
as a tree structure, modifications and updates often require extensive
"pruning" and "grafting," making system maintenance more and more
difficult.
• The actual system function is not easy to describe
Large-scale interactive system is difficult to describe from the functional
aspects. Many large systems do not have a "top", for example, a software
system that involves data queries, data changes, and data consistency. If
followed by a functional top-down design, the system may be designed to be
based on a unique "Virtual" vertices and produce very complex structures.
Call-and-return
Top-down programming has the following problems:
• Functional Design Loses Data and Data Structure.
Because system decomposition highlights only the functional aspects of the
problem, the impact of the data structure on the problem is lost
• Software products designed by function produce less
reusable code.
The design of each program unit considers only very limited requirements,
because these specific requirements are less likely to appear in the next
question, so the resulting design and code is not universal and generic.
Call-and-return
Main Program and Subroutines
• Summary: Decomposition based upon separation of functional
processing steps.
• Components:· Main program and subroutines.
• Connectors: Function/procedure calls.
• Data elements: Values passed in/out of subroutines.
• Topology: Static organization of components is hierarchical; full structure
is a directed graph.
• Additional constraints imposed:None.
• Qualities yielded: Modularity: Subroutines may be replaced with
different implementations long as interface semantics are unaffected.
• Typical uses:. Small programs; pedagogical purposes
• Cautions: Typically fails to scale to large applications; inadequate
attention to data structures. Unpredictable effort required to
accommodate new requirements.
• Relations to programming languages. or environments: Traditional
imperative programming languages, such as BASIC, Pascal, or C.
Call-and-return
Object-Oriented
• Object-oriented design and programming methods allow
programmers to encapsulate data and limit access to data.
• An object is an entity that binds data to operations (ie,
functions or methods) that access and maintain the data.
Objects provide some easy-to-use, standardized methods to
manipulate their data and hide the tedious details of their
specific tasks.
• In object-oriented design, the system is seen as consisting of a
collection of objects (rather than functions or methods) that
send messages from one object to another. Each object has its
own related functions.
Call-and-return
Object-Oriented

Object-Oriented architecture structure

Call-and-return
Object-Oriented--Advantage
• Easy to maintain: Because an object hides its internal
representation from the client, its internal implementation can
be changed without affecting those clients.
• Reusability: The object is suitable for reuse components.
• Mapping the real world: For many software systems there are
obvious real-world entity to system objects.
• Easy to split a system: Object-Oriented design bind data and
data access,control methods together to form a class, the
object is generated by the class. Enables software designers to
divide the entire problem into a series of interacting objects.
Call-and-return
Object-Oriented—Disadvantage
• Object-oriented programs occupy large memory. This is
because each newly created object must occupy a piece of
memory during program execution, whereas in object-
oriented programs, a large number of objects are often
created.
• In order for one object to interact another(via procedure call)
it must know the identity of that other object, including the
object name, method name and parameter type.
• In object-oriented systems, whenever the identity of an object
changes it is necessary to modify all other objects that
explicitly invoke it.
Call-and-return—Object-Oriented
• Summary: State strongly encapsulated with functions that operate on
that state as object. Objects must be instantiated before the
objects’methods can be called.
• Components: Objects(aka. Instances of a class)
• Connector: Method invocation(procedure calls manipulate state)
• Data elements: Arguments to methods
• Topology: Can vary arbitrarily; components may share data and interface
functions through inheritance hierarchies.
• Additional constriants imposed: Commonly: shared memory (to support
use of pointers), single threaded.
• Qualities yielded: Integrity of data operations: data manipulated only by
appropriate functions. Abstraction: implementation details hidden.
Call-and-return—Object-Oriented
• Typical uses: Applications where the designer wants a close
correlation between entities in the physical world and entities in
the program; pedagogy; application involving complex, dynamic
data structure
• Cautions: Use in distributed applications requires extensive
middleware to provide access to remote objects .Relatively
inefficient for high-performance applications with large, regular
numeric data structures, such as un scientific computing. Lack of
additional structuring principles can result in highly complex
applications
• Relations to programming languages or environments:Java ,C++
 Call-and-return
Comparison
• Similarities
① In the program generated by the main program-subroutine architecture,
each software component has a unique program execution entry and a
unique program execution exit, and when one component calls another
component, program execution control is transferred to the called
component, when the called component code is completed, the program
runs to the component‘s exit, the control is returned to the calling control.
② The program generated by Object-oriented architecture, when an object's
method calls another object's method, the called object will take over the
program run control, when the called object method is run, the control
will be returned to the calling object .
Call-and-return
Comparison
• Difference

Structured design Object-oriented design

Focus function, process object data

Reusability Low High

Project definition is very clear, Large projects where demand may

Suitable item
user needs stable change often
Program
• Structure Diagram • Program design class diagram
Structure
• Element：The nodes in the • The nodes in the diagram are class
Diagram/Elemen
diagram are function
t
Example: Key Word In Context
Parnas proposed the following problem[1972]:
Example: Key Word In Context
Problem Description
• “The KWIC index system accepts an ordered set of lines, each
line is an ordered set of words, and each word is an ordered
set of characters.
• Any line may be ‘circularly shifted’ by repeatedly removing
the first word and appending it at the end of the line.
• The KWIC index system outputs a listing of all circular shifts of
all lines in alphabetical order.“
Example: Key Word In Context
Solution 1—Main program Subroutine
• Decompose the overall processing into a sequence of processing steps
according to the four basic functions performed.
• Read lines; MaEach step transforms the data completely.
• Intermediate data stored in shared memory.
• ke shifts; Alphabetize; Print results
• Arrays of characters with indexes
• Relies on sequential processing
Example: Key Word In Context
Solution 1： Modularization
• Module 1: Input
• Reads data lines and stores them in “core” storage.
• Storage format: 4 chars/machine word; array of pointers to start
of each line.
• Module 2: Circular Shift
• Called after Input is done.
• Reads line storage to produce new array of pairs: (index of 1st
char of each circular shift, index of original line)
• Module 3: Alphabetize
• Called after Circular Shift.
• Reads the two arrays and produces new index
Example: Key Word In Context
Solution 1： Modularization
• Module 4: Output
• Called after alphabetization and prints nicely formatted output
of shifts
• Reads arrays produced by Modules 1 & 3
• Module 5: Master Control
• Handles sequencing of other modules
• Handles errors
Example: Key Word In Context
Main Program/Subroutine with Shared Data
Example: Key Word In Context
Solution 2: pipe-and-filter
• Decompose the overall processing into a sequence of
processing steps.
• Read lines; Make shifts; Alphabetize; Print results
• Copy data in modules
• Determine the representation of data between neighbors.
• Usually use the same representation of data for all modules
Example: Key Word In Context
Solution 2: Modularization
• Module 1：Input
• Read data lines and pass to the next module
• Module 2：Circular Shift
• The first line’s coming make it work
• Transmit the old and new lines to the next
• Module 3：Alphabetize
• Collect data lines, buffer. All done, begin to work
• Finish, output results
• Module 4：Output
• Called after Alphabetization
• Read sorted data lines, print formatted output
Example: Key Word In Context
Solution 2: pipe-and-filter
Call-and-return
Hierarchical layers
• A layered system is organized hierarchically,
each layer providing service to the layer
above it and service as a client to the layer
below.
• The call between layers is unidirectional,
that is, the class on the n-th layer can call
the methods of classes in the n-1 layer, but
the class in layer n-1 can not call methods
in layer n. In addition, it is also not allowed
to call the compartment, that is, the n-th
layer is not allowed to directly call the n-2
layer beyond the n-1 layer. In practice, the
0th layer typically contains processing
procedures, functions, or methods for input
from the hardware.
Call-and-return
Hierarchical layers
• In some layered systems inner layers are
hidden from all except the adjacent
outer layer, except for certain functions
carefully selected for export. Thus in
these systems the components
implement a virtual machine at some
layer in the hierarchy.(In other layered
systems the layers may be only partially
opaque.)
• The connectors are defined by the
protocols that determine how the layers
will interact. Topological constraints
include limiting interactions to adjacent
layers. The figure illustrates this style.
Call-and-return
Hierarchical layers
• The Most widely known examples of this kind of architectural style
are layered communication protocols. In such applications each
layer provides a substrate for communication at some level of
abstraction. Lower levels define lower levels of interaction, the lowest
typically being defined by hardware connections. Other application
areas for this style include database systems and operating
systems.
Call-and-return
Hierarchical layers--Advantage
• They support design based on increasing levels of
abstraction.( This allows implementors to partition a complex
problem into a sequence of incremental steps)
• They support enhancement.(As with pipelines,because each
layer interacts with at most the layers below and above,
changes to function of one layer affect at most two other
layers)
• They support resuse. (They allow different implementations of
the same layer to be used interchangeably, provided they
support the same interfaces to their adjacent layers)
Call-and-return
Hierarchical layers--Disadvantage
• Not all systems are easily structured in a layered fashion. (Even
if a system can logically be structured as layers, considerations
of performance may require closer coupling between logically
high-level functions and their lower-level implementations)
• It can be quite difficult to find the right models.(The
communications community, for instance, has had some
difficulty mapping existing protocols into the ISO framework
because many of those protocols bridge several layers)
Call-and-return—Hierarchical layers
• Summary: Consists of an ordeted sequence of layers; each layer, or virtual
machine, offers a set of services that may be accessed by
programs(subcomponents) residing within the layer above it.
• Components: Layers offering a set of services to other layers, typically
comprising several programs (subcomponents).
• Connectors: Typically procedure calls.
• Data elements: Parameters passed between layers.
• Topology: Linear, for strict virtual machines; a directed acyclic graph in looser
interpretations.
• Additional constraints imposed: None
• Qualities yielded: Clear dependence structure; software at upper levels
immune to changes of implementation within lower levels as long as the
service specifications are invariant. Software at lower levels fully
independent of upper levels.
• Typical uses: Operating system design; network protocol stacks.
• Cautions: Strict virtual machines with many levels can be relatively inefficient.