UNIVERSITÀ DI PISA. Studio ed implementazione di un algoritmo per generare i prodotti validi in Product Family Engineering

Transcript

1 UNIVERSITÀ DI PISA Facoltà di Scienze, Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica Tesi di Laurea Studio ed implementazione di un algoritmo per generare i prodotti validi in Product Family Engineering Relatore Prof.ssa Stefania Gnesi Candidato Aldi Sulova Relatore Dott. Franco Mazzanti Anno Accademico 2010/2011

2 Alla mia famiglia...

3 Sommario Questo lavoro di tesi si colloca all'interno dell'attività di ricerca svolta presso il gruppo di metodi formali dell'isti al CNR di Pisa. I temi principali sono la Product Family Engineering (PFE) ed il Model Checking. Più specicatamente mi sono occupato dell'implementazione di un algoritmo che genera i prodotti validi a partire da un modello astratto di una famiglia di prodotti. Inoltre, è stato realizzato un ambiente che presenta le seguenti funzionalità: 1) descrivere il modello di una famiglia mediante una sintassi ben denita, 2) esprimere vincoli statici e comportamentali sulle funzionalità dei prodotti, 3) generare i prodotti validi, 4) vericare formalmente proprietà sul modello della famiglia e sui singoli prodotti. Il contributo principale e più signicativo è stato nel punto 3, cosa che ha dato il titolo anche a questa tesi. Per realizzare gli obbiettivi il lavoro si è focalizzato sull'attività di ricerca eseguita dal gruppo di metodi formali nell'ambito del PFE, e sull'utilizzo di FMC, un model checker con logica branching basata su azioni (ACTL), per reti di automi deniti come algebra dei processi in un formalismo CCS-like. Come risultato nale è ottenuta una applicazione a linea di comando accessibile anche mediante una più elaborata interfaccia web. ii

4 Indice 1 Introduzione Contributo della tesi Sintesi Product Family Engineering Ingengneria del Software Product Family Engineering La variabilità Model Checking Introduzione Modelli formali Logica Model checking Attività di ricerca Introduzione Esempio della macchina del caè Feature Modelling iii

5 4.4 Logica deontica e Feature Models Modal Transition System MHML, logica temporale in Product Families Proprietà statiche e comportamentali in MHML Generazione dei prodotti validi di una famiglia Il modello di una famiglia Algoritmo per generare i prodotti validi Implementazione Prodotti validi della macchina per caè Validità di una sottofamiglia oppure di un prodotto Osservazioni Interfaccia Web Denire il modello della famiglia Verica di proprietà con VMC Conclusioni e lavoro futuro 69 iv

6 Elenco delle gure 3.1 Modelli per una macchina da caè Signicato degli operatori temporali in LTL Esempi di predicati in CTL Operatori temporali in HML Feature Diagram per la famiglia di macchine da caè MTS per la macchina da caè Passo dell'algoritmo Generazione delle combinazioni LTS della macchina da caè per il mercato europeo LTS della macchina da caè per il mercato statunitense a alternative b, perché non posso tener i prodotti intermedi in MTS VMC, pagina iniziale VMC, scegliere il modello VMC, descivere il modello VMC, modello caricato VMC, lista prodotti validi della famiglia VMC, LTS di un prodotto v

7 6.7 VMC, MTS della famiglia VMC, vericare proprietà sulla famiglia VMC, vericare proprietà sui prodotti vi

8 Capitolo 1 Introduzione I sistemi software sono sempre più complessi, questo fa si che le aziende si orientino verso le cosiddette Product Family. Una Software Product Family [14] è una gamma di prodotti che condivide una base comune di funzionalità. Diversi modelli si ottengono estendendo il prodotto base con caratteristiche aggiuntive per, ad esempio, soddisfare una particolare tipologia di clienti oppure soddisfare mercati di paesi dierenti. Possiamo distinguere due parti in una famiglia, la parte condivisa e la parte estendibile. La parte estendibile viene riferita nel campo con il termine variabilità, e rappresenta quelle funzionalità che sono usate per costruire diversi prodotti della famiglia. Un formalismo ampiamente utilizzato e al quale si fa riferimento in questa tesi per descrivere una famiglia di prodotti è il Feature Modelling [9]. Nella modellazione della variabilità in Feature Modelling, l'interesse sta nel denire quali funzionalità o componenti di un sistema siano opzionali oppure necessari e quali siano le relazioni tra loro. Le relazioni vincolanti ed ulteriori proprietà dei prodotti si possono formalizzare mediante una logica proposizionale [15] e vericate utilizzando algoritmi ecienti per trovare un assegnamento che rende vere le formule (SAT Solvers). In questo modo posso stabilire le 1

9 funzionalità che un prodotto nale deve, non deve, o può avere. Mediante questo procedimento però, non si ha la possibilità di esprimere il comportamento nel tempo dei prodotti e quali caratteristiche nell'evoluzione sono obbligatorie o permesse. Il Modal Transition System (MTS) [8] è riconosciuto come il modello formale per descrivere il comportamento nel tempo delle famiglie di prodotti. Un MTS è simile ad un Labelled Transition System (LTS), ma diversamente dall'lts le transizioni si presentano in due tipi, must e may. Una transizione must indica che l'azione in essa contenuta è obbligatoria, ovvero che ogni prodotto nale deve avere la possibilità di eseguire l'azione, mentre la transizione may indica che un prodotto nale può anche non avere tale possibilità. Questo formalismo esprime in modo naturale le transizioni che devono essere disponibili in un prodotto e quelle che sono transizioni opzionali per estendere il prodotto. Data una famiglia di prodotti, un singolo MTS permette di denire: il comportamento della famiglia mediante stati ed azioni comuni a tutti gli prodotti, transizioni must, la variabilità, ovvero i punti dove il comportamento rende i prodotti estendibili mediante le transizioni may. La logica deontica [3] fornisce un modo naturale per formalizzare concetti come la violazione, obbligo, permesso e divieto. Una logica deontica contiene gli operatori proposizionali logici classici, negazione ( ), congiunzione ( ), disgiunzione ( ), implicazione ( ) a cui sono aggiunti gli operatori deontici. I due principali operatori deontici sono; è obbligatorio che (O) ed è permesso che (P). Una caratterizzazione deontica di un Feature Model è un insieme di formule deontiche la congiunzione delle quali descrive in modo preciso la famiglia dei prodotti. In [1] si descrive anche una caratterizzazione di un MTS con formule deontiche mediante la logica 2

10 proposizionale deontica completa denita in [3]. Quello che è importante dire è che a partire da questi studi si hanno le basi per denire MHML. MHML [2][16] è una logica deontica temporale branching basata su azioni ed interpretata su un MTS, con la quale è possibile esprimere concetti di variabilità su una famiglia di prodotti. In confronto con il Feature Modelling, MHML aggiunge la possibilità di specicare ed analizzare nello stesso ambiente proprietà statiche e comportamentali delle famiglie. I concetti di variabilità trattati in questa tesi e che hanno origine nel Feature Modelling riguardano le funzionalità opzionali espresse mediante le transizioni may nell'mts che descrive la famiglia. In particolare, siamo interessati alla espressione dei seguenti vincoli fra tali funzionalità: a alternative b, solo una delle due funzionalità è presente; a requires b, se a è presente nel prodotto nale anche b lo è; a exclude b, a e b non possono co-esistere nello stesso prodotto; ed alla loro espressione mediante predicati nella logica MHML. Per esempio la formula logica: (EF a true) (EF b true) rappresenta il vincolo a requires b. In ogni prodotto della famiglia questa proprietà deve essere valida. In MHML i vincoli che riguardano le funzionalità alternative, exclude e requires si rappresentano con opportune formule, come vedremo più avanti, simili a quella introdotta precedentemente. Una importante operazione in PFE è derivare tutti i prodotti validi di una famiglia. Il contributo principale di questa tesi è lo studio e l'implementazione di un algoritmo che 3

11 realizza questa operazione. L'algoritmo parte dall'mts che modella la famiglia e dall'insieme di formule esprimenti vincoli di variabilità denite in MHML. Il risultato della sua esecuzione è una lista di prodotti validi: un prodotto valido è un LTS con tutte le azioni presenti in transizioni must della famiglia, la selezione di qualche azione presente in una transizione may, e che rispetta i vincoli espressi in MHML. 1.1 Contributo della tesi L'obbiettivo principale della tesi è l'implementazione di un algoritmo che genera i prodotti validi a partire da un modello astratto di una famiglia di prodotti. Inoltre, è stato realizzato un ambiente di analisi e verica che permette di: descrivere il modello di una famiglia di prodotti mediante una sintassi ben denita, esprimere vincoli statici e comportamentali sulle funzionalità dei prodotti, generare i prodotti validi, vericare formalmente proprietà sul modello della famiglia e sui singoli prodotti. Il contributo principale e più signicativo è stato nel punto 3. Per realizzare gli obbiettivi il mio lavoro si è focalizzato sull'attività di ricerca eseguita dal gruppo di metodi formali nell'ambito del PFE [1][2][16][17], e sull'utilizzo di FMC [12], un model checker con logica branching basata su azioni (ACTL), per reti di automi deniti come algebra dei processi in un formalismo CCS-like. Come risultato nale è ottenuta una applicazione command line accessibile anche mediante una più elaborata interfaccia web. 4

12 1.2 Sintesi Questa tesi è organizzata come segue. Il Capitolo 2 e 3 orono una presentazione sintetica dei concetti principali della tesi, la Product Family Engineering ed il Model Checking. Nel capitolo 4 viene presentato il lavoro di ricerca sul quale si basa questa tesi. Nel capitolo 5 sono descritte le scelte, le problematiche ed i risultati ottenuti. Il capitolo 6 presenta l'interfaccia web ed un semplice esempio su come si può utilizzare. Nel capitolo 7 le conclusioni e qualche possibile lavoro futuro. 5

13 Capitolo 2 Product Family Engineering In questo capitolo si presenta la Product Family Engineering [14]. Inizialmente viene introdotto l'ingengneria del software come una disciplina ormai consolidata per assistere un team di sviluppatori nel processo di realizzazione di un sistema software. Il capitolo procede con una breve descrizione della PFE e del contesto nel quale questo approccio ingegneristico del software presenta dei vantaggi. Inne, viene introdotto il concetto principale di questo paradigma che è la variabilità. Gran parte della ricerca sulla PFE si concentra su questo concetto, inoltre, ha un ruolo importante nella mia tesi in quanto l'algoritmo realizzato per generare i prodotti validi della famiglia deve analizzare modelli che esprimono variabilità. 2.1 Ingengneria del Software Il primo calcolatore data negli anni 40 del secolo scorso. Si trattava di un semplice esecutore automatico di istruzioni in grado di elaborare funzioni pre stabilite. Il programma era cablato dentro la macchina e non c'era possibiltà di cambiarlo. Per eseguire altre 6

