Parliamo di UML

Parliamo di UML

Quando Parliamo di UML intendiamo l’ abbreviazione di Unified Modeling Language, è un linguaggio di modellazione standardizzato costituito da un set integrato di diagrammi, sviluppato per aiutare gli sviluppatori di sistemi e software a specificare, visualizzare, costruire e documentare gli artefatti dei sistemi software, nonché per la modellazione aziendale e altri sistemi non software. Se parliamo di UML intendiamo rappresentare una raccolta di best practice ingegneristiche che hanno dimostrato di avere successo nella modellazione di sistemi grandi e complessi. UML è una parte molto importante dello sviluppo di software orientato agli oggetti e del processo di sviluppo software. UML utilizza principalmente notazioni grafiche per esprimere la progettazione di progetti software. L’utilizzo di UML aiuta i team di progetto a comunicare, esplorare potenziali progetti e convalidare la progettazione architettonica del software. In questo articolo, ti forniremo idee dettagliate su cosa sia UML, la storia di UML e una descrizione di ciascun tipo di diagramma UML, insieme ad esempi UML.

L’origine di UML – Parliamo di UML
L’obiettivo di UML è di fornire una notazione standard che possa essere utilizzata da tutti i metodi orientati agli oggetti e di selezionare e integrare i migliori elementi delle notazioni precursore. UML è stato progettato per un’ampia gamma di applicazioni. Quindi, fornisce costrutti per un’ampia gamma di sistemi e attività (ad esempio, sistemi distribuiti, analisi, progettazione e distribuzione di sistemi).

Se parliamo di UML intendiamo una notazione che è il risultato dell’unificazione di OMT da:

• Tecnica di modellazione degli oggetti OMT [ James Rumbaugh 1991] – era la migliore per l’analisi e i sistemi informativi ad alta intensità di dati.
• Booch [ Grady Booch 1994] – è stato eccellente per progettazione e implementazione. Grady Booch aveva lavorato molto con il linguaggio Ada ed era stato un attore importante nello sviluppo di tecniche orientate agli oggetti per il linguaggio. Sebbene il metodo Booch fosse forte, la notazione è stata accolta meno bene (molte forme di nuvole dominavano i suoi modelli – non molto ordinato)
• OOSE (Object-Oriented Software Engineering [ Ivar Jacobson 1992]) – presentava un modello noto come Casi d’uso. I Casi d’uso sono una tecnica potente per comprendere il comportamento di un intero sistema (un’area in cui OO è stata tradizionalmente debole).

Nel 1994, Jim Rumbaugh, il creatore di OMT, sbalordì il mondo del software quando lasciò la General Electric e si unì a Grady Booch alla Rational Corp. L’obiettivo della partnership era di fondere le loro idee in un singolo metodo unificato (il titolo provvisorio del metodo era in effetti “Unified Method”).

Nel 1995, il creatore di OOSE, Ivar Jacobson, si era unito a Rational e le sue idee (in particolare il concetto di “casi d’uso”) furono inserite nel nuovo Unified Method, ora chiamato Unified Modelling Language1. Il team di Rumbaugh, Booch e Jacobson è affettuosamente noto come i “Three Amigos”

L’UML è stato influenzato anche da altre notazioni orientate agli oggetti:

• Mellor e Shlaer [1998]
• Coad e Yourdon [1995]
• Il ritorno di Wirfs-Brock [1990]
• Martin e Odell [1992]

Se parliamo di UML includiamo anche nuovi concetti che all’epoca non erano presenti in altri metodi principali, come i meccanismi di estensione e un linguaggio di vincoli.

Storia dell’UML – Parliamo di UML
Nel 1996, la prima richiesta di proposta (RFP) emessa dall’Object Management Group (OMG) fornì lo stimolo affinché queste organizzazioni unissero le forze per produrre una risposta RFP congiunta.
Rational ha costituito il consorzio UML Partners con diverse organizzazioni disposte a dedicare risorse per lavorare verso una solida definizione UML 1.0. Quelli che hanno contribuito maggiormente alla definizione UML 1.0 includevano:

