DA UML A MATLAB

1. DA UML A MATLAB Progetto di Controllo dei Processi Come ricavare un modello di simulazione in ambiente Matlab partendo da una descrizione in linguaggio UML Studenti: Roberto Nicolino, Nicola di Lecce

2. Brevemente Partendo da una analisi approfondita sulle potenzialità che oggi offre Unified Modeling Language si mostrerà come questo linguaggio si ponga da tramite tra cliente e committente, per evitare inutili incomprensioni e per permettere la realizzazione di un modello completo e dettagliato di un sistema. Grazie ad UML è possibile realizzare simulazioni in ambiente Matlab percorrendo un processo di integrazione completo tra le due piattaforme di sviluppo.

3. Si procederà descrivendo • Cosa è UML e a cosa serve • Come integrare il linguaggio Uml con Matlab o altri ambienti di simulazione • Quali procedure adottare per tradurre un modello descritto in UML in un modello utile alla simulazione

4. 1/2 Intoduzione ad UML • Lo Unified Modeling Language è un linguaggio per specificare, costruire, visualizzare e documentare manufatti sia di sistemi software, che di altri sistemi non strettamente software. • UML rappresenta una collezione di best practices di ingegneria, dimostratesi vincenti nella modellazione di vasti e complessi sistemi. • UML permette di visualizzare, per mezzo di un formalismo rigoroso, “manufatti” dell’ingegneria, consentendo di illustrare idee, decisioni prese, e soluzioni adottate. • Tale linguaggio favorisce, inoltre, la divulgazione delle informazioni, in quanto standard internazionale non legato alle singole imprese.

5. 2/2 Intoduzione ad UML • Lo UML dispone di tutti i meccanismi necessari per la specifica di qualsiasi dettaglio ritenuto rilevante in ogni fase del ciclo di vita del progetto e quindi, in ultima analisi, per produrre modelli accurati. • Lo UML, permette di realizzare modelli che si prestano ad essere implementati con diversi linguaggi di programmazione e ambienti di simulazione tipo Matlab • Sul mercato sono presenti diversi tool, in grado di generare codice a partire dal relativo modello, sia interattivamente durante la fase di disegno, sia su richiesta. L’esistenza di queste funzionalità, sebbene ancora non del tutto mature, dovrebbe far capire che l’implementazione è veramente un dettaglio del disegno, specie con linguaggi come Java. • lo UML fornisce sia dei meccanismi molto formali, sia del testo libero da aggiungere, ogni qual volta lo si ritenga necessario, a parti ritenute poco chiare o particolarmente complesse, al fine di aumentarne il livello di dettaglio.

6. Perché utilizzare UML ?

7. 1/2 Perché utilizzare UML • Ogni qualvolta, in una disciplina dell’ingegneria, vi sia la necessità di realizzare un “manufatto”, indipendentemente dalla dimensione e dal settore di interesse (una casa, un grattacielo, un particolare meccanismo, un ponte, un dipartimento di un’azienda, e così via) si procede cercando di realizzarne un modello. • L’obiettivo è produrre, in tempi relativamente brevi e soprattutto a costi contenuti, una versione razionalizzata e semplificata del sistema reale che, tuttavia, consenta di evidenziarne l’aspetto finale e di studiarne prestazioni, affidabilità e comportamento. • Si provi a immaginare che cosa potrebbe accadere se si avviasse la progettazione di un ponte a partire da specifiche sommarie, magari comunicate verbalmente o, peggio ancora, se si partisse subito a costruirlo materialmente, magari affidandosi all’esperienza di qualche costruttore

8. 2/2 Perché utilizzare UML Il risultato sarebbe il seguente:

9. Questo è il motivo per cui è importante utilizzare un linguaggio di modellizzazione universale

10. Attualmente è possibile sfruttare le caratteristiche descrittive offerte da UML attraverso numerosi software free disponibili in rete, tra questi si segnala:Argo UMLhttp://argouml.tigris.org/

11. Componenti UML

12. 1/14 Componenti UML • Il linguaggio UML contiene svariati elementi grafici che vengono messi insieme durante la creazione dei diagrammi. Dato che l'UML è un linguaggio, come tale utilizza delle regole per combinare i componenti nella creazione dei diagrammi. • L'obiettivo dei diagrammi è quello di costruire molteplici viste di un sistema tutte correlate tra di loro. • La notazione UML include dieci tipi di diagrammi, divisi in cinque categorie. Si tenga presente che è assolutamente possibile costruire e aggiungere dei diagrammi differenti dagli standard (che vengono definiti ibridi) rispetto a quelli definiti dal linguaggio. La tabella seguente mostra le categorie e i diagrammi corrispondenti.