14 funzionalità si doveva ricostruire la macchina. In pratica non esisteva la distinzione tra software e hardware. Negli anni 50 vengono in luce i primi linguaggi di programmazione, il linguaggio assembler e successivamente Fortran per calcoli scientici e Cobol per applicazioni gestionali. La tecnologia continuava ad evolversi ma non l'approccio allo sviluppo del software, che si deniva come un processo artigianale dove il programmatore gestiva tutte le fasi: costruzione, manutenzione e utilizzo della applicazione. Negli anni 60 il costo del sviluppo di nuove applicazioni software lievitò drasticamente a seguito di due principali cause: le richieste dal mercato per funzionalità sempre piu complesse, rese disponibili anche dalle nuove potenzialità di calcolo introdotte da nuovi potenti calcolatori, la seria dicoltà del programmatore nel gestire individualmente una quantita di lavoro che aumentava di dimensioni. Il risultato era software poco adabile, troppo costoso e che generalmente non rispettava i termini di scadenza. Queste conseguenze implicavano la impossibilità di continuare a vedere il software come un prodotto artigianale creato da una sola persona, ma come una attività che doveva essere svolta in gruppo. Il software doveva diventare il prodotto di un processo ingegneristico, con compiti dierenziati del personale coinvolto e con metodologie di sviluppo ben denite. Il problema della costruzione di un software doveva essere arontato nello stesso modo adottato dagli ingegneri tradizionali per costruire sistemi grandi e complessi come ponti, navi, aeroplani, ecc. L'obbiettivo era quello di stabilire metodologie, strumenti, teorie e tecniche simili a quelle utilizzate in un approccio ingegneristico classico. Possiamo denire l'ingegneria del software come l'applicazione dell'ingegneria al software. Più precisamente, l'ieee Standard Glossario standard della terminologia 7

15 dell'ingegneria del software(ansi) denisce l'ingegneria del software come l'applicazione di un approccio sistematico, disciplinato e quanticabile nello sviluppo, funzionamento e manutenzione del software. 2.2 Product Family Engineering La diversità del software richiesto dal mercato ha dato origine allo sviluppo di nuove tecniche ingegneristiche. Naturalmente, particolare interesse si è mostrato per i sistemi software complessi e di grandi dimensioni. Le caratteristiche di questo insieme di prodotti hanno portato gli ingegneri del software a considerare la possibilità del riuso degli artefatti software. Varie tecnologie sono state proposte tra le quali "l'object-oriented system development", "software design patterns" oppure il "component-oriented software development". Il riuso si è quindi trasformato in un concetto chiave nel campo. Questo perchè la sua applicazione porta a miglioramenti in termini di produttività, volta alla: riduzione dei costi, non si deve rifare tutto dall'inizio; risposta al mercato, si può avere un prodotto nale in tempi più brevi; qualità, utilizzo di componenti già utilizzati e vericati. Nel contesto del riuso nasce anche la Product Family Engineering. La PFE è un approccio ingegneristico nel processo di sviluppo software nel quale, i prodotti generati condividono una base comune di funzionalità. L'obbiettivo è quello di denire delle metodologie formali per assistere il team di sviluppo nel riutilizzo delle architetture, codice sorgente, test cases, ecc. ai ni di ridurre i costi ed i tempi di messa ad opera di un prodotto. La PFE ha una visione del riuso diversa dalle tecnologie menzionate precedentemente. Si 8

16 passa da una visione opportunistica, dove il team di sviluppatori cerca di utilizzare componenti standard oppure componenti deniti in altri progetti, ad una visione pianicata dove il sistema che rappresenta il dominio applicativo viene progettato specicatamente per praticare un ecace riuso di componenti e architetture. Una famiglia di prodotti è una gamma di prodotti che condivide una base comune di funzionalità. Diversi modelli si ottengono congurando il prodotto base con caratteristiche aggiuntive per, ad esempio, soddisfare una particolare tipologia di clienti oppure soddisfare mercati di paesi dierenti. Si può fare l'esempio di una famiglia di software per macchine da caè. Per soddisfare il mercato europeo la macchina deve accettare come moneta l'euro e avere la possibilità di scegliere il cappuccino. La macchina per il mercato statunitense invece, prende come moneta il dollaro e la possibilità di orire il cappuccino non è obbligatoria. I produttore, quindi, deve riprodurre e/o adattare un suo prodotto un numero di volte pari al numero di tutte le varianti individuate. Questo signica di dover gestire n prodotti diversi anche se questi sono estremamente simili tra loro (il caè, il tè, ecc. sono oerte in tutte le macchine). L'economicità della metodologia sta proprio nella gestione del nucleo comune di tutti i prodotti e nel costo ridotto della gestione delle parti dierenti. I vantaggi di questo approccio sono: analizzare i requisiti per l'intera famiglia e specicare solo le dierenze tra i singoli prodotti invece di descrivere i requisiti per ognuno di questi; riutilizzo degli artefatti software, si intende parte dell'architettura, documentazione oppure codice sorgente, ovvero un qualsiasi prodotto del processo di sviluppo; limitare alcuni tipi di analisi costosi relativi alla qualità del software solo sul nucleo. La PFE si compone di due sotto processi relativamente indipendenti tra loro: la domain engineering e la application engineering. La domain engineering si focalizza nell'iden- 9

17 ticazione degli artefatti software comuni alla famiglia e nell'evidenziazione delle parti variabili che caratterizzano i prodotti. La application engineering si occupa della creazione dei prodotti a partire dalla piattaforma creata nella denizione del dominio. Nella specica di un nuovo prodotto vengono scelte le caratteristiche che il nuovo prodotto deve avere oltre alle caratteristiche di base. 2.3 La variabilità Anché il paradigma del PFE abbia successo si devono attentamente valutare le parti comuni e le parti estendibili dei prodotti della famiglia. La parte congurabile è riconosciuta nel campo con il termine variabilità, e rappresenta quegli aspetti che sono usati per costruire diversi prodotti. Un formalismo ampiamente utilizzato e al quale si fa riferimento in questa tesi per descrivere una famiglia di prodotti è il Feature Model. Nella fase della domain engineering il dominio del sistema software viene rappresentato mediante un insieme di funzionalità e ogni prodotto si caratterizza da una opportuna selezione delle medesime. Le features sono classicate nel modo seguente: optional features, funzionalità opzionali; mandatory features, funzionalità obbligatorie; Si possono denire anche vincoli tra le funzionalità: alternative features, un insieme di funzionalità tra le quali solo una è presente. a require b, se a è presente nel prodotto nale anche b lo è; a exclude b, a e b non possono co-esistere nello stesso prodotto. 10

18 Nella denizione della variabilità l'interesse sta nel descrivere quali funzionalità o componenti di un sistema siano opzionali oppure necessari e quali siano le relazioni tra loro. Successivamente, tecniche e strumenti sono stati sviluppati per stabilire se un prodotto fa parte della famiglia, oppure per derivare un prodotto da una famiglia selezionando le funzionalità o gli componenti che si vuole. 11

19 Capitolo 3 Model Checking In questo capitolo si presenta la tecnica del Model Checking [4]. Una breve introduzione iniziale da una panoramica generale del metodo. Il capitolo procede con la denizione dei modelli formali utilizzati per descrivere un modello di un sistema software, solitamente espresso mediante un sistema di transizioni, cioè grafo orientato formato da nodi e archi. Successivamente si introduce la logica temporale, che consente di formalizzare proprietà relative all'evoluzione nel tempo del sistema. Inne, si presentano i due approcci comunemente utilizzati per scrivere algoritmi di verica che sono il global ed il local model checking. La conoscenza del model checking è necessaria per studiare l'attività di ricerca descritta in dettaglio nel capitolo successivo, dove quest'ultima ha come obiettivo la denizione di un framework logico sul quale si possono esprimere e vericare proprietà su una famiglia di prodotti. Inoltre, per denire in modo corretto la procedura di generazione dei prodotti validi si poteva far riferimento ad algoritmi di model checking, ovvero l'esplorazione dei nodi e degli archi di un sistema di transizioni. 12

20 3.1 Introduzione La tecnica del model checking, introdotta da Clarke, Emerson [4] e contemporaneamente da Quielle e Sifakis agli inizi degli anni '80, è basata su idee estremamente semplici ed è probabilmente uno dei più signicativi avanzamenti della ricerca in informatica di base di questi ultimi decenni. Nella verica tramite model checking il sistema sotto analisi viene descritto con un linguaggio formale e successivamente modellato mediante un sistema di transizione (Kripke Structure oppure Labelled Transition System). Le proprietà da vericare su di esso sono rappresentate tramite un linguaggio preciso e non ambiguo, tipicamente in logica temporale, e la loro soddisfacibilità sul sistema di transizione che modella il sistema viene vericata in modo eciente ed automatico. Se le proprietà non sono soddisfatte una traccia di esecuzione (controesempio) è mostrata al ne di evidenziare perche si ha il fallimento nella verica. In sintesi la verica tramite model checking consiste, dato un sistema di transizione M modello di un sistema e una formula di logica temporale φ, che rappresenta una proprietà che si desidera che M abbia, nel vericare se M soddisfa φ. 3.2 Modelli formali In generale, il comportamento del sistema software viene rappresentato mediante una struttura a grafo, dove i nodi rappresentano gli stati del sistema e gli archi le transizioni tra gli stati. I gra di per se non sono molto espressivi quindi a loro viene aggiunto dell'informazione. Da qui nascono anche i due approcci comunemente utilizzati per formalizzare una descrizione del sistema nelle prime fasi del processo di sviluppo, che sono; 13

