8/15/2022

Software Architecture

Lecture 3

A Software Architecture
is an Abstraction
• An architecture is an abstraction of a system that
suppresses details of components that do not affect
how they:
– Use
– Are used by
– Relate to
– Interact with
…other components.

1
 8/15/2022

Externally Visible
Properties of Components
• Externally visible properties refers to those
assumptions other components can make of
a component, such as:
– Provided services
– Performance characteristics
– Fault handling
– Shared resource usage
– Etc.

Software Architecture styles

• Architecture styles - A set of design rules that identify the kinds of
components and connectors that may be used to compose a system or
subsystem, together with local or global constraints on the way the
composition is done’
• Architectural Styles of Software Systems:
– Repository-Subsystems access and modify data from a single data
structure called the repository.
– Pipe and Filter-
• Case Study of Compiler Architecture
• architectural style to divide a larger processing task into a sequence of smaller,
independent processing steps (Filters) that are connected by channels (Pipes).

– Object-Oriented- focused on modeling a business domain and defining

business objects based on entities within the business domain.

2
 8/15/2022

Software Architecture styles

– Implicit Invocation-
• instead of invoking a procedure directly, 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 the event is announced the system itself invokes all
of the procedures that have been registered for the event.
• Thus an event 'implicitly' causes the invocation of
procedures in other modules."

Software Architecture styles

– Layered
• A layered system is organized hierarchically, each layer serving the
layer above. In some systems, inner layers are hidden in all but the
adjacent outer layer.
– Interpreter
– Process-Control
– Client/Server

3
 8/15/2022

Can a system have

more that one structure?
• Yes, no one structure holds the claim to being the
architecture.
• Below are some examples of structures:
– Module decomposition
– Objects and message passing at runtime
– Build dependencies
– Etc.

Does Every System have an

Architecture?
• Yes.
• For small systems the architecture may be
trivial.
• For large systems it definitely exists in the
software product, but may not have been
documented.

4
 8/15/2022

Why is Software Architecture Important?

• Communication among stakeholders:

– Customers, managers, designers, programmers.

• Documentation of early design decisions:

– Constraints on implementation
– Organizational structure
– Guides evolutionary prototyping

• Transferable abstraction of a system to similar systems

(reuse):
– Program families share a common architecture
– Architecture can be the basis for training.

Architectural Structures (Module)

• Components: work Structure assignments.

– Work assignments have products
associated with them:
• Interface specifications
• Code
• Test plans, etc.
• Relations: is-a-submodule-of
• Use: Allocating a project’s labor and other
resources during development and
maintenance.

10

5
 8/15/2022

Considerations in Architectural
Structures
• Conceptual and logical structures:
Abstractions of the system’s functional
requirements. - shares-data-with. It is important for
understanding the interactions between units.
• Process or Coordination Structure: Modeling
dynamic aspects of a running system.
Synchronizes-with, Can’t-run-without and Can’t-run-
with. Processes and threads

11

Architectural Structures …
Cont..
• Physical Structure: Hardware (computers,
networks, etc.). “communicates-with”. Create
models to reason about performance,
availability, security, etc.
• Uses Structure: procedures or modules. “assumes-
the-correct-presence-of ”. For modeling system
extendibility and incremental system building
(e.g., Makefile dependencies).

12

6
 8/15/2022

Architectural Structures ..
• Cont.. Used to model trace
Calls Structure. “Procedures”.
of execution in a program.
• Data Flow Structure Programs or modules. “
transmits-data-to”. Used to model data transmission
which can aid requirements traceability.
• Class Structure. classes and interfaces. “inherits-from,
implements”. Used to model collections of similar
behavior and parameterizes differences.

13

The Importance of Structures

• Structures are important because they “boil

away” details about the software that are
independent of the concern reflected by the
abstraction.
• Each structure provides a useful perspective
of the system.
• Sometimes the term view is used instead of
structure.

14

7
 8/15/2022

Abstraction

15

Modeling Views
• Modeling system architectures is best done
using multiple concurrent views

• Individual views divide the complexity, and

create artifacts that separately address the
concerns of different stakeholders

16

8
 8/15/2022

Lines and Component

