Sistemi di elaborazione dati

Corso di Ingegneria del Software
Paolo Bottoni
Lezione 11: Progetto Architetturale
Obiettivi
•
•
•
•
•
Introdurre importanza progetto architetturale.
Spiegare decisioni di progetto architetturale.
Illustrare alcune architetture di applicazione.
Illustrare alcune architetture distribuite.
Discutere architetture di riferimento per
comunicare e confrontare architetture.
Ingegneria del Software
Lezione11Architetture
2
Architettura software
• Progetto architetturale: Processo che identifica
sotto-sistemi e quadro di riferimento per
controllo e comunicazione sotto-sistemi.
• Risultato è descrizione di architettura software.
Ingegneria del Software
Lezione11Architetture
3
Progetto architetturale
•
•
•
•
Stadio iniziale processo di progetto.
Collegamento tra specifica e progetto.
Spesso condotto in parallelo con specifica
Comporta identificazione componenti
principali sistema e loro comunicazioni.
Ingegneria del Software
Lezione11Architetture
4
Vantaggi di un'architettura esplicita
• Comunicazione con stakeholder
– Architettura focalizza discussione.
• Analisi sistema
– Investigare soddisfazione requisiti non funzionali.
• Riuso su larga scala.
– Riutilizzabile per vari sistemi.
Ingegneria del Software
Lezione11Architetture
5
Architettura e requisiti non-funzionali
• Prestazioni
– Localizzare operazioni critiche e minimizzare comunicazioni.
– Usare componenti di grana grossa piuttosto che fine.
• Sicurezza
– Usare architettura stratificata con valori critici in strati interni.
• Salvaguardia
– Localizzare caratteristiche critiche in piccolo numero di sottosistemi.
• Disponibilità
– Includere componenti ridondanti e meccanismi di tolleranza a errori.
• Manutenibilità
– Usare componenti di grana fine, rimpiazzabili.
Ingegneria del Software
Lezione11Architetture
6
Conflitti architetturali
• Uso di componenti di grana grossa migliora
prestazioni ma riduce manutenibilità.
• Introduzione dati ridondanti migliora disponibilità,
ma più difficile garantire sicurezza.
• Localizzare caratteristiche di salvaguardia porta
a più comunicazione, quindi degrada prestazioni.
Ingegneria del Software
Lezione11Architetture
7
Strutturazione del sistema
• Decomposizione in sotto-sistemi interagenti.
• Diagramma a blocchi mostra visione generale
struttura sistema.
• Modelli più specifici per condivisione dati fra
sotto-sistemi, distribuzione e interfacciamento.
Ingegneria del Software
Lezione11Architetture
8
Decisioni di progetto architetturale
•
•
•
•
•
•
•
•
Esiste architettura applicativa generica?
Come sarà distribuito sistema?
Quali stili architetturali sono appropriati?
Che approccio sarà usato per strutturare sistema?
Come sarà decomposto sistema in moduli?
Che strategia di controllo sarà usata?
Come sarà valutato progetto architetturale?
Come sarà documentata architettura?
Ingegneria del Software
Lezione11Architetture
9
Riuso dell'architettura
• Per sistemi stesso dominio spesso architetture
simili che riflettono concetti dominio.
• Linee di prodotti applicativi costruiti intorno ad
architettura base con varianti che soddisfano
particolari requisiti cliente.
Ingegneria del Software
Lezione11Architetture
10
Stili architetturali
• Modello architetturale di sistema può conformarsi a
generico modello o stile architetturale.
• Conoscenza stili semplifica definizione architettura.
• Grandi sistemi spesso eterogenei.
– Non seguono singolo stile architetturale.
Ingegneria del Software
Lezione11Architetture
11
Modelli architetturali
•
•
•
•
•
Usati per documentare progetto architetturale.
Modello strutturale statico per componenti principali.
Modello di processo dinamico per struttura processo.
Modello di interfaccia per interfacce sotto-sistemi.
Modello di relazioni per relazioni fra sotto-sistemi
– Es. Modello di flusso dei dati
• Modello di distribuzione per distribuzione su macchine.
Ingegneria del Software
Lezione11Architetture
12
Architetture di applicazione generiche
• Sistemi applicativi progettati per rispondere
a bisogno organizzativo
• Attività economiche hanno caratteristiche
comuni. Sistemi con architettura comune
che riflette requisiti applicativi.
• Architettura generica configurata e adattata
per rispondere a requisiti specifici.
Ingegneria del Software
Lezione11Architetture
13
Uso di architetture di applicazione
•
•
•
•
•
Punto di partenza per progetto architetturale
Lista di controllo per progetto
Modo di organizzare lavoro gruppo di sviluppo
Mezzo per valutare componenti per riuso
Vocabolario per parlare di tipi dell'applicazione.
Ingegneria del Software
Lezione11Architetture
14
Tipi di applicazione
• Applicazioni di elaborazione dati
– Guidate da dati, elaborano dati a lotti senza intervento
utente esplicito durante elaborazione.
• Applicazioni di elaborazione di transazioni
– Centrate su dati, elaborano richieste utente e
aggiornano informazioni in base di dati.
• Sistemi di elaborazione di eventi
– Azioni sistema da interpretazione eventi in ambiente
• Sistemi di elaborazione di linguaggi
– Intenzioni utente specificate in linguaggio formale
elaborato e interpretato da sistema.
Ingegneria del Software
Lezione11Architetture
15
Esempi
• Sistemi di elaborazione dati
– Sistemi di addebito
– Sistemi di paghe
• Sistemi di elaborazione di transazioni
– Sistemi di e-commerce
– Sistemi di prenotazione
• Sistemi di elaborazione di eventi
– Elaboratori di testi
– Sistemi a tempo reale
• Sistemi di elaborazione di linguaggi
– Compilatori
– Interpreti di comandi
Ingegneria del Software
Lezione11Architetture
16
Sistemi di elaborazione dati
• Basi di dati solitamente ordini di grandezza
maggiori del software stesso.
• Dati introdotti e ottenuti in lotti
– Ingresso: insieme di numeri di clienti e letture
associate di contatori elettrici.
– Uscita: insieme di bollette corrispondenti, una
per ogni numero cliente.
• Struttura: ingresso-elaborazione-uscita.
Ingegneria del Software
Lezione11Architetture
17
Ingresso-elaborazione-uscita
• Componente ingresso legge dati da documento o
base di dati, controlla validità, accoda dati validi.
• Componente processo preleva transazione da coda
ingresso, crea nuova struttura con risultati calcolo.
• Componente uscita legge strutture, le organizza e
le scrive su base di dati o manda a stampante.
Sistema
Ingresso
Processo
Uscita
Printer
Database
Ingegneria del Software
Lezione11Architetture
18
Diagramma di flusso dati per stipendi
Tax deduction + SS
number + tax office
Employee
records
Read employee
record
Decoded
employee
record
Read monthly
pay data
Write pension
data
Monthly pay
rates
Compute
salary
Pay information
Print payslip
Empoyee data
+ deductions
Net payment + bank
account info.
Tax
tables
Monthly pay
data
Ingegneria del Software
Tax
transactions
Pension data
Pension
deduction +
SS number
Valid
employee record
Validate
employee data
Write tax
transactions
Social security
deduction + SS number
PRINTER
Write bank
transaction
Bank
transactions
Write social
security data
Social security
data
Lezione11Architetture
19
Sistemi di elaborazione transazioni
• Elabora richieste utente di informazione da base
di dati o di aggiornamento base.
• Prospettiva utente:
– Sequenza coerente di operazioni che soddisfa obiettivo.
• Es. trovare orari voli da Londra a Parigi.
• Richieste utente verso servizio asincrone.
– Elaborate da gestore transazioni.
I/O processing
Ingegneria del Software
Application log
Transaction
manager
Lezione11Architetture
Database
20
Organizzazione sistema bancomat
Input
Get customer
account id
Process
Output
Print details
Query account
Validate card
Return card
Update account
Select service
ATM
Ingegneria del Software
Dispense cash
Database
Lezione11Architetture
ATM
21
Strato intermedio gestione transazioni
• Gestisce comunicazione con diversi tipi di
terminali (es. Bancomat e terminali a sportello),
serializza dati e li invia per elaborazione.
• Elaborazione richiesta in base di dati.
• Risultati a terminale tramite gestore di transazioni.
Interrogazioni e
aggiornamenti conti
Transazioni
serializzate
Gestore elaborazione
remota
Base di dati
conti
Bancomat e sportelli
Ingegneria del Software
Lezione11Architetture
22
Architettura di applicazione stratificata
• Tipica per sistemi informativi
• Strato di presentazione
– presentazione risultati calcolo
– raccolta ingressi utente
Interfaccia utente
Comunicazioni con utente
Ritrovamento e modifica informazione
Gestione transazioni
Base di dati
• Strato di comunicazione con utente
– Disaccoppiamento da dispositivo
• Strato di elaborazione
– fornisce funzionalità specifiche applicazione
• Es. in sistema bancario, "apri conto", "chiudi conto"
• Strato di gestione dati
– Gestisce basi dati.
Ingegneria del Software
Lezione11Architetture
23
Architettura LIBSYS
• Sistema biblioteca LIBSYS.
• Strato di comunicazione utente
– Componente per login.
– Gestore moduli e interrogazioni.
– Gestore stampa.
• Strato ritrovamento informazione
–
–
–
–
Ricerca distriibuita.
Ritrovamento documento.
Gestore dei diritti.
Contabilità.
Ingegneria del Software
Lezione11Architetture
24
Organizzazione LIBSYS
Web browser interface
LIBSYS
login
Distributed
search
Forms and
query manager
Document
retrieval
Print
manager
Rights
manager
Accounting
Library index
DB1
Ingegneria del Software
DB2
DB3
DB4
Lezione11Architetture
DBn
25
Sistemi di allocazione risorse
• Quantità fissata di risorse da allocare a utenti.
• Esempi:
– Sistemi di gestione orario.
– Sistemi di biblioteca.
– Sistemi di controllo traffico aereo.
Ingegneria del Software
Lezione11Architetture
26
Architetture sistemi di allocazione risorse
• Sistemi stratificati:
–
–
–
–
–
–
–
–
Base di dati di risorse.
User interface
Insieme di regole per allocazione
Gestore di risorse
User
Query
Resource
authentication
delivery management
Allocatore di risorse
Autenticazione utente
Resource
Resource policy Resource
management
allocation
control
Gestore interrogazioni
Componente consegna risorse
Transaction management
Interfaccia utente
Resource database
Ingegneria del Software
Lezione11Architetture
27
Architettura di sistema e-commerce
• Sistemi di gestione risorse su Internet che
accettano ordini elettronici per merci o servizi.
• Più livelli
– strati applicativi associati a ogni livello.
Web
browser
Ingegneria del Software
Web server
Application
server
Lezione11Architetture
Database
server
28
Sistemi di elaborazione eventi
• Rispondono a eventi nel loro ambiente
• Tempo dell'evento impredicibile.
• Tipi più comuni
– Sistemi a tempo reale
– Sistemi di editing
Ingegneria del Software
Lezione11Architetture
29
Sistemi di editing
• Sistemi a utenti singoli
• Devono fornire retroazione rapida ad azioni utente
• Organizzati su transazioni lunghe.
– Possono includere strumenti per recupero.
Ingegneria del Software
Lezione11Architetture
30
Componenti sistemi di editing
• Naturalmente orientati a oggetti:
–
–
–
–
–
–
–
Schermo –gestisce memoria schermo e individua eventi.
Evento – riconosce eventi e li passa a elaborazione.
Comando – esegue comando utente.
Dati editor – gestisce struttura dati editor.
Dati ausiliari – gestisce altri dati, es. stili e preferenze.
Sistema di documenti – gestisce I/O documenti.
Display – aggiorna immagine schermo.
Ingegneria del Software
Lezione11Architetture
31
Architettura sistema editing
File System
save
open
Ancillary data
Editor data
Ancillary
commands
Editing
commands
Command
Display
interpret
update
Event
Screen
process
refresh
Ingegneria del Software
Lezione11Architetture
32
Sistemi elaborazione linguaggio
• Accetta linguaggio naturale o artificiale come
ingresso e genera rappresentazione diversa.
• Può includere interprete per agire su istruzioni
linguaggio in elaborazione.
• Usati quando modo più semplice per risolvere
problema è descrivere algoritmo o dati di sistema.
– Strumenti Meta-CASE elaborano descrizioni di
strumenti, regole di metodi, etc. e generano strumenti.
Ingegneria del Software
Lezione11Architetture
33
Sistema elaborazione linguaggio
Translator
Instructions
Check syntax
Check semantics
Generate
Abstract m/c
instructions
Interpreter
Data
Ingegneria del Software
Fetch
Execute
Lezione11Architetture
Results
34
Componenti elaboratore di linguaggio
•
•
•
•
•
•
Analizzatore lessicale
Tabella dei simboli
Analizzatore sintattico
Albero sintattico
Analizzatore semantico
Generatore di codice
Ingegneria del Software
Lezione11Architetture
35
Stili di decomposizione modulare
• Decomposizione di sotto-sistemi in moduli.
• Non c'è distinzione rigida fra organizzazione
sistema e decomposizione modulare.
Ingegneria del Software
Lezione11Architetture
36
Sotto-sistemi e moduli
• Sotto-sistema è sistema in sé con operazioni
indipendenti da servizi forniti da altri sotto-sistemi.
• Modulo è componente di sistema che fornisce
servizi ad altre componenti, ma non è
normalmente considerato sistema separato.
Ingegneria del Software
Lezione11Architetture
37
Decomposizione modulare
• Due modelli:
– Modello a oggetti: decomposizione in oggetti interagenti.
– Modello a condotta, o flusso di dati: decomposizione in
modelli funzionali che trasformano ingressi in uscite.
• Se possibile, decisioni su concorrenza ritardate
fino a implementazione dei moduli.
Ingegneria del Software
Lezione11Architetture
38
Metodi di progetto I
• Decomposizione funzionale
–
–
–
–
Ripartisce funzioni o requisiti in moduli
Inizia da funzioni elencate in specifica requisiti
Progetto a basso livello divide in sottofunzioni, assegnate a sottomoduli
Descrive dipendenze di chiamate fra moduli
Ingegneria del Software
Lezione11Architetture
39
Metodi di progetto II
• Decomposizione orientata alle caratteristiche
– Assegna caratteristiche a moduli
– Progetto alto livello: servizio e collezione di caratteristiche
– Progetto a basso livello:
• come ogni caratteristica incrementa servizio
• Interazioni fra caratteristiche
Ingegneria del Software
Lezione11Architetture
40
Metodi di progetto III
• Decomposizione orientata ai dati
• Fuoco su come ripartizione dati fra moduli
• Progetto alto livello: strutture dati concettuali
• Progetto basso livello
• Distribuzione dati fra moduli
• Dati distribuiti realizzano modelli concettuali
Ingegneria del Software
Lezione11Architetture
41
Metodi di progetto IV
• Decomposizione orientata a processi
• Sistema ripartito in processi concorrenti
• Progetto alto livello:
• Identifica compiti principali sistema
• Assegna compiti a processi da eseguire
• Specifica come si coordinano compiti
• Progetto a basso livello: dettagli su processi
Ingegneria del Software
Lezione11Architetture
42
Metodi di progetto V
• Decomposizione orientata a eventi
• Fuoco su eventi da gestire
• Assegna responsibilità per eventi a diversi moduli
• Progetto alto livello: cataloga eventi attesi in input per sistema
• Progetto basso livello:
• Decomposizione sistema in stati
• Specifica come eventi attivano trasformazioni di stato
Ingegneria del Software
Lezione11Architetture
43
Metodi di progetto VI
• Decomposizione orientata a oggetti
• Assegna oggetti a moduli
• Progetto alto livello:
• Identifica tipi di oggetti in sistema
• Specifica relazioni fra oggetti
• Progetto basso livello dettaglia attributi e operazioni oggetti
Ingegneria del Software
Lezione11Architetture
44
Modelli a oggetti
• Strutturano sistema in insieme di oggetti
debolmente accoppiati con interfacce ben definite.
• Decomposizione orientata a oggetti interessata a
identificare classi di oggetti, attributi e operazioni.
• Quando implementati, oggetti creati da classi e
modello di controllo coordina operazioni oggetti.
Ingegneria del Software
Lezione11Architetture
45
Sistema di elaborazione delle fatture
Customer
customer#
name
address
credit period
Payment
invoice#
date
amount
customer#
Ingegneria del Software
Receipt
Invoice
invoice#
date
amount
customer
invoice#
date
amount
customer#
issue ()
sendReminder ()
acceptPayment ()
sendReceipt ()
Lezione11Architetture
46
Vantaggi del modello a oggetti
• Accoppiamento debole: Implementazione
modificabile senza influenzare altri oggetti.
• Oggetti possono riflettere entità mondo reale.
• Linguaggi OO largamente usati
• Problemi:
– Da cambiamenti interfaccia oggetti.
– Entità complesse difficili da rappresentare come oggetti.
Ingegneria del Software
Lezione11Architetture
47
Condotte orientate alla funzione
• Trasformazioni funzionali
– Elaborano ingressi e producono uscite.
• Modello a condotta e filtri
– Es. shell UNIX
• Adatto per:
– trasformazioni sequenziali
– modello di elaborazione a lotti
– sistemi di elaborazione dati.
• Non adatto a sistemi interattivi.
Ingegneria del Software
Lezione11Architetture
48
Sistema di elaborazione di fattura
Lettura
invoices
Fatture
Issue
receipts
Receipts
Find
payments
due
Issue
payment
r eminder
Identify
payments
Reminders
Payments
Ingegneria del Software
Lezione11Architetture
49
Modello a condotta di compilatore
Symbol table
Syntax tree
Lexical
analysis
Ingegneria del Software
Syntactic
analysis
Semantic
analysis
Lezione11Architetture
Code
generation
50
Vantaggi modello a condotta
•
•
•
•
Supporta riuso di trasformazioni.
Intuitivo per comunicazione con stakeholder.
Facile aggiungere nuove trasformazioni.
Implementazione semplice.
– Sistema concorrente o sequenziale
• Problema:
– Richiede formato comune per trasferimento dati.
– Difficile supporto per interazione basata su eventi.
Ingegneria del Software
Lezione11Architetture
51
Organizzazione di sistema
• Strategia di base per strutturare sistema.
• Tre stili organizzativi largamente usati:
– Stile a deposito di dati condiviso
– Stile a servizi e server condivisi
– Stile a macchina astratta o stratificato
Ingegneria del Software
Lezione11Architetture
52
Modello a deposito
• Sotto-sistemi devono scambiare dati:
– Dati condivisi mantenuti in base di dati o deposito
centrale, acceduti da ogni sotto-sistema.
– Ogni sotto-sistema mantiene propria base di dati e
passa dati esplicitamente ad altri sotto-sistemi.
• Modello a deposito più usato quando si
devono condividere grandi quantità di dati.
Ingegneria del Software
Lezione11Architetture
53
Architettura strumenti CASE
Editor di
progetti
Traduttore
progetti
Deposito dati progetto
Analizzatore
progetto
Ingegneria del Software
Generatore di
codice
Editor di
programmi
Generatore
rapporti
Lezione11Architetture
54
Caratteristiche modello a deposito
• Vantaggi
–
–
–
–
Modo efficiente di condividere grandi quantità di dati.
Sotto-sistemi non interessati a come prodotti dati.
Gestione centralizzata per backup, sicurezza, ecc.
Modello di condivisione pubblicato come schema deposito
• Svantaggi
– Sotto-sistemi devono accordarsi su modello dati deposito.
• Compromessi inevitabili.
– Evoluzione dati difficile e costosa.
– Non c'è spazio per politiche di gestione specifiche.
– Difficile distribuire efficacemente.
Ingegneria del Software
Lezione11Architetture
55
Modello a deposito di compilatore
Lexical
analyser
Pretty printer
Editor
Syntax
analyser
Semantic
analyser
Abstract
syntax tree
Grammar
definition
Symbol
table
Output
definition
Optimiser
Code
generator
Repository
Ingegneria del Software
Lezione11Architetture
56
Modello client-server
• Distribuzione dati ed elaborazione fra componenti.
• Server indipendenti forniscono servizi specifici, es.
stampa, gestione dati.
• Clienti chiamano servizi.
• Rete permette a clienti di accedere a server.
– Clienti conoscono server, server non necessitano conoscere clienti
• Clienti e server processi logici.
• Rapporto processori e processi non necessariamente 1:1.
Ingegneria del Software
Lezione11Architetture
57
Calcolatori in una rete C/S
c1
CC1
c2
CC2
CC3
c3, c4
Network
s1, s2
s3, s4
SC2
Server
computer
SC1
c5, c6, c7
c8, c9
CC4
Ingegneria del Software
CC5
C10, C11, C12
Client
computer
CC6
Lezione11Architetture
58
Biblioteca di film e foto
Client 1
Client 2
Client 3
Client 4
Internet
Catalogue server
Video server
Picture server
Web server
Library catalogue
Film clip files
Digitised
photographs
Film and photo
info
Ingegneria del Software
Lezione11Architetture
59
Caratteristiche client-server
• Vantaggi
– Distribuzione dati immediata.
– Uso efficace sistemi interconnessi.
• Può richiedere hardware più economico.
– Facile aggiungere nuovi server o aggiornare esistenti.
• Svantaggi
– Mancano modelli condivisi di dati. Sottosistemi con diverse
organizzazioni dati. Scambio può essere inefficiente.
– Gestione ridondante in ogni server.
– Nessun registro centrale di nomi e servizi. Può essere
difficile trovare quali server e servizi sono disponibili.
Ingegneria del Software
Lezione11Architetture
60
Clienti "sottili" e "grassi"
• Modello a cliente sottile
– Elaborazione e gestione di dati su server. Cliente
responsabile solo software presentazione.
• Modello a cliente grasso
– Server responsabile solo gestione dati. Cliente
ha logica applicazione e interazione con utente.
Presentation
Thin-client
Presentation
Application processing
Client
Ingegneria del Software
Data management
Application processing
Client
Fat-client
Server
Server
Data management
Lezione11Architetture
61
Modello a cliente sottile
• Per sistemi in lascito migrati a client-server.
– Sistema in lascito come server a se stante
– Interfaccia grafica implementata su client.
• Svantaggio principale:
– Pesante carico di elaborazione su server e rete.
Ingegneria del Software
Lezione11Architetture
62
Modello a cliente grasso
• Più elaborazione delegata al cliente.
• Più adatto per nuovi sistemi C/S con
capacità del sistema cliente note in anticipo.
• Gestione più complessa. Nuove versioni
applicazione vanno installate su tutti i clienti.
Ingegneria del Software
Lezione11Architetture
63
Sistema bancomat client-server
ATM
ATM
Account server
Teleprocessing
monitor
Customer
account
database
ATM
ATM
Ingegneria del Software
Lezione11Architetture
64
Architetture a tre livelli
• Ogni strato eseguibile su processore dedicato.
– Prestazioni migliori di cliente sottile
– Più semplice da gestire di cliente grasso.
• Architettura più scalabile
– Nuovi server aggiungibili se domanda aumenta.
Presentation
Client
Ingegneria del Software
Server
Server
Application
processing
Data
management
Lezione11Architetture
65
Sistema bancario via Internet
Client
HTTP interaction
Client
Web server
Database server
SQL query
Account service
provision
SQL
Customer
account
database
Client
Client
Ingegneria del Software
Lezione11Architetture
66
Uso di architetture C/S
Architettura
Applicazione
C/S a due livelli
con clienti sottili
Sistemi in lascito dove non pratico separare elaborazione e gestione dati.
Peso su computazione con poca gestione dati (e.g. compilatori). .
Peso su dati con poca elaborazione (e.g. browsing e querying).
C/S a due livelli
con clienti grassi
Elaborazione fornita da software esterno su client (e.g. Excel).
Richiesta computazione grandi quantità dati (e.g. visualizzazIone dati).
Funzionalità utente relativamente stabili con gestione sistema stabile.
C/S a tre o più strati
Applicazioni su grande scala con centinaia o migliaia di clienti.
Dati e applicazioni volatili.
Integrazione di dati da fonti multiple.
Ingegneria del Software
Lezione11Architetture
67
Modello a macchina astratta (stratificata)
• Usato per modellare interfacciamento di sotto-sistemi.
• Organizza sistema in insieme di strati (macchine astratte).
– Ogni strato fornisce insieme di servizi.
• Sviluppo incrementale di sotto-sistemi in strati diversi.
– Cambiamento interfaccia strato influenza solo strato adiacente.
• Organizzazione sistema spesso artificiale.
Ingegneria del Software
Lezione11Architetture
68
Sistema di gestione delle versioni
Strato gestione configurazione sistema
Strato sistema gestione oggetti
Strato sistema base di dati
Strato sistema operativo
Ingegneria del Software
Lezione11Architetture
69
Stili di controllo
• Interesse: flusso di controllo tra sotto-sistemi.
Distinto da modello decomposizione sistema.
• Controllo centralizzato
– Sotto-sistema specifico con responsabilità generale
di controllo. Fa partire e arrestare altri sotto-sistemi.
• Controllo basato su eventi
– Ogni sotto-sistema può rispondere a eventi generati
esternamente da altri sotto-sistemi o da ambiente.
Ingegneria del Software
Lezione11Architetture
70
Controllo centralizzato
• Sotto-sistema di controllo assume responsabilità
gestione esecuzione altri sotto-sistemi.
• Modello a chiamata e ritorno
– Modello a sottoprogrammi top-down. Controllo parte in
cima a gerarchia di subroutine e si muove verso basso.
Applicabile a sistemi sequenziali.
• Modello di gestore
– Applicabile a sistemi concorrenti. Componente specifica
controlla arresto, partenza e coordinamento di altri
processi di sistema. Implementabile in programma
sequenziale come struttura case.
Ingegneria del Software
Lezione11Architetture
71
Modello a chiamata e ritorno
Main program
Routine 1
Routine 1.1
Ingegneria del Software
Routine 1.2
Routine 2
Routine 3
Routine 3.1
Lezione11Architetture
Routine 3.2
72
Controllo di sistema in tempo reale
Actuator
processes
Sensor
processes
System
controller
Computation
processes
Ingegneria del Software
User
interface
Lezione11Architetture
Fault
handler
73
Sistemi guidati da eventi
• Eventi generati esternamente. Temporizzazione eventi
fuori da controllo sotto-sistemi che li elaborano.
• Due modelli principali
– Modelli broadcast. Evento trasmesso a ogni sotto-sistema.
Ogni sottosistema in grado di gestire evento può farlo
– Modelli guidati da interruzioni in sistemi a tempo reale.
Interruzioni individuate da gestore interruzioni e passate a
componente per elaborazione
• Altri modelli guidati da eventi.
– fogli elettronici
– sistemi di regole
Ingegneria del Software
Lezione11Architetture
74
Modello broadcast
• Integrare sotto-sistemi su calcolatori diversi in una rete.
• Sotto-sistemi registrano proprio interesse in tipi di eventi.
– Su occorrenza evento, controllo a sotto-sistema che può gestirlo.
• Politica di controllo non incorporata in evento o gestore.
– Sotto-sistemi decidono su eventi di interesse per loro.
• Sotto-sistemi non sanno se o quando evento gestito.
Sub-system1
Sub-system2
Sub-system3
Sub-system4
Event and message handler
Ingegneria del Software
Lezione11Architetture
75
Sistemi guidati da interruzioni
• Usati in sistemi a tempo reale
– essenziale risposta veloce a evento.
• Tipi di interruzione noti
– gestore definito per ogni tipo.
• Tipi associati a locazioni di memoria
• Interruttore hardware trasferisce controllo a gestore.
• Difficile da programmare e validare.
Ingegneria del Software
Lezione11Architetture
76
Controllo guidato da interruzioni
Interrupts
Interrupt
vector
Handler1
Handler2
Handler3
Handler4
Process1
Process2
Process3
Process4
Ingegneria del Software
Lezione11Architetture
77
Architetture a oggetti distribuiti
• Non c'è distinzione fra cliente e server
• Ogni entità distribuibile è oggetto
– Fornisce e riceve servizi a e da altri oggetti.
• Comunicazione fra oggetti attraverso middleware
– Ricevitore di richieste di oggetti.
• Più complesse da progettare di sistemi C/S.
Ingegneria del Software
Lezione11Architetture
78
Architettura a oggetti distribuiti
o1
o2
o3
o4
S (o1)
S (o2)
S (o3)
S (o4)
Object request broker
o5
o6
S (o5)
S (o6)
Ingegneria del Software
Lezione11Architetture
79
Vantaggi architettura a oggetti distribuiti
• Permette di ritardare decisioni su dove e
come fornire servizi.
• Architettura molto aperta. Risorse possono
essere aggiunte dinamicamente.
• Sistema flessibile e scalabile.
• Possibile riconfigurare dinamicamente
sistema con oggetti che migrano in rete.
Ingegneria del Software
Lezione11Architetture
80
Architetture peer-to-peer (p2p)
• Sistemi decentralizzati
– Computazioni possono essere condotte in ogni nodo.
• Sistema globale sfrutta potenza computazionale
e di memoria di gran numero di calcolatori in rete.
• Uso crescente a livello di impresa.
Ingegneria del Software
Lezione11Architetture
81
Modelli architetturali p2p
• Architettura di rete logica
– Architetture decentralizzate
– Architetture semicentralizzate
• Architettura di applicazione
– Organizzazione generica di componenti
Ingegneria del Software
Lezione11Architetture
82
Architettura p2p decentralizzata
n4
n6
n8
n7
n2
n1 3
n1 2
n3
n1 3
n9
n1
n1 0
n1 1
n5
Ingegneria del Software
Lezione11Architetture
83
Architettura p2p semi-centralizzata
Discovery
server
n4
n1
n3
n6
n5
n2
Ingegneria del Software
Lezione11Architetture
84
Architetture orientate ai servizi
• Servizi forniti esternamente (web service).
• Servizio Web, approccio standard per rendere
disponibile e accessibile componente riusabile
tramite Web.
– Esempio: servizio di sottomissione per tasse: utenti
compilano moduli fiscali e li sottomettono.
Ingegneria del Software
Lezione11Architetture
85
Servizi web
Service
registry
Publish
Find
Service
requestor
Ingegneria del Software
Service
provider
service
Bind
Lezione11Architetture
86
Servizi e oggetti distribuiti
•
•
•
•
•
•
•
Indipendenza fornitore
Pubblicizzazione disponibilità servizio
Potenzialmente, assegnazione servizio a run-time
Costruzione di nuovi servizi attraverso composizione.
Pagamento per uso dei servizi
Applicazioni più piccole e compatte
Applicazioni reattive e adattive.
Ingegneria del Software
Lezione11Architetture
87
Standard di servizi
• Servizi basati su standard condivisi, basati su XML.
– Possono essere forniti su ogni piattaforma e scritti in
qualsiasi linguaggio di programmazione.
• Standard principali
– SOAP - Simple Object Access Protocol;
– WSDL - Web Services Description Language;
– UDDI - Universal Description, Discovery and Integration.
Ingegneria del Software
Lezione8Architetture
88
Scenario di servizi
• Sistema informativo per automobile fornisce a
guidatori informazioni su tempo, condizioni traffico,
informazione locale, etc.
• Collegato a autoradio
– Informazione trasmessa come segnale su canale specifico
• Auto dispone di ricevitore GPS
• Basandosi su posizione, sistema accede a vari servizi
di informazione
– Informazione può essere trasmessa in linguaggio guidatore
Ingegneria del Software
Lezione8Architetture
89
Sistema auto
Road traffic info
Weather
info
Facilities
info
gps coord
Road
locator
gps
coord
gps coord
Mobile Info Service
Translator
Info
stream
Language
info
Traffic
info
Collates information
Service discovery
Finds available
services
command
gps coord
Receiver
Transmitter
User inter face
Receives
information stream
from services
Sends position and
information request
to services
Receives request
from user
Radio
Translates digital
info stream to
radio signal
Locator
Discovers car
position
In-car software system
Ingegneria del Software
Lezione8Architetture
90
Architetture di riferimento
• Modelli architetturali possono essere specifici a
qualche dominio applicativo.
• Due tipi di modelli specifici a dominio
– Modelli generici:
• astrazioni da sistemi reali, incapsulano caratteristiche principali.
– Modelli di riferimento:
• modelli astratti, idealizzati.
• Forniscono mezzo di informazione su classe di sistemi, e di
confronto fra architetture diverse. Derivati da studio dominio.
– Es. Modello OSI stratificato per sistemi di comunicazione.
• Generici bottom-up; riferimento top-down.
Ingegneria del Software
Lezione8Architetture
91
Modello di riferimento OSI
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
Communications medium
Ingegneria del Software
Lezione8Architetture
92
Modello di riferimento CASE
• Servizio di deposito dati
– Memorizzazione e gestione elementi dati
• Servizi di integrazione dati
– Gestione gruppi di entità
• Servizi di gestione compiti
– Definizione e attivazione di modelli di processo
• Servizi di messaggistica
– Comunicazione fra strumenti e fra strumenti e ambiente
• Servizi di interfacce utente
– Sviluppo di interfacce utente
Ingegneria del Software
Lezione8Architetture
93
Modello di riferimento ECMA
Data repository services
Data integ ration services
Tool
slots
Task management services
User inter face services
Ingegneria del Software
Lezione8Architetture
Message
services
94