UML - Guida rapida

UML è un linguaggio standard per specificare, visualizzare, costruire e documentare gli artefatti dei sistemi software.

UML è stato creato dall'OMG (Object Management Group) e la bozza della specifica UML 1.0 è stata proposta all'OMG nel gennaio 1997.

OMG si impegna continuamente per creare un vero standard di settore.

• UML sta per Unified Modeling Language.

• UML è diverso dagli altri linguaggi di programmazione comuni come C ++, Java, COBOL, ecc.

• UML è un linguaggio pittorico utilizzato per creare progetti software.

• UML può essere descritto come un linguaggio di modellazione visuale per scopi generali per visualizzare, specificare, costruire e documentare il sistema software.

• Sebbene UML sia generalmente utilizzato per modellare sistemi software, non è limitato all'interno di questo confine. Viene anche utilizzato per modellare anche sistemi non software. Ad esempio, il flusso di processo in un'unità di produzione, ecc.

UML non è un linguaggio di programmazione, ma è possibile utilizzare strumenti per generare codice in vari linguaggi utilizzando i diagrammi UML. UML ha una relazione diretta con l'analisi e la progettazione orientata agli oggetti. Dopo un po 'di standardizzazione, UML è diventato uno standard OMG.

Obiettivi di UML

Un'immagine vale più di mille parole , questo idioma si adatta perfettamente alla descrizione di UML. I concetti orientati agli oggetti sono stati introdotti molto prima di UML. A quel punto, non c'erano metodologie standard per organizzare e consolidare lo sviluppo orientato agli oggetti. Fu allora che UML entrò in scena.

Ci sono una serie di obiettivi per lo sviluppo di UML, ma il più importante è definire un linguaggio di modellazione generico, che tutti i modellisti possono utilizzare e deve anche essere reso semplice da comprendere e utilizzare.

I diagrammi UML non sono fatti solo per gli sviluppatori ma anche per utenti aziendali, persone comuni e chiunque sia interessato a comprendere il sistema. Il sistema può essere un sistema software o non software. Quindi deve essere chiaro che UML non è un metodo di sviluppo piuttosto si accompagna ai processi per renderlo un sistema di successo.

In conclusione, l'obiettivo di UML può essere definito come un semplice meccanismo di modellazione per modellare tutti i possibili sistemi pratici nell'ambiente complesso di oggi.

Un modello concettuale di UML

Per comprendere il modello concettuale di UML, prima dobbiamo chiarire cos'è un modello concettuale? e perché è necessario un modello concettuale?

• Un modello concettuale può essere definito come un modello fatto di concetti e delle loro relazioni.

• Un modello concettuale è il primo passo prima di disegnare un diagramma UML. Aiuta a capire le entità nel mondo reale e come interagiscono tra loro.

Poiché UML descrive i sistemi in tempo reale, è molto importante creare un modello concettuale e poi procedere gradualmente. Il modello concettuale di UML può essere padroneggiato apprendendo i seguenti tre elementi principali:

• Elementi costitutivi di UML
• Regole per collegare gli elementi costitutivi
• Meccanismi comuni di UML

Concetti orientati agli oggetti

UML può essere descritto come il successore dell'analisi e della progettazione orientata agli oggetti (OO).

Un oggetto contiene sia dati che metodi che controllano i dati. I dati rappresentano lo stato dell'oggetto. Una classe descrive un oggetto e forma anche una gerarchia per modellare il sistema del mondo reale. La gerarchia è rappresentata come eredità e le classi possono anche essere associate in modi diversi secondo il requisito.

Gli oggetti sono le entità del mondo reale che esistono intorno a noi ei concetti di base come astrazione, incapsulamento, ereditarietà e polimorfismo possono essere rappresentati utilizzando UML.

UML è abbastanza potente da rappresentare tutti i concetti che esistono nell'analisi e nella progettazione orientata agli oggetti. I diagrammi UML sono rappresentazioni solo di concetti orientati agli oggetti. Pertanto, prima di apprendere UML, diventa importante comprendere in dettaglio il concetto di OO.

Di seguito sono riportati alcuni concetti fondamentali del mondo orientato agli oggetti:

• Objects - Gli oggetti rappresentano un'entità e l'elemento costitutivo di base.

• Class - La classe è la stampa blu di un oggetto.

• Abstraction - L'astrazione rappresenta il comportamento di un'entità del mondo reale.

• Encapsulation - L'incapsulamento è il meccanismo per legare insieme i dati e nasconderli al mondo esterno.

• Inheritance - L'ereditarietà è il meccanismo per creare nuove classi da quelle esistenti.

• Polymorphism - Definisce il meccanismo che esiste in diverse forme.

Analisi e progettazione OO

OO può essere definito come un'indagine e per essere più specifici, è l'indagine sugli oggetti. Design significa collaborazione di oggetti identificati.

Pertanto, è importante comprendere l'analisi OO e i concetti di progettazione. Lo scopo più importante dell'analisi OO è identificare gli oggetti di un sistema da progettare. Questa analisi viene eseguita anche per un sistema esistente. Ora un'analisi efficiente è possibile solo quando siamo in grado di iniziare a pensare in un modo in cui gli oggetti possono essere identificati. Dopo aver identificato gli oggetti, vengono identificate le loro relazioni e infine viene prodotto il design.

Lo scopo dell'analisi e della progettazione OO può essere descritto come:

• Identificazione degli oggetti di un sistema.

• Identificare le loro relazioni.

• Realizzare un design, che può essere convertito in eseguibili utilizzando linguaggi OO.

Ci sono tre passaggi di base in cui i concetti OO vengono applicati e implementati. I passaggi possono essere definiti come

OO Analysis → OO Design → OO implementation using OO languages

I tre punti precedenti possono essere descritti in dettaglio come:

• Durante l'analisi OO, lo scopo più importante è identificare gli oggetti e descriverli in modo corretto. Se questi oggetti vengono identificati in modo efficiente, il prossimo lavoro di progettazione è facile. Gli oggetti dovrebbero essere identificati con le responsabilità. Le responsabilità sono le funzioni svolte dall'oggetto. Ogni oggetto ha un certo tipo di responsabilità da eseguire. Quando queste responsabilità sono collaborate, lo scopo del sistema è soddisfatto.

• La seconda fase è la progettazione OO. In questa fase si pone l'accento sui requisiti e sul loro soddisfacimento. In questa fase, gli oggetti vengono collaborati secondo la loro associazione prevista. Una volta completata l'associazione, anche il design è completo.

• La terza fase è l'implementazione OO. In questa fase, il design viene implementato utilizzando linguaggi OO come Java, C ++, ecc.

Ruolo di UML nella progettazione OO

UML è un linguaggio di modellazione utilizzato per modellare sistemi software e non software. Sebbene UML sia utilizzato per sistemi non software, l'accento è posto sulla modellazione di applicazioni software OO. La maggior parte dei diagrammi UML discussi finora sono usati per modellare diversi aspetti come statico, dinamico, ecc. Ora qualunque sia l'aspetto, gli artefatti non sono altro che oggetti.

Se esaminiamo il diagramma delle classi, il diagramma degli oggetti, il diagramma di collaborazione, i diagrammi di interazione, tutti sarebbero fondamentalmente progettati sulla base degli oggetti.

Quindi, la relazione tra il design OO e UML è molto importante da capire. Il design OO viene trasformato in diagrammi UML in base al requisito. Prima di comprendere in dettaglio l'UML, il concetto di OO dovrebbe essere appreso correttamente. Una volta che l'analisi e la progettazione OO sono state eseguite, il passaggio successivo è molto semplice. L'input dall'analisi e dalla progettazione OO è l'input per i diagrammi UML.

Poiché UML descrive i sistemi in tempo reale, è molto importante creare un modello concettuale e poi procedere gradualmente. Il modello concettuale di UML può essere padroneggiato apprendendo i seguenti tre elementi principali:

• Elementi costitutivi di UML
• Regole per collegare gli elementi costitutivi
• Meccanismi comuni di UML

Questo capitolo descrive tutti gli elementi costitutivi di UML. Gli elementi costitutivi di UML possono essere definiti come:

• Things
• Relationships
• Diagrams

Cose

Thingssono gli elementi costitutivi più importanti di UML. Le cose possono essere -

• Structural
• Behavioral
• Grouping
• Annotational

Cose strutturali

Structural thingsdefinire la parte statica del modello. Rappresentano gli elementi fisici e concettuali. Di seguito sono riportate le brevi descrizioni delle cose strutturali.

Class − La classe rappresenta un insieme di oggetti con responsabilità simili.

Interface − L'interfaccia definisce un insieme di operazioni, che specificano la responsabilità di una classe.

Collaboration −La collaborazione definisce un'interazione tra gli elementi.

Use case −Il caso d'uso rappresenta un insieme di azioni eseguite da un sistema per un obiettivo specifico.

Component −Component descrive la parte fisica di un sistema.

Node − Un nodo può essere definito come un elemento fisico che esiste in fase di esecuzione.

Cose comportamentali

A behavioral thingè costituito dalle parti dinamiche dei modelli UML. Di seguito sono riportate le cose comportamentali:

Interaction − L'interazione è definita come un comportamento che consiste in un gruppo di messaggi scambiati tra elementi per portare a termine un compito specifico.

State machine −La macchina a stati è utile quando lo stato di un oggetto nel suo ciclo di vita è importante. Definisce la sequenza di stati che un oggetto attraversa in risposta agli eventi. Gli eventi sono fattori esterni responsabili del cambiamento di stato

Raggruppare le cose

Grouping thingspuò essere definito come un meccanismo per raggruppare insieme elementi di un modello UML. C'è solo una cosa di raggruppamento disponibile:

Package − Il pacchetto è l'unica cosa di raggruppamento disponibile per raccogliere elementi strutturali e comportamentali.

Cose annotazionali

Annotational things può essere definito come un meccanismo per acquisire osservazioni, descrizioni e commenti degli elementi del modello UML. Note- È l'unica cosa annotativa disponibile. Una nota viene utilizzata per visualizzare commenti, vincoli, ecc. Di un elemento UML.

Relazione

Relationshipè un altro elemento costitutivo più importante di UML. Mostra come gli elementi sono associati tra loro e questa associazione descrive la funzionalità di un'applicazione.

Sono disponibili quattro tipi di relazioni.

Dipendenza

La dipendenza è una relazione tra due cose in cui il cambiamento in un elemento influisce anche sull'altro.

Associazione

L'associazione è fondamentalmente un insieme di collegamenti che collega gli elementi di un modello UML. Descrive anche quanti oggetti prendono parte a quella relazione.

Generalizzazione

La generalizzazione può essere definita come una relazione che collega un elemento specializzato con un elemento generalizzato. Fondamentalmente descrive la relazione di eredità nel mondo degli oggetti.

Realizzazione

La realizzazione può essere definita come una relazione in cui due elementi sono collegati. Un elemento descrive una certa responsabilità, che non è implementata e l'altro le implementa. Questa relazione esiste in caso di interfacce.

Diagrammi UML

I diagrammi UML sono l'output finale dell'intera discussione. Tutti gli elementi, le relazioni vengono utilizzati per creare un diagramma UML completo e il diagramma rappresenta un sistema.

L'effetto visivo del diagramma UML è la parte più importante dell'intero processo. Tutti gli altri elementi servono per completarlo.

UML include i seguenti nove diagrammi, i cui dettagli sono descritti nei capitoli successivi.

• Diagramma di classe
• Diagramma dell'oggetto
• Usa il diagramma dei casi
• Diagramma di sequenza
• Diagramma di collaborazione
• Diagramma delle attività
• Diagramma del diagramma di stato
• Diagramma di distribuzione
• Schema dei componenti

Qualsiasi sistema del mondo reale viene utilizzato da utenti diversi. Gli utenti possono essere sviluppatori, tester, uomini d'affari, analisti e molti altri. Quindi, prima di progettare un sistema, l'architettura è realizzata con diverse prospettive in mente. La parte più importante è visualizzare il sistema dalla prospettiva di diversi spettatori. Più comprendiamo meglio possiamo costruire il sistema.

UML gioca un ruolo importante nella definizione delle diverse prospettive di un sistema. Queste prospettive sono:

• Design
• Implementation
• Process
• Deployment

Il centro è il Use Casevista che collega tutti questi quattro. UNUse Caserappresenta la funzionalità del sistema. Quindi, altre prospettive sono collegate al caso d'uso.

Designdi un sistema è costituito da classi, interfacce e collaborazione. UML fornisce diagramma di classe, diagramma di oggetti per supportare questo.

Implementationdefinisce i componenti assemblati insieme per realizzare un sistema fisico completo. Il diagramma dei componenti UML viene utilizzato per supportare la prospettiva di implementazione.

Processdefinisce il flusso del sistema. Quindi, gli stessi elementi usati in Design sono usati anche per supportare questa prospettiva.

Deploymentrappresenta i nodi fisici del sistema che forma l'hardware. Il diagramma di distribuzione UML viene utilizzato per supportare questa prospettiva.

È molto importante distinguere tra il modello UML. Diversi diagrammi vengono utilizzati per diversi tipi di modellazione UML. Esistono tre tipi importanti di modellazione UML.

Modellazione strutturale

La modellazione strutturale cattura le caratteristiche statiche di un sistema. Sono costituiti da quanto segue:

• Diagrammi delle classi
• Diagrammi di oggetti
• Diagrammi di distribuzione
• Diagrammi di pacchetto
• Diagramma della struttura composita
• Schema dei componenti

Il modello strutturale rappresenta la struttura del sistema e questa struttura è il luogo in cui esistono tutti gli altri componenti. Pertanto, il diagramma delle classi, il diagramma dei componenti e i diagrammi di distribuzione fanno parte della modellazione strutturale. Rappresentano tutti gli elementi e il meccanismo per assemblarli.

Il modello strutturale non descrive mai il comportamento dinamico del sistema. Il diagramma delle classi è il diagramma strutturale più utilizzato.

Modellazione comportamentale

Il modello comportamentale descrive l'interazione nel sistema. Rappresenta l'interazione tra i diagrammi strutturali. La modellazione comportamentale mostra la natura dinamica del sistema. Sono costituiti da quanto segue:

• Diagrammi di attività
• Diagrammi di interazione
• Usa i diagrammi dei casi

Tutto quanto sopra mostra la sequenza dinamica del flusso in un sistema.

Modellazione architettonica

Il modello architettonico rappresenta la struttura complessiva del sistema. Contiene elementi sia strutturali che comportamentali del sistema. Il modello architettonico può essere definito come il modello dell'intero sistema. Il diagramma del pacchetto rientra nella modellazione architettonica.

UML è popolare per le sue notazioni schematiche. Sappiamo tutti che UML serve per visualizzare, specificare, costruire e documentare i componenti di sistemi software e non software. Quindi, la visualizzazione è la parte più importante che deve essere compresa e ricordata.

Le notazioni UML sono gli elementi più importanti nella modellazione. Un uso efficiente e appropriato delle notazioni è molto importante per creare un modello completo e significativo. Il modello è inutile, a meno che il suo scopo non sia rappresentato correttamente.

Quindi, le notazioni di apprendimento dovrebbero essere enfatizzate fin dall'inizio. Sono disponibili diverse notazioni per cose e relazioni. I diagrammi UML sono realizzati utilizzando le notazioni di cose e relazioni. L'estensibilità è un'altra caratteristica importante che rende UML più potente e flessibile.

Il capitolo descrive in dettaglio le notazioni UML di base. Questa è solo un'estensione della sezione building block UML discussa nel Capitolo Due.

Cose strutturali

Le notazioni grafiche usate nelle cose strutturali sono le più usate in UML. Questi sono considerati i nomi dei modelli UML. Di seguito è riportato l'elenco delle cose strutturali.

• Classes
• Object
• Interface
• Collaboration
• Caso d'uso
• Classi attive
• Components
• Nodes

Notazione di classe

La classe UML è rappresentata dalla figura seguente. Il diagramma è diviso in quattro parti.

• La sezione superiore viene utilizzata per denominare la classe.
• Il secondo viene utilizzato per mostrare gli attributi della classe.
• La terza sezione viene utilizzata per descrivere le operazioni eseguite dalla classe.
• La quarta sezione è facoltativa per mostrare eventuali componenti aggiuntivi.

Le classi vengono utilizzate per rappresentare gli oggetti. Gli oggetti possono essere qualsiasi cosa che abbia proprietà e responsabilità.

Notazione degli oggetti

L' oggetto è rappresentato allo stesso modo della classe. L'unica differenza è il nome che è sottolineato come mostrato nella figura seguente.

Poiché l'oggetto è un'effettiva implementazione di una classe, che è nota come istanza di una classe. Quindi, ha lo stesso utilizzo della classe.

Notazione dell'interfaccia

L'interfaccia è rappresentata da un cerchio come mostrato nella figura seguente. Ha un nome che è generalmente scritto sotto il cerchio.

L'interfaccia viene utilizzata per descrivere la funzionalità senza implementazione. L'interfaccia è proprio come un modello in cui si definiscono diverse funzioni, non l'implementazione. Quando una classe implementa l'interfaccia, implementa anche la funzionalità secondo i requisiti.

Notazione di collaborazione

La collaborazione è rappresentata da un'eclissi tratteggiata come mostrato nella figura seguente. Ha un nome scritto all'interno dell'eclissi.

La collaborazione rappresenta responsabilità. In generale, le responsabilità sono in un gruppo.

Usa la notazione delle maiuscole

Il caso d'uso è rappresentato come un'eclissi con un nome al suo interno. Può contenere responsabilità aggiuntive.

Il caso d'uso viene utilizzato per acquisire funzionalità di alto livello di un sistema.

Notazione dell'attore

Un attore può essere definito come un'entità interna o esterna che interagisce con il sistema.

Un attore viene utilizzato in un diagramma dei casi d'uso per descrivere le entità interne o esterne.

Notazione dello stato iniziale

Lo stato iniziale è definito per mostrare l'inizio di un processo. Questa notazione è utilizzata in quasi tutti i diagrammi.

L'utilizzo di Initial State Notation è quello di mostrare il punto di partenza di un processo.

Notazione dello stato finale

