Modello UML(modello UML) è un insieme di un insieme finito di costrutti linguistici, il principale dei quali sono entità e relazioni tra di loro.
Le entità e le relazioni del modello stesso sono istanze delle metaclassi del metamodello.
Considerando il modello UML dalle posizioni più generali, possiamo dire che si tratta di un grafo (più precisamente un multi-pseudo-iper-digrafo caricato) in cui vengono caricati vertici e archi Informazioni aggiuntive e può avere una struttura interna complessa. I vertici di questo grafo sono chiamati entità e gli spigoli sono chiamati relazioni.. Il resto della sezione contiene un fluente (preliminare) ma recensione completa tipi di entità e relazioni disponibili. Fortunatamente, non ce ne sono molti. Nei capitoli successivi del libro, tutte le entità e le relazioni sono considerate nuovamente, in modo più dettagliato e con esempi.
Per comodità di panoramica, le entità in UML possono essere suddivise in quattro gruppi:
Le entità strutturali, come puoi immaginare, hanno lo scopo di descrivere la struttura. Tipicamente, le entità strutturali includono quanto segue.
Un oggetto(oggetto) 1 è un'entità che ha unicità e incapsula stato e comportamento.
Classe(classe) 2 - descrizione di un insieme di oggetti con attributi comuni che definiscono lo stato e le operazioni che definiscono il comportamento.
Interfaccia(interfaccia) 3 è un insieme denominato di operazioni che definisce un insieme di servizi che possono essere richiesti dal consumatore e forniti dal fornitore di servizi.
Cooperazione(collaborazione) 4 - un insieme di oggetti che interagiscono per raggiungere un obiettivo.
Attore(attore) 5 è un'entità che è al di fuori del sistema modellato e interagisce direttamente con esso.
∇ Tale relazione esiste certamente, espressa in Fig. Gerarchia dei tipi di diagramma per UML 1 come relazione di dipendenza con lo stereotipo "raffinato".
∇∇ In UML 1, c'era un'associazione involontaria tra un diagramma di collaborazione e un'entità con lo stesso nome, il che non era del tutto vero e talvolta fuorviante.
∇∇∇ In UML 2, il carico sintattico e semantico del diagramma di stato è cambiato così tanto che il nome non riflette più il contenuto.
Di seguito è riportato un elenco dei nuovi diagrammi e dei loro nomi adottati in questo libro.
Sulla fig. Gerarchia dei tipi di diagramma per UML 2 (Parte 1 e 2) un diagramma di classe che mostra la relazione dei diagrammi in UML 2.
Più avanti in questo capitolo, descriveremo molto brevemente tutti i tredici diagrammi canonici per avere un contesto e un vocabolario per ciò che segue. I dettagli sono esposti nei restanti capitoli del libro.
Ma prima di passare alla sezione successiva, facciamo una piccola digressione su come lo standard richiede la formattazione dei grafici. Il modello generale di presentazione del grafico è riportato di seguito.
Ci sono due elementi di design principali: una cornice esterna e un'etichetta con il nome del grafico. Se tutto è semplice con la cornice: è un rettangolo che delimita l'area in cui dovrebbero essere posizionati gli elementi del diagramma, quindi il nome del diagramma è scritto in un formato speciale mostrato in Fig. Notazione del grafico.
Questa complessa forma di tabulazione non è supportata da tutti gli strumenti. Tuttavia, questo non è necessario, poiché la semantica è primaria e la notazione è secondaria. In quanto segue, usiamo un rettangolo come etichetta del grafico, e questo non dovrebbe causare malintesi.
I possibili tag (tipi) per i grafici sono mostrati nella tabella seguente. I tag offerti dallo standard sono scritti nella seconda colonna. Tuttavia, come ha dimostrato la pratica, le regole proposte dalla norma non sono sempre convenienti e logicamente giustificate, pertanto la terza colonna della tabella contiene a nostro avviso un'alternativa ragionevole.
Scheda. Tipi di grafici e tag
| Titolo grafico | Etichetta (di serie) | Tagga (consigliato) |
|---|---|---|
| Diagramma di utilizzo | caso d'uso O u.c | caso d'uso |
| diagramma di classe | classe | classe |
| diagramma dell'automa | macchina statale O stm | macchina statale |
| diagramma di attività | attività O atto | attività |
| diagramma di sequenza | interazione O SD | SD |
| Diagramma di comunicazione | interazione O SD | comm |
| Diagramma dei componenti | componente O cmp | componente |
| Diagramma di posizionamento | indefinito | distribuzione |
| Diagramma oggetto | indefinito | oggetto |
| Schema della struttura interna | classe | classe O componente |
| Diagramma di panoramica dell'interazione | interazione O SD | interazione |
| Diagramma dei tempi | interazione O SD | tempismo |
| Schema del pacchetto | pacchetto O conf | pacchetto |
UML è ora la notazione standard per la modellazione visiva dei sistemi software, adottata dall'Object Managing Group (OMG) nell'autunno del 1997 e supportata da molti prodotti CASE orientati agli oggetti.
Lo standard UML offre il seguente set di diagrammi per la modellazione:
Diagramma dei casi d'uso (diagramma dei casi d'uso) - per modellare i processi aziendali di un'organizzazione o impresa e determinare i requisiti per il sistema informativo che si sta creando;
diagramma di classe (diagramma di classe) - per modellare la struttura statica delle classi di sistema e le relazioni tra di esse;
diagramma di comportamento del sistema (diagrammi di comportamento);
diagrammi di interazione;
Diagrammi di sequenza - per modellare il processo di messaggistica tra oggetti all'interno di un caso d'uso;
diagramma di collaborazione (diagramma di collaborazione) - per modellare il processo di messaggistica tra oggetti all'interno dello stesso caso d'uso;
diagramma di stato - per modellare il comportamento degli oggetti del sistema durante la transizione da uno stato all'altro;
diagramma di attività - per modellare il comportamento del sistema nell'ambito di vari casi d'uso o attività di modellazione;
diagramma di implementazione (diagrammi di implementazione):
Diagrammi dei componenti (diagrammi dei componenti) - per modellare la gerarchia dei componenti (sottosistemi) di un sistema informativo;
diagramma di distribuzione (diagramma di distribuzione) - per la modellazione architettura fisica sistema informativo progettato.
Sulla fig. 1.1 presenta un modello integrato del sistema informativo, inclusi i principali diagrammi da sviluppare in questo progetto di corso.
Riso. 1. Un modello integrato di un sistema informativo nella notazione del linguaggio UML
4.2. Diagramma dei casi d'uso
Un caso d'uso è una sequenza di azioni eseguite dal sistema in risposta a un evento attivato da un oggetto esterno (attore). Un caso d'uso descrive una tipica interazione tra un utente e un sistema. Nel caso più semplice, il caso d'uso è determinato nel processo di discussione con l'utente delle funzioni che vorrebbe implementare in questo sistema informativo. In UML, un caso d'uso è rappresentato come segue:
Fig.2. Caso d'uso
Un attore è un ruolo che un utente svolge in relazione al sistema. Gli attori rappresentano ruoli, non persone specifiche o titoli di lavoro. Sebbene siano raffigurati come figure umane stilizzate nei diagrammi dei casi d'uso, un attore può anche essere esterno. sistema informativo, che richiede alcune informazioni dal sistema specificato. Dovresti mostrare gli attori in un diagramma solo quando hanno davvero bisogno di alcuni casi d'uso. In UML, gli attori sono rappresentati come forme:
Fig.3. Personaggio (attore)
Gli attori sono divisi in tre tipi principali:
Utenti
sistemi;
Altri sistemi che interagiscono con questo;
Il tempo diventa un attore se da esso dipende l'innesco di qualsiasi evento nel sistema.
4.2.1. Relazioni tra casi d'uso e attori
In UML, i diagrammi dei casi d'uso supportano diversi tipi di relazioni tra gli elementi del diagramma:
Comunicazione (comunicazione),
Inclusione (includere),
estensione (estendere),
generalizzazione.
comunicazione comunicazioneè la relazione tra il caso d'uso e l'attore. In UML, i collegamenti di comunicazione vengono visualizzati utilizzando un'associazione unidirezionale (linea continua).
Fig.4. Esempio di collegamento di comunicazione
Connessione di inclusione utilizzato in situazioni in cui c'è un comportamento del sistema che si ripete in più di un caso d'uso. Con l'aiuto di tali collegamenti, di solito viene modellata una funzione riutilizzabile.
Collegamento di estensione utilizzato per descrivere i cambiamenti nel comportamento normale di un sistema. Consente l'uso facoltativo di un caso d'uso funzionalità un altro caso d'uso.
Fig.5. Un esempio di relazione di inclusione ed estensione
Generalizzazione della comunicazione indica che diversi attori o classi hanno proprietà comuni.
Fig.6. Un esempio di relazione di generalizzazione
4.3.
Diagrammi di interazione descrivere il comportamento di gruppi di oggetti interagenti. In genere, un diagramma di interazione copre solo il comportamento degli oggetti all'interno di un singolo caso d'uso. Tale diagramma mostra un numero di oggetti e i messaggi che si scambiano tra loro.
Messaggioè il mezzo con cui l'oggetto mittente richiede all'oggetto destinatario di eseguire una delle sue operazioni.
Messaggio informativo (informativo).è un messaggio che fornisce all'oggetto ricevente alcune informazioni per aggiornare il suo stato.
Messaggio di richiesta (interrogativo)è un messaggio che richiede l'output di alcune informazioni sull'oggetto destinatario.
Messaggio imperativoè un messaggio che chiede al destinatario di eseguire un'azione.
Esistono due tipi di diagrammi di interazione: diagrammi di sequenza e diagrammi di collaborazione.
4.3.1. Diagrammi di sequenza
diagramma di sequenza riflette il flusso di eventi che si verificano all'interno di un singolo caso d'uso.
Tutti gli attori (attori, classi o oggetti) coinvolti in un determinato scenario (caso d'uso) sono mostrati nella parte superiore del diagramma. Le frecce corrispondono ai messaggi passati tra un attore e un oggetto o tra oggetti per eseguire le funzioni richieste.
In un diagramma di sequenza, un oggetto è raffigurato come un rettangolo, dal quale viene tracciata una linea verticale tratteggiata verso il basso. Questa linea si chiama linea di vita di un oggetto . È un frammento del ciclo di vita di un oggetto nel processo di interazione.
Ogni messaggio è rappresentato come una freccia tra le linee di vita di due oggetti. I messaggi vengono visualizzati nell'ordine in cui appaiono sulla pagina dall'alto verso il basso. Ogni messaggio è contrassegnato con almeno il nome del messaggio. Facoltativamente, puoi anche aggiungere argomenti e alcune informazioni di controllo. Puoi mostrare l'autodelega, un messaggio che un oggetto invia a se stesso, con la freccia del messaggio che punta alla stessa linea di vita.
Riso. 7. Esempio di diagramma di sequenza
4.3.2. Diagramma di collaborazione
Diagrammi di cooperazione visualizzare il flusso di eventi all'interno di uno scenario specifico (caso d'uso). I messaggi sono ordinati per tempo, sebbene i diagrammi di collaborazione si concentrino maggiormente sulle relazioni tra gli oggetti. Un diagramma di collaborazione mostra tutte le informazioni di un diagramma di sequenza, ma un diagramma di collaborazione descrive il flusso degli eventi in modo diverso. Da esso è più facile capire le connessioni che esistono tra gli oggetti.
In un diagramma di collaborazione, proprio come in un diagramma di sequenza, le frecce rappresentano i messaggi che vengono scambiati all'interno del framework. questa opzione utilizzo. La loro sequenza temporale è indicata dalla numerazione dei messaggi.
Riso. 8. Un esempio di diagramma di cooperazione
4.4. diagramma di classe
4.4.1. informazioni generali
diagramma di classe definisce i tipi di classi di sistema e vari tipi di collegamenti statici che esistono tra di loro. I diagrammi di classe mostrano anche attributi di classe, operazioni di classe e vincoli posti sulle relazioni tra le classi.
Un diagramma di classe in UML è un grafo i cui nodi sono gli elementi della struttura statica del progetto (classi, interfacce), e gli archi sono le relazioni tra i nodi (associazioni, ereditarietà, dipendenze).
Il diagramma delle classi mostra i seguenti elementi:
· Pacchetto (pacchetto) - un insieme di elementi del modello, logicamente correlati tra loro;
· Classe (classe) - descrizione delle proprietà comuni di un gruppo di oggetti simili;
· Interfaccia (interfaccia) - una classe astratta che specifica un insieme di operazioni che un oggetto di una classe arbitraria associata a una data interfaccia fornisce ad altri oggetti.
4.4.2. Classe
Classeè un gruppo di entità (oggetti) che hanno proprietà simili, vale a dire dati e comportamento. Un singolo membro di una classe è chiamato un oggetto della classe, o semplicemente un oggetto.
Il comportamento di un oggetto in UML si riferisce a qualsiasi regola per l'interazione di un oggetto con il mondo esterno e con i dati dell'oggetto stesso.
Nei diagrammi, una classe è raffigurata come un rettangolo con un bordo pieno, diviso da linee orizzontali in 3 sezioni:
La sezione superiore (la sezione del nome) contiene il nome della classe e altre proprietà generali (in particolare, lo stereotipo).
La sezione centrale contiene un elenco di attributi
In fondo c'è un elenco di operazioni di classe che ne riflettono il comportamento (azioni eseguite dalla classe).
Nessuna delle sezioni degli attributi e delle operazioni potrebbe non essere mostrata (o entrambe). Per la sezione mancante non è necessario tracciare una linea di demarcazione e in qualche modo indicare la presenza o l'assenza di elementi al suo interno.
Sezioni aggiuntive, come Eccezioni, possono essere introdotte a discrezione di una particolare implementazione.
Riso. 9. Esempio di diagramma di classe
4.4.2.1.Stereotipi di classe
Gli stereotipi di classe sono un meccanismo per classificare le classi in categorie.
L'UML definisce tre principali stereotipi di classe:
Confine (confine);
Entità (entità);
Controllo (gestione).
4.4.2.2.Classi limite
Le classi limite sono quelle classi che si trovano sul confine del sistema e dell'intero ambiente. Si tratta di display, report, interfacce con hardware (come stampanti o scanner) e interfacce con altri sistemi.
Per trovare le classi limite, è necessario esplorare i diagrammi dei casi d'uso. Ogni interazione tra un attore e un caso d'uso deve avere almeno una classe limite. È questa classe che consente all'attore di interagire con il sistema.
4.4.2.3.Classi di entità
Le classi di entità contengono informazioni memorizzate. Hanno il massimo significato per l'utente, e quindi i loro nomi usano spesso termini dell'area tematica. Di solito, per ogni classe di entità, viene creata una tabella nel database.
4.4.2.4.Classi di controllo
Le classi di controllo sono responsabili del coordinamento delle azioni di altre classi. In genere, ogni caso d'uso ha una classe di controllo che controlla la sequenza di eventi per quel caso d'uso. La classe di controllo è responsabile del coordinamento, ma non porta alcuna funzionalità in sé, poiché le altre classi non la inviano un largo numero messaggi. Invece, lui stesso invia molti messaggi. La classe manager delega semplicemente la responsabilità ad altre classi, motivo per cui viene spesso definita classe manager.
Potrebbero esserci altre classi di controllo nel sistema comuni a diversi casi d'uso. Ad esempio, potrebbe esserci una classe SecurityManager responsabile del monitoraggio degli eventi relativi alla sicurezza. La classe TransactionManager gestisce il coordinamento dei messaggi relativi alle transazioni del database. Potrebbero esserci altri gestori che si occupano di altri elementi del funzionamento del sistema, come la condivisione delle risorse, l'elaborazione distribuita dei dati o la gestione degli errori.
Oltre agli stereotipi sopra menzionati, puoi crearne uno tuo.
4.4.2.5.Attributi
Un attributo è un'informazione associata a una classe. Gli attributi memorizzano i dati della classe incapsulati.
Poiché gli attributi sono contenuti all'interno della classe, sono nascosti alle altre classi. Per questo motivo, potrebbe essere necessario specificare quali classi hanno il diritto di leggere e modificare gli attributi. Questa proprietà è chiamata visibilità dell'attributo.
L'attributo può avere quattro possibili valori per questo parametro:
Pubblico (generale, aperto). Questo valore di visibilità presuppone che l'attributo sarà visibile a tutte le altre classi. Qualsiasi classe può visualizzare o modificare il valore di un attributo. In accordo con la notazione UML, un attributo comune è preceduto da un segno "+".
Privato (chiuso, segreto). L'attributo corrispondente non è visibile a nessun'altra classe. Un attributo privato è denotato da un segno "-" secondo la notazione UML.
Protetto (protetto). Tale attributo è disponibile solo per la classe stessa e per i suoi discendenti. La notazione UML per un attributo protetto è il segno "#".
Pacchetto o implementazione (batch). Supponiamo che l'attributo dato sia condiviso, ma solo all'interno del suo pacchetto. Questo tipo di visibilità non è indicato da alcuna icona speciale.
Con l'aiuto della chiusura o della sicurezza, è possibile evitare la situazione in cui il valore dell'attributo viene modificato da tutte le classi del sistema. Invece, la logica di modifica dell'attributo verrà racchiusa nella stessa classe dell'attributo stesso. Le opzioni di visibilità impostate influenzeranno il codice generato.
4.4.2.6.Operazioni
Le operazioni implementano il comportamento relativo alla classe. Un'operazione è composta da tre parti: un nome, parametri e un tipo restituito.
I parametri sono gli argomenti che l'operazione riceve come input. Il tipo restituito si riferisce al risultato dell'azione dell'operazione.
Un diagramma di classe può mostrare sia i nomi delle operazioni che i nomi delle operazioni insieme ai relativi parametri e al tipo restituito. Per ridurre il carico sul diagramma, è utile mostrare solo i nomi delle operazioni su alcuni di essi e la loro firma completa su altri.
In UML, le operazioni hanno la seguente notazione:
Nome operazione (argomento: tipo di dati argomento, argomento2: tipo di dati argomento2,...): tipo restituito
Ci sono quattro diversi tipi di operazioni da considerare:
Operazioni di attuazione;
Operazioni di gestione;
Operazioni di accesso;
Operazioni ausiliarie.
Operazioni di attuazione
Le operazioni dell'implementatore implementano alcune funzioni aziendali. Tali operazioni possono essere trovate esaminando i diagrammi di interazione. I diagrammi di questo tipo si concentrano sulle funzioni aziendali e ogni messaggio nel diagramma può molto probabilmente essere associato a un'operazione di implementazione.
Ogni operazione di implementazione deve essere facilmente riconducibile al requisito corrispondente. Ciò si ottiene in varie fasi della simulazione. L'operazione è derivata dal messaggio nel diagramma di interazione, i messaggi provengono dalla descrizione dettagliata del flusso di eventi, che viene generato in base al caso d'uso, e quest'ultimo in base ai requisiti. Essere in grado di tracciare l'intera catena aiuta a garantire che ogni requisito sia implementato nel codice e che ogni parte di codice implementi alcuni requisiti.
Operazioni di gestione
Le operazioni di gestione gestiscono la creazione e la distruzione degli oggetti. Costruttori e distruttori di classi rientrano in questa categoria.
Operazioni di accesso
Gli attributi sono solitamente privati o protetti. Tuttavia, altre classi a volte devono visualizzare o modificare i propri valori. Ci sono operazioni di accesso per questo. Questo approccio rende possibile incapsulare in modo sicuro gli attributi all'interno di una classe, proteggendoli da altre classi, ma consentendo comunque loro di esserlo accesso controllato. La creazione di operazioni Get e Set (ottenimento e modifica di un valore) per ogni attributo di una classe è uno standard.
Operazioni ausiliarie
Le operazioni ausiliarie (operazioni di supporto) sono quelle operazioni di una classe che sono necessarie per adempiere alle proprie responsabilità, ma di cui le altre classi non dovrebbero sapere nulla. Si tratta di operazioni di classe private e protette.
Per identificare le transazioni, procedere come segue:
1. Studia diagrammi di sequenza e diagrammi cooperativi. La maggior parte dei messaggi in questi diagrammi sono operazioni di implementazione. I messaggi riflessivi saranno operazioni ausiliarie.
2. Considerare le operazioni di controllo. Potrebbe essere necessario aggiungere costruttori e distruttori.
3. Considerare le operazioni di accesso. Per ogni attributo di classe con cui le altre classi dovranno lavorare, è necessario creare operazioni Get e Set.
4.4.2.7.Connessioni
Una relazione è una relazione semantica tra classi. Dà a una classe la capacità di conoscere gli attributi, le operazioni e le relazioni di un'altra classe. In altre parole, affinché una classe possa inviare un messaggio a un'altra in una sequenza o in un diagramma cooperativo, deve esistere una connessione tra di esse.
Esistono quattro tipi di relazioni che possono essere stabilite tra le classi: associazioni, dipendenze, aggregazioni e generalizzazioni.
Associazione di comunicazione
Un'associazione è una relazione semantica tra classi. Sono disegnati sul diagramma delle classi come una normale linea.
Riso. 10. Associazione di comunicazione
Le associazioni possono essere bidirezionali, come nell'esempio, o unidirezionali. In UML, le associazioni bidirezionali sono disegnate come una semplice linea senza frecce o con frecce su entrambi i lati della linea. Un'associazione unidirezionale ha una sola freccia che ne indica la direzione.
La direzione di un'associazione può essere determinata esaminando diagrammi di sequenza e diagrammi cooperativi. Se tutti i messaggi su di esse sono inviati da una sola classe e ricevuti solo da un'altra classe, ma non viceversa, c'è una comunicazione unidirezionale tra queste classi. Se almeno un messaggio viene inviato nella direzione opposta, l'associazione deve essere bidirezionale.
Le associazioni possono essere riflessive. Associazione riflessiva significa che un'istanza di una classe interagisce con altre istanze della stessa classe.
Dipendenza da comunicazione
Anche le relazioni di dipendenza riflettono la relazione tra le classi, ma sono sempre unidirezionali e mostrano che una classe dipende dalle definizioni fatte in un'altra. Ad esempio, la classe A utilizza metodi della classe B. Quindi, quando la classe B cambia, è necessario apportare modifiche corrispondenti alla classe A.
Una dipendenza è rappresentata da una linea tratteggiata tracciata tra due elementi del diagramma e si dice che l'elemento ancorato all'estremità di una freccia dipende dall'elemento ancorato all'inizio di quella freccia.
Riso. 11. Dipendenza dalla comunicazione
Quando si genera il codice per queste classi, non verranno aggiunti nuovi attributi. Tuttavia, verranno creati gli operatori specifici della lingua necessari per supportare la comunicazione.
Aggregazione della comunicazione
Le aggregazioni sono una forma più stretta di associazione. L'aggregazione è la connessione tra il tutto e la sua parte. Ad esempio, potresti avere una classe di auto, oltre a classi di motore, pneumatici e classi per altre parti di auto. Di conseguenza, un oggetto di classe Car sarà costituito da un oggetto di classe Engine, quattro oggetti di Tires, ecc. Le aggregazioni sono visualizzate come una linea con un rombo per una classe che è un numero intero:
Riso. 11. Aggregazione della comunicazione
Oltre alla semplice aggregazione, l'UML introduce una forma più forte di aggregazione chiamata composizione. Secondo la composizione, una parte dell'oggetto può appartenere solo a un unico insieme e, inoltre, di regola, il ciclo di vita delle parti coincide con il ciclo dell'intero: vivono e muoiono con esso. Qualsiasi rimozione del tutto si estende alle sue parti.
Questa cancellazione a cascata è spesso considerata parte della definizione di aggregazione, ma è sempre implicita quando la molteplicità dei ruoli è 1..1; ad esempio, se è necessario eliminare un cliente, tale eliminazione deve essere propagata agli ordini (e, a sua volta, alle righe d'ordine).
Penso che tutti abbiano sentito durante l'infanzia un detto come " Sette volte misura tagliata una volta". Nella programmazione è lo stesso. È sempre meglio pensare all'implementazione prima di passare il tempo a eseguirla. Spesso devi creare classi durante l'implementazione, inventare la loro interazione. E spesso una rappresentazione visiva di questo può aiutare a risolvere il problema nel modo più corretto È qui che aiutiamo UML.Se guardi le immagini in motori di ricerca, diventa chiaro che UML- si tratta di schemi, frecce e quadrati. Ciò che è importante è che UML si traduca come Linguaggio di modellazione unificato. La parola Unificato è importante qui. Cioè, le nostre immagini saranno comprese non solo da noi, ma anche da altri che conoscono UML. Si scopre che questa è una lingua così internazionale per disegnare diagrammi.
Come dice Wikipedia
UML è un linguaggio di descrizione grafica per la modellazione di oggetti in fase di sviluppo Software, modellazione dei processi aziendali, progettazione del sistema e visualizzazione delle strutture organizzative.La cosa più interessante a cui non tutti pensano o indovinano è che UML ha delle specifiche. Inoltre, esiste anche una specifica UML2. Ulteriori informazioni sulla specifica sono disponibili sul sito Web di Object Management Group. In realtà, questo gruppo è impegnato nello sviluppo delle specifiche UML. È anche interessante che UML non si limiti a descrivere la struttura delle classi. Esistono molti tipi di diagrammi UML. Una breve descrizione dei tipi di diagrammi UML può essere vista nella stessa Wikipedia: diagrammi UML o nel video di Timur Batyrshinov Panoramica dei diagrammi UML. UML è anche ampiamente utilizzato per descrivere vari processi, ad esempio qui: Single sign-on utilizzando JWT. Tornando all'uso dei diagrammi di classe UML, vale la pena notare il libro Head First: Design Patterns, in cui i modelli sono illustrati da quegli stessi diagrammi UML. Si scopre che l'UML viene effettivamente utilizzato. E si scopre che conoscere e comprendere la sua applicazione è un'abilità piuttosto utile.
Ma cosa succede se vuoi disegnare te stesso e anche se non esiste una versione definitiva di Idea? Se utilizziamo IntelliJ Idea Community Edition, non abbiamo altra scelta. Per fare ciò, devi capire come funziona un tale schema UML. Per prima cosa dobbiamo installare Graphviz . È un insieme di utilità di visualizzazione di grafici. Viene utilizzato dal plugin che useremo. Dopo l'installazione, è necessario aggiungere una directory bidone dalla directory installata graphviz ad una variabile di ambiente SENTIERO. Successivamente, in IntelliJ Idea, seleziona File -> Impostazioni dal menu. Nella finestra "Impostazioni", seleziona la categoria "Plugin", fai clic sul pulsante "Sfoglia repository" e installa il plug-in di integrazione PlantUML. Perché questo è così buono PlantUML? Usa per descrizioni UML un linguaggio di descrizione del grafico chiamato " punto" e questo gli permette di essere più universale, perché questo linguaggio è utilizzato non solo da PlantUML. Inoltre, tutto ciò che faremo di seguito può essere fatto non solo nell'IDE, ma anche nel servizio online planttext.com. Dopo aver installato il Plugin PlantUML, saremo in grado di creare diagrammi UML tramite "File" -> "Nuovo". Creiamo un diagramma del tipo "classe UML". Durante questo, viene generato automaticamente un modello con un esempio. Cancelliamo il suo contenuto e crea il nostro, armato di un articolo di Habr: Class Relations - from UML to code... E per capire come rappresentarlo nel testo, prendiamo il manuale PlantUML: plantuml class-diagram... In esso, alla fin dall'inizio, c'è un segno con come descrivere le relazioni:
A proposito delle connessioni stesse, possiamo ancora sbirciare qui: "Relazioni tra classi in UML. Esempi". Sulla base di questi materiali, iniziamo a creare il nostro diagramma UML. Aggiungi il seguente contenuto che descrive le due classi: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Per vedere il risultato in Idea, seleziona "View" -> "Tool Windows" -> "PlantUML". Otterremo solo due quadrati che denotano le classi. Come sappiamo, entrambe queste classi implementano l'interfaccia List. Questa relazione di classi è chiamata - implementazione (realizzazione). Una freccia con una linea tratteggiata viene utilizzata per rappresentare tale relazione. Disegniamolo: interfaccia List List< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о pacchetto privato element array: ~ Object elementData Ora vogliamo mostrare che l'ArrayList contiene alcuni oggetti. IN questo caso ci sarà un tipo di connessione - aggregazione(aggregazione). L'aggregato in questo caso è ArrayList , perché contiene altri oggetti. Scegliamo l'aggregazione perché gli oggetti nella lista possono vivere anche senza la lista: non ne sono parte integrante. La loro durata non è legata alla durata della lista. L'unità dal latino è tradotta come "raccolto", cioè qualcosa composto da qualcosa. Ad esempio, nella vita esiste un'unità di pompaggio, che consiste in una pompa e un motore. L'unità stessa può essere smontata, lasciando alcuni dei suoi componenti. Ad esempio, per vendere o inserire un'altra unità. Quindi è sulla lista. E questo si esprime sotto forma di un rombo vuoto all'unità e di una linea continua. Mettiamola così: class Object ( ) ArrayList o- Object Ora vogliamo mostrare che, a differenza di ArrayList , la classe LinkedList contiene Node - contenitori che fanno riferimento a dati memorizzati. In questo caso, i nodi fanno parte della stessa LinkedList e non possono vivere separatamente. Il nodo non è contenuto memorizzato direttamente, ma contiene solo un riferimento ad esso. Ad esempio, quando aggiungiamo una riga a LinkedList, aggiungiamo un nuovo nodo che contiene un collegamento a quella riga, nonché un collegamento al nodo precedente e successivo. Questo tipo di connessione è chiamato composizione(composizione). Per visualizzare un composto (uno che consiste di parti), viene disegnato un robic pieno, una linea continua conduce ad esso. Ora scriviamo questo come visualizzazione testuale del collegamento: class Node ( ) LinkedList * -- Node E ora dobbiamo imparare come visualizzare un altro importante tipo di collegamento - dipendenza(relazione di dipendenza). Viene utilizzato quando una classe ne utilizza un'altra, mentre la classe non contiene la classe utilizzata e non è il suo successore. Ad esempio, LinkedList e ArrayList possono creare un ListIterator . Visualizziamolo come frecce tratteggiate: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
Puoi dettagliare quanto ti serve. Tutte le designazioni sono elencate qui: "PlantUML - Class Diagram". Inoltre, non c'è nulla di soprannaturale nel disegnare un tale schema e quando lavori ai tuoi compiti, puoi disegnarlo rapidamente a mano. Ciò svilupperà le capacità per pensare attraverso l'architettura dell'applicazione e aiuterà a identificare i difetti della struttura della classe nella fase iniziale, e non dopo aver già trascorso una giornata a implementare il modello sbagliato. Penso che sia un buon motivo per provarlo?)
Poiché Maven non è al centro di questo articolo, le risposte alle tue domande su Maven sono disponibili nel Maven Users Center . Nel progetto generato, apri il file di descrizione del progetto per la modifica, pom.xml. Copiamo il contenuto dalla descrizione di uml-java-docklet che si installa al suo interno. L'artefatto utilizzato nella descrizione non è stato trovato nel repository Maven Central. Ma ha funzionato per me con questo: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0 . Cioè, in quella descrizione devi solo sostituire ID gruppo Con " info.leadinglight" SU " com.chfourie" e metti la versione " 1.0.0 ". Successivamente, possiamo eseguire nella directory in cui si trova il file pom.xml questi comandi sono: mvn clean install e mvn javadoc:javadoc . Ora, se apriamo la documentazione generata (explorer target\site\apidocs\index.html), vedremo i diagrammi UML. A proposito, l'implementazione è già visualizzata correttamente qui)
Tutti i diagrammi UML possono essere suddivisi condizionatamente in due gruppi, il primo dei quali è diagrammi generali. I diagrammi generali sono praticamente indipendenti dall'oggetto della modellazione e possono essere utilizzati in qualsiasi progetto software indipendentemente dall'area tematica, dall'area decisionale, ecc.
Diagramma di utilizzo(use case diagram) è la rappresentazione più generale dello scopo funzionale del sistema.
Il diagramma di utilizzo ha lo scopo di rispondere alla domanda principale di modellazione: cosa fa il sistema nel mondo esterno?
Nel diagramma d'uso vengono utilizzati due tipi di entità principali: i casi d'uso 1 e gli attori 2, tra i quali si stabiliscono i seguenti tipi principali di relazioni:
Un diagramma di utilizzo, come qualsiasi altro, può avere commenti 7 . Inoltre, si consiglia vivamente di eseguire questa operazione per migliorare la leggibilità dei grafici.
Di seguito sono riportati gli elementi principali della notazione utilizzata nel diagramma di utilizzo. Una descrizione dettagliata è fornita nella sezione 2.2.
diagramma di classe(diagramma delle classi) è il modo principale per descrivere la struttura del sistema.
Questo non è sorprendente, dal momento che l'UML è principalmente un linguaggio orientato agli oggetti e le classi sono il principale (se non l'unico) elemento costitutivo.
Sul diagramma delle classi viene utilizzato un tipo principale di entità: le classi 1 (inclusi numerosi casi speciali di classi: interfacce, tipi primitivi, classi di associazione e molti altri), tra i quali vengono stabiliti i seguenti tipi principali di relazioni:
Di seguito sono riportati alcuni elementi della notazione utilizzata nel diagramma delle classi. Una descrizione dettagliata è data nel capitolo 3 .
diagramma dell'automa(diagramma della macchina a stati) è uno dei modi per descrivere il comportamento in dettaglio nell'UML basato sull'allocazione esplicita degli stati e sulla descrizione delle transizioni tra gli stati.
In sostanza, i diagrammi degli automi, come suggerisce il nome, sono un grafico di transizione di stato (vedi Capitolo 4), caricato con molti dettagli e dettagli aggiuntivi.
Nel diagramma dell'automa viene utilizzato un tipo principale di entità - stati 1 e un tipo di relazioni - transizioni 2 , ma per entrambi vengono definite molte varietà, casi speciali e designazioni aggiuntive. Elencarli tutti in una recensione introduttiva non ha senso.
Una descrizione dettagliata di tutte le variazioni dei diagrammi degli automi è data nella sezione 4.2, e la figura seguente mostra solo gli elementi principali della notazione usata nel diagramma degli automi.
diagramma di attività(diagramma di attività) - un modo per descrivere il comportamento basato sull'indicazione dei flussi di controllo e dei flussi di dati.
Un diagramma di attività è un altro modo di descrivere il comportamento che ricorda visivamente un buon vecchio diagramma di flusso. Tuttavia, grazie alla notazione modernizzata, coerente con l'approccio orientato agli oggetti, e soprattutto, grazie alla nuova componente semantica (libera interpretazione delle reti di Petri), il diagramma di attività UML è un potente strumento per descrivere il comportamento del sistema.
Nel diagramma di attività viene utilizzato un tipo principale di entità - azione 1 e un tipo di relazione - transizioni 2 (trasferimenti di controllo e dati). Sono anche usate costruzioni come biforcazioni, fusioni, connessioni, diramazioni 3 , che sono simili alle entità, ma non lo sono realmente, ma sono un modo grafico di rappresentare alcuni casi speciali di relazioni a molti posti. La semantica degli elementi del diagramma di attività è discussa in dettaglio nel Capitolo 4. Di seguito sono riportati gli elementi principali della notazione utilizzata nel diagramma di attività.
diagramma di sequenza(sequence diagram) è un modo di descrivere il comportamento del sistema basato sull'indicazione della sequenza dei messaggi trasmessi.
Infatti, un diagramma di sequenza è una registrazione del protocollo di una particolare sessione del sistema (o un frammento di tale protocollo). Nella programmazione orientata agli oggetti, la cosa più essenziale in fase di esecuzione è il passaggio di messaggi tra oggetti cooperanti. È la sequenza di invio dei messaggi che viene visualizzata su questo diagramma, da cui il nome.
Nel diagramma di sequenza viene utilizzato un tipo principale di entità: istanze di classificatori interagenti 1 (principalmente classi, componenti e attori), e un tipo di relazione - le connessioni 2 , attraverso le quali vengono scambiati i messaggi 3 . Esistono diversi modi per inviare messaggi, che nella notazione grafica differiscono nella forma di una freccia corrispondente a una relazione.
Un aspetto importante del diagramma di sequenza è la visualizzazione esplicita del passare del tempo. A differenza di altri tipi di diagrammi, ad eccezione forse dei diagrammi di sincronizzazione, in un diagramma di sequenza, conta non solo la presenza di collegamenti grafici tra gli elementi, ma anche la posizione relativa degli elementi sul diagramma. Vale a dire, si considera che esista un asse temporale (invisibile), per impostazione predefinita diretto dall'alto verso il basso, e il messaggio che viene inviato successivamente è disegnato sotto.
L'asse del tempo può essere orientato orizzontalmente, nel qual caso si considera che il tempo scorra da sinistra a destra.
La figura seguente mostra gli elementi principali della notazione utilizzata in un diagramma di sequenza. Per designare gli stessi oggetti interagenti, viene utilizzata la notazione standard: un rettangolo con il nome di un'istanza di classificatore. La linea tratteggiata che ne esce è chiamata linea della vita (lifeline) 4 . Questa non è una designazione di una relazione nel modello, ma un commento grafico destinato a indirizzare il lettore del diagramma nella giusta direzione. Anche le figure sotto forma di strisce strette sovrapposte alla linea della vita non sono immagini di entità simulate. Questo è un commento grafico che mostra il periodo di tempo in cui un oggetto possiede un'occorrenza di esecuzione 5 o in altre parole ha luogo l'attivazione di un oggetto. Le fasi di interazione composta (frammento combinato) 6 consentono al diagramma di sequenza di riflettere gli aspetti algoritmici del protocollo di interazione. Si veda il Capitolo 4 per maggiori dettagli sulla notazione del diagramma di sequenza.
Diagramma di comunicazione(diagramma di comunicazione) - un modo di descrivere il comportamento, semanticamente equivalente a un diagramma di sequenza.
In effetti, questa è la stessa descrizione della sequenza di scambio di messaggi di istanze interagenti di classificatori, espressa solo con altri mezzi grafici. Inoltre, la maggior parte degli strumenti può convertire automaticamente i diagrammi di sequenza in diagrammi di comunicazione e viceversa.
Pertanto, nel diagramma di comunicazione, così come nel diagramma di sequenza, viene utilizzato un tipo principale di entità - istanze di classificatori interagenti 1 e un tipo di relazione - connessioni 2 . Tuttavia, qui l'enfasi non è sul tempo, ma sulla struttura delle relazioni tra istanze specifiche.
La figura mostra gli elementi principali della notazione utilizzata nel diagramma di comunicazione. Per designare gli stessi oggetti interagenti, viene utilizzata la notazione standard: un rettangolo con il nome di un'istanza di classificatore. La posizione reciproca degli elementi sul diagramma della cooperazione non ha importanza: sono importanti solo le connessioni (il più delle volte istanze di associazioni), lungo le quali vengono trasmessi i messaggi 3 . Per visualizzare l'ordine dei messaggi nel tempo, viene utilizzata la numerazione decimale gerarchica.
Diagramma dei componenti(schema dei componenti) - mostra la relazione tra i moduli (logici o fisici) che compongono il sistema simulato.
Il tipo principale di entità nel diagramma dei componenti sono i componenti stessi 1 , così come le interfacce 2 , attraverso le quali viene indicata la relazione tra i componenti. Nel diagramma dei componenti si applicano le seguenti relazioni:
La figura mostra gli elementi principali della notazione utilizzata nel diagramma dei componenti. Una descrizione dettagliata è data nel capitolo 3 .
Diagramma di posizionamento(diagramma di distribuzione), oltre a visualizzare la composizione e le relazioni degli elementi del sistema, mostra come sono posizionati fisicamente sulle risorse di elaborazione durante l'esecuzione.
Pertanto, nel diagramma di posizionamento, rispetto al diagramma dei componenti, vengono aggiunti due tipi di entità: artefatto 1 , che è l'implementazione del componente 2 e del nodo 3 (può essere un classificatore che descrive il tipo di nodo o un'istanza specifica), così come una relazione di associazione tra i nodi 4 , che indica che i nodi sono collegati fisicamente in fase di esecuzione.
La figura mostra gli elementi principali della notazione utilizzata nel diagramma di posizionamento. Per dimostrare che un'entità è parte di un'altra, viene utilizzata una relazione di dipendenza "deploy" 5 oppure la forma di un'entità viene inserita all'interno della forma di un'altra entità 6 . Una descrizione dettagliata del diagramma è fornita nel capitolo 3.
Il diagramma UML è un linguaggio di descrizione grafica specializzato progettato per la modellazione di oggetti nello sviluppo di vari software. Questo linguaggio ha un ampio profilo ed è uno standard aperto che utilizza varie notazioni grafiche per creare un modello astratto di un sistema. L'UML è stato creato per consentire la definizione, la visualizzazione, la documentazione e la progettazione di tutti i tipi di sistemi software. Vale la pena notare che il diagramma UML stesso non è un linguaggio di programmazione, ma prevede la possibilità di generare un codice separato basato su di esso.
L'uso di UML non si esaurisce con la modellazione di tutti i tipi di software. Inoltre, questo linguaggio viene utilizzato attivamente oggi per modellare vari processi aziendali, condurre la progettazione di sistemi e visualizzare strutture organizzative.
Con l'aiuto di UML, gli sviluppatori di software possono garantire un accordo completo nel formato simboli grafici presentare concetti generali, come: componente, generalizzazione, classe, comportamento e aggregazione. Questo raggiunge un maggior grado di concentrazione su architettura e design.
Vale anche la pena notare che esistono diversi tipi di tali grafici.
Un diagramma di classe UML è un diagramma di struttura statica progettato per descrivere la struttura di un sistema, oltre a mostrare gli attributi, i metodi e le dipendenze tra diverse classi.
Vale la pena notare il fatto che ci sono diversi punti di vista sulla costruzione di tali diagrammi, a seconda di come verranno utilizzati:
Il diagramma dei componenti UML è un diagramma a struttura completamente statica. Ha lo scopo di dimostrare la partizione di un certo sistema software in vari componenti strutturali, così come le connessioni tra di loro. Il diagramma dei componenti UML in quanto tale può utilizzare tutti i tipi di modelli, librerie, file, pacchetti, file eseguibili e molti altri elementi.
Anche il diagramma di struttura composito/composito UML è un diagramma di struttura statica, ma viene utilizzato per mostrare la struttura interna delle classi. Se possibile, questo diagramma può anche dimostrare l'interazione di elementi che si trovano nella struttura interna della classe.
Una sottospecie di questi è il diagramma di collaborazione UML, utilizzato per dimostrare i ruoli e le interazioni di diverse classi nell'ambito di una collaborazione. Sono abbastanza utili se devi modellare modelli di progettazione.
Vale la pena notare che i diagrammi di classe UML ei diagrammi a struttura composita possono essere utilizzati contemporaneamente.
Questo diagramma viene utilizzato per modellare i nodi in esecuzione, nonché tutti i tipi di artefatti che sono stati distribuiti su di essi. In UML 2, gli artefatti vengono distribuiti in vari nodi, mentre nella prima versione venivano distribuiti solo i componenti. Pertanto, il diagramma di distribuzione UML viene utilizzato principalmente per la seconda versione.
Si forma una dipendenza di manifestazione tra un artefatto e il componente che implementa.
Questa visualizzazione consente di visualizzare un'immagine completa o parziale. sistema creato in un certo momento. Visualizza completamente tutte le istanze delle classi di un particolare sistema, indicando i valori correnti dei loro parametri, nonché le relazioni tra di loro.
Questo diagramma è di natura strutturale e il suo contenuto principale è costituito da tutti i tipi di pacchetti, nonché dalle relazioni tra di essi. In questo caso, non esiste una netta separazione tra diversi diagrammi strutturali, per cui il loro uso è spesso utilizzato esclusivamente per comodità e non ha alcun significato semantico. Vale la pena notare che diversi elementi possono fornire altri diagrammi UML (esempi: pacchetti e diagrammi dei pacchetti stessi).
Il loro utilizzo viene effettuato per garantire l'organizzazione di più elementi in gruppi secondo un determinato attributo, al fine di semplificare la struttura, nonché per organizzare il lavoro con il modello di questo sistema.
Il diagramma di attività UML mostra la scomposizione di una particolare attività in più parti componenti. In questo caso, il concetto di "attività" si riferisce alla specifica di un determinato comportamento eseguibile sotto forma di esecuzione sequenziale parallela e coordinata di vari elementi subordinati - tipi di attività nidificati e varie azioni, uniti da flussi che vanno dal uscite di un certo nodo agli ingressi di un altro.
Il diagramma di attività UML viene spesso utilizzato per modellare vari processi aziendali, elaborazione parallela e sequenziale. Tra le altre cose, modellano tutti i tipi di procedure tecnologiche.
Questa vista è chiamata e in qualche modo diversa: il diagramma di stato UML. Ha una macchina a stati presentata con stati semplici e compositi, nonché transizioni.
Una macchina a stati finiti è una specifica di una sequenza di diversi stati attraverso i quali passa un certo oggetto, o un'interazione in risposta ad alcuni eventi della sua vita, così come la risposta di un oggetto a tali eventi. Viene assegnata la macchina a stati utilizzata dal diagramma di stato UML elemento genitore e viene utilizzato per definire il comportamento delle sue istanze.
I cosiddetti diagrammi del drago possono essere usati come analoghi di tali diagrammi.
Il diagramma dei casi d'uso UML mostra tutte le relazioni che si verificano tra gli attori, nonché i diversi casi d'uso. Il suo compito principale è fornire un mezzo completo con cui il cliente, l'utente finale o qualche sviluppatore possa discutere congiuntamente il comportamento e la funzionalità di un particolare sistema.
Se un diagramma dei casi d'uso UML viene utilizzato in un processo di modellazione del sistema, l'analista deve:
Se si sta sviluppando un diagramma di utilizzo in UML, la procedura inizia con una descrizione testuale, che si ottiene lavorando con il cliente. Allo stesso tempo, vale la pena notare che vari requisiti non funzionali sono completamente omessi nel processo di compilazione del modello dei casi d'uso e per essi sarà già formato un documento separato.
Il diagramma di comunicazione, proprio come il diagramma di sequenza UML, è transitivo, cioè esprime l'interazione, ma allo stesso tempo la dimostra. diversi modi e, se necessario, con il grado di precisione richiesto, è possibile convertire l'uno nell'altro.
Il diagramma di comunicazione riflette le interazioni che si verificano tra i vari elementi della struttura composita, così come i ruoli della cooperazione. La sua principale differenza rispetto al diagramma di sequenza è che indica chiaramente la relazione tra diversi elementi e il tempo non viene utilizzato come dimensione separata.
Questo tipo si distingue per un formato assolutamente libero di ordinare diversi oggetti e relazioni nello stesso modo in cui viene eseguito in un diagramma di oggetti. Se è necessario mantenere l'ordine dei messaggi in questo formato libero, vengono numerati cronologicamente. La lettura di questo diagramma inizia con il messaggio iniziale 1.0, e prosegue successivamente lungo la direzione in cui i messaggi vengono passati da un oggetto all'altro.
Per la maggior parte, tali diagrammi mostrano esattamente le stesse informazioni che ci fornisce un diagramma di sequenza, ma poiché utilizza un modo diverso di presentare le informazioni, alcune cose in un diagramma diventano molto più facili da determinare che in un altro. Vale anche la pena notare che un diagramma di comunicazione mostra più chiaramente con quali elementi interagisce ogni singolo elemento, mentre un diagramma di sequenza mostra più chiaramente in quale ordine vengono eseguite le interazioni.
Il diagramma di sequenza UML mostra le interazioni tra diversi oggetti, ordinati in base all'ora in cui si verificano. Tale diagramma mostra un'interazione ordinata nel tempo tra diversi oggetti. In particolare, visualizza tutti gli oggetti che prendono parte all'interazione, nonché la sequenza completa dei messaggi da essi scambiati.
Gli elementi principali in questo caso sono le designazioni di vari oggetti, nonché linee verticali, che rappresenta il passare del tempo e rettangoli che rappresentano l'attività di un oggetto particolare o l'esecuzione di una sua funzione.
Questo tipo di diagramma permette di mostrare le interazioni tra più oggetti, astraendo dalla sequenza di traduzione dei messaggi. Questo tipo di diagrammi in una forma compatta mostra assolutamente tutti i messaggi trasmessi e ricevuti di un determinato oggetto, nonché i formati di questi messaggi.
Poiché i diagrammi di sequenza e i diagrammi di comunicazione sono semplicemente viste diverse delle stesse procedure, Rational Rose offre la possibilità di creare un diagramma di sequenza di comunicazione da un diagramma di sequenza o viceversa e li sincronizza anche in modo completamente automatico.
Si tratta di diagrammi UML, che appartengono a un tipo di diagrammi di attività e includono sia elementi Sequence che costrutti di flusso di controllo.
Vale la pena notare il fatto che dato formato combina il diagramma di collaborazione e di sequenza, che offre l'opportunità di considerare l'interazione tra diversi oggetti nel sistema che si sta formando da diversi punti di vista.
Rappresenta Opzione alternativa diagramma di sequenza, che dimostra esplicitamente il cambiamento di stato sulla linea di vita con una certa scala temporale. Può essere molto utile in varie applicazioni in tempo reale.
Vale la pena notare diversi vantaggi che distinguono il diagramma di utilizzo UML e altri:
Nonostante il fatto che la costruzione di diagrammi UML abbia molti dei suoi vantaggi, sono spesso criticati per le seguenti carenze:
Pertanto, l'uso di questa lingua non è rilevante in tutte le situazioni.
