Corso UML

Definizione di UML

Cos'è UML ?

UML ( Unified Modeling Language) è un linguaggio standard di modellazione per Specificare Visualizzare Costruire Documentare

domini applicativi eterogenei, adatto maggiormente a progettare sistemi object-oriented e sistemi component-based.

UML è un linguaggio...

UML è un linguaggio pertanto costituito da sintassi e semantica sintassi: regole attraverso le quali gli elementi del

linguaggio (parole) sono assemblate in espressioni (frasi). semantica: regole attraverso le quali alle espressioni

sintattiche viene assegnato un significato.

UML non è una metodologia!

La metodologia serve per specificare: quale linguaggio di modellazione utilizzare per

descrivere il lavoro progettuale quali sono i passi necessari per raggiungere la

“industrializzazione” nella produzione del software.

UML non è un processo!

Il processo è un insieme di regole che definiscono come un progetto di sviluppo dovrebbe essere condotto. Include una descrizione e sequenzializzazione di attività,

documenti e modelli. Definisce i criteri per il monitoraggio delle attività e la

valutazione degli artefatti.

…standard…

Per standard si intende: un paradigma codificato per la produzione di tecnologie fra

loro compatibili e interoperabili riferiti ad hardware, software o infrastrutture di rete.

…di modellazione…

Modellare significa descrivere un sistema in termini di: entità coinvolte relazioni esistenti tra di loro

Esempio: Diagrammi di flusso UML Diagrammi Entita-Relazione

La qualità di un modello

Accuratezza: deve descrivere il sistema correttamente, completamente e

senza ambiguità;

Consistenza: le diverse viste devono completarsi vicendevolmente per

formare un insieme coerente

Semplicità: deve poter essere compreso, senza troppi problemi, da

persone estranee al processo di modellazione;

Manutenibilità: la variazione dello stesso deve essere la più semplice

possibile.

… per specificare, visualizzare, costruire e documentare ...

Specificare Dettagli di implementazione

Visualizzare Un immagine è meglio di 100 parole

Costruire Idee, pensieri

Documentare Interazione con gruppi esterni

...domini applicativi eterogenei...

Dominio eterogenei sanità, finanza, TLC, aerospazio indipendentemente dalla piattaforma

Sistema: una singola organizzazione vista nella sua globalità (es.

azienda) una parte di un’organizzazione (es. divisione, oppure

processo) un insieme di organizzazioni, o di parti di organizzazioni, in

relazione tra loro (es. processi di interazione Business-to-Business)

...e sistemi component-based.

I quattro “dogmi” della modularizzazione sono: Alta coesione (omogeneità interna) Information hiding (poco rumore nella comunicazione) Basso accoppiamento (indipendenza da altri moduli) Interfacciamento esplicito (chiare modalità d’uso)

...e sistemi component-based…

Il PC che stiamo utilizzando ne è un esempio... Componenti riutilizzabili Dividere la logica dall'interfaccia Utilizzare uno standard di comunicazione

...adatto maggiormente a progettare sistemi object-oriented.

I concetti OO si sono sviluppati dal 1970 attraverso diversi linguaggi di programmazione c++, smalltalk, java, eiffel.

Vediamo meglio cosa si intende per Object Oriented …

Come usare UML

Approccio ad UML

Steve Mellon e Martin Flower prevedono tre modi diversi di utilizzo: Abbozzo (sketch) Progetto (blueprint) Linguaggio di programmazione

Approccio ad UML

UML come abbozzo (sketch) Documentazione, discussione e condivisione delle idee Basso rigore formale Selettività: focalizzazione solo su alcuni aspetti dell’applicazione Bassa, se non nulla dipendenza dal tool di modellazione

Approccio ad UML

UML come progetto (blueprint) Alto rigore formale Completezza Forward e reverse engineering Forte dipendenza dal tool di modellazione

Approccio ad UML

UML come linguaggio di programmazione Utilizzare diagrammi per generare codice Fortissima dipendenza dal tool di modellazione

Storia di UML

Come si arriva allo standard ?

UML è definito: sotto l'egida dell'OMG (Object Management Group) a partire dal contributo dei “Tre Amigos” (Grady Booch, Jim

Rumbaugh e Ivar Jacobson) ed il supporto delle più importanti società di software

mondiali

Cos'è OMG ?

OMG (Object Management Group) è un consorzio creato nel 1989 partecipano: 440 aziende (Microsoft, Digital, HP, NCR, SUN, OSF)

Obiettivo: creare un sistema di gestione di un'architettura distribuita basati sul paradigma ad oggetti.

Standard più importanti proposti: architettura CORBA linguaggio di modellazione UML standard XMI

“Method wars”

Negli anni ’80 si alternano vari linguaggi grafici di modellazione: SADT (Structured Analysis and Development Technique) DFD (Data Flow Diagram) IDEF0 (Integration Definition for Function Modeling)

“Tre Amigos”

Grady Booch: Object Oriented Design – OOD Jim Rumbaugh: Object Modeling Technique - OMT Ivar Jacobson: Object-Oriented Software

Engineering - OOSE

La guerra è finita

Booch e Rumbaugh lavoravano alla Rational e nel 1994 Unified Object Notation v0.8

Jacobson capo di Objectory che nel 1995 fu acquistata dalla Rational e nel 1995 Unified Modeling Language v0.9

Booch e Rumbaugh e Jacobson crearono consorzio “UML Partners” e redassero UML v1.0

Microsoft, HP, Oracle, Rational ed altri crearono consorzio “OMG”

Le versioni di UML

novembre 1997 versione v1.1 dicembre 1998: versione 1.2 Marzo 2000: versione 1.3 settembre 2001: versione 1.4 marzo 2003: versione 1.5 luglio 2005 : versione 2.0 agosto 2006: versione 2.1 settembre 2008: versione 2.2 Beta

Le versioni di UML

Diagrammi UML

Diagrammi UML

Classica suddivisione dei diagrammi UML Strutturali: come è composto il sistema Comportamentali: come interagisce sistema▪ Interattivi: che tipo di messaggi si scambia il sistema

Diagrammi UML

UML 1.x Class diagram Object diagram Deployment diagram Component diagram Package diagram Activity diagram Use case diagram Sequence diagram

Communication diagram State Chart diagram

UML 2.xn Class diagramn Object diagramn Deployment diagramn Component diagramn Package diagramn Activity diagramn Use case diagramn Sequence diagram

n Collaboration diagramn State Machine diagram

n Interaction Overview diagram

n Composite Structuren Timing diagram

Class Diagram

Consentono di descrivere tipi di entità, con le loro caratteristiche e le eventuali relazioni fra questi tipi.

Concetti di: classe, associazione, dipendenze, generalizzazione.

Object Diagram

Consentono di descrivere un sistema in termini di oggetti e relative relazioni.

Concetti di: oggetto, relazione.

Deployment Diagram

Consentono di descrivere un sistema in termini di risorse hardware detti nodi, e di relazioni fra di esse.

Spesso si combina con le componenti software per mostrare dove sono distribuite (Component Diagram).

Concetti di: nodo, connessione.

Component Diagram

Consentono di descrivere l'organizzazione e le dipendenze tra componenti software.

Concetti di: componente, interfaccia.

Package Diagram

Consentono di mostrare l'organizzazione dei packages e dei loro elementi.

Concetti di: package, merge, import, nested.

Sequence Diagram

Consentono di mostrare il comportamento dinamico di un gruppo di oggetti che interagiscono.

Concetti di: oggetti, messaggi, lifetime, attivazione

Activity Diagram

Consentono di rappresentare la logica interna di un processo.

Concetti di: attività, flusso, responsabilità.

Use Case Diagram

Consentono la descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso.

Concetti di: sistema, attore, caso, associazioni.

Communication Diagram

Consentono la descrizione dell'interazione fra più oggetti ed i messaggi scambiati, focalizzandosi sugli oggetti e non sul tempo.

Concetti di: oggetti, messaggi.

State Machine Diagram

Consentono la descrizione del comportamento di entità o di classi in termini di stato.

Concetti di: stato, transizione.

Interaction Overview Diagram

Fornisce una visione complessiva delle interazioni che cooperano in un flusso molto simile a quella di un diagramma di attività

Concetti di: oggetto, relazione.

Timing Diagram

Mostra le interazione tra gli oggetti ed il loro cambiamento di stato in un dato periodo di tempo.

