Sergio Di Martino » 8.La Specifica dei Requisiti

Obiettivi della Lezione

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:

• Definire i Modelli di Dominio
• Identificazione degli oggetti
• Definizione del comportamento degli oggetti
• Definizione delle relazioni tra gli oggetti
• Classificazione degli oggetti
• Organizzazione degli oggetti

Software Lifecycle Activities

Il Documento di Specifica dei Requisiti

E’ composto da tre modelli:

1. Modello Funzionale, rappresentato da use cases (già visti nelle scorse lezioni). Possibile contratto col cliente, è scritto per i “profani”;
2. Modello di Dominio, rappresentato dal diagramma delle classi;
3. Modello Dinamico, rappresentato da statechart e sequence diagram.

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.

Il modello di Dominio

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.

Il modello dinamico

Si focalizza sul comportamento del sistema:

• I sequence diagram rappresentano le interazioni tra un insieme di oggetti durante un singolo use case;
• Gli statechart rappresentano il comportamento di un singolo oggetto o di alcuni oggetti strettamente accoppiati.

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.

Attività di Analisi: dagli use case agli oggetti

Le attività che consentono di trasformare gli use case e gli scenari della raccolta dei requisiti in un modello di analisi sono:

1. Identificare gli Oggetti Entity, Boundary e Control;
2. Mappare gli Use Case in Oggetti con Sequence Diagrams;
3. Identificare le Associazioni;
4. Identificare gli Attributi;
5. Modellare il Comportamento dipendente dallo stato degli Oggetti individuali;
6. Modellare le Relazioni di Ereditarietà;
7. Rivedere il Modello di Analisi.

Queste attività sono guidate da euristiche.
La qualità dei risultati dipende dall’esperienza degli sviluppatori nell’applicare le euristiche e i metodi.

Identificazione degli oggetti

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

Euristica three-object-type

Secondo tale euristica, il modello ad oggetti di analisi classifica gli oggetti in Entity, Boundary e Control.

• Gli oggetti Entity rappresentano i concetti del dominio che sono persistenti
  • Sono concettualmente simili alle entità che si identificano nella progettazione di un database
  • Es: Biglietti, Clienti, Prenotazioni, etc…
• Gli oggetti Boundary sono responsabili di gestire le interazioni tra tutti gli attori e il sistema
  • Es: Form, bottoni, Report, etc…
• Gli oggetti Control modellano la logica che si occupa di realizzare gli use case
  • In genere uno per caso d’uso

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).

Identificare gli Oggetti Boundary

Gli oggetti Boundary rappresentano l’interfaccia del sistema con gli attori:

• In ogni use case, ogni attore (sia esso umano o modulo software già esistente) interagisce almeno con un oggetto Boundary;
• Gli oggetti Boundary collezionano informazioni dall’attore e le traducono in una forma (invocazione di metodi) che può essere usata sia dagli oggetti Control che dagli oggetti Entity;
• Gli oggetti Boundary mostrano informazioni in output agli attori.

Gli oggetti Boundary modellano l’interfaccia senza descriverne gli aspetti visuali!

• Non ha senso parlare di “item di menu” o “scroll bar”.
• Lo sviluppo dell’interfaccia è solitamente di tipo prototipale, e iterativo.

Linee guida per l’identificazione:

• Identificare i controlli della UI di cui l’utente ha bisogno per iniziare lo use case
• Identificare form di cui l’utente ha bisogno per inserire dati nel sistema
• Identificare avvisi e messaggi che il sistema usa per rispondere all’utente
• Non modellare aspetti visuali della UI con oggetti Boundary (meglio i mock-up)
• Usare sempre i termini dell’utente finale per descrivere l’interfaccia, non usare termini del dominio di implementazione

Esempio: ReportEmergency

Un esempio di identificazione di oggetti, sul caso d'uso ReportEmergency, in cui un FieldOfficer può segnalare sul suo terminale mobile un' emergenza.

Identificazione degli Oggetti Entity

Dall’esame dello use case ReportEmergency, dalla conoscenza del dominio e dalle interviste al cliente è possibile identificare i seguenti oggetti

• Dispatcher;
• FieldOfficer;
• Incident;
• EmergencyReport.

Si noti che EmergencyReport non è nominato esplicitamente nello use case:

• nel passo 4 (Classificazione degli oggetti) si nomina “informazione sottomessa dal FieldOfficer”;
• e dal colloquio con il cliente si deduce che è proprio ciò che solitamente è detto “emergency report”.

Identificazione degli Oggetti Entity

Identificazione degli Oggetti Boundary

Identificare gli Oggetti Control

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:

• Identificare almeno un oggetto Control per ogni use case;
• La vita di un oggetto Control dovrebbe corrispondere alla durata di uno use case o di una sessione utente.
  • Se è difficile identificare l’inizio e la fine dell’attivazione di un oggetto Control, il corrispondente use case probabilmente non ha delle entry e exit condition ben definite.

Identificare gli Oggetti Control

Il flusso di controllo dello use case ReportEmergency viene modellato con due oggetti Control:

• ReportEmergencyControl per FieldOfficer;
• ManageEmergencyControl per Dispatcher.

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.

• Si è passati da una prospettica “flusso di eventi” ad una “strutturale”.
• È aumentato il livello di dettaglio della descrizione.
• Sono stati selezionati termini standard per riferirci alle entità principali del dominio di applicazione e del sistema.

Analisi e Sequence Diagram

Durante l’analisi i Sequence Diagram sono usati per individuare:

1. nuovi oggetti;
2. comportamenti mancanti.

Disegnare Sequence Diagram è un’attività laboriosa, quindi:

• Occorre dare priorità a quelle funzionalità problematiche o non ben specificate
• Per le parti ben definite può essere utile solo per evitare di posticipare alcune decisioni chiavi

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.

Documento dei Requisiti Software

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.

Documento dei Requisiti Software

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

Documento dei Requisiti Software

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