Diagramma di sequenza

I diagrammi di sequenza sono diagrammi dinamici e descrivono come gli oggetti collaborano tra loro. Hanno lo scopo di definire le interazioni tra gli oggetti in funzione del tempo. Il tempo viene rappresentato come evoluzione lungo l’asse verticale, gli oggetti come rettangoli ed i messaggi con delle frecce. Rappresenta come gli oggetti si scambiano i messaggi. Sull’asse orizzontale vengono rappresentati gli oggetti, da essi parte una linea verticale (lifeline, linea di evoluzione) che diventa un rettangolo nei periodi in cui l’oggetto è attivo. L’attivazione inizia alla ricezione di un messaggio.

Figura 47 Scambio di messaggi e attivazione

CAPITOLO 5 UNIFIED MODELING LANGUAGE

metodo dell'oggetto ricevente. La coordinata verticale del messaggio è legata all'asse del tempo. I messaggi possono essere:

• Ricorsivi un oggetto manda un messaggio a se stesso, è rappresentato da una freccia che inizia e finisce sulla lifeline dello stesso oggetto.

• Simple rappresenta il passaggio di controllo da un oggetto all’altro, rappresentato da una freccia

• Sincroni il mittente del messaggio deve ottenere una risposta dal destinatario del suo messaggio prima di proseguire con altre azioni. Si rappresenta con una freccia con punta a triangolo pieno.

• Asincroni il mittente non deve aspettare alcuna risposta dal destinatario prima di proseguire con le successive operazioni. Un messaggio asincrono può creare un nuovo thread, creare un nuovo oggetto, inviare un messaggio.

Un messaggio è caratterizzato da una condizione, indicata tra parentesi quadre, e da un iteration marker che indica quante volte viene spedito. La return di un messaggio, che non è un nuovo messaggio, dal destinatario al mittente è rappresentata con una freccia a linea tratteggiata. È possibile inserire nel diagramma, in alto a destra tra parentesi graffe, del testo che indica una condizione temporale. Questa corrisponde a un vincolo che esprime l'intervallo di tempo all'interno del quale gli oggetti dello schema continuano ad inviarsi messaggi secondo la sequenza indicata. Se un oggetto attivo manda un messaggio a se stesso si crea un altro rettangolo di attivazione centrato sul lato destro del rettangolo di attivazione che era già in atto. All'interno di un diagramma di sequenza è possibile creare un oggetto, che viene posizionato nella posizione verticale corrispondente al momento della sua creazione. Viene rappresentato con un rettangolo all'altezza (al tempo) in cui viene creato. Un oggetto che crea un altro oggetto invia un messaggio rappresentato da un linea punteggiata con la scritta create o new tra doppi apici la cui freccia punta al nuovo oggetto. La cancellazione di un oggetto si disegna con una X che interrompe la sua lifeline. Un oggetto può autocancellarsi o può cancellarsi dopo aver ricevuto un dato messaggio. Un modo per sfruttare questi diagrammi è quello di farne uno per ogni scenario di un caso d’uso. Può essere comodo inserire alla sinistra dello schema del testo per spiegare cosa sta succedendo.

CAPITOLO 5 UNIFIED MODELING LANGUAGE

5.3.1.11 Diagramma di Comunicazione

I diagrammi di comunicazione sono un tipo speciale di diagramma di interazione, enfatizzano lo scambio di dati tra oggetti. Sono facili da disegnare quindi possono essere usati durante le riunioni per discutere diverse alternative di progetto. Permette di disegnare i partecipanti, in qualsiasi posizione aggiungendo collegamenti per mostrare le connessioni. La sequenza temporale delle connessioni è espressa tramite la numerazione dei messaggi. In UML 1.x erano chiamati diagrammi di collaborazione. Nel diagramma è possibile includere collegamenti temporanei, che esistono solo per la durata dell’interazione. Un collegamento temporale può essere «local» «parameter» e «global». Queste parole chiave erano previste in UML 1 ma nella nuova versione non lo sono più. Per la numerazione dei messaggi si deve usare, per rispettare lo standard, un sistema decimale nidificato per risolvere l’ambiguità nella sequenza delle chiamate in presenza di auto-collegamenti di un oggetto a se stesso. I messaggi possono essere etichettati anche con delle lettere per specificare che appartengono a diversi thread di controllo. I messaggi A5 e B2 appartengono a thread diversi; i messaggi 1a1 e 1b1 corrispondono a thread differenti in esecuzione parallela all’interno del messaggio 1. I diagrammi di comunicazione non definiscono una notazione per esprimere la logica di controllo, si possono usare indicatori di iterazione e guardie, ma non sono sufficienti a specificare completamente la logica. Manca una notazione speciale per la creazione/distruzione di oggetti, ma si possono usare le parole chiave «create» «delete».

