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

V prípade EJB nie je vôbec jednoduché ilustrovať jednotlivé koncepty technológie na jednoduchých príkladoch, obsiahnutých v samostatných článkoch. Preto som sa rozhodol navrhnúť určitý centrálny príklad a budovať ho počas celej série. V situáciách, kde to bude užitočné, použijeme aj iné príklady na ilustráciu vysvetľovaných vlastností. Dúfam, že tento prístup vám pomôže lepšie sa zamerať na detaily technológie EJB.

Bude si to vyžadovať určité kompromisy z vašej strany, pretože nie je možné vybrať aplikáciu, ktorá by bola zaujímavá a relevantná pre každého z vás. Mojím hlavným zámerom bolo vybrať doménu, ktorá je blízka B2C aj B2B aplikačným rozhraniam, a hlavne je jednoducho pochopiteľná. Po dlhých úvahách som sa rozhodol, že jadro tejto série článkov bude postavené na vytvorení on-line aukčnej siene.

Uvedomujem si, že každá aplikácia môže byť veľmi jednoduchá ale aj poriadne komplikovaná. Záleží na požiadavkách, ktoré musí splniť. Aby sa nám teda nestalo, že náš seriál sa extrémne skomplikuje, budem sa snažiť zamerať viac na hĺbku jednotlivých aspektov implementácie EJB ako na jej šírku. Inými slovami mojím cieľom bude, aby náš cieľ bol maximálne realistický, ale nie na úkor pochopenia EJB a jej spletitostí.

V nasledujúcej časti sa vám pokúsim priblížiť svet aukcií. Cieľom tejto analytickej časti nebude spraviť z vás odborníkov na všetky systémy aukcií používané po celom svete. Cieľom bude zostaviť zoznam požiadaviek na aplikáciu a správne pochopiť biznis logiku tak, aby sme boli schopní vytvoriť model, na ktorom vybudujeme našu on-line aukčnú sieň.

Aukcie – všeobecný prehľad

Existuje niekoľko typov aukcií, ale najbežnejšie sú anglická, japonská a holandská. Každý typ má svoje vlastné pravidlá, ale cieľom každej z nich je predať predmet aukcie za čo najvyššiu cenu. Predpokladám, že poznáte aspoň základnú terminológiu používanú pri aukciách. Mali by ste vedieť, že ponuka (bid) je suma ponúkaná za predmet aukcie a ten, čo určuje ponuku, je dražiteľ (bidder). Schválne som nepovedal, že dražiteľ je ten, čo zvyšuje ponuku. Záleží to totiž od typu aukcie. Jednotlivé typy aukcií sa primárne líšia spôsobom vykonávania licitácie (bidding). Na opačnej strane ako dražiteľ je predávajúci, alebo licitátor (auctioneer).

Anglický typ aukcie začína na najnižšej sume a jednotlivý dražitelia postupne prihadzujú sumy, svoje ponuky, za ktoré sú ochotní daný predmet vydražiť. Aukcia pokračuje až do okamihu, kedy už nikto nie je ochotný zvýšiť ponuku. Víťazom sa stáva ten, kto dal poslednú, teda najvyššiu ponuku. Pri japonskej aukcii sa tiež začína na najnižšej sume, rozdiel je však v tom, že každý, kto je ochotný zaplatiť aspoň počiatočnú sumu, sa prihlási do aukcie ako dražiteľ. Následne je suma za predmet aukcie v krokoch navršovaná a každý dražiteľ má možnosť kedykoľvek odstúpiť alebo zostať. Ten ktorý zostane ako posledný, je víťaz. Pri holandskej aukcii je princíp presne opačný. Začína sa na najvyššej sume, ktorá je postupne znižovaná. Prvý dražiteľ, ktorý je ochotný zaplatiť aktuálnu sumu, sa stáva víťazom.

Bez ohľadu na ich špecifiká, všetky tri vymenované typy aukcií majú jedno spoločné. A to, že proces dražby, respektíve určovania ponuky, je verejný pre všetkých zúčastnených. Inak povedané, dražiteľ má informácie o výške aktuálnej ponuky. Okrem takýchto „open“ aukcií existujú aj aukcie, pri ktorých sa ponuka neurčuje verejne. Označujú sa termínom sealed-bid aukcie. Používajú sa hlavne na rôznych charitatívnych akciách, kde každý, kto má záujem o predmet dražby, napíše svoju ponuku na tlačivo a vhodí ho do zapečatenej skrinky. Po uplynutí určitého času sa skrinka otvorí a najvyššia ponuka víťazí. Existuje ešte viac možností, ako môže dražba prebiehať, ale to už len na okraj.

