Analisi Modelli per la specifica dei requisiti

Modelli per la specifica dei requisiti Modelli semantici dei dati Entità-Relazioni (E-R) Modelli orientati all elaborazione dati Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD) Modelli orientati alla classificazione Modelli orientati agli oggetti Modelli operazionali Automi a stati finiti Reti di Petri Modelli descrittivi Logica del primo ordine Logica temporale Ingegneria del Software L-A 2.63 Modelli per la specifica dei requisiti Obiettivo Specificare (cioè definire) le proprietà che il sistema dovrà avere senza descrivere una loro possibile realizzazione Approccio funzionale Astrae sino al massimo livello il modo di funzionare di un calcolatore Approccio orientato agli oggetti Si basa sulla stessa forma di astrazione applicata dagli uomini per affrontare la complessità del mondo Principio fondamentale: Astrazione Permette di gestire la complessità intrinseca del mondo reale Ignorare gli aspetti che non sono importanti per lo scopo attuale Concentrarsi maggiormente su quelli che lo sono Ingegneria del Software L-A 2.64 Ingegneria del Software L-A 2.1

Approccio Funzionale Tecnica della Scomposizione Funzionale Strategia: scegliere i passi ed i sotto-passi di elaborazione previsti per il sistema tipica analisi top-down L analista concentra la sua attenzione sulla modularizzazione delle procedure i moduli devono essere il più possibile indipendenti specifica le elaborazioni e le interfacce delle procedure La scomposizione in funzioni è molto volatile (a causa del continuo cambiamento dei requisiti funzionali) Ingegneria del Software L-A 2.65 Approccio Funzionale Astrazione procedurale Considerare ogni operazione come una singola entità Nonostante tale operazione sia effettivamente realizzata da un insieme di operazioni di più basso livello Ingegneria del Software L-A 2.66 Ingegneria del Software L-A 2.2

Approccio Orientato agli Oggetti Si basa sugli oggetti che sono molto più stabili delle funzioni Produce una specifica più resistente ai cambiamenti Fornisce una base efficace per L analisi del dominio Il riuso Fornisce una rappresentazione omogenea analisi progettazione programmazione in quanto si utilizzano Gli stessi principi La stessa notazione Gli stessi oggetti Ingegneria del Software L-A 2.67 Approccio Orientato agli Oggetti Astrazione dei dati Definire un tipo di dato in termini delle operazioni applicabili agli oggetti di quel tipo, con il vincolo che i valori di tali oggetti si possano modificare e osservare solo usando tali operazioni Si definiscono un insieme di attributi un insieme di operazioni (procedure) che manipolano in esclusiva tali attributi l unico modo per accedere agli attributi è tramite un operazione Gli attributi e le loro operazioni possono essere trattati come un tutto unico Ingegneria del Software L-A 2.68 Ingegneria del Software L-A 2.3

Approccio Orientato agli Oggetti Principio fondamentale: Incapsulamento Ogni tipo di dato deve rivelare il meno possibile della sua struttura interna e del suo funzionamento interno Obiettivo Minimizzare le modifiche da fare durante le fasi di sviluppo e di manutenzione Applicabile a tutti i livelli: Singoli attributi di una classe Singoli componenti del sistema Ingegneria del Software L-A 2.69 Approccio Orientato agli Oggetti Principio fondamentale: Ereditarietà Attributi e operazioni comuni devono essere specificati una volta sola Attributi e operazioni specifici vengono aggiunti e/o ridefiniti Obiettivo Semplificare la definizione e la realizzazione di tipi di dato simili Permette di esprimere esplicitamente le caratteristiche comuni, sino dalle prime attività dell analisi Ingegneria del Software L-A 2.70 Ingegneria del Software L-A 2.4

