UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ingegneria del software
Prof. Michele Amoretti
Fondamenti di Informatica
a.a. 2007/2008
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Sommario
•
Definizione di ingegneria del software
•
Qualità del software
•
Ciclo di vita del software
•
Universal Modeling Language (UML)
•
Design pattern
•
Anti-pattern
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Definizione di ingegneria del software
Crescente
necessità
di
ingegnerizzazione
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Definizione di ingegneria del software
L’ingegneria del software tratta della realizzazione di sistemi software di
dimensioni e complessità tali da richiedere uno o più team di persone.
L’ingegneria del software è la disciplina tecnologica e manageriale che
riguarda la produzione sistematica e la manutenzione dei prodotti
software che vengono sviluppati e modificati entro tempi e costi
preventivati.
L’ingegneria del software è un insieme di teorie, metodi e strumenti, sia
di tipo tecnologico che organizzativo, che consentono di produrre
applicazioni con le desiderate caratteristiche di qualità.
Grande sviluppo a partire dagli anni ’90, con:
•
•
•
tecnologie OOP
Unified Modelling Language (UML)
design pattern
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Qualità del software
Le qualità su cui si basa la valutazione di un sistema software
possono essere
• interne, se riguardano le caratteristiche legate alle scelte
implementative e non sono visibili agli utenti;
• esterne, se riguardano le funzionalità fornite dal sistema
e sono visibili agli utenti.
Le due categorie sono legate, infatti non è possibile ottenere
qualità esterne se il sistema non gode di qualità interne.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Qualità del software
Correttezza - un sistema è corretto se rispetta le specifiche.
Affidabilità (dependability) - un sistema è affidabile se l’utente può
dipendere da esso.
Robustezza - un sistema è robusto se si comporta in modo
ragionevole anche in circostanze non previste dalle specifiche.
Efficienza - un sistema è efficiente se usa bene le risorse di
calcolo.
Facilità d’uso - un sistema è facile da usare se l’interfaccia che
presenta all’utente gli permette di operare in modo naturale.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Qualità del software
Verificabilità - un sistema è verificabile se le sue caratteristiche sono
verificabili.
Riusabilità - un sistema è riusabile se può essere usato, in tutto o in
parte, per costruire nuovi sistemi.
Portabilità - un software è portabile se può funzionare su più piattaforme
hardware/software.
Facilità di manutenzione - un sistema è facile da manutenere se
• è strutturato in modo tale da facilitare la ricerca degli errori,
• la sua struttura permette di aggiungere nuove funzionalità al sistema,
• la sua struttura permette di adattarlo ai cambiamenti del dominio applicativo.
Interoperabilità - si riferisce all’abilità di un sistema di cooperare
con altri sistemi, anche di altri produttori.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Vari studi hanno mostrato che nei progetti di grandi dimensioni
l’implementazione iniziale del programma può occupare soltanto il
10–20% del tempo totale speso da programmatori e progettisti.
Circa il 25–40% del tempo si spende nelle fasi di specifica del
problema e progetto del programma, che vanno completate prima
dell’implementazione.
Un altro 40–65% si spende su attività che seguono
l’implementazione, come revisione, modifica, correzione e
miglioramento del codice originale, oltre che scrittura della
documentazione.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
1. Prima dell’implementazione
(a) Studio di fattibilità
(b) Specifica del problema
(c) Progettazione del programma
(d) Selezione o sviluppo degli algoritmi, analisi
2. Implementazione
(a) Codifica
(b) Debugging
3. Dopo l’implementazione
(a) Test, verifica e benchmarking
(b) Documentazione
(c) Manutenzione
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Studio di fattibilità
Vale la pena di acquistare un computer (o di procurarsi un nuovo e
più veloce sistema) e di scrivere o acquistare del software per
risolvere il problema?
Al termine dello studio di fattibilità, un documento di fattibilità
esprime i risultati, consigliando se procedere con l’acquisto di
hardware e software. La creazione di questo documento può
essere un processo di grande complessità, che comporta
valutazioni in campo economico, legale, gestionale, psicologico e
fiscale, oltre che informatico.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Specifica del problema
Comporta lo sviluppo di una descrizione chiara, concisa e non
ambigua dell’esatto problema da risolvere e dei requisiti a cui il
programma dovrà rispondere. La descrizione originale del
problema (in linguaggio naturale), usata nello studio di fattibilità,
potrebbe essere poco chiara, incompleta o anche contraddittoria.
Il documento di specifica dei requisiti riporta su carta la specifica
finale e completa e guida gli sviluppatori in tutte le decisioni
successive. Tale documento descrive esattamente come si
comporta il programma in tutte le circostanze, non solo nella
maggioranza nei casi, ma anche nelle condizioni meno usuali.
Include una descrizione dei dati attesi in ingresso, e dei risultati
che dovranno essere calcolati, e del modo in cui tali risultati
dovranno essere riportati in uscita.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Specifica del problema
La specifica del problema avviene normalmente come
negoziazione fra individui legati allo sviluppo (analisti) e i clienti,
oppure (nel caso di pacchetti software pensati per la grande
distribuzione) fra analisti e responsabili del marketing.
I modelli di ciclo di vita del software moderni hanno abbandonato
l'assunzione che sia possibile identificare i requisiti di un sistema
software a priori, e tendono a privilegiare approcci iterativi in cui i
requisiti vengono esplicitati gradualmente, per esempio
coinvolgendo l'utente nella prova di prototipi e rilasci parziali del
sistema in corso di sviluppo.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Specifica del problema
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Progettazione del programma
E’ il processo di conversione della specifica dei requisiti in un documento
di progetto di un sistema funzionante.
In questa fase si identificano i moduli appropriati,
insieme ai loro dati e alle sottoattività che devono
svolgere. Nel caso di progetti di tipo OOP,
identificare gli oggetti appropriati consente di
progettare classi con le necessarie variabili
istanza per memorizzare i dati e i metodi per
eseguire le sottoattività.
Più ampio è il progetto, più importante è identificare i
moduli che cooperano.
Si tratta di componenti di base che possono essere
progettati e creati singolarmente, e poi assemblati
in modo opportuno per risolvere il problema.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Progettazione del programma
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Selezione o sviluppo degli algoritmi, analisi
Una volta identificate le varie sottoattività, occorre trovare gli
algoritmi per svolgerle. Ad esempio, una sottoattività potrebbe
essere la ricerca di un valore in una lista di numeri.
Se vi è una scelta di algoritmi, occorre determinare quale è più
adatto al compito, e quale è il più efficiente. Talvolta occorre
sviluppare un algoritmo da zero, un processo molto creativo.
La documentazione di questa fase include una descrizione degli
algoritmi scelti o sviluppati, eventualmente in pseudocodice, e dei
motivi che hanno portato a utilizzarli.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Codifica
La codifica è il processo con cui si traducono i progetti dettagliati
di moduli e algoritmi in linguaggio di programmazione.
Se il progetto è stato sviluppato con cura, dovrebbe essere una
fase quasi di routine. Talvolta si può prendere del codice riusabile
da una libreria di programma, o una classe utile.
Anche la fase di codifica dà origine a un documento scritto, il
listato di codice di programma.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Debugging
Il debugging è il processo in cui si individuano e correggono gli
errori di programma.
•
Errori di sintassi: un’istruzione non segue le corrette regole
della sintassi, il che la rende irriconoscibile dal compilatore.
•
Errori di runtime: si verificano soltanto quando il programma è
eseguito con particolari insiemi di dati che danno origine a
operazioni non lecite, come la divisione per zero.
•
Errori logici: i più difficili da rintracciare ed eliminare, causati
da scelte fatte nell’algoritmo usato per risolvere il problema.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Test, verifica e banchmarking
Un approccio, detto collaudo empirico, è quello di progettare una
speciale serie di casi di prova ed eseguire il programma con tali
dati. I dati di prova, se scelti con cura per percorrere tutti i diversi
percorsi logici all’interno di un programma, possono aiutare a
scoprire errori.
Un secondo approccio per confermare l’affidabilità di un
programma consiste nell’usare la logica matematica per tentare di
dimostrare che il programma sia corretto. La verifica del
programma può essere impiegata per dimostrare che, se i dati di
ingresso per un programma soddisfano certe condizioni, allora,
dopo l’esecuzione del programma su questi dati, i dati di uscita
soddisferanno certe altre condizioni.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Test, verifica e banchmarking
Oltre alla correttezza, la specifica del problema potrebbe
richiedere alcune caratteristiche prestazionali come il tempo
richiesto per calcolare i risultati. Il benchmarking di un programma
significa eseguirlo su molti insiemi di dati per assicurarsi che le
prestazioni ricadano entro i limiti richiesti.
•
•
Testing in the small, riguarda moduli singoli.
Testing in the large, riguarda il sistema nella sua globalità.
Naturalmente tutti i risultati di queste fasi dovranno essere
riportati sulla carta come prova che il programma soddisfa le
specifiche.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Documentazione
La documentazione del programma è tutto il materiale scritto
che lo rende comprensibile.
Comprende la documentazione interna, che fa parte del codice
di programma stesso. Una buona documentazione interna si
ottiene scegliendo nomi significativi per gli identificatori di
programma, usando molti commenti per descrivere il codice e
separando il programma in classi ragionevoli con metodi brevi,
ognuno dei quali svolga una sottoattività specifica.
La documentazione esterna è costituita dai materiali raccolti
per facilitare la comprensione del programma. Anche se abbiamo
posto questa fase in un punto avanzato del processo di sviluppo,
si deve notare che ogni fase precedente produce qualche forma di
documentazione.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Documentazione
La documentazione accompagna tutto il ciclo di vita del software.
La versione definitiva è scritta in due forme.
La documentazione tecnica consente ai programmatori che in un
secondo tempo interverranno sul programma di comprenderne il
codice. Informazioni come descrizioni di classi e di algoritmi, oltre
ai listati, rientrano in questa categoria.
La documentazione utente aiuta gli utenti a eseguire il
programma; comprende tutorial online o sistemi di guida che
l’utente può utilizzare mentre il programma è in esecuzione, e
(sempre più raramente) manuali scritti.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Manutenzione
I programmi non sono entità statiche che, una volta completate,
non cambiano più. I programmi di successo, scritti con grande
impegno di tempo e denaro nello sviluppo, vengono usati a lungo.
Non è raro che un programma rimanga in uso per 5, 10 o 15 anni
dopo la sua creazione. In effetti il ciclo di vita tipico per un
software medio-grande è di 1–3 anni in sviluppo e 5–15 anni sul
mercato. Durante questo lungo periodo d’uso si possono scoprire
errori, acquistare nuovo hardware per l’esecuzione del
programma, possono cambiare le esigenze dell’utente, ecc.
Il programma originale deve essere modificato e fornito in versioni
nuove per adeguarsi alle esigenze cambiate.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Ciclo di vita del software
Manutenzione
La manutenzione del programma, il processo con cui si adatta un
software esistente, può occupare fino al 65% del budget totale per
il ciclo di vita del software. Se il programma è stato ben
pianificato, progettato con attenzione, collaudato ampiamente
e ben documentato, la manutenzione risulterà molto più facile.
La manutenzione non dovrebbe essere considerata come un
passaggio separato nel ciclo di vita del software; in realtà
coinvolge la ripetizione di alcune o tutte le fasi descritte in
precedenza, da uno studio di fattibilità a implementazione,
collaudo e documentazione aggiornata. Questa fase riflette il fatto
che il ciclo di vita del software è veramente un ciclo, durante il
quale è necessario ripetere le prime fasi di sviluppo mentre il
software cresce, cambia e matura.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Unified Modeling Language (UML)
In ingegneria del software, UML (Unified Modeling Language,
"linguaggio di modellazione unificato") è un linguaggio di
modellazione e specifica basato sul paradigma object-oriented.
Il nucleo del linguaggio fu definito nel 1996 da Grady Booch, Jim
Rumbaugh e Ivar Jacobson (detti "i tre amigos") sotto l'egida dello
Object Management Group (OMG), che tuttora gestisce lo
standard di UML.
UML svolge un'importantissima funzione di lingua franca nella
comunità della progettazione e programmazione a oggetti. Gran
parte della letteratura di settore usa UML per descrivere soluzioni
analitiche e progettuali in modo sintetico e comprensibile a un
vasto pubblico.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Unified Modeling Language (UML)
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Class Diagram
I CD consentono di descrivere le classi di un sistema, con
le loro caratteristiche (variabili membro e metodi) e le relazioni
che intercorrono tra di esse.
Es.
associazione
Si legge: un cliente
può fare più ordini.
1
navigabilità
La freccia dice che
un ordine ha la
responsabilità di
specificare da quale
cliente proviene.
Ingegneria del software
+  public
-  private
#  protected
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Class Diagram
Nei CD si usa una simbologia specifica per esprimere l’ereditarietà.
Es.
implementazione
estensione
classi
Ingegneria del software
interfaccia
Note:
1) l’estensione può essere anche tra interfacce
2) l’ereditarietà in generale può essere multipla
[in Java no, però!]
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Class Diagram
Anche le relazioni “parte di” hanno una loro simbologia specifica.
Es.
Diamante vuoto: aggregazione  la durata della vita dell’oggetto
composto NON coincide con quella delle parti
Diamante pieno: composizione  la durata della vita dell’oggetto
composto coincide con quella delle parti
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Package Diagram
I PD permettono di raggruppare elementi (classi, in genere) affini
e di esprimere le dipendenze tra gruppi di elementi.
Es.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Object Diagram
Gli OD permettono di descrivere un sistema in termini di oggetti e
relative relazioni.
Notazione per gli oggetti: nomeOggetto: Classe
Es.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Component Diagram
Servono a rappresentare le interazioni tra moduli:
•
•
•
•
•
programmi eseguibili
librerie
tabelle
file
documenti
Es.
A sinistra le interfacce fornite, a destra quelle richieste.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Component Diagram
Es.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Deployment Diagram
Es.
I DD servono a descrivere i sistemi in
termini di risorse hardware detti nodi,
e di relazioni fra di esse.
Spesso si utilizza un diagramma che
mostra come le componenti software
sono distribuite rispetto alle risorse
hardware disponibili sul sistema;
questo diagramma è costruito unendo
il Component Diagram e il Deployment
Diagram.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Use Case Diagram (UCD)
Gli UCD sono dedicati alla descrizione delle funzioni o servizi
offerti da un sistema, così come sono percepiti e utilizzati dagli
utenti (detti attori) che interagiscono col sistema stesso.
Es.
Ciascun ovale rappresenta uno use case. Gli omini sono gli attori.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
UML – Activity Diagram
Fondamenti di Informatica
Es.
Un AD definisce le attività da
svolgere per realizzare una data
funzionalità. Può essere utilizzato
anche in fase di design per
dettagliare un determinato
algoritmo (in tal caso è come un
flowchart).
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Sequence Diagram
I SD vengono utilizzati per
Descrivere sequenze di azioni
in cui tutte le scelte sono
state già effettuate; in pratica
nel diagramma non
compaiono scelte, né flussi
alternativi.
Es.
Un SD descrive le relazioni che
intercorrono, in termini di
messaggi, tra attori, oggetti o
entità del sistema che si sta
rappresentando.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Communication Diagram
Un diagramma di questo tipo serve a descrivere l'interazione fra
più partecipanti alla realizzazione di una certa funzionalità.
I messaggi sono scambi di informazione fra due partecipanti e
possono essere sincroni o asincroni a seconda se il chiamante resti
bloccato in attesa della risposta al messaggio oppure prosegua la
sua elaborazione in parallelo al partecipante che ha ricevuto il
messaggio.
I messaggi sono numerati, al fine di comprendere la loro sequenza
temporale. La numerazione può essere semplice (1, 2, 3 ...)
oppure decimale nidificata (1, 1.1, 1.1.1, ... 2 ...).
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
UML – Communication Diagram
Es.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Nell'ingegneria del software, un design pattern può essere definito
"una soluzione progettuale generale a un problema ricorrente".
Esso non è una libreria o un componente di software riusabile,
quanto 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.
La differenza tra un algoritmo e un design pattern è che il primo
risolve problemi computazionali, mentre il secondo è legato agli
aspetti progettuali del software.
L'uso di pattern nella descrizione di altri pattern dà origine ai
cosiddetti linguaggi di pattern.
PLoP  http://hillside.net/plop/2008/index.php
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Un design pattern è definito da:
•
un nome, costituito da una o due parole che siano il più
possibile rappresentative del pattern stesso;
•
un problema, ovvero la descrizione della situazione alla quale
si può applicare il pattern; il problema può essere generale o
specifico; può esserci anche una lista di condizioni perché sia
necessario l'utilizzo del pattern;
•
una soluzione, che descrive gli elementi costitutivi del pattern
con le relazioni e relative implicazioni, senza però addentrarsi
in una specifica implementazione;
•
delle conseguenze, cioè i risultati e i vincoli che derivano
dall'applicazione del pattern. Sono fondamentali in quanto
possono essere l'ago della bilancia nella scelta dei pattern.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Classificazione generale:
• Pattern dello sviluppo
Riguardano l’attività degli sviluppatori di software.
• Pattern architetturali
Riguardano l’attività dei progettisti di software.
• Pattern gestionali
Riguardano l’attività dei “project manager”.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Classificazione dei pattern per l’OOP (sono pattern dello sviluppo e
architetturali allo stesso tempo):
• Pattern creazionali
Forniscono un’astrazione del processo di creazione delle istanze
delle classi, favorendo l’indipendenza del sistema dalle modalità di
creazione e dai tipi concreti effettivamente generati.
• Pattern strutturali
Consentono di riutilizzare oggetti esistenti fornendo agli
utilizzatori un'interfaccia più adatta alle loro esigenze.
• Pattern comportamentali
Forniscono soluzione alle più comuni tipologie di interazione tra gli
oggetti.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Es. Singleton
E’ un pattern creazionale.
Il suo scopo è assicurare che una classe abbia una sola istanza.
public class MegaDirettoreGalattico {
private static MegaDirettoreGalattico istanza = null;
private MegaDirettoreGalattico() {} // COSTRUTTORE PRIVATO!
}
public static MegaDirettoreGalattico getMegaDirettoreGalattico() {
if (istanza == null) {
istanza = new MegaDirettoreGalattico();
}
return istanza;
}
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Es. Singleton
(continuazione)
Si ricordi che static significa “condiviso da tutte le istanze
della classe”. Quindi quando viene creato l’oggetto a cui la
variabile membro istanza fa riferimento, tutte le successive
invocazioni di getMegaDirettoreGalattico() restituiranno un
riferimento a quell’oggetto.
// prima invocazione: l’istanza viene creata
MegaDirettoreGalattico direttore =
MegaDirettoreGalattico.getMegaDirettoreGalattico();
// seconda invocazione: nessuna nuova istanza creata
MegaDirettoreGalattico altroDirettore =
MegaDirettoreGalattico.getMegaDirettoreGalattico();
direttore e altroDirettore sono due riferimenti allo stesso oggetto!
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Es. Adapter
E’ un pattern strutturale.
Il suo scopo è fornire una soluzione astratta al problema
dell'interoperabilità tra interfacce differenti.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Design pattern
Es. Strategy
E’ un pattern comportamentale.
Il pattern Strategy è utile in quelle situazioni dove è necessario
modificare dinamicamente gli algoritmi utilizzati da un'applicazione.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Un antipattern si può definire alla stessa maniera dei "pattern" in
quanto è comunque una soluzione progettuale generale a un
problema ricorrente ed è costituito da un nome, un problema, una
soluzione e delle conseguenze.
La differenza tra un pattern (migliorativo) ed un antipattern è che
il primo è caratterizzato da una soluzione universalmente
riconosciuta come buona e positiva, mentre il secondo propone
una falsa soluzione o una soluzione fondamentalmente negativa e
che quindi deve essere evitata.
Un antipattern può anche essere un pattern utilizzato nel modo
e/o nel posto sbagliato…
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Classificazione generale:
• Antipattern dello sviluppo
Riguardano l’attività degli sviluppatori di software.
• Antipattern architetturali
Riguardano l’attività dei progettisti di software.
• Antipattern gestionali
Riguardano l’attività dei “project manager”.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Vediamo alcuni noti antipattern per l’OOP:
Es. Spaghetti code
Sintomi:
• Struttura confusa del codice
• Uso di variabili globali
• Uso di GOTO
Es. Accumulate and fire
Il programma crea e inizializza un certo numero di variabili globali,
che poi vengono utilizzate (e modificate) da sottoprogrammi o
metodi.
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Es. God object
Un oggetto non deve “sapere” troppe cose e “fare” troppe cose.
Un God object è l’istanza di una classe che ha troppe variabili
membro e troppi metodi (spesso non correlati).
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Es. Polimorfismo dei poveri
if (animale instanceof Gatto) {
faiQualcosa(animale);
}
else if (animale instanceof Papero) {
faiQualcosAltro(animale);
}
Si hanno comportamenti diversi in base alla classe di cui
“personaggio” è istanza, ma tali comportamenti sono dati da
metodi diversi della classe utilizzatrice.
Se aggiungiamo una nuova classe Cane e vogliamo un nuovo
comportamento, siamo costretti a definire un nuovo metodo nella
classe utilizzatrice:
faiQualcosAltroAncora(Cane cane) { .. }
Ingegneria del software
Prof. M. Amoretti
UNIVERSITA’ DEGLI STUDI DI PARMA
Corso di Laurea in Ingegneria Gestionale
Fondamenti di Informatica
Antipattern
Es. Polimorfismo dei poveri
Riguardo quest’ultimo antipattern, basta un pò di OOP per
rifattorizzare il tutto in maniera più corretta e manutenibile,
semplicemente usando interfacce e relazioni di implementazione
e/o ereditarietà tipo:
animale.faiQualcosa();
avendo avuto cura di definire
public interface Animale {
void faiQualcosa();
}
public class Gatto implements Animale { .. };
public class Papero implements Animale { .. };
Ingegneria del software
Prof. M. Amoretti