Una delle maggiori difficoltà è “tradurre” i requisiti software in un progetto di sistema implementabile.
Obiettivo della fase successiva all’analisi dei requisiti è di iniziare ad individuare le classi, il loro comportamento dinamico, e le relazioni che vi intercorrono.
Obiettivo della lezione:
E’ composto da tre modelli:
Gli use case prodotti nella fase di raccolta dei requisiti vengono raffinati per derivare il Modello di Dominio e il Modello Dinamico, primo passo per la successiva Progettazione del sistema.
E’ il più importante modello della fase di Specifica dei Requisiti
E’ una rappresentazione visuale di classi concettuali, relative al dominio del problema.
Si esprime attraverso un class diagram, con classi, attributi e operazioni.
Si focalizza sui concetti che sono manipolati dal sistema, le loro proprietà e le relazioni
E’ un dizionario visuale dei concetti principali relativi al dominio.
E’ detto anche Modello a Oggetti di Analisi.
E’ una rappresentazione di oggetti del mondo reale in uno specifico dominio, NON di oggetti software
NB: sia il modello dinamico che il modello ad oggetti rappresentano concetti a livello utente, non a livello di componenti e classi software
Le classi di analisi rappresentano astrazioni che saranno dettagliate e/o raffinate successivamente.
Si focalizza sul comportamento del sistema:
Consente di assegnare le responsabilità alle classi e quindi individuare nuove classi che sono aggiunte al modello ad oggetti di analisi, in un procedimento iterativo.
Le attività che consentono di trasformare gli use case e gli scenari della raccolta dei requisiti in un modello di analisi sono:
Queste attività sono guidate da euristiche.
La qualità dei risultati dipende dall’esperienza degli sviluppatori nell’applicare le euristiche e i metodi.
La fase fondamentale dello sviluppo del software OO è quella dell’analisi (OOA Object Oriented Analysis) e della progettazione (OOD Object Oriented Design), perchè sono queste fasi che garantiscono il successo e il raggiungimento degli obiettivi dell’OOP.
L’idea di massima è di analizzare la descrizione di ogni caso d’uso, individuando le classi candidate, cioè concetti che molto probabilmente saranno mappati in classi nella fase implementativa.
E’ un procedimento altamente creativo e soggettivo.
Sono possibili svariate soluzioni per uno stesso problema.
Può essere guidato dall’euristica Three-Object-Type → Classificazione Oggetti in Entity, Boundary e Controllo
Secondo tale euristica, il modello ad oggetti di analisi classifica gli oggetti in Entity, Boundary e Control.
L’approccio three-object-type porta a modelli che sono più flessibili e facili da modificare.
L’interfaccia al sistema (rappresentata da oggetti boundary) è più soggetta a cambiamenti rispetto alle funzionalità (rappresentate da oggetti entity e control).
UML fornisce il meccanismo degli stereotipi per consentire di aggiungere tale meta-informazione agli elementi di modellazione.
E’ opportuno usare convenzioni sui nomi:
Gli oggetti control possono avere il suffisso Control;
Gli oggetti boundary dovrebbero avere nomi che ricordano aspetti dell’interfaccia (es. suffisso Form, Button, ecc).
Gli oggetti Boundary rappresentano l’interfaccia del sistema con gli attori:
Gli oggetti Boundary modellano l’interfaccia senza descriverne gli aspetti visuali!
Linee guida per l’identificazione:
Un esempio di identificazione di oggetti, sul caso d'uso ReportEmergency, in cui un FieldOfficer può segnalare sul suo terminale mobile un' emergenza.
Dall’esame dello use case ReportEmergency, dalla conoscenza del dominio e dalle interviste al cliente è possibile identificare i seguenti oggetti
Si noti che EmergencyReport non è nominato esplicitamente nello use case:
Gli oggetti Control sono responsabili del coordinamento degli oggetti Boundary e Entity.
Si preoccupano di collezionare informazioni dagli oggetti Boundary e inviarle agli oggetti Entity.
Di solito non hanno una controparte nel mondo reale: modellano la logica di funzionamento di un caso d’uso.
Esiste una stretta relazione tra oggetti Control e use case: un oggetto Control è creato all’inizio dello use case e cessa di esistere alla fine.
Linee Guida:
Il flusso di controllo dello use case ReportEmergency viene modellato con due oggetti Control:
Tale decisione deriva dalla consapevolezza che FieldOfficerStation e DispatcherStation sono due sottosistemi che comunicano su un link asincrono.
Questa decisione potrebbe essere rimandata all’attività di design, comunque renderla visibile in fase di analisi consente di focalizzare l’attenzione su comportamenti eccezionali, come la perdita di comunicazione tra due stazioni.
Nel modellare lo use case ReportEmergency sono state modellate le stesse funzionalità usando oggetti Boundary, Entity e Control.
Lo use case ReportEmergency è incompleto: menziona l’esistenza di una notifica ma non descrive l’informazione ad essa associata.
C’è necessità di chiarire con il cliente → l’oggetto Acknowledgment è aggiunto al modello di analisi e lo use case è raffinato.
L’oggetto Acknowlegment è creato prima dell’oggetto Boundary AcknowldegmentNotice.
Durante l’analisi i Sequence Diagram sono usati per individuare:
Disegnare Sequence Diagram è un’attività laboriosa, quindi:
In generale sarebbe da disegnare un Sequence Diagram per ogni Caso d’Uso significativo.
Usare diversi Sequence Diagrams per rappresentare diversi scenari di un Caso d’Uso.
I risultati della raccolta dei requisiti e dell’analisi sono documentati nel Documento dei Requisiti Software (o DRS).
Il DRS descrive completamente il sistema in termini di requisiti funzionali e non funzionali e serve come base del contratto tra cliente e sviluppatori.
I partecipanti coinvolti sono: cliente, utenti, project manager, analisti del sistema, progettisti.
La prima parte del documento, che include Use Case e requisiti non funzionali, è scritto durante la raccolta dei requisiti.
La formalizzazione della specifica in termini di modelli degli oggetti è scritto durante l’analisi.
1. Introduction
1.1. Purpose of the system
1.2. Scope of the system
1.3. Objectives and success criteria of the project
1.4. Definition, acronyms, and abbreviations
1.5. References
1.6. Overview
2. Current system
3. Proposed system
3.1. Overview
3.2. Functional requirements
3.3. Nonfunctional requirements
3.4. System models
3.4.1. Scenarios
3.4.2. Use case model
3.4.3. Object model (during analysis)
3.4.4. Dynamic model (during analysis)
3.4.5. User interface – navigational path and screen mock-up
4. Glossary
1. Introduzione all'Ingegneria del Software – La qualità del Software
2. Il Ciclo di vita del Software: i modelli di Processo
3. Concetti e strumenti di base per il Project Management
5. Introduzione ad UML: Gli Use Case Diagrams
6. Il documento dei Requisiti Software
7. UML: I Sequence Diagrams ed i Class Diagrams