Esercitazione I.S. II a.a. 2001/2002 Un Nuovo Frame Chiara Casanova Alberto Grillo Massimo Ruffa

Descrizione del Frame Utile per la Automazione di un Business Idea intuitiva per una classe di problemi parte del mondo fisico la cui automazione è controllata da operatori che posso essere identificati in usufruitori del business ( Users ) gestori del Business Il problema è costruire un sistema software che accetti i comandi degli operatori e li esegua in accordo con i requisiti e la business logic

Presentazione del Frame 1/2 Design Domain ( Business Model ) Requirement Commanded Behaviour Provider … User … * System Automatized … Generic … bound boundaries

Presentazione del Frame 2/2 Design Domain ( Business Model ) Requirement Commanded Behaviour Provider User U_Req S_Resp P_Resp S_Req. bound * Automatized … Generic … boundaries System S_Act

Entità costituenti il Domain User –utenti del sistema Provider –fornitori di servizi al sistema Generic –presenti concettualmente nel dominio ma non sono direttamente coinvolte dal system Automatized –“pezzi” di realtà simulati/sostituiti dal sistema

Comunicazioni P_Resp –Risposte che i providers forniscono al sistema U_Req –Richieste che gli users rivolgono al sistema S_Resp –Risposte che il sistema fornisce agli users S_Req –Richieste che il sistema rivolge ai providers ( per soddisfare richieste di users ) S_Act –Messaggi/comunicazioni che il sistema invia/instaura a seguito di computazioni/eventi interni o di sua iniziativa. –Possono essere conseguenza dell’ automazione di entità attive del domain che non devono perdere del tutto la propria autonomia decisionale una volta incorporate dall’ applicazione ( vicino al concetto di agente ) NOTA –la linea tratteggiata * evidenzia le comunicazioni fittizie tra sistema e entità automatizzate ( racchiuse nel bound )

Maggiori dettagli sui propositi del Frame Il concetto di Automazione modella la necessità di eliminare dal Domain delle entità reali e concettualizzarle all’ interno della software application ( System ) presente nel design. Per migliorare la comprensione sopraeleviamo il Design e proiettiamo la sua ombra sul Domain evidenziando le entità che vengono automatizzate. L’ attenzione deve essere rivolta a due aspetti in particolare : 1.Nel normale Commanded Behaviour le entità presenti nel dominio vengono considerate come preesistenti rispetto all’inizio del funzionamento del sistema e comunicano con la machine tramite eventi. Ora tutte quelle automatizzate sono create dal system quindi presenti nella realtà digitale solo dopo la messa in opera del system 2.Le comunicazioni tra le entità “automatized” ed il system non avvengono più nel modo esterno-interno tipico del Commanded Behaviour ma ( sempre che avvengano ) interno-interno

Business Logic Approfondimento : Business Logic Per rendere il frame più application- oriented si deve descrivere la logica del business ovvero le caratteristiche/vincoli che regolano la business application Include proprietà specifiche delle entità del Domain Design Domain ( Business Model ) Provider User U_Req S_Resp P_Resp S_Req. bound * Automatized … Generic … boundaries System S_Act

Automation Frame : Specification Business Logic Design Domain ( Business Model ) Provider User U_Req S_Resp P_Resp S_Req. bound * Automatized … Generic … boundaries System S_Act Requirement Commanded Behaviour Sistema Dinamico strutturato Proprietà addizionali sul sistema dinamico strutturato

Domain : Specification 1/2 Provider … User … Automatized … Generic … bound boundaries È un sistema dinamico strutturato (sds) chiuso (cioè non vi sono interazioni con il mondo esterno e pertanto le etichette delle sue transizioni saranno sempre l’insieme vuoto di interazioni elementari). Per questa ragione vengono cancellate le parti riguardanti le interazioni elementari nella specifica dell’sds Il sistema strutturato descritto è formato da sistemi semplici (user, provider, automatized e generic) Le proprietà sull’ sds costituiscono la business logic

Domain : Specification 2/2 Provider User U_Req S_Resp P_Resp S_Req. System S_Act È un sistema dinamico strutturato (sds) chiuso Le proprietà addizionali sull’ sds costituiscono i requisiti, quindi il commanded behaviour INTERAZIONI ELEMENTARI LOCALI

Interazioni Elementari Locali Le Ei dei sottosistemi sono suddivise in 5 categorie: –S_Resp Interazioni elementari corrispondenti a una comunicazione unidirezionale tra il sistema e gli User, a seguito di una richiesta di quest’ultimi –S_Req Interazioni elementari corrispondenti a una richiesta di servizio da parte del sistema nei confronti dei Provider –P_Resp Interazioni elementari corrispondenti a una comunicazione unidirezionale tra i Provider e il sistema, a seguito di una richiesta di quest’ultimo –U_Req Interazioni elementari corrispondenti a una richiesta da parte degli User nei confronti del sistema –S_Act Interazioni elementari corrispondenti a delle comunicazioni unidirezionali che il sistema trasmette agli User