Concetti di: oggetto, relazione, tempo.

Composite-structure Diagram

Mostra i sottosistemi che compongono il sistema Concetti di: parte, connettore, porte.

UML 2.0

UML 2 è distribuito dall' OMG in 4 specifiche:Diagram Interchange Specification▪ layout dello schema con strumenti diversi (xmi)

UML Infrastructure▪ definisce il core dell'uml, cioè il meta modello utilizzato

UML Superstructure▪ definizione formale degli elementi uml, utilizzata dai tool

dei vendor e definisce in dettaglio i diagrammi utilizzati

Object Constraint Language (OCL)▪ definisce le regole e le logiche da utilizzare. Ha una

sintassi e delle parole chiavi.

UML 2.0

Si basa su una struttura composta da 4 livelli di meta modelli:

Meta-Metamodel E’ il padre di tutti gli elementi Viene usato per formalizzare la notazione e

definire le specifiche di linguaggio per il metamodel

Metamodel Ogni oggetto del metamodel è una istanza dei

concetti del meta-metamodel Qui si descrivono astrazioni di modelli object-

oriented e component-oriented Si definiscono linguaggi per definire domini e

modelli

UML 2.0

Si basa su una struttura composta da 4 livelli di meta modelli:

Model Qui si definiscono i domini, i problemi e le

soluzioni di sistemi User object E’ composto da elementi che semplificano i

modelli UML Qui si descrivono le specifiche informazioni del

dominio

Model Driven Engenering a 4 livelli

Computer Aided Software Engineering ( CASE )

Tool di modellazione Supporto alla creazione dei diagrammi e validazione Ricerca tra i mille modelli creati

Generazione del codice Supporto a diversi linguaggi di programmazione, DDL, DML

Reverse engineering Supporto all'analisi partendo dal codice

UML 1.x – 2.x Supporto alle versioni

UML CASE Tools

Rose; Rational Modeller ed Architect (IBM - Rational)

Together (Borland) Visio (Microsoft) TAU (Telelogic) Objecteering (Softeam) Poseidon (Gentleware) Enterprise Architect (Sparx

Systems) Magic Draw (No Magic) ArgoUML (open source) StarUML (open source) UModel 2005 (Altova) TAU Developer and TAU Architect

(Telelogic)§ Jude (open-source)§ InnovatorAOX 2006 Object

eXcellence (MID)

§ Real-time Studio(ARTiSAN)§ OMONDO EclipseUML Studio

(open source)§ PathMATE (Pathfinder Solutions)§ Metis with UML 2.0 Template

(Computas)§ Describe (Embarcadero)§ I-Logix Rhapsody§ MetaMatrix MetaBase Modeller

(Tibco)§ Java Studio Enterprise (Sun

Microsystems)§ Model-in-Action (Mia Software)§ Pattern Weaver Ver. 2.0§ EDGE UML Suite (Mentor

Graphics)

Use Case

Dove si colloca

Cosa sono

Esistono diversi modi di “guardare” un sistema Interno▪ Punto di vista del progettista, interessato agli aspetti

architetturali Esterno▪ Visto come una “black box”, di cui si può osservare solo il

comportamento dall’esterno Il punto di vista esterno è il punto di vista dell’utilizzatore e di

tutto ciò che interagisce con il sistema per assicurarne il corretto funzionamento.

Esempio

Un videoregistratore Vista del progettista (interno)▪ All’interno vi sono dei componenti▪ Ogni componente svolge funzioni particolari▪ Ogni componente deve essere utilizzato correttamente e

rispettare dei requisiti Vista dell’utente (esterno)▪ Nel manuale c’è la descrizione di come può essere utilizzato▪ Come si inserisce una cassetta▪ Come si effettua il fermo immagine▪ Ecc...ecc..

Use Case Diagram: cosa sono?

Rappresentano le modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori)

Descrivono l’interazione tra attori e sistema, senza rivelare l’organizzazione interna del sistema

Sono espressi anche in forma testuale, comprensibile anche per i non “addetti ai lavori”

Possono essere definiti a livelli diversi (sistema o parti del sistema)

A cosa servono?

Svolgono un duplice ruolo nello sviluppo del sistema Nelle fasi iniziali della progettazione Chiariscono cosa dovrà fare il sistema Stabiliscono una base comune per la discussione con il committente Fine - individuare ed analizzare i requisisti del sistema

A regime Guidano l’intero processo di sviluppo Rappresentano il punto di partenza per la progettazione del sistema

▪ Definizione dell’architettura▪ Creazione dei modelli di analisi e disegno▪ Realizzazione del codice applicativo

Costituiscono il riferimento primario per dei test per la verifica di quanto prodotto▪ la definizione▪ la progettazione▪ l’esecuzione

Da cosa sono composti?

Il Modello dei Casi d’Uso rappresenta le funzionalità che il sistema offre ai suoi utilizzatori

E’ costituito dalla documentazione e dai diagrammi La Documentazione▪ Descrive, in modo testuale, il Caso d’Uso▪ Costituisce l’elemento centrale di comunicazione tra tutte le

parti in causa▪ Committente, Management, Gruppo di progetto

▪ Guida la progettazione e la definizione dei Casi di Test I Diagrammi▪ Ruolo complementare ma secondario▪ Forniscono una “mappa visuale” estremamente sintetica,

delle modalità di uso del sistema

Casi d’uso

Casi d’uso Sono le funzionalità che il sistema mette a disposizione dei suoi

utilizzatori Descrivono il sistema da un punto di vista esterno (black box) Sono rappresentati con un’icona a forma di ellisse

Attori

Attori Sono i soggetti (esterni) che interagiscono con il sistema tramite

messaggi Ogni attore corrisponde ad un insieme coerente di ruoli che i soggetti

possono assumere interagendo con il sistema Possono rappresentare

▪ Esseri umani▪ Sistemi hardware o software▪ Organizzazioni

Sistema

Sistema Contiene un insieme di casi d’uso riguardanti un particolare sistema Descrive in modo completo gli utilizzi del sistema dall’esterno Non rileva la struttura interna del sistema Gli attori sono esterni al sistema

Associazione

Attori e casi d’uso Ha il significato di comunicazione Ogni caso d’uso è collegato agli attori (uno o più) Per evidenziare la direzione della comunicazione l’associazione

può essere orientata

Associazione

Attore primario È quello per il quale è stato pensato il caso d’uso Ha un interesse primario per la funzionalità che quel caso d’uso

esprime Attore secondario E’ un sistema esterno che interagisce con il sistema di

riferimento nell’ambito del caso d’uso Ogni caso d’uso ha per definizione almeno un attore primario Il ruolo “primario” o “secondario” non è assoluto Un attore primario per un caso d’uso può essere secondario in

un altro E viceversa

Associazione

Associazioni tra Attori L’unica associazione ammessa tra attori è la specializzazione L’attore specializzato eredita la partecipazione a tutti i casi d’uso con i

quali comunica l’attore generico L’attore specializzato può partecipare ad ulteriori casi d’uso ai quali

l’attore generico non è collegato

Associazione

Tra Casi d’Uso Non è ammessa in UML una associazione di comunicazione tra i

casi d’uso (un caso d’uso descrive un utilizzo completo del sistema)

Non è ammessa la suddivisione di una funzionalità completa in casi d’uso distinti

Associazione

L’UML ammette, tra casi d’uso, tre tipi di relazioneSpecializzazioneEstensioneInclusione

Specializzazione

Ogni caso d’uso specializzato eredita le caratteristiche del padre Il caso d’uso specializzato può aggiungere nuovi passi o ridefinire

i passi ereditati da quello generale Ogni caso d’uso generale può avere più figli Ogni caso d’uso specializzato può avere più padri

Inclusione

Casi d’uso diversi possono avere in comune una sequenza di passi da svolgere

La sequenza comune può essere esportata e definita come un caso d’uso a se stante

Il caso d’uso che si ripete verrà poi incluso in altri casi d’uso In questo modo si evidenziano le parti in comune L’inclusione viene utilizzata tramite la parola chiave

<<include>>

Estensione

Permette di definire che un caso d’uso “base” può venire “esteso” con il comportamento definito da un altro caso d’uso

L’estensione riguarda un comportamento opzionale del caso d’uso base (l’estensione è soggetta ad una condizione di attivazione)

La direzione dell’associazione di estensione va dal caso d’uso “di estensione” al caso d’uso “base”

