Transcript Architectural Design - ISTI-CNR

Lezione 12. Architetture e Design

[S2001, Capp. 10-11]

1. System structuring
•
•
•

2. Control policy models
•
•

repository-based
client server
abstract machines (layered architecture)
centralised control
event driven systems
3. Design process and techniques
1
Architectural design

Establishing the overall structure of a software system

Architects are the technical interface between the customer
and the developer

A bad architectural design for a building cannot be rescued
by good construction; the same is true for software.

A bad architecture may prevent the achievement of
performance, robustness, distributability, maintainability
requirements
2
Architectural design process

System structuring
•

Control modelling
•


A model of the control relationships between the different parts
of the system is established
Modular decomposition
•

The system is decomposed into several principal sub-systems
and communications between these sub-systems are identified
The identified sub-systems are decomposed into modules
In pratica, queste attività non sono ordinate temporalmente, per il solito principio
del rapido feedback.
Anche la fase di specifica formale (concettualmente precedente) puo’ intersecarsi
con la definizione dell’architettura.
3
Sub-systems and modules


A sub-system is a system in its own right whose operation
is independent of the services provided by other subsystems.
A module is a system component that provides services to
other components but is not considered as a separate
system
4
1. System structuring




Concerned with decomposing the system into interacting
sub-systems
The architectural design is normally expressed as a
possibly nested block diagram
More specific architectural models showing how subsystems share data, are distributed, and interface with
each other may be considered (1.1-1.3)
Language: UML!!! (Class, Activity diagrams, subsystems,
packages…)
5
Packing robot control system
Vision
system
Object
identification
system
Arm
controller
Packaging
selection
system
Packing
system
Gripper
controller
Valore relativo (-> stakeholders)
di rappresentazioni box-diagram
in cui le frecce non hanno significato
preciso...
Conveyor
controller
6
1.1 - Repository-based architecture

Sub-systems must exchange data. This may be done in
two ways:
•
•

Shared data is held in a central database or repository and may be
accessed by all sub-systems
Each sub-system maintains its own database and passes data explicitly
to other sub-systems
When large amounts of data are to be shared, the
repository model is convenient
•
Examples: Command and control, CAD, CASE Toolset
7
CASE toolset architecture
Design
editor
Design
translator
Code
generator
Project
repository
Design
analyser
Program
editor
Report
generator
8
Repository model characteristics

Advantages
•
•
•
•

Efficient way to share large amounts of data (write once for all to read)
A sub-systems need not be concerned with how data is used/produced by every
other subsystem
Centralised management of backup, security, access control...
Sharing model is published as the repository schema ==> easy to add new
subsystems
Disadvantages
•
•
•
•
Sub-systems must agree on a compromise data model ==> lower performance
Data evolution (adopting new data model) is difficult and expensive, because:
(a) the repository is large, (b) all subsystems must be updated
Different subsystem may have different reqs on backup, security… Not supported
Difficult (but possible) to distribute on several machines the centralised repository
efficiently
9
1.2 - Client-server architecture

Distributed system model where data and processing are
distributed across processors:
•
•
•
Set of stand-alone servers which provide specific services such as printing,
file management, compiling, etc.
Set of clients which call on these services (by remote procedure calls). These
are typically concurrent subsystems.
Network which allows clients to access servers.

Clients must know the names and nature of the Servers;
Servers need not know the identity and number of Clients.

Can be used to implement a repository-based system

•
•
the repository is the (only) server
subsystems accessing the repository are the clients
10
Film and picture library
The client program is an ntegrated user-interface
to the services
Client 1
Client 2
Client 3
Client 4
Wide-bandwidth network
Catalogue
server
Video
server
Picture
server
Hypertext
server
Catalogue
Film clip
files
Digitiz ed
photographs
Hypertext
web
Providing links
to other servers
Transmit quickly,
in synchrony,
low resolution
High resolution,
no stringent timing
requirements
(complementary
info)
11
Client-server characteristics

Advantages
•
•
•

Distribution of data is straightforward
Makes effective use of networked systems. May require cheaper
hardware, exactly sized for specific service
Easy to add new servers or upgrade existing servers
Disadvantages
•
•
•
No shared data model: sub-systems use different data organisation.
Data interchange may be inefficient
Redundant management (backup, recovery…) in each server
No central register of names and services - it may be hard to find out
what servers and services are available (in WAN more than in LAN)
12
1.3 - Abstract machine (layered) architecture

Organises the system into a set of layers, called abstract
machines, each of which provide a set of services, representing
the abstract machine language