Interazioni Elementari Locali I sottosistemi cooperano soltanto effettuando simultaneamente le interazioni condivise. Quindi le proprietà di sincronizzazione tra le diverse Ei locali sono standard e non dipendono dal caso particolare. Lo stesso vale per le proprietà di Local Versus Global (che nel nostro caso non ci sono)

Requirement : Specification Provider User U_Req S_Resp P_Resp S_Req. System S_Act Proprietà a riguardo –Entità automatizzate attive –Interazioni elementari

Requirement : Specification La formalizzazione avviene con –S_Resp Pre-condition / Vitality / Incompatibility –S_Req Pre-condition / Post-condition / Vitality / Incompatibility –P_Resp Pre-condition / Incompatibility –U_Req Pre-condition / Post-condition / Incompatibility –S_Act Pre-condition / Post-condition / Vitality / Incompatibility Notare –Il system è Event Driven gli user effettuano richieste, alla sollecitazione il system risponde Il system effettua rechieste ai providers, alla sollecitazione i providers rispondono

Business Logic Istanziazione del frame: Lotteria Algebrica L-AL Commanded Behaviour Gestore Accessi Posta Elettronica Gestore CC Cliente Giocatore (**) (*) Biglietto, Legge Ordinamento Direttore Notaio 5

Elenco delle comunicazioni 1.Registrarsi, Collegarsi, Scollegarsi, Cancellarsi, Compra_Biglietto, Biglietti_Disponibili 2.Sei_Registrato, Registrazione_Fallita, Sei_collegato, Fine_Collegamento, Collegamento_Fallito, Sei_Cancellato, Cancellazione_Fallita, Sono_Disponibili, Scollegamento_Fallito, Biglietto_Acquistato 3.NonEsiste_Giocatore, Cancellato_Giocatore, Codice_OK, Codice_KO, Carta_OK, Carta_KO, Addebito_Fatto, Addebito_Negato 4.Registra, Collega_Giocatore, Controlla_Giocatore, Controlla_CC, Addebita, Manda_ 5.Distribuisci_Biglietti_Omaggio, Estrai, Inizia_Nuova_Lotteria

Descrizione della Business Logic (1/3) Per ogni lotteria va fissata una dimensione ( Dim ) che determinerà la quantità dei suoi biglietti Il numero di biglietti per ogni lotteria è 2*Dim+1 Ogni lotteria ha Legge e Ordinamento unici Dopo che sono stati venduti Dim+1 biglietti la Legge può essere usata in qualunque momento e quante volte si vuole ( prima della fine della lotteria ) Legge e Ordinamento vanno depositati da un notaio Per ogni lotteria il direttore deve essere unico Estrazione può avvenire solo nel momento in cui non esistono più biglietti disponibili Non ci può essere più di una lotteria attiva nello stesso momento I giocatori vengono avvisati via di –inizio/fine lotteria –eventuale biglietto omaggio –eventuale vincita

(**) Descrizione della Business Logic (2/3) Ogni giocatore ha diritto a numero biglietti omaggio pari al numero dei biglietti acquistati Direttore può decidere di assegnare ai giocatori che ne hanno diritto un numero di biglietti arbitrario ( non superiore a quello dei biglietti acquistati ) I clienti possono giocare solo nel momento in cui diventano giocatori cioè si registrano e acquisiscono un codice identificativo all’ interno del sistema Nota Ogni volta che ci si collega al sistema è necessario possedere una chiave di sessione direttamente gestita dall’ applicazione

Descrizione della Business Logic (3/3) Biglietti –Ogni rappresentazione interna del biglietto è unica –Numero dei biglietti è compreso tra –Dim e Dim ( Dim=dimensione della lotteria ) Giocatori –Giocatore deve avere un codice identificativo all’ interno del sistema ( sua rappresentazione interna ) Legge –Deve generare numeri tra –Dim e Dim Ordinamento –Deve essere un ordine totale su un insieme che contiene numeri tra –Dim e Dim

Domain Individuazione dei sottosistemi presenti: Utente (raggruppa Giocatore e Cliente) Direttore Gestore degli Accessi Gestore delle Carte di Credito Posta Elettronica Lotteria