Representation
• Software architecture and design documentation is
often modeled using components and line diagrams
• Modelers often struggle with:
– What do the lines and components represent?
– Do the lines and boxes represent the same abstractions
from one model to another?
– Do models developed by more than one individual have
the same meaning for the lines and components?
– Is the goal of the model clear - are the lines network
messages, procedure calls, or structural relationships? –
are the boxes functions, classes, components, servers, etc.

17

Abstraction (Cont’d)

• Early 1950s: Software was written in

machine language:
– programmers placed instructions and data
individually and explicitly in the computer’s
memory
– insertion of a new instruction in a program
might require hand checking the entire program
to update references to data and instructions

18

9
 8/15/2022

Requirements for Modeling SW

Architectures

• Use multiple views, each view addressing one

specific set of concerns
• Organize the views into categories, with each
category being specifically targeted to be used
by a different constituency
• Use consistent notation for the individual
views

19

Programming Languages

• Late 1950s: The emerging of the first high-

level programming languages. Well
understood patterns are created from
notations that are more like mathematics than
machine code.
– evaluation of arithmetic expressions
– procedure invocation
– loops and conditionals

20

10
 8/15/2022

The 4+1 View Model

Architects Developers

Development
Logical View
View

Business
Scenarios Analysts

Process View Physical View

Integrators Infrastructure
Engineers

• Each view is consumed by a different stakeholder

21

Abstract Data Types

• 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.
– Data and related code are encapsulated into modules.
– Interfaces to modules are made explicit.

22

11
 8/15/2022

Software Architecture Issues

• Organization and global control structure.

• Protocols of communication, synchronization, and
data access.
• Assignment of functionality to design elements.
• Physical distribution of data and processes.
• Selection among design alternatives.

23

The Architecture Widgets

The “Widgets” of Architecture Connector Interface

Component A Connector Component B

• Each view is expressed using a set of elements and

connectors
• Each view can be guided by using patterns or
architectural styles to introduce constraints on
downstream design artifacts
• Each view is developed taking the appropriate set of
requirements into mind
• Each view might use different notation that is most
appropriate for the view
24

12
 8/15/2022

Logical View
The Logical View
• This view expresses the key abstractions from the problem
domain
– Classes, Components
• Think in terms of the services that the system will provide to
the user
• Express the relationships between the logical components
– Use, generalize, aggregate
• Define the important interfaces of the components and
connectors associated with this view

25

Logical View
The Logical View
• Choose a “style” for the logical view
– Object-oriented style
– Component style
– Service-oriented style
• The style helps define the structure and
semantics of the elements captured in the
logical view

26

13
 8/15/2022

Process View
The Process View
• The process view takes into account non-
functional requirements such as performance,
availability
• This view also deals with concurrency,
showing the different threads of control
– Intra-process threads
– Inter-process coordination (messages to and
from different servers)

27

Process View
The Process View
• A “process” in the process view groups tasks
into logical execution units. Execution units
have a:
– Well defined point where they start and stop as
well as rule for dealing with exceptions to the
normal course of operation
• Possible styles for the process views:
– Client/Server, MVC, pipe and filter.

28

14
 8/15/2022

Process View
The Process View
• Components for the process view include:
– Processes and threads
• Connectors include
– Messages, shared memory, pipes

29

Development
The Development View View

• The development view defines the actual software

modules to be constructed
• The granularity of the components in this view
should be at the level where they can be
implemented by one or a small set of developers
– Classes, Packages, Subsystems
• This view should clearly define the import and
output relations
– We will hear more about this later when we talk about
provided and required interfaces…

30

15
 8/15/2022

Development
The Development View View

• Connectors for the development view may

include:
– Function/procedure calls, inheritance, includes,
uses, etc.
• Styles for the development view include the
layer style
– Subsystems, components, modules/classes,
functions/procedures

31

The +1 View - Scenarios Scenarios

• Scenarios are abstractions of the most

important requirements
• Map closely to use cases
• Ties the other views together
• The scenario view is redundant to the other
views (+1) but is a cross-cutting aspect tying
the architecture together

32

16
 8/15/2022

The +1 View - Scenarios Scenarios

• Why scenarios:
– A mechanism to discover the key architectural
elements and connectors
– Validation of the architecture design after the
other views are created
– Addresses the concerns of both the functional
and non-functional requirements

33

State of Practice

• There is not currently a well-defined terminology or

notation to characterize architectural structures.
• However, good software engineers make common
use of architectural principles when designing
software.
• These principles represent rules of thumb or
patterns that have emerged informally over time.
Others are more carefully documented as industry
standards.

