Architektúra modulu témata

Transkript

1 Architektúra modulu témata Vypracované autorským kolektívem v složení: Jiři Novotný Miroslav Vacek Peter Cipov Push Team, 2010 Vytvorené Verzia Úvod Účelem tohoto dokumentu je blíže přiblížit architekturu projektu modul Témata, tak jak jsme ji navrhly v rámci této iterace. Během této iterace jsme vyrobily testovací modul, který prokázal, že v naší architektuře lze bezezbytku využít možností frameworku SPRING v oblast testování výsledného kódu. Naše architektura dále umožňuje ladit chyby bez rizika jejich zavlečení do dalších částí aplikace, neboť jednotlivé části jsou od sebe fyzicky odděleny. Toto ještě umocňuje fakt, že později ve fázi deploymentu od sebe budou fyzicky odděleny i aplikace (tedy stávající aplikace bude provozována tam kde doposud a naše řešení se bude otrkávat na serveru beta.kiv.zcu.cz dokud nebude zadavatel spokojen s našimi výsledky). V rámci návrhu této architektury jsem vycházeli zejména z finální verze vize projektu schválené zákazníkem (viz wiki projektu, sekce downloads) a dále z diagramu případů užití (viz Ilustrace 1), který vznikl na základě konzultace se zákazníkem.

2 Ilustrace 1: Diagram případů užití 2 Klíčové aspekty organizace Modul témata má za úkol umožnit zaměstnancům KIV vypisovat a následně přidělovat témata. Na takto vypsaná témata se budou moci zapisovat studenti KIV pomocí svého webového prohlížeče. Náš modul má v současnosti tři základní subsystémy: 1) modul DAO obstarává komunikaci s databází, fyzicky z ni vybírá data 2) modul Mediator zabezpečuje práci z daty, např. logika pro filtrování, editaci, či výpis témat 3) modul View zobrazení výsledků uživateli 3 Mimofunkční požadavky V rámci mimofunkčních požadavků jsme narazili na zajímavý problém. V našem týmu totiž nelze dostatečně dobře použít tzv. Burnout charts. Důvodem tohoto problému je fakt, že na této práci pracujeme ve velké míře nárazově, což je do značné míry vynuceno skladbou předmětů v tomto semestru. Není tedy neobvyklé, když člen týmu věnuje práci na tomto tématu jen dva dny v týdnu, nicméně tyto dva dny pracuje opravdu jen na zadaném úkolu. Jako určitou formu náhrady za Burnout charts je možné chápat FlySpray RoadMap, který monitoruje stav jednotlivých tasků ze systému FlySpray. Tato náhrada se však uplatní pouze tehdy, budeme-li mít možnost ji využívat (probíhají jednání s Přemyslem Bradou o přístupu k tomuto nástroji).

3 4 Kontext Modul témata běží v kontextu několika dalších aplikací. Toto ukazuje ilustrace 2. Zde je vidět, že nedílnou součástí našeho systému je OpenCMS, SMTP server, a další služby, bez kterých by funkce našeho modulu nebyla možná. Ilustrace 2: Návaznosti modulu Témata na další služby 5 Zdůvodnění Naše architektura se do současné podoby dostala zejména proto, že ze strany zákazníka byly kladeny konkrétních požadavky na použití určitých technologií. Tyto požadavky mají svůj původ v politice katedry, která aplikace podobného rozsahu jako je naše, dává k vyřešení svým studentům. Tito studenti však mnohdy nemají znalost pokročilých technologií (např. Hybernate,...), čili je nutné, aby na řešení mohli pracovat s nástroji, které důvěrně znají (např. Java, JSP,...). Proto se naše architektura opírá zejména právě o programovací jazyk Java, JSP, Servlety a pouze okrajově používáme pokročilejší technologie, jako např. SPRING.