21 a) Kripke Structure dove i nodi sono annotati con le proposizioni atomiche (AP, atomic propositions) e, b) Labelled Transition System (LTS), sistemi di transizioni etichettati dove gli archi vengono annotati con le azioni. Le due descrizioni sono ampiamente accettate come delle notazioni formali chiare, semplici e sucientemente astratte. Kripke Structure. Un Kripke Structure K è una tupla K = (S, S 0, R, L, AP) dove: 1. S è un insieme nito di stati; 2. S 0 S è l'insieme degli stati iniziali; 3. R S S è una funzione di transizione totale, ovvero che per ogni stato s R esiste uno stato s' R tale che R(s,s'); 4. L: S 2 AP è una funzione che associa ogni stato con l'insieme delle proposizioni vere in quel stato. Un cammino nella struttura di Kripke K che parte da uno stato s è una sequenza innita di stati π = s 0 s 1 s 2... tale che s = s 0 e per ogni i 0, R(s i,s i+1 ). Labelled Transition System. Un LTS è una tupla L = (S, S 0, Act, ) dove: 1. S è un insieme nito di stati; 2. S 0 S è un l'insieme degli stati iniziali; 3. Act è l'insieme delle azioni; 4. S Act S è la funzione di transizione, (s,a,s') oppure s a s' descrive che il sistema si muove dallo stato s allo stato s' eseguendo l'azione a. 14

22 Un cammino in un LTS L che parte da uno stato s è una sequenza innita di stati e transizioni alternati π = s 0 a 1 s 1 a 2 s 2... tale che s = s 0, a i Act e per ogni i 0, (s i,a i+1, s i+1 ). 3.3 Logica Delle proprietà tipiche che si possono vericare su un sistema modellato mediante un Kripke Structure sono: a partire dallo stato s 0 esiste uno stato s' in qualche cammino dove la proposizione logica p è vera, ovvero: π = s 0 s 1... ed una i 0 tale che s i π e s i (p) = true, a partire dallo stato s 0 si ha un cammino tale che la proposizione logica p è vera su tutti gli stati del cammino. In un LTS una proprietà da vericare può essere: a partire dallo stato s 0 esiste in qualche cammino uno stato s' dove s' π = s 0 a 1 s 1 a 2 s 2... ed una i 0 e a i Act tale che s i b s i+1 e b Act. b s, ovvero: Si può notare come le domande proposte hanno implicitamente il senso del tempo. In un cammino arriverò nel futuro in uno stato con una particolare proprietà (eventually) oppure, tutti gli stati del cammino hanno una qualche proprietà (always). Per logica temporale si intende una logica classica in cui le formule possono essere arricchite da dei quanticatori temporali (always, eventually), anche se questi non hanno alcuna misura esplicita del tempo. La logica predica su variabili di stato della struttura di Kripke oppure sulle azioni di un LTS considerato. Sono interpretate su alberi di computazioni, i cammini possibili di una esecuzione a partire dallo stato iniziale. 15

23 I due tipi di logiche temporali più comunemente utilizzate sono: linear-time logic e la branching-time logic. La nozione qualitativa del tempo è denita sul cammino. Nella logica linear-time in ogni istante esiste un unico possibile successore e quindi un solo possibile stato futuro. In questo senso il tempo è lineare. Questo modello considera il comportamento del sistema come l'insieme di tutti i possibili cammini da uno stato particolare. Un predicato φ è valido se lo è per ogni computazione dell'insieme. Nella logica branching la nozione del tempo non è lineare bensì ha una struttura ad albero, ad ogni istante esiste un insieme di possibili stati successori. Le computazioni sono raggruppate in alberi computazionali le cui ramicazioni rappresentano le diverse possibilità di continuare in una computazione. Una proprietà φ è valida se l'albero di computazione generato da uno stato particolare soddisfa φ. Per rendere più chiari i concetti introdotti prendiamo come esempio due modelli diversi di una macchina da caè. La macchina Figura 3.1: Modelli per una macchina da caè dopo l'inserimento di una moneta può servire il caè oppure il tè. Nel primo modello è il cliente che sceglie la bevanda, nel secondo invece, è la macchina che fa una scelta interna. Tutti a due i modelli hanno lo stesso insieme di computazioni possibili: {(moneta, caè), (moneta, tè)}. Una logica linear-time non sarebbe in grando di distinguere tra i due modelli. In una logica branching-time invece posso esprimere la proprietà: è possibile scegliere un caè dopo aver inserito una moneta. Tale proprietà distingue i due modelli 16

24 di una macchina per caè. In seguito vengono introdotte la LTL (Linear Temporal Logic) e la CTL (Computation Tree Logic), logiche linear-time e branching-time rispettivamente e che vengono interpretate su un Kripke Structure. Inoltre, sono introdote anche la ACTL (Action-Based Computation Logic) e la Hennessy Milner Logic, logiche interpretate su un LTS. Linear Temporal Logic. La logica LTL consente di predicare formule senza alcuna considerazione della struttura ad albero dei cammini eettuati dal sistema nella sua evoluzione dallo stato scelto. Nel vericare la validità di una proprietà devo considerare tutte le possibili computazioni uno ad uno. La formule nella logica LTL sono denite come segue: φ ::= p φ φ 1 φ 2 X(φ) U(φ 1, φ 2 ) F (φ) G(φ) Le formule sono interpretate sui cammini di un Kripke Structure K = (S, S 0, R, I, AP). Un cammino nito è una sequenza nita, non vuota π = s 0...s n 1 di stati s 0,..., s n 1 S tale che (s i, s i+1 ) R per ogni 0 i < n 1. n viene chiamata la lunghezza del cammino, e si denota con π. Un path innito è una innita sequenza π = s 0, s 1, s 2... di stati in S tale che (s i, s i+1 ) R per ogni i 0. La lunghezza di un cammino innito è. Per 0 i < π, π i denota l'i-esimo stato nel cammino π, mentre π i = s i, s i+1,... è la coda del cammino che inizia in s i. In particolare, s 0 = π. Sia K = (S, R, L) un Kripke Structure e sia π un cammino in K, la relazione = è denita induttivamente come: π = p sse p L(π 0 ) π = φ sse π = φ 17

25 π = φ 1 φ 2 sse π = s 1 oppure π = φ 2 π = X(φ) sse π > 1 e π 1 = φ π = G(φ) sse per ogni k con 0 k < π, s k = ϕ π = F (φ) sse esiste k, 0 k < π, con s k = ϕ π = U(φ, ϕ) sse esiste k, 0 k < π, con s k = ϕ e per ogni i, 0 i < k, s i = φ L'operatore temporale X(φ) stabilisce se φ è valido oppure no nel prossimo stato del cammino; G(φ) se φ è valido in tutti gli stati del cammino; F(φ) se prima o poi (in qualche stato nel futuro) φ vale; U(φ, ψ) se ψ diventera vero in uno stato e φ è vero in tutti gli stati visitati precedentemente. Il signicato degli operatori temporali è mostrato nella gura 3.2. Una struttura di Kripke K in uno stato s S soddisfa la formula φ (K, s = φ) Figura 3.2: Signicato degli operatori temporali in LTL se tutti i cammini di K che partono da s soddisfano φ. Computation Tree Logic. Le formule in CTL consentono di predicare sulla struttura ad albero delle possibili computazioni che partono da un determinato stato iniziale. Arrivato in un particolare stato che verica la proprietà p la sua struttura ad albero verica la proprietà q. Cioè si possono esprimere proprietà della forma; per ogni cammino da 18

26 uno stato iniziale s si puo trovare nel futuro uno stato s' tale che la proprietà q vale nel sottoalbero delle computazioni che iniziano in s'. Si può notare come le proprietà riguardano non solo il cammino ma anche un particolare stato nel cammino. Le formule in CTL sono divise in formule di stato (state formula) e in formule di cammino (path formula). Le formule di stato sono aermazioni sul valore di una proposizione atomica in uno stato scelto oppure sulla struttura ad albero delle computazioni che partono da questo stato. Le path formula sono formule sui cammini che partono da uno stato. Per specicare queste proprietà vengono introdotti gli operatori di quanticazione universale ed esistenziale. Formalmente: Formule di Stato: φ ::= true p φ 1 φ 2 φ ϕ ϕ per p proprietà atomica e ϕ una formula di cammino. Formule di cammino: ϕ ::= X(φ) U(φ 1, φ 2 ) F (φ) G(φ) dove φ, φ 1, φ 2 sono state formula. La gura 3.3 illustra il signicato degli operatori temporali. Sia K = (R, S, L) un Kripke Structure e sia s S uno stato qualunque. La relazione = è denita nel modo seguente: K, s = p sse p L(s) K, s = φ sse K, s = φ K, s = φ 1 φ 2 sse K, s = φ 1 oppure K, s = φ 2 K, s = Aϕ sse K, s = ϕ per ogni cammino π di K che inizia in s K, s = Eϕ sse K, s = ϕ per qualche cammino π di K che inizia in s 19

27 Figura 3.3: Esempi di predicati in CTL Gli operatori temporali X, G, F, U sono deniti in maniera uguale come per la logica lineare. Hennessy-Milner Logic. E una logica temporale branching il cui dominio di interpretazione è il Labelled Transition System. Le formule sono denite come segue: φ ::= true false φ 1 φ 2 φ 1 φ 2 [a]φ a φ dove a Act. La logica viene interpretata su un LTS. Sia L = (S, Act, ), la relazione = viene denita induttivamente, L, s = true sse L, s = false L, s = φ 1 φ 2 sse L, s = φ 1 e L, s = φ 2 L, s = φ 1 φ 2 sse L, s = φ 1 oppure L, s = φ 2 L, s = [a]φ sse per ogni a tale che s a s, s = φ 20

28 L, s = a φ sse esiste a tale che s a s e s = φ Il potere espressivo di questa logica è limitato. Si possono esprimere proprietà di una lunghezza nita nell'albero delle computazioni, proprietà che garantiscono il funzionamento per n volte ma non per sempre. La gura 3.4 illustra il signicato degli operatori temporali. Figura 3.4: Operatori temporali in HML Action-based Computation Tree Logic. Come HML anche nella logica ACTL il dominio di interpretazione è il LTS. Gli operatori temporali sono gli stessi con quelli deniti in CTL, solo che in ACTL le proprietà da vericare riguardano le azioni che deniscono il sistema. La sintassi delle formule è denita nel modo seguente: Formule di azioni: Formule di stato: χ ::= true false a Act χ χ χ χ χ φ ::= true false φ 1 φ 2 φ 1 φ 2 Aϕ Eϕ Formule di cammino: ϕ ::= X χ (φ) φ 1 χuφ 2 φ 1 χuχ φ 2 La logica mantiene la struttura della logica denita in [5]. Comunque non è dicile denire gli operatori temporali G ed F da quelli presenti. Valgono le equivalenze: F χ φ = true {true} U χ φ G χ φ = F χ φ 21

29 La relazione = per le formule di azione è denita come segue: a = b se e solo se a = b; a = χ se e solo se a = χ; a = χ χ se e solo se a = χ e a = χ. La semantica degli operatori ACTL si denisce come: sia L = (S, Act, ) L, s = true sempre valido L, s = φ 1 φ 2 sse L, s = φ 1 e L, s = φ 2 L, π = X χ φ sse π > 1 e (s 0, a, s 1 ) e a = χ e s 1 = φ L, π = φ χ U φ sse esiste i 1 tale che L, s i = φ, e per ogni 1 j i 1, L, s j = φ e (s j, a, s j+1 ) e a = χ L, π = φχ U χ φ sse esiste i 2 tale che L, s i = φ e (s i 1, a, s i ) e a = χ, e per ogni 1 j i 1, L, s j = φ e (s j 1, b, s j ) e b = χ 3.4 Model checking La verica tramite model checking consiste, dato un sistema di transizione M modello di un sistema e una formula di logica temporale φ, che rappresenta una proprietà che si desidera che M abbia, nel vericare se M soddisfa φ. In letteratura, due sono gli approcci di model-checking maggiormente applicati per veri- care la validità di una formula logica; global and local model checking. Un algoritmo globale prima costruisce l'intero spazio degli stati del sistema, successivamente algoritmi di ricerca e di etichettatura vengono applicati per trovare particolari stati in cui la 22

30 proprietà desiderata vale. Un inconveniente dell'approccio globale è la generazione anche degli stati che non sono rilevanti per dimostrare la formula, specialmente quando lo spazio degli stati da analizzare diventa troppo grande. Nel modello locale (on-the-y model checking) vengono visitati solo gli stati che sono necessari per dimostrare il valore di verità della formula, espressa rispetto ad un determinato stato iniziale. Un model checker locale può controllare solo una piccola parte della struttura per decidere il problema, la parte che non serve non viene nemmeno costruita. L'algoritmo seguente mostra come viene eettuata l'etichettatura degli stati quando si deve vericare una proprietà della forma E[f 1 U f 2 ] in un model checker globale. Algoritmo: Procedura per etichettare gli stati con formule della forma EU Input: f 1, f 2 T := {s f 2 lable(s)}; for all s T do label(s) := label(s) { E[f 1 U f 2 ]}; end for while T do choose s T ; T := T \ {s}; for all t tale che R(t, s) do if E[f 1 U f 2 ] label(t) e f 1 label(t) then label(t) := label(t) {E[f 1 U f 2 ]}; T := T {t}; end if end for end while In seguito viene illustrato lo pseudo codice di un algoritmo standard di model checking locale. L'algoritmo si basa su una visita breadth-rst oppure depth-rst del sistema di transizione. 23

31 Algoritmo: Procedura per vericare le formule in un model checker locale Input: F:Formula,E:ENV, S:State if caso base: true, false, F = p e p AP then return il risultato else salva l'informazione che sto valutando la formula F nello stato S facendo riferimento all'ambiente E (per esempio, inserisci (F,E,S) in una pila) for all sub-formula F' di F, con S' lo stato successivo ad S, l'ambiente E' aggiornato in S' do chiama ricorsivamente (F', E', S'); if il risultato di (F', E', S') è suciente per stabilire il risultato di (F, E, S) then esci dal ciclo for; end if end for A questo punto abbiamo un risultato. Rimuovi (F, E, S) dalla pila. return il risultato end if L'algoritmo realizzato per generare i prodotti validi e che viene descritto in dettaglio nel capitolo 5, è simile ad un algoritmo di model checking locale. Viene esplorato lo spazio degli stati mantenendo informazione su quello che si è visto no allo stato corrente. La parte alla quale si fa più riferimento è la gestione dell'ambiente da passare al prossimo passo nell'algoritmo. 24

32 Capitolo 4 Attività di ricerca In questo capitolo si presenta il lavoro teorico realizzato dal gruppo dei metodi formali del CNR di Pisa [1][2][16][17]. Viene descrito il framework logico creato e su come questo è utilizzato per esprimere: a) un modello di una famiglia di prodotti e, b) variabilità statica e comportamentale. Inizialmente si introduce il Feature Modelling [9], un formalismo ampiamente utilizato per descrivere una famiglia di prodotti. Successivamente si descrive la logica deontica [3] e si mostrano le sue capacità di caratterizzare un Feature Model, creando le basi per un struttura logica sulla quale esprimere proprietà delle famiglie. Con l'introduzione anche del Modal Transition System [8], formalismo capace di descrivere in modo naturale il comportamento di una famiglia, si ha il supporto teorico necessario per denire MHML [2][16]. MHML è una logica deontica temporale branching basata su azioni, interpretata su un MTS, per esprimere in una famiglia di prodotti concetti di variabilità. In confronto con il Feature Modelling, MHML aggiunge la possibilità di specicare nello stesso framework anche proprietà comportamentali delle famiglie di prodotti. 25

