Tvorba informačných systémov - priebežný test z UML diagramov

Zadanie: Téma: Zrušme pokladničné bločky. Ak započítame všetok papier, ktorý sa neustále odmotáva z roliek registračných pokladní v celej krajine, tak by sa ním za krátky čas dala obmotať Zemeguľa. Dnes aj tak skoro všetci zákazníci majú moderné mobilné telefóny vybavené technológiami, ktoré by umožnili namiesto vytlačenia bločku na papier, zobraziť ho hneď v mobile - a nielen to, zákazník by si mohol napr. z domu kedykoľvek prezerať účtenky svojich predchádzajúcich nákupov a dokonca sledovať štatistiky - koľko minul za jedlo, pitie, dopravu, ošatenie, kultúru a pod. Myšlienka je, že kartový platobný terminál z obchodu po zistení identifikátora kupujúceho zašle nákup na vzdialený server, kam sa zákazník - ale napr. aj daňový úrad, ministerstvo financií, alebo štatistický úrad môžu pripojiť cez bežný webový prehliadač. Ušetrí sa tým množstvo papiera a zjednoduší rozličná administratíva, ktorú bude možné robiť automaticky elektronickou formou.
Nakreslite: UML use-case diagram - podľa možnosti pokrývajúci čo najväčšiu časť aplikácie, pre niektorý scenár z use-case vytvorte UML sekvenčný diagram, vyberte si nejakú entitu a nakreslite pre ňu UML stavový diagram, pre zvolenú časť systému nakreslite UML triedny diagram - využite v ňom všetky tri základné druhy relácií a nakreslite UML deployment diagram pre čo najväčšiu časť systému. Okrem toho svoj návrh popíšte aspoň na 10 riadkov.

Jedno možné riešenie: Zákazník (alebo za neho pokladník) svoj nákup postupne pozadáva do registračnej pokladnice. Väčšinu funkcionality bude zabezpečovať nový platobný terminál, na ktorom bude môcť zaplatiť priamo občianskym preukazom - ku ktorému má registrovaný nejaký účet v banke. Deťom bude možné vystaviť detskú platobnú kartu, ktorá bude registrovaná k občianskemu preukazu zákonného zástupcu. Terminál sa po identifikácii zákazníkovej karty a overení karty v registri platobných médií spojí so vzdialeným serverom, na ktorom beží register kupujúcich. Odtiaľ získa platobné údaje kupujúceho a pokúsi sa realizovať platbu. Ak sa mu to podarí, uloží nákup so zoznamom tovarov do registra nákupov na vzdialenom serveri. Každý tovar je zaradený do nejakej kategórie - pričom kategórie tvoria stromovú hierarchickú štruktúru (nadkategórie/podkategórie) - každá kategória má jednoznačne určenú nadkategóriu (okrem koreňovej kategórie "položka"). Zákazník sa do registra nákupov dokáže dívať cez webovú aplikáciu implementovanú v Java EE, podobné aplikácie sú dostupné pre obchodníka - ktorý si môže sledovať štatistiky nákupov v jeho obchode. To môže urobiť aj daňový úrad a spolu so štatistickým úradom môžu prezerať štatistiky nákupov v celej krajine podľa období a kategórií tovarov a služieb.

Use-case diagram znázorňuje jednotlivé používateľské roly a scenáre, ktoré aplikácia bude poskytovať: use_case_diagram.pdf.

V diagrame možno pozorovať reláciu generalizácie medzi používateľskými rolami - napr. dieťa aj občan sú kupujúcimi a zákonný zástupca dieťaťa je tiež občan. Medzi používateľskými scenármi sú relácie <<extend>>, ak niektorý scenár môže byť realizovaný príslušným spôsobom - napr. scenár platba môže byť realizovaný platbou detskou kartou. Naopak, relácia <<include>> medzi scenármi znázorňuje podscenár, ktorý je súčasťou komplexnejšieho scenára, napr. nakupovanie zahŕňa okrem výberu a registrácie tovarov na pokladni aj platbu, alebo registrácia dieťaťa do registra kupujúcich zahŕňa aj vystavenie detskej platobnej karty.

Stavový diagram znázorňuje stavy entity "nákup": state_diagram.pdf

