EJB 2.x – analýza problémovej domény 2.

V tomto článku si okrem iného zadefinujeme objektový model pre našu aplikáciu. Tento model však nemusí byť definitívny, ale postupne, ako sa naše vedomosti budú rozširovať, rozšírime si aj objektový model. V reálnom svete je cesta od use case diagramov k objektovému modelu pomerne bolestivá a málokedy jednoduchá. Avšak v záujme jednoduchosti preskočíme väčšinu týchto implementačných detailov a vrhneme sa rovno na dizajn. Napriek tomu, že je stále priskoro zaoberať sa umiestnením EJB z pohľadu dizajnu, ukážeme si niektoré základné ciele finálneho návrhu aplikácie.

Už z pohľadu definície on-line aukčnej siene je jasné, že je postavená na viacvrstvovej J2EE architektúre. To v jednoduchosti znamená, že prezentačná vrstva (Web Tier) postavená na JavaServer Pages a Java Servlets, musí byť oddelená od aplikačnej logiky, umiestnenej v samostatnej aplikačnej vrstve (Application Tier). Celá táto aplikačná logika (business logic), uzavretá v komponentoch EJB, bude zodpovedná za všetku komunikáciu s vrstvou EIS (Enterprise Information Systems), čo je v našom prípade samostatná relačná databáza.

Identifikácia objektov aplikačnej logiky

Objekt aplikačnej logiky, volajme ho biznis objekt, predstavuje kľúčový koncept problémovej domény, a obvykle ide o perzistentný objekt zviazaný s aplikáciou. Tieto objekty zapuzdrujú implementačné detaily reálnych objektov, ktoré reprezentujú. Biznis objekty by mali byť izolované od aplikačnej logiky, ktorá jediná vie ako tieto objekty využívať a „donútiť“ k vzájomnej spolupráci.

Zoberte si napríklad predmety ponúkané v dražbe. Každý predmet bude reprezentovaný biznis objektom Item, ktorý obsahuje atribúty definujúce predmet a metódy na manipuláciu s nimi. Napriek tomu tento objekt môže byť znovu použitý v akejkoľvek inej aplikácii, a z toho vyplýva, že by nemal obsahovať žiadne špecifiká týkajúce sa aukčného systému. Na úrovni aplikačnej logiky sa nachádza aplikačný kód, ktorý vie ako použiť biznis objekt Item. Takéto striktné oddelenie biznis objektov a aplikačnej logiky umožňuje ich jednoduchšie využívanie medzi aplikáciami. Aplikačný kód obsahujúci aplikačnú logiku sa často označuje pojmom aplikačný kontroler.

V nasledujúcej časti si vytvoríme úvodný zoznam biznis objektov potrebných pre aukčný systém a úvodný zoznam aplikačných kontrolerov. V obidvoch prípadoch využijeme na ich zápis UML. V ďalších článkoch sa dozviete, akú úlohu hrajú v implementácii biznis objektov takzvané entity beans a v implementácii aplikačnej logiky takzvané session beans.

V prípade aukčného systému každý návrhár veľmi rýchlo rozpozná, že entity typu aukcia, predmet aukcie, dražiteľ, ponuka a podobne, sú primárne biznis objekty. V reálnom svete nasleduje v tejto fáze pomerne detailná analýza, s cieľom identifikovať všetky biznis objekty budúcej aplikácie. Tejto fáze sa radšej vyhneme a rovno si ukážeme výsledok podobnej analýzy, potrebnej na budovanie nášho príkladu. Je možné použiť rôzne techniky, ale najbežnejší spôsob je využitie class diagramu. V tomto okamihu je dôležité, aby ste správne pochopili obsah jednotlivých objektov ako aj vzťahy medzi nimi. Odporúčam vám zobraziť si nasledujúci class diagram v samostatnom okne.

Biznis objekty reprezentujúce perzistentné entity aukčného domu

Class diagram je vždy skupina tried. Pri použití UML je trieda reprezentovaná určitým obdĺžnikom, obsahujúcim názov triedy a zoznamy atribútov a operácií resp. metód. Náš class diagram obsahuje primárny biznis objekt, reprezentovaný triedou EnglishAuction. Táto trieda má niekoľko atribútov, napríklad name alebo startingBid. V našom prípade je zoznam metód limitovaný na skutočné biznis metódy. Sú to metódy zabezpečujúce biznis funkcionalitu triedy EnglishAuction. Napríklad metóda submitBid spracováva prichádzajúce ponuky, pričom ako parameter očakáva ponúkané množstvo a referenciu na dražiteľa, čo je trieda Bidder. Metódy typu get/set však naša trieda neobsahuje. To však neznamená, že ich nebudeme potrebovať. Našťastie veľká vačšina CASE nástrojov vám dokáže automaticky vygenerovať potrebné get/set metódy.