Modello dei dati del dominio del problema al fine di individuare Oggetti e classi rilevanti per il sistema da sviluppare Limitarsi esclusivamente a quelle classi che fanno parte del vocabolario del dominio del problema Relazioni tra le classi Per ogni classe Responsabilità Attributi Operazioni fondamentali cioè servizi forniti all esterno (interfaccia) Attività non strettamente sequenziali, ma reiterate sino alla produzione di un modello coerente Ingegneria del Software L-A 2.71 Modello dei dati Raggruppamento delle classi in sottosistemi Documentazione Diagrammi delle classi e dei sottosistemi Diagrammi di collaborazione tra le classi (opzionali) Per ogni classe, descrizione che ne specifica scopo, responsabilità, attributi, operazioni Per ogni attributo e ogni operazione, descrizione testuale accurata Ingegneria del Software L-A 2.72 Ingegneria del Software L-A 2.5

Notazione UML Una classe si rappresenta come un rettangolo diviso in 1 o 3 sezioni Stereotipo Nome della classe matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() Attributi Operazioni Ingegneria del Software L-A 2.73 Notazione UML matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() La prima sezione contiene Il nome della classe (in grassetto) può contenere Lo stereotipo della classe (ad esempio, controllore, attore, evento, interfaccia utente, database, ecc.) Il nome del pacchetto (package, namespace) Quizzer::Esaminando Altre proprietà della classe tra parentesi graffe ad esempio {abstract} Ingegneria del Software L-A 2.74 Ingegneria del Software L-A 2.6

Notazione UML matricola cognome nome «attore» Esaminando La seconda sezione contiene Gli attributi La terza sezione contiene Le operazioni getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.75 Notazione UML «attore» Esaminando Interfaccia IStudente IEsaminando matricola cognome nome getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.76 Ingegneria del Software L-A 2.7

Notazione UML «interface» IStudente «interface» IEsaminando getmatricola() getcognomenome() effettuaesame() matricola cognome nome «attore» Esaminando getmatricola() getcognomenome() effettuaesame() Ingegneria del Software L-A 2.77 Individuazione delle classi Due analisti non produrranno mai due modelli delle classi identici per lo stesso dominio applicativo La letteratura è ricca di approcci raccomandati per l individuazione delle classi Approccio basato sulle frasi nominali Approccio basato sulle strutture comuni Approccio guidato dai casi d uso Approccio CRC La cosa migliore è usare un approccio misto Ingegneria del Software L-A 2.78 Ingegneria del Software L-A 2.8

Individuazione delle classi Fonti principali Documento dei requisiti Altri documenti di tutti i tipi che descrivono il sistema Altre fonti Altri sistemi che funzionano nello stesso dominio o in domini analoghi Enciclopedie, nomenclature e documenti tecnici che descrivono il dominio Riutilizzare classi, gerarchie e strutture ottenute da precedenti analisi nello stesso dominio Ingegneria del Software L-A 2.79 Individuazione delle classi Il nome della classe deve Indicare al singolare un oggetto della classe Iniziare con una lettera maiuscola Essere un nome familiare All utente o All esperto del dominio del problema Non allo sviluppatore! Esempi Docente CorsoDiStudio AttivitaFormativa Ingegneria del Software L-A 2.80 Ingegneria del Software L-A 2.9

Individuazione delle classi Elencare i nomi (semplici o composti) che compaiono nei documenti raccolti, convertendoli al singolare Eliminare i nomi che sicuramente non si riferiscono a classi indicano attributi (dati di tipo primitivo) indicano operazioni Scegliere un solo termine significativo se più parole indicano lo stesso concetto (sinonimi) Ingegneria del Software L-A 2.81 Individuazione delle classi Attenzione agli aggettivi e agli attributi, possono Indicare oggetti diversi Indicare usi diversi dello stesso oggetto Essere irrilevanti Ad esempio: Studente bravo potrebbe essere irrilevante Studente fuori corso potrebbe essere una nuova classe Attenzione alle frasi passive, impersonali o con soggetti fuori dal sistema devono essere rese attive ed esplicite, perché potrebbero mascherare entità rilevanti per il sistema in esame Ingegneria del Software L-A 2.82 Ingegneria del Software L-A 2.10