Toto bol len veľmi stručný popis najbežnejších typov aukcií. Neurobí síce z vás expertov na dražby, ale dúfam, že bol dostatočný na to, aby ste pri budovaní on-line aukčnej siene pochopili, o čo tu vlastne ide. Budeme sa analýze samozrejme venovať ďalej, pretože žiadny enterprise-class projekt nemôžeme budovať na zelenej lúke. Vidíte sami, že projekt on-line aukčnej siene by mohol byť veľmi komplexný, keby mal pokryť všetky možné variácie na tému aukcia. Preto si musíme pre naše potreby stanoviť určité hranice. Rozhodol som sa teda, že náš projekt bude obsahovať iba podporu pre anglický typ aukcie. Všetky ďalšie úvahy a analýzy budú preto postavené na tomto predpoklade.

Aukcie – business rules

Anglická aukcia (niekedy označovaná ako štandardná) nie je vôbec komplikovaná. Potrebujete však spoznať pravidlá jej fungovania, aby vám boli jasné požiadavky kladené na vytváranú aplikáciu. Ako pri každej enterprise-class aplikácii, tak aj pri aukčnom serveri sú požiadavky naň kladené závislé od pravidiel obchodu a jednotlivých entít, potrebných na modelovanie problémovej domény.

Aukcie sa konajú v aukčných domoch, kde predávajúci uzatvorí kontrakt na predaj predmetu dražby. Províziou pre aukčný dom je určité percento z eventuálnej získanej sumy. Aukčný dom zamestnáva samotných licitátorov a vlastní know-how na plánovanie, zabezpečenie a realizáciu aukcií. Aukčný dom tiež pripraví materiály s informáciami o predmete dražby a stanoví jeho minimálnu vyvolávaciu cenu. Ďalej stanoví minimálnu výšku prihodenia, aby sa predišlo extrémnemu predlžovaniu dražby. V prípade klasickej „kamennej“ dražby, má tieto záležitosti obvykle na starosti licitátor, ale v prípade on-line aukčnej siene musíme tieto záležitosti zabezpečiť elektronicky.

Po spustení aukcie sa začne proces určitého súťaženia medzi dražiteľmi a to na princípe zvyšovania ponuky z ich strany. Minimálna výška navŕšenia ponuky je vopred daná a závisí od exkluzivity draženého predmetu. Licitátor akceptuje jednotlivé ponuky až do okamihu uzavretie aukcie. Uzavretie môže nastať z dvoch príčin. Buď už nie je nikto ochotný navŕšiť ponuku, alebo uplynul vopred stanovený časový limit. Po uzavretí aukcie je vydražený predmet predaný víťaznému dražiteľovi, s jednom možnou výnimkou. Táto výnimka súvisí s tým, že predávajúci, ktorý uzavrel kontrakt s aukčným domom, môže stanoviť takzvanú rezervovanú sumu. Je to suma, ktorá bude v prípade predaja predmetu akceptovaná predávajúcim. Ak konečná ponuka dosiahne alebo prekročí rezervovanú sumu stanovenú predávajúcim, predaj sa môže uskutočniť. V prípade, že nedosiahne ani požadovanú minimálnu sumu, predaj sa po uzavretí aukcie neuskutoční.

Prípady užitia (use cases) – implementácia požiadaviek

Po všeobecnom úvode do oblasti aukcií a definovaní si pravidiel fungovania, je pred nami úloha definovania množiny požiadaviek na on-line aukčný systém. Keďže čítate tento článok, môžem predpokladať, že máte určité skúsenosti alebo sa zaujímate o objektovo orientovanú analýzu a dizajn. Nechcel by som sa preto dopodrobna zaoberať nástrojmi a metódami na zber a vyhodnocovanie požiadaviek a ich prevod na funkčný model. Chcem iba zvýrazniť určité základné body analýzy a použiť pritom osvedčený spôsob zápisu pomocou modelovacieho jazyka UML (Unified Modelling Language).

Prvou a základnou požiadavkou na on-line aukčný systém, je jednoduchá dostupnosť. Preto bude systém používať štandardný web browser, na prístup ku všetkým svojim rozhraniam. Takže teoreticky ktokoľvek sa môže pridať a vstúpiť do systému. Toto zjednodušenie na druhej strane prináša určitý problém. Ten spočíva v tom, že musíme zabezpečiť určitú úroveň autentifikácie a autorizácie na kontrolu prístupu k možnostiam správy jednotlivých aukcií, a zároveň k možnosti prihadzovania ponúk v niektorej z on-line aukcií.

