Trattazione del Comportamento Emergente in Sistemi...

Universita degli Studi di Firenze

FACOLTA DI SCIENZE MATEMATICHE, FISICHE E NATURALI

Corso di Laurea in Scienze e Tecnologie dell’Informazione

Tesi di Laurea Specialistica

Trattazione del Comportamento Emergente

in Sistemi Complessi

Laureando

Lorenzo Vinerbi

Relatore

Prof. Andrea Bondavalli

Correlatore

Dott. Paolo Lollini

Anno Accademico 2008-2009

a Liliana

Abstract

ἔστι τι τὸ ὄλοv ηαρὰ τὰ μὅρια

L’interezza è qualcosa chetrascende le singole parti.

Aristotele

Così scriveva Aristotele nel 4◦ sec. A.C., disquisendo di un tema caro alla filosofia: che rappor-to vige tra i componenti di un sistema e l’interezza del sistema stesso? L’azione associativa puòmutare la natura dell’agglomerato sino a renderlo un soggetto nuovo, caratterizzato da proprietàpeculiari? É sull’impronta di queste considerazioni che nel 18◦ secolo nasce l’Emergentismo, cor-rente principalmente filosofica ma che ben presto amplia il proprio orizzonte interessando le piùdisparate discipline, dalla biologia alle neuroscienze, dalla logica all’economia. Al centro delladisamina vi era il concetto di emergenza, intesa come “proprietà di sistema non derivabile dalleproprietà (note) dei suoi componenti”.

Il lavoro condotto in questa tesi si inserisce in questa linea di ragionamento cercando di conte-stualizzarla nell’ambito informatico. La necessità di un simile momento di analisi è giustificata dauna realtà in cui i sistemi informatici, nonostante tecniche di progettazione, validazione e testingsempre più evolute, mostrano una tendenza al fallimento pressoché inalienabile. Perché non riu-sciamo a sviluppare sistemi esatti? É possibile che i fallimenti informatici possano essere intesicome fenomeni emergenti?

La risposta tipica a queste domande risiede in una parola: complessità. I sistemi attuali so-no troppo ricchi, troppo interconnessi, in una parola troppo complessi, per riuscire a svilupparearchitetture scevre da errori. Nel corso della tesi noi non contesteremo questa verità purtroppoimprescindibile, sosterremo però che molti fallimenti sono figli di errori progettuali evitabili edettaglieremo una tecnica che possa guidare il progettista nella riduzione di tali errori.

Il nostro approccio al problema si fonda su due idee chiave. Anzitutto l’individuazione di unafase, nel processo di sviluppo di un sistema, su cui concentrare i nostri sforzi. In questo caso lascelta è stata quasi naturale, rappresentando la Requirement Engineering (RE) uno dei momentipiù critici della catena di sviluppo, dove l’esperienza del progettista è ancora la principale metricaaccettata e spesso non è supportata da strumenti sufficientemente validi. Proprio per questo motivola RE si prefigura come una delle fasi in cui vengono immessi più errori e certamente quella incui vengono immessi gli errori più critici.

Il primi due capitoli della tesi si occuperanno pertanto di contestualizzare l’ambito di lavorodella RE, evidenziandone le problematiche, le soluzioni offerte nel corso degli anni e approfon-

v

vi

dendo il rapporto con l’analisi di sistemi complessi e di sistemi critici. Nel secondo capitolo cifocalizzeremo quindi su quella che, ai nostri occhi, appare la soluzione ideale per approcciarela problematica in studio: KAOS. Il framework sviluppato da Lamsweerde et al. ha infatti ilpregio di unire una rappresentazione chiara e disambigua, che fa ricorso al modello GORE, dicui descriveremo i pregi, con una tecnica di raffinamento dei requisiti formale e al tempo stessointuitiva.

La seconda idea cardine del lavoro riguarda chiaramente la genesi dei fallimenti sistemici. Giànei primi due capitoli proporremo alcune digressioni sul rapporto vigente tra le tecniche di RE e larealtà in esame, mostrando come la dicotomia sottesa sia forse insormontabile e certamente inducanel progetto aspetti di ignoranza che non possono essere trascurati. Tali considerazioni verrannoampliate e diverranno manifeste nel capitolo 3 dove proporremo un’ampia disamina del concettodi emergenza. Lo studio delle proprietà che lo caratterizzano nelle differenti discipline permetteràinfatti di sintetizzarne le peculiarità, offrendoci gli strumenti adatti per poterlo formalizzare econtestualizzare nell’ambito informatico. Questa nuova consapevolezza permetterà di qualificarele cause delle manifestazioni emergenti e di caratterizzarne l’evoluzione. Su tali basi fonderemola nostra tecnica di analisi e rilevazione dell’emergenza, basata sul concetto di individuazionedell’ignoranza associata ai differenti sotto-sistemi in cui si specializza il sistema in esame e dimodalità di agglomerazione della medesima.

Offerto uno strumento per rilevare e quantificare l’emergenza, nel capitolo 4 mostreremo cometale concetto rappresenti una vera e propria metrica di dependability, capace peraltro di ricoprireun ruolo essenziale nello sviluppo di sistemi testabili. Indagheremo pertanto il rapporto vigentecon le tecniche di testing, evidenziando come l’utilizzo di uno strumento come KAOS consentadi arricchire significativamente la duttilità e l’efficacia delle tecniche stesse.

Il percorso centrale della tesi si concluderà nel capitolo 5 dove verranno analizzate le modali-tà di risoluzione dell’emergenza, approfondendo peraltro il rapporto vigente tra queste ultime el’Obstacle Analysis tipica di KAOS.

Le conoscenze apprese nel corso della tesi confluiranno quindi nel capitolo 6, in cui appliche-remo la tecnica da noi proposta su un caso di studio reale. Effettueremo in particolare la disaminadell’emergenza associata ad un Sistema di Rilevazione Incendio da installare in una rete di me-tropolitane. Il caso di studio, pur non prefigurandosi come ottimale, permetterà di “osservareall’opera” il funzionamento del metodo proposto, evidenziando come tramite una disamina certa-mente non troppo onerosa sia possibile migliorare sensibilmente la qualità dei requisiti dati e, diconseguenza, diminuire la possibilità di manifestazioni emergenti sul sistema critico proposto.

L’ultimo capitolo offrirà un’ampia digressione relativa al rapporto tra emergenza e COTS BasedSystems. La particolare natura dei componenti COTS li rende infatti portatori naturali di ignoran-za, facendo sì che nei sistemi in cui essi vengono impiegati sia alto il rischio di manifestazioniemergenti. Terminata una prima disamina di questi componenti, daremo alcune direttive che, anostro parere, dovrebbero essere seguite nell’utilizzo di COTS. Inoltre la disamina del linguaggioUDDI, tipico dei WS, permetterà di aprire un’interessante parentesi sul ricorso ad un database diCOTS; parentesi in cui sottolineeremo l’essenzialità di campi informativi generalmente trascurati,la cui presenza al contrario garantirebbe un utilizzo più cosciente (e questo aspetto sarà ribaditotramite alcuni semplici casi di studio) dei medesimi.

Indice

1 Introduzione 11.1 Sviluppo Di Un Sistema 21.2 Safety Properties 4

1.2.1 Verifica Formale 41.2.2 Critiche Ai Metodi Formali 61.2.3 Il Dilemma Della Conoscenza A Priori 7

1.3 Requirement Engineering 81.3.1 Problematiche Tipiche Della RE 91.3.2 Il Rapporto Tra RE & Mondo Reale 101.3.3 Tecniche Di Raffinamento Dei Requisiti 111.3.4 Requirement Validation 13

1.4 Il Problema Dell’Ignoranza 141.4.1 Studiare L’Ignoranza 14

1.5 Svolgimento Del Lavoro 16

2 La Goal-Oriented Requirement Engineering e KAOS 192.1 La Requirement Engineering 19

2.1.1 La RE Sino A GORE 202.1.2 Requisiti Non Funzionali 222.1.3 Trattare NFR Utilizzando I Goal 24

2.2 L’Approccio GORE 262.2.1 Formal Framework Vs. Qualitative Framework 262.2.2 Specificare I Goal 272.2.3 Specifica Formale Dei Goal 282.2.4 Perché Utilizzare I Goal? 30

2.3 KAOS 322.3.1 Il Linguaggio Di KAOS 332.3.2 Raffinamento Dei Goal 392.3.3 Analisi Degli Ostacoli 422.3.4 Il Prodotto Di KAOS 45

3 L’Emergenza 473.1 Introdurre L’Emergenza In Informatica 48

vii

viii Indice

3.1.1 L’Emergenza 483.1.2 I Differenti Volti Dell’Emergenza 493.1.3 L’Emergenza In Informatica 51

3.2 Trattare L’Emergenza In KAOS 543.2.1 Introdurre L’Emergenza In KAOS 553.2.2 Rappresentare L’Emergenza 563.2.3 Quantificare L’Ignoranza 573.2.4 L’Emergenza Come Strumento Di Conoscenza 59

3.3 Derivare L’Emergenza 603.3.1 L’Emergenza In Rapporto Alla Obstacle Analysis 603.3.2 Raffinamento Dei Goal Emergenti 613.3.3 Analisi Dell’Emergenza: Un Processo Top-Down O Bottom-Up? 63

3.4 Composizionalità Dell’Emergenza 643.4.1 Le Fonti Di Emergenza 643.4.2 Comporre L’Ignoranza 653.4.3 Modello Di Analisi Dell’Emergenza 673.4.4 Vantaggi Dell’Approccio Proposto 70

3.5 Considerazioni Conclusive 72

4 Testabilità In Sistemi Emergenti 734.1 Testability 73

4.1.1 Testability: Le Parole Chiave 744.1.2 I Fattori Che Influenzano La Testability Software 75

4.2 Individuare L’Emergenza In Ambienti GORE 814.2.1 Ridurre La Complessità Con Un Approccio A Livelli 824.2.2 Combattere L’Emergenza Con Un Testing Mirato 844.2.3 Vantaggi Dell’Approccio Proposto 87


5 Correggere L’Emergenza 915.0.1 Obstacle Resolution e Correzione Dell’Emergenza: Una Differenza So-

stanziale 915.0.2 Rileggere La Obstacle Analysis In Ottica Emergente 93

5.1 Eliminare L’Emergenza 935.1.1 Selezionare Un Raffinamento Alternativo 935.1.2 Selezionare Un Agente Alternativo 945.1.3 Prevenire L’Emergenza 945.1.4 Modificare Il Dominio 965.1.5 De-Idealizzare I Goal 96

5.2 Ridurre La Frequenza Del Fenomeno Emergente 985.3 Tollerare L’Emergenza 98

5.3.1 Limitare Temporalmente L’Emergenza 995.3.2 Indebolire Gli Effetti Del Fenomeno Emergente 99


6 Caso Di Studio Affrontato 101

Indice ix

6.0.1 Breve Presentazione Del Caso Di Studio 1026.1 Disamina Approfondita Del Caso Di Studio 103

6.1.1 Requisiti Principali Del Progetto 1046.1.2 Normative Di Riferimento 1056.1.3 Analisi Effettuata Da AZ 1066.1.4 Limiti Del Caso Di Studio 1076.1.5 Obiettivi Del Caso Di Studio 109

6.2 Analisi Dell’Emergenza 1106.2.1 Emergenza: Allarme Manuale 1146.2.2 Emergenza: Rilevazione Incendio 1206.2.3 Emergenza: Estinzione 1216.2.4 Emergenza: PTU 1256.2.5 Emergenza: HVAC 1276.2.6 Emergenza: Diagnostica 128


7 Commercial Off The Shelf 1357.1 Il Ricorso A Componenti COTS 135

7.1.1 Il Ricorso A Componenti COTS: Una Soluzione Plug & Pray? 1367.2 L’Emergenza Come Metrica Di Valutazione Dei COTS 138

7.2.1 La Selezione Tra COTS Come Problema di Emergenza 1397.3 Web Service 141

7.3.1 Linguaggi Per La Definizione Dei Web Service 1427.3.2 Web Service Vs. COTS 1447.3.3 Informazioni Addizionali Per i Web Service 145

7.4 Arricchire I COTS Con Informazioni Addizionali 1487.4.1 Rating Dei COTS 1497.4.2 Maggiori Informazioni Dai Vendor: I Test 1507.4.3 Maggiori Informazioni Dai Vendor: I Domini 1517.4.4 Maggiori Informazioni Dai Vendor: NFR 1517.4.5 Studio Dinamico Dei COTS 152

7.5 Casi di Studio 1547.5.1 Esempio 1 1547.5.2 Esempio 2 1557.5.3 Esempio 3 1567.5.4 Considerazioni Finali Sui Casi Di Studio 157

Conclusioni 159

B I B L I O G R A F I A 161

Elenco delle figure

Figura 1 Markov Chain esemplificativa di un sistema elementare. 15Figura 2 Markov Chain esemplificativa di un sistema potenzialmente emergente. 16Figura 3 Esempio di grafo rappresentante un insieme di NFR nel framework di

Chung et al.. 25Figura 4 Esempio di pattern applicabile ad un “Achieve Goal”. 30Figura 5 Altro esempio di pattern applicabile ad un “Achieve Goal”. 30Figura 6 Modelli del linguaggio di KAOS. 34Figura 7 Esempio di formalizzazione di un goal in KAOS. 35Figura 8 Esempio di raffinamento di un goal con assegnazione di responsabilità ad

agenti. 36Figura 9 Esempio di modello agenti in cui si evidenziano le interfacce degli agen-

ti. 37Figura 10 Tattiche di raffinamento per risolvere l’irrealizzabilità di un goal. 41Figura 11 Schema riassuntivo che mostra le varie tecniche adottabili per risolvere

gli ostacoli. 45Figura 12 Sintesi del sistema minimo analizzato dal metodo proposto. 70Figura 13 Sistema con partizionamento dei moduli. 78Figura 14 Schematizzazione di un PCO. 79Figura 15 Funzionalità di Observation Mode. 80Figura 16 Funzionalità di Test Mode. 80Figura 17 Goal-Tree (parziale) relativo al requisito “DistBetweenTrains”. 86Figura 18 Figurino di una tipica metro componente la piattaforma PM. 103Figura 19 Schematizzazione del primo livello del Goal-Tree relativo all’intero RSI. 113Figura 20 Goal Tree (basico) relativo al requisito emergente “SegnalaAllarmeSeTem-

pAltaOManuale”. 114Figura 21 Pattern utilizzato per il raffinamento del goal “SegnalaAllarmeSeTempAl-

taOManuale”. 115Figura 22 Goal Tree (primo raffinamento) relativo al requisito emergente “Segna-

laAllarmeSeTempAltaOManuale”. 116Figura 23 Goal Tree (secondo raffinamento) relativo al requisito emergente “Segna-

laAllarmeSeTempAltaOManuale”. 116Figura 24 Goal Tree (versione alternativa) relativo al requisito emergente “Segna-

laAllarmeSeTempAltaOManuale”. 119

xi

Figura 25 Goal Tree (raffinamento parziale) relativo al requisito “RilevazioneIncen-dio”. 120

Figura 26 Goal Tree (basico) relativo al requisito emergente “SpegniIncendioSeRile-vato”. 122

Figura 27 Goal Tree (primo raffinamento) relativo al requisito emergente “SpegniIn-cendioSeRilevato”. 123

Figura 28 Goal Tree (completo) relativo al requisito emergente “SpegniIncendioSe-Rilevato”. 124

Figura 29 Goal Tree (parziale) relativo al requisito emergente “CheckPTU”. 126Figura 30 Goal-Tree relativi ai requisiti “DiagnFumo” e “DiagnTemp&Manuale”. 129Figura 31 Goal-Tree relativo all’intero requisito emergente “Rileva&ComunicaDiagnostica”. 130Figura 32 Pseudo Goal-Tree relativo all’intero requisito emergente “Rileva&ComunicaDiagnostica”,

considerando l’incognita indotta dalla diagnostica real-time. 132Figura 33 Schematizzazione del funzionamento di una Production Cell. 155

Acronimi e Abbreviazioni

Notazione SignificatoAPI Application Programming InterfaceBART San Francisco Bay Area Rapid TransitB2B Business-To-BusinessBBN Bayesian Belief NetworksBIT Built-In TestCBS COTS Based SystemsCOTS Commercial Off-The-ShelfCTL Computation Tree LogicCS Caso di Studio(CS) AZ Nome (fittizio) dell’azienda proprietaria del CS(CS) HVAC Sistema di Condizionamento e Riscaldamento(CS) PM Piattaforma di Metropolitane (sistema su cui si applica RSI)(CS) PTU Portable Test Unit(CS) SRI Sistema di Rilevazione Incendio(CS) TCMS Sistema di Controllo e Monitoraggio del TrenoDFT Design For TestabilityDFV Design For ValidationDSR Documento di Specifica dei RequisitiER Entità-RelazioneFR Requisiti FunzionaliGORE Goal-Oriented Requirement Engineering(KAOS) AIM Agent Interface Model in KAOS(KAOS) ARM Agent Responsibility Model in KAOS(KAOS) GM Goal Model in KAOS(KAOS) OM Object Model in KAOS(KAOS) OP Operation Model in KAOS(KAOS) OA Obstacle Analysis in KAOSLTS Labelled Transition SystemNFR Requisiti Non-FunzionaliPCO Point of Control and ObservationQoS Quality Of Service

xiii

RAMS Reliability, Availability, Maintainability and SafetyRE Requirement EngineeringSE Safety EngineeringSIL Safey Integrity LevelsVLSI Very Large Scale IntegrationWS Web Services(WS) WSDL Web Services Description Language(WS) UDDI Universal Description, Discovery and Integration

Capitolo 1Introduzione

“...così parlai a Fermi di quel problema e iniziai a descrivergli i risultati ottenuti. Lui miinterruppe: “Aspetta! Prima di dirmi il risultato, lasciami pensare. Dovrebbe tornare in questo

modo (e in effetti aveva ragione) e dovrebbe tornare così per questa e quest’altra ragione”.Stava calcolando ciò che io avevo ottenuto (col calcolatore) e lo stava facendo dieci volte più

veloce.”(R. Feynman)

La citazione proposta è il resoconto di una conversazione avvenuta tra Feynman (voce narrante)e Fermi nei primi anni ’50 ed è utilizzata dallo stesso Feynman per ribadire l’eccellenza di unamente geniale, quale fu indubbiamente quella di Fermi, in rapporto ad un artefatto umano comeun calcolatore.

In effetti, nell’informatica ai suoi albori, può essere certamente sottintesa una latente volontà diemulare (e poi superare) le capacità almeno computazionali del cervello umano: l’idea era quelladi analizzare un problema, strutturarlo nelle sue componenti basiche e far elaborare queste ultimead un calcolatore.

Pur rimanendo pressoché immutata l’idea di fondo, nel corso degli anni è cambiato radicalmen-te l’ambito in cui tale obiettivo deve essere sviluppato. Se fino a qualche anno fa le performancee la reliability di un sistema informatico erano strutturalmente connesse ai limiti fisici dei com-ponenti utilizzati, negli ultimi anni l’apporto (soprattutto in termini di fallimenti indotti) datodal software ha assunto un ruolo preponderante, a tal punto che oggi si adducono ai fallimentisoftware l’80% di tutti i fallimenti connessi ad un sistema informatico.

A questi dati si affianca la consapevolezza che sempre più frequentemente si è soliti assiste-re alla sperimentazione di fallimenti sistemici, come se una volta terminata la composizione diun’architettura software sia inevitabile assistere ad uno o più malfunzionamenti, del tutto inattesie, spesso, ignoti. E’ anche questa una delle ragioni alla base dell’utilizzo massivo di tecniche ditesting, momento di analisi che pare divenuto ineluttabile, quasi che la presenza di errori sia unassioma irrinunciabile di un componente software. Una siffatta situazione spinge a indagare leragioni sottostanti, alla ricerca di un denominatore comune che possa spiegare, almeno in parte,l’impossibilità di creare, nonostante le sofisticate tecniche di progettazione e implementazioneattuali, un sistema scevro da malfunzionamenti: non pare più possibile in sostanza operare comeoperavano Feynman e Fermi, in cui parti diverse di un problema si componevano naturalmenteoffrendo il risultato desiderato.

1

2 I N T R O D U Z I O N E

La tesi trae origine proprio da tali considerazioni e cercherà di qualificare, per quanto possibile,un carattere quiescente che sembra pervadere l’intero processo di progettazione di un sistema,inducendo in molti casi la sperimentazione di fenomeni che noi chiameremo emergenti.

1.1 S V I L U P P O D I U N S I S T E M A

L’incipit del nostro lavoro trae spunto da un concetto talmente basilare nella disciplina informaticada apparire ovvio: quello di Sistema [1] [2].

Def. 1 (Sistema) “Un sistema può essere definito come un insieme di elementi eterogenei intera-genti, correlati o indipendenti che vengono organizzati e integrati per formare un’unità collettivaatta a raggiungere obiettivi predeterminati.” [3]

Nella definizione data è infatti racchiusa l’essenza stessa della ricerca che intendiamo intra-prendere: vi possiamo individuare fondamentalmente quattro nozioni base, che costituiranno glielementi d’interesse della nostra analisi.

1. L’idea che un sistema debba essere inteso come un insieme di elementi più o meno ete-rogenei. Si sottintende in pratica la necessità di approntare un momento di analisi e diconoscenza degli elementi stessi, in quanto ognuno di essi potrebbe essere caratterizzatoda peculiarità non ovvie e da comportamenti potenzialmente dannosi per il sistema intesonella sua interezza.

2. Il fatto che tali elementi debbano interagire introduce inoltre un secondo spunto di rifles-sione: che caratteristiche ha il processo di interazione tra elementi (siano essi software ohardware)? E’ un fenomeno esatto o si caratterizza per risultanze inattese? Integrare uncomponente all’interno di un sistema e, di conseguenza, correlarlo con una molteplicità didifferenti agenti è, in sostanza, un’operazione che travalica la semplice realizzazione di unafeature e, potendo comportare la manifestazione di hazardous state, entra nel difficile campodelle problematiche di validazione sia dei requisiti d’interesse, sia della safety complessivadel sistema.

3. Abbiamo sin qui parlato genericamente di requisiti da soddisfare, d’altra parte, la loro enu-cleazione è uno degli argomenti topici della letteratura relativa allo sviluppo di un sistemasoftware.

4. L’idea secondo cui il sistema si prefigura come un’unità collettiva, atta a realizzare certe fun-zionalità, introduce inoltre tutta una serie di problematiche correlata alla verifica del correttomatching tra requisiti richiesti e funzionalità realizzate (problematiche peraltro strettamentelimitrofe a quelle di testing da svolgere sul sistema).

In sostanza, il nostro interesse verterà sulle modalità di sviluppo di un sistema non elementare,con un’attenzione particolare per quei limiti, fisici o concettuali, che impediscano la costruzionedi un sistema corretto. Quello che si osserva all’atto pratico infatti, è l’evidenza di sistemi chesperimentano condizioni inattese, operando secondo modalità non preventivate e, forse, non pre-ventivabili. Nel corso dello studio mostreremo come l’insorgenza di tali condizioni debba essereconsiderata una risultanza irrinunciabile laddove si operi con sistemi complessi e addurremo lagenesi di tale verità ad un deficit di conoscenza, latente in ogni modello o soluzione approntabile.

1.1 S V I L U P P O D I U N S I S T E M A 3

In questo primo capitolo cercheremo di sintetizzare i presupposti teorici che ci hanno spinto adapprofondire lo studio nella direzione appena esposta, ripercorrendo il percorso congetturale checi ha portato a studiare compiutamente il concetto di emergenza.

Anzitutto, in sezione 1.1, introdurremo il concetto di sistema critico e mostreremo come losviluppo di un siffatto sistema e il mantenimento delle relative proprietà possano essere realizzatiseguendo due approcci duali. Descriveremo pertanto in sezione 1.2 il primo di questi approcci,il quale, ricorrendo ai metodi formali, si concentra sulla verifica di proprietà globali, general-mente di safety, supposta una descrizione formale del sistema in esame. In seguito, in sezione 1.3,sintetizzeremo i passi tipici della Requirement Engineering, tecnica di sviluppo e ingegnerizzazio-ne di un sistema fondata sull’assiomatizzazione di requisiti (generalmente funzionali). L’analisidi entrambi gli approcci evidenzierà una criticità di base, associata alla presenza di un assuntoche criticheremo nell’ultima sezione del capitolo: l’idea cioè che l’ignoranza associata ai singolicomponenti del sistema sia un elemento fondamentalmente trascurabile.

Sistemi Critici

Abbiamo puntualizzato in precedenza alcune criticità che accompagnano lo sviluppo di un siste-ma in ambito informatico sottolineando la centralità del concetto di requisiti sistemici; vogliamoadesso approfondire l’analisi in questa direzione, introducendo il concetto di Sistema Critico [4][1].

Def. 2 (Sistema Critico) Viene definito Sistema Critico ogni sistema il cui fallimento mette arepentaglio vite umane o l’ambiente in cui il sistema opera. [3]

Dove per fallimento non si intende la mancata ottemperanza ad una data specifica funzionale,quanto piuttosto un comportamento del sistema potenzialmente pericoloso. Il sistema non vienepiù letto come un’entità assestante, ma è calato nel suo contesto sociale: cambia la semantica delvocabolario di riferimento e termini come fallimento e stato di sistema inatteso ampliano la lorovalenza, dovendo necessariamente considerare l’impatto dei medesimi sulla realtà contingente.Come diretta conseguenza, la qualità del sistema non può più essere letta unicamente in funzionedelle feature offerte, ma anche in relazione al mantenimento dell’integrità del contesto in cuiopera.

L’effetto di tale mutato orizzonte visivo è la necessità di definire in modo assolutamente certocondizioni supplementari che travalichino una prospettiva meramente funzionale, per stabilirecondizioni di sicurezza per l’intero contesto di utilizzo: le proprietà di safety.

Def. 3 (Safety) Una Proprietà di Safety è una proprietà atta ad affermare che “non deve realiz-zarsi un certo stato dannoso”. [5]

Le proprietà di safety aiutano i designer del sistema a modellare, analizzare, prendere coscien-za di punti di debolezza, capire ed, eventualmente, eliminare condizioni di hazard, sino al rag-giungimento di un livello di safety considerato accettabile (ovviamente concetti come quello di“danno” e di “accettabilità di un livello di hazard”, sono del tutto soggettivi e variano da progettoa progetto).

Esiste una ricchissima letteratura relativa alla Safety engineering (SE), in particolare per lostudio di sistemi critici come, ad esempio, le centrali nucleari. Tradizionalmente la SE parte dalpresupposto di poter preventivare certi errori, generalmente umani, che potrebbero presentarsi e


improntare azioni correttive studiate ad-hoc per tollerare l’evenienza. A nostro modo di vederequest’impostazione del problema è fondamentalmente carente, trascurando un aspetto che inveceriteniamo essenziale nell’analisi di sistemi critici: la possibile insorgenza di condizioni emergenti.

1.2 S A F E T Y P R O P E RT I E S

I concetti di proprietà di safety e di sistema safe si caratterizzano per differenti accezioni a secondadell’ambito di utilizzo. Nel proseguo considereremo l’orientamento tipico dei linguaggi formali(e, più in generale, di tutta l’ottica software), assumendo che una proprietà di safety sia tale inquanto espressione di una condizione che deve essere sempre vera all’interno di un sistema diriferimento. Formalmente possiamo dare la seguente definizione.

Def. 4 (Proprietà di Safety) Si dice Proprietà di Safety [6] [7] [8] ogni proprietà di un sistemache possa venire espressa da una formula del tipo:

�p

dove p è una qualche formula nella logica di riferimento e � è l’operatore henceforth, il qualeesprime il fatto che la formula deve essere sempre valida da lì in avanti.

La keyword tipica che caratterizza lo studio delle proprietà di safety diventa pertanto la parola“globale”. Una proprierà di safety è una proprietà globale, nel senso che essa fa riferimento all’in-tero sistema e può essere verificata unicamente a quel livello di lettura. Disquisendo sul ricorso adun approccio dependable facevamo riferimento al concetto di componente, al suo comportamentoe alle modalità di fallimento che potevano caratterizzarlo, questo perché l’analisi funzionale ivicondotta era inquadrabile in un’ottica bottom-up; potevamo cioè seguire un flusso di errore/erro-ri sino alla sua manifestazione come ostacolo alla realizzazione di un requirement. Parlando diproprietà globali dobbiamo, al contrario, porci in un’ottica differente in cui l’unità del sistema rap-presenta un presupposto imprescindibile per garantire l’assenza di una catena di stati indesiderata,che risulti in una negazione della condizione di safety.

La principale tecnica analitica utilizzata per trattare queste proprietà è rappresentata dal ricorsoa Metodi Formali [9] [10] [1], in cui l’intero sistema è tradotto utilizzando specifici formalismi ela correttezza del medesimo è garantita utilizzando opportuni checker (solitamente) automatici.

1.2.1 Verifica Formale

Il ricorso a metodi formali per comprovare la correttezza di un sistema è una soluzione che, vistianche gli enormi passi avanti fatti in termini di capacità computazionali dei processori odierni, staprendendo sempre più piede. La verifica formale è ovviamente un argomento amplissimo, in cuiper anni si è discusso, e tutt’ora si sta discutendo, su di una molteplicità di aspetti: concetti come lestrutture che dovrebbero essere considerate imprescindibili per la logica di riferimento, così comele problematiche legate ad un’analisi temporale, sono tutti temi topici del settore. Per gli scopidello studio attuale, non interessa approfondire tali aspetti, quanto piuttosto sottolineare talunecaratteristiche d’interesse legate principalmente alle criticità di una siffatta analisi in relazioneagli input offerti.

1.2 S A F E T Y P R O P E RT I E S 5

A((NOT p) W (q AND (NOT p)))

L’evento q non può avvenire sinché non è occorso, e poi è stato rilasciato, l’evento p

Tabella 1: Esempio di safety pattern.

Trasformare Una Notazione Ambigua In Una Formale

Possiamo indicare, a grandi linee, tre passi successivi che caratterizzano lo svolgimento di unaverifica formale.

1. Specifica rigorosa del sistema basata sul ricorso ad una logica opportuna.

2. Specifica rigorosa delle proprietà desiderate.

3. Verifica del soddisfacimento delle proprietà da parte del sistema per mezzo di una dimostra-zione formale:

• tramite un prover automatico/semi-automatico;

• in modo manuale.

Si capisce pertanto come l’apporto nevralgico dato da un metodo formale risieda nel passaggio dauna rappresentazione ambigua del sistema in esame, realizzata solitamente con il mero ricorso adiagrammi e linguaggio naturale, ad una rappresentazione univoca e interpretabile da un softwarespecificamente pensato (il checker del framework di riferimento).

Le strutture che meglio palesano tale parallelismo sono i pattern. I pattern sono oggetti attia racchiudere in un unico spazio logico la descrizione non formale e formale di una proprietà.Per i nostri scopi risultano particolarmente interessanti i Safety Pattern [11] [6], in cui la proprietàformale presente è una proprietà di safety. Un safety pattern tipico potrebbe essere quello propostoin tabella 1.

Il ricorso a pattern permette di costruire un vocabolario di riferimento per il passaggio da lin-guaggio naturale a linguaggio formale. Si pensi ad esempio di voler formalizzare il requisito disafety: “solo dopo che il treno è passato è permessa l’apertura dei gate di un attraversamentoferroviario”. Utilizzando il pattern di tabella 1 si ottiene:

A((NOT opening) W (train_passed AND (NOT opening)))

Ritroveremo il concetto di pattern nel capitolo 2, dove costituirà uno strumento essenziale perguidare l’analisi del sistema, per adesso interessava sottolineare la delicatezza e, in parte, lasoggettività di un momento chiave del processo di verifica formale.

Rappresentare La Realtà

Al di là delle disquisizioni relative alle modalità realizzative ed alla complessità del processoappena esposto, interessa soffermarsi su due aspetti particolari:

1. la presenza di semplificazioni inevitabili laddove si voglia tradurre la realtà in un modelloformale;

2. la relatività di una traduzione che converte una visione soggettiva della realtà in un modelloformale.


In relazione al primo punto l’obiezione è la stessa che concerne tutte le tecniche di modellizzazio-ne: la realtà è troppo variegata per essere compiutamente riassunta in un modello formale finito esufficientemente limitato. Si rischia in sostanza di modellare comportamenti che sono solo sem-plificazioni della realtà e risultano pertanto suscettibili di errori. Non ci soffermeremo su taleobiezione, ritenendola più un problema di qualità della modellizzazione effettuata e di profonditàdell’analisi, piuttosto che un reale limite dei metodi formali.

Per quanto riguarda il secondo punto in esame: quando formalizziamo, ad esempio, un LTSeffettuiamo una trasformazione che converte il nostro modo di leggere la realtà in un modelloequivalente, a meno di errori di traduzione. Al di là delle considerazioni relative alle garanzie chepossono essere poste sul processo di conversione, su cui ci soffermeremo nel seguito (paragrafo1.2.2), è importante capire la rilevanza di una lettura della realtà che risulta, imprescindibilmente,soggettiva.

Il processo di formalizzazione di un modello analitico viene effettuato da un agente umanoe, pertanto, non può considerarsi oggettivo, ma sarà necessariamente corredato da un apportosoggettivo. In fondo sia le assunzioni sul modello, che la natura stessa delle interazioni presentitra i processi di un sistema, sono qualità strettamente correlate al grado di conoscenza che ilsoggetto ha, o pensa di avere, sul sistema stesso. Una verifica formale pertanto certifica, al più, lacorrettezza del sistema in relazione alle informazioni in nostro possesso, non alla realtà.

1.2.2 Critiche Ai Metodi Formali

Il complesso rigore formale che caratterizza questi metodi dà adito a tutta una serie di critiche chenel corso degli anni sono state rivolte ai metodi formali. Fondamentalmente tali accuse si possonoriassumere in due concetti chiave [12]:

• utilizzare specifiche e verifiche formali è un’operazione fattibile unicamente in relazione asistemi che sono stati pensati per essere analizzati utilizzando queste tecniche;

• il problema rimane trattabile solamente se il numero di componenti presi in esame si man-tiene basso e le interazioni tra i medesimi possono essere modellate in maniera sufficiente-mente semplice.

Al di là delle due opposizioni (probabilmente le più conosciute) sovracitate, si possono individuarevari momenti critici che caratterizzano le due fasi chiave dell’analisi formale: la definizione dellespecifiche formali e l’effettuazione della verifica.

1. Specifica Formale del Sistema: in cui si formalizza, ricorrendo alla logica desiderata, il mo-dello in uso, le sue interazioni e le proprietà d’interesse. Le problematiche legate alla spe-cifica formale di un sistema possono includere deficienze particolari, come inconsistenza oincompletezza di una specifica, così come vulnerabilità più generiche che possono affligge-re il metodo stesso (soprattutto la sua corretta applicazione). Al di là degli errori di “forma”ci sono poi difficoltà legate ai contenuti che si intende esprimere: si potrebbe cercare di diretroppo (aumentando la complessità dell’analisi), troppo poco, oppure potremmo rappresen-tare aspetti differenti da quelli che pensavamo o nozioni errate nella sostanza. Tali possibiliproblematiche rappresentano però unicamente delle criticità su cui riporre attenzione e noncostituiscono un limite strutturale del processo di analisi di un metodo formale. Si limitanoin sostanza ad essere incognite di rappresentazione, argomento che non interessa il nostrostudio relativo alle cause profonde che portano a sviluppare un sistema malfunzionante.

1.2 S A F E T Y P R O P E RT I E S 7

2. Verifica Formale del Modello Sviluppato: in cui le specifiche formali vengono introdottenel checker (solitamente) automatico per verificare la consistenza delle proprietà richieste.É interessante in quest’ottica approfondire un aspetto tangenziale alle critiche solitamenterivolte ai metodi formali, ma che comunque trova spazio nella letteratura del settore [13][12] [14] [15]. L’assunto è che la verifica compiuta possa essere errata, ma tale scorrettezzanon dipenda dal metodo approntato, quanto piuttosto dalle assunzioni su cui abbiamo pog-giato la prova: sia cioè figlio di un’erronea, o quantomeno incompleta, assiomatizzazionedella realtà. Svilupperemo questa osservazione nel prossimo paragrafo.

1.2.3 Il Dilemma Della Conoscenza A Priori

In questo senso ci possono essere due tipologie di errori che tendenzialmente vengono commessistilando la lista degli assiomi di partenza:

1. si può formalizzare un’assunzione incorretta;

2. si possono tralasciare comportamenti chiave.

La prima tipologia di errore è la meno problematica. Un’assunzione sbagliata infatti, essendo unainterpretazione erronea della realtà, è:

• un errore oggettivo, nel senso che altri progettisti/utenti tenderanno a notare l’imprecisione;

• un errore permanente, rimane cioè a disposizione del progettista sino alla sua eliminazione;

• un errore che può indurre forme di inconsistenza con altri assiomi.

Tutte queste caratteristiche, in particolare l’ultima, fanno sì che la formalizzazione di un’assunzio-ne erronea sia un’eventualità (abbastanza) facilmente risolvibile. Anzitutto, ogni checker effettuaun controllo di consistenza tra le regole immesse nel modello. In secondo luogo, un sistema valida-bile, cioè rispondente alle euristiche della design for validation, consente una rilettura costruttivaanche degli assiomi, in modo tale da poter controllare efficientemente l’aderenza delle assunzionicol mondo reale.

Decisamente più problematica è la seconda tipologia di errore: tralasciare certe conoscenze. Inquesto caso il problema nasce dall’incapacità a rispondere a due domande: il dominio informativodi cui si è corredato il sistema è sufficiente per simulare la realtà in esame? E, in secondo luogo:il proprio dominio conoscitivo è sufficiente per simulare la medesima realtà?

Rispondere alla prima domanda non rappresenta uno scoglio insormontabile. E’ vero che nonè semplice essere pienamente coscienti, soprattutto in una fase del progetto così precoce, di qualiinformazioni potrebbero venire utilizzate dal checker, ma, d’altra parte, si può pensare di risolverefacilmente l’ostacolo dotando il sistema di tutte le informazioni di cui siamo a conoscenza.

La risposta alla seconda domanda al contrario non è banale. Il rischio sottostante è quello diporre in essere tutta una serie di analisi, che abbiamo genericamente indicato con il termine dimetodi formali, che poggiano su una conoscenza aprioristicamente accettata. L’assurdo è che po-tremmo arrivare a sviluppare un verificatore perfetto ma non funzionante, proprio perché la bontàdi un simile strumento è direttamente dipendente dalla correttezza degli input immessi. Si pensialla volontà di verificare una condizione di safety. Stanti certe assunzioni un sistema potrebberispondere positivamente al requisito d’interesse: d’altra parte aggiungendo altre interazioni, di


cui magari non eravamo a conoscenza, il medesimo sistema potrebbe non offrire più la coperturadesiderata.

Considerazioni in tal senso verranno riprese e ampliate nel paragrafo 1.4. Prima di concentrarcisu tali aspetti, è nostro interesse analizzare l’approccio allo sviluppo di un sistema generalmenteindicato con il termine Requirement Engineering: anche in questo caso difatti si manifesterannocriticità similari a quelle viste in queste pagine.

1.3 R E Q U I R E M E N T E N G I N E E R I N G

La definizione che offre Lamsweerde di Requirement Engineering [16] offre un’interessante spun-to per iniziare la trattazione di questa tipologia di analisi.

Def. 5 (Requirement Engineering) La Requirement Engineering (RE) concerne l’identificazio-ne degli obiettivi (goal) che il sistema sotto esame deve raggiungere, l’operazionalizzazione di talirequisiti in servizi e in costanti e l’assegnamento della responsabilità dei medesimi ad opportuniagenti, umani, device o software.

La RE si prefigura pertanto come un’operazione atta a trasformare i desiderata degli utenti inun progetto strutturato [17]. In particolare possiamo identificare tre apporti cruciali dati da unsiffatto studio.

• Definizione Dei Goal D’Interesse: attraverso cui si sintetizzano i reali obiettivi del progetto,consentendo di focalizzarsi su elementi specifici, senza disperdere risorse essenziali.

• Strutturazione Della Gerarchia Dei Requisiti: requisiti basici si strutturano per costituirerequisiti più generici, sino alla strutturazione di una gerarchia, generalmente ad albero, incui i livelli alti rappresentano proprietà globali del sistema.

• Assegnamento Delle Responsabilità: tramite cui possiamo avere una prima impressionedegli agenti che entreranno a far parte del progetto.

La RE non è ovviamente un’operazione elementare e, anzi, come vedremo nel prossimo paragrafo,gode di una complessità notevole. La RE si prefigura peraltro, venendo applicata nella primissimafase di progettazione di un sistema, come un’analisi basica, il cui errato svolgimento induce riper-cussioni dirette su tutta l’evoluzione del progetto e in cui gli errori presenti si prefigurano comedifficilmente risolvibili nelle fasi successive. Nei suoi studi sulla natura degli errori riscontrati neiprogrammi della NASA Voyager e Galileo, Lutz [16] ha sottolineato come la causa primaria deiguasti legati alla rottura della safety era spesso da rintracciare in un’errata definizione dei requisitifunzionali e di interfaccia.

Nel proseguo cercheremo di caratterizzare brevemente il contesto della RE, analizzandone leproblematiche e le metodologie risolutive adottabili. Similmente a quanto visto per l’analisi dellesafety property e dei metodi formali, il nostro scopo non sarà quello di dettagliare completamentela RE, quanto piuttosto quello di evidenziarne talune criticità che a nostro parere si conformanocome sostanziali per il tipo di analisi condotta nella RE. Ci soffermeremo in particolare sul rappor-to tra il raffinamento dei requisiti e la realtà esterna, cercando di prendere coscienza della naturastessa di tale nesso.

1.3 R E Q U I R E M E N T E N G I N E E R I N G 9

1.3.1 Problematiche Tipiche Della RE

Effettuare RE è un’operazione tutt’altro che semplice, nel 1987 Brooks scriveva [16]:

“...la fase più complessa dello sviluppo di un sistema software risiede nel decidere precisamenteche cosa sviluppare...Dunque il ruolo più importante che uno sviluppatore svolge per un cliente

consiste nell’estrazione e nel raffinamento iterativo dei requisiti di progetto.”

Le cause principali dell’intrinseca complessità della RE possono essere identificate in alcunicaratteri nodali della medesima.

• Anzitutto lo scopo stesso che essa si prefigge risulta assolutamente complesso. Si vuoleeffettuare una trasformazione da un mondo di interazioni umane, o al limite leggi fisiche,in un artefatto tecnologico che, peraltro, dovrà solitamente innestarsi in esso. Si passa inol-tre da oggetti interpretati ad alto livello, ad una descrizione operazionale sufficientementeraffinata; e da un contesto informale ad uno prettamente formale. Peraltro il target che siintende realizzare non è semplicemente un blocco software, ma comprende e si innesta inun contesto ambientale specifico, in cui agiscono agenti umani, device o altri software.

• Ci sono poi tutta una serie di aspetti d’interesse che vanno oltre il mero carattere funzionaledel progetto: sicurezza, usabilità, flessibilità, etc. Peraltro tali requisiti non funzionali sonospesso in contrasto tra loro.

• C’è da considerare il fatto che il processo di RE non viene svolto da un singolo soggetto,ma considera tutta una serie di gruppi di lavoro coinvolti, ognuno dei quali ha background,conoscenze, obiettivi, formalismi espressivi, differenti.

• Come mostreremo nel seguito la RE potrebbe contenere tutta una serie di deficienze. Talierrori potrebbero avere un impatto disastroso sull’intero progetto, inducendo fasi succes-sive di sviluppo erronee: inadeguatezza di alcuni requisiti, incompletezza dei medesimi,ambiguità, etc.

Peraltro la struttura stessa di un’analisi di RE, data la presenza di molte fasi che si susseguono, eche sono strettamente dipendenti, induce un’alta complessità.

• Analisi Del Dominio: in cui si studia l’ambito attuale in cui il sistema verrà innestato. Idifferenti gruppi di utenza sono individuati e intervistati. Si identificano i problemi con isistemi esistenti e si stilano i macro-obiettivi che si intende raggiungere.

• Raffinamento Dei Requisiti: vengono formalizzate le assunzioni sui componenti e, utiliz-zando uno specifico modello di riferimento, si procede alla individuazione dei differentirequisiti. Solitamente viene stilato anche un modello (o alcuni sottomodelli) alternativo.

• Negoziazione e Accettazione: le alternative considerate vengono valutate; si analizzano irischi connessi; il miglior compromesso diventa la soluzione definitiva.

• Formalizzazione Delle Specifiche: vengono formalizzati i requisiti e le relazioni tra i mede-simi.

• Analisi Delle Specifiche: le specifiche vengono controllate, anche automaticamente, perrilevare errori (inadeguatezza, inconsistenza, incompletezza) o punti deboli (in termini dirisorse richieste, costi di sviluppo, etc.).


• Documentazione: in cui i vari passi di sviluppo sono raccolti e dettagliati e le assunzioni ele scelte vengono ribadite e giustificate.

• Evoluzione: i requisiti possono modificarsi nel tempo per azioni correttive o di adeguamen-to ad un mutato environment o per l’aggiunta di nuovi desiderata.

1.3.2 Il Rapporto Tra RE & Mondo Reale

Il processo di specifica dei requisiti pone in primo piano le problematiche, già accennate per lasafety, connesse alla soggettività del modo in cui lo sviluppatore interpreta la realtà. CitandoNuseibeh & Easterbrook [18]: “...dunque la RE dovrebbe tener conto del modo in cui le personepercepiscono e interpretano la realtà circostante, del modo in cui interagiscono con la medesimae di come la sociologia di un particolare ambito influenzi le loro azioni.”.

Da un punto di vista ideale le tecniche di RE dovrebbero pertanto filtrare e rielaborare i con-tenuti dati tenendo conto di tutti gli aspetti descritti in precedenza. La RE si conformerebbe intal senso come uno studio in cui confluiscono apporti provenienti da dottrine cognitive e sociali,osserviamone alcune.

• Psicologia Cognitiva: si prefigge di sviluppare tecniche atte a esplicitare le difficoltà che lepersone, gli utenti di un servizio, possono avere nel descrivere i loro bisogni. Rientrano inquesto campo le difficoltà legate alla capacità di investigazione di alcuni concetti specificida parte dei designer, difficoltà che si traducono in requirement incompleti; o la scarsaattenzione che talvolta viene posta allo sviluppo di un’interfaccia facile da usare per gliutenti di riferimento.

• Linguistica: è una disciplina essenziale. La RE è infatti prima di tutto un problema di comu-nicazione: eliminare le ambiguità o incrementare la comprensibilità di alcune affermazioni,sono operazioni dall’impatto non indifferente.

• Antropologia: si tratta di un approccio metodologico utile per osservare e comprendere leinterazioni umane collaterali al sistema, in modo da sviluppare un sistema che possa aiutaretali interazioni. E’ il caso della etnometodologia, una disciplina che ha sviluppato tecnichedi osservazione e analisi riguardo l’interazione di un team o la collaborazione all’interno diun progetto.

• Sociologia: si cerca di qualificare l’impatto che il sistema in sviluppo potrebbe avere da unpunto di vista dei cambiamenti culturali indotti. L’introduzione di un nuovo apparato auto-matico potrebbe infatti mutare significativamente la qualità o la quantità, se non addiritturala natura, del lavoro prodotto all’interno di un’organizzazione; potrebbe mutare le modalitàdi comunicazione; finanche gli user needs stessi, precedentemente individuati.

Il Mondo Esterno

Al di là delle difficoltà legate alla specificità e soggettività degli utenti, o comunque di coloroche commissionano il lavoro, sono comunque presenti nella RE problematiche correlate all’in-terpretazione del mondo esterno. Di fatto, anche ignorando problematiche connesse alle condi-zioni socio/culturali, rimangono infatti limiti intrinseci dell’operazione di modellizzazione dellarealtà, slegati dalle peculiarità sociali descritte in precedenza, ma derivanti dalla natura umana


del soggetto che effettua l’analisi; questo perché ognuno di noi legge un’interpretazione ristret-ta della realtà e, di conseguenza, semplifica e limita la conoscenza complessiva che al contrariocontraddistinguerebbe il mondo esterno.

Si parla in questi casi di tre possibili trasformazioni indotte [18].

1. Epistemologica: legata al modo in cui si percepiscono i bisogni dei differenti insiemi diutenti;

2. Fenomenologica: legata ai limiti di osservabilità di un fenomeno. La domanda diventa: cosaè osservabile della realtà? O, letta in chiave più prettamente pratica: quante informazioniriusciamo a cogliere della realtà in esame?

3. Ontologica: legata alla natura stessa della realtà; su quali nozioni della realtà è possibileconcordare in modo oggettivo?

In sostanza, anche supponendo di poter depurare la nostra analisi dalle imperfezioni dovute alleinterazioni con l’utente o con l’ambito di studio, rimangono comunque limiti fisiologici inelutta-bili che accompagnano il processo di raffinamento dei requisiti. La complessità del mondo realee la natura umana del soggetto che effettua la RE inducono nella medesima un’indeterminatezzache, pur non potendo quantificare, dovrebbe essere tenuta in considerazione.

Il Ricorso Alla Logica Nella RE

Nel paragrafo precedente abbiamo analizzato il rapporto non sempre lineare vigente tra requisitisviluppati e mondo reale. In particolare abbiamo sottolineato come l’ambiguità sia un caratterelatente che accompagna tutto il processo di RE. Per cercare di ovviare, almeno in parte, a taleevidenza, nel corso degli anni i linguaggi di definizione dei requisiti si sono perfezionati semprepiù [19] e in essi ha assunto un peso sempre maggiore il ruolo della logica.

Offrire una descrizione formale del requisito che si sta trattando consente di fissarlo nel tempoe renderlo univoco. In questo modo:

• si definisce una descrizione univocamente interpretabile dai vari soggetti potenzialmenteinteressati;

• si è costretti, data la non immediatezza di tali formalismi, ad approfondire la sostanzadel requisito che stiamo analizzando, riscontrandone magari debolezza precedentementesfuggite;

• si offre una mappa dei requisiti facilmente seguibile, soprattutto laddove si ricorra a struttu-razioni gerarchiche.

1.3.3 Tecniche Di Raffinamento Dei Requisiti

Nel corso degli anni sono state sviluppate molteplici tecniche di raffinamento dei requisiti, ognunaottimale in riferimento a specifici ambiti d’uso. La scelta della tecnica di estrazione da utilizzaredipende pertanto da differenti fattori: tipo di informazioni che si vuole esternare, risorse disponibi-li, tempo massimo concesso, etc. Si possono classificare le tecniche secondo una serie di possibiliclassi di appartenenza.


• Tecniche Classiche: includono tutta una serie di approcci generici per la raccolta di in-formazioni. Si fa riferimento in particolare a questionari, survey, interviste, analisi delladocumentazione esistente, etc.

• Tecniche di raffinamento di gruppo: si intendono tutti quegli approcci che incoraggiano unlavoro collettivo, magari con il ricorso a gruppi dinamici di stesura dei requisiti. Rientranoin questa categoria brainstorming, focus group, etc.

• Prototipizzazione: è una tecnica utilizzata per trattare ambiti in cui sia presente molta incer-tezza. E’ spesso utilizzata in combinazione con altre tecniche. Il ricorso ad un prototipo vie-ne infatti inteso come un momento di analisi proattiva per guidare l’utilizzo di una tecnicatipica.

• Tecniche model-driven: in questi casi si ricorre a modelli specifici che dovrebbero confor-marsi appieno alla situazione contingente. Rientra, seppur in senso lato, in questa tipologiail ricorso ad approcci goal-oriented.

• Tecniche Cognitive: includono una serie di tecniche originariamente sviluppate per acqui-sire conoscenza in sistemi knowledge-based.

– Protocol Analysis: basata su un feedback continuo tra un esperto che svolga il task inesame e un osservatore esterno.

– Laddering: in cui si usano strutture preposte alla strutturazione della conoscenza deidifferenti utenti.

– Card Sorting: in cui si ricorre a più discussioni di gruppo su topic casualmente estrattie specifici per il caso in esame.

– Repertory Grids: in cui il dominio di conoscenza è esplicitato per mezzo dell’assegna-mento iterato di attributi a certe entità di riferimento.

• Tecniche Contestuali: in cui le tecniche classiche e cognitive vengono rilette per introdurree dare particolare rilievo al concetto di contesto. Tali tecniche sono nate agli inizi degli anni’90, dopo che erano state apportate svariate critiche alle tecniche classiche proprio per lamancanza di una lettura contestualizzata del progetto. L’idea è che non si possa effettuareun raffinamento realmente valido senza calarsi nel contesto d’uso, senza cioè considerare ledinamiche sociali e organizzative dell’ambiente in cui il sistema dovrà essere immesso.

La disamina, seppure molto veloce, di queste tecniche dovrebbe aver permesso di osservare uncarattere peculiare della RE: laddove parlando di safety facevamo riferimento ad uno studio forte-mente orientato all’analisi dei componenti e dei malfunzionamenti connessi, in questo caso stiamoanalizzando un momento del design cui è obbligatoriamente precluso un simile studio. Il raffina-mento dei requisiti non si pone problemi di tipo implementativo o hardware, l’obiettivo non ècapire quale strumento utilizzare per risolvere un task; il problema è piuttosto quale task si vuolerisolvere. In realtà, e questo diverrà palese quando parleremo di KAOS, le tecniche mostrate nonsi limitano a stilare una lista di requisiti ma cercano anche di guidare la progettazione del sistemafisico.

Rimanendo comunque nell’ambito di una tecnica di raffinamento pura, o comunque di un suoutilizzo esclusivo per la formalizzazione di requisiti, il prodotto della RE consiste in una lista direquisiti richiesti dall’utente, spesso dotata di una qualche struttura che possa, ad esempio, aiutarea capire quali siano i requisiti maggiormente rilevanti e quali interazioni esistano tra i medesimi.


1.3.4 Requirement Validation

Una volta che i requisiti sono stati esplicitati e modellati, non sempre i differenti gruppi di utenticoncordano sulla validità del risultato, soprattutto perché gli obiettivi di ognuno sono differen-ti (talvolta anche divergenti). La Requirement Validation consiste nello stabilire se i requisitiformalizzati e il modello ottenuto offrono una descrizione accurata per ogni gruppo di interesse.

Per ottenere una siffatta garanzia è necessario effettuare un duplice controllo:

1. è necessario assicurarsi che i requisiti siano coerenti tra sé;

2. è necessario verificare che ogni requisito sia coerente in relazione alla realtà descritta.

Abbiamo già osservato, parlando dei metodi formali, l’esistenza di tecniche specificamente pensa-te per la verifica della coerenza tra requisiti e non interessa soffermarsi nuovamente su tale aspetto,estraneo alle tematiche d’interesse.

Tecniche come la prototipizzazione, la specification animation, il ricorso a scenari, si focalizza-no invece sulla ricerca di una corretta corrispondenza con la realtà del problema. Effettuare unarequirement validation che consideri tali aspetti si rivela un task doppiamente difficile:

1. da una parte è presente, come abbiamo detto in precedenza, una difficoltà legata alla possi-bilità di raggiungere una soluzione accettata da tutti i soggetti interessati;

2. inoltre l’idea stessa di verificare la corrispondenza con la realtà potrebbe essere utopica (inprecedenza abbiamo accennato a riflessioni sulla conoscibilità stessa della realtà).

Il primo ostacolo può essere risolto introducendo un momento di negoziazione in cui i require-ment, appartenenti a soggetti differenti, che entrano in conflitto vengono analizzati e riletti e ilmodello è aggiornato di conseguenza.

Più sostanziale il secondo ostacolo. Il problema della validazione dei requisiti in questo caso po-trebbe essere paragonato a quello della validazione di una conoscenza scientifica. L’approccio piùcomunemente accettato, cui alcuni danno il nome di visione positivista, parte dal presupposto chevi sia un mondo oggettivo che può essere modellato e che le osservazioni empiriche garantiscanouna conoscenza e una verifica sufficiente. L’idea è che l’artefatto mentale che ci si costruisce sudi una conoscenza sia valido se esso è confermato dalle osservazioni empiriche. In realtà alcunidetrattori di tale linea di pensiero ribadiscono come un’osservazione non possa costituire la baseper una verifica, ma possa essere utilizzata al più per dare una confutazione.

Ai nostri occhi, stabilire se la realtà possa o meno essere conosciuta e rappresentata compiuta-mente appare essere una questione più prettamente filosofica che informatica e certo la rispostaad una simile questione non muterebbe in alcun modo lo studio attuale. Interessa però tenerememoria della questione in sé, perché ribadisce l’essenzialità di un momento di verifica che si stavia via palesando come imprescindibile. Anche in questo caso infatti, come era di fatto avvenutoparlando si safety property, si ha l’impressione che la bontà dell’intera disamina, in questo casola RE, dipenda dal grado di conoscenza posseduto e che la tecnica in sé, anche se svolta in modoimpeccabile, non sia sufficiente per garantire un risultato corretto. Nel prossimo paragrafo appro-fondiremo questo aspetto, mostrando come i principi di ignoranza vigente su certi elementi di unprogetto e di evoluzioni conseguenti inattese siano caratteri strutturali del design di un sistema erichiedano un approccio e uno studio specifici.


1.4 I L P R O B L E M A D E L L’ I G N O R A N Z A

La disamina condotta sin ora ha mostrato come sia un’analisi precoce, come quella fatta nellaRE, sia un’analisi attuata a progetto quasi-completo, come la verifica di proprietà globali, sonocaratterizzate da un’incompletezza di fondo identificabile con una qualche deficienza conoscitivasui componenti, sulle loro interazioni o sull’ambito d’uso.

Il design di un sistema, ma in realtà tutto il processo di sviluppo che parte dall’analisi dellarealtà contingente, dovrebbe pertanto cercare di prendere in considerazione tale problematica,approntando magari un momento di analisi specifico che cerchi di approssimare se non la quantità,almeno la natura e la geografia dell’ignoranza presente nel progetto.

La tesi approfondirà proprio questa problematica, cercando di capire quali sono i bound conosci-tivi cui dobbiamo sottostare e quale ruolo possa assumere un’analisi dell’ignoranza all’interno delprocesso di sviluppo di un sistema. Prima di calarci in una simile disamina, riteniamo interessanterichiamare alcuni articoli limitrofi a queste problematiche, che ci consentiranno di sottolineare lacriticità delle considerazioni offerte e di introdurre il concetto chiave dell’intero lavoro: quello diemergenza.

1.4.1 Studiare L’Ignoranza

L’idea che alla base del malfunzionamento di un sistema non vi siano errori progettuali, quantopiuttosto la presenza di informazioni non possedute, pur non trovando grande spazio nella lettera-tura del settore, non è nuova. Pare interessante sottolineare in modo particolare l’apporto dato in[13].

L’articolo trae spunto dall’idea che la qualità di un progetto, intesa come dependability as-sociata, sia diretta conseguenza dell’incertezza connessa ad alcuni momenti dello sviluppo delmedesimo. Si sottintende in pratica che ognuno dei passi che si susseguono nello sviluppo di unsistema contenga, ipoteticamente, un grado di incertezza e che tali misconoscenze risultino, unavolta che l’architettura è ultimata, in funzionalità deficienti o totalmente assenti.

La soluzione proposta considera il ricorso a Bayesian Belief Networks (BBN) [20] [21], struttu-re tipiche di discipline come l’Apprendimento Automatico o, in generale, l’Intelligenza Artificiale.I BBN risultano infatti strumenti:

• sufficientemente semplici da utilizzare, poiché basati su di un approccio grafico user friend-ly;

• molto potenti, con ottime proprietà di estrazione di informazioni nascoste.

L’ipotesi che gli autori portano avanti è che ogni passaggio (formalizzazione dei requisiti, imple-mentazione, ricorso a metodi formali, etc.) tipico del processo di sviluppo possieda un grado diincertezza caratteristico e aggiunga tale apporto al grado di incertezza collettivo del progetto di-minuendo, di conseguenza, la QoS del medesimo. In particolare si suggerisce che ogni metricatipica della QoS, come la reliability, sia caratterizzata da una BBN specifica, cioè da uno speci-fico modo di relazionare le conoscenze a priori degli sviluppatori e le varie fasi di progetto; perogni framework e per ogni metrica d’interesse diviene pertanto possibile calcolare l’incertezzaassociata. Il calcolo fa riferimento a dei dati particolari, in parte soggettivi, come l’esperienzadello staff o la complessità del problema, in comunione con i gradi di incertezza delle singole fasi,quantificati applicando la metodologia dei BBN a un numero sufficiente di casi di studio.

1.4 I L P R O B L E M A D E L L’ I G N O R A N Z A 15

Al di là della soluzione specifica, che, come si vedrà, differisce sostanzialmente da quella of-ferta in questo studio, è interessante osservare come negli ultimi anni si stia facendo largo laconsapevolezza di non poter tendere ad una metodologia scevra da imperfezioni e che ad ogni si-stema, o meglio alle sue componenti, sia associata una “zona d’ombra”, la cui natura deve esserenecessariamente tenuta in considerazione

Fenomeni Emergenti

L’importanza del grado di incertezza cui abbiamo accennato in precedenza si palesa pienamenteladdove si vadano a considerare proprietà globali. Emblematico in questo senso è [22], in cuisi sottolineano le peculiarità di una proprietà come la safety. Nel loro lavoro Blake e Koopmanarrivano a sviluppare una tesi che può essere riassunta nella seguente:

“La safety è una proprietà globale del sistema non ricavabile dalle proprietà dei componenti.”

Alla safety viene pertanto dato il nome di proprietà emergente, dove con tale termine si indica lamancanza di una dipendenza diretta tra lo strato dei componenti e quello del sistema consideratonella sua interezza.

La considerazione chiave di Blake e Koopman, e che costituisce in effetti anche la genesi ditutto il nostro lavoro, è che ogni sistema, per quanto attentamente sviluppato possiede dei compor-tamenti inattesi che accrescono l’insieme delle caratteristiche funzionali del medesimo, talvoltainficiando alcuni requisiti d’interesse. E’ solamente sotto questa ottica che si è in grado di giustifi-care la manifestazione di taluni malfunzionamenti, espressione di interazioni che si supponevanoininfluenti o di comportamenti considerati inaccadibili.

Fenomeni Emergenti: Un Esempio

Per esplicitare meglio le ragioni che ci spingono a sottolineare l’importanza di uno studio checonsideri queste tematiche prendiamo spunto da un esempio presente in [12].

Figura 1: Markov Chain esemplificativa di un sistema elementare.

Parlando di Design For Validation, gli autori presentano il design proposto in figura 1, sottoli-neando come sia necessario considerare non solo i tassi di fallimento (indicati con f), ma anche lapossibilità che il sistema si accorga o meno del fallimento avvenuto (condizione indicata dal rateC).

In un’ottica emergente, la rappresentazione corretta del sistema dovrebbe essere quella propostain figura 2, dove la precedente è arricchita di un quinto stato indicante il possibile accadimento diun evento inatteso (con tasso, ovviamente, non conosciuto).


Figura 2: Markov Chain esemplificativa di un sistema potenzialmente emergente.

L’esempio è molto elementare, ma serve a sottolineare come un sistema non transisca unica-mente tra stati noti, ma sia caratterizzata da operazioni ignote e, forse, non conoscibili.

1.5 S VO L G I M E N TO D E L L AVO R O

Nel corso del capitolo abbiamo proposto una prima panoramica dell’ambito in cui si muoveràla tesi. In particolare abbiamo approcciato le problematiche inerenti lo sviluppo di un sistema(in particolar modo software), mostrando come il passaggio dai desiderata di un cliente ad unprodotto finito sottintenda particolari criticità spesso sottovalutate. Nell’ottica di uno studio voltoad analizzare la realizzazione e il mantenimento di specifiche proprietà, abbiamo approfonditodue tecniche, i metodi formali e la requirement engineering, che si prefigurano come soluzionitipiche degli ambiti osservati.

Lo studio di entrambe le tecniche ha permesso di evidenziare come la semplice correttezzadell’applicazione del metodo non garantisca un risultato corretto; il problema, come abbiamovisto, è l’inevitabilità di tutta una serie di assunzioni, volontarie o inconsce, che minano alla baseil comportamento funzionale del prodotto. Il problema appare essere una latente, ed erronea,fiducia che il progettista tende a riporre nella qualità della propria interazione con la realtà chesta analizzando. E’ un duplice problema di qualità dell’interazione vigente: da un parte si tende,per convenzioni sociali, superficialità o scarsa conoscenza dell’ambito di studio, a fare assunzioniche si rivelano inesatte; dall’altra, c’è il problema della completezza dell’informazione addotta,in cui errori presenti nel prodotto finale sono figli di informazioni trascurate o di un mancatoapprofondimento della natura e del comportamento di un certo componente/sottosistema.

Il proseguo dello studio cercherà di approfondire questo secondo aspetto. Se infatti le metodo-logie di lavoro considerate, ma anche altre proposte nel corso degli anni, sono in grado di assistereun progettista nel rilevamento e nella correzione di situazioni di inconsistenza tra requisiti o trarequisiti e realtà esterna, poco o niente è stato fatto nell’ottica di una disamina dell’apporto cheuna deficienza informativa può indurre nel risultato finale di un progetto. Indicheremo l’evidenzadi situazioni erronee derivanti da tale condizione con il termine di emergenza e cercheremo du-rante tutto lo studio di approfondirne la natura; cercando di indagarne l’origine, lo sviluppo, lepossibili tecniche di individuazione e risoluzione e contestualizzandone l’apporto in due ambitimassivamente diffusi nell’informatica odierna, i COTS e i Web Services.

La tesi si svilupperà come segue. Anzitutto nel capitolo 2 porremo le basi della nostra analisi,descrivendo un framework, KAOS, che consente di effettuare RE con orientamento GORE. Talestrumento ci servirà, da un punto di vista didattico, come ausilio per accompagnare la trattazione,

1.5 S VO L G I M E N TO D E L L AVO R O 17

oltreché come strumento sostanziale per giustificare alcune soluzioni che proporremo, in quantotalune strutture tipiche del framework si riveleranno molto utili nella trattazione dell’emergen-za. Dal capitolo 3 in poi tratteremo il concetto di emergenza, iniziando dalla sua genesi in altrediscipline sino a formalizzarlo compiutamente in rapporto alla scienza informatica. L’analisi con-sidererà la sua influenza in relazione al testing (capitolo 4) e mostrerà come, una volta verificatala presenza di condizioni emergenti, si possano approntare tecniche risolutive (capitolo 5). Nelcapitolo 6 un caso di studio mostrerà come, all’atto pratico, il ricorso ad un’analisi emergentemigliori significativamente la QoS del sistema sviluppato. Infine, nel capitolo 7, apriremo unabreve parentesi per esaminare due tipologie di componenti software in cui l’emergenza svolge unruolo cruciale.

Capitolo 2La Goal-Oriented RequirementEngineering e KAOS

“Il segreto di ogni vittoriarisiede nell’organizzazione diciò che non è ovvio.”

Marco Aurelio

Nel capitolo precedente abbiamo introdotto il concetto di requirement engineering cercando ditratteggiarne le problematiche tipiche e di qualificarne l’apporto nell’ottica dello sviluppo di unsistema che goda di certe proprietà sistemiche. In questo capitolo approfondiremo quest’ambitodi studio, analizzando più a fondo le modalità di lavoro proprie di un processo di RE e descrivendola strada che ha portato a sviluppare il concetto di goal. L’essenzialità di tale concetto è legataall’importanza che l’approccio derivante, GORE, rivestirà all’interno della tesi.

Terminata la prima parte del capitolo, focalizzata appunto sulle nozioni di goal (sezione 2.1)e sull’approccio goal oriented (sezione 2.2), dettaglieremo il principale framework sviluppato inquesto ambito: KAOS (sezione 2.3). La disamina del suo linguaggio permetterà infatti di prendereconfidenza con tutta una serie di nozioni, ma anche strutture e metodi, che utilizzeremo diffusa-mente nei prossimi capitoli; essi costituiranno infatti gli strumenti chiave per la manipolazionedelle dinamiche emergenti.

2.1 L A R E Q U I R E M E N T E N G I N E E R I N G

In questa prima parte del capitolo cercheremo di palesare le trasformazioni storiche occorse nel-l’ambito della RE che, negli anni, hanno portato all’introduzione del concetto di goal. A tale scopoapriremo una importante parentesi relativa ai requisiti funzionali e non funzionali, rappresentandoquesti ultimi l’ambito in cui è nato e si è sviluppato il concetto stesso di goal e di elaborazione deigoal.

19

20 L A G O A L - O R I E N T E D R E Q U I R E M E N T E N G I N E E R I N G E K AO S

Quattro Punti Chiave Per La RE

Possiamo individuare quattro questioni essenziali che hanno sempre caratterizzato la ricerca delmiglior modello di raffinamento dei requisiti:

1. quali aspetti modellare nell’ottica WWH (why-what-how);

2. come modellare tali aspetti;

3. quale formalismo adottare per la definizione di tali aspetti;

4. secondo quali processi ragionare sul modello sviluppato.

La risposta alla prima problematica identifica quella che potremmo indicare come l’ontologiadelle unità concettuali da sviluppare. Si deve in sostanza qualificare il vocabolario di base dautilizzare per costruire il modello, in termini di: eventi, goal, operazioni, agenti, dati grezzi, etc.

La risposta alla seconda questione definisce le correlazioni che potranno caratterizzare le unitàaccennate in precedenza: sia in termini di interazioni tra unità appartenenti alla medesima cate-goria; sia transendo tra categorie differenti, cioè passando da una vista del sistema ad un’altra.Fanno parte di questa categoria le scelte relative alle relazioni di input/output, le regole di trigger,le generalizzazioni e i raffinamenti, ma anche le problematiche di assegnamento di responsabilità,etc.

La terza questione è relativa al formalismo specifico che si intende adottare [19]. Deve esserespecificato in dettaglio il linguaggio, formale o semi-formale, che si vuole utilizzare, sia per quan-to riguarda la rappresentazione degli elementi del modello, sia per quanto riguarda le proprietàche dovranno caratterizzare il sistema che si sta sviluppando. Definito il formalismo si dovrannoprovvedere opportune regole per il suo trattamento (da qui la quarta problematica esposta).

In questa prima parte del capitolo ci focalizzeremo sulle ultime due problematiche esposte: ladefinizione cioè di una forma, o più precisamente di una tecnica, di ragionamento che consentadi effettuare raffinamento, specifica e analisi della struttura formalizzata rispondendo alle questio-ni precedenti. In particolare osserveremo come, nell’ambito della RE, rivesta un ruolo sempremaggiore il ricorso a processi che seguano un approccio di tipo goal-oriented.

2.1.1 La RE Sino A GORE

La nascita della RE come campo di studio assestante può essere individuata in due articoli di Rosse Schoman del 1977. I due lavori sono da considerarsi complementari, occupandosi il primo didefinire i contorni e, in particolare, gli obiettivi della RE; il secondo, di proporre una metodologiarisolutiva specifica, SADT [23]. Da un punto di vista teorico i due studiosi introdussero giàin questo primo lavoro quelli che sarebbero poi divenuti i capisaldi dell’ontologia di una tipicatecnica di RE:

• goal;

• viewpoint;

• operazioni;

• agenti;

2.1 L A R E Q U I R E M E N T E N G I N E E R I N G 21

• dati grezzi.

È interessante sottolineare come SADT, figlio diretto di tale teoria, evidenziò una grande varietàdi elementi utilizzabili e un potere espressivo che altri linguaggi, proposti anche in seguito, nonpossedevano. La caratteristica chiave di questa tecnica può essere rintracciata nel suo naturaleorientamento a leggere il sistema come l’unione di due modelli differenti, ognuno pensato percaratterizzare al meglio una certa chiave di lettura del sistema. Si aveva:

• un modello per i dati;

• un modello per le operazioni.

I modelli si correlavano tra sé per mezzo di regole di consistenza. Oltre a questi due modellichiave, erano già presenti, se pur non sviluppati, concetti come quello di evento, di operazionedi trigger e di agente responsabile di un’operazione/trigger. Peraltro SADT si prefigurava comeun semi-formalismo capace di supportare il concetto di raffinamento iterativo, tramite il qualeun sistema in esame poteva venir sviluppato in sotto-sistemi più dettagliati. Abbiamo parlato disemi-formalismo in quanto pur richiedendo una rigida formalizzazione dei dati, delle operazionie delle interazioni tra i medesimi, non era ancora presente alcun meccanismo che consentisse didescrivere i requisiti stessi in modo univoco (di fatto erano espressi in linguaggio naturale).

Negli anni successivi furono sviluppate un numero sempre crescente di tecniche pensate per ar-ricchire le capacità operative di SADT. In particolare si osservò il proliferare di tecniche fondatesu diagrammi Entità-Relazione (ER), per la modellazione dei dati, e su diagrammi Transition-State per la specifica delle operazioni eseguibili dall’utente. Queste tecniche godettero inizial-mente di una crescente popolarità, dovuta alla semplicità realizzativa che le contraddistingueva;d’altra parte, ben presto, ci si accorse che esse possedevano limiti troppo stringenti, in partico-lar modo per quanto riguarda la ricchezza espressiva, decisamente limitata dalla scarsa ontologiasottostante (sia in termini di strutture, che di correlazioni). Peraltro tali tecniche, erano ancorasemi-formalismi, definiti spesso in modo ancor più ambiguo di SADT.

Bisogna aspettare la definizione di Requirement Modeling Language (RML) per osservare unreale passo avanti nello sviluppo di linguaggi per la RE. L’apporto dato da RML può essereriassunto in due elementi chiave:

1. formalizzò strutture complesse per la generalizzazione, aggregazione e classificazione deirequisiti;

2. arricchì e standardizzò il concetto di costanti (soprattutto temporali).

L’ultima grande innovazione introdotta in questo ambito (prima dell’introduzione dei processigoal-oriented) può essere considerata l’introduzione degli agenti. In effetti il concetto di agenteera già presente in SADT, solo nella seconda metà degli anni ’80 però si iniziò a considerareimprescindibile la presenza di elementi atti a rappresentare i componenti attivi del sistema. Lapresenza di tali elementi attivi introdusse tutta una serie di problematiche che possono essereriassunte nell’espressione: agent-based reasoning. Un framework che accetti e possieda al suointerno il concetto di agente deve in sostanza provvedere opportuni formalismi atti a modellar-li, definirne l’interfaccia, limitarne il comportamento in relazione alle costanti del sistema, etc.L’orientamento agent-based rimarrà un elemento imprescindibile per lo sviluppo delle successivetecniche di RE: di fatto i concetti di goal e di assegnamento di responsabilità, altro non sono cheuna sua estrema evoluzione.


2.1.2 Requisiti Non Funzionali

Prima di addentrarci nella disamina dello sviluppo goal-oriented, è necessario aprire una parentesiessenziale riguardante i requisiti non funzionali (NFR). Di fatto, l’attenzione data negli ultimi annial concetto di goal e, in particolare, a tecniche che consentissero la manipolazione di tali costrutti,è quasi interamente dovuta alla volontà di strutturare una metodologia valida per il trattamentodegli NFR.

Abbiamo già accennato nel capitolo introduttivo alla natura dei requisiti non funzionali e, ineffetti, tali costrutti si possono considerare come elementi basici di una qualsiasi analisi qualitativadi un sistema, fatto che ha portato negli anni alla presenza di una sempre più vasta letteraturarelativa. Nonostante tale interesse non è possibile rintracciare una definizione universalmenteaccettata del concetto di NFR; tale deficienza è probabilmente figlia della variegata natura diquesto concetto in cui ricadono tutta una serie di proprietà assolutamente eterogenee tra loro. Ingenerale, e operando probabilmente un abuso di notazione, possiamo affermare che un NFR è unrequisito sistemico, o specifico di un componente, che non riguarda direttamente la realizzazionepratica di una funzione del sistema, o del componente.

Rientrano in questa definizione: maintainability, usability, traceability, security, costi, perfor-mance, reliability, etc. In sostanza, tutte quelle proprietà che accrescono la Quality Of Serviceofferta.

Si capisce immediatamente pertanto come lo sviluppo di un sistema debba essere consideratocome un processo in cui alla realizzazione di certe funzionalità richieste dal customer, si affianca,parallelamente, un raffinamento atto a migliorare la qualità del prodotto. Tale essenzialità nelprocesso di design e sviluppo fa sì che i differenti NFR debbano, idealmente, essere individuati,separati e contestualizzati già nella prima fase di analisi del documento dei requisiti, o, al limite,in un momento sufficientemente precoce del processo di sviluppo: un progettista che approcciun problema dovrebbe, in sostanza, possedere una lista dei requisiti funzionali desiderati e, alcontempo, tenere in grande considerazione la lista degli NFR. Chiaramente però la complessità el’aleatorietà sottostante la natura stessa di tali requisiti fa sì che la loro individuazione sia tutt’altroche facile, al punto che spesso essa viene demandata quasi completamente ad un’operazione deltutto manuale, e assolutamente non formale, in cui si confronta il risultato dei colloqui con ilcliente, o al più le specifiche di un lavoro, con un elenco di possibili NFR [24], cercando dirilevare la presenza di questi ultimi.

Classificare Requisiti Non Funzionali

Sottolineata la criticità degli NFR è interessante capire se e come sia possibile sviluppare unformalismo atto a rappresentarli.

Una simile problematica ne sottintende naturalmente una di carattere diverso: come si classifi-cano i requisiti non funzionali. Prima di poter rappresentare un costrutto si richiede infatti sempredi possederere una sufficiente visione d’insieme della realtà da rappresentare, al fine di poternedefinire consapevolmente limiti e termini espressivi. Ancora una volta la vaghezza peculiare degliNFR fa sì che non esista una classificazione univoca.

Richiamando [25] potremmo considerare due aspetti.

• L’orientamento:

– consumer-oriented: di cui fanno parte i requisiti che esprimono un fattore di incremen-to qualitativo recepito in primo luogo dall’utente finale;


– technically-oriented: i cui requisiti sono invece relativi a criteri di qualità nello svilup-po stesso del software.

• Il contenuto:

– NFR qualitativi: in cui si esprimono proprietà generali di un prodotto;

– NFR quantitativi: in cui si offre una quantificazione della qualità desiderata (ad es, lareliability).

D’altra parte in altri articoli si propongono classificazioni del tutto differenti. Interessante è adesempio [24] in cui si distingue tra:

• NFR Dinamici: hanno a che vedere con concetti astratti (maintainability, portability, etc.);

• NFR Statici: si riferiscono ad un qualche tipo di informazione che deve essere presentata(accuracy, security, etc.).

Questa latente difficoltà nel classificare (ma anche nell’enumerare compiutamente) gli NFR si ètradotta in due caratteri peculiari delle tecniche di trattazione dei medesimi:

1. solitamente ogni tecnica è accompagnata da una classificazione propria;

2. le tecniche tendono a non dare particolare risalto al tipo di classificazione.

Rappresentare Requisiti Non Funzionali

Fondamentalmente le tecniche di manipolazione e trattamento degli NFR rispondono a due possi-bili esigenze:

1. affiancare alla rappresentazione tipica della struttura e delle funzionalità di un sistema, undocumento capace di dettagliare le proprietà non funzionali associate (in effetti la coesisten-za tra FR e NFR è un argomento topico del settore [26]);

2. guidare la scelta tra architetture/design alternative approntabili per la progettazione di unsistema.

Una soluzione molto conosciuta e appartenente al primo approccio è Language Extended Lexicon(LEL [27] [28]). LEL è stato introdotto per sopperire alla naturale ambiguità che caratterizza ilrilevamento e la formalizzazione degli NFR. Si propone in particolare di costruire un vocabolariodi riferimento in cui inserire, completi di una accurata descrizione in linguaggio naturale, tuttigli agenti che entreranno in gioco nel sistema da sviluppare. Il processo è iterativo e considerainizialmente un agente e la sua descrizione. Il principio guida per l’iterazione è che la descrizionedeve essere autoreferenziale in relazione al vocabolario. Pertanto, quando la descrizione di unoggetto contiene un termine non presente nell’Universo del Discorso (UoD), cioè un contestod’utilizzo, si procede ad inserirlo con la relativa descrizione. A conclusione del lavoro, datoun UoD, il LEL offrirà una descrizione completa degli agenti e dei requisiti richiesti, sia quellifunzionali che quelli non funzionali. La tecnica, pur nella sua complessità in termini di costi disvolgimento, appare interessante perché permette la formalizzazione di un documento dei requisiticompleto in cui FR e NFR coesistono per offrire una completa descrizione del sistema. Peraltro,i collegamenti ipertestuali presenti tra le descrizioni di un agente e gli altri agenti interni a tali


descrizioni, permettono di costruire grafi in cui i vari requisiti si correlano tra loro, offrendo alprogettista una visione d’insieme ottimale.

Al di là delle tecniche, comunque poco realizzabili all’atto pratico, volte a introdurre una rap-presentazione degli NFR da affiancare a quella tipica dei FR, molto spesso, gli NFR sono utilizzatiper distinguere qualitativamente la migliore architettura approntabile laddove vi siano più scelteeffettuabili. In effetti ogni progettista che si accinga a sviluppare un qualsiasi progetto, si trova difronte tutta una serie di possibili alternative che, considerando unicamente gli aspetti funzionaliche si intendono realizzare, non mostrano particolari differenze. Uno degli aspetti di maggiore in-teresse degli NFR risiede proprio nella loro propensione a qualificare differentemente sistemi che,dal lato funzionale, appaiono identici: un sistema che, ad esempio, svolga le medesime funzionidi un altro, ma che allo stesso tempo sia portabile e manutenibile, dovrebbe essere preferito. Inquest’ottica la soluzione maggiormente conosciuta fa ricorso, e anzi ne rappresenta il fulcro, alconcetto di goal. Nel prossimo paragrafo ci concentreremo proprio sulla disamina di tale politica,considerandola un passaggio obbligato prima di poter trattare compiutamente l’approccio GORE.

2.1.3 Trattare NFR Utilizzando I Goal

Chung et al. [29] [25] in una serie di lavori pubblicati verso la metà degli anni ’90 proposero unframework pensato specificamente per introdurre, nell’ambito della selezione tra architetture (odesign) alternative, il concetto di NFR.

La metodologia proposta offriva gli strumenti necessari per risolvere (quasi) tutte le problema-tiche legate alla rappresentazione di NFR.

1. Formalismo per la rappresentazione dei singoli NFR: come detto in precedenza, vieneintrodotto il concetto di goal, espressione di un singolo requisito non funzionale.

2. Utilizzo maturo delle informazioni legate all’architettura di design: si introducono i “me-todi”, intesi come modalità di correlazione tra i vari goal, espressione dell’architetturacaratterizzante un certo sistema.

3. Tradeoff tra le differenti alternative architetturali: tramite opportune “regole di correlazione”(rappresentate solitamente in forma tabellare), i collegamenti tra i goal sono arricchiti diinformazioni relative al rapporto vigente tra i goal stessi

4. Processo di valutazione continuo: si utilizzano etichette specifiche per decretare e mantene-re nel tempo gli effetti di certe scelte architetturali.

Rappresentare NFR Come Goal

Gli NFR vengono rappresentati come goal all’interno di un grafo: ma cos’è un goal? Formalmenteun goal non è altro che un nodo (generalmente di un grafo, ma sussiste anche isolato dal contesto)che esprime un certo requisito o una proprietà che si desidera. Nel caso del framework di Chunget al. i goal rappresentano ovviamente dei requisiti non funzionali, in particolare ogni goal:

• ha un nome, che rappresenta un NFR stesso;

• una lista di parametri, identificante i componenti (o il sistema) cui si riferisce;


• un livello di criticità, atto a sottolineare il suo ruolo all’interno del documento di specificadei requisiti.

I differenti goal si relazionano anzitutto per mezzo dei metodi. Esistono tre tipi di metodi: decom-posizione, soddisfazione e dettaglio. In particolare interessa sottolineare il ruolo della decomposi-zione: un goal può essere decomposto in goal figli da cui dipende la realizzabilità del NFR padre.Si introduce in sostanza il concetto di albero dei requisiti e, implicitamente, di raffinamento degliNFR in requisiti interpretati ad un livello di lettura più basso.

In figura 3 si può osservare un esempio di grafo degli NFR. Abbiamo un requisito padre (Mo-difiability applicato a tutto il sistema), che si specializza in requisiti figli correlati in AND tra loro(la cui realizzazione è cioè necessaria per il padre). Quello proposto in figura è ovviamente unrequisito in una fase iniziale di analisi:

• il raffinamento può continuare a piacimento;

• non è presente una tabella che indichi le regole di correlazione tra i differenti goal presenti.

Throughout the goal graph expansion process� the evaluation procedure propagates upwards� via labels ofnodes in the graph� the e�ect of each design decision from o�spring to parents� hence providing assessment of thedegree of goal achievement�

The labels include satis�ced �p�� denied �X�� and undetermined �� In our approach� goal assessment is

carried out by interaction between the evaluation procedure and the software architect who� by considering thecharacteristics of the intended application domain� makes the �nal decision on the label value to be propagated�

Figure � shows some of the rules used by the evaluation procedure� Notice that the propagation of a satis�ced

label along a strong negative satis�cing link results in a denied label�

� Architectural Design Process� Illustration

Our approach to supporting the process of architectural design is illustrated by the use of a KWIC systemwhich was formulated by Parnas ��

The KWIC �Key Word in Context� index system accepts an ordered set of lines� each line is an orderedset of words� and each word is an ordered set of characters� Any line may be �circularly shifted� byrepeatedly removing the �rst word and appending it at the end of the line� The KWIC index systemoutputs a listing of all circular shifts of all lines in alphabetical order�

The example is chosen since it is relatively well known� and used in several studies �by Parnas �� Garlan�Kaiser� and Notkin �� and Garlan and Shaw �� which provide a good illustration of tradeo�s among NFRsand design alternatives for the KWIC domain� However� it is used primarily as a �pedagogical� example in thispaper� so that we can illustrate the use of the NFR Framework for selecting among alternatives for architecturaldesign�

NFR Goals and Decomposition� For the purposes of illustration� assume that there is an initial set of NFRgoals� �the system should be modi�able� with good performance� and reusable�� The software architect mightrepresent these by Modifiability �System�� Performance �System�� and Reusability �System�� They areshown at the top of Figure � which depicts the situation but with more progress �Some parameters are omittedfrom the �gure�� Details will be explained as we move along� This is an initial set of NFR goals that the software

[Function]

[Process]

[System]

[Data Rep]

[Function][Function]

Modifiability

ModifiabilityModifiability

Extensibility

[Function]Modifiability

Deletability

Performance

Updatability

Reusability

TimePerformance

PerformanceSpace

Figure �� Initial stage of goal graph for KWIC architectural design �based on Garlan and Shaw��

architect starts with� if needs arise� she can add more NFRs during the process�After posting NFRs as goals to satis�ce� the software architect attempts to clarify them� as they �rstly can

mean many di�erent things to di�erent people� and secondly are too coarse to be put under analysis concerningtheir interactions� For example� security has di�erent shades of meaning in industrial and military contexts� andperformance can be decomposed into time and space considerations� For the purpose of clari�cation� the architectcan decompose each goal either on its sort or on its parameter �Figure �� The architect focuses on decomposingModifiability �System� on its parameter� After browsing methods in consultation with domain experts� the

Figura 3: Esempio di grafo rappresentante un insieme di NFR nel framework di Chung et al..

L’Importanza Del Framework

Al di là dei limiti, che ne hanno limitato significativamente l’adozione pratica, la proposta diChung et al. possiede innumerevoli meriti. Anzitutto ha un rilievo storico, essendo stato il primoframework significativo, cioè che abbia attratto l’attenzione di un sufficiente numero di studiosi,ad adottare il formalismo dei goal. In secondo luogo la proposta ha certificato, mettendoli alcentro del lavoro, due aspetti chiave nell’ambito della rappresentazione a goal:

1. i goal NFR non sono elementi assestanti ma, al contrario, interagiscono tra loro, in conflittoo in sinergia;

2. un goal NFR non è statico ma, mutando la profondità dell’analisi, può essere raffinatoinducendo la definizione e la correlazione di tutta una serie di goal figli.

Tali presupposti hanno un rilievo basilare, rappresentando di fatto, il cuore dell’approccio GORE.


2.2 L’ A P P R O C C I O G O R E

Pur non essendo stato il primo lavoro a trattare il concetto di goal (in letteratura si trovano ac-cenni in proposito già dalla seconda metà degli anni ’70) la proposta di Chung et al. rappresentòcertamente una spinta importantissima per lo studio di queste problematiche. Nel giro di pochianni apparvero una moltitudine di lavori incentrati proprio sull’elaborazione dei goal nell’ambitodella RE [30]: in relazione allo studio della completezza dei goal individuati; alla realizzabilità daparte di agenti e all’operazionalizzazione conseguente; alla risoluzione dei conflitti; al ruolo degliscenari; etc...

Nel corso della tesi la nostra attenzione verterà quasi completamente su di un particolare ap-proccio metodologico all’analisi e al trattamento dei goal, generalmente indicato con i terminiGoal-Oriented Requirement Engineering (GORE) e, in particolare, su di un framework sviluppatoproprio su tale base: KAOS.

In generale potrebbero ricadere sotto l’appellativo di processi GORE tutte quelle proposte che,anche in modo tangenziale, risolvono la RE tramite la manipolazione dei goal; nel nostro casoperò, utilizzeremo tale termine per riferirci all’approccio sviluppato da Lamsweerde nella secondametà degli anni ’90 [17] [31] [32] [33] [34] [35].

Formalmente possiamo pensare di definire l’approccio di Lamsweerde come segue.

Def. 6 (Goal) I Goal catturano, a differenti livelli di astrazione, i vari obiettivi che il sistema inesame dovrebbe raggiungere. [36]

Def. 7 (GORE) La Goal-Oriented Requirements Engineering (GORE) è un approccio alla REche ricorre al concetto di Goal per specificare, elaborare, strutturare, specializzare, analizzare,negoziare, documentare e modificare i requisiti. [36]

2.2.1 Formal Framework Vs. Qualitative Framework

Prima di proseguire nella descrizione di GORE interessa sottolineare la differenza sostanziale traquest’ultimo approccio e la proposta di Chung et al. vista nel paragrafo precedente.

Seguendo la classificazione offerta in [16], possiamo affermare che i due framework apparten-gono addirittura a categorie differenti, in particolare:

1. la proposta di Chung et al. è inquadrabile come Qualitative Framework;

2. mentre GORE è di fatto un Formal Framework.

La differenza tra le due tipologie di framework, che rappresentano le due tipologie possibili nel-l’ambito di un’analisi che ricorra a goal, risiede nei bound posti sul concetto di soddisfazione diun goal.

Parlando di Formal Framework ci si riferisce a soluzioni in cui:

• il raffinamento dei goal è ottenuto ricorrendo a grafi AND/OR, in cui ogni goal si relazionacon i subgoal e ogni goal è supposto essere necessariamente soddisfatto;

• i conflitti tra goal sono rappresentati tramite formalismi opportuni e, ove possibile, risolti;

• i goal sono generalmente arricchiti del concetto di operazione e si riferiscono pertanto aduno, o più, agenti responsabili.

2.2 L’ A P P R O C C I O G O R E 27

Un Qualitative Framework è una struttura similare, ma in questo caso si manipolano soft goal(laddove in precedenza si parlava di hard goal) [36]. Un soft goal, è un goal la cui soddisfaci-bilità è intesa non tanto come un presupposto ineluttabile del sistema, quanto piuttosto come undesiderata verso cui tendere; in contrasto, trattando hard goal ci si deve assicurare, anche tramiteopportune tecniche di verifica, che il requisito sia stato rispettato in toto. Introdurre soft goal si-gnifica presupporre requisiti che possono soddisfare solo parzialmente i goal proposti e, in ultimaanalisi, prevedere un raffinamento dei goal anche parziale. In pratica in un Qualitative Framework,e in effetti è ciò che avveniva nella proposta di Chung at al., i sub-goal possono contribuire sololimitatamente alla risoluzione di un goal e non hanno l’obbligo di tenere in considerazione gli altrisub-goal, con i quali potrebbero addirittura essere in conflitto. Opportuni formalismi aiuterannopoi lo sviluppatore a rappresentare tali condizioni di conflitto o di ingerenza.

2.2.2 Specificare I Goal

Terminata una prima, necessaria, contestualizzazione dell’approccio GORE vogliamo adesso ap-profondire l’analisi del concetto di goal, per poi caratterizzare le dinamiche di raffinamentosemi-automatico; l’aspetto probabilmente di maggior interesse dell’intero approccio

Inizieremo ovviamente la disamina considerando i formalismi che sottostanno alla definizionedi un goal.

Tipologie Di Goal

Come abbiamo visto nelle precedenti pagine, i modi in cui è possibile classificare i goal (ma ingenerale i requisiti tutti) sono molteplici, a seconda dell’asse di lettura che intendiamo seguire.Abbiamo già accennato a due possibili macro-categorie parlando della differenza tra FR e NFRe di quella tra soft goal e hard goal. D’altra parte, analizzando il problema dal lato agente, sipotrebbe pensare di introdurre “satisfaction goal”, atti a garantire il soddisfacimento di certe ri-chieste da parte di un agente, o di “information goal”, in cui si richiede il mantenimento di certeinformazioni in un agente.

In GORE si è scelto di utilizzare un orientamento particolare: l’asse di lettura consideratoconsidera infatti il comportamento temporale sotteso al goal in esame. Si parla pertanto di:

• “Achieve Goal” (risp. “Cease Goal”): in cui si richiede che la proprietà sottesa vengaraggiunta in un qualche istante di tempo futuro.

• “Maintain Goal” (risp. “Avoid Goal”): in cui si richiede che la proprietà sottesa vengamantenuta durante tutta la vita operativa del sistema.

La somiglianza con le strutture formali dei linguaggi logici per il trattamento di proprietà tempo-rali non è casuale; infatti, come vedremo parlando di KAOS, la volontà è quella di avvicinare laformalizzazione di un goal a quella di una tipica proprietà in logica simil CTL.

I goal caratteristici di un processo di RE possono essere tutti dedotti dalle precedenti categorie:

• Satisfaction Goal: altro non sono che Achieve goal relativi al soddisfacimento delle richie-ste di un agente.

• Safety Goal: sono Maintain goal in relazione al mancato arrivo in stati di hazard.


• Security Goal: sono Maintain goal che assicurano la mancata forzatura del sistema.

• Information Goal: sono Achieve goal atti a stabilire l’assegnamento di opportune informa-zioni ad un agente in relazione ai cambiamenti di stato.

Parametri Dei Goal

Al di là di una tipologia peculiare, i goal sono poi caratterizzati da tutta una serie di parametriaccessori:

• possiedono ovviamente un “nome” che li contraddistingue;

• hanno una specifica formale (che dettaglieremo in sezione 2.2.3);

• possono avere una priorità, utile nella risoluzione dei conflitti tra goal.

Oltre a queste specifiche proprie del singolo goal, vi sono poi i differenti link correlati al goal.

• Abbiamo anzitutto i collegamenti di raffinamento, utilizzati per organizzare i goal in gerar-chie e realizzare la relazione padre/figli.

• Il soddisfacimento dei goal dipende dal corretto svolgimento del lavoro di particolari agenti,con cui i goal si relazionano tramite link di soddisfacimento.

• I link possono poi essere utilizzati per correlare i goal con costrutti (parzialmente) esternicome le operazioni.

• Vi possono poi essere link atti a rappresentare conflitti tra goal.

Sono comunque ipotizzabili moltissime altre tipologie di link, che possono arricchire l’approccioGORE a piacimento.

2.2.3 Specifica Formale Dei Goal

L’apporto principale dell’approccio GORE all’intera area di studio dei goal risiede principalmentenel nuovo ruolo dato ai formalismi logici. Il presupposto da cui scaturisce tale rilettura è chel’intero procedimento di RE, per quanto possa venir raffinato e potenziato, conserva due limitistrutturali essenziali:

1. i requisiti espressi in linguaggio naturale sono troppo ambigui;

2. l’operazione di raffinamento è totalmente demandata alla soggettivita dell’ingegnere deirequisiti, il quale ha linguaggi sempre più ricchi, ma non ha strumenti per monitorare lacorrettezza del lavoro che sta svolgendo.

Entrambe queste limitazioni vengono affrontate introducendo una logica temporale utile a:

1. formalizzare univocamente ogni goal;

2. limitare le trasformazioni, intese come scissioni e raffinamenti, eseguibili sull’albero deigoal.


La Logica Di Riferimento

La logica adottata è una variante della logica CTL, che ha come scopo primario quello di poteresprimere proprietà temporali. Osserviamo l’alfabeto di riferimento.

• ♦: prima o poi nel futuro.

• �: prima o poi nel passato.

• �: sempre nel futuro.

• �: sempre nel passato.

• W (unless): sempre nel futuro “a meno che”.

• B (back to): sempre nel passato “a meno di”.

• U (until): sempre nel futuro “fino a”.

• S (since): sempre nel passato “da”.

Una siffatta logica permette di rappresentare le condizioni di nostro interesse. Se volessimo, adesempio, caratterizzare un “achieve goal” del tipo “se si verifica P dovrà accadere Q”:

P ⇒ ♦Q

Formalizzare Univocamente Un Goal

Si capisce immediatamente come uno strumento di questo tipo consente di descrivere in manieraformale, e quindi disambigua, un goal, liberandolo dai limiti del linguaggio naturale.

Consideriamo come esempio il seguente goal (tratto dal caso di studio di una miniera): “se siverifica un fallimento alla pompa di estrazione, la miniera deve essere evacuata entro un’ora.”

∀ p : pompa, m : miniera

p.failure ∧ Presente(p, m)⇒61h¬(∃minatore : Minatore) : Dentro(minatore, m)

Alla descrizione in linguaggio naturale, certamente più fruibile, cui accennavamo prima, ladefinizione di un goal in GORE affianca dunque una formalizzazione logica, utile a eliminarepossibili interpretazioni erronee.

Il Ricorso A Pattern Di Raffinamento

La descrizione formale di un goal rappresenta inoltre un valido strumento per guidare l’analistanel raffinamento del main goal. L’obiettivo è quello di eliminare dall’operazione di raffinamentoogni apporto soggettivo, trasformando la medesima in una vera e propria dimostrazione formale.

L’aver associato ad ogni goal una descrizione formale permette infatti di stabilire un criteriooggettivo per qualificare il rapporto vigente tra goal a differenti livelli dell’albero dei goal. Inaltre parole, il formalismo descritto offre i mezzi per dimostrare l’equivalenza tra un parent goaled i suoi sub-goal; dimostrare tale equivalenza significa reinterpretare ogni nodo dell’albero comeun passo della dimostrazione della correttezza del raffinamento svolto, potendo pertanto affermarecon certezza l’equivalenza tra l’insieme composto da tutti i goal foglia e il main goal. Dimostrare


tale equivalenza è un aspetto essenziale, in quanto permette di dire che se tutti i goal foglia sonosoddisfatti, è soddisfatto anche il main goal, cioè viene soddisfatto il requisito base del sistema.

In GORE la dimostrazione appena accennata viene sottesa per mezzo del costrutto dei patterndi raffinamento. L’idea è che, dato un goal, il numero di possibili raffinamenti dimostrabili correttiè limitato e, pertanto, è possibile offrire una casistica limitata da applicare ad ogni goal in esame.Individuata la categoria di un goal d’interesse, è sufficiente ricercare i possibili pattern applicabilie scegliere quello che meglio realizza il tipo di elaborazione che si intende effettuare. La correttez-za del metodo risiede nel fatto che ogni pattern utilizzabile è stato dimostrato in maniera formalee, pertanto, induce un raffinamento certamente corretto. Pertanto, un raffinamento che dal maingoal arrivi sino al livello di dettaglio desiderato per mezzo della sola applicazione dei pattern ècertamente corretto, nel senso che il progettista non ha inserito errori nella scomposizione deigoal.

Se consideriamo l’esempio precedente relativo all’achieve goal, possiamo pensare di applicareun pattern che inserisca un milestone intermedio, ottenendo i due nuovi goal (vedi figura 4):P ⇒ ♦R

P ∧ R⇒ ♦Q

Overview Requirements Elaboration in KAOS

Main Contributions 27

Finally we have applied our goal reduction/operationalization technique to develop complete KAOS mod-els including goals, constraints, actions, etc. for systems based on the concept of resource.

• Our third contribution allows one to reuse resource models on which a lot of systems rely.

These three main contributions are now reviewed in turn.

1.3.1 A Library of goal reduction patterns

Before describing the library of goal reduction patterns, we need first to define what an and-reduction con-sists of and what a goal reduction pattern looks like. Section 1.3.1.1 is devoted to this aim. NextSection 1.3.1.2 briefly explains how the reduction patterns have been identified. Section 1.3.1.3 illustratesthis process on an example. Section 1.3.1.4 surveys a set of operators that can be used to derive new reduc-tion patterns from existing ones. Finally, Section 1.3.1.5 introduces reduction tactics. They aim to guide theanalysts for selecting reduction patterns according to semantic criteria.

1.3.1.1 Preliminary Definitions

The following informal definition of an And-reduction is sufficient to understand what follows in this vol-ume. A more precise definition of this concept will be provided in Vol. 2.

Definition. Consider a goal G and suppose G has been decomposed into goals G1 and G2. G1and G2 are an and-reduction of G if the conjunction of goals G1 and G2 entail goalG, that is, if G1 and G2 are satisfied, then G is satisfied too.

When no ambiguity arises, the term reduction stands for and-reduction.

Definition. A (goal) reduction pattern is a one-level tree of abstract assertions such that the leafassertions are an and-reduction of the root one.

Example. Fig. 6 shows two reduction patterns. The first one identifies an intermediate milestone R to achieve Q from a state de-scribed by P. The second pattern identifies sub-cases P1 and P2 from which Q can be reached in order to satisfy the up-per goal.

1.3.1.2 Identifying Reduction Patterns

Our identification of reduction patterns has consisted of two consecutive phases:

• In the inductive phase, candidate reduction patterns were identified by abstracting goal reductions fromcase studies. Then each candidate reduction was proved correct using the proof theory of temporal logic

P ⇒ ◊ Q

P ⇒ ◊ R R ⇒ ◊ Q

P ⇒ ◊ Q

P1 ⇒ ◊ Q P2 ⇒ ◊ Q P ⇒ (P1 ∨ P2)

FIGURE 6 Examples of reduction patterns

Figura 4: Esempio di pattern applicabile ad un “Achieve Goal”.

Overview Requirements Elaboration in KAOS

Main Contributions 29

A candidate reduction pattern can be inductively identified by abstracting from the concrete domain. Thepropositional version of the candidate reduction pattern is:

This pattern can indeed be intuitively matched against the previous goals as follows:

• P stands for the antecedent of goal RequestSatisfiedForALibraryBook and of goal BookCop-yEventuallyAvailable; it also stands for the partial antecedent of goal AvailableBookRequestSat-isfied;

• Q stands for the consequent of goal RequestSatisfiedForALibraryBook and goal Available-BookRequestSatisfied;

• R stands for the consequent of goal BookCopyEventuallyAvailable and the partial antecedent ofgoal AvailableBookRequestSatisfied

Having a candidate reduction pattern, the following activity consists in trying to prove it. In fact, any at-tempt to prove the candidate pattern will fail because there is no way to derive from the first subgoal that(P ∧ R) will eventually hold (which is needed to prove the parent goal through entailment transitivity). Acondition requiring for instance that P holds continuously at least until R holds is missing here. In concreteterms, it means that a book request should be maintained until a book copy becomes available. Three newcandidate reduction patterns are generated; the two first ones strengthen the goal (P ⇒ ◊ R) by requiring

that P must hold continuously until R or Q becomes true. The third candidate requires that P holds forever.The second candidate is discarded because the first subgoal is just a strengthened version of the parentgoal. The proof of the first candidate is easy. It relies on the fact that if p and (p U q) hold, then (◊ q) holdstoo. The third candidate is more complex to prove. It requires the proof of an auxiliary lemma in Annex C.

Proof (first candidate)

1. P ⇒ (P U (P ∧ R)) Hyp

2. P ∧ R ⇒ ◊ Q Hyp

3. P Hyp

P ⇒ ◊ Q

P ⇒ ◊ R P ∧ R ⇒ ◊ Q

P ⇒ ◊ Q

P ⇒ (P U (P ∧ R)) P ∧ R ⇒ ◊ Q

P ⇒ ◊ Q

P ⇒ (P U (P ∧ Q)) P ∧ R ⇒ ◊ Q

P ⇒ ◊ Q

P ⇒ ❑ PP ⇒ ◊ R P ∧ R ⇒ ◊ Q

Figura 5: Altro esempio di pattern applicabile ad un “Achieve Goal”.

Prendendo in considerazione un esempio più complesso potremmo pensare di applicare ilpattern di figura 5, la cui correttezza è dimostrata in tabella 2.

2.2.4 Perché Utilizzare I Goal?

Dovrebbero a questo punto apparire evidenti i vantaggi legati all’adozione di un formalismo rap-presentativo che ricorra ai goal. Prima di proporre un elenco dei principali è però necessariosottolineare i caratteri distintivi di due concetti che, a prima vista, potrebbero apparire equivalenti.

Abbiamo offerto in precedenza la definizione di goal, indicando l’insieme dei goal come latotalità degli obiettivi che il sistema dovrebbe realizzare. Il documento di specifica dei requisiti(DSR) è, invece, un concetto più vasto in cui gli obiettivi da raggiungere sono solo una partedel contenuto. Utilizzando le parole di Ross & Schoman possiamo definirlo: “un documentodi specifica dei requisiti deve motivare la necessità di un sistema, ... .Esso deve spiegare quali


1 P ⇒ (PU(P ∧ R)) (ipo.)2 P ∧ R⇒ ♦Q (ipo.)3 P (ipo.)4 PU(P ∧ R) (1,3 - MP)5 ♦(P ∧ R) (3,4,def. Until)6 ♦(P ∧ R)⇒ ♦♦Q (2,♦ − monotonicità)7 ♦(P ∧ R)⇒ ♦Q (♦-idempotenza)8 ♦Q (5,7 - MP)9 P ⇒ ♦Q (3,8)

Tabella 2: Dimostrazione del pattern di figura 5.

feature il sistema dovrà offrire, in funzione anche del soddisfacimento del contesto di utilizzo.Inoltre, esso deve dettagliare le modalità di costruzione del sistema stesso”. Il DSR si proponepertanto come il risultato della fase di requirement engineering, di cui i goal altro non sono chel’input iniziale. Ribadita questa distinzione essenziale, possiamo adesso sintetizzare i principalivantaggi correlati all’adozione di un approccio che utilizzi il formalismo dei goal.

Anzitutto i goal offrono un criterio preciso per stabilire condizioni sufficienti [36] per verificarela completezza di un DSR: un DSR è completo rispetto ad un insieme di goal, se tutti i goalsono dimostrabili (cioè vengono verificati) considerando unicamente il DSR e le proprietà notedel dominio in esame.

Peraltro essi offrono anche un criterio per la verifica della pertinenza dei requisiti di un DSR, al-tro problema topico nell’ambito della RE. In particolare, un requisito di un DSR è detto pertinenterispetto ad un insieme di goal nel dominio d’uso, se la sua specifica è alla base della realizzabilitàdi uno dei goal.

La caratteristica organizzazione ad albero dei requisiti è poi un valore aggiunto nell’ottica dellacomunicazione con gli utenti finali (o anche con futuri sviluppatori del medesimo progetto). Ta-le organizzazione gerarchica consente infatti di palesare facilmente i desiderata del software inessere e di descriverli a vari livelli di lettura; senza considerare il fatto che, di fatto, l’approcciotramite goal incrementa significativamente la tracciabilità del progetto.

Una RE sviluppata tramite goal tende naturalmente a considerare l’analisi di design o raffi-namenti alternativi. Questo consente di sviluppare un DSR che consideri già alcune alternativepossibili, permettendo al progettista di considerare differenti aspetti e scegliere la soluzione cheritiene più performante o più adatta all’ambito di studio.

Peraltro utilizzare i goal induce implicitamente ad adottare tecniche di analisi e risoluzione deiconflitti tra goal, fatto che porta a risolvere facilmente anche i conflitti, spesso consistenti, tra idifferenti user interessati al sistema.

Infine si fa notare come la distinzione stessa, su cui ci siamo soffermati in precedenza, tragoal e requisiti presenti nel DSR è un apporto significativo. In sostanza utilizzare goal significacreare un sovra-livello stabile oltre i requisiti, che sono notoriamente volatili e mutevoli nel tempo:raffinamento di un requisito, adozione di differenti soluzioni per risolvere il requisito, etc... sonotutte condizioni che mutano il requisito stesso, ma che non alterano in alcun modo goal sistemici.Effettuare tale distinzione permette pertanto di mantenere un livello stabile e immutabile durantetutto il corso della RE.


Quando Esplicitare I Goal

Per quanto detto sin ora si potrebbe pensare che il raffinamento dei goal sia un’operazione rele-gata ad una primissima fase di sviluppo di un sistema: in sostanza, essa rappresenterebbe, e silimiterebbe, ad un’identificazione dei requisiti effettuata ancora prima della stesura del DSR.

In realtà l’individuazione dei goal è un processo che prosegue durante tutto lo svolgimentodella RE: raffinamento dei goal, stesura del DSR e implementazione sono, di fatto, tre fasi instretta correlazione e che si scambiano feedback continui.

2.3 K AO S

Le considerazioni sin ora offerte nel corso del capitolo sono servite per contestualizzare al megliol’ambito d’uso in cui si innesta il framework al centro della nostra analisi: KAOS.

KAOS può essere considerato come un linguaggio di definizione atto a completare e formaliz-zare l’approccio GORE. Il primo a standardizzare l’essenza del linguaggio è R. Darimont nellasua tesi di dottorato [37] nel 1995, anche se per la versione definitiva (o, almeno, quella attuale) sidovrà attendere sino al 2001, anno in cui E. Letier raffina l’intero progetto (anch’egli nell’ambitodel suo lavoro di dottorato [38]).

Scopo di KAOS, rappresentando esso stesso la realizzazione pratica di una tecnica GORE, èl’individuazione e il raffinamento dei requisiti di un sistema. L’importanza di tale frameworkrisiede però nel fatto che il suo apporto non si esaurisce nella mera definizione dei requisiti,ma, accanto all’albero dei goal d’interesse, vengono costruite tutta una serie di strutture utiliall’implementazione vera e propria del sistema, in particolare:

1. il modello agenti esemplifica i componenti (o i soggetti umani) che dovranno occuparsidella realizzazione dei goal;

2. per ogni assegnazione di responsabilità ad un agente, viene formalizzata anche l’operazionetramite la quale l’agente realizzerà il goal;

3. vi è un attento studio della fattibilità e delle incongruenze tra i goal.

Già questa prima breve enunciazione delle feature offerte dovrebbe aver permesso di intuire chele dimensioni del framework sono assolutamente significative. Al fine di mantenere la trattazionecoerente con il resto del lavoro, e per evitare un approfondimento eccessivamente esteso, abbiamodeciso di limitare la disamina del framework a pochi aspetti essenziali per il proseguo della tesi.In particolare prenderemo in considerazione:

1. il modello dei goal, in cui è dettagliato il formalismo sottostante la definizione dei goal e leregole di correlazione tra i medesimi;

2. il modello agenti, che consentirà di associare ad ogni goal un agente responsabile e permet-terà di definire un criterio di terminazione del raffinamento;

3. la obstacle analysis, cioè l’analisi degli impedimenti che potrebbero minare la realizzazionedi un goal.

2.3 K AO S 33

2.3.1 Il Linguaggio Di KAOS

Il linguaggio utilizzato da KAOS è un linguaggio multiparadigma, in cui differenti modelli sirelazionano tra loro, per mezzo di opportune regole di consistenza inter-modello. In figura 6 èpossibile osservare i differenti modelli presenti, con le relative regole di consistenza.

• Goal Model (GM): in cui vengono modellati i goal del sistema.

• Object Model (OM): tramite il quale maneggiare gli oggetti (agenti, eventi, etc.).

• Agent Responsibility Model (ARM): che regola l’assegnamento di responsabilità di un goalad un agente.

• Agent Interface Model (AIM): atto a definire l’interfaccia agenti.

• Operation Model (OP): atto a definire le operazioni che gli agenti possono svolgere.

La nostra descrizione del framework KAOS si concentrerà proprio sulla natura e sulle intera-zioni tra questi modelli. La disamina di tali costrutti permetterà infatti di esemplificare appienoil funzionamento delle feature di nostro interesse, in particolare tutta la fase di individuazione,raffinamento e validazione dei goal.

Goal Model

Il modello dei goal (GM) è ovviamente il modello centrale dell’intero linguaggio, tramite il suoformalismo è infatti possibile dichiarare i requisiti che il sistema dovrà realizzare, solitamentetramite il ricorso ad uno o più agenti. In figura 7 si può osservare la formalizzazione del requisitoprimario richiesto nel caso di studio di uno Scheduler Meeting [33]: “il meeting d’interesse vieneinfine svolto, con la presenza di tutti i partecipanti desiderati.”

KAOS segue chiaramente le direttive presenti in GORE per quanto riguarda le informazionicaratterizzanti un goal, di conseguenza le strutture e i parametri presenti nel GM sono quellegià presentate nel paragrafo 2.2.3. Non ci soffermeremo pertanto molto sul modello, preferendodedicare un più ampio spazio alle novità introdotte da KAOS.

L’unico elemento d’interesse è una più matura, e in effetti in KAOS diviene un concetto fon-damentale, concezione dei conflitti tra goal [32]. Come suggerisce la parola stessa, un con-flitto tra goal indica la presenza di un sistema in cui sono stati definiti due requisiti che spin-gerebbero il sistema stesso a compiere due, o più, azioni differenti in risposta al medesimostimolo. Si pensi in tal senso ai due goal Maintain[PompaAttivaQuandoAcquaAlta] e Main-tain[PompaDisattivaQuantoLivelloMetanoCritico], individuabili nel case study [39]:

s.livelloAcqua > LivelloAcquaMassimo ∧ PompaInUso(s, p)⇒ p.Status = On

s.livelloMetano > LivelloMetanoCritico ∧ PompaInUso(s, p)⇒ p.Status = Off

Ovviamente i due goal non possono venir realizzati simultaneamente: quando il livello dell’ac-qua supera il livello critico e, allo stesso tempo, quello del metano supera il livello di metanoconsiderato critico, i due goal richiedono, il primo che la pompa sia attiva, il secondo che siadisattiva.

L’aver introdotto un rigido formalismo permette di rilevare, manualmente o, in parte, auto-maticamente, le situazioni di conflitto e di proseguire il raffinamento operando, al limite, sceltedifferenti.

34 L A G O A L - O R I E N T E D R E Q U I R E M E N T E N G I N E E R I N G E K AO SGoal-Oriented Requirements Engineering with KAOS

13

Object Model

PrtcptsCstrRequested

Goal Model

PrtcptsCstrKnown

AND

OR

AND

Prtcpt MeetingIntended

Agent Responsibility Model

Agent Interface Model

Operation ModelOperation SendCstrRequestDomPre ¬ CstrRequested(p,m)DomPost CstrRequested(p,m)ReqTrig For PrtcptsCstrRequested

Intended(p,m)

FIGURE 3.1. Overview of the KAOS models

ConvenientMeetingHeld

PrtcptsInformedConvenientMeetingPlaned

AND

Scheduler

InitiatorOR

Scheduler

Initiator

PrtcptCstrRequest

Intended

... ...... ...

inter-modelconsistency rule

Figura 6: Modelli del linguaggio di KAOS.

2.3 K AO S 35

24

Goal-Oriented Requirements Engineering with KAOS

3.2.4 The Goal Model

Having introduced the conceptual modelling framework and the temporal assertionframework, we now detail the various submodels that together define a KAOS model.

3.2.4.1 Defining Goals

As mentioned before, a goal defines an objective the composite system should meet usu-ally through the cooperation of multiple agents. For example, a goal in a meeting sched-uling problem would be that each requested meeting is eventually held with the presenceof all intended participants. This ideal goal might be captured by the following specifica-tion fragment.

Goal Achieve[ConvenientMeetingHeld]

Definition each requested meeting is eventually being held with the presence of allintended participants.FormalDef ∀ m: Meeting:m.Requested⇒ ◊m.Holds∧ (∀ p: Participant): Intended(p,m) → Participates(p,m)

Each goal has aname, a natural languagedefinition, and an optionalformal definition.The above goal is namedAchieve[ConvenientMeetingHeld] (the Achieve verb is a key-word that will be explained below).

A goal defines a set of admissible histories in the composite system. Intuitively, an his-tory is a temporal sequence of states of the system. Each goal is satisfied by some histo-ries and falsified by some other histories. The notation

h |= G

is used to express that historyh satisfies the goalG.

The definition of a goal is a natural language statement describing the set of histories sat-isfying the goal. The formal definition of a goal is a temporal logic formula describingthe same set of histories. (It is the specifier’s responsibility to ensure that the natural lan-guage and formal definitions of a goal describe the same property.)

3.2.4.2 Classifying Goals

A goal taxonomyis used to guide the acquisition and definition of goals. Goals are clas-sified according to their pattern and category.

The pattern of a goal is based on the temporal behaviour required by the goal. TheKAOS language distinguishes the following four goal patterns:

Achieve goals: goals requiring that some property eventually holdsCease goals: goals requiring that some property eventually stops to holdMaintain goals: goals requiring that some property always holdsAvoid goals: goals requiring that some property never holds

Goal patterns provide a lightweight way of declaring the temporal behaviour of a goalwithout writing formal goal definitions.

Figura 7: Esempio di formalizzazione di un goal in KAOS.

Definizione EsempioENTITA’ oggetto autonomo MeetingAGENTE oggetto attivo Scheduler, PartecipanteEVENTO oggetto istantaneo RichiestaMeetingRELAZIONE oggetto subordinato InvitatoA

Tabella 3: Tipologie di oggetti supportati dall’Object Model di KAOS.

Object Model

L’Object Model è il vero fulcro innovativo dato da KAOS: di fatto tutte le operazioni di raffina-mento e verifica sono in qualche modo correlate all’azione di un oggetto (spesso un agente).

Volendo dare una, pur approssimativa, definizione di oggetto, si può dire che “un oggetto è unqualcosa che può essere distinto univocamente” [38]. In KAOS si distinguono differenti tipolo-gie di oggetto, dipendentemente dall’autonomia, subordinazione e temporalità dell’oggetto (veditabella 3): entità, relazione, evento, agente.

Le Entità sono oggetti autonomi utili per definire compiutamente il vocabolario d’uso. In so-stanza ad ogni entità viene associato un nome ed una descrizione, al fine di eliminare elementi diambiguità dal sistema in uso (in modo similare a quanto avveniva utilizzando LEL, vedi paragrafo2.1.2). L’obbligo di associare una descrizione ad ogni oggetto (come vedremo la regola varrà in-fatti anche per le altre tipologie di oggetto) deriva dalla presenza di una regola base di consistenzatra oggetti e goal: “ogni elemento del vocabolario utilizzato per la definizione formale di un goaldeve essere dichiarato nell’object model.”

Un Evento è un oggetto istantaneo, come, ad esempio, la richiesta di una specifica azione.Anche in questo caso la formalizzazione è ottenuta meramente tramite l’assegnazione di un nomee di una definizione. Il concetto di evento è particolarmente importante in relazione all’utilizzodella logica, in quanto permette la definizione di proprietà temporali su azioni che il sistema hacompiuto o dovrà compiere.

Un oggetto Relazione è in effetti una vera e propria relazione matematica tra n oggetti: adesempio, tra i partecipanti ad un meeting e il meeting stesso.

Gli AgentiLa trattazione ha sin qui ignorato gli oggetti Agenti [35]. La dimenticanza non è casuale ed è fi-

glia della volontà di mettere in risalto il costrutto centrale, assieme ovviamente ai goal, dell’interoframework.


Gli agenti sono oggetti attivi, cioè oggetti capaci di svolgere un’operazione. La natura degliagenti può essere la più disparata: essi possono essere componenti hardware, moduli software oanche agenti umani addetti a svolgere un compito all’interno del sistema. Riprendendo l’esempiodel meeting sono agenti: lo scheduler, l’organizzatore del meeting, i partecipanti al meeting, etc.

Il particolare interesse suscitato dagli agenti risiede in due aspetti:

1. essi si relazionano con le operazioni, potendo pertanto garantire la soddisfazione di un goal;

2. ad essi sono associati attributi particolari che, come vedremo parlando dell’AIM, permetto-no di stabilire se si è raggiunto un sufficiente livello di raffinamento.

Agent Responsibility Model

Abbiamo visto nelle pagine precedenti come il principio base di un approccio GORE risiedanella possibilità di raffinare un goal sino a goal elementari e come il soddisfacimento del maingoal sia totalmente dipendente dal soddisfacimento dei goal terminali (i nodi foglia dell’alberodei goal). L’ARM risponde proprio alla necessità di stabilire un criterio di soddisfacimento pertali goal terminali, criterio che si traduce nell’assegnazione ad ogni goal terminale di un agenteresponsabile della realizzazione del goal in esame; assegnamento che si realizza per mezzo di unopportuno link di responsabilità. In figura 8 è proposto un esempio di raffinamento di un goal indue sub-goal con assegnamento di responsabilità per i subgoal.


35

3.2.6 The Agent Responsibility Model

The agent responsibility model is used to declare responsibility assignments of goals toagents. Responsibility assignments provide a criterion for stopping the goal refinementprocess. A goal assigned as the responsibility of a single agent must not be refined fur-ther.

3.2.6.1 Responsibility Links

Responsibility is an OR meta-relationship that links agents to goals.Responsibility linksdeclare potential responsibility assignment of goals to agents.

Examples of responsibility assignment are shown in Figure 3.6. In the figure, the goalAchieve[PrtcptsCstrRequested] is potentially assigned to theInitiator agentor to theScheduler agent. The goalAchieve[RequestedCstrProvided] is potentially assigned asthe responsibility of theParticipant agent.

Responsibility links have aSelectedattribute used to indicate which alternative responsi-bility assignments are actually chosen.

A goal effectively assigned to an agent in the software-to-be is then called aRequire-ment, whereas a goal effectively assigned to an agent in the environment is called anAssumption.

3.2.6.2 Instance declarations

At the outer-level, responsibility links declare the agent class responsible for the goal.Instance declarations attached to responsibility links specify more precisely whichinstance of the agent class is responsible for the goal instantiated to specific objectinstances. The following example illustrates the need for such instance declarations.Consider an air traffic system, and the goalMaintain[PlaneInRegionOnCourse] whosedefinition is given by

∀ pl: Plane, atc: AirTrafficController

InRegion(pl, atc) ⇒ pl.OnCourse

Achieve[PrctptsCstrRequested]

Achieve[PrctpsCstrKnown]

Achieve[RequestedCstrProvided]

Participant

Initiator

Scheduler

OR

Resp

Resp Resp

FIGURE 3.6. Responsibility assignments

Figura 8: Esempio di raffinamento di un goal con assegnazione di responsabilità ad agenti.

Chiaramente il mero ricorso ad un link di assegnamento rappresenta una soluzione troppo sem-plicistica per esprimere compiutamente tutto il contenuto informativo che potrebbe essere d’inte-resse in un caso simile. Si pensi ad esempio ad un controllore del traffico aereo: ovviamente taleagente è capace di risolvere un possibile goal MantenereAereoInTragitto, d’altra parte il il taskrichiesto non è quello di ritenere ogni controllore responsabile di ogni aereo che circola, ma piutto-sto di evidenziare aree di interesse per ogni controllore, all’interno delle quali esso è responsabiledi tutto il traffico aereo.

Il contenuto informativo precedente può essere espresso in KAOS al momento della specificaformale di un assegnamento di responsabilità. Ogni assegnamento infatti, non è limitato alla defi-nizione del link tra goal e agente, ma deve essere esaurito tramite una definizione più completa incui l’operatore Instance Declaration, permette di specificare le informazioni aggiuntive. Nel casodell’esempio precedente, una formalizzazione corretta potrebbe essere.

Responsibility [Controllore,Aereo]Instance Declaration “∀cr : Controllore, pl : Aereo”Responsibility[cr, InRegion(pl, cr)⇒ pl.OnCourse ]

2.3 K AO S 37

Agent Interface Model

Oltre all’introduzione del concetto di responsabilità, il secondo spunto d’interesse offerto dagliagenti in KAOS è rappresentato dall’introduzione di un’interfaccia di riferimento per ogni agen-te. L’interfaccia è utilizzata per dichiarare i parametri monitorati e controllati da ogni agente.L’assegnazione di responsabilità e pertanto le operazioni svolte dagli agenti, hanno infatti sensounicamente in relazione al controllo di taluni valori: i parametri monitorati devono in sostanzaessere intesi come input di trigger per l’effettuazione dell’operazione, mentre i parametri control-lati (cioè modificabili) rappresentano le quantità modificate dall’operazione stessa. Peraltro ogniagente può possedere variabili interne, cioè attributi controllati dall’agente e non monitorabili daaltri agenti.

Graficamente un’interfaccia agente è rappresentata da un context diagram (si veda figura 9),in cui gli agenti, identificati da un nome, si correlano per mezzo di link uscenti, per i parametricontrollati, ed entranti, per quelli monitorati.

42


TheMonitoring andControl links in the example above will be represented graphically asfollows.

Monitoring andControl are Or meta-relationships. Alternative agent interface models canbe represented. In the graphical view, alternative agent interface models are representedby separate, alternative agent interface diagrams.

3.2.8.2 Instance declarations

Instances declarations attached toMonitoring and Control links enable one to describemore precisely which agent instance monitors or controls the values of the attribute forwhich object instance.

For example, the instance declaration attached to the followingControl link declares thatthe scheduler instancesch scheduling the meetingm controls the date of that meting.

Control [Scheduler, Meeting.Date]InstanceDeclaration (∀ sch: Scheduler, m: Meeting):Scheduling(sch,m) ⇒ Ctrl(sch, m.Date)

TheMon andCtrl operators relate an agent instance to an attribute of an object instance.Instance declarations forMonitoring andControl links have the form

R(ag, o) ⇒ Mon(ag, o.Attr)R(ag, o) ⇒ Ctrl(ag, o.Attr)

whereR is a domain-specific predicate betweenag ando.

3.2.8.3 The “unique control” meta-constraint

TheControl meta-relationship must satisfy theunique control constraintrequiring that ineach alternative an object’s attribute is controlled by at most one agent.

At the outer-level of the language, the unique control constraint is defined as follows:

if Control(ag, Ob.Attr) then there is noag’ ≠ ag such thatControl(ag’, Ob.Attr).

At instance-level, the unique control constraint requires that the predicateR involved inan instance declaration of the form

R(ag, o) ⇒ Ctrl(ag, o.Attr)

satisfies the following condition:

R(ag, o) ⇒ ¬ (∃ ag’) ag’ ≠ ag ∧ R(ag’, o).

The unique control constraint is used to avoid interference problems between concurrentexecutions of agents.

The unique control constraint is an important and necessary feature of the language. It isnecessary to be able to assign goals as the responsibility of single agents. As an example,consider a goal requiring that a predicateP never holds:

❑ ¬ P

Initiator SchedulerMeetingRequest Meeting.Date

Figura 9: Esempio di modello agenti in cui si evidenziano le interfacce degli agenti.

Costruzione Delle InterfacceSi potrebbe essere indotti a pensare che la definizione di un interfaccia sia un’operazione total-

mente manuale: resasi evidente la necessità di un agente, si procede a definirne l’interfaccia inlinea con l’architettura dell’albero dei goal. In realtà vige una, pur ovvia, corrispondenza tra goale interfacce, che permette di automatizzare il processo.

Quando si definisce formalmente un requisito infatti si offrono tre tipi di informazioni:

1. si esplicita ovviamente il requisito stesso;

2. si individuano una serie di oggetti che in qualche modo (generalmente tramite un parametro)concorrono alla verifica del requisito;

3. spesso si offrono inoltre indicazioni sullo stato del sistema in un certo momento futuro, sidefiniscono cioè condizioni di uscita da un’operazione e, pertanto, parametri modificati.

La definizione delle interfacce è perciò una diretta conseguenza di una corretta definizione deirequisiti. L’obiettivo di tutto il framework è in effetti quello di concentrare quanto più possibile illavoro dell’ingegnere dei requisiti sullo sviluppo dell’albero dei goal, rendendo la creazione dellestrutture di appoggio (modello degli agenti, interfacce, operazioni, etc.) un’operazione quanto piùpossibile trasparente (o, comunque, immediata).

Controllo UnivocoVale una limitazione cui si è costretti ad attenersi maneggiando le interfacce: ogni attributo di

un oggetto può essere controllato al più da un agente.Tale regola di “controllo univoco” si rende necessaria per evitare problemi di interferenze tra

esecuzioni concorrenti di agenti. E’ evidentemente una regola molto restrittiva, d’altra parte nonlimita significativamente l’espressività del linguaggio, in quanto nella quasi totalità dei casi la


necessità di far controllare l’attributo da più agenti può essere risolta con l’adozione di due, o più,variabili controllate ognuna da un agente.

Operation Model

Un’operazione altro non è che una relazione input/output tra oggetti. In linea con quanto ci sipuò aspettare dal generico concetto di operazione, essa viene definita per mezzo di una serie dicondizioni.

1. pre-Condizioni: caratterizzano lo stato nel momento immediatamente precedente l’esecu-zione dell’operazione. Il Precondition Domain caratterizza l’insieme di tutti gli stati in cuil’operazione, ammesso che scatti il trigger, può venire applicata.

2. post-Condizioni: caratterizzano lo stato nel momento immediatamente successivo all’ese-cuzione dell’operazione. Il Postcondition Domain caratterizza lo stato all’uscita dall’opera-zione, in sostanza identifica le trasformazioni avvenute sugli input.

3. Regole di Trigger: identifica la condizione che deve verificarsi affinché l’operazione possaessere eseguita.

Di seguito viene proposto un esempio di operazione (ancora in relazione al caso di studio delMeeting).

Operation PianificazioneMeetingInput Meeting {arg m}PersoneInvitateLimitazioniImposteOutput Meeting/{Pianificato, Data}DomPre ¬ m.PianificatoDomPost m.PianificatoReqPostFor Maintain[DataMeetingAccettabile](∀ p:Partecipante): • PersoneInvitate(p,m)→m.Data /∈ • LimitazioniImposte[p,m].insiemeEsclusioni

In quest’esempio si caratterizza l’operazione di pianificazione del meeting. Dato un meeting,un insieme di persone invitate e opportune limitazioni imposte dai differenti soggetti interessati, siproduce un output in cui la data è decisa e il meeting viene etichettato come già pianificato. L’ope-razione consiste banalmente nella ricerca di una data che non appartenga all’insieme di esclusione(cioè alle date con impegni già presi) di alcun invitato. Ovviamente l’esempio fa riferimento ad ungoal che potrebbe, e probabilmente dovrebbe, essere ulteriormente raffinato, in questo caso peròinteressava unicamente l’aspetto didattico dell’esempio.

Atomicità Delle OperazioniVale anche in questo caso un’assunzione molto forte: tutte le operazioni sono intese atomiche.Laddove si debba obbligatoriamente modellare un’attività che si svolge in un lasso di tempo

prolungato, in cui magari si possono svolgere altre operazioni, è necessario effettuare una parcel-lizzazione. In particolare si procederà a introdurre un’operazione che indichi l’inizio dell’attività;una o più operazioni che ne caratterizzano una possibile fine; oltre all’aggiunta di un opportunoparametro che, nei goal interessati, evidenzi il fatto che l’operazione si sta svolgendo.

2.3 K AO S 39

2.3.2 Raffinamento Dei Goal

Descritti i modelli componenti il linguaggio di KAOS, possediamo adesso tutti gli strumenti ne-cessari per poter osservare e capire lo svolgimento di una analisi di RE effettuata con tale fra-mework. In particolare, i modelli dati consentono di caratterizzare compiutamente l’operazionepiù importante all’interno di KAOS: il raffinamento dei goal sistemici.

L’idea alla base del raffinamento in KAOS è quella di confrontare un goal con l’agente respon-sabile della sua realizzazione e stabilire se tale agente è effettivamente capace di adempiere alcompito assegnatogli. Riletto nell’ottica dei modelli visti:

1. si individua l’agente di riferimento per un dato goal;

2. si determinano gli insiemi contenenti i parametri monitorati e quelli controllati;

3. si esamina la descrizione formale del goal;

4. si confronta tale descrizione con gli insiemi precedenti, al fine di capire se viene richiestaall’agente la lettura di parametri su cui non ha diritti di monitoraggio, o la scrittura suquantità che non controlla.

Rilevare una siffatta condizione è sintomatico di un raffinamento ancora acerbo, in cui il goal inesame deve essere ulteriormente specializzato, magari con l’aggiunta di ulteriori agenti.

Consideriamo per esempio il goal “Achieve[InterventoInfermieraPerPulsazioneCritica]”,definito da:

p.Pulsazione /∈ p.IntervSicuroPuls

⇒ �6ritardoMaxIntervento(∃i : Infermiera)Intervento(i, p)

Una tipica definizione dell’agente Infermiera difficilmente prevederà che essa possa monitora-re la variabile Pulsazione del paziente (a meno di pensare ad un’assistenza continua), pertantoil confronto tra l’agente Infermiera, responsabile del goal, e il goal stesso mette in evidenzauna condizione che possiamo indicare come “Mancanza di Monitoraggio”. Una soluzione tipi-camente adottata in questi casi, detta SplitLackOfMonitorabilityUsingMilestone (SuddividereLa-MancanzaDiMonitoraggioUsandoMilestone) consiste nell’introduzione di un agente intermedio,accessibile all’infermiera, che può monitorare il parametro origine del problema. In questo ca-so si può, banalmente, pensare di introdurre un segnalatore acustico che evidenzi il ritmo irre-golare. Si ottengono pertanto due nuovi goal: Achieve[AllarmePerPulsazioneCritica] eAchieve[InterventoInfermieraPerAllarme].

La procedura di raffinamento di KAOS, può pertanto essere definita una tecnica basata sugliagenti in cui si guida sistematicamente il raffinamento, scindendo i goal non realizzabili in sub-goal sino a che questi ultimi non divengono realizzabili da un singolo agente.

Una Casistica Ristretta

Si potrebbe essere indotti a pensare che in realtà l’apporto dato dalla metodologia appena vistavenga, almeno in parte, vanificato dalle dimensioni della casistica in esame. Infatti le situazioniche inducono l’impossibilità da parte di un agente a realizzare un certo goal, potrebbero essere unnumero enorme, fatto che impedisce una veloce individuazione dei goal irrealizzabili e, in ultimaanalisi, svilisce l’intero procedimento.


La realtà dimostra invece che tutte le evenienze di irrealizzabilità possono essere raccolte inuna tassonomia composta da sole cinque voci (tassonomia dimostrata peraltro completa [38]).

1. Mancanza di Monitoraggio: è quella vista nell’esempio precedente, un agente non haaccesso ad un parametro d’interesse.

2. Mancanza di Controllo: duale alla precedente, in questo caso si richiede che l’agentemodifichi un parametro su cui non ha controllo.

3. Riferimenti al Futuro: nel goal si specifica la situazione attuale di alcuni parametri in terminidi futuri valori assunti da altre variabili.

4. Goal Insoddisfacibile: esistono comportamenti di un agente o del contesto in cui esso simuove che rendono impossibile a priori la realizzazione del goal.

5. Goal Infinitamente Violabile: in cui l’azione dell’agente può indurre un loop.

Tali condizioni rappresentano un insieme completo, ma non sono tutte ugualmente fruibili. E’evidente infatti che, mentre le prime due sono banalmente riscontrabili tramite un checker au-tomatico, le restanti non sono altrettanto malleabili. Per quanto riguarda l’insoddisfacibilità deigoal, essa può essere chiaramente riscontrata solo da un confronto tra le proprietà degli agenti, odel contesto, e i goal. Mentre per quanto riguarda i riferimenti al futuro e l’infinità violabilità cisono al più euristiche di controllo, ma non vere e proprie tecniche di rilevazione. Nonostante ciò,la tassonomia precedente offre due risultati significativi:

• offre uno strumento sintetico e completo per un’eventuale analisi manuale;

• offre tecniche automatiche per rilevare le due situazioni di irrealizzabilità più diffuse.

Una Libreria Di Tattiche Di Raffinamento

La casistica precedente ha permesso di offrire un metodo per individuare, più o meno automati-camente, le condizioni di irrealizzabilità e, di conseguenza, per decidere se continuare o menoil raffinamento di un goal, rimane però da decidere le modalità da seguire per effettuare taleraffinamento.

La soluzione è molto elegante e fa riferimento al concetto di pattern, massima espressione dellaformalità e delle solide basi matematiche che sottostanno a KAOS. L’idea è quella di sfruttarele informazioni offerte dalla tipologia di irrealizzabilità per “consigliare” una, o più, tecniche daadottare per risolverla.

Non ci soffermeremo nel dettaglio sulle differenti tattiche (la cui tassonomia è proposta in fi-gura 10 e per i cui dettagli si possono vedere [38] [40]), vogliamo però sottolineare un aspettoessenziale dell’intero procedimento. La tassonomia risolutiva appena offerta non si limita ad offri-re un aiuto nel raffinamento, ma garantisce anche la correttezza del medesimo. Uno dei problemiprincipali riscontrati analizzando RE risultate erronee, è stato visto essere infatti la presenza diun raffinamento non corretto: i goal sino ad un certo livello erano coerenti con il sistema dasviluppare, ma poi si effettuava una scissione, o comunque la trasformazione di un goal, che pre-sentava un errore concettuale. Uno degli scopi base di KAOS è proprio cercare di porre un frenoall’insorgenza di una simile situazione.

L’idea è quella di utilizzare la logica sottostante ogni goal per ottenere una dimostrazione dicorrettezza. Tale dimostrazione è di fatto implicita nei pattern risolutivi visti in figura 10. In

2.3 K AO S 41Agent-Driven Tactics for Elaborating Goal Models

108

splitlack of monitorability


with milestone

introduceaccuracy goal

replaceunmonitorable state

by monitorable eventssplit

lack of monitorabilityby cases


by chaining

Resolvelack of monitorability

add monitorability

splitlack of control

splitlack of controlwith milestone

introduceactuation goal

replaceuncontrollable state

by controllable eventssplit

lack of controlby cases

splitlack of controlby chaining

Resolvelack of control

add control

ResolveReferences to Future

ResolveReferences to StrictFuture

ResolveSynchronization Problem

temporallyweaken goal

applyanticipation pattern

applymutual exclusion

pattern

replace current byprevious

ResolveUnsatisfiability

weakenunsatisfiability

preventunsatisfiability

(a) Tactics for resolving lack of monitorability

(b) Tactics for resolving lack of control

(c) Tactics for resolving references to the future

(d) Tactics for resolvinggoal unsatisfiability

FIGURE 6.7. The library of agent-driven tactics

(e) Tactics for resolvingunbounded Achieve goals

ResolveUnbounded Achieve Goals

add real-timebound

replace eventuallyby next

Figura 10: Tattiche di raffinamento per risolvere l’irrealizzabilità di un goal.


pratica ogni pattern esprime una trasformazione che è stata dimostrata, una volta per tutte, correttae che, pertanto, applicata ad un goal, produrrà sub-goal coerenti con le specifiche iniziali. Il ricorsoa pattern risolutivi permette perciò di affermare che un raffinamento ottenuto tramite KAOS noncontiene (almeno in linea ipotetica) errori; nel senso che se dimostriamo la correttezza di tutti igoal foglia, la correttezza del main goal è implicita.

2.3.3 Analisi Degli Ostacoli

Uno dei problemi tipici della RE e che si manifesta anche in KAOS, assumendo anzi proporzioniancora maggiori, riguarda la tendenza a sviluppare specifiche, requisiti e assunzioni troppo ideali:tali asserzioni finiscono con l’essere inevitabilmente violate, quando il sistema reale è in run, acausa di comportamenti inaspettati (o, meglio, trascurati) da parte di agenti umani, device hard-ware o componenti software [32]. Rifacendosi ancora all’esempio della miniera, si può pensaredi dover manipolare il goal Maintain[PompaAttivaQuandoAcquaAlta], ma, chiaramen-te, tale goal è troppo ideale e tende naturalmente ad essere violato: il sensore che rileva l’acquaalta potrebbe fallire; la pompa potrebbe non attivarsi; il controller della pompa potrebbe produrreinput erronei; etc.

L’idealizzazione di goal, requisiti e assunzioni si traduce pertanto in inconsistenze tra le specifi-che del sistema e il suo comportamento reale, inducendo la creazione di un documento di specificadei requisiti irrealistico o, peggio, incompleto. In ultima analisi la bontà dell’intero procedimentoviene vanificata, producendo un sistema formalmente corretto ma, all’atto pratico, incapace di in-nestarsi compiutamente in un contesto reale. Al fine di evitare la persistenza di questo tipo di goale per arricchire il sistema di un momento di analisi che lo rapporti con la realtà d’uso contingente,KAOS è stato ampliato con un’analisi finale detta Analisi degli Ostacoli (OA).

Gli ostacoli possono essere considerati una nozione duale a quella di goal: mentre i goal cat-turano condizioni desiderate, gli ostacoli rappresentano quelle indesiderate (ma comunque pos-sibili). Un ostacolo ostruisce un goal, nel senso che la realizzazione dell’ostacolo impedisce larealizzazione del goal.

Def. 8 (Ostacolo) Sia G un goal e Dom un insieme di proprietà appartenenti al dominio d’uso.Un’asserzione O è detta un ostacolo per G se e solo se valgono le seguenti condizioni:

1. {O, Dom} |= ¬G (ostruzione)

2. {O, Dom} | ¬false (consistenza col dominio)

La prima condizione afferma che la negazione del goal è conseguenza logica della specifica dell’o-stacolo nell’ambito del dominio attuale. La seconda condizione si riferisce invece alla consistenzadell’ostacolo rispetto al dominio; un ostacolo è una condizione inattesa, ma comunque accadibile.Nell’ottica di KAOS (e questa sarà la principale differenza con la proposta che faremo nel prose-guo della tesi) un ostacolo incoerente col dominio non ha senso, in quanto sarebbe espressione diun avvenimento inaccadibile.

La teoria relativa al trattamento e alla natura stessa degli ostacoli è estremamente ricca, in questepagine, per ragioni di sintesi, eviteremo di trattare completamente l’argomento (un siffatto studioè presente in [38] [32]), cercando di focalizzarci maggiormente sugli aspetti inerenti il nostrostudio.

2.3 K AO S 43

Generare Gli Ostacoli

Formalizzato il concetto di ostacolo, il primo problema che ci si pone riguarda l’individuazionedei medesimi. Si potrebbe pensare ad una generazione manuale: analizzando ciascun goal e con-frontandolo con il dominio, si potrebbe cercare di stilare una lista degli accadimenti che si prefigu-rano come ostacoli. Ovviamente l’approccio sarebbe troppo dispendioso, oltreché eccessivamentesoggettivo.

Esistono in realtà due soluzioni per la generazione degli ostacoli:

1. il ricorso ad euristiche da tenere in considerazione per esplicitare gli ostacoli;

2. il ricorso ad un metodo di generazione automatica.

Risulta particolarmente interessante questo secondo approccio, che si basa sull’idea che, nei fatti,un ostacolo non è altro che la negazione di un goal. La procedura [31] parte proprio dall’ideadi negare la formula caratterizzante un goal, e procedere poi con una serie di passi, automatici,successivi:

1. si nega la formula logica del goal in esame;

2. si ricorre a tecniche di regressione per ampliare la nuova formula ottenuta con informazioniprese dal dominio;

3. si applicano pattern di raffinamento per generare gli ostacoli d’interesse.

Come apparirà evidente, la procedura è molto dispendiosa in termini computazionali. I risultati of-ferti da Lamsweerde nei suoi lavori mostrano però come sia possibile ottenere con questo metodouna buona copertura.

Completezza Di Un Insieme Di Ostacoli

Prima di proseguire nella disamina della OA è interessante soffermarsi su un concetto: quello dicompletezza di un insieme di ostacoli.

KAOS, così come ogni metodologia di RE si basa su un assioma di completezza abbastanzaevidente: se l’insieme dei goal (o, in generale, dei requisiti) è completo, la RE condotta è corretta eil sistema sviluppato risponde ai requisiti iniziali. In realtà abbiamo visto come tale sillogismo siaevidentemente sbagliato laddove l’individuazione e la formalizzazione degli ostacoli poggino suidealizzazioni eccessive. Il precedente può allora essere esteso: se l’insieme dei goal è completoe se l’insieme degli ostacoli è completo, la RE condotta è corretta e il sistema sviluppato rispondeai requisiti iniziali.

Evidentemente comunque anche questa formalizzazione è abbastanza limitante. Il problema èche non esiste un modo per assicurare la completezza che desideriamo. Formalmente è vera:

{¬O1, . . . , ¬On, Dom} |= G

Ma in realtà:

• non è possibile sapere se gli ostacoli individuati sono tutti quelli individuabili, e quindi,anche laddove si sia riusciti a garantire che nessuno di questi si manifesterà, non possiamoaccertare la verifica del goal;


• la completezza del dominio in uso è del tutto dipendente da ciò che crediamo di conosceredel dominio, più che dalla natura stessa del dominio.

Queste problematiche verranno riprese e ampliate analizzando il concetto di fenomeno emergente,rimanendo nell’ottica della RE classica, la mancata realizzazione di tutti gli ostacoli associati adun goal, equivale alla realizzazione del goal stesso.

Raffinamento Degli Ostacoli

Allo stesso modo dei goal, gli ostacoli possono subire un processo di raffinamento ed espansio-ne. L’idea è ancora quella di poter identificare un ostacolo ad alto livello e poi, sempre tramitel’applicazione di opportuni pattern, procedere alla formalizzazione di sotto-ostacoli più semplici.

Come nel caso dei goal, il raffinamento rappresenta un presupposto assolutamente imprescindi-bile per poter completare l’analisi, dovendo riuscire ad associare un goal ad un singolo agente. Seripensiamo all’esempio del goal Maintain[PompaAttivaQuandoAcquaAlta], si capisceimmediatamente come la formalizzazione di un ostacolo che affermi che la pompa può non atti-varsi quando è stata rilevata acqua alta ha un valore molto limitato. Raffinare l’ostacolo permettedi capire quali agenti potrebbero compiere azioni che inducono un fallimento, potendo pertantoapportare gli opportuni aggiustamenti.

Risolvere Gli Ostacoli

L’ultima fase della OA consiste chiaramente nella rimozione di tutti quegli ostacoli che impedi-scono la realizzazione dei requisiti richiesti.

La risoluzione degli ostacoli è un processo composto essenzialmente da due fasi successive:

1. identificazione delle tecniche che possono essere approntate per risolvere il tipo di ostacoloin esame;

2. scelta della soluzione col miglior rapporto costi/benefici.

Interessa in particolare evidenziare la prima fase, in cui si palesano le metodologie tipiche diristrutturazione dell’albero dei goal.

In figura 11 è possibile osservare uno schema riassuntivo in cui sono proposte tutte le tecnicheadottabili per la risoluzione degli ostacoli. Si osserva in particolare come si possano individuaretre macro-categorie.

1. Eliminazione dell’Ostacolo: appartengono a questa categoria tutte quelle tecniche il cui fineè rendere impossibile la manifestazione dell’ostacolo. Tale impossibilità si può raggiungerein più modi.

a) La soluzione più evidente, ma anche la più costosa, è rappresentata dalla ristruttu-razione dell’albero dei goal creato; cambiando agente responsabile, o modificandoaddirittura il raffinamento condotto. In alternativa si può pensare di effettuare unatrasformazione parziale, in cui si modifica unicamente il goal afflitto, in modo chel’ostacolo, secondo la nuova formalizzazione, non possa evidenziarsi.

b) Altra soluzione è rappresentata dall’anticipazione dell’ostacolo; cioè dall’immissionedi un goal che introduca un requisito specificamente pensato per rendere impossibilel’avvenimento indesiderato.

2.3 K AO S 45 Obstacle Analysis

181

[Kec98]; inconsistencies in software development [Nus96]; or conflicts between require-ments [Rob97, Lam98b]. The objective here is to specialize such tactics to the resolutionof obstacles to goals during requirements engineering, and to make them explicit interms of specification transformation rules in the formal framework of temporal logic.

The obstacle resolution process will result in a transformed goal structure, transformedrequirements specifications, and transformed domain properties in some cases.

The library of obstacle resolution tactics is shown in Figure 8.21.

8. 5. 1. Obstacle Elimination

Eliminating an obstacle requires one among the conditions defining an obstructing obsta-cle in Section 8.2.1 to be inhibited; the obstruction should be avoided or the obstacleshould be made inconsistent/infeasible within the domain. The strategies below addressone of the conditions or the other.

8. 5. 1. 1. Goal substitution

A most effective way of resolving an obstacle is to identify analternative goal refine-mentfor some higher-level goal, in which the obstructed goal and obstructing obstacleare no longer present. In the meeting scheduler example, one may eliminate the obstacleElectronicAgendaNotMaintained that obstructs the goalElectronicAgendaUpToDate bychoosing an alternative refinement for the father goalParticipantsConstraintsKnown (seeFigure 8.22); the alternative goal refinement consists in introducing the two companiongoalsConstraintsRequested (under responsibility of the meeting scheduling software)and ConstraintsProvided (still under joint responsibility of participants and the emailsystem).

Choosing an alternative goal refinement will in general result in a different design for thecomposite system.

Obstacle Resolution Tactics

Eliminate Obstacle Reduce Obstacle Tolerate Obstacle

chosealternative goal

chosealternative agent

preventobstacle

anticipateobstacle

transformdomain

makeobstacle

unfeasible

removeobstruction

support

mitigate Obstacle restore goal

weakly mitigateObstacle

strongly mitigateObstacle

FIGURE 8.21. The library of obstacle resolution tactics

deidealizegoal

Figura 11: Schema riassuntivo che mostra le varie tecniche adottabili per risolvere gli ostacoli.

c) L’ultimo approccio percorribile riguarda la modifica del dominio attuale. Cambiareil dominio infatti può rendere teoricamente inaccadibile un ostacolo, impedendo cheesso sia coerente con il dominio stesso.

2. Riduzione dell’Ostacolo: in questo caso si cerca di ridurre l’occorrenza dell’ostacolo, piùche impedirne la manifestazione. In particolare fanno parte di questa categoria tutti quegliapprocci orientati “all’educazione” degli utenti, al fine di motivarli ad usare il sistema inmodo corretto e incentivarli a seguire specifiche procedure atte a ridurre gli hazardous stateo l’usura del sistema stesso.

3. Tolleranza dell’Ostacolo: per tolleranza dell’ostacolo si intendono tutte quelle tecniche chenon hanno lo scopo di eliminare l’ostacolo, quanto piuttosto di eliminarne il principaleapporto negativo. In particolare si individuano due possibili alternative.

a) Cercare di verificare, anche in presenza dell’ostacolo, almeno una versione ristrettadel goal (in cui, ad esempio, siano presenti solo le caratteristiche più importanti).

b) Cercare di riportare il sistema ad uno stato corretto, dopo un certo lasso di tempo.

2.3.4 Il Prodotto Di KAOS

La breve presentazione offerta di KAOS dovrebbe aver permesso di apprezzare le possibilità offer-te dal framework, oltreché capire, se pur non approfonditamente, le tecniche e la teoria sottostantele problematiche principali affrontate dai suoi sviluppatori. Vista la complessità del linguaggio, sivuole comunque offrire un piccolo sunto riassuntivo utile a sintetizzare i passi e le trasformazioniche si susseguono durante una tipica RE con KAOS.

1. L’input di partenza è costituito dai desiderata richiesti dal cliente e dalle conoscenze posse-dute sul dominio.

2. La lettura dei desiderata permette di evidenziare il main goal da ricercare. Tale goal vieneformalizzato e costituisce la radice dell’albero dei goal.


3. Per ogni goal contenuto nell’albero si eseguiranno i seguenti passi.

a) Si tratta anzitutto di stabilire se il goal è realizzabile, cioè se esiste un singolo agenteche, compiendo un’operazione, può risolvere il requisito.

b) Riscontrato un goal irrealizzabile, e stabilità la categoria di irrealizzabilità, si sele-ziona, in base a tale categoria, l’insieme dei pattern applicabili e si seleziona quellodesiderato, scindendo il goal in due (o più) sub-goal figli.

c) Se viene creato un nuovo goal si devono effettuare le seguenti.

i. Il goal deve essere formalizzato.

ii. Se nella sua formalizzazione si è fatto ricorso a concetti non ancora presenti nelvocabolario del dominio, si deve estendere il dominio.

iii. L’estensione del dominio è correlata alla modifica dell’object model e dell’agentinterface model.

d) Quando un goal è realizzabile da un agente, si interrompe il raffinamento e si ratifical’operazione da svolgere, formalizzandola nell’insieme delle operazioni.

4. Una volta che l’albero dei goal contiene tutti goal foglia realizzabili da un agente l’itera-zione termina. A questo punto il lavoro è completato a meno di idealizzazioni eccessive:l’obstacle analysis dovrà infatti reintrodurre nel sistema gli aspetti trascurati, provocando allimite mutamenti nel sistema sin qui ottenuto.

5. Il prodotto del lavoro effettuato sarà rappresentato da:

a) un albero dei goal, rappresentate tutti i requisiti d’interesse, le relazioni tra i medesimie gli agenti responsabili per ognuno;

b) un object model in cui sono rappresentati tutti gli oggetti che concorreranno al funzio-namento, o anche solo al contesto, del sistema;

c) un agent model, con un agent interface model, in cui si evidenzieranno tutti i soggettiche opereranno nel sistema, i loro privilegi di lettura e scrittura e, di conseguenza, irapporti vigenti tra i medesimi.

Per quanto riguarda il proseguo del nostro studio a noi interessa in modo particolare l’albero deigoal. Esso ci consentirà infatti di acquisire due informazioni essenziali. Anzitutto, i legami pre-senti tra i vari goal consentiranno di capire in che modo l’irrealizzabilità pratica di un goal haripercussioni sull’intero sistema. In secondo luogo, la presenza degli agenti responsabili consen-tirà di focalizzare la nostra attenzione su eventuali debolezze strutturali dei componenti che siandranno ad utilizzare nel sistema.

Capitolo 3L’Emergenza

“... allora capii che veramenteio ero il più sapiente perchéero l’unico a sapere di nonsapere.”

Socrate

Acquisiti gli strumenti, teorici (in particolare lo studio della RE) e formali (KAOS), per affron-tare lo studio prefissato, in questo terzo capitolo affronteremo il tema cardine dell’intero lavoro:l’emergenza.

L’importanza e, a suo modo, l’inevitabilità di questo concetto appariranno evidenti nel corsodella trattazione, è però utile, prima di calarci nel nuovo argomento, fare un breve sunto delpercorso sin qui condotto.

L’analisi trova la sua genesi nella volontà di sviluppare un sistema complesso (possibilmentecritico) scevro da errori. Per raggiungere tale scopo siamo inevitabilmente partiti (capitolo 1) dal-l’analisi delle due metodologie chiave nello sviluppo e nella disamina dei sistemi complessi: imetodi formali e la requirement engineering. Entrambe le metodologie, pur nelle loro differen-ze (inevitabili visto il diverso main task), hanno evidenziato una latente tendenza a scadere incondizioni di errore correlate all’interpretazione della realtà. L’impressione che ne abbiamo rica-vato è che l’assiomatizzazione del mondo esterno, così come la definizione dei componenti delsistema, tendano naturalmente a scadere in condizioni di deficienza informativa; condizioni cheinevitabilmente, nel momento dell’integrazione, sviluppano comportamenti indesiderati.

Un simile comportamento ricorda fortemente la natura del concetto di proprietà emergente,che presenteremo nel capitolo, permettendoci di ipotizzare la rilettura degli errori sistemici in unanuova ottica. La chiave di volta è rappresentata proprio da tale rilettura, la quale spinge a ripensaregli errori come fenomeni emergenti di sistemi complessi.

Nel proseguo del capitolo cercheremo pertanto di contestualizzare compiutamente il concetto diemergenza. Anzitutto, la disamina delle varie accezioni in cui esso è rintracciabile nelle differentidiscipline ci consentirà di formalizzare l’emergenza nell’ambito informatico (sezione 3.1). Termi-nata questa prima, necessaria, presa di coscienza, paleseremo l’applicabilità di un simile concettoal framework KAOS (sezione 3.2), evidenziando peraltro, grazie ad un parallelo con la fase diObstacle Analysis tipica proprio di KAOS, la naturale idiosincrasia dei fenomeni emergenti ad

47

48 L’ E M E R G E N Z A

essere previsti (sezione 3.3). Le conoscenze apprese consentiranno infine (sezione 3.4) di predi-sporre una tecnica di previsione parziale dell’emergenza, la quale, tramite l’analisi dell’ignoranzasistemica, consente di identificare le criticità di un progetto.

3.1 I N T R O D U R R E L’ E M E R G E N Z A I N I N F O R M AT I C A

Primo ineluttabile passo per riuscire a formalizzare l’emergenza in informatica consiste in un’at-tenta disamina del concetto di emergenza nelle altre discipline in cui esso è presente. Lo scopoè quello di estrapolare gli assiomi base che dovremo considerare e, allo stesso tempo, iniziare ascegliere di quali peculiarità necessiteremo nel nostro particolare ambito di studio.

3.1.1 L’Emergenza

Quello di emergenza è un concetto sfumato, esso nasce nell’ambito della biologia, probabilmentenel 18◦ secolo, per poi venire adottato, e conseguentemente re-interpretato, da una pletora didifferenti discipline. Tale mutevolezza rende difficoltoso offrire una definizione chiara e concisache riesca a riassumerne i differenti aspetti. Un primo approccio alla sua enucleazione può esserdato considerando la definizione di O’Connor e Wung [41]:

“Le proprietà emergenti sono feature sistemiche di sistemi complessi che non possono esserepredette ad un livello di osservazione che preceda la loro manifestazione; tutto questo nonostantesi possiedano conoscenze approfondite delle funzioni e delle leggi che governano le componenti.”

L’emergenza si esprime dunque come una “proprietà di sistema non direttamente derivabiledalle proprietà dei suoi componenti”. Ogni problema che coinvolge un sistema, più o meno com-plesso, in cui differenti componenti sono innestati assieme per produrre un certo risultato diventa,di conseguenza, suscettibile di un comportamento emergente. Incontriamo questo concetto in:

• biologia [42] [43] [15] [41], in cui i sistemi vitali multi-cellulari esprimono comportamentinon in linea con le peculiarità delle singole cellule;

• artificial life [42] [43], in cui si studia il comportamento del “branco”, il quale gode diun’intelligenza superiore a quella della somma dei suoi individui;

• filosofia [44][45], dove l’emergenza si inserisce nella diatriba tra meccanicismo, finalismoe dominio della casualità;

• neuroscienze[46][45][42], in cui il concetto di emergenza sfocia in quello di coscienza;

• . . . ma anche in Logica[46], Chimica[41][45], Economia[42], Artificial Intelligence [43],Ecologia[42], etc . . .

Come si sarà notato, non abbiamo fatto accenno ad un utilizzo in ambito prettamente Informatico(parlando di Artificial Life e Artificial Intelligence facevamo riferimento soprattutto ad un’analisilogica delle regole di comportamento). In Informatica infatti il concetto di emergenza ha sempremantenuto un ruolo abbastanza marginale. In letteratura sono presenti alcuni articoli in proposito,ma la sua natura e le sue ricadute rimangono spesso un concetto aleatorio, non riuscendo a trovare

3.1 I N T R O D U R R E L’ E M E R G E N Z A I N I N F O R M AT I C A 49

spazio in un mondo dominato dal determinismo e dalla, supposta, assenza di meccanismi estraneia quelli preventivati.

Nel corso del capitolo cercheremo, al contrario, di mostrare come non solo il concetto di emer-genza ha motivo di esistere in informatica, ma che, in effetti, esso risulti essenziale laddove siintenda effettuare un’analisi realistica di un sistema complesso [14] [47], prefigurandosi cometecnica privilegiata nella rilevazione di avvenimenti inattesi, trattati sino ad oggi solamente comeeventi statistici indesiderati.

3.1.2 I Differenti Volti Dell’Emergenza

L’analisi che ci accingiamo a fare riguarda in particolar modo due discipline, Filosofia ed Ecologia,in cui si palesano al meglio i differenti volti del concetto di emergenza.

Filosofia

Il concetto di emergenza in Filosofia ha rappresentato, soprattutto nella prima metà del secoloscorso, un elemento di indagine di interesse assoluto. Il padre dell’emergenza, da un punto divista filosofico, è G. H. Lewes che nel 1875, nel libro Problems of Life and Mind, parlò di emer-gent entities (proprietà o, filosoficamente parlando, sostanze) riferendosi a oggetti derivanti dacomponenti di base, che presentavano però proprietà nuove o non connesse con i componentistessi.

Successivamente, negli anni ’20, in particolar modo nel Regno Unito, si sviluppò una discipli-na, detta appunto Emergentismo, che si focalizzò proprio su tale concetto, considerando la suainterpretazione un elemento di discrimine nella diatriba, in voga in quegli anni, tra la fisica, ocomunque tra le “general sciences”, e le cosiddette “special sciences”: l’obiettivo, più o menodichiarato, era quello di decidere se il sub-strato di tutte le scienze fosse il medesimo o se ledifferenti discipline trattassero oggetti qualitativamente differenti.

In ultima analisi il problema era: come possono discipline che evidenziano e sperimentanocomportamenti tanto dissimili da apparire contrastanti, essere se non unificabili, quantomeno in-quadrabili in un contesto comune? Gli emergentisti, in opposizione al meccanicismo puro, estre-mizzazione massima del principio cartesiano, sostenevano che la materia alla base fosse sì lamedesima, ma le differenti regole di aggregazione cui poteva andare incontro conferivano agliaggregati proprietà peculiari troppo dissimili da quelle concernenti gli altri aggregati. Aggregatidifferenti sperimentavano in sostanza “proprietà emergenti” differenti: la natura di tale emergenzadistingueva le differenti soluzioni proposte.

Era fondamentalmente un problema di livello di astrazione; esistevano leggi che guidavano lamateria ad un certo livello, ma cambiando la granularità di osservazione, e quindi passando agliaggregati, tali leggi smettevano di valere e ne subentravano altre. C. D. Broad parlava di:

• Intra-ordinal laws: valide al medesimo livello di astrazione;

• Trans-ordinal laws: che introducevano nuove regole, cioè proprietà emergenti, negli aggre-gati.

Altri filosofi, in particolare S. Alexander, estremizzarono questi concetti introducendo fattori ester-ni di evoluzione che travalicavano la fisica sino a sfociare nella metafisica: è emblematica la


lettura della coscienza come proprietà emergente altrimenti inspiegabile con le regole della neuro-scienza. Per lui il processo mentale non è meramente neurale, ma è qualcosa di nuovo, una qualitàdistintiva che emerge, anziché esserne il risultato, dal processo neurale.

É sufficiente questa breve introduzione al concetto di emergenza in Filosofia per riuscire adindividuare alcune, probabilmente le principali, chiavi di volta che dovranno guidare il processodi assiomatizzazione dell’emergenza in Informatica: l’emergenza è un problema di granularitàdella tecnica di osservazione o risiede in qualcos’altro? É, in sostanza, figlia, seguendo le ideemeccaniciste, dell’ignoranza o, come ipotizzava Alexander, esprime un carattere nuovo introdottodal contesto o comunque da un ente esterno?

Biologia ed Ecologia

In Biologia, e soprattutto in una sua sotto-branca, l’Ecologia, il concetto di emergenza è utilizzato,seppur inconsapevolmente, in modo massivo. Lo studio dei branchi, o delle comunità in generale,è un esempio tipico: le proprietà in esame sono sistemiche, si fanno affermazioni come “il brancomanifesta ...” o “il comportamento del gruppo è ...” trascurando, consapevolmente, le caratteristi-che dei singoli individui della comunità, che mal si conformerebbero con le proprietà precedenti.Già nel 1972 Harre’s parlava di:

“Molti branchi, o comunque aggregati, possiedono proprietà che non sono proprietà degliindividui che compongono la collezione. Tali proprietà sono dette proprietà emergenti ...”

Come accennato in precedenza, le proprietà emergenti sono talmente inevitabili negli studi biolo-gici che alcune discipline, come l’analisi degli ecosistemi, omettono in toto lo studio dei singolicomponenti, iniziando l’analisi dal livello di aggregazione successivo: l’ecosistema stesso. Intal senso è esemplare la difficoltà, sollevata in [42], a trovare esempi di proprietà emergenti nel-l’ambito dello studio degli ecosistemi, proprio per l’assenza di informazioni sui componenti stessidell’ecosistema.

Nel tempo l’attenzione si è spostata, ne è un esempio la definizione di G. W. Salt [42], sullapossibilità di prevedere, e dunque derivare, le proprietà sistemiche.

“Una proprietà emergente di un’unità ecologica è tale poiché totalmente impredicibile dallamera osservazione dei componenti di tale unità.”

Si sottintende in pratica il ricorso ad uno studio che si sviluppa secondo differenti livelli di analisi:

• l’analisi degli atomi fa riferimento a certi comportamenti;

• quando si analizza l’intero sistema i comportamenti mutano.

Si palesa allora una dicotomia insanabile, che impedisce di derivare, analiticamente o logicamente,le proprietà di sistema da quelle dei componenti.

“Una proprietà emergente di un’unità ecologica è individuabile unicamente dall’osservazionedell’unità stessa.”

Una proprietà emergente è allora un comportamento osservabile ma non prevedibile.


Artificial Life

L’ultima digressione che andremo a considerare riguarda l’ambito della Vita Artificiale e dunquerichiama in senso lato molte delle problematiche presenti in Ecologia e Biologia.

Il punto nodale è cercare di formalizzare strumenti che consentano di simulare il comporta-mento di organizzazioni complesse (siano esse animali, vegetali o meramente fisiche); abilità,comportamenti, ma anche reazioni chimico/fisiologiche, non sono sempre predicibili, né sono sta-te del tutto capite, pur avendo scandagliato sotto ogni aspetto le proprietà dei loro componenti.Concetti come l’evoluzione di specie animali o la nascita del DNA, sono eventi simulabili solo infunzione delle conoscenze tipicamente possedute o si è costretti a supporre la presenza di altro?E in tal caso come si può rappresentare questo altro, al fine di renderlo utilizzabile per comporresistemi complessi, stavolta veramente predicibili?

In [43] P. Cariani classifica tre tipologie di emergenza.

• Computational Emergence: si ragiona a livello formale/logico, supponendo uno stato dellecose in cui l’ordine conduce inequivocabilmente all’ordine. Secondo quest’accezione, ilmacro-ordine è figlio del micro-determinismo e il macro-indeterminismo è figlio della teo-ria del caos ed è quindi, fondamentalmente, un falso macro-indeterminismo correlato allanostra incapacità di predire correttamente il macro-ordine.

• Thermodynamic Emergence: il punto di partenza stavolta è più prettamente fisico, legatoprincipalmente a strutture complesse, animali e vegetali, naturalmente tendenti ad un equi-librio. Si ipotizza che la natura, seguendo principi di stabilizzazione e di semplificazione,tenda ad un equilibrio in cui è possibile individuare macro-strutture. Tali macro-strutturenon sono direttamente connesse con i processi esistenti prima della stabilizzazione e nonsono predicibili, essendo derivanti principalmente dal caso.

• Emergence Relative to a Model: in questa accezione si vede la materia, ma in senso latoogni essere vivente, come caratterizzata da alcune proprietà funzionali manifeste e da altreproprietà o qualità nascoste. Un concetto come quello dell’evoluzione è accettabile solose sottintendiamo che ogni essere vivente celi peculiarità latenti che possono manifestarsiladdove cambi il contesto, ambientale o sociale.

Nell’ottica della formalizzazione del concetto di emergenza, risulta particolarmente interessantequest’ultima versione del concetto di emergenza: l’emergenza non è estranea all’aggregato, ma èfiglia di una qualità nascosta dei componenti. Si deve superare la tendenza diffusa a rappresentareun agente come mera composizione delle funzioni che lo caratterizzano, ogni agente, sia essovivente, così come un componente fisico di un sistema elettronico, è anche qualcos’altro, magaria noi ignoto.

3.1.3 L’Emergenza In Informatica

In informatica le problematiche discusse sono inquadrabili nel più ampio contesto dell’analisi disistemi complessi. La definizione che Simon, già nel 1962, dà di sistema complesso [14] aiuta acapire lo stretto legame.

Def. 9 (Sistema Complesso) Per sistema complesso io intendo un sistema composto da un altonumero di componenti che interagiscono tra loro secondo modalità non elementari.


La chiave è la presenza di quel “non elementari”, chiaro preludio alla manifestazione di fenomeniemergenti.

Il concetto di emergenza è stato recentemente ripreso ed introdotto in ambito informatico daBlake & Koopman [22]. In particolare nel loro lavoro si fa riferimento ai concetti di:

• sistema complesso risultante: il cui comportamento è interamente derivabile dalle proprietàdei componenti;

• sistema complesso emergente: in cui si evidenziano comportamenti inattesi, non in lineacon le previsioni effettuabili dall’analisi dei componenti.

L’articolo introduce il concetto di emergenza nell’ambito dello sviluppo di tecniche di rappresen-tazione e analisi per requisiti di Safety, in particolare tramite approcci di tipo GORE, senza peròapprofondirne la disamina. Dettaglieremo nel seguito, in particolar modo in sezione 3.2, alcuniinteressanti spunti presenti nell’articolo, preferendo per adesso concentrarci sull’ontologia stessadel concetto di emergenza.

Definizione Del Concetto Di Emergenza

Tenendo bene a mente le considerazioni e le problematiche descritte nei paragrafi precedenti siamoadesso in grado di formalizzare il concetto di emergenza.

Def. 10 (Emergenza) L’emergenza riferisce la manifestazione, all’interno di un sistema comples-so, di un fenomeno emergente.

Def. 11 (Fenomeno Emergente) Un fenomeno è detto emergente se esso non deriva, direttamen-te o indirettamente, dall’applicazione delle regole compositive note alla definizione che possedia-mo dei componenti.

La definizione precedente racchiude in sé le scelte da noi effettuate in relazione alle problematicheevidenziate in precedenza. Anzitutto, si è supposto che l’emergenza sia sempre figlia di un difettodi conoscenza. Un sistema di cui conosciamo tutte le caratteristiche dei componenti e, in particolarmodo, tutti gli effetti provocati dalle loro interazioni non può produrre condizioni emergenti. Équesta probabilmente l’assunzione più forte che facciamo; d’altra parte essa appare ragionevolein un mondo tipicamente deterministico come quello dei calcolatori.

Si noti che l’assunzione adottata risolve implicitamente le due problematiche di livello digranularità e di emergenza come agente esterno discusse in precedenza.

Immaginare di possedere una conoscenza totale sul sistema e sui componenti riguarda infat-ti tutti i differenti livelli di astrazione immaginabili: praticamente, pensando ad esempio ad uncalcolatore elettronico, si immagina di conoscere la natura e le interazioni non solo dei suoimacro-componenti (scheda madre, alimentatore, etc. . . ) ma anche di micro-componenti, sino,idealmente, alle singole parti meccaniche che compongono i chip o le celle della batteria. Identi-co discorso vale per i componenti software, in cui si richiede una padronanza comprensiva di ognisingola riga di codice. Ovviamente stiamo parlando di un livello di conoscenza che molto spessorisulterà utopico, avendo a che fare con sistemi di complessità non elementare o con componentieterogenei.

In secondo luogo, noi intenderemo l’emergenza come un concetto interno agli agenti in esame,mai derivante dall’esterno. L’emergenza farà riferimento ad un quid, magari non conosciuto,


che si manifesta in un certo momento, ma che comunque era presente, in stato dormiente, già inprecedenza. Al limite, tratteremo il concetto di contesto, inteso come elemento esterno che scatenauna risposta inattesa. Anche in questo caso però tale incongruenza è figlia di una deficienzainformativa; è correlata cioè al fatto di non conoscere appieno la natura del componente in queldato contesto.

L’emergenza è allora una X indefinita che, potenzialmente, è presente in ogni componente.Un uso o un contesto improprio di un componente, laddove per improprio si intende differente dacome concepito dal suo creatore, può innescare tale X producendo un risultato inatteso. Ogni com-portamento emergente deriva dall’innesco di una X latente, il cui studio assume un’importanzabasilare.

Il problema è ovviamente che di tale X noi non sappiamo e, a meno di euristiche generali, nonpossiamo sapere praticamente niente. É qui che si palesa, riprendendo la definizione offerta daDarley [15], lo stretto legame tra emergenza e testing; poiché non possiamo conoscere X (non c’èinfatti alcun modo per prevedere l’emergenza) essa può essere rilevata unicamente effettuandoanalisi prossime, o coincidenti, al testing.

Def. 12 (Fenomeno Emergente (Darley)) “A true emergent phenomenon is one for which theoptimal means of prediction is simulation.”

Ma se stabilire la natura emergente di un fenomeno è un’attività da svolgere inevitabilmente a run-time, consegue che non è possibile nemmeno stabilire a priori se un sistema sia o meno emergente[22]. L’ottica nella quale ci dobbiamo porre è che, potenzialmente, ogni sistema non elementareè emergente, ma, in effetti, non possiamo avere alcuna certezza né in un senso, né in un altro.

L’Emergenza Come Strumento Di Dependability

Si noti come l’emergenza sia di fatto una metrica di dependability.Così come si richiede che un sistema, sia esso hardware o software, goda di certe proprietà

come MTTF, reliability, availability, etc . . . , allo stesso modo è logico ritenere che un buon pro-getto debba cercare di diminuire l’emergenza, debba cioè tendere alla minimizzazione della Xintrinseca. Un componente hardware con certe proprietà ottimali all’interno di un certo ambitod’uso potrebbe essere assolutamente mediocre se utilizzato in un contesto differente: ripensare ilcomponente per essere usato in un ambito più ampio o semplicemente sottolineare il range d’usoottimale, sono entrambi modi per diminuire la portata della X, rendendo il sistema in cui verràimmesso il componente meno suscettibile di comportamenti emergenti.

Riprenderemo in seguito (nel capitolo 7) considerazioni di questo tipo parlando di componentioff-the-shelf; interessa per adesso ribadire come la X non debba essere pensata come un quidaleatorio, esistente in teoria ma inutile all’atto pratico, ma piuttosto come una vera e propriamisura di QoS.

L’Emergenza Come Problematica Computazionale

Sin ora si è parlato di emergenza come prodotto di un unico fattore: l’ignoranza. D’altra parte,ma questa considerazione veniva fuori già dalla lettura dei paragrafi precedenti, un’altra causa ca-pace di far scaturire fenomeni inattesi è la nostra incapacità di calcolare compiutamente un certostato del sistema. Pur avendo una conoscenza completa di certi componenti potremmo infatti nonessere in grado, principalmente per limitazioni fisiche legate alle capacità dei calcolatori odierni,


di analizzare appieno le loro interazioni. In una simile evenienza le informazioni possedute sa-rebbero sufficienti, ma potrebbero comunque verificarsi situazioni inattese conseguenza del fattoche il calcolatore non è stato capace di esplorare la finestra di interazioni possibili. In pratica,andando ad esaminare le cause di un evento inaspettato, scopriremmo che eravamo già in posses-so di tutte le informazioni necessarie per predire tale accadimento, ma probabilmente tale eventoapparteneva ad una casistica troppo ampia per poterla esplorare interamente.

Potrebbe inoltre non essere un problema di risorse computazionali, ma di mancanza di metodianalitici adeguati: si pensi in tal senso all’assenza di un modello matematico inerente l’ambitod’uso o alla presenza di sistemi troppo complessi che sfociano nella matematica del caos.

Per la definizione che abbiamo dato di emergenza una simile eventualità non è inquadrabi-le come fenomeno puramente emergente, nel corso di questo lavoro tenderemo pertanto a nonconsiderare tale accezione.

3.2 T R AT TA R E L’ E M E R G E N Z A I N K AO S

Appurato che l’emergenza non è un concetto vago, ma è qualcosa di reale di cui è necessariotenere conto, sorge naturale il bisogno di formalizzare tecniche che ci consentano di rappresentarla.Come abbiamo detto più volte la nostra attenzione verte sulle problematiche di ingegnerizzazionedei requisiti ed è proprio in tale ambito che cercheremo di immettere il concetto di emergenza.

E’ necessario anzitutto approfondire meglio il ruolo dell’emergenza in questa disciplina. Abbia-mo osservato nei capitoli precedenti differenti approcci alla RE, sottolineando come, al di là dellaspecifica soluzione adottata, sussistano criticità basiche, legate principalmente alla deficienza ditalune informazioni. Le obiezioni sorte in precedenza assumono un interesse ancora maggiore seosservate sotto la nuova ottica emergente. In particolare un’assunzione, pur involontaria, che, anostro parere, limita considerevolmente la qualità dei risultati ottenuti nei framework classici peril trattamento della RE, risiede nella diffusa accettazione passiva che i componenti funzionino e sicorrelino esattamente come supposto. Tale assunzione è figlia probabilmente di un orientamentoparticolare che sembra pervadere la maggior parte dei lavori; l’interesse cioè ad una disamina piùprettamente qualitativa, dove gli aspetti quantitativi, così come gli attributi di dependability, sonolasciati a momenti successivi di analisi o di sviluppo del progetto.

Nel momento in cui si effettui un’analisi quantitativa diviene inevitabile infatti un cambio dimentalità in cui il corretto funzionamento è solo uno stato possibile e ogni componente si ca-ratterizza non solo per il naturale stato di funzionamento, ma anche per una varietà di stati dimalfunzionamento che potrebbero palesarsi. Trae origine proprio da questo mutato approccio lanecessità di trattare il concetto di accadimento emergente, in quanto, accanto agli stati di funzio-namento supposti, siamo interessati ad inserire situazioni incognite di cui al momento possiamo,a fatica, provare a supporre l’esistenza.

Cercheremo pertanto in questo paragrafo di capire se e come il concetto di emergenza appenadettagliato possa relazionarsi con il framework KAOS, studiando le eventuali assunzioni da rila-sciare per permetterne l’immissione. La disamina ci porterà ad affermare che un fenomeno emer-gente può essere solo parzialmente immesso nel sistema e ci consentirà di porre le basi, tramite ilconcetto di grado di ignoranza, per lo studio dell’emergenza che analizzeremo nel paragrafo 3.4.

3.2 T R AT TA R E L’ E M E R G E N Z A I N K AO S 55

3.2.1 Introdurre L’Emergenza In KAOS

KAOS è un framework che intrinsecamente esclude il concetto di emergenza, cerchiamo di ca-pirne il motivo. Inizieremo l’analisi considerando un parallelo con una struttura concettualmentelimitrofa a quella di fenomeno emergente: gli ostacoli.

Nel capitolo 2 abbiamo introdotto la Obstacle Analysis, mostrando come le assunzioni effettua-te nella prima fase di raffinamento del main goal vengano via via rilasciate al fine di conformare ilsistema a situazioni reali in cui avvengono eventi inizialmente imprevisti. In effetti, la descrizioneappare molto simile a quella di fenomeno emergente: in entrambi i casi si maneggiano situazioniindesiderate, che possono compromettere il corretto funzionamento dell’intero sistema. Il puntochiave è che gli eventi analizzati in KAOS sono indesiderati ma:

1. realistici: sono cioè ammissibili all’interno del dominio di conoscenza che caratterizza ilsistema;

2. preventivabili: sono cioè pensabili nel momento in cui si progetta il sistema.

Cerchiamo di capire perché queste due assunzioni sono inconciliabili col concetto di emergenza.Ragioniamo anzitutto sul concetto di realismo. Ad una prima, superficiale, analisi l’idea se-

condo cui una condizione emergente deve necessariamente rispondere alle logiche del dominio inuso potrebbe apparire sensata, forse anche inevitabile. D’altra parte il dominio attuale altro nonè che il nostro modo di vedere e limitare (nel senso di stabilire bound di accadimento) la realtàcon cui il sistema dovrà interagire. Ma questa realtà è, quantomeno, suscettibile di errori se nonaltro perché è figlia di una nostra interpretazione; senza contare che potrebbe cambiare il contesto,si pensi a componenti COTS studiati per certi ambiti ed utilizzati invece in modalità differenti.Un evento emergente non risponde ad alcuna legge formale, tantomeno quindi ad un dominio diriferimento, l’unica verità e che esso può accadere; al limite, se è un evento improbabile, con untasso di occorrenza infinitesimo.

L’inconciliabilità della seconda assunzione con il concetto di emergenza è più evidente. Ovvia-mente una condizione emergenze è per definizione stessa inattesa, diventa difficile dunque pensaredi formalizzarla in fase di RE. Lo strumento principale di raffinamento dell’emergenza è rappre-sentato dal testing; sono infatti i test, a livello di sistema o di sotto-sistemi, gli strumenti necessariper pensare di estrapolare incongruenze tra funzionamento ideale e funzionamento reale.

Introdurre l’emergenza in KAOS richiederebbe pertanto una serie di trasformazioni necessarieper conformare il framework alla nuova struttura. In particolare si potrebbe operare su tre aspetti.

1. Dovrebbero, con specifico riferimento alle osservazioni fatte in precedenza, essere rilasciatealcune assunzioni proprie di KAOS: in particolare l’aderenza ad un dominio di riferimento.

2. Rilevare l’insorgere di situazioni emergenti richiederebbe, inoltre, l’immissione di una fasedi analisi aggiuntiva, che consideri in modo particolare tecniche di testing.

3. Ovviamente poi, al fine di integrare correttamente le precedenti, si dovrebbero cambiarealcune strutture del framework. Il formalismo dovrebbe infatti prevedere la presenza di si-tuazioni (leggasi nodi di un albero dei raffinamenti, così come funzionalità degli agenti) nonderivanti dalle altre strutture presenti. Si potrebbe ad esempio dover prevedere la presenzadi nodi foglia nell’albero dei requisiti che non si correlano ad un agente (espressione di unaevidenza che si manifesta ad un certo livello, senza conoscerne la genesi).


Per quanto una simile modifica del sistema non sia particolarmente complessa, pare discostarsidall’obiettivo vero del nostro studio. Ai nostri occhi, operare trasformazioni atte a introdurreun qualche formalismo per rappresentare un fenomeno emergente già manifestatosi, non pare unpassaggio costruttivo. Il rischio è quello di ricercare uno strumento passivo, un formalismo cioè ilcui scopo non è tanto quello di offrire un’informazione aggiuntiva a chi approccia le problematichedel sistema in esame, quanto quello di stilare banalmente un documento di risultanze.

3.2.2 Rappresentare L’Emergenza

La nuova ottica nella quale ci poniamo per affrontare il problema dell’insorgenza di fenomeniemergenti parte dal presupposto che ogni componente del sistema sia in qualche modo portatoredi un “lato nascosto”, induttore di comportamenti emergenti. Formalmente si va ad associare adogni componente una variabile X che qualifica le nostre debolezze conoscitive.

Un’analisi che si sviluppi associando ad ogni componente una X incognita ci permetterà diavere una conoscenza più approfondita del sistema che stiamo costruendo. Pensiamo ad esempioad un albero dei goal strutturato secondo le direttive GORE con l’aggiunta di aspetti emergenti,appare evidente come, al di là delle analisi specifiche, avremo:

• migliore leggibilità dei punti critici del sistema;

– sia per quanto riguarda l’individuazione dei nodi in cui si addensa un alto numero divariabili emergenti;

– sia per quanto riguarda le X associate a requisiti critici;

• possibilità di introdurre concetti di bound su tali variabili incognite come conseguenza degliattributi quantitativi dei requisiti associati.

L’Emergenza Come Variabile Comportamentale

Prima di proseguire l’analisi dobbiamo anzitutto estendere le conoscenze dell’approccio GOREdate nel capitolo 2.

Anzitutto vale il concetto di composizionalità di un goal.

Def. 13 (Fully Composable Goal) Un goal G si definisce fully composable se esiste un insiemedi n sub-goal {G1, . . . , Gn} terminali, cioè realizzabili da un singolo componente, cosicché G èlogicamente equivalente alla congiunzione dei sub-goal:

G1 ∧ · · ·∧ Gn ⇔ G (3.1)

che equivale all’unione delle seguenti:

G1 ∧ · · ·∧ Gn ⇒ G

¬G1 ∨ · · ·∨ ¬Gn ⇒ ¬G(3.2)

In altre parole, il parent goal è soddisfatto quando tutti i suoi figli sono soddisfatti ed è violatoquando almeno uno dei sub-goal non viene mantenuto.

Blake & Koopman [22] rileggono il concetto di emergenza sotto questa particolare ottica,affermando che un goal G è emergente se non esiste alcun sotto-insieme che verifica le 3.2.


Def. 14 ((Partially Composable) Emergent Goal) Un goal G è detto emergente (e parzialmentecomponibile) se esiste un insieme m di sub-goal e un goal irrealizzabile X tali che vengonosoddisfatte le 3.2:

G1 ∧ · · ·∧ Gn ∧ X⇔ G (3.3)

In generale si può dire che un goal è emergente ogni qual volta X è non nullo. Occorre soffermarsiun attimo sul concetto di X. Anzitutto abbiamo detto che X esprime un goal irrealizzabile, questoè vero in un duplice senso:

1. è irrealizzabile perché non sapendo nulla su di esso, non possiamo provvedere tecniche dirisoluzione;

2. è irrealizzabile anche perché, semplicemente, non è possibile evitare che esso si manifesti.

Un secondo chiarimento è necessario a proposito dell’accezione in cui viene usato X. Chiaramen-te X è espressione della manifestazione di una qualche attività indesiderata, formalmente però X

traduce una formula negativa. L’approccio seguito da Koopman et al. fa infatti riferimento al-le condizioni (i vari G1, . . . , Gm, X) che devono realizzarsi per verificare G, ma una condizioneemergente è intrinsecamente una evidenza che impedisce la realizzazione di G; formalmente dun-que, e questo si vede bene nell’equazione 3.3, X esprime il fatto che la condizione emergente nonsi è verificata. Da qui in avanti, indicheremo, per chiarezza espositiva, X in termini di condizionepositiva, la precedente definizione può essere allora riletta.

Def. 15 ((Partially Composable) Emergent Goal) Un goal G è detto emergente (e parzialmentecomponibile) se esiste un insieme m di sub-goal e un goal irrealizzabile X tali che vengonosoddisfatte le 3.2:

G1 ∧ · · ·∧ Gn ∧ ¬X⇔ G (3.4)

A nostro parere la nuova definizione esplicita meglio il significato di X; evenienza che può acca-dere e la cui realizzazione, se non trattata (cioè se non negata), inficia il parent goal. Ovviamen-te la nuova lettura del problema lascia inalterate tutte le problematiche descritte in precedenza:i sub-goal dei goal emergenti parzialmente componibili sono praticamente inutili se considera-ti assestanti, in quanto il verificarsi di X comunque inficia il parent goal; d’altra parte se nonconosciamo niente di X, non possiamo affermare niente nemmeno sulla sua realizzabilità.

3.2.3 Quantificare L’Ignoranza

Verificata l’impossibilità di qualificare la natura dell’incognita X appena introdotta, possiamopensare di limitarci ad offrirne una qualche quantificazione, sia pur assolutamente relativa. L’ideaè quella di effettuare una trasformazione concettuale che sposti il focus attuale dalla ricerca di unfenomeno emergente, alla quantificazione delle cause, cioè l’ignoranza, che inducono il fenomenostesso. Anzitutto appare necessario soffermarsi sulla differente natura dei due concetti sovracitati.

Emergenza E Ignoranza: Una Differenza Sfumata

Nelle precedenti pagine abbiamo fatto riferimento ai concetti di ignoranza e di emergenza, descri-vendo la profonda correlazione presente tra i due. Abbiamo osservato come l’ignoranza induca


emergenza e come un fenomeno emergente sia sempre figlio di una qualche carenza conoscitiva,quasi che, in ultima analisi, le due nozioni rappresentassero una differente declinazione del mede-simo concetto. In realtà, osservando quanto detto finora si noterà, ad esempio, che non abbiamomai utilizzato il termine emergenza in riferimento ad un singolo componente. Una breve disaminadi questi aspetti ci consentirà di sottolineare una sfumatura importante del concetto di emergenza.

Se riprendiamo in esame la definizione (10) che abbiamo dato di emergenza, o meglio di feno-meno emergente (11), appare evidente come tale concetto sia indissolubilmente legato a quello disistema e ad una visione del sistema sufficientemente profonda da poterne individuare, almeno agrandi linee, le componenti. L’emergenza si esplica come opposizione ad un generico requisito (ogoal) che abbiamo localizzato, analizzato e risolto ed è tale perché rappresenta una nuova proprie-tà che, citando il filosofo Alexander, emerge dal sistema così come è stato costruito. L’emergenzaperciò è tale solo se si è in possesso di una visione del sistema sufficientemente approfondita dapoterne predire, o comunque intuire, il funzionamento: dato un certo insieme di componenti, datal’architettura di correlazione e date certe conoscenze, supponiamo che il sistema soddisferà lespecifiche funzionali. Se poi il sistema realizzerà veramente tali specifiche parleremo, riallaccian-doci all’articolo di Blake e Koopman [22], di sistema risultante, altrimenti il sistema in esame saràemergente.

Se pensiamo a componenti elementari, o anche a sistemi equiparabili a black box (ad esempiocomponenti COTS), la condizione è totalmente differente. Non si può etichettare tali oggetti co-me emergenti, in quanto, non avendo una visione delle sue parti, non siamo in grado di giudicarele ragioni di un eventuale fenomeno inatteso. Un COTS potrebbe esprimere un comportamentonon in linea con le specifiche per differenti ragioni: perché sono scritte male le specifiche, per-ché è il componente stesso ad essere implementato in modo errato, etc. Ma tali evenienze nonrappresentano una condizione emergente, quanto piuttosto errori di progetto o cattive abitudininel documentare il medesimo. Un singolo componente non può dunque evidenziare emergenza,ma è semplicemente correlato ad una nostra ignoranza che, in un secondo tempo, può indurre uncomportamento emergente.

Nel proseguo del lavoro limiteremo pertanto il campo applicativo dell’emergenza seguendoquanto detto sin ora, limitandoci, nel caso dei singoli componenti, a parlare di ignoranza.

Grado Di Ignoranza

Abbiamo sin ora accennato genericamente ai termini grado di emergenza di un sistema o gradodi ignoranza su di un componente, vogliamo adesso puntualizzare meglio l’accezione con cuiabbiamo utilizzato, e utilizzeremo diffusamente nel seguito, la parola “grado”.

Intuitivamente appare ovvia l’introduzione di una metrica che differenzi tra situazioni in cuisi possiedono molte conoscenze sui costrutti che si intende utilizzare, rispetto a situazioni in cuil’ignoranza è preminente. Introdurre un concetto di questo tipo consente di fissare, anche daun punto di vista meramente grafico, la conoscenza correlata alle varie parti del sistema; peral-tro, come vedremo nel seguito, quest’approccio ci consentirà di improntare un’analisi qualitativadell’emergenza stessa.

Ci si potrebbe allora domandare quale sia il miglior formalismo da utilizzare per definire isuddetti gradi. Agli occhi di chi scrive, la scelta tra un formalismo piuttosto che un altro noninfluisce sulla bontà dell’analisi condotta. Adottare una gradazione continua piuttosto che discretao fare riferimento ad una scala che faccia uso di un ristretto vocabolario di termini, sono tuttescelte attuabili, ma assolutamente soggettive e specifiche per un particolare sistema. Ovviamente


adottare una scala che ricorre ad un maggior numero di gradi migliora la precisione del modello diemergenza che si va a sviluppare. D’altra parte spesso, proprio per la natura stessa dell’emergenza,non si è in grado di stabilire dettagliatamente il nostro grado di conoscenza o il grado di emergenzadi una soluzione rispetto ad un’altra (probabilmente se lo fossimo potremmo decrescere, almenoin parte, tale ignoranza). Ricorrere ad una scala ampia piuttosto che utilizzarne una binaria, sonoquindi scelte dettate dal singolo sistema in esame e non mutano le considerazioni proposte inprecedenza o che daremo nel seguito.

3.2.4 L’Emergenza Come Strumento Di Conoscenza

Ci siamo sin ora concentrati sulla formalizzazione dell’emergenza, qui e nel proseguo cerchere-mo di capire come sfruttare questa condizione indesiderata per rendere il sistema migliore (dalpunto di vista della qualità del servizio associata). Osserveremo in particolare come sia possibiledefinire un approccio in cui quest’ultima rappresenta un bagaglio di conoscenza da non trascura-re. Vale infatti l’assunto secondo cui l’accettazione stessa della nostra ignoranza è una forma diconoscenza e come tale può essere utilizzata per arricchire il sistema che stiamo sviluppando.

Anzitutto è importante sottolineare i motivi per cui la qualificazione dell’ignoranza rappre-senta una conquista tanto importante. Fondamentalmente possiamo individuare due motivazioniprimarie:

1. perché ci offre una metrica di valutazione per la bontà del sistema sin ora costituito;

2. perché ci informa di stati indesiderati in cui il sistema potrebbe venirsi a trovare.

Abbiamo già analizzato la prima giustificazione; il grado di emergenza di un sistema è, di fatto,una metrica di dependability del medesimo.

La seconda motivazione è meno ovvia e può apparire in conflitto con quanto detto nei paragrafiprecedenti. Abbiamo infatti sottolineato come sia praticamente impossibile individuare l’emer-genza con un’analisi svolta “a priori” e come, pertanto, non si possa pensare di individuare icomponenti che provocano il fenomeno emergente.

• L’emergenza non può essere conosciuta a priori:

– né per quanto riguarda i componenti cui associarla;

– né per quanto riguarda la sua quantificazione;

• Non si può predirne in modo evidente l’evoluzione.

Abbiamo dunque accennato al fatto che, stanti queste considerazioni, l’unica cosa che rimane dafare è accettarne arrendevolmente la presenza: ogni componente e ogni interazione presente in unsistema può generare emergenza, in quanto sottende una possibile ignoranza che può manifestarsicome fenomeno indesiderato. Il punto di partenza dell’approccio che intendiamo proporre consi-ste proprio nel ribaltamento del punto di vista, che sposta il focus dall’emergenza all’ignoranzache la genera.

Nel prossimo paragrafo mostreremo come sia possibile in questo modo individuare l’emergen-za all’interno di un sistema, mettendoci nelle condizioni di selezionare un subset del sistemapotenzialmente afflitto da tale evenienza indesiderata. Tale subset potrà rappresentare il punto dipartenza di un’eventuale analisi, o ristrutturazione, del sistema.


3.3 D E R I VA R E L’ E M E R G E N Z A

Nei paragrafi precedenti abbiamo sottolineato come l’emergenza sia un carattere difficilmentepreventivabile, tanto che, in ultima analisi, l’unica tecnica realmente approntabile per la sua rile-vazione sia costituita dal ricorso ad una fase di testing. D’altra parte lo studio della medesima haevidenziato interessanti analogie con il concetto di ostacolo in KAOS: in particolar modo, i dueconcetti si caratterizzano entrambi come eventi indesiderati che inducono un impedimento allarealizzazione di un goal. La domanda che sorge spontanea è, pertanto, se sia possibile applicarele regole di analisi vigenti per gli ostacoli in questo nuovo ambito.

Il proseguo della sezione cercherà, di conseguenza, di puntualizzare il legame presente tra idue concetti, evidenziando assonanze e differenze e spiegando come mai nella pratica la teoriavalida per la Obstacle Analysis (OA) perda di validità laddove si parli di sistemi emergenti. Leconsiderazioni offerte costituiranno una ulteriore, e definitiva, prova per ribadire l’inevitabilità deltesting per il rilevamento di condizioni emergenti.

3.3.1 L’Emergenza In Rapporto Alla Obstacle Analysis

Ad una prima, superficiale, analisi i due concetti di OA e studio dell’emergenza potrebbero sem-brare limitrofi: dove si interrompe il campo d’azione degli ostacoli, inizia l’ambito applicativodell’emergenza. L’unica differenza sembra risiedere nella proprietà di consistenza nel dominio diriferimento:

{Ostacolo, Dom} |6= false

che per un fenomeno emergente, non dovendo esso rispondere a supposti requisiti ambientali, nonvale.

Supponiamo però di andare ad integrare vari componenti COTS in un sistema; non è insensa-to pensare di rilevare un’incompatibilità tra le funzioni espresse da due componenti, anche se lespecifiche relative suggerivano un corretto funzionamento. Si chiarifica allora la distinzione traostacolo ed emergenza: la mancata necessità, da parte di un evento emergente, di sottostare adun dominio di conoscenza ha una ripercussione così profonda da rendere i due oggetti concet-tualmente molto differenti. Il primo, l’ostacolo, svolge il ruolo di analisi collaterale al normaleprocesso di RE; si tratta in pratica di un approfondimento utile ad ampliare la QoS del sistema.Al contrario l’emergenza è una condizione che non può essere preventivata e, di conseguenza,non si propone come strumento di arricchimento del sistema, ma di correzione e raffinamento delmedesimo. Questo significa che non solo i due concetti sono analizzati in momenti differenti disviluppo del sistema, ma anche con strumenti differenti: analitici il primo, di testing il secondo.

Da un punto di vista pratico, il rilascio dell’assunzione precedente obbliga chiaramente a rein-terpretare tutte le operazioni correlate al trattamento degli ostacoli. Anzitutto cambia la tecnica diindividuzione. Normalmente un ostacolo viene individuato tramite tre approcci:

• negazione formale dei goal;

• tecniche di regressione;

• euristiche di indirizzamento all’individuazione dell’ostacolo.

3.3 D E R I VA R E L’ E M E R G E N Z A 61

Nessuna di queste tecniche è in contrasto, almeno da un punto di vista pratico, con i principiemergenti. Le tecniche di regressione, ad esempio, consentono di formalizzare condizioni che poi,se coerenti col dominio, vengono intese come ostacoli. Tralasciando l’assunto di coerenza, talicondizioni potrebbero rappresentare una situazione emergente comunque d’interesse. Discorsodel tutto similare si può fare per le altre due tecniche; in fondo entrambe si limitano a trovaresituazioni indesiderate, siano poi esse ostacoli o emergenze sta a noi deciderlo.

Il problema non è tanto la rilettura di queste tecniche per renderle attinenti ai concetti emergenti,la vera questione è se abbia senso ricercare tecniche di estrazione di condizioni emergenti in fasedi RE. Alcune situazioni emergenti sarebbero individuabili con le tecniche appena descritte, mail dispendio computazionale necessario per effettuare un’analisi di questo tipo sarebbe impropo-nibile. L’Obstacle Analysis potenzialmente potrebbe consentire di sviscerare se non le situazioniemergenti (che rimangono aprioristicamente imprevedibili), quantomeno tutte le condizioni di im-pedimento prodotte da una condizione emergente in relazione alla realizzazione di un goal: perfar ciò, si potrebbe banalmente pensare di utilizzare processi regressivi atti a creare un alberodi fallimento per ogni combinazione tra un sub-goal e un insieme generico di sub-goal. Appa-re evidente che se l’OA è già di per sé un’analisi piuttosto complessa, uno studio come quelloappena descritto sarebbe un’evenienza intrattabile per sistemi anche abbastanza piccoli. Quandosi effettua la normale regressione in ambito OA il controllo di coerenza con il dominio permetteinfatti di filtrare considerevolmente la casistica d’interesse, lasciando solo un numero limitato diostacoli che vanno ad interessare l’analisi. Togliere tale restrizione e proporre un’analisi globaleche vada ad integrare tutto è pressoché un’utopia, senza considerare che non avremmo alcun tipodi garanzia sul grado di copertura finale.

Rimane la possibilità di ricorrere ad euristiche, ma anche in questo caso non sembra una sceltafruttuosa. Proporre euristiche per l’emergenza richiama infatti tutte le problematiche discussein precedenza. Euristiche troppo generiche rimanderebbero ai problemi di complessità visti inrelazione alla regressione. D’altra parte euristiche troppo specifiche non sembrano applicabili; ilrischio è quello di scadere, al fine di evitare un’esplosione di complessità, in direttive banali checonsiderano una casistica ovvia di cui un buon progettista tiene implicitamente conto.

L’idea è allora quella di demandare completamente il processo di individuazione delle situa-zioni emergenti ad una fase di individuazione specifica (di cui tratteremo nel paragrafo 4.2), suc-cessiva all’Obstacle Analysis e che adempirà al suo compito sfruttando le conoscenze ottenutetramite testing, vera arma di rilevamento per l’emergenza. L’Obstacle Analysis tratterà dunqueunicamente gli ostacoli e si svilupperà come solito; sfrutteremo però alcuni suoi processi tipiciper reintrodurre l’emergenza nel sistema ed, eventualmente, riuscire a trattarla (vedi capitolo 5).

3.3.2 Raffinamento Dei Goal Emergenti

La seconda fase dell’Obstacle Analysis consiste nel raffinamento degli ostacoli, tramite patternspecifici, al fine di formalizzare ostacoli elementari, in pratica impedimenti sugli agenti. Per capirese questa procedura può essere utilizzata anche parlando di emergenza immaginiamo anzitutto dipossedere la descrizione di un evento emergente, che da qui in avanti chiameremo goal emergente;si tratta di capire se dato un goal emergente si possa o meno effettuare raffinamento in modocanonico.

I pattern pensati per gli ostacoli sono perfettamente compatibili con un ipotetico raffinamentodei goal emergenti. L’idea potrebbe essere quella di avere un goal emergente ad un certo livello


che esprime un comportamento inatteso espresso secondo un certo formalismo. Ci aspettiamoche tale goal emergente non sia elementare, ma sia espressione di un’interazione, più o menocomplessa, tra differenti agenti. L’applicazione dei pattern pensati per la OA non produce alcunassurdo, induce anzi un processo di raffinamento che, correttamente, permette di derivare goalterminali che sono espressione di goal emergenti elementari (referenti cioè un singolo agente oun’interazione tra due agenti). La domanda che ci poniamo è la seguente: l’insieme di goal emer-genti elementari e il main goal emergente sono coerenti col concetto di emergenza? In pratica, seinvertissimo il processo di raffinamento ritroveremmo un goal emergente o il carattere emergentesarebbe perso? Nel momento in cui andiamo ad effettuare il raffinamento ci sono due possibilità.

1. Il carattere emergente dell’ostacolo si esplica già a livello di singolo agente: è ad esempioil caso di un componente inserito in un contesto imprevisto o utilizzato in modo erroneo.In questo caso i goal emergenti elementari racchiudono in sé tutti gli aspetti emergentidel problema in atto: l’emergenza c’è, ma è tutta inerente quel singolo goal elementare.Ovviamente, in una situazione di questo tipo andare ad invertire il processo di raffinamentomantiene il carattere emergente del main obstacle rendendo il processo di raffinamentocorretto.

2. Il carattere emergente dell’ostacolo deriva anche dalle correlazioni tra agenti: in questocaso l’evento inatteso è figlio di un’interazione indesiderata o di una feature che, contestua-lizzata, muta il suo servizio. Se facciamo riferimento alla formula logica che descrive ilmain pattern, in questo caso l’emergenza non si trova negli atomi della formula, quantopiuttosto nei connettivi (and, or, derivazione, etc. . . ) e nelle variabili di stato; ma il proces-so di raffinamento si occupa proprio di eliminare tali costrutti per mantenere solo gli atomi.Quello che accade dunque è che il processo di raffinamento toglie i costrutti che sottinten-dono l’emergenza senza re-introdurre tale concetto (perché non avendone coscienza nonsappiamo come farlo) negli atomi, divenuti sotto-ostacoli. In questo secondo caso dunqueda un main obstacle emergente avremmo ricavato ostacoli elementari non emergenti (per-ché l’emergenza si è persa raffinando e dunque eliminando i connettivi), rendendo vano ilprocesso di raffinamento.

Alla luce delle considerazioni appena addotte appare inutile l’applicazione di un processo di raf-finamento a eventi emergenti. Un ostacolo emergente deve essere inteso, in riferimento ai livellisottostanti, come un’unità atomica con cui dobbiamo avere a che fare, e nei prossimi paragrafivedremo come, ma che non è pensabile, almeno da un punto di vista di pattern formali, pensare diraffinare. Vedremo nel prossimo paragrafo come questo stesso atomo abbia invece una sua utilitàin rapporto ai livelli superiori di astrazione, in quanto rappresenta un costituente per la definizionedel grado di emergenza di tali livelli.

Derivazione Dell’Emergenza

Si inserisce in questo contesto un’interessante considerazione. Sin dal momento in cui abbiamoiniziato a trattare l’emergenza ha iniziato a delinearsi in noi una domanda: esistono pattern formaliper riconoscere ed isolare l’emergenza partendo da requisiti di sistema? Non ci stiamo ovviamenteriferendo alla rilevazione di una “zona d’ombra”, già discussa nel capitolo 3, ma ci chiediamo seesista un modo per qualificare completamente il tipo di fenomeno emergente che si esplicherà.

Tralasciamo per il momento il concetto di ostacolo. L’idea, assolutamente legittima, è che pos-sano esistere regole, siano esse più o meno generali, che, date certe assunzioni e data una specifica

3.3 D E R I VA R E L’ E M E R G E N Z A 63

conformazione, ci indichino una situazione emergente o potenzialmente emergente. A prima vistal’ostacolo potrebbe sembrare rappresentato dalla complessità intrinseca di un problema che coin-volge un numero decisamente elevato di variabili. In realtà riuscire a formalizzare simili regoleformali è probabilmente un task concettualmente errato.

Fondamentalmente l’impedimento in questione nasce dalle medesime considerazioni fatte perl’applicazione dei pattern al raffinamento degli ostacoli. Il problema di base è che l’emergenzasi manifesta a runtime e non è osservabile a priori. Come in precedenza, dato un goal emergentenon eravamo in grado di capire dove si celasse l’aspetto emergente, allo stesso modo, data unaconformazione non è possibile ipotizzare un comportamento emergente. Perché sia possibile in-fatti dovremmo possedere una conoscenza sufficiente per indicare un certo comportamento comesuscettibile di emergenza, ma in tal caso non sarebbe più un evento emergente quanto una normalemanifestazione di un comportamento atteso, sia esso corretto o erroneo. Se l’evenienza non fossestata considerata in fase di modellizzazione, per venire scoperta solo a runtime, non si tratterebbedi comportamento emergente, ma di un errore concettuale del progettista che non ha tenuto inconsiderazione alcune conoscenze da lui possedute.

3.3.3 Analisi Dell’Emergenza: Un Processo Top-Down O Bottom-Up?

Le osservazioni precedenti sulle difficoltà che si riscontrano nel far esternare, tramite pattern,caratteri emergenti passando da un livello di raffinamento al successivo, fanno sorgere un dub-bio di ampia portata: un’analisi di tipo top-down, come quella effettuata da KAOS, è davverol’approccio corretto per affrontare il problema dell’emergenza?

E’ questa la considerazione di partenza che fanno, pur senza riferirsi direttamente a KAOS,Privosnik et al. [46]; la loro ricerca considera infatti pregi e difetti di politiche di tipo top-downe bottom-up in relazione all’emergenza. Proporremo anzitutto le osservazioni presenti nel lorolavoro, per poi definire la posizione che prenderemo nel corso della tesi in relazione a questoproblema.

L’approccio top-down all’analisi e al design di un sistema multi-agents è adottabile con succes-so laddove si abbia un basso numero di agenti o dove, pur con un alto numero di agenti, il sistemasia di tipo risultante. In questi casi infatti un approccio “a cascata” si confà perfettamente a quelleche sono le direttive di un processo di RE. D’altra parte, se il sistema è emergente l’approccio ten-de a fallire perché, come abbiamo osservato in precedenza, la natura prettamente non-riduzionaledi un fenomeno emergente prende il sopravvento.

D’altra parte laddove si vada ad effettuare uno studio di tipo RE l’approccio bottom-up rivelatutti i suoi limiti. Anzitutto fare requirement engineering partendo dai componenti non è pratica-bile per l’assenza stessa dei componenti in questa specifica fase di studio. Inoltre, un approcciobottom-up si rivela inadatto allo studio e alla verifica di proprietà generali e, di conseguenza, allosviluppo di sistemi che devono soddisfare certi requisiti globali. Inoltre “seguire” l’emergenza inuna catena di tipo bottom-up non è realistico; basti pensare al fatto che quest’ultima può derivareanche dall’integrazione di due goal.

In [46] si propone un approccio che cerca di mediare tra le due soluzioni: il ricorso ad un’ar-chitettura gerarchica a livelli. Si suppone in pratica di avere più livelli di lettura e, ad ogni livello,vedere il sistema come la composizione di strutture elementari, per quel particolare punto di os-servazione. In sostanza una struttura elementare ad un certo livello sarà composizione di piùstrutture elementari al livello sottostante. Una simile strutturazione permetterebbe di raccogliere


i vantaggi delle due politiche descritte in precedenza. Da una parte avremmo una visione tipica-mente bottom-up in cui si va ad organizzare il sistema come composizione di organismi che rea-lizzano certe feature; d’altra parte potremmo comporre tali organismi, e studiarne più facilmentecondizioni emergenti, partendo dai componenti di base.

Secondo il nostro punto di vista, un’architettura gerarchica a livelli non pare direttamente appli-cabile in KAOS; terremo comunque conto delle considerazioni appena fatte quando, nel capitolo4, andremo ad analizzare il ricorso al testing per lo studio delle condizioni emergenti. In talecontesto infatti interpreteremo l’albero dei goal prodotto da KAOS utilizzando diversi livelli dilettura, al fine di avere componenti agglomerate con specifiche proprietà da verificare in fase ditesting.

3.4 C O M P O S I Z I O N A L I TÀ D E L L’ E M E R G E N Z A

Nei paragrafi precedenti abbiamo completato la disamina del concetto di emergenza nella RE. Lostudio condotto ha permesso di apprezzare le peculiarità della nuova nozione, purtroppo però haanche palesato l’impossibilità di condurre un’analisi costruttiva, che permetta di preventivare unfenomeno emergente in una fase precedente a quella di testing: sembra in sostanza venir meno lapossibilità di sfruttare la rilettura del concetto di fallimento sistemico data.

In realtà, come abbiamo accennato in precedenza, pur privati della possibilità di formalizzareintegralmente un fenomeno emergente, è possibile approcciare tangenzialmente il problema eottenere informazioni comunque importantissime nell’ottica di un sistema complesso.

3.4.1 Le Fonti Di Emergenza

Si tratta anzitutto di stabilire in modo univoco quali costrutti all’interno del sistema dovrannoesser letti come potenziali fonti di emergenza. Per quanto detto in precedenza, si possono indicaretre possibili cause dietro la genesi di un comportamento inatteso:

1. componente;

2. interazione;

3. contesto (evento esterno).

Osserviamo da vicino i differenti soggetti in esame.

1. Componente: l’elenco delle cause non può che partire dal singolo componente. Abbiamoosservato (e lo paleseremo ancor di più parlando di componenti COTS - vedi capitolo 7)come uno dei nodi di ignoranza primari sia rappresentato proprio dalle limitate conoscenzache possediamo sugli strumenti che si vanno ad utilizzare. Indipendentemente dal fattoche si maneggi agenti hardware o software, ogni qual volta si abbia a che fare con sistemicomplessi o con costrutti realizzati da soggetti differenti, si deve considerare la possibilità,e anzi la inevitabilità, di un funzionamento del componente distante da quello atteso. Leragioni di tali evenienze non sono necessariamente correlate ad un’errata progettazione oimplementazione, ma possono riguardare un utilizzo inappropriato o l’inserimento in uncontesto non consono. Al di là delle specifiche ragioni rimane l’assunto secondo cui ogni

3.4 C O M P O S I Z I O N A L I TÀ D E L L’ E M E R G E N Z A 65

componente è portatore di uno strato di ignoranza che, all’interno di un sistema, può indurreemergenza.

2. Interazione: anche le interrelazioni tra componenti sono una fonte evidente di emergenza.Ogni volta che correliamo tra loro due componenti, che spesso non sono nemmeno pensatiin origine per collaborare, si può incappare in un utilizzo improprio o, semplicemente, inun output inatteso.

Si potrebbe obiettare che in realtà parlare di ignoranza a livello di componente o di emer-genza a livello di correlazione di questi ultimi sia in realtà la stessa cosa. In effetti ognicorrelazione emergente è figlia di un’ignoranza sul componente; di conseguenza, andandoad associare un grado di ignoranza al componente, implicitamente si qualifica un grado diemergenza sull’interazione. La scelta di differenziare questi due concetti è però connessaad un aspetto importante inerente le correlazioni tra componenti, il fatto cioè che la pro-gettazione del sistema garantisca solitamente un ventaglio di possibilità nelle modalità dicorrelazione. La presenza di soluzioni alternative nella messa in opera di un componenteimplicitamente ci obbliga a considerare differenti gradi di emergenza connessi con ogniscelta. Ogni componente possiede quindi un suo grado intrinseco di ignoranza, ma le dif-ferenti modalità di correlazione tenderanno ad esplicitarlo in modi differenti, producendoeffetti quantitativamente differenti.

Implicitamente il ragionamento appena fatto induce un’euristica di progetto. La qualità diun sistema dipenderà anche dalle modalità utilizzate per connettere gli agenti presenti; sidovranno quindi preferire soluzioni semplici o comunque soluzioni quanto più possibilescevre di aree d’ignoranza.

3. Contesto: l’ultima fonte di emergenza che prenderemo in considerazione è rappresentatada possibili eventi esterni al sotto-sistema in esame che inficino il corretto funzionamentodel sistema. In precedenza abbiamo sottolineato come la soddisfazione di un requisito siaovviamente figlia del corretto funzionamento dei componenti e di corrette correlazioni trai medesimi, ma potrebbero intervenire eventi esterni, impredicibili, che sovvertono il rego-lare svolgimento del lavoro inducendo un fenomeno emergente. Oppure, semplicemente,il contesto operativo è particolarmente stressante in relazione alle funzionalità offerte dalcomponete. Parlando di contesto, o di evento esterno, facciamo pertanto riferimento adogni possibile accadimento limitrofo, da un punto di vista logico e non necessariamentefisico, allo spazio d’uso dei componenti in esame. É il caso più difficile da considerare perla totale estraneità ai dati posseduti. In tal senso diventa estremamente complesso non soloidentificarlo, ma anche provare a quantificarlo.

In generale la politica che seguiremo sarà quella di riporre maggiore fiducia sui contestidi cui sappiamo molto e che non si caratterizzano per “ambientalità estreme”; al contrariol’utilizzo del sistema in un ambiente a noi non totalmente definito può essere indizio dimanifestazioni inattese.

3.4.2 Comporre L’Ignoranza

Definite le fonti di emergenza di un sistema, si tratta adesso di capire come esse si relazioninotra loro sino a sfociare in un fenomeno emergente, cioè una manifestazione che si pone comeostacolo alla realizzazione di un requisito sistemico.


Anzitutto è necessario chiarire i limiti nei quali intendiamo muoverci. Utopisticamente il taskdi un’analisi come quella che intendiamo portare avanti dovrebbe essere approssimabile ad unaobstacle analysis o al suo inverso:

• date certe evenienze emergenti ad alto livello, trovare le interazioni o comunque le condi-zioni che le determinano;

• date delle condizioni di ignoranza di base, preventivare le situazioni emergenti che potreb-bero prodursi.

D’altra parte non è possibile pensare di derivare o esplicitare specifiche condizioni emergenti;l’ottica nella quale ci si deve porre abbandona pertanto l’idea di evidenziare un singolo fenome-no emergente, per cercare piuttosto di quantificare il grado di ignoranza (e, di conseguenza, laprobabilità di una sperimentazione emergente) associato ad una specifica area del progetto.

Si suggerisce in sostanza di abbandonare la velleità di studiare compiutamente l’emergenza,poiché di essa non è possibile ipotizzare né un modello qualitativo, né uno quantitativo, e diconcentrarci invece su ciò che sappiamo o, parafrasando Socrate, sappiamo di non sapere: l’igno-ranza, che in questo caso è anche la genesi del problema. L’assunto alla base dell’approccio èassolutamente banale: dove c’è più ignoranza, ci aspettiamo di poter riscontrare più emergenza.

Intuitivamente l’idea non può che apparire corretta: se riusciamo ad individuare le zone delprogetto di cui conosciamo meno particolari (da un punto di vista dei componenti, delle relazionio del contesto), saremo in grado di indicare le aree in cui, probabilisticamente, si potrebbe manife-stare un fenomeno emergente. Si noti che in realtà il sillogismo proposto non è del tutto corretto,proprio in relazione alla sua focalizzazione quantitativa e non qualitativa. Il fatto è che non èsempre vero che maggiore ignoranza induce effetti emergenti più rilevanti: ci potrebbero esseredei componenti di cui non sappiamo quasi niente ma che, per la loro natura o per il tipo di utiliz-zo, sono tendenzialmente meno propensi a generare una risultanza emergente; d’altra parte, nonsapere un piccolo aspetto di un componente potrebbe tradursi immediatamente in un fenomenoemergente molto negativo. Peraltro, l’idea stessa di associare un grado di ignoranza può esserecriticata: come possiamo essere sicuri di aver coscienza dell’ignoranza che abbiamo in relazionead un agente? Le due critiche sono ovviamente entrambe valide, ma trovano ancora una voltarisposta nell’idea secondo cui, stanti i limiti strutturali indotti dalla natura stessa dell’emergenza,tutto quello che si può fare è approcciare intuitivamente e quantitativamente il problema.

Rimane da capire come interlacciare le differenti localizzazioni dell’ignoranza.

Trattare L’Emergenza Nella RE

Un simile obiettivo è raggiunto sfruttando il modello agenti di KAOS in congiunzione con l’alberodei requisiti. La scelta di far riferimento a strutture di tale framework è figlia della volontà direndere la trattazione più semplice e maggiormente in linea con il resto del lavoro. Si fa notareinfatti come l’approccio che descriveremo sia facilmente estendibile ad una qualsiasi tecnica diRE di tipo GORE; previa, ovviamente, la definizione di una struttura non troppo dissimile dalmodello agenti sviluppato in KAOS.

L’uso congiunto delle due strutture consente di entrare in possesso di quasi tutte le conoscenzeaccennate in precedenza.

• Il modello agenti:

– dettaglia i componenti presenti nel sistema;


– informa sulle interazioni che li correlano.

• L’albero dei requisiti:

– consente di focalizzare l’analisi su un singolo sub-set dell’intero sistema e informasulla gerarchia dei requisiti.

Si nota immediatamente come in realtà manchi una nozione rispetto a quelle precedentementeelencate, il contesto.

La mancanza del contesto non è da considerarsi una deficienza strutturale di KAOS, ma è inrealtà figlia di una problematica maggiore relativa all’attuabilità stessa di un’analisi emergentenell’ambito della RE. I tre concetti di base descritti in precedenza sono infatti, inevitabilmente,espressioni di scelte progettuali mature.

• Componente: l’ignoranza su di un componente può essere ipotizzata solo avendo ben inmente uno specifico elemento.

• Interazione: anche in questo caso un’approssimazione del livello di ignoranza appare sen-sata se già sono state fatte alcune scelte tipicamente implementative più che progettuali.

• Evento Esterno: le medesime considerazioni ovviamente valgono per gli eventi esterni, figlidi un contesto che al termine della RE non è ancora sufficientemente chiaro.

Le limitazioni espresse sono conseguenza del gap presente tra la formalizzazione dei requisitie la definizione dei componenti reali. Un tipico processo di RE infatti si occupa di strutturareun’architettura in cui siano definiti gli agenti in gioco e le loro correlazioni; gli agenti in giocoperò rimangono costrutti teorici. Le scelte che trasformano tali enti ipotetici in agenti fisici, se-lezionandoli dalla pletora di possibili alternative, vengono fatte in una fase successiva. L’idea èdunque quella di sviluppare un’analisi che non si collochi logicamente all’interno della RE, main un momento immediatamente successivo. Non stiamo ovviamente proponendo l’adozione diuna tecnica valutativa post-implementazione, ma, certamente, senza aver prima effettuato alcunescelte, che normalmente sono escluse da una RE tipica, appare difficile pensare di formalizzare estudiare il concetto di ignoranza e le sue differenti specializzazioni.

Il concetto di contesto e le ipotesi correlate all’intervento di eventi esterni sono pertanto intro-dotte nello studio come conseguenza di tale momento di analisi addizionale; terminata la RE edefinite alcune scelte di base, il progettista sarà in grado di offrire un’approssimazione, sia purlabile, del grado di incidenza di un evento esterno.

3.4.3 Modello Di Analisi Dell’Emergenza

Definite le premesse tecniche e la natura degli oggetti interessati, si tratta adesso di descrivere neldettaglio il modello che intendiamo proporre. Abbiamo sottolineato in precedenza come le duestrutture cui faremo riferimento saranno l’albero dei requisiti e il modello agenti, la trattazionesarà portata avanti pertanto con un continuo parallelo tra le informazioni aggiunte ed estratte dalledue strutture.

Analizziamo anzitutto lo stato iniziale.

• La prima operazione, implicita, da compiere consiste nell’associazione di un grado di igno-ranza ai differenti agenti. Tale quantità, dal lato requisiti, viene arricchita di un contesto


e rappresenterà il grado di ignoranza di un requisito elementare. Ciò avviene perché ge-neralmente un requisito di base altro non è che la realizzazione di una feature da parte diun agente: l’ignoranza si compone in tal caso di una possibile mancata conoscenza sullafeature (cioè sul componente), unita ad un’eventuale ingerenza del contesto.

• Oltre alla conoscenza costruita sui requisiti di base, ne possediamo altre, dettate dal progettostesso, sull’architettura:

– modalità di interrelazione tra i componenti;

– differenti contesti in cui si muove il sistema.

Date queste premesse è possibile iniziare l’analisi d’interesse, che ovviamente si prefigura comeun processo iterativo. L’evoluzione del flusso d’ignoranza deve essere studiata considerando ilminimo livello di granularità: questo significa che il lavoro dovrà proseguire con un’analisi dellesingole “famiglie” dell’albero di KAOS; un parent-goal con i relativi sub-goal. L’affermazionepuò sembrare triviale, in realtà potremmo però pensare di applicare queste stesse metodologielavorando con un qualsiasi livello di astrazione. D’altra parte è nostra opinione che, considerandoanche i limiti conoscitivi in cui già siamo costretti a muoverci, un risultato valido possa esse-re ottenuto unicamente andando a scandagliare tutti i nodi d’interesse e, dunque, prendendo inconsiderazione la granularità minima.

Prendiamo in considerazione pertanto i sub-goal relativi ad un unico parent-goal. Si tratta dicapire come trasformare il loro grado di ignoranza in un grado di emergenza per il goal padre.Facciamo notare che durante la trattazione faremo riferimento a due figli anche se tale cardinalitàpuò variare liberamente; le considerazioni che offriremo sono comunque banalmente estendibiliad un numero qualsiasi di figli.

Sub-goal allo stesso livello possono essere correlati da due tipologie di dipendenza, and o or;cerchiamo di capire come è opportuno elaborare le due situazioni.

Due sub-goal correlati in AND sottintendono che la realizzazione del parent-goal necessitadella realizzazione di entrambi. Questo di fatto implica che l’ignoranza su entrambi i sub-goalpartecipa contemporaneamente all’ignoranza sul padre, che, pertanto, può essere pensata come la“summa”, intesa in senso lato, degli specifici gradi di ignoranza. Abbiamo utilizzato i termini “insenso lato”, perché non avendo esplicitato un formalismo univoco per rappresentare i gradi, nonè possibile offrire una formula definitiva; comunque, indipendentemente dalla soluzione scelta, èessenziale considerare entrambi gli apporti. In tabella 4 è presente una schematizzazione dellasoluzione da noi proposta. Nella prima colonna si può leggere il connettivo che relaziona i due,o più, sub-goal; per ogni connettivo è descritto un formalismo utilizzabile per rappresentare ilgrado di ignoranza (abbiamo considerato i tre formalismi più immediati) e per ognuno è data unafunzione da utilizzare per calcolare il grado del parent-goal.

Anzitutto, si vuole sottolineare una particolare scelta da noi effettuata. Come si può vedere intabella 4, la funzione di riferimento per sub-goal in AND con rappresentazione percentuale, malo stesso discorso vale per la rappresentazione intera, è rappresentata dalla selezione del massimo.Generalmente, si pensi ad esempio all’analisi probabilistica, in situazioni di questo tipo, in cuidue valori sono connessi in AND per offrirne uno nuovo, si tende a preferire soluzioni che fannoriferimento alla media o al prodotto tra percentuali. In questo caso si è preferito percorrere unastrada differente per la particolare natura del fenomeno in studio. La differenza tra le due soluzionirisiede infatti fondamentalmente su di una particolare chiave di lettura.


• L’approccio con prodotto intende il grado di livello superiore come una valutazione mediadell’ignoranza sottostante. In pratica l’ignoranza generale da noi supposta viene diffusasulla molteplicità dei componenti.

• Al contrario, un approccio che ricorre al massimo tiene memoria del componente su cui siha l’ignoranza maggiore.

Studiando l’ignoranza si ritiene che la seconda soluzione sia la migliore, perché permette di quali-ficare un sistema come tendenzialmente emergente laddove si abbia la presenza anche di un ridottonumero di componenti su cui sappiamo poco. L’idea che vogliamo ricercare è che anche un solocomponente di cui sappiamo molto poco è critico per la bontà del sistema. Scegliendo questasoluzione pertanto consideriamo peggiore un siffatto sistema, rispetto ad uno in cui sono presentipiù componenti con ignoranza, ma il loro grado di ignoranza non è mai troppo alto. Ovviamentele suddette considerazioni devono essere intese come proposte di approccio al problema, sceglierefunzioni differenti da quelle descritte non inficia il funzionamento complessivo del metodo.

Connettivo Rappresentazione Grado FunzioneAND % maxAND int (in scala) maxAND bool orOR % minOR int (in scala) minOR bool and

Tabella 4: Funzioni di riferimento per il calcolo del grado di emergenza di un goal padre, dati i gradi diignoranza dei sub-goal.

Stabilite le funzioni da utilizzare per correlare i gradi dei sub-goal possiamo completare l’analisiinserendo gli altri elementi in causa. In Figura 12 è riassunto l’ambito in esame, in un siffattosistema, in cui i sub-goal sono correlati in AND. Il grado di emergenza del parent-goal potràessere ottenuto:

gradogoal.p = max{gradogoal.c1, gradogoal.c2} + gradolink + gradoee

La precedente riassume le considerazioni fatte nel corso del paragrafo, l’ignoranza relativa alparent-goal sarà infatti composizione dell’ignoranza su:

1. sub-goal e loro necessità per il requisito;

2. la tipologia di correlazione tra sub-goal;

3. contesto in cui si muove il sotto-sistema di interesse per quel requisito.

Nel caso di una correlazione in OR, il grado risultante sarà ovviamente:

gradogoal.p = min{gradogoal.c1, gradogoal.c2} + gradolink + gradoee

Ci siamo quindi posti nelle condizioni di definire analiticamente l’ignoranza su un goal non ele-mentare, dati requisiti di base. Ovviamente, l’ignoranza sul parent-goal altro non è che il gradodi emergenza del sotto-sistema di cui tale goal è radice. Iterando il procedimento si può dunquepervenire al grado di emergenza del main goal, mappando l’intero sistema tramite l’associazionedi valori di emergenza.


Figura 12: Sintesi del sistema minimo analizzato dal metodo proposto.

3.4.4 Vantaggi Dell’Approccio Proposto

L’analisi proposta consente di accrescere considerevolmente la conoscenza del sistema che si staprogettando, offrendoci un punto di vista che solitamente viene tralasciato in toto. Fondamental-mente i vantaggi connessi alla sua adozione sono riassumibili:

1. associazione di un grado di emergenza ad ogni requisito del sistema:

• sia a livello globale (main goal);

• che a livello dei sub-goal;

2. rilevamento di zone logiche all’interno del sistema maggiormente propense a produrrecondizioni emergenti.

Ciò che ci attendiamo da un’analisi di questo tipo è difatti una mappa dell’emergenza, o megliodelle sue cause, non uniforme, conseguenza della natura stessa del processo di progettazione, chetende a focalizzarsi su certe specificità del sistema, tralasciandone, o comunque analizzandolesolo superficialmente, altre. Di norma, quindi, sperimenteremo l’evidenza di un sistema in cuialcune gerarchie di requisiti (un parent-goal con relativi figli a differenti livelli) sono tendenzial-mente ben conosciute, mentre altre contengono componenti su cui abbiamo scarsa conoscenza.Gli approcci risolutivi applicabili per rispondere a condizioni fortemente svantaggiose, in cui adesempio si sia palesato un grado di emergenza troppo alto in relazione ad un requisito chiave,possono essere molteplici (si veda in proposito il capitolo 2). Si noti comunque come il metodoinduca banalmente la rilevazione di componenti chiave che producono un alto tasso di emergenza.Di per sé un componente su cui si abbia notevole ignoranza non è inutilizzabile; ovviamente si do-vrebbero preferire componenti maggiormente conosciuti, ma se trattasi di un agente scarsamente


usato, e magari su requisiti non cruciali, si può pensare di innestarlo comunque nel sistema. D’al-tra parte un componente con grado di ignoranza media, potrebbe essere massicciamente utilizzatocomportando un degrado importante della qualità del sistema prodotto. L’analisi appena descrittapermette di evidenziare comportamenti di questo tipo in modo immediato: sarà sufficiente infattiandare a modificare il grado di ignoranza associato ad un componente nel modello agenti, perosservare le modificazioni negli indici di emergenza indotte nell’albero dei requisiti. Un siffattosistema ad esempio potrebbe, e a nostro parere dovrebbe, giocare un ruolo chiave anche nellaselezione di componenti COTS (aspetto che infatti indagheremo nel capitolo 7).

Il nostro procedimento verrà “messo alla prova” nel capitolo 6, in cui utilizzeremo gli strumentiappena discussi per analizzare un sistema critico.

Un’Analisi “Distruttiva”

É interessante notare il particolare orientamento del metodo, il quale, nato dalla volontà di pro-porre un’analisi costruttiva capace di verificare proprietà, si caratterizza invece come uno studioatto a indebolire le certezze possedute ed accertare l’assenza (o comunque la parziale mancanza)di tali proprietà.

Scopo non dichiarato, e in un certo senso utopico, del presente lavoro era infatti la ricerca didirettive che consentissero, date certe proprietà d’interesse, di certificare l’assenza di tutte quellecondizioni che potevano minare la qualità di tali proprietà. L’analisi dei comportamenti emergentie l’identificazione dell’ignoranza quale responsabile primario dei fallimenti inattesi, ci obbliganoa desistere dalle nostre velleità: la permanente e inevitabile presenza di ignoranza ci impedisce apriori, come abbiamo visto, di poter anche solo ricercare una metodologia di questo tipo.

Né d’altra parte questa nuova consapevolezza deve sminuire il valore del lavoro condotto edello studio proposto. Il nuovo ruolo dato all’ignoranza e la qualità, e quantità, di informazioniottenibili dalla sua disamina, permettono di accrescere considerevolmente la correttezza di unsistema informatico, eliminando eventi inattesi o, ove non sia stato possibile, offrendo indicazioniprecise per la loro risoluzione.

Analisi Dell’Emergenza: Uno Studio In Più Fasi

L’approccio proposto per la disamina dell’emergenza evidenzia un aspetto che diverrà palese nelproseguo della trattazione (in particolar modo quando parleremo di testabilità - capitolo 4): l’a-nalisi dell’emergenza non è uno studio che si innesta e si esaurisce in un momento specifico delciclo di sviluppo di un sistema informativo.

Un primo “attacco” al problema dell’emergenza può essere fatto, seguendo la tecnica appenadescritta, nella fase di RE vera e propria, o comunque in un momento immediatamente successi-vo (si rivedano le considerazioni a proposito della fase di scelta dei componenti). D’altra partel’analisi è assolutamente attuale, e anzi esprime in quel contesto la sua maggiore efficacia, anchequando si ricorra a tecniche di testing per certificare il corretto comportamento dell’architetturasviluppata. In questa fase infatti saremo in grado di “toccare con mano” comportamenti emergenti,approntando di conseguenza le giuste contromisure per individuare le criticità ed eventualmentecorreggerle (tratteremo queste problematiche nei capitoli 4 e 5). Né lo studio dell’emergenza puòconsiderarsi ultimato al momento del testing; l’utilizzo reale del sistema potrebbe infatti offrirenuove evidenze di questo tipo, che potranno essere affrontate proprio con la mappa dell’emer-genza e dei requisiti discussa in queste pagine. Peraltro quest’ultima tipologia di fallimenti si


prefigura come la più dannosa in quanto non è né ipotizzata (come nell’analisi dell’ignoranza), nérilevata su di una casistica ipotetica (come nel testing).

Quando parleremo di “studio dell’emergenza” faremo pertanto riferimento ad un concetto am-pio e variegato, che si compone di una serie di analisi di differente natura. Ad ogni modo, ilcontesto, oppure opportuni chiarimenti, permetteranno di non scadere in situazioni di ambiguità.

3.5 C O N S I D E R A Z I O N I C O N C L U S I V E

Il presente capitolo rappresenta il punto di svolta dell’intero lavoro. L’idea centrale è rappresentatadalla rilettura dei fallimenti sistemici come proprietà emergenti di sistemi complessi. Si è cercatoin sostanza di andare oltre il mero parallelismo fallimento-errore, per rileggere un fallimentocome il prodotto di una serie di apporti, quali: definizione dei componenti parziale, immissionedi feature troppo specializzate, utilizzo in contesti inusuali o inattesi, etc. Tutti questi apporti, chepotrebbero anche non essere considerati veri e propri errori, si sommano convergendo in uno statodel sistema disatteso: un fallimento.

Il nuovo strumento teorico in nostro possesso è stato compiutamente contestualizzato, dandoampio spazio alla sua rilettura in ambito informatico. Il concetto in effetti era già stato introdottonell’ottica dei sistemi informativi, ma, nonostante la sua criticità, ci si era sempre arrestati acongetture limitate sia in termini di struttura formale costituita, sia in termini di utilizzo indotto;peraltro non era mai stata condotta una disamina completa di questa nozione, che permettesse, adesempio, di rapportarla alle varie tecniche specifiche del settore.

Il nostro studio, al contrario, ha esaurientemente analizzato le differenti specificità dell’emer-genza e del suo rapporto con la RE. A nostro modo di vedere infatti è proprio in questa fase delciclo di vita di un progetto (o meglio, come detto in precedenza, immediatamente dopo), chel’emergenza assume maggior interesse, prefigurandosi non come concetto lato, ma come metricaprecisa per qualificare e correggere la bontà di un sistema. L’unione delle conoscenze ottenutee quelle derivanti dal framework KAOS hanno infatti portato allo sviluppo di una tecnica di pre-venzione almeno parziale. Se è vero, e questo è uno dei risultati teorici più evidenti del capitolo,che non è possibile pensare di improntare uno studio pro-attivo per la rilevazione e reazione afenomeni emergenti, in quanto la loro aleatorietà impedisce di estrapolarli in una fase precedentea quella di testing, è altrettanto evidente che la nuova tecnica proposta consente di arricchire con-siderevolmente il nostro background di conoscenze, diminuendo significativamente le criticità diun sistema in fase di sviluppo.

La nuova accezione consente di approcciare le problematiche di ingegnerizzazione dei requisitiin modo, a nostro parere, maggiormente cosciente, focalizzando l’attenzione sulla quantificazionedell’ignoranza: un aspetto che spesso viene sotteso e che invece, come aveva già evidenziato ilcapitolo 1, ha un ruolo assolutamente preminente.

Capitolo 4Testabilità In Sistemi Emergenti

“Design is not just what itlooks like and feels like.Design is how it works.”

Steve Jobs

Il capitolo precedente ha cercato di formalizzare il concetto di emergenza e di sistemi emergenti,sottolineando come per questi ultimi l’unica forma di verifica per la correttezza sia rappresentatadal testing. Nelle prossime pagine estenderemo pertanto l’analisi proprio a questo specifico am-bito, cercando di qualificare le direttive da seguire nell’ottica dello sviluppo di una fase di testspecificamente orientata alla disamina di evenienze emergenti.

La trattazione può essere pensata divisa in due momenti conseguenti. Anzitutto, in sezione4.1, approfondiremo le problematiche di testabilità di sistemi complessi, in tal modo sarà pos-sibile estrapolare le caratteristiche principali che dovrebbe possedere uno strumento di analisi edi manipolazione della fase di testing vera e propria. Muniti di queste nuove certezze analizze-remo (sezione 4.2) il rapporto tra la fase di testing, la rilevazione di contingenze emergenti e ilframework KAOS, qualificando l’orientamento GORE (e, nello specifico, il goal-tree tipico diKAOS) come strumento ideale per l’elaborazione e l’analisi di test.

4.1 T E S TA B I L I T Y

Stabilita l’inevitabilità del ricorso al testing per evidenziare la presenza di situazioni emergentiall’interno di un sistema, la nostra attenzione si sposta adesso sulla struttura che tale momento dianalisi dovrà assumere per conformarsi pienamente alle specificità dei sistemi emergenti. A talfine inizieremo il nostro studio con una disamina del concetto stesso di testing e, in particolare,di testabilità (specialmente in ambito software). L’idea è quella di evidenziare le criticità su cuiè necessario porre attenzione per rispettare i principi di testabilità di un sistema software. Ovvia-mente, per non dilungare troppo la trattazione, riporteremo solo gli aspetti di reale interesse ancheper l’ambito emergente.

73

74 T E S TA B I L I TÀ I N S I S T E M I E M E R G E N T I

La generazione di test per sistemi hardware o software può essere pensata a tre differenti livelli diapplicazione al crescere del grado di profondità dell’analisi:

1. livello applicativo;

2. livello funzionale;

3. livello strutturale.

Il livello applicativo è quello più semplice caratterizzandosi come la mera messa in opera di unsistema. Di fatto viene sperimentato ogni giorno dai customer che comprano un componente VeryLarge Scale Integration (VLSI [48]) pre-costruito, ad esempio un processore, e lo immettono inun sistema per verificarne il corretto funzionamento. Tale metodologia di analisi, ammesso che sipossa definire tale, è chiaramente limitante in termini di qualità del risultato offerto. Il problemaè che operando in questo modo si vanno ad analizzare solo un numero limitato di stati in cui ilcomponente potrebbe venirsi a trovare, non assicurando in alcun modo che, nel caso di un testpassato con successo, il chip in esame sia effettivamente privo di guasti.

Il livello funzionale offre una copertura decisamente maggiore del precedente, poiché in questocaso si va a stressare il chip considerando l’intero range di feature per il quale era stato progettato.A tal fine si considera non tanto il chip come entità singola, quanto piuttosto come aggregazionedi moduli e si vanno a testare tali sotto-unità. Stavolta il black-box in esame è dunque il modulostesso, il quale viene visto come un fornitore di funzioni dati opportuni input (generalmente sipossiedono proprio le coppie “input/output atteso”). La conoscenza della struttura interna deimoduli non è richiesta.

Il testing a livello funzionale offre chiaramente una copertura maggiore del precedente, maancora non si raggiunge il 100%. Copertura che invece viene assicurata, o comunque avvicinatasignificativamente, dal livello strutturale, in cui la test generation considera la struttura stessa delcomponente: la mappa delle porte logiche dal lato hardware, l’implementazione dal lato software.Dal punto di vista di un utente, o compratore, il problema in questo caso risiede ovviamente nelladisponibilità di tali informazioni: generalmente chi acquista chip VLSI o prodotti COTS non puòavere accesso alla struttura interna.

D’altra parte, anche considerando il produttore stesso dei componenti, l’operazione può nonessere banale. Generalmente si tende infatti a concepire la fase di testing come una fase assestante,slegata dal naturale processo di progettazione di un sistema e demandata ad un gruppo specificoche, trovandosi di fronte ad un prodotto finito o quasi finito, delinea opportune politiche di analisi.Questa linea di pensiero ha fatto sì che, negli anni, i costi legati alla fase di testing siano cresciuti dipari passo con l’aumento della complessità dei sistemi tecnologici sviluppati. Inevitabilmente si èquindi fatta largo l’idea secondo cui già a livello di design del progetto si dovesse in qualche modotener conto dell’attitudine dello stesso ad essere utilizzato per effettuare testing. A tal proposito siè iniziato a parlare del concetto di Testability (testabilità) [49] [50] di un sistema, intesa come unametrica atta a valutare la facilità con cui si può effettuare testing su di un sistema finito.

4.1.1 Testability: Le Parole Chiave

La testability non deve essere pensata come una metodologia precisa di sviluppo di un sistemasoftware o hardware, quanto piuttosto come un’attenzione particolare che deve essere posta nelprogetto, e nell’integrazione, dei singoli componenti del sistema. In tal senso si fa riferimento inmodo particolare a due concetti chiave:

4.1 T E S TA B I L I T Y 75

1. controllability [51] [52];

2. observability [53] [47].

I motivi per cui si introducono queste due metriche sono ovvi: per testare un componente è in-dispensabile avere un sufficiente controllo sui suoi input; d’altra parte, perché il test abbia unsignificato si dovrà verificare la natura dell’output riportato, necessitando pertando di sufficientiprivilegi di leggibilità. Soltanto tenendo in considerazione entrambi questi aspetti, si può pensaredi ottenere un sistema realmente testabile.

La carenza di controllo e leggibilità nasce come conseguenza della struttura intrinsecamentecomplessa dei sistemi odierni. Quotidianamente assistiamo ad un incremento della densità deicomponenti fisici e delle feature che vi si devono applicare e, anche laddove si riesca a realizza-re un modulo altamente testabile, sussiste poi il problema del mantenimento di tale peculiaritàall’interno del sistema che lo utilizzerà. Quando si va ad immettere un modulo all’interno di unsistema infatti spesso esso perde la sua natura assestante, per divenire un nodo di passaggio nell’e-laborazione tra differenti sotto-sistemi. In pratica, perdiamo in termini di controllability, poichésvaniscono gli accessi diretti al modulo e si perde in termini di observability, perché l’output pro-dotto viene utilizzato, e dunque rielaborato, da altri moduli prima di divenire leggibile all’esterno.Proprio per queste ragioni uno degli approcci alla base della Design For Testability (DFT, cioèdi una progettazione che tenga in considerazione la testability) è rappresentato dalla rimozione, omeglio dalla capacità di rendere trasparenti, tutti i moduli, eccezion fatta per quello di interesse:il sistema deve cioè essere settabile in modo tale da poterne isolare sue specifiche parti.

Apparirà adesso chiara la necessità di considerare tutte queste problematiche già a livello didesign del progetto: rendere un sistema testabile implica l’immissione di feature aggiuntive neivari moduli e questa è un’operazione assolutamente non realizzabile a prodotto finito.

4.1.2 I Fattori Che Influenzano La Testability Software

Risulta molto difficile individuare quali scelte progettuali o implementative si ripercuotano mag-giormente sul grado di testabilità finale di un sistema; di fatto possiamo affermare che quasi tuttele scelte compiute nella fase di design del medesimo abbiamo un qualche tipo di risultanza sullasua testabilità. Proprio per questo motivo, la letteratura del settore è ricca di articoli contenentidirettive, nel senso più generale del termine, che si prefigurano come linee guida da seguire du-rante la fase di progettazione. Tali direttive spaziano dalle banali norme di buona progettazione,a rigide regole per la scelta dei componenti fisici del sistema [50] o del tipo di programmazioneadottata [52]. Visto il focus attuale del lavoro, tralasceremo quasi interamente le considerazionirelative all’ambito hardware, per concentrarci in modo particolare sulle linee guida riguardanti illato software.

Da un punto di vista pratico infatti, la testability è tanto un problema tecnico/fisico, quantoun problema legato al processo di sviluppo e alle scelte implementative adottate. In [52] gliautori individuano sei fattori primari, correlati all’intero processo di sviluppo del software, chepossono influenzare la qualità della testability del prodotto finale. Cercheremo di caratterizzarebrevemente ognuno di questi fattori, arricchendo la trattazione con considerazioni personali especificità riprese da altri lavori presenti in letteratura [47] [49]. I sei fattori nodali sono:

• rappresentazione;

• implementazione;


• built-in-test;

• test suite;

• test case.

Essi rappresentano la spina dorsale dell’intero processo di sviluppo di un sistema testabile.

Rappresentazione

La forma rappresentativa del sistema è un fattore cruciale per la qualità del testing risultante. Lemodalità di rappresentazione di un sistema spaziano dall’utilizzo del linguaggio naturale per de-scrivere i desiderata, sino al ricorso a dettagliate specifiche formali per strutturare i medesimi. Difatto, testare senza tener conto di una rappresentazione, di qualsiasi natura essa sia, è un sempliceesercizio di stile, il cui risultato non può in alcun modo essere validato: come si può decidere seun test è stato passato o meno, laddove non si abbia una sufficiente coscienza dei risultati attesi?

Parlando di Rappresentazione, possiamo individuare tre parole chiave che rappresentano altret-tanti fattori d’interesse. Anzitutto il concetto di Requirements, in cui si fa riferimento a quelle chepotremmo indicare come “capacità narrative” del linguaggio utilizzato, cioè a tutte quelle pecu-liarità del linguaggio che consentono di caratterizzare i requisiti in modo usabile, quantificabile enon ambiguo. Vigono le seguenti keyword, espressione delle problematiche inerenti l’ambito didiscussione.

• Objective: i requisiti sono descritti o modellati in modo tale da non scadere in situazioni diambiguità.

• Feasible: i requisiti dovrebbero essere fattibili, nel senso che dovrebbe esistere una tradu-zione implementativa abbastanza diretta che faccia riferimento a tecnologie possedute opossedibili.

• Quantifiable: si dovrebbe cercare di quantificare quante più misure possibile, facendo rife-rimento ad esempio a valori, medie, etc.

• IEEE 830: lo standard 830 specifica gli aspetti “desiderabili” connessi alla specifica direquisiti software.

Particolare attenzione deve esser posta anche sulla Traceability. Con tale termine indichiamo lacaratteristica del sistema di possedere una buona tracciabilità, cioè, in ultima analisi, la possi-bilità di effettuare una facile associazione tra feature offerte e sotto-sistemi delegati a risolverle.Quando andiamo ad effettuare un’operazione di testing, siamo infatti interessati a poter individua-re facilmente il componente software che implementa una data specifica o, dato un componentesoftware, nel rilevare quale specifica esso realizzi. Mancando queste informazioni diventa im-praticabile effettuare testing, non potendo pianificare le dovute operazioni in modo completo eaccurato nemmeno per sistemi di dimensioni relativamente piccole.

Merita uno spazio a parte il concetto di Separation Of Concerns (SOC). Con questo terminesi è soliti indicare la proprietà di un sistema di possedere componenti che risultino quanto piùpossibile indipendenti l’uno dall’altro. Apparirà evidente come tale accezione sia direttamentecorrelata con i concetti di controllabilità e osservabilità: tanto più un componente è indipendentedagli altri, tanto più risulterà maneggevole e leggibile.


Implementazione

Le modalità di sviluppo e di realizzazione dell’implementazione rappresentano ovviamente unfattore essenziale per la qualità e per la testabilità del sistema. Gli aspetti di cui tener conto sonoovviamente numerosi e spaziano da caratteri più generici (quale, ad esempio, la gestione dell’in-terfaccia), ad altri più prettamente tecnici come il ricorso alle eccezioni. Molto interessante inquesto contesto risulta ad esempio l’articolo di Binder [52], in cui viene evidenziato come spe-cifiche peculiarità della programmazione (in quel caso a oggetti) permettano di migliorare o, alcontrario, inducano un peggioramento in rapporto alla testabilità. In queste pagine tralasceremotali considerazioni, preferendo concentrarci sull’aspetto dell’ambito implementativo più interes-sante nell’ottica dell’analisi che stiamo conducendo: il tipo di Struttura che andremo a dare alleclassi del progetto e, in particolare, il partizionamento logico interno al sistema.

Effettuare Partizionamento

Le modalità di suddivisione logica del sistema software che si va a sviluppare rappresentanoun elemento qualitativo importante per decretare la testabilità dell’intero software. Ci sono unamoltitudine di regole e di euristiche per effettuare partizionamento all’interno del sistema [50][47] [51], possiamo comunque individuare due aspetti essenziali: minimizzare le dipendenze trai differenti moduli che si vanno ad implementare e minimizzare il parallelismo all’interno deisingoli moduli.

Il criterio di minima dipendenza tra moduli fa riferimento al fatto che, idealmente, il sistemadovrebbe essere costituito da moduli completamente indipendenti tra loro. Tale obiettivo puòessere raggiunto riducendo al minimo le interazioni e le comunicazioni tra i moduli stessi. Intal modo, al momento del testing, è possibile isolare e studiare un singolo modulo con relativasemplicità.

Anche minimizzare il parallelismo all’interno dei singoli moduli offre il vantaggio di produrremoduli “well-testable”, cioè facili da testare. Il numero di possibili stati cresce infatti esponen-zialmente se il modulo è costituito da elementi che interagiscono in parallelo e, di fatto, il numerodi stati è indicativo del numero di scenari da ipotizzare per il test cioè, in ultima analisi, della suaonerosità.

Da un punto di vista ideale, dovrebbe essere possibile modellare il sistema come un insiemedi processi comunicanti (vedi figura 13). La minimizzazione delle dipendenze permette di tene-re basso il numero di interazioni tra processi, mentre la mancanza di parallelismo consente diimmaginare ogni modulo come un singolo processo sequenziale.

Feature Aggiuntive

Una soluzione che ha assunto un ruolo sempre maggiore parlando di testabilità software è l’im-missione di funzionalità aggiuntive specifiche [49] [47].

Abbiamo osservato in precedenza come un software “well-testable” dovrebbe essere partizio-nato in moduli, rimane da capire come aumentare la testabilità dei singoli moduli. Al di là dellariduzione del parallelismo, la soluzione più performante è rappresentata dall’utilizzo di featureappositamente pensate. In sostanza ogni modulo viene arricchito da metodi che consentano distimolarlo e leggere le risposte offerte.


Figure 2: Partitioned system

under test. Third, in real-time systems the order in which events occur is essential. Therefore during testing the timing of incoming events should be controllable and the timing of outgoing events should be observable, which is very difficult to achieve if the system parts under test cannot be reached directly.

In order to improve testability, test functionality is added in the system specification. The following three kinds of test functionality are proposed. Note that these test functionalities are stated as implementation-independent test requirements in the system specification.

SYSIN d

System Part$

II

1) Transparent Test Mode (TTM) The behaviour of a system part can be extended with a transparent test mode. Whenever a system part is switched into TTM, the system part passes incoming events directly to outgoing events in a predefined way. The paths to and f?om the system part under test c<m be set up and maintained easily by switching the system parts on the paths into ITM.

An example is shown in figure 3. In order to offer a test stimulus on input IN1 of the system part under test, and to observe the responses on output OUTl and OUT2, the system parts A ‘and B are switched into TTM. The behaviour off system part A and part B is modelled as a state machine. In TTM the state machine is brought into the stite TTM. During the test the state machine remains in state TTM, so the sequential behaviour is transformed into combinatorial behaviour. An event on input SYSIN is translated into a test stimulus on input INI , and the responses on OUT1 and OUT2 are translated directly into SYSOUT.

However a one to one translation of incorning flows into outgoing flows is not always possible. If the number of input vectors of a system part is smaller than the number of output vectors, then it is not possible to derive all output vectors from input vectors. In such situations an incoming data flow can be added in order to equal the number of input vectors and output vectors.

2) Built-In-Self-Test (BIST) A system part can be equipped with functionality which performs the self-testing of the system part. This reduces

r- System Part B

O U T l

OUT2

SYSOUT ___)

1 MODE

Figure 3: Transpurent Test Mode ( T T M )

Paper 5.3 137

Authorized licensed use limited to: Universita degli Studi di Firenze. Downloaded on May 19, 2009 at 08:26 from IEEE Xplore. Restrictions apply.

Figura 13: Sistema con partizionamento dei moduli.

Ovviamente un pre-requisito per tale approccio è quello di lavorare con moduli dai “confiniben definiti”, si dovrebbe cioè essere in presenza di moduli logicamente indipendenti e su cuiabbiamo accesso diretto. Per quanto una simile situazione rappresenti la condizione ideale dilavoro e l’ottimo cui tendere nella progettazione di un sistema, nella realtà difficilmente potremopartire da un simile presupposto; molto più spesso saremo costretti a raggiungere l’elementod’interesse passando attraverso altri moduli. Con riferimento alla figura 13, è ipotizzabile pensaredi non avere accesso diretto al modulo C e di dovere, di conseguenza, accedervi tramite D o E. Insostanza, quella che si prefigurava come una buona progettazione, in cui il sistema era giustamentepartizionato in costrutti sufficientemente indipendenti, viene inficiata dalla mancata accessibilitàdiretta a ciascuno di essi.

Una simile limitazione in termini di controllo e leggibilità riduce infatti drasticamente la testa-bility.

• Diventa indispensabile inizializzare e mantenere, per ogni test, un cammino specifico da eper il modulo in esame. Ciò potrebbe peraltro essere impossibile o estremamente dispen-dioso.

• Nel momento in cui un test rileva un errore non è banale scoprire l’origine dell’errore:potendo essersi verificato nel modulo in esame o nei moduli incontrati durante il cammino.

• In sistemi real-time l’ordine e la temporizzazione sono elementi cruciali. Durante il testvorremmo pertanto essere in grado di controllare il timing degli eventi, task complicato senon si ha accesso al singolo modulo.

Per aumentare la testability è necessario pertanto aggiungere opportune feature che arricchiscanoi moduli in esame. Vediamo brevemente le principali soluzioni adottabili.

Transparent Test Mode

Il behaviour di un modulo del sistema può essere esteso immettendo un Transparent Test Mo-de (TTM) [49] [53]. La nuova feature è realizzata in modo tale che ogni qual volta il com-ponente venga portato in configurazione di test (Test Mode), il suo ruolo diventa unicamentequello di restituire in output i dati acquisiti in input senza modifiche, o al limite con modifichepre-impostate.


Impostare un path non invasivo sino al modulo d’interesse diviene allora un’operazione moltopiù semplice: è sufficiente infatti limitarsi a commutare in test mode tutti i moduli presenti nelcammino che non siano il modulo in esame.

Ovviamente l’introduzione di una siffatta feature non è un task elementare, in quanto un modu-lo, essendo di fatto l’implementazione di una certa funzione, tende ad elaborare gli input acquisitie talvolta, anzi spesso, a modificarli anche come cardinalità dei medesimi. Si potrà quindi averela presenza di un modulo che acquisisce in input n dati, per restituirne in output m < n. In questicasi, non potendo semplicemente tradurre i dati in output, si può pensare di arricchire il modulocon un elemento di input aggiuntivo cui passare dati, specificamente formattati, quando il modulosi trova in modalità test mode.

Point Of Control And Observation

La soluzione maggiormente utilizzata in questo ambito è rappresentata dai “point of control andobservation” (PCO) [49] [47]. L’idea è quella di aggiungere, tra le zone di valenza dei singolimoduli, dei punti di controllo che migliorino la leggibilità del sistema. In sostanza si cerca dilavorare sulle interconnessioni tra le varie parti del sistema, manipolandole in modo da poterlecontrollare, o anche solo osservare, durante il test.

PCO System System System Input Part A Part B Part A

Mode Observation Control output Input

Figure 4: Inserting U Point of Control and Observation (PCO)

the required controllability and observability from the system environment. The BIST functionality in the system part is started and controlled from the system environment. The BIST functionality in the system part trikes care of offering test stimuli to the system part, and observing and evaluating the responses. When the test is completed, a go/no-go response or diagnostic inforination is returned to the system environment.

3) Point of Control and Observation (PCO) At the boundaries of the system parts, points of control and observation can be inserted, so the interconnections between the system parts can be controlled and observed directly from the system environment. A PCO can be inserted in a flow between two system parts, as shown in figure 4. In figure 5 is indicated that a PCO has three operation modes, which is selected by the flow Mode:

Transparent mode This mode is used during normal system operation, and no observation or control is performed. The PCO input is passed directly to the PCO output. The control input and the observation output are of no concern. Observation mode This inode can be used to monitor the system during norrnzd operation. The PCO input is passed to both the PCO output and the observation output. The control input is of no concern. Test mode This inode is used to test a system part in isolation from its environment The PCO input is passed eo the observation output. The control input is passed

In this mode the PCO is used to observe the sending system piut, and to control the receiving system part. Both control and observation actions cm be performed independently, so both system parts can be tested simultaneously.

to the PCO output.

In general the information in &ita stores cannot be reached directly. Therefore &o the stores can be equipped with ;t PCO. In observation mode the PCO can be used to monitor the contents of the store. In test mode the PCQ can be used to sead/write the ctore.

The 7TM and PCO functiondity offer paths from the

system environment to embedded system parts. Besides test information, the paths through the system can also be used to transport management information.

4. Implementation of test functionality During hardware/software integration, production and field operation the testability of the implementation is considerably improved if test functionality like TTM, BIST, and PCOs is available. Therefore it is required that the implementaion-independent test functionality, which has been introduced in the system specification, is actually implemented in hardware and software. The actual hardware/software implementation of a system can be quite different from the partitioned system stated in the system specification, because the boundaries between the h:udwxe/

PCO PCO Input output *

Mode

Transparent Mode

Input output -Yap:* ._.. .................... -- -

Mode Observation output

Observation Mode

Input output

Mode Observation Control Output Input

Test Mode

Figure 5: PCO operution modes

Paper 5.3 138


Figura 14: Schematizzazione di un PCO.

In figura 14 è mostrato uno schema riassuntivo che esemplifica la collocazione e gli input/outputdi un PCO. Il costrutto acquisisce in entrata un PCO-input e restituisce un PCO-output, che altronon sono se non il normale flusso di dati che intercorrerebbe tra le due parti del sistema. Esistonofondamentalmente tre modalità operative, selezionabili tramite un comando di Mode. Il PCO puòchiaramente restituire un output al tester o acquisire uno specifico input.

1. Transparent Mode: è una modalità che può ricordare il TTM descritto in precedenza, inrealtà questa situazione identifica un PCO dormiente che non altera il normale scambio diinformazioni tra i moduli.

2. Observation Mode: in questo caso il PCO è utilizzato per monitorare un modulo. In so-stanza, ponendo il PCO in correlazione con l’output di un certo modulo, lo si può isolare eleggere il suo specifico output (vedi figura 15).

3. Test Mode: è la modalità più invasiva. In questo caso, si veda la figura 16, viene estrattol’output del modulo precedente e viene immesso un nuovo input al modulo successivo.

Built-In-Test

Si inseriscono nell’ottica di un incremento delle feature sistemiche anche i Built-In-Test (BIT).L’idea è quella di arricchire ogni classe di un’interfaccia che consenta di stressare uno specifico









to the PCO output.






Mode

Transparent Mode

Input output -Yap:* ._.. .................... -- -


Observation Mode

Input output


Test Mode


Paper 5.3 138


Figura 15: Funzionalità di Observation Mode.








to the PCO output.






Mode

Transparent Mode

Input output -Yap:* ._.. .................... -- -


Observation Mode

Input output


Test Mode


Paper 5.3 138


Figura 16: Funzionalità di Test Mode.

modulo ed ottenere un responso di corretto funzionamento del medesimo. Ovviamente, possedereuna simile interfaccia riduce al minimo il costo di sviluppo di una sovra-architettura di testing. Iconcetti chiave legati all’ambito dei BIT [54] sono fondamentalmente tre.

1. Set/Reset: l’immissione di operazioni di set/reset per portare il sistema ad uno stato prefis-sato. É infatti questa la condizione necessaria tipica per quasi ogni metodologia di testing(ovviamente legata al concetto di controllability).

2. Reporting: in questo caso l’obiettivo è unicamente quello di riportare lo stato attuale delsistema (si aumenta la observability). Il problema principale di questi operatori è legato allacredibilità di cui devono godere. Proprio come conseguenza del loro ruolo sorge la necessitàdi poter riporre una fiducia assoluta in tali sistemi, il cui malfunzionamento potrebbe indurrecostose operazioni di testing o addirittura re-ingegnerizzazione. Solitamente, pertanto, talistrumenti sono controllati addirittura a livello di correttezza formale o, almeno, testati contecniche di debugging a basso livello.

3. Safety: una feature potente, da un punto di vista dei privilegi di controllo posseduti, comeun BIT deve necessariamente prevedere tecniche che cerchino di evitare, per quanto possi-bile, un utilizzo indesiderato, maligno o incidentale. Alcune soluzioni prevedono anche lapossibilità di provvedere due copie del medesimo modulo, una con feature di BIT aggiunti-ve, una senza. Possedere una versione basica, e per questo più probabilmente corretta, delmodulo offre vantaggi ovvi, d’altra parte è questo un approccio assolutamente dispendioso.

La letteratura inerente i BIT evidenzia un numero assolutamente ragguardevole di soluzioni ap-prontabili, ognuna focalizzata sull’ottimizzazione di certi aspetti e sulla risoluzione di determi-nate problematiche. La disamina di tali aspetti preclude dalla trattazione attuale, interessava pe-rò sottolineare come i BIT rappresentino soluzioni del tutto specifiche per il singolo modulo ecostituiscano comunque la soluzione più dispendiosa nell’ambito delle feature aggiuntive.

4.2 I N D I V I D UA R E L’ E M E R G E N Z A I N A M B I E N T I G O R E 81

Test Suite

Un Test Suite è un insieme di test case e di istruzioni (e planning) di utilizzo dei medesimi. I possi-bili approcci alla realizzazione, e utilizzo, di test case sono molteplici. Una lista sufficientementeampia è presente ad esempio nello standard IEEE/ANSI 829, dove si definiscono le modalità perspecificare il design utilizzato, per specificare i test case, le procedure di test, etc.

Il tema, come si può intuire, è topico nell’ambito della letteratura inerente il testing: molteplicisono in tal senso le discussioni relative alla documentazione, alla riusabilità, alla verifica, cosìcome allo sviluppo o scelta del miglior oracolo di riferimento. Tale disamina esula però dalleproblematiche d’interesse e viene pertanto demandata alla letteratura di riferimento.

Test Tools

Effettuare testing richiede automazione, elemento imprescindibile senza il quale diminuirebbela quantità di test effettuati e aumenterebbe il costo dei medesimi. Gli elementi componenti untool sono molteplici; si va dal manager di configurazione, al manager per la test suite, al tracerrun-time, sino a comparatori, strumenti di reporting, etc. Una loro approfondita disamina esulacomunque la trattazione attuale.

4.2 I N D I V I D UA R E L’ E M E R G E N Z A I N A M B I E N T I G O R E

Terminata la pur breve panoramica relativa al concetto di testabilità in ambito software, lo scopodiviene adesso quello di capire se le nozioni apprese possano aiutarci nello sviluppo di in unatecnica di testing orientata alle peculiarità di un’analisi emergente.

Mostreremo in particolare come il ricorso ad un approccio GORE assuma un interesse assolutoin relazione alle considerazioni fatte nelle pagine precedenti. Nel far ciò giustificheremo la secon-da ragione essenziale (oltre al suo utilizzo nella disamina dell’ignoranza di un sistema) per cuiabbiamo scelto il framework di Lamsweerde. KAOS, e in particolare, ancora una volta, il goal-tree da esso sviluppato, si prefigura infatti come lo strumento ideale per maneggiare il testing disistemi emergenti.

Testabilità Dei Requisiti

Parlando di testabilità in rapporto ai requirement di un progetto, tornano naturalmente alla mentele considerazioni offerte in precedenza a proposito della rappresentazione di un sistema. L’alberodei requisiti sviluppato da KAOS, così come il tipo di formalismo utilizzato per i goal, soddisfapienamente le direttive date, in particolar modo (come abbiamo visto nel capitolo 2) per quantoriguarda la completezza e la mancanza di ambiguità. Indipendentemente dall’implementazioneche andremo ad adottare, questo primo momento di sviluppo del design risulta pertanto coerentecon le teoria offerta. Resta da capire, sempre rimanendo nell’ambito dei requisiti, come sviluppareun processo di testing che riesca a sfruttare altre peculiarità della testability.

Nel proseguo della trattazione descriveremo nel dettaglio la tecnica da noi proposta. Interes-sa per adesso soffermarci sui due caratteri principali della tecnica ereditati dallo studio dellatestability:

• partizionamento;


• pseudo punti di controllo.

Parlando di “partizionamento” facciamo riferimento alla scissione logica implicitamente indottadall’analisi dei requisiti di KAOS. Di fatto parlare di “singolo requisito” o di “requisito unione disotto-requisiti” significa leggere il sistema come un oggetto composto da elementi assestanti, capa-ci di operare individualmente. Un requisito foglia richiama infatti in causa un singolo elemento (e,anzi, una specifica feature di un elemento), permettendo di pensare un eventuale controllo, cioè untest, in modo più semplice, tralasciando ad esempio le eventuali problematiche di interrelazione.Il sistema viene, in sostanza, partizionato nelle singole funzioni realizzate da un componente.

Il riferimento agli “pseudo punti di controllo” vuole invece porre l’attenzione sul legame concet-tuale presente tra un modulo (software) e un requisito. Così come ci prefiguravamo di possederesufficienti permessi per poter controllare e leggere appieno un singolo modulo, allo stesso mododobbiamo cercare di pensare il singolo requisito. Tradotto in pratica, ciò significa che non dovre-mo immaginare l’albero dei requirement di KAOS come una coda in cui andiamo ad immettereinformazioni sui nodi foglia e otteniamo un output dal nodo radice; al contrario, dovremo vederetale costrutto come un insieme di moduli distinti e proprio sui singoli moduli andremo a con-centrare la nostra attenzione. Così come avviene nella tecnica PCO, potremo operare sui singoligoal partendo dal presupposto di potervi immettere informazioni (controllo) e poterne leggere lerisultanze (leggibilità). É questo un punto di vista che consentirà di focalizzare l’attenzione suspecifiche parti del sistema e di poter minimizzare la complessità del testing, potendo ridurre alminimo il numero di componenti coinvolti in una singola analisi.

Il paragrafo attuale si inserisce in questo contesto e mostrerà come un RE sviluppato tramiteun approccio GORE possa guidare lo sviluppo di una tecnica di testing che risponda alle esigenzeappena descritte. Descriveremo anzitutto i vantaggi legati all’adozione di uno sviluppo tramitegoal, per poi evidenziare come la complessità del problema in esame sia riducibile focalizzandosisolo su certe aree del sistema.

4.2.1 Ridurre La Complessità Con Un Approccio A Livelli

Studiare l’emergenza di un sistema prevede idealmente il susseguirsi di una serie di operazioni:

1. testing del sistema già costruito;

2. rilevamento di un fenomeno emergente;

3. studio del fenomeno per individuare i punti deboli del progetto.

Approcciando il problema in questo modo si commettono almeno due errori concettuali macro-scopici.

• Anzitutto, come abbiamo osservato in precedenza, si sottintende l’ineluttabilità di possedereil sistema già ultimato (o comunque una sua versione sufficientemente realistica).

• Il secondo errore risiede nel tentativo di coniugare gradi di lettura del sistema che in realtàsono troppo distanti. Si ricerca in pratica di trovare una soluzione particolare, cioè conside-rando una granularità di lettura molto fine, per un problema che si manifesta a livello globa-le, dove il sistema è visto, più o meno, come un blocco unico. Le difficoltà che incontranomolte tecniche di analisi dei risultati del testing, così come di progettazione del medesimo,


sono correlate proprio a questa distanza. Un fenomeno emergente che si manifesta a livellodi sistema si è evoluto a tal punto, in termini di correlazioni con altri componenti, da ren-dere eccessivamente nascosta la sorgente dell’errore: se il gap tra la rappresentazione di uncomponente e quella del sistema è troppo ampio, si rischia di non essere più in grado dicorrelare la causa all’effetto. Una tecnica di testing efficace dovrebbe pertanto cercare diintercettare l’errore prima che si manifesti come ostacolo al main goal.

Sorge allora l’esigenza di rileggere il sistema a livelli e sorge contemporaneamente la domanda:che tipo di struttura intermedia deve essere posta tra i costituenti elementari e il comportamentoglobale del sistema?

In [55] si ipotizza l’adozione di una “gerarchia dell’emergenza”. Si suggerisce in pratica cheun sistema (emergente) possa essere visto come il risultato di oggetti che possono a loro volta es-sere sistemi emergenti. La gerarchia, diminuendo la distanza tra costituenti e globalità, induce unordine nel sistema che consente di rappresentarlo più efficacemente. Inoltre la presenza di un mag-gior numero di livelli di lettura aiuta ad individuare più facilmente, e soprattutto anticipatamente,l’insorgere di condizioni indesiderate. Con una siffatta metodologia rappresentativa si potrebbeinfatti pensare di inserire dei checker che verifichino l’assenza di emergenza tra un livello e l’altro[56].

La soluzione proposta in [55], una volta formalizzata l’organizzazione a livelli, fa ricorso ad uncontrollore centrale che, possedendo informazioni su tutto il sistema e sui requisiti che ogni sotto-sistema deve soddisfare, è in grado di rilevare per tempo l’emergenza. Tale soluzione non verràpresa in considerazione proprio per la presenza di un siffatto checker che pare una limitazionetroppo rigida sul tipo di modello utilizzabile. La nostra proposta manterrà invece l’approccio alivelli, rileggendolo nel più ampio contesto dell’ingegnerizzazione tramite goal.

L’Importanza Dei Requisiti Locali

Le problematiche di livello appena descritte trovano una risultanza pratica nel tipo di studio con-dotto tramite KAOS. L’ingegnerizzazione effettuata da tale framework considera infatti comemomento di analisi iniziale la specializzazione di uno o più goal che, all’interno del sistemache andremo a creare, dovranno risultare globalmente validi. Tipicamente le tecniche di testingutilizzabili per esaminare il sistema andranno quindi a verificare l’effettiva soddisfazione di talirequisiti, ricadendo in questo modo nei limiti concettuali espressi in precedenza.

Osservando il tipo di raffinamento effettuato da KAOS si osserva la presenza di un numerocrescente di goal, e quindi requisiti, sempre più specializzati, referenti cioè ad un numero sem-pre minore di componenti e feature dei medesimi: si ricerca cioè la definizione di requisiti chepossiamo intendere come locali. Il vantaggio di tali requisiti in rapporto a fenomeni emergentiè chiaramente connesso alla loro maggiore leggibilità e trattabilità. Un requisito locale è intrin-secamente più semplice, sia perché riferisce meno agenti, sia perché strutturalmente richiede larealizzazione di un numero minore di funzioni. Laddove si evincano condizioni inattese saràallora molto più facile:

• correlarle al malfunzionamento di un numero molto limitato di componenti;

• proporre, eventualmente, soluzioni correttive.

Lo sviluppo di una tecnica di testing esplicitamente pensata per l’individuazione di fenomeniemergenti dovrebbe dunque partire proprio da un’analisi dei requisiti locali. Individuare anomalie


già a questo livello è infatti condizione indispensabile per evitare che la complessità delle tecnichedi risoluzione esploda, rendendo improba la mole di lavoro necessaria per correggere il sistema.

4.2.2 Combattere L’Emergenza Con Un Testing Mirato

Abbiamo visto come l’albero dei requisiti sviluppato da KAOS sia il riferimento primario perl’individuazione dei requisiti locali, in quanto offre una mappa completa in cui sono presenti lespecializzazioni dei requisiti a qualsivoglia livello di lettura. D’altra parte tale struttura ci offreun’altra importante informazione: le correlazioni presenti tra i differenti requisiti.

La conoscenza della “geografia dei requisiti” è un punto nodale per la risoluzione del proble-ma, in quanto ci consente di correlare tra loro requisiti posti a differenti livelli di lettura. Negliapprocci canonici al testing una limitazione fondamentale è infatti rappresentata dalla incapacitàdi poter leggere esaurientemente il corretto funzionamento di una parte del sistema come prodottodel corretto funzionamento di sue sottoparti, deficienza derivante dalla mancanza di una mappaconcettutale come quella sovracitata.

Un utilizzo consapevole dell’albero dei requisiti di KAOS permette invece di isolare una sotto-parte del sistema in esame, consentendoci di avere quindi una formula che correli un parent-goala differenti sub-goal e, di conseguenza, di poter stabilire la soddisfacibilità di un requisito infunzione della soddisfazione di requisiti a livello inferiore (magari a livelli differenti). In tal modoci siamo posti nell’ottica di poter effettuare un testing mirato che analizzi e verifichi uno specificosotto-sistema:

• in modo pressoché immediato, perché la mappatura data garantisce un’ottima leggibilità;

• senza l’obbligo di dover sottostare al medesimo livello di lettura, ma potendo, ad esempio,considerare nodi foglia di certi sotto-sistemi e agglomerati (parent-goal), di altri.

Peraltro effettuando una disamina di questo tipo diviene possibile re-introdurre (e, soprattutto,maneggiare con facilità) anche nella fase di testing il concetto di modalità di integrazione giàvisto a proposito dell’analisi dell’ignoranza. Non si suggerisce di improntare uno studio specularea quello visto nel capitolo 3, ma certamente alcune informazioni su tali ambiti sono possedutee potranno “indirizzare” un eventuale addetto alla fase di test. É realistico pensare infatti che,una volta rilevato un fenomeno emergente, l’analista tenderà a sviluppare i sub-goal correlati aintegrazioni a rischio, mentre tenderà a mantenere i parent-goal laddove si abbia più confidenza.

La tecnica proposta può essere riassunta nelle seguenti fasi sequenziali.

1. Individuazione dei requisiti d’interesse:

a) selezione di un requisito da verificare, ad un certo livello (parent goal);

b) conseguente individuazione dei sotto-requisiti che lo compongono (sub-goal).

2. Controllo del corretto funzionamento del sotto-sistema:

a) testing sui sotto-requisiti;

b) verifica del perfetto checking tra comportamento del sotto-sistema e requisito padre.

In questo modo è possibile approntare una politica di testing che si focalizzi su specifiche parti delsistema, andando a verificare la corretta integrazione dei sub-goal. É infatti proprio nella fase diintegrazione che si sperimentano condizioni emergenti, conseguenza questa di interazioni inattese(cioè di un’ignoranza di base su alcune feature offerte).


Esempio

Proponiamo adesso un piccolo esempio utile a fissare, anche visivamente, i concetti espressi inprecedenza. In particolare abbiamo deciso di utilizzare un requisito presente in uno dei casi distudio finali di [38]. Il requisito in questione è “DistBetweenTrains” e appartiene al caso di studiorelativo allo sviluppo di una “Advanced Automatic Train Control” all’interno della “San Franci-sco Bay Area Rapid Transit” (BART). Non interessa dilungarsi più di tanto sugli scopi dell’interoprogetto, è sufficiente sapere che il main task consisteva nello sviluppo di un sistema di gestioneautomatico della linea ferroviaria capace di gestire un numero maggiore di passeggeri. In parti-colare il requisito in esame richiede che la distanza tra due treni non possa (eccezion fatta per lasosta nelle stazioni) mai essere inferiore ad una distanza considerata di sicurezza.

Applicando i pattern tipici di KAOS il requisito può essere raffinato nei differenti apporti, siimmagina pertanto di essere in possesso dell’intero goal-tree relativo al main-goal in esame. Ov-viamente tale apporto informativo dovrebbe derivare da un’analisi compiuta in fase di RE, il cuiprodotto viene passato agli sviluppatori dei test.

Osserviamo come tali informazioni possono essere utilizzate per accompagnare questa fase. Sisuppone in sostanza di aver rilevato, in fase di testing, una situazione anomala in cui due trenisi sono trovati ad una distanza inferiore a quella di sicurezza. Chiaramente l’esempio (forse nonmolto realistico) deve essere inteso come prettamente didattico.

Analizzando il goal-tree proposto in figura 17 (dato lo spazio a nostra disposizione, il goal-treeè solo parziale) la prima informazione che è possibile cogliere riguarda i sub-goal di primo livello.

• “NoTrainEnteringTrackInFrontOfCloseTrain”: nessun treno entra nei medesimi binari, pre-cedendo il treno in esame, ad una distanza minore di quella di sicurezza.

• “NoTrainEnteringTrackBehindCloseTrain”: nessun treno entra nei medesimi binari, dietroal treno in esame, ad una distanza minore di quella di sicurezza.

• “DistBetweenTrainsOnSameTrack”: la distanza tra due treni nei medesimi binari non scen-de sotto quella di sicurezza

Abbiamo cioè ottenuto una mappatura che ci informa del fatto che, stante l’infrazione del main-goal, devono essere stati infranti uno dei tre goal sovra citati. Occorre a questo punto sottolineareun aspetto. É evidente che le medesime informazioni sarebbero state ricavate da una sempli-ce lettura della composizione del sistema, ma operando in questo modo si hanno almeno duevantaggi:

1. anzitutto le informazioni sono già disponibili e non richiedono alcun tipo di analisi;

2. in secondo luogo sono già strutturate in livelli. Il rischio infatti è che, trovandosi di fron-te all’interezza del sistema, si possano trattare contemporaneamente informazioni che, alcontrario, riferiscono profondità differenti di lettura (col conseguente rischio di introdurreerrori nel testing).

I goal estrapolati dal primo raffinamento hanno una natura fortemente differente. Si immaginaad esempio che l’accesso ai binari sia una feature “coperta”; perché già sottoposta ad altri test, operché ereditata dal sistema precedente, etc. In un caso del genere l’analista potrebbe decidere dinon sviluppare ulteriormente i primi due goal, concentrandosi invece sul terzo (da qui la mancatacontinuazione del raffinamento in figura 17).


Figura 17: Goal-Tree (parziale) relativo al requisito “DistBetweenTrains”.

Proseguendo nella lettura dell’albero il requisito “DistBetweenTrainsOnSameTrack” viene ulte-riormente sviluppato.

1. “BackwardTrain”: in cui si richiede che nessun treno possa cambiare senso di marcia.

2. “SafeAccCmdOfFollowingTrain”: in cui si richiede, stante la proprietà precedente, che siail treno che segue ad occuparsi di mantenere la distanza di sicurezza.

Anche in questo caso è sensato ritenere che, data la semplicità implementativa del primo requisito,l’errore possa trovarsi nel secondo. Volendo verificare la correttezza dei ragionamenti sin quicondotti si potrebbe testare proprio tale requisito verificando, con tutta probabilità, una infrazione.

Tramite una semplice lettura dell’albero e con poche informazioni aggiuntive, siamo dunquestati in grado di rileggere il requisito radice in un requisito (“SafeAccCmdOfFollowingTrain”)molto più specializzato e, pertanto, molto più semplice da analizzare. É evidente pertanto comeil ricorso all’albero costruito da KAOS possa prefigurarsi come un aiuto sostanziale alla fase ditesting. Né d’altra parte tale orientamento era stato indicato nei documenti dei suoi sviluppatori, iquali focalizzavano tutta l’attenzione sulla fase di RE.

Proseguiamo speditamente nell’analisi concentrandoci sul requisito “SafeAccCmdOfFollowing-TrainBasedOnSpeed/LocationEstimates”, in cui si richiede, date informazioni corrette sulla po-sizione e sulla velocità (che immaginiamo già verificate), che il “Train Control System” elaboriun’accelerazione coerente con i dati posseduti e modifichi di conseguenza la velocità del treno.Mentre prima abbiamo sfruttato l’albero ricorrendo a livelli di lettura differenti, in questo caso


potremmo decidere, al contrario, di verificare la “famiglia” data, confrontando il parent-goal coni due sub-goal figli:

1. “CmdMsgTransmittedInTime”: in cui si comanda che il messaggio di variazione dell’acce-lerazione sia elaborato, correttamente, in tempo.

2. “ReceivedCmdMsgExercised”: in cui si richiede che il messaggio sia ricevuto e applicatocorrettamente.

In questo caso si potrebbero verificare due situazioni.

1. Uno dei due sub-goal non passa il test. In questo caso si continuerebbe l’analisi sul medesi-mo solco visto sin qui, seguendo l’approccio canonico al testing.

2. Entrambi i sub-goal passano il test, evidenziando dunque un problema di integrazione.

La seconda evenienza mostra l’altro grande pregio di quest’orientamento al testing, oltre alla dut-tilità (evidenziata maneggiando i livelli di lettura): la capacità cioè di evidenziare gli errori diintegrazione e di correlazione tra componenti in modo sufficientemente semplice. In una meto-dologia classica di testing, che non faccia cioè ricorso ad una struttura equivalente al goal-treedi KAOS, si sarebbe probabilmente arrivati a condurre test sulle singole feature (cioè sui goalfoglia), per poi, verificata la correttezza di tali feature, ricostruire il funzionamento del sistema e,infine, trovare l’errore di integrazione. Il fatto è che, se immaginiamo fenomeni emergenti, effet-tuare test sui singoli componenti o sulle feature espresse risulta praticamente inutile: ogni sistemaemergente ha infatti i nodi foglia soddisfatti (anche perché si immagina che i componenti venganotestati prima di essere immessi nell’interezza del sistema). Ciò che interessa è invece la capacitàdi manipolare in modo semplice e immediato le differenti integrazioni interne al sistema, perchéè proprio in tali aree che si sviluppa l’emergenza.

4.2.3 Vantaggi Dell’Approccio Proposto

L’idea di base è dunque assolutamente banale, ma si conforma come un aiuto essenziale al testingche muta radicalmente la tipica prospettiva di analisi. Il testing solitamente opera infatti a livellodi componenti, siano essi hardware o software, e dalla loro “geografia” (supposta, derivata oposseduta) cerca di identificare un input d’interesse per uno specifico sottosistema e un outputrelativo. Il problema è che così facendo l’attenzione del tester si sposta dal “sistema supposto” aquello reale, inficiando una vera e approfondita analisi dei requisiti. La tendenza è in sostanzaquella di focalizzarsi troppo su taluni requisiti funzionali essenziali, di cui abbiamo coscienza perinterazione diretta, rischiando di trascurare aspetti secondari, la cui presenza non è evidenziabilesenza una documentazione precisa, che, soprattutto laddove si esplichino caratteri emergenti, puòrappresentare una deficienza importante del progetto.

La metodologia si innesta perfettamente nei ragionamenti offerti nei capitoli precedenti, prefi-gurandosi come uno strumento ideale da utilizzare in comunione con la disamina dell’emergenzatrattata nel capitolo 3. Parlando di agglomerazione dell’ignoranza avevamo infatti offerto alcuneregole basiche per seguirne l’evoluzione e individuare punti critici nell’albero dei requisiti. Lad-dove si sperimentino, tramite testing (ma anche tramite un utilizzo tipico del sistema), comporta-menti emergenti appare inevitabile identificare in tali criticità la genesi del malfunzionamento edè pertanto in tali zone che andremo a concentrare la nostra analisi, testando i requisiti ivi presenti.


Diventa essenziale quindi avere una metodologia di testing come quella descritta, che consente difocalizzare l’attenzione su specifiche aree del progetto.

L’approccio, peraltro, rimane valido sia in ottica Top-Down, che Bottom-Up. Una metodologiadi utilizzo potrebbe infatti riguardare la volontà di garantire il soddisfacimento di uno specificorequisito. In tal caso è sufficiente individuare i suoi sub-goal e testare, in relazione alle funziona-lità offerte dal parent goal d’interesse, il reale funzionamento del sotto-sistema. Così facendo èanche possibile pensare di approntare il testing su sistemi parziali o, al limite, avere una metodo-logia di controllo efficace per verificare i moduli di un sistema non appena essi vengono ultimati,senza pertanto aspettare il completamento del sistema. D’altra parte si può pensare di effettuareun’analisi Bottom-Up, la quale, considerando alcuni goal foglia, verifichi passo passo il relativosotto-albero dei requisiti in modo da scongiurare che si manifestano comportamenti inattesi, cioèfenomeni emergenti.

Il limite principale del metodo è certamente costituito dalla necessità di possedere un sistemache sia testabile da un punto di vista fisico/implementativo. Il presupposto da cui siamo partiti èinfatti quello di poter controllare i singoli goal, il che, tradotto, implica due tipi di privilegi:

1. possibilità di avere accesso agli agenti responsabili del goal;

2. capacità di poter utilizzare all’interno di un agente una data feature.

Quella descritta in queste pagine deve pertanto essere pensata come una sovra-architettura dainnestare su di una metodologia di testing tipica, approntata su di un sistema quanto più possibilerispondente alle direttive dalla DFT.


Il presente capitolo si prefigura come la prosecuzione naturale del cammino tracciato nel capitoloprecedente. Terminata la contestualizzazione del concetto di emergenza si è infatti palesata tutta lasua natura dicotomica. Da una parte sussiste infatti la volontà di poter almeno in parte preventivareun fenomeno emergente, approntando ad esempio uno studio in linea con le direttive da noi offerte.D’altra parte abbiamo sottolineato più volte come l’evidenza di un siffatto fenomeno si palesi soloa livello di testing e sia dunque possibile esaminarla compiutamente solo a questo livello. Avendogià dettagliato l’analisi dell’ignoranza, che risolve la prima questione, rimaneva aperto questosecondo aspetto.

Nell’approcciare il problema è parso naturale anzitutto approfondire compiutamente le nozionilimitrofe alla fase di testing e, in particolare, la testabilità di sistemi. La ricca letteratura delsettore ha permesso di “toccare con mano” le differenti connotazioni che tale concetto assumenei vari ambiti d’uso, consentendoci di estrapolare i connotati base del medesimo e le soluzionipiù interessanti in relazione al concetto di emergenza. Nel capitolo, onde evitare una inutiledissertazione sui variegati aspetti della testabilità, abbiamo riportato unicamente questi ultimi,che, d’altra parte, rappresentano una giustificazione aggiuntiva all’adozione di KAOS (oltre aquella rappresentata dal suo utilizzo per la disamina dell’ignoranza).

Le considerazioni offerte nella prima parte del capitolo sono infatti servite per giustificare ilruolo centrale che, a nostro avviso, KAOS può assumere laddove si intenda effettuare testingsu sistemi supposti emergenti o dimostrati tali. Nella seconda parte ci siamo infatti concentratisull’aderenza, corredandola di giustificazioni teoriche e pratiche (vedi l’esempio proposto), del

4.3 C O N S I D E R A Z I O N I C O N C L U S I V E 89

goal-tree sviluppato dal framework di Lamsweerde alle direttive di testabilità viste. Tale orienta-mento, pur potendo apparire banale, non era stato preso in considerazione dagli sviluppatori delframework, i quali avevano approntato una attenta analisi focalizzata però sulla sola fase di RE.

A conclusione del capitolo possediamo dunque gli strumenti necessari per trattare l’emergenzanella sua interezza:

1. sia, in un primo momento, a livello di RE, tramite lo studio dell’ignoranza;

2. sia, in secondo luogo, a livello di testing, tramite il ricorso al goal-tree di KAOS.

Capitolo 5Correggere L’Emergenza

“I computer sono incredibilmente veloci,accurati e stupidi. Gli uomini sonoincredibilmente lenti, inaccurati e intelligenti.L’insieme dei due costituisce una forzaincalcolabile.”

Albert Einstein

Nei paragrafi precedenti abbiamo discusso il concetto di emergenza mostrandone la genesi, lasua applicabilità all’ambito GORE e proponendo alcune tecniche di testing (e non) adottabili perindividuarla, la trattazione non poteva quindi esimersi dall’affrontare gli approcci che possonoessere approntati per contrastare ed eliminare tali fenomeni indesiderati.

In sezione 2.3.3 abbiamo brevemente presentato le tecniche di risoluzione degli ostacoli, mo-strando come sia possibile, principalmente tramite trasformazioni sul raffinamento effettuato, ini-bire certe condizioni avverse. D’altra parte, il profondo legame presente tra emergenza e ObstacleAnalysis, sottolineato anche in sezione 3.3.1, ci suggerisce l’idea che le medesime tecniche po-trebbero essere utilizzate per correggere contingenze emergenti. Nella prima parte del capitolo,analizzeremo pertanto la validità, da un punto di vista formale ed ambientale (cioè in relazione alcontesto d’uso), di questa ipotesi, indagando la possibilità di individuare tecniche che impedisca-no a priori l’accadimento di situazioni emergenti, o che, perlomeno, consentano di assiomatizzareazioni correttive che, modificando il sistema, permettano di superare l’impasse emergente.

Anche in questo caso sfrutteremo diffusamente il framework KAOS, ritenendo le sue strutturestrumento irrinunciabile per organizzare, ed eventualmente rielaborare, le conoscenze possedute.

5.0.1 Obstacle Resolution e Correzione Dell’Emergenza: Una Differenza Sostanzia-le

La breve premessa fatta, ma in realtà anche il proseguo della trattazione, potrebbe indurre a pensa-re che la differenza tra la Obstacle Resolution e le tecniche approntate per la correzione dell’emer-genza non sia così marcata. Vi è, al contrario, una differenza sostanziale legata ai fini e ai tempiche caratterizzano questa nuova analisi.

91

92 C O R R E G G E R E L’ E M E R G E N Z A

Parlando di Obstacle Resolution facciamo infatti riferimento ad uno studio a priori che, pre-figurandosi ambiti d’uso e relazioni tra gli agenti ipotizzati, cerca di prevedere l’evoluzione delsistema, la sua capacità di rispondere a certi accadimenti indesiderati e si prefigge di correggereeventuali incongruenze tramite la rilettura del raffinamento operato. É pertanto un’analisi chepoggia su due assunzioni chiave:

1. essere in grado di ipotizzare gli eventi inattesi già a livello di RE;

2. poter correggere il sistema in modo significativo, in quanto le modifiche indotte fanno co-munque riferimento ad un progetto che è ancora teorico e la cui correzione non si ripercuotecon costi elevati;

3. considerare come principale prodotto dello studio un nuovo raffinamento, stavolta scevrodagli impedimenti rilevati.

Al contrario la risoluzione dell’emergenza è un momento di analisi parcellizato nel tempo, limitatonell’applicabilità e non certo.

La suddivisione temporale è figlia del carattere imprevedibile dell’emergenza. Parlando dirisoluzione della medesima pensiamo infatti ad una tecnica correttiva che si applica in tre momentidistinti:

1. terminata la RE, laddove siano stati rilevati, tramite la tecnica descritta nel capitolo 3, nodidi agglomerazione dell’ignoranza;

2. durante la fase di testing ove (magari seguendo le considerazioni proposte nel capitolo 4) sisiano rilevati fenomeni emergenti;

3. a sistema ultimato, come conseguenza di errori manifestatisi in fase di run del prodotto.

Le tre eventualità sono caratterizzate da proprietà profondamente differenti. Il primo tipo di rileva-zione induce un approccio abbastanza simile alla OA: uno studio a priori ha rilevato incongruenze,perciò si applicano opportune migliorie per correggerle. Gli ultimi due casi sono, al contrario,espressione di una situazione totalmente diversa, in cui il sistema è già stato sviluppato e, di con-seguenza, i cambiamenti effettuabili nella “mappa” del progetto sono minimi. In effetti, come siosserverà nel proseguo del capitolo, il peso dei cambiamenti richiesti rappresenterà il principalelimite all’applicabilità delle tecniche di risoluzione della OA in questo nuovo contesto.

Quando parleremo, qui e nel proseguo, di fase di “Correzione dell’Emergenza” faremo pertantoriferimento ad un’analisi che non si caratterizza per una dinamica precisa, ma che può, al contrario,venir applicata per scopi differenti:

1. per diminuire l’ignoranza connessa ad un sotto-sistema, calcolata con la nostra metodolo-gia;

2. per risolvere l’emergenza rilevata tramite testing, impedendo la realizzazione della manife-stazione emergente.

Cercheremo pertanto di re-interpretare le tecniche tipiche della OA nella duplice ottica; proprioper questa ragione spesso la disamina di ogni approccio sarà divisa in due parti, con conclusioniche potranno anche differire significativamente per l’una e per l’altra.

5.1 E L I M I N A R E L’ E M E R G E N Z A 93

5.0.2 Rileggere La Obstacle Analysis In Ottica Emergente

Le tecniche che analizzeremo possono essere classificate in tre classi ed è questa la struttura chedaremo al resto del paragrafo. La classificazione è correlata al fatto che l’ostacolo venga:

1. eliminato (sezione 5.1);

2. ridotto (sezione 5.2);

3. tollerato (sezione 5.3).

Il processo di correzione dell’emergenza, così come avveniva in quello degli ostacoli, si espliciteràin differenti forme che altereranno il sistema progettato sino a quel momento. Potremo pertantoavere:

• un albero dei goal modificato;

• un modello agenti aggiornato;

• specifiche dei requisiti alterate.

Differentemente da quanto avviene per la Obstacle Analysis, considereremo solo marginalmenteil dominio d’interesse, non dovendo un fenomeno emergente sottostare a tali restrizioni.

É interessante sottolineare il passaggio logico che talvolta effettueremo, e che comunque sot-tostà all’analisi stessa, tra fenomeno emergente e goal inficiato. La risoluzione di un’evenienzaemergente nasce e si sviluppa infatti proprio sul presupposto di andare ad elaborare il goal chetale accadimento impedisce di realizzare. E’ un punto di vista radicalmente mutato rispetto allesoluzioni tipicamente adottate per superare simili inconvenienti durante la progettazione di un si-stema. In sostanza, in contrasto con quanto suggerirebbe l’istinto, non si lavorerà direttamente sulfenomeno, sui suoi componenti e sulle interazioni caratterizzanti; si cercherà piuttosto di modifi-care, o ampliare, il sistema in modo da rompere le correlazioni che sperimentano emergenza o, allimite, cercare di limitarne la valenza nel tempo. Un simile approccio è fondamentalmente unaresa all’inevitabilità dell’ignoranza con cui lavoriamo.

5.1 E L I M I N A R E L’ E M E R G E N Z A

Il primo caso che prenderemo in considerazione riguarda l’eliminazione dell’eventualità emergen-te. Si ricerca in pratica l’ottenimento di un sistema modificato in modo tale da rendere impossibilela manifestazione del fenomeno emergente.

5.1.1 Selezionare Un Raffinamento Alternativo

L’idea alla base di questo approccio è quella di riuscire a formalizzare un raffinamento alternativoa quello proposto in modo tale che il goal non più soddisfatto non venga esplicitato, rendendoimplicitamente inaccadibile l’evenienza emergente che contrastava con il goal. La scelta di undiverso design per il sistema si evidenzia con differenti scelte progettuali per quanto riguarda gliagenti e le loro relazioni.

Il metodo, tipico nella OA, è difficilmente estendibile all’ambito emergente. Le ragioni di taledifficoltà sono connesse a due limiti essenziali:


1. difficoltà ad offrire una re-ingegnerizzazione equivalente;

2. mancata conoscenza delle cause profonde della risultanza emergente.

Particolarmente importante la seconda causa. Ignorare le cause che inducono emergenza rappre-senta una condizione estremamente limitante; pur essendo vero che il testing rivela un effettoemergente, è altrettanto vero che tale evidenza è limitata agli effetti del fenomeno e non alle suecause. Nel momento in cui si palesa un fenomeno emergente, potremo quindi, al più, proporreuna lista di ipotetici candidati al ruolo di causa scatenante, senza però poter disporre di alcunacontroprova. Ciò significa che la re-ingegnerizzazione che andremo a proporre cercherà di evitarequegli agenti fallaci o quelle interazioni supposte erronee, ma non potremo avere alcun riscontrose non dopo una nuova effettuazione del testing. Valgono poi le precedenti considerazioni suicosti di ri-progettazione in una fase così avanzata del progetto.

La “selezione di un raffinamento alternativo”, appare dunque una tecnica difficilmente estendi-bile alla correzione di manifestazioni emergenti. Al più si può pensare di utilizzarla per diminuirel’ignoranza del sistema. Laddove si siano rilevati nodi d’ignoranza è infatti ipotizzabile pensaredi applicare una formalizzazione alternativa del goal-tree. Ovviamente anche in questo caso larisoluzione non è banale, in quanto l’ignoranza, per sua stessa natura, solitamente non ha confinicosì netti da permettere di qualificare come buona una formalizzazione e come fallace un’altra,magari non troppo dissimile.

5.1.2 Selezionare Un Agente Alternativo

Un altro modo per superare l’impedimento emergente è quello di scegliere un agente differenteper l’assegnamento di un certo goal. Chiaramente, se il fenomeno è conseguenza dell’ignoranzaassociata ad uno specifico agente, selezionarne un altro dovrebbe eliminare a priori l’esplicitarsidell’evenienza. La speranza è che il nuovo agente si correli col resto del sistema secondo modalitàattese e non sviluppi anch’esso fenomeni imprevisti. In effetti scegliere un agente differenterappresenta, chiaramente, una delle opzioni principali nell’ottica di una riduzione dell’ignoranzadel sistema. Se l’alto grado di ignoranza dipende dalle mancate conoscenze su un componente,abbiamo, di fatto, due alternative:

1. cercare informazioni sul componente;

2. selezionarne uno equivalente ma su cui abbiamo maggiori informazioni.

Più marcati sono invece i limiti applicativi laddove si cerchi di correggere l’emergenza associata,principalmente per le difficoltà legate al cambiamento di un agente in questa fase del progetto.Peraltro, se il fenomeno emergente è rilevato da un testing, potrebbe non essere neppure possibilecambiare i componenti in uso.

5.1.3 Prevenire L’Emergenza

In questo caso l’eliminazione dell’evenienza emergente avviene a priori, tramite la prevenzionedella medesima. Vengono indicate con il termine Obstacle Prevention l’insieme di tecniche diri-progettazione del sistema che:

1. prevengano il verificarsi dell’ostacolo tramite l’aggiunta di requisiti addizionali;


2. consentano ai requisiti di tollerare l’ostacolo stesso.

In ottica emergente l’unica operazione realmente valida consiste nell’immissione di uno o piùrequisiti addizionali atti a negare la genesi stessa dell’ostacolo.

1. Per quanto riguarda la risoluzione dell’emergenza: un fenomeno emergente sussiste perchési verifica una condizione inattesa. Si potrebbero pertanto inserire nel progetto requisiti piùrestrittivi, in relazione al tipo di manifestazione rilevata, su quei componenti che con mag-giori probabilità hanno originato il fenomeno. D’altra parte, l’inserimento di simili requisitiaddizionali non pare troppo realistico in un momento in cui, probabilmente, i componentisono già stati selezionati.

2. In relazione alla diminuzione dell’ignoranza l’immissione di requisiti aggiuntivi rappresen-ta, come vedremo nel caso di studio del capitolo 6, una tecnica tipica. L’ignoranza in fondoè spesso correlata a una definizione parziale dei requisiti, i quali devono pertanto essereampliati e rivisti.

Esistono inoltre in letteratura alcune tecniche di “approccio” alla progettazione inquadrabili nel-l’ottica di una prevenzione dell’emergenza. Nel seguito ne proponiamo due particolarmenteattinenti con lo studio in atto.

Costanti Meno Restrittive

Un primo, triviale, approccio potrebbe consistere nel semplice allentamento della restrittività dellecostanti presenti nel progetto. L’idea è la seguente: in sistemi emergenti che contengono costanti,rendere meno restrittive queste ultime potrebbe implicitamente indurre una maggiore coperturadel sistema che stiamo sviluppando.

Un esempio tipico è quello dello sviluppo di un’automobile. Ipotizziamo di star trattando ilrequisito che richiede di non avere un’accelerazione eccessiva: una soluzione è rappresentatadal ricorso ad una costante che esprime il massimo valore di accelerazione accettato. D’altraparte è evidente come tale goal sia tipicamente emergente, potrebbero dunque esserci situazioniinattese che inducono la macchina ad accelerare. Questo significa che se abbassiamo il limitedi accelerazione accettato, potremo sopportare minime accelerazioni incidentali senza sforare illimite originario.

AccelerationLimit = NewAccelerationLimit + SafetyEnvelope

Ovviamente l’approccio non va inteso come una vera e propria tecnica di risoluzione dell’emer-genza, piuttosto come una “buona norma progettuale” da tenere in considerazione laddove sivadano a trattare situazioni potenzialmente emergenti.

Indirect Control Path Analysis

In [57] è poi presente un altro approccio alla prevenzione, basato sullo sviluppo di una tecnicadi analisi delle dipendenze indirette tra componenti di un sistema (ICPA -Indirect Control PathAnalysis). L’obiettivo è quello di formalizzare un confronto che consenta di rilevare non solo leinterazioni ovvie esistenti tra i diversi agenti (invio di informazioni, ricezione, trasporto, risolu-zione task, etc.), ma anche tutte quelle ricadute indirette che un certo componente può avere su diun altro non direttamente connesso, ad esempio la modifica di variabili comuni. ICPA è pensato


per essere integrato all’interno di KAOS, in quanto quest’ultimo non prevede tecniche evolute dianalisi dell’integrazione tra componenti (di fatto si considerano solo le interazioni dirette).

Ai nostri occhi ICPA non pare classificabile come tecnica di riduzione dell’emergenza. Con-cordiamo ovviamente sulla necessità di introdurre in KAOS strumenti capaci di analizzare piùapprofonditamente le interazioni tra componenti, un simile momento di analisi sarebbe moltointeressante anche in relazione alla formalizzazione degli ostacoli, ma, seguendo la nostra defini-zione di emergenza, ICPA non risolve situazioni emergenti. Tale strumento offre infatti un aiutoper capire quali siano le ricadute dell’utilizzo di un certo componente sugli altri, ma tale disaminafa riferimento unicamente:

• alle nozioni possedute relativamente ai componenti;

• alle nozioni possedute sulle rispettive interazioni.

E’ evidente dunque che una condizione emergente che, per sua stessa definizione, fa riferimentoall’ignoranza, non possa essere rilevata da ICPA.

5.1.4 Modificare Il Dominio

Nella Obstacle Analysis la strategia consisteva nel modificare il dominio in cui opera il sistemain modo tale da annullare il campo applicativo dell’ostacolo. In pratica si poteva operare su duelivelli.

1. Rendendo inconsistente l’ostacolo: un ostacolo per essere considerato come tale deve sotto-stare alle regole del dominio, cambiandole si può rendere formalmente inaccadibile l’eventoindesiderato.

2. Cambiando la natura dell’ostacolo: un ostacolo è tale perché, date le regole del dominio,contrasta con un goal. Cambiando le regole si può non avere più una situazione di conflitto.

Nel trattamento dell’emergenza però il concetto di dominio assume contorni molto più sfumati:il fatto che un evento emergente non debba rispondere a regole di dominio fondamentalmenteinvalida a monte il ricorso alle due tattiche.

5.1.5 De-Idealizzare I Goal

Si indicano con questo nome quelle soluzioni che risolvono la presenza dell’ostacolo rendendomeno “ideale” il goal inficiato. Rilasciare alcuni requisiti, magari troppo restrittivi, che caratte-rizzano un goal, può ampliare la casistica coperta da quest’ultimo, accettando magari anche lasituazione precedentemente intesa come ostacolo.

Un simile approccio cerca di correggere deficienze progettuali nella definizione o nella tradu-zione dei requisiti. Solitamente infatti si vanno ad affinare goal che erano stati definiti in modotroppo approssimativo o comunque poco realistico.

La tecnica, pur estendibile da un punto di vista teorico non pare realmente interessante nelnuovo ambito in cui ci stiamo muovendo. Di fatto la politica di de-idealizzazione ha senso inpresenza di una RE parziale o comunque ancora da raffinare, in cui ci troviamo di fronte a featurese non superflue, almeno non essenziali.


Stabilire Condizioni Sufficienti Di Realizzabilità

Rientra nell’ottica di una de-idealizzazione dei goal un approccio, dal carattere prettamente for-male, proposto in [22]. La soluzione nasce dalla stessa domanda essenziale: dato un sistemache sperimenta comportamenti emergenti, è possibile rileggerne alcuni requisiti, rendendoli piùrestrittivi, al fine di porci nelle condizioni di tollerare il comportamento emergente?

L’idea alla base è che ogni goal partially composable può essere analizzato come prodotto dellesue parti e, in talune occasioni, l’emergenza ad esso interna possa essere eliminata rendendolo piùrestrittivo. Si immagina cioè che l’emergenza sia correlata ad una specificità del goal, eliminatala quale l’ignoranza sottostante cessa di manifestarsi. Non si realizzerà dunque più il goal origi-nariamente pensato, ma se ne implementerà una versione edulcorata che conserva la sostanza delprecedente, ma rinuncia ad alcune funzionalità.

Vediamo un esempio. Un goal del tipo:

�(A ∨ ¬X) (5.1)

può essere suddiviso in due sub-goal:

�A (5.2)

�¬X (5.3)

Così come un goal della forma:

A ∧ ¬X⇒ B (5.4)

cioè:

�((¬A ∨ ¬¬X) ∧ B) (5.5)

può essere riletto come:

A⇒ B (5.6)

¬X⇒ B (5.7)

Questo significa che possiamo verificare la realizzabilità di 5.1 e 5.4 tramite la realizzabilità di 5.2e 5.6, ignorando cioè gli aspetti emergenti.

Si suggerisce in pratica che un goal, con sub-goal sconosciuti o irrealizzabili, che sperimen-ta evidenze emergenti possa essere comunque soddisfatto rendendolo più restrittivo. Vengonoproposti in tal senso due pattern di riduzione.

�(A ∧ ¬X)→ �A (5.8)

A ∨ ¬X⇒ B→ A⇒ B (5.9)

Il problema di un simile approccio è l’attuabilità pratica. Se è vero infatti che una or-reduction,come quella proposta in 5.8, assicura la realizzazione di una versione edulcorata del goal, è al-trettanto vero che quasi mai saremo nelle condizioni di scindere così nettamente l’emergenza daisub-goal che si trovano al medesimo livello. Il problema risiede, ancora una volta, nella nostra


limitatezza conoscitiva. Predisporre una corretta restrizione del goal potrebbe essere concettual-mente valida come soluzione, ma quasi mai saremo in grado di fare assunzioni corrette sullalocalizzazione e sull’estensione dell’emergenza, risultando dunque incapaci di avere una metricadi giudizio valida per capire cosa ridurre del goal iniziale.

A livello pratico tutto questo si traduce in un’impossibilità a possedere i punti di partenza dellededuzioni proposte in 5.8 e 5.9. Normalmente infatti X ed A non possono essere trattati cometipici atomi di una formula CTL, in quanto non sono logicamente separati. A potrebbe infatticontenere al suo interno:

• X e quindi rendere insensata la semplificazione;

• un X ′ che è sottoparte dell’emergenza totale (X = X ′ ∧ · · ·∧ Xn), dunque X ′ → X e valeancora la considerazione precedente.

5.2 R I D U R R E L A F R E Q U E N Z A D E L F E N O M E N O E M E R G E N -T E

Rientrano sotto il nome di tattiche di Reduction Obstacle tutte quelle soluzioni che possono es-sere approntate per ridurre la frequenza con cui un ostacolo si manifesta. Si fa spesso riferi-mento a tecniche focalizzate su agenti umani, il cui fine è generalmente quello di “disincentivarecomportamenti scorretti”.

Nell’ottica di un’analisi emergente non paiono politiche applicabili. Il problema è che nonconoscendo le cause profonde di un fenomeno emergente non ha senso parlare di riduzione quan-titativa del fenomeno: come si possono progettare soluzioni che modifichino la frequenza con cuiavvengono specifiche azioni se non si ha coscienza di tali azioni?

Politiche di questo tipo sono invece coerenti con la volontà di ridurre l’ignoranza. In fondo essaè spesso conseguenza del contesto in cui si esprime una feature e, tra le altre ragioni, dell’intera-zione con agenti umani, i quali possono “inquinare” l’idealità del contesto così come esso era statooriginariamente pensato. Pertanto, pur non prefigurandosi come la scelta preferenziale per affron-tare il problema, le tecniche accennate possono certamente rappresentare un aiuto nell’approccioalla riduzione dell’ignoranza.

5.3 TO L L E R A R E L’ E M E R G E N Z A

L’assunzione di base delle tecniche di tolleranza degli ostacoli è che, posta l’impossibilità dievitare che un certo ostacolo si manifesti, possono esserci condizioni d’interesse da rendere validein concomitanza o successivamente alla manifestazione dell’impedimento.

Predisporre tecniche di tolleranza significa, implicitamente, richiedere come presupposto ine-luttabile l’avvenuta manifestazione dell’evento emergente, ciò fa sì che queste tecniche sianoaprioristicamente inutilizzabili per la riduzione dell’ignoranza associata ad un sottosistema, inquanto, come abbiamo sottolineato in precedenza, tale analisi è compiuta nella prima fase di REquando il fenomeno emergente non è ancora manifesto.

Nel caso dell’emergenza tale approccio rimane teoricamente valido ma certamente vede svilirela sua efficacia; sia per limiti strutturali del medesimo, che non riesce a conformarsi al nuovo


ambito emergente, sia per i costi indotti dalle trasformazioni richieste che, vista la fase avanzatadel progetto, risultano eccessivi.

5.3.1 Limitare Temporalmente L’Emergenza

L’idea è quella di immettere nel sistema un goal atto a specificare limiti temporali per l’irrea-lizzabilità connessa al fenomeno emergente. Si immagina in sostanza che il goal ostacolato dalfenomeno emergente possa essere ripristinato in un tempo ragionevole (possibilmente prefissato).

L’applicabilità di un simile task è ovviamente correlata con la possibilità di invertire o quan-tomeno stabilizzare il processo emergente. Essa dipende pertanto dai singoli casi ed è difficileoffrire linee guida generali. Si fa notare comunque come viga una difficoltà di fondo che nell’am-bito degli ostacoli non sussisteva. Il problema è che un ostacolo ha una risultanza ben definitae, da un punto di vista degli effetti correlati, limitata con precisione. Al contrario, proprio perl’impossibilità di conoscere le cause associate a certi fenomeni, l’ambito emergente manifestacondizioni inattese di cui conosciamo solo una forma, quella attuale. Di conseguenza, se è facilepensare di limitare l’area di azione di un ostacolo e, successivamente, proporre azioni reattiveche ripristinino certe condizioni d’interesse, più difficile appare riuscire a stabilire condizioni disicurezza in cui muoverci per assiomatizzare il ripristino del goal d’interesse.

Nonostante ciò la tecnica è assolutamente estendibile al nuovo ambito e può anzi conformarsicome particolarmente utile in presenza di contingenze non critiche.

5.3.2 Indebolire Gli Effetti Del Fenomeno Emergente

In precedenza si immaginava di ripristinare completamente il goal invalidato dalla condizioneemergente, in questo caso il task diviene quello di ripristinare parzialmente tale costrutto. Insostanza si immagina di poter definire limiti temporali entro i quali rendere valida:

• una versione edulcorata del goal;

• una versione edulcorata del parent-goal.

Le considerazioni a proposito dell’applicabilità di una siffatta tecnica risolutiva sono sostanzial-mente le medesime date in precedenza. Valgono in effetti le stesse problematiche, connesse ancoracon l’impossibilità di predire gli eventi collaterali alla manifestazione emergente in esame.


Il capitolo attuale ha permesso di concludere il percorso nodale della tesi. Dopo aver osservato lanascita del concetto di emergenza, la sua introduzione nell’ambito della RE e alcune tecniche dianalisi e di testing pensate appositamente per individuare fenomeni di questo tipo, la trattazionenon poteva esimersi dal considerare gli approcci idealmente utilizzabili per il superamento delfenomeno indesiderato. In particolare, viste le analogie che correlano l’emergenza e la nozione diostacolo, l’analisi si è concentrata proprio sulla OA di KAOS, cercando di capire le reali possibilitàdi traduzione nel nuovo ambito.


La disamina condotta ha evidenziato come l’emergenza sia un concetto molto più sfuggentedi quello di ostacolo, rendendo solo parzialmente applicabili le soluzioni viste in precedenza. Ilproblema risiede principalmente nella tempistica associata all’atto risolutivo.

Se parliamo di correzione dell’emergenza a livello di RE, cioè di eliminazione di un’agglo-merazione anomala di ignoranza (rilevata tramite la tecnica da noi proposta), il processo risultasufficientemente simile alla OA da permettere l’adozione delle principali metodologie osservateanche per gli ostacoli. In particolare assumono un rilievo particolare la selezione di un agentealternativo e la modifica delle specifiche tramite l’immissione di requisiti aggiuntivi. Le due tecni-che rappresentano infatti entrambe un modo per garantirsi quell’accrescimento informativo che, inultima analisi, è il vero orientamento da seguire per risolvere l’emergenza. Al di là delle tecnicheformali infatti, ciò che si tenderà ad osservare all’atto pratico (e il caso di studio del capitolo 6 nesarà una riprova) è la ricerca delle informazioni mancanti, più che una ristrutturazione completadel goal-tree. Peraltro la vicinanza, temporale e logica, con le fasi iniziali del progetto (in cuisi intervistano i commissionari e si stilano i documenti di specifica) permettono di reperire taliinformazioni mancanti in modo sufficientemente semplice.

Queste considerazioni assumono una validità ancora maggiore nell’ottica della correzione diun fenomeno emergente già evidenziatosi (tramite test o a run-time). In questo caso infatti icosti correlati ad una ristrutturazione del sistema, o comunque a cambiamenti sostanziali, inibi-scono a priori gran parte delle tecniche viste. Dovendo affrontare un fallimento di questo tipo sipropenderà pertanto ad adottare tecniche “canoniche” di correzione di un errore.

La rilettura emergente non consente dunque di migliorare significativamente la correzione diun errore. Né d’altra parte tale rilettura risulta inutile in questo contesto: la possibilità (descrittanel capitolo precedente) di individuare velocemente il problema di integrazione radice dell’errore,riduce infatti considerevolmente il tempo totale spesso nella fase di risoluzione del comportamen-to erroneo, consentendo di isolarlo e di indirizzare quelli che abbiamo definito come approccicanonici alla correzione dell’errore.

Capitolo 6Caso Di Studio Affrontato

“Il concetto omette o perde qualcosa diestremamente importante, qualcosa diprezioso che si trova solo nella realtà.”

Anthony De Mello

L’analisi sin qui condotta ha permesso di prendere coscienza di un problema essenziale neldesign di sistemi complessi; quello dell’ignoranza associata ai suoi elementi costituenti e, di con-seguenza, al sistema stesso. La trattazione ha offerto una panoramica completa dall’ambito distudio, consentendo di apprezzare le differenti sfaccettature del problema in essere: partendo daconsiderazioni relative ai limiti intrinseci dei sistemi critici, abbiamo formalizzato una tipologiadi analisi che si prefigura come ottimale per lo studio di sistemi costituiti da componenti basicieterogenei; sono state inoltre osservate le differenti manifestazioni del problema a differenti livellidi lettura e cercando di sintetizzare alcune direttive di base per reagire a tali manifestazioni.

Naturale conclusione di questo percorso è ovviamente costituita dalla disamina di un caso distudio reale, che permetta di osservare “all’opera” le tecniche proposte nel lavoro. Assume, diconseguenza, un’importanza nodale la selezione dell’esempio da sviscerare. La nostra scelta èricaduta su un caso di studio “particolare”, distante cioè dall’idealità che le osservazioni fatte neicapitoli precedenti avrebbero suggerito. Abbiamo scelto questo tipo disamina, capace di portare allimite le capacità analitiche della metodologia proposta, in modo da poter osservare e qualificarecompiutamente i bound applicativi della metodologia stessa.

Idealmente infatti, volendo esternare tutte le peculiarità descritte nelle pagine precedenti, sisarebbe dovuto cercare un esempio caratterizzato da:

• requisiti sistemici chiari, dettagliati ed esaustivi;

• presenza di molteplici componenti di base che si integrano assieme, ove ogni componente ècaratterizzato da requisiti (funzionali, ma anche di reliability) non eccessivamente restrittivi;

• presenza di un insieme di componenti equivalenti tra cui scegliere per selezionare quelloottimale in relazione alle feature richieste, con accesso alle descrizioni, funzionali e non, ditali alternative;

101

102 C A S O D I S T U D I O A F F R O N TATO

• progetto in fase avanzata, in cui si siano già operate alcune scelte e si siano effettuati test (icui risultati siano accedibili);

• al limite un’architettura già messa in opera e per cui si siano rilevati comportamenti inattesi.

Le caratteristiche sovraindicate avrebbero consentito di applicare in toto le direttive proposte nel-la tesi. D’altra parte ci sono almeno due aspetti che, a nostro parere, devono essere tenuti inconsiderazione.

1. Un caso di studio che sappia soddisfare le richieste di cui sopra è difficilmente reperibile. Leaziende del settore sono infatti chiaramente restie a divulgare un loro progetto, soprattutto secorredato di documenti interni all’azienda come quelli che possono riguardare la selezionedi alternative, i test condotti e il funzionamento risultante.

2. Peraltro, le considerazioni offerte nel corso del lavoro dovrebbero aver sufficientementeconvinto il lettore della necessità dell’analisi in corso e della bontà dell’apporto ad essaconnesso. Risulta pertanto forse più interessante osservare i risultati ottenuti dal metodoproposto in relazione ad un caso di studio tutt’altro che ideale, ma certamente più vicino aquelle che sono le necessità reali di un’azienda e alle risorse effettivamente disponibili perun progettista. Inoltre la mutata disamina permetterà di qualificare l’apporto che la nostraproposta può dare limitatamente alla fase di specifica dei requisiti. In tal senso potrebbe es-sere infatti assolutamente interessante capire se la nostra metodologia mantiene una “ragiond’essere” anche se circoscritta alle prime fasi della RE e se, in tale ambito, può realmen-te rappresentare una tecnica immediata ed efficace, pur con gli ovvi limiti del caso, perarricchire la RE stessa con considerazioni relative all’ignoranza sottesa.

6.0.1 Breve Presentazione Del Caso Di Studio

Stanti le considerazioni precedenti, il caso di studio esaminato riguarda un progetto (attualmentein corso) di un’importante società italiana (che indicheremo con il termine AZ) che lavora nelsettore ferroviario1. In particolare, la società ci ha gentilmente permesso l’accesso ai documentidi specifica [58] [59] di un sistema critico che stanno sviluppando. Oggetto della nostra analisiè infatti un Sistema di Rilevazione Incendio (SRI) da installare a bordo dei veicoli appartenentiad una piattaforma di metropolitane (che indicheremo con PM) finalizzata a coprire i bisogni dialcune città italiane.

Possiamo sintetizzare le funzionalità richieste.

Lo scopo del sistema in esame consiste nella rilevazione di un incendio durante la fase diservizio a bordo dei veicoli PM (vedi figura 18). L’allarme viene generato se si verifica una delle

seguenti condizioni:

• presenza di fumo nei comparti passeggeri;

• superamento della soglia di temperatura di 110◦C all’interno dei cassoni ritenuti criticiper l’eventuale innesco di un incendio;

• chiamata manuale di allarme.

6.1 D I S A M I N A A P P R O F O N D I TA D E L C A S O D I S T U D I O 103

AA06PHF [ REV. 2 ] Pagina 24 di 95

3.1.1 Caratteristiche generali di Veicolo

La piattaforma MLA sarà composta da una flotta di veicoli che sono riportati nei figurini non definitivi in Figura 1: Figurini non definitivi della piattaforma MLA.

Figura 1: Figurini non definitivi della piattaforma MLA

Le caratteristiche principali del veicolo vengono riassunte nelle tabelle che seguono ( Metropolitana Salonicco

VEHICLE TYPE Train composition Train set composed of four articulated coaches. It

can be coupled in multiple unit under emergency conditions in case of a failed train.

Vehicle Bi-directional with fully automatic drive + aux. control desk for manual drive in emergency condition.four cars four motor bogies one trailer bogie.

Design life 30 years 120.000 Km /Yr Structure compression load According EN12663 in the worst vertical load

conditions.Finite element stress analysis reqrd Differentiated energy absorption structure (Salonicco)

Energy absorbers on coupler, buffers and anticlimber. The vehicle can withstand, with no damage, impacts

Figura 18: Figurino di una tipica metro componente la piattaforma PM.

Come accennato in precedenza, il progetto è attualmente in fase di sviluppo da parte di AZ. Difatto, per quanto concerne gli elementi in nostro possesso, possiamo dare i seguenti riferimentitemporali:

• Il documento di specifica tecnica dei requisiti [58] è aggiornato a Maggio 2008;

• mentre la sintesi dei requisiti definitivi per SRI [59] è aggiornata alla revisione 01 diGennaio 2009.

In sintesi possiamo dire che, relativamente alle nostre conoscenze, il progetto è attualmente in fasedi revisione finale dei requisiti, in modo da poter sottoporre i medesimi alle aziende interessate asviluppare i componenti richiesti. In tal senso, possiamo individuare quattro componenti chiaveche dovranno necessariamente essere implementati (da aziende esterne ad AZ):

• sensori di fumo;

• sensori di temperatura;

• pulsanti di chiamata;

• unità di controllo elettronica.

Il sistema ha chiaramente un carattere critico, in particolar modo per la presenza dei passegge-ri della linea metropolitana. L’impianto, come detto, dovrà infatti essere installato a bordo deiveicoli delle metropolitane di alcune città italiane.

6.1 D I S A M I N A A P P R O F O N D I TA D E L C A S O D I S T U D I O

La brevissima descrizione proposta non è certamente sufficiente ad esemplificare la natura e leproblematiche del caso di studio. In questa sezione proporremo pertanto una panoramica delprogetto, cercando di palesare le principali caratteristiche, le soluzioni architetturali adottate ele interrelazioni tra i componenti. Tutte queste informazioni saranno infatti indispensabili peraffrontare poi in modo consapevole la lettura della nostra analisi dell’emergenza. Cercheremo,per quanto possibile, di limitare la descrizione ai tratti salienti del progetto, in modo da nonscadere in una riproposizione speculare dei documenti di specifica. Peraltro i copyright vigenti sutali documenti ci impediscono di eccedere nella divulgazioni di informazioni che sono tutelate dadiritto d’autore.

1 Visti gli interessi economici in gioco ci è stato chiesto di non rendere pubblico il nome dell’azienda.


La trattazione si dividerà in più parti al fine di coprire le differenti sfaccettature del problema inesame. Anzitutto, in sezione 6.1.1, dettaglieremo le funzionalità richieste al sistema, con partico-lare attenzione alle modalità di integrazione dei componenti e le relative correlazioni. Lo studiodella normativa di riferimento (sezione 6.1.2) permetterà poi di associare, in estrema sintesi, requi-siti qualitativi specifici ai differenti componenti. Ci soffermeremo poi sulla natura e sull’apportodato dall’analisi effettuata da AZ (sezione 6.1.3), utilizzandola peraltro come spunto per trattarequelli che, ai nostri occhi, si caratterizzano come limiti strutturali del caso di studio (CS) (sezione6.1.4); limiti che, comunque, non inficiano l’interesse del caso stesso (sezione 6.1.5).

6.1.1 Requisiti Principali Del Progetto

Di seguito riportiamo gli elementi costitutivi salienti dell’intero progetto. Come già detto, abbia-mo deciso di dare particolare risalto alle funzionalità richieste e alle interrelazioni conseguenti. Ladisamina è suddivisa in più parti, in linea con le differenti “aree logiche” individuabili all’internodel progetto:

• rilevazione incendio;

• interfacce di comunicazione e di trasmissione;

• diagnostica;

• attività collaterali.

Rilevazione Incendio

Il sistema SRI deve essere in grado di rilevare la presenza di un probabile incendio sui convogliappartenenti alla piattaforma PM. In particolare si devono provvedere i seguenti:

1. sensori fumo atti a rilevare la presenza di fumo per combustione di componenti costitutiviil veicolo o di oggetti portati dai passeggeri;

2. sensori temperatura atti a rilevare, come probabile causa d’incendio, il superamento di unasoglia di temperatura ritenuta critica;

3. allarme manuale azionabile dai passeggeri stessi.

Il sistema SRI deve essere in grado di fornire tempestivamente un allarme al TCMS, comprensivodella localizzazione della zona in cui si è manifestato l’allarme.

Il sistema è composto da due centraline elettroniche (in modo da avere ridondanza) poste alleestremità del veicolo.

Interfacce

Il sistema sarà interfacciato con:

• sistema di bassa del veicolo;

• TCMS (sistema di controllo centrale del treno);

• HVAC (impianto di riscaldamento e condizionamento).


Le apparecchiature dovranno funzionare nel range di tensioni considerato (per ragioni di brevitàdemandiamo a [59] i dettagli).

Dovranno essere predisposte le interfacce:

• segnale di allarme antincendio, uno per cassa;

• segnale di avaria centralina;

• segnale di stato centalina;

• segnale di incendio a bordo.

Tali interfacce sono di natura hardware.

Auto-Diagnosi

Si richiede che sia i sensori fumo, che i sensori temperatura siano in grado di monitorare almenoi seguenti stati di funzionamento:

• funzionamento normale;

• necessità di manutenzione;

• stato di allarme;

• stato di guasto.

Tramite tali funzionalità il sistema diagnostico, integrato nella centralina di controllo, deve comu-nicare al TCMS tutte le informazioni relative allo stato del sistema. RSI deve peraltro tenere inmemoria, a scopi di diagnostica, tutti i valori significativi riscontrati, secondo intervalli di tempoprefissati.

Attività Collaterali

Dovranno essere previsti dispositivi che permettano di spegnere gli incendi rilevati nel minortempo possibile.

Il sistema SRI deve essere predisposto di un comando di reset attuabile:

• manualmente dalla centralina stessa;

• da remoto, per mezzo della linea treno dedicata.

Si deve inoltre poter collegare una “Portable Test Unit” (PTU) alla centralina di controllo peroperazioni di diagnostica.

6.1.2 Normative Di Riferimento

I componenti (così come del resto le feature) proposti nel paragrafo precedente sono ovviamentecorredati da un corposo insieme di normative atto a qualificarli e regolamentarli. Per brevità ditrattazione, abbiamo preferito riassumere tali requisiti in un’unica tabella (vedi sotto). In questomodo rimane comunque possibile apprezzare le stringenti richieste cui è sottoposto l’impianto e,di conseguenza, l’intrinseca bontà del medesimo.


Normative Soggetto Della NormaSRI

EN 11170EN 50155

ComponentiEN 54 Sensori FumoUNI CEI 11170-2 (par 7.1) Allarme PasseggeriEN 50155 Documentazione del SoftwareEN 62061 Specifica di SIL1 (cui devono appartenere le

funzioni software)UNI CEI 20-36 Prova di resistenza al fuoco dei cavi elettrici

AmbientaliEN 14750-1 Classificazione Ambientale Treno

InterfacceEN 50155 (par 5.2.1) Specifica delle Interfacce Digitali di Input/OutputIEC 61375-1 Interfaccia Bus MVB Elettrico a Trasformatore

di Tipo EMDEIA RS-485 Interfaccia Bus RS485 di Tipo Half-Duplex a 3 FiliEN 12633 Supporti Meccanici di Categoria P-IIIEN 50153 Protezione Contatti Indiretti Tramite Messa a Terra

AutodiagnosiCEI EN 50155 (par 5.4) Autodiagnosi per ogni Apparato Elettronico

Hazard AnalysisEN 50126EN 50128EN 50129

6.1.3 Analisi Effettuata Da AZ

La ricchezza dei requisiti richiesti e la profondità dell’analisi sottesa sono indicatori chiari delfatto che AB abbia già condotto un’analisi, o almeno una sua parte, sul sistema in esame. Ovvia-mente tale evidenza è un pleonasmo: l’analisi dei requisiti sistemici è un primo passo ineluttabileladdove si intendano ricercare fornitori per i componenti dell’impianto da sviluppare; come sareb-be possibile altrimenti esplicitare le feature d’interesse e definire, almeno approssimativamente, ilcontesto operativo?

Abbiamo pertanto in nostro possesso [59] una strutturazione già completa di tutti i requisitifunzionali di cui dovrà godere il sistema. Tale strutturazione segue chiaramente le direttive tipichedi una RE aziendale, in cui i requisiti si caratterizzano come mere richieste funzionali espressein linguaggio naturale e non organizzate secondo alcuna struttura. Il risultato di tale lavoro, purtenuto nella dovuta considerazione, è stato pertanto utilizzato solo come base di partenza perla nostra disamina, la quale poggia su un formalismo (KAOS) che ha regole molto più rigide.I requisiti dati sono dunque stati reinterpretati in un contesto collettivo (che ci ha permesso diriottenere un’approssimazione del documento di specifica originario) e solo dopo si è procedutoad una RE che seguisse le direttive da noi proposte.


Al di là dello studio effettuato sui requisiti, l’analisi di AB ha comunque prodotto altri risultatidi notevole interesse per la nostra analisi. In particolare è essenziale sottolineare la specifica dei“Metodi di Qualifica”, cioè la definizione della fase di testing. Per i vari requisiti rilevati (da AB)sono infatti preventivate tecniche di verifica, che possono essere di tipologia differente.

• Test: in cui si applica una metodologia di testing per verificare la corretta risposta alrequisito in esame.

• Analisi: in cui la qualifica avviene per mezzo di dati sperimentali o teorici.

• Ispezione: in questo caso ci si limita ad effettuare un esame visivo dei componenti delsistema.

Particolarmente eloquente, in relazione alla bontà del sistema che si sta sviluppando, è il numero direquisiti su cui si effettua un vero e proprio test: di fatto tutti i requisiti, eccezion fatta per alcuniaspetti relativi ai componenti elettrici (in particolare fili), vengono testati. Questo è un aspettoessenziale del sistema (e in generale è una caratteristica tipica dei sistemi critici): il presuppostoda cui dobbiamo partire pertanto è che ogni requisito (da loro) rilevato è verificato tramite untest. La grande incognita che rimane (che approfondiremo nel seguito) riguarda la natura del testcondotto, che, vista la fase di sviluppo del sistema, probabilmente non è conosciuta neppure daglianalisti di AB.

6.1.4 Limiti Del Caso Di Studio

I dettagli del caso di studio, così come l’intera contestualizzazione del medesimo, dovrebbero averpalesato le differenze sostanziali che caratterizzano il sistema in esame rispetto ad un eventualeCS ideale (vedi pag. 101). Possiamo inquadrare tali limitazioni in due categorie:

1. anzitutto si riscontrano difficoltà legate alla mancanza di alcune conoscenze vitali per un’a-nalisi integrale;

2. in secondo luogo la particolare criticità del sistema obbliga a trattare componenti e meto-dologie di integrazione assolutamente ottimali, riducendo in maniera significativa l’apportomigliorativo che la nostra analisi può indurre.

Cerchiamo di esemplificare anzitutto il primo aspetto.Parlando di mancanza di conoscenza si vuole soffermarsi sull’impossibilità, assolutamente ine-

vitabile, di possedere o anche accedere ad informazioni che, al contrario, sono assodate per unprogettista/analista di AB che esamini il medesimo CS. Notiamo anzitutto una difficoltà legataalla mancanza del naturale background nozionistico che caratterizza ogni azienda, tanto più un’a-zienda delle dimensioni di AB e che si occupa di componenti e impianti estremamente critici.Leggendo i documenti dei requisiti si nota in sostanza la mancanza di alcuni dettagli che, al con-trario ai nostri occhi, sembrerebbero rilevanti per ottemperare ad una trattazione esauriente: sinotano pertanto aspetti completamente trascurati, figli del fatto che un chiarimento in tal sensosarebbe inutile rappresentando tali dettagli assunzioni implicite per chi lavora o abbia lavoratosu altri progetti similari oppure essendo caratteristiche già ampiamente dettagliate in altri docu-menti interni all’azienda (vedi in particolare la mancanza di indicazioni sui test da condurre o lasupposta conoscenza del comportamento del HVAC o del TCMS).


Uno degli ambiti che maggiormente risulta interessato da questa deficienza informativa riguar-da, come abbiamo accennato, la natura dei test che si intende condurre per verificare il correttofunzionamento del sistema. In effetti, come abbiamo sottolineato anche in sezione 6.1.3, la criti-cità dell’impianto implicitamente comporta la necessità di preventivare un testing massivo atto acontrollare quasi ogni requisito componente il sistema. In tal senso l’apporto che la metodologiada noi proposta può dare al progetto viene ridimensionato, poiché le considerazioni offribili suitest da condurre decadono di fronte alla presenza di un testing totale. D’altra parte di tale testingnon si conosce niente, a parte il requisito che va a stressare. Ipoteticamente pertanto potremmotrovarci di fronte ad una metodologia di testing quantitativamente esaustiva, ma qualitativamentedeficiente. Data la portata del progetto e l’importanza di un’azienda come AB, nel corso del-la nostra disamina noi partiremo ovviamente dal presupposto che i test siano stati condotti con“coscienza di causa” e che pertanto siano corretti; laddove con tale termine intendiamo che il re-quisito in esame viene controllato nella sua interezza e considerato nel contesto di riferimento.Nel proseguo ci limiteremo pertanto a esternare alcuni focus non ovvi, che però, stante l’analisicondotta, assumono (o potrebbero assumere) un ruolo rilevante.

La seconda deficienza, in termini informativi, nodale del CS è rappresentata dalla totale man-canza di informazioni sui componenti costitutivi il sistema in essere. Parlando di disamina dell’i-gnoranza abbiamo infatti sottolineato come l’analisi emergente proposta muta la tempistica tipicadi una RE, spostandosi ad un momento leggermente successivo in cui è presente almeno una listadei componenti da acquistare e delle relative alternative. In un siffatto caso infatti (e questo diver-rà ancor più evidente nel capitolo 7 in cui parleremo di componenti COTS) l’ignoranza assumeun ruolo essenziale e, di conseguenza, si esplica al meglio l’apporto dato dal nostro studio. Qui,al contrario, non solo non sono presenti alternative, ma di fatto non sono ancora stati scelti i com-ponenti che si andranno ad inserire nell’impianto. Questa mancanza è ovviamente figlia del fattoche il progetto di AB è ancora in una fase troppo precoce per aver già effettuato una selezionedelle soluzioni possibili. La conseguenza naturale delle osservazioni fatte è che siamo costretti adanticipare l’ambito applicativo del nostro studio, conformando quest’ultimo come un’analisi dacompiere totalmente in fase di specifica dei requisiti; questo fatto peraltro non deve essere intesocome totalmente negativo, in quanto ci permette, in linea con le considerazioni offerte a pag. 102,di apprezzare meglio il tipo di apporto che la nostra proposta può dare in una primissima fase dianalisi del sistema.

Correttezza Del Progetto In Esame

Il secondo limite strutturale del CS in esame è rappresentato paradossalmente dalla sua bontà.In sezione 6.1.2 abbiamo osservato le regolamentazioni cui devono adeguarsi i vari componentidel sistema; si tratta di requisiti stringenti, sia in termini di funzionalità richieste, che di analisieffettuate sulle medesime e di documentazione associata. D’altra parte una simile situazione nonpuò sorprendere, stiamo infatti maneggiando un impianto addetto a monitorare una condizioneambientale critica (quale è chiaramente un incendio) che mette a repentaglio la vita stessa deipasseggeri (in tabella 5 è proposto il RAMS relativo, in cui si palesa l’alta affidabilità richiesta).E’ evidente dunque, visto anche il know-how di AB in questo settore, come la disamina fatta suirequisiti del RSI, pur non essendo ancora ultimata, sia assolutamente ottimale.

Tale accuratezza è immediatamente percepibile analizzando [58] [59], in cui spicca la ricchezzadi requisiti, in termini di funzionalità e di affidabilità, richiesta per ogni elemento costitutivo. Aldi là di poche eccezioni (che verranno sottolineate nel corso della nostra analisi) i componenti


devono tutti rispondere a normative stringenti e sono corredati di richieste particolari in funzionedelle peculiarità che li possono caratterizzare: in questo modo si riesce a coprire compiutamentela pur ricca casista di eventi, anche inaspettati , che potrebbe caratterizzare componenti immessiin un contesto complesso com’è quello di una carrozza di una metropolitana, in cui l’apportoumano costituisce un elemento di disturbo assolutamente di rilievo. In tal senso ha evidentementegiocato un ruolo chiave la pregressa esperienza di AB, che certamente aveva già sviluppato sistemisimilari.

A queste considerazioni, si deve poi aggiungere la dichiarata volontà da parte di AB di massi-mizzare l’affidabilità del sistema, disinteressandosi alla ricerca di soluzioni alternative o innovati-ve, così come all’utilizzo di prodotti nuovi. Sono chiarificatrici in tal senso le seguenti (tratte da[58]).

Non è richiesta la progettazione di una soluzione innovativa, ma la realizzazione di un sistema“service proven” già sperimentato e realizzato mediante componenti già utilizzati sulle principali

reti metropolitane europee per garantire il massimo grado di affidabilità.

I sensori utilizzati dovranno essere di comprovata affidabilità.

Né i requisiti sono meno stringenti sui componenti software:

Nel caso in cui le funzioni descritte nella presente specifica siano gestite con il contributo difunzioni SW, le funzioni SW dovranno essere sviluppate con SIL 1.

E’ evidente pertanto come anche i termini della nostra ricerca dovranno adattarsi ad un similecontesto. Termini quali “X alta” o, equivalentemente, “grande ignoranza” assumono una conno-tazione sfumata rispetto alle osservazioni fatte nei capitoli precedenti; ovviamente non ci potràessere una misconoscenza così marcata in relazione a componenti che costituiscono un sistema ditale criticità.

6.1.5 Obiettivi Del Caso Di Studio

Stanti le considerazioni offerte sin ora appare evidente come gli obiettivi che ci aspettiamo direalizzare tramite questo studio si discostino, almeno in parte, dall’orizzonte di riferimento tipi-co dettagliato nei capitoli precedenti. La mancanza di informazioni sui componenti, così comel’effettuazione dell’analisi in una fase precoce dello sviluppo del sistema, rendono impossibilel’ottenimento di risultati quali:

• l’identificazione di componenti con elevata ignoranza associata;

• la strutturazione di un piano di testing da associare ai requisiti (essendo già preventivato).

La nostra attenzione si sposterà pertanto sull’ignoranza presente nelle feature richieste ai com-ponenti, esamineremo cioè componenti “virtuali” sulla base dei requisiti approntati da AB e sutali componenti cercheremo di ragionare, identificando la compiutezza della loro definizione el’impatto dei medesimi nel contesto di utilizzo. Particolare interesse assumeranno difatti le moda-lità in cui verranno utilizzati i componenti e, in generale, le modalità di correlazione, e quindi didisturbo, tra i medesimi.

L’obiettivo è pertanto quello di migliorare, per quanto possibile, il sistema, proponendo oppor-tune modifiche.


Tipologia Requisito DatiAffidabilità

Distanza Media tra Guasti Immobil. 6.500.000 kmDistanza Media tra Guasti Critici 2.500.000 kmDistanza Media tra Guasti Generici- Convoglio 3 casse 135.000 km- Convoglio 4 casse 125.000 kmFattore di conversione MD/MT 20km

DisponibilitàMateriale di ricambio in seguito a guasto

ManutenibilitàConvoglio 3 casse- Ore uomo 0.008 Mhr/100 km- Costo materiale 0.35 AC/1000 kmConvoglio 4 casse- Ore uomo 0.01 Mhr/100 km- Costo materiale 0.50 AC/1000 km

SicurezzaSil1

Tabella 5: Requisiti RAMS del caso di studio.

• Indicazioni su particolari comportamenti indesiderati da verificare nei test già preventivati.

• Migliorare la definizione di alcuni componenti, in modo da evitare l’utilizzo di componenticon “zone d’ignoranza”.

• Qualificare al meglio i contesti ambientali, così da percepire più consapevolmente le moda-lità di integrazione tra componenti e, se necessario, prevedere modalità differenti.

Un ulteriore apporto dato dall’attuale disamina è inoltre rappresentato dalla sua accezione di “ve-rificatore” di correttezza. Chiaramente durante lo sviluppo della nostra analisi proporremo tuttauna serie di raffinamenti e di considerazioni che si differenzieranno da quelle proposte in [59] eche costituiscono la sintesi dell’analisi condotta da AB. Il confronto tra i due progetti permette-rà pertanto di rilevare eventuali differenze di sostanza e, al limite, ipotizzare una progettazionedifferente del SRI.

6.2 A N A L I S I D E L L’ E M E R G E N Z A

Terminata la, pur necessaria, contestualizzazione del caso di studio condotta nelle pagine prece-denti, ci focalizzeremo adesso sulla disamina vera e propria dei contenuti emergenti del medesimo.Come si potrà osservare, sono stati individuati alcuni “nodi di agglomerazione” dell’ignoranza chemeritano di essere analizzati a fondo.

Prima di addentrarci in queste considerazioni, pare però indispensabile soffermarsi su talunescelte stilistiche che riguardano la rappresentazione adottata nel corso del capitolo.

6.2 A N A L I S I D E L L’ E M E R G E N Z A 111

Per ogni evidenza emergente rilevata seguiremo i passi seguenti:

1. formalizzazione del goal-tree di riferimento;

2. calcolo dell’ignoranza associata al main-goal di tale albero;

3. tecniche risolutive adottabili per ridurre l’apporto emergente.

Per quanto riguarda il primo punto si sottolinea in particolare come il numero di elementi costi-tuenti sia stato ridotto ai soli goal e agli agenti associati, rinunciando in sostanza ad esplicitaremolti dei modelli di appoggio tipici di KAOS quali AIM, ARM, OM, OP (vedi capitolo 2). Ovvia-mente le informazioni presenti in tali modelli, pur non esternate graficamente, vengono utilizzatenel corso della trattazione. D’altra parte la scelta è coerente con le considerazioni fatte nei capito-li precedenti in cui, pur rimarcando l’interesse di tali modelli, sottolineavamo come lo strumentoirrinunciabile della nostra analisi sia rappresentato proprio dalle informazioni gerarchiche offertedal goal-tree.

Peraltro noi faremo ricorso ad una versione edulcorata dell’albero dei goal, rinunciando:

1. alla descrizione informale del singolo goal;

2. alla formalizzazione logica del singolo goal.

Tali rinunce sono legate al fine didattico degli esempi proposti e sono pertanto figlie della volontàdi mantenere sintetica e manifesta la rappresentazione; ove necessario il testo provvederà a farechiarezza, soprattutto per quanto riguarda il significato e il ruolo dei differenti goal rappresentati.Peraltro, sempre in considerazione della necessità di sintesi, nel corso della disamina non propor-remo il dettaglio completo dei goal-tree del sistema, limitandoci a presentare solo i sotto-alberiindispensabili per chiarire le considerazioni offerte.

Più complesso si è rivelato al contrario il secondo aspetto accennato in precedenza (il calcolodell’ignoranza). Da un punto di vista della fruibilità delle informazioni associate, l’ottimo sarebbestato il ricorso ad una rappresentazione ancora ad albero capace di evidenziare, anche visivamente,il “flusso di ignoranza” e, di conseguenza, l’agglomerazione dell’emergenza. In realtà utilizzareun formalismo simile si è rilevato impraticabile, conseguenza questa del tipo di correlazione (mol-to complessa e sfaccettate) tra le informazioni d’interesse (ignoranza sul singolo goal, contesto,ignoranza sulla feature offerta). Si è dunque deciso di adottare una rappresentazione tabellarecostituita da tante righe quanti sono i possibili apporti di ignoranza e tante colonne quanti sono igradi di ignoranza associabili (vedi l’esempio di tabella 6).

Per quanto riguarda gli apporti si possono avere fondamentalmente quattro tipologie di costrutti(anche in questo caso per gli esempi facciamo riferimento alla tabella 6).

1. Agente: ovviamente per ogni agente dobbiamo dare un grado di ignoranza specifico per lafunzione offerta dall’agente (nell’esempio è “SensoreTemp”).

2. CxNomeDelGoal: con questa notazione si indicano i contesti di riferimento di ogni goal(nell’esempio è “CxRilevaTempAlta”).

3. InNomeDelGoal: con questa notazione si indica l’ignoranza associata alle modalità dicorrelazione tra differenti sub-goal (nell’esempio è “IntRilevaTempAltaOMan...”).


SoggettoInEsame IgnoranzaAlta Media Bassa

SensoreTemp√

. . .

CxRilevaTempAlta√

. . .

IntRilevaTempAltaOMan...√

. . .

RilevaTempAlta√

Tabella 6: Esempio di tabella utilizzata per il calcolo dell’ignoranza. Qui sono presentati estratti delgoal-tree relativo al main goal “SegnalaAllarmeSeTempAltaOManuale”.

Dati questi valori è possibile calcolare l’ignoranza associata ai differenti goal e, in modo partico-lare, al main goal (nell’esempio è “RilevaTempAlta”).

Ad ogni apporto è associato un grado di ignoranza. Valgono ovviamente le considerazioni fattenel capitolo 3 (pag. 58), si trattava pertanto di scegliere una metrica da utilizzare per quantificarel’ignoranza presente nel progetto. Data la natura del caso di studio abbiamo deciso di ricorrere aduna gradazione piuttosto ridotta, in cui si hanno quattro possibili gradi di ignoranza.

1. Nullo: indicativo di elementi/goal su cui si ritiene di avere una conoscenza sufficiente (intabella è rappresentato da una “×” nella colonna “Ignoranza/Bassa”).

2. Basso/Medio/Alto: rappresentano i tre stati di “supposta ignoranza”.

a) Basso: identifica elementi/goal su cui si ritiene di poter fare sufficiente affidamento,pur consapevoli di non avere tutte le certezze che desideravamo.

b) Medio: identifica elementi/goal su cui ipotizziamo di avere deficienze informative.

c) Alto: è utilizzato principalmente per il goal radice. Un main-goal cui viene associatoun valore (calcolato) alto d’ignoranza è espressione di una possibile manifestazioneemergente.

Studio Dell’Emergenza Condotto

L’ultima importante premessa relativa alle modalità di lavoro seguite nel caso di studio riguardala “mappa concettuale” delle differenti sezioni in cui organizzeremo il resto della trattazione.

Chiaramente, in primo luogo per motivi di sintesi, non era infatti possibile pensare di proporreuna disamina onnicomprensiva in cui approfondire tutti gli aspetti trattati nelle specifiche. Si ètrattato pertanto di privilegiare alcuni requisiti, enfatizzando certi sotto-sistemi e tralasciandonequasi in toto altri. La politica di scelta dei requisiti di maggior interesse ha risposto a due direttive.

• Anzitutto abbiamo cercato di privilegiare sotto-sistemi che fossero espressioni di requisitipiù prettamente funzionali e legati al funzionamento imminente del dispositivo (abbiamoin tal senso scartato molte considerazioni relative alla manutenzione e alla collocazionedell’impianto).


• Inoltre sono stati preferiti i requisiti su cui avevamo una maggiore ricchezza informativa(quelli che prevedevano minori assunzioni, minor know-how aziendale, etc.).

Deve essere letta in quest’ottica la mancata disamina di aspetti comunque richiesti dalle specifiche,tra i quali sottolineiamo in particolare la “Manutenzione” e il “Trattamento delle Superfici”.

Figura 19: Schematizzazione del primo livello del Goal-Tree relativo all’intero RSI.

In figura 19 si può osservare una schematizzazione del primo livello dell’albero dei requisiti re-lativo all’intero sistema di rilevazione. La figura è utile per chiarire la topografia dei requisiti cheandremo ad approfondire; come si può osservare il SRI si sviluppa in vari sotto-alberi ognuno rela-tivo ad una problematica da risolvere. In linea con le considerazioni precedenti, ci concentreremosolo sulla parte bassa della figura in cui sono presenti i vari requisiti che analizzeremo.

1. Diagnostica&PTE: coinvolge tutte le fasi di auto-diagnosi e di accesso alle informazioni delsistema. Questo macro-requisito si specializza in due goal d’interesse:

a) Diagnostica: relativo solo all’auto-diagnosi (sviluppato in sezione 6.2.6).

b) PTU: che riguarda il collegamento con il PTU (sviluppato in sezione 6.2.4).

2. RilevaComunica&Estingui: è il requisito chiave del sistema, anch’esso composizione didifferenti apporti.

a) RilevaIncendio: vi si realizza chiaramente la funzione basilare di rilevazione di uneventuale incendio (sviluppato in sezione 6.2.2).

b) Estinione: in cui ci si occupa della fase di spegnimento dell’incendio rilevato (svilup-pato in sezione 6.2.3).

c) HVAC: dove è studiato il rapporto con il sistema di condizionamento/riscaldamento(sviluppato in sezione 6.2.5).


Prima di proseguire nella disamina è però importante sottolineare un ultimo aspetto relativo alleassunzioni inerenti il formalismo descrittivo utilizzato. Al fine di mantenere contenuta (e pertantoleggibile) la struttura dei vari alberi proposti è stato infatti trascurato l’apporto energetico cuiogni elemento, evidentemente, necessità. Tale assunzione, che permette di eliminare tutta unaserie di sub-goal relativi proprio a questo aspetto, ci è concessa dall’estrema attenzione data nellespecifiche a questo aspetto, sia da un punto di vista della sicurezza sul singolo cavo, sia per quantoriguarda l’interazione dei medesimi; aspetti che pertanto ci spingono a considerare l’ignoranzaassociata a tali componenti come trascurabile.

6.2.1 Emergenza: Allarme Manuale

Iniziamo la nostra disamina delle conformazioni a rischio emergenza con un caso abbastanzasemplice, ma che permetterà di apprezzare appieno il tipo di lavoro da svolgere.

La nostra attenzione si concentra in modo particolare sul sotto-albero relativo ai componen-ti “Sensore Temperatura” e “Allarme Manuale” (in figura 19 sarebbe un derivato del goal “Ri-levazioneIncendio”). Tali componenti vengono trattati contemporaneamente in conseguenza diuna particolare scelta architetturale, operata da AZ, che prevede la commistione spaziale e fisica(ottenuta tramite l’uso congiunto di opportuni componenti elettromeccanici) dei due.

Il requisito che si intende raffinare richiede pertanto la rilevazione di un incremento di tempera-tura o di una chiamata manuale, cui deve seguire la segnalazione della medesima al SRI.

Raffinamento Requisito

Figura 20: Goal Tree (basico) relativo al requisito emergente “SegnalaAllarmeSeTempAltaOManuale”.

Chiamiamo tale requisito “SegnalaAllarmeSeTempAltaOManuale”. Un primo, approssimativo,approccio ci spinge ad associare tale requisito alla responsabilità, congiunta, dei due agenti “Sen-soreTemp” e “AllManuale” (vedi figura 20 in cui gli agenti hanno forma trapezoidale e i goal sonorappresentati da rettangoli). Formalmente un simile requisito può essere scritto:


Goal: Achieve[SegnalaAllarmeSeTempAltaOManuale]InformalDef: Se viene rilevata una temperatura superiore ad una soglia

prestabilita o se viene attivato l’allarme manuale, si deveinviare un segnale di allarme alle CCU entro un tempo massimo.

FormalDef: ∀ m:AllarmeManuale, ∀ st:SensoreTempst.TempRilevata /∈ IntervalloSicurezza ∨

m.AllarmeAzionato = true⇒♦t6tmax (∀ c:CCU): c.Allarme = true

Chiaramente una simile situazione corrisponde ad un requisito irrealizzabile, in quanto né “Sen-soreTemp”, né “AllManuale” sono in grado di controllare ( siamo quindi in una condizione dilackOfControl) la variabile “Allarme” delle “CCU”. Siamo spinti pertanto a raffinare il requisi-to utilizzando un pattern tipico per gli achieve goal “SolveLackOfControlUsingMilestone” (vedifigura 21).

Tactics for Requirements Elaboration Domain-Independent Tactics

42 Reducing Goals into Subgoals

Proof.

1. P ⇒ ❍ ◊ Q Premise2. ❑ (P → ❍ ◊ Q) 1, Def ⇒3. (P → ❍ ◊ Q) ⇒ (P → (Q ∨ ❍ ◊ Q)) L14. ❑ (P → (Q ∨ ❍ ◊ Q)) 2, 3, E-MP5. ❑ (P → ◊ Q) 4, FE26. P ⇒ ◊ Q 5, def ⇒

C3:

Proof. The proof of this reduction pattern is an instantiation of the following generic proof:

where ✫ stands for ◊ or ❑.

1. P ⇒ ✫ R Premise2. R ⇒ ✫ Q Premise3. ✫ R ⇒ ✫ ✫ Q 2, ✫-monotonicity4. ✫ R ⇒ ✫ Q 3, ✫-idempotence5. P ⇒ ✫ Q 1, 4, E-TRNS

C4:

Proof.

1. P ∧ R ⇒ ◊ Q Hyp2. ❑ R Hyp3. ❑ (P ∧ R → ◊ Q) 1, def-⇒4. ❑ (¬P ∨ ¬ R ∨ ◊ Q) 3, def-→, Morgan5. ❑ (R → (P →◊ Q)) 4, commut., assoc., def-→6. R ⇒ (P →◊ Q) 5, def-⇒7. ❑ (P →◊ Q) 2, 6, E-MP8. P ⇒ ◊ Q 7, def-⇒

P ⇒ ◊ Q

P ⇒ ◊ R R ⇒ ◊ Q

P ⇒ ✫ Q

P ⇒ ✫ R R ⇒ ✫ Q

P ⇒ ◊ Q

P ∧ R ⇒ ◊ Q ❑ R

Figura 21: Pattern utilizzato per il raffinamento del goal “SegnalaAllarmeSeTempAltaOManuale”.

Il ricorso al pattern precedente scinde il goal in esame in due sub-goal, ponendo un “milestone”intermedio, aggiungendo cioè uno stadio raggiungibile dallo stato iniziale e che possa comunquepermettere di raggiungere lo stato finale. In questo caso abbiamo deciso di considerare sepa-ratamente la rilevazione dell’incendio, dalla segnalazione del medesimo, interpretando cioè larilevazione come stadio intermedio di appoggio. La nuova conformazione del goal-tree è quellaproposta in figura 22, in cui si osservano due sub-goal.

1. RilevaTempAltaOManuale: in cui si monitorano il sensore temperatura e l’allarme manuale.

2. SegnalaAllarme: che si occupa di inviare le informazioni raccolte al SRI.

L’elemento chiave, che consente di superare l’impasse precedente (“lackOfControl”) è rappresen-tato dall’introduzione dell’agente “Link”, adibito proprio all’invio della comunicazione d’emer-genza.

In teoria il raffinamento, se ci limitiamo alle regole utilizzate da KAOS, potrebbe concludersiqui.

• RilevaTempAltaOManuale: viene risolto dagli agenti “SensoreTemp” e “AllManuale”.

– SensoreTemp: può leggere la variabile “TemperaturaAlta” e può controllare “Rileva-toAllarme”.

– AllManuale: può leggere la variabile “AzionatoAllManuale” e può controllare “Rile-vatoAllarme”.

• SegnalaAllarme: è risolto dall’agente “Link”, il quale può leggere la variabile “RilevatoAl-larme” e può controllare “AllarmeIncendio”.


Figura 22: Goal Tree (primo raffinamento) relativo al requisito emergente “SegnalaAllarmeSeTempAltaO-Manuale”.

La nostra attenzione verte però sugli aspetti emergenti del sistema in esame; siamo pertanto spintiad approfondire l’analisi sino al massimo livello concessoci dai documenti in nostro possesso. Inparticolare pare interessante raffinare RilevaTempAltaOManuale, in modo da esplicitare al meglioil ruolo dei due agenti adibiti alla sua risoluzione. La nuova conformazione è quella proposta infigura 23, dove abbiamo introdotto i due sub-goal “RilevaTempAlta” e “RilevaAllManuale”. Ilraffinamento può pertanto considerarsi concluso.

Figura 23: Goal Tree (secondo raffinamento) relativo al requisito emergente “SegnalaAllarmeSeTempAl-taOManuale”.



Link ×SensoreTemp

√

AllManuale ×CxSegnalaAllarme

√

CxRilevaTempAlta√

CxRilevaAllManuale√


IntSegnalaAllarmeSe... ×SegnalaAllarme

√

RilevaTempAlta√

RilevaAllManuale√

RilevaTempAltaOMan...√

SegnalaAllarmeSe...√

Tabella 7: Tabella rappresentante la distribuzione dell’ignoranza nel goal-tree relativo al requisito“SegnalaAllarmeSeTempAltaOManuale”.

Analisi Dell’Ignoranza

La metodologia offerta da KAOS ci ha permesso di costruire un goal-tree utile a studiare l’igno-ranza connessa a questa parte del progetto. Applicheremo adesso la metodologia dettagliata neicapitoli precedenti al fine di ricercare elementi potenzialmente produttori di fenomeni emergenti.

In tabella 7 sono proposti i valori di ignoranza ottenuti dall’applicazione del metodo. Essen-do questo il primo requisito analizzato, procederemo lentamente soffermandoci su ogni passodell’analisi e cercando di chiarire al meglio le ragioni dei differenti apporti proposti.

Lo studio parte chiaramente dall’analisi del goal-tree di figura 23. In particolare la primadisamina riguarda gli agenti interessati all’operazione.


Link ×SensoreTemp

√

AllManuale ×

1. Link: l’analisi delle specifiche ribadisce l’estrema attenzione posta dai tecnici di AZ sullaqualità del collegamento tra i differenti sensori e le CCU poste agli estremi del veicolo.Normative specifiche (in particolare “UNI CEI 20-36” e “EN 50155”) garantiscono un’altaqualità dei componenti utilizzati. Inoltre, la collocazione del cablaggio e l’alto numero disituazioni considerate (ad esempio, seppur ovvi, la presenza di fuoco o di cortocircuiti), cispingono ad associare a tale costrutto un’alta copertura, ritenendo che non vi siano zone diignoranza rilevanti.

2. Sensore Temperatura: più lacunose risultano invece le direttive relative ai sensori temperatu-ra. Per questi ultimi infatti si dà grande spazio ai requisiti funzionali, dettagliando le molte


feature richieste, ma non è presente alcuna considerazione riguardo alle normative correlate(che indurrebbero un certo tipo di reliability e di documentazione correlata), né ad eventuali“contesti inusuali” in cui questi ultimi potrebbero venirsi a trovare (presenza di fumo, spor-cizia, etc.). Si è portati di conseguenza ad associare un valore di ignoranza leggermente piùalto in corrispondenza di questo elemento. Si fa notare che tale valore fa riferimento al sin-golo componente, non alla feature offerta (cioè al requisito “RilevaTempAlta”). Associareun valore di ignoranza medio o alto ad un componente implica l’associazione di tale valoread ogni requisito per cui tale agente sia responsabile: al contrario, vi saranno situazioni incui l’emergenza non è relativa ad un intero agente, ma solo ad una feature offerta da taleagente; in questi casi non assoceremo un alto valore di ignoranza al componente, ma cilimiteremo a segnalare questa situazione nel requisito interessato da tale feature.

3. Allarme Manuale: l’allarme manuale è un oggetto ampiamente discusso nelle specifiche,cui ci si riferisce peraltro con normative dettagliate (in particolare “UNI CEI 11170-2”).L’ignoranza associata pertanto sarà trascurabile.

Per quanto riguarda i contesti in cui si realizzano le differenti feature, scegliamo di associa-re una ignoranza bassa ai due requisiti “CxRilevaTempAlta” e “CxRilevaAllManuale” in conse-guenza della particolare ambientalità d’uso, che potrebbe comportare un’ingerenza umana nonpreventivabile.


CxSegnalaAllarme ×CxRilevaTempAlta

√

CxRilevaAllManuale√

Un aspetto su cui ci sono invece delle osservazioni da fare riguarda la connessione dei due requi-siti “RilevaTempAlta” e “RilevaAllManuale”, che si uniscono in “RilevaTempAltaOManuale”. Atale connessione abbiamo associato un’ignoranza media, figlia della singolare architettura scelta(accennata in precedenza). Il componente “Allarme Manuale” viene infatti utilizzato all’interno,o comunque nel medesimo spazio funzionale, del sensore temperatura. Il fatto è che, pur preven-tivando norme piuttosto rigide per la sicurezza dell’allarme, non è richiesto (al costruttore) alcunrequisito funzionale su un utilizzo di questo tipo: minor areazione dovuta allo spazio ristretto,temperature più elevate per la vicinanza di più dispositivi elettronici, etc. fanno sì che un simileutilizzo induca un’ignoranza sul funzionamento complessivo del “black-box” che dovrà conte-nere il sensore e l’allarme manuale, rendendo il relativo requisito suscettibile di funzionamentoemergente.



IntSegnalaAllarmeSe... ×

A questo punto è possibile calcolare l’emergenza associata ai differenti goal ottenendo i risultatiproposti di seguito.



SegnalaAllarme√

RilevaTempAlta√

RilevaAllManuale√

RilevaTempAltaOMan...√

SegnalaAllarmeSe...√

L’ignoranza media associata al tipo di integrazione effettuato in “RilevaTempAltaOManuale” sisomma all’ignoranza connessa al goal “RilevaTempAlta” facendo sì che al goal “RilevaTempAl-taOManuale” venga associata un’alta ignoranza e, di conseguenza, che il main goal “SegnalaAl-larmeSeTempAltaOManuale” si prefiguri come potenzialmente emergente.

Risoluzione Dell’Emergenza

Possiamo ipotizzare due politiche risolutive per l’emergenza riscontrata.Anzitutto si prefigura come essenziale l’utilizzo di specifiche maggiormente restrittive (e se

possibile standardizzate) per quanto riguarda il “Sensore Temperatura”. É indispensabile infattipoter riporre sufficiente fiducia sul corretto funzionamento del medesimo. Ove non fosse possibileottemperare alla richiesta di requisiti più restrittivi, l’alternativa sarebbe rappresentata dal ricorsoad un testing particolarmente stressante sul dispositivo, in differenti contesti e considerando anchesituazioni d’uso critiche.

Figura 24: Goal Tree (versione alternativa) relativo al requisito emergente “SegnalaAllarmeSeTempAltaO-Manuale”.

Il secondo aspetto da correggere, se possibile, riguarda la disposizione dei “Sensori Temperatu-ra” e degli “Allarmi Manuali”. In figura 24 si può osservare il goal-tree relativo al sotto-sistema


in esame, dove però sono stati, fisicamente e logicamente, separati i due componenti. Il mancatoapporto contestuale ridurrebbe l’ignoranza complessiva, facendo sì ad esempio che il grado diemergenza associato al main-goal, in questa nuova conformazione, rimanga basso.

6.2.2 Emergenza: Rilevazione Incendio

L’analisi fatta a proposito del requisito “SegnalaAllarmeSeTempAltaOManuale” ci offre uno spun-to interessante per alcune considerazioni relative ai “Sensori Fumo”. Il rapporto vigente tra idue è ovviamente molto stretto, come si può osservare in figura 25, dove viene proposta unaschematizzazione2 del requisito “RilevazioneIncendio”. In precedenza abbiamo sottolineato co-me il requisito “SegnalaAllarmeSeTempAltaOManuale” si prefiguri come potenzialmente emer-gente, palesando di conseguenza l’emergenza anche del requisito “RilevazioneIncendio”, d’altraparte tale situazione non ci può esentare dal contestualizzare anche l’apporto dato dal requisito“SegnalaAllarmeSeRilFumo”, relativo all’attività svolta dai rilevatori di fumo.

Figura 25: Goal Tree (raffinamento parziale) relativo al requisito “RilevazioneIncendio”.

Per definizione i sensori fumo devono:

• rilevare ogni tipologia di fumi;

• adattarsi alle condizioni operative per avere la massima sensibilità e non andare in falsoallarme (cercando di individuare e sopperire ad aleatorie contaminazioni);

• essere muniti di “line isolators” per evitare la perdita di segnale a causa di un corto circuitonel loop dei cavi;

2 Le linee tratteggiate indicano una catena di raffinamenti complessa di cui sono dati solo i componenti principali.


• essere muniti di protezione da insetti.

Tali requisiti, uniti alle garanzie offerte dalle normative “EN 54” (per quanto riguarda il sensorefumo) e “UNI CEI 20-36” “EN 50155” (per i cavi e le trasmissioni), ci spingono ad associare unbasso grado di ignoranza relativo al requisito “SegnalaAllarmeSeRilFumo”.

In effetti l’unica incognita in questo caso è rappresentata dalla presenza di requisiti funzionaliespressi in maniera ambigua. Ci riferiamo in particolare ad alcune espressioni caratterizzanti irilevatori di fumo, che potrebbero indurre comportamenti inattesi.

• “..ogni tipologia di fumo..”: non è assolutamente un dato oggettivo, serviranno certamentechiarimenti da parte del produttore del dispositivo, con eventuali rischi di fraintendimentocon AZ sui termini stessi del contratto.

• “..adattarsi alle condizioni operative..”: in questo caso, pur essendo la funzionalità richiestadi interesse assoluto, rimane l’incognita dettata dalle modalità realizzative di una siffattafeature. Come si rapporta il sistema al rischio di falsi negativi? Quali soluzioni verrannoadottate?

• “..aleatorie contaminazioni..”: valgono le medesime considerazioni del precedente.

Si potrebbe obiettare che quella che stiamo conducendo non sia una vera e propria analisi dell’i-gnoranza, quanto piuttosto una mera disamina della correttezza sintattico/formale dei requisiti, main effetti questo è vero ed è voluto. Anzitutto perché l’analisi dell’ignoranza non può prescindereda considerazioni sull’ambiguità espressiva dei requisiti stessi, in fondo gran parte dell’ignoranzache affligge i sistemi informativi è figlia dell’ambiguità intrinseca del linguaggio naturale. In se-condo luogo si può dire che tutti i metodi di analisi dei requisiti sviluppati negli anni “tendesserol’orecchio” al concetto di ignoranza e alla sua rilevazione, quindi è evidente che ci debbano essereaffinità.

Quella presentata è una situazione tipica in cui la disamina dell’emergenza offre indicazioni perl’esecuzione del testing. Nei documenti di AZ è previsto il ricorso al testing praticamente perogni requisito del sotto-albero in esame. D’altra parte, come abbiamo sottolineato nelle pagineprecedenti, noi non abbiamo conoscenza della natura del testing effettuato, si ritiene però che talemomento di analisi dovrebbe ritagliare uno spazio anche per la verifica degli aspetti citati.

• Si dovranno predisporre test atti a valutare la copertura dei sensori al variare della tipologiadi fumo, dando particolare enfasi alla ricerca di tutte le tipologie di fumo riscontrabili.

• Si dovrà stressare la funzionalità aggiuntiva al sensore che gli permette di individuare unfalso positivo. Tale operazione sarà ovviamente approntata in base alle specifiche offer-te dal costruttore, al fine di evitare che il sistema possa scadere in falsi negativi o possacompromettere alcune funzionalità.

6.2.3 Emergenza: Estinzione

Il prossimo requisito su cui intendiamo soffermarci riguarda la messa in funzione di un sistema dispegnimento dell’incendio (estintore) una volta rilevato il medesimo.

Dovranno essere previsti dispositivi che permettano di spegnere gli incendi rilevati nel minortempo possibile.


Nei documenti di specifica si immagina l’estintore entrare in funzione su richiesta del SRI, unavolta rilevato l’incendio. Non è presente una descrizione sufficientemente dettagliata del requisi-to, essendo la standardizzazione degli estintori considerata una fase da effettuare a valle di altreanalisi ancora da compiere. Sosterremo però che, pur nell’ottica di un requisito che dovrà essersviluppato in seguito, alcuni dettagli e alcune specificità devono essere prese in considerazionegià in questa fase, pena la definizione di un requisito potenzialmente emergente.


La rappresentazione base del requisito (vedi figura 26) è assolutamente banale, né d’altra parterisulta completa, non potendo in alcun modo (in particolare per una duplice “LackOfMonitorabi-lity”) un semplice estintore rispondere alle direttive richieste dal requisito.

Figura 26: Goal Tree (basico) relativo al requisito emergente “SpegniIncendioSeRilevato”.

Si decide pertanto di sviluppare il goal utilizzando il pattern D21 di [37], il quale determina lacreazione di tre sub-goal, così come si può osservare in tabella.

Main-Goal

P ⇒ ♦Q

Sub-Goal Sub-Goal Sub-Goal

P ⇒ ♦R P ∧ R⇒ ♦Q P ⇒ �P

L’applicazione del pattern deve essere letta come una volontà di specializzare e suddividere leresponsabilità del main-goal. I tre sub-goal sono infatti demandati a differenti agenti.

La trasformazione indotta può essere letta nel seguente modo.

• Goal Originario: P ⇒ ♦Q: data una situazione di incendio (P) l’agente associato (cioèl’estintore) deve estinguerlo (Q).

• Raffinamento:

– P ⇒ ♦R: data una situazione di incendio (P) l’agente associato (cioè CCU3) deverichiedere l’estinzione (R).

– P ∧ R ⇒ ♦Q: data una situazione di incendio e la richiesta di estinzione (P ∧ R)l’agente associato (cioè l’estintore) deve estinguerlo (Q).

– P ⇒ �P: a patto che l’incendio permanga (quest’ultima condizione è implicita edunque non viene formalizzata in un goal).


Figura 27: Goal Tree (primo raffinamento) relativo al requisito emergente “SpegniIncendioSeRilevato”.

L’applicazione del pattern produce il goal-tree rappresentato in figura 27.Una simile conformazione non è comunque sufficiente, non avendo CCU i privilegi di scrittura

sulla variabile “IncendioRilevato” dell’estintore. Tale situazione è risolta dall’applicazione delpattern già visto nel caso precedente.

Main-Goal

P ⇒ ♦Q

Sub-Goal Sub-Goal

P ⇒ ♦R R⇒ ♦Q

La specializzazione del goal “RicevoSegnale” permette di ottenere il goal-tree definitivo (pro-posto in figura 28).


Lo studio dell’ignoranza associata si basa su due considerazioni di base:

• le funzionalità richieste in questo requisito operano in un ambiente critico (essendo proba-bilmente in corso un incendio);

• non abbiamo alcun tipo di informazione sull’estintore, in particolare non abbiamo informa-zioni sulla sua diagnostica (e dunque su di un suo eventuale malfunzionamento).

Tali riscontri hanno una ricaduta assolutamente rilevate nel grado complessivo di ignoranza diquesta parte del progetto.

Osservando l’albero di figura 28 possiamo fare le osservazioni seguenti.

• Visti gli stringenti requisiti (e normative) associati riteniamo di poter fare affidamento sugliagenti “Link” e “CCU”. D’altra parte il particolare ambito d’uso (vedi “incendio in corso”)obbliga a porre una pur bassa incertezza sui relativi contesti di utilizzo (“CxComunicazione”e “CxIncendioRilevato”).

3 Per CCU in questo caso si intende l’unione delle due centraline adibite alla rilevazione e segnalazioen di incendio.


Figura 28: Goal Tree (completo) relativo al requisito emergente “SpegniIncendioSeRilevato”.

• Non abbiamo alcun tipo di informazione sull’estintore.

– In particolare non sappiamo niente della diagnostica associata, dunque non possiamonemmeno valutare consapevolmente il sua grado di affidabilità in una situazione estre-ma. É vero che, trattandosi di un estintore, ci aspettiamo un certo tipo di affidabilità,ma ci sono problematiche correlate, come ad esempio la manutenzione, che obbliganoad avere informazioni aggiuntive.

A tale elemento viene pertanto associata un’ignoranza media.

Il risultato dell’analisi, proposto in tabella 8, evidenzia un main-goal potenzialmente emergente.


In questo caso la risoluzione dell’emergenza poggia su due aspetti essenziali.

• Anzitutto è necessario arricchire la definizione di estintore. Anche laddove si intenda man-tenere una tempistica differenziata per la specifica di tale requisito (demandandola a valledi un’analisi di rischio effettuata da AB), pare comunque importante fissare alcuni elementichiave; come, ad esempio, la presenza di diagnostica.

• In secondo luogo sembra importante verificare il comportamento del sistema di comunica-zione in ambiente “estremo”. Se è vero che in particolare i cavi hanno richieste importantianche in relazione alla resistenza (pur per brevissimo periodo) ad alte temperature, è altret-tanto vero che, mentre per altri aspetti del sistema sono previsti test finali, in questo casonon si accenna ad alcun tipo di test. L’assenza è ovviamente giustificata dal fatto che ilrequisito verrà sviluppato in seguito, ai nostri occhi però un simile modo di agire è un ti-pico induttore di emergenza. Quando infatti si andrà a sviluppare il requisito scegliendo ilcomponente “estintore” si rischia di immettere un agente funzionante su di una linea su cui



Link ×CCU ×Estintore

√

IncendioRilevato√

Comunicazione√

AzionaEstintore√

CxIncendioRilevato√

CxComunicazione√

CxAzionaEstintore√

IntRicevoSegnale ×IntAzionaEstintore ×IntSpegniIncendioSe... ×RicevoSegnale

√

AzionaEstintore√

SpegniIncendioSe...√

Tabella 8: Tabella rappresentante la distribuzione dell’ignoranza nel goal-tree relativo al requisito“SpegniIncendioSeRilevato”.

facciamo affidamento “alla cieca”. Al contrario, preventivare già in questa fase un test attoa valutare l’avvenuta trasmissione del segnale anche in condizioni critiche, pare un modoper approntare un’analisi davvero completa.

6.2.4 Emergenza: PTU

La trattazione proseguirà adesso analizzando un componente quasi assestante del SRI: il Porta-ble Test Unit (PTU), consistente in un computer portatile da collegare alle CCU per operazionidi diagnostica. Peraltro sottolineiamo come da qui in avanti cercheremo di accelerare l’analisiassumendo come apprese certe tecniche e dunque sottintendendo alcuni passaggi.

In questo caso l’incognita è rappresentata dal PTU stesso.

L’applicazione PTU (Portable Test Unit) deve poter essere eseguita su di un normale computerportatile dotato di sistema operativo Windows XP o superiore. Per il collegamento tra il

computer e la centralina di controllo deve essere utilizzato un sistema di connessione che verràdefinito in fase successiva tra AZ e Fornitore.


Il requisito può essere raffinato come proposto in figura 29. In realtà il goal-tree dato è evidente-mente parziale, in quanto non vengono esplicitati né l’apporto dato dalla diagnostica del SRI (lacui natura verrà esaminata in dettaglio nel seguito - vedi sezione 6.2.6), né il sub-tree relativo algoal “Check” (da qui l’utilizzo dei connettori tratteggiati). L’assenza di questi aspetti è figlia dellanostra volontà di concentrare l’analisi su un singolo aspetto chiave: l’affidabilità del PTU.


Figura 29: Goal Tree (parziale) relativo al requisito emergente “CheckPTU”.

I software di appoggio del SRI devono, come da specifiche, essere tutti di tipo Sil1. Ovviamentetale richiesta si riferisce ai software interni al sistema (come quelli operanti nelle CCU), ma nonpuò essere estesa a quelli agenti su un componente come la PTU. D’altra parte nelle specifiche disistema non si fa riferimento ad alcun tipo di garanzia che tale agente deve fornire.

Senza bisogno di dettagliare il goal-tree nella sua interezza, diventa pertanto evidente la presen-za di almeno due elementi critici (vedi tabella 9):

1. il PTU stesso;

2. la connessione del medesimo con il sistema.

Il sistema deficita in sostanza sia di requisiti sul singolo PTU, sia di opportune garanzie sullaconnessione.

• Sia da un punto di vista fisico: come la robustezza a tensioni di corrente inattese, correlate,ad esempio, ad un fallimento della PTU.

• Sia dal lato software: dove si dovrebbe palesare meglio il rapporto con il software internoal SRI.


Anche in questo caso si ritiene corretto lavorare su due aspetti.

1. Anzitutto prevedere requisiti specifici atti a regolare la natura delle comunicazioni tra PTUe CCU. In questo modo si cerca di diminuire eventuali “influenze” negative del PTU sul-l’apparato software del SRI.



PTU_os√

Link√

PTU_diagn√

...CheckPTU

√

Tabella 9: Tabella (parziale) rappresentante la distribuzione dell’ignoranza nel goal-tree relativo alrequisito “CheckPTU”.

2. In secondo luogo si ritiene doveroso approntare una tipologia di test specifici, utili perverificare l’assenza delle influenze di cui sopra.

6.2.5 Emergenza: HVAC

Considerazioni analoghe a quelle proposte per “PTU” ed “Estintori” valgono anche per l’apparatoHVAC. Si nota anche in questo caso tutta una serie di informazioni mancanti che, al contrario, di-vengono essenziali laddove si voglia qualificare in senso positivo o negativo l’ignoranza associataal goal “ChiudiHVAC”.

Il sotto-sistema in esame finisce dunque per essere caratterizzato da una serie di domande senzarisposta.

• L’apparato HVAC è dotato di un qualche sistema di diagnostica? Possiamo quindi riporrefiducia sul suo corretto funzionamento, laddove si invii un segnale “ChiudiTutto”, oppurenon abbiamo certezze in tal senso?

• Che tipo di requisiti caratterizzano il collegamento tra HVAC e CCU?

– Sia da un punto di vista dell’affidabilità del medesimo in condizioni critiche.

– Sia per quanto riguarda l’isolamento meccanico/energetico (cortocircuiti, etc.).


Anche in questo caso la risoluzione del goal potenzialmente emergente avviene tramite il ricorsoa requisiti di specializzazione e sicurezza. É indispensabile effettuare alcune richieste minimesul tipo di servizio offerto dal HVAC. Particolarmente interessante pare ai nostri occhi il ricorsoa componenti capaci di diagnosticare un eventuale malfunzionamento; in una siffatta situazionesi potrebbe peraltro pensare di richiedere che il sistema HVAC si sposti automaticamente in uno“stato sicuro”, impostando ad esempio la chiusura dei condotti di areazione.

Prendiamo spunto dall’analisi attuale per sottolineare un aspetto interessante. Evidentementeall’analisi condotta si potrebbe obiettare un errore di sostanza: il fatto cioè che l’apparato di ri-scaldamento/condizionamento di una linea metropolitana con i requisiti di sicurezza descritti inprecedenza sia certamente ottimale, sia come reliability, sia da un punto di vista della sicurezza


correlata. Si potrebbe in sostanza sottintendere che ipotizzare un malfunzionamento così macro-scopico, in un’architettura studiata e raffinata sin nei dettagli, sia un mero gioco dialettico. E inrealtà in parte è così, nemmeno noi ci aspettiamo sensatamente che il sistema HVAC presenti falledella natura di quelle appena supposte, ma questa non è una giustificazione sufficiente per esimer-si dall’analisi fatta: un simile presupposto logico è anzi una delle ragioni che spesso sottostannoalla manifestazione di fenomeni emergenti.

Al contrario la linea di ragionamento adottata negli esempi proposti porta due grossi vantaggi.

1. Anzitutto prende in considerazione, e permette di risolvere, aspetti che, per quanto impro-babili, possono comunque accadere.

2. In secondo luogo permette di formalizzare aree progettuali scevre da ignoranza, le quali,una volta inserite in un contesto più ampio, tenderanno a non generare eventi emergenti.Nel progetto in corso, nonostante la sua bontà, si ha l’impressione di dover maneggiaresotto-sistemi (HVAC, estinzione, etc.) contenenti “black area”; un tipo di approccio alla REche, come abbiamo ribadito più volte, deve essere considerato assolutamente deprecabile.

6.2.6 Emergenza: Diagnostica

Vogliamo adesso sfruttare quello che ai nostri occhi appare come un requisito a rischio emer-genza per fare alcuni ragionamenti in merito alle tipiche modalità di elaborazione dei requisiti eall’apporto che, al contrario, può dare, soprattutto in termini di immediatezza e duttilità, la nostraproposta.

Analizzeremo in particolare la diagnostica del SRI e mostreremo come quello che potrebbeapparire a prima vista un insieme di requisiti ben sviluppati, nasconda, al contrario, una lacunapotenzialmente pericolosa.


La diagnostica di sistema può essere riassunta con i due seguenti requisiti, relativi rispettivamenteal “Sensore Fumo” e al “Sensore Temperatura”.

[Sensore Fumo]: Il valore di ciascun elemento, misurato ai capi della linea sensori fumo, viene elaborato in modotale che in funzione delle curve di riferimento (taratura e compensazione), possa essere stabilito lo stato di

funzionamento del sensore rilevando uno dei seguenti stati:

• Funzionamento normale;

• Necessità di manutenzione;

• Stato di allarme, pre-allarme;

• Stato di guasto;

• Mancanza di sensore;

• Valore analogico.

[Sensore Temperatura]: Le linee di rilevazione di Sovra-temperatura e di chiamata manuale passeggero, vengonomonitorate in modo tale che possano essere rilevati i seguenti stati:

• Funzionamento normale;

• Necessità di manutenzione;

• Stato di allarme;


• Stato di guasto.

Si può dunque procedere, supposta la presenza di sensori che rispondano ai requisiti dati, allosviluppo dei goal-tree relativi ai due requisiti, ottenendo gli alberi proposti in figura 30.

Figura 30: Goal-Tree relativi ai requisiti “DiagnFumo” e “DiagnTemp&Manuale”.

La prima osservazione, spontanea, che si potrebbe addurre riguarda la presenza dell’agente in-cognito in riferimento al goal “DiagnManuale”. Tale notazione è stata utilizzata per rappresentareil fatto che non è prevista diagnosi per il pulsante di allarme manuale. Nonostante le, pur interes-santi, considerazioni che si potrebbero fare su tale mancanza (e quindi sul tipo di comportamentoe di QoS in una simile situazione), preferiamo non investigare oltre tale mancanza, preferendoconcentrarci su altri aspetti.

Dati i due goal-tree appena visti, è naturale formalizzare il main-goal “Rileva&ComunicaDiagnostica”,come la summa dei precedenti, ottenendo l’albero di figura 31.


L’analisi dell’ignoranza associata (vedi tabella 10) si basa sulle considerazioni seguenti.

• Già in precedenza abbiamo proposto (in particolare analizzando il requisito in sezione 6.2.1)alcune considerazioni riguardo le comunicazioni e, in generale, le attività “accessorie” ad unsingolo componente (fornitura energetica, fissaggio, etc.). In particolare è stata sottolineatala bontà, intesa come ricchezza di feature richieste e come copertura di eventi indesiderati,dell’analisi fatta da AZ e, in ultima analisi, la scarsa presenza di ignoranza in relazione aicavi di comunicazione.

• Considerazioni sui sensori sono già state fatte in precedenza.

• I componenti sono supposti essere capaci di auto-diagnosticarsi, si può pertanto realistica-mente riporre fiducia sul loro corretto funzionamento.

• L’unico aspetto che può inficiare un corretto funzionamento è rappresentato dal contesto diutilizzo: l’apporto umano è capace di produrre una mole considerevole di situazioni inattese,oltre che danneggiare direttamente i medesimi.


Figura 31: Goal-Tree relativo all’intero requisito emergente “Rileva&ComunicaDiagnostica”.

Applicando le semplici regole di correlazione e seguendo il goal-tree di figura 31 si può affermare(vedi risultato della tabella 10) che il main-goal “Rileva&ComunicaDiagnostica” non è caratteriz-zato da un livello di ignoranza rilevante, risultato peraltro assolutamente atteso vista la presenzadi pochi caratteri ignoti, peraltro neppure troppo rilevanti.

Eppure cambiando prospettiva si ottengono risultati decisamente più significativi. Il punto èche nell’effettuare la precedente analisi abbiamo seguito i ben noti binari di una tipica disaminadei requisiti, in cui l’approccio bottom-up ha permesso di focalizzare l’attenzione su specificicomponenti, per poi correlarli assieme secondo le direttive date nelle specifiche. Nel capitolo3 abbiamo affrontato in più di un’occasione il rapporto tra RE e strategia top-down/bottom-up,sottolineando come il limite maggiore di quest’ultima politica fosse rappresentato da una visioned’insieme deficiente che rischia di perdere alcuni aspetti essenziali. In questo caso tale difettodiventa evidente.

Se infatti fossimo partiti, come prevede un’analisi che segua le tipiche regole di KAOS, dai re-quisiti per formalizzare il main-goal e poi specializzarlo nei relativi sub-goal, avremmo notato unaspetto essenziale: la differente diagnosi richiesta al SRI, rispetto a quella richiesta ai componenti.Di fatto il main-goal richiede due tipologie di auto-diagnosi:

1. diagnostica del sistema al momento del boot;

2. auto-diagnosi del sistema a run-time.

Laddove, invece, i requisiti funzionali dei sensori si limitano a parlare di un sensore capace, ge-nericamente, di qualificare il proprio stato. A nostro modo di vedere una simile difformità è unesempio tipico di ignoranza induttrice di un comportamento emergente: quali garanzie ho che isensori siano in grado di rispondere correttamente ad un SRI che, ad esempio, effettua rilevazioni



SensoreFumo ×LinkFumo ×SensoreTemp

√

LinkTemp ×CxDiagnSensFumo

√

CxComunicaDiagnFumo ×CxDiagnSensTemp

√

CxComunicaDiagnTemp ×IntDiagnTemp ×IntDiagnFumo ×IntDiagnTemp&Manuale ×IntRileva&ComunicaDiagn... ×DiagnTemp

√

DiagnFumo√

DiagnTemp&Manuale√

Rileva&ComunicaDiagn...√

Tabella 10: Tabella rappresentante la distribuzione dell’ignoranza nel goal-tree relativo al requisito“Rileva&ComunicaDiagnostica”.

di stato continue? Ci sono rischi di over-load? Oppure i sensori rispondono correttamente, garan-tendo un monitoraggio continuo? In pratica la conformazione logica del sistema muta prevedendoper ogni componente fisico due strutture logiche, di cui:

• la prima, relativa alla diagnosi di boot, non induce ignoranza, essendo il suo comportamentopienamente specificato nei documenti;

• la seconda, relativa alla diagnosi real-time, comporta un’ignoranza non trascurabile.

In figura 32 si può osservare un goal-tree utile a far comprendere meglio il problema. In questanuova conformazione, a fronte di un’identica ignoranza associata ai componenti, le feature relativeal comportamento in real-time sarebbero caratterizzate da un’ignoranza maggiore.


DiagnBootFumo√

DiagnBootTemp√

DiagnFumoRT√

DiagnTempRT√

Situazione che indurrebbe ovviamente la rilevazione di un parent-goal emergente e, di conse-guenza, di un main-goal emergente.


Figura 32: Pseudo Goal-Tree relativo all’intero requisito emergente “Rileva&ComunicaDiagnostica”,considerando l’incognita indotta dalla diagnostica real-time.


DiagnosticaRealTime√

Rileva&ComunicaDiagn..√


In questo caso è banale proporre una tecnica risolutiva, è sufficiente infatti livellare le due defini-zioni di diagnostica per riportare la tabella ai valori precedenti, evitando a monte il rilevamento diun goal emergente.

L’esempio proposto, al di là del risultato ottenuto, raggiungibile comunque con altre tecnichedi analisi dei requisiti, è servito per mostrare la necessità di un formalismo univoco di tipo top-down per approcciare la RE. Un errore come quello descritto nella prima parte non è infatti daconsiderarsi come un’evenienza sporadica e, d’altra parte, esso ha ripercussioni, soprattutto intermini di costi, assolutamente rilevanti per l’intero progetto. La nostra metodologia, al contrario,ha permesso l’identificazione dell’incongruenza in modo assolutamente immediato.


L’analisi condotta, nonostante la non idealità del caso di studio, ha offerto diversi spunti d’interes-se.

Anzitutto è stato possibile osservare “all’opera” il metodo di studio proposto, permettendo ditoccare con mano le tecniche sottese e di apprezzarne il funzionamento generale. In tal senso ilmetodo ha mostrato una duttilità e una immediatezza assolutamente rilevanti, soprattutto se lo si


confronta con le tipiche tecniche di analisi dei requisiti molto più focalizzate e, nonostante ciò,più complesse, sia in termini di costi applicativi che di tempi correlati.

Certamente il risultato di maggior rilievo è rappresentato dall’individuazione di alcuni “nodid’ignoranza” che, nonostante l’analisi di AZ, permangono nel progetto del SRI. É chiaro, e que-st’aspetto è già stato sottolineato in precedenza, che le debolezze riscontrate costituiscono aspettisolo relativamente critici, essendo comunque inseriti in un contesto di assoluta bontà e di stringen-te sicurezza. Nonostante ciò gli approcci risolutivi consigliati potrebbero costituire un interessanteorizzonte di lavoro per AZ, prefigurandosi come un presupposto imprescindibile per sviluppareun sistema sempre più perfezionato.

Peraltro l’analisi condotta non esaurisce il suo apporto nella mera individuazione di tali debo-lezze, ma, e anzi questo rappresenta un aspetto altrettanto qualificante, garantisce una mappaturadei requisiti di assoluto interesse. Si pensi in tal senso al contributo di tali informazioni nell’otticadel rilevamento di un malfunzionamento.

Come abbiamo accennato in precedenza, la natura del caso di studio non permette di avereinformazioni sui test condotti, né sull’eventuale manifestazione di insorgenze emergenti durantel’utilizzo del sistema; possiamo però fare delle supposizioni. Ipotizziamo, ad esempio, che in fasedi test (o dopo un utilizzo più o meno lungo) si sia rilevato un comportamento erroneo del sistemadi diagnostica, il quale cessa di funzionare oppure offre informazioni erronee. I tipici passi chesi succederebbero in un caso del genere vedrebbero la scomposizione del sistema di diagnosticanei suoi componenti elementari, seguita da un test su ogni componente; con il rischio, magari,di non rilevare alcunché in quanto il guasto potrebbe manifestarsi solo con i dispositivi collegatie dopo un tempo di utilizzo non breve. Al contrario, nella nostra disamina quest’aspetto è statoconsiderato e, se non corretto, almeno registrato.

Stesso discorso si può fare per un malfunzionamento a livello della componentistica di rileva-mento incendio. Anche in questo caso l’albero sviluppato in sezione 6.2.2 permette di additare im-mediatamente l’integrazione tra “allarme manuale” e “sensore temperatura” come probabile causa,con la possibilità peraltro di proseguire nella lista dei “sospetti” verificando poi l’inquinamentoambientale dato dal particolare contesto, etc.

Concludendo possiamo ritenerci soddisfatti di un’analisi che, a discapito delle difficoltà date dalcaso di studio, ha certamente permesso, con una mole di lavoro certamente non eccessiva vista lacriticità del sistema, di incrementare la qualità del progetto in esame, riducendo significativamentel’ignoranza sottesa.

Capitolo 7Commercial Off The Shelf

“You can add up the partsbut you won’t have the sum.”

(Anthem) Leonard Cohen

La trattazione sin qui condotta ha cercato di introdurre il concetto di emergenza in informatica,cercando di mostrare come la nuova presa di coscienza possa migliorare la RE di un sistemae in che modo lo studio di accadimenti inattesi possa essere previsto o, quantomeno, tenuto inconsiderazione. Ci siamo per adesso comunque mantenuti nell’ottica di una disamina generale, ilcui interesse era quello di fissare i capisaldi di un principio a nostro parere troppo trascurato.

Il capitolo attuale intende superare quest’accezione generica per concentrarsi su di un ambi-to applicativo cruciale nell’informatica moderna: quello dei componenti Commmercial Off-The-Shelf (COTS). I COTS possiedono infatti caratteristiche peculiari che li rendono naturali induttoridi fenomeni emergenti. La disamina di tali agenti, e in particolare la loro selezione, permette-rà di palesare compiutamente l’importanza di un’analisi incentrata sugli aspetti emergenti di uncomponente (o di un sistema).

La trattazione approccerà anzitutto, sezione 7.1, il concetto di COTS, cercando di puntualizza-re i pregi e i difetti correlati all’adozione di tali soluzioni. Mostreremo poi, sezione 7.2, comein questo particolare ambito le problematiche di emergenza non rappresentino un concetto lato,ma debbano essere intese come una vera e propria metrica di cui tener conto al momento dellaselezione iniziale. Introdurremo in un secondo tempo il concetto di Web Service, sezione 7.3,che ci consentirà di osservare soluzioni d’interesse per lo studio attuale. Soluzioni che verrannorilette, assieme ad altre proposte proprie, in sezione 7.4, dove offriremo alcune linee guida perarricchire la definizione dei COTS, al fine di ridurre le evenienze emergenti. Infine, in sezione 7.5,applicheremo le linee operative esposte nel capitolo ad alcuni casi di studio elementari al fine diesemplificare l’apporto dato da un’analisi dell’ignoranza alla fase di selezione tra COTS.

7.1 I L R I C O R S O A C O M P O N E N T I C OT S

Alla base del diffuso ricorso ai COTS [60] [61] [62] osservato negli ultimi anni vi è la speranza chesistemi (generalmente software) component-based sempre più grandi e complessi possano essere

135

136 C O M M E R C I A L O F F T H E S H E L F

Vantaggi SvantaggiImmediatamente disponibile Ritardi nell’ottenimento delle proprietà intellettualiSviluppo del sistema più economico Costi di manutenzione altiSistema ricco di funzionalità Reliability sconosciuta o inadeguata: poca scalabilitàUso massivo, tecnologie mature Limitazioni sull’efficienzaUpgrades frequenti Nessun controllo sugli upgradesSupporto dedicato da parte del vendors Dipendenza totale dal vendorsIndipendenza hardware/Software Integrazione non banale: incompatibilità tra vendors

Tabella 11: Breve sintesi dei principali vantaggi e svantaggi ottenibili dall’adozione di componenti COTS.

sviluppati in modo ragionevolmente veloce e facile utilizzando blocchi (software) pre-costituiti; iCOTS appunto.

Non esiste una definizione universalmente accettata di COTS; si può realisticamente dire cheogni gruppo di lavoro ha un’idea leggermente differente di tale concetto, che si differenzia perambito applicativo, tecniche di sviluppo adottate per crearlo, conoscenza dei suoi meccanismi in-terni, evoluzione, etc., tanto che le varie specializzazioni presenti in letteratura sono innumerevolie, purtroppo, non sempre dai contorni ben definiti [63]. Per gli scopi di questa analisi adotteremola definizione di COTS contenuta in [64]:

Un prodotto COTS è un blocco software disponibile in commercio, o open source, che altriprogettisti software possono riusare e integrare nei loro prodotti.

L’adozione di un simile approccio alla progettazione dei sistemi ha avuto un’accettazione tale daparte dei progettisti che, ad oggi, si ritiene [65] che più del 99% delle istruzioni eseguite su di uncalcolatore provengano da prodotti COTS.

Progettare, ma anche analizzare in un secondo momento, sistemi di questo tipo comporta tuttauna serie di problematiche di non facile risoluzione, legate principalmente alla scarsa (o meglionulla) trasparenza di tali oggetti. Fondamentalmente un componente COTS è una scatola nera[66] che offre feature; gli utilizzatori, a meno di codice open source, non hanno accesso al codicesorgente e lo sviluppatore è l’unico controllore del suo sviluppo, attuale o futuro.

Descriveremo nel dettaglio le problematiche correlate all’adozione di COTS nel prossimo pa-ragrafo; si capisce comunque già da questa prima breve descrizione come il grado di conoscenzache il progettista possiede su tali componenti è molto basso: mancanza di indicazioni dettagliatesul contesto di utilizzo, sulle peculiarità delle feature offerte e sul grado di correlazione rispettoad altri COTS rappresentano un terreno fertile dove l’emergenza si manifesta nella sua massimaespressione, divenendo problema quotidiano. Nonostante ciò tale concetto viene sostanzialmentetrascurato nei differenti momenti di analisi dei componenti, anche, e questa carenza appare comela più rimarchevole, laddove si vadano a mettere in atto tecniche di selezione tra componenti.

Prima di concentrarci sulle problematiche indotte e sulle possibili soluzioni, è importante fissarealcune nozioni, e peculiarità, di base che caratterizzano il ricorso a COTS.

7.1.1 Il Ricorso A Componenti COTS: Una Soluzione Plug & Pray?

Lo sviluppo di COTS Based Systems (CBS) comporta tutta una serie di vantaggi (si osservi laTabella 11 [67] per un elenco dei principali) irrinunciabili al giorno d’oggi. Spesso si è infatti

7.1 I L R I C O R S O A C O M P O N E N T I C OT S 137

costretti a sottostare a limitatezze, temporali ed economiche, che impediscono a priori di pensaredi sviluppare per conto proprio certe feature, senza contare eventuali problematiche di sviluppofuturo e di supporto interamente demandate ai vendors. D’altro canto un simile approccio non èovviamente una soluzione scevra di inconvenienti [68], aspetto che spesso non è tenuto sufficiente-mente in considerazione: alti costi di manutenzione, incompatibilità tra componenti, dipendenzadai vendors, sono tutti aspetti che cedono il passo alla necessità iniziale di sviluppare un sistemafunzionante in breve tempo.

Osserviamo nel dettaglio alcune deficienze tipiche dei CBS (gli esempi sono ripresi da [65][67] [63]) per capire meglio la sostanza del problema.

1. L’incremento, spesso selvaggio, di feature all’interno di un prodotto è prima di tutto unanecessità economica per un vendor, ma introduce ovviamente un crescente aumento dellacomplessità del prodotto stesso.

a) Più della metà delle feature presenti in COTS di grandi dimensioni rimane inutilizzato.

2. Ogni istruzione è verificata tramite un market test for value, cioè una verifica a livello disistema e non dell’istruzione stessa: si prova cioè che una certa feature è offerta in contestipredefiniti e non si verifica la correttezza della singola istruzione.

3. Il progettista non ha alcun controllo sull’evoluzione di un prodotto COTS.

a) Un software COTS mediamente presenta una nuova release ogni nove mesi, consupporto da parte del vendor solo per le ultime tre release.

4. La maggior parte dei prodotti COTS non sono pensati per inter-operare reciprocamente.

5. I costi di manutenzione e di evoluzione di un CBS eccedono quelli di progettazione erealizzazione.

6. Le singole capacità e l’esperienza del progettista rimangono in questo ambito fattori domi-nanti per lo sviluppo di un CBS efficace.

a) Sviluppare CBS rimane a tutt’oggi un processo rischioso.

Abbiamo cercato di raccogliere in questo elenco le principali peculiarità dei COTS che induco-no ignoranza. Un prodotto che si caratterizza per una moltitudine di feature, soprattutto se talifunzionalità non sono verificate in maniera assestante, sottintende un sub-strato caratterizzato dapericolose approssimazioni e problematiche di correlazione assolutamente non approfondite. Lemodalità stesse di utilizzo dei COTS poi sono potenziali fonti di errore: la rilevanza quantitativadelle feature è generalmente caratteristica d’interesse; d’altra parte induce il cliente, che solita-mente richiama un sub-set limitato di tali funzioni, ad utilizzarne alcune in modo approssimativoe, dunque, potenzialmente induttore di comportamenti emergenti. Non vogliamo con ciò sostene-re che i prodotti COTS siano strutturalmente deboli o debbano essere approssimati a contenitori dierrori (le tecniche di validazione e analisi di tali componenti [69] sono, al contrario, spesso moltovalide). Quello che si intende sottolineare è l’assenza, inevitabile per certi versi, colpevole peraltri, di un’analisi più ampia che legga il componente non come un’isola, ma come un elementodi un contesto allargato.

Sul medesimo solco si colloca anche l’affermazione 3 relativa all’evoluzione dei COTS. Sonoprodotti che intrinsecamente evolvono molto rapidamente [70]; peraltro spesso per risoluzione


di bug o aggiunta di funzionalità, senza una rilettura organica dell’intero framework. Così fa-cendo appare evidente l’incremento delle dark area, regioni di ignoranza presenti nel progettoprincipalmente come conseguenza di correlazioni inattese.

I concetti esposti sin ora si riassumono nell’affermazione 4, emblematica di tutta la trattazione,in cui si sottolinea come viga la totale, seppur ovvia e giustificabile, assenza di comunicazionee apertura tra i vari vendors: lo scopo è realizzare un prodotto che offra le funzionalità pensate,la sua collocazione e integrazione nel mondo reale rimane fondamentalmente un problema delprogettista (da cui le affermazioni 6 e 6.a). Al momento dell’integrazione dei differenti COTS,ma le medesime considerazioni valgono a livello dell’intero framework [71], si manifestano diconseguenza una moltitudine di comportamenti inattesi [72] [73] tutti identificabili come compor-tamenti tipicamente emergenti. Anche perché lo sviluppo delle migliori tecniche di integrazionerichiederebbe la conoscenza del source code [74], che invece nei COTS è raramente disponibile.Un esempio tipico di fenomeno emergente manifestatosi come conseguenza di un’errata integra-zione di componenti è il fallimento della missione Arianne 5, esploso, nel Giugno del 1996, circaun minuto dopo il lancio [69]. La commissione d’indagine accertò che la deflagrazione fu causatadalla presenza di software originariamente sviluppato per l’Arianne 4 e re-introdotto, senza untesting opportuno, sulla nuova missione. L’assunzione, evidentemente errata, fu che non c’eranostati sufficienti cambiamenti nel progetto per giustificare una nuova serie di test su un componen-te che la pratica aveva deciso funzionare perfettamente. L’incidente dell’Arianne 5 è esemplare eribadisce come il contesto sia un parametro irrinunciabile per giudicare la bontà di un componente.

L’emergenza diviene allora un carattere peculiare dei CBS, che non solo non si può evitare, mada cui è anche probabilmente errato cercare di prescindere. Un esempio di questa linea di pensie-ro è rappresentato da ArchWare [66], un framework per lo studio dell’interazione dei componentiin CBS e dell’evoluzione di tale interazione nel tempo (supponendo upgrade software). In taleframework infatti la possibilità che si verifichino interazioni emergenti non solo viene contem-plata, ma è intesa come inevitabile, tanto che sono preposte tecniche apposite per includere talievenienze al fine di rappresentare più compiutamente l’evoluzione del prodotto.

La realtà dei fatti dimostra che il ricorso a COTS sta divenendo processo ineluttabile nell’otticadello sviluppo di sistemi complessi; resta da capire se e come una disamina maggiormente coscien-te, magari corroborata dal ricorso ad informazioni addizionali, possa ridurre la manifestazione difenomeni emergenti nei CBS.

7.2 L’ E M E R G E N Z A C O M E M E T R I C A D I VA L U TA Z I O N E D E I

C OT S

Il primo aspetto che tratteremo nella nostra disamina dei CBS riguarda il momento di selezione deicomponenti. Il task è evidente: dati certi requisiti funzionali che vogliamo soddisfatti, si ricercail componente, o l’insieme di componenti, che, oltre a soddisfare tali desiderata, si conformacome preferibile per quello specifico sistema. Il sempre più diffuso ricorso a software e hardwarecommerciali ha difatti reso l’attività di selezione un momento cruciale nel ciclo di sviluppo di unprodotto. D’altra parte, come si può intuire anche dalle considerazioni precedenti, selezionare ilCOTS più appropriato non è un task elementare, dovendo tenere in considerazione una moltitudinedi aspetti, ognuno a suo modo importante.

Una soluzione triviale al problema [75] è rappresentata dal semplice ricorso all’esperienza e

7.2 L’ E M E R G E N Z A C O M E M E T R I C A D I VA L U TA Z I O N E D E I C OT S 139

all’intuizione del decision maker di un progetto; pur essendo una soluzione ovviamente limitata,questa rappresenta tutt’oggi l’approccio più frequente, per immediatezza, tempi di esecuzione eassenza di costi indotti. Appare evidente comunque come tale soluzione, troppo soggettiva, siadeprecabile nel contesto di progetti ampi o cruciali.

La letteratura offre una moltitudine di soluzioni adottabili per risolvere il task in esame, ognunafocalizzata su specifici aspetti del problema o orientata su un certo ambito d’uso. Non è nostro inte-resse effettuare una survey delle differenti tecniche [61] [72] [76], cercheremo invece di mostrarecome le considerazioni fatte sul concetto di emergenza si innestino in questo ambito e indichinola necessità di un momento di analisi, precedente alla selezione tra COTS, utile per diminuire ilgrado di emergenza globale del processo. Prima di entrare nel cuore della trattazione proponiamouna breve digressione assestante, utile a puntualizzare alcuni aspetti d’interesse.

Adeguarsi Ai COTS

L’analisi della letteratura inerente gli argomenti di discussione ha mostrato come sussistano fon-damentalmente due politiche tipiche: la selezione di un componente che copra tutte le nostrenecessità oppure, dati certi requisiti, l’ottenimento di un equilibrio tra costo del componente ela sua capacità di coprire il maggior numero possibile di requisiti. Nel nostro lavoro ci concen-treremo sul primo caso. La puntualizzazione può apparire triviale, ma non è affatto scontata secorrelata ad alcuni ambiti d’uso in cui si fa un forte ricorso a componenti off-the-shelf. Il punto èche talvolta, per ragioni legate essenzialmente al risparmio indotto, si è costretti ad effettuare unaRE anomala, in cui i requisiti devono obbligatoriamente piegarsi alle limitazioni indotte dai COTS.Progetti in cui bound economici hanno il sopravvento sono infatti costretti ad adottare soluzionicommerciali che non coprono l’intera gamma delle feature richieste, obbligando il progettista aridisegnare il vocabolario dei requisiti rinunciando o rileggendone alcuni. In questo contesto siinseriscono alcune soluzioni [77] [61] [62] che aiutano a capire, dato un insieme di COTS, qualescelta copra il maggior numero di feature desiderate. Particolarmente interessante in tal senso,soprattutto in relazione all’utilizzo di un framework come KAOS, è la soluzione indicata in [62]in quanto tiene conto di un aspetto sin ora tralasciato: il ricorso ad un approccio di tipo GOREper effettuare la selezione tra COTS. Tale scelta è figlia della necessità di avere differenti livellidi lettura dei requirement del progetto; un approccio tramite goal è implicitamente gerarchico epermette dunque di ottenere tali livelli in modo naturale. In quest’ottica è interessante osserva-re come l’albero costruito da KAOS potrebbe essere utilizzato per effettuare una selezione tracomponenti off-the-shelf. In generale quella appena proposta è un’inversione di prospettiva cheesula dai nostri interessi specifici e contrasta in parte con le considerazioni fatte nel capitolo 2,dove i componenti erano gli assiomi di partenza su cui costruire l’albero. Le considerazioni cheoffriremo nel seguito sono comunque valide indipendentemente dalla politica adottata e fannoriferimento a condizioni che sono alla base del processo stesso di selezione.

7.2.1 La Selezione Tra COTS Come Problema di Emergenza

Un approccio tipico, tanto da essere considerato uno standard, allo sviluppo di una tecnica diselezione è Procurement-Oriented Requirements Engineering (PORE [78]) che indica le fasi cheun team di sviluppo dovrebbe seguire dall’acquisizione dei requisiti hardware sino alla selezionedei componenti COTS che li soddisfino. Le macro-tappe di PORE possono essere riassunte in:

1. acquisizione dei requisiti desiderati dal cliente;


2. selezione di un criterio di decision-making per identificare i giusti candidati;

3. eliminazione dei candidati che non soddisfano alcuni requisiti;

4. esplorazione dei candidati rimanenti con possibile raffinamento dei requisiti iniziali.

Appare evidente come anche in questo caso si parta da un assunto azzardato, cioè che i candidatisiano espressi compiutamente e in modo disambiguo.

L’articolo di Cechich et al. [61] ci offre un ottimo spunto per entrare nel cuore della trattazione.Gli autori propongono infatti una survey delle principali tecniche di selezione che pone l’atten-zione sulle modalità di rappresentazione dei componenti stessi. Il fatto è che, indipendentementedalla tecnica di selezione adottabile, tutto il processo di analisi e selezione si svolge basandosisu una valutazione dei singoli COTS che altro non è se non un’idea che ci si può esser fatti delcomponente, idea che spesso è ambigua e incompleta. Senza contare l’eterogeneità descrittivache caratterizza i differenti vendors, che, anche per motivi di marketing e di mercato di riferimen-to, pongono l’attenzione su certi aspetti piuttosto che su altri. In [73] gli autori immaginano lapresenza di uno scambio di informazioni tra vendors e clienti per ovviare a questi problemi; le in-formazioni potrebbero riguardare l’interfaccia, i pre-requisiti, il livello middleware supposto, etc.La soluzione non interessa lo studio attuale (in cui non si prende in considerazione la possibilitàche il vendor aiuti il progettista guidandolo in alcune scelte cardine), ma sottolinea come spesso lescelte effettuate in un siffatto contesto siano preludio alla definizione di un’architettura dalle basitroppo deboli, naturalmente tendente a scadere in evenienze emergenti. Se, come abbiamo osser-vato in precedenza, i componenti COTS sono portatori naturali di ignoranza, ovviare in un’analisidei medesimi ad una più completa fase di esplorazione dei dati, che tenga conto dell’ignoranzaimplicita, appare un errore decisivo nella qualità dello studio condotto: un’analisi dei COTS devetenere in considerazione l’ignoranza associata e, di conseguenza, le possibili risultanze emergenti.

Fondamentalmente ogni tecnica di selezione sviluppa un proprio vocabolario di definizione deicomponenti, focalizzato sulle specialità d’interesse per quella particolare tecnica: si osservanoin tal senso approcci che sottolineano gli aspetti legati ai costi, quelli che analizzano il rapportocon il numero di utenti e con la customizzazione del dispositivo, etc. Il fatto è che i vendorsnon potendo adeguarsi a tutti i differenti stili descrittivi ovviano il problema proponendone unoproprio. Ciò fa sì che la distanza tra le informazioni richieste dalle tecniche di selezione e quelledisponibili per ogni componente, sia talvolta non indifferente e induca una selezione deficiente ditalune informazioni, in cui per alcuni dispositivi abbiamo tutte le nozioni richieste, per altri solouna minima parte; evenienza che, logicamente, riduce l’efficacia delle differenti tecniche, pensatein teoria per funzionare su costrutti completi.

Apparirà evidente a questo punto come il problema della selezione tra COTS sia parente pros-simo delle problematiche di integrazione dei componenti descritte in precedenza e sia dunque, inultima analisi, un’altra declinazione delle problematiche di emergenza. La deficienza informativacorrelata ai COTS impedisce infatti:

• da una parte di usarli in modo corretto, inducendo comportamenti emergenti;

• dall’altra di poterli valutare compiutamente, obbligandoci ad una visione limitata dei mede-simi.

Si palesa allora la necessità di stabilire a monte quali siano i parametri descrittivi che dovrannocaratterizzare i COTS. Già Garlan et al. [79] nel 1994, trovandosi di fronte ad un incrementoesponenziale nel costo e nella durata dello sviluppo di un loro progetto, scrivevano:

7.3 W E B S E RV I C E 141

I creatori dei sotto-sistemi che abbiamo utilizzato non erano né pigri, né incompetenti, némalevoli. E d’altra parte noi non stavamo utilizzando tali componenti in modo differente da

quanto descritto nei documenti allegati. Allora perché non funzionavano a dovere?

Nello stesso articolo gli autori propongono di usare un formalismo univoco che consenta di ovvia-re a quegli errori di progettazione dell’architettura che, a parer loro, provocavano le problematicheriscontrate. Il loro approccio era fortemente orientato alle problematiche di integrazione dei varicomponenti e la loro soluzione si concentrava pertanto su di una tassonomia dei fallimenti orien-tata esplicitamente in tal senso. In realtà negli ultimi anni sono state offerte varie proposte [61],che considerano differenti punti di vista attraverso i quali possono essere interpretati i componen-ti. Non interessa in questa sede disquisire su quale approccio sia preferibile, è nostro interesseunicamente sottolineare come una corretta analisi e selezione dei COTS non possa prescinderedall’introduzione di un formalismo descrittivo maturo cui i differenti vendors dovrebbero, se nonproprio aderire, almeno tendere.

Ovviamente ci rendiamo conto che introdurre una siffatta metodologia di progettazione e docu-mentazione sia approssimabile ad un desiderio utopico: probabilmente le distanze tra i differentivendors e le necessità economiche impediscono a priori una soluzione di questo tipo. Mostreremoperò nel proseguo della trattazione come sarebbero sufficienti poche informazioni aggiuntive perridurre considerevolmente il grado di ignoranza che un utente associa ad un COTS.

Le considerazioni sin ora offerte si prefigurano come elementi di un’analisi prettamente teorica,in cui si è cercato di sintetizzare la nuova filosofia con cui si dovrebbe approcciare il ricorso acomponenti COTS alla luce delle problematiche emergenti. Cercheremo adesso di puntualizzarealcune proposte più concrete. In particolare la loro disamina prenderà spunto dallo studio dellesoluzioni presenti nell’ambito dei Web Service, ambito affine a quello dei COTS, in cui alcuniostacoli visti in precedenza sono stati risolti (complice anche una minore complessità generale delproblema).

7.3 W E B S E RV I C E

Abbandoneremo, almeno per il momento, le riflessioni relative alla natura e all’utilizzo dei CO-TS, per concentrarci in questa sezione su oggetti che mostrano problematiche limitrofe e offronospunti interessanti per approcciare i componenti off-the-shelf stessi: i Web Service (WS) [80][81].

La volontà di trattare i WS nasce da alcune considerazioni essenziali:

• i WS, come vedremo in sezione 7.3.2, hanno una natura similare ai COTS, in particolarmodo per quanto concerne l’assimilazione di entrambi a black box;

• i WS sono strutturalmente più semplici dei COTS e, di conseguenza, le problematicheinerenti sono più facilmente risolubili;

• il problema della selezione nei WS è essenziale e, pertanto, esistono in letteratura molteplicisoluzioni, alcune delle quali offrono possibili spunti utili parlando di emergenza in ambitoCOTS.


Nel corso della trattazione partiremo dall’assunto che il lettore abbia una conoscenza almenoapprossimativa dei concetti e delle problematiche inerenti i WS, preferendo concentrare la nostraattenzione sulla metodologia rappresentativa dei medesimi e, in particolare, sul concetto di repo-sitory di WS, da cui, inevitabilmente, scaturiranno tutte le considerazioni relative alla selezione ditali oggetti.

7.3.1 Linguaggi Per La Definizione Dei Web Service

Fino a pochi anni fa i software di supporto per il business orientati al web si basavano su approcciad hoc atti a sfruttare i vantaggi offerti da Internet. Oggigiorno, tale ruolo è stato interamenteassunto dai WS che si prefigurano come strumenti capaci di offrire un approccio sistematico,nonché un framework facilmente estendibile, per interagire tra applicazioni sfruttando i protocolliweb e basandosi su standard aperti, in particolare XML.

La definizione di un WS deve considerare la presenza di tre main-task:

1. protocollo di comunicazione;

2. descrizione dei servizi offerti;

3. discovery dei servizi presenti in un dato insieme.

Per ciascuno dei precedenti è stato sviluppato uno, o più, linguaggi specificamente pensati perdefinirne compiutamente le differenti sfaccettature [80] [82].

1. Simple Object Access Protocol (SOAP) per i protocolli di comunicazione;

2. Web Services Description Language (WSDL) per la definizione dei WS;

3. Universal Description, Discovery and Integration (UDDI) per il rilevamento di WS.

SOAP è un protocollo di comunicazione, basato su XML, per lo scambio di messaggi e per le Re-mote Procedure Call (RPC). Piuttosto che definire un nuovo protocollo di trasporto, SOAP poggiasu quelli esistenti tipici del web, quali HTTP, SMTP, etc. In questo modo SOAP si prefigura co-me un meccanismo di comunicazione indipendente dalla piattaforma, sicuro e internazionalmentericonosciuto.

SOAP abilita la comunicazione tra agenti interessati all’uso dei WS, ma non specifica in alcunmodo la natura e il contenuto dei messaggi che è necessario scambiare al fine di interagire consuccesso con il WS d’interesse. Tale ruolo è infatti ricoperto da WSDL, un formato, sviluppatoda Microsoft e IBM e basato anch’esso su XML, atto a descrivere i messaggi accettati da unWS. In sostanza la comunicazione tra WS viene vista come una collezione di messaggi che dueagenti sono abilitati a scambiarsi. Anche in questo caso, non interessa dettagliare la natura e ilformalismo specifico caratterizzante WSDL, basti sapere che le informazioni che si vanno a daresono fondamentalmente di due tipi.

1. Descrizione Del Livello Applicativo: in cui si specificano il vocabolario in uso e i messaggiaccettati.

2. Dettagli Del Protocollo: in cui si specificano le informazioni sul protocollo da utilizzare,sulla catena di interazioni necessarie e sugli indirizzi di riferimento per la comunicazione.

7.3 W E B S E RV I C E 143

UDDI: Un Repository Per I Web Service

UDDI è un linguaggio di specifica finalizzato a definire, in modo univoco e sistematico, una tec-nica di selezione tra WS sfruttando un registro centralizzato. La necessità di possedere un similelinguaggio può essere rintracciata nel passaggio, avvenuto da alcuni anni, da un utilizzo tipicamen-te B2B (Business-To-Business) dei WS, ad un suo ricorso più diffuso in ambito B2C (Business-To-Consumer). Tale trasformazione ha indotto un naturale incremento dei soggetti interessati alavorare con WS, comportando:

1. la presenza di agenti meno consapevoli delle specificità dei WS, e dunque bisognosi di unaiuto per la fase di selezione dei medesimi;

2. un significativo incremento nel numero di WS disponibili.

La soluzione a tali problematiche è stata rintracciata nel ricorso ad un repository specificato escandagliato tramite un linguaggio specifico: UDDI.

UDDI consente infatti di risolvere due task essenziali nell’ottica di un utilizzo di un repositorypubblico:

1. esso permette la definizione di un WS e delle informazioni ottenibili tramite ogni suoservizio;

2. esso specifica inoltre le API di riferimento per le query e gli update del registro.

L’idea alla base di UDDI è quella di avere un registro pubblico (UDDI Business Registry - UBR),distribuito su diversi nodi, in cui i dati sui nodi vengono tenuti sincronizzati. UBR si caratterizzapertanto come un insieme di nodi pubblici. Pur effettuando l’inserimento su di un singolo nodo, lareplicazione e sincronizzazione vigenti in UBR fanno sì che qualsiasi nodo al suo interno forniscale medesime informazioni.

Un registro UDDI contiene una serie di informazioni racchiuse in quattro strutture dati (definitecome istanze di uno schema XML).

1. Business Entity: informazioni sul responsabile del servizio.

2. Business Services: informazioni su uno o più servizi offerti.

3. Binding Template: alla base di tutte le operazioni di binding all’interno del linguaggio. Siutilizza in particolar modo per fare riferimento ai tModel.

4. tModel: informazioni per la tassonomia dei servizi.

Apparirà evidente come l’elemento chiave del linguaggio sia rappresentato dal tModel; di fatto, lecapacità espressive di UDDI dipendono direttamente da quelle dei tModel. Al fine di migliorarel’efficienza della ricerca e l’interazione con tale struttura, i tModel sono pensati come metadati, incui non sono presenti descrizioni, ma solo riferimenti. Abbiamo infatti: una chiave, un nome, unadescrizione opzionale e un URL di riferimento per la descrizione della risorsa.

Le strutture appena definite consentono di dettagliare tre tipologie di informazioni trasportateda UDDI.

1. Pagine Bianche: con cui si dettagliano le informazioni di base sulla Business Entity diriferimento.


2. Pagine Gialle: in cui si categorizzano i WS e, nello specifico, i relativi servizi offerti, inbase al settore di riferimento.

3. Pagine Verdi: in cui sono offerti dettagli tecnici sui differenti servizi offerti.

WS: Il Problema Della Ricerca

Le considerazioni offerte sin ora, incentrate sul concetto di repository e di linguaggio di ricerca,dovrebbero aver palesato l’essenzialità del problema della ricerca nell’ambito dei WS. In effetti,una percentuale considerevole della letteratura del settore è improntata proprio su tale problema-tica, sul suo peso all’interno di un processo di sviluppo di un’architettura che usa WS e sullepossibili soluzioni approntabili per affrontare efficientemente la questione.

Parlando di ricerca di WS ci poniamo nell’ottica di un utilizzatore di servizi (sia esso a livellobusiness o costumer) che necessita di alcune feature prefabbricate. La selezione di un WS presentafondamentalmente due problematiche chiave:

• selezione di un insieme di WS che implementino i servizi d’interesse;

• definizione di un ranking dei WS selezionati, sulla base di opportune metriche qualitative.

Il primo problema nasce dall’impossibilità di etichettare ogni servizio con una keyword univoca.Le molteplici specificità dei vari servizi fanno infatti sì che, per caratterizzare ognuno di essi, sisia costretti a definire un insieme di keyword qualificanti. A tal punto la selezione, e il rankingconseguente, avvengono come in una tipica ricerca tra lemmi: maggiore è il numero di keyworddi un servizio che matchano con il pattern di ricerca, migliore sarà la posizione di tale servizio nelranking finale.

Si capisce immediatamente come una simile metodologia sia limitante. Anzitutto il semplicericorso a keyword, peraltro neppure standardizzate (non sempre c’è un vocabolario di riferimento[80]), è un approccio troppo labile e con basso contenuto informativo. D’altra parte un siffattoranking ignora completamente peculiarità del WS o anche evidenti metriche di QoS [83] che, alcontrario, rappresenterebbero i veri capisaldi su cui poggiare la stesura di una graduatoria tra iWS selezionati.

Nel proseguo osserveremo pertanto come il processo di selezione possa essere raffinato tramiteil ricorso ad informazioni addizionali.

7.3.2 Web Service Vs. COTS

La breve introduzione data sui WS e, in particolare, la digressione precedente sul problema dellaselezione, dovrebbero aver permesso di apprezzare le evidenti assonanze che legano WS e COTS(intesi nella loro accezione software).

La caratteristica certamente più interessante che li accomuna è la possibilità di intenderli en-trambi come dei black box che offrono servizi, senza curarsi della loro architettura interna o dellespecificità dell’implementazione adottata. Tale attitudine fa sì che per entrambi valgano le consi-derazioni offerte nel capitolo 3 a proposito delle problematiche di interconnessione e, in ultimaanalisi, di emergenza. Così come avveniva per i componenti off-the-shelf, laddove si vadano adutilizzare in comunione WS differenti si realizza un sistema il cui corretto funzionamento non èassicurato, in quanto potrebbero manifestarsi comportamenti inattesi tali da invalidare i risultati

7.3 W E B S E RV I C E 145

ottenuti. Si torna a parlare in sostanza di grado di ignoranza su di un WS e di grado di ignoranzasull’intero sistema o su parti di esso.

D’altra parte, anche da un punto di vista della testability, WS e COTS presentano caratteristichecomuni [84]. Possiamo brevemente indicarne alcune, probabilmente le principali:

• i WS possono essere richiamati da fonti non prevedibili, con richieste anch’esse non preve-dibili da parte di client o altri WS;

• i WS sono caratterizzati da un carattere tipicamente dinamico e il loro comportamento puòessere osservato compiutamente solo a runtime;

• i WS hanno il vantaggio di essere caratterizzati da un’architettura non troppo complessa,ma, d’altra parte, richiedono ottime prestazioni;

• l’esecuzione dei WS comporta spesso il ricorso a thread concorrenti o alla condivisione dioggetti.

Ovviamente, così come esistono importanti affinità, allo stesso modo permangono innegabili dif-ferenze. In particolare, almeno per quanto riguarda lo stato attuale dell’arte, la differenza fon-damentale tra i due risiede nella maggiore semplicità dei WS rispetto ai COTS. I WS infatti, sipresentano come oggetti piuttosto semplici, nella maggior parte dei casi basati su un’architetturaimplementativa elementare. La ragione di tale evidenza è rintracciabile nella natura stessa deiWS; si tratta infatti, come del resto suggerisce il nome stesso, di oggetti fortemente orientati adun utilizzo in rete e, pertanto, il loro throughput deve implicitamente rapportarsi alle capacità diuna architettura, come quella Internet, che fino a pochi anni fa era caratterizzata da prestazionilimitate e che comunque, ancora oggi, non è paragonabile, in termini di prestazioni, al tipo dilavoro conducibile su un calcolatore. Ciò ha fatto sì che il numero di feature offerte da un singoloWS e la loro complessità siano ancora abbastanza limitate, permettendo di conseguenza una fasedi analisi e di testing più semplici e più efficienti.

Al di là di questa, pur importante, differenza, rimane una vicinanza concettuale tale da avercispinto ad esplorare maggiormente i WS e, in particolar modo, le problematiche correlate allaricerca di WS. E’ soprattutto in questo particolare ambito infatti che si palesa l’analogia tra idue soggetti della trattazione. In entrambi i casi abbiamo la presenza di un customer che vuolerealizzare certe feature e la disponibilità di un ventaglio di possibilità da cui attingere per scegliereil prodotto maggiormente performante. Nel caso dei WS il vantaggio risiede nella loro maggioresemplicità: scegliere tra componenti meno complessi rende ovviamente meno difficoltosa l’interaprocedura di scelta. Il motivo per cui abbiamo scandagliato il concetto di WS è proprio questo:osservare, in presenza di un problema del tutto similare, ma con complessità minore, quali sono lesoluzioni approntate. Ovviamente, il nostro obiettivo è quello di capire se gli spunti offerti sonotraducibili nell’ottica di un sistema emergente costituito da COTS.

7.3.3 Informazioni Addizionali Per i Web Service

In questa sezione cercheremo di riassumere i principali approcci presenti in letteratura per mi-gliorare il trattamento dei WS. Abbiamo infatti osservato come la qualità della ricerca nei WSsia fortemente inficiata dalla difficoltà ad assegnare un riferimento qualitativo ai differenti WS: aparità di copertura funzionale, si dovrebbero prevedere criteri di selezione che considerino la QoS


dei WS e, dal nostro punto di vista, l’ignoranza associata ai medesimi; tutti parametri di non facileassegnamento.

Fondamentalmente possiamo individuare tre approcci percorribili per attaccare il problema:

1. raffinamento della ricerca;

2. ricorso a test;

3. utilizzo di informazioni aggiuntive.

Raffinamento Della Ricerca

Volendo realizzare una ricerca tra WS più raffinata, esistono fondamentalmente due metodologiedi lavoro, derivanti dalle due possibili fasi sequenziali in cui è possibile suddividere l’operazionedi ricerca:

1. specifica della query di ricerca;

2. rilevamento di un matching con i candidati.

Per quanto riguarda la specifica delle query esistono una moltitudine di alternative, particolar-mente interessante appare quella proposta in [82], dove si introduce il concetto di raffinamentosuccessivo della query. L’utilizzo di raffinamenti successivi consente infatti all’utente di parti-re da concetti anche vaghi, senza bisogno quindi di ricorrere a keyword specifiche che magariomettono risultati d’interesse, per poi, una volta osservati i risultati offerti dalla prima scrematura,focalizzarsi su certi aspetti d’interesse. Soluzioni di questo tipo non interessano lo studio attuale,in quanto sono orientate alla risoluzione di una deficienza espressiva non correlata all’ignoranzadei componenti da selezionare.

Nell’ottica di migliorare il rilevamento del matching tra candidati si inseriscono tutte quellesoluzioni che prevedono il ricorso ad un’analisi semantica dei termini contenuti nelle descrizionidei WS. L’idea è che un matching classico, fondato sulla coincidenza delle keyword sia troppolimitante. Tale limite può però essere superato associando un significato semantico ad alcuneparole chiave, in modo da poter ricorrere a tecniche di AI o di regressione per stabilire un gradodi attinenza. E’ comunque anche questa una tecnica troppo specifica per i WS e che non risolve ilimiti propri di un’analisi emergente.

Più interessante l’approccio proposto in [85] dove si immagina il ricorso a matching pre-calcolatied autonomi rispetto al framework di lavoro. Si suppone in sostanza di arricchire il sistema in-troducendovi la possibilità di dichiarare tabelle di matching esterno in cui l’attinenza tra keyworde WS o tra due WS è stabilita a priori secondo una metrica ignota all’utente. Il vantaggio delmetodo consiste nella possibilità di tradurre in un apporto numerico una conoscenza possedutasugli elementi in esame. Si potrebbe pensare ad esempio di voler stabilire uno stretto legame trauna keyword e un WS, anche se le specifiche del WS non lo implicherebbero, perché si ritiene chelogicamente i due elementi siano legati. Oppure, notata la somiglianza tra due WS, si potrebbeessere interessati a tradurre tale vicinanza concettuale in una risultanza pratica: una keyword cheselezioni uno dei due WS, selezionerebbe in pratica anche l’altro. L’approccio è particolarmen-te interessante poiché permette di materializzare e condividere una conoscenza posseduta, scopoche, in fondo, è alla base della nostra disamina del concetto di emergenza.

7.3 W E B S E RV I C E 147

Ricorso A Test

Parlando di ricorso ai test nell’ambito della selezione di WS si intende la volontà di qualificarepositivamente quei WS di cui possediamo informazioni ottenute tramite testing. L’idea è la me-desima discussa a proposito dei fenomeni emergenti: un WS che abbia passato un qualche testdovrebbe essere preferibile ad uno che, al contrario, non è stato verificato. La letteratura del set-tore è ricca di tecniche finalizzate alla generazione di test per la verifica di WS: si può pensare diutilizzare in modo automatico la descrizione WSDL [86]; di arricchire il sistema con una notazio-ne semantica e sfruttare tali conoscenze aggiuntive [87]; o di inserire script di testing pre-costruiti[84]. Le soluzioni sovracitate appaiono comunque difficilmente esportabili nell’ambito dei COTS.Da una parte, la mancanza di una descrizione approssimabile a quella data da WSDL impedisceil ricorso a tecniche di generazione automatica dei test. Dall’altra, anche il concetto di script pre-costruito non sembra attuabile: come rapportare tra loro risultati offerti da test differenti, pensatiperaltro da vendor differenti? E quale grado di completezza e complessità possiamo riporre in untest che, in ultima analisi, ha lo scopo di certificare la correttezza di un prodotto che il vendor deveimmettere nel mercato?

Utilizzo Di Informazioni Aggiuntive

L’ultimo approccio citato in precedenza riguarda l’immissione di informazioni aggiuntive per ogniWS. Una simile direzione di lavoro si focalizza di fatto sulle problematiche di ignoranza di cui ab-biamo parlato durante tutto il lavoro. L’idea è ancora una volta quella di dover maneggiare oggettisu cui abbiamo dei deficit informativi, cui si pone rimedio con l’aggiunta di campi addizionali. In[88] si immagina l’immissione di quattro campi particolarmente utili nell’ambito dello sviluppodi tecniche di testing.

1. Dipendenze tra input e output: in questo caso si richiede la specifica della dipendenza esi-stente tra valori di input dati e valori di output attesi. L’immissione di questo campo ècorrelata alla volontà di migliorare il ricorso a tecniche di testing ottimali. Molte di que-ste tecniche infatti, come ad esempio il Regression Testing, richiedono obbligatoriamentetale informazione. Ovviamente è un campo sensato unicamente in relazione a WS (o, me-glio, a WS semplici); nel caso dei COTS offrire una funzione che formalizzi la dipendenzadesiderata non è ipotizzabile.

2. Sequenza di Richiamo: alcuni WS poggiano il proprio funzionamento su output ottenutitramite chiamate ad altri WS. Con il termine sequenza di richiamo si intende proprio lacatena di richieste che è necessario effettuare verso altri WS al fine di portare a termine lacomputazione del WS d’interesse.

3. Descrizione della Gerarchia Funzionale: tramite WSDL è possibile specificare una descri-zione funzionale. Si potrebbe pensare di organizzare tale descrizione tramite una gerarchicae strutturare l’albero ottenuto con le descrizioni funzionali specifiche per ogni nodo. Si ipo-tizza in pratica di costruire un albero dei requisiti funzionali offerti dal WS, non troppodissimile da quello proposto da KAOS (in realtà la differenza sostanziale sta nel fatto chei requisiti di KAOS sono desiderati, mentre qui sono implementati). L’utilizzo di questenuove informazioni può rappresentare un punto di partenza per lo sviluppo di differentitipologie di testing funzionale.


4. Specifica della Sequenza Operativa: la sequence specification è un concetto utilizzato so-prattutto nel testing di programmi OO. Si potrebbe pensare di offrire una descrizione, ov-viamente ad alto livello, delle macro-funzioni che vengono richiamate durante la normaleesecuzione del WS. Ovviamente, una simile strategia è difficilmente coniugabile con lariservatezza che accompagna i COTS.

7.4 A R R I C C H I R E I C OT S C O N I N F O R M A Z I O N I A D D I Z I O N A -L I

Nella prima parte del capitolo abbiamo analizzato la natura dei componenti off-the-shelf, esa-minandone le problematiche e la innata tendenza a indurre fenomeni emergenti. La trattazionesi è successivamente spostata sull’analisi dei WS, quale ambito d’interesse per ricercare approc-ci risolutivi traducibili nell’ottica di una tecnica di riduzione dell’ignoranza associata ai COTS.Nell’ultima parte di questo capitolo intendiamo tirare le somme della disamina compiuta sin ora.Proporremo pertanto alcune linee guida utili a migliorare l’interazione con componenti COTS, losviluppo di sistemi complessi e, in ultima analisi, capaci di ridurre l’ignoranza cui è costretto asottostare un customer che utilizzi tali componenti.

Le indicazioni date cercheranno di risolvere i limiti conoscitivi individuati in sezione 7.1. Talideficienze saranno risolte con l’introduzione di campi informativi specifici, ma anche tramite ilricorso ad alcune soluzioni osservate a proposito dei WS.

In particolare, analizzeremo due tipi di apporti:

• dal lato customer cercheremo di capire quale apporto possa dare la collettività degli utentifinali al giudizio su di un prodotto;

• dal lato vendor proporremo alcune informazioni che riteniamo essenziali per qualificarel’ignoranza relativa ad un componente.

Un Repository Per I COTS

Come accennato in precedenza, faremo un diffuso ricorso all’aggiunta di informazioni addizio-nali, tale approccio alla risoluzione del problema sarà inserito nel contesto dello sviluppo di unrepository per COTS. In analogia a quanto visto per i WS, si ipotizzerà di possedere un contenitoredi COTS in cui andremo ad aggiungere particolari campi informativi per migliorare la selezionedi tali componenti.

L’ipotesi di lavoro può apparire poco realistica, se non altro perché non esiste un repository diriferimento per i COTS, ma è assolutamente valida e utile nell’ottica delle soluzioni che andremo aproporre, semplificando notevolmente la trattazione. Tale assunzione peraltro non inficia in alcunmodo la validità delle argomentazioni che proporremo, che rimangono valide anche rinunciandoal contesto di un repository e pensando, ad esempio, di utilizzare i campi descrittivi in modoautonomo per ogni COTS.

Si sottolinea peraltro come lo sviluppo di un siffatto repository potrebbe risultare di notevoleinteresse nell’ambito del trattamento e, in particolare, selezione dei COTS. L’utilizzo di un repo-sitory rappresenta infatti, come vedremo, il background ideale per introdurre il concetto di ratinge per consentire a differenti customer di pubblicare una valutazione del prodotto.

7.4 A R R I C C H I R E I C OT S C O N I N F O R M A Z I O N I A D D I Z I O N A L I 149

7.4.1 Rating Dei COTS

L’intera disamina sin ora condotta sui COTS ha avuto, fondamentalmente, un obiettivo latente benpreciso: riuscire a stabilire una graduatoria tra COTS. In sostanza, selezionati alcuni COTS cherispondono a certe esigenze funzionali, vorremmo poter stilare una lista in cui il migliore, intesocome quello che più difficilmente sperimenterà emergenza, sia nei primi posti.

In [89] si sottolinea come nei WS l’idea di ranking sia intrinsecamente indotta dall’utilizzodi UDDI. In tale articolo si propongono infatti semplici operazioni per introdurre tale concettonell’ambito della selezione di WS. L’idea di base è quella di valutare un WS (o anche un singoloservizio da esso offerto) secondo due meccanismi di feedback:

1. un feedback manuale lasciato dall’utente, il quale propone una sua valutazione sull’operatodel WS;

2. un feedback automatico assegnato dal calcolatore sulla base dell’avvenuta effettuazionedelle operazioni richieste al WS.

I due feedback confluiscono per creare una valutazione complessiva del prodotto. Ovviamentetale valutazione può essere raffinata utilizzando differenti customizzazioni.

• Concetto di Credibilità di un’Azienda: in cui la valutazione data ad un vendor influisce sulfeedback dei suoi prodotti.

• Concetto di Credibilità di un Prodotto: in cui il feedback di un prodotto influenza il feedbackdi eventuali estensioni o upgrade.

Una soluzione di questo tipo ha l’enorme vantaggio di distribuire globalmente la conoscenzaposseduta da un singolo cliente su di un prodotto: concetto assolutamente rilevante nell’otticadi uno studio dell’emergenza. Abbiamo detto infatti che l’emergenza può essere quantificata, oalmeno rilevata, solo tramite testing, ma, di fatto, ogni utente che utilizzi un prodotto lo testa; ilconcetto di feedback consente in tal senso di diffondere, sia pur in maniera estremamente sintetica,i risultati di tali testing.

Immaginando di possedere un repository di COTS, si potrebbe pensare di associare un cam-po espressione del grado di ignoranza associabile al componente. Un customer che abbia rilevatocomportamenti emergenti, lasciando un feedback basso in tale campo, informerebbe gli altri utentidi un possibile aspetto emergente latente nel prodotto. Peraltro, aggiungendo una semplice descri-zione alla valutazione data, si potrebbe pensare di arricchire la medesima indicando, se non altro,anche l’ambito d’uso e le correlazioni che hanno sperimentato la condizione inattesa. Un prodottocaratterizzato da un’alta ignoranza associata, tenderà ad assumere un feedback basso, espressio-ne di una difficoltà, o comunque ambiguità, intrinseca nell’utilizzo del medesimo; difficoltà chesi traduce nella creazione di sistemi emergenti. Inoltre, la descrizione associata, informando suiprodotti che confliggono con quello d’interesse, potrebbe scoraggiare eventuali clienti interessatiad utilizzare quel sottoinsieme di prodotti.

Ovviamente la soluzione non è scevra da inconvenienti.

• Si tratta anzitutto di riuscire a creare un’ontologia comune per la valutazione dei prodotti.Idealmente infatti ogni cliente dovrebbe seguire la medesima metrica valutativa. D’altraparte una simile eventualità appare certamente complessa soprattutto in relazione a prodottinotevolmente differenti tra loro.


• Vi è poi il problema dei false rating, cioè l’assegnazione di feedback non veritieri al fine diincrementare o decrementare il rating di un prodotto.

Al di là di queste difficoltà, che riguardano meramente l’implementazione reale della tecni-ca, rimane l’importanza di una soluzione che consente di condividere la conoscenza della nonconoscenza, elemento imprescindibile per creare un background di esperienze di utilizzo utile avalutare pienamente, da un punto di vista dell’emergenza indotta, un prodotto.

7.4.2 Maggiori Informazioni Dai Vendor: I Test

Abbiamo descritto una tecnica, l’utilizzo di un rating basato sul concetto di feedback, svolta essen-zialmente dal customer finale e strettamente dipendente dall’utilizzo di un repository. Vogliamoadesso concentrarci su soluzioni del tutto differenti, in cui il ruolo principale è svolto dal vendore la cui applicabilità è indipendente dall’idea di possedere un contenitore univoco. L’approccio sibasa sul presupposto che il vendor associ informazioni aggiuntive, solitamente nascoste all’utenzafinale, ad ogni prodotto. Ciò consente all’utente:

• di avere una migliore conoscenza del prodotto;

– selezione tra COTS più attenta;

– utilizzo dei COTS maggiormente cosciente;

• di provvedere tecniche di testing più efficaci.

La prima informazione di interesse assoluto, che si ritiene indispensabile per rapportarsi in modomaggiormente cosciente con i COTS, riguarda le conoscenze aggiuntive sui test condotti dal ven-dor. Ai nostri occhi il produttore di un componente dovrebbe informare l’utente sulla natura deitest condotti sul medesimo. Da un punto di vista del cliente maneggiare un prodotto su cui è statafatta una mera verifica per valore o, al contrario, uno su cui sono stati condotti test più approfon-diti, rappresentano due situazioni assolutamente differenti. Già in fase di selezione dei prodotti,sapere che su di un componente è stata approntata una verifica utilizzando metodi formali puòessere un elemento decisivo per scegliere un COTS piuttosto che un altro.

Proseguendo su questa linea di ragionamento pare interessante riprendere in considerazione leproposte presenti in [88] a proposito della definizione di una descrizione funzionale gerarchica.In effetti, se per un WS, vista la semplicità del componente, specificare il tipo di test condotto puòessere un’informazione sufficiente, nel caso dei COTS siamo in presenza di strumenti molto piùcomplessi, in cui i test condotti sono probabilmente stati molteplici, a differenti livelli di analisi.L’ideale sarebbe pertanto possedere una mappa (gerarchica) delle feature espresse dal componentee, per ogni feature, la specifica del tipo di test condotto.

E’ evidente come un simile apporto informativo cambi radicalmente il modo di correlarsi conil componente. Anzitutto è presente un accrescimento informativo dettato dalla presenza dellamappa funzionale. Inoltre, siamo in grado di abbozzare una mappa dell’ignoranza da sovrapporrealla precedente. Il tipo di test condotto infatti ci permette di stabilire, sia pure a grandi linee,la credibilità che possiamo riporre su ogni feature e, in ultima analisi, il grado di ignoranza daassociare ad un flusso di lavoro che richiami specifiche feature (magari di differenti COTS).

Possedere queste informazioni offre pertanto un duplice vantaggio. Da una parte consente dieffettuare una scelta più matura al momento della selezione di un prodotto.


• Componenti che mediamente presentano test meno provanti saranno scartati in favore dialtri su cui sono stati approntati test più severi.

• Focalizzandosi di più sulle singole feature, è sensato ritenere che un acquirente preferi-rà acquistare quei prodotti in cui le feature di maggiore interesse sono state verificate almeglio.

In secondo luogo, la mappa descritta in precedenza permette di elaborare al meglio le analisi sul-l’emergenza (o meglio sull’agglomerazione dell’ignoranza) descritte nel capitolo 3. In precedenzaavevamo infatti parlato di grado di ignoranza associato ad un agente, sottintendendo ovviamen-te di possedere sufficienti informazioni per poter almeno approssimare tale valore. Ovviamente,parlando di COTS tale approssimazione non è attuabile a causa dell’accezione di black box chesolitamente caratterizza i componenti off-the-shelf. Possedere una mappa delle funzionalità e deirelativi test ci riporta nelle condizioni ideali, o comunque accettabili, per completare l’analisi.

7.4.3 Maggiori Informazioni Dai Vendor: I Domini

Nei capitoli precedenti abbiamo sottolineato come uno dei principali motivi per cui si manifestanocondizioni emergenti è legato ad un utilizzo erroneo del componente; laddove per utilizzo erroneosi intende un utilizzo non conforme a quanto immaginato dal progettista. Il fenomeno derivaprincipalmente dall’immissione di dati inattesi, cioè dati estranei al dominio di riferimento. Talesituazione può avvenire per vari motivi:

1. mancata specifica del dominio di riferimento da parte del progettista;

2. mutato contesto di utilizzo con variazione dei dati in elaborazione;

3. errori in componenti connessi a quello in esame, che producono output inattesi.

Per l’analisi in atto, pare estremamente interessante il punto 1, in cui si palesa una deficienza chespesso accompagna i COTS: il dettaglio dei domini di riferimento. Spesso infatti la specifica diun componente si focalizza sulle funzionalità offerte e, al limite, sui contesti di utilizzo attesi,ignorando però una formalizzazione attenta dei domini.

Al contrario nella letteratura relativa ai COTS [88] [79] [70] [74] si sottolinea l’importanza diun’attenta formalizzazione di tali bound. L’ultimo campo addizionale che intendiamo proporreriguarda pertanto la specifica dei domini di riferimento. L’idea è quella di caratterizzare ognifeature offerta dal componente off-the-shelf con dei bound di accettazione per i valori immessiin input. In tal modo ci si aspetta di ridurre significativamente il numero di computazioni conrisultati inattesi. Peraltro, tale informazione risulta utile anche a livello di selezione dei compo-nenti. Volendo scegliere un prodotto si potrà infatti tenere in considerazione non solo la featured’interesse, ma anche il campo di applicabilità della medesima.

7.4.4 Maggiori Informazioni Dai Vendor: NFR

Un ultimo apporto informativo, che potrebbe concorrere a ridurre significativamente l’ignoranzacorrelata a un componente off-the-shelf, riguarda l’immissione di informazioni aggiuntive relativeai requisiti non funzionali. Nei capitoli precedenti abbiamo accennato all’importanza dei NFR, in


modo particolare in un ambito come quello dei COTS in cui la selezione tra alternative è unmomento essenziale dell’intero processo di progettazione e implementazione.

Nonostante la ricca letteratura inerente [29] [90], in cui troviamo differenti soluzioni approc-ciabili per qualificare al meglio i NFR dei differenti COTS in esame, le descrizioni che accom-pagnano i differenti COTS sono spesso povere di indicazioni proprio in relazione ai requisiti nonprettamente funzionali che caratterizzano quel componente. In particolare si dovrebbe teneremaggiormente in considerazione il ruolo delle interfacce, le quali:

• laddove si relazionino con uno end-user, rappresentano un discrimine importante nella QoSdel prodotto risultante;

• anche quando vengono immessi all’interno di un sistema, svolgono un ruolo chiave, bastipensare agli errori prodotti da comunicazioni erronee tra componenti.

Una soluzione potrebbe essere rappresentata dall’adozione di una tabella standard in cui sonopresenti i requisiti non funzionali più importanti; in tal caso ogni produttore di COTS dovrebbeesplicitare le modalità in cui il componente che immette sul mercato si adegua (ove lo faccia) aciascun NFR. Quella esposta è chiaramente una proposta estemporanea, non interessa in effettisoffermarsi sulle modalità di definizione degli NFR stessi; ciò che ritenevamo interessante eraspostare l’attenzione su di un aspetto che dal lato utente, cioè dal punto di vista di chi acquistacomponenti off-the-shelf, acquista una rilevanza considerevole.

7.4.5 Studio Dinamico Dei COTS

Nei paragrafi precedenti abbiamo sottolineato come i CBS siano architetture intrinsecamenteemergenti in cui, anche supponendo un descrizione adeguata, è praticamente certa la risultanzadi situazioni emergenti. Tale condizione nasce dalla presenza di componenti che si intercorrelanosecondo modalità inattese: il componente, considerato come entità assestante, si caratterizza perun certo comportamento, se inserito in un contesto muta il suo behaviour in modo impredicibile.

Sin ora ci siamo limitati a considerare le informazioni possedute, o possedibili, sul componente,nell’ultima parte del capitolo proveremo a stabilire la fattibilità di una ridefinizione dei componen-ti stessi, o almeno di una loro parte, che tenga in considerazione il contesto di utilizzo [91] e cheanalizzi i componenti in tale contesto. In fondo un simile approccio era già sottinteso nella defini-zione che offre Darley 12 di fenomeno emergente: se l’unico modo per sperimentare un fenomenoemergente è effettuare un testing, allo stesso modo l’unica forma definitiva di conoscenza sullemodalità di correlazione tra COTS è il testing dei medesimi.

Ovviamente la situazione ottimale sarebbe la creazione di un modello quanto più vicino pos-sibile a quello finale, su cui effettuare testing che possano mettere in risalto fenomeni emergenti.Potendo disporre di una siffatta situazione la nostra confidenza sulla bontà del sistema che stia-mo creando sarebbe certamente accresciuta, d’altra parte appare utopico, se non concettualmenteerrato, pensare di porci in una condizione simile. Anzitutto un simile approccio sarebbe ecces-sivamente dispendioso, in quanto il costo delle modifiche ad un progetto cresce con l’avanzaredelle fasi di sviluppo [69] ed è difficile pensare di re-ingegnerizzare un modello già quasi ultima-to. Inoltre effettuare la rilevazione di condizioni emergenti in fase avanzata impedisce di poterproporre un’analisi delle alternative valida, portandoci a non considerare opportunità che invecepotevano rappresentare una buona soluzione.


Si deve quindi mediare tra la volontà di accrescere le conoscenze sui componenti, soprattuttoin relazione al loro inserimento in un contesto, e la necessità di effettuare tale operazione nelleprime fasi di sviluppo del progetto. Si tratta, in pratica, di andare a creare nuova conoscenzasui componenti. In letteratura, sia in quella di riferimento per i COTS, sia per quanto riguarda iWS, sono presenti alcune soluzioni che immaginano il ricorso ad un simile momento di analisi.Cerchiamo di analizzarne l’attuabilità nell’ottica di un’analisi emergente.

Il Ricorso A Exploration Case

L’accrescimento informativo desiderato richiede lo sviluppo di un tool automatico che consentaal progettista di esplorare sistematicamente gli oggetti in esame sotto una varietà di differenticondizioni. In [92] è proposto un framework che cerca di rispondere proprio a queste esigenze.

Alla base dell’approccio vi è il concetto di exploration case, cioè un contesto applicativo ipo-tetico che dovrebbe riuscire a stressare e, di conseguenza, verificare il corretto funzionamento diun componente. Non potendo immettere il componente all’interno del sistema reale, né di unsuo modello completo, si allestiscono pertanto contesti simulativi che cercano di riprodurne almeglio le problematiche. L’idea è dunque quella di associare ad ogni componente una serie dicasi esplorativi in cui si analizzano le modalità di correlazione tra il componente stesso e un sotto-insieme, molto limitato, dei componenti che potenzialmente comporranno il sistema. Ovviamentein una politica di questo tipo assume un ruolo centrale la tecnica di definizione dei casi stessi. Intal senso si può pensare ad una moltitudine di soluzioni [70] [74] [76], ognuna con un’improntacaratteristica che si focalizzi su certi aspetti rispetto ad altri: come ad esempio sulla conoscenzarelativa al componente, piuttosto che sugli user need. In questo ambito un interesse particolare èassunto dall’approccio descritto in [77] dove la definizione dei NFR, tramite ad esempio UnifiedModel of Dependability (UMD) [93], guida la strutturazione degli exploration case.

Una soluzione di questo tipo soffre ovviamente dei limiti conoscitivi che il concetto di simula-zione mostra nei confronti di un’analisi emergente. Abbiamo già sottolineato come la simulazionenon sia utilizzabile per analizzare condizioni emergenti, fatto che inficia l’utilizzabilità degli ex-ploration case, i quali, nonostante provvedano un focus molto specializzato e attento a specificheproblematiche, rimangono inermi nei confronti del rilevamento di situazioni inattese.

Script

Più interessante appaiono soluzioni come quelle indicate in [68] [84], dove si immagina il ricorsoa script, dati dal vendor stesso, atti a realizzare test. In questo caso la bontà della proposta dipendechiaramente dalla profondità e dalla ricchezza degli script di test proposti. Appare evidente chesuggerire di utilizzare in modo passivo test dati dal cotruttore difficilmente arricchirà la conoscen-za posseduta o comunque permetterà di qualificare meglio un prodotto. Anche perché un siffattotest non potrebbe considerare quella varietà di contesti di utilizzo che, al contrario come abbiamovisto, rappresenta il vero elemento di accrescimento conoscitivo cui saremmo interessati.

In realtà il concetto di script risulta estremamente interessante se rapportato alla disamina sulladesign for testability vista nel capitolo 4. Sotto questo nuova ottica, uno script non dovrebbe rap-presentare tanto un test preconfezionato, quanto piuttosto uno strumento di supporto e di guida alsetting di un test privato. In sostanza, ai nostri occhi, il concetto di script ha un valore conosci-tivo reale solo se utilizzato in comunione con un componente che possieda almeno alcune dellecaratteristiche di testabilità viste in precedenza. Lo script dovrebbe dunque essere inteso come


una sorta di interfaccia tramite la quale avere accesso a parametri o settaggi che, al contrario, perla natura stessa dei COTS sono intangibili.

Un costrutto di questo tipo contribuirebbe a migliorare significativamente la testabilità di uncomponente COTS, consentendo di attuare tutta una serie di analisi utili a incrementare la cono-scenza su un componente e, di conseguenza, a ridurre l’insorgere di situazioni emergenti.

7.5 C A S I D I S T U D I O

Nella parte finale di questo capitolo cercheremo di applicare le considerazioni offerte sin oraa semplici casi di studio in modo da esemplificare l’apporto che un’analisi dell’emergenza (o,meglio, dell’ignoranza) può dare alla manipolazione di COTS.

Sono stati scelti esempi elementari al fine di mantenere sintetica la trattazione e di focalizzareil più possibile l’attenzione sulle problematiche d’interesse. Abbiamo considerato sia componentihardware che software, a riprova che le osservazioni date hanno un’applicabilità generale.

Gli esempi offerti intendono evidenziare particolari condizioni di errore (più o meno gravi)correlate a differenti deficienze dei componenti off-the-shelf:

1. mancata conoscenza di un comportamento del componente;

2. descrizione inadeguata dell’ambiente/contesto di utilizzo (e di testing);

3. mancata descrizione del tipo di testing compiuto.

Peraltro le mancanze proposte consentono di ricorrere a tre differenti apporti conoscitivi ipotizzatinelle pagine precedenti:

1. utilizzo di una metodologia di feedback che consenta di scambiare le esperienze degli utenti;

2. ricorso ad una descrizione più dettagliata del supposto contesto di utilizzo e dei contesti dioperazione del testing effettuato;

3. esplicitazione della metodologia di test eseguita.

7.5.1 Esempio 1

Il primo esempio che riportiamo riguarda il ricorso ad un componente software atto a informarel’utente sugli orari dei treni d’interesse. Si desidera in pratica acquisire un elemento, da utiliz-zare probabilmente in un framework di dimensioni maggiori, capace di sfruttare la connessionesottostante per accedere, ad esempio, al portale web delle “Ferrovie dello Stato” e catturare leinformazioni d’interesse. L’esempio è ripreso dall’ambito dei web service ma può evidentementerappresentare un COTS elementare.

Supponiamo di dover scegliere tra due componenti selezionati nella pletora di applicazioni co-struite per realizzare la feature d’interesse. Lo svolgimento di una tipica operazione di selezionetra tali oggetti riguarda considerazioni come la velocità di ricerca, la ricchezza delle query ese-guibili per la selezione del treno, la velocità di refresh dei risultati offerti, etc. La trattazione sinqui condotta dovrebbe aver evidenziato come, in comunione con gli indicatori appena descritti, sidovrebbe ricercare l’approssimazione dell’ignoranza connessa agli oggetti considerati.

7.5 C A S I D I S T U D I O 155

Si potrebbe, ad esempio, incappare in un componente che manifesta un funzionamento inde-siderato laddove il portale delle ferrovie risulti inaccessibile (per aggiornamento del sito o sem-plicemente per un problema ai server). In tal caso non è irrealistico pensare che il componente,incapace di effettuare il refresh, mantenga l’orario precedentemente letto senza avvisare l’utentedel problema, utente che al contrario dovrebbe essere sempre informato della fallita lettura, inmodo da consentirgli di prendere decisioni realmente consapevoli (ad esempio quello di salire suun treno differente da quello inizialmente preventivato).

In questo caso è ovvio che l’implementazione di un’architettura comune per la condivisionedelle esperienze d’uso avrebbe comportato un rating basso (o comunque un avviso da parte dialtri utenti) nei confronti del componente che sperimenta l’errore.

7.5.2 Esempio 2

Figure 2: Robot movementDevice Action Value, t.u.Feed belt Move plate to sensor 3Feed belt Move plate to table 1Table Raise and twist 2Table Return and twist 2Press Press plate 22-25Press Prepare for new plate 18-20Deposit belt Move plate out of cell 4Robot Arm A at table to arm B at press 5Robot Arm B at press to arm B at deposit 15Robot Arm A to press 5Robot From B at deposit to A at table 25Robot From B at deposit to wait position 22*Robot From B at press to wait position 17*Robot From wait position to A at table 3*Robot From wait position to B at press 2*Robot At wait position 2*Notes on the tableThere are a few time values that are considered design parameters, i.e. theymay be modi�ed during the modelling to adjust the behaviour. These valuesare marked with a *.The press requires some time to prepare for a new plate.The times given for the robot includes picking up and deposit plates at thetable, the press and the deposit belt.2.1 How the robot should workWhen a plate is moved from the feed belt1 to the table the table must be in itslowest position. The table then rises to a level where arm A can pick up theplate. The robot movement is then as follows (see �gure 2):1. Arm A extends and pick up the plate from the table.2. The robot rotates counterclockwise until arm B points towards the press.Arm B is extended until it reaches the press. Arm B picks up the forgedplate and retracts.1Note that the belt does not move continuously (it can be stopped), but you don't have tomodel this explicitly. 3

Figura 33: Schematizzazione del funzionamento di una Production Cell.

Per il secondo esempio prenderemo in considerazione un case study tipico in letteratura: laProduction Cell [94] [95]. Esistono molteplici versioni di tale caso di studio, nella trattazioneconsidereremo l’architettura proposta in figura 33:

1. una feed-belt porta un “piatto vergine” sino al braccio rotante;

2. il quale si occupa contemporaneamente:

a) di scaricare il “piatto lavorato” dalla pressa e portarlo su di una deposit-belt;

b) di caricare il “piatto vergine” nella pressa;

3. infine la deposit-belt porta via il “piatto lavorato”.

Ovviamente le criticità, da un punto di vista dei componenti fisici interessati, di un simile progettosono rappresentate dal sensore atto a rilevare un nuovo piatto disponibile per la pressa, dal bracciorotante e dalla pressa stessa; è pertanto realistico pensare che su tali componenti si concentrerannoi requisiti più restrittivi (ad esempio in termini di reliability), decidendo invece di utilizzare unCOTS non particolarmente costoso per i due nastri.

In questo caso il problema potrebbe presentarsi sotto forma di “contesto di utilizzo inatteso”.Un nastro trasportatore inteso come COTS basico (cioè non pensato per ambiti d’uso particolari)potrebbe evidenziare dei problemi se immesso in un contesto in cui:

1. si possono raggiungere alte temperature di lavoro (si pensi alla vicinanza di un’eventualesorgente di calore rappresentata dal condotto di raffreddamento del braccio rotante);

2. ci possono essere disturbi ambientali (come ad esempio le scintille della pressa).


Chiaro che in questo caso una soluzione potrebbe essere rappresentata dal ricorso ad un nastro conrequisiti maggiormente stringenti, ma in realtà sarebbe sufficiente indicare da parte del costruttore:

1. supposte condizioni di utilizzo (o comunque condizioni d’uso garantite);

2. contesto in cui si è effettuato il testing.

Mentre, al contrario, se le prime vengono spesso indicate solo genericamente, le seconde sonopraticamente trascurate.

7.5.3 Esempio 3

L’ultimo esempio che prendiamo in considerazione è relativo ad un “sensore luce” per automo-bili. In molti modelli attuali di macchine è infatti presente un dispositivo il cui ruolo è quello dimisurare la quantità di luce dell’ambiente in cui si trova la macchina e, ove si trovi sotto una certasoglia, accendere le luci dell’automezzo (solitamente quelle di posizione unite agli anabbaglianti).Per il caso di studio attuale, supponiamo che il dispositivo sia composto da una serie di sensoriposti in vari punti della macchina e da un’unità centrale, il cui scopo è quello di elaborare i datiletti dall’esterno e prendere una decisione in relazione all’accensione delle luci.

Anche in questo caso una casa produttrice che voglia installare elementi di questo tipo sullesue autovetture si troverà a dover scegliere tra una serie di soluzioni presenti sul mercato, dandoparticolare risalto ad aspetti legati alla velocità di computazione, all’affidabilità nel tempo, etc. Inrealtà il sensore luce, pur non rappresentando di per sé un elemento critico, controlla o comunquemodifica oggetti (le luci della macchina) che hanno un ruolo chiave in rapporto alla sicurezzastradale. I progettisti potrebbero pertanto essere interessati alla qualificazione di proprietà (disafety) come:

1. in condizioni di luce complesse (ad es. una galleria non chiusa) in cui ci siano valoricontrastanti tra i sensori, il dispositivo propende sempre per l’accensione delle luci;

2. il dispositivo non deve mai spegnere le luci qualora esse siano state accese manualmentedall’utente.

La verifica di tali proprietà richiede una mole non indifferente di test per studiare:

1. il tipo di scelte effettuate al variare degli input sui differenti sensori;

2. il behaviour del dispositivo in relazione al controllo delle luci.

In realtà tale mole di lavoro potrebbe venir considerevolmente ridotta laddove si possedesseroinformazioni aggiuntive sul tipo di test condotti dal costruttore.

1. Per quanto riguarda lo stress degli input:

• è stato studiato il comportamento del dispositivo nel complesso, variando ad esempiola luce esterna;

• oppure si è provveduto a stimolare ogni sensore con input differenti, magari anchecontradditori?

2. Analizzando l’accessibilità alle luci potrebbe essere invece interessante sapere se sono staticondotti test per valore o se si possiedono risultati ottenuti tramite metodi formali (chegarantiscano, ad esempio, che il dispositivo non forza mai lo spegnimento).

C O N C L U S I O N I 157

7.5.4 Considerazioni Finali Sui Casi Di Studio

Gli esempi proposti hanno permesso di evidenziare l’apporto che l’introduzione di poche sempliciinformazioni aggiuntive potrebbe dare nell’ambito dei COTS. In tutti i casi si è osservato come lamancanza di alcune conoscenze relative ai componenti tra cui si effettuava la selezione inducesseuna scelta poco consapevole, con il rischio di acquistare un oggetto che, utilizzato in un certocontesto, finiva con il manifestare fallimenti inattesi, figli di condizioni emergenti.

Ovviamente gran parte delle informazioni che abbiamo indicato come desiderate erano ottenibi-li tramite l’applicazione di una intensa fase di testing e, in effetti, questo è proprio ciò che spessoavviene oggigiorno lavorando con i COTS (situazione che spesso è indicata come uno dei limitiprincipali al loro utilizzo): si acquista cioè un componente supposto di offrire certe feature, mapoi si è costretti ad un ingente numero di test se si vuole garantire un qualche tipo di certezza sullacorrettezza del lavoro svolto dalla propria architettura.

Ai nostri occhi questa politica è essenzialmente errata. Anzitutto per motivi connessi alle pe-culiarità della fase di testing, che dovrebbe sempre esser condotta dal costruttore, il quale è (odovrebbe essere) onnisciente sul prodotto sviluppato, e non demandata ad un soggetto secondariocon conoscenze limitate. In secondo luogo i costi, materiali e temporali, connessi con la necessitàdi attuare una fase di testing ridimensionano i vantaggi legati all’adozione di componenti COTS.

É auspicabile che in un prossimo futuro, visto il sempre più diffuso ricorso alla componentisti-ca off-the-shelf, utenti da una parte e costruttori dall’altra prendano coscienza dell’inevitabilità diun arricchimento conoscitivo, figlio principalmente di un maggior numero di informazioni con-divise, in linea con le direttive proposte in queste pagine. Tale condizione pare ai nostri occhiun presupposto ineluttabile per ridurre il grado di manifestazioni emergenti nell’intero ambitoinformatico.

Conclusioni

A conclusione del lavoro proponiamo un breve sunto riepilogativo utile a fissare i capisaldi dellostudio condotto.

La genesi dell’analisi può essere rintracciata in una nuova interpretazione del concetto di erroresistemico. Per arrivare a questo risultato siamo partiti anzitutto da un’attenta disamina della fasedi Requirement Engineering (e, seppur meno in dettaglio, dei Metodi Formali), la quale ha eviden-ziato una difficoltà latente nella formalizzazione delle informazioni relative alla realtà contingente,ai requisiti richiesti e ai componenti sistemici. Né d’altra parte tale difficoltà, pur avendone co-scienza, viene considerata a sufficienza nella RE e, tantomeno, nelle fasi successive; permanendola diffusa tendenza a concepire ancora l’errore unicamente come una scorrettezza implementati-vo/progettuale. Nel nostro lavoro si è cercato al contrario di andare oltre il mero parallelismofallimento-errore, per rileggere un fallimento come il prodotto di una serie di apporti differenti,quali: definizione dei componenti parziale, immissione di feature troppo specializzate, utilizzo incontesti inusuali o inattesi, etc. Tutti questi apporti, che potrebbero anche non essere considerativeri e propri errori, si sommano convergendo in uno stato del sistema disatteso.

L’analogia con la natura di un fenomeno emergente è lampante. Così come gli emergentistia inizio ’800 qualificavano come emergenti tutte quelle proprietà di un sistema (nel loro casobiologico/filosofico) “non derivabili dalle proprietà (note) dei suoi componenti”, allo stesso mo-do è possibile ripensare un errore come l’inevitabile confluenza di caratteri ignoti. L’analisi diquesta congettura e lo studio delle ricadute dirette sulla progettazione e sullo sviluppo di sistemicomplessi hanno rappresentato il fulcro di tutto il nostro lavoro.

Il concetto di Emergenza in effetti era già stato introdotto nell’ottica dei sistemi informativi,ma, nonostante la sua criticità, ci si era sempre arrestati a congetture limitate sia in termini distruttura formale costituita, sia in termini di utilizzo indotto; peraltro non era mai stata condottauna disamina completa di questa nozione, che permettesse, ad esempio, di rapportarla alle varietecniche specifiche del settore. Al contrario lo studio effettuato ha considerato come incipit ob-bligato proprio la completa contestualizzazione di tale concetto nell’ambito informatico, così dapoterne conoscere appieno i limiti applicativi e poter proporre, in maniera realmente cosciente,tecniche di analisi e risoluzione.

La nuova accezione ha permesso di approcciare le problematiche di ingegnerizzazione dei re-quisiti in modo, a nostro parere, maggiormente consapevole, focalizzando l’attenzione sulla quan-tificazione dell’ignoranza: un aspetto che spesso viene sotteso e che invece, come evidenziatoanche in rapporto alla RE, ha un ruolo assolutamente preminente. L’unione delle conoscenzeottenute e quelle derivate dal framework KAOS hanno portato allo sviluppo di una tecnica di pre-

159

160 C O N C L U S I O N I

venzione almeno parziale, tramite la quale diviene possibile estrapolare le zone del progetto incui si accentrano troppi comportamenti incogniti, prefigurandosi come “aree a rischio emergen-za”. Appurato infatti, e questo è uno dei risultati teorici ottenuti, che non è possibile pensare diimprontare uno studio pro-attivo per la rilevazione e reazione a fenomeni emergenti, in quantola loro aleatorietà impedisce di qualificarli in una fase precedente a quella di testing, è evidenteche la nuova tecnica proposta consente comunque di arricchire considerevolmente il nostro back-ground di conoscenze, diminuendo le criticità di un sistema in fase di sviluppo e, di conseguenza,riducendo la probabilità che si generi un fenomeno emergente.

Lo sviluppo di una tecnica di analisi del “flusso di ignoranza” ha rappresentato la prima eviden-za dell’utilità di un approccio di tipo GORE (quale è KAOS), capace di strutturare efficacemente,in particolare per mezzo di una notazione ad albero, il prodotto della RE. In effetti un altro deitemi topici della tesi è rappresentato proprio dal ruolo di un framework goal-oriented all’internodella RE e, in particolare, nel trattamento dell’emergenza. La centralità di quest’aspetto è divenutairrefutabile con la trattazione relativa allo sviluppo di una tecnica di testing specifica.

Nell’approcciare il problema è parso naturale anzitutto approfondire compiutamente le nozionilimitrofe alla fase di testing e, in particolare, la testabilità di sistemi. La ricca letteratura del settoreha permesso di apprezzare le differenti connotazioni che tale concetto assume nei vari ambitid’uso, consentendoci di estrapolare i connotati base del medesimo e le soluzioni più interessantiin relazione al concetto di emergenza. Le considerazioni offerte sono servite per giustificare ilruolo centrale che, a nostro avviso, KAOS può assumere laddove si intenda effettuare testing susistemi supposti emergenti o dimostrati tali. Il ricorso a considerazioni teoriche, ma anche unapporto pratico dato da un esempio specifico, hanno permesso di palesare il grande contributo cheil goal-tree sviluppato da KAOS può dare nello sviluppo e analisi di un test; permettendo peraltrodi riconsiderare il ruolo degli approcci top-down nella fase di testing, generalmente abbastanzatrascurati. Tale orientamento, pur potendo apparire banale, non era stato preso in considerazionedagli sviluppatori del framework, i quali avevano approntato una attenta analisi focalizzata peròsulla sola fase di RE.

Una piccola parentesi sulle politiche adottabili per correggere condizioni emergenti ha chiusoil corpo centrale della tesi. In particolare, viste le analogie che correlano l’emergenza e la nozionedi Ostacolo, l’analisi si è concentrata proprio sulla Obstacle Analysis di KAOS, cercando di capirele reali possibilità di traduzione nel nuovo ambito.

A conclusione dello studio abbiamo dunque acquisito gli strumenti necessari per trattare l’e-mergenza nella sua interezza:

1. a livello di RE, tramite lo studio dell’ignoranza;

2. a livello di testing, tramite il ricorso al goal-tree di KAOS;

3. per quanto riguarda la correzione delle evidenze emergenti.

L’applicazione (sia pure parziale) di tali strumenti ad un caso di studio reale ha permesso di osser-vare “all’opera” il metodo di studio proposto, permettendo di toccare con mano le tecniche sottesee di apprezzarne il funzionamento generale. In tal senso il metodo ha mostrato una duttilità e unaimmediatezza assolutamente rilevanti, soprattutto se lo si confronta con le tipiche tecniche dianalisi dei requisiti molto più focalizzate e, nonostante ciò, più complesse, sia in termini di costiapplicativi che di tempi correlati. Certamente il risultato di maggior rilievo è rappresentato dall’in-dividuazione di alcuni “nodi d’ignoranza” che, nonostante l’analisi dell’azienda commissionante,permanevano nel progetto dato.

C O N C L U S I O N I 161

Lo studio condotto si è infine concentrato su un focus differente, spostando la propria attenzionesui “COTS Based System”, ambito, sempre più diffuso, in cui l’emergenza diviene contingenzaquotidiana, figlia dell’alta ignoranza che accompagna il ricorso a COTS. Anche in questo casoabbiamo condotto una disamina teorica che ha permesso di evidenziare le pecche (ambientali ecomportamentali) che caratterizzano il settore. Tali competenze sono confluite nella formaliz-zazione di alcune linee guida utili per ottenere un arricchimento conoscitivo ritenuto necessario.

Bibliografia

[1] J. Bowen and V. Stavridou. Safety-critical systems, formal methods and standards. SoftwareEngineering Journal, 8(4):189–209, Jul 1993. (Citato alle pagine 2, 3 e 4.)

[2] John C. Knight. Safety critical systems: challenges and directions. In ICSE ’02: Proceedingsof the 24th International Conference on Software Engineering, pages 547–550, New York,NY, USA, 2002. ACM. (Citato a pagina 2.)

[3] Ian Sommerville. Critical systems engineering. 2000. (Citato alle pagine 2 e 3.)

[4] John Rushby. Critical system properties: Survey and taxonomy. Technical Report SRI-CSL-93-1, Computer Science Laboratory, SRI International, 1994. (Citato a pagina 3.)

[5] Robi Malik. Topics in software engineering, 2004. (Citato a pagina 3.)

[6] Friedemann Bitsch. Safety patterns_ the key to formal specification of safety requirements.Computer Safety, Reliability and Security, pages 176–189, 2001. (Citato alle pagine 4 e 5.)

[7] Zohar Manna and Amir Pnueli. Temporal verification of reactive systems: safety. Springer-Verlag New York, Inc., New York, NY, USA, 1995. (Citato a pagina 4.)

[8] Friedemann Bitsch. A way for applicable formal specification of safety requirements by tool-support. Universität Stuttgart, Germany, Institute of Industrial Automation and SoftwareEngineering (IAS)„ 2002. (Citato a pagina 4.)

[9] Nancy G. Leveson. Safeware: system safety and computers. ACM, New York, NY, USA,1995. (Citato a pagina 4.)

[10] Shing Chi Cheung and Jeff Kramer. Checking safety properties using compositional rea-chability analysis. ACM Trans. Softw. Eng. Methodol., 8(1):49–78, 1999. (Citato apagina 4.)

[11] Friedemann Bitsch. A way for applicable formal specification of safety requirements by tool-support. Universitat Stuttgart, Germany, Institute of Industrial Automation and SoftwareEngineering (IAS)„ 2002. (Citato a pagina 5.)

[12] Sally C. Johnson and Ricky W. Butler. Design for validation. Technical report, 2003. (Citatoalle pagine 6, 7 e 15.)

163

164 B I B L I O G R A F I A

[13] N. Fenton, B. Littlewood, M. Neil, L. Strigini, A. Sutcliffe, and D. Wright. Assessingdependability of safety critical systems using diverse evidence. Software, IEE Proceedings-, 145(1):35–39, Feb 1998. (Citato alle pagine 7 e 14.)

[14] Herbert A. Simon. The architecture of complexity. Proceedings of the AmericanPhilosophical Society, 106(6):467–482, 1962. (Citato alle pagine 7, 49 e 51.)

[15] Vince Darley. Emergent phenomena and complexity. In Artificial Life IV. Proceedings ofthe Fourth International Workshop on the Synthesis and Simulation of Living Systems, pages411–416. MIT Press, 1994. (Citato alle pagine 7, 48 e 53.)

[16] Axel van Lamsweerde. Requirements engineering in the year 00: a research perspective. InICSE ’00: Proceedings of the 22nd international conference on Software engineering, pages5–19, New York, NY, USA, 2000. ACM. (Citato alle pagine 8, 9 e 26.)

[17] Axel van Lamsweerde. Goal-oriented requirements engineering: from system objectivesto uml models to precise software specifications. In ICSE ’03: Proceedings of the 25thInternational Conference on Software Engineering, pages 744–745, Washington, DC, USA,2003. IEEE Computer Society. (Citato alle pagine 8 e 26.)

[18] Bashar Nuseibeh and Steve Easterbrook. Requirements engineering: a roadmap. In ICSE’00: Proceedings of the Conference on The Future of Software Engineering, pages 35–46,New York, NY, USA, 2000. ACM. (Citato alle pagine 10 e 11.)

[19] Axel van Lamsweerde. Formal specification: a roadmap. In ICSE ’00: Proceedings of theConference on The Future of Software Engineering, pages 147–159, New York, NY, USA,2000. ACM. (Citato alle pagine 11 e 20.)

[20] Y Collan P W Hamilton D Thompson R Montironi, W F Whimster and P H Bartels. How todevelop and use a bayesian belief network. Journal Of Clinical Pathology, 49(3):194–201,1996. (Citato a pagina 14.)

[21] Jie Cheng David, David A. Bell, and Weiru Liu. An algorithm for bayesian belief networkconstruction from data. In In Proceedings of AI & STAT?97, pages 83–90, 1997. (Citato apagina 14.)

[22] P. Koopman J. Black. System safety as an emergent property in composite systems. 2008.(Citato alle pagine 15, 52, 53, 56, 58 e 97.)

[23] Melvin E. Dickover, Clement L. McGowan, and Douglas T. Ross. Software design using:Sadt. In ACM ’77: Proceedings of the 1977 annual conference, pages 125–133, New York,NY, USA, 1977. ACM. (Citato a pagina 20.)

[24] Luiz Marcio Cysneiros, Julio Cesar Sampaio do Prado Leite, and Jaime de Melo Sa-bat Neto. A framework for integrating non-functional requirements into conceptual models.Requirements Engineering, 6(2):97–115, 2001. (Citato alle pagine 22 e 23.)

[25] J. Mylopoulos, L. Chung, and B. Nixon. Representing and using nonfunctional requirements:A process-oriented approach. IEEE Trans. Softw. Eng., 18(6):483–497, 1992. (Citato allepagine 22 e 24.)


[26] Barbara Paech, Allen H. Dutoit, Daniel Kerkow, and Antje Von Knethen. Functional re-quirements, non-functional requirements, and architecture should not be separated -a posi-tion paper. Technical report, Proceedings of the International Workshop on RequirementsEngineering: Foundations for Software Quality, 2002. (Citato a pagina 23.)

[27] Luiz Marcio Cysneiros and Julio César Sampaio do Prado Leite. Using uml to reflect non-functional requirements. In CASCON ’01: Proceedings of the 2001 conference of the Cen-tre for Advanced Studies on Collaborative research, page 2. IBM Press, 2001. (Citato apagina 23.)

[28] Julio Cesar Sampaio do Prado Leite, Julio Cesar, Sampaio Prado Leite, Ann Paula M. Franco,and M. Franco. A strategy for conceptual model acquisition. (Citato a pagina 23.)

[29] Lawrence Chung, Brian Nixon, and Eric Yu. Using non-functional requirements to syste-matically select among alternatives in architectural design. In Proc. 1st Int. Workshop onArchitectures for Software Systems, pages 31–43, 1994. (Citato alle pagine 24 e 152.)

[30] Axel van Lamsweerde. Goal-oriented requirements enginering: A roundtrip from researchto practice. In RE ’04: Proceedings of the Requirements Engineering Conference, 12th IEEEInternational, pages 4–7, Washington, DC, USA, 2004. IEEE Computer Society. (Citato apagina 26.)

[31] Axel van Lamsweerde and Emmanuel Letier. Handling obstacles in goal-orientedrequirements engineering, 2000. (Citato alle pagine 26 e 43.)

[32] A. van Lamsweerde, R. Darimont, and E. Letier. Managing conflicts in goal-driven requi-rements engineering. Software Engineering, IEEE Transactions on, 24(11):908–926, Nov1998. (Citato alle pagine 26, 33 e 42.)

[33] A. van Lamsweerde, R. Darimont, and P. Massonet. Goal-directed elaboration of require-ments for a meeting scheduler: problems and lessons learnt. In Requirements Engineering,1995., Proceedings of the Second IEEE International Symposium on, pages 194–203, Mar1995. (Citato alle pagine 26 e 33.)

[34] Anne Dardenne, Stephen Fickas, and Axel van Lamsweerde. Goal-directed concept acquisi-tion in requirements elicitation. In IWSSD ’91: Proceedings of the 6th international work-shop on Software specification and design, pages 14–21, Los Alamitos, CA, USA, 1991.IEEE Computer Society Press. (Citato a pagina 26.)

[35] Emmanuel Letier and Axel van Lamsweerde. Agent-based tactics for goal-oriented require-ments elaboration. In ICSE ’02: Proceedings of the 24th International Conference on Soft-ware Engineering, pages 83–93, New York, NY, USA, 2002. ACM. (Citato alle pagine 26e 35.)

[36] Axel Van Lamsweerde. Goal-oriented requirements engineering: A guided tour. In RE ’01:Proceedings of the Fifth IEEE International Symposium on Requirements Engineering, page249, Washington, DC, USA, 2001. IEEE Computer Society. (Citato alle pagine 26, 27 e 31.)

[37] R. Darimont. Process support for requirements elaboration. Master’s thesis, UniversitéCatholique de Louvain, Faculté des Sciences Appliquées, June 1995. (Citato alle pagine 32e 122.)


[38] Emmanuel Letier. Reasoning about agents in goal-oriented requirements engineering. Ma-ster’s thesis, Université Catholique de Louvain, Faculté des Sciences Appliquées, May 2001.(Citato alle pagine 32, 35, 40, 42 e 85.)

[39] Brendan P. Mahony and Ian J. Hayes. A case-study in timed refinement: A mine pump.IEEE Trans. Softw. Eng., 18(9):817–826, 1992. (Citato a pagina 33.)

[40] Robert Darimont and Axel van Lamsweerde. Formal refinement patterns for goal-drivenrequirements elaboration. In SIGSOFT ’96: Proceedings of the 4th ACM SIGSOFT sympo-sium on Foundations of software engineering, pages 179–190, New York, NY, USA, 1996.ACM. (Citato a pagina 40.)

[41] Hong Yu Wong Timothy O’Connor. Emergent properties, 2006. (Citato a pagina 48.)

[42] George W. Salt. A comment on the use of the term emergent properties. The AmericanNaturalist, 113(1):145, 1979. (Citato alle pagine 48 e 50.)

[43] Peter Cariani. Emergence and artificial life. volume 10, page 23, 1991. (Citato alle pagine 48e 51.)

[44] D.T. Campbell M. H. Bickhard. Emergence, 1998. (Citato a pagina 48.)

[45] Timothy O’Connor. Emergent properties. volume 31, pages 91–104, 1994. (Citato apagina 48.)

[46] M. Privosnik, M. Marolt, A. Kavcic, and S. Divjak. Evolutionary construction of emergentproperties in multi-agent systems. pages 327–330, 2002. (Citato alle pagine 48 e 63.)

[47] H.P.E. Vranken, M.F. Witteman, and R.C. Van Wuijtswinkel. Design for testability in hard-ware software systems. Design & Test of Computers, IEEE, 13(3):79–86, Fall 1996. (Citatoalle pagine 49, 75, 77 e 79.)

[48] C.F. Hawkins, H.T. Nagle, R.R. Fritzemeier, and J.R. Guth. The vlsi circuit test problem-atutorial. Industrial Electronics, IEEE Transactions on, 36(2):111–116, May 1989. (Citato apagina 74.)

[49] H.P.E. Vranken, M.P.J. Stevens, M.T.M. Segers, and J.H.M.M. van Rhee. System-leveltestability of hardware/software systems. pages 134–142, 2-6 1994. (Citato alle pagine 74,75, 77, 78 e 79.)

[50] H.T. Nagle, S.C. Roy, C.F. Hawkins, M.G. McNamer, and R.R. Fritzemeier. Design fortestability and built-in self test: a review. Industrial Electronics, IEEE Transactions on,36(2):129–140, May 1989. (Citato alle pagine 74, 75 e 77.)

[51] T.W. Williams and K.P. Parker. Design for testabilityâATa survey. Proceedings of the IEEE,71(1):98–112, Jan. 1983. (Citato alle pagine 75 e 77.)

[52] Robert V. Binder. Design for testability in object-oriented systems. Commun. ACM,37(9):87–101, 1994. (Citato alle pagine 75 e 77.)

[53] S. Chiu and C.A. Papachristou. A design for testability scheme with applications to datapath synthesis. pages 271–277, 1991. (Citato alle pagine 75 e 78.)


[54] V.D. Agrawal, C.R. Kime, and K.K. Saluja. A tutorial on built-in self-test. i. principles.Design & Test of Computers, IEEE, 10(1):73–82, Mar 1993. (Citato a pagina 80.)

[55] M. Privosnik, M. Marolt, A. Kavcic, and S. Divjak. Evolutionary construction of emergentproperties in multi-agent systems. In Electrotechnical Conference, 2002. MELECON 2002.11th Mediterranean, pages 327–330, 2002. (Citato a pagina 83.)

[56] Rok Sosic. The many faces of introspection. PhD thesis, 1992. Chair-Johnson„ Robert R.(Citato a pagina 83.)

[57] J. Black and P. Koopman. Indirect control path analysis and goal coverage strategies forelaborating system safety goals in composite systems. pages 184–191, Dec. 2008. (Citato apagina 95.)

[58] Nome Non Divulgabile. Specifica tecnica dei requisiti. Aprile 2008. (Citato alle pagine 102,103, 108 e 109.)

[59] Nome Non Divulgabile. Requisiti del sistema di rilevazione incendio. Gennaio 2009. (Citatoalle pagine 102, 103, 105, 106, 108 e 110.)

[60] Marija Rakic and Nenad Medvidovic. Increasing the confidence in off-the-shelf componen-ts: a software connector-based approach. SIGSOFT Softw. Eng. Notes, 26(3):11–18, 2001.(Citato a pagina 135.)

[61] A. Cechich, A. Requile-Romanczuk, J. Aguirre, and J.M. Luzuriaga. Trends on cotscomponent identification. pages 10 pp.–, Feb. 2006. (Citato alle pagine 135, 139, 140e 141.)

[62] Carina Alves, Xavier Franch, Juan P. Carvallo, and Anthony Finkelstein. Using goals andquality models to support the matching analysis during cots selection. COTS-Based SoftwareSystems, pages 146–156, 2005. (Citato alle pagine 135 e 139.)

[63] D. Carney and F. Leng. What do you mean by cots? finally, a useful answer. Software, IEEE,17(2):83–86, Mar/Apr 2000. (Citato alle pagine 136 e 137.)

[64] M. Torchiano and M. Morisio. Overlooked aspects of cots-based development. Software,IEEE, 21(2):88–93, March-April 2004. (Citato a pagina 136.)

[65] V.R. Basili and B. Boehm. Cots-based systems top 10 list. Computer, 34(5):91–95, May2001. (Citato alle pagine 136 e 137.)

[66] B. Warboys, B. Snowdon, R.M. Greenwood, W. Seet, I. Robertson, R. Morrison, D. Balasu-bramaniam, G. Kirby, and K. Mickan. An active-architecture approach to cots integration.Software, IEEE, 22(4):20–27, July-Aug. 2005. (Citato alle pagine 136 e 138.)

[67] B. Boehm and C. Abts. Cots integration: plug and pray? Computer, 32(1):135–138, Jan1999. (Citato alle pagine 136 e 137.)

[68] M. Morisio, C. B. Seaman, A. T. Parra, V. R. Basili, S. E. Kraft, and S. E. Condon. Investi-gating and improving a cots-based software development. In ICSE ’00: Proceedings of the22nd international conference on Software engineering, pages 32–41, New York, NY, USA,2000. ACM. (Citato alle pagine 137 e 153.)


[69] E.J. Weyuker. Testing component-based software: a cautionary tale. Software, IEEE,15(5):54–59, Sep/Oct 1998. (Citato alle pagine 137, 138 e 152.)

[70] Leonardo Mariani, Sofia Papagiannakis, and Mauro Pezze. Compatibility and regressiontesting of cots-component-based software. In ICSE ’07: Proceedings of the 29th internatio-nal conference on Software Engineering, pages 85–95, Washington, DC, USA, 2007. IEEEComputer Society. (Citato alle pagine 137, 151 e 153.)

[71] Michael Mattsson, Jan Bosch, and Mohamed E. Fayad. Framework integration problems,causes, solutions. Commun. ACM, 42(10):80–87, 1999. (Citato a pagina 138.)

[72] VR Basili D Yakimovich, GH Travassos. A classification of software components in-compatibilities for cots integration. pages 10 pp.–, 2000. (Citato alle pagine 138e 139.)

[73] S. Beydeda and V. Gruhn. Merging components and testing tools: the self-testing cotscomponents (stecc) strategy. pages 107–114, Sept. 2003. (Citato alle pagine 138 e 140.)

[74] L. Mariani and M. Pezze. Dynamic detection of cots component incompatibility. Software,IEEE, 24(5):76–85, Sept.-Oct. 2007. (Citato alle pagine 138, 151 e 153.)

[75] Huan-Jyh Shyur. Cots evaluation using modified topsis and anp. Applied Mathematics andComputation, 177(1):251 – 259, 2006. (Citato a pagina 138.)

[76] Cornelius Ncube and Neil Maiden. Cots software selection: The need to make tradeoffsbetween system requirements, architectures and cots components. In In COTS workshop.Continuing Collaborations for Successful COTS Development, 2000. (Citato alle pagine 139e 153.)

[77] P. Donzelli, M. Zelkowltz, V. Basili, D. Allard, and K.N. Meyer. Evaluating cots compo-nent dependability in context. Software, IEEE, 22(4):46–53, July-Aug. 2005. (Citato allepagine 139 e 153.)

[78] Cornelius Ncube and Neil A.M. Maiden. Pore: Procurement-oriented requirements enginee-ring method for the component-based systems engineering development paradigm. In De-velopment Paradigm.? International Workshop on Component-Based Software Engineering,pages 1–12, 1999. (Citato a pagina 139.)

[79] D. Garlan, R. Allen, and J. Ockerbloom. Architectural mismatch: why reuse is so hard.Software, IEEE, 12(6):17–26, Nov 1995. (Citato alle pagine 140 e 151.)

[80] F. Curbera, M. Duftler, R. Khalaf, W. Nagy, N. Mukhi, and S. Weerawarana. Unravelingthe web services web: an introduction to soap, wsdl, and uddi. Internet Computing, IEEE,6(2):86–93, Mar/Apr 2002. (Citato alle pagine 141, 142 e 144.)

[81] Christopher Ferris and Joel Farrell. What are web services? Commun. ACM, 46(6):31, 2003.(Citato a pagina 141.)

[82] Wolf-Tilo Balke and Matthias Wagner. Towards personalized selection of web services. InIn Proc. of the Int. World Wide Web Conf. (WWW, 2003. (Citato alle pagine 142 e 146.)

[83] M. Tian, A. Gramm, H. Ritter, and J. Schiller. Efficient selection and monitoring of qos-aware web services with the ws-qos framework. In Web Intelligence, 2004. WI 2004. Pro-ceedings. IEEE/WIC/ACM International Conference on, pages 152–158, Sept. 2004. (Citatoa pagina 144.)

[84] W.T. Tsai, R. Paul, Z. Cao, L. Yu, and A. Saimi. Verification of web services using anenhanced uddi server. In Object-Oriented Real-Time Dependable Systems, 2003. (WORDS2003). Proceedings of the Eighth International Workshop on, pages 131–138, Jan. 2003.(Citato alle pagine 145, 147 e 153.)

[85] J. Colgrave, R. Akkiraju, and R. Goodwin. External matching in uddi. In Web Services,2004. Proceedings. IEEE International Conference on, pages 226–233, July 2004. (Citato apagina 146.)

[86] Xiaoying Bai, Wenli Dong, Wei-Tek Tsai, and Yinong Chen. Wsdl-based automatic test casegeneration for web services testing. In Service-Oriented System Engineering, 2005. SOSE2005. IEEE International Workshop, pages 207–212, Oct. 2005. (Citato a pagina 147.)

[87] J. Kopecky, T. Vitvar, C. Bournez, and J. Farrell. Sawsdl: Semantic annotations for wsdland xml schema. Internet Computing, IEEE, 11(6):60–67, Nov.-Dec. 2007. (Citato apagina 147.)

[88] W.T. Tsai, R. Paul, Yamin Wang, Chun Fan, and Dong Wang. Extending wsdl to facilitateweb services testing. In High Assurance Systems Engineering, 2002. Proceedings. 7th IEEEInternational Symposium on, pages 171–172, 2002. (Citato alle pagine 147, 150 e 151.)

[89] Michael E. Maximilien and Munindar P. Singh. Agent-based architecture for autonomic webservice selection. (Citato a pagina 149.)

[90] Lawrence Chung and Brian A. Nixon. Dealing with non-functional requirements: threeexperimental studies of a process-oriented approach. In ICSE ’95: Proceedings of the 17thinternational conference on Software engineering, pages 25–37, New York, NY, USA, 1995.ACM. (Citato a pagina 152.)

[91] D.A. Fisher and H.F. Lipson. Emergent algorithms-a new method for enhancing survivabilityin unbounded systems. volume Track7, pages 10 pp.–, 1999. (Citato a pagina 152.)

[92] M.A. Copenhafer and K.J. Sullivan. Exploration harnesses: tool-supported interacti-ve discovery of commercial component properties. pages 7–14, Oct 1999. (Citato apagina 153.)

[93] V. Basili, P. Donzelli, and S. Asgari. A unified model of dependability: capturingdependability in context. Software, IEEE, 21(6):19–25, Nov.-Dec. 2004. (Citato apagina 153.)

[94] Elena Fersman and Tobias Amnell. Production cell case study: Modeling and verifying areal-time system. (Citato a pagina 155.)

[95] Helmut Melcher and Klaus Winkelmann. Controller synthesis for the “production cell” casestudy. In FMSP ’98: Proceedings of the second workshop on Formal methods in softwarepractice, pages 24–33, New York, NY, USA, 1998. ACM. (Citato a pagina 155.)

... one more thing

Ringraziamenti

“La nostra memoria è la nostra coerenza, lanostra ragione, il nostro sentimento, persino ilnostro agire. Senza di essa non siamo nulla.”

Luis Bunuel

Una pagina vuota. Era questa l’idea. Non perché non ci fosse nessuno da ringraziare, ma per-ché le parole, soprattutto queste parole, dovrebbero essere libere, non obbligate da consuetudiniabusate. Pensavo che il dono restituito di un grazie fosse un piacere lieve da spendere assieme,nella vicinanza che giustifica, e che non dovesse essere relegato ad un corollario costretto per ami-ci, professori e parenti. Ma ragioni più valide cercano una voce, perché se nella natura di questolibro è sancita, come dite voi, la fine di una strada intrapresa ormai troppi anni fa, non posso farea meno di pensare che nessun percorso si fa mai da soli e che, certo, in questo percorso non sonostato solo.

Penso alla mia famiglia che mi ha guidato e mia ha protetto e mi ha insegnato senza pretendere.Devo soprattutto a loro queste pagine, queste ore felici.

E penso al resto: alla vita incontrata e scontrata negli anni. Niente nomi, perché i nomi servonosolo ad ego superbi vogliosi di classifiche e attestati. Senza nomi, ma con un rosario di memoriache vale tanto e che mi insegna e mi ricorda: ciò che ero e da cui discendo; ciò che non sono,perché mi avete aiutato a non esserlo; e ciò che sono e che mi avete insegnato ad accettare. Voiche siete stati ragione e scopo nel tempo e del tempo. E che quel tempo avete riempito, plasmato,giustificato, accompagnandomi nel mio modo sgarbato di affrontare i giorni, nonostante i mieisilenzi e i miei difetti. Di notte, a poche ore dalla consegna, ripenso a tutto quel tempo e nondimentico che in ogni passo, in ogni lezione, c’era uno di voi.

Voi stranieri conosciuti appena l’attimo di un ricordo, eppure fissati in un gesto o in un discorso.Voi amici persi per la via, negli errori intesi colpe o nell’innocenza di strade semplicemente diffe-renti. Voi amici sopravvissuti, nonostante l’età che decreta lontananza; sopravviventi, tra le colpeperdonante e le ore ancora assieme. Voi amanti di un sogno o di qualcosa in più: mani perdutenei giorni e mani che stringo tra le mani, sperando di non perderle mai. In voi le risate, le paure,le scoperte, le lacrime. In tutte queste cose, e in tutte quelle che adesso non sovvengono ma sonoimpresse tanto a fondo, ho trovato la forza per combattere la vita e la felicità per amarla.

La citazione di Bunuel non è casuale: voi siete la mia memoria, voi siete la mia storia, voi sietela mia verità (capita o provata a capire). Voi siete in questa parola che scrivo in calce per nondimenticarla più: GRAZIE!

Trattazione del Comportamento Emergente in Sistemi...

Documents

Transcript of Trattazione del Comportamento Emergente in Sistemi...