UML, questo sconosciuto

Riporto qui alcuni posts che ho cominciato a scrivere sull'altro forum sperando che a qualcuno interessino.

UML (Unified Modelling Language) è uno strumento estremamente potente e relativamente facile da usare che nelle mani di un progettista capace è in grado di rappresentare qualsiasi sistema.
Possiamo rappresentare in UML il funzionamento di un computer, di un impianto di riscaldamento, di un sistema informativo o di un robot.
L'importanza di UML risiede nel fatto che fornisce delle regole generali per la rappresentazione dei sistemi, regole che definiscono una linea guida in grado di rendere comprensibilissimo un progetto.
UML non si limita solo a quanto sopra scritto. Infatti partire direttamente con l'implementazione di un sistema senza averne fatto prima un'analisi porta molto spesso a punti morti che rendono difficile proseguire. Lo studio tramite UML mette in risalto tutte le problematiche legate al progetto e dunque consentono di approfondire le soluzioni a questi problemi. UML si basa su tre elementi fondamentali:

1) Viste: che sono interpretabili come diversi modi di vedere un sistema
2) Diagrammi: che sono la maniera con cui graficamente si rappresentano gli aspetti del progetto
3) Componenti: che costituiscono i diagrammi

Infatti UML permette una rappresentazione grafica del progetto rendendolo estremamente conprensibile.
Prima di cominciare a parlare in maniera piu' approfondita di UML è indispensabile spiegare cosa è un Oggetto.

Prendiamo un libro fra le mani ed osserviamolo. Un libro possiede ad esempio una copertina che ha un certo colore, un certo numero di pagine, un formato, un peso. Tutti questi elementi sono delle CARATTERISTICHE del nostro libro, che possiamo considerare un oggetto. Quini un oggetto possiede delle caratteristiche che prendono il generico nome di ATTRIBUTI. Alcuni attributi puo' essere solo letti, altri consentono la modifica. Ad esempio se pensiamo ad un ascensore fermo ad un certo piano, il numero del piano puo' essere considerato un attributo che però puo' essere modificato. Invece il numero di pagine di un libro è un attributo che puo' essere solo letto. Non possiamo modificare il numero di pagine (a meno di strapparle ).
Adesso lasciamo cadere il nostro libro. Possiamo notare come un'azione esterna come quella delle nostre mani possa influenzare un oggetto. Tale azione esterna si chiama EVENTO.
Posiamo il nostro libro ed osserviamo il lettore di CD del nostro PC. Il lettore puo' svolgere alcune azioni come leggere un cd, scriverci (se è un masterizzatore), espellerlo ecc... Tutte queste azioni si chiamano METODI e sono operazioni che il nostro oggetto puo' svolgere.

Concentriamoci di nuovo sugli ATTRIBUTI. Alcuni attributi sono numerici, altri sono caratteri, altri ancora parole. Come fare ad identificarli? Per far questo si ricorre al concetto di TIPO che identifica la natura di un certo oggetto. Abbiamo i seguenti TIPI (standard):

INTEGER: un numero intero
FLOAT: un numero decimale (non ci soffermiamo per ora sui vari tipi di decimali, ci basta per adesso FLOAT)
CHAR: un carattere
STRING: una sequenza di caratteri
BOOLEAN: un valore che puo' essere o vero o falso


Ad esempio, il numero di pagine di un libro è un INTEGER, il peso di una mela misurato in Kg è un FLOAT, il nostro nome è uno STRING, la prima lettera dell'alfabeto è un CHAR. Ed i BOOLEAN? Supponiamo di chiederci se pesiamo piu' di 60 Kg o meno, la risposta è SI o NO, cioè VERO o FALSO. Ecco che la risposta a quella domanda è un BOOLEAN.
Allora possiamo provare a definire un attributo usando i tipi. Esempi sono:

PagineLibro:Integer
PesoMela:Float
Nome:String

ecc...

Passiamo ai metodi. Un metodo è quasi inutile se non possiamo specificare dei parametri su cui il metodo agisce. Ad esempio supponiamo che un metodo faccia la somma di due numeri. Per far ciò serve dar al metodo i due numeri. Possiamo specificare il metodo in questo modo:

SOMMA(numero1,numero2)

Però facendo cosi' non abbiamo specificato cosa sono numero1 e numero2. Inoltre il nostro metodo deve ritornarci la somma dei due numeri altrimenti non potremo mai conoscere il risultato di quella somma. Per far ciò useremo la:

SOMMA(numero1:Integer , numero2:Integer):Integer

In pratica abbiamo scritto che SOMMA accetta due interi in ingresso e ritorna un intero in uscita. Tralasciando ora le istruzioni necessarie a svolgere il compito, supponiamo di voler utilizzare il metodo. Per esempio sommiamo 4 e 5:

SOMMA(4,5)

SOMMA ritornerà come valore 9. Però serve che questo valore venga messo dentro qualche cosa che funga da contenitore per non perdere l'informazione. Chiamiamo Temp questo contenitore che deve essere un intero. Ad esempio:

Temp:Integer
Temp=SOMMA(4,5)

bene adesso Temp dovrebbe contenere il valore ritornato da SOMMA. Immaginiamo di disporre di un altro metodo che stampa su schermo il valore di una certa variabile (il 'contenitore' che abbiamo usato prima, ovvero Temp) definito come:

STAMPA(NumeroDaStampare:Integer)

Si noti che STAMPA non ci ritorna nulla ma esegue un'operazione proiettando il risultato su schermo. Non tutti i metodi infatti ritornano un risultato.
Proviamo ad usarlo:

Temp:Integer
Temp=SOMMA(4,5)
STAMPA(Temp)

Il risultato sarà 9 e verrà stampato su schermo.
Quanto abbiamo scritto fino ad ora è una specie di pseudocodice (ovvero non è un linguaggio di programmazione ben definito, ma creato ad Hoc da noi) che però rispecchia molto delle regole usate da UML.

Facciamo un passo in avanti. Prendiamo tutti i libri che abbiamo nella libreria ed osserviamoli. Possiamo notare come la struttura dei libri sia a comune, tutti hanno delle pagine, tutti hanno una copertina, tutti hanno stessi metodi ed eventi, ciò che cambia sono gli attributi. Allora un Libro appartiene ad un insieme che è quello dei Libri. Tale insieme si chiama CLASSE. Quindi la classe mette insieme un insieme di oggetti simili che si differenziano solo per gli attributi. Ad esempio tutte le persone appartengono alla classe PERSONA ma ciascuna ha caratteristiche proprie, sebbene tutte abbiano stessa capacità di azione (metodi).

Prima di concludere questo primo post proviamo a creare una classe usando sempre una sintassi di comodo:

CLASSE orologio

ATTRIBUTI
ore:Integer
minuti:Integer
secondi:Integer

METODI

settaOra(nuovaora:integer)
settaMinuti(nuoviminuti:integer)
settaSecondi(nuovisecondi:integer)
stampaOrario()


La nostra classe di esempio possiede come attributi ora-minuti-secondi che rappresenta l'orario. Inoltre dispone di alcuni metodi che servono a modificare gli attributi e di un metodo (stampaOrario() ) che non necessita di parametri di input o di output e manda allo schermo direttamente l'orario. Questo è un esempio molto semplificato di come costruire una classe, ma rende bene, spero, l'idea di cosa ci appresteremo a fare piu' avanti.

Un saluto...

Seconda parte della nostra breve carrellata su UML.
Quando si realizza un sistema capita spesso che sia necessario interfacciare tale sistema in maniera tale da consentire ad un operatore certe operazioni. L'operatore (che puo' essere un uomo o un altro sistema) prende il nome di attore e rappresenta colui che esegue un'operazione che il sistema che stiamo sviluppando fornisce. Ad esempio volendo trattare il progetto di un ascensore è logico che l'operatore dovrà poter:

1) Chiamare l'ascensore
2) Selezionare il piano di destinazione
3) Suonare un allarme
4) Bloccare la corsa dell'ascensore

Per rappresentare questo punto di VISTA, che prende il nome appunto di USE CASE VIEW, si usa un tipo di diagramma detto Use Case Diagram.
Use Case Diagram ha una serie di caratteristiche che lo rendo ideale per astrarsi dalla vera e propria realizzazione del sistema e dai dettagli tecnici pur consentendo di sottolineare le funzionalità che il sistema deve possedere.
Supponiamo di voler realizzare un robot dotato di cingoli e di un braccio meccanico e di volerlo controllare tramite un operatore (ad esempio i robot che vengono usati per disinnescare e rimuovere esplosivi).
L'attore principale sarà sicuramente l'operatore, che indicheremo con un ominino stilizzato, per convenzione. E' importante indicare sempre il nome dell'attore. Gli Use Case (casi d'uso) invece vengono rappresentati dentro delle ellissi, ed infine la relazione fra l'attore e lo use case è indicata con una linea. Gli use case che sicuramente serviranno sono:

1) Controlla Cingoli
2) Controlla Braccio

