OOANS - Knižnica

SLOVENSKÁ TECHNICKÁ UNIVERZITAFAKULTA INFORMATIKY A INFORMAČNÝCH TECHNOLÓGIÍ

Semestrálny projekt z predmetu OOANS

Knižnica Použitie vzorov

Autor: Miloš Radošinský

Rok: 2009/2010

KNIŽNICA ............................................................................................................................... 1 1 ÚVOD ...................................................................................................................................... 3

1.1 PREHĽAD DOKUMENTU ............................................................................................................ 3 1.2 POUŽITÁ NOTÁCIA NÁZVOV A ODKAZOV ..................................................................................... 3

2 OPIS PROBLÉMOVEJ OBLASTI ..................................................................................... 3 3 KONCEPTUALIZÁCIA ....................................................................................................... 4

3.1 ZÁKLADNÉ POJMY .................................................................................................................. 4 3.2 KATALÓG POŽIADAVIEK .......................................................................................................... 4

3.2.1 Funkcionálne požiadavky .......................................................................................... 4 3.2.2 Nefunkcionálne požiadavky ....................................................................................... 5 3.2.3 Katalóg rolí ................................................................................................................ 5

3.3 DIAGRAMY PRÍPADOV POUŽITIA ................................................................................................ 6 3.3.1 Obchodné prípady použitia ........................................................................................ 6 3.3.2 Softvérové prípady použitia ....................................................................................... 6

4 ANALÝZA ............................................................................................................................ 9 4.1 DYNAMICKÝ MODEL ............................................................................................................... 9

4.1.1 ST04 Pripravený na výdaj ....................................................................................... 10 4.1.2 ST05 Požičaný ......................................................................................................... 10 4.1.3 ST06 Vrátený ........................................................................................................... 10

5 NÁVRH ................................................................................................................................. 11 5.1 VRSTVY ............................................................................................................................. 11

5.1.1 Vrstva Entity ............................................................................................................ 12 5.1.2 Vrstva Control ......................................................................................................... 13 5.1.3 Vrstva Report ........................................................................................................... 14

5.2 POUŽITÉ VZORY ................................................................................................................... 15 5.2.1 Vzor State ................................................................................................................. 15 5.2.2 Vzor Singleton .......................................................................................................... 16 5.2.3 Vzor Abstract Factory .............................................................................................. 17 5.2.4 Vzor Builder ............................................................................................................. 18 5.2.5 Vzor Iterator ............................................................................................................ 19 5.2.6 Vzor Facade ............................................................................................................. 20

5.3 DYNAMICKÝ A FUNKČNÝ MODEL SYSTÉMU ............................................................................... 21 5.3.1 Prípad použitia Vyhľadanie knihy ........................................................................... 21 5.3.2 Prípad použitia Žiadosť o knihu .............................................................................. 22 5.3.3 Metóda UserAccount.add_book .............................................................................. 23 5.3.4 Prípad použitia Zmena stavu výpožičky .................................................................. 24 5.3.5 Metóda ST06_Handler.EnterState ........................................................................... 25 5.3.6 Metóda UserAccount.progress_reservation ............................................................ 26 5.3.7 Prípad použitia Vizualizácia konta .......................................................................... 27

5.4 CELKOVÝ STATICKÝ MODEL SYSTÉMU ...................................................................................... 28

6 ZHODNOTENIE ................................................................................................................. 29

1 Úvod

1.1 Prehľad dokumentuTento dokument vznikol ako výsledok semestrálneho študentského projektu v predmete Objektovo - orientovaná analýza a návrh systému. Obsahuje konceptualizáciu, analýzu a návrh informačného systému pre knižnicu. V dokumente opisujem problémovú oblasť, katalóg požiadaviek, katalóg rolí, funkčný a logický model na úrovni konceptualizácie, dynamický a logický model na aplikačnej úrovni. Súčasťou dokumentu je tiež aplikácia návrhových vzorov.

1.2 Použitá notácia názvov a odkazovV tejto kapitole uvádzam akým spôsobom budem v dokumente používať názvy entít a tried. V modeloch som kombinoval anglický a slovenský jazyk. Entity sú v angličtine, niektoré názvy metód, hlavne tých ktoré majú popisnejší názov sú v slovenčine. Z toho dôvodu budem v dokumentácii pre názvy kombinovať obidva jazyky, t.j. názov triedy entity uvediem v jednom z tvarov:

• Anglický názov (použitý v modeli) / Slovenský ekvivalent (používaný v praxi)• Anglický názov (použitý v modeli)

2 Opis problémovej oblasti Knižnica je každému pomerne dobre známa aplikačná oblasť. Avšak nie je knižnica ako knižnica. Mnohé z nich majú viditeľne rovnaký spôsob fungovania, ale sú aj výnimky. V tejto práci som si zobral za vzor knižnicu známu pod názvom Slovenská technická knižnica alebo po novom Centrum vedecko-technických informácií SR.

Ide o knižnicu, kde čitateľ nemá priamy prístup ku knihám v knižničnom fonde. Miesto toho používa informačný systém knižnice ako katalóg kníh, v ktorom vyhľadáva a objednáva knihy. Bežný pracovný postup čitateľa preto pozostáva z týchto krokov: vyhľadanie a objednanie kníh, prevzatie kníh a vrátenie kníh. Katalóg kníh je schopný vyhľadať knihy podľa rôznych atribútov ako napr. autor, názov, rok a miesto vydania a iné. S katalógom kníh môže pracovať ľubovoľný návštevník knižnice – nemusí mať členský preukaz. Avšak na objednanie knihy je potrebný platný čitateľský preukaz, ktorého kód sa zadáva ručne ako postupnosť čísiel alebo pomocou čítačky čiarového kódu (CCK). Objednané knihy sa preberajú pri okienku na výdaj a príjem kníh po uplynutí určitého časového obdobia od objednania. Odstup medzi objednávkou a vyzdvihnutím kníh môže byť rôzny v závislosti od miesta uloženia kníh – katalógu.

Knižničný fond obsahuje pre každý knižný titul (ISBN) niekoľko kópií - exemplárov. Ak sú rozpožičané všetky kópie jednej knihy (nie je voľná kópia), čitateľ môže miesto objednávky kópie knihy požiadať o rezerváciu knihy. Po vyčerpaní zásob sa teda miesto objednávky kópie generuje rezervácia knihy. Rezerváciou knihy čitateľ deklaruje záujem o knižný titul. Ak sa rezervovaný knižný titul vráti späť do knižnice, knižnica informuje ”rezervanta“ o dostupnosti knihy – rezervant dostane písomné oznámenie vo forme pozvánky. Rezervovaný knižný titul sa po vrátení nevracia do skladu. Miesto toho “čaká“ na čitateľa (rezervanta) ako po objednaní kópie knihy. Rezerváciu je možné zrušiť.

Kniha sa požičiava na určité obdobie - výpožičná lehota. Jej prekročenie sa považuje za “priestupok“, ktorý knižnica postihuje “pokutou“. Po uplynutí prvej výpožičnej lehoty sa počíta druhá a ďalšia výpožičná lehota – sú kratšie. Čitateľ takto môže nazbierať prvú, druhú a poslednú upomienku, po ktorej nasleduje riešenie súdnou cestou. Každé prekročenie lehoty znamená pre čitateľa zvýšenie pohľadávky knižnice a tiež písomné oznámenie, v ktorom čitateľa informuje o skutkovom stave - ktoré publikácie prekročili výpožičnú lehotu.

