Appunti di Ingegneria del Software -...

Appunti di Ingegneria del Software

Corso tenuto dal Prof. Flavio Bonfatti A.A. 2000-2001

Realizzazione a cura di Francesca Mazzoni ([email protected]) ��

��

�� !"#��$��%��&��

��'��(��'��)� *��+

*��,�(��)��(��*��

��-��(��.�/�� (��/��*��0��1-��(��.�/��1��(��/�

2�� '��'��'��3!"#

��$��%��3�

INGEGNERIA DEL SOFTWARE AA. 00-01

© Francesca Mazzoni 2001 - 1 -

Introduzione Il software è un prodotto particolare per vari motivi, fra i quali quello di essere un prodotto immateriale, intellettuale. All'inizio ho solo una vaga idea di quello che il software deve fare. Ho indicazioni va-ghe, incomplete, spesso contraddittorie. Poi si passa attraverso vari stadi, ognuno dei quali è una raffinazione delle informazio-ni che ho sul software che devo produrre. Ad ogni passaggio aumenta la quantità di in-formazione, si riducono le incompletezze e le contraddizioni. Con l'ultimo di questi passaggi ottengo il codice del software, che è la versione definitiva. Gestire la produzione di software significa porre delle regole su ognuno di questi step. N.B. è necessario l'impiego di molte persone perché il processo avvenga. Il software è un prodotto “one-of-a-kind” (ogni software è diverso da tutti gli altri). L'unicità del prodotto (lo vendo in una o poche più copie), insieme al lungo processo di sviluppo e alle molte persone che vi hanno lavorato, lo rendono un prodotto industriale. N.B. più il software è vecchio, e meglio è: gli errori sono stati testati o comunque quel-li che sono rimasti non erano poi così drammatici. Uno degli obiettivi fondamentali è l'utilizzo del software perché riduce i costi.

Tasso di guasto di un prodotto software La curva che rappresenta il tasso di guasto di un prodotto materiale è profondamente diversa da quella del tasso di guasto di un prodotto software. Per un prodotto materiale si ha un primo momento in cui si verificano molti guasti e questo momento corrisponde alla fase di progettazione dell’oggetto (in figura corri-sponde al tratto (0, t1)), poi la pendenza della curva cala notevolmente (tratto (t1, t2)) e ricomincia a salire (da t2 in poi) a causa dell’usura.

inizio fine

OGGETTO MATERIALE

gioventù del prodotto

vecchiaia del prodotto

t1 t2

Tass

o di

gua

sti

L’inizio della curva per un prodotto software è sostanzialmente analoga, ma in seguito presenta profonde differenze. I picchi verticali, che si possono notare nella prossima figura, corrispondono a nuove release del software: il nuovo pacchetto ricomincia una fase in cui vi è un’alta incidenza di guasti dovuti al fatto che qualcuno ha rimesso le mani sul software; è come se fossi di nuovo all’inizio. In realtà è ancora peggio perché,



come mostra la freccia, non si raggiunge mai il livello precedente di incidenza dei gua-sti, ma se ne raggiunge di volta in volta uno sempre un po’ più elevato, ciò è dovuto al fatto che non tutti i bug della versione precedente vengono corretti e si aggiungono quelli della nuova release. In definitiva il software è un prodotto molto più soggetto a guasti rispetto a qualunque altro tipo di prodotto (è anche abbastanza naturale, visto che è fatto per la maggior parte dall’ingegno dell’uomo).

inizio fine

SOFTWARE

Tass

o di

gua

sti

Crisi del software Riguarda un serie di aspetti per i quali nasce l'insoddisfazione sia del cliente che del fornitore. I principali motivi sono:

1) Aumenta il back-log: Non c'è abbastanza capacità produttiva per soddisfare la richiesta inevasa.

2) Sempre in ritardo Le date di consegna fissate non vengono mai rispettate. (Questo soprattutto nelle piccole aziende)

3) Sempre pieno di buchi: Non viene mai consegnato un software che funzioni perfettamente.

4) Costa troppo: Il cliente si sente chiedere molti soldi subito, molti dopo, molti per la manuten-zione, molti per nuove release.

5) Pago subito e spero: Solo alla fine il software si vede. Il cliente paga qualcosa all'inizio e per mesi non vede niente.

Tipi di software Sostanzialmente vi sono 3 tipi di software richiesto:

1. software sequenziale (gestionale) 2. software real-time 3. software per PC/internet



1. Questo tipo di software lavora attorno ad una grande base di dati. È un softwa-

re poco complicato, di grandi dimensioni, ad esempio software per gestire una banca, un negozio. Occupa circa 1/3 delle risorse che la scuola produce.

2. Ha lo scopo di controllare e comandare macchine e impianti che, attraverso questo software subiscono un’automazione. Esistono problemi sul tempo di ri-sposta del software. Nella nostra zona abbiamo la prevalenza di software soft real-time (time driven). Si hanno software soft per l’automazione di macchinari, software hard quando è in gioco la vita dell’uomo (es. aerei).

3. Applicazioni client-server. C’è una nuova idea del software pagato in base al tempo di utilizzo: le server farms mettono a disposizione degli utenti il softwa-re sul server e il cliente paga in base al tempo effettivo di utilizzo ⇒ il cliente non ha più bisogno di avere lui un server, ma gli basta un comune PC.

Qualità del software I fattori di qualità del software sono di due tipi: fattori esterni ed interni. FATTORI ESTERNI. Sono quelli che l’utente percepisce dal software.

1. CORRETTEZZA. Potrebbe voler dire che il software non si ferma mai (N.B. è un’utopia) ⇒ lo valuto in base a quante volte si ferma (MTBF = Mean Time Be-tween Failures). Il MTBF è una misura oggettiva, ma parziale: non mi dice nulla riguardo la gravità della failure! AFFIDABILITÀ. Il software mi dà pochi problemi, in particolare pochi proble-mi di tipo grave. ROBUSTEZZA. Un software è robusto se tende al continuare a lavorare anche in presenza di guai o di cose non previste. Magari va avanti in modo un po' dege-nerato, ma tenta di andare avanti. SICUREZZA. Il software non compie mai azioni che possano essere di tipo di-struttivo. Il software è sicuro anche quando è utilizzato da un utente inesperto o male intenzionato. RISPETTO DEI BISOGNI. Il software deve fare esattamente quello che voglio io sia per ciò che riguarda le specifiche (verifica), sia per ciò che riguarda i bi-sogni reali: le specifiche che ho dato al progettista possono essere: sbagliate, incomplete, poco chiare (validazione)

2. PRESTAZIONI. Si possono valutare in base a - tempo di risposta: qualunque comando dell'utente deve ricevere risposta en-

tro il tempo di risposta fissato. Eventualmente il tempo di risposta può esse-re riferito al tipo di operazione

- occupazione di memoria: questo problema è molto diminuito negli ultimi anni 3. FACILITÀ D'USO. Rientrano in questo punto l’interfaccia utente, la grafica, la

capacità da parte dell'utente di usare le funzioni del sistema mai usate senza



dover ricorrere ad una guida. La guida in linea migliora un po'. La facilità d'uso è legata alla logica con cui il sistema è progettato: se è a step è meglio rispetto ad un blocco monolitico.

FATTORI INTERNI: sono quelli percepiti da chi progetta o realizza il software Se il software è progettato bene è più facile soddisfare i requisiti esterni.

1. COMPRENSIBILITÀ: devo organizzare il software in moto da poter capire e spiegare cosa fa una parte rispetto alle altre

2. RIUSABILITÀ: mi piacerebbe poter estrarre una parte da un pacchetto sof-tware e usarla per costruire un nuovo pacchetto software.

3. VERIFICABILITÀ: ha a che fare col collaudo. Se può essere verificato parte per parte, allora è OK. Devo avere la possibilità di rapportare ciò che è stato progettato con le specifiche.

4. MANTENIBILITÀ: il software deve poter essere corretto, adattato a nuove situazioni. N.B. anche un altro programmatore deve essere in grado di modifica-re il software.

Modularità Esiste una parola chiave per soddisfare tutte queste richieste: MODULARITÀ Se concepisco il software come diviso in parti sostanzialmente autonome è meglio ⇒ lo possono fare persone diverse ⇒ faccio prima. Se ciascuna parte è stata concepita come autonoma ⇒ OK comprensibilità (ogni parte ha la sua funzione), OK riusabilità (ho fatto un pezzettino che fa solo una determinata cosa ⇒ quando ne ho bisogno di nuove ce l'ho già), OK anche verificabilità e mantenibilità (aggiorno solo il modulo richiesto e lascio stare gli altri). Si può dimostrare che x =x1+x2 (dove x sono le cose da fare e x1, è x2 sono le parti in cui le scompongo) C(x) > C(x1) + C(x2) C = complessità Quanto più una cosa è complessa , tanto più costa C (x) ~ E (x) E = efford (=sforzo) E(x) > E(x1) + E(x2) > E(x11) + E(x12) + E(x2) > … Lo sforzo si riduce tanto più, quanto più elevato è il numero di parti in cui ho scompo-sto il problema iniziale



n° di moduli in cui suddivido il problema

sfor

zo c

osto

di i

nter

facc

iam

ento

fra

le p

arti

N.B. va però in modo opposto è il costo della "colla" per riattaccare tutti i moduli. Il costo totale è la somma dei due

n° di moduli in cui suddivido il problema

cost

o to

tale

⇒ c'è un'area di costo minimo. N.B. non c'è nessun metodo per dire qual è il numero di moduli. Anzi, di più, non si sa nemmeno quali sono i moduli in cui devono scomporre il problema iniziale. Riguardo alla modularità si hanno due punti di vista, due scuole di pensiero. 1) non importa quale metodologia uso, importa che il prodotto presenti certi requisiti di modularità. 2) allo scopo di avere una programmazione modulare conta molto la metodologia che deve essere ispirata a certi principi di modularità. Entrambi questi punti di vista portano grosso modo alle stesse conclusioni.



Caso 1: non importa quale metodologia uso, importa che il prodotto presenti certi re-quisiti di modularità. Se esaminiamo un software già progettato vediamo che questo prodotto è valutabile in termini di due requisiti

• COESIONE di ciascun modulo • ACCOPPIAMENTO fra moduli

L'idea è di misurare l'esito di una progettazione in base a coesione e accoppiamento. COESIONE: il modulo è molto coeso se tutte le operazioni che vi sono contenute han-no lo stesso scopo, se non è ragionevole dividerlo in altri moduli. Se è poco coeso po-trei avere buone ragioni per scomporlo in moduli più piccoli. Problema: come si misura la coesione? È chiaro che la coesione deve essere il più grande possibile. Vediamo un approccio prettamente qualitativo. Fisso una scala che ha a sinistra il valo-re più basso di coesione e a destra il più alto, poi metto sulla scala i casi campione per fare dei confronti.

coes

ione

ca

suale

coes

ione

log

ica

coes

ione

te

mpo

rale

coes

ione

or

ienta

ta ai

dati co

esio

ne

funz

iona

le

basso alto

COESIONE CASUALE Voglio fare moduli di circa 200 istruzioni e ho un codice di 5000 implica semplicemen-te ogni 200 mi fermo e faccio un modulo. COESIONE LOGICA Si ha coesione logica all’interno di un modulo al cui interno si compiono operazioni ana-loghe, ad esempio modulo di gestione degli errori. Tutti gli altri moduli si rivolgono a lui quando vanno in errore. La coesione è bassa perché potrei scomporlo in base al tipo di errore. COESIONE TEMPORALE Riguarda moduli che gestiscono successioni strette di eventi. Ad esempio la stampa delle buste paga. Deve fare la stampa di certi dati poi di leggere un file e fa dei calco-li poi fa un'altra stampa poi legge da un altro file e stampa,..., Sono ancora a livelli piuttosto bassi di coesione: è abbastanza vicino alla coesione logi-ca. COESIONE ORIENTATA AI DATI Un certo modulo è progettato per eseguire tutte le operazioni, le funzioni su un una certa struttura dati. Sono in un grado molto alto di coesione.



COESIONE FUNZIONALE La funzione è un modulo che, quando invocata, riceve dei dati (parametri), fa delle o-perazioni e produce un risultato. In un buon progetto software devono esistere molti moduli funzionali e orientati ai dati ed invece un numero limitato ed ben circoscritto di moduli con coesione logica o temporale. N.B. non devono esistere moduli con coesione casuale. ACCOPPIAMENTO È molto difficile dare un criterio quantitativo, molto più facile è invece darne uno qua-litativo. L'accoppiamento deve essere il più basso possibile ⇒ ciascun modulo è più fa-cilmente isolabile dagli altri

mini

mo sc

ambio

di

dati scam

bio di

str

uttu

re

pass

aggio

di

cont

rollo

ambie

nte

cond

ivisio

ne

di ar

ee d

i m

emor

ia acce

sso

all’a

rea

dati d

i un

altro

m

odulo

ACCOPPIAMENTO MINIMO È quando rendo minimo il numero di collegamenti fra i moduli ACCOPPIAMENTO PER SCAMBIO DI DATI È quando trasferisco dei dati fra un modulo e l'altro. È un buon accoppiamento perché è comprensibile e rende i moduli quasi separati. ACCOPPIAMENTO PER SCAMBIO DI STRUTTURE Se scambio record devo condividere la definizione del record stesso e così se scambio un array ⇒ se modifico la struttura in un modulo debbo cambiarla anche nell'altro. ACCOPPIAMENTO PER PASSAGGIO DI CONTROLLO Il modulo A invoca il modulo B. Il modulo A non può mai vivere senza B. Se voglio riusa-re A devo portarmi dietro anche B. ACCOPPIAMENTO PER AMBIENTE Due moduli fanno uso dell'ambiente (sistema operativo) per scambiarsi i dati. Adesso sono legata anche al sistema operativo e non solo ai due moduli.



ACCOPPIAMENTO PER CONDIVISIONE DI AREE DI MEMORIA Esempio le variabili globali. È un accoppiamento difficilmente isolabile, comprensibile. ACCOPPIAMENTO PER ACCESSO ALL'AREA DATI DI UN ALTRO MODULO Il modulo A si trova i dati scambiati chissà in che modo e chissà da chi. Se è il progetto è a sinistra nel grafico è buono, se tende a scivolare a destra non è buono. Caso 2: allo scopo di avere una programmazione modulare conta molto la metodologia che deve essere ispirata a certi principi di modularità. È meglio se è la metodologia stessa che ci spinge ad una buona progettazione, piuttosto che vedere a posteriori se il progetto è buono o no, perché se non lo è, è troppo tardi. Vi sono cinque criteri per creare un buon progetto software: 1) SCOMPONIBILITÀ. La metodologia deve spingere verso la scomposizione del pro-getto in moduli. 2) COMPONIBILITÀ (riusabilità). La metodologia deve favorire il riutilizzo di moduli sviluppati in altri progetti. 3) COMPRENSIBILITÀ. La metodologia deve spingere a concepire moduli che siano comprensibili in sé, senza che si debbano conoscere i moduli accoppiati (è un'utopia: va bene in realtà se si parla di pochi altri moduli) 4) CONTINUITÀ (proporzionalità). Ci deve essere una certa proporzione fra il biso-gno di modificare il pacchetto software e il numero di moduli che lo compongono. Se ho pochi moduli ne devo modificare pochi, se ne ho tanti, ne devo modificare di più. 5) PROTEZIONE (isolamento). Ciascun modulo deve mantenere isolati al proprio inter-no i problemi che genera, al più estenderli a pochissimi altri moduli. Ho anche i cinque principi