• Società di apparecchiature digitali
• CV
• i-Logix
• IntelliCorp
• IBM
• Elaborazione ICONA
• Sistema MCI
• Microsoft
• Oracolo
• Software razionale
• Io
• Unisistemi

Questa collaborazione ha prodotto UML 1.0, un linguaggio di modellazione ben definito, espressivo, potente e generalmente applicabile. Questo è stato presentato all’OMG nel gennaio 1997 come risposta RFP iniziale.1
Nel gennaio 1997 IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies e Softeam hanno anche presentato risposte RFP separate all’OMG. Queste aziende si sono unite ai partner UML per contribuire con le loro idee e insieme i partner hanno prodotto la risposta UML 1.1 rivista. L’obiettivo della versione UML 1.1 era migliorare la chiarezza della semantica UML 1.0 e incorporare i contributi dei nuovi partner. È stata presentata all’OMG per la sua valutazione e adottata nell’autunno del 1997.1 e migliorata da 1.1 a 1.5 e successivamente a UML 2.1 da 01 a 06 (ora la versione corrente di UML è 2.5)

Perché UML – Parliamo di UML
Poiché il valore strategico del software aumenta per molte aziende, il settore cerca tecniche per automatizzare la produzione di software e per migliorare la qualità e ridurre i costi e il time-to-market. Queste tecniche includono la tecnologia dei componenti, la programmazione visuale, i pattern e i framework. Le aziende cercano anche tecniche per gestire la complessità dei sistemi man mano che aumentano in ambito e scala. In particolare, riconoscono la necessità di risolvere problemi architettonici ricorrenti, come distribuzione fisica, concorrenza, replicazione, sicurezza, bilanciamento del carico e tolleranza agli errori. Inoltre, lo sviluppo per il World Wide Web, pur semplificando alcune cose, ha esacerbato questi problemi architettonici. L’Unified Modeling Language (UML) è stato progettato per rispondere a queste esigenze. Gli obiettivi principali nella progettazione dell’UML sono riassunti da Page-Jones in Fundamental Object-Oriented Design in UML come segue:

• Fornire agli utenti un linguaggio di modellazione visiva espressivo e pronto all’uso, in modo che possano sviluppare e scambiare modelli significativi.
• Fornire meccanismi di estensibilità e specializzazione per ampliare i concetti fondamentali.
• Essere indipendenti da particolari linguaggi di programmazione e processi di sviluppo.
• Fornire una base formale per comprendere il linguaggio di modellazione.
• Incoraggiare la crescita del mercato degli strumenti OO.
• Supportare concetti di sviluppo di livello superiore quali collaborazioni, framework, modelli e componenti.
• Integrare le migliori pratiche.

Parliamo di UML – Una panoramica
Prima di iniziare ad analizzare la teoria dell’UML, faremo una breve panoramica di alcuni dei concetti principali dell’UML.

La prima cosa da notare riguardo all’UML è che ci sono molti diagrammi (modelli) diversi a cui abituarsi. Il motivo è che è possibile guardare un sistema da molti punti di vista diversi. Uno sviluppo software avrà molti stakeholder che giocano un ruolo.

Per esempio:

• Analisti
• Progettisti
• Programmatori informatici
• Tester
• Controllo qualità
• Il cliente
• Autori tecnici

Tutte queste persone sono interessate a diversi aspetti del sistema e ciascuna di esse richiede un diverso livello di dettaglio. Ad esempio, un programmatore deve comprendere la progettazione del sistema ed essere in grado di convertire la progettazione in un codice di basso livello. Al contrario, uno scrittore tecnico è interessato al comportamento del sistema nel suo complesso e deve comprendere come funziona il prodotto. L’UML tenta di fornire un linguaggio così espressivo che tutte le parti interessate possano trarre vantaggio da almeno un diagramma UML.

