Ingegneria del Software + UML

UML: Modellazione software (software modeling): approcci e motivazioni

UMLModellazione software (software modeling): approcci e motivazioni è un approccio pratico, focalizzato sulle tecnologie e strumenti largamente accettati e utilizzati nell'industria.

Permette di costruire modelli indipendenti dal linguaggio (language-indipendent) e dà vita al paradigma dello sviluppo guidato da modelli (model-driven development).

Ha un grande impatto nella fase di analisi, design e documentazione.

Un modello software (similmente a un modello di sistema) è una semplificazione della realtà, è una descrizione accurata e possibilmente parziale di un sistema in fase di studio ad un qualche livello di astrazione.

Un modello software:

• È formato da diversi sotto modelli che descrivono una certa vista del sistema;
• Non ha bisogno di essere completo;
• È espresso in qualche linguaggio a qualche livello di astrazione;
• È più di una descrizione: è una rappresentazione analogica di quello che.

I modelli software ci aiutano a visualizzare un sistema così complesso; ci permettono di specificare sia la struttura che il comportamento del sistema. Ci forniscono un template che ci guida durante l'intera costruzione del sistema e inoltre documentano le decisioni prese dal team.

L'UML è un linguaggio di modellazione standardizzato (ISO) che ci permette di visualizzare, specificare, costruire e documentare artefatti software. UML nasce come strumento di comunicazione nelle fasi di progettazione: un fallimento di comunicazione durante il processo di sviluppo può portare a conseguenze negative. UML è indipendente dalle metodologie di sviluppo.

L'UML non è un linguaggio di programmazione: è indipendente dai dettagli di basso livello (è machine independent). UML serve come mezzo di discussione dei problemi (requisiti, analisi, design). UML fornisce diverse viste di diverso livello di dettaglio dello

stesso artefatto. Segue una lista dei principali modelli software utilizzati, in ambito del linguaggio UML

Casi d'uso

Un caso d'uso è una descrizione di una serie di sequenze di azioni (comprese le loro varianti), che un sistema esegue per produrre un risultato di valore osservabile per un attore. Un caso d'uso descrive cosa fa un sistema ma non specifica come lo fa. Un caso d'uso solitamente rappresenta un pezzo principale di funzionalità che porta valore tangibile all'utente. Un caso d'uso è la descrizione di uno scenario (o di set di scenari strettamente correlati) nel quale il sistema interagisce con l'utente. I casi d'uso sono descritti da scenari narrativi e modelli grafici.

Un attore è un agente esterno che deve/vuole interagire con il sistema e che rappresenta un specifico ruolo. Gli attori NON fanno parte del sistema.

Notazione dei casi d'uso:

• Caso d'uso: ovale
• Attore: stickman

20Andrea Mansi

UNIUD 2019-2020

Riassunto concetti chiave Ingegneria del Software (ver. 1 4/2/2020)

Un diagramma dei casi d'uso è un modo eccellente per comunicare alla gestione, ai clienti e alle altre persone che non sviluppano il software cosa farà il sistema quando sarà completato.

I diagrammi dei casi d'uso sono usati per modellare il contesto e i requisiti di un sistema. Inoltre, forniscono la prospettiva dell'utente del sistema.

Un'associazione tra caso d'uso e attore indica che l'attore e il caso d'uso comunicano l'uno con l'altro, possibilmente mandando e ricevendo messaggi.

L'associazione descrive il "canale" di interazione. È importante notare che un'associazione:

• non modella un flusso di dati;
• non indica una direzione del flusso di interazione, dunque l'associazione è raramente ornata da una freccia terminale;

L'interazione è descritta da un testo fuori dal diagramma.

diagramma.▪È possibile notare delle associazioni dall'esempio di diagramma di casi d'uso ATM sovrastante.

Relazioni tra casi d'uso

La relazione tra casi d'uso <<include>> specifica che il caso d'uso d'origine incorpora esplicitamente il comportamento del caso d'uso incluso. Si ha che: il caso d'uso d'origine specifica il punto esatto in cui il flusso è sospeso e il caso d'uso è▪ iniettato. Alla fine dell'esecuzione del caso d'uso incluso, il caso d'uso d'origine continua la sua▪ esecuzione dal punto in cui è stato sospeso. Tutte queste descrizioni sono di natura testuale e quindi posizionate al di fuori del modello▪ grafico. Un esempio è il seguente: "card identification" è incluso in "withdraw"

