Requirement Engineering. Enrico Giunchiglia

Transcript

1 Requirement Engineering Enrico Giunchiglia

2 Requisiti Requisito: Ogni informazione (ottenuta in qualche modo) circa le funzionalità, i servizi, le modalità operative e di gestione del sistema da sviluppare può quindi variare da una descrizione astratta ed imprecisa del sistema, fino a una descrizione dettagliata e matematica dello stesso. Enrico Giunchiglia Ingegneria del Software II 2

3 Requirement Engineering Il Requirement Engineering è il processo secondo cui i requisiti del sistema sono evidenziati, analizzati e validati. Scopo del Requirement Engineering è la produzione di un documento (il requirement document) che definisca le funzionalità e i servizi offerti dal sistema da realizzare Tale documento deve pertanto dire che cosa (piuttosto che come) il sistema dovrebbe fare Enrico Giunchiglia Ingegneria del Software II 3

4 Il processo di Requirement Engineering Feasibility study Feasibility report Requirements elicitation and analysis System models Requirements specification User and system requirements Requirements validation Requirements document Enrico Giunchiglia Ingegneria del Software II 4

5 Elicitazione dei Requisiti L Elicitazione dei requisiti è il processo di acquisizione di informazioni sul sistema da sviluppare. Tale processo può coinvolgere diverse persone (end-users, managers, programmatori, esperti dominio), ma può anche comportare l analisi della legislazione e/o di realizzazioni pre-esistenti. Le diverse persone coinvolte in tale processo rappresentano gli stakeholders. Enrico Giunchiglia Ingegneria del Software II 5

6 Problemi nell Analisi dei Requisiti Gli Stakeholders difficilmente hanno una chiara idea di quello che esattamente vogliono (soprattutto all inizio) Gli Stakeholders usano un loro linguaggio (molto spesso tipico del dominio) molte volte non noto all analista E facile che diversi stakeholders abbiano richieste diverse, e quindi pongano requisiti in conflitto I requisiti del sistema possono dipendere da fattori esterni al sistema stesso (esigenze derivate da motivi organizzativi aziendali, o politico/legislativi) I requisiti (così come gli stakeholder) possono cambiare durante la fase di analisi Enrico Giunchiglia Ingegneria del Software II 6

7 Il Processo di Analisi dei Requisiti Requirements validation Requirements definition and specification Process entry Domain understanding Prioritization Requirements collection Conflict resolution Classification Enrico Giunchiglia Ingegneria del Software II 7

8 Classificazione dei requisiti I requisiti si possono dividere (o classificare) in diversi modi, in base a diversi parametri, quali 1. Le caratteristiche descritte (funzionali o non) 2. La sorgente del requisito (i view points) 3. L oggetto descritto (sistema vs. modulo) Enrico Giunchiglia Ingegneria del Software II 8

9 Requisiti Funzionali e Non I Requisiti Funzionali (Functional Requirement) descrivono le funzionalità ed i servizi forniti dal sistema I Requisiti Non Funzionali (Non Functional Requirement) non sono collegati direttamente con le funzioni implementate dal sistema, ma piuttosto alle modalità operative, di gestione,. Definiscono vincoli sullo sviluppo del sistema Enrico Giunchiglia Ingegneria del Software II 9

10 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 10

11 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 11

12 Esempio: Bancomat Si consideri un sistema bancomat. Il servizio deve mettere a disposizione le funzioni di prelievo, saldo, estratto conto. Il sistema deve essere disponibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie... Enrico Giunchiglia Ingegneria del Software II 12

13 Tipi di Requisiti Non Funzionali Non-functional requirements Product requirements Organizational requirements External requirements Efficiency requirements Reliability requirements Portability requirements Interoperability requirements Ethical requirements Usability requirements Delivery requirements Implementation requirements Standards requirements Legislative requirements Performance requirements Space requirements Privacy requirements Safety requirements Enrico Giunchiglia Ingegneria del Software II 13

14 Altri tipi di requisiti: di Dominio Domain Requirements: derivano dal dominio in cui il sistema deve operare. Es.: La decelerazione del treno deve essere computata come D train = D control + D gradient dove D gradient dipende dal tipo di treno Il sistema deve garantire la privatezza delle informazioni trattate, ed in particolare deve essere garantito da intrusioni esterne Enrico Giunchiglia Ingegneria del Software II 14

15 Altri tipi di Requisiti: Utente User Requirements: descrizione astratta, non tecnica del sistema. Deve essere comprensibile agli utenti del sistema. Di solito, sono specificati in linguaggio naturale. Es. Il sistema permetterà all utente di inserire/modificare/cancellare nodi attraverso menu a finestra Enrico Giunchiglia Ingegneria del Software II 15

16 Risoluzione dei Conflitti Può accadere che si abbiano inconsistenze fra o requisiti di sistemi complessi, soprattutto quando le sorgenti sono diverse. Es. Il sistema deve essere operativo e funzionante entro X mesi Il sistema deve garantire la funzionalità Y vs Il sistema non deve costare più di Z Soluzione: rimozione di uno dei due requisiti Enrico Giunchiglia Ingegneria del Software II 16

17 Prioritizzazione Più frequentemente si hanno conflitti fra requisiti non funzionali. Es.: Al fine di minimizzare il consumo di energia, si deve minimizzare il numero di chip utilizzati preferendo quelli a basso consumo vs Si devono garantire tempi di risposta adeguati Soluzione: Prioritizzazione Enrico Giunchiglia Ingegneria del Software II 17

18 Validazione dei Requisiti Il documento prodotto alla fine dell analisi è: Corretto: La descrizione rappresenta fedelmente i vincoli indicati dall utente? Completo: La descrizione comprende tutte le funzioni ed i vincoli indicati dall'utente? Consistente: Ci sono incongruenze tra i requisiti? (vedi IEEE ) Enrico Giunchiglia Ingegneria del Software II 18

19 Specifica dei Requisiti Processo attraverso il quale i requisiti vengono rappresentati e strutturati in modo organico Tecniche diverse si adattano a diverse categorie di problemi. É importante quindi scegliere la tecnica di specifica più adatta al problema e/o dominio Le tecniche si suddividono rispetto al grado di formalità linguaggio usato rispetto a cosa descrivono del sistema (il loro stile) Enrico Giunchiglia Ingegneria del Software II 19

