Ingegneria del software

ESEMPI:

Criterio progettuale Definizione

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?

Leggibilità Quanto è facile comprendere il sistema leggendo il codice sorgente?

Tracciabilità dei requisiti Quanto è facile ricondurre le parti di codice agli specifici requisiti che le hanno motivate?

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

Intesa come compatibilità di ritorno, si ha quando un nuovo sistema sostituisce uno vecchio e bisogna tenere in conto i costi per effettuare la transizione

e per garantire, per l’appunto, la compatibilità di ritorno. Ha una particolare importanza durante l’analisi dei criteri di costo di upgrade.

5. Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione i costi associati al sistema. Fornisci degli

esempi delle tipologie di costo tipicamente coinvolte.

Criterio progettuale Definizione

Costi di sviluppo Lo sviluppo ex-novo del sistema

L’installazione l’addestramento

Costi di deployment e configurazione del sistema, e degli utenti

Costi di upgrade Il trasferimento dei dati dal vecchio sistema, risultanti dai requisiti di compatibilità backward.

Costi di manutenzione Correzione di errori e miglioramenti del sistema Costi amministrativi Amministrazione del sistema

6. Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione la dependability(affidabilità) del sistema.

Fornisci degli esempi delle caratteristiche del sistema tipicamente coinvolte.

Criterio Definizione

Robustezza Capacità di sopravvivere a input non validi o condizioni ambientali avverse

Reliability Differenze tra comportamento specificato ed osservato

Availability (disponibilità) Percentuale di tempo in cui il sistema funziona correttamente

Tolleranza ai guasti Capacità di operare in condizioni di errore

Sicurezza Capacità di sopportare attacchi di hacker

Safety Non causare pericoli per gli utenti, anche in caso di errori o guasti

7. In fase di identificazione degli obiettivi del design possiamo fare riferimento a cinque gruppi di criteri progettuali. Citane almeno quattro.

– Prestazioni

– Dependability (affidabilità)

– Costo

– Manutenzione

– dell’utente

Criteri finale

8. Un gruppo di criteri progettuali su cui si basa l'identificazione degli obiettivi del design prende in considerazione le prestazioni del sistema. Fornisci degli

esempi delle caratteristiche del sistema tipicamente coinvolte.

Criterio progettuale Definizione dell’utente?

Tempo di risposta Quanto rapidamente il sistema risponde ad una richiesta

Throughput (capacità di elaborazione) Quanti task possono essere eseguiti dal sistema in un dato lasso di tempo?

Memoria Quanto spazio è richiesto dal sistema per funzionare?

Lezione 021

1. Un design pattern specifico si dimostra spesso utile nella decomposizione in sotto-sistemi. Quale?

Factory

Singleton

Observer

Façade

2. Una delle seguenti indicazioni non rappresenta un'euristica valida per raggruppare gli oggetti in sotto-sistemi. Quale?

d’uso

Tutti gli oggetti identificati in uno specifico caso sono assegnati allo stesso sotto-sistema .

E' utile raggruppare gli oggetti in modo che sia massimo il numero di associazioni che attraversano i confini dei sotto-sistemi.

E' utile creare un sotto-sistema dedicato per gli oggetti usati per trasferire dati tra i sotto-sistemi .

Tutti gli oggetti di un sotto-sistema dovrebbero essere correlati sul piano funzionale.

3. Da che cosa viene derivata, di norma, la versione iniziale della decomposizione in sotto-sistemi?

Dai requisiti non-funzionali.

Dai diagrammi degli stati UML.

Dai diagrammi di sequenza UML.

Dai requisiti funzionali.

4. Relativamente all'attività di identificazione dei sotto-sistemi durante il system design, una delle affermazioni che seguono non è corretta. Quale?

Durante l'identificazione dei sotto-sistemi è consentito decomporre un sotto-sistema complesso nelle sue parti più semplici, ma non è ammesso fondere due o più sotto-

sistemi in uno unico.

L'identificazione dei sotto-sistemi è soggetta ad iterazioni che, all'inizio, possono richiedere cambiamenti drastici al modello del design.

un’attività l’identificazione

Determinare i sotto-sistemi durante il system design è simile a quella di determinare gli oggetti durante la fase di analisi: alcune euristiche per

degli oggetti sono riproponibili per i sotto-sistemi.

L'identificazione dei sotto-sistemi è soggetta a revisione ogni volta che nuove problematiche progettuali emergono.

5. Abbiamo classificato gli obiettivi del design in 5 categorie: prestazioni, dependability, costo, manutenzione e utente finale. Assegna una o più 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.

6. Fornisci una definizione di design pattern.

Un design pattern è una soluzione progettuale generale a un problema ricorrente. Esso non è una funzione di libreria o di un componente software, bensì, una descrizione

