• Vedi
• Modifica
• Versioni
• Stampa

Progettazione

Progettazione

Autori: Alberto Taiocchi

Introduzione

L’ingegneria progettuale inizia quando termina la prima iterazione dell’ingegneria dei requisiti. Lo scopo della progettazione del software è quello di applicare un insieme di principi, concetti e attività pratiche che conducano allo sviluppo di un sistema di qualità. L’obiettivo della progettazione è quello di creare un modello del software che implementi correttamente tutti i requisiti del cliente e risulti di facile lettura e comprensione per i programmatori. Gli ingegneri del software devono esaminare varie alternative di progettazione e convergere su una soluzione adatta al progetto.

Criteri generali

Ruolo della progettazione

La progettazione specifica la struttura ed il funzionamento di un software che soddisfi le specifiche (funzionali e non funzionali), costruibile con le risorse assegnate (vincoli di costo, tempo e personale). I compiti e le esigenze della progettazione comprendono:

• Soddisfacimento delle specifiche funzionali e non funzionali
• Costruibilità
• Rispetto dei vincoli (Personale, tempo, costi)
• Controllo della complessità, scelta della soluzione più semplice
• Tracciabilità del lavoro svolto in modo da poter verificare e controllare l’evolversi del sistema
• Riuso dell’esistente, il codice esistenze è corretto, si risparmiano tempo e costi
• Supporto per l’evoluzione nel tempo, sia nel tempo della stesura del progetto, sia nel tempo di vita del prodotto.

Il ruolo dell’ingegnere durante la fase di progettazione è quello di unire conoscenze, problemi, vincoli, risorse per generare una soluzione. La soluzione non potrà mai essere quella ottimale in quanto i vincoli impongono dei limiti.

Documento di progettazione

Il documento di progettazione è il risultato della progettazione e prende il nome di progetto. E’ un documento che specifica:

• Come le funzioni sono allocate a componenti software.
• Come i componenti interagiscono tra di loro.
• L’ambiente utilizzato per l’implementazione
• Dettagli esecutivi, cioè delle linee da seguire per l’implementazione.

In alcune realtà aziendali il documento di progettazione non è usato come dovrebbe, si possono trovare disegni orientativi e non dettagliati, architetture e dettagli mischiati. Il documento non contiene informazioni che poi verranno implementate. Ci sono anche casi nei quali il documento non esiste. Capita spesso che il progetto è costruito a posteriori per questioni contrattuali con il cliente, oppure che non serva più, in quanto dopo alcuni mesi il progetto reale è diventato completamente diverso. E’ bene distinguere due tipi di documenti:

• Documento di progettazione (progetto), i disegni che usa il progettista per capire e spiegare ai suo programmatori che cosa devono fare.
• Documentazione (manuale utente), oggetto in più prodotto per il cliente, per completare il prodotto.

Progettazione architetturale e di dettaglio esecutivo

Dopo la fase di specifica dei requisiti (e il rilascio del documento di specifica), la fase di progettazione viene divisa in due parti sequenziali: ''progettazione architetturale e progettazione di dettaglio''.

• Progettazione architetturale: rappresenta l’organizzazione in grande dei componenti del sistema, evidenziando le interazioni tra i moduli ma senza specificare il particolare metodo di implementazione (le interazioni tra moduli sono semplici frecce che magari nella realtà sarà

una rete intranet, oppure per un database sono indicate solamente le operazioni di input/output, senza specificare il DBMS usato). Il progetto architetturale può essere organzzato in un documento strutturato nella seguente maniera. Si ha lo storico delle revisioni indicante il numero di revisione, l’autore, le modiche apportante e la data. Dopo una parte introduttiva si possono specificare e definire termini, abbreviazioni e sigle che verranno usate all’interno del documento. Nella sezione successiva si dovrebbero indicare i riferimenti ai quali si farà riferimento nel corso del documento. Nella fase successiva verrà definita l’architettura del sistema e successivamente l’architettura del software (struttura statica, dinamica e implementazione). Nella fase terminale si specificheranno in dettaglio i componenti software che realizzeranno il sistema.

• Progettazione di dettaglio, qui si introducono descrizioni particolareggiate dei moduli e del loro interfacciamento in modo da poter assegnare il compito di implementazione ai programmatori, i quali, grazie a questo documento, avranno le idee chiare su cosa devono fare, oltre al tempo che ci devono impiegare, organizzando così anche il lavoro di codifica.

Viste

L’architettura di un prodotto software è descritta da più aspetti (viste) relativamente indipendenti. Le viste possono essere classificate in base alla struttura.

