Risposte aperte paniere di Ingegneria del software

Lo stile architetturale Pipe & Filter

Nello stile architetturale pipe & filter ogni sotto-sistema elabora i dati da uno o più input e manda i risultati in output ad altri sotto-sistemi, in una sorta di catena (pipeline). Il principale vantaggio di tale architettura sta nel fatto che essa risulta facilmente modificabile: i filtri possono essere facilmente sostituiti o configurati per perseguire scopi diversi. Lo stile pipe & filter è adatto a sistemi che applicano trasformazioni a flussi (streams) di dati senza intervento dell'utente.

Un esempio in cui tale stile è ampiamente adottato è il sistema di elaborazione dei dati in un server di posta elettronica. In questo caso, i filtri vengono utilizzati per gestire le regole di filtraggio delle email, ad esempio per instradare le email in specifiche cartelle o per bloccare lo spam.

Riconfigurati per perseguire scopi diversi. I sotto-sistemi prendono il nome di «filtri», e le associazioni tra ogni sotto-sistema e il successivo sono chiamate «pipes». L’esempio l’output supiù noto di architettura pipe & filter è la Unix shell: la maggior parte dei filtri sono scritti in modo tale che essi leggano il loro input e scrivono pipesstandard. l’utenteIn questo modo può combinare in vario modo i comandi in molti modi diversi.

5. Descrivi lo stile architetturale Four-tier. Fornisci un esempio.un’architettura “presentation client”Lo stile architetturale four-tier è three-tier in cui il livello di interfaccia è stato decomposto in due sotto-livelli, il ed il“presentation server”. macchina dell’utente,Il primo è collocato nella mentre il secondo può essere eseguito su uno o più server. Un esempio del suo utilizzo può essere una stessa

Applicazione bancaria che può avere diverse interfacce: web, bancomat o un client per gli operatori.

Qual è il vantaggio insito nell'adozione di uno stile architetturale Three-tier?

Il vantaggio dello stile architetturale Three-tier è che il livello di storage può essere condiviso da diverse applicazioni che lavorano sugli stessi dati. Analogamente, la separazione tra il livello di interfaccia e il livello della logica applicativa permette lo sviluppo e la modifica di interfacce utente diverse per la stessa applicazione.

Fornisci una definizione del concetto di operazione callback. Quale stile architetturale, tra quelli presentati nel corso, fa tipicamente uso di operazioni callback?

Un callback è temporanea e fatta su misura per un determinato scopo. Nei sistemi peer-to-peer un DBUser può specificare al database quale operazione eseguire in occasione della notifica di un cambiamento dei dati.

dati.L'operazione l'operazione è definita nel DBUser, non nel database: il database esegue (potenzialmente diversa per ogni differente DBUser) come forma dinotifica.Sistemi peer-to-peer in cui un sotto-sistema interagisce con altri sotto-sistemi solo attraverso funzioni di callback vengono impropriamente definiti client/server.

Lezione 0201.Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione la manutenzione del sistema. Fornisci degli esempi delle caratteristiche del sistema tipicamente coinvolte.

I criteri di manutenzione determinano quanto sia difficile modificare il sistema dopo la sua installazione. I più significativi criteri di manutenzione sono:

• Estensibilità, quanto è facile aggiungere funzionalità o nuove classi al sistema;
• Modificabilità, quanto è facile cambiare le funzionalità del sistema;
• Adattabilità, quanto è facile

adattare il sistema a un diverso dominio applicativo; - Portabilità, quanto è facile portare il sistema su una diversa piattaforma.

1. Adattare il sistema a un diverso dominio applicativo;
2. Portabilità, quanto è facile portare il sistema su una diversa piattaforma.

2. Che cos'è la backward compatibility? In quali contesti assume particolare importanza?

Quando un nuovo sistema sostituisce uno vecchio, bisogna tenere in conto i costi per effettuare la transizione e per garantire la compatibilità di ritorno (backward compatibility). Tale tipologia di costo entro in gioco in caso di upgrade del Sistema dove mantenere la compatibilità con un sistema precedente può aumentare i costi di sviluppo, ma ridurre quelli di transizione.

3. Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione i criteri dell'utente finale. Fornisci degli esempi delle caratteristiche del sistema tipicamente coinvolte.

I criteri finale indicano qualità che sono desiderabili dal punto di vista dell'utente.

non sono state ancora considerate dai criteri prestazione e di affidabilità. L'utente spesso questi criteri non sono considerati con la dovuta attenzione, specialmente quando il committente non coincide con finale. Alcuni esempi possono essere: dell'utente; - Utilità, la misura in cui il sistema supporta il lavoro nell'uso dell'utente. Usabilità, facilità del sistema da parte-4. In fase di identificazione degli obiettivi del design possiamo fare riferimento a cinque gruppi di criteri progettuali. Citane almeno quattro. Sull'occupazione- Prestazioni, includono i requisiti sui tempi di risposta e di memoria imposti sul sistema; - Affidabilità, determinano quanto sforzo deve essere speso per minimizzare gli arresti del sistema e le relative conseguenze; - Costo, includono gli oneri finanziari di sviluppo ed amministrazione del sistema, sia per quanto riguarda la progettazione che la gestione; - Manutenzione, determinano quanto sia

