Concludiamo qui, con quest'articolo, questo percorso che ci ha portato alla scoperta della modellazione UML, in particolar modo per quanto concerne la fase di analisi di un sistema software, parlando di un tipo di diagrammi molto importanti, i diagrammi di attività.

Dopo un lungo percorso siamo finalmente vicini alle fasi finali di quella che è l'analisi di un progetto software. In questo penultimo articolo affronteremo la realizzazione dei casi d'uso, ovvero la dimostrazione di come l'interazione tra le classi modellate implementi il comportamento descritto in precedenza dal caso d'uso.

Dopo aver fornito una visione panoramica su ciò che concerne le relazioni tra classi e tra oggetti, tentiamo di andare avanti parlando quindi di package d'analisi, ovvero quelle entità definite nell'UML utili a raggruppare logicamente altri elementi i quali condividono un valore semantico.

Nel precedente articolo abbiamo esplorato cosa siano le classi di analisi, quale il loro scopo e quali i modi per individuarle. Ora si necessita di un ulteriore approfondimento attorno a ciò che lega gli elementi di un sistema, ovvero relazioni per le classi e collegamenti per gli oggetti.

Nel precedente articolo abbiamo affrontato il concetto di “classe” e “oggetto” e ne abbiamo osservato la rappresentazione nei diagrammi UML. Con quest'articolo ci avvicineremo invece ad una delle prime attività proprie della fase di analisi: l'identificazione delle classi di analisi.

Cominciamo ora ad entrare nel vivo della modellazione. Fino a questo momento abbiamo affrontato la parte riguardante la raccolta dei requisiti e la definizione delle facoltà future del sistema, preludio della fase più interessante e più delicata dell'intero processo di sviluppo del software: l'analisi. Ma prima di questa rinfreschiamoci le idee su cosa sia una “classe” e un “oggetto”, e prendiamo familiarità con le relative rappresentazioni nei diagrammi UML.

Dopo aver introdotto i casi d'uso e come questi servano a descrivere un sistema software, passeremo in rassegna alcune tecniche avanzate della modellazione dei casi d'uso, più o meno utili, e riepilogheremo un pò il tutto.

Dopo la raccolta dei requisiti è ora di cominciare a definire in maggior dettaglio cosa il sistema sarà in grado di fare. Il primo passo in questa direzione è la creazione del modello dei casi d'uso, sempre che sia applicabile per il progetto in questione. Vediamo assieme cosa significa.

Nella prima puntata mi sono occupato di descrivere sommariamente l'UML nelle sue componenti principali. Vorrei ora continuare con questo articolo per introdurre l'Unified Process, ovvero una metodologia per la progettazione di sistemi software, che va affiancata all'UML per gestirne l'esecuzione nell'analisi e nella progettazione object oriented.

L'UML è un linguaggio di modellazione che si è molto affermato negli ultimi anni. Nato come linguaggio ad uso generico è già sulla strada per il rilascio delle specifiche a versione 2, ma, grazie alla sua completezza, è stato fin da subito adottato nella modellazione di sistemi software Object Oriented. In questa serie di articoli, cercherò di descrivere le componenti dell'UML, e cercherò di spiegare come usarle nelle fasi di raccolta dei requisiti (in cui c'è poco di UML) e di analisi. Seguendo le mie personali necessità professionali andrò a selezionare, dagli studi che ho effettuato ultimamente, le sole componenti tra UML e Unified Process (UP) che mi sono state più utili nel mio lavoro quotidiano.