Poichè parliamo di UML diamo un’ occhiata a ciascuno di questi 13 diagrammi, e lo raccontiamo di seguito.

I diagrammi di struttura mostrano la struttura statica del sistema e delle sue parti su diversi livelli di astrazione e implementazione e come sono correlati tra loro. Gli elementi in un diagramma di struttura rappresentano i concetti significativi di un sistema e possono includere concetti astratti, del mondo reale e di implementazione, ci sono sette tipi di diagramma di struttura come segue:

• Diagramma di classe
• Diagramma dei componenti
• Diagramma di distribuzione
• Diagramma dell’oggetto
• Diagramma del pacchetto
• Diagramma della struttura composita
• Diagramma del profilo

I diagrammi comportamentali mostrano il comportamento dinamico degli oggetti in un sistema, che può essere descritto come una serie di cambiamenti del sistema nel tempo . Esistono sette tipi di diagrammi comportamentali come segue:

• Diagramma dei casi d’uso
• Diagramma di attività
• Diagramma della macchina a stati
• Diagramma di sequenza
• Diagramma di comunicazione
• Diagramma di panoramica dell’interazione
• Diagramma temporale

Che cos’è un diagramma di classe? – Parliamo di UML
Il diagramma di classe è una tecnica di modellazione centrale che attraversa quasi tutti i metodi orientati agli oggetti. Questo diagramma descrive i tipi di oggetti nel sistema e vari tipi di relazioni statiche che esistono tra di essi.

Relazioni – Parliamo di UML
Esistono tre tipi principali di relazioni che sono importanti:

• Associazione : rappresenta relazioni tra istanze di tipi (una persona lavora per un’azienda, un’azienda ha più uffici).
• Ereditarietà : l’aggiunta più ovvia ai diagrammi ER per l’uso in OO. Ha una corrispondenza immediata con l’ereditarietà nella progettazione OO.
• Aggregazione – Aggregazione, una forma di composizione di oggetti nella progettazione orientata agli oggetti.

Che cos’è il diagramma dei componenti? – Parliamo di UML
Nel linguaggio di modellazione unificato, un diagramma dei componenti illustra come i componenti sono cablati insieme per formare componenti più grandi o sistemi software. Illustra le architetture dei componenti software e le dipendenze tra di essi. Tali componenti software includono componenti di runtime, componenti eseguibili e anche componenti del codice sorgente.

Che cos’è un diagramma di distribuzione? – Parliamo di UML
Il Deployment Diagram aiuta a modellare l’aspetto fisico di un sistema software orientato agli oggetti. È un diagramma di struttura che mostra l’architettura del sistema come distribuzione di artefatti software a target di distribuzione. Gli artefatti rappresentano elementi concreti nel mondo fisico che sono il risultato di un processo di sviluppo. Modella la configurazione di runtime in una vista statica e visualizza la distribuzione di artefatti in un’applicazione. Nella maggior parte dei casi, comporta la modellazione delle configurazioni hardware insieme ai componenti software che vi risiedevano.

Che cos’è un diagramma di oggetti? – Parliamo di UML
Un diagramma di oggetti è un grafico di istanze, inclusi oggetti e valori di dati. Un diagramma di oggetti statico è un’istanza di un diagramma di classe; mostra un’istantanea dello stato dettagliato di un sistema in un punto nel tempo. La differenza è che un diagramma di classe rappresenta un modello astratto costituito da classi e dalle loro relazioni. Tuttavia, un diagramma di oggetti rappresenta un’istanza in un momento particolare, che è di natura concreta. L’uso di diagrammi di oggetti è abbastanza limitato, vale a dire per mostrare esempi di struttura dati.

Diagramma di classe vs diagramma di oggetto – Un esempio
Alcune persone potrebbero trovare difficile comprendere la differenza tra un diagramma di classe UML e un diagramma di oggetto UML poiché entrambi comprendono “blocchi rettangolari” denominati, con attributi al loro interno e con collegamenti tra loro, che rendono i due diagrammi UML simili. Alcune persone potrebbero persino pensare che siano la stessa cosa perché nello strumento UML usano entrambe le notazioni per il diagramma di classe e il diagramma di oggetto che sono inserite nello stesso editor di diagrammi: diagramma di classe.