L’estensione viene utilizzata tramite la parola chiave <<extend>>

Pertanto La relazione“extend” tra un Use Case A ed un Use Case B indica che ogni istanza di un Use Case B, in condizioni particolari, viene estesa con le funzionalità di una istanza di Use Case A.

Sommario

Esempio

Scenari

In UML, ogni specifica esecuzione (istanza) di un caso d’uso è detta scenario Esempio – in un caso d’uso “Acquistare un prodotto”, ogni

acquisto effettuato da uno specifico cliente in uno specifico momento costituisce uno scenario particolare

Ci sono due diverse tipologie di scenario Scenari di successo (nell’esempio – l’acquisto va a buon fine) Scenari di fallimento (nell’esempio – l’acquisto non va a buon

fine)

Scenari

Ogni scenario può essere descritto da una sequenza di passi che specificano l’interazione tra il sistema gli attori coinvolti nello scenario

La prassi più diffusa per la specifica degli scenari consiste in: definire uno scenario base, cioè lo scenario che porta al

successo dei casi d’uso definire gli scenari alternativi, cioè gli scenari che possono

verificarsi per effetto delle varianti che possono condurre ad un nuovo scenario

Ciascuno scenario costituisce una diramazione che può portare al successo o al fallimento del caso d’uso

Identificare i casi d'uso

L’identificazione dei casi d’uso può avvenire Per un sistema già esistente dallo studio del manuale d’utente se disponibile da suo utilizzo tramite una serie di interviste agli utilizzatori

Per un sistema nuovo o per un sistema in evoluzione dai requisiti già rilevati dal committente dai documenti iniziali disponili per il progetto

Identificare i casi d'uso

Identificare tutte le tipologie di utilizzatori del sistema in termini di individui od atri sistemi.

Per ogni attore primario, rilevare in quale modo può/deve utilizzare il sistema, partendo dagli obiettivi che deve raggiungere. Ad ogni modalità di utilizzo corrisponde, almeno inizialmente, un caso

d’uso Per ogni caso d’uso, descrivere lo scenario base

▪ la sequenza di passi più semplice possibile che conduce al successo del caso d’uso

▪ le risposte attese dal sistema le principali varianti a tale scenario

▪ Così facendo, possono emergere necessità di interazione del sistema con altri soggetti (individui o sistemi) che verranno rappresentati come attori secondari

Realizzare i casi d'uso

La realizzazione di un caso d’uso è influenzata da due fattori la tipologia del sistema di cui descrivere l’utilizzo l’approccio utilizzato per la progettazione

Se il sistema cui ci si riferisce è un sistema software, la realizzazione dei casi d’uso dipende dall’approccio utilizzato per la progettazione Object-oriented - La realizzazione comporta

▪ l’individuazione: delle classi che vi parteciperanno, delle rispettive responsabilità

▪ nonché la definizione delle modalità di interazione tra gli oggetti delle classi coinvolte

Strutturato-funzionale - Si devono definire▪ le procedure e le transazioni coinvolte▪ la struttura gerarchica dei moduli software

La realizzazione dei casi d’uso rientra tra le attività delle fasi di analisi e design

Realizzare i casi d'uso

In UML la realizzazione dei casi d’uso può essere espressa mediante una “collaborazione”

La collaborazione è costituita da una serie di oggetti che interagiscono tra di loro cioè effettuano delle azioni e si scambiano messaggi per richiedere servizi corrispondenti alle rispettive responsabilità

La collaborazione che realizza uno scenario può essere descritta A livello statico, mediante un diagramma delle classi che

evidenzi le classi o gli oggetti coinvolti nella collaborazione e le rispettive associazioni e legami

A livello dinamico, mediante uno dei diagrammi d’interazione (es. diagramma di sequenza) che evidenzi i messaggi che gli oggetti si scambiano nell’ambito della collaborazione

Class e Object Diagram

Dove si colloca

Class Diagram

E’ il modello più importante in UML perché definisce gli elementi base del sistema

Rappresenta il sistema attraverso una visione statica

Rappresenta le classi che compongono il sistema ed i relativi attributi e comportamenti

Specifica, mediante le associazioni, i vincoli che legano tra loro le classi

Classi

La classe modella un insieme di oggetti omogenei (le istanze della classe) ai quali sono associate proprietà statiche e dinamiche

Ogni classe è descritta da: Nome della classe (l’identificatore) Attributi (lo stato) Operazioni (il comportamento)

Oggetti

Gli attributi di una classe determinano gli attributi delle sue istanze (oggetti)

Regole importanti Se una classe C ha un attributo A di tipo T, ogni oggetto

che è istanza di C ha l’attributo A, con un valore associato di tipo T

Un oggetto X non può avere un valore per un attributo che non è definito nella classe di cui X è istanza

Rapporto Classi – Oggetti

La relazione tra un oggetto, che è istanza di una classe C, e la classe C si rappresenta mediante un arco Instance-of

L’arco in realtà non è strettamente necessario, poiché la classe, di cui l’oggetto è istanza, è già indicata nell’oggetto.

Importanza dell'identificativo

Due oggetti con identificativi distinti sono comunque distinti, anche se hanno i valori di tutti gli attributi uguali

Due oggetti diversi devono avere identificativi diversi, anche se possono avere gli stessi valori per tutti gli attributi

Attributi di Classe

Un attributo modella una proprietà della classe valida per tutte le istanze

Formalmente, un attributo A della classe C può considerarsi una funzione che associa un valore di tipo T ad ogni oggetto che è istanza della classe C

Attributi di Oggetto

Un oggetto in UML modella un elemento del dominio di analisi che ha vita propria è identificato univocamente mediante l’identificativo di oggetto è istanza di una classe (la classe più specifica)

DivComm è l'identificativo dell'oggetto Libro è la classe di cui l'oggetto è istanza Notare la sottolineatura

Operazione di Classe

In realtà, le classi (e quindi le loro istanze) sono caratterizzate anche da proprietà dinamiche, che in UML si chiamano operazioni. Un’operazione associata ad una classe C indica che sugli oggetti della classe C si può eseguire una computazione (detta anche metodo ), per calcolare una proprietà, per effettuare cambiamenti di stato

In una classe, un’operazione sidefinisce specificando iparametri e il tipodel risultato (se c’è).

Operazione di Classe

In una classe, un’operazione si definisce specificando i parametri e il tipo del risultato (se c’è).

Non è necessario che un’operazione restituisca un valore o un oggetto. Un’operazione può anche effettuare solamente azioni senza calcolare un risultato.

Classe - Visibilità

Ogni attributo e metodo può avere varie caratteristiche (+) Pubblico: visibile da tutte le classi (#) Protetto: visibile dalle classi dello stesso package o dalle

sottoclassi (~) Package: visibile solo dalle classi dello stesso package (-) Privato: visibile da nessuno

Classe Astratta

E’ una classe che non ha una concreta implementazione ma ha solo la dichiarazione delle operazioni

Non può essere istanziata, ma può avere costruttori. Può contenere sia dei metodi astratti (statici e di

istanza) sia dei metodi concreti Se un metodo è definito astratto, anche la classe deve

essere astratta, Se nessun metodo è astratto la classe può comunque

essere astratta.

Classe Astratta

Il nome della classe astratta è in corsivo E’ possibile inserire il costruttore (non astratto) I metodi statici sono sottolineati Il metodi astratti sono in corsivo E’ possibile indicare metodi “concreti”

Classe Astratta

Le classi astratte consentono di usare il meccanismo di "fattorizzazione" delle informazioni comuni, anche quando la superclasse risultante non sarebbe "ben definita".

Facciamo un esempio: Supponiamo di avere le classi “Sfera” e “Cubo” in cui

troviamo delle ridondanze di dati, quindi possiamo definire una classe “Solido” che fattorizzi le informazioni comuni.

Ma purtroppo non c'è un modo per calcolare la superficie di un solido generico!

Come possiamo implementarlo? Definire “volume()” come metodo astratto, avente solo

l'intestazione ma non l'implementazione, di conseguenza “Solido” è una classe astratta.

Classe Astratta

public class Sfera { double raggio; double pesoSpecifico; public Sfera(double raggio, double ps) { this.raggio = raggio; pesoSpecifico = ps; } public double volume() { return 4/3 * Math.PI * Math.pow(raggio,3); } public double peso() { return pesoSpecifico * volume(); }}

public class Cubo { double lato; double pesoSpecifico; public Cubo(double lato, double ps) { this.lato = lato; pesoSpecifico = ps; } public double volume() { return Math.pow(lato,3); } public double peso() { return pesoSpecifico * volume(); }}

Classe Astratta

Classe Astratta

public class Sfera { double raggio; public Sfera(double raggio, double ps) { this.raggio = raggio; pesoSpecifico = ps; } public double volume() { return 4/3 * Math.PI * Math.pow(raggio,3); }}public class Cubo { double lato; public Cubo(double lato, double ps) { this.lato = lato; pesoSpecifico = ps; } public double volume() { return Math.pow(lato,3); }}public abstract class Solido { double pesoSpecifico; public abstract double volume(); // metodo astratto public double peso (){ return volume() * pesoSpecifico; }}

Classe Astratta

Classe Astratta

Cosa succede invece in questo caso?

abstract class ClassAbstract { public ClassAbstract(){ System.out.println("ClassAbstract"); };}class Classe extends ClassAbstract { public Classe(){ System.out.println("Classe"); };}

class MiaAvvio { public static void main(String[] args) {

ClassAbstract ca = new Classe(); }}

Classe Astratta

Ed in questo caso?

abstract class ClassAbstract {public void metodo(){

System.out.println("metodo ClassAbstract "); };}class Classe extends ClassAbstract {

public void metodo(){System.out.println("metodo Classe");

};}


ClassAbstract ca = new Classe();ca.metodo();

}}

