Caratteristiche generali del linguaggio UML. Tipi di diagrammi UML Tipi di diagrammi UML

Annotazione: L'argomento di questo corso è L'UML - Unified Modeling Language. Nella lezione precedente, abbiamo parlato di cos'è UML, della sua storia, scopo, modi di usare il linguaggio, struttura della sua definizione, terminologia e notazione. È stato notato che un modello UML è un insieme di diagrammi. In questa lezione considereremo queste domande: perché abbiamo bisogno di diversi tipi di diagrammi; tipi di diagrammi; OOP e diagramma di sequenza

Prima di passare alla discussione del materiale principale di questa lezione, parliamo del perché costruire dei diagrammi. Lo sviluppo di un modello di qualsiasi sistema (non solo software) precede sempre la sua creazione o aggiornamento. Questo è necessario almeno per immaginare più chiaramente il problema che viene risolto. I modelli ponderati sono molto importanti sia per l'interazione all'interno del team di sviluppo che per la comprensione reciproca con il cliente. Dopotutto, ti consente di assicurarti che il progetto sia "coerente dal punto di vista architettonico" prima che venga implementato nel codice.

Costruiamo modelli di sistemi complessi perché non possiamo descriverli completamente, "dare loro un'occhiata a colpo d'occhio". Pertanto, individuiamo solo le proprietà del sistema che sono essenziali per un compito particolare e costruiamo il suo modello che riflette queste proprietà. Il metodo dell'analisi orientata agli oggetti consente di descrivere nel modo più adeguato sistemi complessi reali. Ma man mano che i sistemi diventano più complessi, è necessaria una buona tecnologia di simulazione. Come abbiamo detto nella lezione precedente, un sistema unificato viene utilizzato come tecnologia "standard". linguaggio di modellazione(Unified Modeling Language, UML), che è un linguaggio grafico per la specifica, la visualizzazione, la progettazione e la documentazione dei sistemi. Usando UML, puoi sviluppare un modello dettagliato del sistema in fase di creazione, che riflette non solo il suo concetto, ma anche caratteristiche di implementazione specifiche. Nell'ambito del modello UML, tutte le rappresentazioni del sistema sono fissate sotto forma di speciali costruzioni grafiche dette diagrammi.

Nota. Non considereremo tutti, ma solo alcuni tipi di grafici. Ad esempio, il diagramma dei componenti non è trattato in questa lezione, che è solo una breve panoramica dei tipi di diagramma. Il numero di tipi di grafici per un particolare modello di applicazione non è limitato in alcun modo. Per applicazioni semplici, non è necessario creare diagrammi di tutti i tipi senza eccezioni. Alcuni di essi potrebbero semplicemente mancare e questo fatto non sarà considerato un errore. È importante capire che la disponibilità di diagrammi di un certo tipo dipende dalle specifiche di un particolare progetto. Le informazioni su altri tipi di diagrammi (non discussi qui) possono essere trovate nello standard UML.

Perché hai bisogno di più tipi di grafici

Innanzitutto, definiamo la terminologia. Nella prefazione a questa lezione, abbiamo utilizzato ripetutamente i concetti di sistema, modello e diagramma. L'autore è sicuro che ognuno di noi comprenda intuitivamente il significato di questi concetti, ma per chiarire completamente, esaminiamo nuovamente il glossario e leggiamo quanto segue:

Sistema- un insieme di sottosistemi controllati interconnessi uniti da un obiettivo comune di funzionamento.

Sì, non molto istruttivo. Che cos'è un sottosistema allora? Per chiarire la situazione, passiamo ai classici:

sistema chiamare un insieme di sottosistemi organizzati per raggiungere un obiettivo specifico e descritti utilizzando un insieme di modelli, possibilmente da diversi punti di vista.

Bene, non c'è niente che tu possa fare, devi cercare la definizione di un sottosistema. Lo dice anche lì sottosistemaè un insieme di elementi, alcuni dei quali specificano il comportamento di altri elementi. Ian Sommerville spiega il concetto in questo modo:

Sottosistemaè un sistema il cui funzionamento non dipende dai servizi di altri sottosistemi. Il sistema software è strutturato come un insieme di sottosistemi relativamente indipendenti. Vengono anche definite le interazioni tra i sottosistemi.

Inoltre non molto chiaro, ma migliore. Parlando in un linguaggio "umano", il sistema è rappresentato come un insieme di entità più semplici che sono relativamente autosufficienti. Questo può essere paragonato a come, nel processo di sviluppo di un programma, costruiamo un'interfaccia grafica da "cubi" standard - componenti visivi, o come il testo del programma stesso sia anche diviso in moduli che contengono subroutine che sono combinate secondo una funzione funzionalità e possono essere riutilizzati nei seguenti programmi.

Comprendere il concetto di sistema. Durante il processo di progettazione, viene considerato il sistema da diversi punti di vista con l'ausilio di modelli, le cui diverse rappresentazioni appaiono sotto forma di diagrammi. Anche in questo caso, il lettore potrebbe avere domande sul significato dei concetti Modelli e diagrammi. Pensiamo a una definizione bella, ma non molto chiara modelli come astrazione di un sistema semanticamente chiusoè improbabile che chiarisca la situazione, quindi proviamo a spiegare "con parole nostre".

Modello- questo è un certo oggetto (materiale o meno) che mostra solo le caratteristiche più significative del sistema per questo compito. I modelli sono diversi: tangibili e immateriali, artificiali e naturali, decorativi e matematici...

Facciamo alcuni esempi. Le macchinine di plastica familiari a tutti noi, che abbiamo giocato con tanta eccitazione durante l'infanzia, non sono altro che materiale artificiale decorativo modello di auto reale. Certo, in una tale "macchina" non c'è motore, non riempiamo il serbatoio di benzina, il cambio non funziona (inoltre, è del tutto assente), ma come modello, questo giocattolo soddisfa pienamente il suo funzioni: dà al bambino un'idea dell'auto, perché mostra i suoi tratti caratteristici sono la presenza di quattro ruote, una carrozzeria, porte, finestrini, la capacità di guidare, ecc.

Nella ricerca medica, i test sugli animali spesso precedono gli studi clinici sui farmaci nell'uomo. In questo caso, l'animale agisce come materiale naturale modelli umani.

Anche l'equazione mostrata sopra è un modello, ma questo è un modello matematico e descrive il movimento di un punto materiale sotto l'azione della gravità.

Resta solo da dire cos'è un diagramma. Diagrammaè una rappresentazione grafica di un insieme di elementi. Solitamente rappresentato come un grafico con vertici (entità) e spigoli (relazioni). Ci sono molti esempi di diagrammi. Questo è un diagramma a blocchi familiare a tutti noi dagli anni della scuola, e diagrammi di installazione per varie apparecchiature che possiamo vedere nei manuali dell'utente, e un albero di file e directory su un disco, che possiamo vedere eseguendo il comando tree nel Console Windows e molto altro ancora. Nella vita di tutti i giorni, i diagrammi ci circondano da tutti i lati, perché un'immagine è più facile da percepire per noi di un testo...

Ma torniamo alla progettazione del software (e non solo). In questo settore da allora tramite diagrammi è possibile visualizzare l'impianto da diversi punti di vista. Uno dei diagrammi, ad esempio, può descrivere l'interazione dell'utente con il sistema, l'altro - il cambiamento degli stati del sistema durante il suo funzionamento, il terzo - l'interazione tra gli elementi del sistema, ecc. Un complesso sistema può e deve essere rappresentato come un insieme di modelli - diagrammi piccoli e quasi indipendenti, e nessuno di essi è sufficiente per descrivere il sistema e avere un quadro completo di esso, poiché ciascuno di essi si concentra su un aspetto particolare del funzionamento del sistema sistema ed esprime un diverso livello di astrazione. In altre parole, ad ogni modello corrisponde un punto di vista specifico e particolare sull'impianto che si sta progettando.

Nonostante il fatto che nel paragrafo precedente fossimo molto sciolti con il concetto di modello, va inteso che nel contesto delle definizioni di cui sopra nessun singolo diagramma è un modello. I diagrammi sono solo un mezzo per visualizzare il modello e i due dovrebbero essere distinti. Solo un insieme di diagrammi costituisce un modello di sistema e lo descrive in modo più completo, ma non un diagramma preso fuori contesto.

