UML: un passo avanti per l’ingegneria del software

Uml consente di effettuare l'astrazione della realtà mediante modelli basandosi sul linguaggio di programmazione ad oggetti

0
838
UML Unified Modeling Language, Close-up Engineering
caso d'uso, Close up engineering
tecninfo.drivehq.com

UML (Unified Modeling Language, “linguaggio di modellazione unificato”) è un linguaggio di modellazione e specifica basato sul paradigma object-oriented . Il nucleo del linguaggio viene definito nel 1996 da Grady Booch, Jim Rumbaugh e Ivar Jacombson sotto la guida dello Object Management Group, consorzio che tuttora gestisce lo standard UML. Lo scopo principale di UML,  linguaggio semiformale e grafico poiché utilizza una serie di diagrammi, è quello di specificare, visualizzare, realizzare, modificare e documentare gli artefatti di un nuovo sistema o di uno già esistente software e non. Per artefatto intenderemo qualunque prodotto tangibile del progetto: sorgenti, eseguibili, documentazione, file di configurazione, tabelle di database, benchmark… In buona sostanza si tratta di un linguaggio di modellazione utilizzato indipendente dall’ambito del progetto, dal processo di sviluppo e dal linguaggio di programmazione dal momento che è stato progettato per essere abbinato alla maggior parte dei linguaggi object-oriented.

Alla base della programmazione UML ci sono i diagrammi che visualizzano una particolare proiezione del sistema analizzato da una specifica prospettiva. Essi possono essere classificati a livello logico:

  • Diagramma dei casi d’uso (Use Case Diagram): mostra le modalità di utilizzo del sistema mediante i casi d’uso, gli utilizzatori e coloro i quali interagiscono con il sistema e le relazioni fra gli attori e i casi d’uso;
  • Diagramma delle classi (Class Diagram): rappresenta le classi di oggetti del sistema con i loro attributi e operazioni; mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione) e può essere utilizzato a diversi livelli di dettaglio ( in analisi e in disegno);
  • Diagramma di sequenza (Sequence Diagram): è utilizzato per definire la logica di uno scenario (dal momento che specifica una sequenza di eventi) di un caso d’uso,mostra gli oggetti coinvolti mostrando la sequenza temporale dei messaggi scambiati dagli oggetti;
  • Diagramma di collaborazione (Collaboration Diagram): rappresenta un insieme di oggetti che collaborano per realizzare il comportamento di uno scenario di un caso d’uso;
  • Diagramma di transizione di stato (Statechart Diagram): è normalmente utilizzato per modellare il ciclo di vita degli oggetti di una singola classe, mostra gli eventi che causano la transizione da uno stato all’altro, le azioni eseguite a fronte di un determinato evento; quando un oggetto si trova in un certo stato può essere interessato da determinati eventi ( e non da altri) è opportuno utilizzarlo solo per le classi che presentano un ciclo di vita complesso e segnato da una successione ben definita di eventi;
  • Diagramma delle attività (Activity Diagram): rapresenta sistemi di workflow, oppure la logica interna di un caso d’uso o di una specifica operazione di una classe; consente di modellare processi paralleli e la loro sincronizzazione registrando ogni specifico stato di un’attività;

e a livello fisico:

  • Diagramma dei componenti (Component Diagram): evidenzia l’organizzazione e le dipendenze tra i componenti software che possono essere raggruppati in package;
  • Diagramma di distribuzione dei componenti (Deployment Diagram): è utilizzato per mostrare come sono allocate le componenti hardware e software per un’applicazione.

Esiste poi la possibilità di specificare tre importanti relazioni fra i casi d’uso:

  • Relazione di inclusione <<include>> : indica che il caso d’uso principale incorpora esplicitamente il comportamento di un altro caso d’uso subordinato; il caso d’uso principale indica l’esatto punto in cui il caso d’uso subordinato viene incluso; al termine dell’esecuzione del caso d’uso subordinato, il caso d’uso principale riprende dal punto in cui è stato sospeso;
  • Relazione di generalizzazione: indica che il caso d’uso subordinato estende il comportamento del caso d’uso principale, aggiungendo la logica necessaria per gestire eccezioni, flussi di lavoro alternativi, ecc. Il caso d’uso principale indica l’esatto punto in cui il caso d’uso subordinato viene incluso (detto “punto d’estensione”); al termine dell’esecuzione del caso d’uso subordinato, il caso d’uso principale riprende dal punto in cui è stato sospeso;
  • Relazione di estensione <<extend>>: specifica gerarchie di attori e/o casi d’uso (s’intende concettualmente la classificazione di ereditarietà).

 

SHARE
Previous articleL’utilità strategica dei big data per le Pmi
Next articleCome economizzare cambiando font?
Francesca Granatiero nasce a San Giovanni Rotondo, classe 1988. Frequenta il Liceo Scientifico a Manfredonia per poi intraprendere, conseguito il diploma, la facoltà di Ingegneria Gestionale presso il Politecnico di Bari. Iscrittasi al corso di Laurea Magistrale in Ingegneria Gestionale presso lo stesso Politecnico di Bari consegue il titolo di Esperto in sistemi (SGA) per la gestione delle PMI. Diventa referente e scrittrice per la rivista Close-up Engineering nel settembre 2014 ad oggi. Consegue la laurea in Ingegneria Gestionale Magistrale nel dicembre 2015. Pur avendo un’impronta scientifica e assorta nell’ affascinante mondo dell’ingegneria, è molto appassionata di letteratura classica. D’indole “sognatrice” nel tempo libero ama leggere e viaggiare.

LEAVE A REPLY