Ma in realtà, Class Diagram e Object Diagram rappresentano due aspetti diversi di una base di codice. In questo articolo, vi forniremo alcune idee su questi due diagrammi UML, cosa sono, quali sono le loro differenze e quando utilizzare ciascuno di essi.

Relazione tra diagramma di classe e diagramma di oggetto – Parliamo di UML
Creiamo “classi” quando programmiamo. Ad esempio, in un sistema di online banking possiamo creare classi come “Utente”, “Conto”, “Transazione”, ecc. In un sistema di gestione delle classi possiamo creare classi come “Insegnante”, “Studente”, “Assegnazione”, ecc. In ogni classe, ci sono attributi e operazioni che rappresentano le caratteristiche e il comportamento della classe. Class Diagram è un diagramma UML in cui puoi visualizzare quelle classi, insieme ai loro attributi, operazioni e interrelazione.

UML Object Diagram mostra come le istanze di oggetti nel tuo sistema interagiscono tra loro in uno stato particolare. Rappresenta anche i valori dei dati di quegli oggetti in quello stato. In altre parole, un UML Object Diagram può essere visto come una rappresentazione di come le classi (disegnate in UML Class Diagram) vengono utilizzate in uno stato particolare.

Se non sei un fan di queste cose di definizione, dai un’occhiata ai seguenti esempi di diagramma UML. Credo che capirai le loro differenze in pochi secondi.

Esempio di diagramma di classe – Parliamo di UML
Il seguente esempio di Class Diagram rappresenta due classi: User e Attachment. Un utente può caricare più attachment, quindi le due classi sono collegate con un’associazione, con 0..* come molteplicità sul lato

Esempio di diagramma di oggetto –Parliamo di UML
Il seguente esempio di Object Diagram mostra come “sembrano” le istanze di oggetti delle classi User e Attachment nel momento in cui Peter (ovvero l’utente) sta tentando di caricare due allegati. Quindi ci sono due Instance Specification per i due oggetti allegato da caricare.

Che cos’è un diagramma di pacchetto? – Parliamo di UML
Il diagramma del pacchetto è un diagramma di struttura UML che mostra i pacchetti e le dipendenze tra i pacchetti. I diagrammi modello consentono di mostrare diverse viste di un sistema, ad esempio, come applicazione multistrato (alias multi-tiered) – modello di applicazione multistrato.

Che cos’è un diagramma di struttura composita?– Parliamo di UML
Composite Structure Diagram è uno dei nuovi artefatti aggiunti a UML 2.0. Un composite structure diagram è simile a un class diagram ed è un tipo di component diagram usato principalmente nella modellazione di un sistema dal punto di vista micro, ma raffigura singole parti anziché intere classi. È un tipo di static structure diagram che mostra la struttura interna di una classe e le collaborazioni che questa struttura rende possibili.

Questo diagramma può includere parti interne, porte attraverso cui le parti interagiscono tra loro o attraverso cui le istanze della classe interagiscono con le parti e con il mondo esterno, e connettori tra parti o porte. Una struttura composita è un set di elementi interconnessi che collaborano in fase di esecuzione per raggiungere uno scopo. Ogni elemento ha un ruolo definito nella collaborazione.

Che cos’è un diagramma di profilo? – Parliamo di UML
Un diagramma di profilo consente di creare stereotipi specifici di dominio e piattaforma e di definire le relazioni tra di essi. È possibile creare stereotipi disegnando forme stereotipali e collegarle con la composizione o la generalizzazione tramite l’interfaccia incentrata sulle risorse. È inoltre possibile definire e visualizzare valori taggati di stereotipi.