Tipi di grafici

UML 1.5 definito dodici tipi di grafici diviso in tre gruppi:

• quattro tipi di diagrammi rappresentano la struttura statica dell'applicazione;
• cinque rappresentano gli aspetti comportamentali del sistema;
• tre rappresentano gli aspetti fisici del funzionamento del sistema (diagrammi di implementazione).

L'attuale versione di UML 2.1 non ha apportato troppe modifiche. I diagrammi sono leggermente cambiati nell'aspetto (sono apparsi frame e altri miglioramenti visivi), la notazione è leggermente migliorata, alcuni diagrammi hanno ricevuto nuovi nomi.

Tuttavia, il numero esatto schemi canoniciè assolutamente irrilevante per noi, poiché non li considereremo tutti, ma solo alcuni, poiché il numero di tipi di diagramma per un particolare modello di una particolare applicazione non è strettamente fisso. Per applicazioni semplici, non è necessario creare tutti i diagrammi senza eccezioni. Ad esempio, per un'applicazione locale, non è necessario creare un diagramma di distribuzione. È importante capire che l'elenco dei diagrammi dipende dalle specifiche del progetto in fase di sviluppo ed è determinato dallo stesso sviluppatore. Se il lettore curioso volesse ancora conoscere tutti i diagrammi UML, lo rimanderemo allo standard UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Ricordiamo che lo scopo di questo corso non è descrivere assolutamente tutte le possibilità dell'UML, ma solo introdurre questo linguaggio, per dare un'idea iniziale di questa tecnologia.

Quindi, esamineremo brevemente tipi di grafici come:

• diagramma caso d'uso;
• diagramma di classe;
• diagramma dell'oggetto;
• diagramma di sequenza;
• diagramma di interazione;
• diagramma di stato;
• diagramma di attività;
• diagramma di distribuzione.

Parleremo di alcuni di questi diagrammi in modo più dettagliato nelle prossime lezioni. Per ora non ci concentreremo sui dettagli, ma ci poniamo l'obiettivo di insegnare al lettore a distinguere almeno visivamente tra le tipologie di diagrammi, per dare una prima idea dello scopo delle principali tipologie di diagrammi. Quindi, iniziamo.

Usa diagramma caso

Eventuali sistemi (anche software) sono progettati tenendo conto del fatto che nel corso del loro lavoro verranno utilizzati da persone e/o interagiranno con altri sistemi. Vengono chiamate le entità con cui il sistema interagisce nel corso del suo lavoro attori e ogni attore si aspetta che il sistema si comporti in modo prevedibile e rigorosamente definito. Proviamo a dare una definizione più rigorosa di ector. Per fare ciò, utilizziamo un meraviglioso vocabolario visivo per UML Zicom mentore:

Ettore (attore)- questo è un insieme di ruoli logicamente correlati svolti durante l'interazione con precedenti o entità (sistema, sottosistema o classe). Un attore può essere una persona o un altro sistema, sottosistema o classe che rappresenta qualcosa al di fuori dell'entità.

Graficamente, il vettore è rappresentato o " piccolo uomo", simili a quelli che abbiamo disegnato durante l'infanzia, raffiguranti membri della nostra famiglia, o simbolo di classe con stereotipo corrispondente, come mostrato nell'immagine. Entrambe le forme di presentazione hanno lo stesso significato e possono essere utilizzate nei diagrammi. La forma "stereotipata" è più spesso utilizzata per rappresentare attori del sistema o nei casi in cui l'attore ha proprietà che devono essere visualizzate (Fig. 2.1).

Il lettore attento può immediatamente porre la domanda: Perché Hector e non un attore?? Siamo d'accordo, la parola "ektor" taglia un po' l'orecchio di un russo. Il motivo per cui diciamo questo è semplice: l'ector è formato dalla parola azione, che significa in traduzione azione. La traduzione letterale della parola "ektor" - attore- troppo lungo e scomodo da usare. Pertanto, continueremo a dirlo.

Riso. 2.1.

Lo stesso attento lettore potrebbe notare la parola "precedente" balenata nella definizione dell'ector. Che cos'è? Questa domanda ci interesserà ancora di più se ricordiamo che ora stiamo parlando diagramma caso d'uso. Così,

Precedente (caso d'uso)- descrizione di un particolare aspetto del comportamento del sistema dal punto di vista dell'utente (Butch).

La definizione è abbastanza comprensibile ed esaustiva, ma può essere ulteriormente affinata utilizzando la stessa Zicom mentore"Om:

caso d'uso- descrizione dell'insieme degli eventi successivi (comprese le varianti) eseguiti dal sistema che portano al risultato osservato dall'attore. Un caso d'uso rappresenta il comportamento di un'entità descrivendo l'interazione tra gli attori e il sistema. Un precedente non mostra "come" si ottiene un certo risultato, ma solo "che cosa" è.

I precedenti sono indicati in un modo molto semplice - sotto forma di un'ellisse, all'interno della quale è indicato il suo nome. Casi d'uso e attori sono collegati con linee. Spesso a un'estremità della linea raffigurano riso. 2.3

formazione dei requisiti generali per il comportamento del sistema in progettazione;

sviluppo di un modello concettuale del sistema per il suo successivo dettaglio;

predisposizione della documentazione per l'interazione con i clienti e gli utenti del sistema.

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 la seguente serie di diagrammi per la modellazione:

Diagramma del caso d'uso (diagramma del caso d'uso) - per modellare i processi aziendali di un'organizzazione o impresa e determinare i requisiti per il sistema informativo in fase di creazione;

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 del diagramma di stato - per modellare il comportamento degli oggetti di 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 attuazione (schemi di attuazione):

Diagrammi dei componenti (diagrammi dei componenti) - per modellare la gerarchia dei componenti (sottosistemi) di un sistema informativo;

diagramma di distribuzione (diagramma di distribuzione) - per modellare l'architettura fisica del sistema informativo progettato.

Sulla fig. 1.1 presenta un modello integrato del sistema informativo, comprensivo dei principali schemi da sviluppare in questo progetto del corso.

Riso. 1. Un modello integrato di un sistema informativo nella notazione del linguaggio UML

4.2. Diagramma del caso 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 rappresentati come figure umane stilizzate nei diagrammi dei casi d'uso, un attore può anche essere un sistema informativo esterno che necessita di alcune informazioni dal sistema. 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 eventi 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 di 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 è presente un comportamento del sistema ripetuto in più di un caso d'uso. Con l'aiuto di tali collegamenti, di solito viene modellata una funzione riutilizzabile.

Collegamento di estensione usato per descrivere i cambiamenti nel comportamento normale di un sistema. Consente a un caso d'uso di utilizzare la funzionalità di un altro caso d'uso quando necessario.

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 attraverso il quale 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 aggiornarne lo 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 alcune azioni.

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 è rappresentato come un rettangolo, dal quale viene tracciata una linea verticale tratteggiata verso il basso. Questa linea è chiamata ancora di salvezza 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 in base al 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 di eventi in un modo diverso. Da esso è più facile capire le connessioni che esistono tra gli oggetti.

In un diagramma di collaborazione, come in un diagramma di sequenza, le frecce rappresentano i messaggi che vengono scambiati all'interno di un determinato caso d'uso. 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. Informazione Generale

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 gli attributi di classe, le operazioni di classe e i vincoli posti sulle relazioni tra 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, eredità, dipendenze).

Il diagramma di classe 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 determinata interfaccia fornisce ad altri oggetti.

4.4.2. Classe

Classeè un gruppo di entità (oggetti) che hanno proprietà simili, ovvero 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 fa riferimento a qualsiasi regola per l'interazione di un oggetto con il mondo esterno e con i dati dell'oggetto stesso.

Nei diagrammi, una classe è rappresentata 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 riflettono il suo comportamento (azioni eseguite dalla classe).