33 4.1 Introduzione Una famiglia è un insieme di prodotti che condividono una base comune di funzionalità. Diversi modelli si ottengono estendendo il prodotto base con caratteristiche aggiuntive per soddisfare una particolare tipologia di clienti oppure per soddisfare mercati di paesi digerenti. Quindi possiamo distinguere due parti in una famiglia, la parte condivisa e la parte estendibile. La parte estendibile viene riferita nel campo con il termine variabilità, e rappresenta quei aspetti che sono usati per costruire diversi prodotti della famiglia. La modellazione della variabilità è stata ampiamente studiata in letteratura, soprattutto quella relativa al Feature Modelling (sezione 4.3). In questo formalismo l'interesse nella modellazione della variabilità sta nel denire quali funzionalità o componenti di un sistema siano opzionali oppure necessari e quali siano le relazioni tra loro. Successivamente, tecniche e strumenti sono stati sviluppati per stabilire se un prodotto fa parte della famiglia, oppure per derivare un prodotto da una famiglia selezionando le funzionalità o i componenti che si vuole. 4.2 Esempio della macchina del caè Per rendere più chiaro il contenuto di questo capitolo prendiamo un semplice esempio di una famiglia di macchine per caè. Le seguenti regole caratterizzano i prodotti di questa famiglia: 1. La macchina viene attivata da una moneta. Le monete accettate sono quella da un euro (1e) per i prodotti del mercato europeo, e quella da un dollaro (1$) per i prodotti del mercato statunitense. 26

34 2. Dopo aver inserito una moneta, l'utente deve scegliere se vuole lo zucchero o meno, per poi continuare con la selezione della bevanda. 3. La scelta delle bevanda (caè, tè, cappuccino) dipende dal prodotto. Ogni macchina deve dare la possibilità di scegliere il caè, inoltre la scelta del cappuccino deve essere disponibile solo nelle macchine per il mercato europeo. 4. Dopo aver preparato il caè la macchina può emettere un suono. Il suono ci deve essere dopo la preparazione del cappuccino. 5. La macchina ritorna sul suo stato iniziale non attivo dopo che l'utente ha preso la bevanda. I requisiti 1, 3 e parzialmente anche il 4, sono considerati come aspetti statici della famiglia. Non riguardano il comportamento nel tempo dei prodotti ma semplicemente quelle funzionalità che un prodotto nale può o non può avere. I requisiti 2 e 5 e parzialmente il 4 invece, sono vincoli su quello che deve essere il comportamento dei prodotti validi della famiglia. 4.3 Feature Modelling Un formalismo ampiamente utilizzato per descrivere una famiglia di prodotti è il Feature Modelling. Nella fase del domain engineering (vedi sezione 2.2) il dominio del sistema software viene rappresentato mediante un insieme di funzionalità (feature) e ogni prodotto si caratterizza da una opportuna selezione di quest'ultime. Le feature sono classicate nel modo seguente: optional feature, funzionalità opzionale, è presente solo se il padre lo è; 27

35 mandatory feature, funzionalità obbligatoria, è presente se e solo se il padre lo è; Si possono denire anche vincoli tra le feature: alternative features, un insieme di funzionalità tra le quali solo una è presente. a require b, se a è presente nel prodotto nale anche b lo è; a exclude b, a e b non possono co-esistere nello stesso prodotto. Una rappresentazione graca di un Feature Model è il Feature Diagram; le features sono i nodi di un albero nel quale la famiglia è la radice. Il Feature Diagram della macchina per caè introdotta nel paragrafo 4.2 viene mostrato nella gura 4.1. Figura 4.1: Feature Diagram per la famiglia di macchine da caè 4.4 Logica deontica e Feature Models La logica deontica fornisce un modo naturale per formalizzare concetti come violazione, obbligo, permesso e divieto. Una logica deontica contiene gli operatori proposizionali logici classici, negazione( ), congiunzione( ), disgiunzione( ), implicazione( ) ed aggiungendo gli operatori deontici. In questa ricerca sono considerati solo i due principali operatori 28

36 deontici; è obbligatorio che (O) ed è permesso che (P). Nelle classiche versioni della logica vale la proprietà duale: P (α) = O( α), qualcosa è permessa se e solo se la sua negazione non è obbligatoria. Una caratterizzazione deontica di un Feature Model è un insieme di formule deontiche, la congiunzione delle quali, descrive in modo preciso la famiglia dei prodotti. La costruzione viene denita nel modo seguente: Se A è una feature e, A 1 e A 2 sono due sub-feature (alternative, opzionali oppure obbligatorie), allora aggiungi la formula: A = Φ(A 1, A 2 ), dove la formula Φ(A 1, A 2 ) vale: Φ(A 1, A 2 ) = (O(A 1 ) O(A 2 )) (P(A 1 ) P(A 2 )) se A 1 e A 2 sono marcati come due feature alternativi, altrimenti la formula Φ(A 1, A 2 ) vale: Φ(A 1, A 2 ) = φ(a 1 ) φ(a 2 ), dove A i, per i {1,2}, è denita come: P (A i ), φ(a i ) = O(A i ), se A i è opzionale; se A i è obbligatorio. se A requires B, allora aggiungi la formula: 29

37 A = O(B) se A excludes B, allora aggiungi la formula: (A = P(B)) (B = P(A)) Applichiamo la costruzione appena denita all'esempio della macchina del caè introdotta nel paragrafo 4.2. Le formule deontiche risultanti sono: O(Moneta) O(Bevanda) P(Suono) Moneta = (O(1$) O(1e)) (P(1$) P(1e)) Bevanda = O(Caè) P(Tè) P(Cappuccino) Cappuccino = O(Suono) (1$ = P(Cappuccino)) (Cappuccino = P(1$)) Mediante la caratterizzazione con formule deontiche di un Feature Model posso stabilire se un prodotto appartiene alla famiglia. Prendiamo per esempio le formule denite qui sopra e supponiamo di avere due modelli della macchina da caè: CM1 = {Moneta, 1e, Bevanda, Caè} CM2 = {Moneta, 1e, Bevanda, Caè, Cappuccino} La macchina CM1 soddisfa la caratterizzazione deontica della macchina da caè ed è quindi un prodotto corretto della famiglia. La CM2 non soddisfa le formule deontiche in quanto rende falso il vincolo che dopo aver preparato il cappuccino si deve emettere un suono. L'appartenenza (oppure la non appartenenza) si può vericare formalmente rappresentando queste formule come una lista di assiomi messi in congiunzione. La formula 30

38 risultante sarà vera se il prodotto appartiene alla famiglia e falsa altrimenti. Il problema di trovare un prodotto che soddisfa la caratterizzazione deontica di un Feature Model si può rappresentare come il problema di trovare un assegnamento che rende vera la congiunzione delle formule (SAT). Algoritmi ecienti per SAT si possono utilizzare per risolvere questi tipi di problemi. Abbiamo dimostrato che la logica deontica è un formalismo che in modo naturale riesce ad esprimere nozioni di permesso ed obbligo, fondamentali nel gestire la variabilità nello sviluppo di Product Families. Si può notare che gli Feature Models esprimono solo gli aspetti statici di una famiglia di prodotti. Per descrivere anche come i prodotti evolvono nel tempo e quali caratteristiche nell'evoluzione sono obbligatorie o permesse, si deve ricorrere ad un formalismo che riesce a descrivere queste particolarità. Uno dei formalismi più utilizzati in questo contesto è il Labelled Transition System (vedi sez. 3.2). Con gli LTSs però, non si ha la possibilità di distinguere tra le azioni possibili e quelle necessarie, per questo che vengono introdotti gli Modal Transition Systems. 4.5 Modal Transition System Il Modal Transition System (MTS) è riconosciuto come il modello formale per esprimere il comportamento nel tempo delle famiglie dei prodotti. Un MTS è un LTS dove le transizioni sono di due tipi, must e may. Una transizione must indica che l'azione in essa contenuta è obbligatoria, ovvero che ogni prodotto nale deve avere la possibilità di eseguire l'azione, mentre la transizione may indica che un prodotto nale può anche non avere tale possibilità. Questo formalismo esprime in modo naturale le transizioni che devono essere disponibili in un prodotto e quelle che sono transizioni opzionali da aggiungere al prodotto. Data una famiglia di prodotti un singolo MTS permette di denire: 31