3 KonceptualizáciaKatalóg požiadaviek obsahuje funkcionálne ako aj nefunkcionálne požiadavky. V prvej skupine sú požiadavky, ktoré reprezentujú konkrétne operácie používateľa v systéme. Druhá skupina reprezentuje pravidlá, ktorými sa dané operácie riadia – obchodné pravidlá. Požiadavky sú rozdelené na niekoľko logických okruhov podľa používateľov a času použitia – sú oddelené riadkami s tučným písmom. Katalóg požiadaviek síce obsahuje všetky požiadavky, ktoré som identifikoval, no v ďalšom texte sa pracuje a počíta iba s ich podmnožinou.

3.1 Základné pojmyPojem PopisKópia knihy/exemplár Konkrétny kus / exemplár knihyVýpožička Exemplár v knižnici, ktorý je alebo môže byť požičanýOmeškanie Označuje prekročenie výpožičnej doby danej kópie knihyUpomienka Oznámenie o tom, že došlo k omeškaniu. Toto oznámenie môže mať

jednu z dvoch foriem – klasickou poštou alebo emailom.

3.2 Katalóg požiadaviek

3.2.1 Funkcionálne požiadavkyID Názov PopisFR0 Správa skladuFR0.1 Objednávanie kníh Knižnica objednáva nové knihy.FR0.2 Evidencia kníh Knižnica eviduje zakúpené a dodané knihy v sklade. Knihy sú

od tohto momentu k dispozícii čitateľom.FR0.3 Vyradenie kníh Knižnica vyraďuje z evidencie poškodené kópie kníhFR0.4 Manipulačný plán v

skladeSystém vytvára manipulačný plán s knihami podľa ich polohy. Cieľom je optimalizovať zber a uskladnenie kníh.

FR1 Správa účtovFR1.1 Registrácia čitateľa Systém prijme osobné údaje, zadané knihovníkom a vytvorí

nové čitateľské kontoFR1.2 Vyradenie čitateľa Opak registrácie, zruší kontoFR1.3 Správa účtu čitateľa Čitateľ môže špecifikovať niektoré vlastnosti svojho účtu ako

e-mail, telefón, spôsob doručovania upomienok a iné.FR2 Vznik výpožičkyFR2.1 Vyhľadanie knihy Čitateľ prezerá dostupnú literatúru v katalógu knižnice.

Čitateľ najskôr špecifikuje atribúty knihy, systém mu následne nájde a zobrazí výsledok.

FR2.1.1 Jednoduchý vyhľadávač

Umožňuje vyhľadávať iba podľa niektorých kritérií, ktoré nemožno špecifikovať oddelene, ale spoločne.

FR2.1.2 Pokročilý vyhľadávač Umožňuje vyhľadávať podľa všetkých kritérií, ktoré možno špecifikovať samostatne.

FR2.2 Objednanie knihy Systém umožní vytvoriť objednávku knihy, ktorá je k dispozícii – je voľná.

FR2.3 Rezervácia knihy Systém umožní vytvoriť registráciu knihy, ktorá nie je voľná. Používateľ sa tak stáva rezervant danej publikácie.

FR2.4 Oznámenie o rezervácii

Rezervovaná kniha je dispozícii. Systém vytvorí oznámenie o dostupnosti knihy, ktoré pošle rezervantovi.

FR2.5 Výdaj kníh Čitateľ preberá objednané knihy doručené zo skladu. Systém eviduje kópiu knihy ako požičaná.

FR2.6 Predĺženie výpožičky Ak sú splnené podmienky dané zásadami, systém predĺži výpožičnú lehotu publikácie

FR3 Zánik výpožičky

FR3.1 Poslanie upomienky Systém generuje a posiela upomienky. Služba je aktivovaná časovačom podľa kalendára upomienok.

FR3.2 Oznam o strate Čitateľ oznamuje stratu knihyFR3.3 Úhrada dlhu Čitateľ spláca dlh za omeškanie alebo za stratu knihy.

FR3.4 Vrátenie kníh Čitateľ vracia výpožičky FR4 Konfigurátor zásad

a pravidielUmožňuje konfigurovať zásady a pravidlá, ktoré majú číselnú reprezentáciu. Zásady a pravidlá viď ďalšiu kapitolu nefunkcionálne požiadavky

3.2.2 Nefunkcionálne požiadavkyID Názov PopisNR0 Dostupnosť kníhNR0.1 Priama dostupnosť Knihy sú voľne dostupné – prístupné priamo k nahliadnutiuNR0.2 Nepriama dostupnosť Knihy nie sú voľne dostupné – sú uskladnené v skladeNR0.3 Poloha knihy Knižnica musí mať evidenciu o tom, kde sa nachádza kópia

knihy – sklad, študovňa, prípadne iné umiestnenie a spresnenie umiestnenia

NR1 Typ výpožičkyNR1.1 Prezenčná výpožička Kópiu knihy je možné požičať iba prezenčne pre internú

študovňu knižnice, nesmie opustiť priestory knižnice.NR1.2 Absenčná výpožička Kópiu knihy je možné požičať aj mimo priestorov knižnice,

môže opustiť priestory knižnice.NR2 Zásady a pravidlá Niektoré obchodné pravidlá knižnice, ktoré uplatňuje voči

čitateľoviNR2.1 Podmienky na výdaj

kníhUpravuje podmienky pre výdaj kníh.

NR2.2 Kalendár upomienok Definuje rozvrh zasielania upomienokNR2.3 Sadzobník poplatkov

za omeškanieDefinuje sadzobník poplatkov za prekročenie – závislosť sadzby /výšky poplatkov od dĺžky omeškania.

NR2.4 Zásada predlžovania výpožičiek

Definuje podmienky predlžovania výpožičiek pre čitateľa ako aj pre knihovníka.

3.2.3 Katalóg rolíID Názov PopisUSR1 Skladník Stará sa o sklad kníh. Organizuje sklad kníh pre potreby

rýchleho vyhľadania knihy. Úlohou skladníka je evidencia, výber a vrátenie kníh.

USR2 Knihovník Vydáva alebo prijíma knihy od čitateľa. Je kontaktná osoba pre čitateľa a zároveň je správca výpožičiek.

USR3 Čitateľ Klient knižnice

3.3 Diagramy prípadov použitiaDiagramy prípadov použitia naznačujú a modelujú pomerne širokú oblasť, ktorú som nedokázal za tak krátky čas pokryť v analýze a už vôbec nie v návrhu. Takže konceptualizácia v tejto kapitole ma širší záber ako má analýza a návrh.

3.3.1 Obchodné prípady použitiaTieto prípady použitia modelujú najvyššiu úroveň, ktorá je ale príliš abstraktná a na vysokej úrovni, aby mohla slúžiť pre vývoj a špecifikáciu softvéru. Prípady použitia v tejto vrstve sú však dobrým základom pre dekompozíciu na softvérové prípady použitia v ďalšej kapitole, ktoré už môže zabezpečovať informačný systém.

