Luca Dan Serbanati - Software Design Techniques 1

SOFTWARE DESIGN
TECHNIQUES

prof. Luca Dan Serbanati

2009
Luca Dan Serbanati - Software Design Techniques 2

REVIEW
The scope: to establish The scope: to discover The scope: to identify The scope:
a problem definition the resources required an architecture where 1 Define the internal
1.Define
that will guide the rest by the problem domain. user expectations implementation of each
of the project. For each resource, (security, number of problem domain
define its purpose and users, data and resource.
the interface it supports.
supports processing distribution
distribution, 2.
2 Add the classes that
shared resources, enable the software
response time) could be to support the use of
placed. the resources.
3 Iterate through the
3.
model to enhance and
refine it.

Our Project Lifecycle

The scope: to create The scope: 1.to validate the finished application; 2. to plan the rollout of
the solution specified by completed system(s); 3. to coordinate manual and automated portions of
the software's design. the system; 4. training users on the features and mechanics of the system
 UML Diagrams
g
Use-case
diagram Statechart
Class diagram diagram
add file

DocumentList

Use Case 1 FileMgr

Document

add( )

Actor A Actor B fetchDoc( ) delete( )

name : int

docid : int
sortByName( )
numField : int

add file [ numberOffile==MAX ] / Writing

get( )
flag OFF
open( ) read() fill the

Use Case 2 close( ) code..

read( )
Openning
FileList
sortFileList( )

fLi t
fList
create( )

fillDocument( )
add( ) close file
delete( )
1

Use Case 3 close file

Closing
Reading

rep

Deployment
File
Repository

(from Persistence) GrpFile

read( )

diagram
name : char * = 0

read( )
readDoc( )
open( )
readFile( )
create( )

fillFile( )

Collaboration diagram
9: sortByName ( )
Repository DocumentList

Windows9
mainWnd : MainWnd 5

FileManager
1: Doc view request ( )

2: fetchDoc( )

4: create ( ) gFile : GrpFile Document Ŭ¶óÀ̾ðÆ®.EX

E ¹®¼-°ü¸®
¾ÖÇø´

8: fillFile ( )
N
T

user : Clerk Solari

s

fileMgr : FileMgr ¹®¼-°ü¸®

¿£Áø.EXE

3: create ( ) GraphicFile
UNI
ÀÀ¿ë¼-¹ö.EX X
6: fillDocument ( )
E

File FileList

IBM
7: readFile ( ) Mainframe

5: readDoc ( )

document : Document
repository : Repository
µ¥ÀÌŸº£À̽º¼-¹
ö

Component
user
mainWnd fileMgr :
FileMgr
document :
Document
gFile repository
diagram
Target
g
System
2: fetchDoc(
)

3: create (
)

5: readDoc (
)

È-ÀÏ°ü¸®ÀÚ´Â Àоî¿Â 6: fillDocument (

)

Forward and Reverse

°´Ã¼¿¡ ¼³Á¤À»
¿äûÇÑ´Ù.

È-¸é °´Ã¼´Â ÀоîµéÀÎ

°´Ã¼µé¿¡ ´ëÇØ À̸§º°·Î

º¸¿©ÁØ´Ù
.
9: sortByName (
)
Engineering
Sequence
diagram
Luca Dan Serbanati - Software Design Techniques 5

UP: Design
Model
 Domain Model
Captured-on Register Catalog
Sale

R l ti
Relations
... 1 1 ... ...

domain Use-Case Model

concepts
p
:System
between
bet ee
artefacts in the
Process Sale
system makeNewSale()
1. Customer arrives Process
events enterItem Sale
… (id, quantity)
2. Cashier makes
new sale.
3. … ….
UP model
Use Cases System Sequence UseCase
Diagrams Diagrams

use-case Design Model

realization with
interaction : Register : Catalog
diagrams
makeNewsale()
create() : Sale
Conceptual
classes in the enterItem(id, quantity) spec:=getSpecification(id)
domain
inspire the addLineItem(spec, quantity)
names of ...
The design classes
some software discovered while
classes in the designing UCRs
design can be summarized
in class diagrams
Register Catalog
1 1 …..
makeNewSale() getSpecification(….):ProductSpecification
enterItem(….) ….
….
Luca Dan Serbanati - Software Design Techniques 7

UP: Deriving
the Design
g
Model
Luca Dan Serbanati - Software Design Techniques 8

Design
g Class Diagram
g
 Package
g Diagram
g
• UML package diagrams are often used to illustrate the logical architecture of
a system, the layers, subsystems, Java packages, etc.
• A layer can be modeled as a UML package
package.
• A UML package diagram provides a way to group elements: classes, other
packages, use cases, anything. Nesting packages is very common.
Package Dependency Generalization

Stereotype “Contains” and “uses” relationships

XX

<<subsystem>>
y
(from XX) (from XX)

global

• UML standard stereotypes: façade, framework , stub , subsystem, system .

Luca Dan Serbanati - Software Development Methods 9
 Luca Dan Serbanati - Software Development Methods

Alternative ways to represent

packages

10
 Luca Dan Serbanati – Software Development Methods

Package Diagram - Exemple

OrderCapturing UI AWT E-mail List UI

Order Capturing E-mail

Application Application

Orders Clients

Oracle Interface

<<abstract>>
Database
Interface SQL Server
Interface

A UML package
k represents
t a namespace
11
 Nested
ested Package
ac age Diagram
ag a
Order Capturing UI AWT E-mail List UI

E-mail
Application
Order Capturing
Application

Domain

Orders Clients
(from Domain) (from Domain)

<<global>>
l b l

Oracle Interface

<<abstract>>
abstract
Database
Interface SQL Server
Interface
Luca Dan Serbanati - Analisi e progettazione dei sistemi in UML 12
Luca Dan Serbanati - Software Design Techniques 13

PART II. ARCHITECTING

SOFTWARE SYSTEMS
 Software Architecture
• Software architecture is a body of methods and
techniques that helps us to manage the complexities
of software development.
• Software architecture is a natural extension of the
software
ft engineering
i i di
discipline.
i li IIn early
l lit
literature
t it
was simply referred to as programming in the large.
• Software architecture design
g is not entirely y different
from existing software design methodologies.
14
Luca Dan Serbanati - Software Design Techniques 15

Types of Architecture
In the IT industry, the term architecture is used to refer to several things.
From the enterprise point of view, there are four types of architecture:
– Business
B siness architecture.
architect re
– Information technology (IT) architecture.
– Information architecture.
– Application (software) architecture.
Collectively, these architectures are referred to as enterprise architecture.
 Luca Dan Serbanati - Software Design Techniques 16

Business Architecture
• Business architecture defines the business strategy, governance,
organization, and key business processes within an enterprise. The field of
business process reengineering (BPR) focuses on the analysis and design
of business processes, not necessarily represented in an IT system. The
business architecture is mapped to the IT architecture
architecture.
Luca Dan Serbanati - Software Design Techniques 17

Information Technology Architecture

• Information technology (IT) architecture defines the hardware and
software building blocks that make up the overall information system of
the organization. The IT architecture should enable achievement of the
business goals using a software infrastructure that supports the
procurement, t development,
d l t and
dddeployment
l t off core mission-critical
i i iti l
business applications. IT investment should meet its business needs by
providing a foundation for data and application architectures.
Luca Dan Serbanati - Software Design Techniques 18

Information Architecture
• Information architecture includes logical and physical data assets and
data management resources. Information is becoming one of the most
important assets a company has in achieving its objectives, and the IT
architecture must support it.
Luca Dan Serbanati - Software Design Techniques 19

Application
pp Architecture
• Application (software) architecture serves as the blueprint for individual
applications systems, their interactions, and their relationships to the
business processes of the organization. The application architecture is
commonly built on top of and utilizes the services of the IT architecture.
• Application architecting is more than the specification of the internal physical
structure of the software. It involves creating models of the problem in order
to simplify and understand the problem and creating implementation-
independent models of the solution that address those problems
problems, for
example, creating business process workflows and reviewing these with the
end users. It also involves user interface and interaction design.
Luca Dan Serbanati - Software Design Techniques

Software Architecture
Software Architecture = the set of significant decisions about the organization
of a software system, the selection of the structural elements and their
interfaces by which the system is composed, together with their behaviour
as specified
ifi d in
i the
th collaborations
ll b ti among th
those elements,
l t th
the composition
iti off
these structural and behavioural elements into progressively larger
subsystems, and the architectural style that guides this organization these
elements and their interfaces, their collaborations, and their composition
Software architecture presents a view of a software system as components and
connectors.
– Components encapsulate some coherent set of functionality.
– Connectors realize the runtime interaction between components.
The system design achieves certain qualities based on its composition from
components and connectors.
An architecture style defines a family of systems in terms of a pattern of
structural organization
organization. It should contain:
– a vocabulary of components and connector types
– a set of constraints on how they can be combined
– one or more semantic models that specify how a system’s
system s overall
properties can be determined from the properties of its parts.
20
 Luca Dan Serbanati - Software Design Techniques 21

Architectural Views
Characteristics
Ch t i ti off a good d architecture:
hit t
– Flexible
– Simple
– Approachable
– Clear separation of concerns
– Balanced distribution of responsibilities
p
– Balances economic and technology constraints.
An architectural view is
a simplified description
(an abstraction) of a Logical View Implementation View
system from a particular
perspective
p p or vantage
g End-user
Programmers
point, covering particular Functionality Software management
concerns, and omitting Use Case
entities that are not View
relevant
l t tto this
thi
perspective. Process View Deployment View
System integrators System engineering
Performance System topology
Scalability Delivery installation
Delivery,
Throughput Communication

Conceptual Physical
Luca Dan Serbanati - Software Design Techniques

Logical
g Architecture
Logical architecture = the large-scale organization of the software classes into
packages (or namespaces), subsystems, and layers (“logical” because
there's
there s no decision about how these elements are deployed across different
operating system processes or across physical computers in a network.
These latter decisions are part of the deployment architecture).
L
Layer = a very coarse-grained
i d grouping
i off classes,
l packages,
k or subsystems
b t
that has cohesive responsibility for a major aspect of the system. Also,
layers are organized such that "higher" layers (such as the UI layer) call
upon services of "lower" layers, but not normally vice versa.
Typically layers in an OO system include:
– User Interface.
Interface
– Application Logic and Domain Objects software objects representing
domain concepts that fulfill application requirements.
– Technical Services general purpose objects and subsystems that provide
supporting technical services, such as interfacing with a database or
error logging.
logging These services are usually application-independent
application independent and
reusable across several systems.
22
A logical architecture doesn't have to be organized in layers.
 Luca Dan Serbanati - Software Design Techniques 23

Views on the Software Product Life Cycle

Management View Software Engineering View Architectural View

This view captures how the This view captures how This view represents the
management views the software
ft engineers
i view
i software
ft development
d l t lif
life cycle
l
development life cycle (it is the development life cycle. from the perspective of
seen outside of engineering) architecting concerns, activities,
and artifacts.
Luca Dan Serbanati - Software Design Techniques 24

The Architecture Design Process

The basic architecture design process is composed of these steps:
1. Understand the p problem in order to avoid the implementation
p trap
p
(end up focusing their efforts on solving technical problems that
ultimately do not address the original problem).
2 Identify design elements and their relationships
2. relationships. We perform a naive
functional decomposition of the application, which establishes a
baseline for future design tasks and design transformation.
3 Evaluate the architecture design for assessing the architecture for
3.
conformance to architectural quality attribute requirements. Many
quality attributes can be assessed by inspecting the design or by
i l
implementing
ti prototypes
t t off th
the architecturally
hit t ll significant
i ifi t componentt
interactions.
4. Transform repeatedly the architecture design into a new design that
addresses the quality attribute requirements better than the previous
design.
 Luca Dan Serbanati - Software Design Techniques 25

Representing
p g Design
g Elements ((I))
• Design Elements Representation = A baseline
decomposition that splits the system based on
functional requirements is initially (during the
predesign phase) established.
• The decomposition can be modeled using a design
structure matrix (DSM),
(DSM) which represents the
dependencies between design elements without
prescribing the granularity of the elements.
• The architecture of a software application is often
represented as a set of interconnected modules or
subsystems, often called components. These
modules are organizational constructs that
structure source code, but often are not directly
visible in the source code.
• Source code is an abstraction of machine
instructions and data patterns structured in terms
of a programming language's grammar.
• This physical view of a software application can be
viewed from an even higher-level set of
components called software modules.
 Luca Dan Serbanati - Software Design Techniques 26

Representing
p g Design
g Elements ((II))
• Modules are discrete units of software (binary and source). They have high
internal cohesion and low external coupling.
• Components and connectors describe the physical instantiation of a system
and are run-time instantiations of modules.
• A module may contain several component definitions. The client module
may contain many class definitions for various user interface components
components.
UML Packages Design Structure Matrix (DSM)
 Luca Dan Serbanati - Software Design Techniques 27

Identifying Design Elements and Their Relationships

This initial functional decomposition will undergo many transformations
transformations. The
design elements do not necessarily correspond to physical modules.
The modules will be discovered in time, as the model is refined in subsequent
steps. TheTh identification
id ifi i off d design
i elements
l andd their
h i relationships
l i hi can b be
further subdivided into the following steps:
1. Define the system context. It helps describe the application from an
external perspective, that is, that of the users and operators of the
application or system. The system context is useful in describing the
purpose
p p of the system
y as well as for identifying
y g the external interfaces
to the system. The input to defining the system context is the initial
requirements list.
2 Identify the modules
2. modules. It is the central activity of software architecture
design. A module refers to a unit of software (some set of source code
files) that can be designed, implemented, and compiled into a
deliverable executable system or subsystem; it is a unit of execution
that exhibits high internal cohesion and low external coupling. A
modular architecture is an application that is composed of two or more
modules,
d l each
h off which
hi h can be
b modified
difi d internally
i t ll without
ith t affecting
ff ti th the
other.
3. Describe the components and connectors.
 Luca Dan Serbanati - Software Design Techniques 28

