Linguaggio di modellazione

ULTERIORI ASPETTI DEI CLASS DIAGRAM: Aggregazione

Le Aggregazioni sono speciali associazioni che rappresentano una relazione 'tutto-parti'. Il lato del 'tutto' è spesso chiamato l'aggregato. Il simbolo dal lato del tutto sostituisce una associazione avente nome isPartOf.

Quando usare una aggregazione:

• Una associazione diventa una aggregazione se è possibile affermare che:
• Le parti sono "parte di" un insieme
• L'aggregato è "composto da" parti
• Quando qualcosa possiede o controlla l'aggregato, allora esso possiede o controlla anche le sue parti.

www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK Il linguaggio di modellazione ad oggetti 14

Composizione. Una composizione è una forma forte di aggregazione. Se l'aggregato viene distrutto, anche le sue parti saranno distrutte (le parti non esistono senza il tutto). Due alternative per

Rappresentare l'indirizzo (composizione uno-a-uno): Propagazione. Un meccanismo secondo cui un'operazione in un aggregato è implementata facendo svolgere all'aggregato l'operazione sulle sue parti. Analogamente, le proprietà delle parti si propagano indietro verso l'aggregato (es. Calcolo il peso totale tramite il peso delle parti). La Propagazione sta all'aggregazione come l'ereditarietà sta alla generalizzazione.

Differenza fondamentale:

• L'ereditarietà è un meccanismo implicito
• La propagazione deve essere programmata, se richiesta.

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.

http://www.quellidiinformatica.org – La

associazioni: il programmatore dovrà poi rispettare tali vincoliOCL 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, o r, =, >, < o <> (not equals)
• Stringhe di caratteri quali: 'a string'
• Interi e numeri reali
• Operatori aritmetici: *, /, +, -

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK Il linguaggio di modellazione ad oggetti 16

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK Il linguaggio di modellazione ad oggetti 17

Una raccomandazione

In relazione ai Class diagram, UML include altri aspetti di dui non ci siamo occupati.

Esempio:

• notazione per le classi parametriche (template)
• Visibilità di attributi e metodi
• Relazioni di dipendenza fra

Classi - Fare riferimento allo standard!!!

Il processo di sviluppo dei Class Diagram. Anche per lo sviluppo dei diagrammi delle classi si devono attraversare diverse fasi che costituiscono una sorta di processo di sviluppo. I diagrammi UML possono essere creati in diverse fasi del ciclo di vita, con diversi scopi e livelli di dettaglio:

1. Exploratory domain model: viene sviluppato nella fase di analisi del dominio del problema al fine di documentare ciò che si è appreso. Infatti significa modello di esplorazione del dominio del problema.
2. System domain model: descrive aspetti del dominio del problema che saranno presenti nel sistema (i dati di interesse). Significa modello di dominio del sistema.
3. System Model: include anche classi che saranno usate per costruire le interfacce utente e l'architettura del sistema.

Per quanto riguarda le differenze tra System domain model e System model si possono enumerare le seguenti: il system domain model trascura molte classi che

sono necessarie per il sistema finale. Può contenere anche meno della metà delle classi del sistema e dovrebbe essere sviluppato per essere riusato indipendentemente da user interface classes e architecture classes.

Il system model completo include il system domain model, le classi dell'interfaccia utente (ad esempio, finestre, menù, form...), classi dell'architettura del sistema (client/servers/file/database), classi di utilità.

www.quellidiinformatica.org - La community studenti di Ingegneria Informatica di Napoli

FranK Il linguaggio di modellazione ad oggetti 18

Sequenza di attività suggerite. Per sviluppare un modello per i diagrammi delle classi si suggeriscono le seguenti attività:

1. identificare un primo insieme di classi candidate;
2. aggiungere associazioni ed attributi a queste classi;
3. trovare le generalizzazioni;
4. trovare le principali responsabilità di ogni classe;
5. in base alle responsabilità

decidi sulle operazioni;

6) Itera il processo finché il modello ottenuto è soddisfacente (aggiungi o cancella classi, associazioni, attributi, generalizzazioni, responsabilità o operazioni, identifica le interfacce utente, usa i design patterns) Non essere disorganizzati, né troppo rigidi.

