Diagrammi di attivit`a

I diagrammi di attivit`a servono a descrivere il flusso di controllo e di infor-mazioni dei processi. In un modello di analisi si usano spesso per descrivere i processi del dominio di applicazione, come, per esempio, le procedure ri-chieste nella gestione di un’azienda, nello sviluppo di un prodotto, o nelle transazioni economiche. In un modello di progetto possono essere usati per descrivere algoritmi o implementazioni di operazioni. Si pu`o osservare che, nella loro forma pi´u semplice, i diagrammi di attivit`a sono molto simili ai tradizionali diagrammi di flusso (flowchart).

Un diagramma di attivit`a `e formato da nodi e archi. I nodi rappresentano attivit`a svolte in un processo, punti di controllo del flusso di esecuzione, o oggetti elaborati nel corso del processo. Gli archi collegano i nodi per rappresentare i flussi di controllo e di informazioni.

Il diagramma di Fig. 3.30 descrive un processo di controllo: alla ricezione di un segnale di start, se il sistema `e abilitato vengono messe in funzione

3.5. LINGUAGGI ORIENTATI AGLI OGGETTI 117

s : User : Switch ^{: Conversation}

r : User 1: liftReceiver() 2: setDialTone() 3: * dialDigit() 4.3: connect(r) 4.1: ring() 4.2: liftReceiver() 4.4: connect() 4: <<create>>

Figura 3.29: Un diagramma di comunicazione.

le valvole A e B e la pompa P . Quando tutte e due le valvole sono aperte viene emesso il segnale A and B open, e quando la pompa `e stata avviata si apre la valvola C, e viene emesso il segnale finished (lo schema nel riquadro tratteggiato non fa parte del diagramma).

Le tre linee orizzontali spesse rappresentano un nodo di controllo di tipo fork (diramazione del flusso di controllo in attivit`a parallele) e due nodi di tipo join (ricongiungimento di attivit`a parallele).

I diagrammi di attivit`a possono descrivere attivit`a svolte da entit`a diffe-renti, raggruppandole graficamente. Ciascuno dei gruppi cos´ı ottenuti `e una partizione, detta anche corsia (swimlane).

La Fig. 3.31 mostra un diagramma di attivit`a che descrive (in modo molto semplificato) il processo di sviluppo di un prodotto, mostrando quali reparti di un’azienda sono responsabili per le varie attivit`a.

Il nodo Specification `e un nodo oggetto, in questo caso il documento di specifica prodotto dall’attivit`a Design.

Letture

Obbligatorie: Cap. 5 e Sez. 4.6 Ghezzi, Jazayeri, Mandrioli, oppure Cap. 2 (esclusi 2.5.1, 2.5.2, pagg. 90–100 di 2.6.2, 2.6.4, 2.7.3) Ghezzi, Fuggetta et al., oppure Cap. 7 (esclusi 7.4.2, 7.6.2, 7.7), Sez. 8.4–8.9, Sez. 23.1, Sez. 24.1 Pressman.

start

P _{A B}

C

Open valve B

Open valve A Start pump P

A and B open Open valve C finished fork join Compute parameters [not enabled] [enabled]

3.5. LINGUAGGI ORIENTATI AGLI OGGETTI 119

Market product Make product

Sell product

Specification Design new product

Design dept. Marketing dept. Manufacturing dept.

Capitolo 4

Il progetto

L’obiettivo dell’attivit`a di progetto `e produrre una architettura software, cio`e una descrizione della struttura del sistema da realizzare, espressa in termini dei suoi moduli, cio`e dei suoi componenti e delle loro relazioni reciproche.

Questa descrizione deve rispondere a due esigenze contrastanti: deve es-sere abbastanza astratta da permettere una facile comprensione del sistema (e quindi la verifica dell’adeguatezza del progetto rispetto alle specifiche), ed abbastanza dettagliata da fornire una guida alla successiva fase di codifica.

L’attivit`a di progettazione `e un processo iterativo attraverso una serie di approssimazioni successive a partire da un primo progetto ad alto livello, che ´ındica una suddivisione del sistema in pochi grandi blocchi, fino ad ottenere una struttura “abbastanza” dettagliata. Generalmente la fase di progetto viene considerata come composta di due sottofasi, il progetto architetturale, o di sistema, ed il progetto dettagliato.

`

E difficile stabilire a priori a quale livello di dettaglio si debba fermare la fase di progetto. Inoltre, l’uso di metodi formali, di tecniche di prototipazione e di linguaggi ad alto livello (adatti sia al progetto che alla codifica) rende sfumata la distinzione fra progetto e codifica.

Neppure la distinzione fra la fase di analisi e specifica dei requisiti e la fase di progetto `e completamente netta, poich´e nella fase di progetto spesso si rilevano delle incompletezze e inconsistenze delle specifiche, che devono quindi essere riconsiderate e riformulate. Per questo sono sempre pi´u diffu-si i procesdiffu-si di sviluppo che alternano ciclicamente fadiffu-si di analidiffu-si e fadiffu-si di progetto.

Infine, ricordiamo che il progetto dell’architettura software `e legato al-121

l’architettura hardware, che pone dei vincoli alle scelte del progettista. Il progettista del software deve anche specificare le relazioni fra architettura software ed architettura hardware, e in particolare l’assegnamento dei vari componenti software ai componenti hardware che li devono eseguire.

4.1 Obiettivi della progettazione

Data una specifica, esistono molti modi per realizzarla. Naturalmente la scel-ta fra le diverse possibilt`a non `e arbitraria, ma `e guidascel-ta sia da vincoli di carattere economico, sia dalla necessit`a di conseguire un’adeguata qualit`a del prodotto o del progetto stesso. Per qualit`a del progetto si intendono quelle caratteristiche che, pur non essendo “visibili” all’utente, determinano la qua-lit`a del prodotto, e quelle caratteristiche che offrono un vantaggio economico al produttore del software, rendendo pi´u efficace il processo di sviluppo.

Fra le caratteristiche che determinano la qualit`a del prodotto o del pro-getto, citiamo l’affidabilit`a, la modificabilit`a (ricordiamo il principio “design for change”), la comprensibilit`a e la riusabilit`a. L’esperienza accumulata finora dimostra che queste propriet`a dipendono fortemente da un’altra, la modularit`a. Un sistema `e modulare se `e composto da un certo numero di sottosistemi, ciascuno dei quali svolge un compito ben definito e dipende da-gli altri in modo semplice. `E chiaro che un sistema cos´ı strutturato `e pi´u comprensibile di uno la cui struttura venga oscurata dalla mancanza di una chiara suddivisione dei compiti fra i suoi componenti, e dalla complessit`a delle dipendenze reciproche. La comprensibilit`a a sua volta, insieme alla sempli-cit`a delle interdipendenze, rende il sistema pi´u facile da verificare, e quindi pi´u affidabile. Inoltre, il fatto che ciascun sottosistema sia il pi´u possibile indipendente dagli altri ne rende pi´u facili la modifica e il riuso.