Evaluating
g the Architecture
• The Architectural Design Evaluation = Determine if the system satisfies the
architectural requirements. The design is evaluated in order to gather
qualitative measures or quantitative data
data, both of which are metrics.
metrics Each
metric is then compared to the quality attribute requirements.
• It is not enough to say "the system must be fast" or "the system must be
easy to modify or adapt to customer needs." These statements may be
acceptable in an initial requirements list, but they are not specific enough to
evaluate the designg against.
g Such requirements must first be articulated as
specific quality attributes and their acceptable values.
• A performance quality attribute will usually be stated as some numeric range
or set of ideal numbers
numbers, but most quality attributes are not quantitative in
nature so their values may not be numeric. For instance, a modifiability
requirement may be reified as a scenario called a change case.
 Luca Dan Serbanati - Software Design Techniques 29

Transforming the Architecture

There are six modular operators (concerned with the module view of the
system):
– Splitting
S litti a design
d i iinto
t ttwo or more modules
d l
– Substituting one design module for another
– Augmenting the system by adding a new module
– Excluding a module from the system
– Inverting a module to create new interfaces (design rules)
– Porting g a module to another system.
y
and five basic design operators (concerned with the runtime component
view of the system):
– Decomposition of a system into components
components.
– Replication of components to improve reliability.
– Compression of two or more components into a single component to
improve performance
performance.
– Abstraction of a component to improve modifiability and adaptability.
– Resource sharing, or the sharing of a single component instance with
other
th components t to
t improve
i i t
integrability
bilit (the
(th ability
bilit tto iintegrate
t t
applications and systems), portability, and modifiability.
 Luca Dan Serbanati - Software Design Techniques 30

Modeling the Problem and Solution Domains

• Models can be divided into two groups:

– The problem domain models are created during analysis and their goal is
to minimize the semantic gap between the real system (for example, an
enterprise)
t i ) andd it
its representation
t ti models
d l iin order
d tto achieve
hi the
th quality
lit
attributes we are trying to promote.
• systems analysis models is the result of modeling of a system in
order to understand its behavioral characteristics;
• requirements analysis models are specifications of all known system
functions and quality attributes. The requirements specification is a
response to a recognized need of stakeholders
stakeholders.
– The solution domain models are created during design and their goal of
is to form a chain of models from the problem domain models to the
implementation by reducing the semantic gap between these models models.
• platform- or technology-independent models (PIM) are specified in a
language that generalizes services without specifying a platform;
• pplatform- or technology-specific
gy p models map p a PIM to a specific
p
technology platform or programming language, tracing the
generalized services to specific technologies and the generalized
system structures to programming language constructs.
 Luca Dan Serbanati - Software Design Techniques 31

Architectural Views
• Models may be classified by or organized into viewsviews.
• An Architectural View is a representation of a system from the perspective
of a related set of concerns (e.g. a concern in a distributed system is how
the software components are allocated to network nodes)nodes). This
representation is comprised of a set of system elements and the
relationships associated with them.
• Views are aspects or dimensions of an architectural model. A view can
contain either problem domain models or solution domain models.
• The types of the elements and the relationships as well as other meta-
information on the views are described by y the Viewpoint
p in order to
document and communicate views unambiguously.
• Views are instances of viewpoints because the elements and relationships
contained in the View are instances of the corresponding types of elements
and relationships contained in the Viewpoint.
An Architectural Pattern defines types of
elements and relationships that work together in
order to solve a particular problem from some
perspective. It is a specialization of a viewpoint
since it provides specialized semantics to the
types of elements and relationships, as well as
constraints upon them.
 Luca Dan Serbanati - Software Design Techniques 32

Architectural Views
– Objectives/purpose describes what is needed.
– Behavior/function describes what the system does to satisfy the
objectives (it is compulsory for information systems).
– Information/data describes the information created by and retained in
the system (it is compulsory for information systems).
– Form/structure describes the physical structure of the software (for
example, modules and components).
– Performance describes how effectively the system performs its
functions.
• Other views can be added for more recent systems:
– Deployment view,
– User and external systems interaction view
view,
– Technological view, how commercial or standard technologies are used
• The architect must determine which views are most critical to the software
system's success.
 Luca Dan Serbanati - Software Design Techniques 33

Objectives and Purpose Models

• One of the roles of the architect is to help the client identify the system's
objectives and priorities.
• Some objectives can be stated and measured precisely; others are abstract
and cannot be expressed quantitatively: functional objectives can be
specified with precision, but objectives such as maintainability are harder to
define. These models are referred to as requirements analysis models.
• Refinement of objectives is a key to successful design.
• Some objectives can be captured in a use case model which is a functional
model.
• A requirements specification represents a family of solutions. The
experienced architect knows which aspects of the requirements are most
critical and can p
potentially
y narrow the wide rangeg of p possible solutions.
Likewise, any number of implementations (detail designs) can derive from a
given architectural description.
It is important that the architect strive toward
understanding a problem before getting too
deeply into design. This principle applies at all
design phases and for every model being
created. The first architectural response to the
objectives will itself introduce new problems.
 Luca Dan Serbanati - Software Design Techniques 34

Behavioral/Functional Models
• Functional or behavioral models specify what the system does. These
models are a response to the functional objectives in the objectives models.
• In modern software development, we usually only start with a partially
specified behavior model because we usually do not have a complete set of
fully
y defined requirements
q and objectives
j before design
g begins.
g
• This is why we promote iterative refinement of requirements and system
design. We create models of the target system, and we test or measure
these models against the desired quality attributes
attributes.
• There are several kinds of behavioral models:
– User interface prototypes
p yp
– Scenarios and threads
– State transition diagrams
– Process models .
Luca Dan Serbanati - Software Design Techniques 35

ARCHITECTURAL STYLES
AND PATTERNS
Luca Dan Serbanati - Software Design Techniques 36

Architectural
c tectu a p
Architectural
process
ocess = A seque
sequence
ce o
of act
Design
activities
t es tthat
at lead
ead to tthe
epproduction
oduct o oof
architectural artifacts: a software architecture description and an architectural
prototype. In order to carry out this process:
Identify, select, and validate “architecturally significant” elements. Not
everything is architecture, but the followings are architecture:
• Main “business” classes
• Important
p mechanisms
• Processors and processes
• Layers and subsystems
• Interfaces.
Interfaces
Architectural Design Workflow
1. Select scenarios: criticality and risk Use case view
2 Identify main classes and their responsibility
2.
Logical view
3. Distribute behavior on classes
4. Structure in subsystems, layers, define interfaces Implementation view
5 Define distribution and concurrency
5.
6. Implement architectural prototype Deployment view
7. Derive tests from use cases Process view
8 Evaluate
8. E l t architecture
hit t
Iterate
Result: A Software Architecture Document
Luca Dan Serbanati - Software Design Techniques 37

Elements of Architectural Descriptions

p
Architectural definition of a system includes:
– Components: define the loci of computation
• Examples:
E l filt
filters, d
databases,
t b objects,
bj t ADTs
ADT
– Connectors: mediate interactions of components
p
• Examples: p
procedure call,, p pipes,
p , event broadcast
– Attributes: specify info for construction & analysis
• Examples: signatures, pre/post conditions
A architectural
An hit t l style
t l d
defines
fi a ffamily
il off architectures
hit t constrained
t i db by:
Component/connector vocabulary+Topology rules+Semantic constraints

Ports (Interfaces)

Connector
Component Component

Attributes
Attributes Attributes
Configuration
 Luca Dan Serbanati - Software Design Techniques 38

Components
Components are the basic building blocks and the active computational entities
in a system.
Such a component:
1) encapsulates a subset of the system’s functionality and/or data,
2)) restricts access to that subset via an explicitly
p y defined interface, and
3) has explicitly defined dependencies on its required execution context.
• A Component communicates with its environment (which includes other
components)
t ) through
th h one or more ports
t or interfaces.
i t f
– A port may be: (1) a user interface, (2) a shared variable, (3) a procedure
name that can be called by y another component,
p , ((4)) a set of events that
can be emitted, or (6) some other mechanism.
• Attributes (or properties) of the component specify information for analysis
and development of the software,
software such as protocols
protocols, real
real-time
time constraints,
constraints
and behavioral constraints.
• y aspect
The key p is that any
y component
p can be “seen” by y its users, whether
human or software, from the outside only via the interface it has chosen to
make public.
Luca Dan Serbanati - Software Design Techniques 39

Connectors
Connectors define the interaction between components and describe the
rules that govern those interactions.
• A Connector links the ports of two or more components.
• A Connector has a Role attached to it as an attribute that defines the
behavior of the attached components
components. ee.g.,
g in a unidirectional
communication scheme, one component would be the source, while the
other component would be the receiver.
• A Connector can have other attributes. e.g., rates, capacities, and
latencies.
 Luca Dan Serbanati - Software Design Techniques 40

Configuration
g ((Topology)
p gy)
• A configuration (topology) is a connected graph (a set of specific
associations) of components and connectors that describes the architectural
structure.
structure
• The configuration must:
– Adhere to the rules for proper connectivity.
– Satisfy concurrent and distributed properties
properties.
• Adhere to constraints such as design heuristics (e.g. end-to-end connectivity
may be no longer than five components.) and style rules.
• C fi
Configuration
ti can bbe analyzed
l d ffor: system
t properties
ti such h as performance,
f
bottlenecks, concurrency, system reliability, security, etc.
• A system can have several configurations.

• Example:
 Luca Dan Serbanati - Software Design Techniques 41

Architectural Styles
y and Patterns
An architecture style is a named collection of architectural design decisions that
1) are applicable in a given development context,
context 2) constrain architectural
design decisions that are specific to a particular system within that context,
3) elicit beneficial qualities in each resulting system .
A architectural
An hit t l style
t l iis a ttype off metamodel
t d l th
thatt prescribes
ib a sett off elements
l t
and their relationships that characterize a system based on the style. These
elements are commonly expressed as components and connectors and their
relationships are the constraints on how components and connectors may
be combined.
An architectural pattern is a named collection of architectural design decisions
that are applicable to a recurring design problem, parameterized to account
for different software development contexts in which that problem appears.
Examples:
– Three tiers
– Model-View-Controller
– Sensor-Controller-Actuator
– etc.
Luca Dan Serbanati - Software Design Techniques 42

Software Architectural Styles

y
• Recurring pattern or idiom for expressing software architecture.
• A pattern is a solution to a problem in a context. It codifies specific
knowledge collected from experience in a domain
• All well-structured systems are full of patterns:
– Design patterns
– Architectural
A hit t l patterns.
tt

Classification
C ass ca o o of
architectural
styles
(M. Shaw,
DG l )
D.Garlan)
Luca Dan Serbanati - Software Design Techniques 43

Architectural Style Classification(I)

The Layered View deals with how the system as a complex heterogeneous
entity can be decomposed into interacting parts.
– LAYERS
– INDIRECTION LAYER
– VIRTUAL MACHINE
The Data Flow View deals with how streams of data are successively
processed or transformed by components.
– BATCH SEQUENTIAL
– PIPES AND FILTERS
The Data-centered View is appropriate when the concerns involve how a
central repository of data is accessed by multiple components.
– SHARED REPOSITORY
– ACTIVE REPOSITORY
– BLACKBOARD
Th Adaptation
The Ad t ti ViewVi deals
d l withith how
h th
the system
t adapts
d t ititself
lf d
during
i
evolution.
– MICROKERNEL
– REFLECTION
– INTERCEPTOR
Luca Dan Serbanati - Software Design Techniques 44

Architectural Style Classification (II)

The Language
Th L E
Extension
t i View
Vi is
i concerned d with
ith h
how systems
t offer
ff an
abstraction layer to the computation infrastructure.
– INTERPRETER
– RULE-BASED
RULE BASED SYSTEM
The User Interaction View shows the runtime structure of components that
offer a user interface.
– MODEL-VIEW-CONTROLLER
– PRESENTATION-ABSTRACTION-CONTROL
– C2
The Component Interaction View focuses on how individual components
exchange messages but retain their autonomy.
– EXPLICIT INVOCATION (called “communicating processes”)
– IMPLICIT INVOCATION (also called “eventevent systems
systems” in)
– CLIENT-SERVER
– PEER-TO-PEER
– PUBLISH-SUBSCRIBE ((called “publisher-subscriber”).
p )
The Distribution View tackles concerns about disseminating components in
a networked environment.
– BROKER
– REMOTE PROCEDURE CALLS (called “distributed objects” )
– MESSAGE QUEUING (called “messaging” )
Luca Dan Serbanati - Software Design Techniques 45

Layered View
In the Layered View the system is viewed as a complex heterogeneous entity
that can be decomposed into interacting parts of distinct, related
responsibilities, with a clean, cohesive separation of concerns with each other
The design concerns addressed by this view are:
• What are the parts that make up the whole system?
• How do these parts interact with each other?
• How do the parts perform their functionality and still remain decoupled from
each other?
• How are the quality attributes of modifiability, scalability, and integrability
supported?
 Luca Dan Serbanati - Software Design Techniques 46

Rationale for the Layers

y Pattern
Consider a system in which high-level components depend on low-level
components to perform their functionality
functionality, which further depend on even
lower-level components and so on. Decoupling the components in a vertical
manner is crucial in order to support modifiability, portability, and reusability.
On the other hand components also require some horizontal structuring that
is orthogonal to their vertical subdivision.
To achieve these goals, the system is structured into LAYERS so that each
layer provides a set of services to the layer above and uses the services of
the layer below. Within each LAYER all constituent components work at the
same level of abstraction and can interact through g connectors.
Between two adjacent layers a clearly defined interface is provided. In the pure
form of the pattern, layers should not be by-passed: higher-level layers
access lower
lower-level
level layers only through the layer beneath
beneath.
 Luca Dan Serbanati - Software Design Techniques 47

Layered Architecture (I)

Layered
Architecture Procedure
call
Subsystems
Virtual
machine
Procedure
call Utilitaries
Virtual
machine
Core
Layer

Users
Characteristics:
• A hierarchically layered system consists of a large software application that
is partitioned into layers that is components that are decoupled as much as
possible from one another.
• Each layer acts as a virtual machine for the layers above it, providing
services to those layers
layers. In turn
turn, it acts as a client to the layers below itit.
• Communication between layers occurs through connectors that include
appropriate well-defined APIs interfaces, states, and interaction protocols.
 Luca Dan Serbanati - Software Design Techniques 48

Layered Architecture (II)