Individuazione delle classi Individuare Attori con cui il sistema in esame deve interagire Persone Docente, Studente, Esaminatore, Esaminando, Sistemi esterni ReteLocale, Internet, DBMS, Dispositivi attuatori, sensori, Individuare Modelli e loro elementi specifici, cioè oggetti descrittivi e istanze specifiche Insegnamento Ingegneria del Software L-A CorsoDiStudio Ingegneria Informatica Facoltà Ingegneria Ingegneria del Software L-A 2.83 Individuazione delle classi Individuare Cose tangibili, cioè oggetti reali appartenenti al dominio del problema Banco, LavagnaLuminosa, Schermo, Computer, Individuare Contenitori (fisici o logici) di altri oggetti Facoltà, Dipartimento, Aula, SalaTerminali, ListaEsame, CommissioneDiLaurea, OrdineDegliStudi, Window, Form, Individuare Eventi o Transazioni che il sistema deve gestire e memorizzare - possono avvenire in un certo istante (ad es., una vendita) o - possono durare un intervallo di tempo (ad es., un affitto) Appello, EsameScritto, Registrazione, AppelloDiLaurea, Ingegneria del Software L-A 2.84 Ingegneria del Software L-A 2.11

Individuazione delle classi Per determinare se includere una classe nel modello, porsi le seguenti domande: Il sistema deve ricordare qualcosa sugli oggetti della classe? In caso negativo, la validità e l importanza della classe è dubbia; può anche succedere che un oggetto abbia delle operazioni, ma non abbia dati da memorizzare: per esempio, una classe che descrive un sistema esterno potrebbe avere solo operazioni per colloquiare col sistema in esame Il sistema deve interagire con gli oggetti di questa classe? Quali sono le responsabilità della classe? Ingegneria del Software L-A 2.85 Individuazione delle classi Attenzione a Oggetti con un solo attributo si può essere giunti a un livello di dettaglio troppo basso: probabilmente conviene includere l'oggetto come attributo di un altra classe Classi con un solo oggetto (singleton) Oggetti di tipo diverso con le stesse responsabilità Ingegneria del Software L-A 2.86 Ingegneria del Software L-A 2.12

Individuazione delle classi Attributi e operazioni devono essere applicabili a tutti gli oggetti della classe Se esistono Attributi con un valore ben definito solo per alcuni oggetti della classe e/o Operazioni applicabili solo ad alcuni oggetti della classe siamo in presenza di ereditarietà Esempio: dopo una prima analisi, la classe Studente potrebbe contenere un attributo booleano incorso, ma un analisi più attenta potrebbe portare alla luce la gerarchia: Studente StudenteInCorso StudenteFuoriCorso Ingegneria del Software L-A 2.87 Individuazione delle responsabilità Responsabilità di una classe Descrizione ad alto livello dello scopo per cui è stata definita la classe Vengono descritti solo i servizi disponibili pubblicamente, non quelli privati interni alla classe, la cui definizione sarebbe prematura Obiettivo aiutare nell identificazione di Classi Attributi Operazioni Relazioni tra le classi Ingegneria del Software L-A 2.88 Ingegneria del Software L-A 2.13

Individuazione delle responsabilità Principali sorgenti di informazione Documento dei requisiti Classi già identificate Cercare verbi che rappresentano azioni fatte da un oggetto del sistema Utilizzare le classi già identificate per il semplice fatto di esistere, devono avere almeno una responsabilità Annotare tutte le informazioni che gli oggetti devono mantenere e gestire Ingegneria del Software L-A 2.89 Individuazione delle responsabilità Una volta identificate, le responsabilità vanno assegnate alle classi in base ai seguenti criteri: Distribuire le responsabilità in modo bilanciato (molti oggetti che si scambiano messaggi) Assegnare le responsabilità al livello più generale possibile salendo la gerarchia delle classi Mantenere il comportamento collegato alle informazioni ad esso necessarie Ingegneria del Software L-A 2.90 Ingegneria del Software L-A 2.14

