Sviluppo dell’“Enterprise” application Lavaza

1. Sviluppo dell’“Enterprise” applicationLavaza

2. Prima puntata

3. 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è.

4. Cosa mettere nei tre strati Client Business Enperprise IS …….. 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 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 (??)

5. 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

6. Seconda puntata

7. EIS tier • In questa applicazione lo strato EIS contiene giusto un unico database • Schema del data base

8. <<entity>> <<entity>> <<entity>> Sell Refill Consumer 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} name: String surname: String login: String {quella che ogni persona del dipartimento usa nel suo indirizzo di email} deb: Int {il debito corrente} <<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} Schema del database In questo caso usiamo una notazione UML-like, self-explaining, ma è possibile usarne altre (es. entity relationship) in questo caso non ci sono relazioni tra le varie entità

9. 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

10. 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

11. 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è

12. <<session>> <<session>> H_Sell H_Debit <<session>> <<session>> Check Statistic <<session>> H_Refill Session beans (2) 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

13. Sell{quella del mese corrente} Situation AC H_Sell sellMon(nPks) sellMon(nPks) sold(nPks) Cosumer{quella con login = lg} Sell{quella del mese corrente} Situation AC H_Sell sellCred(lg,nPks) sellCred(nPks) debit(nPks) sold(nPks) H_Sell (gestire una vendita) in contanti a credito

14. Consumer{quella con login = lg} AC H_Debit M =debitOf(lg) d = get_deb() show(lg,b) pay(lg,b) payed(b) H_Debit (gestire i debiti)

15. Situation AC Check check() (c,pkgs) = how() show(c,pkg) Check (controlla situazione)

16. Situation AC H_Refill arrived(nBox) refill&Pay(nBox) H_Refill (registra un rifornimento)

17. si:Selli  COD(y1,y2) {quello di codice I} AC Statistic statistic(y1,y2) qi = HowMany() show(q1 :: … ::qk) Static (esamina le statistiche di vendita) COD(y1,y2) = { 1, …, k} = codici dei mesi tra inizio anno y1 e l’ultimo mese dell’anno y2

18. 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à

19. Completare la definizione dei beans • classificarli rispetto alle varie tipologie • definire le loro interfacce • definire i loro metodi

20. <<entity>> Refill <<entity>> <<entity>> Situation Consumer day: int month: Int year: Int quantity: Int key: int {= day * 51 * month * 37 * year * 41} <<entity>> 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} Sell name: String surname: String login: String {quella che ogni persona del dipartimento usa nel suo indirizzo di email} deb: Int = 0 {il debito corrente} month: Int year: Int quantity: Int {in bustine} key: int {= month *37 * year * 41} howmany(): Int sold(Int) 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 beans • tutti con persistenza gestita dal container, e nessuno sarà remoto getDeb(): Int payed(Int) debits(Int) {la definizione di queste operazioni è piuttosto ovvia}

21. <<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_Sell remoto, stateless

22. <<session>> H_Debit …….. ………. Sessions Beans • H_Debit remoto, statefull • finire per esercizio e fare gli altri

23. 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

24. Transaction • ????

25. Security • quali problemi, al massimo il furto di qualche Euro da parte di un mio collega/personale delle pulizie • autenticare l’unico utente

26. 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

27. Fine lezione