14. 3/14 Componenti UML: Class Diagrams • Per avere una idea immediata di cosa sia una classe è possibile usare come esempio il fatto che tutti gli oggetti o esseri viventi, spesso, sono riconducibili a determinate categorie (computers, automobili, piante, animali). Queste categorie costituiscono le classi. Una classe è una categoria o un gruppo di oggetti (con questo termine si includono, per comodità anche gli esseri viventi) che hanno attributi simili e comportamenti analoghi. I Class Diagrams forniscono le rappresentazioni utilizzate dagli sviluppatori.

15. 4/14 Componenti UML: Object Diagrams • Un oggetto è una istanza di una classe, ovvero una qualcosa di specifico che ha dei valori determinati per i suoi attributi e dei comportamenti specifici.

16. 5/14 Componenti UML: Use Case Diagrams • Uno Use Case (caso d'uso) è una descrizione di un comportamento particolare di un sistema dal punto di vista dell'utente. Per gli sviluppatori, gli use case diagram rappresentano uno strumento notevole: infatti tramite tali diagrammi, essi possono agevolmente ottenere una idea chiara dei requisiti del sistema dal punto di vista utente e quindi scrivere il codice senza timore di non aver recepito bene lo scopo finale. Nella rappresentazione grafica, viene utilizzato un simbolo particolare per l'actor (l'utente o un altro sistema che interagisce) che si vedrà in seguito. • L'actor è l'entità che interagisce con uno use case facendo partire la sequenza di azioni descritte dallo use case stesso e, eventualmente, ricevendo delle precise risposte dal sistema. Può essere una persona o anche un altro sistema.

17. 6/14 Componenti UML: State Diagrams • Ad un determinato istante, durante il funzionamento del sistema, un oggetto si trova in un particolare stato. Gli State Diagrams rappresentano tali stati, ed i loro cambiamenti nel tempo. Ogni state diagram inizia con un simbolo che identifica lo stato iniziale (Start State) e termina con un altro simbolo che rappresenta lo stato finale (End State). Per esempio, ogni persona può essere identificato dai seguenti stati: neonato, bambino, adolescente, adulto, anziano.

18. 7/14 Componenti UML: Sequence Diagrams • I class diagrams e gli object diagrams rappresentano informazione statica. In un sistema funzionante, tuttavia, gli oggetti interagiscono l'uno con l'altro, e queste interazioni avvengono in relazione al trascorrere del tempo. Il sequence diagram mostra le dinamiche, basate sul tempo, delle varie interazioni tra gli oggetti.

19. 8/14 Componenti UML: Activity Diagrams • Le attività che si riscontrano all'interno di use case o all'interno del comportamento di un oggetto accadono, tipicamente, in una sequenza ben definita. Tale sequenza si rappresentata con gli activity diagrams.

20. 9/14 Componenti UML: Collaboration Diagrams • Gli elementi di un sistema lavorano insieme per realizzare e soddisfare le necessità del sistema. Un linguaggio di modellazione deve avere un modo per rappresentare tale cooperazione. Il Collaboration Diagram nasce proprio per questa ragione.

21. 10/14 Componenti UML: Component Diagrams • Oggi, nell'ingegneria del software si utilizza sempre più il modello di organizzazione secondo il quale ognuno nel team di lavoro lavora su un componente differente. Il component diagram descrive questa importante caratteristica.

22. 11/14 Componenti UML: Deployment Diagrams • Il Deployment Diagram mostra l'architettura dal punto di vista fisico e logistico di un sistema. Tale diagramma può descrivere i vari dispositivi presenti, mostrare le varie connessioni che intercorrono tra di essi e, ancora, il software che è installato su ogni macchina.

23. 12/14 Class Interface Use Case Deployment :Name2 :Name1 :Name1 1:Messages State Component :Name2 Collaboration Sequence Activity I simboli grafici • Elementi Strutturali • Elementi Comportamentali

24. 13/14 Association Generalization Dependency Realization Package I simboli grafici • Relazioni • Raggruppamento

25. 14/14 Note I simboli grafici • Estensioni <<Stereotipo>> {Constraint} • Annotazioni ed Actor Actor

26. UML: Considerazioni • Nell’effettuare la traduzione di un sistema descritto in ambiente UML in un sistema descritto in ambiente Matlab ci si serve prevalentemente di: • Class Diagram • State Diagram • Collaboration Diagram • Sequence Diagram