• Architettura di sistema, con questa vista si rappresenta l’hardware che andrà a comporre il sistema. Per hardare si intendono client, server, reti, router e eventuali firewall.
• Architettura software, con questa vista si rappresentano i moduli software e le loro interconnesioni. Si divide in struttura statica nella quale si rappresentnao i moduli e programmi che compongono il sistema e in struttura dinamica nella quale si gestiscono i flussi di dati

tra i moduli software. Solo in questa fase si indicano le risorse che vengono scambiate e in che modo.

• Implementazione nell’hardware per ogni modulo definito nell’architettura sofware si indica in quale dispositivo hardaware verrà calocato. Per esempio il componente che esegue l’elaborazione dati sarà sul server, quello di reportisitica sul client.
• Implementazione nel software: Si aumenta il livello di dettaglio, introducendo su quale piattaforma fisica finiranno i moduli gestori di una o più funzioni. Per ogni modulo definito nell’architettura sofware si indica quale software verrà usato. Per esempio la navigazione dei dati

potrà essere fatta usando JSP/Tomcat, oppure il database di supporto sarà Postgres.

Regole e principi di progettazione

Un buon ingegnere del software per realizzare un prodotto si basa su regole e principi di progettazione. Tra le fondamentali vengono ricordate quelle di:

• Astrazione, il sistema viene suddiviso in livelli differenti di astrazione. Al livello più alto la soluzione è espressa a grandi linee, nel linguaggio del contesto del problema. Ai livelli più bassi si adotta una descrizione più dettagliata. A mano a mano che si procede a livelli differenti di astrazione, si creano astrazioni procedurali e astrazioni relative ai dati. Si sfruttano tecniche di ereditarietà e polimorfismo.
• Modularizzazione, il sistema è diviso in diversi moduli, ognuno con compito specifico. La modularizzazione permette facilmente di suddividere lo sforzo tra i vari programmatori. Ogni modulo può essere testato singolarmente e, quando funzionante in modo corretto, integrato nel sistema. Il tutto implica una definizione a priori dei moduli, delle loro funzioni e delle interfacce per una corretta integrazione. Criterio di modularizzazione di Myers (1974) definisce un modello di stabilità: massimizzare la coesione, minimizzare l’accoppiamento.
• Information hiding, ogni modulo gestisce localmente le informazioni, nascondendole al sistema esterno. Saranno le sue interfacce a permettere un dialogo con il resto dei moduli. Questa tecnica offre il vantaggio di poter cambiare a posteriori l’implementazione, per correggere bug o aumentare l’efficienza, senza dover cambiare l’interfaccia esterna che rimane uguale.
• Interazioni tra moduli
  • Flusso di controllo, tramite frecce è possibile indicare quale modulo usa i dati di un’altro modulo (Esempio: a^b indica che a usa il modulo b)
  • Flusso dei dati, tramite frecce è possibile indicare quale modulo sfrutta quale risorsa (Esempio: a ! b indica che il modulo a legge dalla risorsa b, a $ b il modulo a legge dalla e scrive sulla risorsa b).
• Coesione, per coesione di un componente si intende un modulo che realizza una o più funzioni simili (Esempio: modulo di visualizzazione delle immagini) e quindi, in caso di errore (esempio un’immagine visualizzata male) è possibile identificare velocemente il modulo incriminato dell’errore. Quindi gli elementi nel modulo non devono esserci per pura coincidenza ma in seguito ad uno studio accurato, in modo da includere procedure (e i relativi dati) coerenti ad un unico tema applicativo. Ci sono diversi gradi di coesione:
  • Coincidental, gli elementi di un modulo sono nel modulo per pura coincidenza
  • Logical, esiste un criterio debole di appartenenza (es. Funzioni che trattano calcoli matematici. Molte funzioni legate in modo complesso potenzialmente separabili in moduli diversi)
  • Temporal, il criterio di appartenenza è legato al tempo (es. funzioni di inizializzazione)
  • Communication, gli elementi hanno lo stesso insieme di dati di ingresso e/o uscita (es. gestione di un file)
  • Sequential, l’uscita di un elemento è l’ingresso del successivo
  • Functional, tutti gli elementi sono relativi all’esecuzione di un’unica funzione applicativa
  • Informational, il modulo contiene tutte le procedure ed relativi dati connessi ad uno specifico tema applicativo
• (Dis)accoppiamento, si ha un accoppiamento, un’interazione tra moduli quando sono interconnessi per scambiarsi dati. Bisogna ridurre al minimo il grado di interconnessione tra moduli evitando il caso in cui tutto vede tutto e un modulo può modificare i dati di un altro modulo. In caso di modifiche sarebbe veramente catastrofico doverci rimettere le mani. Il caso migliore è quello in cui un modulo, che deve comunicare con un’altro modulo, gli passa una lista di parametri sulla quale lavorare.

I gradi di accopiamento si dividono in base al come:

