Sviluppo dellEnterprise application Lavaza. Prima puntata.

Presentazione sul tema: "Sviluppo dellEnterprise application Lavaza. Prima puntata."— Transcript della presentazione:

1 Sviluppo dellEnterprise application Lavaza

2 Prima puntata

3 v. 3 Scopo dellapplicazione 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 v. 3 Client BusinessEnperprise 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 dellaltra 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 v. 3 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 larrivo 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 v. 3 EIS tier In questa applicazione lo strato EIS contiene giusto un unico database Schema del data base

8 v. 3 Schema del database In questo caso usiamo una notazione UML-like, self-explaining, ma è possibile usarne altre (es. entity relationship) Consumer name: String surname: String login: String {quella che ogni persona del dipartimento usa nel suo indirizzo di email} deb: Int {il debito corrente} > Sell month: Int year: Int quantity: Int key: int {= month * 37 * year * 43} > Refill day: int month: Int year: Int quantity: Int key: int {= day * 51 + month * 37 * year * 43} > 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à

9 v. 3 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 v. 3 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 v. 3 Session beans (1) quali/quante/di che tipo sono le sessioni interattive dellapplication client (AC da ora in poi) con lo strato business ? –sono possibili varie scelte *minimale ˚ununica sessione che inizia quando lAC parte e finisce quando lAC termina lesecuzione *massimale ˚una sessione differente per gestire ogni funzionalità dellAC *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 larrivo di un rifornimento di caffè

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

13 v. 3 H_Sell (gestire una vendita) ACH_Sell Situation Sell {quella del mese corrente} sellMon(nPks) sold(nPks) ACH_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

14 v. 3 H_Debit (gestire i debiti) ACH_Debit E = debitOf(lg) Consumer {quella con login = lg} E = get_deb() pay(lg,E) payed(E) return

15 v. 3 Check (controlla situazione) ACCheck (E,pkg) = check() Situation (E,pkgs) = how()

16 v. 3 H_Refill (registra un rifornimento) ACH_Refill arrived(nBox) Situation refill&Pay(nBox)

17 v. 3 Static (esamina le statistiche di vendita) ACStatistic giveData(today,y1,y2) si:Sell i COD(y1,y2) {quello di codice I} qi = HowMany() retrun (q1 :: … ::qk) COD(y1,y2) = { 1, …, k} = codici dei mesi tra inizio anno y1 e lultimo mese dellanno y2

18 v. 3 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 v. 3 Completare la definizione dei beans classificarli rispetto alle varie tipologie definire le loro interfacce definire i loro metodi

20 v. 3 Entity beans tutti con persistenza gestita dal container, e nessuno sarà remoto Consumer name: String surname: String login: String {quella che ogni persona del dipartimento usa nel suo indirizzo di email} deb: Euro = 0.00 {il debito corrente} > getDeb(): Euro pay(Euro) debit(Euro) {la definizione di queste operazioni è piuttosto ovvia} Refill day: int month: Int year: Int quantity: Int key: int {= day * 51 * month * 37 * year * 41} > Sell month: Int year: Int quantity: Int {in bustine} key: int {= month *37 * year * 41} > howmany(): Int sold(Int) Situation cash: Euro {money contained in the cash} coffee: Int {numero di busitne disponibili } key: Int { sempre = 1, dato che ci sarà sempre un unico oggettodi questa classe} > refil&pay(nBox:Int) {cash = cash - nBox * 31.00; quantity = quantity + nBox * 50} how(): Euro x Int {return cash, quantity} sellMon(nPkgs: Int) {coffee = coffee -nPkgs; cash = cash + 0.62 * nPkhgs} sellCred(nPkgs: Int) { coffee = coffee - nPkgs}

21 v. 3 Sessions Beans (1) H_Sell remoto, statefull H_Sell > 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: int year: int currentMonth =[derived] month * 31 * year * 37