Lo stato finale viene utilizzato per mostrare la fine di un processo. Questa notazione è usata anche in quasi tutti i diagrammi per descrivere la fine.

L'utilizzo di Final State Notation serve per mostrare il punto di conclusione di un processo.

Notazione di classe attiva

La classe attiva è simile a una classe con un bordo pieno. La classe attiva viene generalmente utilizzata per descrivere il comportamento concorrente di un sistema.

La classe attiva viene utilizzata per rappresentare la concorrenza in un sistema.

Notazione dei componenti

Un componente in UML è mostrato nella figura seguente con un nome all'interno. È possibile aggiungere ulteriori elementi laddove necessario.

Il componente viene utilizzato per rappresentare qualsiasi parte di un sistema per il quale sono realizzati i diagrammi UML.

Notazione dei nodi

Un nodo in UML è rappresentato da una casella quadrata come mostrato nella figura seguente con un nome. Un nodo rappresenta il componente fisico del sistema.

Il nodo viene utilizzato per rappresentare la parte fisica di un sistema come il server, la rete, ecc.

Cose comportamentali

Le parti dinamiche sono uno degli elementi più importanti in UML. UML ha una serie di potenti funzionalità per rappresentare la parte dinamica del software e dei sistemi non software. Queste funzionalità includono interazioni e macchine a stati .

Le interazioni possono essere di due tipi:

• Sequenziale (rappresentato dal diagramma di sequenza)
• Collaborativo (rappresentato dal diagramma di collaborazione)

Notazione di interazione

L'interazione è fondamentalmente uno scambio di messaggi tra due componenti UML. Il diagramma seguente rappresenta le diverse notazioni utilizzate in un'interazione.

L'interazione viene utilizzata per rappresentare la comunicazione tra i componenti di un sistema.

Notazione macchina a stati

La macchina a stati descrive i diversi stati di un componente nel suo ciclo di vita. Le notazioni sono descritte nel diagramma seguente.

La macchina a stati viene utilizzata per descrivere diversi stati di un componente del sistema. Lo stato può essere attivo, inattivo o qualsiasi altro a seconda della situazione.

Raggruppare le cose

L'organizzazione dei modelli UML è uno degli aspetti più importanti del design. In UML, è disponibile un solo elemento per il raggruppamento e questo è il pacchetto.

Notazione pacchetto

La notazione del pacchetto è mostrata nella figura seguente e viene utilizzata per racchiudere i componenti di un sistema.

Cose annotazionali

In ogni diagramma, la spiegazione dei diversi elementi e delle loro funzionalità sono molto importanti. Quindi, UML ha la notazione delle note per supportare questo requisito.

Notazione delle note

Questa notazione è mostrata nella figura seguente. Queste annotazioni vengono utilizzate per fornire le informazioni necessarie di un sistema.

Relazioni

Un modello non è completo a meno che le relazioni tra gli elementi non siano descritte correttamente. La relazione dà un significato appropriato a un modello UML. Di seguito sono riportati i diversi tipi di relazioni disponibili in UML.

• Dependency
• Association
• Generalization
• Extensibility

Notazione delle dipendenze

La dipendenza è un aspetto importante negli elementi UML. Descrive gli elementi dipendenti e la direzione della dipendenza.

La dipendenza è rappresentata da una freccia tratteggiata come mostrato nella figura seguente. La punta della freccia rappresenta l'elemento indipendente e l'altra estremità rappresenta l'elemento dipendente.

La dipendenza viene utilizzata per rappresentare la dipendenza tra due elementi di un sistema

Notazione di associazione

L'associazione descrive come vengono associati gli elementi in un diagramma UML. In parole semplici, descrive quanti elementi stanno prendendo parte a un'interazione.

L'associazione è rappresentata da una linea tratteggiata con (senza) frecce su entrambi i lati. Le due estremità rappresentano due elementi associati come mostrato nella figura seguente. La molteplicità è anche menzionata alle estremità (1, *, ecc.) Per mostrare quanti oggetti sono associati.

L'associazione viene utilizzata per rappresentare la relazione tra due elementi di un sistema.

Notazione di generalizzazione

La generalizzazione descrive la relazione di ereditarietà del mondo orientato agli oggetti. È una relazione genitore e figlio.

La generalizzazione è rappresentata da una freccia con una punta di freccia cava come mostrato nella figura seguente. Un'estremità rappresenta l'elemento genitore e l'altra estremità rappresenta l'elemento figlio.

La generalizzazione è usata per descrivere la relazione genitore-figlio di due elementi di un sistema.

Notazione di estensibilità

Tutti i linguaggi (programmazione o modellazione) hanno alcuni meccanismi per estendere le sue capacità come sintassi, semantica, ecc. UML ha anche i seguenti meccanismi per fornire funzionalità di estensibilità.

• Stereotipi (rappresenta nuovi elementi)
• Valori con tag (rappresenta nuovi attributi)
• Vincoli (rappresenta i confini)

Le notazioni di estensibilità vengono utilizzate per aumentare la potenza del linguaggio. Si tratta fondamentalmente di elementi aggiuntivi utilizzati per rappresentare alcuni comportamenti extra del sistema. Questi comportamenti extra non sono coperti dalle notazioni standard disponibili.

Nei capitoli precedenti abbiamo discusso degli elementi costitutivi e di altri elementi necessari di UML. Ora dobbiamo capire dove utilizzare questi elementi.

Gli elementi sono come componenti che possono essere associati in modi diversi per creare un'immagine UML completa, nota come diagramma. Pertanto, è molto importante comprendere i diversi diagrammi per implementare la conoscenza nei sistemi della vita reale.

Qualsiasi sistema complesso può essere compreso meglio creando una sorta di diagrammi o immagini. Questi diagrammi hanno un impatto migliore sulla nostra comprensione. Se ci guardiamo intorno, ci accorgeremo che i diagrammi non sono un concetto nuovo ma sono ampiamente utilizzati in forme diverse in diversi settori.

Prepariamo diagrammi UML per comprendere il sistema in modo migliore e semplice. Un unico diagramma non è sufficiente per coprire tutti gli aspetti del sistema. UML definisce vari tipi di diagrammi per coprire la maggior parte degli aspetti di un sistema.

È inoltre possibile creare il proprio set di diagrammi per soddisfare le proprie esigenze. I diagrammi sono generalmente realizzati in modo incrementale e iterativo.

Esistono due ampie categorie di diagrammi e sono nuovamente suddivisi in sottocategorie:

• Diagrammi strutturali

• Diagrammi comportamentali

Diagrammi strutturali

Gli schemi strutturali rappresentano l'aspetto statico del sistema. Questi aspetti statici rappresentano quelle parti di un diagramma, che costituisce la struttura principale e sono quindi stabili.

Queste parti statiche sono rappresentate da classi, interfacce, oggetti, componenti e nodi. I quattro schemi strutturali sono:

• Diagramma di classe
• Diagramma dell'oggetto
• Schema dei componenti
• Diagramma di distribuzione

Diagramma di classe

I diagrammi di classe sono i diagrammi più comuni utilizzati in UML. Il diagramma di classe è costituito da classi, interfacce, associazioni e collaborazione. I diagrammi di classe rappresentano fondamentalmente la vista orientata agli oggetti di un sistema, che è di natura statica.

La classe attiva viene utilizzata in un diagramma delle classi per rappresentare la concorrenza del sistema.

Il diagramma delle classi rappresenta l'orientamento agli oggetti di un sistema. Quindi, è generalmente utilizzato per scopi di sviluppo. Questo è il diagramma più utilizzato al momento della costruzione del sistema.

Diagramma dell'oggetto

I diagrammi degli oggetti possono essere descritti come un'istanza del diagramma delle classi. Pertanto, questi diagrammi sono più vicini a scenari di vita reale in cui implementiamo un sistema.

I diagrammi degli oggetti sono un insieme di oggetti e la loro relazione è proprio come i diagrammi delle classi. Rappresentano anche la vista statica del sistema.

L'utilizzo dei diagrammi a oggetti è simile ai diagrammi delle classi, ma vengono utilizzati per costruire prototipi di un sistema da una prospettiva pratica.

Schema dei componenti

I diagrammi dei componenti rappresentano un insieme di componenti e le loro relazioni. Questi componenti sono costituiti da classi, interfacce o collaborazioni. I diagrammi dei componenti rappresentano la vista dell'implementazione di un sistema.

Durante la fase di progettazione, gli artefatti software (classi, interfacce, ecc.) Di un sistema sono organizzati in diversi gruppi a seconda della loro relazione. Ora, questi gruppi sono noti come componenti.

Infine, si può dire che i diagrammi dei componenti vengono utilizzati per visualizzare l'implementazione.

Diagramma di distribuzione

I diagrammi di distribuzione sono un insieme di nodi e le loro relazioni. Questi nodi sono entità fisiche in cui vengono distribuiti i componenti.

I diagrammi di distribuzione vengono utilizzati per visualizzare la vista di distribuzione di un sistema. Questo è generalmente utilizzato dal team di distribuzione.