Nessuna delle sezioni degli attributi e delle operazioni potrebbe non essere visualizzata (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 stereotipi di classe principali:

Confine (confine);

Entità (entità);

Controllo (gestione).

4.4.2.2.Classi di confine

Le classi limite sono quelle classi che si trovano al 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 archiviate. Hanno il significato più grande 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 delle 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 ha alcuna funzionalità in sé, poiché le altre classi non le inviano un gran numero di 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 di tuoi.

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 conformità 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 è indicato da un segno "-" in conformità con 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 carattere "#".

Pacchetto o implementazione (batch). Si supponga che l'attributo specificato 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. Al contrario, la logica di modifica dell'attributo verrà racchiusa nella stessa classe dell'attributo stesso. Le opzioni di visibilità impostate influiranno sul 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 alcune di esse e la loro firma completa su altre.

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ò essere molto probabilmente associato a un'operazione di implementazione.

Ogni operazione di attuazione deve essere facilmente riconducibile al corrispondente requisito. Ciò si ottiene in varie fasi della simulazione. L'operazione è derivata dal messaggio nel diagramma di interazione, i messaggi sono derivati ​​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 pezzo di codice implementi alcuni requisiti.

Operazioni di gestione

Le operazioni del gestore gestiscono la creazione e la distruzione degli oggetti. I costruttori di classi e i distruttori rientrano in questa categoria.

Operazioni di accesso

Gli attributi sono generalmente privati ​​o protetti. Tuttavia, altre classi a volte devono visualizzare o modificare i propri valori. Ci sono operazioni di accesso per questo. Questo approccio consente di incapsulare in modo sicuro gli attributi all'interno di una classe, proteggendoli da altre classi, ma consentendo comunque l'accesso controllato ad essi. La creazione di operazioni Get e Set (ottenimento e modifica di un valore) per ciascun 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 sue responsabilità, ma di cui le altre classi non dovrebbero sapere nulla. Si tratta di operazioni di classe private e protette.

Per identificare le transazioni, procedi come segue:

1. Studia i diagrammi di sequenza e i 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 invii un messaggio a un'altra in una sequenza o in un diagramma cooperativo, deve esserci una connessione tra di loro.

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 di classe come una linea ordinaria.

Riso. 10. Associazione di comunicazione

Le associazioni possono essere bidirezionali, come nell'esempio, o unidirezionali. Nell'UML, le associazioni bidirezionali vengono tracciate come una semplice linea senza frecce o con frecce su entrambi i lati della linea. Un'associazione unidirezionale ha solo una freccia che ne mostra la direzione.

La direzione di un'associazione può essere determinata esaminando diagrammi di sequenza e diagrammi cooperativi. Se tutti i messaggi su di essi vengono inviati solo da una classe e ricevuti solo da un'altra classe, ma non viceversa, c'è una comunicazione unidirezionale tra queste classi. Se almeno un messaggio viene inviato in direzione opposta, l'associazione deve essere bidirezionale.

Le associazioni possono essere riflessive. L'associazione riflessiva significa che un'istanza di una classe interagisce con altre istanze della stessa classe.

Dipendenza dalla comunicazione

Le relazioni di dipendenza riflettono anche 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 i metodi della classe B. Quindi, quando la classe B cambia, è necessario apportare le modifiche corrispondenti nella classe A.

Una dipendenza è rappresentata da una linea tratteggiata tracciata tra due elementi del diagramma e si dice che l'elemento ancorato alla fine di una freccia dipende dall'elemento ancorato all'inizio di quella freccia.

Riso. 11. Dipendenza dalla comunicazione

Durante la generazione del codice per queste classi, non verranno aggiunti nuovi attributi. Tuttavia, verranno creati gli operatori specifici della lingua necessari per supportare la comunicazione.

Aggregazione comunicativa

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 Auto, oltre a classi Motore, Pneumatici e classi per altre parti di automobili. Di conseguenza, un oggetto della classe Car sarà composto da un oggetto della classe Engine, quattro oggetti di Tyres, ecc. Le aggregazioni sono visualizzate come una linea con un rombo per una classe che è un intero:

Riso. 11. Aggregazione comunicativa

Oltre alla semplice aggregazione, l'UML introduce una forma più forte di aggregazione chiamata composizione. Secondo la composizione, una parte-oggetto può appartenere solo a un tutto unico e, inoltre, di regola, il ciclo vitale delle parti coincide con il ciclo del tutto: con esso vivono e muoiono. L'eventuale 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, l'eliminazione deve essere propagata agli Ordini (e, a loro volta, alle Righe d'ordine).

L'UML è un linguaggio di modellazione grafica generico per la specifica, la visualizzazione, la progettazione e la documentazione di tutti gli artefatti creati nello sviluppo di sistemi software.

Ci sono molti buoni libri che descrivono in dettaglio l'UML (a volte anche molto dettagliato), vorrei raccogliere in un unico posto i concetti di base su diagrammi, entità e relazioni tra di loro per un rapido richiamo, qualcosa come un cheat sheet.

La nota utilizza materiali di libri: Ivanov D. Yu., Novikov FA Linguaggio di modellazione unificato UML e Leonenkov. Esercitazione UML.

Cominciamo con l'editor. Sotto Linux, ho provato diversi editor UML, soprattutto mi è piaciuto UMLet, sebbene sia scritto in Java, si muove molto rapidamente e la maggior parte degli spazi vuoti delle entità sono al suo interno. C'è anche ArgoUML, un editor UML multipiattaforma, anch'esso scritto in Java, ricco di funzionalità, ma più lento.

Mi sono fermato a UMlet, installarlo sotto Arch Linux e ubuntu:

# sotto Arch Linux yaourt -S umlet # sotto Ubuntu sudo apt-get install umlet

In UML, tutte le entità possono essere suddivise nei seguenti tipi:

• strutturale;
• comportamentale;
• raggruppamento;
• annotativo;

L'UML utilizza quattro tipi principali di relazioni:

Dipendenza- indica che la modifica dell'entità indipendente influisce in qualche modo sull'entità dipendente. Graficamente, una relazione di dipendenza è rappresentata come una linea tratteggiata con una freccia che punta dall'entità dipendente all'entità indipendente.