39 il comportamento della famiglia mediante stati ed azioni comuni a tutti gli prodotti, transizioni must, la variabilità, ovvero i punti dove il comportamento rende i prodotti congurabili, mediante gli transizioni may. Modal Transition System. Un MTS è una quintupla (Q, A, q 0, δ, δ ), e ha due relazioni di transizione distinte: δ Q A Q è la relazione may che esprime le transizioni possibili, δ Q A Q è la relazione must che stabilisce chi sono le transizioni obbligatorie. Per denizione una transizione obbligatoria è anche permessa, δ δ. L'MTS per la macchina da caè dell'esempio introdotto nel paragrafo 1 è visualizzato nella gura 4.2. Le transizioni may sono rappresentate da frecce tratteggiate mentre quelle must da frecce solide. Figura 4.2: MTS per la macchina da caè Cammino must. Sia M un MTS, σ è una must path (da q 0 ) in M se q i a i+1 q i+1, per ogni 32

40 i 0. L'insieme di tutti i cammini must da q 0 si denota con -path(q 0 ). Un cammino must si denota con σ. Famiglie di un MTS. Sia M = (Q, A, q 0, δ, δ ) un MTS. L'insieme delle famiglie possibili di M si possono rappresentare mediante gli MTSs {M i = (Q i, A, q 0, δ i, δ i ) i 0}, dove preso R i insieme delle transizioni trasformate da may a must, si ha δ i δ i δ \ R i e δ R i. Gli stati Q i sono un sottoinsieme di Q (Q i Q) tale che q 0 Q i, e per ogni q Q i esiste un cammino da q 0 in q con transizioni in δ i δ i. Formalmente: M i è una sottofamiglia di M con R i insieme di transizioni may trasformati in must, M i M, se e solo se vale q i 0 q 0, dove q i q, per qualche q i Q i e q Q vale se e solo se: se q q i q e, se q a q, per qualche q Q, allora q i Q i tale che q i a i q i e a q denita in R i, per qualche q Q, allora q i Q i tale che q i a i q i e q i q e, se q i a i q i denita in δ \ R i, per qualche q i Q i, allora q Q tale che q a q e q i q. Si può notare che quando δ i = le transizioni dell'mts risultante sono tutti must. In questo caso l'mts è equivalente ad un LTS dove le transizioni sono tutte obbligatorie e non si distingue tra must e may. Nella sezione 4.4 abbiamo mostrato le capacità della logica deontica a modellare una famiglia di prodotti, descrivendo una trasformazione da un Feature Model in una congiunzione di formule logiche. In questa sezione abbiamo introdotto il Modal Transition System come formalismo che riesce ad esprimere in maniera naturale il comportamento di 33

41 una famiglia di prodotti. In [1] viene descritto come caratterizzare un MTS con formule deontiche mediante la logica proposizionale deontica completa denita in [3]. Si rimanda alla lettura degli articoli per approfondire il procedimento. Quello che è importante dire è che a partire da questi studi si hanno le basi per denire un framework logico per esprimere proprietà statiche e comportamentali sulle famiglie di prodotti. Il risultato è una nuova logica temporale con operatori modali deontici che vengono interpretati in maniera naturale in un MTS. 4.6 MHML, logica temporale in Product Families MHML è una logica temporale branching basata su azioni simile alla logica Henessy-Milner con Until[5], aggiungendo anche il quanticatore esistenziale ed universale da CTL. Il suo dominio di interpretazione è un MTS. MHML è composta da formule di stato φ, formule dei cammini π e formule di azioni ϕ (vedi sezione 3.3, action-based logic) deniti su un insieme di azioni atomiche Act ={a, b,...}. La sintassi della logica MHML è denita come segue: State Formula: φ ::= true φ φ φ a φ [a]φ Eπ Aπ Path Formula: π ::= φ{ϕ}u{ϕ }φ φ{ϕ}u {ϕ }φ Action Formula: ϕ := true false a Act ϕ ϕ ϕ ϕ ϕ Il fatto che MHML viene interpretata su un MTS fa si che le classiche modalita box e diamond, abbiano una interpretazione deontica. Il signicato non formale degli operatori di MHML è come segue: a φ: esiste uno stato, raggiungibile da una transizione must(a) con a Act dove φ è valida, 34

42 [a]φ: in tutti gli stati, raggiungibili da una transizione must(a) oppure may(a) con a Act, φ è valida, Eπ: esiste un camino nel quale π è valida, Aπ: in tutti i camini, π e valida, φ{ϕ} U {ϕ }φ : esiste uno stato nel cammino raggiungibile da una azione che soddisfa ϕ dove φ è valida e φ vale in tutti gli stati precedenti a questo stato nel cammino, le azioni nel cammino soddisfano ϕ; φ{ϕ} U {ϕ }φ : come sopra, ma in questo caso il cammino che porta allo stato in futuro dove φ vale è un cammino must. La semantica formale di MHML viene interpretata in un MTS. Sia (Q, A, q 0,, ) una MTS, sia q Q e sia σ un cammino. La relazione di soddisfacibilità di MHML è denita da: q = true, sempre valida q = φ, se e solo se q = φ q = φ φ se e solo se q = φ e q = φ q = a φ se e solo se q Q : q a q e q = φ q = [a]φ se e solo se q Q: q a q, vale q = φ q = Eπ se e solo se σ path(q) : σ = π q = Aπ se e solo se σ path(q) : σ = π 35

43 q = φ {ϕ} U {ϕ } φ se e solo se j 1 : σ(j) = φ, σ{j} = φ e σ(j + 1) = φ, e i, 1 i j : σ(i) = φ e σ{i} = φ q = φ {ϕ} U {ϕ } φ se e solo se σ è un cammino must σ e σ = φ {ϕ} U {ϕ }φ La regola della dualità in Henessy-Milner, la quale stabilisce che a φ è equivalente a [a] φ, non vale in MHML. La [a] φ corrisponde ad una versione piu debole dell'operatore classico diamond e che viene denotata con P (a)φ: esiste uno stato, raggiungibile da una transizione may(a) con a Act e φ valida. Formalmente, sia (Q, A, q 0,, ) un MTS, sia q Q, allora: q = a φ se e solo se q Q : q a q e q = φ. Una esempio di una formula ben denita in MHML è: [a](p(b) true (φ = c true)), dopo l'esecuzione di una azione a, il sistema si trova in uno stato nel quale: 1) è permesso eseguire l'azione b (una transizione may(b)) e, 2) quando la formula φ è valida allora l'esecuzione di c è obligatoria(una transizione must(c)). Altri operatori logici si possono derivare da quelli sopra deniti: false è equivalente a ( true), φ φ a ( φ φ ) e φ φ a φ φ. F φ è equivalente a (true {true} U {true} φ), esiste uno stato nel futuro dove φ vale. F{ϕ} true è equivalente a (true {true} U {ϕ} true), esiste uno stato nel futuro raggiungibile da una transizione che soddisfa ϕ. F è equivalente a (true {true} U {true} φ), esiste uno stato nel futuro raggiungibile da un cammino must dove φ vale. AG φ è equivalente a EF φ, in tutti gli stati di tutti i cammini φ vale. AG φ è equivalente a EF φ, in tutti gli stati di tutti i cammini must, φ vale. 36

44 4.7 Proprietà statiche e comportamentali in MHML MHML arricchisce la descrizione comportamentale di un MTS con ulteriori concetti di variabilità. Questo viene realizzato aggiungendo vincoli sulle azioni che compongono i prodotti di una famiglia. Mediante MHML si possono denire proprietà statiche e comportamentali che un MTS non riesce ad esprimere. Tornando all'esempio della macchina del caè i requisiti si possono formalizzare con le seguenti formule. Per la parte statica: Le azioni 1e e 1$ sono alternativi (1e alternative 1$), requisito 1. ((EF 1e true) (EF 1$ true)) ((EF P(1e) true) (EF P(1$) true)) Il cappuccino non deve essere disponibile in prodotti per il mercato statunitense (cappuccino excludes 1$), seconda parte del requisito 3. ((EF P(cappuccino) true) = (AG P(1$) true)) ((EF P(1$) true) = (AG P(cappuccino) true)) Le macchine che orono il cappuccino devono emettere un suono (cappuccino requires suono), requisito 4. (EF P(cappuccino) true) = (EF suono true) Il requisito 2 rappresenta un vincolo sul comportamento dei prodotti della famiglia. Un caè non si può consegnare se non si è inserito la moneta prima. In MHML si può denire con la formula seguente: 37