Note- Se le descrizioni e gli usi di cui sopra vengono osservati attentamente, è molto chiaro che tutti i diagrammi hanno una qualche relazione tra loro. I diagrammi dei componenti dipendono dalle classi, interfacce, ecc. Che fanno parte del diagramma classe / oggetto. Anche in questo caso, il diagramma di distribuzione dipende dai componenti, che vengono utilizzati per creare i diagrammi dei componenti.

Diagrammi comportamentali

Ogni sistema può avere due aspetti, statico e dinamico. Quindi, un modello è considerato completo quando entrambi gli aspetti sono completamente coperti.

I diagrammi comportamentali catturano fondamentalmente l'aspetto dinamico di un sistema. L'aspetto dinamico può essere ulteriormente descritto come le parti mutevoli / mobili di un sistema.

UML ha i seguenti cinque tipi di diagrammi comportamentali:

• Usa il diagramma dei casi
• Diagramma di sequenza
• Diagramma di collaborazione
• Diagramma del diagramma di stato
• Diagramma delle attività

Usa diagramma dei casi

I diagrammi dei casi d'uso sono un insieme di casi d'uso, attori e relative relazioni. Rappresentano la visualizzazione dei casi d'uso di un sistema.

Un caso d'uso rappresenta una particolare funzionalità di un sistema. Quindi, il diagramma dei casi d'uso viene utilizzato per descrivere le relazioni tra le funzionalità e i loro controllori interni / esterni. Questi controller sono noti comeactors.

Diagramma di sequenza

Un diagramma di sequenza è un diagramma di interazione. Dal nome è chiaro che il diagramma tratta alcune sequenze, che sono la sequenza di messaggi che scorrono da un oggetto all'altro.

L'interazione tra i componenti di un sistema è molto importante dal punto di vista dell'implementazione e dell'esecuzione. Il diagramma di sequenza viene utilizzato per visualizzare la sequenza di chiamate in un sistema per eseguire una funzionalità specifica.

Diagramma di collaborazione

Il diagramma di collaborazione è un'altra forma di diagramma di interazione. Rappresenta l'organizzazione strutturale di un sistema e dei messaggi inviati / ricevuti. L'organizzazione strutturale è costituita da oggetti e collegamenti.

Lo scopo del diagramma di collaborazione è simile al diagramma di sequenza. Tuttavia, lo scopo specifico del diagramma di collaborazione è visualizzare l'organizzazione degli oggetti e la loro interazione.

Diagramma del diagramma di stato

Qualsiasi sistema in tempo reale dovrebbe reagire a un qualche tipo di eventi interni / esterni. Questi eventi sono responsabili del cambiamento di stato del sistema.

Il diagramma del diagramma di stato viene utilizzato per rappresentare il cambiamento di stato guidato dagli eventi di un sistema. Fondamentalmente descrive il cambio di stato di una classe, interfaccia, ecc.

Il diagramma del diagramma di stato viene utilizzato per visualizzare la reazione di un sistema a fattori interni / esterni.

Diagramma di attività

Il diagramma delle attività descrive il flusso di controllo in un sistema. Consiste di attività e collegamenti. Il flusso può essere sequenziale, simultaneo o ramificato.

Le attività non sono altro che le funzioni di un sistema. I numeri dei diagrammi di attività sono preparati per catturare l'intero flusso in un sistema.

I diagrammi di attività vengono utilizzati per visualizzare il flusso dei controlli in un sistema. Questo è preparato per avere un'idea di come funzionerà il sistema una volta eseguito.

Note- La natura dinamica di un sistema è molto difficile da catturare. UML ha fornito funzionalità per catturare le dinamiche di un sistema da diverse angolazioni. I diagrammi di sequenza e i diagrammi di collaborazione sono isomorfi, quindi possono essere convertiti l'uno dall'altro senza perdere alcuna informazione. Ciò vale anche per il diagramma di stato e il diagramma di attività.

Il diagramma di classe è un diagramma statico. Rappresenta la visualizzazione statica di un'applicazione. Il diagramma delle classi non viene utilizzato solo per visualizzare, descrivere e documentare diversi aspetti di un sistema, ma anche per costruire il codice eseguibile dell'applicazione software.

Il diagramma di classe descrive gli attributi e le operazioni di una classe e anche i vincoli imposti al sistema. I diagrammi di classe sono ampiamente utilizzati nella modellazione di sistemi orientati agli oggetti perché sono gli unici diagrammi UML, che possono essere mappati direttamente con linguaggi orientati agli oggetti.

Il diagramma delle classi mostra una raccolta di classi, interfacce, associazioni, collaborazioni e vincoli. È anche noto come diagramma strutturale.

Scopo dei diagrammi di classe

Lo scopo del diagramma delle classi è modellare la visualizzazione statica di un'applicazione. I diagrammi di classe sono gli unici diagrammi che possono essere mappati direttamente con linguaggi orientati agli oggetti e quindi ampiamente utilizzati al momento della costruzione.

I diagrammi UML come il diagramma di attività, il diagramma di sequenza possono solo fornire il flusso di sequenza dell'applicazione, tuttavia il diagramma di classe è leggermente diverso. È il diagramma UML più popolare nella comunità dei programmatori.

Lo scopo del diagramma delle classi può essere riassunto come:

• Analisi e progettazione della vista statica di un'applicazione.

• Descrivi le responsabilità di un sistema.

• Base per componenti e diagrammi di distribuzione.

• Forward e reverse engineering.

Come disegnare un diagramma di classe?

I diagrammi di classe sono i diagrammi UML più popolari utilizzati per la costruzione di applicazioni software. È molto importante imparare la procedura di disegno del diagramma di classe.

I diagrammi di classe hanno molte proprietà da considerare durante il disegno, ma qui il diagramma verrà considerato da una vista di livello superiore.

Il diagramma delle classi è fondamentalmente una rappresentazione grafica della vista statica del sistema e rappresenta diversi aspetti dell'applicazione. Una raccolta di diagrammi di classe rappresenta l'intero sistema.

I seguenti punti dovrebbero essere ricordati mentre si disegna un diagramma di classe:

• Il nome del diagramma delle classi dovrebbe essere significativo per descrivere l'aspetto del sistema.

• Ogni elemento e le loro relazioni dovrebbero essere identificati in anticipo.

• La responsabilità (attributi e metodi) di ogni classe dovrebbe essere chiaramente identificata

• Per ogni classe, è necessario specificare il numero minimo di proprietà, poiché le proprietà non necessarie complicheranno il diagramma.

• Utilizzare le note ogni volta che è necessario per descrivere alcuni aspetti del diagramma. Alla fine del disegno dovrebbe essere comprensibile allo sviluppatore / programmatore.

• Infine, prima di fare la versione finale, il diagramma dovrebbe essere disegnato su carta comune e rielaborato quante più volte possibile per renderlo corretto.

Il diagramma seguente è un esempio di un sistema di ordini di un'applicazione. Descrive un aspetto particolare dell'intera applicazione.

• Prima di tutto, Ordine e Cliente vengono identificati come i due elementi del sistema. Hanno una relazione uno-a-molti perché un cliente può avere più ordini.

• La classe Order è una classe astratta e ha due classi concrete (relazione di ereditarietà) SpecialOrder e NormalOrder.

• Le due classi ereditate hanno tutte le proprietà della classe Order. Inoltre, hanno funzioni aggiuntive come dispatch () e receive ().

Il seguente diagramma di classe è stato disegnato considerando tutti i punti sopra menzionati.

Dove utilizzare i diagrammi di classe?

Il diagramma delle classi è un diagramma statico e viene utilizzato per modellare la vista statica di un sistema. La visualizzazione statica descrive il vocabolario del sistema.

Il diagramma di classe è anche considerato la base per i diagrammi di componenti e di distribuzione. I diagrammi di classe non vengono utilizzati solo per visualizzare la vista statica del sistema, ma sono anche utilizzati per costruire il codice eseguibile per l'ingegneria diretta e inversa di qualsiasi sistema.

In generale, i diagrammi UML non vengono mappati direttamente con alcun linguaggio di programmazione orientato agli oggetti, ma il diagramma delle classi è un'eccezione.

Il diagramma di classe mostra chiaramente la mappatura con linguaggi orientati agli oggetti come Java, C ++, ecc. Per esperienza pratica, il diagramma di classe viene generalmente utilizzato per scopi di costruzione.

In poche parole si può dire che i diagrammi di classe vengono utilizzati per:

• Descrivere la vista statica del sistema.

• Mostra la collaborazione tra gli elementi della vista statica.

• Descrivere le funzionalità svolte dal sistema.

• Costruzione di applicazioni software utilizzando linguaggi orientati agli oggetti.

I diagrammi degli oggetti sono derivati ​​dai diagrammi delle classi, quindi i diagrammi degli oggetti dipendono dai diagrammi delle classi.

I diagrammi degli oggetti rappresentano un'istanza di un diagramma delle classi. I concetti di base sono simili per i diagrammi delle classi e i diagrammi degli oggetti. I diagrammi degli oggetti rappresentano anche la vista statica di un sistema, ma questa vista statica è un'istantanea del sistema in un momento particolare.

I diagrammi degli oggetti vengono utilizzati per eseguire il rendering di un insieme di oggetti e le loro relazioni come un'istanza.

Scopo dei diagrammi a oggetti