27. Ambiente Matlab • Esistono principalmente due modi per poter simulare un sistema descritto in UML attraverso le funzionalità offerte da Matlab: • Mediante Simulink e Stateflow utilizzati rispettivamente per simulare sistemi continui e ad eventi discreti (macchine a stati) • Mediante scrittura di codice in linguaggio S-Function, anch’esso integrato pienamente in Matlab. • Si procederà ora analizzando prima lo Stateflow che risulta essere lo strumento più semplice per poter rappresentare sistemi di tipo discreto o ibridi (in aggiunta a Simulink) e che rispetto ad S-function è più “User Friendly”

28. 1/5 Ambiente Matlab: Stateflow • Lo stateflow è uno strumento di sviluppo grafico per sistemi basati sulla teoria delle macchine a stati finiti ossia sistemi di controllo logici (controllore on-off, scheduler), o sistemi di supervisione (controllori ad alto livello, ecc). • Una macchina a stati finiti, dunque, non è altro che la rappresentazione di un sistema a eventi discreti la cui evoluzione è regolata dal susseguirsi di condizioni vere o false. • L’approccio utilizzato da Stateflow per descrivere un sistema a stati discreti è quello di modellarne il comportamento, in termini di transizioni attraverso gli stati. Lo stato attivo è determinato basandosi sul susseguirsi di eventi sotto determinate condizioni. Pertanto le transizioni e gli stati nel loro complesso non sono altro che delle rappresentazioni grafiche basate su questo tipo di approccio.

29. 2/5 Ambiente Matlab: Stateflow • Le macchine a stati finiti che questo ambiente di sviluppo permette di descrivere, sono caratterizzate da uno stato, un ingresso ed un’uscita e si connettono fra di loro mediante delle transizioni. In dettaglio: • Stato: è la condizione (modo) di funzionamento della macchina; • Transizione: è la condizione di cambiamento dello stato della macchina; • Ingressi: sono informazioni provenienti dall’esterno (eventi, segnali); • Uscite: sono segnali verso l’esterno il cui valore può essere funzione degli stati o delle transizioni.

30. 3/5 Ambiente Matlab: Stateflow • Di seguito è riportato un semplice esempio di controllo On-Off di un forno per porre in evidenza le parti caratterizanti di una Macchina a Sati descritta in Stateflow:

31. 4/5 Ambiente Matlab: Stateflow • Le macchine a stati finiti che questo ambiente di sviluppo permette di descrivere, sono caratterizzate da uno stato, un ingresso ed un’uscita e si connettono fra di loro mediante delle transizioni. In dettaglio: • Stato: è la condizione (modo) di funzionamento della macchina; • Transizione: è la condizione di cambiamento dello stato della macchina; • Ingressi: sono informazioni provenienti dall’esterno (eventi, segnali); • Uscite: sono segnali verso l’esterno il cui valore può essere funzione degli stati o delle transizioni.

32. 5/5 Ambiente Matlab: Stateflow • Le transizioni avvengono al verificarsi di un evento che può coincidere ad esempio con la variazione di un “oggetto Dato” o “Tempo”. • Tali oggetti sono variabili di tipo numerico utilizzate da Stateflow per scambiare informazioni con Simulink, e quindi con il Workspace di Matlab, o con altre Macchine a Stati.

33. Ambiente Matlab: Considerazioni • Come già anticipato, è anche possibile tradurre una descrizione UML in ambiente Matlab attraverso le S-Function, rispettando le regole di scrittura ampiamente trattate in letteratura. • Una S-Function è una descrizione, di un sistema dinamico, realizzata attraverso un linguaggio di programmazione, il cui codice può essere scritto utilizzando i linguaggi Matlab o C. • Mediante S-Function è possibile descrivere un sistema ibrido completo e pronto per la simulazione, semplicemente analizzando la descrizione UML.

34. Da UML a Matlab: Un Esempio

35. UML-Matlab: Esempio • Si vedrà ora quali procedure adottare per poter realizzare un modello di simulazione Matlab-Simulink partendo da una descrizione UML di un sistema di tipo ibrido. Verrà considerato come sistema una cella di lavoro da poter utilizzare in catene di montaggio industriali • Il sistema, costituito da due bracci robotici, da una rastrelliera, da una attrezzatura su cui eseguire la saldatura, da un nastro trasportatore, e da un pallet svolge ciclicamente le seguenti azioni: • Prelievo pezzo A con Movimentatore da rastrelliera; • Deposito pezzo A su attrezzatura di saldatura; • Prelievo pezzo B con Movimentatore da rastrelliera; • Deposito pezzo B su attrezzatura di saldatura; • Esecuzione saldatura a punti (Saldatore); • Posizionamento dell’assieme su pallet (Movimentatore); • Ripetizione saldatura per un secondo pezzo; • Allontanamento del pallet con due pezzi saldati dalla cella.