Examine
E i ththe llayers off th
the system
t using
i th
the ffollowing
ll i criteria:
it i
1. There are no more than seven (plus or minus two) layers.
2. The rationale for each layer definition is clearly presented and consistently
applied.
li d
3. Layer boundaries are respected within the design.
4. Layers are used to encapsulate conceptual boundaries between different
kinds of services and provide abstractions to make the design easier to
understand.
Advantages :
• The layers support designs based on increasing abstraction levels that
allows designer to partition a complex problem into a sequence of
incremental steps.
• The layers promote changes
changes. A change in a layer implies changes only in
the neighbouring layers.
• The layers support reuse. Two implementations of the same layer can be
exchanged
e c a ged oneo e for
o the
t e other
ot e if they
t ey expose
e pose thet e same
sa e interfaces
te aces to tthe
e
adjacent layers.
Disadvantages:
y
• The layered architecture can not be universally y used. Theyy are systems
y that
can not be structured according to this architecture: the definition of layers
accordin to abstraction lavels can not be always easily obtained.
• Often the independence of layers can not be efficiently maintained.
Luca Dan Serbanati - Software Design Techniques

Layered
Architecture (III)
Layered
y Patern

Layer

Package

Characteristics
The system structure is partitioned system into discrete layers of distinct,
related responsibilities of use-cases or classes and interface , with a clean,
cohesive separation of concerns such that the "lower" layers are low-level
and general services, and the higher layers are more application specific.
The lower layer has an interface with hardware components or with the
operating
p g system
y and the highest
g layer
y contains the application
pp objects
j .
The architecture is very portable. The lower layers are reusable with various
higher layers for the same platform. The
49 higher layers are reusable for
various platforms.
 Luca Dan Serbanati - Software Design Techniques

Common Layers in Logical Architecture

50
Luca Dan Serbanati - Software Design Techniques

Benefits in Using
g Layers
y
• In general, there is a separation of concerns, a separation of high from low-
level services
services, and of application-specific
application specific from general services
services. This
reduces coupling and dependencies, improves cohesion, increases reuse
potential, and increases clarity.
• Related
R l t d complexityl it is
i encapsulated
l t d and
d decomposable.
d bl
• Some layers can be replaced with new implementations. This is generally
not ppossible for lower-level Technical Service or Foundation layers y (e.g.,
( g
java.util), but may be possible for UI, Application, and Domain layers.
• Lower layers contain reusable functions.
• Some
S layers
l ((primarily
i il th
the D
Domain i and
dT Technical
h i lSServices)
i ) can b
be
distributed.
• Development
p by
y teams is aided because of the logical
g segmentation.
g
Note. The domain layer is part of the software and the domain model is part
of the conceptual-perspective analysis they aren't the same thing. But by
creating a domain layer with inspiration from the domain model model, we achieve
a lower representational gap, between the real-world domain, and our
51
software design.
Luca Dan Serbanati - Software Design Techniques

Domain Layer
y vs. Domain Model

52
Luca Dan Serbanati - Software Design Techniques

Layers
y and Partitions
• The original notion of a tier in architecture was a logical layer, not a physical
node, but the word has become widely used to mean a physical processing
node (or cluster of nodes)
nodes), such as the "client
client tier"
tier (the client computer)
computer).
• The layers of an architecture are said to represent the vertical slices, while
partitions represent a horizontal division of relatively parallel subsystems of
a layer.

Example 1 Example 2
Partitions
Application package
Wi d
Window
Graphics
Layers

User Dialog Screen

Simulation
Control Graphics
Pixel
Graphics
Operating System
Computer
p hardware

53
Luca Dan Serbanati - Software Design Techniques

Mixing
g views of the architecture

54
 Luca Dan Serbanati - Software Design Techniques 55

Motivation
Indirection Layer
A sub-system should be accessed by one or more components, but direct
access to the subsystem is problematic. For instance, the components
should not get hard
hard-wired
wired into the subsystem,
subsystem instead the accessors for the
sub-system should be reused. Or the access should be defined in a way that
it can be flexibly adapted to changes. The same problem appears at different
levels of scale: it can happen between two ordinary components in one
environment, components in two different languages, components in two
different systems (e.g. if a legacy system is accessed).
Solution
An INDIRECTION LAYER is a LAYER between the accessing component
and the “instructions” of the sub-system that needs to be accessed. The
general term “instructions”
instructions can refer to a whole programming language
language, or
an application programming interface (API) or the public interface(s) of a
component or sub-system, or other conventions that accessing components
must follow.
follow The INDIRECTION LAYER wraps all accesses to the relevant
sub-system and should not be bypassed.
The INDIRECTION LAYER can perform additional tasks while deviating
i
invocations
ti tto th
the subsystem,
b t such
h as converting
ti or ttracing
i ththe iinvocations.
ti
The INDIRECTION LAYER pattern is a foundation for the architectures of
INTERPRETER, VIRTUAL MACHINE, and RULE-BASED SYSTEM.
 Luca Dan Serbanati - Software Design Techniques 56

Indirection Layer
y Example
p

• The INDIRECTION LAYER can either be integrated to the sub-system