Lo scopo di un diagramma dovrebbe essere compreso chiaramente per implementarlo nella pratica. Gli scopi dei diagrammi a oggetti sono simili ai diagrammi di classe.

La differenza è che un diagramma delle classi rappresenta un modello astratto costituito dalle classi e dalle loro relazioni. Tuttavia, un diagramma a oggetti rappresenta un'istanza in un momento particolare, che è di natura concreta.

Significa che il diagramma degli oggetti è più vicino al comportamento effettivo del sistema. Lo scopo è catturare la vista statica di un sistema in un particolare momento.

Lo scopo del diagramma degli oggetti può essere riassunto come:

• Forward e reverse engineering.

• Relazioni oggettuali di un sistema

• Visualizzazione statica di un'interazione.

• Comprendere il comportamento degli oggetti e la loro relazione da una prospettiva pratica

Come disegnare un diagramma a oggetti?

Abbiamo già discusso che un diagramma a oggetti è un'istanza di un diagramma delle classi. Implica che un diagramma a oggetti sia costituito da istanze di cose usate in un diagramma di classe.

Quindi entrambi i diagrammi sono composti dagli stessi elementi di base ma in una forma diversa. Nel diagramma di classe gli elementi sono in forma astratta per rappresentare la stampa blu e nel diagramma a oggetti gli elementi sono in forma concreta per rappresentare l'oggetto del mondo reale.

Per acquisire un particolare sistema, il numero di diagrammi di classe è limitato. Tuttavia, se consideriamo i diagrammi degli oggetti, possiamo avere un numero illimitato di istanze, che sono uniche per natura. Vengono prese in considerazione solo quelle istanze che hanno un impatto sul sistema.

Dalla discussione sopra, è chiaro che un singolo diagramma di oggetto non può catturare tutte le istanze necessarie o piuttosto non può specificare tutti gli oggetti di un sistema. Quindi, la soluzione è:

• Innanzitutto, analizza il sistema e decidi quali istanze hanno dati e associazioni importanti.

• In secondo luogo, considera solo quelle istanze, che copriranno la funzionalità.

• Terzo, fai delle ottimizzazioni poiché il numero di istanze è illimitato.

Prima di disegnare un diagramma a oggetti, è necessario ricordare e comprendere chiaramente le seguenti cose:

• I diagrammi degli oggetti sono costituiti da oggetti.

• Il collegamento nel diagramma degli oggetti viene utilizzato per connettere gli oggetti.

• Oggetti e collegamenti sono i due elementi utilizzati per costruire un diagramma di oggetti.

Dopodiché, prima di iniziare la costruzione del diagramma è necessario decidere le seguenti cose:

• Il diagramma degli oggetti dovrebbe avere un nome significativo per indicarne lo scopo.

• Gli elementi più importanti devono essere identificati.

• L'associazione tra gli oggetti dovrebbe essere chiarita.

• I valori dei diversi elementi devono essere acquisiti per includerli nel diagramma degli oggetti.

• Aggiungi note appropriate nei punti in cui è richiesta maggiore chiarezza.

Il diagramma seguente è un esempio di diagramma a oggetti. Rappresenta il sistema di gestione degli ordini di cui abbiamo discusso nel capitolo Diagramma di classe. Il diagramma seguente è un'istanza del sistema in un particolare momento di acquisto. Ha i seguenti oggetti.

• Customer

• Order

• SpecialOrder

• NormalOrder

Ora l'oggetto cliente (C) è associato a tre oggetti ordine (O1, O2 e O3). Questi oggetti di ordine sono associati a oggetti di ordine speciale e normale (S1, S2 e N1). Il cliente ha i seguenti tre ordini con numeri diversi (12, 32 e 40) per il particolare tempo considerato.

Il cliente può aumentare il numero di ordini in futuro e in quello scenario il diagramma degli oggetti lo rifletterà. Se vengono osservati oggetti ordine, ordine speciale e ordine normale, scoprirai che hanno alcuni valori.