45 A [ true { caè} U {1e 1$} true] L'applicazione delle formule divide la famiglia originale in sottofamiglie. Le sottofamiglie sono degli MTSs con le transizioni must, qualche may cambiato in must e le rimanenti transizioni may dell'mts iniziale (vedi denizione dell'mts nella sezione 4.5). Ad esempio la formula che esprime il vincolo 1e alternative 1$ crea due sottofamiglie. Nella prima rimuovo la transizione s 0 s 0, s 0 dollar s 1 e modico l'altra transizione uscente dallo stato euro s 1, da may a must. Si procede in modo simile anche per la seconda sottofamiglia e si può notare che la formula esprimente il vincolo alternative addesso è valida per entrambi i casi. 38

46 Capitolo 5 Generazione dei prodotti validi di una famiglia In questo capitolo si presenta il lavoro eseguito. Inizialmente si descrive un modello testuale per denire una famiglia di prodotti. Successivamente viene introdoto l'algoritmo per generare i prodotti validi e vengono descritte le principali procedure implementate. Il risultato nale è uno modulo nel linguaggio di programmazione Ada [10] [11] aggiunto al model checker FMC [12] per includere su questo la procedura di generazione. 5.1 Il modello di una famiglia Come abbiamo denito nel capitolo precedente una famiglia di prodotti è un MTS più una serie di vincoli espressi nella logica temporale MHML. Per rappresentare un MTS è suciente l'utilizzo dell'operatore di ricorsione e dell'operatore della scelta non deterministica oltre ad una chiara distinzione tra i due tipi d'archi. Nella macchina del caè per esempio lo stato iniziale viene modellato come: 39

47 T0 = may(1e).t1 + may(1$).t1 L'interpretazione è abbastanza intuitiva, nello stato T0 ho due scelte possibili che sono permesse ma non obbligatorie. Per denire i vincoli invece, sono utilizzate le parole chiave ALT, EXC e REQ che rappresentano le formule dei vincoli alternative, exclude e requires rispettivamente. L'esempio della macchina del caè mediante questo formalismo si può denire nel modo seguente: Modello della macchina da caè T0 = may(dollar).t1 + may(euro).t1 T1 = must(sugar).t2 + must(no_sugar).t3 T2 = must(coee).t4 + may(tea).t5 + may(cappuccino).t6 T3 = may(cappuccino).t7 + may(tea).t8 + must(coee).t9 T4 = must(pour_sugar).t9 T5 = must(pour_sugar).t7 T6 = must(pour_sugar).t7 T7 = must(pour_coee).t10 T8 = must(pour_tea).t11 T9 = must(pour_coee).t11 T10= must(pour_milk).t11 T11= may(no_ring).t12 + may(ring_a_tone).t12 T12= must(cup_taken).t0 net SYS = T0 Constraints { dollar ALT euro dollar EXC cappuccino cappuccino REQ ringatone } Un semplice confronto con FMC penso che sia necessario. L'MTS che descrive il comportamento della famiglia si può denire mediante un'algebra di processi sequenziali in un formalismo CCS-like, quest'ultima è anche la sintassi utilizzata per descrivere i modelli in FMC. Il processo a.p esegue l'azione a per poi comportarsi come il processo P. Nello 40

48 stesso modo un prodotto dell'mts può eseguire l'azione euro nello stato T0 per spostarsi successivamente nello stato T1 e comportarsi come se T1 fosse lo stato iniziale. Si può notare anche la sintassi utilizzata per distinguere le azioni must da azioni may, costrutti che in FMC si deniscono come "typed actions". 5.2 Algoritmo per generare i prodotti validi Inizio questo paragrafo con una osservazione. Per implementare l'algoritmo si possono seguire due approcci di base, quello globale oppure quello locale. Nell'approccio globale inizialmente vengono generate tutte le famiglie dell'mts e successivamente vericata la validità delle formule che rappresentano i vincoli. Da notare che questo modello introduce ridondanza, nel senso che sottofamiglie oppure prodotti vengono valutati molte volte perchè presenti in una sottofamiglia già valutata. Nell'approccio locale invece, ogni volta che aggiungo un arco verico le formule. Risulta più eciente in una situazione dove la famiglia si presenta con un numero abbastanza grande di archi may e vincoli tra loro. Questo perchè posso tagliare interi sottoalberi a causa della non soddisfazione di qualche vincolo. Nell'approccio locale però, tenere gli archi may in prodotti intermedi è complicato come sarà descritto nella sezione 5.6. In quanto siamo interessati alla generazione dei prodotti nali penso che la scelta ottimale sia quella di generare i prodotti nali di un MTS seguendo l'approccio locale. In questa sezione viene descritto un algoritmo per generare i prodotti validi di una famiglia. Un prodotto valido nale è un LTS dove gli archi sono tutti obbligatori e non esiste la distinzione fatta per MTS nel quale gli archi sono di due tipi, archi possibili e archi obbligatori. L'algoritmo parte dall'mts che modella la famiglia e dall'insieme di formule espresse in MHML. Il risultato è un sottoinsieme dei prodotti possibili di un MTS (vedi 41

49 denizione delle famiglie di un MTS, sezione 4.5); un elemento di questo sottoinsieme è un LTS con tutte le azioni presenti in una transizione must, qualche azione presente nelle transizioni may e che rispetta i vincoli espressi in MHML. L'idea dell'algoritmo è di costruire LTSs intermedi che sono i prodotti dell'mts seguendo la logica sopra descritta e che sono composti dalle azioni e dagli stati no ad uno particolare stato della famiglia. Prendiamo l'esempio dell'mts della macchina per caè mostrato in gura 5.1, dallo stato iniziale ho 4 possibili LTSs intermedi: Figura 5.1: Passo dell'algoritmo Un passo generale dell'algoritmo viene denito come: aggiungi ad un LTS intermedio un arco dell'mts iniziale e verica le formule che esprimono i vincoli alternative ed exclude, continuando solo con gli LTSs che soddisfano le formule. Quando non è più possibile eseguire altri passi perchè abbiamo analizzato tutti gli stati e tutti gli archi dell'mts, esegui la verica nale delle formule dei vincoli alternative (vedi in seguito) e requires. La verica nale della formula del vincolo alternative è necessaria in quanto l'algoritmo in un passo intermedio verica semplicemente che nell'lts non siano presenti entrambi gli operandi della formula ma non che almeno uno di questi sia presente. In questo senso è necessario eseguire la verica nale in modo da selezionare quei prodotti nali dove almeno uno dei operandi ci sia. Consideriamo la proprietà: 1e e 1$ sono alternativi. L'algoritmo prende uno ad uno le situazioni illustrate nella gura 5.1. Per ognuna di queste verica la validità della formula che esprime il vincolo alternative: (EF 1$ true EF 1e true) (EF P(1$) true EF P(1e) true) 42

50 Qui si deve fare una precisazione. Le formule sono interpretate su un MTS e quindi il procedimento sopra introdotto è sensato se diciamo che un prodotto valido, ovvero l'lts, in realtà è un MTS dove le transizioni sono tutte must. Se si considera l'lts come dominio dell'interpretazione delle formule allora si deve utilizzare una logica simile a MHML ma senza l'interpretazione deontica degli operatori box e diamond. La formula si trasforma in: (EF 1$ true EF 1e true) (EF 1$ true EF 1e true) All'inizio di questo lavoro si pensava ad un algoritmo che poteva generare anche le sottofamiglie valide, ma questo è complicato come sarà descritto in dettaglio nella sezione 5.6. Quindi per esprimere i vincoli è suciente una logica simile ad MHML ma senza l'interpretazione deontica degli operatori box e diamond, osservazione presa in considerazione anche in [6]. Ritornando all'esempio, per ognuno degli LTSs intermedi si può dire che l'algoritmo continuerà a procedere in avanti solo nei casi (ii) ed (iii). In questo modo si garantisce che negli LTSs nali almeno una delle due azioni in relazione è presente. Riassumendo, il problema si può specicare come: data una MTS M ed un insieme Φ di vincoli sulle azioni, espressi mediante formule φ i in MHML per i 0, derivare un insieme P di LTSs L j, per qualche j 0, tale che per ogni t 0 e t j, P t M e P t = φ i per ogni i 0. Passo di generazione. Un passo di generazione generate(m,p,l,q) si applica ad uno stato p dell'mts M e ad uno stato q di un LTS L intermedio. In particolare, q è una foglia non visitata prima (non ci sono archi in uscita). I possibili eetti dell'applicazione di un passo generate(m,p,l,q) sono: 43

51 si aggiunge uno stato q' ed un arco q a q' all'lts L in corrispondenza ad uno stato p' e ad un arco p a p' dell'mts M, come sopra ma si aggiunge solo l'arco in quanto lo stato q' dell'lts L risulta visitato in un passo precedente, si crea una copia L' di L se q contiene archi may in uscita, esegue i passi 1) e/o 2) ed aggiunge L' nell'insieme degli LTSs intermedi, si marca q come visitato a causa della applicazione di una delle prime due regole qui sopra, si aggiorna l'insieme D dei passi di generazione di L che l'algoritmo deve eseguire successivamente, da notare che ogni LTS intermedio ha il suo insieme D di passi di generazione. Prima di introdurre l'algoritmo faccio due considerazioni. La prima riguarda gli archi must e may. Per semplicità, quando si parla di un arco may non sono inclusi gli archi must, diversamente da come abbiamo denito l'mts nella sezione 4.5. La seconda riguarda le formule. L'inisieme Φ contiene le formule dei vincoli exlude ed alternative mentre Φ REQ contiene solo la formula del vincolo requires. Algoritmo di generazione. L'algoritmo inizia con la MTS M, l'insieme delle formule Φ ed un ambiente di lavoro P = {L}. L'insieme dei passi di generazione D di L inizialmente contiene solo generate(m, q 0, L, q 0 ) e L solo lo stato iniziale q 0 di M. L'algoritmo esegue un passo di generazione da un qualche D, no a quando tutti gli D non sono vuoti. Un passo di generazione generate(m, p, L, q) è denito nel modo seguente: 1. Per ogni arco must(a), p a p, in M : 44

52 (a) se p = p', aggiungi l'arco q a q a L, (b) se lo stato p è stato visitato in qualche passo di generazione generate(m,p',l,q') oppure è stato aggiunto nel passo corrente da un arco p b p, allora aggiungi l'arco q a q a L; (c) altrimenti aggiungi uno stato q' e una nuovo arco q a q a L, e aggiungi il passo di generazione generate(m,p',l,q') a D; (d) inne, marca q come visitato e per ogni formula φ Φ \ Φ REQ dove l'azione a occorre, verica se L = φ. Se L = φ, rimuovi L dall'ambiente di lavoro P; 2. Per tutti gli archi may(a 1 )... may(a n ), p a 1 p 1... p an p n, in M, il passo 1) deve essere ripetuto per ogni combinazione degli archi, ovvero per ogni Act a 1...a n : (a) aggiungi una copia L Act di L nell'ambiente di lavoro P, (b) per ogni arco may p a p j in M dove 1 j n e tale che a j Act: se p j = p, aggiungi un arco q a j q in L Act : se p j risulta visitato in un passo di generazione generate(m,p j,l,q') precedente oppure nel gestire un arco della forma p b p j oppure p b p j nel passo di generazione corrente, allora aggiungi un arco q a q a L Act : altrimenti, aggiungi uno nuovo stato q ed un arco q a j q a L Act ed aggiungi il passo generate(m, p j, L Act, q ) all'insieme D di L Act (c) marca q come visitato e per ogni formula φ Φ \ Φ REQ dove occorre un azione che sta in Act, verica se L = φ. Se L = φ, rimuovi L dall'ambiente di lavoro P; Quando non sarà più possibile eseguire un passo di generazione perché nessuna delle liste D di qualche L che sta in P ne contiene, l'algoritmo verica se per ogni prodotto LTS 45

53 in P valgono le formule esprimenti i vincoli requires e alternative. Ovvero, L in P e φ Φ REQ ALT verica se L = φ. Se per qualche L P la formula φ non vale, L = φ, allora L viene rimosso dall'ambiente di lavoro P. Quando l'algoritmo termina P contiene un insieme di LTSs che rappresentano i prodotti validi della famiglia. 5.3 Implementazione Il modulo per generare i prodotti validi viene aggiunto al model checker FMC ed è implementato nel linguaggio di programmazione Ada. Ada è un linguaggio di programmazione general-purpose e unisce in un'unica soluzione principi e tecniche provenienti da diversi paradigmi di programmazione, in particolare programmazione modulare, programmazione orientata agli oggetti, programmazione concorrente e programmazione distribuita. Un programma in Ada è composto da unità di programmazione. Un'unità può essere: un sottoprogramma, nella forma di una funzione oppure di una procedura; un package, i sottoprogrammi e tipi di dato che hanno una relazione logica tra loro possono essere raggruppati in un package; un task, attività che può essere realizzata in concorrenza con altre, simile ad un package, a dierenza dei package viene specicato il comportamento in relazione con gli altri task; un'unità generica, forma parametrica di package o di programma. Un programma Ada completo è concepito come una procedura con un nome appropriato, costituente essa stessa un'unità di programma e che richiama funzionalità rese disponibili 46

