Sviluppo dell’“Enterprise”
application
Lavaza
Prima puntata
Scopo dell’applicazione
• Nel nostro dipartimento abbiamo una macchina per il caffè che utilizza
delle cialde preconfezionate. Tali cialde sono vendute in bustine che ne
contengono due al prezzo di ¤ 0.62. In genere vengono acquistati
gruppi di 5 bustine al prezzo di ¤ 3.10.
• Daniela, una delle nostre segretarie si occupa della vendita, e di
richiedere i rifornimenti quando è il momento.
• Le bustine sono fornite in scatole da 50.
• Daniela, per prevedere quando è il momento giusto di fare rifornimento,
è interessata a sapere quanti caffè ha ancora disponibili, ed a
informazioni statistiche riguardanti quanti caffè si vendono durante i vari
periodi.
• Molte volte noi acquistiamo i caffè a credito, e siamo molto smemorati.
• Quando Daniela non è presente in Dipartimento altro personale
amministrativo si occupa di venderci i caffè.
Cosa mettere nei tre strati
Client
un solo tipo di
application client
in ogni momento
una sola istanza
sarà in
esecuzione
(sulla macchina
di Daniela o
dell’altra persona
che venderà i
caffè in sua
vece)
Business
……..
Enperprise IS
Un database
contenente le
seguenti
informazioni
• debiti (crediti ?) dei
consumatori
• numero di bustine
vendute in ogni
mese
• il numero delle
bustine disponibili
• i soldi in cassa
• quando sono stati
fatti gli ordini (??)
Application client
• funzionalita offerte
– Registrare una vendita, classificata in a credito o in contanti
(facilitazioni per 5 bustine, una scatola)
– Mostrare quante bustine sono disponibili
– Mostrare le statistiche di vendita (bustine vendute in ogni mese)
– Controllare se un consumatore ha dei debiti
– Pagare un debito (totalemente o anche parzialmente ?)
– Mostrare quanto ci deve essere in cassa
– Registrare l’arrivo di un rifornimento di caffè
• GUI
– schemino grafico
– deve offrire mezzi per accedere alle funzionalità di cui
sopra
• descrivere operativamente le funzionalità di cui
sopra, dopo aver definito gli altri due strati
Seconda puntata
EIS tier
• In questa applicazione lo strato EIS contiene giusto
un unico database
• Schema del data base
Schema del database
In questo caso usiamo una notazione UML-like, self-explaining, ma è
possibile usarne altre (es. entity relationship)
<<entity>>
<<entity>>
<<entity>>
Consumer
Sell
Refill
name: String
surname: String
login: String
{quella che ogni persona
del dipartimento usa nel
suo indirizzo di email}
deb: Int
{il debito corrente}
month: Int
year: Int
quantity: Int
key: int
{= month * 37 * year * 43}
day: int
month: Int
year: Int
quantity: Int
key: int
{= day * 51 + month * 37 * year * 43}
<<entity>>
Situation
cash: Euro
{money contained in the cash}
coffee: Int
{number of packages available}
quantity: Int
key: int
{ = 1, since there will be always a
unique object of this class}
in questo caso non ci sono
relazioni tra le varie entità
Business tier
• schema (software architecture)
– mostra quante istanze di enterprise beans ci sono e
come interagiscono tra di loro
• gli enterprise beans, opportunamente classificati,
utilizzati per questa applicazione
Entity beans
• Lo schema del database presentato
precedentemente definisce in modo ovvio quali
saranno gli entity bean utilizzati nella nostra
applicazione: uno per ogni relazione del database
• Quale tipo di persistenza avranno?
– la persistenza gestita dal contenitore sembra
ragionevole in questo caso, pertanto scegliamo quella
Session beans (1)
• quali/quante/di che tipo sono le sessioni interattive
dell’application client (AC da ora in poi) con lo
strato business ?
– sono possibili varie scelte
* minimale
˚ un’unica sessione che inizia quando l’AC parte e finisce
quando l’AC termina l’esecuzione
* massimale
˚ una sessione differente per gestire ogni funzionalità dell’AC
* preferita, una sessione per questi gruppi di funzionalità, che
ragionevolmente saranno eseguiti assieme
˚
˚
˚
˚
effettuare una vendita
controllare la situazione (bustine disponibili e soldi in cassa)
vedere le statistiche di vendita
gestire il debito di un consumatore (controllare quanto deve, e
magari pagare)
˚ registrare l’arrivo di un rifornimento di caffè
Session beans (2)
<<session>>
H_Sell
<<session>>
Check
<<session>>
H_Debit
<<session>>
Statistic
<<session>>
H_Refill
Vediamo ora grossolanamente che cosa fanno
presentando possibili scenari (casi/esempi di esecuzione) delle loro
attività
per semplicità ora non consideriamo le possibili situazioni di errore
aggiungerle per esercizio
H_Sell (gestire una vendita)
in contanti
AC
Situation
H_Sell
Sell
{quella del mese corrente}
sellMon(nPks)
sellMon(nPks)
sold(nPks)
a credito
AC
H_Sell
sellCred(lg,nPks)
Cosumer
{quella con login = lg}
Situation
Sell
{quella del mese corrente}
sellCred(nPks)
debit(nPks)
sold(nPks)
H_Debit (gestire i debiti)
AC
H_Debit
M =debitOf(lg)
d = get_deb()
show(lg,b)
pay(lg,b)
payed(b)
Consumer
{quella con login = lg}
Check (controlla situazione)
AC
Check
check()
(c,pkgs) = how()
show(c,pkg)
Situation
H_Refill (registra un rifornimento)
AC
H_Refill
arrived(nBox)
refill&Pay(nBox)
Situation
Static (esamina le statistiche di vendita)
AC
Statistic
i  CO D(y1,y2)
{quello di codice I}
si:Sell
statistic(y1,y2)
qi = HowMany()
show(q1 :: … ::qk)
COD(y1,y2) = { 1, …, k} =
codici dei mesi tra
inizio anno y1 e
l’ultimo mese dell’anno y2
Message-driven beans
• Servono per questa applicazione ?
– No; infatti, questa applicazione, come pure le sue
componenti, non devono ricevere comunicazioni
asincrone da parte di altre entità
Completare la definizione dei beans
• classificarli rispetto alle varie tipologie
• definire le loro interfacce
• definire i loro metodi
Entity beans
• tutti con persistenza gestita dal container, e
nessuno sarà remoto
<<entity>>
Consumer
name: String
surname: String
login: String
{quella che ogni persona
del dipartimento usa nel
suo indirizzo di email}
deb: Int = 0
{il debito corrente}
getDeb(): Int
payed(Int)
debits(Int)
{la definizione di
queste operazioni è
piuttosto ovvia}
<<entity>>
Situation
cash: Euro
{money contained in the cash}
coffee: Int
{number of packages available}
quantity: Int
key: int
{ = 1, since there will be always a
unique object of this class}
refil&pay(nBox:Int)
{cash = cash - nBox * 31.00;
quantity = quantity + nBox * 50}
how(): Int x Int
{return cash, quantity}
sellMon(nPkgs: Int)
{quantity = quantity-nPkgs;
cash = cash + 0.62 * nPkhgs}
sellCred(nPkgs: Int)
{quantity = quantity-nPkgs}
<<entity>>
Sell
month: Int
year: Int
quantity: Int {in bustine}
key: int
{= month *37 * year * 41}
howmany(): Int
sold(Int)
<<entity>>
Refill
day: int
month: Int
year: Int
quantity: Int
key: int
{= day * 51 * month * 37 * year * 41}
Sessions Beans
• H_Sell remoto, stateless
<<session>>
H_Sell
month: int
year: int
currentMonth =[derived] month * 31 * year * 37
sellMon(nPkgs: Int)
{findSituation(1).sellMon(nPkgs);
findSell(currentMonth).sold(nPkgs)}
sellCred(log: String, nPkgs: Int)
{findSituation(1).sellMon(nPkgs);
findSell(currentMonth).sold(nPkgs);
findConsumer(log).debit(nPkgs)}
Sessions Beans
• H_Debit remoto, statefull
<<session>>
H_Debit
……..
……….
• finire per esercizio e fare gli altri
Reusable components
• non abbiamo riusato niente, Ok
• possiamo pensare qualcuna delel nostre
componenti in vista del riuso ? (ovviamente
rendendole un poco più generale)
• Statistic…
• Situation
Transaction
• ????
Security
• quali problemi, al massimo il furto di qualche Euro
da parte di un mio collega/personale delle pulizie
• autenticare l’unico utente
Esercizi
L0] Preparare uno schema per la GUI dell’application
client di Lavaza.
L1] rifare la documentazione sul progetto di Lavaza
presentato in questo documento utilizzando altri
tipi di notazioni, precisando quale usate (es., UML
puro preparato con tools, disegni & testo
completamenti liberi)
L2] modificare il progetto di Lavaza secondo i vostri
gusti, e modificare in modo corrispondente la
documentazione presentato in questo documento
L3] Correggere un grossolano errore presente in
questo progetto
Fine lezione