Vai alla Home Page About me Courseware Federica Living Library Federica Federica Podstudio Virtual Campus 3D Le Miniguide all'orientamento Gli eBook di Federica La Corte in Rete
 
 
Il Corso Le lezioni del Corso La Cattedra
 
Materiali di approfondimento Risorse Web Il Podcast di questa lezione

Porfirio Tramontana » 7.Class diagram – parte seconda


Generalizzazioni

I concetti di generalizzazione e specializzazione UML sono del tutto analoghi a quelli object oriented.
Un discriminatore potrà essere implementato come un attributo con valori diversi nelle due sottoclassi.

La linea tratteggiata indica che la generalizzazione è incompleta.

La linea tratteggiata indica che la generalizzazione è incompleta.


Interpretazione della generalizzazione

A livello concettuale, una gerarchia di generalizzazione esprime una relazione Is-a tra un concetto generale e le sue specializzazioni.
A livello di progetto di dettaglio, invece, può essere interpretato:

  • Come una relazione di ereditarietà tra due classi concrete
    • Le classi derivate (figlie) ereditano attributi e metodi public e protected dalla classe padre;
  • Come una relazione di implementazione (o realizzazione) tra una classe concreta ed una classe astratta
    • La classe padre ha soltanto prototipi di metodi; la classe figlia implementa i metodi sfruttando l’overriding.

Esempio


Interfaccia

Un’interfaccia descrive una porzione del comportamento visibile di un insieme di oggetti.

  • Un’interfaccia è simile ad una classe, tranne che essa non possiede variabili d’istanza nè metodi implementati.
  • Una o più classi possono fornire l’implementazione dell’interfaccia.

Interfaccia (segue)

In generale non c’è un simbolo apposito per l’interfaccia ma si utilizza lo stereotipo <<interface>> a volte abbreviato in una I maiuscola prima del nome della classe (sconsigliato).
L’interfaccia è molto utilizzata, specie in linguaggi come Java, per separare l’implementazione di una o più classi (raggruppate in un package) da quella che è la loro interfaccia vera e propria.
L’interfaccia rappresenta anche un metodo per alterare le regole di visibilità dei metodi.

Una stessa classe o un package di classi possono “mostrare” diverse interfacce con diversi sottoinsiemi di classi e metodi resi accessibili in maniera pubblica.

Il concetto di interfaccia UML coincide con quelli realizzati in Java e CORBA, mentre rappresenta solo un modo possibile di utilizzare le classi abstract in C++.

Notazione “Lollipop”

Una notazione molto utilizzata per le interfacce è quella a “Lollipop”:

  • La pallina (lollipop) rappresenta l’interfaccia esposta da una classe (quindi è una realization);
  • Il semicerchio (socket) rappresenta il servizio richiesto (quindi è una dependency).

Esempio:

  • un motore di ricerca fornisce la possibilità di accedere al proprio servizio Cerca tramite un’interfaccia;
  • La classe visualizzatore richiama la ricerca.

Responsabilità

Nei diagrammi che descrivono il dominio del problema non si inseriscono di solito metodi perchè essi rappresenterebbero un elemento del dominio della soluzione.
In alternativa si possono utilizzare le Responsabilità.

Una responsabilità è un insieme di servizi e compiti che la classe dovrebbe garantire.
Sono utili per controllare la completezza del modello di dominio.


Note e testo descrittivo

Si possono aggiungere ulteriori informazioni direttamente in linguaggio naturale ad un qualsiasi diagramma UML utilizzando le annotazioni.

Note:

  • Una nota è un pezzo di testo incluso in un diagramma UML;
  • È come un commento in un linguaggio di programmazione.

Object Constraint Language (OCL)

OCL è un linguaggio di specifica progettato per specificare vincoli nei moduli software.

Una espressione OCL specifica un vincolo (predicato logico) sul sistema che deve assumere valore vero;
La valutazione di un’espressione OCL non può avere effetti collaterali;
Gli statements OCL nei class diagrams possono specificare quali devono essere i valori di attributi e associazioni: il programmatore dovrà poi rispettare tali vincoli.

OCL statements

Gli statements OCL possono essere costruiti usando:

  • Riferimenti a nomi di ruolo, nomi di associazioni, attributi ed I risultati di operazioni
  • I valori logici true e false
  • Operatori logici come and, or, =, >, < o <> (not equals)
  • Stringhe di caratteri quali: 'a string'
  • Interi e numeri reali
  • Operatori aritmetici: *, /, +, -

Esempio OCL

Vincolo OCL: ogni utente può rispondere una sola volta ad ogni sondaggio.

Vincolo OCL: ogni utente può rispondere una sola volta ad ogni sondaggio.


Dependency

Una Dependency rappresenta una relazione tra le istanze di due classi, che viene a realizzarsi a tempo di esecuzione.

Esempi: c’é dependency dalla classe A verso la classe B se:

  • Metodi della classe A vanno a leggere/scrivere/modificare il valore di attributi di oggetti della classe B;
  • Metodi della classe A invocano metodi della classe B;
    • caso particolare: la classe A istanzia oggetti della classe B (ovvero ne invoca il costruttore).

La Dependency si rappresenta con una linea tratteggiata che termina con una freccia dall’oggetto dipendente verso quello da cui dipende.

Dependency (segue)

Le relazioni di dependency sono individuate principalmente durante la fase di progetto di dettaglio: esse raramente contribuiscono al modello concettuale.

Esprimono una dipendenza (accoppiamento) tra le classi, nel senso che la classe origine della dipendenza non potrà essere riusata senza la classe destinazione della dependency. Una modifica nella classe da cui c’è dipendenza implicherà modifiche anche nella classe dipendente.

Analogamente, la correttezza della classe da cui parte una relazione di dipendenza è condizionata alla verifica della correttezza della classe dipendente.

Tipi di Dipendenze in UML 2.0

Per distinguere diverse tipologie di dipendenze, UML mette a disposizione gli stereotipi, che possono essere indicati con keywords scritti tra parentesi angolari doppie.

Alcuni esempi di stereotipi:
<<call>> Chiamata di metodo
<<create>> Creazione di un’istanza di oggetto
<<use>> Utilizza un attributo

I materiali di supporto della lezione

Ian Sommerville, Ingegneria del Software, capitolo 8, 14.

Martin Fowler, UML Distilled, capitolo 3, 5 (class diagram).

  • Contenuti protetti da Creative Commons
  • Feed RSS
  • Condividi su FriendFeed
  • Condividi su Facebook
  • Segnala su Twitter
  • Condividi su LinkedIn
Progetto "Campus Virtuale" dell'Università degli Studi di Napoli Federico II, realizzato con il cofinanziamento dell'Unione europea. Asse V - Società dell'informazione - Obiettivo Operativo 5.1 e-Government ed e-Inclusion