20 Verifica/Validazione dei Requisiti Al fine di verificare una specifica, vi sono due possibilità: 1. Analisi statica delle proprietà del sistema, deducendole dalla specifica 2. Analisi dinamica del sistema attraverso Simulazione o Prototipazione Enrico Giunchiglia Ingegneria del Software II 20

21 Il Requirement Document Documento ufficiale risultato del Requirement Engineering Process Stabilisce che cosa il sistema deve fare, piuttosto che come si deve fare Usato sia in fase di sviluppo che di validazione/verifica del sistema Enrico Giunchiglia Ingegneria del Software II 21

22 IEEE Lo standard IEEE è espressamente dedicato al Software Requirements Specification (SRS). Il punto di partenza è costituito dalla definizione di otto attributi di qualità cui deve rispondere un SRS. Questi sono 1. Non ambiguità 2. Correttezza 3. Completezza 4. Verificabilità 5. Consistenza 6. Modificabilità 7. Tracciabilità 8. Priorità Enrico Giunchiglia Ingegneria del Software II 22

23 IEEE Std NON AMBIGUO An SRS is unambiguous if and only if every requirement stated therein has only one interpretation. As a minimum, this requires that each characteristic of the final product is described using a single unique term. In cases where a term used in a particular context could have multiple meanings, the term must be included in a glossary where its meaning is made more specific. Ogni requisito ha una sola interpretazione possibile, sia per chi lo definisce ( chi scrive ), sia per chi lo usa ( chi legge ). Enrico Giunchiglia Ingegneria del Software II 23

24 IEEE Std CORRETTO An SRS is correct if and only if every requirement stated therein is one that the software shall meet. Ogni requisito rappresenta fedelmente nel sistema finale qualcosa che è stato richiesto Da questa definizione segue che: Non può esistere nessun tool o procedura che verifica la correttezza fino a quando il sistema non è implementato E possibile verificare la correttezza delle specifiche rispetto ad altre specifiche, ad esempio più astratte Enrico Giunchiglia Ingegneria del Software II 24

25 IEEE Std COMPLETO An SRS is complete if it has the following qualities: 1. Inclusion of all significant requirements, whether relating to functionality, perfomance, design constraints, attributes or external interfaces. 2. Definition of the responses of the software to all reliable classes of input data in all realizable classes of situations. Note that it is important to specify the responses to valid and invalid input values. 3. Full labelling and referencing of all figures, tables, and diagrams in the SRS and definition of all terms and units of the measure. Any SRS that uses the phrase TBD... is not complete. If it is necessary, it should be accompanied by: A description of the conditions causing the TBD (for example, why an answer is not known) so that the situation can be solved. A description of what must be done to eliminate the TBD. Contiene i requisiti di tutte le funzionalità del sistema, e specifica, per tutte le possibili classi di input, la risposta del sistema. La completezza è spesso ottenibile solo incrementalmente, dopo raffinamenti successivi. Enrico Giunchiglia Ingegneria del Software II 25

26 IEEE Std VERIFICABILE An SRS is verifiable if and only if every requirement stated therein is verifiable. A requirement is verifiable if and only if there exists some finite cost-effective process with which a person or machine can check that the software product meets the requirement. If a method cannot be devised to determine whether the software meets a particular requirement then that requirement has to be removed or revised. Ogni requisito deve essere verificabile. Se un requisito non è esprimibile in termini verificabili nel momento in cui l SRS viene definito, dovrebbe essere definito un momento del ciclo di vita del software entro cui il requisito deve essere presentato in una forma verificabile Enrico Giunchiglia Ingegneria del Software II 26

27 IEEE Std CONSISTENTE Consistency refers to internal consistency. An SRS is consistent if and only if no set of individual requirements described in it conflict. There are three types of likely conflicts in an SRS: two or more requirements might describe the same real world object but use different terms for that objects. the specified characteristics of the real world object might conflict. there might be a logical or temporal conflict between two specified actions. non vi devono essere requisiti che sono inconsistenti fra loro Enrico Giunchiglia Ingegneria del Software II 27

28 IEEE Std MODIFICABILE An SRS is modifiable if and only if its structure and style are such that any necessary changes to the requirements can be made easily, completely and consistently. Modifiability generally requires an SRS to: have a coerent and easy-to-use organization, with a table of contents, an index, and explicit cross-referencing; not to be redundant. Whenever redundancy is necessary, the SRS should include explicit cross-references to make it modifiable. Express each requirement separately, rather than intermixed with other requirements. Enrico Giunchiglia Ingegneria del Software II 28

29 IEEE Std TRACCIABILE An SRS is traceable if the origin of each of its requirements is clear and if it facilitates the referencing of the requirement in future development or enhancement of the documentation. Two types of traceability are recommented: 1. Backward Traceability: depends upon each requirement explicitly referencing its source in previous documents. 2. Forward Traceability: depends upon each requirement in the SRS having a unique name or reference number. Ogni requisito deve essere identificabile univocamente (FT). Quando un requisito A nell SRS deriva da un altro requisito B, deve essere specificata la dipendenza di A da B (BT). Enrico Giunchiglia Ingegneria del Software II 29

30 IEEE Std PRIORITA An SRS is ranked for importance and/or stability if each requirement in it has an identifier to indicate either the importance or stability of that particular requirement. Typically, all of the requirements that relate to a software product are not equally important. Some requirements may be essential, while others may be desiderable. Each requirement in the SRS should be identified to make these differences clear and explicit Enrico Giunchiglia Ingegneria del Software II 30

31 Struttura del Requirements Document (IEEE/ANSI ) 1. Introduzione 1. Obiettivo del Requirement Document 2. Obiettivo del prodotto 3. Definizioni, acronimi, abbreviazioni 4. Riferimenti 5. Struttura del documento 2. Descrizione Generale 1. Descrizione del prodotto dai diversi punti di vista 2. Funzionalità del prodotto 3. Caratteristiche utente 4. Vincoli sul prodotto 3. I Requisiti (funzionali, non-funzionali, lato utente ) 4. Appendici 5. Indice Enrico Giunchiglia Ingegneria del Software II 31

32 Struttura del Requirements Document (I. Sommerville) 1. Glossario: Definisce i termini tecnici utilizzati 2. Modelli del sistema: Definisce i modelli mostrando i componenti del sistema e le loro relazioni 3. Definizione dei requisiti funzionali: Descrive i servizi forniti 4. Definizione requisiti non funzionali: Definisce i vincoli sul sistema ed il processo di sviluppo 5. Evoluzione del sistema: Definisce le assunzioni principali su cui si basa il sistema e le modifiche future 6. Specifica dei requisiti: Specifica dettagliata dei requisiti funzionali 7. Appendici: Descrizione dettagliata collegata all applicazione da sviluppare. (Es. piattaforma hardware da usare, schema della base dei dati) 8. Indice Enrico Giunchiglia Ingegneria del Software II 32

