Linguaggio di modellazione

FranK Il linguaggio di modellazione ad oggetti 1

Appunti tratti da “DA C++ A UML”, Fadini-Savy

Il linguaggio di modellazione a oggetti UML

L’analisi e il progetto agli oggetti rappresentano un modo di affrontare i

problemi attraverso la cui organizzazione è basata il più possibile su concetti

del mondo reale. Il concetto fondamentale è quello di oggetto, che raccoglie in

una sola entità la struttura dei dati e il suo comportamento. I concetti basi di

una simili analisi sono l’identificazione dei singoli oggetti, la loro

organizzazione in classi, l’ereditarietà, il polimorfismo. L’essenza finale

dello sviluppo orientato agli oggetti è l’identificazione e l’organizzazione dei

concetti del dominio dell’applicazione, piuttosto che la loro rappresentazione

finale in un linguaggio di programmazione. Lo sviluppo dei sistemi orientati

agli oggetti avviene attraverso le seguenti fasi:

- analisi dei requisiti e definizione delle specifiche (analisi orientata

agli oggetti, OOA);

- progettazione a oggetti (OOD, design orientato agli oggetti);

- programmazione a oggetti (OOP, programmazione orientata agli oggetti).

Un oggetto incapsula contemporaneamente un’informazione e un comportamento

tipici del dominio applicativo. Esso possiede un’informazione e un

comportamento.

La classificazione permette di mettere insieme oggetti con una propria

individualità, ma con caratteristiche comuni. Queste caratteristiche vengono

catturate tramite il concetto di classe. La classe, dunque, è un meccanismo di

astrazione che permette di raggruppare entità in un’unica metafora concettuale.

Il linguaggio UML (Unified Modeling Language) nasce per soddisfare il bisogno di

un linguaggio di modellazione che sia facile e capace di affrontare le

problematiche di progetto di sistemi software complessi. Lo sviluppo di UML

comincia nel 1994 quando Booch e Rumbaugh della Rational Software Corporation

inziano il lavoro di unificazione dei rispettivi metodi. Successivamente

Jacobson si aggrega a questo processo di unificazione integrando anche il suo

OOSE (Object Oriented Software Enginnering).

UML è un linguaggio per la specifica, la costruzione e la documentazione di

sistemi software complessi. Le notazioni di UML consentono la costruzione di

diagrammi che rappresentano diverse astrazioni del modello del sistema. I

diagrammi standard di UML sono i seguenti:

- diagrammi dei casi d’uso (use case diagram);

- diagramma delle classi (class diagram);

- diagramma di sequenza (sequence diagram);

- diagramma di collaborazione (collaboration diagram);

- diagramma di stato (state diagram);

- diagramma di attività (activity diagram);

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

FranK Il linguaggio di modellazione ad oggetti 2

- diagramma dei componenti (component diagram);

- diagramma di allocazione (deployment diagram).

Diagramma dei casi d’uso

Un caso d’uso è una tipica interazione tra un utente e il sistema; esso cattura

la funzionalità così come percepite dall’utente. L’utilizzo dei casi d’uso

fornisce una rappresentazione delle responsabilità del sistema in termini di

funzionalità esterne, permettendo una individuazione dei ruoli e dei processi

esistenti nel dominio del problema. Un processo all’interno del dominio del

problema può essere rappresentato (ad un alto livello di astrazione) da un caso

d’uso. I ruoli giocati dai vari utenti del sistema sono rappresentati da attori.

Il frammento della realtà che si cerca di modellare sarà pertanto l’interazione

tra gli attori e il sistema, attraverso i casi d’uso tipici.

Modellare la realtà d’interesse significa, secondo UML, individuare tutti i

possibili casi d’uso del sistema, tutti gli utenti dei singoli casi d’uso e

rappresentare le interazioni tra questi.

Le relazioni tra attori e casi d’uso indicano partecipazione: gli attori

