Corso di Ingegneria del Software - Dipartimento...

Corso di Ingegneria del Software

Paolo Bottoni

Lezione 7: Progetto Architetturale

Lezione7ArchitettureIngegneria del Software 2Ingegneria del Software

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

Lezione7ArchitettureIngegneria del Software 3

Architettura software

• Progetto architetturale: Processo che identifica

sotto-sistemi e quadro di riferimento per

controllo e comunicazione sotto-sistemi

• Risultato è descrizione di architettura software.


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


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


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


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


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


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?


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


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


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


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


Uso di architettura generica

• 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


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


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


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 UscitaPrinter

Database

Lezione7Architetture 18Ingegneria del Software

Diagramma di flusso dati per stipendi

Read employee

record

Read monthly

pay data

Compute

salary

Write tax

transactions

Monthly pay

data

Tax

tables

Tax

transactions

Pension data

Validate

employee data

Write pension

data

Write bank

transaction

Write social

security data

Employee

records

Monthly pay

rates

Bank

transactions

Social security

data

Print payslip

Decoded

employee

record

Pay information

Valid

employee record

Tax deduction + SS

number + tax office

Pension

deduction +

SS number

Empoyee data

+ deductions

Net payment + bank

account info.

Social security

deduction + SS number

PRINTER


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 Application logTransaction

managerDatabase


Organizzazione sistema bancomat

Get customer

account id

Validate card

Input

Query account

Update account

Print details

Return card

Dispense cash

Process Output

Select service

ATM Database ATM


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.

Transazioni

serializzate

Gestore elaborazione

remota

Base di dati

conti

Bancomat e sportelli

Interrogazioni e

aggiornamenti conti


Architettura di applicazione stratificata

• Tipica per sistemi informativi

• Strato di presentazione

– presentazione risultati calcolo

– raccolta ingressi utente

• 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

Interfaccia utente

Ritrovamento e modifica informazione

Gestione transazioni

Base di dati

Comunicazioni con utente


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


Organizzazione LIBSYS

Web browser interface

Distributedsearch

Accounting

LIBSYSlogin

Forms andquery manager

Library index

Documentretrieval

DB1 DB2 DB3 DB4 DBn

Rightsmanager

Printmanager

Ingegneria del Software 25Lezione7Architetture

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


Architetture sistemi di allocazione risorse

• Sistemi stratificati:

– Base di dati di risorse

– Insieme di regole per allocazione

– Gestore di risorse

– Allocatore di risorse

– Autenticazione utente

– Gestore interrogazioni

– Componente consegna risorse

– Interfaccia utente

User interface

Resource

management

Resource policy

control

Resource

allocation

User

authentication

Query

management

Resource database

Resource

delivery

Transaction management


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

Webbrowser

Web serverApplication

serverDatabase

server


Sistemi di elaborazione eventi

• Rispondono a eventi nel loro ambiente

• Tempo dell'evento impredicibile

• Tipi più comuni

– Sistemi a tempo reale

– Sistemi di editing


Sistemi di editing

• Sistemi a utenti singoli

• Devono fornire retroazione rapida ad azioni utente

• Organizzati su transazioni lunghe

– Possono includere strumenti per recupero


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


Architettura sistema editing

File System

saveopen

Editor data

Editingcommands

Ancillary data

Ancillarycommands

Command

interpret

Screen

refresh

Display

update

Event

process


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


Sistema elaborazione linguaggio

Translator

Check syntaxCheck semantics

Generate

Interpreter

FetchExecute

Abstract m/cinstructions

Data Results

Instructions


Componenti elaboratore di linguaggio

• Analizzatore lessicale

• Tabella dei simboli

• Analizzatore sintattico

• Albero sintattico

• Analizzatore semantico

• Generatore di codice


Stili di decomposizione modulare

• Decomposizione di sotto-sistemi in moduli

• Non c'è distinzione rigida fra organizzazione

sistema e decomposizione modulare


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


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

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


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


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


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


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


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



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


Sistema di elaborazione delle fatture

issue ()

sendReminder ()

acceptPayment ()

sendReceipt ()

invoice#

date

amount

customer

invoice#

date

amount

customer#

invoice#

date

amount

customer#

customer#

name

address

credit period

Customer

Payment

Invoice

Receipt


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.


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


Sistema di elaborazione di fattura

Lettura

invoices

Identify

payments

Issue

receipts

Find

payments

due

Receipts

Issue

payment

reminder

Reminders

Fatture Payments


Modello a condotta di compilatore

Lexical

analysis

Syntactic

analysis

Semantic

analysis

Code

generation

Symbol table

Syntax tree


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


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


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


Architettura strumenti CASE

Deposito dati progettoTraduttore

progetti

Editor di

programmi

Editor di

progetti

Generatore di

codice

Analizzatore

progettoGeneratore

rapporti


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


Modello a deposito di compilatore

Syntax

analyser

Lexical

analyser

Semantic

analyser

Abstractsyntax tree

Grammardefinition

