|
Struttura
del libro
Capitolo
0 - Presentazione
Nel capitolo di presentazione viene introdotto il libro.
In particolare sono presenti la descrizione di una breve
genesi dello stesso, l'illustrazione del variegato pubblico
dei potenziali fruitori, alcuni consigli per la lettura,
l'illustrazione dettagliata della struttura del libro con
una breve sintesi dei contenuti dei capitoli, gli immancabili
ringraziamenti nonché le scuse dell'autore e le convenzioni
grafiche adottate.
Capitolo
1 - UML: che cosa è, che cosa non è
Il primo capitolo si apre con una breve panoramica storica
dello Unified Modeling Language e delle motivazioni che
hanno spinto i Tres Amigos ad affrontare lo straordinario
progetto di un linguaggio di modellazione unificato.
Si prosegue con una descrizione di cosa sia e cosa non sia
lo Unified Modeling Language, della relativa architettura
e di quali siano i suoi obiettivi.
Successivamente viene affrontato il tema dei più
diffusi processi di sviluppo del software e, in particolare,
"The Unified Software Development Process", "Use
case Driven Object Modeling with UML", l'eXtreme Programming
(XP) ed l'"Agile Modeling" (AM).
Il capitolo termina con l'immancabile paragrafo dedicato
ai tool disponibili in commercio, corredati da una concisa
riflessione, quanto più oggettiva possibile, dei
relativi pregi e difetti.
Obiettivo del primo capitolo è presentare lo UML
inquadrandolo nel relativo contesto, chiarendo fin da subito
il rapporto con le altre tecniche/metodologie che lo circondano.
Capitolo
2 - UML: struttura, organizzazione, utilizzo
Il secondo capitolo è interamente dedicato a una
panoramica dello UML: vengono presentate le viste, i diagrammi
e i meccanismi di estensione utilizzati dallo UML per aumentarne
semantica e sintassi. Sono inoltre introdotti i profili,
ossia collezioni standard di meccanismi di estensione predefiniti
da utilizzarsi durante la modellazione di sistemi che utilizzano
architetture standard quali ad esempio CORBA e EJB o per
compiti specifici come la modellazione dell'area business.
Attraverso il presente capitolo, l'autore si pone l'obiettivo
di fornire un'idea, quanto più esauriente possibile,
di cosa sia il linguaggio senza aver la pretesa che il lettore
comprenda fin da subito tutti i concetti introdotti, per
i quali sono presenti appositi capitoli di dettaglio. Importante
è iniziare a comprendere che lo UML fornisce tutta
una serie di "utensili", ciascuno dei quali risulta
appropriato a scopi ben precisi e del tutto inadeguato ad
altri: una vera e propria cassetta degli attrezzi.
La descrizione dei vari manufatti che si prestano a essere
realizzati per mezzo dello UML avviene nel contesto di un
generico processo di riferimento.
Capitolo
3 - Introduzione agli Use Case
Nel terzo capitolo, dopo una breve disquisizione su cosa
si intenda con i termini "requisiti utente", si
procede con l'introduzione della use case view (vista dei
casi d'uso). Si entra finalmente nel vivo dello UML!
In questo capitolo si focalizza l'attenzione sulla teoria
degli use case e sul relativo impiego rispettando rigorosamente
le direttive dello UML. Nel capitolo seguente invece, ci
si discosterà sensibilmente dalle direttive standard,
al fine di illustrare un utilizzo avanzato e maggiormente
operativo dei casi d'uso.
Della vista dei casi d'uso sono descritte le due componenti:
statica e dinamica. Per ciò che riguarda la proiezione
statica, vengono descritti in dettaglio i diagrammi dei
casi d'uso ed i relativi elementi.
Per ciò che concerne la proiezione dinamica (ossia
gli scenari), ne viene illustrata la versione standard basata
sui flussi degli eventi e sui diagrammi dello UML atti a
modellare comportamenti dinamici (diagrammi di sequenza,
collaborazione, attività, ecc.).
Capitolo
4 - Modellazione avanzata degli Use Case
Nel quarto capitolo viene illustrata una serie di tecniche
di utilizzo decisamente operativo anche se, a volte, sensibilmente
distante dalle direttive standard, per la cattura e documentazione
dei requisiti utente. Modellare sistemi reali mette in luce
tutta una serie di problemi e lacune raramente trattati
nei libri e nelle specifiche ufficiali dello UML.
Si tratta di un capitolo di stampo decisamente pratico corredato
da un notevole numero di esempi di casi d'uso pseudoreali.
Sebbene non sia indispensabile esaminare attentamente tutti
gli esempi, ognuno di essi è stato selezionato in
quanto fornisce una serie di spunti molto interessanti.
Capitolo
5 - Completamento dell'analisi dei requisiti
Il quinto capitolo è imperniato sue due tematiche
portanti: la presentazione di una tecnica dimostratasi particolarmente
valida nell'arduo compito dell'analisi dei requisiti utente
e l'illustrazione dei manufatti (artifact) che completano
il modello dell'analisi dei requisiti.
Il problema che tenta di risolvere la tecnica di analisi
dei requisiti esposta è trovare una piattaforma di
dialogo comune e costruttiva tra personale tecnico e clienti,
in altre parole trovare un efficace raccordo tra i due diversi
linguaggi tecnici: quello dell'area business e quello informatico.
A tal fine viene sfruttato il formalismo degli activity
diagram (diagramma delle attività).
Il modello dei casi d'uso, pur essendo un artifact molto
importante, da solo non è assolutamente in grado
di fornire sufficienti informazioni per il pieno svolgimento
delle restanti fasi del ciclo di vita del sistema. La completa
realizzazione della vista dei requisiti del sistema prevede
la produzione di ulteriori manufatti complementari. In particolare,
nel quinto capitolo sono presentati artifact di notevole
importanza, come il dettaglio delle interfacce, i test case,
il documento dei requisiti non funzionali e le famosissime
business rules.
Capitolo
6
Il sesto capitolo è dedicato alla presentazione dei
principi fondamentali dell'Object Oriented. L'obiettivo
è introdurre le nozioni utilizzate nei capitoli successivi,
senza aver la presunzione di trattare in maniera approfondita
un argomento così importante e vasto.
Il capitolo non poteva che iniziare con la definizione formale
di oggetto e classe e delle relative relazioni, prosegue
poi con l'illustrazione degli elementi essenziali di cui
è composto un oggetto (identità, stato e interfaccia)
e vengono presentate le tre leggi fondamentali dell'Object
Oriented (ereditarietà, incapsulamento e polimorfismo).
In questa sede si coglie l'occasione per riportare alcuni
errori tipicamente commessi da tecnici alle prime armi.
Questa prima sezione termina con l'introduzione di due principi
fondamentale del disegno dei sistemi, note con i nomi di
massima coesione e minimo accoppiamento. La parte conclusiva
del capitolo è dedicata al formalismo dell'Abstract
Data Type (tipo di dato astratto) e al Design By Contract
(disegno per contratto).
Capitolo
7
Il settimo capitolo è focalizzato sull'illustrazione
del formalismo dei diagrammi delle classi, probabilmente
uno dei più noti e affascinanti tra quelli definiti
dallo UML.
Nei processi di sviluppo del software, questo formalismo
si presta a rappresentare formalmente molteplici artifact
presenti in diversi stadi del processo. Nelle primissime
fasi lo si adotta per rappresentare i modelli del dominio
e di business, nello stadio di analisi è utilizzato
per dar luogo all'omonimo modello (rappresentazione formale
dei requisiti funzionali sanciti nel modello dei casi d'uso),
nella fase di disegno è impiegato per progettare
e documentare l'organizzazione in codice del sistema e così
via.
Dopo aver illustrato come rappresentare in UML i concetti
basilari di classi, interfacce, ecc., si passa all'illustrazione
delle diverse tipologie di relazioni.
La modellazione di un sistema non richiede esclusivamente
l'identificazione delle classi di cui è composto,
ma anche dei legami che le interconnettono. Si prosegue
pertanto passando in rassegna le relazioni con cui è
possibile collegare le classi tra loro.
La sezione successiva del capitolo è dedicata all'illustrazione
del formalismo dei diagrammi degli oggetti (object diagram).
Questi rappresentano una variante dei diagrammi delle classi,
o meglio ne sono istanze e ne condividono gran parte della
notazione. Rappresentano la famosa istantanea del sistema
eseguita in un preciso istante di tempo di un'ipotetica
esecuzione.
Capitolo
8
Il capitolo ottavo è dedicato a illustrare l'utilizzo
del formalismo dei diagrammi delle classi nel contesto di
un processo di sviluppo del software. In particolare si
presentano le diverse versioni di modelli a "oggetti",
le relative proprietà, un nutrito insieme di esempi
e consigli, eventuali "tranelli" in cui è
possibile cadere, il rapporto di ciascuno di essi con i
restanti, ecc. Si tratta di uno di quei capitoli che dovrebbe
fornire le risposte esaurienti agli interrogativi più
ricorrenti richiesti all'autore del libro.
Il primo modello ad oggetti presentato è quello relativo
al dominio del problema (Domain Object Model). In particolare
si presenta un processo pratico atto a semplificare l'individuazione
delle classi appartenenti al modello e a inserirle in un
contesto strutturato. Del processo viene fornito un esempio
di applicazione, nel quale sono evidenziati errori ricorrenti
e vengono dati utili consigli.
Poiché è sempre meno frequente realizzare
sistemi partendo dal nulla, mentre è prassi reingegnerizzare
sistemi esistenti, si presenta una tecnica atta a realizzare
prime versioni del modello a oggetti del dominio partendo
dall'analisi di una base di dati del sistema.
Il modello ad oggetti presentato successivamente è
quello relativo all'area business (Business Object Model).
Si tratta di una versione molto simile a quello del dominio,
in cui compaiono elementi aggiuntivi (work unit, unità
di lavoro e worker, lavoratori). Pertanto si evidenziano
le similitudini e differenze con quello del dominio e si
dà quindi una serie di consigli relativi a quale
usare, quando, e così via. Teoricamente in un processo
di sviluppo andrebbero realizzati entrambi, nella pratica,
per via di una serie di problemi relativi al tempo, budget,
personale, ecc. è normale trascurarne uno dei due
per concentrasi sull'altro.
Il passo successivo consiste nel presentare il modello a
oggetti di analisi (analysis model). Anche per questo modello
viene presentata una tecnica utile per la relativa realizzazione,
una serie di consigli, nonché i vari tranelli in
cui si può correre il rischio di imbattersi. Nei
progetti reali non è sempre possibile realizzare
il modello di analisi, per via dei soliti problemi (mancanza
di tempo, personale, ecc.), pertanto si fornisce una serie
di consigli su come ridurre il rischio generato dalla mancata
realizzazione, quando sia possibile trascurarlo, quando
invece è opportuno realizzarlo, ecc. Prima di proseguire
nella presentazione del modello successivo, viene presentato
un formalismo di importanza storica per il processo di realizzazione
dei vari modelli a oggetti che tuttora conserva delle aree
di applicazioni, ossia il metodo delle CRC cards.
L'ultimo modello a oggetti presentato, probabilmente il
più noto, è quello di disegno (Design Object
Model). Di questo dovrebbero esistere due versioni: quello
di specifica e quello di implementazione. Il primo dovrebbe
essere realizzato prima dell'inizio della codifica, mentre
il secondo è il risultato dell'evoluzione che il
disegno subisce durante l'implementazione (variazioni in
corso d'opera). Come al solito si riportano immancabili
esempi, consigli su come realizzarlo ecc. Il capitolo si
conclude cercando di rispondere alla fatidica domanda: "Quando
un modello a oggetti di disegno si può considerare
ben costruito?".
|