compiono i casi d’uso con i quali sono in relazione. Le relazioni tra i casi

d’uso possono essere di due tipi:

1) d’uso: <<uses>>

2) d’estensione: <<extends>>

Le relazioni d’uso formalizza i casi in cui più casi d’uso racchiudono una serie

di azioni comuni. Un caso d’uso dovrebbe ritagliare l’essenza dei processi di

dominio senza inglobare le numerose variazioni che spesso si riscontrano

all’interno del processo stesso. Le estensioni sono dei percorsi aggiuntivi al

caso d’uso di base. il caso d’uso può essere esteso con percorsi alternativi che

compendiano una pluralità di azioni. Quindi, si può utilizzate la relazione

<<usa>> per non ripetere all’interno di più classi d’uso comportamenti comuni;

si può utilizzare la relazione <<estende>> per descrivere le variazioni

possibili a un comportamento “normale”.

Il diagramma delle classi d’uso è un diagramma in cui vengono rappresentati gli

attori, un insieme di casi d’uso del sistema (raffigurato da un rettangolo che

li racchiude), associazioni di comunicazione (partecipazioni) tra attori e casi

d’uso e generalizzazioni tra casi d’uso.

Un caso d’uso è rappresentato da un ellisse, un attore è raffigurato da un’icona

con un uomo stilizzato. Le relazioni significative in un diagramma dei casi

d’uso sono le seguenti:

- conduzione: la partecipazione di un attore a un caso d’uso è rappresentata

da una linea che va dal simbolo dell’attore al particolare caso d’uso.

- estensione: una relazione è rappresentata da una freccia che va dal caso

d’uso A al caso d’uso B. la freccia va etichettata con <<extends>>: si

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

FranK Il linguaggio di modellazione ad oggetti 3

indica che una istanza di B può includere il comportamento specificato da

A;

- uso: una relazione tra casi d’uso è rappresentata da una freccia che va

dal caso d’uso che usa a quello che viene usato; la freccia viene

etichettata con <<uses>>; una relazione d’uso indica che una istanza del

caso d’uso A includerà anche il comportamento specificato da B.

Un caso d’uso ingloba molti percorsi alternativi che saranno seguiti in

funzione delle condizioni che si verificano. Un percorso all’interno di un

caso d’uso è detto scenario. Questo è un singolo cammino che mostra una

particolare combinazione di condizioni entro quest’ultimo. Per ciascun caso

d’uso deve essere preparato almeno uno scenario. Ogni scenario mostra una

sequenza di interazioni tra oggetti, facenti parte del dominio del problema,

necessari al compimento del percorso. La sequenza delle interazioni è

iniziata dall’attore del caso d’uso e deve portare ad un risultato tangibile.

La rappresentazione degli scenari può essere realizzata in maniera testuale,

descrivendo una lista di interazioni tra oggetti, sia grafica. Gli scenari

possono individuare delle entità concettuali del sistema: esplorando le varie

sequenze di azioni si individueranno le entità che subiscono le azioni a

quelle che le compiono.

Diagramma delle classi

La percezione della realtà che ci circonda avviene tramite l’individuazione

delle entità che la compongono e delle relazioni che intercorrono tra esse.

Le entità sono istintivamente sottoposte a un processo mentale di

classificazione: entità apparentemente diverse sono raggruppate in classi in

relazione alle loro proprietà.

UML propone una notazione grafica e un modello standard di rappresentazione:

il diagramma delle classi (class diagram).

Esso cattura i concetti propri del dominio del problema sotto studio

rimanendo svincolato da come tali concetti saranno rappresentati dal

software. In questa fase si deve comprendere “cosa” e non “come”

(l’implementazione). Un diagramma delle classi mostra la struttura statica

del modello del sistema in fase di studio; in particolare esso evidenzia le

classi, la loro struttura interna e le loro relazioni.

Una classe è un descrittore di un insieme di oggetti con struttura,