La relazione tra casi d'uso <<extend>> specifica che il caso d'uso di partenza estende il comportamento del

spec” è l’extension point per la relazione extend;

La relazione tra casi d’uso di generalizzazione specifica che un caso d’uso (figlio) eredita la struttura, il comportamento e le relazioni di un altro attore padre. Il figlio è il caso d’uso più specializzato, mentre il padre è quello più astratto della relazione. La notazione è una freccia completa con l’estremità chiusa dal caso figlio al caso padre.

Esempi di generalizzazione:

I confini del sistema sono usati per definire confini concettuali, aiutano a raggruppare elementi correlati logicamente e aiutano a mostrare cosa risiede dentro il sistema (le funzionalità) e cosa sta fuori (l’utente). 22 Andrea Mansi UNIUD 2019-2020

Riassunto concetti chiave Ingegneria del Software (ver. 1 4/2/2020)

Guidelines

Segue una serie di linee guida per i diagrammi dei casi d’uso:

Iniziare il nome dei casi d’uso con un verbo (affermare il valore reale

Per l'attore:

• Cercare di evitare verbi vaghi come gestire, processare ed eseguire
• Sfruttare il vocabolario del dominio
• Fare attenzione a un usare troppi livelli nidificati di casi d'uso di inclusione, questo significa focalizzarsi sui dettagli di implementazione (come) che non è lo scopo dei casi d'uso (cosa). In linea generale: max. un livello nidificato.

Diagramma delle classi

Una classe è un template per la definizione di tutte le caratteristiche di un oggetto, come attributi e metodi. Una classe definisce una serie di oggetti con la stessa struttura comune e lo stesso comportamento.

Un attributo descrive un'informazione relativa allo stato interno di un oggetto (istanza della classe). Ogni oggetto mantiene un valore per ciascun attributo per la corrispondente classe di appartenenza.

Un metodo definisce il comportamento di un oggetto per uno specifico evento. Il comportamento di un oggetto può essere indipendente dallo stato o

dipendente dallo stato. Un diagramma delle classi descrive le tipologie di oggetti presenti in un sistema e le relazioni statiche che esistono tra di loro. È una tecnica di modellazione basata sui principi dell'orientazione agli oggetti. È la più ricca notazione in UML. Segue la notazione grafica UML del diagramma delle classi:

Una classe è una descrizione di un insieme di oggetti che hanno attributi, operazioni, relazioni e comportamenti simili. Tipicamente una classe descrive un'entità del dominio del problema.

Convenzioni (linee guida) sui nomi:

• Classe: iniziale maiuscola per ogni parola
• Attributi: iniziale minuscola, maiuscola per ogni singola parola successiva
• Metodi:
  • C++: maiuscola anche la prima
  • Java: come gli attributi

Riassunto concetti chiave Ingegneria del Software (ver. 1 4/2/2020)

In un diagramma delle classi sono possibili tre prospettive:

1. concettuale
2. specifica
3. implementativa

La relazione

Contesto dell'associazione. Molteplicità: indica quanti oggetti di una classe possono fare riferimento ad ogni oggetto dell'altra. Permette di indicare se un'associazione è obbligatoria o meno, e il lower e upper bound del numero di istanze. Esempio: 24 Andrea Mansi UNIUD 2019-2020

Riassunto concetti chiave Ingegneria del Software (ver. 1 4/2/2020)

Aggregazione: è una forma speciale di associazione che modella una relazione "whole-part" tra un aggregato (whole - il tutto) e le sue parti. Modella il concetto di "è parte di" e "contiene". Esempio: car-door; house-door;

Composizione: è una forte forma di contenimento (più forte dell'aggregazione). Il "whole" è l'unico proprietario di ogni parte. Le molteplicità nel "whole" devono essere 1 o 0. Esempio:

Generalizzazione: indica