Classe Astratta

Ed in questo caso?

abstract class ClassAbstract {public void metodo(){

System.out.println("metodo ClassAbstract "); };}class Classe extends ClassAbstract {

public void metodo(){super.metodo();System.out.println("metodo Classe");

};}



}}

Classe Astratta

Ed in questo caso?

abstract class ClassAbstract {public abstract void metodo()

}class Classe extends ClassAbstract {

public void metodo(){System.out.println("metodo Classe");

};}



}}

Interfaccia

Una interfaccia “interface” ha una struttura simile a una classe, ma può contenere SOLO: costanti metodi d'istanza astratti metodi e proprietà “public”

quindi non può contenere: né costruttori né variabili statiche né variabili di istanza né metodi statici metodi e proprietà diversi da “pubblic”

Interfaccia

Se scriviamo una interaccia in questo modo:interface MiaInterf { int i=0;

String metodo();}

Il compilatore “aggiungerà” questi modificatori

interface MiaInterf { public static final int i=0; public abstract String metodo();}

Interfaccia

La classe provvede una particolare implementazione ma le altre classi potranno interagire con essa usando una interfaccia

Si aumenta notevolmente l’indipendenza tra le classi

Interfaccia

Possiamo rappresentare lo scenario di un’interfaccia in 3 modi diversi: Uguale alla classe ma con indicato lo

stereotipo <<interface>> Con una icona a forma di pallina

(lollipop -> “leccalecca”) puntata da una freccia tratteggiata (dipendenza)

Con una icona a forma di pallina agganciata da una icona a forma di semicerchio (socket -> “presa”) introdotta con UML 2

Interfaccia

Ed ecco come possiamo rappresentare il codice nel linguaggio Java:

public class Ordine { private List list = new ArrayList();}

public interface List {}

public class ArrayList implements List {}

Interfaccia

Le interfaccia permettono di emulare l’ereditarietà multipla, ma senza i problemi ad essa collegati

Come le classi, le interfacce possono usare l’ereditarietà con altre interfacce

Le interfacce specificano un protocollo che deve essere implementato dalle sottoclassi

Interfaccia

E’ sempre possibile estendere anche una classe in modo da ereditare i metodi e le proprietà in essa contenuta.

public class Figlio extends TerzoPadre implements PrimoPadre, SecondoPadre {

public void metodoPrimo() {}

public void metodoSecondo() {}

}

Interfaccia

Possiamo avere una ereditarietà a diamante ( o rombo ) come nel caso seguente:

public class VeicoloAcquatico implements Veicolo {

public void metodoTerzo() {} public void metodoSecondo() {}}public class VeicoloAnfibio extends

VeicoloAcquatico implements VeicoloTerrestre {

public void metodoPrimo() {} public void metodoSecondo() {}}

public interface VeicoloTerrestre extends Veicolo {

public abstract void metodoPrimo();}public interface Veicolo { public abstract void metodoSecondo();}

Interfaccia

Inoltre sarà sempre possibile che più classi ereditino da una stessa interfaccia come in figura sottostante.

Interfaccia

Una interfaccia può estendere una o più interfacce (non classi), indicate dopo la parola chiave extends. Per le interfacce non vale la restrizione di "ereditarietà singola" che vale per le classi.

public interface PrimoFiglio extends PrimoPadre, SecondoPadre {public void metodo3();

}

Packages

I package sono contenitori di classi Aiutano a modellare sistemi complessi Possono esistere package e sottopackage Si tende ad inserire nel package classi che hanno un

comportamento e scopo comune nel sistema E’ possibile definire relazioni tra package

Relazioni tra Classi

Quando si costituiscono i diagrammi delle classi, accade molto raramente che le entità coinvolte siano destinate a rimanere isolate

Tipicamente, tutte le classi identificate sono connesse con altre secondo precisi criteri Non è sufficiente identificare le classi che compongono il sistema, Ma è necessario individuare anche le eventuali relazioni che le

legano

Nel mondo Object Oriented, tutte le relazioni possono essere facilmente ricondotte ai tre tipi fondamentali Dipendenza Generalizzazione Associazione

Relazioni tra Classi

1-Relazione di dipendenza

Indica che la variazione dello stato di un’istanza della classe indipendente implica un cambiamento di stato nell’istanza della classe dipendente

Es. precedente La dipendenza lega le classi “Window” alla classe ”Event” Indica che un cambiamento di stato dell’oggetto “Event”

genera un aggiornamento dell’oggetto “Window” che lo utilizza

Non è vero l’inverso


È una connessione semantica tra due oggetti di un modello, di cui uno è l’elemento indipendente mentre l’altro è quello dipendente

Indica che un cambiamento dello stato dell’elemento indipendente genera degli effetti su quello dipendente


Ad esempio quando una classe prevede come parametro un oggetto di un’altra classe accede ad un suo oggetti invoca un suo metodo.

In tutti i casi esiste una evidente dipendenza tra le classi sebbene non ci sia un’esplicita associazione

Graficamente Linea tratteggiata con freccia rivolta verso la classe

dipendente


Nell’esempio la classe FilmClip e la classe Channel sono legate da una relazione di dipendenzaSi nota come il metodo PlayOn necessita come

parametro di un oggetto di tipo ChannelCiò evidenzia una dipendenza tra le classi

sebbene non esista un legame di associazione Può essere associato un nome per individuare e

distinguere le relazioni


La tipologia della relazione di dipendenza più frequente:Quando il riferimento ad un oggetto di una specifica

classe venga fornito come parametro ad un metodo di un altro oggetto istanza di una classe diversa

In casi di questo tipo, se i metodi delle classi vengono forniti con la signature completa, è possibile evitare la visualizzazione grafica della relazione

2-Relazione di generalizzazione

Indica un legame tra una classe generale, denominata super-class o parent, ed una sua versione più specifica, denominata sub-class o childclass

Una classe figlio specializza il comportamento di quella del padre

Es. precedente La generalizzazione lega le classi “Window” alla classe

”DialogBox” La classe “DialogBox” va ad aggiungere un comportamento

specifico alla classe padre “Window”


Lega un oggetto (detto super-class o parent) ad uno più specifico (detto sub-class o child-class) appartenente alla stessa tipologia

È spesso indicata con la denominazione Is-kind-of (è di tipo), per specificare che un oggetto specializzato e “del tipo” dell’oggetto più generale

È possibile asserire che le classi

Rectangle, Circle e Polygon sono

del tipo della classe Shape La classe Square, applicando un

ragionamento ricorsivo, è anch’essa di

tipo Shape otre ad essere di tipo Rectangle


La proprietà peculiare di tale relazione prevede che un qualsiasi oggetto, istanza di una classe specializzata, può essere sempre utilizzato ovunque compaia la classe “base” Un oggetto della classe Rectangle può essere sempre

sostituito ad un oggetto Shape (non vale il contrario) Un oggetto della classe Square può sempre sostituire sia da