22 v. 3 Sessions Beans (2) H_Debit remoto, statefull H_Debit > debitOf(lg: String): Euro {C = lg; findConsumer(C).getDeb();} pay(E:Euro) {findConsumer(C).paid(E)} C: String Check remoto, stateless Check > check(): Euro x Int {return findSituation(1).how(); }

23 v. 3 Sessions Beans (3) Statistic remoto, stateless Statistic > giveData(D: Date,Y1,Y2: Int): sequence(Int) {L = []; for y = y1 to y2 do for m = 1 to (if yearOf(D) = y then monthOf(D) else 12) L = L.add(findSell(Y*41 + m * 37).quantity; return L;}

24 v. 3 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

25 v. 3 Transaction ????

26 v. 3 Security quali problemi, al massimo il furto di qualche Euro da parte di un mio collega/personale delle pulizie autenticare lunico utente

27 v. 3 Schema (architettura software) Data base HSell Session Bean HDebit Session Bean Check Session Bean Statistic Session Bean HRefill Session Bean Consumer Entity Bean Situation Entity Bean Sell Entity Bean EJB Container Application Client

28 v. 3 Esercizi L0] Preparare uno schema per la GUI dellapplication 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

29 Terza puntata

30 v. 3 Preparare gli enterprise beans Scrivere il codice usando le appropriate API –javax.ejb (fornisce le le interfacce necessarie per gli enterprise beans) compilarlo impacchettarle aggiungendo il deployment descriptor (per mezzo di tools) –caso session bean –caso entity bean

31 v. 3 Session bean (remoto) per costruire un session bean (sia esso HSell), occorre preparare il seguente codice –Session bean class (HSellBean) –Home interface (HSellHome) –Remote interface (HSell)

32 v. 3 Session bean class caratteristiche –implementa linterfaccia SessionBean(in javax.ejb) –è pubblica [visibile ovunque] –non può essere astratta [non può essere istanziata] o finale [non può avere sottoclassi] –implementa uno o più metodi [devono differire per gIi argomenti] ejbCreate *permettono di fare alcune cose subito dopo che il bean è stato creato (~inizializzazione) –implementa i business metodi *quelli specifici delal sua attività e scopo –gli argomenti ed i tipi devono essere validi tipi RMI se il bean permette laccesso remoto –contiene un costruttore pubblico senza parametri –non deve definire il metodo finalize [quello per distruggere un oggetto direttamente senza aspettare il garbage colector]

33 v. 3 Home Interface estende linterfaccia javax.ejb.EJBHome per un session bean lo scopo della home interface è di definire i metodi create che I clienti remoti possono invocare ogni metodo create method nella home interface corrisponde ad un metodo ejbCreate nella bean class I tipi dei metodi create ed ejbCreate sono simili ma differenti per quello che segue –il numero e tipo degli argomenti devono corrispondere a a quelli del corrispondente metodo ejbCreate –un metodo create ritorna il tipo della remote interface dellenterprise bean (ma un ejbCreate ritorna void ) –la clausola throws del metodo create deve includere java.rmi.RemoteException e javax.ejb.CreateException

34 v. 3 Remote Interface estende javax.ejb.EJBObject definisce i metodi (relativi al) business che un cliente remoto può invocare I metodi definiti in una remote interface sono tali che –ogni metodo dellinterfaccia remotadeve corrispondere ad un metodo implementato nella enterprise bean class –il tipaggio del metodo deve essere identico a quello del metodo corrispondente nella enterprise bean clas –gli argomenti ed i tipi devono essere validi tipi RMI –la clausola throws deve includere java.rmi.RemoteException

35 v. 3 Help Classes nessuna

36 v. 3 Per esercizio codificare gli altri 4 session beans tutti remoti qualcuno avrà anche qualche classe helper (Euro)

37 v. 3 Sources Tre file –HSellBean.java –HSellHome.java –Hsell.java