Che cos’è un diagramma dei casi d’uso? – Parliamo di UML
Un modello di caso d’uso descrive i requisiti funzionali di un sistema in termini di casi d’uso. È un modello della funzionalità prevista del sistema (casi d’uso) e del suo ambiente (attori). I casi d’uso consentono di mettere in relazione ciò di cui si ha bisogno da un sistema con il modo in cui il sistema soddisfa tali esigenze.

Pensiamo ad un modello di caso d’uso come a un menu, molto simile al menu che troveremmo in un ristorante. Guardando il menu, sappiamo cosa è disponibile per noi, i singoli piatti e i loro prezzi. Sappiamo anche che tipo di cucina serve il ristorante: italiana, messicana, cinese e così via. Guardando il menu, ci facciamo un’idea generale dell’esperienza culinaria che ci aspetta in quel ristorante. Il menu, in effetti, “modella” il comportamento del ristorante.

Poiché si tratta di uno strumento di pianificazione molto potente, il modello dei casi d’uso viene generalmente utilizzato in tutte le fasi del ciclo di sviluppo da tutti i membri del team.

Che cos’è un diagramma di attività?
I diagrammi di attività sono rappresentazioni grafiche di flussi di lavoro di attività e azioni graduali con supporto per scelta, iterazione e concorrenza. Descrivono il flusso di controllo del sistema di destinazione, come l’esplorazione di complesse regole aziendali e operazioni, descrivendo il caso d’uso e anche il processo aziendale. Nell’Unified Modeling Language, i diagrammi di attività sono intesi a modellare sia i processi computazionali che organizzativi (ad esempio flussi di lavoro).

Che cosa è un diagramma di macchina a stati?
Un diagramma di stato è un tipo di diagramma utilizzato in UML per descrivere il comportamento dei sistemi, che si basa sul concetto di diagrammi di stato di David Harel. I diagrammi di stato raffigurano gli stati e le transizioni consentiti, nonché gli eventi che influenzano queste transizioni. Aiuta a visualizzare l’intero ciclo di vita degli oggetti e quindi a fornire una migliore comprensione dei sistemi basati sullo stato.

Che cos’è un diagramma sequenziale?
Il Sequence Diagram modella la collaborazione degli oggetti in base a una sequenza temporale. Mostra come gli oggetti interagiscono con gli altri in uno scenario particolare di un caso d’uso. Con la capacità di modellazione visiva avanzata, puoi creare un diagramma di sequenza complesso in pochi clic. Inoltre, alcuni strumenti di modellazione come Visual Paradigm possono generare un diagramma di sequenza dal flusso di eventi che hai definito nella descrizione del caso d’uso.

Cos’è un diagramma di comunicazione?
Simile al Sequence Diagram, il Communication Diagram è utilizzato anche per modellare il comportamento dinamico del caso d’uso. Rispetto al Sequence Diagram, il Communication Diagram è più focalizzato sulla visualizzazione della collaborazione degli oggetti piuttosto che sulla sequenza temporale. In realtà sono semanticamente equivalenti, quindi alcuni degli strumenti di modellazione come Visual Paradigm consentono di generarlo dall’uno all’altro.

Che cos’è il diagramma di panoramica dell’interazione?
L’Interaction Overview Diagram si concentra sulla panoramica del flusso di controllo delle interazioni. È una variante dell’Activity Diagram in cui i nodi sono le interazioni o gli eventi di interazione. L’Interaction Overview Diagram descrive le interazioni in cui messaggi e linee di vita sono nascosti. È possibile collegare i diagrammi “reali” e ottenere un elevato grado di navigabilità tra i diagrammi all’interno dell’Interaction Overview Diagram.

Cos’è un diagramma temporale?
Il diagramma temporale mostra il comportamento dell’oggetto/degli oggetti in un dato periodo di tempo. Il diagramma temporale è una forma speciale di un diagramma di sequenza. Le differenze tra il diagramma temporale e il diagramma di sequenza sono che gli assi sono invertiti in modo che il tempo aumenti da sinistra a destra e le linee di vita sono mostrate in compartimenti separati disposti verticalmente.