uc Business Use Cases

Citatel Officer

Vznik vypozicky

Zánik vypozicky

Správa skladu Správa úctov

Skladnik

Casovac

Obr. 1

3.3.2 Softvérové prípady použitiaV tejto kapitole uvádzam dekompozíciu dvoch najdôležitejších prípadov použitia na obchodnej úrovni:

• Vznik výpožičky • Zánik výpožičky.

Pre každý z nich som vytvoril samostatný model / diagram.

uc Vznik vypozicky

Vyhladanie knihy

Citatel

Ziadost o knihu

Výdaj kníh

Oznámenie o rezerváciiZber kníh

Skladnik

CitatelLogin

Officer

Predlzenie výpozicky

Zmena stavu vypozicky

Vizualizácia konta«include»

«extend»

«extend»

«precedes» «precedes»

«extend»

Obr. 2 Prípady použitia – podsystém Vznik výpožičky

uc Zanik vypozicky

Citatel

Poslanie upomienky

Oznam o strate

Úhrada dlhu

Vrátenie kníh

Skladnik

Officer

Casovac

Zmena stavu vypozicky Vizualizácia konta

«include»

Obr. 3 Prípady použitia – podsystém Zánik výpožičky

4 AnalýzaV tejto kapitole uvádzam analýzu informačného systému Knižnica. Systém Knižnica ukážem len z dynamického hľadiska. Je tu uvedený stavový diagram pre entitu Loan / Výpožička, ktorá je pre knižnicu ako takú kľúčová. Rovnako kľúčová je aj pre informačný systém knižnice. Ukázalo sa, že je kľúčová až tak, že ovplyvňuje architektúru Control vrstvy.

4.1 Dynamický model

stm Exemplar

«ST 01»Na sklade

In i tia l

«ST 02»Ziadany

«ST 03»Vybavuje sa

«ST 04»Pripraveny na vydaj

«ST 05»Pozicany

«ST 06»Vrateny

«ST 08»Vyradeny

Final

«ST 07»Ulynul casový limit

Názov pro jektu: KniznicaAutor: M i los RadosinskýM odel : Dynam ickýDiagram : StavovýPoh lad: LogickýVrstva : DoménováEnti ta: Exem plár / Výpožicka (Loan)Dátum : 30 .11.2009Poznam ka: m odelované su len žl té stavy:ST 04, ST 05, ST 06

ziadost

navrat do skladu

výda j

tim eout [5 m inút]

[je rezervacia]

stra ta

príjem

tim eout [5 dní]

výdajdorucenie na výdaj

zahajenie zberu

Zarad i t na sklad poskoden ie

ziadost

Obr. 4 Stavový diagram entity Loan / Výpožička

Na obrázku Obr. 4 je naznačený životný cyklus Výpožičky v knižnici v podobe stavového diagramu. Ide o deterministický model/diagram, pretože v každom stave sa dá jednoznačne vybrať prechod do ďalšieho stavu – nasledujúci stav podľa okolností. Každému stavu možno priradiť akcie, ktoré sa realizujú buď na vstupe do stavu alebo na výstupe zo stavu, tzv. enter a exit akcie. Okrem toho možno priradiť akcie aj samotnému prechodu, ale túto možnosť som zanedbal. Koncept vstupnej a výstupnej akcie možno výhodne využiť aj v návrhu. V ďalšom texte tejto kapitoly opíšem stručne len na ilustráciu niektoré stavy a ich vstupno výstupné akcie ako motiváciu pre ich použitie v návrhu.

Uvedený model sa možno zdá byť komplikovaný a nasledujúci popis asi tento dojem ešte prehĺbi. Cieľom bolo dosiahnuť maximálnu možnú mieru automatizácie, aby sa prechody medzi stavmi dali automatizovať, t.j. boli deterministické a nevyžadovali si rozhodnutie alebo iný zásah používateľa.

4.1.1 ST04 Pripravený na výdajTento stav má výpožička, ktorá je pripravená a čaká na výdaj čitateľovi, ktorý sa osobne dostaví do knižnice a preberie ju na dočasné a absenčné používanie. Ako vidno z diagramu, kniha / výpožička v tomto stave zotrváva kým neuplynie časový limit 5 dní alebo do príchodu čitateľa. Príchod čitateľa je asynchrónna udalosť, ktorú nevieme ovplyvniť, ale časový limit a čakanie v ňom môžeme naplánovať (ordered loan come back). Presne to sa deje pri vstupe do stavu. Na výstupe / odchode zo stavu, t.j. keď príde čitateľ po knihy, sa musí realizovať opačná operácia – musí sa daný plán zrušiť. V nasledujúcej tabuľke to opíšem podrobnejšie.

Enter Naplánuje prechod do stavu ST07 po piatich dňoch.Exit Zruší sa naplánovaná udalosť prechodu do stavu ST07

Stav s názvom „ST07 Uplynul časový limit“ je dôležitý z pohľadu automatizácie, pretože upozorňuje personál knižnice na výpožičky, ktoré sa majú vrátiť do skladu. Personál nie je nútený sledovať čas ručne.

4.1.2 ST05 PožičanýTento stav má výpožička, ktorá opustí priestory knižnice v rukách a zodpovednosti čitateľa. Výpožička v tomto stave môže v súlade s pravidlami knižničného poriadku zotrvať len obmedzené obdobie a to napr. 1 mesiac. Prekročenie tohto obdobia je sankcionované pokutou. Knižnice vo všeobecnosti využívajú upomienky (reminders) na pripomenutie prekročenia výpožičnej lehoty výpožičky (expired loans), pričom upomienky sa posielajú podľa určitých pravidiel a plánu, t.j. nie náhodne alebo každý deň.

Aj v tomto prípade je výhodné použiť plánovač, konkrétne plánovač na naplánovanie vytvorenia a doručenia upomienky čitateľovi (Expired Loan Reminder). Presne to sa tu deje. Pri vstupe do stavu, t.j. keď čitateľ preberie výpožičku, sa naplánuje prvá upomienka. Na výstupe zo stavu, t.j. keď čitateľ danú výpožičku vráti, sa daná upomienka zruší.

Plánovač sa nestará o realizáciu plánu, stará sa len o vytvorenie plánu, t.j. o zoznam udalostí. O realizáciu plánu sa stará iný komponent.

Enter Naplánuje sa prvá upomienka pre danú výpožičkuExit Zruší sa akákoľvek upomienka pre danú výpožičku

4.1.3 ST06 VrátenýTento stav má výpožička tesne potom, ako ju prebral úradník knižnice od čitateľa. Tento stav je len dočasný, pretože všetky tri prechody zo stavu sa realizujú automaticky alebo manuálne krátko po príchode do tohto stavu. Automaticky sa realizuje prechod do stavu „ST04 Pripravený na výdaj“, ak pre danú knihu existuje registrácia (prejavený záujem v čase jej nedostupnosti). Automaticky sa realizuje tiež prechod do stavu „St07 Uplynul časový limit“ po časovom limite 5 minút. Manuálny prechod môže zrealizovať úradník čítačkou kódu, ktorý výpožičku tak znovu vydá čitateľovi.