• Content, un modulo modifica dati e istruzioni interni ad un altro modulo
• Common, due moduli sono legati da una struttura di dati globale
• Control, un modulo passa flag di controllo ad un altro modulo (altera il flusso di controllo)
• Stamp, come common ma con aree suddivise per gruppi di moduli
• Data, un modulo passa una lista di parametri ad un altro modulo
• Massimo numero di interconnessioni per modulo, Numero medio di interconnessioni per modulo
• Morfologia, in un albero ogni nodo deve essere raggiunto con un cammino minimo.

Euristiche

Sono regole generali utili per evitare di progettare sistemi poco elastici:

• Regola di Murphy, se qualcosa può andare storto ciò accadrà. Si consiglia quindi di realizzare sistemi il più semplice possibili.
• Criterio dei dieci pezzi, creare componenti o oggetti non troppo estesi o complessi perché aumenta il grado di confusione. E’ quindi consigliato di dettagliare per gradi successivi
• Criticità, c’è sempre una parte più critica che richiede maggiore attenzione
• Riutilizzo, sviluppare il meno possibile e riutilizzare il codice il più possibile.

Processi di progettazione (strategie)

Forme, strutture e decorazioni

Il processo di progettazione, in generale, è composto da tre fasi. Nella prima si definisce il progetto concettuale, nella seconda si attua la sintesi del sistema costruibile, nella terza, la fase di analisi, si attuano verifiche di progetto qualitative e costruttive. Come in campo edile, quando si progetta un edificio, anche nella progettazione software si genera una forma (il grattacielo) in grado di risolvere il problema in questione, soddisfando i requisiti funzionali e non funzionali. Una volta definita la forma si crea la struttura, lo scheletro che sostiene la forma (fondamenta, muri portanti,..) ed infine si aggiungono i dettagli.

Ci sono vari modi per attuare la sintesi di un sistema:

• Decomposizione, da un modello a grossi blocchi si ricavano altri blocchi di dimensioni più piccole, seguendo un approccio top-down. Utilizzato nelle situazioni in cui si desidera aumentare la precisione e il livello di dettaglio nella strategia di progettazione del sistema generale, andando ad affrontare la composizione e la realizzazione di eventuali sottosistemi costituenti quest’ultimo. Dai livelli superiori (top) dei grandi blocchi, a quelli elementari di dettaglio (down) dei singoli componenti.
• Composizione, da un modello costituito da tanti blocchi si ricavano blocchi di dimensioni più grandi, seguendo un approccio bottom-up. (Es: reingegnerizzazione di un prodotto basata sull’integrazione di una collezione di componenti già esistenti). Utilizzato quando, al contrario di come succedeva con la strategia precedente, si vuole allargare il dettaglio affrontando una vista d’insieme per verificare il comportamento e il funzionamento globale e l’integrazione dei singoli componenti. Dai livelli inferiori di dettaglio (bottom) a quelli superiori e composti d’insieme (up).
• Aggiunta, viene per prima cosa progettato il cuore del prodotto. Poi, per aggiunte successive, vengono incollate altre funzioni al cuore del programma facendo evolvere il sistema. Utilizzato per proteggere il cuore di sistema, dunque per rafforzare la sicurezza e il controllo dello stesso ed escluderlo dall’attacco esterno o dall’intaccamento dovuto, ad esempio, a funzionalità aggiuntive poco corrette. Ha il vantaggio di poter aggiungere continuamente nuove attività e mansioni i tutta sicurezza e nell’ordine desiderato.

I processi non sono mutuamente esclusivi, dipendono da caratteristiche tecniche, dalla definizione dei requisiti, da altri fattori come tempo e costi. Si dovranno quindi scegliere il processo o i processi più confacenti al processi di progettazione.

Analisi dei requisiti e sintesi del sistema, integrazione con la specifica

Nella realtà il processo di analisi e quello di sintesi sono interconnessi e non è distinguibile concretamente quando si è in una fase o nell’altra. L’idea di analizzare tutto e poi sintetizzare una soluzione è un’idea molto astratta dovuta principalmente a motivazioni tecniche:

• Specifica vincolata da decisioni di progettazione
• I requisiti non funzionali si valutano conoscendo le caratteristiche della progettazione, (le prestazioni di una coda di messaggi si valutano solo sapendo il prodotto software e l’ambiente che si adotta per gestire le code).
• L’implementazione di un requisito può richiedere scelte di progetto che implicano costi non accettabili

Esistono però anche motivazioni gestionali:

• L’analisi generale dei requisiti è fermata ad un definito livello considerato sufficiente per stipulare un contratto
• Il dettaglio non è applicato egualmente a tutti i componenti (criticità dei componenti, tempi di consegna, componenti esistenti)