38 v. 3 Altre features degli enterprise beans Environment entries –permettono di parametrizzare un bean (qualunque genere) con dei valori, che saranno poi forniti al momento dellinstallazione [vedere dettagli nel tutorial] –utili nellapplicazione Lavaza per *………… confrontare enterprise bean –metodo per fare ciò isIdentical –attenzione *ok per statefull session bean *sempre vero per stateless session beans *per gli entity beans si può anche comparare le loro due chiavi primarie passare una referenza a se stesso –non si può usare this (identità maneggiata dal container) –usare il metodo getEJBObject dellinterfaccia SessionContext

39 v. 3 Entity beans (persistenza gestita dal container) tutti quelli dellapplicazione Lavaza sono di questo tipo inoltre nessuno è remoto prendiamo esempio Consumer –il container si preoccupa di farlo corrispondere alle tuple/righe di una relazione –name: String –surname: String –login: String –deb: Double Occorre definire –Entity bean class (ConsumerBean) –Local home interface (ConsumerHome) –Local interface (ConsumerPlayer)

40 v. 3 Entity bean class deve essere definita come pubblica ed astratta deve implementare –linterfaccia EntityBean –zero o più metodi ejbCreate ed ejbPostCreate –i metodi per laccesso get e set, definiti come astratti, dei campi persistenti e relazione –i metodi select necessari, definiti come astratti –i metodi home –i metodi relativi al business specifico non deve implementare –i metodi finder –il metodo finalize

41 v. 3 Metodi accesso il container permette di accedere a dei campi virtuali corrispondenti agli attributi della relazione associata al bean es. per il campo Surname: String public abstract String getSurname(); public abstract void setSurname (String id); similnente per i campi corrispondenti alle relazioni (ma in questo caso non ne abbiamo nessuno)

42 v. 3 Metodi select per realizzare queries sul database espresse usando EJB QL –definite nel deplyment descriptor possono essere chiamati solo dai metodi dellentity bean class, ma non dai clienti in genere ritornano una collection non ce ne sono in Consumer

43 v. 3 Metodi Metodo ejbCreate –inizializza unistanza di un entity bean assegnando gli argomenti ai campi persistenti –dop il suo completamento, il container iniserisce una nuova riga nel database –serve per Consumer ? –no, ma ci dovrebbe essere, manca la funzionalità per inserire un nuovo Consumer (serve, per esempio quando ariva una nuova persona nel dipartimento –esercizio: Modificare il progetto Metodo ejbPostCreate –come per ejbCreate, ma per inizializzare i campi relazione

44 v. 3 Local Home Interface definisce i metodi create, finder e home che possono essere invocati dai clienti locali regole sintattiche per un metodo create –il nome inizia con create –ha lo stesso numero e tipo di argomenti come il corrispondente metodo ejbCreate nella classe entity bean –ritorna il tipo local interface type dellentity bean –la clausola throws include le eccezioni del corrispondente metodo ejbCreate nella classe entity bean, ed anche javax.ejb.CreateException regole sintattiche per un metodo finder –il nome inizia con find –il return tipo è quello dellinterfaccia local del bean, o una collezione di questi tipi –la clausola throws contiene javax.ejb.FinderException –il metodo findByPrimaryKey deve essere definito

45 v. 3

46 Local Interface definisce i metodi business ed accesso che un cliente local può invocare (chiaramente definiti nella entity bean class) nel nostro caso solo pay, debit e getDebit

47 Fine lezione

48 v. 3 Application Client Un application client J2EE è un programma stand alone lanciato con una command line o dal desktop che gli enterprise beans in esecuzione su un application server J2EE in genere ha una interfaccia visuale basata su Swing/AWT

49 v. 3 Come collegarsi ai beans localizzare la home interface del bean di interesse –basato su JNDI …… XXXHome home = …. creare istanze XXX myBeanName = home.create(); chiamare i metodi business myBeanName.METH(…..); Al momento della creazione dellapplicazione verranno fornite le informazioni per realizzare la prima parte