Enter Naplánovanie prechodu do stavu ST07 po piatich minutách.Ak bola vrátená výpožička rezervovaná, vykoná sa jej prevod na konto rezervanta.

Exit Zruší sa naplánovaná udalosť prechodu do stavu ST07Vytlačí sa doklad o vrátení výpožičky

5 NávrhV tejto kapitole opíšem návrh systému Knižnica. Sústredil som sa pritom najmä na dynamický a logický pohľad – sekvenčné diagramy a diagramy tried. Najskôr uvediem akým spôsobom som realizoval pracovný postup návrh, t.j. kroky, ktoré ma viedli k výsledku. Nasledujúce kroky som realizoval väčšinou v takej následnosti, ako sú uvedené v zozname. Samozrejme boli realizované vo viacerých iteráciách, nie len v jednej.

1. Vrstvy. Vytvoril som objektový model pre jednotlivé vrstvy systému, no najmä pre Entity a Control vrstvu. O vrstvách viac ďalej.

2. Návrhové vzory. Pre jednotlivé vrstvy som identifikoval alebo aplikoval návrhové vzory.

3. Dynamický model. Vytvoril som dynamický model pre jednotlivé scenáre použitia systému.

4. Zlučovanie. Na základe dynamického modelu som spojil jednotlivé vrstvy do jedného spoločného statického modelu.

5. Dopĺňanie. Na základe dynamického modelu som dopĺňal objektové modely v jednotlivých vrstvách a celkový model systému o triedy alebo relácie.

Uvedený postup možno zhrnúť tak, že štruktúru aplikácie tvorili najskôr skúsenosti z danej domény (v podstate len entity vrstva), potom návrhové vzory a nakoniec dynamický model.

5.1 VrstvyStatický model systému som vzhľadom na rozsah systému organizoval vo viacerých vrstvách. Hneď od začiatku to boli tri vrstvy a potom sa k nim ešte pridala vrstva Report. Celkovo sú to tieto vrstvy:

• Entity. Obsahuje triedy, ktoré reprezentujú reálne veci v doméne knižnice. Jedná sa v podstate o dátový model, nakoľko všetky triedy tejto vrstvy sú perzistentné.

• Report. Obsahuje triedy, ktoré prezentujú Entity triedy vo forme vhodnej pre používateľské rozhranie. Neznamená to nič iné ako to, že v ich kompetencii je serializovať entity triedy do textu metódami ToString. Sú podobné vzoru MVP (model view presenter).

• Control. Triedy tejto vrstvy implementujú logiku systému. Triedy s postfixom Control alebo Controller v názve sú priamo zodpovedné za chod Use Case, t.j. sú na najvyššej úrovni riadenia, aj keď nie vždy zodpovedajú za celý Use Case. Ostatné triedy tejto vrstvy sú v podstate fasády, pretože majú pod palcom viacero tried, ktoré iné triedy / časti systému nevidia priamo, ale len sprostredkovane.

• Boundary. Jedná sa o používateľské rozhranie systému. Niektoré triedy z tejto vrstvy využívajú triedy z vrstvy Report.

V kapitolách jednotlivých vrstiev je uvedený krátky popis zastúpenia vzorov v nich a spôsob ako vrstvy vznikali. Zastúpenie vzorov je uvedené vo forme odkazov – referencií na príslušnú kapitolu o vzore. Pre každú vrstvu je uvedený zoznam identifikovaných a aplikovaných vzorov (pre rozdiel viď kapitola 5.2). Z podstaty identifikovaných a aplikovaných vzorov vyplýva, že identifikované vzory sú súčasťou diagramov jednotlivých vrstiev, zatiaľ čo aplikované vzory sú iba vo svojich vlastných diagramoch samostatne v kapitole 5.2.

5.1.1 Vrstva Entityclass Entity

«enti ty»Exemplar

- signatura: in t- objednany: da te- pozicany: da te- vrati t: date- stav: in t

«enti ty»Book

- nazov: Stri ng- vydane: date- vydanie: in t- pocet_stran: in t- ISBN: S tring

«enti ty»UserAccount

- m eno: S tring- ad resa: String- m ai l : S tring- d lhu je : in t

«enti ty»Reservation

- kedy: DateT im e

«enti ty»Author

- m eno : String

«enti ty»Publisher

- m eno: String- síd lo: String

«enti ty»CodeManager

«en ti ty»ReservationAvailable

«enti ty»ExpiredLoanReminder

«enti ty»KeyWord

- text: String

«enti ty»Loan

«enti ty»LoanPlanTemplate

- kedyVra ti t: in t- p rvaUpom ienka: in t- d ruhaUpom ienka: in t- tretiaUpom ienka: in t

«enti ty»Event

- kedy: DateT im e

+ T oString() : String+ schedule(tim e) : vo id

«enti ty»OrderedLoanComeBack

Názov projektu: Knizn icaAutor: M i los RadosinskýM ode l : Ob jektovýDiagram : d iag ram triedPohlad : FyzickýVrstva: M ikroprocesná - Enti tyBal ícek: Enti tyDátum : 30.11 .2009

0..*

1

0..*1 0..10 ..*

0..*

1..*

0 ..*

1

0 ..*

1..*

Obr. 5 Vrstva Entity

Štruktúra tejto vrstvy vznikala v podstate intuitívne na základe dobrej znalosti danej domény. Identifikované vzory tejto vrstvy sú vzor Singleton v triede LoanPlanTemplate a vzor Facade v triede UserAccount.

5.1.2 Vrstva Controlclass Control

«contro l»OfficerControl

+ OnUserCode() : void+ OnBookCode() : void

«control»UserControl

Contro l triedy su triedy vykonavajuce log iku nad viacerym i enti ty alebo boundary triedam i . Su to bud: use case specficicke - trieda ktora riad i jeden alebo viacero use casov alebo fasady.

«contro l»Catalog

«contro l»LoanStateHandler

- stav: in t

+ Ente rState () : vo id+ Exi tState() : vo id+ IsUserAccountVisible() : Boo lean

«control»ST04_Handler

+ EnterState() : vo id+ Exi tS tate () : vo id+ IsUserAccountVisib le() : Boolean

«control»ST05_Handler

+ EnterState() : void+ Exi tState() : vo id+ IsUserAccountVisible() : Boolean

«control»Scheduler

+ ScheduleExpi redLoanRem inder(Exem plar) : vo id+ ScheduleReservationAvai lable(Exem plar) : vo id+ ScheduleOrderedLoanCom eBack(Exem plar) : vo id+ CancelExpi redLoanRem inder(Exem plar) : vo id+ CancelOrderedLoanCom eBack(Exem plar) : vo id

Loan

«enti ty»Entity::Exemplar

«contro l»ST06_Handler

+ EnterState() : vo id+ Exi tState() : vo id+ IsUserAccountV isible() : Boolean

«contro l»LoanController

+ ProgressLoan(in t) : vo id+ ProgressLoan(in t, int) : vo id+ IsUserAccoun tVisib le() : Boolean# GetActualState(Exem plar) : LoanStateHandler# GetNextState(Exem plar) : LoanStateHandler

«enti ty»Entity::LoanPlanTemplate