54 da altre unità di programma. Le unità utilizzate possono essere dei sottoprogrammi ma è piu probabile che siano pacchetti applicativi (packages). Un pacchetto applicativo è costituito da un gruppo di argomenti correlati che possono rappresentare sia altri pacchetti sia dei sottoprogrammi. Ogni pacchetto applicativo si compone di due parti, l'interfaccia e l'implementazione. L'interfaccia denisce la parte di specica, contiene l'informazione su quali sono le funzionalità e i tipi di dato visibili ad altre unità, ha l'estensione.ads. L'implementazione (il body) è la parte che realizza l'interfaccia e di solito non è visibile ad altre unità; ha l'estensione.adb. In questo paragrafo sono descritte le unità create e il loro ruolo nella realizzazione dell'algoritmo introdotto nel paragrafo precedente. Il codice è organizzato nelle seguenti unità di programmazione Ada: ProductFamily_Types.ads, la specica dei tipi, strutture dati, funzioni e procedure; denisce l'interfaccia dei sottoprogrammi utilizzati nell'algoritmo di generazione. ProductFamily_Types.adb, implementazione della specica, realizzazione delle procedure e delle funzioni. Riorganizza i sottoprogrammi correlati ragruppandoli in tre nuovi paccheti, ProductFamily_FormulaVerify, ProdutFamily_Congurations, ProdutFamily_Derivations e ProdutFamily_Combinations. Dichiara la struttura dei nuovi pacchetti e, mediante la parola chiave separate, indica che l'implementazione della unità si trova nel le con il rispettivo nome e l'estensione.adb; ProdutFamily_FormulaVerify.adb l'implementazione del pacchetto ProdutFamily_- FormulaVerify denito nel modulo ProductFamily_Types.adb, realizza le procedure per vericare negli LTSs intermedi la validità delle formule esprimenti i vincoli. Osservazione. Per eseguire le veriche si poteva procedere in due modi. Nel primo si interfacciava il codice dell'algoritmo di generazione con quello del model checker 47

55 FMC. FMC è organizzato in due pacchetti principali, nel primo sono denite le strutture dati che contengono il modello (l'mts nel nostro caso) e nel secondo le procedure per vericare la validità delle formule. Quindi, in riferimento ai punti 1.d), 2.c) e verica nale dell'algoritmo, si poteva caricare il modello e vericare le formule chiamando procedure del codice di FMC. Questa scelta è molto dipendente dal codice di FMC e in più, analizzando la struttura delle formule che rappresentano i vincoli si può capire che la verica si può realizzare in modo alternativo, semplicemente tenendo un array delle azioni presenti nelle transizioni che compongono l'lts intermedio. Quando all'lts si aggiunge una transizione in riferimento ai punti 1.a), 1.b), 1.c) e 2.b), basta controllare se l'azione in essa contenuta compare in qualche vincolo, e se questo è vero, controllare che l'altra azione nella relazione vincolante sia (o non sia) presente nell'array. Abbiamo scelto la seconda modalità. Il pseudocodice introdotto più avanti in questa sezione da una descrizione dettagliata dell'approccio seguito. ProdutFamily_Congurations.adb, realizza le procedure necessarie per esplorare gli stati e le transizioni del modello della famiglia di prodotti descritta mediante un MTS; ProductFamily_Derivations.adb, realizza le procedure per gestire i passi di generazione; ProductFamily_Combinations.adb, realizza le procedure per creare le combinazioni delle azioni che compaiono in transizioni may come descritto nel passo 2 dell'algoritmo di generazione; 48

56 ProductFamily.adb, il main dell'algoritmo di generazione. Questo modulo mette assieme tutte le procedure denite nei moduli descritti qui sopra. Continuo questo capitolo cercando di descrivere in linea di massima le strutture dati e le procedure principali, facendo riferimento all'algoritmo del paragrafo precedente per rendere più chiaro il signicato del codice. ProductFamily_Types.ads. È il pacchetto dove sono deniti i tipi di dato, le funzioni e le procedure necessarie per implementare l'algoritmo. I tipi di dato piu signicativi sono quelli che rappresentano il passo di generazione e l'lts intermedio. Tipo di dato: Il tipo generate type generate is record state: Positive templts : Positive end record Il record generate a dierenza del passo "generate" denito nell'algoritmo del paragrafo precedente, contiene solo lo stato q e l'lts intermedio. L'MTS M e lo stato p dell'mts non servono. Questo perchè M è la stessa per tutta l'esecuzione dell'algoritmo e gli stati p e q rappresentano lo stesso stato sia nel modello M che nell'lts intermedio. Nella descrizione del paragrafo precedente sono introdotte per rendere più chiaro l'approccio seguito. Il seguente codice presenta il tipo che modella un LTS: 49

57 Tipo di dato: Il tipo LTS type LTS is record valid_product:is_valid_product := VALID seen_table: Bool_Array_Ref generate_list: Generate_Container.Vector lts_actions : array_of_actions_ref lts_labels: String_Container.Vector end record Il campo valid_product stabilisce se l'lts intermedio è un prodotto valido oppure no. La rimozione di un LTS non valido dall'ambiente P, in riferimento ai passi 1.d), 1.c) e verica nale, viene eseguita cambiando il valore di questo campo in "NON_VALID". Dopo la terminazione dell'esecuzione dell'algoritmo si possono consultare anche i prodotti non validi e quali transizioni hanno causato la loro non validità. Il campo seen_table tiene informazione su quali stati sono visitati. Si riferiscono ai passi 1.d) e 2.c) dell'algoritmo di generazione. Il campo generate_list contiene i passi di generazione che devono ancora essere eseguiti dall'algoritmo; lts_actions contiene le azioni dell'lts intermedio nella forma target, source, label; in questo modo si può costruire il modello che rappresenta l'lts. Inne, lts_labels contiene le etichette delle azioni presenti in questo LTS. Quest'ultime servono per vericare la validità delle formule. Un altro compito importante di questo pacchetto è realizzare la connessione con il codice di FMC. Per utilizzare le funzionalità delle unità di programma di FMC si inserisce la riga: package MyCongurations is new Congurations il signicato del quale è che le funzionalità sotto il pacchetto Congurations di FMC sono disponibili nell'unita di programma che realizza l'algoritmo di generazione. Si tratta principalmente di tipi, strutture dati e funzioni per recuperare e contenere il modello della famiglia di prodotti espressa in MTS. 50

58 ProductFamily_Congurations.adb. Realizza una procedura, la BreadthFirstExplore, per esplorare gli stati e le transizioni del modello MTS. Come descritto sopra posso utilizzare le funzionalità rese disponibili dal pacchetto Congurations di FMC. In particolare, una struttura dati che contiene il modello MTS della famiglia di prodotti. Analizzando questa struttura dati posso recuperare gli stati e le transizioni e inserirli in un array più semplice Transitions che contiene le transizioni, dove ogni transizione è un record con tre campi; source, target e label. Il codice della procedura dipende da strutture dati e funzionalità disponibili nel pacchetto Congurations, per questo motivo non viene mostrato. ProductFamily_Derivations.adb. Ogni LTS intermedio contiene una lista di passi di generazione. Gli LTSs intermedi sono inseriti nell'array lts_list denito nell'unità Product- Family.adb. A causa della verica del passo 2.a) la lista aumenta di un LTS intermedio. L'algoritmo in questo caso continua con il recupero dei passi "generate" dell'lts corrente. Mediante questo ragionamento la procedura Get_Next_Derive() restituisce il passo successivo da elaborare. 51

59 Algoritmo: Recupero delle generate Input: lts_list Output: has_next_generate, generate 1: exit := false 2: while not exit do 3: if lts_list(lts_index).derives is Empty then 4: lts_index := lts_index + 1 5: else 6: generate := lts_list(lts_index).generates.firstelement 7: remove lts_list(lts_index).generates.firstelement from generates 8: exit := true 9: has_next_generate := true 10: end if 11: if lts_list.length < lts_index then 12: exit := true 13: has_next_generate := false 14: end if 15: end while ProductFamily_FormulaVerify.adb. Il tipo di dato LTS contiene il campo lts_label. Questo campo è un array di etichette che specicano quali sono le azioni che compongono l'lts intermedio. In questo modo si ha tutta l'informazione necessaria per vericare la validità delle formule. Le procedure denite in questo pacchetto fanno riferimento ai punti 1.d), 2.c) e alla verica nale delle formule esprimenti i vincoli requires e alternative nell'algoritmo di generazione. Le tre procedure per la verica delle formule sono descritte in seguito. 1) Il signicato intodotto dalle formule dei vincoli alternative ed exclude è lo stesso con l'unica dierenza che uno dei due operandi in alternative deve essere presente nel prodotto nale. La procedura descritta in seguito realizza la verica della formula del vincolo exclude e della prima parte della formula del vincolo alternative (nel senso che sarà rivalutato nella parte nale dell'algoritmo). La procedura prende in input l'azione che è stata aggiunta a causa di uno dei passi 1.b) e 1.c) e le etichette dell'lts in esame. Per i casi 2.b) 52

60 e 2.d) l'algoritmo è un po piu complicato perché in questi casi le azioni da aggiungere sono più di uno. Siccome la base è la stessa per tutti e due le situazioni descrivo la struttura solo per i casi 1.b) e 1.c) che è la seguente: Algoritmo: Verica del vincolo exclude e (parziale) di alternative Input: current_action, current_lts_labels Output: true, false 1: for i in Constraints do 2: if Constraints(i) is ALT or EXC then 3: if una delle azioni in Constraints(i) è uguale alla current_action then 4: verica che current_lts_label non contenga l'altra azione nella relazione vincolante 5: return false se esiste 6: end if 7: end if 8: end for 9: return true 2) Verica nale della formula del vincolo alternative. Una delle due azioni che la formula mette in relazione deve essere presente nel prodotto nale. Algoritmo: Input: current_lts_labels Output: true, false 1: for i in Constraints do Verica della del vincolo alternative per i prodotti nali 2: if Constraints(i) is ALT then 3: for j in lts_labels do 4: if una delle azioni in Constraints(i) è uguale alla lts_labels(j) then 5: return true 6: end if 7: end for 8: end if 9: end for 10: return false 3) Verica della formula del vincolo requires. L'algoritmo verica che il primo operando della formula è presente nella lts_labels e solo quando questo è vero, verica la presenza nella lts_labels del secondo operando. 53