Ecco un esempio di come potrebbe essere il nostro diagramma:



Il diagramma è molto semplice e si spiega da solo. Osservandolo attentamente possiamo notare come ad esempio Controlla Cingoli in realtà consti di due diversi elementi, ovvero controlla cingolo destro e controlla cingolo sinistro. Sebbene si possa indicare al posto di Controlla Cingoli i due Use Case Controlla Cingolo Destro e Controlla Cingolo Sinistro è ovvio il nesso che lega entrambi ed è probabile che si voglia tenerli insieme.
Gli Use Case Diagram consentono di sfruttare alcune relazioni particolari. Fra queste è molto utile l'inclusione, che consente ad uno Use Case di includere altri Use Case che quindi forniscono al primo diverse operazioni. Il nostro diagramma diventa, considerando anche il braccio (supponiamo sia un braccio dotato di 3 gradi di movimento piu' pinza):



Come possiamo notare la relazione di inclusione è specificata dalla <<include>> e dalla presenza della freccia che punta allo Use Case oggetto dell'inclusione.
Probabilmente il nostro Operatore vedendo questo schema comprenderà molto facilmente cosa stiamo mettendo su per lui, ma ci farà notare che pilotare un robot senza una videocamera e qualche sensore è praticamente impossibile. Già qui capiamo che fattori che magari in prima battuta erano stati trascurati saltano fuori realizzando i diagrammi UML. QUindi l'operatore deve essere in grado di:

1) Visualizzare i dati di una telecamera sulla pinza
2) Visualizzare i dati di una telecamera mobile controllata in remoto.
3) Visualizzare messaggi provenienti dal robot (a esempio un avviso che indichi che la pendenza del terreno rischia di far ribaltare il robot)

Procediamo all'angiunta di queste funzionalità.



Ecco pronto il nostro primo use case realizzato interamente in paint. Infatti altra caratteristica di UML è la semplicità con cui si rappresentena i diagrammi, cosa che consente di utilizzare carta e penna, Paint o software complessi come Poseidon e Visual Paradigm.
Ad esempio lo stesso diagramma con qualche piccola modifica e realizzato in Poseidon è il seguente:



Possiamo associare a questo diagramma una piccola immagine che spieghi in maniera molto semplice alcuni Use Case relazionati al robot. Ad esempio una cosa del genere potrebbe essere molto esplicita se affiancata dallo Use Case:



Infatti questo 'scarabocchio in paint' ci spiega a cosa sono associate le funzioni descritte nello Use Case rispetto al nostro robot.

Vediamo un altro Use Case proveniente stavolta dalla rete:



Si nota come sia presente una seconda relazione che è Extend. Extend (Estensione) indica che una Use Case viene estesa da un'altra Use Case che presenta le funzioni della prima ma anche funzioni aggiuntive.
L'uso di Extend e Include sarà piu' chiaro quando parleremo degli altri diagrammi. Ci basti sapere per ora che queste relazioni sono utili per specificare delle funzionalità altrimenti nascoste.

Si ricordi inoltre che gli Use Case sono dei diagrammi che vedono il sistema dal punto di vista dell'utente e che quindi non possono certamente essere troppo specifici, ma devono mantenere un certo livello di astrazione da come poi il sistema verrà implementato.


Terza parte riguardante UML. Vediamo di introdurre i diagrammi di classe. Abbiamo detto che un oggetto è in grado di rappresentare all'interno del nostro programma un oggetto fisico o non. Una classe puo' fungere da stampo per gli oggetti accomunandoli in base a caratteristiche e funzioni comuni (si parla di Abstract Data Type) e quindi è perfetta per individuare le varie parti che compongono un qualsiasi sistema rappresentando in maniera molto efficace le relazioni che esistono fra le componenti del sistema stesso.
Ad esempio vogliamo modellizzare la telecamera del nostro robot in modo da prelevare delle istantanee scattate dalla stessa.
Sicuramente le funzioni che ci interessano sono quelle legate al movimento ed alla messa a fuoco della stessa, quindi:

SpostaDestra(float gradi)
SpostaSinistra(float gradi)
SpostaAlto(float gradi)
SpostaBasso(float gradi)
Zoom(int valore)

in questo modo noi possiamo interagire con la videocamera decidendo come muoverla e se fare uno zoom. La nostra videocamera dispone internamente di una circuiteria che consente di prelevare le immagini. Possiamo rappresentare questo fatto come un attributo di tipo Immagine (che creeremo ad hoc) che contiene una singola immagine della videocamera. Ovviamente ci servirà anche la funzione che ci consente di poter prelevare questa immagine. Quindi:

Immagine foto
GetFoto()

GetFoto() ritorna un oggetto di tipo Immagine, ovvero ci ritorna la foto. La definizione corretta è quindi:

Immagine GetFoto()

inoltre GetFoto deve poter essere usato anche da classi diverse da se stessa, lo possiamo quindi definire come Publico, ad esempio:

Public Immagine GetImmagine()

Ora, in UML le classi si rappresentano dentro rettangoli divisi in tre aree, dove la prima rappresenta il nome della classe, la seconda gli attributi e la terza i metodi. Quindi abbiamo in pratica (usando sempre Poseidon):



Osserviamo attentamente la forma con cui Poseidon realizza la modellazione della classe cosi' da accennare alla sintassi usata da UML per questo tipo di rappresentazioni.

Brevemente, ogni metodo o attributo presenta a sinistra un segno che puo' essere + (Publico) - (Privato) ecc... che ne definisce il modificatore di accesso. Ad esempio Publico vuol dire che tutti gli altri oggetti possono accedere comodamente ai metodi contenuti nella classe.
I tipi sono indicati facendoli seguire a : e piu' a destra, nei metodi, appare il tipo ritornato.

Ad esempio, se chiamiamo il metodo GetImmagine possiamo fare cosi';

MiaImmagine=GetImmagine()

GetImmagine ritorna come risultato un oggetto di tipo immagine che finirà per essere messo dentro MiaImmagine mettendoci a disposizione l'istantanea fatta.
Però se il metodo non fosse +GetImmagine.... ma -GetImmagine allora non potremmo accedere cosi' direttamente al metodo essendo questo privato appunto.
Prossimo post vedremo come collegare fra loro piu' classi.

In realta' UML serve a dare una "forma" ai concetti che stanno dietro un idea e ad organizzarla. Se io e tu dobbiamo fare ad esempio un certo programma avendo a disposizione il progetto UML possiamo ad esempio ripartire meglio il lavoro. Questo perche' una volta deciso cosa faro' io e cosa farai tu entrambi sapremo esattamente ogni parte da noi realizzata come deve funzionare e come si ricollega con le altre. Non solo, e' un potentissimo strumento di documentazione perche' chi verra' dopo a visionare il progetto avra' immediatamente davanti il funzionamento concettuale del sistema.
Per sistemi che non sono programmi l'uso di disegni tecnici e' d'obbligo. Ma cosi' si sa ciascun disegno che ruolo occupa dentro il progetto. Man mano aggiungero' altre cose su UML cosi' da completare la discussione

Piu' che altro UML ti dice:

1) Concettualmente il sistema come funziona e come interagisce con l'esterno
2) Come si coordinano i vari componenti interni fra di loro (scambio di messaggi ad esempio)
3) Come funzionano nel tempo (timing diagram, poi ne parlo fra qualche post)
4) Come lavorano internamente i vari componenti sfruttando ad esempio diagrammi di stato o a blocchi

Quindi si parte da una visione di insieme per poi scendere in dettagli ma UML non ti dice che quel controllore deve usare questo o quell'altro mosfet. Ti dice solo che quell'oggetto deve lavorare in un certo modo per ottenere certe funzioni che altri oggetti richiameranno.

Ed e' estremamente potente nella descrizione. Per dirla tutta io lo uso molto nei miei software e posso assicurarti che quando hai finito di fare il progetto in UML scrivere il codice in java, c++, VB o qualsiasi altra cosa diventa un procedimento quasi automatico. Praticamente non devi pensare quasi piu' a nulla sull'organizzazione. A me piace tantissimo.

Ciao Hellblow.
Questo UML è molto utile ,penso, in quelle situazioni dove si presentano problemi di strutturazione e valutazione di un progetto ,per esempio nel campo architettonico, o per la gestione di catene robotizzate o in campo meccanico , per stabilire dove si puo' migliorare il funzionamento di un elemento....