o un modello da applicare per risolvere un problema che potrebbe presentarsi in diverse situazioni durante la progettazione e lo sviluppo del software.

7. Quali elementi fanno parte della struttura di un design pattern?

Le componenti principali di un design pattern:

il nome: poche parole rappresentative del pattern stesso. Il nome ci permette di accennare al problema progettuale e alla soluzione generale che il

pattern cattura. Il nome del pattern arricchisce il nostro vocabolario progettuale, e ci consente di lavorare ad un livello si astrazione superiore: possiamo

ad es. parlarne coi colleghi per discuterne vantaggi e limiti in un determinato contesto; identificare nomi adeguati è un'operazione critica.

il problema: la descrizione delle situazioni in cui il pattern è applicabile: può comprendere la descrizione di classi o di problemi di progettazione specifici,

o anche una lista di condizioni che rendono utile o necessario l'uso del pattern

la soluzione: gli elementi software che risolvono il problema, con le loro relazioni, responsabilità e collaborazioni, descritti in modo astratto rispetto ai

dettagli specifici dell'implementazione. La soluzione non descrive una specifica implementazione concreta del pattern, che è considerato un template

applicabile in molte differenti situazioni, e offre una descrizione astratta e largamente condivisa della soluzione di un problema progettuale frequente.

le conseguenze: i risultati e i limiti che conseguono all'applicazione del pattern e che determinano la scelta se adottarlo o meno: le conseguenze

comprendono considerazioni di tempo e di spazio, e descrivono le relazioni del pattern con i linguaggi di programmazione che possono essere usati per

implementarlo.

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

Offrire una singola interfaccia semplificata per accedere a tutti i servizi offerti dal sotto-sistema. Il pattern Façade può essere usato per rendere una

libreria software più facile da usare e comprendere, perché predispone metodi semplici per compiti frequenti.

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

Il pattern Façade viene usato per rendere una libreria software più facile da usare e comprendere, perché predispone metodi semplici per compiti frequenti.

Riduce le dipendenze tra i sotto-sistemi esterni (client) e gli oggetti interni al sotto-sistema che offre i servizi (server) di conseguenza migliora il livello di

flessibilità nello sviluppo del sistema. Lo svantaggio è che c’è meno controllo su ciò che accade «dietro» l’interfaccia nel momento in cui si dovesse

modificare l’implementazione dei metodi

10. Quale problema di progettazione viene affrontato con l'uso del design pattern Observer?

Lo scopo di Observer è definire una dipendenza uno a molti tra oggetti, in cui quando un oggetto cambia stato tutti gli oggetti che dipendono da lui sono

automaticamente aggiornati.

11. Descrivi la soluzione proposta dal design pattern Observer.

Quando i valori numerici di un subject cambiano, vogliamo che tutti gli oggetti observer vengano aggiornati con nuovi valori. La soluzione proposta dal

design pattern è quella di permettere l’iscrizione ai vari observer al subject da cui vogliono ricevere le notifiche del suo cambiamento di stato. Una

volta effettuata l’iscrizione ad ogni aggiornamento effettuato sul subject, tutti gli observer iscritti riceveranno una notifica di aggiornamento dei valori,

provvedendo successivamente ad aggiornare il proprio stato interno relative al subject.

12. Descrivi le conseguenze (positive ed, eventualmente, negative) che possono derivare dall'adozione del design pattern Observer.

Il pattern promuove la separazione tra la rappresentazione astratta di un dato e le modalità con cui viene presentato visivamente: un subject non

conosce i dettagli dei suoi observers. Lo svantaggio è che ripetuti aggiornamenti successivi del dato possono essere costosi sul piano computazionale.

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

La decomposizione in sotti sistemi riduce la complessità del dominio nelle soluzioni minimizzando il coupling tra i sotto sistemi. Il design pattern facade consente di ridurre le

un’interfaccia

dipendenza tra classi incapsulando un sotto sistema che espone semplice ed unificata. Facade espone soli i servizi pubblici offerti dal sotto sistema e incapsula tutti

gli altri dettagli riducendo il coupling con gli altri sotto sistemi.

14. Abbiamo classificato gli obiettivi del design in 5 categorie: prestazioni, dependability, costo, manutenzione e utente finale. Assegna una o più categorie al

seguente obiettivo:

Il distributore di biglietti deve essere in grado di emettere un biglietto anche nel caso di caduta della connessione di rete.

I criteri di dependability, tolleranza ai guasti nel caso in esame, determinano quanto sforzo deve essere speso per minimizzare i blocchi del sistema e le relative conseguenze. Il sistema

deve essere in grado, quindi, di operare anche in presenza di un guasto.

15. Abbiamo classificato gli obiettivi del d