5.3.1.12 Diagramma di Interazione

I diagrammi di interazione generale sono una specie di fusione dei diagrammi di attività e di quelli di sequenza introdotti in UML 2. Si possono considerare come dei diagrammi delle attività in cui ogni azione è rimpiazzata da un piccolo diagramma di sequenza, o come diagrammi di sequenza spezzati con la notazione delle attività in modo da mostrare il flusso di controllo. Sono una novità di UML 2

CAPITOLO 5 UNIFIED MODELING LANGUAGE

Figura 48 Esempio di Diagramma delle interazioni

5.3.1.13 Diagramma di Temporizzazione

I diagrammi di temporizzazione sono stati introdotti in UML 2. Sono una forma di diagrammi di interazione, dedicata all’espressione di vincoli temporali: si possono applicare a un oggetto singolo o ad un intero gruppo di oggetti. Sono utili per indicare i vincoli temporali tra i cambiamenti di stato di oggetti differenti.

CAPITOLO 5 UNIFIED MODELING LANGUAGE

CAPITOLO 6 CONCLUSIONI

Capitolo 6 Conclusioni

Considerazioni, esempi e prospettive dell’utilizzo dello UML nell’automazione. Per la trattazione del capitolo sono stati usati i riferimenti [2], [3].

6.1

Sistemi di Automazione

La progettazione del software di automazione è un compito complesso. Oltre a coinvolgere esperti in vari campi (informatica, matematica, elettronica, meccanica, ecc…) e quindi con comunicazione critica, un tipico sistema di automazione è composto da una parte di interfacciamento, una parte di controllo e la macchina da automatizzare. Inoltre sono, in generale, sistemi real-time, costituiti da dispositivi embedded, complessi e distribuiti. Le nove tecnologie di base consentono, infatti, di avere a disposizione dispositivi e sistemi miniaturizzati con potenti unità di calcolo, che consentono di avere una

automazione basata su componenti. In questa ottica è importante avere uno strumento come lo UML, che oltre ad essere diventato uno standard de-facto, e quindi facilita la comunicazione tra i vari partecipanti allo sviluppo, consente di avere una vista olistica del sistema. In questo modo è possibile valutare varie soluzioni, scegliere la migliore e specificare ogni componente separatamente, sviluppando un progetto armonizzato.

6.1.1 Applicazioni

Nell’industria del software real-time i progetti sono sviluppati secondo l’approccio iterativo ed è, sempre più comune, l’uso dei metodi Object-Oriented (OO).

CAPITOLO 6 CONCLUSIONI

Figura 50 Fasi del modello incrementale per un progetto real-time

Il processo iterativo è suddiviso in fasi, poi raffinate a livelli successivi:

• Specifica dei requisiti: vengono specificati e documentati un insieme di requisiti necessari per la costruzione del sistema.

• Sviluppo del sistema: il sistema è costruito in vari passi seguendo le specifiche precedenti.

• Messa in opera del sistema: comprende l’attività di manutenzione e l’uso giorno dopo giorno.

Il maggior problema è come implementare i requisiti con le classi e come modificarli se cambiano, o nascono nuovi, durante lo sviluppo del sistema.

Per definire i requisiti il sistema può essere visto come una scatola nera.

Prima di tutto dobbiamo individuare ed avere chiaro l’ambiente in cui opera il sistema: cosa è esterno e cosa è interno ad esso. Gli elementi esterni al sistema possono essere, persone, quali operatori manutentori; altri sistemi oppure possono essere oggetti astratti come il tempo. Tutte queste entità vengono definite attori. È importante, anche definire le interfacce ed i sottosistemi che sono usati dagli attori per interagire con il sistema stesso. Questi elementi definiscono il contesto del sistema e possono essere modellati con il diagramma di contesto.