un’istanza della classe Rectangle sia da una classe Shape Comprensibile se si considera che una classe figlio eredita

proprietà e metodi della classe padre Anche nel caso limite in cui la classe specializzata non

dovesse aggiungere ulteriore comportamento, conserverebbe comunque, quello della classe padre


Principio di sostituzione di Liskov Se per ogni oggetto O1 di tipo S c’è un

oggetto O2 di tipo T tale che per tutti i programmi P definiti in termini di T, il comportamento di P non cambia quando O1 è sostituito da O2 allora S è un sottotipo di T

In modo meno formale: Si può sempre passare un puntatore o un

riferimento di una classe derivata ad una funzione che si aspetta un puntatore o un riferimento alla classe base.


Quando un metodo di una classe figlio possiede la stessa “signature” (nome, parametri formali e parametri di ritorno) di una classe padre, si dice che ne effettua la sovra-scrittura (override)

Ciò implica che ogni riferimento a tale metodo, eseguito in un oggetto della classe figlio, farà riferimento al metodo ridefinito anziché a quello della classe padre Nel caso della classe padre, è sufficiente

premettere un puntatore a tale classe Graficamente Linea piena con freccia vuota nella

direzione della classe padre


In una generalizzazione la sottoclasse non solo può avere proprietà aggiuntive rispetto alla superclasse, ma può anche specializzare le proprietà ereditate dalla superclasse.

Specializzazione di un attributo: Se una classe C1 ha un attributo A di tipoT1, e se C2 è una sottoclasse di C1, specializzare A in C2 significa definire A anche in C2 ed assegnargli un tipo T2 i cui valori sono un sotto insieme dei valori di T.


Anche le operazioni si possono specializzare nelle sottoclassi.

Specializzazione di una operazione: un’operazione si specializza specializzando i parametri e/o il tipo di ritorno.


Specializzazione di una associazione: Se una classe C1 partecipa ad una associazione R1 con un’altra classe C3, e se C2 è una sottoclasse di C1, specializzare R1 in C2 significa: Definire una nuova associazione R2 tra la classe C2 e la

classeC3 (o una classe C4 che è sottoclasse di C3) Stabilire una dipendenza di tipo {subset} da R2 a R1


Il grafo delle generalizzazioni non può contenere cicli!

class C extends D{}

class A extends C{}class B extends C{}

class D extends B{}

Java Output: cyclic inheritance involving C


La generalizzazione consente di poter implementare il polimorfismo consentendo di istanziare la classe figlia avendo come riferimento l’oggetto padre.


Durante il processo di analisi Incontrare entità aventi un comportamento o una struttura simile

Come agire Modellare le varie entità attraverso classi distinte senza alcun

legame Estrapolare dalle entità il comportamento e la struttura comune, al

fine di realizzare una classe più generale dalla quale far derivare tutte le altre

Può capitare di dover schematizzare determinate relazioni tra classi per mezzo di una relazione di ereditarietà multipla nel caso in cui una classe figlio erediti da più classi padre bisogna utilizzare tali relazioni con molta cautela


Alcuni linguaggi Object-Oriented, come ad esempio Java, non la prevedono si può facilmente incorrere in errori qualora la classe figlio voglia

ridefinire (override) la struttura e/o il comportamento di una delle classi padre

Le relazioni multiple vanno opportunatamente ponderate


È frequente il caso in cui è consigliabile sostituirla con uno schema denominato “Delegazione”

Prevede di rimpiazzare una ereditarietà “n-aria”, con una singola relazione di generalizzazione “n-1” aggregazioni (un particolare tipo di relazione di

associazione)


Anche con le ereditarietà singole si possono avere dei problemi

Un dipendente (Istanza della classe Equipaggio o Personale di terra) può essere un passeggero

Presenza di entità che potrebbero essere istanza di più classi


Bisognerebbe aggiungere ulteriori classi Combinazioni per inserire le possibili casistiche

Utilizzare una serie di relazioni di associazione


La stessa superclasse può partecipare a diverse generalizzazioni.

Concettualmente, non c’è alcuna correlazione tra due generalizzazioni diverse, perché rispondono a due criteri diversi di strutturare la superclasse.


complete - Tutte le sottoclassi sono state specificate, nessun altra sottoclasse è permessa


incomplete - NON tutte le sottoclassi sono state specificate, altre sottoclassi sono permesse.


overlapping – E’ possibile definire una classe che sia sottoclasse di due classi non disgiunte: Studente e Lavoratore cioè StudenteLavoratore


disjoint – NON è possibile definire una classe che sia sottoclasse di più uno stato di esecuzione.

Pertanto due classi disgiunte non possono avere sotto classi comuni.

3-Relazione di associazione

Indica il significato per cui un oggetto di una classe è connesso ad un altro oggetto

È una relazione strutturata tra classi che definisce un canale di comunicazione bi-direzionale fra le classi Tra due classi è associazione binaria Tra n classi è associazione “n-aria”

Una associazione può avere un nome


Può avere una direzione per distinguere meglio il verso della comunicazione

È anche possibile assegnare due nomi con i relativi versi alla stessa associazione

Osserviamo ancora che le frecce che simboleggiano il verso non aggiungono nulla al significato della associazione (che è sempre una relazione), ma aiutano ad interpretare il senso dei nomi scelti per l’associazione

Le frecce che simboleggiano il verso si indicano anche nel link che sono istanze delle associazioni


È riflessiva se coinvolge oggetti della stessa classe Indica oggetti multipli della stessa classe che sono in

relazione fra loro in cui l’oggetto è istanza della stessa classe (self-association)


Istanza di associazione Se “autore” è una associazione tra le classi “Libro” e

“Persona”, una istanza di “autore” è un link tra due oggetti, uno della classe Libro e l’altro della classe Persona


Istanza di associazione Come gli oggetti sono istanze delle classi, così i link

sono istanze delle associazioni (gli archi Instance-of non sono necessari).

Al contrario degli oggetti, però, i link non hanno identificatori espliciti: un link è implicitamente identificato dalla coppia (o in generale dalla ennupla ) di oggetti che esso rappresenta.


Associazione n-aria Una associazione può essere definita su tre o più

classi. In tale caso l’associazione si dice n-aria


Istanze di associazioni n-arie: link n-ari Ogni istanza di una associazione n-aria è un link n-

ario, cioè che coinvolge n oggetti


Associazioni n-arie con attributi Ovviamente, anche le associazioni n-arie possono

avere attributi


Link n-ari con attributi I link che sono istanze di associazioni n-arie con

attributi, hanno un valore per ogni attributo.


Ruolo Denota lo scopo o la capacità con la quale una classe si

associa con un altra Può sostituire il nome dell’associazione Definisce un nome specifico per ogni ruolo che ha

l’associazione con la classe Consente di poter ottenere maggiore chiarezza e leggibilità


Ruolo Analogamente al verso, il ruolo è generalmente opzionale, e non

aggiunge nulla al significato dell’associazione L’unico caso in cui il ruolo è obbligatorio è quello in cui

l’associazione insiste più volte sulla stessa classe. Se non fossero indicati i ruoli nell’associazione“genitore-figlio”,

non sapremmo interpretare correttamente i link che sono istanze dell’associazione


Associazione con Molteplicità Definisce :se la relazione è obbligatoria o noil numero minimo e massimo di oggetti che

prendono parte alla relazione


Associazione con Molteplicità


Associazione con molteplicità


Molteplicità di attributi Si possono specificare anche le molteplicità degli

attributi. Se le molteplicità di un attributo B di tipo T di una

classe C non vengono indicate, vuol dire che B associa ad ogni istanza di C esattamente un valore di T

Al contrario, se un attributo B di tipo T di una classe C ha molteplicità x .. y, allora B associa ad ogni istanza di C al minimo x e al massimo y valori di tipo T


Associazione disordinata Supponiamo di voler descrivere gruppi di persone … Un gruppo è formato da persone. Ogni persona può

apparire in un gruppo al più una volta (ovviamente ciascuna persona può fare parte di 0, 1, molti gruppi) e non ha importanza indicare l’ordine di appartenenza

In UML possiamo rappresentare questo scenario come segue:


Associazione ordinata Consideriamo ora invece una graduatoria di persone … Una graduatoria ha un certo numero di posizioni ciascuna

occupato da una sola persona (non consideriamo pari merito in questo esempio)e una persona può apparire un una graduatoria al più una volta.

•Una possibile rappresentazione in UML è:


Classi di associazioni Definiscono delle proprietà che appartengono alla

associazione e non alle classi coinvolte

Per esempio: Se la relazione tra Studente e Corso è “molti a molti”, come

possiamo fare per registrare i voti di tutti i corsi che uno studente ha seguito?


Poiché: L’attributo del voto non può essere messo nella classe Corso Perché esistono molti link alla classe Studente in quanto lo stesso corso

è seguito da molti studenti L’attributo del voto non può essere messo nella classe Studente Perché esistono molti link alla classe Corso in quanto uno studente

segue dei corsi differenti

Allora: L’attributo appartiene all’associazione che lega lo Studente ed il Corso

3-Relazione di aggregazione

Le aggregazioni sono una forma particolare di associazione Definisce una associazione del tipo “parte di” Relazioni tra classi in cui: una rappresenta un oggetto (Whole) e l’altra una

sua componente (Part) È detta anche Whole-Part

E’ una associazione asimmetrica Graficamente Linea piena con rompo rivolto verso la classe più generale

3-Relazione di aggregazione

Esempio Aggregazione: facoltà universitaria

3-Relazione di composizione

E’ una forma di aggregazione di tipo forte La loro esistenza ha senso solo in relazione al contenitore Creazione e distruzione avvengono nel contenitore I componenti non sono parti di altri oggetti Se si cancella il contenitore si cancellano anche le parti Le parti componenti non esistono senza il contenitore

Stereotipi

Uno stereotipo è un nuovo tipo di elemento di modellazione che estende la semantica del meta modello

In UML gli stereotipi si mostrano aggiungendo il suo nome nel compartimento della classe racchiuso tra << >>

Ci sono degli stereotipi tipicamente utilizzati, quali:

Class Boundary, Control ed Entity

Classi Boundary

Una classe Boundary modella la comunicazione tra l’ambiente ed il sistema ed i suoi meccanismi interni

Riguardano la trasformazione degli eventi che accadono all’esterno e la notifica di cambiamento dello stato “presentation”

Dipendono dall’ambiente che circonda il sistema Aiutano a comprendere i confini del sistema Tipiche classi Boundary: Finestre (interfacce utenti) Interfacce verso stampanti Sensori

Classi Boundary

Un sistema può avere diversi tipi di classi boundary User Boundary: classi che mediano la comunicazione con

utenti umani del sistema System Boundary: classi che mediano la comunicazione con

altri sistemi Device Boundary: classi che forniscono una interfaccia verso

dispositivi come i sensori, che intercettano eventi esterni

Class Control

Una classe Control modella il comportamento di controllo Crea, inizializza e cancella gli oggetti controllati Controlla le sequenze o coordina l’esecuzione degli oggetti

controllati Rappresentano la dinamica del sistema mostrando come

sono controllati i flussi di eventi Effettuano anche la delega di compiti ai diversi oggetti a

cui sono assegnate responsabilità per le singole funzionalità

Classe Entity

Una classe Entity modella informazioni generalmente di tipo persistente ed il comportamento associato

I valori dei suoi attributi sono in genere forniti da un attore Il comportamento è indipendente dal contesto (attori) Sono usate per rappresentare i concetti chiavi che sono

gestiti dal sistema La loro principale responsabilità è quella di memorizzare e

gestire le informazioni necessarie al sistema

Esempio

Tracciare il diagramma delle classi corrispondenti alle seguenti specifiche:

Si vogliono modellare gli studenti (con nome, cognome, numero di matricola, età), il corso di laurea in cui sono iscritti, ed i corsi di cui hanno sostenuto l’esame, con il professore che ha verbalizzato l’esame, ed il voto conseguito. Di ogni corso di laurea interessa il codice e il nome. Di ogni corso interessa il nome e la disciplina a cui appartiene (ad esempio: matematica, fisica, informatica, ecc.). Di ogni professore interessa codice e d’età.

Esempio

Commenti in UML

In UML, quando si vuole specificare una caratteristica che non è possibile rappresentare esplicitamente nel diagramma con i meccanismi visti finora, si può usare la nozione di commento.

Sequence Diagram

Dove si colloca

Sequence Diagram

Il Sequence Diagram descrive il comportamento dinamico di un gruppo di oggetti che interagiscono

Il Sequence Diagram illustra le interazioni degli oggetti ordinate in modo cronologico

Sono usati per “formalizzare” gli scenari, in termini di: Entità (oggetti) Messaggi scambiati (metodi)

Evidenzia la sequenza temporale delle azioni in base ad una dimensione: il TEMPO

Sequence Diagram

Le interazioni tra gli oggetti avvengono in una sequenza specifica

La sequenza consuma del tempo per andare dall'inizio alla fine

Un Sequence Diagram contiene: Oggetti▪ Graficamente – rettangoli con il nome sottolineato

Messaggi▪ Graficamente – tramite frecce a linea continua

Tempo▪ Graficamente – rappresentato progressivamente nell'asse

verticale

Sequence Diagram - Elementi

OggettiRappresenta una singola entità In un ambiente object–oriented rappresenta un'istanzaPuò rappresentare una particolare istanza di un oggetto o

di un attore


MessaggioRappresenta la comunicazione tra due oggettiVa dalla lifeline di un oggetto alla lifeline di un altro

oggettoTipi di messaggi▪ Semplice – trasferimento di controllo da un oggetto ad un

altro▪ Sincrona – chi invia il messaggio deve attendere la risposta▪ Asincrona – chi invia il messaggio non deve attendere la

risposta

I messaggi vengono spesso numerati per meglio mostrare la sequenza temporale delle azioni


Messaggio In UML 1.x i messaggi sincrono ed asincroni erano visualizzati con una

freccia con punta aperta completa o parziale, In UML 2.x per evitare facili confusioni si è preferito visualizzarli con

una freccia chiusa piena ed una aperta completa mantenendo sempre la linea continua

SincronaAsincrona

Il messaggio può essere inviato anche a se stesso in modo ricorsivo

UML 2.xUML 1.x


Messaggio RicorsivoIndica un messaggio inviate a se stessoE' utile quando si vogliono rappresentare

comportamenti ricorsivi


Messaggio di ritornoIndica uno stimolo di ritorno dopo l'invio di un

messaggioNon rappresenta un nuovo messaggioSi commette l'errore di utilizzarlo ogni volta che si

invia un nuovo messaggioDeve essere utilizzato solamente per aggiungere

informazioni e per aumentare la comprensione del sistema


AttivazioneRappresenta il tempo durante il quale un

oggetto esegue un'operazione

Sequence Diagram -Elementi

Creazione e distruzione La X indica quando una particolare istanza cessa di

esistereUn oggetto può morire da solo o grazie all'invio di un

messaggio da parte di un altro oggettoE' utile quando sto rappresentano contesti multithread


Esecuzione concorrenteIndica quando alcune condizioni possono generare

cammini diversi

Combined Fragment (CF)

Questo concetto permette di suddividere un Sequence Diagram in piu’ “frammenti” e di combinare tali frammenti, seguendo diverse regole

Alcuni operatori (gli “InteractionOperator”) definiscono come tali frammenti possono essere combinati insieme

Interaction Operators

Transition Time

Viene utilizzato per esprimere vincoli temporali sul tempo di esecuzione dei messaggi

Espresso tramite constraints In genere si trovano alla sinistra dei messaggi

Sequence Diagram - Relazioni

Ad un lifeline, può essere associato uno “stato” Lo stato viene valutato:Se e’ verificato, allora possiamo continuare ad

eseguire il SDaltrimenti, il SD non può essere verificato.


Macchina seft-service, la cui interfaccia è sostituita da 3 oggetti: Pannello frontale: per il cliente Registro del denaro: raccoglie le monete Dispencer : dove viene erogato il prodotto al cliente

Funzionamento tipico della macchina: Il cliente inserisce le monete nello slot Il cliente fa la selezione Le monete arrivano al registro Il sistema controlla se il prodotto selezionato è nel dispenser Il registro incrementa la sua riserva di cash Il registro rilascia il prodotto nel dispenser


L'istanza del Sequence Diagram può essere schematizzata utilizzando queste sequenze:

Dove si colloca


E' simile al Sequence Diagram:Sono semanticamente equivalenti in quanto

mostrano stesso tipo di informazioniEvidenziano le interazioni tra le partiRivolgono maggiore attenzione allo scambio dei

