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 iniziano il lavoro di unificazione dei rispettivi metodi. Successivamente Jacobson si aggrega a questo processo di unificazione integrando anche il suo OOSE (Object Oriented Software Engineering).

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:

• D’uso: <<uses>>
• 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 classe 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:

• Generalizzazione-specializzazione;
• Composizione (detta anche aggregazione);
• Associazione.

La generalizzazione-specializzazione permette, in fase di analisi, di individuare le entità di interes