1) MODULARITÀ LINGUISTICA. Una metodologia deve contenere in sé il concetto di modulo.

2) POCHE INTERFACCE. Quando si progetta bisogna fare in modo che il numero di comunicazioni fra modulo e modulo sia veramente il piccolo.

3) INTERFACCE PICCOLE. Ciò che viene scambiato fra moduli deve essere poca in-formazione.

4) INTERFACCE ESPLICITE. Lo scambio deve essere esplicito, molto ben definito e documentato.

5) INFORMAZIONI NASCOSTE. Qualunque informazione deve essere accessibile solo tramite le funzioni che il modulo mette a disposizione. Deve essere impedito un accesso diretto dall'esterno ai dati per eventuali modifiche.

Cerchiamo di mettere a confronto i due punti di vista:



Coesione logica: è considerata così poco auspicabile perché se noi abbiamo un modulo che ne presenta le caratteristiche ⇒ componibilità: il modulo tratta situazioni analoghe ad esempio modulo di gestione degli errori: se lo voglio riusare dovrei avere lo stesso numero di errori e lo stesso tipo di errore. È riusabile solo se le situazioni che tratta sono esattamente le stesse (⇒ non è detto che sia riusabile) Comprensibilità: posso spiegare il modulo solo in relazione ai moduli che comunicano con lui per ottenere i suoi servizi. Continuità: se il modulo produce anche dei risultati non è da escludere che un guaio che lo riguardi debba estendersi anche ai moduli accoppiati. Protezione: può provocare effetti di propagazione dei guai. Ho molte interfacce. Coesione temporale: Componibilità: lo posso riusare se ho lo stesso numero di operazioni e se vanno esegui-te nello stesso ordine Comprensibilità: dà meno problemi. Non è detto che richieda molti accoppiamenti ⇒ va meglio. Continuità, protezione: meno soggette a rischi perché ho meno interfacce. Coesione per passaggio di dati, coesione funzionale Componibilità: è probabile non solo che sia riusabile, ma che si porti dietro della cono-scenza: il problema è già stato studiato ⇒ sono a posto. Continuità e isolamento: OK. Ho poche interfacce che sono piccole ed esplicite. Accoppiamento per condivisione di area dati Le informazioni non sono nascoste. Le interfacce non sono esplicite e possono essere grandissime. Non ho isolamento. Se devo modificare la struttura dell'area dati devo modificare tutti i moduli. La comprensibilità rasenta lo zero. La riusabilità si ha solo se l'area dati e identica ⇒ non è riusabile. Accoppiamento per ambiente È simile ma minore Sempre minore se scambio strutture dati o singoli dati.



Ciclo di vita di un prodotto software Il ciclo di vita di un prodotto software ha una prima fase, che chiamo studio di fattibilità: dalle specifiche di progetto guardo se è effettivamente possibile creare un software che sia in grado di rispondere ai requisiti richiesti. Se questa fase dà esito positivo ho il vero e proprio ciclo di sviluppo.

IDEA

FATTIBILITÀ

CICLO DI SVILUPPO

OPERATIVITÀ E MANUTENZIONE

Nuova release molto pesante

Morte del software (non mi serve più)

La fase finale del ciclo di sviluppo è la fase di operatività e manutenzione. Ho tre tipi di manutenzione:

• Correttiva: ha lo scopo di rimuovere errori residui che nel tempo salteranno fuori durante l'uso del software.

• Adattativa: l'ambiente in cui software lavora cambia ⇒ il software ha la neces-sità di alcune modifiche.

• Estensiva: richiede l'aggiunta o la modifica di funzioni già presenti, per far fronte a nuovi bisogni.

A e B rientrano nel contratto d'assistenza, mentre C richiede contratti ad hoc. N.B. errori in progettazione costano circa 60 volte errori di codifica.



Partendo da una definizione approssimativa dei bisogni, passando attraverso una serie di step, si arriva alla codifica del software.

Definizione approssi-mativa del bisogno

Codice

Informazione

Informazione

Informazione

Informazione

Devo poter controllare in qualche modo questo procedimento. Se non c'e controllo in-termedio ⇒ non c'è garanzia di un buon software. Divido il processo in step, fasi, ognuna delle quali deve essere sottoposta a verifica.



Modelli del ciclo di sviluppo

Modello a cascata del ciclo di sviluppo Articola il ciclo di sviluppo nelle seguenti fasi:

1. raccolta dei requisiti 2. analisi e specifica dei requisiti 3. disegno di massima 4. disegno esecutivo 5. codifica 6. test e installazione

C’è poi la manutenzione che è al di là del ciclo di sviluppo; prima c’è lo studio di fattibi-lità.

Raccolta dei requisiti

Analisi e specifica dei requisiti

Studio di fattibilità

Disegno di massima

Disegno esecutivo

Codifica

Test e installazione

Manutenzione

Le sei fasi sono ciascuna definibile con una certa chiarezza e precisione.



Raccolta dei requisiti: il cliente fornisce al progettista tutte le informazioni necessa-rie per realizzare il progetto software. Sia le fonti di informazione che il loro formato non sono omogenei. In genere il cliente non è in grado di fornire i requisiti, tutto al più si lascia intervistare …

Raccolta dei requisiti

req. funzionali

req. non funzionali

insieme organizzato di requisiti di progetto

metodologia

esperienza

L’input di questa prima fase sono i: Requisiti funzionali: descrizione del comportamento del software, elenco di tutte le operazioni che ci si aspetta dal pacchetto software. Requisiti non funzionali: aspetti che vincolano il progetto software ma che non cen-trano con quello che deve fare (ambiente, linguaggio di programmazione, occupazione di memoria, tempi di risposta). Un altro possibile input è l’esperienza della software-house, che serve per le cose che il cliente ha dimenticato, trascurato o spiegato male. L’output di questa fase, che diventa input per la fase successiva, è: Insieme organizzato di requisiti di progetto: occorre che il materiale che ha attra-versato la prima fase sia un po’ migliore di prima:

- deve essere omogeneo - deve evidenziare le incompletezze, le contraddizioni - deve evidenziare e, se possibile, eliminare le ambiguità

Per fare questo serve un lavoro basato su di una metodologia. Analisi e specifica dei requisiti: prende in input l’output della fase precedente e pro-duce una rappresentazione semiformale dei requisiti di progetto; semiformale nel sen-so che alcuni aspetti sono descritti in maniera ancora approssimativa, alcuni altri sono descritti in linguaggio formale.



Analisi e specifica dei

requisiti

insieme organizzato di requisiti di progetto

metodologia

esperienza

rappresentazione semiformale dei requisiti di progetto

Disegno di massima: produce una rappresentazione più formale dell’architettura e delle parti del sistema. Qui si comincia a dire cosa il sistema debba fare, ma non si sa ancora come.

Disegno di massima

rappresentazione più formale dell’architettura e delle parti del sistema

metodologia

esperienza

rappresentazione semiformale dei requisiti di progetto

Se si arriva bene e senza intoppi a questa fase, di qui in poi non ci dovrebbero più es-sere grandi problemi. Negli ultimi anni c’è stata una tendenza a collassate le fasi 2 e 3 in un’unica fase de-nominata “Analisys & Design”. Questo modello presenta alcuni difetti fra cui:

• va bene se è la ventesima volta che produciamo lo stesso pacchetto, altrimenti l’inesperienza gioca un ruolo predominante e mi obbliga a tornare più volte sui miei passi per apportare modifiche.

• Ciascuna delle fasi deve essere opportunamente pianificata nel tempo. • Ci deve essere un’attività di verifica e di controllo di conformità (devo control-

lare l’output di ogni fase prima di passarlo in input alla fase successiva).



Modello di tipo prototipale del ciclo di sviluppo Mi serve per superare in qualche modo le carenze dovute alla mancanza di esperienza.

Raccolta dei requisiti di progetto

Progettazione veloce

Sviluppo del prototipo

A&D

da qui in poi segue il modello a cascata

Raccolgo tutti i requisiti e le specifiche che posso; sulla base di questi requisiti mi prefiguro un certo progetto. Sulla base di questo disegno veloce faccio un prototipo, cioè costruisco un’ipotetica interfaccia utente per mezzo di strumenti RAD (= Rapid Application Development). Faccio vedere il prototipo al cliente e gli chiedo se va bene o se sono necessarie modifiche. Dopo 1, 2, 3 giri di questo genere, in cui faccio il pro-totipo e lo faccio verificare al cliente, di solito il cliente dice che è soddisfatto e che il progettista ha capito cosa volesse. N.B. c’è un problema di fondo nell’utilizzo di questo metodo: di solito ci si impiega po-chissimo a fare il prototipo e il cliente non capisce perché poi ci voglia tanto tempo per sviluppare tutto il progetto, quindi si sente truffato. Il prototipo deve essere buttato via, sia per farlo vedere al cliente che per motivi di progettazione: ricominciando da capo il software sarà sicuramente migliore!