Puo' essere equiparato ad un programma tipo CAD,ma molto piu' evoluto?

Cmq continua pure , l' argomento è alquanto interessante.

Dunque, ogni volta che si tenta di realizzare qualcosa, ingegneristicamente parlando, e' necessario creare un modello. Il modello dà le specifiche e rende quel qualcosa un oggetto che ha delle caratteristiche note e dei comportamenti prevedibili.
Ad esempio, se volessimo realizzare un sistema formato da un generatore di corrente il cui albero viene smosso da una puleggia con avvolta una corda che ad una estremita' ha un peso, la prima che dovremmo fare e' individuare il modello fisico, ovvero le leggi che regolano il moto di tutto il sistema. Il modello quindi ci permette di prevedere il comportamento del sistema.
Ora quando parliamo di software la condizione di prevedibilita' e' quella che ci salva dai bugs. Infatti un errore di programma e' qualcosa che sicuramente il programmatore o l'utente non vogliono e nasce sempre da situazioni non previste o da cattiva programmazione.
Disponendo di un modello si riesce a vedere invece un oggetto sotto punti di vista diversi (viste) che consentono proprio di individuare i punti critici del nostro sistema ottimizzandoli e mettendo anche riparo ad eventuali errori. L'assolutismo qui non esiste ma sta alla bravura del programmatore e dell'analista realizzare un modello e poi un prodotto che abbia un comportamento quanto piu' prevedibile e corretto possibile.
UML seve a questo, non e' un CAD o schema circuitale o altro, ma un insieme di diagrammi regolati da certe norme di cui discuteremo che consente di realizare una documentazione descrittiva di un sistema. E' una razionalizzazione di cio' che intendiamo creare in pratica.

Famosa questa vignetta:



Con UML si individua cosa realmente serve per fare una ben precisa cosa e come il sistema in questione va realizzato.
Piu' tardi continuiamo con il discorso di UML

Uhm, in pratica l'ULM non è altro che una standardizzazione del modo di rappresentare schematicamente un software, il modo in cui disegnare i diagrammi a blocchi, il modo in cui rappresentare le varie sub, le convenzioni per indicare le varie connessioni, etc, etc, ho capito bene?

Si ma non solo gyppe. Andiamo avanti con qualche altra cosuccia (ricordando che quanto sto esponendo e' davvero una piccola parte di UML. Se si vuol fare qualcosa di serio si deve necessariamente fare riferimento a http://www.uml.org).

Abbiamo adesso piu' o meno il concetto di classe e di use case diagram. UML prevede anche altri diagrammi. Ciascuno di questi diagrammi "vede" il problema da un certo punto di vista e con un certo grado di approfondimento. Ad esempio lo use case diagram mostrava come qualcosa (l'attore) interagiva con il sistema ed in un certo senso scomponeva il sistema stesso in parti che interagivano fra loro. E' importante sottolineare che l'attore puo' essere un essere umano ma puo' benissimo essere qualcosa di diverso. Lo use case diagram che abbiamo visto sopra e' anche classificato come statico nel senso che e' una vista statica del sistema. Insieme allo use case diagram statico si puo' creare uno use case diagram dinamico che mostra una evoluzione dell'interazione nel tempo. Questa dinamicita' viene spesso descritta utilizzando dei riferimenti di testo. Tuttavia lo use case diagram non e' certo il modo migliore per descrivere la dinamicita' di un sistema. Ed infatti ci aiutano gli altri diagrammi. Facciamo una rapida panoramica (con definizioni molto generali mirate a capire di cosa si tratta).

Class Diagram: Poiche' possiamo rappresentare la realta' sotto forma di oggetti, dobbiamo tener conto del fatto che questi oggetti si relazionano fra di loro. In particolare il diagramma si riferisce alle classi, che sono rappresentative ciascuna di tutta una categoria di oggetti. Ad esempio un' automobile e' ad esempio formata da un solo oggetto di tipo motore, ma da quattro oggetti di tipo ruota. Ma gli oggetti di tipo ruota, sebbene siano 4 e distinti, appartengono tutti alla stessa classe ruota perche' hanno tutte le stesse caratteristiche. Ora queste relazioni fra classi, ma anche molto altro, vengono descritte dal class diagram. Quindi il class diagram ci dice come le classi che formano il sistema sono ricollegate fra di loro.