Vediamo adesso ogni singolo passo enunciato in precedenza nei particolari:

1) Identificare le classi: quando si sviluppa un domain model si tende a scoprire le classi. Nel lavorare all'interfaccia utente o all'architettura si tende ad inventare classi. Le classi sono necessarie per risolvere un problema di design. Inoltre, si consiglia di riusare il più possibile, usando frameworks, guardando a sistemi simili e se il sistema è una estensione del precedente usare alcune funzionalità della vecchia versione. Per scoprire le classi di dominio esiste una semplice tecnica: si analizza la documentazione di partenza, come la descrizione dei requisiti,

estrarre da questa i nomi e frasi nominali (nomi con aggettivi). Inoltre, bisogna eliminare i nomi che sono ridondanti, cioè che rappresentano la stessa classe, che rappresentano istanze e non classi, che sono vaghi o troppo generici, che corrispondono a classi che non sono necessarie al livello considerato. Fare attenzione a classi nel domain model che rappresentano tipi di utente o altri attori (domandarsi se servano davvero!).

2) Identificare associazioni e attributi: si consiglia di partire con classi ritenute centrali ed importanti e di stabilire i dati ovvi e chiari che esse contengono e le loro relazioni con altre classi. Si proceda poi con le classi meno importanti, evitando di aggiungere troppi attributi ed associazioni ad una classe, infatti un sistema è più semplice se manipola meno informazioni. Ecco una serie di suggerimenti per trovare e specificare associazioni valide: una associazione dovrebbe esistere se una classe: possiede - controlla -

è collegata a – si riferisce a – è parte di – hacome parti – è membro di – ha come membri qualche altra classe del modello.

Dopodichè occorre specificare la molteplicità da entrambi i lati e assegnare un nome chiaro all’associazione.

Un errore comune consiste nel considerare azioni come se fossero associazioni.

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli

FranK Il linguaggio di modellazione ad oggetti 19

Per identicare gli attributi occorre cercare le informazioni che devono essere conservate per ciascuna classe. Èpossibile che i nomi che sono stati scartati come classi, possano ora essere considerati attributi. Un attributodovrebbe in genere contenere un solo valore (ad esempio, stringa, numerico). Per identificare attributi validi sisuggerisce di non avere molti attributi duplicati. Se un sottoinsieme degli attributi di una classe forma un gruppocoerente,

crea una classe distinta per questi attributi.
3) Identificare generalizzazioni e interfacce: due modi per trovare le generalizzazioni, bottom-up (raggruppo
classi simili creando una nuova superclasse), top-down (si cercano prima le classi più generali e poi si
specializza). Conviene creare un'interfaccia, invece di una superclasse se: 
a) le classi sono molto diverse fra loro, tranne che hanno poche operazioni in comune, 
b) una o più classi hanno già le loro superclassi, 
c) potrebbero essere disponibili diverse implementazioni della stessa classe.
http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica di Napoli
FranK Il linguaggio di modellazione ad oggetti 20
4) Assegnare le Responsabilità alle classi: una responsabilità è un qualcosa che è richiesto al sistema. La
responsabilità di ogni requisito potrà essere svolto mediante una collaborazione fra più classi. Tutte

Le responsabilità di una classe dovrebbero essere chiaramente correlate. Se una classe ha troppe responsabilità, valutare l'ipotesi di dividerla in più classi. Se una classe non ha responsabilità, probabilmente è inutile. Quando una responsabilità non può essere attribuita a nessuna delle classi esistenti, dovrebbe essere creata una nuova classe. Per stabilire le responsabilità si deve svolgere un'analisi dei casi d'uso e cercare i verbi e i nomi che descrivono azioni nella descrizione del sistema.

Categorie di responsabilità:

• Set e get dei valori degli attributi
• Creare e inizializzare nuove istanze
• Prelevare o memorizzare dati da una memoria persistente
• Distruggere istanze
• Aggiungere e cancellare istanze di associazioni
• Copiare, convertire, trasformare, trasmettere o fornire in output dati
• Calcolare risultati numerici
• Navigare e cercare dati di particolari istanze
• Altro lavoro

http://www.quellidiinformatica.org – La community studenti di Ingegneria Informatica