Sviluppo dell’“Enterprise” application Lavaza
description
Transcript of Sviluppo dell’“Enterprise” application Lavaza
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è.
Client Business Enperprise IS
Cosa mettere nei tre strati
…….. 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)
Un databasecontenente 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 databaseIn questo caso usiamo una notazione UML-like, self-explaining, ma è possibile usarne altre (es. entity relationship)
Consumer
name: Stringsurname: Stringlogin: String {quella che ogni personadel dipartimento usa nelsuo indirizzo di email}deb: Int {il debito corrente}
<<entity>>Sell
month: Intyear: Intquantity: Int key: int{= month * 37 * year * 43}
<<entity>>Refill
day: intmonth: Intyear: Intquantity: Int key: int{= day * 51 + month * 37 * year * 43}
<<entity>>
Situationcash: 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}
<<entity>>
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)
H_Sell<<session>>
H_Debit<<session>>
Check<<session>>
Statistic<<session>>
H_Refill<<session>>
Vediamo ora grossolanamente che cosa fannopresentando possibili scenari (casi/esempi di esecuzione) delle loro attivitàper semplicità ora non consideriamo le possibili situazioni di erroreaggiungerle per esercizio
H_Sell (gestire una vendita)
AC H_Sell Situation Sell {quella del mese corrente}sellMon(nPks)
sellMon(nPks)
sold(nPks)
AC H_Sell Situation Sell {quella del mese corrente}sellCred(lg,nPks)
sellCred(nPks)
sold(nPks)
Cosumer {quella con login = lg}
debit(nPks)
in contanti
a credito
H_Debit (gestire i debiti)
AC H_DebitM =debitOf(lg)
Consumer {quella con login = lg}
d = get_deb()show(lg,b)
pay(lg,b)
payed(b)
Check (controlla situazione)
AC Checkcheck()
Situation
(c,pkgs) = how()show(c,pkg)
H_Refill (registra un rifornimento)
AC H_Refillarrived(nBox)
Situation
refill&Pay(nBox)
Static (esamina le statistiche di vendita)
AC Statisticstatistic(y1,y2)
si:Sell i COD(y1,y2){quello di codice I}
qi = HowMany()
show(q1 :: … ::qk) COD(y1,y2) = { 1, …, k} =codici dei mesi trainizio 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
Consumer
name: Stringsurname: Stringlogin: String {quella che ogni personadel dipartimento usa nelsuo indirizzo di email}deb: Int = 0{il debito corrente}
<<entity>>
getDeb(): Intpayed(Int)debits(Int){la definizione di queste operazioni è piuttosto ovvia}
Refill
day: intmonth: Intyear: Intquantity: Int key: int{= day * 51 * month * 37 * year * 41}
<<entity>>
Sell
month: Intyear: Intquantity: Int {in bustine}key: int{= month *37 * year * 41}
<<entity>>
howmany(): Intsold(Int)
Situationcash: 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}
<<entity>>
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}
Sessions Beans
• H_Sell remoto, stateless
H_Sell<<session>>
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)}
month: intyear: intcurrentMonth =[derived] month * 31 * year * 37
Sessions Beans
• H_Debit remoto, statefull
H_Debit<<session>>
……….
……..
• 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