Individuazione delle responsabilità Metodo di analisi CRC (Class-Responsibility- Collaboration) di Cunningham e Beck Nome della classe Lista di responsabilità Lista di collaboratori I collaboratori sono le altre classi con le quali la classe in esame deve interagire Si utilizzano schede di cartoncino di 10x15 cm Ingegneria del Software L-A 2.91 Individuazione delle relazioni La maggior parte delle classi (degli oggetti) interagisce con altre classi (altri oggetti) in vari modi Quando si modella un sistema è necessario individuare: Non solo le entità coinvolte nel sistema Ma anche le relazione tra tali entità Una relazione (relationship) è una connessione tra entità Ingegneria del Software L-A 2.92 Ingegneria del Software L-A 2.15

Individuazione delle relazioni Nella modellazione object-oriented le relazioni più importanti sono: Ereditarietà Associazione Associazione generica Aggregazione Composizione Dipendenza Collaborazione (relazione usa) Relazione Istanza Classe Istanza di classe generica Classe generica (istanza di template template) Relazione Classe Metaclasse Ingegneria del Software L-A 2.93 Individuazione delle relazioni In ogni tipo di relazione, esiste un cliente C che dipende da un fornitore di servizi F C ha bisogno di F per lo svolgimento di alcune funzionalità che C non è in grado di effettuare autonomamente Conseguenza per il corretto funzionamento di C è indispensabile il corretto funzionamento di F Ingegneria del Software L-A 2.94 Ingegneria del Software L-A 2.16

Individuazione delle relazioni Tipo di relazione Ereditarietà Associazione Dipendenza sottoclasse classe dipendente (che usa) istanza classe Cliente contenitore superclasse contenuto classe da cui si dipende (che viene usata) classe Fornitore metaclasse Ingegneria del Software L-A 2.95 Individuazione dell ereditarietà Una classe B è in relazione EREDITA_DA con una classe A (B EREDITA_DA A), se B deriva da una modifica incrementale di A La classe B (specializzazione o sottoclasse) è simile alla classe A (generalizzazione o superclasse) e ne eredita Relazioni Attributi Operazioni AB AB Ingegneria del Software L-A 2.96 Ingegneria del Software L-A 2.17

Individuazione dell ereditarietà La ricerca delle relazioni di ereditarietà contribuisce a chiarire il significato delle varie classi e può portare alla scoperta di nuove classi Studente StudenteInCorso StudenteFuoriCorso Ingegneria del Software L-A 2.97 Individuazione dell ereditarietà L ereditarietà deve rispecchiare una tassonomia effettivamente presente nel dominio del problema Eccezione ereditarietà dell implementazione (ma siamo ancora in fase di analisi!) Non usare l ereditarietà solo per riunire caratteristiche comuni ad es., Studente e Dipartimento hanno entrambi un indirizzo, ma non per questo c è ereditarietà! Ingegneria del Software L-A 2.98 Ingegneria del Software L-A 2.18

Individuazione dell ereditarietà Ereditarietà semplice ogni classe della gerarchia ha al più una superclasse La struttura che si ottiene è sempre un albero Ereditarietà multipla almeno una classe della gerarchia ha più di una superclasse Se esistono antenati comuni ripetuti la struttura che si ottiene è un reticolo si hanno conflitti di nome la gestione può diventare molto complessa Ingegneria del Software L-A 2.99 Individuazione dell ereditarietà Tra due o più classi di una gerarchia possono esistere dei vincoli {overlapping} o {disjoin} Veicolo {overlapping} {disjoint} VeicoloTerrestre VeicoloAcquatico VeicoloMilitare VeicoloCivile CarroArmato Taxi Corazzata BarcaAVela Un reticolo di veicoli Ingegneria del Software L-A 2.100 Ingegneria del Software L-A 2.19

Individuazione dell ereditarietà Veicolo OggettoMilitare OggettoCivile VeicoloTerrestre VeicoloAcquatico CarroArmato Taxi Corazzata BarcaAVela Una gerarchia multipla di veicoli, senza antenati ripetuti Ingegneria del Software L-A 2.101 Individuazione delle associazioni Un associazione rappresenta una relazione strutturale tra due istanze di classi diverse o della stessa classe Un associazione può Rappresentare un contenimento logico (aggregazione) Una lista d esame contiene degli studenti Rappresentare un contenimento fisico (composizione) Un triangolo contiene tre vertici Non rappresentare un reale contenimento Una fattura si riferisce a un cliente Un evento è legato a un dispositivo Ingegneria del Software L-A 2.102 Ingegneria del Software L-A 2.20