- kedyVrati t: int- prvaUpom ienka: in t- druhaUpom ienka: int- tre tiaUpom ienka: in t

Názov pro jektu: KniznicaAutor: M i los RadosinskýM odel : ObjektovýDiagram : d iagram triedPohlad: Log ickýVrstva: M ikroprocesná - ControlBal ícek: Contro lDátum : 30.11.2009

Builder::QueryBuilder

«uses»

«schedules for»

«holds state»

Obr. 6 Vrstva Control

Štruktúra tejto vrstvy vznikala prevažne na základe vzorov. O tom svedčí aj ich široké zastúpenie v tejto vrstve. Za svoju štruktúru ale čiastočne vďačí aj dynamickému modelu a analýze. Identifikované vzory tejto vrstvy sú vzor State a vzor Abstract Factory – viditeľné priamo v diagrame. V tejto vrstve je tiež aplikovaný vzor Builder na tvorbu vyhľadávacích dotazov pre katalóg publikácií (trieda catalog) – vzor nie je viditeľný v diagrame.

V diagrame vidno, že systém je horizontálne rozdelený do dvoch relatívne samostatných celkov. Toto rozdelenie je dané tým, že existujú dve kategórie používateľov: čitateľ a knihovník. Triedy v okolí triedy OfficerControl „sú pre“ knihovníka a triedy v okolí triedy UserControl sú pre čitateľa.

5.1.3 Vrstva Reportclass Report

«report»BookReport

+ In i t(Book) : vo id+ T oStringShort() : S tring+ T oStringM edium () : String+ T oStringFul l () : String+ HeaderT oString() : String

«report»LoanReport

+ In i t(Loan) : vo id+ T oStringShort() : S tring+ T oStringM edium () : String+ T oStringFul l () : String+ HeaderT oString() : String

«report»BookReportList

«report»LoanReportList

Bal iba l i cek Report obsahu je triedy so stereotypom Report. T ieto triedy sú urcené na form átovanie textu vhodného na výstup. Reprezentu jú dom énové objekty a lebo pojm y, ktoré nem ajú zobrazenie do jednej enti ty / tabulky v DB, a le do viacerých. T ie to triedy m ajú väzby na viac ako jednu enti tnú triedu.

Názov projektu: Knizn icaAutor: M i los RadosinskýM odel: ObjektovýDiagram : diagram triedPohlad: FyzickýVrstva: Apl ikacnáBal ícek: ReportDátum : 30.11.2009

«enti ty»Entity::Book

«enti ty»Entity::Loan

Obr. 7 Vrstva report

Vrstva Report obsahuje triedy, ktoré prezentujú entity / doménové objekty vo forme vhodnej pre používateľské rozhranie. V ich kompetencii je teda formátovať obsah doménových objektov / entít na zobrazenie. Vo všeobecnosti mapovanie medzi report a entity objektmi nemusí byť 1:1, teda jeden report objekt môže prezentovať obsah viacerých entity objektov a to aj rôznych typov.

Aj v tejto vrstve je badať rozdelenie systému pre dve kategórie používateľov rovnako ako vo vrstve Control. Triedy BookReport a BookReportList sú určené pre vyhľadávanie kníh v katalógu. Slúžia teda pre čitateľa. Naopak triedy LoanReportList a LoanReport slúžia prevažne pre knihovníka, ktorý prezerá stav výpožičiek čitateľa. V tejto vrstve je aplikovaný vzor Iterator v triede LoanReportList (vzor nie je viditeľný v diagrame).

5.2 Použité vzoryNávrhové vzory ktoré som použil v systéme možno rozdeliť podľa viacerých kritérií do rôznych kategórií. Podľa jedného kritéria sú to dve kategórie: identifikované a aplikované vzory. Identifikované vzory sú také, ktoré sú prirodzenou súčasťou problémovej domény – vyplývajú z analýzy. Aplikované vzory naopak neexistujú prirodzene, ale ich použitie (aplikácia) umožní elegantný a flexibilný návrh. Podľa iného kritéria možno použité vzory rozdeliť na tie, ktoré majú „veľký“ vplyv na celý systém a tie ktoré majú len lokálny vplyv na nejaký komponent.

V popise jednotlivých vzorov je uvedený obrázok, krátky popis a tabuľku použitých účastníkov - mapovanie tried systému na účastníkov.

5.2.1 Vzor Stateclass State

«control»Control::ST05_Handler

+ EnterState() : void+ ExitState() : void+ IsUserAccountVisible() : Boolean

«contro l»Control::ST04_Handler

+ EnterState() : void+ Exi tState() : void+ IsUserAccountVisible() : Boolean

«control»Control::ST06_Handler

+ EnterState() : vo id+ ExitState() : void+ IsUserAccountVisible() : Boolean

«control»Control::LoanStateHandler

- stav: in t

+ EnterState() : void+ ExitState() : void+ IsUserAccountVisible() : Boolean

«control»Control::LoanController

+ ProgressLoan(int) : void+ ProgressLoan(int, in t) : void+ IsUserAccountVisible() : Boolean# GetActualState(Exem plar) : LoanStateHandler# GetNextState(Exem plar) : LoanStateHandler

Názov projektu: KniznicaAutor: M i los RadosinskýM odel : ObjektovýDiagram: d iagram triedPohlad: LogickýVzor: StateDátum : 30.11.2009

«enti ty»Entity::Exemplar

- signatura: int- objednany: date- pozicany: date- vrati t: date- stav: int

«holdsstate»

Obr. 8 Identifikácia vzoru State

Dalo sa očakávať, že stavový diagram výpožičky v analýze Obr. 4 bude implementovaný / modelovaný vzorom State a presne to sa naplnilo. Vzor State sa tak stal jediným vzorom, ktorý má vplyv na celý systém v zmysle architektúry. Ostatné vzory majú svojim rozsahom a vplyvom len lokálny význam.

Vzor State bol identifikovaný v Control vrstve ako radič životného cyklu výpožičky, teda ako radič prechodov medzi jednotlivými stavmi výpožičky. Pritom pod pojmom radič pritom treba chápať to isté čo pod pojmom Controller, t.j. triedu ktorá riadi logiku aplikácie cez Entity a Boundary vrstvu. Pri zmene stavu je totiž niekedy nevyhnuté použiť dátovú vrstvu ako aj používateľské rozhranie. Napr. keď treba vytlačiť potvrdenku o vrátení výpožičky.

Zmena stavu výpožičky sa realizuje metódou LoanController.ProgressLoan, ktorú volá trieda OfficerControl. Parametrom tejto metódy je kód / identifikátor výpožičky, ktorú treba posunúť do ďalšieho stavu životného cyklu, tak ako ho definovala analýza na obrázku Obr. 4. Metóda ProgressLoan sa stará v podstate o prechod do ďalšieho stavu, t.j. stará sa o výstup z aktuálneho stavu, o vstup do ďalšieho stavu a o akcie s tým spojené. Uvedené akcie sa definujú v podtriedach triedy LoanStateHandler ako EnterState, ExitState.