V stavovom diagrame sú jednotlivé stavy pasívne situácie, medzi ktorými dochádza k prechodu pri vykonaní nejakej akcie, alebo keď nastane nejaká udalosť, či uplynie stanovený časový interval. Stav archivovaný nákup je makro-stav, ktorý vnútri obsahuje samostatný stavový diagram - znázorňujúci proces odvedenia dph, ktorý musí obchod v spolupráci s daňovým úradom pre každý nákup uskutočniť.

Sekvenčný diagram znázorňuje priebeh používateľského scenára "nákup", ktorý zahŕňa aj platbu: sequence_diagram.pdf.

V diagrame vidíme použitie opakovania (combined fragment - loop) časti interakcie, a alternatívy (alt) medzi dvoma postupnosťami interakcií v závislosti od splnenia určitej podmienky. V diagrame plynie čas zhora nadol, čiarkované nite znázorňujú životnú dráhu jednotlivých entít, ktoré buď (väčšinou) existujú počas celého scenára, alebo niekedy počas neho vznikajú (prípad entity "tento nákup") alebo zanikajú (entita "tento nákup" v prípade nedostatku zdrojov na účte kupujúceho). Šípky medzi entitami zodpovedajú posielaniu správ - ktoré je väčšinou implementované volaním metód, ale môže ísť aj o iný typ interakcie - v tomto prípade medzi kupujúcim a platobným terminálom.

Deployment diagram: deployment_diagram.pdf znázorňuje jednotlivé zariadenia (výpočtové uzly), na ktorých celý systém beží - vrátane čipovej karty, mobilu kupujúceho a registračnej pokladnice. Jadro nášho systému beží na zariadení platobný terminál - diagram zobrazuje jednotlivé softvérové systémy (programy), ktoré sú na ňom nainštalované - artefakty, pričom po ich spustení na systéme tvoria bežiaci komponent (je ich "manifestáciou"), napríklad program terminal_app tvorí komponent "riadenie platby za nákup". V diagrame vidíme, ktoré zariadenia spolu komunikujú a akým protokolom. Na vzdialenom serveri e-bločkového systému sú prevádzkované všetky základné registre - sú to webové aplikácie naprogramovanované pre platformu Java EE a na servri bežia v prostredí aplikačného servra Glassfish. Prístup do nich umožňujú samostatné webové aplikácie, ktoré sú dostupné z akéhokoľvek internetového prehliadača.

Napokon triedny diagram: class_diagram.pdf zachytáva triedy tej časti systému, ktorá sa podieľa na platbe pri nákupe. Nákup - reprezentovaný objektom triedy Nakup tvorí (relácia agregácie) množina nakúpených tovarov, ktoré sú klasifikované do kategórií. Nákup má priradeného svojho kupujúceho - objekt nejakej podtriedy abstraktnej triedy Kupujuci, ktorý obsahuje aj platobné údaje kupujúceho. Tie sú podľa identifikátora kupujúceho získané zo vzdialeného objektu triedy RegisterKupujucich. Občiansky preukaz alebo detská karta (obe podtriedy abstraktnej triedy PlatobneMedium) sú podľa fyzického kódu zapísaného priamo na karte vyhľadané v zdialenom objekte triedy RegisterPlatobnychMedii. Celý proces platby riadi inštancia triedy Terminal prostredníctvom metódy dokonci() - ktorá má dokončiť nákup zaregistrovaný na registračnej pokladnici a v prípade úspešnej autentifikácie kupujúceho a vytvorenia objektu triedy Nakup vyzve banku kupujúceho na uskutočnenie transakcie (vzdialený objekt triedy ManagerPlatiebBanky - referencia naň je uložená v kupujúceho inštancii triedy Banka). Diagram z priestorových dôvodov už nezachytáva register nákupov, kam sa vytvorená inštancia triedy Nakup po úspešnej transakcii odošle ani niektoré iné detaily. Niektoré relácie asociácie a agregácie majú znázornenú násobnosť, napríklad jeden kupujúci uskutoční 0..nekonečno nákupov, alebo každá banka sa nachádza v ľubovoľnom počte platobných údajov.

Toto riešenie zďaleka nie je dokonalé, dalo by sa v ňom nájsť viacero nedotiahnutých detailov, ale jeho cieľom je uviesť príklad riešenia, aké sa očakávalo na teste a demonštrovať využitie UML diagramov pri návrhu informačného systému.