CAPITOLO 6 CONCLUSIONI

Figura 51 Context Diagram

Una volta individuato il contesto in cui opera il sistema si passa all’analisi dei requisiti funzionali, che può essere fatta attraverso i casi d’uso. Lo scopo è quello di definire gli obiettivi dei vari attori ed i passi da eseguire per raggiungerli.

CAPITOLO 6 CONCLUSIONI

Figura 52 Diagramma dei Casi d’uso

Una volta definite le funzionalità del sistema, devono essere prese decisioni su quali devono essere implementate per prime. Ci sono vari criteri in base ai quali vengono fatte queste scelte:

• Secondo i requisiti utente : i casi d’uso vengono discussi con i committenti, che specificheranno quali sono i più importanti ed i prioritari. In modo che siano verificati prima di procedere nell’implementazione di quelli secondari.

• Secondo la complessità delle funzioni: i casi d’uso più complessi devono essere sviluppati per ultimi in quanto richiedono la maggior parte del tempo di sviluppo ed anche per la loro verifica ci vuole più tempo. Saranno

CAPITOLO 6 CONCLUSIONI

• Secondo vincoli impliciti: ci sono alcuni casi d’uso che devono essere logicamente implementati prima di altri; per esempio il caso d’uso che riporta i resoconti sui dati del sistema deve essere implementato dopo il caso d’uso che genera i dati del sistema.

• Secondo la gestione dei rischi: la scelta delle tecnologie, delle piattaforme, del sistema operativo, delle prestazioni devono essere fatte per prime, in modo da assicurare che tutti i problemi siano risolti prima di passare all’implementazione del sistema.

Seguendo questi criteri viene redatto il piano di sviluppo dei casi d’uso: indicando quale è il precedente; quante ore o giorni richiede la sua implementazione; quali e quante risorse occupa, e quale deve precedere.

Figura 53 Piano dei rilasci dei casi d’uso

In parallelo alla definizione dei casi d’uso vanno definite le aree di responsabilità. Queste possono essere usate per assegnare i processi ai gruppi di lavoro individuare componenti che soddisfano i requisiti del sistema e/o suddividerlo in unità più piccole (sottosistemi o librerie). Lo UML usa i packeges per rappresentare le maggiori aree di responsabilità e le loro interconnessioni. I packeges raggruppano le classi che forniscono servizi coerenti. Essi forniscono servizi di supporto alle funzionalità del sistema che sono forniti dalle interfacce; possono contenere altri packages e le loro interconnessioni.

I packages devono essere analizzati (determinare le loro responsabilità), definiti (API che forniscono le responsabilità) e modellati (come interagiscono per fornire le responsabilità)

CAPITOLO 6 CONCLUSIONI

Figura 54 Packages Diagramm

Anche per i packages può essere definito un piano che individua le precedenze e le interconnessioni tra essi e definisce quanto tempo e quali risorse occupano l’analisi, la definizione e la modellazione dello stesso package.

Deve essere schedulato anche il processo di codifica e test dei packages.

La maggior fatica è quella di identificare come implementare le funzionalità dei casi d’uso, a tale scopo è usato il diagramma delle sequenze. Questi mostrano l’ ordine delle interazioni ad alto livello, permettono di raffinare e confermare la descrizione dei casi d’uso. Nella prima analisi i diagrammi di sequenza possono essere usati per confermare i requisiti funzionali illustrando le interazioni tra gli attori e dispositivi di interfaccia (attraverso messaggi di evento) e oggetti software (attraverso messaggi di chiamata a procedure). Questo aiuta anche l’assegnazione delle responsabilità ai packages software suddividendo le varie funzionalità.

CAPITOLO 6 CONCLUSIONI

Figura 55 Diagramma di sequenza per i casi d’uso ad alto livello

Durante la fase di disegno le responsabilità allocate nelle interfacce possono essere riassegnate a classi individuali all’interno del package. In questo modo sono stati determinati anche i packages di cui hanno bisogno i casi d’uso, e le funzionalità richieste dai packages.