D:Direttore ? Vincitori:Sequence(Utenti) ? Inizia_Lotteria: Ordinamento x Legge x Nat ? Distribuisci_BilOmaggio: Nat ? Estrai ? Manda: String x String Ga:Gestore Accessi ! Controllo_DatiC: DatiP x DatiC x Bool ! Cancellami: DatiP ! Registrami: DatiP x DatiC ! Collegami: DatiP ! Scollegami: DatiP ? RegistraC: DatiC x DatiP ? Collegato: DatiP x Bool ? Cancellato: DatiP x Bool ? Scollegato: DatiP x Bool ? Registrato: DatiP x DatiC x Bool Gcc:Gestore CartaCredito ? Controllo_DatiC: DatiP x DatiC x Bool ? Addebito: DatiP x DatiC x Int x Nat x Bool ! RegistraC: DatiC x DatiP ! Acq_Bil: DatiP x DatiC x Int Pt:Posta Elettronica ! Manda: String x String L:Lotteria Dim: Nat Assegnati: Set(Int) ! Vincitori:Sequence(Utenti) ! Inizia_Lotteria: Ordinamento x Legge x Nat ! Distribuisci_BilOmaggio: Nat ! Estrai U:Utente Dati: DatiP Carta: DatiC BilOmaggio: Nat ? Cancellami: DatiP ? Registrami: DatiP x DatiC ? Collegami: DatiP ? Scollegami: DatiP ? Addebito: DatiP x DatiC x Int x Nat x Bool ! Collegato: DatiP x Bool ! Cancellato: DatiP x Bool ! Scollegato: DatiP x Bool ! Registrato: DatiP x DatiC x Bool ! Acq_Bil: DatiP x DatiC x Int Nota: ? Indica che e’ una richiesta (in Uscita) ! Una risposta (in Entrata)

Requirement Individuazione dei sottosistemi presenti: Giocatore Cliente Direttore Gestore degli Accessi Gestore delle Carte di Credito Posta Elettronica Lotteria

D:Direttore ? Vincitori:Sequence(Giocatore) ? Inizia_Lotteria: Ordinamento x Legge x Nat ? Distribuisci_BilOmaggio: Nat ? Estrai Ga:Gestore Accessi ! NonEsiste_Giocatore ! Cancellato_Giocatore ! Codice_Ok:DatiP x Codice x Chiave ! Codice_Ko: DatiP x Codice ? Registra: DatiP x DatiC x Codice ? Collega_Giocatore: DatiP x Codice ? Controlla_Giocatore: DatiP x Codice Gcc:Gestore CartaCredito ! Addebito_Fatto ! Addebito_Negato ! Carta_Ok: DatiC ! Carta_Ko: DatiC ? Controlla_CC: DatiC ? Addebito: DatiC x Nat Pt:Posta Elettronica ! Manda: String x String Nota: ? Indica che e’ una richiesta (in Uscita) ! Una risposta (in Entrata) ! Registrarsi: Cliente x DatiP x DatiC ? Sei_Registrato: Codice ? Registrazione_Fallita Cl:Cliente ! Collegarsi: Giocatore x DatiP x Codice ! Scollegarsi: Giocatore x Chiave ! Cancellarsi: Giocatore x DatiP x Codice ! Compra_Biglietto: Giocatore x Chiave x Int ! Biglietti_Disponibili: Giocatore ? Sei_Collegato: Chiave ? Sei_Scollegato ? Sei_Cancellato ? Sono_Disponibili: Sequence(Int) ? Biglietto_Acquistato: Int ? Errore: String Gu:Giocatore datiP: DatiP Carta: DatiC BilOmaggio: Int Chiave_Sessione: Chiave Cod: Codice

L:Lotteria Dim: Nat Assegnati: Set(Int) Collegati: Sequence(Chiave) ! Vincitori:Sequence(Giocatore) ! Inizia_Lotteria: Ordinamento x Legge x Nat ! Distribuisci_BilOmaggio: Nat ! Estrai ! Sei_Collegato: Chiave ! Sei_Scollegato ! Sei_Cancellato ! Sono_Disponibili: Sequence(Int) ! Biglietto_Acquistato: Int ! Errore: String ! Sei_Registrato: Codice ! Registrazione_Fallita ! Registra: DatiP x DatiC x Codice ! Collega_Giocatore: DatiP x Codice ! Controlla_Giocatore: DatiP x Codice ! Controlla_CC: DatiC ! Addebita: DatiC x Nat ? Manda_ String x String ? Registrarsi: Cliente xDatiP x DatiC ? Collegarsi: Giocatore x DatiP x Codice ? Scollegarsi: Giocatore x Chiave ? Cancellarsi: Giocatore x DatiP x Codice ? Compra_Biglietto: Giocatore x Chiave x Int ? Biglietti_Disponibili: Giocatore ? Addebito_Fatto ? Addebito_Negato ? Carta_Ok: DatiC ? Carta_Ko: DatiC ? Codice_Ok:DatiP x Codice x Chiave ? Codice_Ko: DatiP x Codice