sub system (as in
“virtual machine” or be an independent entity (as in ADAPTER or FACADE)
that forwards the invocations to the sub-system. In both cases the accessing
components are not aware of this,
this since the INDIRECTION LAYER aims at
exactly that: hiding whatever it is that provides the services.
 Luca Dan Serbanati - Software Design Techniques 57

Data Flow View

In the Data Flow View the system is viewed as a number of subsequent
transformations upon streams of input data. The availability of data controls the
computational process. Data flow conceptual elements: process, file, data
flow .The design concerns addressed by this view are:
• What are the elements that perform the transformations?
• What are the elements that carry the streams of data?
• How are the types of elements connected to each other?
• How are the quality attributes of modifiability, reusability, and integrability
supported?
The components are independent of one another, and have input and output
ports. Connectors are streams of data and similarly have data-in and data-out
roles. The relationships between these elements are attachments that connect
input
p p ports of components
p to data-out roles of connectors, and output p pports of
components to data-in roles of connectors.
• Common forms: Batch sequential, Pipes and filters
Luca Dan Serbanati - Software Design Techniques

Dataflow Systems
• Dataflow systems are characterized by how data moves through the system system.
Dataflow architectures have two or more data processing components that
each transform input data into output data.
Pi li architectural
Pipeline hit t l style
t l : it is
i limited
li it d tto a lilinear sequence off filt
filters. V
Version:
i
Bounded pipes, Typed pipes

• It is common in a pipes-and-filters architecture that a processing component

has two outputs, a standard output and an error output and a single input
called standard input. Generically, the input and output mechanisms for a
given processing element are called ports.
Pipes-and-filters architectural style.
pipe
p p
filter
filter pipe filter
filter
Pipes and filters

• It is possible to define more complex processing elements to produce even

more complex arrangements and data flows.
Dataflow with complex processing components.
Luca Dan Serbanati - Software Design Techniques 59

Data Flow System:

y Implementation
p
• Components communicate by passing messages through
unidirectional ports
• Components can have one or more I/O ports.

Connector Connector
Component Component Component

• Each component is isolated from performance of upstream

component. If an upstream component computes faster than its
downstream neighbour,
neighbour the results accumulate in the buffer until used
used.
Physical hardware/software limitations impose a finite size on the
buffer causing overflow error.
• Order of processing by components matters.
• Components may be memoryless (no internal state preserved) or with
memory Only memoryless components can be replaced at runtime
memory. runtime.
Luca Dan Serbanati - Software Design Techniques 60

Types
yp of Data Flow Systems
y
• Transform flow: incoming input data is transformed within the system
into an internal form. While the information is in the system, it may be
subject to further transformations of its internal form. Finally, outgoing
data is transformed within the system from an internal form to its
external form.
• Transaction flow: a single input item triggers data flow along several
action paths. Many interactive systems and query/response systems
fit this model
model. Each element along the data flow path usually has
multiple outputs. Some elements are incorporated solely as junctions
to recombine separate paths.
Transaction
Entering flow Exiting flow
Transactional
External centre
representation
on
Informatio

Flow in
transformation Action path

Internal
representation

Time
Luca Dan Serbanati - Software Design Techniques 61

Batch Sequential
q Systems
y
• A batch sequential system is a collection of programs that are arranged and
executed sequentially.
• Each
E h program runs tto completion.
l ti D
Data
t iis ttransmitted
itt d between
b t the
th programs
via files stored on external storage. A program reads data from one or more
files, processes it, and writes one or more files before exiting. Then the next
program, if there is one, is initiated.
1. UNIX pipe command:
cat foo
foo.txt
txt | grep “bar”
bar | sort > baz
baz.txt
txt

cat grep sort

ba t t
baz.txt
foo.txt

Properties
2. Master file processing system:
•Low memoryy requirement
q
Data
Data Set Data Data • High latency for I/O
Set Set
Set
Edit Sort Update Report • Limited opportunity for concurrency
• Limited opportunity for synchronization
Data • Unable to support interactive systems
Set -> e.g., cannot interrupt the Unix pipe
Luca Dan Serbanati - Software Design Techniques 62

Batch Sequential
q Style
y
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
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.
When can we use it?
Consider a complex task that can be sub-divided into a number of smaller
tasks, which can be defined as a series of independent computations. This
should not be realized by one monolithic component because this
component would be overly complex, and it would hinder modifiability and
reusability.
Luca Dan Serbanati - Software Design Techniques 63

Pipe and Filter Systems (I)

input

input
output
A pipe and filter architecture is
one in which one or more data
pipe sets are processed in discrete,
filter
output separable stages. Each stage is
filter pipe filter
filter represented by a component
component.
Pipes and filters

• A component
p operates
p on the entire data set and p
passes its results along
g to
the next stage: local transformation of input stream/incremental computation
(-> Filter)
• Connectors between components serve as link (-> ( > Pipe)
Properties:
• Pure data-driven interaction
• Each component has a set of inputs and a set of outputs
• Data transmitted as a whole between Filters
• Filters are independent programs
• Each
E h ttransformation
f ti step
t runs to
t completion
l ti before
b f nextt step
t starts
t t
• Filters ignore identity of upstream/downstream filters
• Correctness of output depends on the order of filters.
Luca Dan Serbanati - Software Design Techniques 64

Pipe
p and Filter Systems
y ((II))
Pipelines – the filters are in linear sequence.
Bounded pipes – the data quantity in a pipe is bounded
Typed pipes – the pipes are typed (the data are of certain types only)

Characteristics:
Ch i i
• Filter
– Incrementally transform some amount of the data at inputs to data at
outputs
• Stream-to-stream transformations
– Use little local context in p
processing
g stream
– Preserve no state between instantiations
• Pipe
– Move data from a filter output to a filter input
– Pipes form data transmission graphs
• Overall Computation
– Run pipes and filters (non
(non-deterministically)
deterministically) until no more computations
are possible.
Luca Dan Serbanati - Software Design Techniques 65

Pipe and Filter Systems: Advantages/Disadvantages

Advantages
• Allow designers to understand system input/output behavior as simple
composition of the behaviors of individual filters
filters.
• Support of reuse: any two filters can be hooked together, provided they
agree on the data transmitted between them.
• Easy maintenance: new filters can be added; old filters can be replaced by
improved ones.
• Allow for throughput and deadlock analyses
analyses.

Disadvantages
• Order of filters matters: should be
decided by the designer
• Difficult to maintain correspondences between two separate but related
streams
• Multiple I/O problem: difference in arrival data rates can impose a
performance bottleneck in the system.
Luca Dan Serbanati - Software Design Techniques 66

Pipe-and-filter
p
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 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
programming.
Cautions: When complex data structures must be exchanged between filters;
when interactivity between the program is required.
Relations to programming languages or environments: Prevalent in Unix shell.
 Luca Dan Serbanati - Software Design Techniques 67

C
Consider
id the
h case where
h
Applicability
pp
a complex
l task
k can b
y
be sub-divided
b di id d iinto a number
b off
smaller tasks, which can be defined as a series of independent
computations. Additionally the application processes streams of data, i.e. it
t
transforms
f input
i t data
d t streams
t into
i t output
t t data
d t streams.
t This
Thi functionality
f ti lit
should not be realized by one monolithic component because this
component would be overly complex, and it would hinder modifiability and
reusability Furthermore
reusability. Furthermore, different clients require different variations of the
computations, for instance, the results should be presented in different ways
or different kinds of input data should be provided. To reach this goal, it must
be possible to flexibly compose individual sub sub-tasks
tasks according to the client
client’s
s
demands.
In a PIPES AND FILTERS architecture a complex task is divided into several
sequential subtasks.
subtasks Each of these sub-tasks
sub tasks is implemented by a separate
separate,
independent component, a filter, which handles only this task. Filters have a
number of inputs and a number of outputs and they are connected flexibly
using pipes but they are never aware of the identity of adjacent filters.
Each pipe realizes a stream of data between two components. Each filter
consumes and delivers data incrementally, which maximizes the throughput
of each individual filter,, since filters can potentially
p y work in parallel.
p Pipes
p act
as data buffers between adjacent filters. The use of PIPES AND FILTERS is
advisable when little contextual information needs to be maintained between
the filter components and filters retain no state between invocations.
Luca Dan Serbanati - Software Design Techniques 68

Data-centered
View
Vi
In the Data-centered View the system is viewed as a persistent, shared data
store that is accessed and modified by a number of elements. The concerns
addressed by this view are:
• How is the shared data store created, accessed, and updated?
• How is data distributed?
• Is the data store passive or active, i.e. does it notify its accessors or are the
accessors responsible of finding data of interest to them?
• How does the data store communicate with the elements that access it?
• Do the accessor elements communicate indirectly through the shared data
or also directly with each other?
• How are the quality attributes of scalability, modifiability, reusability, and
integrability supported?
Luca Dan Serbanati - Software Design Techniques 69

Data
ata Ce
Centered
te ed Syste
Systems
s
trans1 trans2
computation
ks1 ks3
Bl kb d
Blackboard

memoriy
trans3
Database direct
computation access
Blackboard
access
transaction to data trans4
database ks2
transaction
ks: knowledge source ks4
Shraed-repository

• A blackboard is a database into which a

process can insert, retrieve, or remove data.
• Blackboard approaches allow multiple
processes (or agents) to communicate by
reading and writing requests and information
to a global data store.
Luca Dan Serbanati - Software Design Techniques 70

Shared Repository
p y
• When transforming a conceptual domain into a technical software
architecture we must sometimes provide a design for applications whose
parts operate on, and coordinate their cooperation via, a set of shared data.
• Some applications are inherently data-driven: interactions between
components do not follow a specific business process, but depend on the
data on which they operate
operate.
Solution:
• Maintain all data in a central repository shared by all functional components
of the data-driven application and let the availability, quality, and state of that
data trigger and coordinate the control flow of the application logic.
Luca Dan Serbanati - Software Design Techniques 71

Active Repository
A system needs to have a SHARED REPOSITORY, but it should not just be
passively accessed by accessor components
components. Clients need to be
immediately informed of specific events in the shared repository, such as
changes of data or access of data. “Polling” (i.e. querying in frequent
intervals) the SHARED REPOSITORY for such events does not work work, for
instance, because this does not deliver timely information or inflicts
overhead on the system performance.
An ACTIVE REPOSITORY is a SHARED REPOSITORY that is “active” in the
sense that it informs number of subscribers of specific events that happen
in the shared repository.
p y The ACTIVE REPOSITORY maintains a registry g y
of clients and informs them through appropriate notification mechanisms.
• The notification mechanism can be realized using ordinary EXPLICIT
INVOCATIONS but in most cases IMPLICIT INVOCATIONS,
INVOCATIONS, INVOCATIONS such as
PUBLISH-SUBSCRIBE, are more appropriate.
Luca Dan Serbanati - Software Design Techniques 72

•
Blackboard System
Consider the case where a SHARED REPOSITORY is needed for the
shared data of a computation, but no deterministic solution strategies are
known. Examples are image recognition or speech recognition applications.
• In a BLACKBOARD architecture the complex p task is divided into smaller
sub-tasks for which deterministic solutions are known.
• The BLACKBOARD is a SHARED REPOSITORY that uses the results of its
clients for heuristic computation and step-wise improvement of the solution.
• Each
E h participant
ti i t agentt h
has expertise
ti iin itits own fi
field,
ld anddhhas a ki
kind
d off
problem solving knowledge (knowledge source) that is applicable to a part of
the problem, i.e., the problem cannot be solved by an individual agent only.
• Agents communicate strictly through a common blackboard whose contents
is visible to all agents. When a partial problem is to be solved, candidate
agents that can possibly handle it are listed up.
Components
p
• The knowledge source: separate, independent parcels of application-
dependent knowledge. Interaction among knowledge sources takes place
solely through the blackboard.
• The
Th blackboard
bl kb d data d t structure:
t t problem
bl solving
l i state
t t ddata,
t organized
i d iinto
t an
application-dependent hierarchy. Knowledge sources make changes to the
blackboard that lead incrementally to a solution to the problem.
• Control: driven entirely by the state of the blackboard
blackboard. Knowledge sources
respond opportunistically when changes in the blackboard make them
applicable. The control unit is responsible for selecting among the candidate
agents to assign the task to one of them.
Luca Dan Serbanati - Software Design Techniques 73

Blackboard: Advantages/Disadvantages
Advantages:
• Suitable when there are diverse
sources of input data
• Suitable for physically distributed
environments
• Suitable for scheduling and
postponement
t t off tasks
t k andd
decisions
• Suitable for team problem-
solving
l i approaches h as it can bbe
Drawbacks: used for posting problem
• Expensiveness subcomponents and partial
• Difficult to determine
results
lt
partitioning of knowledge
• Control unit can be very
complex
p
Luca Dan Serbanati - Software Design Techniques 74

Blackboards
Summary: Independent programs access and communicate exclusively through
a global data repository, known as a blackboard.
Components: Independent programs, sometimes referred to as “knowledge
sources”,, blackboard.
sources
Connectors: Access to the blackboard may be by direct memory reference, or
can be through a procedure call or a database query.
Data elements: data stored in the blackboard.
Topology: star topology, with the blackboard at the center.
Variants: in one version of the style, programs poll the blackboard to determine
if any values of interest have changed; in another version, a blackboard
manager notifies interested components of an update to the blackboard.
Qualities yielded: Complete solution strategies to complex problems do not
have to be preplanned. Evolving views of the data/problem determine the
strategies
i that
h are adapted.
d d
Typical uses: Heuristic problem solving in artificial intelligence applications.
Cautions: When a well-structured solution strategy is available; when
i t
interactions
ti b
between
t the
th independent
i d d t programs require i complex
l regulation;
l ti
when representation of the data on the blackboard is subject to frequent
change (requiring propagating changes to all the participating components)
Relations to programming languages or environments: Versions of the
blackboard style that allow concurrency between the constituent programs
require concurrency primitives for managing the shared blackboard.
Luca Dan Serbanati – Software Design Techniques 75

Data Centered Style: Advantages

• Data Integrity: Data is entered once
once, at any time; erroneous
erroneous, duplicated
data is not possible.
• Design Reuse: Accurate, reliable data are available when needed.
• View-Generation: Alternate views of the data are facilitated by a single
source of data, which means the same data is always displayed.
• Process Flexibility: The data management process is not constrained to
application usage or sequence.
• Data Interaction Independent of Application: Data can be accessed by the
user through multiple applications.
• Scalability: The database can grow with application and domain needs.
Luca Dan Serbanati – Software Design Techniques 76

Language Extension View

In the Language Extension View the system is viewed as a part that is native
to the software/hardware environment and another part that is not.
Th design
The d i concerns addressed
dd dbby thi
this view
i are:
• How can a part of the system that is written in a non-native language be
integrated with the software system?
• How can the non-native part be translated into the native environment?
• How are the quality attribute of portability and modifiability supported?
The native ppart of the application
pp and the non-native ppart are components
p that
communicate indirectly through another type of component, an interpreter
component that “translates” the latter into the former. The connectors between
these components are data that contain the program instructions in the non- non
native language, as well as the internal state of the non-native part.
Luca Dan Serbanati - Software Design Techniques 77

Interpreter
p
Motivation
A language syntax and grammar needs to be parsed and interpreted within
an application. The language needs to be interpreted at runtime (i.e. using
a compiler is not feasible).
feasible)
Solution
An INTERPRETER for the language g g is p provided,, which p
provides both
parsing facilities and an execution environment. The program that needs to
be interpreted is provided in form of scripts which are interpreted at
runtime. These scripts are portable to each platform realization of the
INTERPRETER. For instance, the INTERPRETER can define a class per
grammar rule of the language. The parser of the interpreter parses
language instructions according to these rules and invokes the
interpretation classes. Many more complex INTERPRETER architectures
exist.
 Luca Dan Serbanati – Software Design Techniques 78

Interpreter
p
Interpreter
memory
Program
memory (pseudocode))
(p
Data access
inputs (fetch/store) being
Activation interpreted
records
(program
state)
memory
Computation
Data access
(state (fetch/store)
machine)
Control state
selected instruction of the
outputs
t t Interpretation interpretation
engine engine
selected data
Characteristics:
A interpreter
An i t t hash 4 components. t
• In an interpreter style the software implements a virtual machine .
• An interpreter includes the pseudoprogram being interpreted and the
interpretation engine itself.
• The pseudoprogram includes the program itself and the interpreter’s analog
off its
it execution
ti state
t t (activation
( ti ti records).
d )
• The interpretation engine includes both the definition of the interpreter and
the current state of its execution.
 Luca Dan Serbanati - Software Architectures 79

Interpreter
Summary: Interpreter parses and executes input commands, updating the state
maintained by the interpreter.
Components: Command interpreter, program/interpreter state, user interface.
Connectors: Typically the command interpreter, user interface, and state are
very closely bound with direct procedure calls and shared state.
Data elements: Commands.
C
Topology: Tightly coupled three-tier; state can be separated from the
interpreters.
p
Qualities yielded: Highly dynamic behavior is possible, where the set of
commands is dynamically modified. System architecture may remain
constant while new capabilities are created based upon existing primitives
primitives.
Typical uses: Superb for end-user programmability; support dynamically
changing set of capabilities.
Cautions: When fast processing is needed; memory management may be an
issue, especially when multiple interpreters are invoked simultaneously.
Relations to programming languages or environments: Lisp and Scheme are
interpretive languages, and sometimes used when building other
interpreters; Word/Excel macros.
Luca Dan Serbanati - Software Design Techniques 80

Virtual Machine
Applicability
An efficient execution environment for a programming language is needed.
Th architecture
The hit t should
h ld facilitate
f ilit t portability,
t bilit coded optimizations,
ti i ti and
d native
ti
machine code generation. Runtime interpretation of the language is not
necessarily required.
Solution
A VIRTUAL MACHINE defines a simple machine architecture on which not
machine code but an intermediate form called the byte-code
y can be
executed. The language is compiled into that byte-code. The VIRTUAL
MACHINE can be realized on different platforms, so that the byte-code can
be portable between these platforms.
platforms The VIRTUAL MACHINE redirects
invocations from a byte-code layer into an implementation layer for the
commands of the byte-code. A virtual machine (VM) is an emulator that
executes on top of a hardware or software platform
platform.
• Such a machine provides the familiar functions and services expected by
computer programs but does so using software rather than hardware.
• It iis a variant
i t off th
the INDIRECTION LAYER pattern. tt
Luca Dan Serbanati - Software Design Techniques 81

Virtual Machine
Summary: Consists of an ordered 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 p passed between layers
y
Topology: Linear, for strict virtual machines; a directed acyclic graph in looser
interpretations
Q liti yielded:
Qualities i ld d ClClear ddependency
d structure;
t t software
ft att upper llevels
l iimmune
to change 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
inefficient.
 Luca Dan Serbanati - Software Design Techniques 82

Using
g the Virtual Machine Pattern
Advantages
1. Virtual machine concept provides complete protection of system resources
since each virtual machine is isolated from all other virtual machines
machines. This
isolation, however, permits no direct sharing of resources.
2. A virtual machine is an ideal platform for research and development of new
software concepts because it insulates the R&D environment from the
operational environment and does not disrupt normal operation.
Disadvantages:
The virtual machine concept is difficult to implement due to the effort
required to provide an exact duplicate of the underlying machine.

Examples of Virtual Machines

– Programming language Interpreters are used to build machines that
close the gap between the computing engine expected by the semantics
off the
th program andd th
the computing
ti available
il bl iin h
hardware
d
– Command language processors
– Programming language runtime environment
Luca Dan Serbanati - Software Design Techniques 83

The
M i i
Motivation
e Rule-Based
u e ased Syste
System Pattern
atte
Logical problems are hard to express elegantly in imperative languages that are
typically used in INTERPRETERS and VIRTUAL MACHINES. Consider for
i t
instance an expertt system
t that
th t provides
id the
th knowledge
k l d off an expertt or a sett
of constraints. In imperative languages these are expressed by nested if-
statements or similar constructs which are rather hard to understand.
Solution
A RULE-BASED SYSTEM offers an alternative for expressing such problems in
a system. It consists mainly of three things: facts, rules, and an engine that
acts on them
them. Rules represent knowledge in form of a condition and
associated actions. Facts represent data. A RULE-BASED SYSTEM applies
its rules to the known facts. The actions of a rule might assert new facts,
which in turn
which, turn, trigger other rules
rules.
Rule-based Systems:
– Provide a means of codifying the problem-solving skills of human experts
– Experts tend to capture problem-solving
problem solving techniques as sets of situation-
situation
action rules
– Typically, execution / activation of rules is sequenced in response to the
conditions of the p problem-solvingg computations
p rather than by
ya
predetermined scheme
– Because situation-action rules are not directly executable by computers,
systems for interpreting such rules must be provided (es. PROLOG)
Luca Dan Serbanati - Software Design Techniques 84

Rule-Based Systems

• Rule-based systems provide a means of codifying the problem-solving skills

of human experts.
p These experts
p tend to capture
p p
problem-solvingg
techniques as sets of situation-action rules whose execution or activation is
sequenced in response to the conditions of the computation rather than by
predetermined scheme
scheme.
• Rule-based systems make heavy use of pattern matching and context (i .e.
currently relevant rules).
Luca Dan Serbanati - Software Design Techniques 85

S
Rule-Based/Expert
Summary: IInference
f engine
p
i parses user input
i t and
dd
System
y
determines
t i whether
h th it iis 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
tt t tot resolve
l the
th query.
Components: User interface, inference engine, knowledge base.
Connectors: Components are tightly interconnected, with direct procedure calls
and/or shared data access.
access
Data elements: facts and queries.
Topology: tightly coupled three-tier (direct connection of user interface,
inference engine
engine, and knowledge base)
base).
Qualities yielded: Behavior of the application can be easily modified through
dynamic addition or deletion of rules from the knowledge base. Small
systems can be quickly prototyped
prototyped. Thus useful for iteratively exploring
problems whose general solution approach is unclear.
Typical uses: When the problem can be understood as matter of repeatedly
resolving a set of predicates.
Cautions: When a large number of rules are involved, understanding the
interactions between multiple rules affected by the same facts can become
very y difficult. Understanding g the logical
g basis for a computed
p result can be
as important as the result itself.
Relations to programming languages or environments: Prolog is a common
language for building rule-based systems.
Luca Dan Serbanati - Software Design Techniques 86

C
Component
t IInteraction
t ti View
Vi
IIn the
th Component
C t Interaction
I t ti View
Vi the
th system
t is
i viewed
i d as a numberb off
independent components that interact with each other in the context of a
system. The concerns addressed by this view are:
• How do the independent components interact with each other?
• How are the individual components decoupled from each other?
• How are the quality attributes of modifiability and integrability
supported?
The components retain their independence, since they merely exchange
data but do not directly control each other.
The components interact with each other through connectors that pass
data from one to another. This interaction can be performed
synchronously or asynchronously and can be message-based or through
direct
d ect ca
calls.
s
The two major patterns in this view differentiate whether the components
interact through explicit or implicit invocations.
Luca Dan Serbanati - Software Design Techniques 87

Patterns for Basic Component Interaction

 Luca Dan Serbanati - Architetture e tecnologie di servizi 88

Message Exchange Patterns (MEP)

Primitive MEP request message
1. “Request-response” Server Service
requestor
q provider

response message

PSM

Service

A paradigm for client-server invocation: Single destination

provider

– O
Onlyy the
t e requestor
equesto “knows”
o s tthe
epprovider,
o de , 1. S
Server
Service

provider