difficile modificare il sistema dopo la sua installazione;dell'utente dell'utente.- Criteri finale, indicano qualità che sono desiderabili dal punto di vista5.Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione le prestazioni del sistema. Forniscidegli esempi delle caratteristiche del sistema tipicamente coinvolte. sull'occupazioneI criteri legati alle prestazioni, includono i requisiti sui tempi di risposta e di memoria imposti sul sistema. Alcuni esempi di tali criteripossono essere: dell'utente;- Tempo di risposta, quanto rapidamente il Sistema risponde ad una richiesta- Capacità di elaborazione, quanti task possono essere eseguiti dal sistema in un dato lasso di tempo;- Memoria, quanto spazio è richiesto dal Sistema per funzionare.6.Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione la

La dependability (affidabilità) del sistema è una caratteristica che determina quanto il sistema sia in grado di svolgere le sue funzioni in modo corretto e senza interruzioni. Alcuni esempi delle caratteristiche del sistema tipicamente coinvolte sono:

• Robustezza: la capacità di sopravvivere a input non validi o condizioni ambientali avverse.
• Tolleranza ai guasti: la capacità di operare in condizioni di errore.
• Sicurezza: la capacità di sopportare attacchi di hacker.
• Safety: la capacità di non causare pericoli per gli utenti, anche in caso di errori o guasti.

Un gruppo di criteri progettuali che influenzano l'identificazione degli obiettivi del design è rappresentato dai costi associati al sistema. Alcuni esempi delle tipologie di costo tipicamente coinvolte sono:

• Oneri finanziari di sviluppo del sistema.
• Oneri finanziari di amministrazione del sistema.
• Oneri finanziari di progettazione del sistema.
• Oneri finanziari di gestione del sistema.

Alcuni esempi di tali criteri possono essere: - Costi di sviluppo, in caso di sviluppo ex-novo del Sistema; d'installazione, l'installazione all'addestramento - Costi e la configurazione del sistema, fino degli utenti; - Costi di upgrade, il trasferimento dei dati dal vecchio Sistema al nuovo; - Costi di manutenzione, correzione di errori e miglioramenti del Sistema. Lezione 0211. Abbiamo classificato gli obiettivi del design in 5 categorie: prestazioni, dependability, costo, manutenzione e utente finale. Assegna una opiù categorie al seguente obiettive: l'utente Dopo aver digitato un comando, deve ricevere una risposta entro un secondo. all'utente - Prestazione, perché è richiesto un tempo di risposta ben definito, ossia il tempo entro cui il Sistema deve rispondere non deve essere maggiore di un secondo. 2. Fornisci una definizione di design pattern. Un design pattern è "una soluzione progettuale generale a un problema ricorrente".

Esso non è (ancora) una funzione di libreria o un componente di software riutilizzabile, ma piuttosto una descrizione o un modello da applicare per risolvere un problema che può presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software.

Quali elementi fanno parte della struttura di un design pattern?

Gli elementi che fanno parte della struttura di un design pattern sono:

• Nome: il nome del pattern stesso, il quale ci permette di accennare al problema progettuale e alla soluzione generale che il pattern cattura;
• Problema: la descrizione delle situazioni in cui il pattern è applicabile, può comprendere la descrizione di classi o di problemi di progettazione specifici;
• Soluzione: gli elementi software che risolvono il problema, descritti in modo astratto rispetto ai dettagli specifici dell'implementazione;
• Conseguenza: i risultati ed i limiti che conseguono all'applicazione del pattern e che determinano la scelta se adottarlo.

1. Quale problema di progettazione viene affrontato con l'uso del design pattern Façade?

La decomposizione in sotto-sistemi riduce la complessità del dominio delle soluzioni minimizzando il coupling tra i sotto-sistemi. Il design pattern Façade, mediante un'interfaccia, permette di ridurre ulteriormente le dipendenze tra classi incapsulando un sotto-sistema che espone un'interfaccia semplice ed unificata. Façade espone solo i servizi pubblici offerti dal sotto-sistema e nasconde (incapsula) tutti gli altri dettagli, riducendo il coupling con gli altri sotto-sistemi.

2. Descrivi la soluzione proposta dal design pattern Façade.

La soluzione al problema della decomposizione di un Sistema proposta da Façade sta in una singola interfaccia semplificata, per accedere a tutti i servizi offerti dal sotto-sistema.

3. Descrivi le conseguenze (positive ed eventualmente negative) che possono derivare dall'adozione del design pattern Façade.

Le conseguenze positive derivanti dall'adozione del design pattern Façade sono la riduzione della complessità del sistema, la semplificazione delle dipendenze tra classi e la facilità di manutenzione. Tuttavia, una conseguenza negativa potrebbe essere l'aumento della complessità dell'interfaccia Façade stessa, se il sotto-sistema offre molti servizi diversi.

Le conseguenze del design pattern Fecade sono che i clienti vengono isolati dai componenti del sotto-sistema, riducendo gli oggetti con cui il cliente si interfaccia. Questo migliora il disaccoppiamento.