Eccezioni

Come gi`a accennato, la gestione degli errori e delle situazioni anomale `e un aspetto della suddivisione di responsabilit`a fra moduli. I linguaggi che offrono il meccanismo delle eccezioni permettono di esprimere in modo chiaro e ben strutturato le soluzioni di questo problema. Il problema consiste nel decidere in quale modulo si deve trattare una data situazione eccezionale, dopodich´e bisogna specificare in quali moduli si pu`o verificare tale situazione, come viene riconosciuta, come viene segnalata, e infine come il controllo viene passato al modulo responsabile di gestire l’errore.

Nei linguaggi dotati di gestione delle eccezioni, i moduli in cui si pu`o veri-ficare un’eccezione contengono delle istruzioni che sollevano, cio`e segnalano tale eccezione. I moduli preposti a gestire l’eccezione contengono dei sotto-programmi, detti gestori o handler , esplicitamente designati a tale scopo. A tempo di esecuzione, quando in un modulo si scopre il verificarsi di una si-tuazione eccezionale (cosa che richiede dei controlli espliciti, tipicamente con istruzioni condizionali), l’istruzione che solleva l’eccezione causa l’interruzio-ne dell’esecuziol’interruzio-ne del modulo ed il trasferimento del controllo al gestore “pi´u vicino” nella catena di chiamate che ha portato all’invocazione del modulo che ha sollevato l’eccezione.

Per fissare le idee, supponiamo che un modulo A chiami una funzione definita in un modulo B, che a sua volta chiama una funzione di un modulo C. Supponiamo inoltre che nell’esecuzione di C si possa verificare un’eccezione, e che nel modulo A (ma non in B) ci sia un gestore per tale eccezione. Se, quando si esegue C, l’eccezione viene sollevata, allora vengono interrotte le esecuzioni di C e B, e il controllo passa al gestore appartenente ad A. In questo gestore, se necessario, si pu`o risollevare l’eccezione, delegandone la gestione ad altri moduli ancora, di livello pi´u alto. Questo pu`o accadere se nel modulo A si scopre che l’eccezione non pu`o essere gestita, oppure se A pu`o eseguire solo una parte delle azioni richieste.

In UML1 le eccezioni si modellavano come oggetti che possono essere spediti (come segnali) da un oggetto all’altro. In questo modo, le classi che rappresentano eccezioni hanno lo stereotipo ≪exception≫. La dipenden-za stereotipata ≪send≫ associa le eccezioni alle operazioni che le possono sollevare, come in Fig. 4.12.

4.4. MODULI NEI LINGUAGGI 141 «exception» RangeExc index: int «exception» SizeExc Vector

operator[](in i: int): double& «constructor»

«send»

Vector(in size: int)

«send»

Figura 4.12: Eccezioni in UML1.

In UML2 le eccezioni non sono viste come segnali, ma come oggetti che vengono creati quando l’esecuzione di un’azione incontra una situazione ano-mala e vengono passati come parametri d’ingresso ad un’altra azione, il ge-store di interruzioni. Questo meccanismo viene modellato nel diagramma di attivit`a, con apposite notazioni che non tratteremo, limitandoci a mo-strare, come esempio, un frammento di un possibile diagramma di attivit`a (Fig. 4.13). Nel diagramma delle classi, le eccezioni che si possono solle-vare nel corso di una operazione possono essere elencate come valori della propriet`a exceptions associata all’operazione.

allocate_vector

use_vector ^rangeHandler sizeHandler SizeExc

RangeExc

Letture

Capitolo 5

Progetto orientato agli oggetti

We need to go beyond the condemnation of spaghetti code to the active encouragement of ravioli code. – Raymond J. Rubey, SoftTech, Inc.1

Come abbiamo gi`a osservato parlando della fase di analisi e specifica dei re-quisiti, nelle metodologie orientate agli oggetti un sistema viene visto come un insieme di oggetti interagenti e legati fra loro da vari tipi di relazioni. In fase di analisi e specifica dei requisiti si costruisce un modello in cui il sistema software (cio`e il prodotto che vogliamo realizzare) viene visto nel contesto dell’ambiente in cui deve operare. Questo modello, in cui le en-tit`a appartenenti al dominio dell’applicazione (detto anche spazio del proble-ma) sono preponderanti rispetto al sistema software, `e il punto di partenza per definire l’architettura software, la cui struttura, negli stadi iniziali della progettazione, ricalca quella del modello di analisi.

La fase di progetto parte quindi dalle classi e relazioni definite in fase di analisi, a cui si aggiungono classi definite in fase di progetto di sistema e relative al dominio dell’implementazione (o spazio della soluzione). Nelle fasi successive del progetto questa struttura di base viene rielaborata, riorga-nizzando le classi e le associazioni, introducendo nuove classi, e definendone le interfacce e gli aspetti pi´u importanti delle implementazioni.

1

v. http://www.gnu.org/fun/jokes/pasta.code.html

5.0.4 Un esempio

Immaginiamo di progettare un sistema per la gestione di una biblioteca. La Fig. 5.1 d`a un’idea estremamente semplificata di un possibile modello d’ana-lisi. Ci sono due diagrammi di casi d’uso, di cui il secondo tiene conto del requisito che solo il bibliotecario interagisca direttamente col sistema. Si `e mantenuta la versione originale del diagramma, che mostra il ruolo dell’u-tente, per ricordare che i servizi della biblioteca sono destinati all’udell’u-tente, e lasciare spazio a future estensioni in cui l’utente potrebbe accedere al sistema direttamente. La dipendenza ≪trace≫ si usa per rappresentare la relazione storica fra diverse versioni di un modello o parti di esso.

ricerca(l: Libro) aggiungi(l: Libro) Catalogo Biblioteca RegistroUtenti Amministrazione

Utente _{registra(u: Utente)}

presta(l: Libro, u: Utente)

Biblioteca Bibliotecario Libro Registrazione Prestito Registrazione Prestito «trace» * 1 * 1 prestito * 1 1 * Biblioteca Bibliotecario Utente Biblioteca Bibliotecario

Figura 5.1: Esempio: un progetto OO (1).

La Fig. 5.2 mostra un primo abbozzo del modello di progetto. `E stata introdotta una classe (che in questo stadio sta per un intero sottosistema) che rappresenta l’interfaccia presentato dal sistema al bibliotecario. Questa classe ha lo stereotipo ≪boundary≫ appunto per mostrare questo suo ruolo. `

5.1. EREDIT `A E POLIMORFISMO 145