36. UML-Matlab: Esempio • Analizzando tale cella sarà possibile modellare la dinamica dei robots con uno schema Simulink tempo continuo e il funzionamento di tutti gli altri componenti come una sequenza di operazione discrete, ottenendo un sistema complessivamente Ibrido. Verrà elaborata prima una descrizione del sistema in UML, seguendo le procedure già descritte ossia la realizzazione di: • Class Diagram • State Diagram • Collaboration Diagram • Sequence Diagram • In seguito, servendosi dello State Diagram, si rappresenteranno mediante precise regole di traduzione, le componenti discrete del sistema in ambente Stateflow.

37. UML-Matlab: Esempio • La soluzione adottata per la cella di lavoro prevede che il robot2 (Saldatore) sia posto rispetto alla tavola girevole dalla parte opposta al robot1 (Movimentatore). In figura si indicano schematicamente con Ras la rastrelliera, con R1 e R2 rispettivamente il robot1 e il robot2, con TG la tavola girevole, con P il pallet e con Tr il trasportatore.

38. Class Diagram • Una volta scelti i componenti del sistema si procede con la realizzazione del Class Diagram che servirà a specificare quali oggetti costituiscono il sistema e a grandi linee che relazioni ci sono tra questi tipi di oggetti, ossia che operazioni compiono. • Il diagramma contiene pertanto una classe generica Robot e due istanze di tale classe: Saldatore e Movimentatore. Associate ad esse vi è una classe Pezzo, che è a sua volta associata, con molteplicità 2, alla classe Assemblato (composizione dei pezzi A e B). La comunicazione tra i vari elementi della cella è garantita da 3 segnali presenza_pezzo, finecorsa_nastro e presenza assemblato, inviati ai due Robot dalle classi Rastrelliera, TavolaGirevole e NastroTrasportatore. • La Dinamica è trattata come una classe a se in cui andranno specificate attraverso delle Note o delle Constraint le equazioni differenziali che regolano il funzionamento del braccio Saldatore e del braccio Movimentatore.

40. State Diagram • Nella realizzazione dello State Diagram si è tenuto conto che il sistema è costituito da due elementi fondamentali che risultano essere i due Robots. • Il funzionamento della cella di lavoro nel suo complesso si basa infatti sulle azioni che i due Robots devono compiere per poter effettuare la movimentazione dei pezzi e la saldatura. • Le altre componenti ossia la Tavola Girevole, la Rastrelliera e il Nastro Trasportatore sono visti come degli elementi passivi di cui i Robots si servono per poter ricavare delle informazioni o per poter impartire dei comandi.

41. State Diagram • Si è scelto dunque di realizzare due State Diagram: • uno per il robot Movimentatore; • uno per il robot Saldatore. • Di seguito per completezza sono riportati i rispettivi schemi

44. Collaboration Diagram • Il Collaboration Diagram visualizza lo scambio dei messaggi che avviene tra i vari componenti del sistema, come rappresentato in figura:

45. Sequence Diagram • La realizzazione del Sequence Diagram risulta abbastanza semplice, basta considerare infatti la sequenza delle interazioni che avvengono durante il funzionamento del sistema e rappresentarle secondo la sintassi.

47. Matlab: Simulink e Stateflow • Una volta terminata la realizzazione dei diagrammi UML si passa alla traduzione del sistema in un modello di simulazione all’interno di Matlab. Pertanto si procede con la descrizione della componente continua attraverso dei blocchetti simulink e con la descrizione della componente discreta mediante una macchina a stati.

49. Regole di Traduzione • Si riportano per completezza i passaggi che devono essere effettuati per poter trasformare la descrivere un sistema in UML e poi trasformare tale descrizione in un modello Matlab: • Analisi dei componenti e delle specifiche di progetto • Descrizione dettagliata della dinamica del sistema • Realizzazione di opportuni controllori che consentano il rispetto delle specifiche • Scrittura del Class Diagram UML • Scrittura dello State Diagram • Scrittura del Collaboration Diagram e del Sequence Diagram • Realizzazione del modello Matlab (componenti continue con Simulink e discrete con Stateflow) • Eventuale generazione di codice per la configurazione e la programmazione dei componenti del sistema.

50. Regole di Traduzione • L’unicità di questa procedura è garantita anche grazie ai numerosi strumenti offerti da UML per realizzare la descrizione di un sistema, tra questi assume rilevante importanza il costrutto constraint. • La sua funzione è quella di fornire dei vincoli che garantiscano le specifiche determinanti del sistema.