Možnosti poskytované aukčným serverom môžeme definovať ako sadu funkčných požiadaviek. V objektovo orientovanom prostredí je zvykom zachytiť a dokumentovať tieto požiadavky pomocou prípadov užitia. Ich cieľom je vizuálne popísať interakcie medzi užívateľom a systémom. Prípady užitia môžu variovať v spôsobe ich zápisu ako aj miery detailnosti, ale základnou myšlienkou je definovať čo systém musí zvládnuť bez toho, aby sme sa zatiaľ zaoberali tým, ako to zabezpečiť.

Nasledujúce dva obrázky zobrazujú prípady užitia, ktoré bude náš aukčný systém podporovať. V prvom prípade ide o administráciu a vytváranie aukcií.

Use case správy systému, definujúci požiadavky na administráciu aukcií.

Nasledujúci obrázok ilustruje use case dražiteľa, predstavujúci jeho interakciu s on-line aukčným systémom.

Use case dražiteľa a jeho interakcia so systémom.

Spôsob zápisu prípadov užitia je relatívne jednoduchý a pozostáva z niekoľkých elementov. Postavičky ľudí na jednotlivých obrázkoch predstavujú externé rozhrania systému, na ktoré sa odkazuje ako na predstaviteľov určitej role (actor). Actor môže predstavovať aj človeka, ale môže to byť aj iný systém alebo proces, naviazaný na daný use case. Pre naše potreby si predstavíme, že ide o určitú rolu, ktorú môže na seba vziať užívateľ (napríklad to môže byť administrátor alebo dražiteľ). Actor iniciuje celý use case a procesy prebiehajúce v systéme predstavujú jeho odozvu. Maintenance user a Bidder predstavujú dve užívateľské role, definované pre náš príklad. Prvý z obrázkov obsahuje aj rolu s názvom Auction Timer, čo bude určitý proces, ktorého úlohou bude ukončiť dražbu po uplynutí stanoveného časového limitu bez nutnosti sledovania tohto limitu administrátorom, ktorý má tiež možnosť dražbu ukončiť.

Pomenované elipsy predstavujú jednotlivé prípady užitia. Šípka smerujúca od actora k use casu označuje actora ako stimulant, ktorý naštartuje daný use case. V opačnom smere je actor prijímateľom informácie vyprodukovanej prípadom užitia. Značka <<include>> znamená, že daná operácia môže byť viacnásobne vykonaná. Niekedy sa používa aj označenie <<uses>>.

Create an auction (Vytvorenie aukcie)

Správca on-line aukčného servera musí mať možnosť vytvoriť novú aukciu a zadefinovať jej obsah a parametre. Obsahom sa rozumie predmet dražby a parametre definujú spôsob vykonávania dražby. Môže ísť o parametre typu vyvolávacej ceny, výšky minimálneho prihodenia, času a dátumu začatia a ukončenia dražby a podobne. Systém musí poskytovať odpovedajúce rozhranie pre zadávanie a správu parametrov dražby, ako aj spôsob ukladania a spracovania týchto informácií.

Cancel an auction (Zrušenie aukcie)

Správca by ďalej mal mať možnosť zrušiť aukciu, ktorá buď ešte ani nezačala, alebo začala, ale nemá priradeného víťaza. Zrušiť aukciu má možnosť aj Auction timer v prípade, ak skončila jej časová platnosť a dosiaľ nebol určený víťaz. Tento stav neurčenia víťaza môže nastať v dvoch prípadoch. Buď vtedy, ak neboli dané žiadne ponuky, teda vyvolávacia cena sa nezmenila. Prípadne vtedy, ak dosiahnutá výška ponuky nekorešponduje s rezervovanou sumou.

Assign a winner (Určenie víťaza)

Správca systému musí vedieť správne priradiť danú ponuku k dražiteľovi a označiť odpovedajúceho dražiteľa za víťaza. Auction timer musí byť schopný správne označiť vedúceho dražiteľa ako víťaza aukcie za predpokladu splnenia určitých podmienok. A to, že ponuka dosiahla či presiahla rezervovanú sumu (ak bola určená) a zároveň vypršala doba platnosti aukcie. Po ukončení aukcie a určení víťaza, musí byť systém schopný zmeniť status aukcie (označiť ju ako ukončenú) a upozorniť víťaza (najčastejšie mailom).