Modello a V del ciclo di sviluppo Con i rettangoli si indicano le attività e con le ellissi i risultati

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17 1) RACCOLTA DEI REQUISITI 2) INSIEME DI REQUISITI 3) PROGETTAZIONE DI SISTEMA 4) DEFINIZIONE DI SOTTOSISTEMA 5) PROGETTAZIONE DI SOTTOSISTEMA 6) DEFINIZIONE DEI MODULI 7) DISEGNO DEL MODULO 8) SPECIFICHE DEL SINGOLO MODULO 9) REALIZZAZIONE DEL MODULO10) MODULO TESTATO11) INTEGRAZIONE E TEST DEI MODULI12) SOTTOSISTEMA TESTATO13) INTEGRAZIONE E TEST DEI SOTTOSISTEMI14) SISTEMA TESTATO15)16) SOFTWARE TESTATO17) OPERATIVITÀ

TEST DI ACCETTAZIONE

Il collaudo del software è un’attività che si svolge essenzialmente in quattro momenti:

1. test del singolo modulo, componente 2. test integrato (tutti i componenti insieme)

Questi due momenti sono racchiusi in un’unica fase chiamata α-test e si svolge presso la software-house.

3. test presso il cliente Questa fase è chiamata β-test: è un uso più realistico del software. La durata deve essere definita contrattualmente.

4. test di accettazione Il fornitore è convinto che il software vada circa bene, mentre il cliente è convinto che ci siano ancora troppi bug: si deve giungere ad un accordo! Si definisce una sessione di lavoro (insieme delle operazioni che verranno compiute) ed il software deve uscirne indenne (non si deve inchiodare!!) Il superamento del test obbliga il committente ad accettare il software e a pagare. Il non superamento obbliga il fornitore a porvi rimedio. N.B. definire molto bene in sede contrattuale il test d’accettazione



Modello a X del ciclo di sviluppo La parte di grafico in blu serve per lo sviluppo del software per il cliente, la parte in rosa serve alla software-house per il riutilizzo del software.

progettazione di sistema

integrazione di sistema

progettazione di sottosistema

integrazione di sottosistema

sviluppo dei moduli

sviluppo dei componenti

riusabili

rappresentazione tecnica dei componenti

definizione dei componenti per il

riutilizzo

libreria di componenti

identificazione dei componenti per il riutilizzo



Modello a spirale del ciclo di sviluppo

definizione degli obiettivi e alternative

scelta e soluzione dei rischi

sviluppo e verifica pianificazione

costo per la pianificazione

costo per la pianificazione e la definizione degli obiettivi

costo per la pianificazione, la definizione degli obiettivi e lo step successivo

È un modello puramente economico, in pratica è un diagramma polare in cui la distanza dall'origine rappresenta il costo.



Studio di fattibilità È un’attività che ha come obiettivo la determinazione dell’opportunità di dare vita ad un progetto software. Si va da un’ipotesi (intuizione, esito di un’analisi di mercato, ga-ra d’appalto, richiesta esplicita del cliente) ad una valutazione di tempi, costi, criticità del progetto. Se sbaglio a fare lo studio di fattibilità perdo un sacco di tempo e denaro. Problema: ho veramente poche informazioni su quello che il software deve fare: devo prendere decisioni critiche in poco tempo (settimane) e sulla base di poche informa-zioni. Gli strumenti per svolgere lo studio di fattibilità non sono tanti, ma usati opportuna-mente danno un certo aiuto!

1. raccogliere tutti i dati esistenti 2. stimare i tempi necessari

a. a occhio (N.B. è molto pericoloso e lo posso fare solo se ho molta espe-rienza. È comunque sconsigliabile)

b. con un metodo: diagramma di Gantt

attiv

ità

Tempo (settimane)

A

B

C

DE

F

G

0 3 4 6 8 9 10 12 Quali sono le attività da rappresentare sul diagramma di Gantt? Sono quelle previste dal modello del ciclo di sviluppo della mia software house. Per ogni attività devo sapere il tempo d’inizio e la durata. Come faccio a sapere quanto deve durare ogni attività? Qui va bene una stima ad oc-chio: posso sbagliare anche del 50%, ma poiché le attività sono tante in genere gli errori di stima tendono a compensarsi. Il caso è ben diverso se faccio una stima ad occhio sul tempo dell’intero progetto: la stima è unica e non può essere compensata in nessun modo ⇒ è molto pericoloso!!



Si chiama tempo di rilascio del software il tempo corrispondente alla fine dell’attività che si protrae più a lungo (non quella che dura di più, ma quel-la che finisce più tardi).

3. stimare i costi. Come si fa a stimare il costo del progetto? Guardo, fase per fase, quante per-sone lavorano al progetto, faccio una somma verticale per ottenere il diagram-ma di costo, dal quale posso anche vedere il fabbisogno di manodopera istanta-nea settimana per settimana ⇒ posso sapere se ho effettivamente la possibilità di finire il progetto entro il tempo di rilascio calcolato, o se invece, per mancan-za di manodopera, devo dilazionare nel tempo alcune fasi, e quindi posticipare il tempo di rilascio.

Cos

to

Tempo (settimane) Una casellina nell’istogramma corrisponde ad una settimana di lavoro per una persona, quindi, calcolando l’area dell’istogramma e moltiplicando per il costo settimanale, trovo il costo diretto del progetto (stipendi). Ma qual è il costo settimanale? Beh, dipende da molte cose fra cui il tipo di lavoro che si svolge (programmatore, analista, consulente, …), il grado di esperienza (junior, senior, …). A grandi linee si può valutare, per un programmatore junior, uno stipendio annuo di circa 60 milioni di lire e circa il doppio per un senior. È chiaro inoltre che sarebbe meglio fare un istogramma dei costi per ogni clas-se di lavoratori, per poter tener conto delle differenze di costo settimanale ⇒ si avrebbe una stima molto più accurata. A questi costi diretti va poi aggiunto l’overhead, o costo indiretto, che è dato dalla somma di una miriade di cose fra cui l’affitto dello stabile, la luce, le at-trezzature, le tasse, il mobilio, …. L'overhead ha un'incidenza molto diversa in dipendenza dalla grandezza dell'a-zienda: per aziende piccole esso è pari a circa il 20% del costo diretto (stipen-di), per aziende medio-grandi è circa del 40÷50%, ma per aziende molto grandi può arrivare anche al 120% (in questo caso si hanno enormi spese per la pubbli-cità, la rappresentanza, il fatto che si voglia avere una buona immagine quindi ci si stabilisca in un palazzo storico, …). Se ad esempio ricalcoliamo gli stipendi per un’azienda medio-grande, tenendo conto dell’overhead, si ha: junior 60 + 50% = 90 milioni/anno senior 120 + 50% = 180 milioni/anno per un’azienda grande invece si ha



junior 60 + 120% = 132 milioni/anno senior 120 + 120% = 264 milioni/anno si può facilmente notare la maggior incidenza dell’overhead in un’azienda grande rispetto a quella più piccola.

4. stima della criticità del progetto un progetto è poco critico se piccole modifiche non modificano la stima finale, è molto critico se la stima finale è invece totalmente diversa. Si usa il CPM (Critical Part Method). Il primo passo è quello di costruire il dia-gramma delle attività, cioè un grafo orientato i cui nodi sono gli eventi e i cui rami sono le attività. Bisogna che siano rispettati alcuni vincoli topologici:

• deve esistere un solo evento iniziale • deve esistere un solo evento finale • non vi devono essere cicli all’interno del grafo • non vi devono essere parallelismi, cioè non è ammesso che due nodi siano

collegati da più di un ramo Vediamo, dato un grafo che non rispetta i vincoli topologici, come si fa a renderlo conforme alle regole.

1

2

4

3

5

6

x v

y

z z’

w

In questo grafo esistono i seguenti problemi:

a. ho due eventi iniziali (1 e 2) b. ho due eventi finali (5 e 6) c. vi è parallelismo (i nodi 3 e 4 sono collegati sia dal ramo z che da z’).

Vediamo ora come risolverli: a. metto un ramo fittizio α che collega 1 e 2 b. metto un ramo fittizio β che collega 5 e 6 c. inserisco in uno dei due rami, ad esempio z’, un nodo fittizio 3’



1

2

4

3

5

6

x v

y

z z’

w

3’

γ

α β

Ho risolto tutti i problemi e ora il grafo rispetta i vincoli topologici. Provo ora a fare il grafo corrispondente al mio caso di studio

0

5’’

5’

2 6

3 8

7 4 1

[0,0]

A(3)

B(5) F(4)

C(3)

x(1)

è un ritardo D(5) G(3)

E(4)

α(0)

β(0)

γ(0)

δ(0)

[3,3] [8,8]

[12,12]

[12,12]

[9,12]

[4,7]

[6,8] [10,12]

[9,12]

Le attività D e G, che sono indipendenti una dall’altra, finiscono insieme, ma ciò dipende dalle mie stime ⇒ non le faccio finire nello stesso nodo perché perde-rei di generalità. α, β, γ e δ sono attività fittizie che mi servono per avere un unico evento inizia-le. Per ogni nodo devo determinare il tempo minimo e massimo di inizio: il tempo minimo di un evento è pari al massimo dei tempi corrispondenti ai suoi rami en-tranti, cioè è quello necessario a completare tutte le attività che vi convergono



(N.B. devo sommare tutti i tempi precedenti, cioè quelli dei rami che percorro a ritroso per andare da lì all’evento iniziale). I tempi minimi e massimi degli eventi iniziale e finale coincidono. Il tempo massimo di un nodo è pari al minimo fra i tempi calcolati sui rami u-scenti. Esistono alcuni rami per i quali tempo minimo e massimo coincidono: c’è sempre almeno un percorso critico, che è quello che collega i nodi con tempo minimo u-guale al tempo massimo. (colorato in rosso in figura) L’attività E può iniziare in un qualunque tempo compreso fra [6,8] e può termi-nare in un qualunque istante compreso fra [10,12]; è un’attività flessibile, le cui eventuali oscillazioni non influiscono sulla stima finale (ovviamente solo in ter-mini di tempo, perché se decido di farla cominciare all’istante 6 e farla termi-nare all’istante 12 non cambia niente riguardo il tempo di rilascio del software, ma ovviamente cambiano i costi perché impiego più tempo di quello previsto in precedenza). L’attività B invece deve necessariamente iniziare all’istante 3 e finire all’istante 8, quindi è un’attività critica: qualunque modifica sulle attività critiche impatta sul tempo di rilascio del software. Se ho modifiche riguardanti le attività critiche devo per forza rifare tutte le stime sui tempi e sui costi.

Raccolta delle specifiche di progetto

Raccolta delle specifiche

specifiche

SRS (Software Requi-rement Specification)

metodologia

esperienza

Quali sono gli strumenti che abbiamo a disposizione per questa fase? In generale vi sono 3 tipologie di strumenti:

1. strumenti informali. Aiutano a raccogliere e ordinare l’informazione senza però tradurla in un linguaggio di cui siano state date le regole grammaticali. Lo stru-mento informale per antonomasia è la lingua naturale (italiano). Chi legge il do-cumento ci mette un po’ del suo ⇒ l’interpretazione del documento varia da per-sona a persona.

2. strumenti semiformali. Qualunque tipo di strumento che sia parzialmente for-malizzato, ma che contenga al suo interno anche parti informali.

3. strumenti formali. Esistono regole rigorose per la raccolta delle specifiche e la stesura del documento.



Se prendiamo le varie fasi del ciclo di sviluppo del software è fuori discussione che il grado di completezza delle informazioni che abbiamo nella prima fase è ben poca cosa rispetto a ciò che abbiamo alla fine. È praticamente impossibile usare strumenti for-mali nelle prime fasi perché non si hanno ancora le idee ben chiare. Arrivare in fondo con strumenti ancora informali è però un peccato, perché si rischia di perdere parte della conoscenza che si è acquisita) ⇒ all’inizio uso strumenti informali, poi semifor-mali e infine formali. SRS → informale UML → semiformale MDT→ quasi formale RDP → formale Esiste una guida ANSI/IEEE per fare gli SRS Un documento SRS è un documento che deve dire cose certe e le deve dire in modo certo. Tutto quello che abbiamo ricevuto come informazione parzialmente certa non può allora farne parte. Non devono essere presenti ambiguità. L’SRS deve dare tutti i requirements, nulla di più, cioè tutti i requisiti che abbiamo raccolto devono essere in-seriti nell’SRS; se però saltano fuori ulteriori specifiche (come deve essere gestita la manutenzione, o cose del genere, che non sono propriamente requisiti), ciò non deve essere messo nell’SRS. L’SRS deve avere certe caratteristiche che sono:

• non ambiguo. Ogni informazione ha una sola interpretazione, indipendentemente da chi legge. Ciò si può ottenere, ad esempio, usando dei termini unici per indi-care sempre la stessa cosa, oppure definendo un glossario, cioè l’elenco della terminologia usata su cui potrebbe sorgere ambiguità, specificando anche i termini che sono sinonimi. Ad esempio la frase “L’insieme dei dati deve contenere un carattere di EOF” ha almeno tre possibili interpretazioni:

1. esiste un unico EOF 2. occorre scegliere un carattere da usare come EOF 3. esiste almeno un carattere di EOF

anche la seguente frase si presta ad ambiguità: “Il totale di controllo deve essere preso dall’ultimo record”

1. il totale è preso dal record che si trova prima di EOF 2. il totale è preso dall’ultimo record utilizzato, ad esempio dall’ultimo re-

cord della precedente query 3. il totale è preso dall’ultimo record inserito a livello temporale

• completo. È completo se soddisfa le seguenti qualità: 1. include ogni informazione utile 2. definisce le risposte ad una qualunque configurazione di input 3. rispetta completamente lo standard



4. spiega e cita tutte le figure, tabelle, ecc … 5. fa uso moderato di TBD (To Be Defined). In ogni caso quando si fa uso di

TBD, bisogna spiegarne il motivo. • verificabile. L’SRS è verificabile se lo è ogni informazione in esso contenuta,

cioè se è possibile trovare nel software la risposte ad ogni requisito. Se non esiste la possibilità di verificare un frase dell’SRS ⇒ bisogna modificarla o toglierla

• coerente. L’SRS è coerente se non contiene informazioni in conflitto fra lo-ro. Esistono tre tipi fondamentali di conflitto:

uso di termini diversi per indicare lo stesso concetto attributi conflittuali di un concetto conflitto logico o temporale fra azioni

• tracciabile. Vi sono due tipi di tracciabilità: all’indietro e all’avanti. Tracciabilità all’indietro significa che se in una certa pagina c’è una certa in-formazione, devo sapere esattamente da dove viene (documento precedente, intervista, ecc …) quest’informazione. Tracciabilità in avanti significa invece mantenere il legame fra le specifiche ed il progetto di massima, il progetto in dettaglio e infine la codifica.

• usabile sempre. Poter leggere e consultare l’SRS è molto utile nella fase opera-tiva e di manutenzione del software. Mi serve anche se devo fare un software analogo in futuro.

• ottenuto per sviluppo congiunto. L’SRS è un documento su cui vanno a finire gli sforzi sia del cliente che del fornitore. Deve esistere una collaborazione fra queste due figure, ciò mi serve anche per la validazione da parte del cliente.

Strumenti di supporto alla produzione dell’SRS Si usa un normale word processor, non esistono pacchetti software adatti

Come si fa a specificare un requisito? Ci sono sostanzialmente tre modi per la specifica di un requisito:

1. INPUT/OUTPUT. Certi requisiti si spiegano nel seguente modo: quando ho que-sto IN ⇒ vorrei questo OUT. In qualche caso è sufficiente spiegare l’OUT, perché l’IN è implicito. A volte occorre mappare l’IN sull’OUT (a fronte di un certo IN che OUT mi aspetto). Vi sono poi casi in cui l’OUT deve avere memoria degli IN precedenti e non solo dell’ultimo.

2. Esempi rappresentativi. Se devo fare la gestione di indirizzi, do al fornitore un elenco di indirizzi in modo da coprire tutti i casi che si possono presentare.

3. Modelli. Fornisco modelli, ad esempio formule, modelli matematici o funzionali che facciano vedere la corrispondenza fra In e OUT.

N.B. i tre modi non sono esclusivi, semplicemente certe cose si spiegano meglio col primo metodo, altre col secondo e altre ancora col terzo.



Annotazioni Occorre dare una misura dell’importanza, della stabilità e della necessità di ogni in-formazione, perché questo incide grandemente sul costo del software.

Forma dell’SRS 1) Introduzione

1.1) Scopo. Si delinea lo scopo del documento, dicendo a chi è rivolto. 1.2) Campo di validità. Questo documento si occupa di certi aspetti e non si occu-

pa di altri. Devo dire quali sono quelli di cui si occupa e quelli che invece trascu-ra.

1.3) Definizioni, abbreviazioni. Introduco le definizioni principali e gli acronimi. 1.4) Referenze. La lista dei documenti su cui questo si basa. 1.5) Sommario. Sono indicati i capitoli che seguiranno, perché ci sono, di cosa

parlano. 2) Descrizione generale

2.1) Prospettive. Indico le prospettive di utilizzo future rispetto ad altri compo-nenti software.

2.2) Funzioni. Dichiaro in generale cosa ci si aspetta dal programma. Descrivo per sommi capi le principali funzioni che ci si aspetta dal prodotto.

2.3) Utenti. Quali sono le tipologie di utenti che utilizzeranno io software. 2.4) Vincoli generali. Vincoli sull’hardware, sull’interfaccia, sul linguaggio di pro-

grammazione, ecc … 2.5) Assunzioni e dipendenze. Devo elencare ciascuno dei fattori che influenzano

i requirements. 3) I requisiti del software

3.1) Requisiti funzionali 3.1.1) Requisito N° 1

3.1.1.1) Introduzione. Di cosa si tratta. 3.1.1.2) Inputs. Che IN richiede 3.1.1.3) Processing. Che elaborazioni svolge 3.1.1.4) Outputs. Che OUT produce

3.1.2) Requisito N° 2 … 3.2) Requisiti per interfacce esterne. Sistema operativo, hardware, … 3.3) Requisiti prestazionali. Quali sono i tempi di risposta, quale deve essere

l’occupazione di memoria, … 3.4) Vincoli di progetto 3.5) Attributi

3.5.1) Sicurezza 3.5.2) Mantenibilità

3.6) Altri requisiti



Paradigmi del software

Gestionale Ogni evento deve essere registrato e ci deve essere qualcuno che tiene d’occhio la re-altà e modifica il DB per mantenere la coerenza fra realtà e sua immagine. Esistono molteplici problemi collegati alla realizzazione e al mantenimento del DB. L’unica maniera per garantire un controllo sull’aggiornamento è rivestire l’immagine con del software che gestisca le operazioni di inserimento, modifica, cancellazione, con-trollo. Un’altra parte molto importante è il software che gestisce le interrogazioni alla base di dati. Perché facciamo un’immagine della realtà? Perché è più facilmente interrogabile (se voglio sapere la giacenza del magazzino non vado a contare tutti i pezzi, ma lo chiedo al DB). Il modello che meglio si adatta al software gestionale è l’UML.

software query

software

realtà immagine della realtà (database)

operatore

progettista

operatore



Real-time

realtà software real

time

attuatore

sensore

operatore

comandi

immagine della realtà

Ci interessa la gestione degli aspetti dinamici della realtà. La realtà deve essere con-tinuamente monitorata ⇒ inserisco dei sensori che rilevano lo stato della realtà a tempi prefissati. In base ai segnali d’ingresso il software real-time fa un’immagine della realtà (N.B. molto meno complessa rispetto a quella di un software gestionale). Il software riceve anche dei comandi da parte di operatori. In base a tutte queste cose decide sul da farsi nel mondo reale. Come fa? Invia dei comandi nel mondo reale per mezzo di attuatori. Il software real-time è un software che entra a far parte della realtà, riesce a modificarla facendo muovere gli attuatori.



Work flow management

R1

R5

R7 R6

R3

R4

R2 WMFS

procedure

operatore

richiesta

risposta

È la versione moderna di ciò che una volta era chiamata automazione d’ufficio. La real-tà è fatta di tante risorse (= entità, di qualunque natura, capace di svolgere un lavoro). Queste risorse hanno la caratteristica di concorrere al raggiungimento di un obiettivo comune. Il WFMS (Work Flow Management System) affida la pratica alla risorsa che è in gra-do di gestirla. Quando la risorsa ha finiti, lo dice al WFMS, che controlla che sia tutto a posto e poi trasferisce il controllo alla risorsa successiva, e così via.



Approccio object oriented L’approccio ad oggetti è nato per rinnovare in maniera profonda la metodologia dell’ingegneria del software. L’approccio precedente era di tipo funzionale (struttura-to). All’approccio strutturato non interessano molto i dati, interessa di più rispondere ai requisiti funzionali. Scompongo il problema il tanti sottoproblemi con una rigida struttura gerarchica

P1 ... P2 Pn

P

La progettazione avveniva ad esempio per HIPO (Hierarchic Input Process Output)

I P O Cosa ho in input Cosa ci devo fare Cosa ho in output

I dati erano una specie di corollario di ciò che il software doveva fare. Ci si è accorti che almeno per il paradigma gestionale questo non era l’approccio giusto. I tipi di dati non sono secondari, ma sono importantissimi. Prima definisco i dati e poi definisco le funzioni per gestirli. È un modo, fra l’altro, che rende abbastanza indipen-denti i vari moduli. Un oggetto è composto dai dati e dalle funzioni che servono per gestirli. Il software è lo strumento che deve rendere invisibili i dati all’esterno (information hiding): se ne deve occupare lui dell’interazione coi dati. Facciamo ad esempio un modello ad oggetti per rappresentare l’università. Con un’operazione di astrazione definisco l’oggetto AULA: tutte le aule sono diverse fra loro, ma ci sono aspetti che le accomunano (nome, numero di sedie, lavagna, attac-capanni, …) La classificazione è un’operazione di carattere economico, cioè siamo noi che, in base ai nostri requisiti, decidiamo tutto.



Luogo Nome Tipo

Insersci

Aula

Sedie

Insersci

Ufficio

N° telefonico

Insersci

Aula grande

N°microfoni

Insersci

Aula Nome Sedie ...

Studente Nome ...

Insersci Cancella Modifica

Insersci Cancella Modifica Cerca Calcola ossigeno ...

Potenzialità offerte da un approccio object oriented 1. classificazione 2. specializzazione / generalizzazione 3. incapsulamento (information hiding). L’approccio OO garantisce l’incapsulamento

dei dati da parte del software. L’unico modo per accedere ad un oggetto è at-traverso la sua interfaccia

4. polimorfismo. Posso dare lo stesso nome alla funzione inserisci delle aule e a quella degli studenti. In generale ho un operatore e n metodi per realizzarlo.

5. overriding (sovrascrittura). In una sottoclasse ho una funzione con lo stesso nome di quella della superclasse, ma la implemento in modo totalmente diverso per tener conto delle necessità derivanti dalla diversità fra classe e sottoclas-se.



Modello UML per l’analisi e il disegno di un’applicazione software UML = Unified Modeling Language UML nasce dalla collaborazione di molte persone ed è uno standard de facto. Esso è composto da varie parti fra cui:

Use cases Servono per esprimere le idee non appena raccolti i requisiti. Hanno il pregio di comin-ciare a raccogliere le idee prima di cominciare a fare un’analisi vera e propria. Cominciamo col definire cosa è uno scenario (operativo). È la rappresentazione di una delle sessioni di lavoro che l’utente dovrà svolgere col software. Ha un inizio ed una fine ben determinati. Uno use case è un complesso di funzioni elementari che servono per rispondere in ma-niera compiuta ad un bisogno dell’utente, esaminando tutte le possibilità. In pratica è l’insieme di tutte le possibili situazioni. È una risposta debole all’idea di coesione: tutto ciò che avviene all’interno di uno use case è in correlazione con le altre cose che fanno parte di quello use case. Uno use case è rappresentato da un ovale con indicato il suo nome all’interno.

NOME

L’UCD (Use Case Diagram) prevede la primitiva use case e la primitiva utente, rappre-sentata da un omino con indicata sotto la sua funzione.

nome Se ad esempio voglio modellare la realtà di una banca un possibile use case è “cambio assegno”, che potrebbe essere rappresentato come segue.

cambio assegno

