UML : UNIFIED MODELING LANGUAGE

management

UML : UNIFIED MODELING LANGUAGE

L'UML è un formalismo molto ricco di diagrammi che consentono di descrivere a diversi livelli i molteplici aspetti di un'applicazione; è un formalismo che si incentra sugli oggetti.  Si usano i diagrammi delle classi per descrivere

le classi di oggetti e le loro relazioni; molte nozioni utilizzate si rifanno al modello E/R ma con l'uso dei diagrammi si consente di descrivere aspetti che prima non era possibile rappresentare(dinamica e comportamento).

Elementi fondamentali sono le classi e le associazioni che corrispondono all'entità e al 737i81h le relazioni del modello E/R.

Use Case Diagrams:Esso ci aiuta ad analizzare cosa vogliamo dalle applicazioni software da costruire; è il comportamento,cosa ci consente di fare il sistema, ignorando come si fa in quanto siamo a livello concettuale.

Ogni Use-case soddisfa più requisiti fondamentali: nella realtà i requisiti non funzionali rappresentano caratteristiche del sistema, non funzioni da svolgere (i requisiti di sicurezza, cioè che un sistema funzioni bene non sono delle funzioni, ma bensì dei requisiti non funzionali!).

I casi d'uso descrivono le interazioni tra utente(attore)e sistema; esso è descritto da un nome ma è composto da una serie di attività atomiche(o viene svolta o non viene svolta)che avvengono secondo determinate regole.
L'attore è il ruolo che l'utente del caso d'uso svolge nell'interagire con il sistema(livello concettuale). Un attore sollecita il sistema con un qualche evento e ne riceve un output. Esso è esterno al sistema e può essere:

Una classe di persone fisiche (es. Fornitore),Un altro sistema software (es. Sistema di contabilità) Un dispositivo hardware esterno (es. Sensore).

Il caso d'uso Descrive il comportamento del sistema quando sollecitato da un attore Il comportamento è descritto in maniera testuale, come sequenza di transazioni del sistema(insieme atomico di attività che sono completate o non sono eseguite affatto) Un caso d'uso corrisponde ad un compito che l'attore o il sistema deve eseguire.

Diagramma dei Casi d'Uso

È Usato per modellare il contesto di un sistema, i requisiti funzionali(Ogni caso d'uso corrisponde a uno o più requisiti funzionali ed è coinvolto in una qualche relazione)ed ha Diversi livelli di dettaglio(decompos. gerarchica)

Attori(esterni al sistema), Casi d'uso(interni al sistema)Relazioni di associazione, dipendenza e generalizzazione;

Relazioni principali

Association: identifica relazioni semplici tra attori e casi d'uso

Include: fattorizza proprietà comuni. Un comportamento comune a più casi d'uso diventa un caso d'uso che è incluso nei casi d'uso di partenza; L'inclusione evita di copiare la descrizione del comportamento comune nei differenti use case che lo coinvolgono. Avviene in un punto preciso della descrizione del caso d'uso includente. Il caso incluso non ha senso da solo. utilizzare incudes quando si sta ripetendo la descrizione di un comportamento presente già in uno o più use cases.(graficamente : <<include>>)

Extend: identifica comportamenti simili (varianti). A può essere visto come una variante di B;    Comportamenti alternativi o eccezionali (opzionali) di un caso d'uso formano dei casi d'uso che estendono il caso d'uso generale:nel caso d'uso esteso viene inserito un punto d'estensione, nei sottocasi d'uso si fa riferimento a questi punti.La relazione extends va utilizzata quando abbiamo uno use case simile ad un altro che però fa qualcosa in più.utilizzare extends quando si descrive una variazione al comportamento normale;

Generalization si applica sia ad attori che ad  use case. A eredita il comportamento di B.

Per ogni use case deve essere effettuata la documentazione :

Titolo: Effettua chiamata diretta

Autori: Pluto e Topolino

Descrizione: L'utente compone il numero per effettuare una chiamata diretta

Attori: Utente

Pre-condizioni: Non identificate

Post-condizioni: Non identificate

Scenari: Uno scenario è un'istanza di uno use case; È una "esecuzione" particolare dello use case. Rappresenta il comportamento (le azioni e gli eventi) del sistema nel caso particolare considerato. Definisce cosa accade nel sistema in seguito all'evento di innesco. Ogni use case dovrebbe essere corredato da un insieme di scenari:

Scenari principali (più possibile:Tutto funziona correttamente) e Scenari secondari (pochi e significativi,Eccezioni eventuali problemi o malfunzionamenti). Si devono definire tanti scenari quanti sono quelli necessari per capire il corretto funzionamento del sistema e le eccezioni che si ritengono significative durante l'analisi