61 Algoritmo: Input: current_lts_labels Output: true, false 1: for i in Constraints do Verica del vincolo requires per i prodotti nali 2: if Constraints(i) is REQ then 3: for j in lts_labels do 4: if la prima azione nella relazione vincolante Constraints(i) è uguale alla lts_labels(j) then 5: for k in lts_labels do 6: if la seconda azione nella relazione vincolante Constraints(i) è uguale all lts_labels(k) then 7: return true; 8: end if 9: end for 10: end if 11: end for 12: end if 13: end for 14: return false ProductFamily_Combinations.adb. In questo pacchetto sono denite le procedure necessarie per generare l'insieme delle parti di un insieme di etichette. Questo modulo si riferisce al punto 2 dell'algoritmo di generazione. Nel punto 2 si richiede di generare le combinazioni delle azioni che compaiono in transizioni may uscenti dallo stato in esame (si ricordi generate(l,q)) e di vericare che i nuovi LTSs intermedi, ai quali si aggiungono queste azioni sono nelle condizioni di diventare prodotti validi. Questo modulo ha due procedure; la InitializeCombinations(may_actions) e la Get_Next_Comb(). La prima crea l'insieme delle parti a partire da una lista di azioni. È un procedimento iterativo sulla lista delle azioni dove per ogni azione viene creata una lista di insiemi a partire da insiemi creati nei passi precedenti ed aggiungendo l'azione corrente. La gura 5.2 illustra il risultato dell'applicazione della procedura ad un insieme di 3 elementi. Get_Next_Comb(), restituisce il prossimo insieme considerando la struttura degli array mostrata nella gura

62 Figura 5.2: Generazione delle combinazioni. ProductFamily.adb. Questo è il modulo principale dell'algoritmo di generazione. Contiene la logica dell'algoritmo presentato nel paragrafo precedente. Il pseudocodice dell'algoritmo è il seguente: Algoritmo: Algoritmo per generare i prodotti validi di una famiglia Input: Modello testuale della famiglia di prodotti. Output: Insieme di LTSs che rappresentano prodotti validi. 1: LoadModel; carica il modello 2: BreadthFirstExplore; esplora la MTS e crea l'array delle azioni 3: while has_next_generate do 4: get_next_generate(has_next_generate, current_generate) 5: get_out_actions(current_generate.state); le transizioni in uscita dallo stato nella generate corrente 6: for i in out_actions do 7: if out_actions(i) è una must action then 8: isveried := Verify_Formula(out_actions(i), current_generate.templts).actions) 9: if not isveried then 10: Delete_LTS(lts_list, current_generate.templts) 11: else 12: lts_list(current_generate.templts).lts_labels.append(out_actions(i).label); 13: lts_list(current_generate.templts).lts_actions.append(out_actions(i)); 14: end if 15: else out_actions(i) è una transizione may 16: may_actions.append(out_actions(i)) 17: end if 18: end for 55

63 Algoritmo: Algoritmo per generare i prodotti validi di una famiglia (continua) 19: 20: Initialize_Combinations(may_actions) 21: while has_next_comb do 22: get_next_comb(current_combination_actions,has_next_comb) 23: isveried := Verify_Formula(current_combinations_actions, 24: lts_list(current_generate.templts).lts_actions); 25: if not isveried then 26: Delete_LTS(lts_list, current_generate.templts) 27: else crea una coppia della LTS e aggiuingi le nuove azioni 28: create new_lts; 29: crea una coppia lts_list(current_generate.templts) in new_lts; 30: lts_list(current_generate.templts).lts_actions.append(may_actions(i)); 31: lts_list(current_generate.templts).lts_labels.append(may_actions(i).label); 32: agggiungi new_lts in lts_list; 33: end if 34: end while 35: end while 36: Verica nale delle formule REQ e ALT(parziale) 37: for i in lts_list do 38: if not Verify_ALT_Formula(lts_list(I).lts_labels) then 39: Delete_LTS(lts_list(I)); 40: end if; 41: if not Verify_REQ_Formula(lts_list(I).lts_labels) then 42: Delete_LTS(lts_list(I)); 43: end if; 44: end for Il codice descritto ha prodotto un le eseguibile che introduco solo a scopo illustrativo in quanto la procedura di generazione è più signicativa se si mette in relazione con le capacità di FMC di vericare proprietà espressse in formule logiche (vedi capitolo 6). Prendiamo il modello testuale della macchina da caè del paragrafo 5.2 ed eseguiamo l'algoritmo. > ProductFamily m_cae.txt 56

64 Nella directory corrente vengono create due cartelle. La prima ha il nome "ValidProducts" e contiene i prodotti validi della famiglia, mentre la cartella "NonValidProducts" contiene i prodotti non validi e le azioni che hanno causato la non validità. 5.4 Prodotti validi della macchina per caè Le gure 5.3 e 5.4 mostrano due modelli di macchina per caè, risultanti dall'esecuzione dell'algoritmo di generazione sull'esempio introdotto nel paragrafo 2 di questo capitolo. Figura 5.3: LTS della macchina da caè per il mercato europeo 5.5 Validità di una sottofamiglia oppure di un prodotto Stabilire se un prodotto oppure una sottofamiglia fa parte della famiglia originale può essere una operazione molto utile in Product Family Engineering. Una sottofamiglia oppure un prodotto è un MTS dove ho cambiato alcune transizioni dell'mts della famiglia 57

65 Figura 5.4: LTS della macchina da caè per il mercato statunitense iniziale da may a must e ho selezionate qualche may (vedi la denizione delle famiglie di un MTS, sezione 4.5). Successivamente viene applicato l'algoritmo di generazione e analizzata la lista dei prodotti validi risultanti. Se la lista è vuota signica che il prodotto oppure la sottofamiglia non è corretta rispetto ai vincoli espressi nella logica MHML. 5.6 Osservazioni L'algoritmo viene realizzato in un modello on-the-y, nel senso che non sono costruiti esplicitamente tutti gli LTSs possibili dell'mts per poi vericare le formule, ma ogni volta che una azione viene aggiunta all'lts intermedio si procede con la verica delle formule. Se una delle formule non vale allora l'lts viene rimosso dall'ambiente di lavoro P e non può diventare un prodotto valido della famiglia. La complessità nel tempo dipende dai passi di generazione. In totale, in un modello senza vincoli sulle azioni, il numero totale dei passi generate è 58

66 archi(must) 2 archi(may) Se dobbiamo aggiungere anche i vincoli allora la complessità nel tempo dell'algoritmo è O(archi(must) 2 archi(may) k) dove k rappresenta il tempo necessario per vericare la validità delle formule (sezione 5.3, ProductFamily_FormulaVerify). Comunque, in un modello con un numero abbastanza grande di vincoli tale limite è decisamente più contenuto. Si poteva fare meglio? Diversi tentativi sono stati eettuati per cercare di ottimizare la complessità in tempo dell'algoritmo. Abbiamo cercato di realizzare un algoritmo dove i prodotti intermedi non erano LTS ma MTS, mantenendo archi may nei prodotti intermedi. In questo modo non si doveva generare tutto lo spazio degli LTS di un ramo dell'mts originale, quando nessuna delle transizioni del sottoalbero era inclusa in qualche relazione vincolante. Così si poteva ridurre la complessità mantenendo sottofamiglie invece di singoli prodotti. In un secondo passo a partire dalle sottofamiglie si potevano derivare i prodotti nali. Comunque, questa operazione non era possibile a causa delle formule che esprimono i vincoli alternative e requires. La formula del vincolo alternative mi dice che una delle due azioni in relazione deve essere per forza nel prodotto nale. Se un'azione in alternative compare nel sottoalbero di una qualche transizione may allora devo cambiare tutto il percorso no alla radice in un cammino must per essere sicuro che l'azione sarà presente in tutti gli prodotti nali. La gura 5.5 mostra la impossibilità di mantenere archi may in prodotti intermedi. Si può notare come non tutti i prodotti dell'mts in 5.5(ii) sono validi rispetto al vincolo a alternative b. 59

67 Figura 5.5: a alternative b, perché non posso tener i prodotti intermedi in MTS La stessa situazione si presenta anche per azioni presenti in una formula del vincolo requires. 60

68 Capitolo 6 Interfaccia Web In questo capitolo si presenta una semplice interfaccia web per utilizzare le funzionalità dell'ambiente realizzato. Le operazioni disponibili sono: 1) descrivere il modello di una famiglia di prodotti mediante la sintassi denita nella sezione 5.1, 2) la possibilità di generare i prodotti validi come descritto nelle sezioni 5.2 e 5.3, 3) vericare formalmente proprietà sul modello della famiglia e sui singoli prodotti. Abbiamo chiamato questo ambiente VMC, Variabilty Model Checker [6]. 6.1 Denire il modello della famiglia La pagina web si trova sull'indirizzo: La prima pagina che viene visualizzata è la pagina della gura 6.1. Nella parte a sinistra ci sono i comandi che si possono eseguire. Inizialmente è disponibile solo il comando Model Denition...; selezionandolo il contenuto della pagina cambia, addesso è possibile scegliere un esempio predenito oppure di creare un modello nuovo come illustrato nella gura 61

69 Figura 6.1: VMC, pagina iniziale 6.2. Prendiamo l'esempio della macchina da caè che sta sotto il nome deontic.ccs. La Figura 6.2: VMC, scegliere il modello desrizione testuale del modello viene visualizzata sull'editor di testo nella parte centrale della nestra, gura 6.3. Cliccando sul comando Load Current Model viene caricato il modello testuale della macchina da caè, gura 6.4. Nella parte a sinistra sono visualizzati i 62

70 Figura 6.3: VMC, descivere il modello nuovi comandi che si possono eseguire sul modello, mentre la parte centrale visualizza le possibili evoluzioni del sistema a partire dallo stato iniziale. Figura 6.4: VMC, modello caricato In seguito viene descritto il signicato dei comandi disponibili dopo che il modello è stato caricato. Il comando New Model... riporta la pagina nella situazione iniziale, descritta 63

71 dalla gura 6.2, il comando Edit Current Model alla situazione della gura 6.3 ed il comando Explore the MTS riporta la pagina nella situazione attuale, visualizzando le possibili evoluzioni dallo stato iniziale. Con il comando Generate All Products si possono generare i prodotti validi della famiglia. Cliccando su questo comando il contenuto dell'editor di testo nella parte centrale della pagina cambia. Vengono listati i prodotti validi della famiglia, vedi gura 6.5. Si può notare che il nome del prodotto è un link ad un'altra Figura 6.5: VMC, lista prodotti validi della famiglia pagina. I prodotti a questo punto sono degli LTSs sui quali si possono eseguire veriche utilizzando la versione base di FMC. Cliccando su uno dei link una nuova pagina si apre come mostrato nella gura 6.6. La struttura della pagina è simile a quella descritta per VMC. Un altra operazione utile è la visualizzazione della MTS mediante archi e nodi. Questo è possibile mediante il comando View Family MTS. Cliccando su questo comando nella parte centrale della pagina viene visualizzata la famiglia gracamente, gli archi must sono frecce non tratteggiate e gli archi may sono frecce tratteggiate. 64

72 Figura 6.6: VMC, LTS di un prodotto Figura 6.7: VMC, MTS della famiglia 65