messaggi Ma è diverso dal Sequence Diagram :Organizzato in funzione dello spazio e non del

tempoNon vi è una particolare dimensione per

rappresentare il tempo a parte la numerazione.Sono più evidenti i legami tra gli oggetti rispetto

alla sequenza dei messaggi


Graficamente rappresentato come un grafo dove i nodi sono gli oggetti e gli archi sono i links

E’ una estensioni del diagramma degli oggetti e mostra: Gli oggetti:Rappresentano una singola entità del diagramma In un ambiente object-oriented rappresenta una

istanzaPuò rappresentare una particolare istanza di un

oggetto o di un attore I Link: Label: mostra il messaggio Frecce: puntano all'oggetto ricevente ed eseguono una

delle operazioni dell'oggetto riceventePossono contenere i parametri dell’operazione

chiamata

Communication Diagram - Relazioni

LinkRappresenta la relazione tra gli oggetti in un particolare

istante di tempoE' una particolare istanza delle associazioni del Class

Diagram

Link a se stesso:Rappresenta una particolare istanza di associazioni Inizia e finisce nello stesso oggettoRappresenta una interazione con se stesso

Communication Diagram - Relazioni

MessaggioRappresenta la comunicazione tra due oggetti La comunicazione può essere:▪ Sincrona▪ Asincrona

I messaggi vengono numerati per mostrare la sequenza temporale delle azioni

I messaggi si applicano ai link tra i diversi oggetti

Communication / Sequence Diagram

Esprimono informazioni simili ma le evidenziano in modo differente

Spesso non è necessario descrivere il sistema utilizzando entrambi i diagrammi

Era possibile in UML 1.x passare da un Sequence Diagram ad un Collaboration Diagram e viceversa.

Un Communication Diagram, in UML 2.0, NON e’ più totalmente equivalente ad un Sequence Diagram.

I Combined Fragment ora presenti nei SD, per esempio, NON sono rappresentati nei Communication Diagram

Communication / Sequence Diagram

Dove si colloca


Statechart diagrams sono diagrammi usati per rappresentare il comportamento di una classe (o di un intero sistema) descrivendone i possibili stati raggiunti durante il ciclo di vita della classe, e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte.


Mostrano una macchina a stati enfatizzando il flusso di controllo da stato a stato

Specificano le sequenze di stati che ha un oggetto durante il suo ciclo di vita in risposta ad eventi.

Sono utili per mostrare il comportamento dinamico di oggetti particolarmente complessi

Graficamente è un grafo con vertici ed archi Rappresenta il comportamento dei singoli oggetti di

una classe in termini di:Eventi a cui gli oggetti sono sensibiliAzioni prodotteTransazioni di stato


Gli Statechart Diagrams sono particolarmente adatti per rappresentare il comportamento di reactive objects, siano essi istanze di classe, use cases e interi sistemi.

Gli Interaction Diagrams sono usati per modellare il comportamento di diversi oggetti che cooperano mentre gli Statechart Diagrams vanno usati per modellare il comportamento di un singolo oggetto all’interno del suo ciclo di vita..

Gli Activity Diagrams modellano il flusso di controllo da un’attività ad un’altra attività mentre gli Statechart Diagrams sono usati per modellare il flusso di controllo da evento a evento.


Utile in circostanze dove si ha la necessità di studiare un sistema che:Possiede un numero finito di configurazioniI transiti da una configurazione ad un altra sono in

funzione di uno stimolo esterno Descrivono il ciclo di vita degli oggetti di una classe,

attraverso modifiche causate da eventi che li interessano

E’ composto da: Stato Attività/Azioni Eventi Transizioni


StatoA run-time tutti gli oggetti possiedono uno stato Lo stato di un oggetto è una condizione o situazione che

si verifica durante il ciclo di vita dell'oggetto stessoRappresenta la situazione nel tempo di un oggetto che

esegue una attività o aspetta qualche stimolo esternoE' il risultato di tutte le attività eseguite fino a quel dato

istante dall'oggetto Lo stato è costituito dai valori associati ai relativi attributi

e dai legami con altri oggettiUno stato perdura nel tempo finché un evento non fa

cambiare stato all’oggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo)

Lo stato influenza il comportamento, l'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova.


Lo stato può essere distinti in 3 tipi:Semplice▪ Uno stato che non contiene altri stati

Composite▪ Uno stato che contiene altri stati

Submachine▪ Uno stato che usa altri stati.


Stato iniziale - Stato finaleRappresentano i punti iniziali e finaliNon rappresentano stati veri e propri perché non

hanno tutte le caratteristiche degli altri stati – pseudo stati


Stato intermedioRappresentato con un rettangolo con gli angoli smussatiE’ composto da 2 compartimenti:▪ Nome▪ Una stringa testuale che distingue uno stato da un

altro; se non ha nome è considerato anonimo▪ Transizioni interne▪ Contiene una lista di attività o azioni interne che sono

eseguite mentre l’elemento è all’interno dello stato. Quindi tali attività o azioni non comportano il cambiamento di stato


▪ Transizioni interne (Sintassi: [label] ‘/’ action-expression )label▪ Identificano le circostanze sotto la quale l’azione

specificata da action-expression viene invocata▪ Alcune label sono riservate:▪ Entry/Action: eseguita nel momento in cui si

entra in uno stato▪ Exit/Action: eseguita nel momento in cui si esce

da uno stato▪ Do/Activities: identifica un’attività in esecuzione

mentre l’oggetto è nello stato della transizione▪ Include/nomeSubMachine : invocazione a una

sub-machine. L’azione contiene il nome della sub-machine invocata.


▪ Transizioni interne (Sintassi: [label] ‘/’ action-expression )action-expression▪ Rappresentano operazioni interne eseguite mentre

l’oggetto è in uno stato che possono richiedere tempo e sono interrompibili

▪ Action:▪ sono delle attività che vengono subito eseguite▪ comportano un cambiamento di stato dell’oggetto▪ non possono essere interrotte altrimenti

produrrebbero uno stato inconsistente▪ Activity:▪ sono dellea attività che vengono eseguite dopo che

sono state eseguite altre attivita (entry, exit)▪ non comportano un cambiamento di stato

dell’oggetto▪ possono essere interrotte in quanto non producono

uno stato inconsistente


PseudoStati Sono degli stati di astrazione che permettono di definire uno

stato caratterizzato da determinate comportamento: I tipi di pseudoStati sono i seguenti:▪ initial:▪ deepHistory▪ shallowHistory▪ join▪ fork▪ junction▪ choice▪ entryPoint▪ exitPoint▪ terminate


Fork

Join

junction


Stati compostiUno stato che ha sotto-stati viene detto stato

compostoPuò essere decomposto in▪ Sottostati sequenziali▪ Due o più sottostati concorrenti (dette regioni)

Ogni sottostato può essere a sua volta uno stato composto


Stato composto concorrenteE' utile quando un oggetto ha diversi ed

indipendenti comportamentaliNon bisogna esagerare con gli stati concorrentiSe sono presenti numerosi stati concorrenti è utile

dividere l'oggetto in parti più sempliciIn breve è una decomposizione AND


Stato composto concorrenteSe un sottostato concorrente raggiunge lo stato

finale prima dell’altro, il controllo in questo sottostato aspetta nello stato finale

Quando entrambe le macchine a stato raggiungono il loro stato finale, il controllo dei due sottostati concorrenti si ricongiungono in un unico flusso


TransizioneRappresenta la relazione tra due differenti stati di un

oggetto Indica cha un oggetto che si trova nel primo stato (stato

sorgente) eseguirà determinate azioni ed entrerà nel secondo stato (stato destinazione) quando avverrà un particolare evento e certe condizioni sono soddisfatte.

Ogni transizione potrà avere una etichettaNon avviene spontaneamente, ma al verificarsi di un

opportuno evento


La transizione è rappresentata mediante una freccia diretta continua dallo stato sorgente a quello destinatario con associata un’etichetta

La Transizione è costituita da 5 parti: Stato Sorgente: lo stato su cui la transizione agisce Evento: lo stimolo esterno la cui ricezione da parte

dell’oggetto nello stato sorgente rende la transizione candidata a scattare, in base alla condizione.

Condizione: una espressione booleana che viene valutata quando l’evento arriva. Se la condizione è verificata la transizione scatta

Azione: è atomica e non interrompibile. L’azione può essere costituita dall’invio di un evento ad un altro oggetto.