Glossario e termini UML – Parliamo di UML
Classe astratta – Una classe che non verrà mai istanziata. Un’istanza di questa classe non esisterà mai.
Attore – Un oggetto o una persona che avvia gli eventi in cui è coinvolto il sistema.
Attività : un passaggio o un’azione all’interno di un diagramma di attività. Rappresenta un’azione intrapresa dal sistema o da un attore.
Diagramma di attività : diagramma di flusso evoluto che mostra i passaggi, le decisioni e le operazioni parallele all’interno di un processo, come un algoritmo o un processo aziendale.
Aggregazione – È una parte di un’altra classe. Mostrata con un diamante vuoto accanto alla classe che la contiene nei diagrammi.
Artefatti – Documenti che descrivono l’output di una fase del processo di progettazione. La descrizione è grafica, testuale o una combinazione di queste.
Associazione – Una connessione tra due elementi di un Modello. Potrebbe rappresentare una variabile membro nel codice, o l’associazione tra un fascicolo personale e la persona che rappresenta, o una relazione tra due categorie di lavoratori, o qualsiasi relazione simile. Per impostazione predefinita, entrambi gli elementi in un’Associazione sono uguali e sono a conoscenza l’uno dell’altro tramite l’Associazione. Un’Associazione può anche essere un’Associazione Navigabile, il che significa che l’estremità sorgente dell’associazione è a conoscenza dell’estremità di destinazione, ma non viceversa.
Classe di associazione : una classe che rappresenta e aggiunge informazioni all’associazione tra due altre classi.
Attributi : caratteristiche di un oggetto che possono essere utilizzate per fare riferimento ad altri oggetti o per salvare informazioni sullo stato dell’oggetto.
Classe base : una classe che definisce attributi e operazioni ereditati da una sottoclasse tramite una relazione di generalizzazione.
Branch : un punto di decisione in un diagramma di attività. Dal Branch emergono più transizioni, ciascuna con una condizione di guardia. Quando il controllo raggiunge il Branch, deve essere vera esattamente una condizione di guardia; e il controllo segue la transizione corrispondente.
Classe : una categoria di oggetti simili, tutti descritti dagli stessi attributi e operazioni e tutti compatibili con l’assegnazione.
Diagramma di classe : mostra le classi del sistema e le relazioni tra di esse.
Classificatore : un elemento UML che ha Attributi e Operazioni. In particolare, Attori, Classi e Interfacce.
Collaborazione : relazione tra due oggetti in un diagramma di comunicazione, che indica che i messaggi possono passare avanti e indietro tra gli oggetti.
Diagramma di comunicazione : diagramma che mostra come vengono eseguite le operazioni, sottolineando i ruoli degli oggetti.
Componente : un’unità di codice distribuibile all’interno del sistema.
Diagramma dei componenti : diagramma che mostra le relazioni tra vari componenti e interfacce.
Concetto – Un sostantivo o un’idea astratta da includere in un modello di dominio.
Fase di costruzione – La terza fase del Rational Unified Process durante la quale diverse iterazioni di funzionalità vengono integrate nel sistema in costruzione. È qui che viene svolto il lavoro principale.
Dipendenza : relazione che indica che un classificatore conosce gli attributi e le operazioni di un altro classificatore, ma non è direttamente connesso a nessuna istanza del secondo classificatore.
Diagramma di distribuzione : diagramma che mostra le relazioni tra vari processori.
Dominio : la parte dell’universo in cui è coinvolto il sistema.
Fase di elaborazione : la seconda fase del Rational Unified Process che consente un’ulteriore pianificazione del progetto, comprese le iterazioni della fase di costruzione.
Elemento : qualsiasi elemento che appare in un modello.
Incapsulamento : i dati negli oggetti sono privati.
Generalizzazione – Indica che una classe è una sottoclasse di un’altra classe (superclasse). Una freccia vuota punta alla superclasse.
Evento : in un diagramma di stato, rappresenta un segnale, un evento o un input che induce il sistema a intraprendere un’azione o a cambiare stato.
Stato finale : in un diagramma di stato o di attività, indica il punto in cui il diagramma si completa.
Fork : punto in un diagramma di attività in cui iniziano più thread di controllo paralleli.
Generalizzazione : relazione di ereditarietà in cui una sottoclasse eredita e aggiunge attributi e operazioni a una classe base.
GoF – Insieme di modelli di progettazione Gang of Four.
Elevata coesione : un modello valutativo GRASP che garantisce che la classe non sia troppo complessa e non svolga funzioni non correlate.
Low Coupling : modello valutativo GRASP che misura quanto una classe dipende da un’altra classe o è connessa a un’altra classe.
Fase di avvio : la prima fase del Rational Unified Process che riguarda la concettualizzazione originale e l’inizio del progetto.
Ereditarietà – Le sottoclassi ereditano gli attributi o le caratteristiche della loro classe genitore (superclasse). Questi attributi possono essere sovrascritti nella sottoclasse.
Stato iniziale : in un diagramma di stato o di attività, indica il punto in cui inizia il diagramma.
Istanza – Una classe è usata come modello per creare un oggetto. Questo oggetto è chiamato istanza della classe. È possibile creare un numero qualsiasi di istanze della classe.
Interfaccia : un classificatore che definisce attributi e operazioni che formano un contratto per il comportamento. Una classe o componente provider può scegliere di realizzare un’interfaccia (ovvero implementare i suoi attributi e operazioni). Una classe o componente client può quindi dipendere dall’interfaccia e quindi utilizzare il provider senza alcun dettaglio della vera classe del provider.
Iterazione – Una sezione di mini progetto durante la quale viene aggiunta una piccola parte di funzionalità al progetto. Include il ciclo di sviluppo di analisi, progettazione e codifica.
Join : punto in un diagramma di attività in cui più thread di controllo paralleli si sincronizzano e si riuniscono.
Membro : un attributo o un’operazione all’interno di un classificatore.
Unione : punto in un diagramma di attività in cui si uniscono diversi percorsi di controllo.
Messaggio – Una richiesta da un oggetto a un altro che chiede all’oggetto che riceve il messaggio di fare qualcosa. Si tratta fondamentalmente di una chiamata a un metodo nell’oggetto ricevente.
Metodo – Una funzione o procedura in un oggetto.
Modello – L’artefatto UML centrale. È costituito da vari elementi disposti in una gerarchia da pacchetti, con relazioni anche tra gli elementi.
Molteplicità – Mostrata in un modello di dominio e indicata all’esterno delle caselle concettuali, indica la relazione tra la quantità dell’oggetto e i quantili di altri oggetti.
Navigabilità : indica quale estremità di una relazione è a conoscenza dell’altra estremità. Le relazioni possono avere Navigabilità bidirezionale (ogni estremità è a conoscenza dell’altra) o Navigabilità unidirezionale (un’estremità è a conoscenza dell’altra, ma non viceversa).
Notazione – Documento grafico con regole per la creazione di metodi di analisi e progettazione.
Nota : una nota di testo aggiunta a un diagramma per spiegarlo più in dettaglio.
Oggetto – Oggetto: in un diagramma di attività, un oggetto che riceve informazioni dalle attività o fornisce informazioni alle attività. In un diagramma di collaborazione o un diagramma di sequenza, un oggetto che partecipa allo scenario rappresentato nel diagramma. In generale: un’istanza o un esempio di un dato classificatore (attore, classe o interfaccia).
Pacchetto : gruppo di elementi UML che logicamente dovrebbero essere raggruppati insieme.
Diagramma del pacchetto : diagramma di classe in cui tutti gli elementi sono pacchetti e dipendenze.
Pattern – Soluzioni utilizzate per determinare l’assegnazione di responsabilità per gli oggetti da interagire. È un nome per una soluzione di successo a un problema comune ben noto.
Parametro : argomento di un’operazione.
Polimorfismo – Stesso messaggio, metodo diverso. Utilizzato anche come pattern.
Privato : livello di visibilità applicato a un attributo o a un’operazione, che indica che solo il codice per il classificatore che contiene il membro può accedere al membro.
Processore : in un diagramma di distribuzione, rappresenta un computer o un altro dispositivo programmabile in cui può essere distribuito il codice.
Protetto : livello di visibilità applicato a un attributo o a un’operazione, che indica che solo il codice per il classificatore che contiene il membro o per le sue sottoclassi può accedere al membro.
Pubblico : livello di visibilità applicato a un attributo o a un’operazione, che indica che qualsiasi codice può accedere al membro.
Freccia di direzione di lettura : indica la direzione di una relazione in un modello di dominio.
Realizzazione : indica che un componente o una classe fornisce una determinata interfaccia.
Ruolo – Utilizzato in un modello di dominio, è una descrizione facoltativa del ruolo di un attore.
Diagramma di sequenza : un diagramma che mostra l’esistenza di oggetti nel tempo e i messaggi che passano tra quegli oggetti nel tempo per eseguire un comportamento. Diagramma del grafico di stato: un diagramma che mostra tutti i possibili stati degli oggetti.
Stato : in un diagramma di stato, rappresenta uno stato di un sistema o sottosistema: cosa sta facendo in un dato momento, nonché i valori dei suoi dati.
Diagramma di stato : diagramma che mostra gli stati di un sistema o sottosistema, le transizioni tra gli stati e gli eventi che causano le transizioni.
Statico : un modificatore di un Attributo per indicare che c’è una sola copia dell’Attributo condivisa tra tutte le istanze del Classificatore. Un modificatore di un’Operazione per indicare che l’Operazione è indipendente e non opera su un’istanza specifica del Classificatore.
Stereotipo : un modificatore applicato a un elemento del modello che indica qualcosa su di esso che normalmente non può essere espresso in UML. In sostanza, gli stereotipi consentono di definire il proprio “dialetto” di UML.
Sottoclasse : una classe che eredita attributi e operazioni definiti da una sottoclasse tramite una relazione di generalizzazione.
Swimlane : un elemento di un Activity Diagram che indica quali parti di un sistema o di un dominio eseguono particolari Attività. Tutte le Attività all’interno di una Swimlane sono responsabilità dell’Oggetto, Componente o Attore rappresentato dalla Swimlane.
Time Boxing : ogni iterazione avrà un limite di tempo con obiettivi specifici.
Transizione : in un diagramma di attività, rappresenta un flusso di controllo da un’attività o ramo o fusione o biforcazione o join a un’altra. In un diagramma di stato, rappresenta un cambiamento da uno stato a un altro.
Fase di transizione : l’ultima fase del Rational Unified Process, durante la quale gli utenti vengono formati sull’utilizzo del nuovo sistema e il sistema viene reso disponibile agli utenti.
UML (Unified Modeling Language) utilizza documenti di testo e grafici per migliorare l’analisi e la progettazione di progetti software consentendo relazioni più coese tra gli oggetti.
Caso d’uso : in un diagramma dei casi d’uso, rappresenta un’azione che il sistema intraprende in risposta a una richiesta da parte di un attore.
Diagramma dei casi d’uso : diagramma che mostra le relazioni tra attori e casi d’uso.
Visibilità : un modificatore di un Attributo o di un’Operazione che indica quale codice ha accesso al membro. I livelli di visibilità includono Pubblico, Protetto e Privato.
Flusso di lavoro : insieme di attività che producono un risultato specifico.

(fonte)

Innovaformazione, scuola informatica specialistica promuove la cultura IT fra aziende e privati.

L’offerta formativa è ricca e sempre aggiornata con i trend di mercato. Trovate l’elenco corsi QUI.

INFO: info@innovaformazione.net – tel. 3471012275 (Dario Carrassi)