Metódy ProgressLoan sú vlastne dve. Obidve slúžia k tomu istému účelu. Vyššie menovaná sa používa na tzv. default prechod, t.j. prechod, ktorý je vzhľadom na stav implicitný a najpravdepodobnejší. Druhá metóda sa používa v prípade, že existuje viacero prechodov a je potrebné prejsť do iného stavu ako je default stav. V parametri tejto metódy je okrem kódu výpožičky aj kód nasledujúceho stavu.

Ako možno vidno z obrázku Obr. 8, nositeľom stavu výpožičky je entita Exemplar, podľa ktorej sa pri prechode aktivuje príslušný radič stavu, t.j. podtrieda triedy LoanStateHandler. To sa deje interne.

Účastník podľa katalógu Trieda systémuContext LoanControllerState LoanStateHandlerConcreteStates ST04_handler,

ST05_handler,ST06_handler,…pre ostatné stavy som triedy zanedbal.

5.2.2 Vzor Singletonclass Singleton

«enti ty»Entity::LoanPlanTemplate

- kedyVratit: i nt- p rvaUpom ienka: int- d ruhaUpom ienka: in t- tretiaUpom ienka: i nt

Názov pro jektu: Knizn icaAutor: M i los RadosinskýM odel : ObjektovýDiagram : diagram triedPohlad: LogickýVzor: Sing leton, jed iný platný pre vše tkýchDátum : 30.11.2009

Obr. 9 Identifikácia vzoru Singleton

Pre vzor Singleton bolo veľa kandidátov, ale pri zavedení entity LoanPlanTemplate som vedel, že je ten najlepší kandidát. Entita LoanPlanTemplate má význam okrem iného pri plánovaní upomienok. Definuje šablónu termínov / plánu pre výpožičky, kedy sa majú vrátiť a kedy sa majú upomínať. Šablóna plánu ako taká definuje relatívny plán, t.j. počet dní od výdaja výpožičky. Údaje entity/triedy LoanPlanTemplate sú platné globálne pre všetky výpožičky a typy dokumentov. Táto trieda je vo vrstve Entity jediný Singleton.

5.2.3 Vzor Abstract Factoryclass Abstract Factory

«control»Control::Scheduler

+ ScheduleExpiredLoanRem inder(Exem plar) : vo id+ ScheduleReservationAva i lab le(Exem plar) : void+ ScheduleOrderedLoanCom eBack(Exem plar) : vo id+ CancelExpiredLoanRem inder(Exem plar) : vo id+ CancelOrderedLoanCom eBack(Exem plar) : void

Event

«enti ty»Entity::ExpiredLoanReminder

Event

«enti ty»Entity::OrderedLoanComeBack

Event

«enti ty»Entity::ReservationAvailable

Názov projektu: Knizn icaAutor: M i los RadosinskýM odel : ObjektovýDiagram : diagram triedPohlad: LogickýVzor: Abstract facto ry / Factory M ethodDátum : 30.11.2009

«contro l»Control::LoanStateHandler

- stav: in t

+ EnterState () : vo id+ Exi tS tate() : void+ IsUserAccountVisib le() : Boolean

«creates» «creates» «creates»

Obr. 10 Identifikácia vzoru Abstract Factory / Factory Method

Diagram na obrázku Obr. 10 som pomenoval nejednoznačným názvom „aplikácia vzoru Abstract Factory / Factory Method“, nakoľko nie som si istý, ktorý vzor možno lepšie v danom modeli identifikovať.

Trieda Scheduler reprezentuje plánovač pre rôzne druhy udalostí, ktoré môžu v systéme počas prevádzky nastať. Každá udalosť sa plánuje podľa špecifických pravidiel, preto pre každú udalosť existuje samostatná metóda. Dalo by sa povedať, že množina udalostí v systéme je rodina udalostí podobne ako to chápe katalóg GOF, no len do určitej miery, pretože udalosti v systéme sú do značnej miery samostatné a nezávislé. To znamená, že zmena pravidiel plánovania jednej udalosti si nevyžiada zmeny pre ďalšie udalosti. Okrem toho mám s identifikovaním AF vzoru ešte jeden problém. Neexistujú rôzne rodiny produktov ale len jedna. Akt. analýza a návrh ani nepredpokladá nejaké rozširovanie. No na druhej strane trieda Scheduler obsahuje metódy na tvorbu ako aj na likvidáciu objektov (udalostí), čo je v súlade s revidovaným popisom vzoru AF. Továreň nevytvára inštancie objektov v dočasnej pamäti ale v dátovom úložisku – v databáze.

Účastník podľa katalógu Trieda systémuAbstractFactory Nie je použitýConcreteFactory SchedulerAbstractProduct EventConcreteProduct ExpiredLoanReminder,

OrderedLoanComeBack,ReservationAvailable

Client LoanStateHandler

5.2.4 Vzor Builderclass Builder

QueryBuilder

+ FindT extInAnyField (String) : vo id+ FindT extInOneField(String, S tring) : vo id+ FindLanguage(Language) : void+ FindReleaseYear(in t, in t, in t) : vo id+ FindEdi tion(int) : vo id+ FindAvai lab leBooks() : vo id+ GetQuery() : Query

SQL_QueryBuilder

+ FindT extInAnyField (String) : vo id+ FindT extInOneField(String, S tring) : vo id+ FindLanguage(Language) : void+ FindReleaseYear(in t, in t, in t) : vo id+ FindEdi tion(int) : vo id+ FindAvai lab leBooks() : vo id+ GetQuery() : Query

«enum eratio ...Language

Query

+ T oString() : vo id

SQL_Query

+ T oString() : vo id

«contro l»Catalog

Názov projektu: Kn izn icaAutor: M i los RadosinskýM odel : ObjektovýDiagram : diagram triedPohlad: Log ickýVzor: Bu i lderDátum : 30.11.2009

«creates»

«creates»

Obr. 11 Aplikácia vzoru Builder

Vzor builder sa používa na tvorbu zložitých objektov. V tomto projekte tomu nie je inak. Použil som tento vzor v katalógu kníh, t.j. v triede Catalog, ktorá implementuje logiku vyhľadávania kníh v katalógu podľa rôznych kritérií / polí. Vzor builder som použil na tvorbu dopytu, ktorý používa vyhľadávací engine na vyhľadávanie.

Vyhľadávací engine môže byť napr. relačná databáza a dopyt môže byť výraz v jazyku SQL. Môžu to však byť aj iné technológie. Bez ohľadu nato aká technológia je na konci, na začiatku je vždy používateľ a jeho vyhľadávací formulár. Trieda Catalog stojí medzi nimi a robí konverziu dát formulára na dopyt SQL_Query pomocou triedy SQL_QueryBuilder.Takže metódy rozhrania QueryBuilder sú metódy na pridávanie rôznych vyhľadávacích kritérií, ktoré vyplnil a použil používateľ vo vyhľadávacom formulári.

Účastník podľa katalógu Trieda systémuBuilder QueryBuilderConcreteBuilder SQL_QueryBuilderDirector CatalogProduct SQL_Query

5.2.5 Vzor Iteratorclass Iterator

LoanReportList

+ GetReservationsIterator() : LRL_Iterator+ GetOrderedLoansIterator() : LRL_Iterator+ GetObta inedLoansIterator() : LRL_Iterator+ GetExpi redLoansIterator() : LRL_Iterator+ GetAl lLoansIterator() : LRL_Iterator