Class diagram je však aj množina vzťahov medzi triedami. Tieto vzťahy sú typu inheritencia a asociácia. Asociácia je prezentovaná úsečkou medzi dvoma triedami a zároveň zobrazuje kardinalitu ich vzťahu. Táto kardinalita je vyjadrená číselne a všeobecne môže byť typu jeden-jeden, jeden-viac a viac-viac. Kardinalita môže používať buď samostatnú hodnotu alebo interval. Napríklad vzťah medzi triedami Bidder a Bid je označený ako 1..1 a 0..*. Slovne vyjadrené to znamená, že daná ponuka patrí jednému a práve jednému dražiteľovi, a že daný dražiteľ môže zadať 0 alebo viac ponúk. Toto je typický vzťah jeden-viac. Podobný vzťah je aj medzi triedami Bid a EnglishAuction, aj keď sú tu ďalšie dva vzťahy.

Identifikácia aplikačných kontrolerov

Po definovaní biznis objektov je treba zadefinovať aj aplikačnú logiku, ktorá bude s nimi pracovať. Aplikačná logika je uložená v aplikačných triedach, ktoré môžeme označiť ako triedy aplikačného kontrolera. Tieto triedy sú zodpovedné za implementáciu vytvorených prípadov užitia.

Náš príklad aukčného domu bude využívať dve triedy aplikačnej logiky, AuctionHouse a AuctionManager. Prvá z nich bude reprezentovať funkcionalitu poskytovanú dražiteľovi, potrebnú pre získanie informácií o aukciách definovaných systémom a o možnosti aktívne sa zapojiť do niektorej z aukcií. Trieda AuctionManager bude pokrývať špecifické funkcie vo vnútri systému, potrebné pre administráciu celého on-line aukčného domu.

V tejto chvíli vás nie je nutné zaťažovať podrobným rozoberaním aplikačných kontrolerov na úroveň jednotlivých tried. To znamená, že momentálne nemusíme vytvoriť ďalšie class diagramy. Bolo by však vhodné a užitočné vytvoriť si aspoň dva sekvenčné diagramy, znázorňujúce spôsob interakcie aplikačnej logiky a biznis objektov. Sekvenčný diagram používa na znázornenie interakcie medzi jednotlivými inštanciami tried správy, posielané medzi jednotlivými objektami. Samotné správy odpovedajú konkrétnym metódam, ktoré musia byť implementované príslušnými triedami. Nasledujúci obrázok znázorňuje sekvenčný diagram, definujúci jednotlivé interakcie, ktoré zabezpečujú spracovanie ponuky prišlej od dražiteľa.

Bidder využívajúci AuctionHouse kontroler

Sekvenčný diagram začína vtedy, keď Bidder požiada o zoznam dostupných aukcií. Táto požiadavka je reprezentovaná poslaním správy showAllAuctions() objektu triedy AuctionHouse. Objekt aplikačného kontrolera uspokojí túto požiadavku poslaním správy getAtributes() každej inštancii triedy EnglishAuction, za účelom vytvorenia zoznamu dostupných aukcií. V prípade, že dražiteľ sa rozhodne navŕšiť ponuku v niektorej z aktívnych aukcií, vykoná sa správa submitBid() adresovaná aplikačnému kontroleru AuctionHouse. Tento kontroler sa už postará o to, aby sa suma správne pripísala ku správnej aukcii.

Vytvoríme si ďalší sekvenčný diagram, ktorý zobrazuje spôsob ako MaintenanceUser využíva aplikačný kontroler AuctionManager, s cieľom vytvoriť novú aukciu, definovať jej atribúty a priradiť jej predmet na vydraženie.

MaintenanceUser využívajúci AuctionManager kontroler

V prípade využívania kontrolera AuctionManager, má administrátor možnosť po vytvorení novej aukcie pomocou createAuction(), priradiť jej potrebné atribúty (názov, popis, začiatok a koniec, rezervovanú sumu, minimálnu výšku ponuky a pod.) prostredníctvom setAuctionAttributes(). Následne je treba k danej aukcii priradiť predmet, ktorý sa bude dražiť, pomocou assignItemtoAuction().

Záver analýzy

Máme za sebou úvodnú fázu analýzy problémovej domény – systém anglickej aukcie. Cieľom týchto článkov bolo jemne uviesť vás do série o EJB 2.x. Úvodnú analýzu sme robili hlavne preto, aby vám príklady, ktoré budú postupne nasledovať, lepšie objasnili spôsob použitia EJB pri riešení praktických problémov v oblasti enterprise systémov. V nasledujúcich častiach sa chcem venovať niektorým základným konceptom a technológiám, na ktorých EJB stojí.