Stato destinazione: lo stato che sarà attivo dopo il completamento della transizione


event-signature: EventoVerificarsi di un qualcosa degno di nota che può

innescare una transizione di stato Possono verificarsi 4 tipi di eventi: Change event: L’evento si verifica quando il valore di una

determinata condizione cambia da false a true (esempio “when (date = Jan. 1, 2004)” )

Time event: Il passare un determinato periodo di tempo (esempio “after (10 seconds)”)

Segnale: invio di un evento in modo asincrono Calls: ricezione di una chiamata di un’operazione (chiamata

sincrona)


[guard-condition]: Condizione di guardiaEspressione booleana che viene valutata alla

ricezione dell’evento.Se è true la transizione viene attivata altrimenti non

avviene la transizione di stato e l’evento viene perso


action-expression : AzioneComputazione eseguibile atomica che può agire

sull’oggetto della macchina a stati oppure su altri oggetti inviando segnali o eventi


Macro statoUn macro stato aiuta a comprendere meglio azioni

comuni di tutti i sotto statiSepara le transizioni comuni a più oggetti

Activity Diagram

Dove si colloca

Activity Diagram

Rappresenta sistemi di Workflow o la logica interna di un processo

Può essere usato in livelli di astrazione molto differenti

E’ un caso particolare di Statechart DiagramDifferenze▪ Supportano la descrizione di flussi paralleli▪ Transizione avviene in automatico quando

l’attività è stata completamente eseguita▪ Non si necessita di specificare un evento esplicito

che generi la transizione▪ Abbiamo le condizioni che selezionano la

direzione da utilizzare per l’avanzamento del flusso di controllo

Activity Diagram

Si focalizza sulla sequenze di attività corredate dai relativi risultati prodotti

Necessarie per realizzare le funzionalità del sistema Semplice formalismo Permette di rappresentare processi paralleli e la loro

sincronizzazione E’ molto utile quando è importante definire il

comportamento dinamico degli oggetti

Activity Diagram - Elementi

Stato Iniziale - Stato FinaleCome nel Statechart Diagram rappresentano i

punti iniziali e finali di uno statechart


Action StateUn action state è uno stato con una entry action ed

almeno una transizione uscente in corrispondenza del suo completamento.

Action state non ha transizioni interne, o esterne basate su eventi.

La transizione di uscita non avviene in corrispondenza di un particolare evento.

E’ uno stato in cui è in corso una specifica azioneEsempio:▪ Digitare un tasto▪ Eseguire una routine▪ O un metodo di una classe


Flow TransitionE’ mostrata come una linea continua che va da un

action state sorgente ad un action state di destinazione.

Rappresenta le relazioni tra differenti action statePuò avere una label contenente condizioni booleane

o descrizioni


SwimlanesUna swimlane è una regione che indica l’elemento

responsabile degli action states dentro tale regione.Indica chi sta eseguendo quella attivitàRappresenta attraverso zone verticali la

responsabilità di una particolare classe o di un particolare sottosistema


Branchrappresenta la selezione di una fra più transizioni

sulla base di una condizione di controlloHa un solo punto di ingresso e molti di outputSolo un cammino di uscita può essere presoPuò essere usato come un “if then else”


Fork e JoinRappresentano l’evoluzione

parallela del sistemaAd una fork l’esecuzione

prosegue parallelamente su due o più flussi figli

Ad una join I flussi figli si ricongiungono al flusso padre

L’esecuzione del flusso padre riprende solo quando l’ultimo dei flussi figli ha terminato

Fork ha un solo ingresso e più uscite

Join più ingressi ed una sola uscita


Expansion RegionsUtilizzate quando l’output di una action è causa

di più esecuzioni di un’altra.Una expansion region è un’area dell’activity

diagram costituita da actions ripetute per ogni elemento di una certa collezione.


Flow FinalUn flow final indica la fine di un particolare flusso,

senza che sia stata terminata tutta l’activity


Flussi degli oggetti Le linee tratteggiate mostrano l’utilizzo di specifici

oggetti nelle activity. La linea che parte da una action indica l’oggetto in

essa utilizzato. La linea che parte da un oggetto e va verso un’azione

indica che quell’oggetto è ricevuto in input dalla activity.

Component Diagram

Dove si colloca

Component Diagram

Rappresentano l’architettura SW del sistema, ovvero la suddivisione di esso in varie componenti (classi, librerie, DB, eseguibili, etc.) e le dipendenze tra questi

Mostra l’organizzazione e le dipendenze dei vari componenti del sistema

Può rappresentare unità fisiche, codici sorgenti, librerie, file, etc.

Component Diagram

Componente i componenti sono moduli software (eseguibili o meno),

dotati di identità e con un'interfaccia ben specificata Non esiste un metodo unico per l’individuazione dei

componenti (Alhir li definisce “una parte del sistema che esiste durante l’esecuzione del sistema”)

Spesso un componente rappresenta una classe o un package del class diagram

Component Diagram

Abbiamo tre tipi di componentiDeployment Component : costituiscono la base dei

sistemi eseguibili (DLL, eseguibili, controlli ActiveX, Java Beans)

Work Product Component : sono ricavati i componenti del tipo precedente (file di dati e file sorgenti)

Execution Component : creati come risultato di un sistema running

Component Diagram - Elementi

InterfacciaRappresenta l’interfaccia di un componenteUn componente può avere più interfacce


DipendenzaTra due componenti esiste una dipendenza quando

modificando la definizione di uno (il supplier) può doversi modificare la definizione dell’altro (detto client)

Tra classi esistono diversi motivi che causano dipendenza comunicazione tra due classiuna classe memorizza i dati di un’altra classeUna classe adopera i dati di un’altra come parametriMostra come il cambiamento di un componente causa il

cambiamento di altriE’ utile per mostrare quali sono i componenti che

comunicano con un altro


DipendenzaUML consente di esprimere dipendenze tra tutti i

suoi elementi, e in particolare nel component diagram

Una dipendenza viene rappresentata con una freccia tratteggiata (punta sul supplier), sulla quale è possibile indicare il tipo di dipendenza

Attenzione: la presenza di numerose dipendenze (soprattutto in grossi sistemi) puo’ complicare notevolmente la gestione delle modifiche

Deployment Diagram

Dove si colloca

Deployment Diagram

Rappresenta la relazione fisica tra i componenti software e quelli hardware

E’ utile quando si ha la necessità di mostrare componenti e oggetti in un sistema distribuito

E’ utile quando si ha la necessità di mostrare in quale componente hardware di un sistema distribuito viene eseguito o risiede ciascun componente software

Deployment Diagram - Elementi

NodoOgni nodo rappresenta una unità

computazionaleMolte volte viene usato per

rappresentare un componente hardware

Esempio:▪ Un semplice device▪ Un sensore▪ Un server▪ Un mainframe

Un nodo può anche essere esso stesso del SW, un ambiente di esecuzione, ad esempio macchine virtuali


Istanza di Nodo: In generale il nodo non rappresenta una

specifica risorsa, ma una classe di risorse dello stesso tipo

Per rappresentare una specifica risorsa del sistema si usano le istanze di nodo

In un contesto object-oriented e’ analogo all’istanza di una classe

Una istanza di nodo e’ rappresentata come un nodo, ma il nome e’ del tipo nome:classe

Sia nome che classe possono essere omessi (e in tal caso si può omettere anche il “:”)


ConnectionRappresenta il percorso di comunicazione tra più nodiPuò rappresentare il protocollo di comunicazione

utilizzatoè rappresentata come una linea continua tra i due nodi


All’interno dei nodi è possibile rappresentare gli artifact, che sono la manifestazione fisica del SW

Tipicamente gli artifact sono file, e possono essere: eseguibili (file .exe, .dll, script, file

binari, ecc.) Dati file di configurazione pagine HTML


Se un artifact è posto all’interno di un nodo il file sarà memorizzato proprio in tale nodo durante il funzionamento del sistema

Un artifact può essere indicato elencandoli all’interno del nodo come class box all’interno del nodo, indicando però l’icona documento o la parola <<artifact>>

È possibile etichettare sia i nodi che gli artifact per specificare svariate informazioni (produttore, SO)

Deployment / Component Diagram

Spesso è utile integrare i due diagrammi L’integrazione rappresenta la distribuzione dei vari

componenti nei nodi del sistema

Corso UML

Technology

Transcript of Corso UML