« in terface»LRL_Iterator

+ hasNext() : boolean+ next() : LoanReport+ reset() : vo id

ReservationsIterator


OrderedLoansIterator


ObtainedLoansIterator


ExpiredLoansIterator


AllLoansIterator


Názov pro jektu: Knizn icaAutor: M i los RadosinskýM odel : ObjektovýDiagram : d iagram triedPohlad: LogickýVzor: IteratorDátum : 30.11.2009

«creates»

«creates»

«creates»

«creates»

«creates»

Obr. 12 Aplikácia vzoru Iterator

Vzor Iterator sa používa na oddelenie logiky iterovania od vnútornej reprezentácie štruktúry, nad ktorou iteruje. V tomto projekte je to podobne. Tento vzor som použil v Report vrstve, konkrétne na zobrazenie rôznych typov výpožičiek čitateľa. Čitateľ alebo personál knižnice môže mať záujem vidieť rôzne typy výpožičiek ako sú rezervované výpožičky (ReservationsIterator), objednané výpožičky (OrderedLoansIterator), vydané výpožičky (ObtainedLoansIterator) alebo výpožičky, ktoré vypršali a majú sa vrátiť (ExpiredLoansIterator). Pritom kolekcia výpožičiek je len jedna, t.j. je len jedna kolekcia objektov, nad ktorou sa iteruje. Je to trieda LoanReportList, ktorá obsahuje všetky výpožičky jedného čitateľa.

Účastník podľa katalógu Trieda systémuIterator LRL_IteratorConcreteIterator ReservationsIterator,

OrderedLoansIterator,ObtainedLoansIterator,ExpiredLoansIterator,AllLoansIterator

Aggregate Nie je pokrytéConcreteAggregate LoanReportList

5.2.6 Vzor Facadeclass Facade

UserAccount subsystem classes

«enti ty»Book

- nazov: String- vydane: date- vydanie : in t- pocet_stran: in t- ISBN: String

«enti ty»Exemplar

- signatura: in t- objednany: date- pozicany: date- vrati t: date- stav: in t


- m eno: String- adresa: String- m ai l : String- d lhu je: in t

+ add_book(in t) : boo l+ add_exem plar(int) : bool+ progress_reservation() : vo id+ get_users_loans() : LoanReportL ist

«enti ty»Reservation

- kedy: DateT im e

«enti ty»Loan

Facade

Názov projektu: Knizn icaAutor: M i los RadosinskýM odel : ObjektovýDiagram : d iagram triedPohlad: fyzickýVzor: FacadeDátum : 30.11.2009

0..*

1

0..1

0..*

Obr. 13 Identifikácia vzoru Facade

Vzor Facade sa používa na oddelenie a zakrytie zložitej štruktúry objektov pomocou jednoduchého rozhrania. V tomto projekte som identifikoval fasádu UserAccount, ktorá reprezentuje čitateľské konto používateľa. Funkcionalitu tejto fasády možno zhrnúť v bodoch (v zátvorkách je uvedená metóda rozhrania / fasády):

• Objednávanie a rezervácia knihy (add_book)• Objednávanie a rezervácia exempláru (add_exemplar)• Postúpenie rezervácie rezervantovi pri vrátení knihy (progress_reservation)• Zistenie výpožičiek jedného čitateľa (get_users_loans)• Správa sankcií a upomienok za prekročenie výpožičnej doby (nie je modelované)

Účastník podľa katalógu Trieda systémuFacade UserAccountSubsystem classes Exemplar

BookReservationLoan

5.3 Dynamický a funkčný model systémuV tejto kapitole je uvedený dynamický model pre niektoré prípady použitia a funkčný model pre niektoré metódy. Všetko bude vo forme sekvenčných diagramov.

5.3.1 Prípad použitia Vyhľadanie knihysd Vyhladanie knihy

CitatelTVMenu CatalogUserControlSearchForm CatalogViewer

Ziadost oknihu

«report»BRL

:BookReportList

T V = typ vyhladávaca

Názov projektu : Kn iznicaAutor: M i los RadosinskýM odel : Dynam ickýDiagram : SekvencnýPohlad: LogickýVrstva: Apl ikacnáNázov: Vyhladanie knihyDátum : 30.11.2009

alt dva sposoby ako zacat vyhladavanie

[Hom e page]

[M enu]

www.kniznica.sk()

jednoduchyT V()

T V()on_T V_change()

vybranyT V()

ziadaj_klucove_slova()

zada j_klucove_slova()

zadava_klucove_slova()

vytvor_ponuku_knih()

najdi_knihy()

daj_klucove_slova()

executed_SQL_select()

show_book_ l ist(BRL)

najdi_knihu_v_ponuke()

[kniha_najdena]:

[chceobjednatknihu]:RUN()

[kniha_nenajdena]:

Obr. 14

5.3.2 Prípad použitia Žiadosť o knihusd Ziadost o knihu

:UserContro l loginForm :Log inForm

Cita te l user :UserAccount :BookReportCatalogViewer

Názov p ro jektu : Kn izn icaAuto r: M i los RadosinskýM odel : Dynam ickýDiag ram : SekvencnýPohlad: Log ickýVrstva : Ap l i kacnáNázov: Ziadost o kn ihuDátum : 30 .11.2009

PIN = person Id . num berBIN = book Id . num berEIN = exem pla r Id . num ber = se lected exem plar

E IN je pla tné v request_object, ak ci ta te l ziada konkretny exem plar

log in fa i ledlog in fa i led

BookList

BookDetail

OrderForm

opt book detail

[ci ta te l chce vid ie t deta i l kn ihy]

opt login

[user == nu l l ]

alt exemplar alebo kniha

[E IN je p la tné]

[inak]

opt môže citatel žiadat knihu alebo exemplár?

[n ie nem á, m ôže ob jednat co chce]

show_book_deta i l ()

T oStringFul l (BIN)

:form atted stri ng

show_book_order_ form ()

T oStringFul l (BIN)

:fo rm atted string

[ci ta te l chce konkretny exem pla r]:se lect_exem plar()

request_ob ject()

request_ob ject(BIN, EIN)

ziada jm eno aheslo() zada j

m eno aheslo()

m eno_a_heslo(log inForm )

over_pouzivatela()

load(m eno, heslo)

m a_nedop la tky_?()

add_exem plar(EIN)

add_book(B IN)

Obr. 15

5.3.3 Metóda UserAccount.add_booksd add_book

user :UserAccount

:Reservation

Exemplar

exem plar :Exem plar

:Book

alt je volny exemplar ?

[ano]

[nie ]

inva l id BINinval id BIN

Názov pro jektu: KniznicaAutor: M i los RadosinskýM odel : FunkcnýDiagram : SekvencnýPohlad: LogickýVrstva: M ikroprocesnáNázov: UserAcount.add_bookDátum : 30.11.2009

BIN = book Id . num berEIN = exem plar Id . num ber

add_book(BIN)

load(BIN)

get_free_exem plar(BIN)

:EIN

load(EIN)

set_state_ordered(Calendar.now)

set_user(this)

save()

create(BIN, Calendar.now)

set_user(this)