33 Tecniche di Specifica dei Requisiti Enrico Giunchiglia

34 Specifica dei Requisiti Processo attraverso il quale i requisiti vengono rappresentati e strutturati in modo organico Tecniche diverse si adattano a diverse categorie di problemi. É importante quindi identificare la tipologia del problema per scegliere la tecnica più adatta Le tecniche si suddividono rispetto al grado di formalità linguaggio usato rispetto a cosa descrivono del sistema (il loro stile) Enrico Giunchiglia Ingegneria del Software II 34

35 Linguaggi di specifica Informali: sintassi e semantica non rigorose Es. linguaggio naturale (strutturato) Semi-formali: sintassi rigorosa ma non semantica Es. Diagrammi ER, DFD Formali: sintassi e semantica rigorose Es. FSM, Reti di Petri, Z, Specifiche Logiche, Specifiche Algebriche Enrico Giunchiglia Ingegneria del Software II 35

36 Linguaggi Informali di Specifica Pro: Accessibile a tutti (e soprattutto al committente) Altamente flessibile Contro: Ambiguo Non permette una analisi rigorosa Enrico Giunchiglia Ingegneria del Software II 36

37 Linguaggi Semi-Formali di Specifica Pro: Semplici, e pertanto facili da utilizzare e da comprendere Contro: Potere espressivo limitato alla sola rappresentazione sintattica Limitati alla specifica dei soli requisiti funzionali. Enrico Giunchiglia Ingegneria del Software II 37

38 Linguaggi Formali di Specifica Pro: elimina ambiguità permette specifiche astratte consente di ragionare su e verificare proprietà, anche con strumenti (semi)automatici che supportano quel linguaggio Contro: Non sono immediatamente accessibili, soprattutto dall utente Non tutte le proprietà sono rappresentabili Il processo di verifica può essere non banale Limitati alla specifica dei soli requisiti funzionali. Enrico Giunchiglia Ingegneria del Software II 38

39 Stili di specifica Specifica Operazionale: fornisce una macchina astratta, un modello che si comporta come il sistema da costruire Specifica Descrittiva: si limita a definire il comportamento del sistema (e.g., la relazione fra gli ingressi e le uscite) Specifiche Miste Enrico Giunchiglia Ingegneria del Software II 39

40 Specifiche Operazionali vs Descrittive Pro: Suggerisce un metodo per la realizzazione É (più) facilmente eseguibile e quindi verificabile É (più) facile costruire un prototipo astratto e verificarne l aderenza alla specifica Contro: Spinge decisamente verso una certa implementazione, che non é detto sia la migliore Enrico Giunchiglia Ingegneria del Software II 40

41 Esempi Esempi di Specifiche Operazionali: Diagrammi di Flusso dei Dati (DFD). Macchine a Stati Finiti (FSM). Reti di Petri. Esempi di Specifiche Descrittive: Diagrammi Entità-Relazione (ER). Tutte le tecniche basate sulla Logica (LTL). Formalismi intermedi: Specifiche algebriche Linguaggio Z Enrico Giunchiglia Ingegneria del Software II 41

42 In Sintesi Spec. Alg. Ling. Nat. Enrico Giunchiglia Ingegneria del Software II 42

43 Tecniche di Specifica dei Requisiti Linguaggi Informali di Specifica Linguaggio Naturale Strutturato

44 Linguaggio Naturale Strutturato Tipicamente attraverso Forms, che descrivono Descrizione della funzione o entità da specificare Descrizione degli input e da dove provengono Descrizione degli output e dove vanno a finire Indicazioni di altre entità richieste Pre e post condizioni Effetti collaterali (se ce ne sono) Enrico Giunchiglia Ingegneria del Software II 44

45 Esempio: Add node con Forms ECLIPSE/Workstation/Tools/DE/FS/3.5.1 Function Add node Description Adds a node to an existing design. The user selects the type of node, and its position. When added to the design, the node becomes the current selection. The user chooses the node position by moving the cursor to the area where the node is added. Inputs Source Outputs Destination operation. Requires Pre-condition Node type, Node position, Design identifier. Post-condition at the given position. Side-effects Node type and Node position are input by the user, Design identifier from the database. Design identifier. The design database. The design is committed to the database on completion of the Design graph rooted at input design identifier. None Definition: ECLIPSE/Workstation/Tools/DE/RD/3.5.1 The design is open and displayed on the user's screen. The design is unchanged apart from the addition of a node of the specified type Enrico Giunchiglia Ingegneria del Software II 45

46 Tecniche di Specifica dei Requisiti Linguaggi Semi-Formali di Specifica Modelli Data-Flow

47 Modelli data-flow Mostrano i passi del processo in termini di flusso di dati: come i dati fluiscono attraverso una sequenza di moduli Notazione semplice e intuitiva, non limitata ai processi software, comprensibile da parte del cliente Si presta bene per design a livello di sistema La notazione (di base) rappresenta processi funzionali, il passaggio di dati da un processo all altro, i data stores, e gli agenti esterni Enrico Giunchiglia Ingegneria del Software II 47

48 Diagrammi Data Flow: notazione Funzione o Processo Flusso di dati Agente Esterno Deposito permanente di dati Enrico Giunchiglia Ingegneria del Software II 48

49 Personale Esempio di diagramma data-flow Modulo firmato e notifica di invio dati Completa il modulo Modulo completato modulo d ordine in bianco Convalida l ordine Modulo firmato Dettagli sull ordine Protocolla l ordine Modulo protocollato Modulo protocollato Invia l ordine Aggiorna bilancio Fornitore Importo ordine e dettagli cc Personale File ordini File bilancio Enrico Giunchiglia Ingegneria del Software II 49

50 Diagrammi Data-Flow Possono essere usati a diversi livelli di astrazione: Livello massimo: un unica bolla Raffinamenti: scomposizione della bolla in funzioni specializzate e separate Procedimento ripetibile fino a quando non si raggiunge un livello di dettaglio soddisfacente Vincolo di continuità di flusso: Il raffinamento di una funzione deve conservare gli stessi flussi in entrata e in uscita Enrico Giunchiglia Ingegneria del Software II 50