34

17
 8/15/2022

Architectural Styles
of Software Systems
Style
An architectural style represents a family of
related systems
Defines the design vocabulary (and
constraints) for the components, connectors,
ports, roles, bindings and properties.

35

Architectural Styles of
Software Systems
• 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:
• the topology of the descriptions (e.g., no cycles).
• execution semantics (e.g., processes execute in
parallel).

36

18
 8/15/2022

Determining an Architectural Style

• We can understand what a style is by answering the
following questions:
– 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?

37

Repository Style

• 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 is required.

38

19
 8/15/2022

Repository Style (Cont’d)

• Components:
– A central data structure representing the current
state of the system.
– A collection of independent components that
operate on the central data structure.
• Connectors:
– Typically procedure calls or direct memory
accesses.

39

Repository Style (Cont’d)

Memory Access

Computation

Shared Data

Memory

40

20
 8/15/2022

Repository Style Specializations

• Changes to the data structure trigger

computations.
• Data structure in memory (persistent option).
• Data structure on disk.
• Concurrent computations and data accesses.

41

Repository Style Examples

• Information Systems
• Programming Environments
• Graphical Editors
• AI Knowledge Bases
• Reverse Engineering Systems

42

21
 8/15/2022

Repository Style Advantages

• Efficient way to store large amounts of data.

• Sharing model is published as the repository
schema.
• Centralized management:
– backup
– security
– concurrency control

43

Repository Style Disadvantages

• Must agree on a data model a priority.

• Difficult to distribute data.
• Data evolution is expensive.

44

22
 8/15/2022

Object-Oriented Style

• 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).

45

Object-Oriented Style (Cont’d)

object
obj obj

obj
obj

obj
obj

obj

obj

46

23
 8/15/2022

Object-Oriented Invariants

• Objects are responsible for preserving the

integrity (e.g., some invariant) of the data
representation.
• The data representation is hidden from other
objects.

47

Object-Oriented Specializations

• Distributed Objects
• Objects with Multiple Interfaces

48

24
 8/15/2022

Object-Oriented Advantages

• 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.

49

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.
– Contrast with Pipe and Filter Style.
– When the identity of an object changes, it is necessary to
modify all objects that invoke it.
• Objects cause side effect problems:
– E.g., A and B both use object C, then B’s effects on C
look like unexpected side effects to A.

50

25
 8/15/2022

Pipe and Filter

Architectural Style
• Suitable for applications that require a
defined series of independent computations
to be performed on data.
• A component reads streams of data as input
and produces streams of data as output.

51

Pipe and Filter

Architectural Style (Cont’d)
• 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 or
channels for the streams, transmitting outputs of
one filter to inputs of another filter.

52

26
 8/15/2022

Pipe and Filter

Architectural Style (Cont’d)
filter

pipes

53

Pipe and Filter Invariants

• Filters do not share state with other filters.

• Filters do not know the identity of their
upstream or downstream filters.

54

27
 8/15/2022

Pipe and Filter Specializations

• Pipelines: 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.

55

Pipe and Filter Examples

• Unix Shell Scripts: Provides a notation for

connecting Unix processes via pipes.
– cat file | grep Erroll | wc -l
• Traditional Compilers: Compilation phases
are pipelined, though the phases are not always
incremental. The phases in the pipeline include:
– lexical analysis + parsing + semantic analysis + code generation

56

28
 8/15/2022

Pipe and Filter Disadvantages

• Not good choice for interactive systems,

because of their transformational character.
• Excessive parsing and unparsing leads to loss
of performance and increased complexity
in writing the filters themselves.

57

Client-Server Style
• Suitable for applications that involve distributed data
and processing across a range of components.
• Components:
– 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.

58

29
 8/15/2022

Client-Server Style

Client 1 Client 2 ... Client N

Network

File Server Database Server Object Server

59

Client-Server Style Examples

• File Servers:
– Primitive form of data service.
– Useful for sharing files across a network.
– The client passes requests for files over the
network to the file server.

60

30
 8/15/2022

Client-Server Style
Examples (Cont’d)
• Database Servers:
– 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.

61

Client-Server Style
Examples (Cont’d)
• Object Servers:
– Objects work together across machine and
network boundaries.
– ORBs allow objects to communicate with each
other across the network.
– IDLs (Interactive Data Language) define interfaces
of objects that communicate via the ORB.
– ORBs are the evolution of the RPC.