Object Diagram : Come nel caso del class diagram siamo di fronte ad un diagramma statico. Questo tipo di diagramma descrive stavolta gli oggetti e come sono legati fra di loro. Per la precisione l'oggetto e' l'istanza della classe. Infatti la classe rimane qualcosa di astratto, che ha delle caratteristiche non definite. L'oggetto invece e' qualcosa di definito.


Package Diagram: Piu' classi possono formare un package. Ad esempio se volessimo creare delle classi che risolvono certi problemi di matematica (Sin, Cos, Tg, Radice ecc...) li potremmo tutti inserire dentro un package chiamato Matematica. Perche' fare questo? Nella programmazione ad oggetti e' possibile usare i package in modo da avere a disposizione tutto quello che essi contengono, o almeno quello che e' reso public. Quresti package interagiscono e il package diagram ne da una descrizione.


Statechart Diagram: Se il nostro sistema non desse luogo a interazioni e risultati in funzione degli ingressi sarebbe qualcosa di isolato e inutile. Quando accade un evento che interessa un oggetto, quest'ultimo subisce un cambiamento del suo stato quindi, dando luogo appunto ad una catena piu' o meno lunga di azioni che portano ad un certo stato finale. Stato iniziale, stato finale, evento ecc... sono tutti elementi dello statechart diagram che rappresenta cosi' come e cosa accade in base ad un certo evento.


Activity Diagram : E' un diagramma che esprime come una certa funzione viene svolta. A prima vista lo si associa ai flow charts usati in informatica per descrivere le funzioni, ma in realta' esistono nette differenze fra i due come vedremo.


Sequence Diagram E' un diagramma molto espressivo che mostra l'interazione che si viene a creare quando c'e' un particolare evento. E' uan sorta di fotografia di cio' che vogliamo che accada secondo una sequenza ben precisa. Ovviamente si puo' fare anche altro con questo diagramma fino a renderlo un potentissimo strumento descrittivo.


Timing Diagram: E' una forma particolare di Sequence diagram dove si focalizza l'attenzione sul tempo. Spesso e' necessario progettare un sistema che interagisca con l'utente secondo delle specifiche temporali particolari. Basti pensare alle porte dell'ascensore ed al timer che le gestisce. Si intuisce come questo diagramma sia utilissimo in certi casi, meno utile in altri.


Communication Diagram Sequence e Communication sono i diagrammi che formano gli iteractions diagram. Infatti anche il Communication descrive l'interazione che porta allo svolgimento di un certo compito.


Component Diagram : Mostra in modo "macroscopico" come componenti di un certo sistema siano legati fra di loro.



Deployment Diagram : Come il Component ma riferito stavolta direttamente a componenti hardware.


Composite Structure Diagram: Mostra la struttura interna delle classi come composizione di altre classi. E' molto utile e potente, oltre che versatile.
Esempio. L'immagine era troppo grande ed ho indicato il link.

Esistono anche altri diagrammi ma per non appesantire troppo il thread per ora tralasciamo.
Naturalmente quando si quando si analizza un problema e' necessario individuare tutti quei diagrammi che sono necessari a rappresentare il problema stesso nel migliore dei modi. Inoltre si devono individuare i diagrammi necessari a rappresentare in modo chiaro il sistema che risolvera' quel problema (un software ad esempio). Da qui la difficolta' nel capire quali diagrammi servono e quali no.
Inoltre UML e' enorme. Basti pensare che dalla versione 1.1 alla 2.0 moltissime cose sono cambiate ed e' stato inserito parecchio materiale nuovo con cui poter lavorare. Una trattazione esaustiva in questa sede e' quindi impossibile. Pero' posso provare a stuzzicare il vostro interesse.
Prossimamente continuo con i diagrammi.

Il problema nasce quando sul software devono metterci le mani altre persone o devi rimettercele tu dopo parecchio tempo

UML si integra con molti ambienti di sviluppo. Ad esempio se in netbeans fai un progetto in UML puoi subito portarlo da UML a codice java. Lui ti crea tutte le chiamate, i metodi ecc ed alla fine ti ritrovi con lo scheletro del software gia' pronto e devi solo scrivere il codice dei metodi. Se fai modifiche al codice queste si ripercuotono anche sul modello. Questo perche' i due sono collegati in pratica. Certo per i plc non so se esistono strumenti di questo tipo, devo dar un'occhiata.