– There is only one provider.

requestor

Service

provider

2. “Fire-and-Forget”
Fire and Forget
Multi cast
Unidirectional transmission from Service

provider

one source to one or many destinations 2.

Server

requestor
Service

provider

Service
fire-and-forget provider
message

Message Message Broadcast

Service
Source Destination provider

Service
3. Server

requestor provider

Service
PSM provider
 Luca Dan Serbanati – Software Design Techniques 89

Complex
p MEP
Complex MEP = Aggregation of primitive and complex MEP.
Example: Event-based Communication, Publish/Subscribe
subscription
p
Step 1:
request message
PSM request-response

subscription
response message

Subscriber Publisher

Step 2:
notification
tifi ti messages PSM fire-and-forget

• Characteristics of event-based communications:

– Many
Many-to-many;
to many;
– Event providers and consumers are de-coupled and autonomous: They
do not know each others;
– The notifications are not blocking;
– The notifications are self-describle. At the consumer end they must be
first analysed and then consumed.
Luca Dan Serbanati - Software Design Techniques 90

Explicit Invocation
 Luca Dan Serbanati - Software Design Techniques 91

Motivation Explicit Invocation

C
Consider a component, the client, which needs to invoke a service defined
f in
another component, the supplier. Coupling the client with the supplier in
various ways is not only harmless but often desirable:
– the
th client
li t mustt know
k the
th exactt network
t k location
l ti off the
th componentt which
hi h
offers the service in order to improve performance; or
– the client must always initiate the invocation itself; or
– the client must block,
block waiting for the result of the invocation
invocation, before
proceeding with its business; or
– the topology of the interacting clients and suppliers is known beforehand
and must remain fixed.
fixed
How can these two components interact?
Solution
An EXPLICIT INVOCATION allows a client to invoke services on a supplier supplier,
by coupling them in various respects. The decisions that concern the
coupling (e.g. network location of the supplier) are known at design-time.
The client provides these design decisions together with the service name
and parameters to the EXPLICIT INVOCATION mechanism, when initiating
the invocation.
The EXPLICIT INVOCATION mechanism p performs the invocations and
delivers the result to the client as soon as it is computed. The EXPLICIT
INVOCATION mechanism may be part of the client and the server or may
exist as an independent component.
 Luca Dan Serbanati - Software Design Techniques 92

Patterns of Explicit Invocations

Two main
T i variants
i t off EXPLICIT INVOCATIONS:
INVOCATIONS
• synchronous, explicit invocations : the client blocks until the result is
available.
• asynchronous,
asynchronous explicit invocations: the client continues with its work
immediately immediately and the result is delivered at a later point, after it is
computed. There are four complex patterns that describe different variants of
asynchronous invocations for distributed systems:
– The FIRE AND FORGET pattern describes best effort delivery semantics
for asynchronous operations but does not convey results or
acknowledgments.
acknowledgments
– The SYNC WITH SERVER pattern describes invocation semantics for
sending an acknowledgment back to the client once the operation arrives
on the server side, but the pattern does not convey results.
– The POLL OBJECT pattern describes invocation semantics that allow
clients to poll (query) for the results of asynchronous invocations, for
instance,, in certain intervals.
– The RESULT CALLBACK pattern also describes invocation semantics
that allow the client to receive results; in contrast to POLL OBJECT,
however, it actively notifies the requesting client of asynchronously
arriving results rather than waiting for the client to poll for them.
• There are two variants of the EXPLICIT INVOCATION pattern: CLIENT-
SERVER and PEER-TO-PEER.
Luca Dan Serbanati - Software Design Techniques 93

Explicit, Synchronous
Invocation
• A synchronous
h software
ft architecture
hit t in
i which
hi h the
th client
li t ceases
execution while the service provider performs the service. Upon
completing the service, the service provider may return a value to the
client.
• Call & Return style is used when the order of computation is fixed.
Client
Service Provider
1
2

4
5

Call-and-return control flow

Luca Dan Serbanati - Software Design Techniques 94

Main Program/Subroutine
• The main program and subroutines architecture consists of a main program
that acts as a controller (or executive) and one or more subroutines that
perform specific functions when called by the main program
program.
• This architecture is based on the definition–use relationship, which imposes
a single thread of control.
• The correct operation of the main program and any subroutine is directly
dependent on the correct operation of the subroutines it calls.

main
R0
C1
C2 C3

P1 P2 P3 ... Pn
Main Program R1 R2

Subroutine C21 R2
Return
Call P21
Main
Program/Subroutine C211 R21

Subroutine P211
Luca Dan Serbanati - Software Design Techniques 95

Main Program/Subroutine
g Style
y
Characteristics
• Hierarchical decomposition based on definition-use relationship
• Single
Si l th thread
d off control
t l supported
t d di
directly
tl bby programming
i llanguages
• Subsystem structure implicit: subroutines typically aggregated into
modules
• Hierarchical reasoning: correctness of a subroutine depends on the
correctness of the subroutines it calls.
Ad
Advantages:
t
• Simple to visualize and easy to learn.
• A single thread of control works its way through the various subroutines.
Disadvantages:
• Correctness of any job depends on all subroutines called.
• Tendency to devolve into spaghetti code: several subroutines may do
similar job due to similar requirements added at different times in the
application’s
application s lifetime.
• Scalability & configuration control: one can lose visibility of the flow of
control over several subroutines.
Luca Dan Serbanati - Software Design Techniques 96

Main Program
g and Subroutines
Summary: Decomposition based upon separation of functional processing
steps.
steps
Components: Main programs 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
Qualities yielded: Modularity: Subroutines may be replaced with different
implementations as long as interface are unaffected
Typical uses: Small programs; pedagogical purposes
Cautions: Typically fails to scale to large applications; inadequate attention to
data structures
structures. Un predictable effort required to accommodate new
requirements
Relations to programming languages or environments:
Luca Dan Serbanati - Software Design Techniques 97

Data Abstraction (Object-Oriented)

(Object Oriented) Style
op
op Object
Obj t
Object Manager
(ADT) Object-Oriented
Object Organization
op
op
Procedure Call Procedure Call
Obj t
Object
op Manager
op (ADT)

Object op
Object
op is an invocation or
procedure call
Characteristics:
• The data are encapsulated as the abstract data types demand in
objects together with primitive operations; the object internal
representation
p is hidden for other objects’
j access. The objects
j interact
by means of a message-passing or procedure call mechanism (call-
and-return style) .
• Object systems also support inheritance and/or delegation
mechanisms not necessarily available in program/subroutines
architecture.
Luca Dan Serbanati - Software Design Techniques 98

ADT and OO Systems

y
• Encapsulation: restricted access to certain information, a “Manager” is
responsible for preserving integrity of a resource
• Inheritance: share one definition of shared functionality
• Dynamic binding: determine actual operation to invoke at runtime
• Management of many objects: provide structure on large set of definitions
• Reuse and maintenance: exploit encapsulation and locality
Advantages
• Data hiding -> easy maintenance of objects without affecting the clients that
use these objects
• Supporting concurrent execution
• Natural problem decomposition -> collection of interacting objects.
Drawbacks
• In order for one object to interact with another it must know the identity of
that other object
– If identity of an object changes, it is necessary to modify all other objects
that explicitly invoke it
– Potentiallyy side-effect p problems: if A uses object
j B and C also uses B,,
then C’s effects on B look like unexpected side-effects to A, and vice
versa.
 99

Object-Orientation
Summary: St
S State
t strongly
t l encapsulated
l t d with
ith ffunctions
ti th
thatt operate
t on that
th t state
t t
as objects
Components: Objects (instance of a class)
Connectors: Method invocation (procedure calls to manipulate state)
Data elements: Arguments to methods
Topology:
p gy Can vary y arbitrarily
y components
p may y share data and interface
functions through inheritance hierarchies
Additional constraints imposed: Commonly shared memory (to support use of
pointers) single threaded
pointers),
Qualities yielded: Integrity of data operations: data manipulated only by
appropriate functions. Abstraction implementation details hidden
Typical uses: Applications where the designers wants a close correlation
between entities in the physical world and entities in the program;
applications involving complex, dynamic data structures
C ti
Cautions: U
Use iin di
distributed
t ib t d applications
li ti requires
i extensive
t i middleware
iddl tto
provide access to remote objects. Relatively inefficient for high-performance
applications with large, regular numeric data structures, such as scientific
computing. Lack of additionla structuring principles can result in highly
complex applications
Relations to programming languages or environments: Java, C++
Luca Dan Serbanati - Software Design Techniques 100

Client-Server Architecture
 Luca Dan Serbanati - Software Design Techniques 101

Motivation
Client-Server Pattern
Two components need to communicate, and they are independent of each
other, even running in different processes or being distributed in different
machines The two components are not equal peers communicating with
machines.
each other, but one of them is initiating the communication, asking for a
service that the other provides. Furthermore, multiple components might
q
request the same service p provided by
y a single
g component.
p Thus,, the
component providing a service must be able to cope with numerous
requests at any time(the component must scale well). On the other hand, the
q
requesting g components
p using
g one and the same service mightg deal
differently with the results. This asymmetry between the components should
be reflected in the architecture for the optimization of quality attributes such
as performance, shared use of resources, and memory consumption.
Solution
The CLIENT-SERVER pattern distinguishes two kinds of components:
clients and servers. The client requests information or services from a
server. To
T dod so it needsd tto know
k how
h to
t access the
th server: it requires
i an ID
or an address of the server and of course the server’s interface.
The server responds to the requests of the client, and processes each client
request on its own
own. It does not know about the ID or address of the client
before the interaction takes place. Clients are optimized for their application
task, whereas servers are optimized for serving multiple clients.
Luca Dan Serbanati - Software Design Techniques 102

Type of Connection
Client-Server Issues (I)
• Connectionless communication: e.g. via UDP (User Datagram Protocol),
implements unreliable delivery of messages. Clients should use
connectionless communication when the application service handles errors
andd participates
ti i t iin b broadcast
d t or multicast
lti t service,
i or performance
f
requirements cannot tolerate virtual circuit overhead delays.
• Connection-oriented communication: e.g. via TCP/IP (Transfer Control
P t
Protocol/Internet
l/I t t Protocol),
P t l) implements
i l t reliable
li bl d delivery
li off messages.
Connection oriented communication makes programming easier because
the protocol includes mechanisms for detecting and handling errors and an
acknowledgment mechanism between client and service. service
Stateless vs. Stateful Servers
• State information: Information a server maintains about its clients. A server
may or may not retain this information
information.
• State information may be required if the information exchange between the
client and the application consists of multiple messages. State information
can become useless if messages are lost lost, duplicated
duplicated, or delivered out-of-
out of
order, or if the server crashes and must be rebooted.
• Stateless servers rely on the application protocol to assume the
espo s b y for
responsibility o reliability
e ab y o of de
delivery
eya andd se
service.
ce Thus,
us, the e app
application
ca o
gives the same response no matter how many times a request arrives.
• Stateful designs can lead to complex application protocols and error
handling mechanisms
Luca Dan Serbanati - Software Design Techniques 103

Client-Server Issues (II)

In designing client-server systems the following issues must be considered:
– Authentication: Verifying the identity of the client and its
rights/privileges. Clients may be restricted to the systems they can
access when multiple servers are available.
– Authorization:
A th i ti V if i th
Verifying the rights/privileges
i ht / i il off th
the client.
li t Cli
Clients
t may
be restricted in the kinds of commands they may issue, the applications
they can run, or the data they can retrieve.
– Data Security: Protecting the data stored on the server. Servers must
provide protection to prevent unauthorized release or modification of the
data stored on them
them.
– Protection: Protecting the system itself from errant applications. Servers
must provide mechanisms for trapping errant applications and preventing
th
them from
f damaging
d i th the system
t andd itits resources.
– Middleware: selecting the right middleware for the task.
 Luca Dan Serbanati - Software Design Techniques 104

Client-Server Architecture vs.

Oth A
Other Architectures
hit t
• Using the CLIENT-SERVER pattern we can build arbitrarily complex
architectures by introducing multiple client-server
client server relationships: a server can
act itself as a client to other servers. The result is a so-called n-Tier-
architecture.

• It iis also
l possible
ibl tto combine
bi ththe CLIENT
CLIENT-SERVER
SERVER pattern
tt with
ith LAYERS iin
order to design a system where the client and the server components
individually are layered.
• SHARED REPOSITORIES or BLACKBOARDS can be perceived as
CLIENT-SERVER, where the data store is the server and the data
accessors are the clients.
Luca Dan Serbanati - Software Design Techniques 105

Client/Server Styles

Fat Client Style 3-Tier Style WebApplication Style

Luca Dan Serbanati - Software Design Techniques 106

Client-Server
Summary: Clients send service requests to the server, which performs the
required functions and replies as needed with the requested information.
Communication is initiated by the clients
clients.
Components: Clients and server
Connectors: Remote p procedure calls, network pprotocols
Data elements: Parameters and return values as sent by the connectors
Topology: Two-level, with multiple clients making requests to the server
Additional constraints imposed: Client-to-client communications prohibited
Qualities yielded: Centralization of computation and data at the server, with the
information made available to remote clients. A single powerful server can
service many clients
Typical uses: Applications where centralization of data is required, or where
processing and data storage benefit from a high
high-capacity
capacit machine
machine, and
where clients primarily perform simple user interface tasks, such as many
business applications
Cautions: when the network bandwidth is limited and there are a large number
of client requests
Luca Dan Serbanati - Software Design Techniques 107

Peer-To-Peer Architecture
 Luca Dan Serbanati - Software Design Techniques 108

Motivation The Peer-To-Peer Pattern

Consider a situation similar to that of a CLIENT-SERVER, but in contrast to
CLIENT-SERVER, there is no distinction between the components: each
component might both provide services and consume services. When a
componentt providesid a service
i it mustt perform
f wellll according
di tto th
the
demands of the requesting components. Each component must know how to
access other components.
Solution
In the PEER-TO-PEER pattern each component has equal responsibilities,
in particular it may act both as a client and as a server. Each component
offers its own services (or data) and is able to access the services in other
components. The PEER-TO-PEER network consists of a dynamic number of
components. A PEER-TO-PEER component knows how to access the
network Before a component can join a network
network. network, it must get an initial
reference to this network. This is solved by a bootstrapping mechanism,
such as providing public lists of dedicated peers or broadcast messages
(using IMPLICIT INVOCATION) in the network announcing peers.
Once an initial reference of the PEER-TO-PEER network is found, we need
to find other peers in the network. For this purpose, each peer (or each
dedicated p peer)) realizes the LOOKUP p pattern . Using g LOOKUP p peers can
be found based on their names or their properties. PEER-TO-PEER can be
realized internally using CLIENT-SERVER, or other patterns. It usually also
uses a BROKER architecture.
Luca Dan Serbanati - Software Design Techniques 109