Typically used for compiler systems, to increase platform
independency (==>portability)
•
•
Layer 2 - Translator from Java source to Java bytecode (machine-independent)
Layer 1 - Translator from Java bytecode to machine code (machine dependent)
13
Architecture of a Version Management System
Version management
Object management
Database system
Operating
system
14
OSI architecture (‘reference model’)
7
Application
Application
6
Presentation
Presentation
5
Session
Session
4
Transport
Transport
3
Network
Network
Network
2
Data link
Data link
Data link
1
Physical
Physical
Physical
Communica tions medium
15

Reference models are derived from a study of the
application domain rather than of a single system

May be used as a basis for system implementation or to
compare different systems. It acts as a standard against
which individual system architectures can be evaluated
16
Layered architecture characteristics

Advantages
•
•

Supports the incremental development of sub-systems in
different layers, by incremental delivery of services.
Supports change by minimizing its impact: when a layer
interface changes, only the adjacent upper layer is affected
Disadvantages
•
•
Basic facilities provided by inner layers (e.g. file management)
may be required by several layers up, breaking the model.
Performance is reduced by multiple levels of command
interpretation.
17
2. Control policy models


An architectural model identifies subsystems, not the way these
are controlled.
Control models are concerned with the control flow among subsystems.
•
•

Centralised control --- One sub-system has overall responsibility for controlling
the other subsystems; it starts and stops them
Event-based control --- Each sub-system can respond to externally generated
events from other sub-systems or from the system’s environment
Centralised and event-based control models can be applied to
any of the previous architectural models (at least in
principle……...).
18
2.1 - Centralised control

Call-return model
•

Applicable to sequential systems. Analogous to Top-down
subroutine model of programs, where control starts at the top of
a subroutine hierarchy and moves downwards.
Manager model
•
Applicable to concurrent systems. One system component
controls the stopping, starting and coordination of other system
processes.
» A process is a subsystem or module which can execute in parallel
with other processes.
19
Centralised control / Call-return model
(Main subsystem)
Main
program
Modelling system control dynamics,
not structure: Subsystem1.1 is not
necessarily part of Subsystem 1.
(Other subsystems)
Routine 1
Routine 1.1
Routine 2
Routine 1.2
Advantage: Easy to analyse flow of control
Disadvantage: Not easy to handle exceptions
Routine 3
Routine 3.1
Routine 3.2
20
Centralised control / Manager model
Sensor
processes
Actuator
processes
Control decisions
depend on
state variables
System
contr oller
Computation
processes
User
interface
Adequate for
‘soft’ real time systems.
System loops continuously,
polling subsystems for events
or state changes
Fault
handler
21
2.2 - Event-driven systems

In the previous, centralised-control architectures control decisions depend on
system state variables. By contrast, event driven systems are driven by events,
generated by the environment or by the subsystems themselves

Broadcast models.
•

An event is broadcast to possibly all sub-systems. Any sub-system which
can handle the event may do so
Interrupt-driven models.
•
Used in real-time systems where external interrupts are detected by an
interrupt handler and passed to some other component for processing
22
Event-driven systems / Broadcast model

Effective in integrating sub-systems on different computers in a
network

Sub-systems register an interest in specific events. When these occur,
the Event and Message Handler (EMH, p. 24) checks the register and
transfers the event and control to the sub-system(s) interested in
handling the event (or, possibly, to all of them)

Control policy is not embedded in the EMH, as in central controller
of p. 21: sub-systems decide autonomously on events of interest to
them

The EMH may support also point to point communication between
subsystems
23
Sub-system
1
Sub-system
2
Sub-system
3
Sub-system
4
Event and message handler
- Used for in Softbench (Hewlett-Packard CASE, ‘93)
- Used in distributed object communication (e.g. in CORBA)
24
Broadcast model pros and cons

Advantages
•
•

Evolution is simple: a newly added subsystem just informs the
event handler of its interest on a subset of events
Subsystems activate each other indirectly, by sending events to
EMH, and do not have to know their addresses. Distribution is
transparent to subsystems
Disadvantages
•
•
Subsystems don’t know if/when the events they generate will be
handled
Conflicts if two subsystems share interests for same event
25
Event-driven systems / Interrupt-driven

Used in real-time systems where fast response to an event
is essential

Basic idea: (see figure ===>)
•
•
•

There are known interrupt types with a handler defined for each type
Each type is associated with a memory location where the
corresponding handler’s address is stored.
A fast hardware switch causes immediate transfer of control to the
relevant handler, which may in turn activate specific processes.
Can be combined with (non-reactive) centralized control
model
26
Interrupts
Interrupt
vector
Handler
1
Handler
2
Handler
3
Handler
4
Process
1
Process
2
Process
3
Process
4
27
3. Design process and techniques