51 DFD: Esempio Specifica di un sistema di monitoraggio di un paziente I segnali vitali del paziente (temperatura, pressione, polso) sono misurati periodicamente e convertiti in forma manipolabile da programma; essi vengono confrontati coi dati ammissibili per il paziente, memorizzati in forma permanente su di un file, formattati e memorizzati in un file storico. Se i dati del paziente sono al di fuori dei limiti prestabiliti viene generato un messaggio di allarme che richiama l'attenzione del personale sanitario. Inoltre, un infermiere può occasionalmente, cioè in modo asincrono, richiedere un rapporto sulle condizioni del paziente: in questo caso il rapporto viene generato a partire dall'archivio storico. Enrico Giunchiglia Ingegneria del Software II 51

52 DFD: Esempio Sistema di Monitoraggio Paziente: Passo 1 Enrico Giunchiglia Ingegneria del Software II 52

53 DFD: Esempio Sistema di Monitoraggio Paziente: Passo 2 Enrico Giunchiglia Ingegneria del Software II 53

54 DFD: Esempio Dettaglio della Funzione Monitoraggio Centrale Enrico Giunchiglia Ingegneria del Software II 54

55 DFD: Criteri di Stesura DFD descrive sistema a regime: trascurare l inizializzazione del sistema e la gestione degli errori DFD non descrive il controllo: trascurare il flusso di controllo e la sincronizzazione tra i (sotto)processi Evidenziare opportunamente nel diagramma le entrate e uscite complessive del sistema Assegnare nomi esplicativi ai flussi e ai processi Verificare correttezza e completezza dei flussi informativi Verificare il vincolo di continuità Descrizione (tramite dizionari ) delle funzioni nelle bolle e dei dati informale (linguaggio naturale) semi-formale (pseudo-linguaggi / pseudo-codice) formale (solo in prototipi di ricerca di DFD): grammatiche, BNF Enrico Giunchiglia Ingegneria del Software II 55

56 DFD: Sintesi Pro Facilità d uso Comprensibilità Generalità Contro Mancanza di rigore formale impossibile valutare e/o eseguire la specifica (se non tramite prototipazione) Limiti non descrivono controllo, sincronizzazione descrivono solo vista a regime del sistema Enrico Giunchiglia Ingegneria del Software II 56

57 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche

58 Specifiche Logiche Logica del prim ordine viene usata per esprimere condizioni su un dominio di interesse, attraverso l uso di costanti, variabili, funzioni, predicati. Nel caso di programmi, si esprimono le condizioni che devono valere dopo l esecuzione del programma, semprechè alcune condizioni valgano prima dell esecuzione Enrico Giunchiglia Ingegneria del Software II 58

59 Specifiche Logiche Dato programma P con input <i1,, in> e output <o1, om> Pre-condizione Pre(i1,, in) Post-condizione Post(o1, om) Requisito di P: Enrico Giunchiglia Ingegneria del Software II 59

60 Specifiche Logiche: Esempi procedura di reverse di una sequenza {n >0} procedure reverse(a: in/out integer_array; n: in integer) {forall i ((1<=i <=n) implies (a(i) = old_a (n-i +1)))} sorting di una sequenza {n > 0} procedure sort (a: in/out integer_array; n: in integer) {sorted(a, n)} Dove: sorted(a,n) forall i (1<=i<=n) implies a(i) <= a(i+1) Enrico Giunchiglia Ingegneria del Software II 60

61 Uso della logica per specificare: pre/post condizioni proprietà invarianti e/o critiche proprietà temporali del sistema É possibile utilizzare diversi formalismi (sistemi) logici Logica proposizionale Logica dei predicati LTL CTL, CTL*, TRIO, Enrico Giunchiglia Ingegneria del Software II 61

62 Sistemi Logici Strumenti per descrivere in modo rigoroso una realtà di interesse (programma, oggetto, componente,...) Due componenti: Definizione del linguaggio (formale) usato per la descrizione Definizione dell insieme dei fatti (teoria) caratterizzanti la realtà Enrico Giunchiglia Ingegneria del Software II 62

63 Linguaggio Formale Un Linguaggio Formale è definito da: un Alfabeto di simboli una Sintassi atti a definire un insieme di stringhe accettabili, dette formule ben formate ( well formed formulas, wff). LF Alfabeto Sintassi Enrico Giunchiglia Ingegneria del Software II 63

64 Esempio 1 Sia dato il seguente Linguaggio Formale: Alfabeto = { λ,., (, ), x, y, z } Sintassi = exp ::= var exp, exp λ, var,., exp ( exp ) ; var ::= x y z ; Enrico Giunchiglia Ingegneria del Software II 64

65 Esempi di wff λ x. x y λ y. λ x. x y λ x. λ. y NO! Enrico Giunchiglia Ingegneria del Software II 65

66 sintassi: l insieme delle wff generabili dal linguaggio formale possibili stringhe di simboli dell alfabeto Enrico Giunchiglia Ingegneria del Software II 66

67 Esempio 2 Sia dato il seguente Linguaggio Formale L: Alfabeto = {, } Sintassi = { una wff in L è ogni stringa finita di zero o più simboli, seguita da un numero compreso tra 1 e 4 simboli, o una stringa di 1 o più simboli, senza seguito } Enrico Giunchiglia Ingegneria del Software II 67

68 Definizione di una teoria Metodi sintattici, tramite la definizione di sistemi assiomatici Metodi semantici, tramite la definizione di una funzione di interpretazione Enrico Giunchiglia Ingegneria del Software II 68

69 Metodi Sintattici Un Sistema Assiomatico è caratterizzato da: un Linguaggio Formale (LF) un Apparato Deduttivo (AD) SA LF AD Enrico Giunchiglia Ingegneria del Software II 69

70 Apparato Deduttivo Un Apparato Deduttivo è definito da: un insieme di Assiomi un insieme di Regole di Inferenza. AD Assiomi Regole Enrico Giunchiglia Ingegneria del Software II 70

71 Apparato Deduttivo (segue) Assiomi: wff assunte vere per ipotesi Regole di Inferenza: permettono di derivare wff vere come conseguenza di altre wff ritenute vere. Enrico Giunchiglia Ingegneria del Software II 71

72 Sommario LF SA AD Semantica Alfabeto Sintassi Assiomi Regole Enrico Giunchiglia Ingegneria del Software II 72

73 Esempio SA Alfabeto = {,, } Sintassi = frase ::= sds,, sds,, sds sds ::= sds, Enrico Giunchiglia Ingegneria del Software II 73

