I linguaggi
di programmazione sono in continua evoluzione e in questi
ultimi anni la programmazione orientata agli oggetti (OOP) è diventata
un must; parallelamente anche le tecniche di analisi e progettazione
del software si evolvono. Coad e Yourdon affermano:
Le idee sul modo di progettare sono influenzate dalle idee
su come va scritto il codice; e le idee su come va scritto il codice sono
fortemente influenzate dai linguaggi di programmazione disponibili. Era
difficile parlare di programmazione strutturata (e quindi difficile parlare
di progettazione strutturata e di analisi strutturata) quando i linguaggi
tra cui scegliere erano l'assembler e il FORTRAN; le cose divennero più
facili col Pascal, il PL/1 e l'Algol. Similmente era difficile parlare
in modo orientato agli oggetti quando i linguaggi tra cui scegliere erano
il COBOL o il semplice C; è diventato più facile col C++
e lo Smalltalk. [da OOD]
Poiché oggi si programma ad oggetti, Coad e Yourdon hanno proposto
una nuova tecnica di analisi e una nuova tecnica di progettazione orientate
agli oggetti. Il primo evidente vantaggio del metodo Coad-Yourdon sta nel
fatto di eliminare la tradizionale spaccatura tra DFD (data-flow diagrams,
i diagrammi "a bolle") e i diagrammi Entità-Relazioni (ERD), nonché
la spaccatura tra analisi e progettazione. Questo risultato è ottenuto
utilizzando un'unica rappresentazione grafica in grado di descrivere sia
l'organizzazione dei dati (in sostituzione degli ERD) sia le elaborazioni
effettuate su di essi (in sostituzione dei DFD) e mantenendo invariata
questa notazione sia nella fase di analisi che in quella di progettazione
(in modo da eliminare la "transizione verso il progetto"). Questa tecnica
si propone inoltre di aumentare la produttività facilitando il riuso
e la manutenzione del software.
Avendo una rappresentazione uniforme per l'analisi e la progettazione
non occorre completare l'analisi prima che inizi la progettazione: l'OOA
e l'OOD si possono applicare in sequenza o in modo alternato e quindi si
adattano a diversi cicli di sviluppo del software (a cascata, a spirale,
o incrementale).
La realizzazione di un software complesso richiede una intensa comunicazione
interpersonale, non solo tra i membri del team di sviluppo ma anche tra
questi e il committente. Si pensi ad esempio al caso dello sviluppo di
un sistema per il controllo del traffico aereo: la piena comprensione del
dominio del problema da parte degli analisti richiederà molto tempo
e numerose interviste al personale addetto a tale controllo; questo personale
esperto, poi, dovrà anche convalidare i risultati dell'analisi effettuata.
Per questo motivo gli autori affermano:
Il termine "ingegneria del software" è in fondo ironico:
mentre il mondo si immagina formule, algoritmi e approcci scientifici seri,
l'ingegneria del software è in effetti un'attività molto
orientata agli uomini. [...] I metodi di sviluppo software sono efficaci
solo nella misura in cui aiutano la gente a comunicare. Se l'applicazione
di un "metodo" di ingegneria del software produce un monumento di carta,
allora c'è qualcosa di sbagliato. [da OOA]
Gli autori hanno collaborato in più occasioni alla realizzazione
di sistemi di elevata complessità ma per mettere a punto il loro
metodo hanno seguito da vicino anche il lavoro di altri progettisti orientati
agli oggetti, alla ricerca di uno schema riscontrabile molto spesso nei
buoni progetti e nelle buone implementazioni orientate agli oggetti. Il
risultato è un modello che prevede, nella fase di analisi, la suddivisione
del dominio del problema in cinque livelli e, nella fase di progettazione,
la definizione di quattro componenti. I livelli sono "fette" orizzontali
del modello complessivo e vanno immaginati come fogli trasparenti sovrapposti.
Essi sono:
e corrispondono alle cinque attività principali dell'OOA che consiste
proprio nell'identificazione di Soggetti, Classi-&-Oggetti, Strutture,
Attributi e Servizi. I quattro componenti, invece, sono "fette" verticali
del modello complessivo. Essi sono:
e corrispondono alle quattro attività principale dell'OOD che consiste
proprio nella progettazione di questi componenti come insiemi di classi.
Il primo dei quattro, in particolare, è quello in cui si riversano
i risultati dell'analisi e quindi deve essere solo rifinito nella fase
di progettazione mentre gli altri tre devono essere creati ex novo (fatta
salva la possibilità di riusare pezzi di progetti preesistenti).
Il metodo di Coad e Yourdon è descritto in due volumi separati,
uno dedicato all'OOA e uno all'OOD; a questi se ne aggiunge un terzo, opera
di Coad e Nicola, che propone 4 "casi di studio", vale a dire 4 dettagliati
esempi d'uso della tecnica con relativa implementazione in C++ e Smalltalk.
I tre volumi sono organizzati in maniera da essere indipendenti l'uno
dall'altro. Teoricamente un analista potrebbe leggere solo il primo, un
progettista solo il secondo e un programmatore solo il terzo ma è
ovvio che una lettura sequenziale dei tre volumi fornisce una migliore
visione del metodo e dei problemi connessi con la sua implementazione e
favorisce il dialogo tra le diverse figure professionali coinvolte in un
progetto di medie o grandi dimensioni orientato agli oggetti.
Gli argomenti trattati nei primi due volumi, in particolare, sono caratterizzati
da una forte coesione e quindi per rendere i due libri indipendenti è
stato necessario ripetere pedissequamente alcuni concetti, tanto che alcuni
paragrafi risultano identici o quasi. Anche l'organizzazione dei due volumi
è molto simile.
Il
primo libro, OOA - Analisi dei sistemi orientati agli oggetti,
dopo due capitoli introduttivi, esamina le cinque attività fondamentali
dell'OOA e per ognuna di queste spiega in cosa consiste, perché
è importante, e come deve essere affrontata. Gli ultimi tre capitoli
esaminano i requisiti che dovrebbe avere un buono strumento CASE per l'OOA,
i principali problemi connessi all'introduzione dell'OOA in un'organizzazione,
e i principali aspetti dell'OOD.
Il
secondo volume, OOD - Progettazione dei sistemi orientati agli
oggetti, dopo aver presentato i principi generali dell'OOD, le sue
finalità e la notazione grafica usata nei progetti (la stessa usata
nell'OOA), esamina uno dopo l'altro i quattro componenti rispondendo alle
domande "Che cos'è?", "Perché occorre?" e
"Come si determina?" e proponendo degli esempi. In seguito
vengono analizzate la sintassi e le caratteristiche di alcuni
linguaggi per confrontare il loro supporto alla semantica dell'OOA
e dell'OOD. Poi gli autori presentano i criteri per valutare
la qualità di un progetto OO: accoppiamento, coesione,
riusabilità, ecc. Si tratta di criteri già usati in passato
per la progettazione strutturata e tuttora validi per cui vengono semplicemente
adattati all'OOD. Infine gli ultimi due capitoli esaminano i requisiti
che dovrebbe avere un buono strumento CASE per l'OOD e i principali problemi
connessi all'introduzione dell'OOD in un'organizzazione.
Il
terzo volume, OOP - Programmazione dei sistemi orientati agli
oggetti, è molto più grosso degli altri due e può
essere visto come un libro di esercizi con relativa soluzione. Qui gli
esercizi sono 4 progetti di complessità crescente che vengono affrontati
con le tecniche dell'OOA, dell'OOD e dell'OOP. Il processo di sviluppo
utilizzato è di tipo concorrente: l'OOA, l'OOD e l'OOP vengono applicati
quasi contemporaneamente, a più riprese. L'idea di usare il più
tradizionale approccio a cascata viene scartata con vero e proprio disgusto:
Puah! Perché accollarsi questo rischio? Perché
aspettare ad esplorare le modalità in cui realmente opera il sistema?
Perché aspettare ad esaminare dettagliatamente le vostre classi
chiave? Perché aspettare per verificare le ipotesi che avete fatto?
Perché aspettare così a lungo prima di dimostrare un risultato
pur modesto ma sempre tangibile (del software che gira! non pile di cartaccia).
[da OOP]
I libri si rivolgono ai professionisti del settore, le persone che devono
affrontare tutti i giorni lo sviluppo di sistemi reali. Di conseguenza
si presuppone che il lettore conosca almeno un OOPL così da essere
familiare con classi, ereditarietà e polimorfismo; inoltre in un
paio di paragrafi vengono citati DFD ed ERD dando per scontato che il lettore
sappia di cosa si tratta.
E' da notare, infine, che i tre libri hanno già qualche anno
di vita e quindi non sono l'ultimo grido della moda; già altre tecniche
si affacciano alla ribalta tuttavia il metodo Coad-Yourdon rimane l'opera
di due grandi esperti in fatto di analisi e progettazione e i loro libri
sono tuttora usati come riferimento in numerosi corsi universitari.
| Scheda del prodotto n.1 | |
| Titolo: Autore: Editore: Formato: Pagine: Prezzo: ISBN: |
OOA - Analisi dei sistemi orientati agli oggetti, II ed. Peter Coad, Edward Yourdon Jackson Libri 17x24 cm 240 39000 lire (20.14 euro) 88-7056-963-2 |
| Scheda del prodotto n.2 | |
| Titolo: Autore: Editore: Formato: Pagine: Prezzo: ISBN: |
OOD - Progettazione dei sistemi orientati agli oggetti Peter Coad, Edward Yourdon Jackson Libri 17x24 cm 224 39000 lire (20.14 euro) 88-256-0552-8 |
| Scheda del prodotto n.3 | |
| Titolo: Autore: Editore: Formato: Pagine: Prezzo: ISBN: |
OOP - Programmazione dei sistemi orientati agli oggetti Peter Coad, Jill Nicola Jackson Libri 17x24 cm 600 + floppy disk 79000 lire (40.80 euro) 88-256-0623-0 |