Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
Scarica il documento per vederlo tutto.
vuoi
o PayPal
tutte le volte che vuoi
ASTRAZIONE
Assicurarsi che il progetto permetta di nascondere o ritardare gli aspetti di dettaglio, riducendo la complessità. Varie forme di astrazione (procedurale, sui dati, sul controllo). Una buona astrazione realizza information hiding (occultamento dei dettagli realizzativi). L'astrazione permette di comprendere l'essenza di un sottosistema senza richiedere la conoscenza di dettagli insignificanti.
Astrazione e Classi. Le classi sono astrazioni sui dati che contengono a loro volta astrazioni procedurali. Si può aumentare l'astrazione definendo tutte le variabili come private. Meno metodi pubblici ha una classe, migliore è l'astrazione. Superclassi ed interfacce aumentano il livello di astrazione. Attributi e associazioni sono ulteriori astrazioni sui dati. I metodi sono astrazioni procedurali. Le migliori
www.quellidiinformatica.org - La community studenti di Ingegneria Informatica di Napoli
INGEGNERIA DEL SOFTWARE FranK 6
astrazioni si ottengono dando ai metodi pochi parametri.
PRINCIPIO DI PROGETTO N.ro 5: AUMENTARE LA RIUSABILITÀ
Progettare i vari aspetti del sistema in modo che possano essere riusati anche in altri contesti.
- Generalizzare il progetto il più possibile
- Seguire I tre precedenti principi di progettazione
- Semplificare il progetto il più possibile: è più semplice riusare un componente piccolo e semplice
PRINCIPIO DI PROGETTO N.ro 6: RIUSARE ALTRI PROGETTI E CODICE
Progettare facendo riuso è complementare al progettare per la riusabilità. Riusare il progetto ed il codice altrui permette di avvalersi di altri investimenti fatti per ottenere componenti riusabili. Componenti riusabili: librerie di funzioni, di classi, frameworks, design patterns … Clonare il codice (ossia copiarlo e riportarlo in più punti) non è una forma di riuso da attuare
PRINCIPIO DI PROGETTO N.ro 7: PROGETTARE PER LA FLESSIBILITÀ
Anticipare
Concretamente le modifiche cui un progetto potrà essere sottoposto in futuro e prepararsi per gestirle:
- Ridurre l'accoppiamento ed aumentare la coesione
- Creare astrazioni
- Non prestabilire limitazioni (es. costanti) nel codice
- Lasciarsi aperte varie alternative
- Meglio associare ad ogni evento la chiamata ad un metodo che lo gestisce, piuttosto che gestirlo direttamente
- Facilita il lavoro di chi dovrà modificare il sistema
- Usare codice riusabile e produrre codice riusabile
PRINCIPIO DI PROGETTO 8: ANTICIPARE L'OBSOLESCENZA
Prevedere i cambiamenti delle tecnologie e degli ambienti operativi in modo che il software possa continuare a funzionare o possa essere cambiato facilmente:
- Evitare l'uso delle prime release di una tecnologia
- Evitare librerie software specifiche di un dato ambiente di programmazione (meglio gli standard)
- Evitare di usare caratteristiche non documentate o poco usate delle librerie
software• Evitare di usare software o hardware speciale di compagnie che non forniranno supporto a lungo• Usare linguaggi standard e tecnologie supportate da più venditori
PRINCIPIO DI PROGETTO N.ro 9: PROGETTARE PER LA PORTABILITÀ
Permettere al software di funzionare su più piattaforme• Evitare l’uso di risorse che sono specifiche di un particolare ambiente• Vincolerebbero il sistema all’ambiente per sempre!• Ad esempio, una libreria disponibile solo per Microsoft Windows
PRINCIPIO DI PROGETTO N.ro 10: PROGETTARE PER LA TESTABILITÀ
http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli
INGEGNERIA DEL SOFTWARE FranK 7
Esegui le azioni necessarie a semplificare il testing. Progetta un programma che possa eseguire automaticamente i test
Assicurati che tutte le funzionalità del codice possano essere guidate da un programma esterno, bypassando l’interfacciagrafica utente.
In pratica, occorre fornire anche una versione a linea di comando per le varie funzionalità. In Java, si può creare un metodo main()
in ogni classe che esercita tutti gli altri metodi.
PRINCIPIO DI PROGETTO N.ro 11: PROGETTARE IN MODO DIFENSIVO
Non fidarsi mai di come gli altri useranno un componente che state progettando. Gestisci tutti i casi in cui altro codice potrebbe tentare di usare il tuo componente inappropriatamente. È necessario validare tutti gli input di un componente o controllare le precondizioni. Sfortunatamente, una validazione molto accurata può significare controlli ripetitivi.
Design by contact. Una tecnica per progettare in modo difensivo in maniera efficiente e sistematica:
- Idea di base: ciascun metodo ha un contratto con i suoi chiamanti;
- Il contratto ha una serie di asserzioni che stabiliscono:
- Quali precondizioni il metodo chiamato richiede che siano soddisfatte quando comincia l'esecuzione;
- Quali postcondizioni il metodo garantisce quando termina l'esecuzione.
Il metodo chiamato garantisce di essere vere al termine della sua esecuzione;
Il metodo chiamato garantisce di non modificare durante l'esecuzione;
Tecniche per fare delle buone scelte di progetto. Usare priorità e obiettivi per decidere su alternative:
- Elencare e descrivere le alternative per la decisione di progettazione;
- Elencare vantaggi e svantaggi di ogni alternativa con il rispetto dei vostri aggettivi e priorità;
- Determinare se qualche alternativa ti prevenga dall'incontrare uno o più obiettivi;
- Scegliere l'alternativa che ti aiuta per raggiungere i tuoi obiettivi;
- Adattarsi alle priorità per le sottosequenze di decisioni.
Esempi di priorità e obiettivi. Per un sistema si hanno i seguenti obiettivi, ordinanti in base a priorità decrescenti:
- Sicurezza
- Manutenibilità
- Efficienza della CPU
- Efficienza di memoria
- Portabilità
Le classi progettuali. Sappiamo già che il
Il modello analitico definisce un insieme completo di classi analitiche. Ognuna di queste classi descrive alcuni elementi del dominio del problema, concentrandosi sugli aspetti del problema visibili al cliente o all'utente. Il livello di astrazione di una classe analitica è relativamente elevato. A mano a mano che evolve il modello progettuale, il team di sviluppo software deve definire un insieme di classi di progettazione che:
- Raffinano le classi analitiche fornendo i dettagli progettuali che consentano di implementare le classi
- Creano un nuovo insieme di classi progettuali che implementino un'infrastruttura software per supportare la soluzione operativa
Esistono cinque classi progettuali differenti:
- Le classi dell'interfaccia utente per l'interazione uomo-computer
- Le classi dei processi implementano le astrazioni operative di basso livello necessarie per gestire al meglio le classi del dominio operativo
- Le classi persistenti rappresentano gli
le classi di sistema implementano le funzioni di gestione del software e di controllo che consentono al sistema di funzionare e comunicare con l'ambiente di calcolo e con il mondo esterno;
le classi del dominio operativo sono frequentemente raffinamenti delle classi analitiche. Le classi identificano gli attributi e i servizi (metodi) che sono necessari per implementare gli elementi del dominio operativo.
http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di NapoliINGEGNERIA DEL SOFTWARE FranK 8A
mano a mano che evolve il modello progettuale, il team di sviluppo software deve sviluppare un insieme completo di attributi e operazioni per ogni classe progettuale. Il livello di astrazione viene ridotto a mano a mano che ogni classe analitica viene trasformata in una rappresentazione del progetto. Le classi progettuali offrono molti dettagli tecnici come guida per
l'implementazione.
IL MODELLO PROGETTUALE. Il modello progettuale può essere considerato in due diverse dimensioni: la dimensione del processo indica l'evoluzione del modello progettuale a mano a mano che vengono svolte le attività progettuali nell'ambito del processo di sviluppo software; la dimensione di astrazione rappresenta il livello di dettaglio a mano a mano che ciascun elemento del modello analitico viene trasformato in un equivalente progettuale e poi raffinato iterativamente. Gli elementi del modello progettuale usano più o meno gli stessi diagrammi UML impiegati nel modello analitico. La differenza è che questi diagrammi vengono raffinati ed elaborati nell'ambito del progetto; vengono forniti maggiori dettagli implementativi e si pone l'accento sulla struttura e lo stile dell'architettura, sui componenti che risiedono all'interno dell'architettura e sulle interfacce fra i componenti e il mondo esterno.
Elementi della progettazione dei dati. La progettazione dei dati (o architettura dei dati) crea un modello dei dati e/o delle informazioni rappresentati a un livello di astrazione elevato (il punto di vista del cliente o dell'utente). Questo modello dei dati viene poi raffinato in rappresentazioni sempre più specifiche dell'implementazione che possono essere elaborate dal sistema.
Gli elementi di progettazione dell'architettura. Gli elementi di progettazione dell'architettura forniscono una visione globale del software. Si hanno è fonti: 1) informazioni sul dominio dell'applicazione software che deve essere realizzata; 2) elementi specifici del modello analitico, come ad esempio diagrammi di flusso dei dati o le classi analitiche, le loro relazioni e collaborazioni con il problema, 3) la disponibilità di schemi e stili dell'architettura.
Gli elementi di progettazione dell'interfaccia. Mostrano l'ingresso e l'uscita
delle informazioni nel sistema e le comunicazioni che si svolgono fra i componenti definiti dall'architettura. Vi sono tre elementi importanti nella progettazione dell'interfaccia:
- interfaccia utente;
- le interfacce esterne con altri sistemi, dispositivi, reti o altri produttori o consumatori di informazioni;
- le interfacce interne fra i vari componenti del progetto.
Questi elementi della progettazione delle interfacce consentono al software di comunicare esternamente e rendono possibili le comunicazioni e collaborazioni fra i componenti che costituiscono l'architettura del software. La progettazione delle interfacce esterne richiede l'acquisizione di informazioni sull'entità che invia o riceve le informazioni.
LA PROGETTAZIONE A LIVELLO DEI COMPONENTI
La progettazione a livello dei componenti deve essere eseguita dopo la prima iterazione della progettazione dell'architettura. A questo punto, già sono stati definiti la struttura generale
dei dati e del programma. Lo scopo è quello di trasformare il modello del progetto in un software operativo. Ma il livello di astrazione dell'attuale modello del progetto è relativamente elevato e il livello di a