Client/Server and P2P Systems

Client/Server
– 3-tier: Functionality is equally divided into three logical partitions:
application business
application, business, and data services
services.
– Fat Client: More functionality is placed on the client.
– Fat Server: More functionality is placed on the server.
– Distributed Client/Server
client-server

Workstation Server
Data
Presentation Business Logic Database
Distributed
access Distributed Distributed applications Distributed
dialog data/databases
Peer-to-Peer:
– Any process or node in the system may be both client and server.
peer-to-peer
Process 1 Process2

Process 3 Process4

Process5
 Luca Dan Serbanati - Software Architectures 110

Peer to Peer architectural style

y
• The peer-to-peer architectural style consists of a loosely coupled
autonomous peers, each peer acting as a client and a server. Peers
communicate using a network protocol
protocol, sometimes specialized for P2P
communication (this was the case for Napster and Gnutella file-sharing
applications).
• Unlike the client-server architectural style where state and logic are
centralized, P2P decentralizes both information and control.
• Absence of decentralization makes resource discovery an important issue
for P2P applications: in a pure P2P application queries for information are
issued to the network of peers at large; requests propagate until the
information is discovered or some propagation threshold is passed
passed.
• If the desired information is located, the peer obtains the direct address of
that peer and contacts it directly.
• Hybrid applications optimize this process by having certain peers play
special roles, either for locating other peers or for providing directories
locating information
information.
Luca Dan Serbanati - Software Design Techniques 111

Peer-To-Peer
Peer To Peer Style
Peer-to-peer systems tend to be complex, and there is a greater need
to be aware of issues such as deadlock,, starvation between processes,
p ,
and fault handling.
Luca Dan Serbanati - Architetture e tecnologie di servizi 112

JXTA Virtual Network

• The JXTA protocol creates a virtual P2P network on the physical
network infrastructure .

Output
Service B Pipe
Service A Service C
Input
Output Pipe Input
Pipe Pipe

PeerID PeerID
PeerID
PeerID

PeerID PeerID
PeerID

Peer
Peer Peer Peer
TCP/IP Peer

Peer Peer
Peer NAT
Firewall
HTTP

5
 Luca Dan Serbanati - Software Architectures 113

Peer-to-Peer
Summary: State and beshavior are distributed among peers that can act as
either clients or servers.
C
Components: t PPeers-independent
i d d t components, t having
h i th their
i own state
t t andd
control thread.
Connectors: Network p protocols,, often custom.
Data elements: network messages.
Topology: Network (may have redundant connections between peers); can vary
arbitrarily
bit il and d dynamically.
d i ll
Qualities yielded: decentralized computing with flow of control and resources
distributed among gppeers. Highly
g y robust in face of failure of any
yggiven node.
Scalable in terms of access to resources and computing power.
Typical uses: where sources of information and operations are distributed and
network is ad hoc
hoc.
Cautions: when information retrieval is time critical and cannot afford the
latency imposed by the protocol. Security-P2P networks must make
prevision for detecting malicious peers and managing trust in an open
environment.
Luca Dan Serbanati – Software Design Techniques 114

Implicit Invocation
•Event-driven
Event driven means that processing only occurs when the
event happens.
• The event may be a data point changing, an alarm going off,
a timer timing out or a user clicking on an icon or a graphic
object.
• There is no flow of control.
• Calls are invoked indirectly an implicitly as a response to a
notification or an event.
 Luca Dan Serbanati - Software Design Techniques 115

Motivation Implicit Invocation

Consider the case where an invocation is needed but the client must be
decoupled in various ways from the supplier, during the delivery of the
invocation and of the result:
– the client might
g not know which supplier
pp serves the invocation; or
– the client may not initiate the invocation itself but is merely interested in
the invocation result; or
– the client does not need the result right away so it can be occupied with
another task in the meantime; or
– the supplier might not be ready to reply to the client until some condition
has been met; or
– clients may be added or removed dynamically during the system runtime;
– the client does not know that the supplier is up and running and, if the
supplier is down, the system should suspend the invocation until the
supplier
pp is up
p again;
g ; or
– the client and the supplier are part of dissimilar systems and thus the
invocation must be transformed, queued, or
– otherwise manipulated during delivery.
H
How can such h additional
dditi l requirements
i t dduring
i d delivery
li b
be met?
t?
Solution
In the IMPLICIT INVOCATION pattern the invocation is not performed
explicitly from client to supplier
supplier, but indirectly and rather randomly through a
special mechanism such as PUBLISH-SUBSCRIBE, MESSAGE QUEUING,
or broadcast, that decouples clients from suppliers. All additional
requirements may be handled during the delivery of the invocation.
 Luca Dan Serbanati – Software Design Techniques 116

Asynchronous
y Communication
Two modells:
– pub/sub (publish/subscribe) - like TV. Consumer are listeners
subscribe for a event
event-type
type channel or topic
topic.
– PTP (point-to-point) – like vocal mail. A consumer consumes
messages from a message queue.

provider 1
consumer 1 consumer 1
provider1
provider 2 topic queue

provider 2
consumer 2 consumer 2
provider 2
pub/sub PTP

Publisher Message Source Message

Server Server Message
Message Message
Message Message
channel Subscriber Queue Destination
Publisher Source
Message
Message

Message
essage Source Message
Publiser Subscriber D i i
Destination
channel Queue
Message Message
Luca Dan Serbanati - Software Design Techniques 117

Publish-Subscribe
Architecture
 Luca Dan Serbanati - Software Design Techniques 118

Publish-Subscribe Pattern
Motivation
A component should be accessed or informed of a specific runtime event.
Events are of different nature than direct interactions as in CLIENT-SERVER
or PEER-TO-PEER. Sometimes a number of components should be actively
informed (an announcement or broadcast), in other cases only one specific
component
co po e t iss interested
te ested in the
t eeevent.
e t In co
contrast
t ast to EXPLICIT C
INVOCATIONS, event producers and consumers need to be decoupled for a
number of reasons: to support locality of changes; to locate them in different
processes or machines; to allow for an arbitrary time period between the
announcement of interest in an event, and the actual triggering of the event.
Still, there must be a way to inform the interested components?
S l ti
Solution
PUBLISH-SUBSCRIBE allows event consumers (subscribers) to register for
specific
p events,, and event producers
p to p
publish ((raise)) specific
p events that
reach a specified number of consumers. The PUBLISH-SUBSCRIBE
mechanism is triggered by the event producers and automatically executes a
callback-operation
callback operation to the event consumers
consumers. The mechanism thus takes care
of decoupling producers and consumers by transmitting events between
them.
Luca Dan Serbanati - Software Architectures 119

Publish--Subscribe Style
Publish y
• Publish/subscribe is a style of messaging
Publish-Subscribe
application in which the providers of
Publisher
Architecture i f
information
ti ((publishers)
bli h ) are ddecoupled
l d
Subscriber
from the consumers of that information
Publisher
Publisher
(subscribers) using a broker.
Subscriber

Event
Remote Procedure Call

Subscriber Subscriber • In a publish/subscribe system, a publisher

does not need to know who uses the
information (publication) that it provides,
and a subscriber does not need to know
who provides the information that it
receives as the result of a subscription.
• Message brokers make sure that
messages arrive
i att th
the correctt
destinations, and are transformed to the
format required at each destination.
Luca Dan Serbanati - Software Design Techniques 120

Publish-Subscribe
Summary: Subscribers register/deregister to receive specific messages or
specific content. Publisher maintain a subscription list and broadcast
messages to subscribers either synchronously or asynchronously.
p
Components: Publishers,, subscribers,, proxies
p for managing
g g distribution.
Connectors: Procedure calls may be used within programs, more 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.
V i t Specific
Variants: S ifi uses off the
th style
t l may require i particular
ti l steps
t ffor subscribing
b ibi
and unsubscribing. Support for complex matching of subscription interests
are available information may be provided and be performed by
intermediaries.
intermediaries
Qualities yielded: Highly efficient one-way dissemination of information with
very low coupling of components.
Typical uses: News dissemination – whether in the real world or online events
events.
Graphical user interface programming. Multiplayer-network – based games.
Cautions: When the number of subscribers for a single data item is very large a
p
specialized broadcast pprotocol will likely
y be necessary.
y
Relations to programming languages or environments: In large-scale systems
support for publish-subscribe is provided by commercial middleware
technology.
 Luca Dan Serbanati - Analisi e progettazione orientate agli oggetti 121

Event-Based Architecture
Event
Event-based Implicit Invocation
Architecture
Source
Event
• Instead of invoking a procedure
Procedure g
Manager
E
Event
t Handler
H dl
directly, a component (event source)
can “notify” events to other components
Procedure
Event Handler • There are components (event
Event handlers)) that manifest an interest in an
Remote Procedure Call
event by associating a procedure with it
• When the event is announced, the
Procedure Procedure
system (event manager) invokes all
procedures that have been registered
with it.
• Components: procedures (or methods)
– Interface defines a set of incoming procedure calls
– Interface also defines a set of outgoing events
• Connections: event
event-procedure
procedure bindings
– Procedures are registered with events
– Components communicate by announcing events at “appropriate” times
– When
Wh an eventt is i announced d th
the associated
i t d procedures
d are iinvoked
k d
(implicit invocation)
– Order of invocation is non-deterministic.
 Luca Dan Serbanati – Software Design Techniques 122

Different Levels of Abstraction for Events

Characteristics:
• The source event component does not know the event listeners.
• The components can not know the order in the event processing.
Luca Dan Serbanati – Software Design Techniques 123

GUI Event Processing

 Luca Dan Serbanati - Software Architectures 124

Event Systems: Advantages

• Essential concept for reactive systems:
– Suited for user input / network communication
– Returning results from asynchronous execution
• Strong support for reuse:
– Any component can be introduced into a system simply by registering it
for the events of the system
• E i system
Easing t evolution:
l ti
– Components may be replaced by other components without affecting the
interfaces of the other systems.
y
 Luca Dan Serbanati - Software Architectures 125

Event Systems:
y Drawbacks
Components have no control over the computations performed by the system:
– When a component announces an event, it cannot assume other
components t will
ill respond
d tto itit. M
Moreover, even it kknows what
h t other
th
components are interested in the events it announces, it cannot rely on
the order in which they are invoked.
Exchange of data:
– Sometimes data can be passed with an event, but in other situations
event systems must rely on a shared repository for interaction
interaction.
– In these cases global performance and resource management can
become critical issues.
Reasoning about correctness can become problematic:
– The meaning of a procedure (method) that announces events will
d
depend
d on th
the context
t t off bindings
bi di iin which
hi h it iis iinvoked
k d ((->overloading,
> l di
polymorphism).
– This is in contrast to traditional reasoning
g about p
procedure calls,, which
need only consider a procedure’s pre- and post-conditions when
reasoning about the functional behavior of its invocation.
 Luca Dan Serbanati - Software Architectures 126

Event-Based
Summary: Independent components asynchronously emit and receive events
communicated over event buses.
Components: Independent,
Independent concurrent event generators and/or consumers
consumers.
Connectors: Event bus. In variants, more than one may be used.
Data elements: Events – data sent as a first-class entity over the event bus.
Topology: Components communicate with the event-bases, not directly to each
other.
Variants: Component communication with the event
event-bus
bus may either be push or
pull based.
Qualities yielded: Highly scalable, easy to evolve, effective for highly
distributed, heterogeneous applications.
Typical uses: User interface software, wide-area applications involving
independent parties (such as financial markets,
markets logistics,
logistics sensor networks)
networks).
Cautions: No guarantee if or when a particular event will be processed.
Relations to programming languages or environments: Commercial message-
oriented middleware technologies support event-based architectures.
Luca Dan Serbanati - Software Design Techniques 127

User Interaction View

In the User Interaction View the system is viewed as a part that
represents the user interface and a part that contains the application
logic, associated with the user interface. The concerns addressed by
thi view
this i are:
• What is the data and the application logic that is associated to the
user interface?
• How is the user interface decoupled from the application logic?
• How are the quality attributes of usability, modifiability, and
reusability
y supported?
pp
The elements that present data to the user, accept the user input, and
contain the application logic and data are implemented as
components. The components interact with each other through
connectors that pass data from one to another. This interaction is
usually a message-based change notification mechanism.
 Observer

Subject

attach(obs : Observer) : void

+observers
observers Observer Observer
detach(obs : Observer) : void 0..* update()
notify() : void
for all o in observers {
p
o->update()()
Pattern
}
ConcreteSubject
ConcreteObserver
subjectState : SubjectState +subject observerState : ObserverState
getState() : SubjectState
setState(state : SubjectState) : void update() : void

return subjectState observerState =

subject->getState()

aConcreteSubject: : aConcreteObserver anotherConcreteObserver :

ConcreteSubject : ConcreteObserver ConcreteObserver

setState(SubjectState)
notify( )

update( )
getState(
tSt t ( )
update( )
getState( )

128
Luca Dan Serbanati - Software Design Techniques

Design Pattern: The Model-View Separation Principle

The Model-View Separation principle states that model (domain) objects should
not have direct knowledge g of view ((UI)) objects,
j at least as view objects.
j A
further part of this principle is that the domain classes encapsulate the
information and behavior related to application logic.
MV principle has at least two parts:
• Do not connect or couple non-UI objects directly to UI objects. Why?
Because the windows are related to a particular application, while (ideally)
the non-windowing objects may be reused in new applications or attached to
a new interface.
• Doo not
ot put application
app cat o logic
og c (such
(suc as a tax
ta calculation)
ca cu at o ) in tthe
eUUI object
methods. UI objects should only initialize UI elements, receive UI events
(such as a mouse click on a button), and delegate requests for application
logic on to non-UI objects (such as domain objects).
objects)
• In this context, Model is a synonym for the domain layer of objects (it's an
old OO term from the late 1970s). View is a synonym for UI objects, such as
windows,
i d W
Web b pages, applets,
l t and d reports.
t
129
 Luca Dan Serbanati - Software Design Techniques 130