74 Esempio (segue) AD Assioma: Regole: da a b c (dove a, b e c sono sds) segue a b c : a b c a b c Enrico Giunchiglia Ingegneria del Software II 74

75 Esempio 1. : assioma 2. : conseguenza di 1 3. : conseguenza di 2 4. : conseguenza di 3 Enrico Giunchiglia Ingegneria del Software II 75

76 Prova Viene definita prova (o dimostrazione) in un SF una sequenza finita di wff del LF, ognuna delle quali è un assioma, oppure è una conseguenza di una o più formule precedenti. Enrico Giunchiglia Ingegneria del Software II 76

77 Teorema Una wff che può essere provata a partire dagli assiomi è detta teorema Enrico Giunchiglia Ingegneria del Software II 77

78 Esempio Dimostrare che: è un teorema a partire da Assioma: Regole: a b c a b c a b c b a c Enrico Giunchiglia Ingegneria del Software II 78

79 sintassi: l insieme delle wff generabili dal linguaggio formale assiomi Enrico Giunchiglia Ingegneria del Software II 79

80 sintassi: l insieme delle wff generabili dal linguaggio formale assiomi prova teoremi Enrico Giunchiglia Ingegneria del Software II 80

81 Derivazione Una derivazione di una wff w in un SF a partire da un insieme P di wff dette premesse è una sequenza finita di wff, tale che w è l ultima wff della sequenza ogni wff della sequenza è un assioma una premessa la conseguenza dell applicazione di una regola di inferenza. Enrico Giunchiglia Ingegneria del Software II 81

82 Notazione La derivazione di w dalle premesse P si indica con: P - w Il simbolo - prende il nome di derivatore sintattico Una dimostrazione priva di premesse è un teorema - teorema. Enrico Giunchiglia Ingegneria del Software II 82

83 Conclusioni (sui Met. Sint.) I sistemi assiomatici permettono di caratterizzare (tramite la definizione di prova e/o di derivazione) un insieme di teoremi. L insieme dei teoremi forma una teoria, che intende modellare la realtà di interesse. Enrico Giunchiglia Ingegneria del Software II 83

84 Metodi Semantici Dato un linguaggio (i.e., un insieme di wff) definito come precedentemente Un interpretazione è una funzione che assegna un valore ( vero o falso ) a ogni wff Molte volte si considerano le sole interpretazioni che assegnano una interpretazione fissata ad alcuni simboli (simboli logici) Soddisfano alcune formule particolari (assiomi) Enrico Giunchiglia Ingegneria del Software II 84

85 Esempio 1 di interpretazione I( ) = 1, I( ) = 2, I( ) = + I( ) = = aritmetico Le formule a b c si interpretano come a+b=c: Assioma: corrisponde a: 1+1=2 Regola: corrisponde a: a b c a + b = c a b c a + (b+1) = c+1 Enrico Giunchiglia Ingegneria del Software II 85

86 Esempio 2 Un interpretazione I per L è: denota 5 : I( )=5 denota 0 : I( )=0 I( ) = = aritmetico la giustapposizione di simboli indica la somma algebrica. Enrico Giunchiglia Ingegneria del Software II 86

87 Formula valida Se S è l insieme delle interpretazioni possibili e α è una wff: data I S, I soddisfa α ( =I α) se I(α) = true α è valida, se ogni I in S soddisfa α Enrico Giunchiglia Ingegneria del Software II 87

88 Conseguenza Logica Sia S l insieme delle interpretazioni possibili, P un insieme di premesse, α una wff. Si dice che α è conseguenza logica di P (P = α), se ogni interpretazione in S che soddisfa P soddisfa anche α. Enrico Giunchiglia Ingegneria del Software II 88

89 Conclusioni (sui Met. Sem.) I metodi semantici permettono di caratterizzare (tramite la definizione di interpretazione) un insieme di formula valide. L insieme delle formule valide forma una teoria, che intende modellare la realtà di interesse. Enrico Giunchiglia Ingegneria del Software II 89

90 Correttezza e Completezza Dato un Sistema Logico, sia ST l insieme dei teoremi (definito tramite un sistema assiomatico SA) SV l insieme delle formula valide (definite caratterizzando le interpretazioni possibili) Allora Se ST SV, allora SA viene detto corretto Se SV ST, allora SA viene detto completo Enrico Giunchiglia Ingegneria del Software II 90

91 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche Logica Proposizionale

92 Logica Proposizionale Permette di esprimere proposizioni, dove una proposizione è un asserzione a cui si può associare un valore di verità (Vero o Falso). Es.: i professori sono persone la Francia è in Asia Non sono proposizioni: vattene! Enrico Giunchiglia Ingegneria del Software II 92 come ti chiami?

93 LF = Logica proposizionale Alfabeto = { P, Q, R,,,,,,, (, ) } Sintassi: wff atomica ::= P Q R wff ::= wff atomica wff ( wff wff ) ( wff wff ) ( wff wff ) ( wff wff ) Enrico Giunchiglia Ingegneria del Software II 93

94 Esempi di wff ( P Q ) ( ( P Q ) R ) ((P Q) R )) (((P Q) R) R) Enrico Giunchiglia Ingegneria del Software II 94

95 Interpretazione Se α è wff atomica, allora ad α è associato un valore di verità Se α è composta da sottoformule (β, γ) tramite i connettivi,,,, allora il valore di verità di α è definito sulla base del valore di verità di (β, γ) e della tabella di verità del connettivo. Enrico Giunchiglia Ingegneria del Software II 95

96 Tabelle di Verità α β α β α β α β α β α Enrico Giunchiglia Ingegneria del Software II 96 α β α β α β α β α β α F F F F F T F T T T T T F T T F F T T T F F F T T F T T

97 Esercizio Se P è interpretata come il valore di verità vero, Q come il valore di verità falso, valutare la semantica di: (( P Q ) Q ). In altri termini, dati: I(P) = true, I(Q) = false calcolare I( (( P Q ) Q ) ). Enrico Giunchiglia Ingegneria del Software II 97

98 Tautologia Una formula è una tautologia se una qualunque interpretazione la soddisfa. Una formula è inconsistente se una qualunque interpretazione la falsifica Esempi: Tautologia: A A Inconsistenza: A A Enrico Giunchiglia Ingegneria del Software II 98

99 Natural Deduction System (Gentzen) introduction A, B implica A B A, B implica B A elimination A B implica A A B implica B Enrico Giunchiglia Ingegneria del Software II 99