save()

Obr. 16

5.3.4 Prípad použitia Zmena stavu výpožičkysd Zmena stavu vypozicky

OfficerScanner

ScannerCodeManager

:Offi cerCon tro lLoanController

actua l :LoanStateHandler

next :LoanStateHandler

exem p lar :Exem plar

Názov pro jektu : Kn izn icaAu tor: M i los RadosinskýM odel : Dynam ickýDiagram : SekvencnýPohlad: Log ickýVrstva: Ap l i kacnáNázov: Zm ena stavu vypozickyDá tum : 30.11.2009

opt zobrazit citatelske konto

[IsUserAccountV isib le () == true]

ref

Vizualizácia konta podla PIN

ref

Vizualizácia konta podla EIN

ci ta j_kod_objektu()

pri jm i_a_sp racuj _kod(kod)

da j typ ob jektu pod la kodu(kod )

kn iha a lebo ci ta te l ()

[p reukaz]:OnUserCode(kod)

:UserAccount

[kn iha]:OnBookCode(kod)

ProgressLoan(kod)

load(kod )

GetActua lS ta te (exem plar)

in i t(exem plar)

Exi tSta te()

GetNextS ta te(exem p lar)

in i t(exem pl ar)

exem plar.stav = next.stav()

Ente rS ta te()

IsUserAccountV isib le()

IsUserAccountV isib le()

:UserAccoun t

Obr. 17

5.3.5 Metóda ST06_Handler.EnterStatesd ST06_Handler.Enter

PE :Exemplar:ST 06_Handler user :UserAccountPrinter

«report»LR :LoanReport

String

Scheduler

Názov projektu: KniznicaAutor: M i los RadosinskýModel: Dynam ickýDiagram: SekvencnýPohlad: LogickýVrstva: M ikroprocesnáNázov: ST 06_Handler.Enter (Vrateny)Dátum : 30.11.2009

ref

progress_reservation

LoanContol lerLoanContol lerPE = processed exem plar

alt rezervácie na v rátenú knihu

[sú]

[nie sú]

EnterState()

CancelExpiredLoanReminder(PE)

ini t(PE)

get_data()

T oString()

progress_reservation(PE)

su / n ie su rezervácie()

ScheduleReservationAvai lable(PE)

ScheduleOrderedLoanCom eBack(PE)

print(String)

Obr. 18

5.3.6 Metóda UserAccount.progress_reservationsd ReservationHandling

user :UserAccoun t

PE :Exem plar

:Reservation

reservist :UserAccoun t

:Book

Názov p ro jektu : Kn izn i caAuto r: M i los RadosinskýM odel : FunkcnýDiag ram : SekvencnýPoh lad: Log ickýVrstva : M ikrop rocesnáNázov: UserAccount.progress_reservationDátum : 30 .11.2009

ST 06_Vra teny_EnterST 06_Vra teny_Enter

ST 06_Vrateny_EnterST 06_Vrateny_Enter

ST 06_Vrateny_Ente rST 06_Vrateny_Ente r

progress_reservation (PE)

get_book()

ge t_ fi rst_rese rvati on()

load()

:Reserva tion

[n ie su rezervacie ]:

get_use r_account()

load()

:UserAccoun t

de le te_db_reco rd()

add_exem plar(PE)

[su rezervacie]:

Obr. 19

5.3.7 Prípad použitia Vizualizácia kontasd Vizualizácia konta podla PIN

OfficerUserAccountViewer

user :UserAccount

:OfficerContro l

LRL:LoanReportL ist

Názov pro jektu : Knizn icaAutor: M i los RadosinskýM odel : Dynam ickýDiagram : SekvencnýPohlad: Log ickýVrstva: Ap l i kacnáNázov: V izua l izácia konta podla PINDátum : 30.11.2009

ScannerScanner

PIN = persona l id. num ber

OnUserCode(kod)

ini t_by_PIN(kod)

:boolean

[nep la tny kod]:

show_user_account(user)

get_user_deta i l s()

user_deta i l s()

get_user_ loans()

:LoanReportL ist

user_ loans()

Obr. 20

sd Vizualizácia konta podla EIN

OfficerUserAccountViewer

user :UserAccount

:OfficerControl

LRL:LoanReportList

Názov projektu : KniznicaAutor: M i los RadosinskýM odel: Dynam ickýDiagram: SekvencnýPohlad: LogickýVrstva: Apl ikacnáNázov: Vizual izácia konta podla EINDátum : 30.11.2009

ScannerScanner

EIN = exem plar id. num ber

ini t_by_EIN(kod)

:boolean

[neplatny kod]:

show_user_account(user)

get_user_deta ils()

user_detai ls()

get_user_loans()

:LoanReportL ist

user_loans()

Obr. 21

5.4 Celkový statický model systémuV tejto kapitole je statický objektový model systému na aplikačnej vrstve. Obsahom modelu sú všetky triedy najvyššej úrovne. Neobsahuje interné triedy subsystémov, teda všetky interné triedy aplikovaných vzorov ako napr. QueryBuilder pre katalóg kníh (vzor Builder), iterátory pre reportovanie (vzor Iterator) alebo udalosti plánovača (vzor Abstract Factory).

class Aplikacna

«control»UserControl


«boundary»LoginForm

«boundary»CatalogViewer

«control»Catalog

«boundary»SearchForm

«boundary»UserAccountViewer

«boundary»Scanner

«control»OfficerControl

«enti ty»CodeManager

«boundary»Printer

«enti ty»Exemplar

«report»BookReportList

«report»BookReport

«report»LoanReport

«report»LoanReportList

«contro l»LoanController

«control»LoanStateHandler

«control»Scheduler

«enti ty»LoanPlanTemplate

Názov pro jektu: KniznicaAutor: M i los RadosinskýM odel: ObjektovýDiagram : d iagram triedPohlad: KonceptuálnyVrstva: Ap l ikacná a control vrstvaNázov: Celkový objektový m odel systém uDátum : 30.11.2009

event

«creates»

«uses»

«uses»

«creates»

«uses»

«uses»

«uses»

«holds sta te»

«schedulesfor»

event

Obr. 22 Celkový objektový model systému

Musím osobitne zdôrazniť na tomto mieste, že abstraktná trieda LoanStateHandler má väzbu / reláciu na všetky triedy, ktoré využívajú jej podtriedy. Čiže jej väzby vznikli zjednotením vzťahov jej jednotlivých podtried. Takto je to modelované z dôvodu prehľadnosti.

6 ZhodnotenieAktuálne rozpracovanie návrhu a stav dokumentácie nie je dostatočný s ohľadom na zložitosť domény. Tá si vyžaduje podrobnejší návrh a dokumentáciu, ale z časových dôvodov to nebolo možné dosiahnuť. V práci som použil sekvenčné diagramy na opis logiky operácií a na opis interakcie používateľa so systémom. S ich pomocou som vytvoril logický model systému, v ktorom ale absentuje rozdelenie tried do subsystémov pre používateľov systému. Na relatívne hrubom návrhu som demonštroval existenciu a použitie návrhových vzorov. Celkovo hodnotím prácu dobre.

OOANS - Knižnica

Documents

Transcript of OOANS - Knižnica