The Model-View-Controller Pattern (I)

Motivation
A system may offer multiple user interfaces. Each user interface depicts all
or part of some application data. Changes to the data should be
automatically and flexibly reflected to all the different user interfaces
interfaces. It
should be also possible to easily modify any one of the user interfaces,
without affecting the application logic associated with the data.
Solution
The system is divided into three different parts: a Model that encapsulates
some application data and the logic that manipulates that data,
p
independently y of the user interfaces; one or multiple
p Views that display
p ya
specific portion of the data to the user; a Controller associated with each
View that receives user input and translates it into a request to the Model.
Views and Controllers constitute the user interface. The users interact strictly
through the Views and their Controllers, independently of the Model, which
in turn notifies all different user interfaces about updates.
 Luca Dan Serbanati - Software Design Techniques

Model-View-Controller Pattern (II)

• Events typically cause a
controller to change a model
model,
or view, or both.
• Whenever a controller changes
a model’s data or properties, all
dependent views are
automatically y updated.
p
• Similarly, whenever a controller
changes a view, for example,
by revealing areas that were
previously hidden, the view
gets data from the underlying
model
d l tto refresh
f h ititself.
lf

131
Luca Dan Serbanati - Software Design Techniques

MVC
Observer Observer

Update()
Model-View-
Model

View
Controller
Controller (III)
Model The pattern separates responsibilities
CurrentTime
Controller of the system in three categories of
Subscribe() 1..1
Detach()
1..1
1..1
objects.
AcceptTick()
p ()
1..1
- Controller is the object which
View
0..*
0..*
receives, process and responds to
all events generated by views and
aModel : Model aView : View aController :
Controller
users
users.
Subscribe - View is an object that presents data
Subscribe
to be shown to yhe user. It is
automatically updated when data
Inc(3)
change or periodically. A View
Adjust()
object creates the controller
because the last one should be
Update
customized according to the view.
Update - Model is the object that gathers
domain data. It updates the views e
controllers, if necessary, each time
when a data change occurs.
132
Luca Dan Serbanati - Software Design Techniques

Why using Model-View Separation Pattern?

• To support cohesive model definitions that focus on the domain processes,
rather than on user interfaces.
• To allow separate development of the model and user interface layers
layers.
• To minimize the impact of requirements changes in the interface upon the
domain layer.
• To allow new views to be easily connected to an existing domain layer,
without affecting the domain layer.
• To allow multiple simultaneous views on the same model object
object, such as
both a tabular and business chart view of sales information.
• To allow execution of the model layer independent of the user interface
layer, such as in a message-processing or batch-mode system.
• To allow easy porting of the model layer to another user interface
framework.

133
 Luca Dan Serbanati - Software Design Techniques 134

The Presentation-Abstraction-Control Pattern

Motivation
An interactive system may offer multiple diverse functionalities that need to
be presented to the user through a coherent user interface. The various
functionalities may require their own custom user interface
interface, and they need to
communicate with other functionalities in order to achieve a greater goal.
The users need not perceive this diversity but should interact with a simple
and consistent interface.
Solution
The system is decomposed into a tree-like hierarchy of agents: the leaves of
g
the tree are agents that are responsible
p for specific
p functionalities, usually
y
assigned to a specific user interface; at the middle layers there are agents
that combine the functionalities of related lower-level agents to offer greater
services; at the top of the tree, there is only one agent that orchestrates the
middle-layer agents to offer the collective functionality. Each agent is
comprised of three parts: a Presentation takes care of the user interface; an
Abstraction maintains application data and the logic that modifies it; a
C t l iintermediates
Control t di t b between
t th
the P
Presentation
t ti and d th
the Ab
Abstraction
t ti and d
handles all communication with the Controls of other Agents.
The PRESENTATION-ABSTRACTION-CONTROL pattern is in essence
based on MODEL
MODEL-VIEWCONTROLLER,
VIEWCONTROLLER in the sense that every agent is
designed according to MVC: the Abstraction matches the MVC Model, while
the presentation matches the MVC View and Controller.
 Luca Dan Serbanati - Software Design Techniques 135

PAC
• On a more macroscopic level, the PRESENTATION-ABSTRACTION-
CONTROL patterns is structured according to LAYERS: The top layer
contains the chief agent that controls the entire application; the middle layer
contains agents with coarse-grained functionality; the lower layer is
comprised of fine-grained agents that handle specific services, which users
interact with.

• The various agents usually need to propagate changes to the rest of the
agent hierarchy, and this can be achieved again through the PUBLISH-
PUBLISH
SUBSCRIBE pattern. Usually higher-level agents subscribe to the
notifications of lower-level agents.
C2-Components and Connectors

An alternative to MVC and PAC for applications with

extensive user interface requirements and other
particular requirements is the C2 architectural
pattern.

136
 Luca Dan Serbanati - Software Design Techniques 137

Motivation
The C2 Pattern
An interactive system is comprised of multiple components such as GUI
widgets, conceptual models of those widgets at various levels, data
structures,
t t renderers,
d and
d off course application
li ti llogic.
i Th
The system
t may need
d
to support several requirements such as:
– different implementation language of components,
– different GUI frameworks reused
reused,
– distribution in a heterogeneous network,
– concurrent interaction of components without shared address spaces,
– run-time
run time reconfiguration
reconfiguration,
– multi-user interaction.
Yet the system needs to be designed to achieve separation of concerns and
satisfy its performance constraints
constraints.
Solution
The system is decomposed into a top-to-bottom hierarchy of concurrent
components that interact asynchronously by sending messages through
explicit connectors. Components submit request messages upwards in the
hierarchy, knowing the components above, but they send notification
messagesg downwards in the hierarchy, y, without knowingg the components
p
lying beneath. Components are only connected with connectors, but
connectors may be connected to both components and other connectors.
The purposes of connectors is to broadcast, route, and filter messages.
 Luca Dan Serbanati - Software Design Techniques 138

C2 Example
A example
An l off a C2 architecture
hit t with
ith ffour components
t iin th
three llayers, and
d ttwo
connectors that delimit the layers.

The C2 top
top-to-bottom
to bottom hierarchy resembles the form of a LAYERS architecture
in an upside-down order. A C2 component that belongs to a given layer,
uses the services of the layers above it by invoking services on them and
provides services to the layers below it by sending notifications to them.
Since the C2 pattern provides substrate independence, isolating a component
from the components underneath it, the layer where a component is placed
is in essence an INDIRECTION LAYER.
The interaction between the C2 components takes place through asynchronous
message exchange, thus utilizing an IMPLICIT INVOCATION mechanism,
and specifically callbacks, e.g. PUBLISH-SUBSCRIBE.
 Luca Dan Serbanati - Software Architectures 139

C2 ((Components
p and Connectors)) ((I))
Summary: An indirect invocation style in which independent components
communicate exclusively through message routing connectors. Strict rules
on connectors between components
p and connectors induce layering.
y g
Components: Independent, potentially concurrent message generators and/or
components.
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
connectors. state. Request
messages request performance of an action.
Topology: layers of components and connectors , with a defined top and
bottom wherein notifications flow downward and requests upward
bottom, upward.
Additional constraints imposed:
• All components and connectors have a defined top and bottom. The top of a
component may be attached to the bottom of a single connector and the
bottom of a component may be attached to the top of a single connector. No
direct component-to-component links are allowed; there is however no
bound on the number of components or connectors that may attached to a
single connector. When two connectors are attached to each other, it must
be from the bottom of one to the top of the other.
 Luca Dan Serbanati - Software Architectures 140

C2 (Components and Connectors) (II)

• Each component has a top and bottom domain domain. The top domain specifies
the set of notifications to which a component may react and the set of
requests that the component emits up an architecture. The bottom domain
p
specifies the set of notifications that this component
p emits down an
architecture and the set of requests to which it responds.
• Components may be hierarchically composed, where an entire architecture
becomes a single component in another, larger architecture.
• Each component may have its own thread(s) of control.control
• There can be no assumption of a shared address space among components
Qualities yielded:
p
• Substrate independence: ease in moving g the application
pp to new pplatforms.
• Applications composable from heterogeneous components running on
diverse platforms.
• Support for product lines.
• Ability to program in the model-view-controller style
style, but with very strong
separation.
• Support for concurrent components.
• Support for network distributed applications.
Typical uses: reactive, heterogeneous applications. Applications demanding
low-cost adaptability.
Cautions: event-routing across multiple layers can be insufficient. Overhead
high for some simple kinds of component interactions
interactions.
Relations to programming languages or environments: programming
frameworks are used to faciltate creation of implementations faithful to
architectures in the style. Support for Java, C, Ada.
 Luca Dan Serbanati - Software Design Techniques 141

Mixing the Layers Pattern with other Patterns

• Two adjacent LAYERS can be considered as a CLIENT-SERVER pair.
• The logic behind layers is especially obvious in the INDIRECTION LAYER
where a special
p layer
y “hides” the details of a component
p or subsystem
y and
provides access to its services.
• LAYERS is useful for separating higher-level from lower-level responsibilities
On the contrary, the patterns PIPES AND FILTERS and SHARED
REPOSITORY place all components at the same level of abstraction.
However, both of these patterns may use the LAYERS pattern for structuring
the internal architecture of individual architecture elements.
• A MICROKERNEL or MVC pattern are layered architectures with three
LAYERS.
Luca Dan Serbanati - Software Design Techniques

Distribution View
In the Distribution View the system is viewed as a number of components
that are distributed among network nodes (or different processes). The
concerns addressed by this view are:
• How do the distributed components interact with each other?
• How are the distributed components
p decoupled
p from each other?
• How are the quality attributes of interoperability, location-transparency,
performance, and modifiability supported?
Th components
The t are physically
h i ll located
l t d in
i different
diff t network
t k nodes
d or
processes. They interact with each other through connectors that pass
invocations or data from one to another. The details of these
interactions can be better explained in the Component Interaction
View. 142
Luca Dan Serbanati - Software Design Techniques 143

Remote-Procedure Call
 Luca Dan Serbanati - Software Design Techniques 144

The Remote-Procedure Call Pattern

Motivation
Consider the case where you want to realize an EXPLICIT INVOCATION in
a distributed setting
setting.
The use of low-level network protocols requires developers to invoke the
send and receive operations of the respective network protocol
implementations This is undesirable because the network access code
implementations.
cannot be reused, low-level details are not hidden, and thus solutions are
hard to maintain and understand.
Solution
REMOTE PROCEDURE CALLS extend the well-known procedure call
abstraction to distributed systems. They aim at letting a remote procedure
invocation behave as if it were a local invocation.
Programs are allowed to invoke procedures (or operations) in a different
process and/or on a remote machine.
REMOTE PROCEDURE CALLS leverage the CLIENT-SERVER pattern of
interaction: a client invokes operations, and a server provides a well-defined
set of operations that the client can invoke. To the client developer, these
operations look almost like local operations. A major difference is that
additional
dditi l errors might
i ht occur during
d i a remote t invocation,
i ti for
f examplel
because the network fails or the requested operation is not implemented by
the server. These errors must be signaled to the client
 Luca Dan Serbanati - Software Architectures 145

Distributed Objects
• Objects
Obj t are iinstantiated
t ti t d on diff
differentt hosts,
h t each h off which
hi h exposes a public
bli
interface. Objects can be anythings from data structures to legacy systems.
• The interfaces are special in that all parameters and return values must be
serializable so they can go over the network.
• The default mode of interaction between objects is synchronous procedure
call,, although
g asynchronous
y extensions are found in some p particular version
of distributed objects as CORBA.
• Basic idea: an application is broken up into objects which are effectively
software components that expose one or more interfaces.
interfaces In CORBA these
provided interfaces are specified in terms of Interface Definition Language
(IDL). It resembles the way class interfaces are specified in an OO
programming language
language. IDL is a strongly typed language
language.
interface salestax {
float calculate_tax ( in float taxable_amount );
}
module HelloApp {
interface Hello {
string sayHello();
oneway void shutdown();
};
};
Luca Dan Serbanati – Corba 3 146

Communication with remote objects

j
Oggetto
Client distribuito

Remote interface Communication technologies:

g
Remote interface CORBA, .NET e RMI-IIOP
use middleware .
Client proxy Server Proxy

Rete
Luca Dan Serbanati – Software Design Techniques 147

Middleware
Application Data Application Data
Middleware Layers
Middleware Middleware Middleware
Applications

Didtributed processing Services

Middl
Middleware D i S ifi
Domain-Specific
Services

Piattaforma Hw/Sw
Common
Middleware Services

Distribution
Examples Presentation Middleware

Host Infrastructure
Middle tier Middleware
Application Application

Data Mgm. Operating Systems

Middleware Middleware Components & Protocols

Database Hardware
Operating System Database
Luca Dan Serbanati – Corba 3 148

Host infrastructure middleware

• Remote Procedure Call Asynchronous

Event Handling
operation Asynchronous
Transfer of
Control
Client response Server Physical
Top Layer M
Memory
Client Server Access
Proxy Middle Layer Proxy Synchronization
Network Network
Protocol Bottom Layer Protocol

Network

Memory
Management
Scheduling
Luca Dan Serbanati - Design Patterns 149

Object Remote Invocation

CORBA
Client Code target object
ProxyObject

Codice Skeleton
Stub Code

Client ORB run-time ORB run time

run-time Server
Process environment environment Process

Computer Computer
 Luca Dan Serbanati - Software Architectures 150

Remote Invocation in CORBA

• In order to invoke the remote
object instance, the client first
obtains its object reference.
• To make the remote invocation,
the client uses the same code that
itt used in tthe
e local
oca invocation
ocat o we
e
just described, substituting the
object reference for the remote instance. When the ORB examines the object
reference and discovers that the target object is remote
remote, it routes the
invocation out over the network to the remote object's ORB.
• OMG has standardized this process at two key levels:
1 the client knows the type of object it's
1. it s invoking (that it's
it s a shopping cart
object, for instance), and the client stub and object skeleton are generated
from the same IDL. This means that the client knows exactly which
operations
ti it may invoke
i k
2. the client's ORB and object's ORB must agree on a common protocol - that
is, a representation to specify the target object, operation, all parameters
(input and output) of every type that they may use, and how all of this is
represented over the wire. OMG has defined this also - it's the standard
protocol IIOP.
Luca Dan Serbanati – Corba 3 151