100 introduction A implica A B A implica B A elimination A implica A elimination (modus ponens) A, A B implica B Enrico Giunchiglia Ingegneria del Software II 100

101 elimination A B implica A B A B implica B A introduction A B, B A implica A B. Enrico Giunchiglia Ingegneria del Software II 101

102 Esempio di derivazione 1 P Q - P Q 1. P Q 2. P 3. P Q : premessa : 1, -elim : 2, -intro. Enrico Giunchiglia Ingegneria del Software II 102

103 Esempio di derivazione 2 P, Q, (P Q) R - R 1. P 2. Q 3. (P Q) R 4. P Q 5. R : premessa : premessa : premessa : 1, 2, -intro : 3, 4, -elim. Enrico Giunchiglia Ingegneria del Software II 103

104 AD = Sistema di Hilbert 3 schemi di assioma: 1. (α (β α)) 2. ((α (β γ)) ((α β) (α γ))) 3. ((α β) ((α β) α)) 1 regola di inferenza (modus ponens) + 1 regola di sostituzione per ogni altro connettivo Enrico Giunchiglia Ingegneria del Software II 104

105 Sistemi di ND vs di Hilbert ND: 0 assiomi 9 regole Hilbert: 3 schemi di assiomi 2 regole Enrico Giunchiglia Ingegneria del Software II 105

106 Sistemi di ND vs di Hilbert ND: 0 assiomi 9 regole Hilbert: 3 schemi di assiomi 4 regole Sistema migliore? In pratica: procedure decisionali ad hoc Enrico Giunchiglia Ingegneria del Software II 106