Sempre nella fase di disegno si possono individuare delle classi da assegnare ad un packages oppure espandere un packages per creare classi che forniscano le funzionalità dello stesso. Queste classi devono essere aggiunte al diagramma di sequenza per mostrare le loro interazioni. Inoltre le operazioni complesse possono essere scomposte ulteriormente e si disegnano diagrammi di sequenze individuali.

CAPITOLO 6 CONCLUSIONI

Con la lista delle classi in ogni packages ed i metodi che supportano le funzionalità ai processi di schedulazione si aggiunge anche quello per implementare ogni caso d’uso.

Figura 57 Schedulazione dei processi necessari per implementare il caso d’uso uno

Nello sviluppo di sistemi non real-time, le decisioni riguardanti l’architettura sono prese quasi alla fine. Mentre nei sistemi real-time è importante iniziare a definire l’architettura del sistema mentre si inizia a definire l’architettura degli oggetti. Quando si definisce il dominio del sistema, analizzandolo come una scatola nera, vengono definite anche le interfacce come display, sensori, attuatori etc.. La distribuzione fisica del sistema è rappresentata con il diagramma di architettura, che rappresenta gli attuali o proposti nodi di elaborazione, memorizzazione, dispositivi di interfaccia e le connessioni tra i vari nodi e dispositivi.

CAPITOLO 6 CONCLUSIONI

Figura 58 Diagramma Hardware

Dovranno essere eseguiti processi di test per la piattaforma, per package esterni etc… tali processi vanno schedulati.

Seguendo questo approccio si permette un parallelismo tra lo sviluppo di package, se non sono dipendenti l’uno dall’altro; un certo grado di indipendenza tra i gruppi di lavoro; flessibilità; schedulazione grafica e quindi difetti sono più facili da individuare; supporta il metodo di sviluppo iterativo.

CAPITOLO 6 CONCLUSIONI

Figura 59 Schedulazione dei rilasci

6.2

Sviluppi Futuri

Un ciclo di sviluppo adeguato permette di costruire fin dalle primissime fasi del progetto prototipi realistici e funzionanti, che consentono una completa corrispondenza tra i requisiti dell’utente finale e le reali specifiche di progetto. Viene così eliminato in modo totale ogni rischio progettuale dovuto a incomprensioni o a interpretazioni errate dei requisiti.

L’importanza che hanno assunto le attività di specifica e di modellazione del software rispetto all’implementazione, tendono a far comparire una nuova figura professionale, quella dello sviluppatore software, ancora oggi poco diffusa e non ancora riconosciuta.

Adottando lo UML come linguaggio di specifica, modellazione e documentazione, per lo sviluppo di sistemi software si vanno ad eliminare i problemi di comunicazione tra chi ha il compito di descrivere il sistema e chi ha il compito di realizzarlo evitando così spiacevoli incomprensioni, che spesso sono alla base del fallimento di un progetto.

La tendenza è quella di far diventare la procedura di implementazione e scrittura di codice automatica, con le tecniche di MDA, ancor oggi poco utilizzate e non contemplate

CAPITOLO 6 CONCLUSIONI

Creare diagrammi che permettano di generare in modo univoco un modello pronto per la simulazione indipendente dallo strumento utilizzato, dalla piattaforma di simulazione e dal sistema operativo.

Bibliografia:

[1] Martin Fowler-UML Distilled-terza edizione-Pearsdon

[2] “http://www.omg.org” [3] “http://www.artisansw.com” [4] “http://web.cefriel.it/~alfonso/WebBook” [5] “http://it.wikipedia.org/wiki/” [6] “http://www.tecnoteca.it” [7] “ http://www.bo.iasf.cnr.it/~bulgarelli/index.htm” [8] “http://www.objectway.it” [9] “http://www-dbdeisunibo.it/” [10] “http://www.dis.uniroma1.it” [11] “http://www-lar.deis.unibo.it/~atonielli” [12] “http://www.analisi-disegno.com” [13] “http://www.mokabyte.it” [14] “http://www.object-modeling.it/object-center/”