Torna alla pagina di Ingegneria del Software
:: Ingegneria del Software - Appunti del 30 Marzo 2009 ::
Consideriamo come caso di studio il sistema informativo di una biblioteca.
A quali esigenze dovrà rispondere il software che lo gestisce? Con quali entità dovrà avere a che fare?
Proviamo a redarne un primo caso d'uso:
Facendo riferimento ai numeri cerchiati, osserveremo che:
Notare che in questo caso d'uso l'utente non è solo fruitore dei servizi, ma è anche oggetto di attenzione del sistema dal momento che andrà gestita anche la sua anagrafica.
Sono possibili dei raffinamenti a questo caso d'uso? Certamente:
I raffinamenti potrebbero andare avanti ancora un bel po', ed è compito dell' analista tradurre i requisiti in informazioni ed altri vincoli da passare al designer (o progettista). Questi persegue la separazione delle responsabilità: l' interfaccia deve essere distinta dalla logica, che deve a sua volta essere distinta dalla gestione della persistenza (in genere un database). Questi sono i tre componenti essenziali che costituiscono un software, e che applicati al nostro caso di studio devono essere interpretati come:
Facciamo uno schema:
Alcune osservazioni:
Questo schema è solo una bozza di un diagramma di collaborazione, che nella sua versione definitiva dovrà mostrare le interazioni che avvengono tra gli oggetti che partecipano a una situazione specifica. Consideriamo come situazione l'inserimento di un utente nel sistema e chiediamoci quali sono i componenti coinvolti:
Rappresentiamo il tutto in un diagramma di collaborazione, in cui i messaggi inviati da un componente all'altro sono rappresentati da frecce con etichette che ne spiegano la funzione (nome, parametri, sequenza del messaggio).
Dal diagramma di collaborazione possiamo agilmente ricavare il diagramma di sequenza, che mostra come avviene lo scambio di messaggi tra componenti enfatizzandone l'aspetto temporale. Nei diagrammi di sequenza gli oggetti sono rappresentati con linee verticali tratteggiate, con il nome del componente in cima. Anche l'asse temporale è verticale, e per convenzione aumenta muovendoci verso il basso.
Il designer può semplificare ulteriormente il lavoro dello sviluppatore fornendogli, oltre ai due diagrammi che abbiamo visto e ai casi d'uso, l'insieme delle chiamate (quindi dei servizi richiesti) che devono essere gestite da ogni componente, suddivise per componente stesso. In questo modo si va a formare il cosiddetto diagramma di classe, che gode di una grammatica molto ricca ed è uno strumento rappresentativo molto potente per lo sviluppatore. Mostriamo ad esempio parte del diagramma di classe del gestore di anagrafica utente:
Notare che per passare dal diagramma di collaborazione (o di sequenza) a quello di classe è sufficiente trascrivere tutti quei metodi che hanno frecce entranti nel componente, escludendo beninteso quelle di risposta.
Concludiamo la lezione citando un altro tipo di documentazione utile, ovvero i casi di test, che a fronte dell'inserimento di un certo input mostrano i vari output attesi. Più che per il designer, queste informazioni sono utilissime per lo sviluppatore e per gli operatori che fanno da tester.