Tra queste due fasi viene a definirisi una fase di interleaving cioè una convivenza quasi sequenziale tra requisiti e specifica e progetto. In un sistema semplice si passa dai requisiti e specifica al progetto mentre di norma si ripetono ciclicamente questi due passaggi.

Modelli operazionali e trasformazioni

I modelli operazionali definiscono il modo di gestire le relazioni tra la specifica e il progetto. La caratteristica di questi modelli è che possono simulare i comportamenti reali, il comportamento del modello del sistema viene iterativamente verificato e modificato fino a diventare completo e costruibile.

Dall’architettura all’esecutivo di dettaglio

Il documento prodotto dall’analisi architetturale (progetto architetturale) identifica i componenti e li descrive a grandi linee, in particolare si concentra sulla loro connessione. Il documento prodotto dall’analisi di dettaglio (progetto esecutivo di dettaglio) progetta ogni singolo componente e le interfacce di connessione tra loro. Il livello di dettaglio del progetto esecutivo di dettaglio deve essere tale da essere considerato dai programmatori un documento di specifica completo che deve solo essere trasformato in codice. In situazioni diverse possono corrispondere livelli di dettaglio diversi, cioè a seconda delle competenze tecniche dei programmatori, le loro conoscenze del settore applicativo, se si programma in casa o in subappalto.

Tracciabilità

Per tracciabilità si intende creare una serie di documenti che certificano il lavoro svolto da ciascun programmatore, in modo da mantenere un filo diretto tra tutti gli sviluppatori semplicemente dando la possibilità di leggere il rapporto, la traccia, del lavoro svolto fino a quel momento. Inoltre permette di identificare in modo univoco i componenti del sistema e quali requisiti hanno implementato. Una idea potrebbe essere data dalle tabelle di tracciabilità, dove si associa al codice del requisito (che era stato assegnato durante la fase di analisi dei requisiti) un codice componente del progetto in cui è stato implementato.

Linguaggi e metodi di progettazione

Per modellare il progetto si hanno a disposizione diversi linguaggi, ognuno dotato di regole e guide da seguire. In comune hanno la caratteristica di avere una base grafica perchE’ la comunicazione visiva è più chiara e diretta. Ognuna di queste tecniche ha delle caratteristiche fondamentali che la rendono più o meno adatta a seconda dell’aspetto che dobbiamo modellare (un database e un protocollo, essendo concettualmente diversi, avranno bisogno di tecniche diverse). Si vedrà cosa è possibile modellare e con quale tecnica.

Dati

Il nucleo del progetto è il modello dei dati, attorno al quale vengono create il resto delle funzioni. I dati vengono modellati utilizzando gli schemi Entità Relazioni. Le fasi principali sono:

• Progettazione concettuale (lo schema ER)
• Progettazione logica (conversione da ER in forma di tabelle)
• Progettazione fisica (implementazione)

Funzioni

Questa tecnica è utilizzata quando dobbiamo gestire dei processi che producono ingressi ed uscite. Vengono rappresentati con una evoluzione dei diagrammi di flusso, i diagrammi di struttura, e rappresentano in modo semplice e intuitivo come le funzioni dei vari processi si scambiano dati durante il loro funzionamento. Si utilizzano i seguenti schemi grafici:

• Quadrato per rappresentare gli attori del sistema
• Rettangolo con i bordi smussati per processi e funzioni
• Rettangolo per le basi di dati
• Frecce per evidenziare il flusso dei dati

Oggetti

Il progetto è interamente basato sugli oggetti. Sono delle entità che racchiudono al loro interno dati e funzioni di elaborazione dei dati stessi. La tecnica di modellazione utilizzata è il diagramma delle classi, in linguaggio UML. E’ possibile rappresentare la struttura statica del sistema che però risulta di difficile lettura da parte del cliente. Per definirne il comportamento si utilizzano diverse tecniche, alcune delle quali fanno parte della grande famiglia di linguaggi UML:

• Casi d’uso
• Automi a stati finiti
• Diagramma di sequenza

L’implementazione di questi oggetti, oltre a delle specifiche strettamente tecniche, richiede di sapere anche dove questi oggetti finiranno, sapere cioè qual è il componente fisico per cui sono destinati. I vincoli da applicare a questa tecnica sono quelli della programmazione ad oggetti (Object Constrain Language).

Eventi

Questa tecnica prevede di pilotare gli eventi che guidano lo stato del sistema, utilizzando gli automi a stati finiti. Sono composti da:

• Stati, che rappresentano la situazione globale del sistema.
• Transazioni, passi che portano da uno stato ad un’altro.
• Eventi, particolari situazioni da gestire che possono portare a diverse configurazioni di stati.
• Azioni

Concorrenza

Si utilizza questa tecnica quando si devono modellare processi concorrenti e in generale sistemi distribuiti o basati sulla concorrenza. La tecnica di modellazione utilizzata sono le reti di Petri.

