Esercitazione I.S. II a.a. 2001/2002 Un Nuovo Frame

1
Esercitazione I.S. IIa.a. 2001/2002Un Nuovo
Frame
Chiara CasanovaAlberto GrilloMassimo Ruffa
2
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

3
Presentazione del Frame 1/2
Design
Domain ( Business Model )
System
User
Provider
boundaries

Requirement
bound

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

Requirement
bound
Commanded Behaviour
Automatized
Generic
5
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

6
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 )

7
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
• Nel normale Commanded Behaviour le entità
  presenti nel dominio vengono considerate come
  preesistenti rispetto allinizio 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
• 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

8
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 )
System
S_Act
User
U_Req
S_Resp
P_Resp
Provider
boundaries
S_Req.

bound
Automatized
Generic
Business Logic
9
Automation Frame Specification
Sistema Dinamico strutturato
Design
Domain ( Business Model )
System
S_Act
User
U_Req
S_Resp
P_Resp
Provider
boundaries
S_Req.

bound
Requirement
Automatized
Commanded Behaviour
Generic
Business Logic
Proprietà addizionali sul sistema dinamico
strutturato
10
Domain Specification 1/2

• È un sistema dinamico strutturato (sds) chiuso
  (cioè non vi sono interazioni con il mondo
  esterno e pertanto le etichette delle sue
  transizioni saranno sempre linsieme vuoto di
  interazioni elementari). Per questa ragione
  vengono cancellate le parti riguardanti le
  interazioni elementari nella specifica dellsds
• Il sistema strutturato descritto è formato da
  sistemi semplici (user, provider, automatized e
  generic)
• Le proprietà sull sds costituiscono la business
  logic

11
Domain Specification 2/2

• È un sistema dinamico strutturato (sds) chiuso
• Le proprietà addizionali sull sds costituiscono
  i requisiti, quindi il commanded behaviour

System
S_Act
User
U_Req
S_Resp
P_Resp
Provider
S_Req.
INTERAZIONI ELEMENTARI LOCALI
12
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 questultimi
• 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
  questultimo
• 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

13
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)

14
Requirement Specification

• Proprietà a riguardo
• Entità automatizzate attive
• Interazioni elementari

System
S_Act
User
U_Req
S_Resp
P_Resp
Provider
S_Req.
15
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

16
Istanziazione del frameLotteria Algebrica
L-AL
5
1
Cliente Giocatore
2
3
Gestore Accessi Posta Elettronica Gestore CC
4
Biglietto, Legge Ordinamento Direttore
Commanded Behaviour
Notaio

• Business
• Logic

()
()
17
Elenco delle comunicazioni

1. Registrarsi, Collegarsi, Scollegarsi,
   Cancellarsi, Compra_Biglietto, Biglietti_Disponibi
   li
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_Email
5. Distribuisci_Biglietti_Omaggio, Estrai,
   Inizia_Nuova_Lotteria

18
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 è
  2Dim1
• Ogni lotteria ha Legge e Ordinamento unici
• Dopo che sono stati venduti Dim1 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 e-mail di
• inizio/fine lotteria
• eventuale biglietto omaggio
• eventuale vincita

19
() 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

20
Descrizione della Business Logic (3/3)

• Biglietti
• Ogni rappresentazione interna del biglietto è
  unica
• Numero dei biglietti è compreso tra Dim e Dim
• ( Dimdimensione 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

21
Domain

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

22
GaGestore 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
Nota ? Indica che e una richiesta (in
Uscita) ! Una risposta (in Entrata)
23
Requirement

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

24
GuGiocatore
datiP DatiP Carta DatiC BilOmaggio
Int Chiave_Sessione Chiave Cod Codice
! 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
Nota ? Indica che e una richiesta (in
Uscita) ! Una risposta (in Entrata)
25
(No Transcript)