cassiere L’UCD è molto grossolano: intanto fisso le idee e decido di cosa devo parlare. Ci può essere una qualche relazione fra use case, se ad esempio lo use case “cambio assegno” fa uso dello use case “stato del conto corrente”. La rappresentazione grafica è la se-guente



cambio assegno

stato del conto

corrente gestione prestito

“include” “include”

cassiere

responsabile prestito

L’UCD deve avere, nella sua fase iniziale, da 10 a 30 use cases. Al posto di “include” si può trovare anche “use”. Certi use case possono non avere u-tenti che li usano. Un’altra relazione che si può esprimere fra use cases è quella di specializzazione/generalizzazione.

gestione prestito agricolo

valorizza-zione

proprietà

gestione prestito

“include”

respon-sabile prestito

direttore

Non c’è ordine temporale o logico. C’è bisogno di fissare le prime idee. Il diagramma fa capire intuitivamente di quali “pezzi” di software c’è bisogno. Disegnare use cases è il primo modo per mettere in ordine le idee e per mettere d’accordo le persone dello staff. C’è un’ulteriore relazione fra use cases: estensione. Supponiamo che ci sia uno use case “acquista prodotto” e uno “cliente regolare”. Per mostrare che lo use case “cliente regolare” estende i metodi “pagamento” e “spedizio-ne” e che lo use case “rapporti banca” estende (ridefinisce) il metodo “garanzia” dello use case “acquisto prodotto” si usa la seguente simbologia:

cliente regolare

rapporti banca acquisto prodotto

extension points:

-pagamento -spedizione -garanzia

“extend” (pagamento, spedizione)

“extend” (garanzia)



La relazione di estensione è un modo per spiegare meglio le relazioni di specializzazio-ne/generalizzazione. Quindi faccio uso della primitiva “include” quando uno use case utilizza un altro use ca-se e Vi è un utilizzo da più parti. Faccio uso della primitiva di generalizzazione/specializzazione per distinguere un comportamento generale da uno particolare. Infine faccio uso della primitiva “extend” per specializzare un comportamento particolare rispetto al comportamento base. Un diagramma che non fa direttamente parte di UML, ma è implicito, è il diagramma degli utenti (attori).

actor

utente supporto tecnico

interno esterno amministratore del sistema

sviluppatore

tecnico politico In un diagramma degli use cases gli attori non sono solo persone, ma anche altri use case, altri software. Il modello UML dice di mettere l’omino anche se l’utente non è una persona, noi invece decidiamo di indicare questo utente particolare con un rettan-golo con il nome all’interno. Ad esempio

politico

definizione procedura

modifica procedura

esegui procedura

“include” “actor” DBMS

“actor” motore di

calcolo



Diagramma delle classi Il progettista comincia a tratteggiare le classi che è necessario progettare per co-struire uno use case. Una classe è rappresentata da un rettangolo diviso in tre parti: in quella superiore si indica il nome della classe, in quella centrale c’è l’elenco degli attributi e in quella sot-tostante l’elenco degli operatori (metodi).

conto corrente

identificativo filiale fido apri stampa saldo prelievo deposito

Vi è una primitiva di associazione, che si indica con una linea fra le due classi coinvolte. Sopra la linea si scrive il nome dell’associazione. A fianco delle classi si può indicare quante volte partecipano all’associazione. In figura si ha che una persona può avere da 0 a n conti correnti e che un conto corrente ha uno ed un solo proprietario.

conto corrente

identificativo filiale fido

apri stampa saldo prelievo deposito

persona nome cognome data di nascita

inserisci modifica ...

* titolarità 1 proprietario

In pratica significa che c’è un collegamento fra le istanze della classe “conto corren-te” e le istanze della classe “persona”. Il nome dell’associazione, così come i ruoli delle classi e la molteplicità sono tutti a-spetti facoltativi. Un’altra primitiva è quella di navigabilità, o associazione direzionale: mi serve per spe-cificare il tipo di associazione (unidirezionale, bidirezionale).

casa città



In questo caso la classe “casa” vede la classe “città” ma quest’ultima non vede “casa”. Gli attributi di una classe possono essere specificati fornendo il nome dell’attributo, il suo tipo ed un eventuale valore di default. Ad esempio a:A=10,7; iva:integer=20 Non è obbligatorio essere così precisi, si possono anche omettere tipo di dato e de-fault. Posso poi indicare la visibilità di ogni attributo. Si hanno tre possibilità:

1. pubblico (indicato con un segno “+” davanti al nome dell’attributo) 2. privato (indicato con un segno “-” davanti al nome dell’attributo) 3. protetto (indicato con un segno “#” davanti al nome dell’attributo)

pubblico = invocabile anche da altri oggetti protetto = lo possono chiamare solo gli altri attributi e metodi della stessa classe e le loro specializzazioni (quelli delle sottoclassi) privato = nessuno è autorizzato ad invocare questo attributo o metodo, se non gli operatori o attributi della stessa classe.

Come posso esprimere dei vincoli? Essi non possono essere messi nello schema, se non come commenti fra parentesi graffe. Il commento può essere scritto in italiano corrente o in linguaggio matematico. Se ad esempio devo avere che lo stipendio sia maggiore o uguale ad una certa funzione dell’età, posso scrivere:

persona

età stipendio

{stipendio > f(età)}

Diagramma degli oggetti È uno degli aspetti avanzati del modello UML Il diagramma degli oggetti è una rappresentazione schematica dei rapporti esistenti fra le istanze delle varie classi. Per distinguere una classe da un’istanza, si sottolinea il nome di quest’ultima. Dato il seguente schema delle classi

persona

nome

casa

codice proprietà

un possibile schema degli oggetti è



persona

nome= Carlo

casa

codice= 00151

persona

nome= Arturo

persona

nome= Luigi

casa

codice= 01401

Lo schema degli oggetti mi serve per fare vedere quali sono le possibili relazioni fra le classi. Se in una classe trovo un attributo sottolineato, significa che non è relativo alla singo-la istanza, ma alla classe in generale. Un esempio potrebbe essere l’attributo “età me-dia” nella classe “persona”. Per la singola istanza non ha senso considerarlo, ma ha sen-so per l’intera classe. Un altro esempio è l’attributo “cardinalità” in una qualunque classe: indica quante istanze ha la classe stessa. Questi sono in pratica attributi di sintesi.

persona

... età media cardinalità

{età media = somma dell’età per tutte le istanze / cardinalità}

{età = differenza fra adesso e data di nascita}



Vi sono diversi tipi di relazione: Specializzazione

persona sesso ...

maschio ...

femmina ...

pensionato ...

lavoratore ...

studente ...

disoccupato ...

scuola ...

sesso {completa}

{dinamica}

Se metto un attributo vicino al simbolo di ramificazione indica che quello è l’attributo discriminante. {completa} indica che le istanze delle sottoclassi sono tutte e sole le i-stanze della superclasse. {dinamica} indica che la specializzazione può variare nel tem-po. Aggregazione (part of) Si indica con un rombo dalla parte dell’oggetto composto e con una freccia dalla parte dell’oggetto componente.

libro

gadget

0..2

Indica che il gadget è parte integrante del libro: non ha senso considerarlo a parte, il gadget è un componente del libro. Ad ogni libro possono essere associati da 0 a 2 ga-dgets. In cosa differiscono una aggregazione da un’associazione? L’unico motivo riguarda un ragionamento sull’identità degli oggetti coinvolti. Se prendo la seguente aggregazione



auto

motore

È chiaro che “auto” ha una sua propria identità, indipendente dagli attributi: posso cambiare colore, targa, motore, che quella resta sempre la stessa auto. Il motore in-vece ha senso solo all’interno dell’auto. Quando registro i dati nel mio DB ho una cosa del genere:

auto

motore

A1

M2

M1 M A

Ho tante istanze di auto e tante istanze di motore e una tabella che mantiene la rela-zione fra auto e motore. Se per un qualche motivo interrompo il legame, ne devo crea-re un altro: se tolgo M1 ad esempio, perché si è rotto, allora devo sostituirlo con M2. Se invece modello nel DB le persone e le case ho qualcosa del genere:

persona

casa

P1 C1

C P



Se cancello il legame fra P1 e C1 semplicemente basta che tolga la riga corrispondente nella tabella: le entità persona e casa hanno senso anche considerate a se stanti. L’identità di un’associazione è indipendente dalle identità di chi vi partecipa, mentre l’identità di un’aggregazione dipende dalle identità dei suoi componenti. Esiste poi una variante dell’aggregazione: la composizione, il cui simbolo è il seguente:

auto

motore

Si ha aggregazione se l’entità componente può essere componente di più entità compo-ste, mentre si ha composizione se l’entità componente può far parte solo di quell’entità composta; quindi “auto”-“motore” è una composizione.

Attributi derivati Per indicare che un attributo è derivato, cioè che è calcolabile a partire da altri attri-buti o metodi, si mette una barra (/) davanti al nome.

persona

nome cognome /età

Classi astratte Mi servono quando voglio rappresentare certi aspetti comuni di alcuni oggetti che non ho ancora ben definito, ad esempio l’interfaccia. Per indicare che una classe è astratta si mette {abstract} dopo il nome.

C2{abstract}

C2.1

C2.2

C2.3

C1



So come è fatta C1, non so niente su come sia fatta C2, ma devo poter almeno specifi-care la sua interfaccia. In seguito creerò poi solo le classi C2.1, C2.2 e C2.3 e non C2. Se vicino ad un’associazione compare la parola {ordered}, significa che non associo più un semplice set (=insieme) di istanze, ma una list (=insieme ordinato) di istanze. A volte si fa confusione fra classificazione e specializzazione, questo è dovuto al fat-to che si tende a leggere in entrambi i casi come “is-a”. se si applica is-a ad una sotto-classe ⇒ è una specializzazione; se si applica ad un’istanza è una classificazione.

Associazione qualificata Data l’associazione

ordine linea ordine

1 1..n

vorrei eliminare la molteplicità. Posso allora utilizzare un’associazione qualificata e lo schema diventa:

ordine linea ordine

prod.

Sono riuscita ad eliminare la molteplicità e adesso dico anche che per ogni prodotto ci può essere al più una linea d’ordine in ogni ordine.



Attributi di un’associazione Mi servono per caratterizzare l’associazione come classe a se stante

casa codice

superficie

notaio

proprietà data inizio data fine

persona nome cognome

proprietà 1..n 0..n

Sequence diagram Fanno parte di un pacchetto chiamato interaction diagrams. Sono diagrammi che mo-strano le interazioni fra gli oggetti, disposte secondo un certo ordine temporale. I se-quence diagrams (SD) sono a volte chiamati event trace diagrams (ETD). È utile per indicare quali sono gli oggetti di cui si parla. Ad ogni oggetto associo un as-se dei tempi verticale su cui vengono registrati gli eventi. Dato il seguente class diagram

order

order line

product

order entry

*

* 1

1 1..n

si prende una singola istanza per ogni classe e si disegna il SD.



order entry

order

product

order line

prepara()

ordinazione

prepara() ok:=check()

[ok] cala() poco:=scorta()

[poco] new

spedizione

messaggio

[ok] new

[not ok] new

Vediamo di dare una breve spiegazione del diagramma: quando si ha una order entry, l’oggetto order entry dice all’oggetto order di preparar-si. Quest’ultimo dice di prepararsi all’oggetto order line. Order line chiama il metodo check() dell’oggetto product per vedere se il prodotto richiesto è presente in magaz-zino nella quantità richiesta e si fa ritornare il risultato nella variabile ok. Se ok è true allora dice all’oggetto product di invocare il metodo cala() per calare la quantità del prodotto. Il metodo cala() invoca il metodo scorta() che verifica la quantità rima-nente, mettendo il risultato nella variabile poco. Se poco è true si ha la generazione di una nuova istanza dell’oggetto ordinazione. L’oggetto order line verifica poi che ok sia true e genera una nuova istanza dell’oggetto spedizione; se ok è false genera invece una nuova istanza di messaggio. La linea sottile non è proprio un asse dei tempi, nel senso che non ci interessano in re-altà i valori in assoluto ma ci interessano le relazioni prima-dopo. Ci interessa sapere la sequenza in cui avvengono gli eventi. Le istanze degli oggetti servono per modellare il dialogo, le barre verticali sottili rappresentano il fluire del tempo, quelle più spesse rappresentano la durata dei processi. Le frecce orizzontali rappresentano scambi di



messaggi fra gli oggetti. Sulle frecce ci va il nome o il significato del messaggio. Se davanti al messaggio c’è qualcosa fra parentesi quadre significa che è una condizione; un asterisco indica che il messaggio viene mandato più volte. “new” indica la generazio-ne di una nuova istanza di oggetto. La freccia che parte da un oggetto e vi ritorna si-gnifica che l’oggetto sta invocando un suo metodo. Una freccia tratteggiata con scrit-to sopra “return” indica la fine di un processo. La distruzione di un oggetto si indica con una croce sull’asse dei tempi di quell’oggetto.

oggetto

Se voglio indicare la contemporaneità fra due eventi posso usare questa rappresenta-zione:

spedizione

messaggio

[ok] new

[not ok] new

Activity diagram È una specie si sconfinamento di UML in settori che non sono suoi propri, ad esempio work flow management. Gli AD descrivono delle cose da fare, in particolare quando queste cose presentano casi di parallelismo. Un cerchietto tutto pieno indica il punto di partenza del diagramma e un cerchietto con un pallino il punto di uscita. Con gli ovali si indicano le attività. I seguenti simboli significano poi:



N.B. prima del punto finale devono essere chiuse tutte le biforcazioni e le alternative.



L’AD dice cosa deve essere fatto, ma non dice chi lo debba fare. La proposta che completa l’AD è quella di definire delle corsie che specificano chi si deve incaricare di ogni cosa

È uno strumento facoltativo, non è detto che sia sempre utile. Una variante di un AD è rappresentare l’attività in termini macroscopici e solo succes-sivamente esplodere il concetto.



Diagrammi di stato (state charts) È lo strumento per rappresentare gli aspetti dinamici degli oggetti. Se prendo l’oggetto auto posso cercare di figurarmi una serie di stati in cui esso si trova.

auto ordinata e/o in fabbrica in viaggio dal concessionario immatricolata venduta

Sono situazioni emblematiche dal punto di vista del possesso dell’automobile. Se invece considerassi il funzionamento della macchina potrei avere i seguenti casi:

auto nuova rodata tagliando 1 tagliando 2 tagliando 3 revisionata demolita

Nel caso in cui ci serva modellare alcuni aspetti dinamici degli oggetti allora ci servono gli state charts. Un diagramma di stato è basato su alcune primitive fondamentali Uno stato si indica con un rettangoli coi bordi arrotondati al cui interno è indicato il nome

nome dello stato



Ad esempio per una persona posso avere

celibe / nubile sposato vedovo divorziato

Una transizione di stato si indica con una freccia che collega lo stato di partenza con quello di arrivo.

celibe / nubile

sposato

vedovo divorziato

C1

C2

C5 C4

C3

il diagramma degli stati ha in genere un punto di partenza che permette di stabilire qual è lo stato da cui attivarsi, non è invece detto che ci sia un punto di uscita. Se c’è esso è rappresentato da un cerchio con un pallino nero all’interno, mentre l’inizio è un pallino nero. N.B. in un certo istante può essere attivo uno ed un solo stato. Nel momento in cui si verifica la condizione per la transizione di stato, essa avviene subito, senza lasciare trascorrere del tempo. Se decido di etichettare una transizione posso esprimere tre componenti:

1. un evento (es C2 = sentenza del tribunale) 2. una condizione (età > 18) 3. un’azione (es. stampa modulo)

L’evento si indica semplicemente col nome, la condizione fra parentesi quadre e l’azione preceduta da una barra (/). Diamo ora un esempio di possibile diagramma di stato



celibe / nubile

sposato

vedovo divorziato

matrimonio [età >18] /fissa residenza

mor

te c

oniu

ge

mat

rimon

io

[tem

po =

3 a

nni]

separato

do/paga alimenti

sentenza / iscrizione albo

matrimonio

morte

coniu

ge

/ can

cella

zione

albo

Uno stato ha una denominazione e può comprendere delle azioni; esse vanno specifica-te all’interno dello stato (vedi separato). Vi sono tre possibilità per le azioni:

1. do/… l’azione è eseguita fintantoché si rimane nello stato 2. entry/… l’azione è eseguita quando si entra nello stato 3. exit/… l’azione è eseguita un istante prima di uscire dallo stato

Anche questi diagrammi possono essere sviluppati per strati (raffinamenti successivi)

check invio fatto

attesa cancella x

x

x x

Supponiamo che esista una condizione che riguarda tutti e tre gli stati. Posso allora rappresentare il tutto in maniera molto più semplice. Racchiudo tutti gli stati in un unico superstato a cui do un nome e lo collego con can-cella.



check invio fatto

attesa

cancella x

ok

Se uno stato che non va a cancella basta lasciarlo fuori dal superstato. È indispensabile che le condizioni di uscita da uno stato siano caratterizzati da predi-cati disgiunti. Se durante l’esecuzione di una certa transizione provoco il cambiamento di stato an-che in un altro diagramma lo devo indicare:

pericolante demolita

proprietario

Il rettangolo con gli spigoli indica l’altro diagramma di stato.

Package diagram Si usa solo quando il software è veramente grande. Si dice che fra due packages c’è dipendenza se c’è dipendenza almeno fra due classi dei packages.



P1

P4

P2

P3

Component diagram Ha a che fare con use cases e class diagrams. È la visione realizzativa del software che abbiamo realizzato.

gestione stipendio

gestione presenze

Nel passaggio da OMT a UML si sono persi i DFD (Data Flow Diagrams), noi li facciamo lo stesso anche se non fanno parte di UML.

Data flow diagrams È un diagramma col quale si spiegano gli aspetti funzionali del software. Una funzione, o processo, è un’attività che consuma dei dati in ingresso e produce dei dati in uscita.

processo P1

I1

O2

O1

I3

I2



Posso immaginare che il processo P sia scomponibile in sottoprocessi:

P1

I1

P2 P3

P4 I2

I3

O2

O1

d24

d12 d23

Il bilancio netto dei dati in ingresso e in uscita non deve variare. Posso poi esplodere anche P1 e P2, ma di solito bastano i livelli 0 e 1. Ho anche altre due primitive fondamentali oltre al processo: un agente esterno, rap-presentato con un rettangolo con dentro il nome e un deposito dati, rappresentato con due barre orizzontali con dentro il nome. In che modo si usano queste primitive? Facciamo un esempio.

utente

Dati A

Dati B

Dati A

P1 P2

utente

d12 richiesta x risposta

È preferibile duplicare i nomi anziché incrociare troppe linee. Vi sono alcuni vincoli topologici a cui attenersi:

• non è ammissibile alcuno scambio di dati fra agenti esterni



• non è ammissibile alcuno scambio di dati fra depositi dati • non è ammissibile alcuno scambio di dati fra agenti esterni e depositi dati • non è ammissibile alcuno scambio di dati fra depositi dati e agenti esterni

Non sono quindi possibili le seguenti configurazioni:

x y

x A

A A

Non è possibile mostrare le precedenze fra i processi. Non è nemmeno possibile mo-strare i passaggi di controllo fra i processi ⇒ introduco la primitiva di passaggio di controllo, indicata con una freccia tratteggiata.

P1 P2

P1 è eseguito prima di P2 e P1 attiva P2. Se si fa in modo che i nomi dei processi siano uguali ai nomi dei metodi degli oggetti riesco anche a rappresentare le dipendenze fra oggetti e metodi.



Problematiche di UML

Già il nome delle classi può essere interpretato male. Se al posto di A metto Pers, co-sa significa? Persona, persiana, persino, … ? E poi se legge un cinese, cosa capisce? Devo fare un glossario: Pers= … La parte grafica è formale, la parte scritta è totalmente informale perché è espressa a parole. La parte non formale è in generale molto maggiore rispetto a quella formale. La parte grafica lascia una fetta molto grossa alla parte non formale in prosa. UML preferisce catturare poca conoscenza, ma che venga capita da tutti.

grado di conoscenza

��

UML

multidata

SRS progettazione in dettaglio

Da UML al codice che noi scriviamo ci sono molti passaggi. Posso via via dettagliare gli schemi, ma non posso andare oltre, all’infinito. Posso mettere dei commenti, ma anche questi sono sempre scritti in prosa, quindi sono informali. Il simbolo per il commento è il seguente:

commento

Il modello multidata (MDT) prova a spostare più avanti la formalizzazione, cioè a ri-durre la parte non formalizzata.



Uno stereotipo è un concetto ben definito in maniera informale. Ad esempio il concet-to “include” è uno stereotipo perché ne ho una definizione in prosa. Se voglio rappre-sentare dati grafici, ne faccio uno stereotipo: “grafico”=

spiegazione a parole

Aggiungo conoscenza, ma è sempre di tipo informale. MDT mi serve per formalizzare meglio le cose.

MDT Il modello MDT afferma che non è vero che tutti gli oggetti siano uguali, quindi è me-glio dare loro nomi diversi. MDT distingue allora fra:

Value Object Context

L’object classifica le entità che popolano il mondo reale. Un object è l’insieme di una class e delle sue instances. Per dire che cosa è un value dovremmo pensare alla modellazione della classe persona.

Maria Ugo Giancarlo

classe:persone insieme dei nomi nome

Nome è una funzione che mappa ogni persona su un valore dell’insieme dei nomi. Cosa hanno in comune le due nuvolette? Entrambe sono insiemi. Le persone però hanno senso anche a sé mentre i nomi hanno senso solo se riferiti a persone

persone

professioni

0..100

professione

età

nome

nomi

Gli objects si indicano con ovali, mentre i values con cerchi.



Un valore è diverso da un oggetto. Se prendo un oggetto persona, questo ha una sua propria identità, l’essenza dell’individuo. Poi c’è lo stato, che è la somma dei valori degli attributi. L’identità è fissa, lo stato può cambiare istante per istante. Se non riesco a scindere identità e stato ⇒ è un value e non un object. Vediamo ora degli esempi al confine: prendiamo indirizzo Tipo: (via, p.zza, calle, …) Toponimo: (C. Battisti, Emilia, 25 Aprile, …) Civico: (1..1.000.000) CAP: (0..99.999) Comune: (Albinea, Bomporto, Cavezzo, …) Provincia: (MO, BO, RE, …) Prendo Via C. Battisti, 34 Modena, MO Se mi interessa il luogo di cui l’indirizzo esprime lo stato ⇒ è un object Se invece voglio un elenco di tutti i possibili indirizzi di Modena ⇒ è un value, diventa una cosa di servizio Prendiamo ora la rappresentazione di un territorio:

ramo di fiume

denominazione = string andamento = linea

linea

stringa

object →entità del mondo reale value → attributo di un object context → evento o situazione coinvolgente uno o più oggetti

Esiste una relazione fra persona e casa se lo stato di qualche persona cambia conte-stualmente allo stato di una casa. Esistono regolarità nei cambiamenti di stato di casa e persona.



Le relazioni esprimono i canali lungo i quali viaggia la dinamica del mondo reale. Un context è un legame fra oggetti che esprime le loro relazioni. Un context si rappresente con un ovale dal bordo doppio.

Un esempio di schema MDT è:

proprietà

persona

casa

string

integer

data

bene

proprietario

nome

età

n° catastale

integer

acquisto

real

valore €

g m a

Come si rapportano gli uni con gli altri i concetti di oggetto, valore, contesto? Vi sono tre possibilità:

1. classificazione 2. composizione 3. specializzazione

Si ha composizione quando un concetto è parte di un altro concetto. Value in value: un valore può essere parte di un altro valore, valori complessi sono ottenuti a partire da valori più semplici. Una data è composta da un giorno, un mese e un anno:

data

integer

genn, febb, mar.

1..31

giorno

mese

anno

Una spezzata è formata da una lista ordinata di segmenti, che a loro volta sono for-mati da due punti, ognuno dei quali consta di due coordinate:



spez-zata real punto seg-

mento L

inizio

fine

x

y

La fine del segmenti i-esimo coincide con l’inizio del segmento i+1-esimo Value in object: un oggetto è modellato attraverso un certo numero di attributi.

X

data

spez-zata

x1

x2

Tentiamo ora di modellare l’oggetto Automobile: object Auto Targa: string Cilindrata: integer Potenza: real Anno di immatricolazione: data Se ho dato una definizione esaustiva del value data, non ho più bisogno di dire niente giunti a questo punto: lo utilizzo e basta. Come posso modellare Targa come value?

Auto targa Targa

0..99.999

MO, RE, MI,

provincia

numero

targa= provincia cat numero Value in context: vi sono values che completano il contesto.

proprietà

Auto

data

UMC Persona string

bene

data registrazione nome venditore

proprietario regi

stro

Objeci in object:



riassume in sé il concetto di aggregazione o composizione, alcuni oggetti complessi so-no composti da oggetti più semplici.

Auto

Motore

targa Targa

Propulsore

colore

Colore

integer

diesel, benzina

integer

cilindrata

tipo n° cilindri

Osservazione: quando noi osserviamo il comportamento delle entità del mondo reale, percepiamo delle regolarità.

mondo reale

regolarità (percezione di ciò che è)

impostazione di ciò che deve essere

Object in context: vi è una compartecipazione fra oggetti, i loro stati si modificano simultaneamente.

compra-vendita

Bene

data

Persona real

merce

data valore

acquirente

venditore

Object in context corrisponde all’associazione di UML. Gli OID (Object IDentifier) di Persona e Bene forniscono l’OID di compravendita.



Context in context:

compra-vendita

Bene

Persona

merce

acquirente

venditore

registra-zione

cosa Società di registrazio

ne dove

controllo

cosa

Società di controllo

chi

L’identità di registrazione è legata alle identità di compravendita e di Società di regi-strazione. Si ha invece specializzazione quando introduco un concetto come raffinamento di un concetto preesistente. Vi sono tre tipi di specializzazione:

1. specializzazione di un value 2. specializzazione di un object 3. specializzazione di un context

Per un value, specializzazione significa definire un sottoinsieme del value che sto con-siderando.

Persona

Femmine Maschi

nome nome

maschili

femminili

nome La specializzazione di persona è esclusiva, mentre quella di nome non lo è (Andrea può essere sia femminile che maschile). Vediamo meglio come si indicano specializzazioni esclusive e non:



Persona

Femmina Maschio

lavoratore

tipo di sevizio militare

studente

serv

izio

m

ilita

re

integer n°

figli

ordinale

anno

tipo di impiego

impiego

tipo di scuola

dove

Si può anche avere specializzazione di context:

sposalizio

in municipio in chiesa

Persona

Femmina Maschio

data

nome

m, f

indirizzo

nome

data di nascita (d.d.n.)

sesso residenza

compra-vendita

associa-zione

sportiva

venditore

membro

Un concetto specializzato ha caratteristiche omogenee e caratteristiche diverse dal-l'oggetto da cui deriva. Il concetto specializzato eredita gli attributi e i comportamenti dell'oggetto da cui deriva (può partecipare agli stessi context). Differisce per il fatto che alcuni attributi sono ridotti (può mappare in un sottoinsie-me dei values).



Persona

Giovane Vecchio

data

data giovane

tipo di scuola

data di nascita (d.d.n.)

agonistica

associa-zione

sportiva

membro

scuola

d.d.n.

{1900..2000}

{1980..2000}

membro

Può inoltre avere attributi aggiunti rispetto al concetto da cui deriva. Alcuni comportamenti sono ridotti, altri aggiunti: posso anche avere

Giovane Gita partecipa

Leggi e class attributes Ogni dichiarazione MDT è espressa da un’intestazione (value Data, object Persona, context Compravendita). L’intestazione esprime il tipo di concetto che vogliamo modellare e il nome che gli vogliamo dare. Poi seguono le definizioni degli attributi del concetto: value Data G: 1..31 M:1..12 A: integer+

object Persona Nome, Cognome: string Ddn: Data Sex: (M,F) Residenza: string

context Compravendita Venditore, acquirente: Per-sona Merce: Bene Data: Data Valore: Soldi

value Soldi Valuta: (€, $, ¥) Cifra: real

object Auto M: Motore T: Telaio Costo: Soldi

Ci possono anche essere degli attributi di classe: essi si indicano sotto gli attributi normali preceduti dall’indicazione “Class Attributes”



context Compravendita Venditore, acquirente: persona Merce: Bene Data: Data Valore: Soldi Class Attributes: MaxValore: Soldi UltimaData: Data I class attributes si possono applicare a objects e contexts, ma non a values, per i quali non avrebbero senso. Possiamo poi avere delle leggi (Laws) in tutti e tre i concetti: dopo la parola chiave laws seguono tutte le leggi espresse sotto forma di predicati, cioè condizioni. value Data G: 1..31 M:1..12 A: integer+ Bisestile: boolean Laws: L1: M eq 4 ⇒ G le 30 // aprile ha al massimo 30 giorni L1’: M in (4, 6, 9, 11) ⇒ G le 30 (specifico meglio L1) // aprile, giugno, settembre e novembre hanno al massimo 30 giorni L2: M eq 2 ⇒ G le 29 // febbraio ha al massimo 29 giorni L3: bisestile ⇔ ((A mod 4) and not (A mod 100)) or (A mod 400) /* un anno è bisestile se è divisibile per 4 ma non per 100, oppure se è divisibile per 400 */ L4: not bisestile and M eq 2 ⇒ G le 28 // febbraio in un anno non bisestile ha al massimo 28 giorni object Persona Nome, Cognome: string ddn: Data Sex: (M,F) Residenza: string Maschio, Giovane, Sfortunato: boolean Class Attributes: PiùVecchio: Età Laws: L1: Maschio ⇔ Sex eq M



// si è maschi se e solo se Sex = M L2: Giovane ⇔ (ddn.A+20) le DataCorrente.A /* si è giovani se e solo se l’anno della data di nascita +20 è minore o uguale all’anno della data corrente */ L3: Sfortunato ⇔ ddn.Bisestile // si è sfortunati se e solo se si è nati in un anno bisestile L4: PiùVecchio eq max ((DataCorrente.A – P.ddn.A) for P in Instances) // l’età del più vecchio è la massima fra le età di tutte le istanze Glossario: eq = equal le = less or equal ge = greater or equal lt = less then gt = greater then mod = modulo (resto della divisione intera) not = negazione and = intersezione or = unione minus = sottrazione fra insiemi Consideriamo un oggetto X e gli attributi che lo caratterizzano. Ciascun attributo mappa in un dominio che indichiamo con D1, D2, D3, ….

X D1

D2

D3

a1

a2

a3

Gli stati che ogni istanza di X può assumere devono cadere in S(X) =D1×D2×D3×…, cioè all’interno dello spazio degli stati di X. Mettiamo che esistano solo due attributi, D1 e D2, allora S(X)=

D1

D2

x1

x2

Se ho tre attributi, allora S(X) è un parallelepipedo dentro il quale si colloca ogni i-stanza di X. Ogni istanza di X è rappresentabile come un punto nello spazio degli stati.



Di tutti i possibili valori di S(X), ce ne sono alcuni che sono valori legali, altri che sono illegali ⇒ non posso avere una qualunque combinazione dei valori degli attributi perché avrei uno stato non coerente. Nello spazio degli stati esiste una zona SL(X), che chiamiamo spazio degli stati legali di X. Se vogliamo modellare bene un oggetto X ⇒ dobbiamo definire molto bene gli spazi legali e non legali degli stati. In generale per fare questo mi serve un predicato, una condizione. ps→SL(X)

SL(X)

S(X)

L’istanza x può cambiare di stato, subire modifiche ai suoi attributi in modo da essere portata in un altro punto dello spazio degli stati. Devo garantire che gli stati per cui passo appartengano a SL(X). Vi è poi un altro problema: se x e x' sono due stati legali, tuttavia non è detto che la transizione che porta da x a x' sia anch’essa legale.

SL(X)

S(X) x

x’

Chiamo T(X) lo spazio di tutte le possibili transizioni: T(X)=SL(X)×SL(X) Se Età vale 6 e poi passa a 5 ⇒ questa non è una transizione legale, così come se Sex=M e poi passa ad F. Devo immaginare una condizione pt che mi isoli le transizioni legali: pt→TL(X). Perché tutto vada bene devono essere verificate contemporaneamente le condizioni ps e pt. devo modellare ps e pt per modellare bene le transizioni di stato. UML non è capa-ce di fare questa modellazione. Le leggi di MDT sono lo strumento per rappresentare ps e pt. object Persona … Laws: L1: Età lt 18 ⇒ ServizioMilitare eq NonAssolto L2: Sex eq M ⇒ not Attività in (sarta, levatrice) ps L3: … L4: old Età le Età L5: old StatoCivile eq sposato ⇒ StatoCivile in (sposato, divorziato, vedovo). pt Con old posto davanti ad un attributo si indica il valore di quell’attributo un istante prima dell’ultima transizione di stato.



a1 a2 a3 a4

a2 a3 a’1 a’4

x (old)

x’

Avviene una transizione di stato quando cambia il valore di almeno uno fra gli attributi dello stato. Posso migliorare L4 in questo modo: L4: old Età eq Età or Età eq old Età+1 Gran parte del software scritto serve per catturare la conoscenza riguardo gli stati e le loro caratteristiche. In una transizione di stato (x', <x,x'>) devo applicare ps a x' e pt a <x,x'>. Ho due possibili risulati: true ⇒ rispetto le regole fissate, allora il cambiamento di stato è accettabile; false ⇒ devo prevedere azioni di ripristino. L1: Età lt 18 ⇒ ServizioMilitare eq NonAssolto Questo è un frammento di ps. Potrei aggiungere un commento subito sotto: {ServizioMilitare:=NonAssolto; msg:=”Attenzione Età”} Le azioni di risposta agli errori sono messe sotto forma di commento. Un value deve quindi rispettare ps, un object e un context ps e pt: in realtà ciò non è ancora sufficiente.

compra-vendita

Bene

Persona

merce

acquirente

venditore

Data

Soldi

data

valore

Se do ps e pt per Compravendita ⇒ ok per Compravendita, ma questo potrebbe essere in conflitto con lo stato del compratore o del venditore o della merce. SL(X)= spazio degli stati legali per Compravendita SL(A)= spazio degli stati legali per Persona coma venditore SL(B)= spazio degli stati legali per Persona come Acquirente SL(C)= spazio degli stati legali per Bene X ha associato non solo lo stato SL(X), ma uno spazio esteso Σ(X) = SL(X)×SL(A)×SL(B)×SL(C) Ho tutte le possibili combinazioni degli stati legali di Compravendita con gli stati legali di Persona e di Bene. … L27: alla data della compravendita, l’età della persona che vende deve essere almeno di 18 anni.



C’è un problema di legalità dello stato di un oggetto inteso come stato esteso, cioè lo stato dell’oggetto stesso e degli stati degli oggetti che sono in relazione con l’oggetto stesso. Chiamiamo πs questo predicato e πt il corrispondente predicato per le transizioni. Avrò anche lo spazio delle transizioni esteso: θ(X)=TL(X)×TL(A)×TL(B)×TL(C) Spieghiamo meglio πs e πt:

X

C

B

A

Quali sono le informazioni da rappresentare?

1. leggi sulla legalità degli stati di X(ps) 2. leggi sulla legalità delle transizioni di X(pt) 3. leggi sulla compatibilità fra stato e transizioni di X e stato di A 4. leggi sulla compatibilità fra stato e transizioni di X e stato di B 5. leggi sulla compatibilità fra stato e transizioni di X e stato di C 6. leggi sulla compatibilità fra X e (A con B) 7. leggi sulla compatibilità fra X e (A con C) 8. leggi sulla compatibilità fra X e (B con C) 9. leggi sulla compatibilità fra X e (A con B con C) 10. leggi sulla compatibilità fra A e B 11. leggi sulla compatibilità fra A e C 12. leggi sulla compatibilità fra B e C 13. leggi sulla compatibilità fra A e B e C 14. leggi restrittive su A 15. leggi restrittive su B 16. leggi restrittive su C

Dove devo rappresentare queste informazioni?



A

C

B

H

G

F

E

D

L

K

J

I

Guardiamo ad esempio dove si rappresentano le leggi su C: in A devo rappresentare le leggi su C dipendenti dal contesto di A, in C rappresento le leggi di C indipendenti dal contesto.

A

W P

H L

G

C

C può essere componente di concetti più complessi. Dentro C spiego la conoscenza context-free. Dentro ad A scrivo le leggi su C dipendenti da A. dentro P scrivo le leggi su C dipendenti da P e così per W, G ed H. Mettiamo che ci sia il concetto di persona: tutto ciò che è vero sempre lo metto den-tro persona. Tutto ciò che fanno le sole persone che partecipano a compravendita, lo metto in com-pravendita. Tutto ciò che fanno le sole persone che partecipano ad attività sportiva, lo metto in attività sportiva. La conoscenza sulle persone è l’insieme di tutte queste conoscenze. Questo serve per la riusabilità. Gli oggetti vedono i loro componenti, i componenti devono essere ignari degli oggetti che li usano. Prendiamo il concetto di persona e il concetto di casa. Sappiamo che esistono varie re-lazioni fra persona e casa. Come faccio a rappresentare tutto ciò?



P

C

problema:

P

C

soluzione 1

Persona è un concetto che porta in sé la conoscenza di casa ⇒ se voglio riutilizzare persona, devo riusare anche casa.

P C

soluzione 2

Un concetto è componente dell’altro e viceversa. Ho una situazione pessima: i due con-cetti sono interdipendenti ⇒ non riusabili.

P C

soluzione 3

X

Creo un contesto X in cui P e C collaborano. Se esiste un’altra collaborazione, creo un nuovo contesto. Se ogni volta che P e C col-laborano creo un nuovo contesto ⇒ non devo mai modificare il codice di P e C anche a fronte di modifiche nelle loro relazioni. Facciamo un esempio: value Point x, y: real Laws: L1: x ge 0 L2: y ge 0

value Line path: list of Point start, end: point length: real selfcross: boolean Laws: L1: card(path) ge 2 L2: start eq first(path) L3: end eq last(path) L4: length eq ~LenLine(path) L5: selfcross ⇔~LineSelfCross(path)

Una tilda (~) davanti ad un nome indica che quella è una funzione definita altrove.



list of e set of sono due parole chiave che indicano degli insiemi: list of → insieme ordinato set of → insieme non ordinato Nello schema per indicare list of o set of metto una L o una S sulla linea che indica la relazione.

Line Point

Attributi

L

S

Se ho un oggetto Forma: Line ⇒ posso indicare gli attributi di forma con la dot nota-tion. Forma.path, Forma.start, Forma.end, …

Operatori sulle liste first(Lista) → estrae il primo elemento dalla lista Lista last(Lista) → estrae l’ultimo elemento dalla lista Lista next(Lista, Num) → estrae dalla lista Lista l’elemento successivo a quello di po-sizione Num previous (Lista, Num) → estrae dalla lista Lista l’elemento precedente quello di posizione Num

Operatori sugli insiemi Elem in(Insieme) → indica se l’elemento El fa parte dell’insieme Insieme card(Insieme) → indica quanti elementi contiene l’insieme Insieme

Per indicare che un concetto è una specializzazione di un altro si usa la parola chiave “is a”. value ClosedLine is a Line Area: real L1: selfcross eq false L2: start eq end L3: Area eq ~ClosedLineAreaComp(path) L4: card(path) ge 3 (questa è una restrizione rispetto a Line) value Network Nodes: set of Point Arcs: set of Line Laws:



L1: /* per ognuno dei nodi esiste almeno un arco di cui tale nodo è un estremo */ forall N in Nodes it is (exist A in Arcs such that (N eq A.start or N eq A.end))

L2: forall A in arcs it is (exist N1, N2 in Nodes such that (A.start eq N1 and A.end eq N2))

Vediamo una specializzazione di Network: value ConfluentTree is a Network Root: Point Leaves: set of Point Laws: T1: Root in Nodes T2: not(exist A in Arcs such that (Root eq A.start)) T3: Nodes include Leaves /*include indica inclusione fra insiemi*/ Potrei anche riscriverla così: T3’: forall L in Leaves it is (exist N in Nodes such that (N eq L)) T4: forall L in Leaves it is (not exist A in Arcs such that (L eq A.end)) T5: forall N in (Nodes minus Root) it is (exist unique A in Arcs such that (N eq

A.start))

A

B

C

Definiamo meglio l’oggetto Persona: object Persona Nome: string mandatory Cognome: string mandatory Età: integre CF: string mandatory unique Tel: set of integer mandatory Class Attributes [Instances: set of Persona] EtàMedia: real Laws: P1: Nome ne Null P2: Tel ne Empty P3: forall P1, P2 in Instances it is (ident(P1) ne ident(P2) ⇒ P1.CF ne P2.CF) P4: EtàMedia eq avg(P.Età for P in Instances) Il fatto che un campo sia mandatory lo posso anche esprimere per mezzo di una legge:



Lx: Nomecampo ne Null Glossario: Mandatory → obbligatorio Unique → il valore è unico Null → assenza di un valore assegnato per un attributo semplice Empty → assenza di un valore assegnato per un set o una list Ident(Nomeoggetto) → restituisce l’object identifier dell’oggetto Instances → è l’insieme di tutte le istanze di un oggetto Avg → media Sum → somma Max → massimo Min → minimo Facciamo un esempio: context Ordine Prod: Produttore Forn: Fornitore DataOrd, DataCons: Data QtàCons, QtàRich: integer Prezzo: real Stato: (ordinato, in evasione, cancellato, evaso) Class Attributes: MaxVal, MaxCons: real Laws: L1: QtàCons le QtàRich … L5: Prod.QtàDisp eq Old Prod.QtàDisp-QtàCons Ordine Prodotto s: QtàCons = Null QtàDisp = x s’: QtàCons = z QtàDisp = x-z Noto che L5 è sbagliata, devo scrivere: L’5: old QtàCons eq Null and QtàCons ne Null ⇒ Prod.QtàDisp eq Old Prod.QtàDisp-

QtàCons … L9: MaxVal eq max(X.QtàRich*X.Prezzo for X in Instances) L10:MaxCons eq max(X.QtàCons*X.Prezzo for X in Instances where X.QtàCons ne

Null)



Ordine

Produttore

Fornitore

Data

Integer

Real

Prod

Forn

DataOrd

DataCons

QtàRich QtàCons

Prezzo

Stato

Immaginiamo di avere un value che si chiama Laboratorio, un value che si chiama di-partimento ed un altro che si chiama Personal. Immaginiamo poi che esistano un con-text chiamato PCinLab che associ ad un laboratorio i suoi PC e uno chiamato LabinDip che associ ad ogni dipartimento i suoi laboratori. Dato che chi paga i PC non è il singolo laboratorio, ma è il dipartimento, devo avere un terzo context PCinDip.

PCinLab

Dipartimento

Laboratorio

Personal

LabinDip

PCinDip

Dip Dip

PC

PCS

Lab

Lab

S

context PCinLab context LabinDip Lab: Laboratorio Lab: Laboratorio PC: Personal Dip: Dipartimento … … context PCinDip by PCinLab, LabinDip Dip: Dipartimento PCS: set of Personal NPC: integer … Class Attributes



TotNPC: integer Laws: L1: forall P in PCS it is (exists LD in LabinDip.Instances, PL in PCinLab.Instances such

that (ident(Dip) eq ident(LD.Dip) and ident(LD.Lab) eq ident(PC.Lab) and ident(P) eq ident(PL.PC)))

D17 set of Personal

D17 L02

P712 L02

P (ad esempio P712)

PCinLab

PCinDip

LabinDip

L2: NPC eq card(PCS) L3: TotNPC eq sum(X.NPC for X in Instances) Vediamo un altro esempio: value Point x, y: real

Segmento

Rettangolo

Spezzata Point real real

x y

distanza

corda

diagonale

start end

start end path S

alto dx

basso sx

Ho bisogno di esprimere il concetto di distanza fra due punti una volta per tutte ⇒ faccio un virtual object. Virtual P&P(P1, P2: Point) Distanza: real Coincidenti, Verticali, Orizzontali, Crescenti, Decrescenti: boolean

virtual object

Point

P1 P2

distanza



Sto prendendo una coppia di punti, li sto mappando in un real o in un boolean (⇒ sto esprimendo delle funzioni) Laws: L1: Distanza eq sqrt(sqr(P1.x-P2.x)+sqr(P1.y-P2.y)) L2: Coincidenza ⇔ Distanza eq 0 L3: Orizzontali ⇔ P1.y eq P2.y L4: Verticali ⇔ P1.x eq P2.x L5: Crescenti ⇔ P1.x le P2.x and P1.y le P2.y object Segmento … Lx: Distanza eq P&P(P1 = start, P2 = end).Distanza /* uso il virtual object come generatore di valore */ object Rettangolo Corretto: boolean … Laws: L1: Corda eq P&P(P1 = altosx, P2 = bassodx).Distanza L2: Corretto ⇔ P&P(P1 = altosx, P2 = bassodx).Decrescenti virtual DuePersone Coetanei, PiùVecchio2: boolean … Laws: L1: Coetanei ⇔ P1.Età eq P2.Età L2: PiùVecchio2 ⇔ P1.ddn.A gt P2.ddn.A or (P1.ddn.A eq P2.ddn.A and P1.ddn.M gt P2.ddn.M) or (P1.ddn.A eq P2.ddn.A and P1.ddn.M eq P2.ddn.M and P1.ddn.G gt P2.ddn.G) virtual Gruppo(SP: set of Persona) EtàMax: integer+ Cardinalità: integer+ RedditoMedio: real virtual P&S(P: Point, S: Segment) Appartenenza, StessaLinea: boolean DistanzaMinima, DistanzaMassima: real



Viste ed eventi

mondo reale

software dati inizializzazione

View

Data Entry

domanda sul mondo reale

?

Il modello MDT fornisce i due costrutti Event e View rispettivamente per registrare gli eventi del mondo reale e per estrarre i dati dal sistema informativo. view vista075(Modello: string, CodDip: integer) from PCinDip Ris: set of Personal Laws: L1: forall PC in Ris it is (PC.Modello eq Modello and exists C in PCinDip.Instances such

that (exists PCD in C.PCS such that (ident(PC) eq ident(PCD))) and C.Dip.Cod eq CodDip)

L2: forall PD in PCinDip.Instances it is (PD.Dip.Cod eq CodDip ⇒ exists P in Ris such that (ident(P) eq ident(PD.PC) and P.Modello eq Modello))

Quali sono gli elementi che caratterizzano un evento, cioè di che cosa ho bisogno per indicare un evento?

Denominazione Quali oggetti/classi sono coinvolti Altre informazioni di dettaglio

Un evento assomiglia molto ad un context. Un evento è l’insieme di una classe, che indica le caratteristiche generali e delle sue istanze, che si riferiscono ad un caso specifico e scatenano le modifiche del sistema informativo. Quando modello un sistema informativo devo prevedere tutti i possibili tipi di eventi e e possibili classi di oggetti ⇒ MDT prevede il costrutto Event attraverso il quale è possibile catturare la conoscenza funzionale. L’operatore percepisce un evento (di un certo tipo) che si è verificato nel mondo reale attraverso i suoi attributi. Quali sono gli attributi di un evento? Se consideriamo l’evento “Incidente automobilistico” potrebbero essere: nome delle persone coinvolte, targhe delle auto, luogo, tempo, codici delle assicurazioni… Luogo e tempo sono attributi propri dell’evento, gli altri sono attributi degli oggetti partecipanti. Un evento è caratterizzato solo da attributi. Non ho l’identità degli oggetti coinvolti, sono io che la devo scoprire tramite gli attri-buti che ho.



event Vendita on Cliente, Prodotto, Fattura CodProd, CodCli: string Qtà: integer Data: Data Precondition: /* in generale è necessario esprimere la/e condizione/i che rendo-

no l’evento accadibile */ L1: exists C in Clienti.Instances, P in Prodotto.Instances such that (C.CF eq CodCli and

P.Codice eq CodProd and C.Credito ge Qtà*P.Prezzo and P.Disp ge Qtà) Operation: /* rappresenta cosa accade riguardo alla registrazione dell’evento */ {commento in qualunque linguaggio su cosa accade nel sistema informativo} ad esempio: {1) diminuisci di Qtà la Disponibilità del prodotto 2) genera un’istanza di fattura con Qtà, NomeCliente, Indirizzo, ecc …}

Appunti di Ingegneria del Software -...

Documents

Transcript of Appunti di Ingegneria del Software -...