Tempo

La modellazione si basa su sistemi real-time. Non si intendono però sistemi che evolvono in tempo reale, ma sistemi caratterizzati da vincoli di tempo (di varia natura e di vari ordini di grandezza) che devono essere rispettati per garantire una sincronizzazione dell’intero sistema. Per vincoli di tempo si intendono tempi di risposta accettabili per sistemi interattivi, risposta a delle transazioni, ecc. Inoltre questi tempi devono essere più o meno grandi a seconda del dominio applicativo in cui si sta lavorando (Esempio: i tempi di risposta di un pilota automatico devono essere molto brevi, per ovvie ragioni di sicurezza). Le tecniche di modellazione utilizzate sono degli adattamenti di tecniche già viste in precedenza:

• Diagrammi di flusso arricchiti con flussi di controllo.
• Automi a stati finiti arricchiti per tener conto della durata delle transazioni.
• Reti di petri temporizzate.

Interazione uomo macchina

Questa parte viene realizzata dalle interfacce. Dovrà quindi essere specificato come ci si muove all’interno di essa, quali sono i passi da seguire per raggiungere una certa funzione, ect.

Integrazione dei linguaggi

Nella realtà i sistemi coprono diversi aspetti, sono dei cosiddetti sistemi eterogenei. Ognuno di essi dovrà essere gestito con la tecnica appropriata. Quindi bisogna saper modellare tutti gli aspetti (in una applicazione web, si può avere a che fare con delle basi di dati e le relative interfacce di presentazione dei dati e di interrogazione).

Architetture e pattern di progettazione

Al crescere della complessità dei sistemi software, il design e la specifica diventano più significativi della scelta di particolari algoritmi e strutture dati.

Architetture

Il progetto architetturale è quella fase in cui si gioca la qualità interna del prodotto. L’ingegneria del software è sempre più orientata verso la creazione di moduli separati. La successiva integrazione darà origine ad un unico progetto. Ecco perchE’ la progettazione architetturale diventa sempre più importante. Il progetto architetturale deve essere in grado di definire un modello della realtà costruibile, che soddisfa una serie di requisiti (analizzati nella fase di analisi dei requisiti e sintetizzati nel documento di specifica). L’architettura svolge un ruolo importante anche nella gestione del lavoro del team. Infatti la scomposizione in moduli di un problema grosso permette di creare una serie di problemi più ridotti che possono essere studiati e stimati (a livello di costo e tempo) in modo più semplice, potendo cos`ı ricostruire la difficoltà generale del prodotto. Si deve tener conto anche dell’aspetto della comunicazione tra il personale coinvolto. Scomponendo il lavoro anche questo aspetto diventa più facile. Infine c’è la fase di analisi, da effettuare prima di fabbricare il progetto perchE’ bisogna avere una certa sicurezza sulla bontà del prodotto. La costruzione di un’architettura garantisce anche la possibilità del riuso perchE’ è possibile identificare progetti diversi che richiedono soluzioni architetturali analoghe. E’ possibile cos`ı riutilizzare la conoscenza acquisita durante il lavoro precedente, riducendo tempi e costi. Inoltre garantisce la sua validità in quanto è già stata provata nel progetto precedente. Il tutto porta a tenere una traccia, un documento che descrive tutto il lavoro svolto. Deve essere leggibile da tutto lo staff che ci lavora e non solo dall’autore dell’architettura. Questo significa creare dei documenti ordinati, con strumenti di modellazione adeguati.

Rappresentazione

Gli elementi di un’architettura non vengono rappresentati con un’unica tecnica. Si utilizzano scatole per rappresentare i componenti e righe per evidenziare le connessioni tra i componenti. Utilizzando questi elementi base possiamo rappresentare la:

• Struttura statica
• Struttura dinamica
• L’implementazione fisica delle varie macchine del sistema.
• Struttura del codice.

Quindi l’architettura risulta essere formata da una vista logica, una vista dei processi, del codice di implementazione, una vista dei componenti fisici del sistema e di uno scenario che racchiude il tutto.

Documentazione

Per documentare un’architettura è utile:

• Avere uno schema architetturale preesistente, in cui si seguono i passi impostati
• Utilizzare più viste con altrettanti modelli per i vari aspetti.
• Utilizzare gli strumenti linguistici studiati.

Pattern architetturali

Uno stile architetturale definisce una famiglia di sistemi software che hanno in comune uno schema ricorrente che si ripete. Conoscere gli stili permette il riuso dell’architettura in uno specifico progetto. Significa che affrontando un problema e analizzandolo si può riconoscere la forma ricorrente alla base. Si può quindi riutilizzare gli schemi senza doverli reinventare. Due progetti possono avere funzioni diverse e domini applicativi differenti, ma avere la stessa forma e stile, cioè lo stesso pattern architetturale. In elenco sono descritti alcuni pattern architetturali.