comportamento e relazioni comuni. Una classe in UML è rappresentata

attraverso un rettangolo con tre sezioni: la prima specifica il nome della

classe, la seconda gli attributi e poi i metodi.

Si possono specificare per gli attributi, i tipi e la visibilità, e per i

metodi, la visibilità, il tipo ritornato, tipo e nome dei parametri formali.

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

FranK Il linguaggio di modellazione ad oggetti 4

In un diagramma delle classi è possibile specificare una particolare vista

delle classi e cioè l’insieme dei servizi che una classe mette a

disposizione. Questa specifica prende il nome di interfaccia (<<interface>>).

Si riporta per quest’ultimo un nome e la lista delle operazioni.

La classe che fornisce i servizi specificati in una interfaccia è in

relazione di implements con essa.

Gli attributi rappresentano le caratteristiche comuni degli oggetti di una

classe. Ogni oggetto avrà durante il suo ciclo di vita valori propri per i

suoi attributi. L’insieme di tali valori rappresenta lo stato dell’oggetto e

ne influenza il comportamento.

In alcuni casi, l’attributo può essere una caratteristica della classe, non

degli oggetti. Il valore di tale attributo sarà condiviso da tutti gli

oggetti della classe.

I metodi rappresentano nel loro insieme il comportamento degli oggetti di una

classe. Il comportamento effettivo di un oggetto dipenderà dal suo stato

corrente. In alcuni casi uno o più metodi rappresentano il comportamento

della classe (metodo della classe); l’invocazione di un tale metodo può

essere fatta sia sulla classe che sugli oggetti istanza. Sia gli attributi

che i metodi per gli oggetti di una classe possono avere diverse visibilità:

privata, pubblica e protetta. In UML la visibilità è specificata attraverso i

simboli: - visibilità privata, + visibilità pubblica, # visibilità protetta,

$ metodo o variabile della classe (statica).

La visibilità privata indica che gli attributi e/o metodi sono visibili

soltanto all’interno della classe ove sono definiti, la visibilità pubblica

dice che essi sono visibili anche all’esterno della classe, la visibilità

protetta dice che essi sono visibili all’interno della classe in cui sono

definiti e all’interno di tutte le classi che da queste derivano. È possibile

specificare anche se gli attributi e i metodi sono propri della classe. In

questo caso è usato # e gli attributi e i metodi sono detti statici.

Il principio dell’information hiding spinge alla definizione di attributi

privati alla classe. Questa scelta nasconde all’utente degli oggetti istanza

la struttura dati utilizzata per implementare gli attributi. L’utente conosce

esclusivamente il tipo degli attributi specificato nella “firma” dei metodi.

I metodi sono i meccanismi attraverso il quale gli oggetti di una clase

forniscono un servizio.

Le dimensioni di un diagramma delle classe aumentano rapidamente quando la

realtà da modellare è complessa. Per tale motivo UML propone l’utilizzo dello

stereotipo del package. Il package indica un raggruppamento di classi per una

rappresentazione architetturale del sistema software: ciascun package

rappresenta un sottosistema nel senso più ampio della progettazione. Gruppi

di classi fortemente correlati possono essere raggruppati in un apposito

package. Occorre raggruppare oggetti massimizzando la coesione interna e

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

FranK Il linguaggio di modellazione ad oggetti 5

minimizzando la dipendenza. Una dipendenza tra due package dipende dalla

dipendenza che le classi presenti in uno hanno con le classi nell’altro.

La modellazione in termini di package dovrebbe iniziare in fase di specifica

dei requisiti.

Relazioni tra classi e oggetti. Tra classi e oggetti esistono essenzialmente

tre tipi di relazione:

1) generalizzazione-specializzazione;

2) composizione (detta anche aggregazione);

3) associazione.

La generalizzazione-specializzazione permette, in fase di analisi, di

individuare le entità di interes