1

Lezione 12. Architetture e Design

[S2001, Capp. 10-11]

1. System structuring• repository-based• client server• abstract machines (layered architecture)

2. Control policy models• centralised control• event driven systems

3. Design process and techniques

2

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

3

Architectural design process

System structuring• The system is decomposed into several principal sub-systems

and communications between these sub-systems are identified

Control modelling• A model of the control relationships between the different parts

of the system is established

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

4

Sub-systems and modules

A sub-system is a system in its own right whose operation is independent of the services provided by other sub-systems.

A module is a system component that provides services to other components but is not considered as a separate system

5

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 sub-

systems share data, are distributed, and interface with each other may be considered (1.1-1.3)

Language: UML!!! (Class, Activity diagrams, subsystems, packages…)

6

Packing robot control systemVisionsystem

Objectidentification

system

Armcontroller

Grippercontroller

Packagingselectionsystem

Packingsystem

Conveyorcontroller

Valore relativo (-> stakeholders)di rappresentazioni box-diagramin cui le frecce non hanno significatopreciso...

7

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

8

CASE toolset architecture

Projectrepository

Designtranslator

Programeditor

Designeditor

Codegenerator

Designanalyser

Reportgenerator

9

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

10

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

11

Film and picture library

Catalogueserver

Catalogue

Videoserver

Film clipfiles

Pictureserver

Digitizedphotographs

Hypertextserver

Hypertextweb

Client 1 Client 2 Client 3 Client 4

Wide-bandwidth network

Transmit quickly,in synchrony, low resolution

High resolution, no stringent timingrequirements

(complementaryinfo)

Providing linksto other servers

The client program is an ntegrated user-interface to the services

12

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)

13

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)

14

Architecture of a Version Management System

Operatingsystem

Database system

Object management

Version management

15

OSI architecture (‘reference model’)

Application

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communica tions medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

16

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

17

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.

18

2. Control policy models An architectural model identifies subsystems, not the way these

are controlled. Control models are concerned with the control flow among sub-

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

19

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.

20

Centralised control / Call-return model

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Mainprogram

Modelling system control dynamics, not structure: Subsystem1.1 is not necessarily part of Subsystem 1.

(Main subsystem)

(Other subsystems)

Advantage: Easy to analyse flow of controlDisadvantage: Not easy to handle exceptions

21

Centralised control / Manager model

Systemcontroller

Userinterface

Faulthandler

Computationprocesses

Actuatorprocesses

Sensorprocesses

Control decisionsdepend on state variables

Adequate for‘soft’ real time systems.System loops continuously,polling subsystems for eventsor state changes

22

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

23

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

24

Sub-system1

Event and message handler

Sub-system2

Sub-system3

Sub-system4

- Used for in Softbench (Hewlett-Packard CASE, ‘93)- Used in distributed object communication (e.g. in CORBA)

25

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

26

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

27

Handler1

Handler2

Handler3

Handler4

Process1

Process2

Process3

Process4

Interrupts

Interruptvector

28

3. Design process and techniques Design is concerned with filling the empty boxes of the

architecture Design addresses another structural level where sub-

systems 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

29

Phases in the design process

Architecturaldesign

Abstractspecificatio

n

Interfacedesign

Componentdesign

Datastructuredesign

Algorithmdesign

Systemarchitecture

Softwarespecification

Interfacespecification

Componentspecification

Datastructure

specification

Algorithmspecification

Requirementsspecification

Design activities

Design products

30

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

31

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.

32

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.

33

Functional and Object-Oriented methods

Functional 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]

Object-Oriented methods• Robinson ‘92 - Booch ‘94

• Jacobsen et al. ‘93

• Rumbaugh… ===> Rational Unified Process and UML

Intermediate method• Jackson System Development - JSD [Jackson ‘83]

34

Functional view of a compiler

AnalyseBuild

symboltable

Scansource

Generatecode

Symboltable

Outputerrors

Sourceprogram

Tokens Tokens Syntaxtree

Objectcode

ErrorindicatorSymbols Symbols

Errormessages

35

Object-oriented view of a compiler

Sourceprogram

Tokenstream

Symboltable

Syntaxtree

Grammar Errormessages

Abstractcode

Objectcode

Scan Add

CheckGet

Build Print

Generate

Generate

36

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.

37

Esempio: Aircraft architecture

Instrumentdisplay

Navigationsystem

Enginecontrol

Radarsystem

Commssystem

38

Da Object-Oriented a functional a Object-Oriented

High level architecture: objects• The navigation system

• The radar system

• The communications system

• The instrument display system

• The engine control system

System functions (intermediate level)• 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...