Individuazione delle associazioni Aggregazione Un oggetto x di classe X è associato a (contiene) un oggetto y di classe Y in modo non esclusivo x può condividere y con altri oggetti anche di tipo diverso (che a loro volta possono contenere y) Una lista d esame contiene degli studenti Uno studente può essere contemporaneamente in più liste d esame La cancellazione della lista d esame non comporta l eliminazione fisica degli studenti in lista Ingegneria del Software L-A 2.103 Individuazione delle associazioni Composizione Un oggetto x di classe X è associato a (contiene) un oggetto y di classe Y in modo esclusivo y esiste solo in quanto contenuto in x Un triangolo contiene tre punti (i suoi vertici) L eliminazione del triangolo comporta l eliminazione dei tre punti Se la distruzione del contenitore comporta la distruzione degli oggetti contenuti, si tratta di composizione, altrimenti si tratta di aggregazione Ingegneria del Software L-A 2.104 Ingegneria del Software L-A 2.21

Individuazione delle associazioni In UML La composizione è indicata con un rombo nero dalla parte del contenitore L aggregazione è indicata con un rombo bianco dalla parte del contenitore Ad ogni associazione è possibile aggiungere: Un nome (e una direzione di lettura del nome) I ruoli delle classi coinvolte La cardinalità, cioè il numero di oggetti che possono partecipare all'associazione Il contenimento (aggregazione o composizione) Ingegneria del Software L-A 2.105 matrimonio Società nome indirizzo 1 lavora-per * datore-lavoro impiegato marito Persona nome indirizzo codicefiscale datanascita sottoposto 0..1 0..1 moglie * dirigente 0..1 dirige Poligono 1 contiene {ordered} 3..* Punto Questo è un commento associato alla classe Poligono. Finestra 1 1 1..* 1 BarraTitolo Pannello Bordo 1 1 Etichetta 1 Pulsante Chiusura Vari tipi di associazione. Ingegneria del Software L-A 2.106 Ingegneria del Software L-A 2.22

Individuazione delle associazioni Per individuare potenziali aggregazioni o composizioni, considerare Insieme-PartiComponenti Contenitore-Contenuto Collezione-Membri Se contenitore e contenuto hanno un legame forte e uno stesso ciclo di vita, si tratta di composizione altrimenti, si tratta di aggregazione Ingegneria del Software L-A 2.107 Individuazione delle associazioni Per individuare potenziali associazioni generiche, per ogni oggetto, porsi le domande A quali altri oggetti è collegato nel dominio del problema? Da chi deve ottenere informazioni per soddisfare alle sue responsabilità? Ingegneria del Software L-A 2.108 Ingegneria del Software L-A 2.23

Individuazione delle associazioni Una volta determinata la presenza di un associazione Tracciare la linea di connessione, eventualmente col simbolo di aggregazione o composizione dalla parte del contenitore Se possibile, dare un nome all associazione e ai due ruoli, scegliendolo tra i termini del dominio del problema Definire il valore, l intervallo o l insieme di valori e/o intervalli del limite inferiore la connessione è opzionale? il limite inferiore è 0 la connessione è obbligatoria? il limite inferiore è1 limite superiore la connessione è singola? il limite superiore è 1 la connessione è multipla? il limite superiore è > 1 Ingegneria del Software L-A 2.109 Individuazione delle associazioni Cardinalità Simbolo Significato Esempi n valore singolo 1 * da 0 a * n..m n,m intervallo insieme di valori e/o intervalli 0..1 1..* 1,3..5,7 Ingegneria del Software L-A 2.110 Ingegneria del Software L-A 2.24