Object Invocation Lifecycle

POA Object
Request

? Target
Client ? CORBA
C d
Code Obj t
Object
client_invoke() send_message() target_invoke() (Servant)
receive_message()

Oggetto Request Message

Proxyy p
interceptor p
interceptor
result() receive_message() send_message() result()

Reply

Server
Client Process
Process

Computer Computer
 Luca Dan Serbanati - Design Patterns 152

CORBA: Distributed Client/Server

CORBA: Common Object Request Broker Architecture
• IDL defines components’ boundary, i.e., interface with other components
• All components
t on ORB (Object
(Obj t Request
R t Broker)
B k ) use IDL as their
th i interface
i t f
• Every (distributed) CORBA object is a component.
• Static and Dynamic methods
– Two types of client-server invocation: static and dynamic
– The server is not aware whether the invoked method is static or dynamic
y
C C++ Ada COBOL Java Smalltalk C C++ Ada COBOL Java Smalltalk

IDL IDL IDL IDL IDL IDL

Client Stubs Server Skeletons

Corba IIOP ORB

 Luca Dan Serbanati - Software Architectures 153

CORBA Objects
j
• In CORBA you compile your IDL into client stubs and object skeletons, and
write your object (shown on the right) and a client for it (on the left). Stubs
and skeletons serve as proxies for clients and servers,
respectively. Because IDL defines interfaces so strictly, the stub on the
client side has no trouble meshing perfectly with the skeleton on the server
side, even if the two are compiled into different programming languages, or
even running on different ORBs from different vendors.
• I CORBA,
In CORBA every objectbj t iinstance
t h
has itits own unique
i object
bj t reference,
f an
identifying electronic token. Clients use the object references to direct their
invocations, identifying to the ORB the exact instance they want to invoke
Luca Dan Serbanati - Software Design Techniques 154

Broker Architecture
 Luca Dan Serbanati - Software Design Techniques 155

Motivation
The Broker Pattern
Distributed software system developers face many challenges that do not
arise in single-process software. One is the communication across
unreliable networks. Others are the integration of heterogeneous
components into coherent applications, as well as the efficient use of
networking g resources. If developers
p of distributed systems
y must overcome
all these challenges within their application code, they may lose their primary
focus: to develop applications that efficiently tackle their domain-specific
problems.
problems
Solution
A BROKER separates the communication functionality of a distributed
system from its application functionality. The BROKER hides and mediates
all communication between the objects or components of a system. A
BROKER consists of a client-side REQUESTOR to construct and forward
invocations, as well as a server-side INVOKER that is responsible for
invoking the operations of the target remote object. A MARSHALLER on
each side of the communication path handles the transformation of requests
and replies from programminglanguage native data types into a byte array
that can be sent over the transmission medium.
 Broker
Broker
Broker Broker
object

1..1 1..1
Cliente Server
Client Proxy Server Proxy

0..* Server
0..*
Client
o y
Proxy Server
Proxy
1..1
1..1

0..* 0..*
Cli t
Client Server
Client

Characteristics
The Broker pattern put forward decoupling the server and its clients.
A Broker object is an object which knows where the system objects are located.
This knowledge is learned at compile-time
compile-time, at run-time based on a dynamic
discovery or using a mixed policy .
Luca Dan Serbanati - Software Development Methods 156
 Broker (II)
Two indirection levels.
aClient : aProxy : Client anObject : otherProxy : aServer :
Client Proxy Broker Object Server Proxy Server The first level is composed
Register b proxies
by i which
hi h iisolate
l t th
the
Register clients from the servers.
The second level is
Subscribe represented by the broker
Subscribe
Subscribe object which isolates the
proxies from servers.
Notify(aS) First of all other activities a
Notify(aS)
Notifiy(aS) server has to register itself
Notify(uS) Notif(aS) at the broker.
Detach
Notify(aS) This way the broker can
Detach answer forf allll requests
t with
ith
Detach the server as target.
Notify(aS) Notify(aS)
When the client registers
itself at the local proxy
proxy, the
proxy asks it to register at
the server proxy.
This requests is exclusively
managed by the broker that
Luca Dan Serbanati - Software Development Methods 157 knows where the server is
located.
 Luca Dan Serbanati - Software Design Techniques 158

Broker and Other Patterns

The BROKER is a compound pattern that is realized using a number of
remoting patterns.
patterns The most foundational remoting patterns in a BROKER
architecture are mentioned above: REQUESTOR, INVOKER, and
MARSHALLER. There are many others. Some important examples are: a
CLIENT PROXY represents t the
th remotet object
bj t in
i th
the client
li t process. Thi
This
proxy has the same interface as the remote object it represents. An
INTERFACE DESCRIPTION is used to make the remote object’s interface
known to the clients. LOOKUP allows clients to discover remote objects.
The BROKER uses a LAYERS architecture.
Many well-known BROKER realizations are based on the CLIENT SERVER
pattern. However, the other patterns for component interactions, such as
EXPLICIT INVOCATION, PEER-TO-PEER, MESSAGE QUEUING, and
PUBLISH SUBSCRIBE can also use a BROKER to isolate communication
PUBLISH-SUBSCRIBE,
related concerns, when used in a distributed setting. Only in very simple
distributed systems or in distributed systems with severe constraints (e.g.
regarding performance
f and memory consumption), ) it might be advisable not
to use a BROKER.
Luca Dan Serbanati - Software Design Techniques 159

Broker Example
 Luca Dan Serbanati – Software Architecture 160

ORB Architecture
Object
Implementation
Client

Client requests

Stub IDL Dynamic

Stub IDL Stub
d
del IDL Skeleton
li t Dynamic
l cliente
Dynamic Stub IDL ORB ORB Static IDL Object
Invocation Object
Skeleton
IR - Interface Static cliente
del IDL del cliente
Invocation del cliente Interface
Stubs Interface Skeletons Interface Adapter
Adapter
repository Interface Implementation
repository

ORB Core (IIOP)

Network

• The ORB is responsible for all of the mechanisms required to find the object
implementation for the request, to prepare the object implementation to
receive the request, and to communicate the data making up the request.
The interface the client sees is completely independent of where the object
is located, what programming language it is implemented in, or any other
aspect that is not reflected in the object’sinterface.
• ORB iis universal
i l -> interoperability
i t bilit off implementations.
i l t ti
• IIOP - Inter-ORB (IIOP) - TCP/IP for CORBA .
• ORBs must implement IIOP.
 Luca Dan Serbanati - Software Architectures 161

•
CORBA
ORB Interface
O
Architecture
te ace – Itt provides
Components
p o des access to every
e e y ORB
O service
se ce e except
cept c
(I)
client
e t
invocations (which go through the stubs or the DII), and object activations
and calls (which come through the object adapter, typically a POA). Access
to initial services such as the Naming Service, Trader Service, Root
POA access to the
POA, h IFR
IFR, and
d construction
i off DII iinvocations,
i object
bj
reference operations, etc.
• Interface Repository – It is the component of the ORB that provides
persistent storage of interface definitions
definitions—it it manages and provides access
to a collection of object definitions specified in OMG IDL. An ORB provides
distributed access to a collection of objects using the objects’ publicly
defined interfaces specified in OMG IDL. The Interface Repository provides
for the storage, distribution, and management of a collection of related
objects’ interface definitions.
• Dynamic Invocation Interface - The DII describes the client’s side of the
interface that allows dynamic creation and invocation of request to objects.
DII-based invocations differ from stub-based invocations in the same way
that scripts differ from programs: they're interpreted at run time, and not
compiled in a previous step
step. Using the DII
DII, a client can invoke an operation
on a new type of object that it's just discovered (for example, using the
Trader Service). The invocation itself is a CORBA object with its own object
reference.
reference
• Stub - The stubs are produced by the IDL compiler, each one marshaling the
arguments called for in its definition. There is a separate stub for each
operation of each interface.
 Luca Dan Serbanati - Software Architectures 162

CORBA Architecture Components (II)

• Skeleton - The object-interface-specific
object interface specific ORB component which assists an
object adapter in passing requests to particular methods.
• Dynamic Skeleton Interface – It is a way to deliver requests from an ORB to
an object implementation that does not have compile
compile-time
time knowledge of the
type of the object it is implementing. This contrasts with the type-specific,
OMG IDL-based skeletons, but serves the same architectural role. DSI
allows a dynamic handling of object invocations: rather than being accessed
through a skeleton that is specific to a particular operation, an object’s
implementation is reached through an interface that provides access to the
operation name/parameters in a manner analogous to the client side’sside s DII.
DII
• Portable Object Adapter - The POA is the piece of the ORB that manages
server-side resources for scalability. By deactivating objects' servants when
they have no work to do do, and activating them again when they're
they re needed
needed, we
can stretch the same amount of hardware to service many more clients. The
programmer fixes resource allocation/de-allocation patterns by setting POA
Policys These determine whether object references created by the POA are
Policys.
transient or persistent; whether activation is per-method-call or longer or
shorter; and how multiple CORBA objects (either of a single type, or multiple
t
types)) map to
t servants.t
• Implementation Repository - A storage place for object implementation
information.
 Luca Dan Serbanati – Corba 3 163

Common middleware services

Extends distribution middleware
with domain-independent
services
i f “business
for “b i l i ”
logic”.
Common middleware services
pp facilities in distributed
support
systems:
•Transaction management
•Authentication/autorization
•Database connection pooling
and access synchronization
•Dynamic management of
resources

Exemples
CORBA Object
Obj t Services,
S i CORBA Component
C t
Services, Sun’s J2EE, Microsoft’s .NET
Luca Dan Serbanati – Corba 3 164

OMA Reference Model

Common Facilities
Vertical Common (Domain) Facilities
Application Objects
(interfaces)
Horizontal Common Facilities
Internalization Print Mobile Agent
Service Facility Facility

Object Request Broker (ORB)

Persis Concur
Naming tence Life Cycle Properties rency Collection Security Trading

Externa Events Transactions Querys Relation Time Startup

lization Licensing
ships
Common Object Services (CORBA Services)
 IDL
Luca Dan Serbanati – Corba 3 165

1 Creare le
C++ definizioni IDL 2

C
Compilation
il ti
Carica Interface
x.idl Repository
3 Precompilare

xx.h
h Adattatore
xx_skel.h
skel h di oggetti
tti
x.cpp x_skel.cpp
7
Stub IDL Skeleton 6
del client
Implementation
p
utilizza 4 Repository
8 instance
Implementare
Implementare
il client
il server Java
srv.cpp Count.idl
x cpp
x.cpp module Counter
5 Count
9 Compilare { interface Count
Compilare sum : long { attribute long sum;
long increment ();
increment() };
Classe server };
Classe client eseguibile
eseguibile RPC

idl

C++ ORB Counter

Runtime
Library

class class class class class class class

CountStub Count Count CountPOA Count Count Count

Helper Holder POATie Operations

client side Java server side Java

 Luca Dan Serbanati - Software Architectures 166

Summary:
Distributed
y Application
pp functionality
Objects
y broken up
p into objects
j ((coarse- or fine-
grained) that can run on heterogeneous hosts and can be written in
heterogeneous programming languages . Objects provide services to other
objects through well-defined provided interfaces. Objects invoke methods
across host
host, process
process, and language boundaries via remote procedure call
(RPCs), generally facilitated by middleware.
Components: Objects (software components exposing services through well-
defined provided interfaces).
Connectors: Remote procedure calls (RMIs).
Data elements: Arguments to methods, return values, and exceptions.
Topology: General graph of objects from callers to callees; in general, required
services
i are nott explicitly
li itl represented.
t d
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
faults.
Qualities yielded: Strict separation of interfaces from implementations as wellas
other qualities of OO systems in general, plus mostly-transparent
interoperability across location, platform, and language boundaries.
Typical uses: Creation of distributed software systems composed of
components running on different hosts. Integration of software components
written in different programming languages or for different platforms.
Cautions: Interactions tend to be mostly synchronous and do not take
advantage of the concurrency present in distributed systems. Difficulty
dealing with streams and high-volume data flows.
Relations to programming languages or environments: Any language .
Luca Dan Serbanati - Software Design Techniques 167

Message Queuing
 Luca Dan Serbanati - Software Design Techniques 168

Message Queuing
Motivation
Consider a situation similar to that of REMOTE PROCEDURE CALLS, but it
is necessary to decouple the sender from the receiver to realize queuing of
invocations Queuing is necessary
invocations. necessary, for instance
instance, when temporal outages of
the receiver should be tolerated or when heterogeneous systems should be
integrated. For instance, when a legacy system using BATCH SEQUENTIAL
should be integrated into a distributed system
system, only one invocation can be
handled at a time by that system. Somewhere additional messages must be
queued until the system is ready to process the next message.
Solution
Messages are not passed from client to server application directly, but
through intermediate message queues that store and forward the messages.
q
This has a number of consequences: senders and receivers of messages
g
are decoupled, so they do not need to know each other’s location (perhaps
not even the identity). A sender just puts messages into a particular queue
and does not necessarily know who consumes the messages. For example,
a message might be consumed by more than one receiver. Receivers
consume messages by monitoring queues.
 Luca Dan Serbanati - Software Design Techniques 169

Message
g Queuing
g Example
p
• MESSAGE QUEUING realizes CLIENT-SERVER interactions and
implements IMPLICIT INVOCATION as the primary invocation pattern.
 Luca Dan Serbanati - Software Design Techniques 170

Bibliography
1. D. Garlan, M. Shaw, "An Introduction to Software Architecture", Advances in
Software Engineering and Knowledge Engineering"
Engineering , Volume II, World Scientific
Scientific, 1993
2. P. Avgeriou, U. Zdun, “Architectural Patterns Revisited – A Pattern Language”, in:
Proceedings of 10th European Conference on Pattern Languages of Programs
(EuroPlop 2005),
2005) Irsee,
Irsee Germany,
Germany July,
July 2005
3. Neil B. Harrison, Paris Avgeriou, Uwe Zdun, "Using Patterns to Capture Architectural
Decisions," IEEE Software, vol. 24, no. 4, pp. 38-45, July/Aug. 2007