Close an auction (Uzavretie aukcie)

Tento use case definuje funkcionalitu zdieľanú medzi prípadmi užitia Cancel an auction a Assign a winner. V prípade, že aukcia je ukončená, systém už nesmie akceptovať žiadne ďalšie ponuky. Samozrejmosťou je, že ak daná aukcia určitý čas bežala, skutočný čas ukončenia aukcie bude nastavený na čas, kedy bola naozaj ukončená.

View auctions (Prehľad aukcií)

Správca by mal mať možnosť dať si zobraziť zoznam všetkých aukcií definovaných v systéme. Systém by mal zobrazovať pre každú aukciu jej názov, status, vyvolávaciu cenu, rezervovanú sumu, výšku najvyššej aktuálnej ponuky a zostávajúci čas do uzavretia aukcie. Správca si môže zoradiť zoznam aukcií podľa ich názvu, statusu a zostávajúceho času.

View bid history (Prehľad jednotlivých ponúk)

Správca si môže dať zobraziť zoznam jednotlivých ponúk pre konkrétnu aukciu. Keď si túto možnosť vyberie užívateľ, systém mu ponúkne prehľad jednotlivých ponúk od všetkých dražiteľov v zostupnom poradí (najvyššia ponuka navrchu). Informácie pre jednotlivé ponuky musia obsahovať meno dražiteľa, výšku ponuky a dátum a čas prihodenia.

Browse auctions (Zoznam aukcií)

Každý dražiteľ by mal mať možnosť dať si zobraziť zoznam všetkých aktívnych aukcií, prípadne aj aukcií, ktoré boli otvorené a neskôr uzavreté. Zoznam aukcií musí obsahovať pre každú aukciu jej názov, status, výšku poslednej ponuky, výšku minimálnej ponuky a zostávajúci čas do uzavretia aukcie.

View auction detail (Detaily aukcie)

Okrem zoznamu aukcií by mal dražiteľ mať možnosť dať si zobraziť detailné informácie o konkrétnej aukcii. Detailné informácie musia obsahovať, okrem informácií obsiahnutých v zozname aukcií, aj podrobnejší popis draženého predmetu alebo služby, vrátane fotografie.

Bid on an auction (Pridanie ponuky)

Toto je zrejme najdôležitejší use case, pretože bez neho by celý systém nemal zmysel. Ide o možnosť pridávania jednotlivých ponúk od prihlásených dražiteľov. Systém musí umožniť dražiteľom pridávať svoje ponuky do dražby buď priamo z detailného popisu aukcie, alebo zo zoznamu aktívnych aukcií. Systém bude akceptovať ponuky iba pre aukcie, ktoré začali, ale ešte neboli ukončené. Rovnako bude ponuka akceptovaná len v prípade, ak jej výška dosiahne či presiahne stanovenú minimálnu sumu. Tieto sumy sú určené pre jednotlivé aukcie a môžu sa navzájom líšiť.

View account history (Prehľad aukcií konkrétneho dražiteľa)

Každý dražiteľ by po prihlásení mal mať možnosť dať si zobraziť prehľad aukcií, na ktorých sa aktívne zúčastňuje, alebo v minulosti zúčastňoval. Tento prehľad musí obsahovať názov dražby, jej status, aktuálnu výšku ponuky (respektíve víťaznú ponuku), zostávajúci čas (respektíve dátum a čas ukončenia aukcie) a status dražiteľa voči konkrétnej aukcii. Tento status bude nadobúdať štyri možné hodnoty: Leader (momentálne najvyššia ponuka), Trailer (predbežná ponuka), Winner (víťaz aukcie) a Non-Winner (víťazom je niekto iný, po uzavretí aukcie).

Týmto by sme skončili prvú časť analýzy on-line aukčného systému, bez ktorej by sme nemohli pokračovať v jeho budovaní. V nasledujúcej časti analýzu ukončíme, pričom sa dôkladne pozrieme na biznis objekty a aplikačnú logiku. Dúfam, že som vás príliš nezaskočil využívaním modelovacieho jazyka UML a tým, že analýzu a neskôr aj príklady tvoríme v anglickom jazyku. Predpokladám, že záujemci o problematiku EJB majú UML a anglický jazyk zvládnutý na takej úrovni, že im to nebude robiť problém.

Starší komentáře ke článku

Pokud máte zájem o starší komentáře k tomuto článku, naleznete je zde.