Per gli ordini, i valori sono 12, 32 e 40, il che implica che gli oggetti hanno questi valori per un momento particolare (qui il momento particolare in cui viene effettuato l'acquisto è considerato il momento) in cui l'istanza viene catturata

Lo stesso vale per ordini speciali e oggetti di ordini normali che hanno un numero di ordini pari a 20, 30 e 60. Se si considera un orario di acquisto diverso, questi valori cambieranno di conseguenza.

Il seguente diagramma a oggetti è stato disegnato considerando tutti i punti sopra menzionati

Dove utilizzare i diagrammi degli oggetti?

I diagrammi degli oggetti possono essere immaginati come l'istantanea di un sistema in esecuzione in un determinato momento. Consideriamo un esempio di un treno in corsa

Ora, se scatti uno scatto del treno in corsa, troverai un'immagine statica di esso con quanto segue:

• Uno stato particolare che è in esecuzione.

• Un numero particolare di passeggeri. che cambierà se lo snap viene scattato in un momento diverso

Qui, possiamo immaginare che lo scatto del treno in corsa sia un oggetto con i valori di cui sopra. E questo è vero per qualsiasi sistema semplice o complesso della vita reale.

In poche parole, si può dire che i diagrammi degli oggetti vengono utilizzati per:

• Realizzare il prototipo di un sistema.

• Reverse engineering.

• Modellazione di strutture dati complesse.

• Comprendere il sistema da una prospettiva pratica.

I diagrammi dei componenti sono diversi in termini di natura e comportamento. I diagrammi dei componenti vengono utilizzati per modellare gli aspetti fisici di un sistema. La domanda è: quali sono questi aspetti fisici? Gli aspetti fisici sono gli elementi come eseguibili, librerie, file, documenti, ecc. Che risiedono in un nodo.

I diagrammi dei componenti vengono utilizzati per visualizzare l'organizzazione e le relazioni tra i componenti di un sistema. Questi diagrammi vengono utilizzati anche per creare sistemi eseguibili.

Scopo dei diagrammi dei componenti

Il diagramma dei componenti è un tipo speciale di diagramma in UML. Lo scopo è anche diverso da tutti gli altri diagrammi discussi finora. Non descrive la funzionalità del sistema ma descrive i componenti utilizzati per realizzare tali funzionalità.

Quindi, da quel punto di vista, i diagrammi dei componenti vengono utilizzati per visualizzare i componenti fisici in un sistema. Questi componenti sono librerie, pacchetti, file, ecc.

I diagrammi dei componenti possono anche essere descritti come una vista di implementazione statica di un sistema. L'implementazione statica rappresenta l'organizzazione dei componenti in un determinato momento.

Un diagramma a singolo componente non può rappresentare l'intero sistema, ma per rappresentare il tutto viene utilizzata una raccolta di diagrammi.

Lo scopo del diagramma dei componenti può essere riassunto come:

• Visualizza i componenti di un sistema.

• Costruisci eseguibili utilizzando forward e reverse engineering.

• Descrivi l'organizzazione e le relazioni dei componenti.

Come disegnare un diagramma dei componenti?

I diagrammi dei componenti vengono utilizzati per descrivere gli artefatti fisici di un sistema. Questo artefatto include file, eseguibili, librerie, ecc

Lo scopo di questo diagramma è diverso. I diagrammi dei componenti vengono utilizzati durante la fase di implementazione di un'applicazione. Tuttavia, è preparato con largo anticipo per visualizzare i dettagli di implementazione.

Inizialmente, il sistema viene progettato utilizzando diversi diagrammi UML e quindi quando gli artefatti sono pronti, vengono utilizzati i diagrammi dei componenti per avere un'idea dell'implementazione.

Questo diagramma è molto importante poiché senza di esso l'applicazione non può essere implementata in modo efficiente. Un diagramma dei componenti ben preparato è importante anche per altri aspetti come le prestazioni dell'applicazione, la manutenzione, ecc.

Prima di disegnare un diagramma dei componenti, i seguenti artefatti devono essere identificati chiaramente:

• File utilizzati nel sistema.

• Librerie e altri artefatti rilevanti per l'applicazione.

• Relazioni tra i manufatti.

Dopo aver identificato gli artefatti, è necessario tenere a mente i seguenti punti.

• Utilizzare un nome significativo per identificare il componente per il quale deve essere disegnato il diagramma.

• Preparare un layout mentale prima di produrre gli strumenti di utilizzo.

• Usa le note per chiarire i punti importanti.

Di seguito è riportato un diagramma dei componenti per il sistema di gestione degli ordini. Qui, gli artefatti sono file. Il diagramma mostra i file nell'applicazione e le loro relazioni. In realtà, il diagramma dei componenti contiene anche dll, librerie, cartelle, ecc.

Nel diagramma seguente vengono identificati quattro file e vengono prodotte le loro relazioni. Il diagramma dei componenti non può essere abbinato direttamente con altri diagrammi UML discussi in quanto è disegnato per scopi completamente diversi.

Il seguente diagramma dei componenti è stato disegnato considerando tutti i punti sopra menzionati.

Dove utilizzare i diagrammi dei componenti?

Abbiamo già descritto che i diagrammi dei componenti vengono utilizzati per visualizzare la vista dell'implementazione statica di un sistema. I diagrammi dei componenti sono un tipo speciale di diagrammi UML utilizzati per scopi diversi.

Questi diagrammi mostrano i componenti fisici di un sistema. Per chiarirlo, possiamo dire che i diagrammi dei componenti descrivono l'organizzazione dei componenti in un sistema.

L'organizzazione può essere ulteriormente descritta come la posizione dei componenti in un sistema. Questi componenti sono organizzati in modo speciale per soddisfare i requisiti di sistema.

Come abbiamo già discusso, questi componenti sono librerie, file, eseguibili, ecc. Prima di implementare l'applicazione, questi componenti devono essere organizzati. Questa organizzazione componente è progettata anche separatamente come parte dell'esecuzione del progetto.

I diagrammi dei componenti sono molto importanti dal punto di vista dell'implementazione. Pertanto, il team di implementazione di un'applicazione dovrebbe avere una conoscenza adeguata dei dettagli del componente

I diagrammi dei componenti possono essere utilizzati per:

• Modella i componenti di un sistema.

• Modella lo schema del database.

• Modella gli eseguibili di un'applicazione.

• Modella il codice sorgente del sistema.

I diagrammi di distribuzione vengono utilizzati per visualizzare la topologia dei componenti fisici di un sistema, in cui vengono distribuiti i componenti software.

I diagrammi di distribuzione vengono utilizzati per descrivere la visualizzazione di distribuzione statica di un sistema. I diagrammi di distribuzione sono costituiti dai nodi e dalle loro relazioni.

Scopo dei diagrammi di distribuzione

Il termine Distribuzione stesso descrive lo scopo del diagramma. I diagrammi di distribuzione vengono utilizzati per descrivere i componenti hardware, dove vengono distribuiti i componenti software. I diagrammi dei componenti e i diagrammi di distribuzione sono strettamente correlati.

I diagrammi dei componenti vengono utilizzati per descrivere i componenti e i diagrammi di distribuzione mostrano come vengono distribuiti nell'hardware.

UML è progettato principalmente per concentrarsi sugli artefatti software di un sistema. Tuttavia, questi due diagrammi sono diagrammi speciali utilizzati per concentrarsi sui componenti software e hardware.

La maggior parte dei diagrammi UML vengono utilizzati per gestire i componenti logici, ma i diagrammi di distribuzione sono realizzati per concentrarsi sulla topologia hardware di un sistema. I diagrammi di distribuzione vengono utilizzati dagli ingegneri di sistema.

Lo scopo dei diagrammi di distribuzione può essere descritto come:

• Visualizza la topologia hardware di un sistema.

• Descrivere i componenti hardware utilizzati per distribuire i componenti software.

• Descrivi i nodi di elaborazione runtime.

Come disegnare un diagramma di distribuzione?

Il diagramma di distribuzione rappresenta la vista di distribuzione di un sistema. È correlato al diagramma dei componenti perché i componenti vengono distribuiti utilizzando i diagrammi di distribuzione. Un diagramma di distribuzione è costituito da nodi. I nodi non sono altro che hardware fisico utilizzato per distribuire l'applicazione.

I diagrammi di distribuzione sono utili per gli ingegneri di sistema. Un diagramma di distribuzione efficiente è molto importante in quanto controlla i seguenti parametri:

• Performance

• Scalability

• Maintainability

• Portability

Prima di disegnare un diagramma di distribuzione, è necessario identificare i seguenti artefatti:

• Nodes

• Relazioni tra i nodi

Di seguito è riportato un diagramma di distribuzione di esempio per fornire un'idea della visualizzazione della distribuzione del sistema di gestione degli ordini. Qui, abbiamo mostrato i nodi come -

• Monitor

• Modem

• Server di memorizzazione nella cache

• Server

Si presume che l'applicazione sia un'applicazione basata sul Web, che viene distribuita in un ambiente cluster utilizzando il server 1, il server 2 e il server 3. L'utente si connette all'applicazione utilizzando Internet. Il controllo passa dal server di memorizzazione nella cache all'ambiente cluster.

Il seguente diagramma di distribuzione è stato disegnato considerando tutti i punti sopra menzionati.

Dove utilizzare i diagrammi di distribuzione?

I diagrammi di distribuzione vengono utilizzati principalmente dagli ingegneri di sistema. Questi diagrammi vengono utilizzati per descrivere i componenti fisici (hardware), la loro distribuzione e associazione.

I diagrammi di distribuzione possono essere visualizzati come componenti / nodi hardware su cui risiedono i componenti software.

Le applicazioni software sono sviluppate per modellare processi aziendali complessi. Applicazioni software efficienti non sono sufficienti per soddisfare i requisiti aziendali. I requisiti aziendali possono essere descritti come la necessità di supportare il numero crescente di utenti, tempi di risposta rapidi, ecc.

Per soddisfare questi tipi di requisiti, i componenti hardware devono essere progettati in modo efficiente e in modo conveniente.

Le applicazioni software odierne sono di natura molto complessa. Le applicazioni software possono essere autonome, basate sul Web, distribuite, basate su mainframe e molte altre. Quindi, è molto importante progettare i componenti hardware in modo efficiente.

È possibile utilizzare i diagrammi di distribuzione:

• Per modellare la topologia hardware di un sistema.

• Per modellare il sistema embedded.

• Per modellare i dettagli hardware per un sistema client / server.

• Per modellare i dettagli hardware di un'applicazione distribuita.

• Per Forward e Reverse engineering.

Per modellare un sistema, l'aspetto più importante è catturare il comportamento dinamico. Per comportamento dinamico si intende il comportamento del sistema quando è in esecuzione / in funzione.

Solo il comportamento statico non è sufficiente per modellare un sistema, piuttosto il comportamento dinamico è più importante del comportamento statico. In UML, sono disponibili cinque diagrammi per modellare la natura dinamica e il diagramma dei casi d'uso è uno di questi. Ora, poiché dobbiamo discutere che il diagramma del caso d'uso è di natura dinamica, dovrebbero esserci alcuni fattori interni o esterni per effettuare l'interazione.

Questi agenti interni ed esterni sono noti come attori. I diagrammi dei casi d'uso sono costituiti da attori, casi d'uso e le loro relazioni. Il diagramma viene utilizzato per modellare il sistema / sottosistema di un'applicazione. Un diagramma di caso monouso cattura una particolare funzionalità di un sistema.

Quindi per modellare l'intero sistema, vengono utilizzati numerosi diagrammi di casi d'uso.

Scopo dei diagrammi dei casi d'uso

Lo scopo del diagramma dei casi d'uso è catturare l'aspetto dinamico di un sistema. Tuttavia, questa definizione è troppo generica per descrivere lo scopo, poiché anche altri quattro diagrammi (attività, sequenza, collaborazione e Statechart) hanno lo stesso scopo. Esamineremo uno scopo specifico, che lo distinguerà da altri quattro diagrammi.

I diagrammi dei casi d'uso vengono utilizzati per raccogliere i requisiti di un sistema, comprese le influenze interne ed esterne. Questi requisiti sono principalmente requisiti di progettazione. Quindi, quando un sistema viene analizzato per raccogliere le sue funzionalità, vengono preparati i casi d'uso e vengono identificati gli attori.

Quando l'attività iniziale è completa, i diagrammi dei casi d'uso vengono modellati per presentare la vista esterna.

In breve, si può dire che gli scopi dei diagrammi dei casi d'uso sono i seguenti:

• Utilizzato per raccogliere i requisiti di un sistema.

• Utilizzato per ottenere una vista esterna di un sistema.

• Identificare i fattori esterni e interni che influenzano il sistema.

• Mostra l'interazione tra i requisiti sono attori.

Come disegnare un diagramma dei casi d'uso?

I diagrammi dei casi d'uso sono considerati per l'analisi dei requisiti di alto livello di un sistema. Quando vengono analizzati i requisiti di un sistema, le funzionalità vengono acquisite nei casi d'uso.

Possiamo dire che i casi d'uso non sono altro che le funzionalità del sistema scritte in maniera organizzata. La seconda cosa che è rilevante per i casi d'uso sono gli attori. Gli attori possono essere definiti come qualcosa che interagisce con il sistema.

Gli attori possono essere un utente umano, alcune applicazioni interne o possono essere alcune applicazioni esterne. Quando abbiamo in programma di disegnare un diagramma dei casi d'uso, dovremmo identificare i seguenti elementi.

• Funzionalità da rappresentare come caso d'uso

• Actors

• Relazioni tra casi d'uso e attori.

I diagrammi dei casi d'uso vengono disegnati per acquisire i requisiti funzionali di un sistema. Dopo aver identificato gli elementi di cui sopra, dobbiamo utilizzare le seguenti linee guida per disegnare un diagramma dei casi d'uso efficiente

• Il nome di un caso d'uso è molto importante. Il nome deve essere scelto in modo tale da poter identificare le funzionalità svolte.

• Dai un nome adatto agli attori.

• Mostra chiaramente relazioni e dipendenze nel diagramma.

• Non cercare di includere tutti i tipi di relazioni, poiché lo scopo principale del diagramma è identificare i requisiti.

• Utilizzare le note ogni volta che è necessario per chiarire alcuni punti importanti.

Di seguito è riportato un diagramma di caso d'uso di esempio che rappresenta il sistema di gestione degli ordini. Quindi, se esaminiamo il diagramma, troveremo tre casi d'uso(Order, SpecialOrder, and NormalOrder) e un attore che è il cliente.

I casi d'uso SpecialOrder e NormalOrder sono estesi dal caso d'uso Order . Quindi, hanno una relazione estesa. Un altro punto importante è identificare il confine del sistema, mostrato nell'immagine. L'attore Cliente è esterno al sistema in quanto è un utente esterno del sistema.

Dove utilizzare un diagramma dei casi d'uso?

Come abbiamo già discusso, ci sono cinque diagrammi in UML per modellare la vista dinamica di un sistema. Ora ogni modello ha uno scopo specifico da utilizzare. In realtà questi scopi specifici sono angoli diversi di un sistema in esecuzione.

Per comprendere le dinamiche di un sistema, dobbiamo utilizzare diversi tipi di diagrammi. Il diagramma dei casi d'uso è uno di questi e il suo scopo specifico è raccogliere i requisiti di sistema e gli attori.

I diagrammi dei casi d'uso specificano gli eventi di un sistema e i relativi flussi. Ma il diagramma dei casi d'uso non descrive mai come vengono implementati. Il diagramma dei casi d'uso può essere immaginato come una scatola nera in cui sono noti solo l'input, l'output e la funzione della scatola nera.

Questi diagrammi sono utilizzati a un livello di progettazione molto elevato. Questo design di alto livello viene continuamente perfezionato per ottenere un quadro completo e pratico del sistema. Un caso d'uso ben strutturato descrive anche la pre-condizione, la post-condizione e le eccezioni. Questi elementi aggiuntivi vengono utilizzati per creare casi di test durante l'esecuzione del test.

Sebbene il caso d'uso non sia un buon candidato per l'ingegneria diretta e inversa, vengono comunque utilizzati in modo leggermente diverso per l'ingegneria diretta e inversa. Lo stesso vale per il reverse engineering. Il diagramma dei casi d'uso viene utilizzato in modo diverso per renderlo adatto al reverse engineering.

Nell'ingegneria avanzata, i diagrammi dei casi d'uso vengono utilizzati per creare casi di test e nei casi d'uso dell'ingegneria inversa per preparare i dettagli dei requisiti dall'applicazione esistente.

I diagrammi dei casi d'uso possono essere utilizzati per:

• Analisi dei requisiti e progettazione di alto livello.

• Modella il contesto di un sistema.

• Reverse engineering.

• Ingegneria avanzata.

Dal termine Interazione, è chiaro che il diagramma viene utilizzato per descrivere alcuni tipi di interazioni tra i diversi elementi del modello. Questa interazione fa parte del comportamento dinamico del sistema.

Questo comportamento interattivo è rappresentato in UML da due diagrammi noti come Sequence diagram e Collaboration diagram. Lo scopo fondamentale di entrambi i diagrammi è simile.

Il diagramma di sequenza enfatizza la sequenza temporale dei messaggi e il diagramma di collaborazione enfatizza l'organizzazione strutturale degli oggetti che inviano e ricevono messaggi.

Scopo dei diagrammi di interazione

Lo scopo dei diagrammi di interazione è visualizzare il comportamento interattivo del sistema. Visualizzare l'interazione è un compito difficile. Quindi, la soluzione è utilizzare diversi tipi di modelli per catturare i diversi aspetti dell'interazione.

I diagrammi di sequenza e collaborazione vengono utilizzati per catturare la natura dinamica ma da un'angolazione diversa.

Lo scopo del diagramma di interazione è:

• Per catturare il comportamento dinamico di un sistema.

• Per descrivere il flusso di messaggi nel sistema.

• Descrivere l'organizzazione strutturale degli oggetti.

• Descrivere l'interazione tra gli oggetti.

Come disegnare un diagramma di interazione?

Come abbiamo già discusso, lo scopo dei diagrammi di interazione è catturare l'aspetto dinamico di un sistema. Quindi, per catturare l'aspetto dinamico, dobbiamo capire cos'è un aspetto dinamico e come viene visualizzato. L'aspetto dinamico può essere definito come l'istantanea del sistema in esecuzione in un determinato momento

Abbiamo due tipi di diagrammi di interazione in UML. Uno è il diagramma di sequenza e l'altro è il diagramma di collaborazione. Il diagramma di sequenza cattura la sequenza temporale del flusso di messaggi da un oggetto a un altro e il diagramma di collaborazione descrive l'organizzazione degli oggetti in un sistema che prende parte al flusso di messaggi.

Le seguenti cose devono essere identificate chiaramente prima di disegnare il diagramma di interazione

• Oggetti che prendono parte all'interazione.

• Il messaggio scorre tra gli oggetti.

• La sequenza in cui fluiscono i messaggi.

• Organizzazione degli oggetti.

Di seguito sono riportati due diagrammi di interazione che modellano il sistema di gestione degli ordini. Il primo diagramma è un diagramma di sequenza e il secondo è un diagramma di collaborazione

Il diagramma di sequenza

Il diagramma di sequenza ha quattro oggetti (Customer, Order, SpecialOrder e NormalOrder).

Il diagramma seguente mostra la sequenza dei messaggi per l' oggetto SpecialOrder e la stessa può essere utilizzata in caso di oggetto NormalOrder . È importante comprendere la sequenza temporale dei flussi di messaggi. Il flusso di messaggi non è altro che una chiamata al metodo di un oggetto.

La prima chiamata è sendOrder () che è un metodo dell'oggetto Order . La chiamata successiva è confirm () che è un metodo dell'oggetto SpecialOrder e l'ultima chiamata è Dispatch () che è un metodo dell'oggetto SpecialOrder . Il diagramma seguente descrive principalmente le chiamate di metodo da un oggetto a un altro, e questo è anche lo scenario effettivo quando il sistema è in esecuzione.

Il diagramma di collaborazione

Il secondo diagramma di interazione è il diagramma di collaborazione. Mostra l'organizzazione dell'oggetto come mostrato nel diagramma seguente. Nel diagramma di collaborazione, la sequenza di chiamata del metodo è indicata da una tecnica di numerazione. Il numero indica come i metodi vengono chiamati uno dopo l'altro. Abbiamo utilizzato lo stesso sistema di gestione degli ordini per descrivere il diagramma di collaborazione.

Le chiamate ai metodi sono simili a quelle di un diagramma di sequenza. Tuttavia, la differenza essendo il diagramma di sequenza non descrive l'organizzazione dell'oggetto, mentre il diagramma di collaborazione mostra l'organizzazione dell'oggetto.

Per scegliere tra questi due diagrammi, si pone l'accento sul tipo di requisito. Se la sequenza temporale è importante, viene utilizzato il diagramma di sequenza. Se è richiesta l'organizzazione, viene utilizzato il diagramma di collaborazione.

Dove utilizzare i diagrammi di interazione?

Abbiamo già discusso che i diagrammi di interazione vengono utilizzati per descrivere la natura dinamica di un sistema. Ora esamineremo gli scenari pratici in cui vengono utilizzati questi diagrammi. Per comprendere l'applicazione pratica, dobbiamo comprendere la natura di base della sequenza e del diagramma di collaborazione.

Lo scopo principale di entrambi i diagrammi è simile in quanto vengono utilizzati per catturare il comportamento dinamico di un sistema. Tuttavia, lo scopo specifico è più importante per chiarire e capire.

I diagrammi di sequenza vengono utilizzati per acquisire l'ordine dei messaggi che fluiscono da un oggetto a un altro. I diagrammi di collaborazione vengono utilizzati per descrivere l'organizzazione strutturale degli oggetti che prendono parte all'interazione. Un singolo diagramma non è sufficiente per descrivere l'aspetto dinamico di un intero sistema, quindi viene utilizzato un insieme di diagrammi per catturarlo nel suo insieme.

I diagrammi di interazione vengono utilizzati quando vogliamo comprendere il flusso di messaggi e l'organizzazione strutturale. Flusso di messaggi indica la sequenza del flusso di controllo da un oggetto a un altro. Per organizzazione strutturale si intende l'organizzazione visiva degli elementi in un sistema.

È possibile utilizzare diagrammi di interazione:

• Per modellare il flusso di controllo in base alla sequenza temporale.

• Per modellare il flusso di controllo da parte delle organizzazioni strutturali.

• Per ingegneria avanzata.

• Per il reverse engineering.

Il nome del diagramma stesso chiarisce lo scopo del diagramma e altri dettagli. Descrive i diversi stati di un componente in un sistema. Gli stati sono specifici di un componente / oggetto di un sistema.

Un diagramma di Statechart descrive una macchina a stati. La macchina a stati può essere definita come una macchina che definisce diversi stati di un oggetto e questi stati sono controllati da eventi esterni o interni.

Il diagramma di attività spiegato nel prossimo capitolo è un tipo speciale di diagramma di stato. Poiché il diagramma di Statechart definisce gli stati, viene utilizzato per modellare la durata di un oggetto.

Scopo degli schemi grafici

Il diagramma statechart è uno dei cinque diagrammi UML utilizzati per modellare la natura dinamica di un sistema. Definiscono diversi stati di un oggetto durante la sua vita e questi stati vengono modificati dagli eventi. I diagrammi statechart sono utili per modellare i sistemi reattivi. I sistemi reattivi possono essere definiti come un sistema che risponde a eventi esterni o interni.

Il diagramma del diagramma di stato descrive il flusso di controllo da uno stato a un altro. Gli stati sono definiti come una condizione in cui esiste un oggetto e cambia quando viene attivato un evento. Lo scopo più importante del diagramma Statechart è modellare la durata di un oggetto dalla creazione alla terminazione.

I diagrammi statechart vengono utilizzati anche per il forward e il reverse engineering di un sistema. Tuttavia, lo scopo principale è modellare il sistema reattivo.

Di seguito sono riportati gli scopi principali dell'utilizzo dei diagrammi di Statechart:

• Per modellare l'aspetto dinamico di un sistema.

• Per modellare il tempo di vita di un sistema reattivo.

• Per descrivere i diversi stati di un oggetto durante la sua vita.

• Definire una macchina a stati per modellare gli stati di un oggetto.

Come disegnare un diagramma statico?

Il diagramma Statechart viene utilizzato per descrivere gli stati di diversi oggetti nel suo ciclo di vita. L'enfasi è posta sui cambiamenti di stato su alcuni eventi interni o esterni. Questi stati degli oggetti sono importanti per analizzarli e implementarli accuratamente.

I diagrammi del diagramma di stato sono molto importanti per descrivere gli stati. Gli stati possono essere identificati come la condizione degli oggetti quando si verifica un particolare evento.

Prima di disegnare un diagramma Statechart dovremmo chiarire i seguenti punti:

• Identifica gli oggetti importanti da analizzare.

• Identifica gli stati.

• Identifica gli eventi.

Di seguito è riportato un esempio di un diagramma Statechart in cui viene analizzato lo stato dell'oggetto Order

Il primo stato è uno stato inattivo da cui inizia il processo. Gli stati successivi sono arrivati ​​per eventi come richiesta di invio, richiesta di conferma e ordine di spedizione. Questi eventi sono responsabili dei cambiamenti di stato dell'oggetto ordine.

Durante il ciclo di vita di un oggetto (qui oggetto di ordine) passa attraverso i seguenti stati e possono esserci delle uscite anormali. Questa uscita anomala può verificarsi a causa di qualche problema nel sistema. Quando l'intero ciclo di vita è completo, viene considerata come una transazione completa come mostrato nella figura seguente. Lo stato iniziale e finale di un oggetto è mostrato anche nella figura seguente.

Dove utilizzare i diagrammi del diagramma di stato?

Dalla discussione sopra, possiamo definire le applicazioni pratiche di un diagramma Statechart. I diagrammi statechart vengono utilizzati per modellare l'aspetto dinamico di un sistema come gli altri quattro diagrammi discussi in questo tutorial. Tuttavia, ha alcune caratteristiche distintive per modellare la natura dinamica.

Il diagramma del diagramma di stato definisce gli stati di un componente e questi cambiamenti di stato sono di natura dinamica. Il suo scopo specifico è definire i cambiamenti di stato innescati dagli eventi. Gli eventi sono fattori interni o esterni che influenzano il sistema.

I diagrammi statistici vengono utilizzati per modellare gli stati e anche gli eventi che operano sul sistema. Quando si implementa un sistema, è molto importante chiarire i diversi stati di un oggetto durante il suo ciclo di vita e a questo scopo vengono utilizzati i diagrammi di Statechart. Quando questi stati ed eventi vengono identificati, vengono utilizzati per modellarlo e questi modelli vengono utilizzati durante l'implementazione del sistema.

Se esaminiamo l'implementazione pratica del diagramma Statechart, viene utilizzato principalmente per analizzare gli stati degli oggetti influenzati dagli eventi. Questa analisi è utile per comprendere il comportamento del sistema durante la sua esecuzione.

L'utilizzo principale può essere descritto come:

• Per modellare gli stati dell'oggetto di un sistema.

• Per modellare il sistema reattivo. Il sistema reattivo è costituito da oggetti reattivi.

• Identificare gli eventi responsabili dei cambiamenti di stato.

• Forward e reverse engineering.

Il diagramma di attività è un altro diagramma importante in UML per descrivere gli aspetti dinamici del sistema.

Il diagramma delle attività è fondamentalmente un diagramma di flusso per rappresentare il flusso da un'attività a un'altra attività. L'attività può essere descritta come un'operazione del sistema.

Il flusso di controllo viene tracciato da un'operazione all'altra. Questo flusso può essere sequenziale, ramificato o simultaneo. I diagrammi di attività trattano tutti i tipi di controllo del flusso utilizzando elementi diversi come fork, join, ecc

Scopo dei diagrammi di attività

Lo scopo di base dei diagrammi di attività è simile ad altri quattro diagrammi. Cattura il comportamento dinamico del sistema. Altri quattro diagrammi vengono utilizzati per mostrare il flusso di messaggi da un oggetto a un altro, ma il diagramma di attività viene utilizzato per mostrare il flusso di messaggi da un'attività a un'altra.

L'attività è un'operazione particolare del sistema. I diagrammi di attività non vengono utilizzati solo per visualizzare la natura dinamica di un sistema, ma sono anche utilizzati per costruire il sistema eseguibile utilizzando tecniche di ingegneria diretta e inversa. L'unica cosa che manca nel diagramma di attività è la parte del messaggio.

Non mostra alcun flusso di messaggi da un'attività all'altra. Il diagramma delle attività a volte è considerato come il diagramma di flusso. Anche se i diagrammi sembrano un diagramma di flusso, non lo sono. Mostra flussi diversi come parallelo, ramificato, simultaneo e singolo.

Lo scopo di un diagramma di attività può essere descritto come:

• Disegna il flusso di attività di un sistema.

• Descrivi la sequenza da un'attività all'altra.

• Descrivi il flusso parallelo, ramificato e concorrente del sistema.

Come disegnare un diagramma di attività?

I diagrammi delle attività vengono utilizzati principalmente come diagramma di flusso costituito dalle attività eseguite dal sistema. I diagrammi di attività non sono esattamente diagrammi di flusso in quanto hanno alcune funzionalità aggiuntive. Queste funzionalità aggiuntive includono ramificazione, flusso parallelo, corsia di nuoto, ecc.

Prima di disegnare un diagramma di attività, dobbiamo avere una chiara comprensione degli elementi utilizzati nel diagramma di attività. L'elemento principale di un diagramma di attività è l'attività stessa. Un'attività è una funzione svolta dal sistema. Dopo aver identificato le attività, dobbiamo capire come sono associate a vincoli e condizioni.

Prima di disegnare un diagramma di attività, dovremmo identificare i seguenti elementi:

• Activities

• Association

• Conditions

• Constraints

Una volta identificati i parametri sopra menzionati, è necessario fare un layout mentale dell'intero flusso. Questo layout mentale viene quindi trasformato in un diagramma di attività.

Di seguito è riportato un esempio di diagramma di attività per il sistema di gestione degli ordini. Nel diagramma sono identificate quattro attività associate alle condizioni. Un punto importante dovrebbe essere chiaramente compreso che un diagramma di attività non può essere abbinato esattamente con il codice. Il diagramma delle attività è realizzato per comprendere il flusso delle attività ed è utilizzato principalmente dagli utenti aziendali

Il diagramma seguente è disegnato con le quattro attività principali:

• Invia ordine dal cliente

• Ricevimento dell'ordine

• Conferma l'ordine

• Spedisci l'ordine

Dopo aver ricevuto la richiesta d'ordine, vengono eseguiti i controlli delle condizioni per verificare se si tratta di un ordine normale o speciale. Dopo che il tipo di ordine è stato identificato, viene eseguita l'attività di spedizione che viene contrassegnata come la conclusione del processo.

Dove utilizzare i diagrammi di attività?

L'utilizzo di base del diagramma di attività è simile ad altri quattro diagrammi UML. L'utilizzo specifico è modellare il flusso di controllo da un'attività all'altra. Questo flusso di controllo non include i messaggi.

Il diagramma delle attività è adatto per modellare il flusso di attività del sistema. Un'applicazione può avere più sistemi. Il diagramma di attività cattura anche questi sistemi e descrive il flusso da un sistema all'altro. Questo utilizzo specifico non è disponibile in altri diagrammi. Questi sistemi possono essere database, code esterne o qualsiasi altro sistema.

Esamineremo ora le applicazioni pratiche del diagramma di attività. Dalla discussione di cui sopra, è chiaro che un diagramma di attività è tratto da un livello molto alto. Quindi offre una visione di alto livello di un sistema. Questa visualizzazione di alto livello è principalmente per utenti aziendali o qualsiasi altra persona che non sia una persona tecnica.

Questo diagramma viene utilizzato per modellare le attività che non sono altro che requisiti aziendali. Il diagramma ha un impatto maggiore sulla comprensione del business piuttosto che sui dettagli di implementazione.

Il diagramma delle attività può essere utilizzato per:

• Modellazione del flusso di lavoro utilizzando le attività.

• Modellazione dei requisiti aziendali.

• Comprensione di alto livello delle funzionalità del sistema.

• Analisi dei requisiti aziendali in una fase successiva.