Layers

Si ha una serie di componenti, o layer (disegnati con delle scatole) connessi tra loro (da delle frecce), realizzando una forma tipo pila. La semantica di questa struttura prevede che al layer superiore è permesso di usare il layer inferiore, ma non viceversa. Questa logica permette di semplificare la struttura evitando cos`ı di generare studi intricati e difficilmente gestibili. Quindi la correttezza del layer sovrastante dipende dalla correttezza del layer sottostante, applicando questo concetto all’intera pila. Ogni layer è una collezione di unità software, cioè delle procedure, oggetti, strutture dati, ecc. I servizi del layer sono accessibili esclusivamente attraverso delle interfacce (Esempio: protocollo tcp/ip, che si rifà all’architettura standard ISO-OSI). Ogni layer fornisce una serie di servizi coerenti tra loro. Dall’esterno appaiono come macchine che offrono servizi utilizzabili da una macchina più complessa, il layer sovrastante.

I vantaggi offerti da questa struttura sono:

• Migliore modificabilità e portabilità
• Ci possono essere, senza conseguenze, cambiamenti locali per ogni layer, senza modificare le interfacce di connessione
• Costruzione incrementale, cioè inserire nuovi strati sovrastanti a seconda delle esigenze (come l’aggiunta del protocollo HTTP)
• La definizione di layer riduce la complessità del lavoro. Diventa più facile da gestire tra un gruppo di sviluppatori.

Le possibili varianti sono:

• Segmented Layer
• Bridge

Pipes and filter

I componenti di questa struttura (scatole) vengono chiamati filtri. Leggono un flusso di dati in ingresso e producono un flusso di dati in uscita. Questa trasformazione è indipendente dal lavoro che altri filtri stanno svolgendo, sia a monte sia a valle. Il flusso dei dati in uscita inizia quindi quando il flusso dei dati in ingresso non è ancora stato consumato del tutto. Le connessioni tra i vari filtri servono per condurre i dati da un filtro all’altro. Ogni filtro è un’entità indipendente che non condivide lo stato con altri filtri.

Vantaggi derivanti dall’utilizzo di pipes and filter:

• Il comportamento globale è dato dal comportamento locale dei singoli filtri.
• Garantisce facilità di manutenzione in quanto i filtri possono essere modificati, aggiunti o cancellati senza sconvolgere la struttura del sistema.

Svantaggi derivanti dall’utilizzo di pipes and filter

I filtri non sono adatti a gestire applicazioni interattive, rappresentano solo un flusso di informazioni. Le possibili varianti sono:

• Pipeline: lavora di continuo, l’importante è garantire un flusso di dati sufficiente. I filtri possono lavorare in parallelo preoccupandosi solamente di trasformare gli ingressi in uscite.
• Batch sequenziale: ogni filtro può iniziare a lavorare solamente quando il filtro precedente ha concluso la generazione del suo output.

Repository

In questa struttura si ha una serie di componenti satellite (scatole) indipendenti tra loro, attivati dall’esterno (un utente) che operano su una struttura dati centrale (un database). Le connessioni tra la risorsa di dati centrale e i componenti satellite sono un flusso di dati bidirezionale. La fonte principale della struttura di controllo è data dal componente centrale. Lo stato della struttura centrale è la fonte principale del controllo. Il cambio di stato attiva gli altri componenti

Stili di controllo

Rappresentano gli schemi di gestione del flusso di controllo tra componenti (le scatole).

• A controllo centralizzato:
  • Call Return
  • Manager
• A controllo basato su eventi:
  • Selective Broadcast
  • Interrupt Driver

Generalmente un progetto si compone e può usare più di uno stile. Esistono altri stili classificabili per tipologia applicativa (acquisizione in frequenza, eventi sismici, ect.).

Call Return

E’ molto simile alle chiamate di procedure remote. Viene effettuata una chiamata da un componente ad un altro, il quale, dopo aver elaborato una risposta, risponde al componente che ha effettuato la chiamata. Esempi di questo stile sono l’architettura client-server, con il caso two e three tier. Si sceglie questo stile quando:

• Si devono integrare prodotti software in cui si possono solo aggiungere delle interfacce
• Si ha bisogno di elaborazioni (es grafiche) molto legate all’interfaccia
• Si devono integrare prodotti diversi in un’unica interfaccia comune

Manager

E’ simile al caso precedente. In più si ha un componente (manager) che coordina tutti i processi e le chiamate tra processi. Per esempio si potrebbe avere delle risorse condivise tra più processi che accedono ad un unico software gestore dell’allocazione risorse. Un processo andrà in wait per accedere a una risorsa se quest’ultima non è subito disponibile.

Selective Broadcast

Si hanno uno o più sottosistemi che registrano l’interesse per uno o più eventi presso un gestore (in comune con tutti i sottosistemi). Ogni sottosistema può annunciare la disponibilità di un evento. Quando l’evento accade il gestore invoca direttamente i sottosistemi interessati. Quindi non è direttamente il gestore a controllare i sottosistemi, ma sono loro stessi a richiedere un evento. Inoltre i sottosistemi non sanno quando un evento si verificherà.

Interrupt Driven

Ogni interrupt è associato a un indirizzo e ad un handler, una commutazione hardware attiva l’handler, usato nei sistemi real-time.

Architetture di sistemi distribuiti

Le applicazioni sono costruite da più processi concorrenti che vengono eseguiti su elaboratori diversi ed autonomi connessi da una rete. Generalmente ogni nuovo sistema moderno è distribuito.

Architetture distribuite

• Architetture client/server.
• Architetture di oggetti distribuiti, non c’è distinzione tra client e server.

Ogni oggetto distribuito collabora con altri oggetti, fornendo e richiedendo servizi.

Vantaggi delle architetture distribuite:

• Condivisione delle risorse (distribuire dati con sistemi raid di harddisk).
• Concorrenza, esecuzione parallela e indipendente di più processi.
• Scalabilità, possibilità di espandere il sistema con il crescere dell’attività.
• Tolleranza ai guasti e quindi una maggiore affidabilità.
• Trasparenza delle applicazioni, esecuzione operazioni senza preoccuparsi, per esempio, su quale server si trovano i dati.

Svantaggi delle architetture distribuite.:

• Complessità nella realizzazione.
• Maneggiabilità limitata.
• Sicurezza, controllo degli accessi e privacy (intesa come security) difficile da gestire.

Middleware

Nelle architetture dei sistemi distribuiti si utilizza uno strato di software particolare, il middleware. E’ uno strato di software posto tra il sistema operativo e le applicazioni. Fornisce un’infrastruttura di servizi che facilitano lo sviluppo di applicazioni in un sistema distribuito, come la RPC. E’ basato su prodotti standard di mercato. I servizi di comunicazione di base si basano sui socket. Middleware tradizionali sono RPC, RDA, MOM, OSF; mentre quelli ad oggetti sono CORBA, RMI, DCOM.

Architettura client-server

Le elaborazioni e i dati sono distribuiti su un insieme di componenti. Un insieme di componenti server fornisce servizi (gestione dei dati, stampa, processi di elaborazione), mentre un altro insieme chiede servizi ai componenti server. La rete è utilizzata per connetterli tra loro. I client conoscono i server, mentre non è richiesto che i server conoscano i client. Server e client sono processi logici che possono essere mappati su processori fisici diversi. L’architettura è divisa in tre strati:

• Presentazione, che si occupa delle interazioni uomo macchina
• Logica dell’applicazione, che svolge specifiche funzionalità applicative
• Gestione dei dati, per dialogare con le banche dati

A seconda di dove questi strati vengono fisicamente implementati si possono avere due tipi di architettura client/server: two tier (con thin o fat client, a seconda che la logica dell’applicazione sia implementata sul server o direttamente nel client) e three tier (dove i tre strati sono su computer diversi).

Architetture ad oggetti distribuiti

Non c’è distinzione tra clienti e serventi, ogni oggetto distribuito sulla rete fornisce-richiede servizi a-da altri oggetti distribuiti.La comunicazione tra oggetti avviene attraverso uno strato di middelware chiamato Object Request Broker (bus software). Questo bus software gestisce le richieste di servizi. Conosce tutti gli oggetti esistenti e le loro interfacce. Utilizzando un ORB l’oggetto chiamante esegue il binding con lo stub IDL (che definisce l’interfaccia) dell’oggetto chiamato. La chiamata allo stub diventa una chiamata all’ORB, il quale chiama l’oggetto richiesto attraverso un IDL skeleton che lega l’interfaccia all’implementazione. Un ORB gestisce le comunicazioni tra oggetti che eseguono sullo stesso elaboratore. Ogni elaboratore di un sistema distribuito ha un ORB e gli ORB comunicano tra loro per gestire gli oggetti distribuiti. CORBA (Common Object Request Broker Architecture) definito dallo standard internazionale (OMG - Object Management Group), tramite il linguaggio definisce un’intefaccia comune per ogni oggetto. IDL può essere mappato con diversi linguaggi (C++, Java).

Pattern di componenti

I pattern sono utilizzati per la progettazione di componenti di un’architettura. Descrivono un problema ricorrente in un dato dominio, e la sua soluzione, in modo tale che possa essere riutilizzata, anche se in modo diverso in contesti diversi. Un design pattern è una regola tripartita, che esprime una relazione tra un contesto, un problema ed una soluzione.

Sviluppo di famiglie di componenti

Sviluppare una famiglia di prodotti porta a realizzare una struttura base da cui derivare più prodotti specializzati. Nel progetto di famiglie di prodotti si ha la convergenza di diversi aspetti, tra cui le esigenze specifiche del cliente, gli aspetti comuni delle classi di applicazione e vantaggi gestionali (come la riduzione del costo) in quanto il prodotto è utilizzabile da più clienti.

Sviluppo di framework

Il framework è una struttura software sulla quale vengono innestati componenti aggiuntivi o adattamenti, che permettono di realizzare una specifica applicazione appartenente ad una famiglia di applicazioni. Incorpora un insieme di conoscenze di base del dominio applicativo di interesse.

Sviluppo attraverso integrazione di componenti

Lo sviluppo attraverso integrazione di componenti comporta lo spostamento dell’enfasi dalla programmazione di un sistema software alla realizzazione di un sistema software attraverso l’integrazione di diversi componenti esistenti. Un componente è un’unità software caratterizzata da:

• esistenza in modo indipendente
• acquistato e integrato da entità diverse dal produttore
• interfaccia definita ed un definito contesto di utilizzo
• avere un contesto di cui interessarsi ed inserirsi
• rende disponibile un insieme complesso di funzioni applicative di base
• viene integrato in un processo.

Le tecniche di integrazione utilizzate sono il bridge e il wrapping.

Bridge

Meccanismo di comunicazione per interfacciare una specifica funzionalità del componente da integrare.

Wrapping

Un oggetto software incapsula il componente da integrare rendendone disponibili i servizi come se appartenessero al nuovo sistema nativamente. L’integrazione può essere fatta ad hoc integrando interi sottosistemi ed applicazioni, anche eterogenei come database, programmi applicativi o L’integrazione se avviene tramite un middleware esistente è detta a grana fine in quanto si ha una sola invocazione di metodi e oggetti.

Verifica di progetto

Compito della verifica del progetto è quello di controllare che il progetto rispecchi il documento di specifica e che le specifiche funzionali e non funzionali siano conformi al modello di qualità ISO 9126. Per poter portare a termine la fase di verifica occorre possedere il documento dei requisiti (la specifica) e il documento di progetto (il progetto). Il modello di qualità ISO 9126 permette di effettuare delle analisi della specifica e delle verifiche sul progetto. Per ogni classe di requisiti si devono controllare criteri relativi a:

• Funzionalità
• Affidabilità
• Usabilità
• Efficienza
• Manutenibilità
• Portabilità

Quindi nella specifica devono essere presenti questi aspetti che verranno verificati sulla pelle del progetto. Le verifiche possono essere fatte da una persona estranea al progetto.

Livelli di verifica

Le verifiche possono essere utilmente strutturate per livelli. . .

• Livelli del costo di verifica
  • Valutazioni delle prestazioni attraverso l’esame di progetti analoghi e documentazione dei prodotti utilizzati. Si effettua una verifica qualitativa, una stima, capendo l’ordine di grandezza del

problema.

• Sviluppo di un prototipo e prove di prestazioni. Si ha una verifica quantitativa precisa.

• Livelli di propedeuticità
  • Presenza degli argomenti di interesse nel documento di progetto, verifica della qualità di stesura del documento di progetto.
  • Analisi ulteriori.

Scenari

Possono essere utilizzati dai requisiti o costruiti specifici scenari per verificare le caratteristiche del progetto:

• Manutenibilità, scenari di possibile richieste di modifica.
• Privatezza, scenari di possibili attacchi di hacker o usi non autorizzati.
• Affidabilità, scenari di guasto.

Tipi di verifiche

La verifica di un prodotto non è effettuabile direttamente sul codice in quanto non esiste ancora. Si utilizzano diversi tipi di verifiche tra cui:

• Ispezione
• Analisi
• Animazione e simulazione

Ispezioni

Si effettuano delle ispezioni sul documento di progetto. Si controlla l’aspetto organizzativo, la presenza dell’indice, la leggibilità del tutto. Si controlla inoltre che tutti i requisiti funzionali siano allocati e soddisfatti.

Analisi

Si devono effettuare dei ragionamenti sul progetto:

• Comprendere il requisito
• Esaminare il progetto
• Studiare le caratteristiche del progetto rispetto al requisito e verificarne il comportamento basandosi sul modello
• Definire gli scenari appropriati e valutare il comportamento del progetto
• Esaminare i casi limite
• Valutare le alternative di progettazione
• Verifiche di proprietà del progetto

Animazione e simulazione

Si effettuano delle simulazioni del funzionamento del prodotto creando dei prototipi. Es. si analizza il funzionamento del sistema usando le reti di Petri.