Design is concerned with filling the empty boxes of the
architecture
Design addresses another structural level where subsystems are decomposed into modules
Two main modular decomposition techniques (models)
•
•
An object model where the system is decomposed into interacting
objects
A data-flow model where the system is decomposed into functional
modules which transform inputs to outputs. Also known as the pipeline
model
28
Phases in the design process
Re quire me nts
spec ifica
tion
De sign acvities
ti
Arc hite ctur
al
design
Abstra ct
spec ifica
tio
n
Interfa ce
design
Component
design
Data
structur
e
design
Algorithm
design
Syste m
a rc hite ctur
e
Softwa re
spec ifica
tion
Interfa ce
spec ifica
tion
Component
spec ifica
tion
Data
structur
e
spec ifica
tion
Algorithm
spec ifica
tion
De sign pr
oducts
29
Design phases






Architectural design Identify sub-systems
Abstract specification Specify sub-systems
Interface design Describe sub-system interfaces
Component design Decompose sub-systems
into components
Data structure design Design data structures to
hold problem data
Algorithm design Design algorithms for problem
functions
30
Structured design methods


Structured methods are sets of activities, notations, report
formats, design guidelines (good practice), for
expressing a software design.
Many methods support several system representations and
diagram types:
•
•
•
•

Data flow diagrams showing data transformations
Entity-relation diagrams describing the logical data structures
Structural diagrams showing system components and their interactions
In the O-O approach, also inheritance diagrams, and diagrams showing how
an object is composed by, and uses other objects.
Many methods are supported by CASE tools.
31
Two fundamental design strategies

Functional design (more traditional)
•
•

Starts with high-level view of the system functionality and proceeds primarily
top-down, by refinements (system decomposition).
The system state is centralised and shared between the functions operating on
that state. (But in Data Flow one can distribute data sources and sinks…)
Object-oriented design (more recent)
•
•
•
•
•
O-O as programming discipline known since early 70’s, but OOA (Analysis)
and OOD (Design) widespread since late 80’s.
The system is viewed as a collection of interacting objects.
Proceeds both top-down and bottom-up (by re-using and combining
components).
Does not require a single, most abstract system view at the root of the
decomposition tree.
The system state is de-centralised and each object manages its own state.
32
Functional and Object-Oriented methods

Functional methods
•
•
•
•
•

Object-Oriented methods
•
•
•

Stepwise refinement [Wirth ‘71, ‘76]
Jackson Structured Programming ‘75
Warnier-Orr ‘77
Structured Design (parte di SA/SD: structured analysis, structured
design) [Constantine,Yourdon’ 79]
SSADM [Cutts ‘88, Weaver ‘93]
Robinson ‘92 - Booch ‘94
Jacobsen et al. ‘93
Rumbaugh… ===> Rational Unified Process and UML
Intermediate method
•
Jackson System Development - JSD [Jackson ‘83]
33
Functional view of a compiler
Source
program
Tokens
Scan
source
Syntax
tree
Tokens
Build
symbol
table
Symbols
Symbol
table
Analyse
Symbols
Object
code
Generate
code
Error
indicator
Output
errors
Error
messages
34
Object-oriented view of a compiler
Scan
Source
program
Add
Token
stream
Symbol
table
Check
Syntax
tree
Get
Gr ammar
Build
Print
Err or
messages
Generate
Object
code
Abstract
code
Generate
35
Mixed-strategy design

Object-oriented and functional-oriented approach to design are complementary

Good software engineers should select the most appropriate approach for
whatever sub-system is being designed

Analogamente, adottando LOTOS come linguaggio di Design, nello stesso
progetto possono co-esistere gli stili constraint-oriented, resource-oriented e
state-oriented.
36
Esempio: Aircraft architecture
Navigation
system
Engine
control
Instrument
display
Radar
system
Comms
system
37
Da Object-Oriented a functional a Object-Oriented

High level architecture: objects
•
•
•
•
•

System functions (intermediate level)
•
•
•
•
•

The navigation system
The radar system
The communications system
The instrument display system
The engine control system
Display track (radar sub-system)
Compensate for wind speed (navigation sub-system)
Reduce power (engine sub-system)
Indicate emergency (instrument sub-system)
Lock onto frequency (communications sub-system)
Low-level objects
•
•
•
•
The engine status
The aircraft position
The altimeter
The radio beacon...
38