4 6 Princípy Veríme že dobre členený kód je základom správnych programátorských návykov. Predchádza sa tým znižovaniu čitateľnosti a potenciálnym logickým chybám. Pri vývoji sa budeme držať nasledujúcich zásad: Budeme dodržiavať zaužívané programátorské konvencie [1] Programovanie cez interface [2] bude slúžiť ako základný vzor pre väčšinu situácií. Očakávané výhody tejto voľby by sa mali dostaviť vo forme jednoduchších zmien kódu a lepšieho dekomponovania problému. Vytváranie doménového modelu vo forme jednoduchých java objektov (POJO). To aj znamená úsilie o čo najmenšiu nezávislosť od používaných technológií. Objektový návrh je dôležitejší ako použité technológie Testovanie je nevyhnutnou súčasťou vývoja. 7 Subsystémy Témata modul je vystavaný ako modul do OpenCms. Je fyzicky rozdelený do troch celkov: Dátová vrstva databázy spoločný modul pre všetky moduly. Jedná sa o implementáciu návrhového vzoru DAO [3]. Umožňuje jednotný prístup a zjednocuje rozhranie prístupu k systému riadenia bázy dát (srdb). Kód sa tým odľahčí od manažovania spojenia (vytvorenie, udržovanie, obnova, ukončenie) a implementačných detailov ako rôzne dialekt srbd. Táto vrstva poskytuje veľkú časť doménového modelu, ktorý je spoločný pre všetky vyššie vrstvy. Aplikačná logika aplikačná logika je postavená na DAO vrstve. V podstate sa jedná o vysoko úrovňovú logiku od získania požiadavku od užívateľa až po vytvorenie patričnej odpovede. Riešia sa tu problémy nad viacero DAO objektmi. Komplikovanejšie úlohy nad viacerými tabuľkami, triedenie a zoraďovanie výsledkov, validácia požiadavku, bezpečnosť. Prezentačná vrstva stará sa len o rendering odpovede. Je natívne predpokladaná technológia JSP (Java Server Pages). Jednotlivé JSP stránky volajú aplikačnú logiku ktorá im vráti odpoveď vo forme objektov doménového modelu. Tieto objektu JSP prevedie do požadovaného formátu (napr. XHTML 1.1 strict). Ďoležitou vlastnosťou JSP stránok v module je, že vytvárajú iba neformátovanú odpoveď, tzn., len čisté XHTML bez formátovania. Táto ich vlastnosť bola zvolená z dôvodu, že webmaster cms systému považuje jsp stránky v moduloch za malé atomické jednotky, ktoré si do svojich (iných) jsp stránok vloží pomocou include príkazu. Tým je mu umožnené si stránku poskladať podľa vôle.

5 8 Balíky Distribúcia témata modul je archív komprimovaný štandardnou metodou LZW (.zip súbor). Ten sa skladá z: Priečinok Pages obsahuje JSP stránky Priečinok lib obsahuje všetky jar súbory distribúcie. V súčastnej dobe obsahuje len jeden jar so skompilovanými triedami modulu. Distribúcia sa skladá z balíkov: cz.zcu.kiv.compators komparátory pre vyššiu aplikačnú logiku. cz.zcu.kiv.formhandler validátory odpovede od užívateľa cz.zcu.kiv.mediator obsluha requestu od užívateľa, miesto pre hlavnú apl. logiku cz.zcu.kiv.temata.trideni zabezpečuje funkciu triedenia a načítania zoznamu entit podľa stanovených kritérií

6 9 UML diagramy 9.1 Class diagram Ilustrace 3: Class diagram bližšieho pohľadu na architektúru modulu

7 Ilustrace 4: Class diagram obecnejšieho pohľadu na architektúru modulu 9.2 Component diagram Ilustrace 5: Komponentový diagram modulu temata

8 10 Rekapitulace Naše architektura tedy vychází především z finální verze vize produktu a diagramů užití. V architektuře se dále odráží i výsledky naších informačních schůzek se zákazníkem. Architektura samotná pak byla úmyslně navržena tak, aby nevyužívala žádné pokročilejší technologie, ale naopak byla přístupná studentům KIV (např. Absolventům předmětu PIA). Návrh se do značné míry opírá o programování do rozhraní. Toto je velmi důležitý aspekt, který nám umožnil použít v rámci naší aplikace framework Spring, jako nástroj pro testování výsledného kódu.

9 11 Literatúra [1] Sun Microsystems. Code Conventions for the Java TM Programming Language [online]. Posledné úpravy [cit ]. Dostupné na docs/codeconv/html/codeconvtoc.doc.html. [2] GAMMA Erich. -HELM Richard. -JOHNSON Ralph. -VLISSIDES M. John. Design Patterns: Elements of Reusable Object-Oriented Software. London: Addison-Wesley, 1995, ISBN [3] Wikipedia. Data access object [online]. POsledné úpravy [cit ]. Dostupné na