62

31
 8/15/2022

RPCs Versus ORBs

Client Server
Client Server
Object X Object Y
Code Data call foo call foo Data Data
call foo on on
Object X Object Y Code Code
execute foo

RPC Mechanism Object Request Broker

1) Remote Procedure Call (RPC) 2) Object Request Broker

63

Client-Server Advantages

• Straightforward distribution of data.

• Transparency of location.
• Mix and match heterogeneous platforms,
• Easy to add new servers or upgrade existing
servers.

64

32
 8/15/2022

Client-Server Disadvantages

• Performance of the system depends on the

performance of the network.
• Tricky to design and implement C/S systems.
• Unless there is a central register of names
and services, it may be hard to find out what
services are available.

65

Reading
• Implicit Invocation Style
• Layered Style
• Interpreter Style
• Process-Control Style

66

33
 8/15/2022

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”:
– Changing a service provider.
– Enabling or disabling capabilities.

67

Implicit Invocation Style

(Cont’d)
• Instead of invoking a procedure directly ...
– 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.

68

34
 8/15/2022

Implicit Invocation Style

(Cont’d)
• An event announcement “implicitly” causes the
invocation of procedures in other modules.

procedure procedure procedure

Broadcasting System

69

Implicit Invocation Invariants

• 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).

70

35
 8/15/2022

Implicit Invocation
Specializations
• Often connectors in an implicit invocation
system include the traditional procedure
call in addition to the bindings between event
announcements and procedure calls.

71

Implicit Invocation Examples

• Used in programming environments to

integrate tools:
– 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.

72

36
 8/15/2022

Implicit Invocation
Examples (Cont’d)
• 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.

73

Implicit Invocation Advantages

• 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.

74

37
 8/15/2022

Implicit Invocation
Disadvantages
• When a component announces an event:
– 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

75

Layered Style

• 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.

76

38
 8/15/2022

Layered Style (Cont’d)

• Components: are typically collections of

procedures.
• Connectors: are typically procedure calls
under restricted visibility.

77

Layered Style (Cont’d)

Useful System

sets of
procedures
Basic Utilities

Core Layer

procedure
calls

78

39
 8/15/2022

Layered Style Specializations

• Often exceptions are made to permit non-

adjacent layers to communicate directly.
– This is usually done for efficiency reasons.

79

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
– Unix

80

40
 8/15/2022

Unix Layered Architecture

System Call Interface to Kernel

Plain Cooked
Socket
File Cooked Raw Raw TTY
Block Block TTY
File Interface Interface Interface Line
Protocols
System Disc.

Network
Block Device Driver Character Device Driver
Interface

Hardware

81

Layered Style Advantages

• Design: based on increasing levels of

abstraction.
• Enhancement: Changes to the function of
one layer affects at most two other layers.
• Reuse: Different implementations (with
identical interfaces) of the same layer can be
used interchangeably.

82

41
 8/15/2022

Layered Style Disadvantages

• Not all systems are easily structured in a

layered fashion.
• Performance requirements may force the
coupling of high-level functions to their
lower-level implementations.

83

Interpreter Style

• Suitable for applications in which the most

appropriate language or machine for
executing the solution is not directly available.

84

42
 8/15/2022

Interpreter Style (Cont’d)

• 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.

85

Interpreter Style (Cont’d)

Memory

Current State
inputs Program
of
Being
Program Being
Interpreted
Interpreted

Computation
State Machine store

selected
outputs instruction Current
Execution State of
Engine Execution
Selected Engine
data (fetch)

86

43
 8/15/2022

Interpreter Style Examples

• Programming Language Compilers:
– Java
– Smalltalk
• Rule Based Systems:
– Prolog
– Coral
• Scripting Languages:
– Awk
– Perl

87

Interpreter Style Advantages

• Simulation of non-implemented hardware.

• Facilitates portability of application or
languages across a variety of platforms.

88

44
 8/15/2022

Java Architecture

Java Bytecode
Source Verifier
Code
Class
Loader

Java Interpreter
Compiler

INTERNET Run-time
Environment

Java Hardware
Bytecode

89

Interpreter Style Disadvantages

• Extra level of indirection slows down

execution.
• Java has an option to compile code.
– JIT (Just In Time) compiler.

90

45