Individuazione delle associazioni Attenzione alle associazioni molti a molti possono nascondere una classe (classe di associazione) del tipo evento da ricordare Esempio: la connessione proprietà tra Proprietario e Veicolo nasconde una classe CompraVendita, che lega Proprietari e Veicoli Esempio: la connessione matrimonio tra Persona e Persona nasconde una classe Matrimonio, che lega due Persone Ingegneria del Software L-A 2.111 Individuazione delle associazioni 1 esempio Un proprietario può possedere molti veicoli Proprietario possiede 1..* * 1..* * Veicolo Un veicolo può essere di molti proprietari in tempi successivi Proprietario 1..* * 1..* * Veicolo in comproprietà CompraVendita -dataacquisto Legame 1 a 1 Ingegneria del Software L-A 2.112 Ingegneria del Software L-A 2.25

Individuazione delle associazioni 1 esempio Un proprietario può partecipare a più compravendite Proprietario 1..* * 1..* * CompraVendita -dataacquisto Veicolo Un veicolo può essere contemporaneamente di più proprietari Una compravendita è relativa a un solo veicolo Proprietario 1..* partecipa a 1..* CompraVendita -dataacquisto 1..* Veicolo 1 acquisto di Ingegneria del Software L-A 2.113 Individuazione delle associazioni Persona * * matrimonio Relazione n-m (matrimonio) tra due oggetti della stessa classe. Persona 1 1 marito moglie * * Matrimonio data Un Matrimonio è in effetti una classe, con due associazioni con oggetti di tipo Persona (marito e moglie). Ingegneria del Software L-A 2.114 Ingegneria del Software L-A 2.26

Individuazione delle collaborazioni Una classe A è in relazione USA con una classe B (A USA B) quando A ha bisogno della collaborazione di B per lo svolgimento di alcune funzionalità che A non è in grado di effettuare autonomamente Un operazione della classe A ha bisogno come argomento di un istanza della classe B void fun1(b b) { usa b } Un operazione della classe A restituisce un valore di tipo B B fun2() { B b; return b; } Un operazione della classe A utilizza un istanza della classe B (ma non esiste un associazione tra le due classi) void fun3() { B b = new B(); usa b } Ingegneria del Software L-A 2.115 Individuazione delle collaborazioni La relazione non è simmetrica A dipende da B, ma B non dipende da A Evitare situazioni in cui una classe, tramite una catena di relazioni USA, alla fine dipende da se stessa Cliente Fornitore Cliente Nome Interfaccia Fornitore Ingegneria del Software L-A 2.116 Ingegneria del Software L-A 2.27

Eredità e composizione Una classe potrebbe aver bisogno di utilizzare le risorse di un altra classe Ad esempio, la classe Finestra ha bisogno della classe Rettangolo per memorizzare posizione e dimensione fare calcoli di sovrapposizione con altre finestre... Esistono due possibili soluzioni Ingegneria del Software L-A 2.117 Eredità e composizione 1. Rendere Finestra sottoclasse di Rettangolo Una Finestra eredita e quindi ha accesso diretto a dati e operazioni di un Rettangolo 2. Inserire un Rettangolo entro la struttura dati di una Finestra: una Finestra contiene un Rettangolo Una Finestra ha accesso indiretto alle operazioni pubbliche di un Rettangolo Rettangolo Finestra Ereditarietà Finestra 0..1 1 Rettangolo Composizione Ingegneria del Software L-A 2.118 Ingegneria del Software L-A 2.28

Eredità e composizione Nel primo caso (ereditarietà) La definizione avviene staticamente (compile-time) L implementazione della sottoclasse è facile da modificare, può definire i propri metodi e continuare a usare quelli della superclasse La superclasse definisce parte della rappresentazione fisica della sottoclasse, legando a sé la sottoclasse, rompendo l incapsulamento e rendendo più difficile il riuso della sottoclasse Ingegneria del Software L-A 2.119 Eredità e composizione Nel secondo caso (composizione) La definizione può avvenire dinamicamente (run-time) Le interfacce delle due classi restano indipendenti Quindi Usare l ereditarietà solo se rispecchia il dominio del problema Altrimenti, preferire la composizione Ingegneria del Software L-A 2.120 Ingegneria del Software L-A 2.29