Associazione- avviene se un'entità è direttamente correlata ad un'altra (o ad altre - l'associazione può essere non solo binaria). Graficamente, un'associazione è rappresentata come una linea continua con varie aggiunte che collegano le entità correlate.

Generalizzazioneè una relazione tra due entità, una delle quali è un caso particolare (specializzato) dell'altra. Graficamente, la generalizzazione è rappresentata come una linea con una freccia triangolare vuota all'estremità, diretta dal particolare (sottoclasse) al generale (superclasse).

Implementazioni- la relazione di implementazione indica che un'entità è l'implementazione di un'altra. Graficamente, l'implementazione è rappresentata come una linea tratteggiata con una freccia triangolare non riempita all'estremità, diretta dall'entità implementante a quella implementata.

A UML 2 definito 13 tipi di grafici. Per standard, ogni grafico dovrebbe avere una cornice con un rettangolo (angolo in basso a destra smussato) nell'angolo in alto a sinistra, che indica l'ID del grafico (tag) e il titolo.

Diagrammi per rappresentare la struttura del sistema:

• Schema dei componenti (schema dei componenti, tag componente);
• Diagramma di distribuzione (diagramma di distribuzione, tag distribuzione);
• Diagramma di classe (diagramma di classe, tag classe);
• Diagramma oggetto (diagramma oggetto, tag oggetto);
• Diagramma della struttura interna (diagramma della struttura composita, tag classe);

Diagrammi per rappresentare il comportamento del sistema:

• Diagramma di sincronizzazione (diagramma di interazione, tag tempismo);
• Diagramma di attività (diagramma di attività, tag attività);
• diagramma di sequenza (diagramma di sequenza, tag sd);
• Diagramma di comunicazione (diagramma di comunicazione, tag com);
• Diagramma dell'automazione (diagramma della macchina a stati, tag macchina a stati);
• Diagramma della panoramica dell'interazione, tag interazione);

Spiccano le classifiche:

• Diagramma caso d'uso (diagramma caso d'uso, tag caso d'uso);
• Schema del pacchetto (schema del pacchetto, tag pacchetto);

Diagramma di utilizzo

Diagramma di utilizzo(Diagramma caso d'uso) è la rappresentazione più generale dello scopo funzionale del sistema.

Considerando un diagramma di casi d'uso come un modello di un sistema, lo si può associare a un modello di scatola nera. Ogni caso d'uso definisce una sequenza di azioni che devono essere eseguite dal sistema progettato quando interagisce con l'attore corrispondente.

Il diagramma d'uso utilizza due tipi di entità di base: casi d'uso e attori, tra i quali vengono stabiliti i seguenti tipi di base di relazioni.

relazione di associazione- Questa relazione stabilisce quale ruolo specifico svolge un attore quando interagisce con un'istanza di un caso d'uso. Una relazione di associazione è indicata da una linea continua tra l'attore e il caso d'uso. Questa riga può avere simboli aggiuntivi, come ad esempio un nome e una molteplicità.

Relazione di estensione- definisce la relazione tra le istanze di un singolo caso d'uso con un caso d'uso più generale, le cui proprietà sono determinate in base al modo in cui queste istanze vengono combinate insieme. Pertanto, se esiste una relazione di estensione dal caso d'uso A al caso d'uso B, significa che le proprietà di un'istanza del caso d'uso B possono essere integrate a causa della presenza di proprietà nel caso d'uso esteso A.

Una relazione di estensione tra casi d'uso è indicata da una linea tratteggiata con una freccia (caso di relazione di dipendenza) che punta lontano dal caso d'uso che è un'estensione del caso d'uso originale.

Relazione di generalizzazione serve a indicare il fatto che alcuni casi d'uso A possono essere generalizzati al caso d'uso B. In questo caso, il caso d'uso A sarà una specializzazione del caso d'uso B. In questo caso, B è chiamato antenato o genitore di A e usa A è un discendente dell'uso di casi d'uso di V.

Graficamente, questa relazione è rappresentata da una linea continua con una freccia triangolare aperta che punta al caso d'uso padre.

Viene utilizzata una relazione di generalizzazione tra i casi d'uso quando è necessario notare che i casi d'uso figlio hanno tutti gli attributi e i comportamenti dei casi d'uso padre.

Relazione di inclusione tra due casi d'uso indica che un comportamento specificato per un caso d'uso è incluso come componente nella sequenza di comportamento di un altro caso d'uso.

Una relazione di inclusione, dal caso d'uso A al caso d'uso B, indica che ogni istanza del caso d'uso A include le proprietà funzionali specificate per il caso d'uso B.

Graficamente, questa relazione è rappresentata da una linea tratteggiata con una freccia (variante della relazione di dipendenza) che punta dal caso d'uso di base al caso d'uso incluso.

diagramma di classe

diagramma di classe(diagramma di classe) - il modo principale per descrivere la struttura statica del sistema.

Il diagramma delle classi utilizza un tipo principale di entità: le classi (inclusi numerosi casi speciali di classi: interfacce, tipi primitivi, classi di associazione, ecc.), tra le quali si stabiliscono i seguenti tipi principali di relazioni: dipendenze, associazioni, generalizzazioni, implementazioni.

Relazione di dipendenza generalmente indica una relazione semantica tra due elementi del modello o due insiemi di tali elementi che non è una relazione di associazione, generalizzazione o implementazione. Una relazione di dipendenza viene utilizzata in una situazione in cui alcune modifiche in un elemento del modello potrebbero richiedere una modifica in un altro elemento del modello dipendente.

Una relazione di dipendenza è rappresentata graficamente da una linea tratteggiata tra gli elementi corrispondenti con una freccia a un'estremità, con la freccia che punta dalla classe client della dipendenza alla classe indipendente o di origine.

Parole chiave speciali (stereotipi) possono essere posizionate sopra la freccia:

• "access" - serve per indicare la disponibilità degli attributi pubblici e delle operazioni della classe sorgente per le classi client;
• "bind" - la classe client può utilizzare alcuni modelli per la sua successiva parametrizzazione;
• "derivare" - ​​gli attributi della classe client possono essere calcolati dagli attributi della classe sorgente;
• "import" - gli attributi pubblici e le operazioni della classe sorgente diventano parte della classe client, come se fossero dichiarati direttamente in essa;
• "perfeziona" - indica che la classe client funge da perfezionamento della classe di origine per motivi storici, quando ulteriori informazioni diventano disponibili nel corso del lavoro sul progetto.

relazione di associazione corrisponde alla presenza di qualche relazione tra le classi. Questa relazione è indicata da una linea continua con simboli speciali aggiuntivi che caratterizzano le proprietà individuali di una particolare associazione. Come caratteri speciali aggiuntivi, è possibile utilizzare il nome dell'associazione, nonché i nomi e la molteplicità delle classi di ruolo dell'associazione. Il nome di un'associazione è un elemento facoltativo della sua designazione.

Relazione di aggregazione si verifica tra più classi se una delle classi è un'entità che include altre entità come componenti. Viene utilizzato per rappresentare relazioni di sistema del tipo "parte-intero".

Relazione di composizioneè un caso speciale di una relazione di aggregazione. Questa relazione serve a mettere in evidenza una forma speciale del rapporto parte-tutto in cui le parti costituenti sono in un certo senso all'interno del tutto. La specificità del rapporto tra loro sta nel fatto che le parti non possono agire isolatamente dal tutto, cioè con la distruzione del tutto vengono distrutte anche tutte le sue parti costituenti.

Relazione di generalizzazioneè una relazione tra un elemento più generale (genitore o antenato) e un elemento più specifico o speciale (figlio o discendente). Applicata a un diagramma di classe, questa relazione descrive la struttura gerarchica delle classi e l'ereditarietà delle loro proprietà e del loro comportamento. Ciò presuppone che la classe discendente abbia tutte le proprietà e il comportamento della classe antenata e abbia anche proprietà e comportamenti propri che non sono presenti nella classe antenata.

diagramma di automazione

diagramma di automazione(diagramma della macchina a stati) o diagramma di stato in UML 1 (diagramma del diagramma di stato) è un modo per descrivere il comportamento in dettaglio in UML. In sostanza, i diagrammi di automa, come suggerisce il nome, sono un grafico di stati e transizioni di un automa finito caricato con molti dettagli e dettagli aggiuntivi.

Il diagramma di stato descrive il processo di modifica degli stati di una sola classe, o meglio, un'istanza di una determinata classe, ovvero modella tutti i possibili cambiamenti nello stato di un particolare oggetto. In questo caso, un cambiamento nello stato di un oggetto può essere causato da influenze esterne di altri oggetti o dall'esterno. È per descrivere la reazione di un oggetto a tali influenze esterne che vengono utilizzati diagrammi di stato.

Nel diagramma dell'automa viene utilizzato un tipo principale di entità - stati e un tipo di relazione - transizioni, ma per entrambi vengono definite molte varietà, casi speciali e designazioni aggiuntive. L'automa rappresenta gli aspetti dinamici del sistema simulato sotto forma di un grafo orientato, i cui vertici corrispondono a stati e gli archi corrispondono a transizioni.

Stato inizialeè un caso speciale di uno stato che non contiene azioni interne (pseudo-stati). L'oggetto è in questo stato per impostazione predefinita al momento iniziale. Serve ad indicare sul diagramma di stato dell'area grafica da cui inizia il processo di cambiamento degli stati.

Finale (finale) uno stato è un caso speciale di uno stato che non contiene azioni interne (pseudo-stati). L'oggetto sarà in questo stato per impostazione predefinita dopo il completamento dell'automa all'ora della fine.

diagramma di attività

Quando si modella il comportamento di un sistema progettato o analizzato, diventa necessario non solo presentare il processo di modifica dei suoi stati, ma anche dettagliare le caratteristiche dell'implementazione algoritmica e logica delle operazioni eseguite dal sistema.

diagramma di attività(diagramma di attività) è un altro modo per descrivere il comportamento che assomiglia visivamente a un buon vecchio diagramma di flusso di un algoritmo. Utilizzato per simulare il processo di esecuzione delle operazioni.

La direzione principale dell'utilizzo dei diagrammi di attività è visualizzare le caratteristiche dell'implementazione delle operazioni di classe, quando è necessario presentare algoritmi per la loro esecuzione.

Nel diagramma di attività viene utilizzato un tipo principale di entità - azione e un tipo di relazione - transizioni (trasferimenti di controllo). Vengono utilizzate anche costruzioni come biforcazioni, fusioni, connessioni, diramazioni. Si consiglia di utilizzare un verbo con parole esplicative come nome di un'azione semplice.

diagramma di sequenza

diagramma di sequenza(diagramma di sequenza) è un modo per descrivere il comportamento del sistema "tramite esempi".

In effetti, 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 (principalmente classi, componenti e attori) e un tipo di relazione - collegamenti attraverso i quali vengono scambiati i messaggi.

Possibili tipi di messaggi (immagine tratta da larin.in):

Diagramma di comunicazione

Diagramma di comunicazione(diagramma di comunicazione) - un modo per 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.

Pertanto, nel diagramma di comunicazione, così come nel diagramma di sequenza, viene utilizzato un tipo principale di entità: istanze di classificatori interagenti e un tipo di relazione: le connessioni. Tuttavia, qui l'enfasi non è sul tempo, ma sulla struttura delle relazioni tra istanze specifiche.

Diagramma dei componenti

Diagramma dei componenti(diagramma dei componenti) - mostra la relazione tra i moduli (logici o fisici) che compongono il sistema simulato.

Il tipo di entità principale in un diagramma dei componenti sono i componenti stessi, così come le interfacce, attraverso le quali viene indicata la relazione tra i componenti. Nel diagramma dei componenti si applicano le seguenti relazioni:

• implementazioni tra componenti e interfacce (il componente implementa l'interfaccia);
• dipendenze tra componenti e interfacce (un componente utilizza un'interfaccia);

Diagramma di posizionamento

Diagramma di posizionamento(diagramma di distribuzione), oltre a visualizzare la composizione e le relazioni degli elementi del sistema, mostra come sono fisicamente posizionati sulle risorse di calcolo durante l'esecuzione.

Nel diagramma di posizionamento, rispetto al diagramma dei componenti, vengono aggiunti due tipi di entità: un artefatto, che è un'implementazione del componente e un nodo (può essere un classificatore che descrive il tipo di nodo o un'istanza specifica) , nonché una relazione di associazione tra nodi, che mostra che i nodi sono fisicamente connessi in fase di esecuzione.

Diagramma di oggetti

Diagramma di oggetti(diagramma oggetto) - è un'istanza di un diagramma di classe.

Nel diagramma degli oggetti viene utilizzato un tipo principale di entità: gli oggetti (istanze di classe), tra i quali sono indicate relazioni specifiche (il più delle volte istanze di associazione). I diagrammi di oggetti sono di natura ausiliaria - in effetti, questi sono esempi (si potrebbe dire, dump di memoria) che mostrano quali oggetti esistono e le relazioni tra loro in un particolare momento del funzionamento del sistema.

Schema della struttura interna(diagramma della struttura composita) viene utilizzato per una presentazione più dettagliata dei classificatori strutturali, principalmente classi e componenti.

Un classificatore strutturale viene visualizzato come un rettangolo con il nome del classificatore in alto. All'interno ci sono parti. Potrebbero esserci più parti. Le parti possono interagire tra loro. Ciò è indicato da connettori di vario genere. Il punto sul bordo esterno della parte a cui è collegato il connettore è chiamato porta. Le porte si trovano anche sul confine esterno del classificatore strutturale.

Diagramma di panoramica dell'interazione(diagramma di panoramica dell'interazione) è una sorta di diagramma di attività con una sintassi estesa: i collegamenti alle interazioni (uso dell'interazione) definiti da diagrammi di sequenza possono fungere da elementi di un diagramma di interazione panoramica.

Grafico dei tempi

Grafico dei tempi(diagramma temporale) è una forma speciale di diagramma di sequenza, in cui viene prestata particolare attenzione al cambiamento degli stati di varie istanze di classificatori e alla loro sincronizzazione temporale.

Schema del pacchetto

Schema del pacchetto(diagramma a pacchetto) è l'unico strumento che permette di gestire la complessità del modello stesso.

Gli elementi principali della notazione sono i pacchetti e le dipendenze con vari stereotipi.

Modello entità-relazione (modello ER)

analogico diagrammi di classe(UML) può essere modello ER, che viene utilizzato nella progettazione di database (modello relazionale).

Il modello entità-relazione (ER-model) è un modello di dati che consente di descrivere gli schemi concettuali dell'area disciplinare. Il modello ER viene utilizzato nella progettazione di database di alto livello (concettuale). Con il suo aiuto, puoi evidenziare le entità chiave e designare le relazioni che possono essere stabilite tra queste entità. wikipedia

Qualsiasi frammento dell'area tematica può essere rappresentato come un insieme di entità, tra le quali esiste un certo insieme di relazioni.

Concetti basilari:

Essenza(entità) è un'entità che può essere identificata in un modo che la distingue da altre entità, ad esempio, CLIENTE 777. Un'entità è in realtà un insieme di attributi.

Insieme di entità(insieme di entità) - un insieme di entità dello stesso tipo (con le stesse proprietà).

Connessione(relazione) è un'associazione stabilita tra più entità.

Dominio(dominio) - insieme di valori (dominio) dell'attributo.

Esistono tre tipi di collegamenti binari:

• uno a uno- una singola istanza di un'entità di una classe è associata ad una singola istanza di un'entità di un'altra classe, ad esempio HEAD - DEPARTMENT;
• da 1 a n o uno a molti- una singola istanza di un'entità di una classe è associata a molte istanze di un'entità di un'altra classe, ad esempio DEPARTMENT - EMPLOYEE;
• N a M o molti a molti- molte istanze di un'entità di una classe sono associate a molte istanze di un'entità di un'altra classe, ad esempio EMPLOYEE - PROJECT;
Glossario dei concetti di base in UML

oggetto- un'entità che ha un'unicità e incapsula lo stato e il comportamento.

classe- una descrizione di un insieme di oggetti con attributi comuni che definiscono lo stato e le operazioni che definiscono il comportamento.

interfaccia- un insieme denominato di operazioni che definisce un insieme di servizi che possono essere richiesti dal consumatore ed erogati dal prestatore di servizi.

Cooperazione- un insieme di oggetti che interagiscono per raggiungere un determinato obiettivo.

Attore- un'entità che è al di fuori del sistema modellato e interagisce direttamente con esso.

componente- una parte modulare del sistema con un insieme ben definito di interfacce richieste e fornite.

Artefatto- un elemento di informazione che viene utilizzato o generato nel processo di sviluppo del software. In altre parole, un artefatto è un'unità fisica di implementazione derivata da un elemento del modello (come una classe o un componente).

Nodo- una risorsa informatica su cui gli artefatti vengono collocati e, se necessario, eseguiti.

Le entità comportamentali hanno lo scopo di descrivere il comportamento. Ci sono solo due entità comportamentali di base: stato e azione.

stato- un periodo nel ciclo di vita di un oggetto, in cui l'oggetto soddisfa una determinata condizione e svolge la propria attività o attende il verificarsi di un evento.

azione- calcolo atomico primitivo.

Macchinaè un pacchetto che definisce un insieme di concetti necessari per rappresentare il comportamento dell'entità modellata come uno spazio discreto con un numero finito di stati e transizioni.

classificatoreè un descrittore per un insieme di oggetti dello stesso tipo.

Lettura extra

• Fowler M. UML. Fondamenti, 3a edizione
• Butch G., Rambo D., Jacobson I. Linguaggio UML. Manuale utente

UML è l'acronimo di Unified Modeling Language. In effetti, è una delle tecniche di modellazione dei processi aziendali più popolari ed è una notazione standard internazionale per specificare, visualizzare e documentare lo sviluppo del software. Definito dal gruppo di gestione degli oggetti, è emerso come risultato di diversi sistemi di notazione UML aggiuntivi ed è ora diventato lo standard de facto per la modellazione visiva. Il principio fondante di qualsiasi programmazione orientata agli oggetti inizia con la costruzione del modello.

L'UML è stato creato dal caos attorno allo sviluppo del software e alla documentazione. Negli anni '90 c'erano diversi modi di rappresentare i sistemi software. C'era bisogno di un modo UML visivo più unificato per rappresentare questi sistemi e, di conseguenza, è stato sviluppato tra il 1994 e il 1996 da tre ingegneri del software che lavoravano presso Rational Software. Successivamente è stato adottato come standard nel 1997 ed è rimasto tale fino ad oggi con pochi aggiornamenti.

Fondamentalmente, UML è un linguaggio di modellazione generico nel campo dello sviluppo software. Tuttavia, ora ha trovato la sua strada nella documentazione di diversi processi aziendali o flussi di lavoro, come i diagrammi di attività. Il tipo di diagramma UML può essere utilizzato in sostituzione dei diagrammi di flusso. Forniscono sia un modo più standardizzato per modellare i flussi di lavoro sia un'ampia gamma di funzionalità per migliorare la leggibilità e l'efficienza.

L'architettura si basa su un meta-oggetto, che definisce le basi per la creazione del linguaggio UML. È abbastanza preciso da creare un'intera applicazione. Un UML completamente eseguibile può essere distribuito su più piattaforme utilizzando diverse tecnologie con tutti i processi durante l'intero ciclo di sviluppo del software.

UML è progettato per consentire agli utenti di sviluppare un linguaggio di modellazione visiva. Supporta concetti di sviluppo di alto livello come strutture, modelli e collaborazioni. UML è una raccolta di elementi come:

1. Affermazioni sul linguaggio di programmazione.
2. Gli attori descrivono il ruolo svolto dall'utente o da qualsiasi altro sistema che interagisce con l'oggetto.
3. Attività da svolgere per l'esecuzione del contratto di lavoro e da presentare in schemi.
4. Un processo aziendale che include un insieme di attività che creano un servizio specifico per i clienti, visualizzato da un diagramma di flusso di azioni sequenziali.
5. Componenti software logici e riutilizzabili.

I diagrammi UML si dividono in due categorie. Il primo tipo include sette tipi di diagrammi che rappresentano informazioni strutturali, il secondo - i restanti sette rappresentano tipi generali di comportamento. Questi diagrammi vengono utilizzati per documentare l'architettura dei sistemi e sono direttamente coinvolti nella modellazione UML del sistema.

I diagrammi UML sono presentati come rappresentazioni statiche e dinamiche del modello di sistema. La vista statica include diagrammi di classe e struttura composita che enfatizzano la struttura statica. La vista dinamica rappresenta l'interazione tra gli oggetti e le modifiche negli stati interni degli oggetti utilizzando sequenze, attività e diagrammi di stato.

È disponibile un'ampia varietà di strumenti di modellazione UML per semplificare la modellazione, inclusi IBM Rose, Rhapsody, MagicDraw, StarUML, ArgoUML, Umbrello, BOUML, PowerDesigner e Dia.

L'uso di UML ha varie forme sia nella documentazione di sviluppo del software che nei processi aziendali:

1. Schizzo. In questo caso, i diagrammi UML vengono utilizzati per trasmettere vari aspetti e caratteristiche di un sistema. Tuttavia, questa è solo una vista di primo livello del sistema e molto probabilmente non includerà tutti i dettagli necessari per portare a termine il progetto fino alla fine.
2. Forward Design - Il design dello schizzo viene eseguito prima che l'applicazione venga codificata. Questo viene fatto per una migliore panoramica del sistema o del flusso di lavoro che l'utente sta tentando di creare. È possibile identificare molti problemi o carenze di progettazione, che miglioreranno la salute generale e il benessere del progetto.
3. Design inverso. Una volta scritto il codice, i diagrammi UML vengono visualizzati come una forma di documentazione per varie attività, ruoli, contributori e flussi di lavoro.
4. Planimetria. In questo caso, il diagramma funge da costrutto completo che richiede solo l'effettiva implementazione del sistema o del software. Questo viene spesso fatto utilizzando gli strumenti CASE (Computer Aided Software Engineering Tools). Il principale svantaggio dell'utilizzo degli strumenti CASE è che richiedono un certo livello di conoscenza, formazione degli utenti, gestione e personale.

UML non è un linguaggio di programmazione autonomo come Java, C++ o Python, tuttavia, con gli strumenti giusti, può trasformarsi in uno pseudo linguaggio di programmazione UML. Per raggiungere questo obiettivo, l'intero sistema deve essere documentato in diversi diagrammi e, utilizzando il software giusto, i diagrammi possono essere tradotti direttamente in codice. Questo metodo può essere utile solo se il tempo impiegato per disegnare i diagrammi richiede meno tempo rispetto alla scrittura del codice effettivo. Anche se UML è stato creato per la modellazione del sistema, ha trovato diversi usi nelle aree aziendali.

Di seguito è riportato un esempio di diagramma UML per la modellazione aziendale.

Una soluzione pratica sarebbe rappresentare visivamente il flusso di processo per le televendite attraverso un diagramma di attività. Dal momento in cui l'ordine viene preso come input, fino al momento in cui l'ordine viene completato e viene fornito uno specifico output.

Esistono diversi tipi di diagrammi UML e ognuno di essi svolge un'attività diversa, sia che venga sviluppato prima dell'implementazione o dopo, come parte della documentazione. Le due categorie più ampie che coprono tutti gli altri tipi sono il diagramma di comportamento e il diagramma di struttura. Come suggerisce il nome, alcuni diagrammi UML tentano di analizzare e rappresentare la struttura di un sistema o processo, mentre altri descrivono il comportamento del sistema, dei suoi partecipanti e dei componenti.

Le diverse tipologie sono così suddivise:

1. Non tutti i 14 diversi tipi di diagrammi UML vengono utilizzati regolarmente durante la documentazione di sistemi e architetture.
2. Il principio di Pareto si applica anche all'uso dei diagrammi UML.
3. Il 20% dei diagrammi viene utilizzato dagli sviluppatori l'80% delle volte.

Gli elementi più comunemente usati nello sviluppo del software sono:

• diagrammi di utilizzo;
• diagrammi di classe;
• sequenze.

Diagrammi di attività - I diagrammi UML più importanti per la creazione di modelli di processi aziendali. Nello sviluppo del software, vengono utilizzati per descrivere il flusso di varie attività. Possono essere seriali o paralleli. Descrivono gli oggetti utilizzati, consumati o prodotti da un'attività e la relazione tra le diverse attività.

Tutto quanto sopra è essenziale per modellare i processi aziendali che portano l'uno all'altro, poiché sono interconnessi con un inizio e una fine chiari. In un ambiente aziendale, questo viene anche definito mappatura dei processi aziendali. Gli attori principali sono l'autore, editore ed editore. Un esempio di UML è il seguente. Quando un revisore esamina un progetto e decide che è necessario apportare alcune modifiche. L'autore quindi rivede la bozza e la restituisce nuovamente per analizzare la revisione.

Diagramma di utilizzo

La pietra angolare del sistema - utilizzata per analizzare i requisiti per il livello di sistema. Questi requisiti sono espressi in diversi casi d'uso. I tre componenti principali di un diagramma UML sono:

1. Funzionale: presentato come casi d'uso.
2. Un verbo che descrive un'azione.
3. Attori - per interagire con il sistema. Gli attori possono essere utenti, organizzazioni o un'attestazione esterna. Le relazioni tra i partecipanti sono rappresentate da frecce diritte.

Ad esempio, per il diagramma di gestione delle scorte. In questo caso, c'è un proprietario, un fornitore, un manager, uno specialista dell'inventario e un ispettore dell'inventario. I contenitori rotondi rappresentano le azioni che gli attori compiono. Possibili azioni: acquistare e pagare azioni, controllare la qualità delle azioni, restituire azioni o distribuire azioni.

Questo tipo di diagramma è adatto per mostrare il comportamento dinamico tra i partecipanti a un sistema, semplificandone la presentazione senza rivelare dettagli di implementazione.

Temporaneo

I diagrammi temporali UML vengono utilizzati per rappresentare le relazioni tra oggetti quando il focus dipende dal tempo. In questo caso, non è interessante come gli oggetti interagiscono o si modificano tra loro, ma l'utente vuole immaginare come oggetti e soggetti agiscano lungo un asse temporale lineare.

Ogni singolo partecipante è rappresentato attraverso una linea di vita, che è essenzialmente una linea che forma fasi mentre un singolo partecipante si sposta da una fase all'altra. L'attenzione principale è rivolta alla durata del tempo degli eventi e ai cambiamenti che si verificano a seconda di esso.

I componenti principali di un diagramma temporale sono:

1. Lifeline è un membro individuale.
2. Cronologia degli stati: l'unico percorso di vita può attraversare diversi stati all'interno di un processo.
3. Vincolo di durata: un vincolo di intervallo di tempo che rappresenta la durata del vincolo richiesto per essere soddisfatto.
4. Limite di tempo - Limitare l'intervallo di tempo durante il quale qualcosa deve essere eseguito da un membro.
5. Destruction Emergence - La comparsa di un messaggio che distrugge un singolo membro e descrive la fine del ciclo di vita di quel membro.

I diagrammi orizzontali, detti anche diagrammi di stato, vengono utilizzati per descrivere i vari stati di un componente all'interno di un sistema. Prende il formato del nome finale perché il diagramma è essenzialmente una macchina che descrive i molteplici stati di un oggetto e come cambia in base a eventi interni ed esterni.

Un diagramma di stato macchina molto semplice sarebbe in una partita di scacchi. Un tipico gioco di scacchi consiste in mosse fatte dal Bianco e mosse fatte dal Nero. Il bianco ha la prima mossa, dando così inizio al gioco. La fine del gioco può aver luogo indipendentemente dal fatto che il Bianco o il Nero vincano. La partita può terminare con una partita, con le dimissioni o con un pareggio (diversi stati dell'auto). I diagrammi di stato vengono utilizzati principalmente nella progettazione UML diretta e inversa di vari sistemi.

Sequenziale

Questo tipo di diagramma è il diagramma UML più importante non solo nella comunità informatica, ma anche come modello a livello di progettazione per lo sviluppo di applicazioni aziendali. Sono popolari nella descrizione dei processi aziendali grazie alla loro natura visivamente autoesplicativa. Come suggerisce il nome, i diagrammi descrivono la sequenza di messaggi e interazioni che avvengono tra soggetti e oggetti. Attori o oggetti possono essere attivi solo quando necessario o quando un altro oggetto vuole comunicare con loro. Tutte le comunicazioni sono presentate in ordine cronologico.

Per ulteriori informazioni, vedere l'esempio di diagramma di sequenza UML riportato di seguito.

Come segue dall'esempio, i diagrammi strutturali vengono utilizzati per mostrare la struttura di un sistema. Più specificamente, il linguaggio viene utilizzato nello sviluppo del software per rappresentare l'architettura di un sistema e come sono correlati i diversi componenti.

Il diagramma di classe UML è il tipo più comune di diagramma per la documentazione del software. Poiché la maggior parte del software attualmente in fase di scrittura è ancora basato sul paradigma della programmazione orientata agli oggetti, l'utilizzo di diagrammi di classe per documentare il software è di buon senso. Questo perché OOP si basa sulle classi UML e sulle relazioni tra di esse. In poche parole, i grafici contengono classi, insieme ai loro attributi, chiamati anche campi dati, e ai loro comportamenti, chiamati funzioni membro.

Nello specifico, ogni classe ha 3 campi: nome in alto, attributi subito sotto il nome, operazioni/comportamento in basso. La relazione tra classi diverse (rappresentate da una linea di collegamento) costituisce un diagramma di classe. L'esempio sopra mostra un diagramma di classe di base.

Oggetti

Quando si discute di diagrammi di struttura UML, è necessario approfondire i concetti relativi all'informatica. Nell'ingegneria del software, le classi sono considerate tipi di dati astratti mentre gli oggetti sono istanze.Ad esempio, se esiste "Car" che è un tipo astratto generico, l'istanza della classe "Car" sarebbe "Audi".

I diagrammi di oggetti UML aiutano gli sviluppatori di software a verificare se la struttura astratta generata è una struttura praticabile quando implementata nella pratica, ovvero quando vengono creati gli oggetti. Alcuni sviluppatori considerano questo un livello secondario di controllo dell'accuratezza. Visualizza le istanze di classe. Più precisamente, la classe generica "Client" ha ora un client effettivo, ad esempio chiamato "James". James è un'istanza di una classe più generale e ha gli stessi attributi, tuttavia, con determinati valori. Lo stesso è stato fatto con il conto Conti e Risparmio. Sono entrambi oggetti delle rispettive classi.

Distribuzioni

I diagrammi di distribuzione vengono utilizzati per visualizzare la relazione tra software e hardware. Per essere più specifici, con i diagrammi di distribuzione è possibile creare un modello fisico di come i componenti software (artefatti) vengono distribuiti ai componenti hardware noti come nodi.

Un tipico schema di distribuzione semplificato per un'applicazione Web include:

1. Nodi (server di applicazioni e server di database).
2. Diagramma degli artefatti dell'applicazione client e del database.

Il diagramma del pacchetto è simile alle macro per i diagrammi UML di distribuzione spiegati sopra. Vari pacchetti contengono nodi e artefatti. Raggruppano diagrammi e modellano i componenti in gruppi, proprio come uno spazio dei nomi incapsula nomi diversi che sono in qualche modo correlati. Infine, il pacchetto può essere creato anche da molti altri pacchetti per rappresentare sistemi e comportamenti più complessi.

Lo scopo principale di un diagramma a pacchetto è mostrare le relazioni tra i vari componenti di grandi dimensioni che compongono un sistema complesso. I programmatori trovano che questa astrazione sia un buon vantaggio per l'uso dei diagrammi di pacchetto, specialmente quando alcuni dettagli possono essere omessi dall'immagine.

Come ogni altra cosa nella vita, per fare qualcosa di giusto, hai bisogno degli strumenti giusti. Per documentare software, processi o sistemi, utilizza strumenti che offrono annotazioni UML e modelli di diagramma. Esistono vari strumenti di documentazione del software che possono aiutare a disegnare il diagramma.

In genere rientrano nelle seguenti categorie principali:

1. Carta e penna è facile. Prendi carta e penna, apri il codice di sintassi UML dal Web e disegna qualsiasi tipo di diagramma desideri.
2. Strumenti online - Esistono diverse applicazioni online che possono essere utilizzate per creare un grafico. La maggior parte di essi offre un abbonamento a pagamento o un numero limitato di diagrammi nel livello gratuito.
3. Gli strumenti online gratuiti sono quasi gli stessi di quelli a pagamento. La differenza principale è che quelli a pagamento offrono anche tutorial e modelli già pronti per diagrammi specifici.
4. Applicazione desktop: l'applicazione desktop tipica da utilizzare per i diagrammi e per qualsiasi altro diagramma è Microsoft Visio. Offre caratteristiche e funzionalità avanzate. L'unico inconveniente è che devi pagare per questo.

Pertanto, è chiaro che l'UML è un aspetto importante associato allo sviluppo di software orientato agli oggetti. Utilizza la notazione grafica per creare modelli visivi di programmi di sistema.

Il diagramma UML è un linguaggio di descrizione grafica specializzato progettato per la modellazione di oggetti nello sviluppo di vari software. Questo linguaggio ha un profilo ampio 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, visualizzazione, documentazione e 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.

Perché è necessaria?

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 del sistema e visualizzare le strutture organizzative.

Con l'aiuto di UML, gli sviluppatori di software possono garantire il pieno accordo nella notazione grafica utilizzata per rappresentare concetti comuni come: componente, generalizzazione, classe, comportamento e aggregazione. In questo modo si ottiene un maggior grado di concentrazione su architettura e design.

Vale anche la pena notare che esistono diversi tipi di tali grafici.

diagramma di classe

Un diagramma di classe UML è un diagramma di struttura statico 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:

• Concettuale. In questo caso, il diagramma delle classi UML descrive il modello di un'area tematica specifica e fornisce solo classi di oggetti dell'applicazione.
• Specifico. Il diagramma viene utilizzato nel processo di progettazione di vari sistemi informativi.
• Implementazione. Il diagramma delle classi include tutti i tipi di classi che vengono utilizzate direttamente nel codice del programma.

Diagramma dei componenti

Il diagramma del componente UML è un diagramma della struttura completamente statico. Ha lo scopo di dimostrare la scomposizione di un particolare sistema software in vari componenti strutturali, nonché le relazioni tra di loro. Un diagramma componente UML può utilizzare tutti i tipi di modelli, librerie, file, pacchetti, eseguibili e molti altri elementi in quanto tali.

Diagramma della struttura composita/composita

Anche il diagramma della struttura composita/composita UML è un diagramma della 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, che viene 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 e i diagrammi di struttura composita possono essere utilizzati contemporaneamente.

Diagramma di distribuzione

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 dalla manifestazione tra un artefatto e il componente che implementa.

Diagramma di oggetti

Questa visualizzazione consente di visualizzare un'istantanea completa o parziale del sistema in fase di creazione in un determinato 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.

Schema del pacchetto

Questo diagramma è di natura strutturale e il suo contenuto principale sono tutti i tipi di pacchetti, nonché le relazioni tra di essi. In questo caso, non esiste una separazione rigorosa 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 elementi diversi possono fornire altri diagrammi UML (esempi: pacchetti e diagrammi di pacchetto stessi).

Il loro utilizzo viene effettuato al fine di garantire l'organizzazione di più elementi in gruppi secondo un determinato attributo, al fine di semplificare la struttura, nonché di organizzare il lavoro con il modello di questo sistema.

diagramma di attività

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 specificazione di un determinato comportamento eseguibile sotto forma di esecuzione sequenziale parallela e coordinata di vari elementi subordinati - tipi nidificati di attività e varie azioni, uniti da flussi che vanno dal output di un certo nodo agli input 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.

diagramma di automazione

Questa vista è chiamata e in modo leggermente diverso: diagramma di stato UML. Ha una macchina a stati presentata con stati semplici e compositi, nonché transizioni.

Una macchina a stati è una specifica di una sequenza di stati diversi attraverso i quali passa un determinato oggetto, o un'interazione in risposta ad alcuni eventi della sua vita, così come la risposta di un oggetto a tali eventi. La macchina a stati utilizzata dal diagramma di stato UML è collegata all'elemento originale e utilizzata per definire il comportamento delle sue istanze.

I cosiddetti diagrammi del drago possono essere usati come analoghi di tali diagrammi.

Usa i diagrammi dei casi

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 attraverso il quale il cliente, l'utente finale o qualche sviluppatore possono discutere congiuntamente il comportamento e la funzionalità di un particolare sistema.

Se un diagramma di caso d'uso UML viene utilizzato in un processo di modellazione del sistema, l'analista dovrà:

• Separare chiaramente il sistema da modellare dal suo ambiente.
• Identificare gli attori, le modalità della loro interazione con questo sistema, nonché la sua funzionalità prevista.
• Impostare nel glossario come area disciplinare vari concetti che si riferiscono a una descrizione dettagliata della funzionalità di questo sistema.

Se si sta sviluppando un diagramma di utilizzo nell'UML, la procedura inizia con una descrizione testuale, che si ottiene lavorando con il cliente. Allo stesso tempo, vale la pena notare il fatto che vari requisiti non funzionali vengono completamente omessi nel processo di compilazione del modello di caso d'uso e per essi sarà già formato un documento separato.

Comunicazioni

Il diagramma di comunicazione, proprio come il diagramma di sequenza UML, è transitivo, cioè esprime l'interazione, ma allo stesso tempo lo dimostra in modi diversi e, se necessario, con il grado di accuratezza richiesto, può essere trasformato in altro.

Il diagramma di comunicazione riflette le interazioni che si verificano tra i vari elementi della struttura composita, nonché 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 è usato come una dimensione separata.

Questo tipo si distingue per un formato assolutamente libero di ordinare più oggetti e relazioni nello stesso modo in cui si fa in un diagramma di oggetti. Se è necessario mantenere l'ordine dei messaggi in questo formato libero, questi vengono numerati in ordine cronologico. La lettura di questo diagramma inizia con il messaggio iniziale 1.0, e successivamente prosegue nella direzione in cui i messaggi vengono trasmessi 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 ogni singolo elemento interagisce, mentre un diagramma di sequenza mostra più chiaramente in quale ordine vengono eseguite le interazioni.

diagramma di sequenza

Il diagramma di sequenza UML mostra le interazioni tra diversi oggetti, che sono ordinate in base al momento 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 scambiati dagli stessi.

Gli elementi principali in questo caso sono le designazioni di vari oggetti, nonché linee verticali che mostrano il passare del tempo e rettangoli che rappresentano l'attività di un particolare oggetto o l'esecuzione di qualche funzione da parte di esso.

Diagramma di cooperazione

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 ei 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, sincronizzandoli anche in modo completamente automatico.

Diagrammi di panoramica dell'interazione

Si tratta di diagrammi UML, che appartengono a un tipo di diagrammi di attività e includono sia elementi di sequenza che costrutti di flusso di controllo.

Vale la pena notare il fatto che questo 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.

Grafico dei tempi

Rappresenta una versione alternativa del diagramma di sequenza, che mostra in modo esplicito il cambiamento di stato sulla linea di vita con una certa scala temporale. Può essere molto utile in varie applicazioni in tempo reale.

Quali sono i vantaggi?

Vale la pena notare diversi vantaggi che distinguono il diagramma di utilizzo UML e altri:

• Il linguaggio è orientato agli oggetti, per cui le tecnologie per descrivere i risultati dell'analisi e della progettazione effettuata sono semanticamente vicine ai metodi di programmazione in tutti i tipi di linguaggi orientati agli oggetti di tipo moderno.
• Usando questo linguaggio, il sistema può essere descritto da quasi tutti i punti di vista possibili e vari aspetti del suo comportamento sono descritti allo stesso modo.
• Tutti i diagrammi sono relativamente facili da leggere anche dopo una familiarità relativamente rapida con la sua sintassi.
• UML ti consente di espandere, oltre a introdurre i tuoi stereotipi grafici e testuali, il che contribuisce al suo utilizzo non solo nell'ingegneria del software.
• La lingua è diventata abbastanza diffusa e si sta sviluppando anche abbastanza attivamente.

Screpolatura

Nonostante il fatto che la costruzione di diagrammi UML abbia molti dei suoi vantaggi, vengono spesso criticati per le seguenti carenze:

• ridondanza. Nella stragrande maggioranza dei casi, i critici affermano che l'UML è troppo grande e complesso, e spesso ciò è ingiustificato. Include molte costruzioni e diagrammi ridondanti o quasi inutili, e molto spesso tali critiche vanno alla seconda versione, e non alla prima, perché nelle revisioni più recenti ci sono più compromessi "progettati dal comitato".
• Varie imprecisioni semantiche. Poiché UML è definito da una combinazione di se stesso, inglese e OCL, manca della rigidità inerente alle lingue che sono definite con precisione da tecniche di descrizione formale. In alcune situazioni, la sintassi astratta di OCL, UML e inglese inizia a contraddirsi a vicenda, mentre in altri casi è incompleta. L'imprecisione della descrizione del linguaggio stesso colpisce sia gli utenti che i fornitori di strumenti, portando alla fine a incompatibilità degli strumenti a causa del modo unico in cui vengono trattate le diverse specifiche.
• Problemi nel processo di attuazione e di studio. Tutti i problemi di cui sopra creano alcune difficoltà nel processo di implementazione e apprendimento dell'UML, e questo è particolarmente vero quando il management costringe gli ingegneri a usarlo quando mancano delle competenze precedenti.
• Il codice riflette il codice. Un'altra opinione è che non sono i modelli belli e attraenti ad essere importanti, ma i sistemi che funzionano direttamente, cioè il codice è il progetto. Secondo questo punto di vista, è necessario sviluppare un modo più efficiente per scrivere software. UML è apprezzato negli approcci che compilano modelli per rigenerare codice eseguibile o sorgente. Ma in realtà, questo potrebbe non essere sufficiente, perché il linguaggio manca delle proprietà di completezza di Turing e ogni codice generato sarà eventualmente limitato da ciò che lo strumento di interpretazione UML può assumere o determinare.
• Mancata corrispondenza del carico. Questo termine deriva dalla teoria dell'analisi dei sistemi per determinare l'incapacità dell'input di un certo sistema di percepire l'output di un altro. Come con qualsiasi notazione standard, l'UML può rappresentare determinati sistemi in modo più efficiente e conciso rispetto ad altri. Pertanto, lo sviluppatore è più propenso verso quelle soluzioni che sono più comode per tessere tutti i punti di forza dell'UML, così come altri linguaggi di programmazione. Questo problema è più evidente se il linguaggio di sviluppo non è conforme ai principi fondamentali della dottrina ortodossa orientata agli oggetti, cioè non cerca di funzionare secondo i principi dell'OOP.
• Cerca di essere universale. UML è un linguaggio di modellazione generico che cerca di essere compatibile con qualsiasi linguaggio di elaborazione attualmente esistente. Nel contesto di un particolare progetto, affinché il team di progettazione possa raggiungere l'obiettivo finale, è necessario scegliere le caratteristiche applicabili di questo linguaggio. Inoltre, i possibili modi per limitare la portata dell'uso dell'UML in un determinato ambito passano attraverso un formalismo che non è completamente formulato, ma che è esso stesso oggetto di critica.

Pertanto, l'uso di questo linguaggio non è rilevante in tutte le situazioni.