Symbol

table

Output

definition

Pretty -

printer

Editor

Optimiser

Code

generator

Repository


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


Calcolatori in una rete C/S

Network

SC1SC2

CC1 CC2 CC3

CC5 CC6CC4

Server

computer

Client

computer

s1, s2 s3, s4

c5, c6, c7

c1 c2 c3, c4

c8, c9 C10, C11, C12


Biblioteca di film e foto

Catalogue server

Library catalogue

Video server

Film clip files

Picture server

Digitised

photographs

Web server

Film and photo

info

Client 1 Client 2 Client 3 Client 4

Internet


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 server e servizi disponibili

60Lezione7ArchitettureIngegneria del Software

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

Thin-client

Fat-client

Client

Client

Server

Data management

Application processing

Presentation

Server

Data management

Presentation

Application processing


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


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 da installare su tutti i clienti


Sistema bancomat client-server

Account server

Customeraccountdatabase

Tele-processing

monitor

ATM

ATM

ATM

ATM

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

Client

Server

Data

management

Presentation

Server

Application

processing


Sistema bancario via Internet

Database server

Customeraccountdatabase

Web serverClient

Client

Account serviceprovision

SQL

SQL query

HTTP interaction

Client

Client


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.


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


Sistema di gestione delle versioni

Strato gestione configurazione sistema

Strato sistema base di dati

Strato sistema operativo

Strato sistema gestione oggetti


Stili di controllo

• Interesse: flusso di controllo tra sotto-sistemi

Distinto da modello decomposizione sistema

• Controllo centralizzato

– Sotto-sistema specifico con responsabilità 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


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


Modello a chiamata e ritorno

Routine 1.2Routine 1.1 Routine 3.2Routine 3.1

Routine 2 Routine 3Routine 1

Main program


Controllo di sistema in tempo reale

System

controller

User

interface

Fault

handler

Computation

processes

Actuator

processesSensor

processes


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


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

Event and message handler

Sub-system2 Sub-system3 Sub-system4


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


Controllo guidato da interruzioni

Handler1 Handler2 Handler3 Handler4

Process1 Process2 Process3 Process4

Interrupts

Interrupt

vector


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


Architettura a oggetti distribuiti

Object request broker

o1 o2 o3 o4

o5

S (o1) S (o2) S (o3) S (o4)

S (o5) S (o6)

o6


Vantaggi architettura a oggetti distribuiti

• Permette di ritardare decisioni su dove e

come fornire servizi

• Architettura molto aperta

• Risorse aggiungibili dinamicamente

• Sistema flessibile e scalabile

• Possibile riconfigurare dinamicamente

sistema con oggetti che migrano in rete


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


Modelli architetturali p2p

• Architettura di rete logica

– Architetture decentralizzate

– Architetture semicentralizzate

• Architettura di applicazione

– Organizzazione generica di componenti


Architettura p2p decentralizzata

n1

n2 n3

n4

n5

n6

n7

n8

n9 n10 n11

n12

n13

n13


Architettura p2p semi-centralizzata

Discoveryserver

n1

n2

n3

n4

n5

n6


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.


Servizi web

Service

registry

Service

requestor

Service

provider

Publish

Bind

Find

service


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


Lezione8ArchitettureIngegneria del Software 87Ingegneria del Software 87Ingegneria del Software

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.


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


Sistema auto

User interface

Locator

Discovers carposition

Weatherinfo

Receives requestfrom user

Receiver

Receivesinformation stream

from services

Transmitter

Sends position andinformation request

to services

Radio

Translates digitalinfo stream to

radio signal

In-car software system

Mobile Info Service

Facilitiesinfo

Translator

Roadlocator

Trafficinfo

Collates information

Road traffic info

command

gps coord

gps

coordgps coordgps coord

Language

infoInfo

stream

Service discovery

Finds availableservices

Architetture a microservizi

• Architettura decomposta funzionalmente

• Insieme di servizi che collaborano

• Ogni servizio implementa un insieme di funzioni

strettamente correlate

• Comunicazione sincrona o asincrona

• Sviluppo e dispiegamento indipendenti

• Ogni servizio ha propria base di dati

• Se necessario, consistenza tramite meccanismi

di replicazione o eventi da applicazione

Lezione8ArchitettureIngegneria del Software

Un esempio

Accesso a risorse

Lezione8ArchitettureIngegneria del Software

Lezione8ArchitettureIngegneria del Software 92Ingegneria del SoftwareIngegneria del Software

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.


Modello di riferimento OSI

Presentation

Session

Transport

Network

Data link

Physical

7

6

5

4

3

2

1

Communications medium

Network

Data link

Physical

Application

Presentation

Session

Transport

Network

Data link

Physical

Application


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


Modello di riferimento ECMA

Toolslots

Message

services

Task management services

User inter face services

Data repository services

Data integration services

Corso di Ingegneria del Software - Dipartimento...

Documents

Transcript of Corso di Ingegneria del Software - Dipartimento...