107 Conclusioni su Logica Proposizionale Potere espressivo limitato L insieme delle tautologie è decidibile (ricorsivo), ma: Decidere se una formula è soddisfacibile è difficile (NP completo) Decidere se una formula è una tautologia è difficile (co-np completo) In pratica, gli attuali (i.e., del 2005) solutori (completi) sono specializzati per risolvere problemi (cfr. SAT competition, di origine industriale, e arrivano a qualche milione di variabili generati casualmente secondo il modello FCL, e arrivano a circa 500 variabili Esistono solutori incompleti per problemi soddisfacibili (basati su tabu search, simulated annealing, algoritmi genetici, ) Enrico Giunchiglia Ingegneria del Software II 107

108 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche Logica dei Predicati

109 Logica dei predicati La logica dei predicati costituisce un estensione della logica proposizionale. I predicati consentono di esprimere proprietà e relazioni esistenti tra determinati oggetti che costituiscono il dominio di interesse. Questo aumentato potere descrittivo richiede una opportuna estensione del linguaggio logico. Enrico Giunchiglia Ingegneria del Software II 109

110 Il linguaggio logico dei predicati Termini: rappresentano gli oggetti del discorso: le costanti individuali e le variabili sono termini. se f() è un simbolo di funzione (funtore) di arità n e t 1,..., t n sono termini, f(t 1,...,t n ) è un termine. Enrico Giunchiglia Ingegneria del Software II 110

111 Formule (wff): se P() è un simbolo di predicato (predicato) di arità n e t 1,..., t n sono termini, P(t 1,...,t n) è una formula. se α e β sono formule allora α β, α β, α β, α β e α sono a loro volta formule. se α è una formula e x una variabile, x α e x α sono formule. Enrico Giunchiglia Ingegneria del Software II 111

112 Interpretazione: Intuizione In logica proposizionale le formule atomiche sono atomi, direttamente mappabili in un valore di verità. In logica dei predicati le formule atomiche sono ottenute applicando un simbolo predicativo a dei termini che rappresentano l oggetto del discorso. Per stabilire la verità di P(t 1,...,t n ) è quindi necessario: Definire a quale oggetto corrisponde ogni termine t i Definire per quali n-uple di oggetti è vera P Enrico Giunchiglia Ingegneria del Software II 112

113 Interpretazione: Definizione Una interpretazione è una coppia <D,g>, dove D è il dominio (ognuno rappresentante un oggetto della realtà che si vuole modellare) g è la funzione di interpretazione. g è tale che A ogni costante associa un elemento in D A ogni funzione n-aria associa una funzione n-aria con dominio Dx...xD e codominio D. A ogni lettera predicativa n-aria associa un insieme di n-tuple di elementi di D Enrico Giunchiglia Ingegneria del Software II 113

114 Assumiamo che gli oggetti in D non facciano parte dell alfabeto. Una interpretazione I soddisfa una formula α sse se α =P(t 1,...,t n ), allora <g[t 1 ],...,g[t n ]> g[p] se α = (β γ), allora I soddisfa sia β sia γ... analogamente per,,, se α= xβ(x), allora I soddisfa β(t), per qualunque t in D... analogamente per xβ(x) Enrico Giunchiglia Ingegneria del Software II 114

115 Validità, Conseguenza Logica Sia S l insieme delle interpretazioni possibili. Una formula è valida (in S) se una qualunque interpretazione in S la soddisfa Una formula α è conseguenza logica (in S) di un insieme di formule Γ se una qualunque interpretazione in S che soddisfa le formule in Γ soddisfa anche α Enrico Giunchiglia Ingegneria del Software II 115

116 AD: Sistemi di ND elimination x P(x) P(a) introduction P(a) con a particolare x P(x) introduction P(a) x P(x/a) elimination Enrico Giunchiglia Ingegneria del Software II 116

117 Esempio Dimostrare che x y (P(x,y) P(y,x)) - x P(x,x) 1 x y (P(x,y) P(y,x)) 2 y (P(a,y) P(y,a)) 3 P(a,a) P(a,a) 4 P(a,a) 5 P(a,a) 6 P(a,a) 7 x P(x,x) premessa 1 elimination 2 elimination assunzione 3,4 elimination 4,5 introduction 6 introduction Enrico Giunchiglia Ingegneria del Software II 117

118 AD: Altri sistemi di Hilbert basati su refutazione + risoluzione... Enrico Giunchiglia Ingegneria del Software II 118

119 Conclusioni (su LPred) Più espressiva di logica proposizionale (permette di parlare di domini con numero non limitato di oggetti) Insieme di formule valide è non ricorsivo (semidecidibile) Esistono frammenti decidibili (es. Logica monadica: decidibile ma PSPAZIO completa). Estendibile con il simbolo di uguaglianza, e con multi-sorte Enrico Giunchiglia Ingegneria del Software II 119

120 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche Logica dei Predicati con Uguaglianza

121 Uguaglianza E possibile indicare con nomi diversi la stessa entità introducendo simbolo di uguaglianza =. Semanticamente: <D,g> soddisfa t=t sse g[t]=g[t ]. Deduttivamente: Si deve estendere AD con Assioma di riflessività x x=x Regola di sostituzione m=n S(n) S(m/n) Enrico Giunchiglia Ingegneria del Software II 121

122 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche Logica dei Predicati Multi Sorte

123 Intuizione Finora si è assunto che gli oggetti del discorso fossero tutti dello stesso tipo. In realtà nei sistemi complessi, si trovano oggetti di tipo diverso, non direttamente confrontabili tra di loro. Enrico Giunchiglia Ingegneria del Software II 123

124 Definizione di Linguaggio Quindi, nella definizione di wff: si associa a ogni costante/variabile un tipo, per ogni funzione n-aria, si deve precisare il tipo di ogni suo argomento, e il tipo dell oggetto di ritorno, per ogni predicato n-ario, si deve precisare il tipo di ogni argomento, l uguaglianza è possibile solo fra oggetti dello stesso tipo. Enrico Giunchiglia Ingegneria del Software II 124

125 Esempio 1 Termini: Sorte <box>: Costanti: a,b,c,d,e; Variabili: x,y,z; Sorte <table>: Costanti: t1,t2; Variabili: t; Predicati: OnTable(box,table) On(box,box) Above(box,box) Enrico Giunchiglia Ingegneria del Software II 125

126 Esempio 2 Termini: Sorte <natnum>: Costanti: 0,1,2,...; Variabili: ep,ef; Funzioni: numfigli(persona)=natnum, mediafigli(nazione)=natnum, natnum + natnum=natnum Sorte <persona>: Variabili: p1,p2,p3,...; Sorte <nazione>: Costanti: Italia, Francia, Germania,...; Variabili: n Predicati: natnum > natnum genitore(persona,persona) Enrico Giunchiglia Ingegneria del Software II 126

127 Definizione di interpretazione Per ogni sorte, si ha un corrispondente Dominio Ogni costante viene mappato in un elemento del dominio corrispondente alla sorte della costante Le definizioni di interpretazione di una simbolo funzionale, predicativo, formula, vengono modificate di conseguenza Enrico Giunchiglia Ingegneria del Software II 127

128 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche Esempi

129 Specifica di Dominio La logica può essere utilizzata per descrivere uno scenario, specificandone: gli oggetti, le relazioni esistenti e di interesse. Enrico Giunchiglia Ingegneria del Software II 129

130 Esempio 1 A1: x y z (above(x,y) above(y,z) above(x,z)) A2: x y (on(x,y) above(x,y)) stato iniziale A3: on(a,t1) A4: on(b,a) A5: on(c,t1) A6: on(d,t2) A7: on(e,d) Enrico Giunchiglia Ingegneria del Software II 130

131 Esempio 2 A1: x y (numfigli(x)=0 genitore(x,y)) A2: x (numfigli(x)=1 y (genitore(x,y) z (genitore(x,z) z=y))) Q1: SopraMedia(x,n) numfigli(x) > mediafigli(n) Enrico Giunchiglia Ingegneria del Software II 131

132 Specifica di Programmi La specifica di un programma viene fornita definendo la relazione che deve esistere fra i dati di ingresso e di uscita (specifica di input/output) Enrico Giunchiglia Ingegneria del Software II 132

133 Esempio 3 (ordinamento) Ordinamento(ai,ao) Permutazione(ai,ao) Ordinato(ao) //Assumiamo a1,a2 con elementi distinti Permutazione(a1,a2) k (0 k<n-1 i (0 i<n-1 a1[k]=a2[i])) Ordinato(a) k (0 k<n-1 a[k] < a[k+1]) Enrico Giunchiglia Ingegneria del Software II 133

134 Esempio 4 (merging) <definizione del linguaggio> Merging(ai1,ai2,ao) Ordinato(ai1) Ordinato(ai2) Ordinato(ao) Unione(ai1,ai2,ao) Unione(ai1,ai2,ao) k (0 k<n-1 ( i (0 i<2n-1 ai1[k] = ao[i]) i (0 i<2n-1 ai2[k] = ao[i]))) Enrico Giunchiglia Ingegneria del Software II 134

135 Esempio 5 (ricerca) <definizione del linguaggio> Ricerca(num,a) = 1 k (0 i<n a[k]=num) Ricerca(num,a) = 0 Ricerca(num,a) = 1 Enrico Giunchiglia Ingegneria del Software II 135

136 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Logiche TRIO

137 TRIO: Intuizione TRIO = Sistema logico del primo ordine, multisorte, con uguaglianza. La sorte Tempo è parte integrante del linguaggio TRIO è quindi finalizzato alla specifica di proprietà temporali di sistemi (non necessariamente software) Enrico Giunchiglia Ingegneria del Software II 137

138 TRIO: Esempi Esempi di proprietà temporali: La sbarra del passaggio a livello deve chiudersi PRIMA dell arrivo del treno Un messaggio di allarme deve apparire sulla console dell operatore ENTRO 10 secondi dal verificarsi di... Non deve esistere nessun ISTANTE DI TEMPO in cui la sbarra del passaggio a livello è aperta ed il treno sta attraversando i binari Enrico Giunchiglia Ingegneria del Software II 138

139 Esempio: Data una linea di trasmissione La formula in(m) Futr(out(m), 5) esprime che la linea introduce un ritardo di 5 unità di tempo, ma non introduce rumore. Enrico Giunchiglia Ingegneria del Software II 139

140 TRIO: Sintassi Alfabeto Nomi di variabili, funzioni, predicati Operatori proposizionali,,,,, Quantificatori, I simboli Futr e Past Variabili, funzioni e predicati possono essere Dipendenti dal tempo (Nell esempio, in e out sono predicati dipendenti dal tempo) Indipendenti dal tempo (Nell esempio, m è una variabile indipendente dal tempo) Enrico Giunchiglia Ingegneria del Software II 140

141 Il linguaggio è multi-sorte: Ad ogni variabile si associa un dominio (nell esempio, m assume valori nel dominio dei messaggi) Esiste un dominio particolare: il dominio temporale Ad ogni funzione si associa un dominio ed un codominio Ad ogni predicato si associa un dominio per ognuno dei sui argomenti Enrico Giunchiglia Ingegneria del Software II 141

142 TRIO: Semantica Una interpretazione S è caratterizzata da un insieme di interpretazioni classiche (come in logica proposizionale e/o dei predicati), una per ogni instante temporale in T: S = {Si i T} Si è una funzione di valutazione. Assegna al tempo i un valore ad ogni nome di variabile, una funzione ad ogni nome di funzione, una relazione ad ogni nome di predicato. Enrico Giunchiglia Ingegneria del Software II 142

143 Sulla base della struttura di interpretazione, si generalizza una funzione di valutazione che assegna i valori ad ogni formula TRIO Esempi: Si(Futr(out(m), 5)) = true iff Si+5(out(m)) = true Si(Past(in(m), 5)) = true iff Si-5(in(m)) = true Futr(out(m), 5) è vera negli istanti 1 e 7 Past(in(m), 5) è vera all istante 6 Enrico Giunchiglia Ingegneria del Software II 143

144 Soddisfacibilità temporale: Una formula è temporalmente soddisfacibile in una interpretazione sse esiste almeno un istante di tempo in cui la formula è vera in(m) Futr(out(m), 5) è temporalmente soddisfacibile in questa interpretazione (è vera all istante 1, è falsa all istante 10) La struttura di interpretazione è un modello per la formula Enrico Giunchiglia Ingegneria del Software II 144

145 Validità temporale: Una formula è temporalmente valida in una struttura di interpretazione sse è vera PER OGNI istante di tempo in(m) Futr(out(m), 5) è temporalmente valida in questa struttura di interpretazione Validità: Una formula è valida sse è temporalmente valida in qualsiasi struttura di interpretazione Enrico Giunchiglia Ingegneria del Software II 145

146 TRIO: Esempio Interpretazione di in(m) Futr(out(m), 5) La formula è temporalmente valida nella struttura precedente (permette messaggi spuri) Per non avere messaggi spuri, si deve imporre: in(m) Futr(out(m), 5) Si noti la differenza tra le formule: in(m) Futr(out(m), 5) in Futr(out, 5) Enrico Giunchiglia Ingegneria del Software II 146

147 TRIO: Operatore Always Alw(F) =def F t (t>0 Futr(F, t)) t (t>0 Past(F, t)) Serve per asserire proprietà invarianti. Es: Alw(in(m) Futr(out(m), 5)) Una formula è tempo invariante sse per ogni struttura di interpretazione è temporalmente valida o temporalmente non soddisfacibile Le specifiche TRIO sono sempre formule tempo invarianti L operatore Alw racchiude implicitamente ogni specifica TRIO Enrico Giunchiglia Ingegneria del Software II 147

148 TRIO: Esempi di operatori derivabili Lasted, Lasts: utili per asserire la durata di un fenomeno. Lasted(F,t) é vera all istante corrente i iff F é vera nell intervallo aperto (i-v,i) con v valore corrente del termine temporale t Within: Within(F,t) é vera all istante corrente i sse F é vera in almeno un istante dell intervallo aperto (i-v, i+v) con v valore corrente del termine temporale t Until, Since: Until(F,G) é vera all istante corrente iff F é vera almeno fino alla prossima occorrenza in cui G é vera: si richiede che G valga in qualche istante futuro Enrico Giunchiglia Ingegneria del Software II 148

149 TRIO: Lampada con Timer Una lampada con pulsante che fa partire un timer accende la lampada per 10 secondi Specifica del sistema in TRIO (Alw sottinteso): TurnOn: predicato vero quando il pulsante é premuto Light: predicato vero quando la lampada é accesa Enrico Giunchiglia Ingegneria del Software II 149

150 Prima Soluzione: TurnOn Lasts(Light,10) Un modello (a tempo continuo): Presenza di soluzioni spurie E con tempo discreto cosa succede? Enrico Giunchiglia Ingegneria del Software II 150

151 Seconda soluzione: TurnOn Lasts(Light,10) Un modello (a tempo continuo): Si eliminano soluzioni spurie > 10 secondi E con tempo discreto cosa succede? Enrico Giunchiglia Ingegneria del Software II 151

152 Terza soluzione: TurnOn Light Lasts(Light,10) Light t (0<t<10 Past(TurnOn Light,t)) Un modello (a tempo continuo): Si eliminano tutte le soluzioni spurie E con tempo discreto cosa succede? Enrico Giunchiglia Ingegneria del Software II 152

153 TRIO: Controllo remoto di una lampada La lampada rimane accesa o spenta finchè non arriva un nuovo segnale dal telecomando Predicati: Turn({ON, OFF}) Light Enrico Giunchiglia Ingegneria del Software II 153

154 Turn(ON) Until(Light, Turn(OFF)) dove Until(F, G) Enrico Giunchiglia Ingegneria del Software II 154

155 Turn(OFF) UntilW( Light, Turn(ON)) dove UntilW(F, G) =def Until(F, G) AlwF(F) (Turn(ON) Turn(OFF)) Non determinismo dello stato iniziale Enrico Giunchiglia Ingegneria del Software II 155

156 TRIO: Sistema di Monitoraggio mes M controlla lo stato di R: Ogni ora R deve mandare ad M un messaggio (mes) con info sul suo stato Se M non riceve il messaggio allo scadere di un ora, inizia la procedura di verifica: M invia a R il messaggio con R deve rispondere entro 5 sec con il messaggio ans seguito entro i successivi 5 sec dal messaggio mes Altrimenti, M emette il segnale idle, che indica che lo stato di R è scorretto Enrico Giunchiglia Ingegneria del Software II 156

157 Predicati dipendenti dal tempo: con, mes, ans con LastTime(mes, 3600) dove LastTime(F, t) =def t>0 Past(F, t) x (0<x<t Past( F, x)) idle ((Past(con, 5) Lastedii( ans, 5)) (Past(ans, 5) Lastedii( mes, 5))) dove Lastedii(F, t) =def x (0 x t Past(F, x)) Enrico Giunchiglia Ingegneria del Software II 157

158 TRIO: Esercizio Un sistema di allarme è costituito da due sensori (S1 ed S2), una sirena, una centralina di controllo La centralina di controllo attiva la sirena: Dopo 30 sec. dal ricevimento di un segnale da S1, a meno che in tale intervallo il sistema non venga disattivato Non appena riceve un segnale da S2 Una volta attivata, la sirena rimane in funzione fino a quando il sistema non viene disattivato e comunque non più di 5 min. Enrico Giunchiglia Ingegneria del Software II 158

159 Tecniche di Specifica dei Requisiti Linguaggi Formali di Specifica Specifiche Algebriche