MASARYKOVA UNIVERZITA
Fakulta informatiky
Informační systém TPV pro realizaci interiérů
Bakalářská práce
2007, Brno
Vypracoval: Antonín Klein Vedoucí: RNDr. Pavel Hajn
Poděkování: Rád bych tímto poděkoval RNDr. Pavlu Hajnovi za ochotnou pomoc a cenné rady při zpracování bakalářské práce a realizaci projektu. Dále bych rád poděkoval Marku Klementovi za neméně cenné tematické informace.
2
Prohlášení:
Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj.
Antonín Klein
3
Shrnutí: Tato práce popisuje návrh informačního systému TPV pro realizaci interiérů. Hlavním tématem je analýza problematiky, návrh datového modelu a funkční dekompozice. Práce obsahuje implementaci většiny funkcí nutných pro koncového zákazníka, návrh a skript k vytvoření kompletní databáze.
Klíčová slova: Informační systém, technická příprava výroby, realizace interiérů, Java, JSP, Firebird, VRML,
4
Obsah 1Úvod..........................................................................................................................................6 1.1Zadání................................................................................................................................7 1.2Forma realizace.................................................................................................................7 1.3Záměr.................................................................................................................................7 2Rozbor problematiky.................................................................................................................8 2.1Požadavky na systém.........................................................................................................8 2.2Uživatelé a jejich role.......................................................................................................9 2.2.1Dovozce materiálu ....................................................................................................9 2.2.2Správce katalogu......................................................................................................10 2.2.3Maloobchodník (podlahář)......................................................................................10 2.2.4Koncový zákazník (neregistrovaný)........................................................................10 2.2.1Koncový zákazník (registrovaný)............................................................................10 2.3Události v systému..........................................................................................................10 2.3.1Dovozce materiálu...................................................................................................10 2.3.2Správce katalogu......................................................................................................11 2.3.3Maloobchodník........................................................................................................11 2.3.4Zákazník (nepřihlášený)..........................................................................................11 2.3.5Zákazník (přihlášený)..............................................................................................12 2.4Kontextový diagram........................................................................................................12 2.5Diagram datových toků (Data-Flow Diagram.................................................................13 3Datový model..........................................................................................................................15 3.1.1Entitně relační diagram............................................................................................18 3.1.2Entity.......................................................................................................................19 3.1.3Relace mezi entitami................................................................................................23 4Realizace systému...................................................................................................................25 4.1Programové vybavení na úrovni databáze.......................................................................25 4.2Aplikační vrstva v prostředí JavaBeans..........................................................................27 4.2.1Objektová hierarchie................................................................................................27 4.3Vizualizace......................................................................................................................30 5Závěr.......................................................................................................................................30 5.1Přínos práce.....................................................................................................................30 5.2Možnosti rozšíření...........................................................................................................30 6Použité informační zdroje.......................................................................................................31 6.1Literatura.........................................................................................................................31 6.2Internetové zdroje............................................................................................................31 7Přílohy.....................................................................................................................................32
5
1 Úvod V posledních letech lze pozorovat značný rozmach informačních systémů podpořený rozšířením internetu. Informační systémy usnadňují a šetří práci lidem ve většině oborů. Tento trend zasáhl většinu obchodních i výrobních aktivit, stavebnictví nevyjímaje. Zaměstnancům kvalitní systém poskytuje právě informace relevantní pro jejich práci a to právě v čas, kdy tyto informace potřebují. Jedná se nejen o údaje důležité pro vnitřní chod podniku, ale také o neméně důležité informace o potřebách zákazníků, nebo o nabídce dodavatelů. Z pohledu spolupráce více subjektů rozlišujeme tři základní modely komunikace. Je to spolupráce dvou a více firem, jenž bývá běžně označována zkratkou B2B z anglického termínu „business to business“, spolupráce (a komunikace) společnosti se zákazníkem (Business to Customer, B2C) a často opomíjený termín „Customer to Customer“ (C2C), který v doslovném překladu značí spolupráci více zákazníků. Znamená to, že není předem dáno, který účastník komunikace je zákazníkem a který obchodníkem. Do modelu C2C bývají řazeny např. aukční portály nebo inzertní servery. Důležitou skupinou jsou systémy pro informační podporu výroby. Technická příprava výroby obvykle eviduje data o potřebném materiálu a jeho množství, pracovních postupů, případně balení výsledných výrobků nebo odpady, které při výrobě vznikají. Zpravidla bývají kombinovány různé typy informačních systémů tak, aby co nejlépe vyhověly potřebám zadavatele. Často se například používá IS logistiky skladu nebo evidence objednávek propojený s účetním systémem, případně i s podporou řízení výroby. Takto, vhodnou kombinací komponent, vzniká IS schopný usnadnit, až zčásti převzít řízení celého podniku. Tato práce vznikla v rámci dlouhodobé spolupráce s dovozcem podlahových krytin, v návaznosti na elektronický obchod, jehož funkce připravovaný systém zčásti převezme. Snahou investora IS je podpořit prodej mimo jiné tím, že klade důraz na dobrou informovanost koncových zákazníků. Jedním z hlavních cílů systému je tedy poskytnout koncovému zákazníkovi možnost navrhnout si vlastní podlahu podle rozměrů místnosti a dalších aspektů ovlivňujících její funkčnost a získat přesnou kalkulaci s ohledem na výběr konkrétního podlaháře. Ve druhé kapitole jsou dopodrobna rozepsány požadavky na funkčnost systému. Tento text vznikl po dvou konzultacích se zadavatelem IS a s využitím poznatků získaných dlouhodobou spoluprací s ním. Specifikace, tedy soupis požadovaných funkcí systému, je velmi důležitým dokumentem. Má za úkol ujasnit, co všechno má IS umět, tedy za co všechno klient zaplatí. Kapitola pokračuje analýzou problematiky z pohledu jednotlivých uživatelů systému, kterou ilustruje v kontextovém diagramu. Následuje nástin rozvržení programových komponent a jejich komunikace v podobě diagramu datových toků (Data-Flow diagram), který vzniká dekompozicí kontextového diagramu.
6
Jde o neopomenutelnou fázi vývoje každé aplikace. Podle [1] totiž ve fázi rozboru problematiky vzniká 56% všech chyb v realizaci informačních systémů, navíc celých 82% času bývá třeba věnovat právě takto vzniklým chybám. Navíc, pokud se chyba neprojeví vlastním provozem systému, často značně zkomplikuje jeho rozšižování o nové funkce.
Třetí kapitolase zabývá návrhem datového modelu a nabízí podrobný popis jeho entit včetně relací mezi nimi. Programové vybavení IS lze rozdělit do několika vrstev v závislosti na tom, jak podrobné rozlišení požadujeme. V této práci budu uvažovat rozčlenění do tří z nich, jako je databázová, aplikační a prezantační vrstva (uživatelské rozhraní). Rozdělení funčnosti aplikace mezi tyto vrstvy je vždy značně diskutabilní, nelze přesně definovat, na které úrovni psát jednotlivé komponenty. Na tento problém narážíme zejména v rozhodování mezi úrovní databáze a aplikace. Zde si lze mírně usnadnit rozhodování zodpovězením otázky přenositelnosti na jiné platformy. Poslední, pátá, kapitola nabízí shrnutí a zhodnocení výsledků celé práce. Zvažuje její přínosy, výhody a některá možná úskalí práce se systémem. Dále jsou zde uvedena možná rozšíření s nástinem realizace některých z nich.
1.1 Zadání Autor zjistí a zanalyzuje základní požadavky a vlastnosti systémů pro technickou přípravu výroby (TPV). Dále se zaměří na specifika a odlišnosti technické přípravy výroby v oblasti realizace interiérů (pokládky podlah). Definuje požadavky na obsah a funkčnost systému. Zanalyzuje tyto požadavky a navrhne IS pro podporu TPV v oblasti realizace interiérů. Návrh bude obsahovat datový a funkční model a praktickou realizaci části systému.
1.2 Forma realizace Text práce obsahuje analytické diagramy (DFD, ERD), jejich popis, zdůvodnění některých složitějších postupů a ukázky zajímavých programových částí. Na základě analýzy vznikla databáze, nad níž pracují softwarové komponenty napsané v procedurálním SQL (PL/SQL) a v programovacím jazyce Java, jako objekty JavaBeans pro platformu JSP. Praktická realizace části těchto komponent je zahrnuta v příloze práce.
1.3 Záměr Cílem této práce je navrhnout systém pro informační podporu realizace interiérů specializovaný a navržený primárně na pokládku podlah. Systém by měl být s úpravami použitelný i pro jiné oblasti zakázkové výroby. Kromě formálního návrhu budou implementovány základní knihovny (javovské balíky - „packages“) poskytující část aplikační logiky.
7
2 Rozbor problematiky 2.1 Požadavky na systém Navrhovaný IS technické přípravy pokládky podlah obsluhuje toky informací mezi třemi základními skupinami uživatelů, jimiž jsou koncoví zákazníci, maloobchodníci (podlaháři) a dovozce materiálu. Koncovým zákazníkům systém nabídne možnost sestavit si projekt nové podlahy přesně podle parametrů místnosti, aniž by opustili pohodlí domova, obchodníkům by pak měl usnadnit evidenci objednávek, jejichž přenos z velké části přebírá. Základem je potenciálně velmi rozsáhlá databáze podlahových krytin včetně jejich fotografií a co nejpodrobnějších popisů. Materiály jsou rozděleny do kategorií a podkategorií, které lze dělit do libovolné úrovně. Systém eviduje také výrobcemateriálů, přičemž do budoucna by měla být možná snadná implementace generování objednávek pro výrobce. Kromě materiálů jsou také evidovány pracovní postupy nutné k jejich instalaci a doplňkové úpravy. Koncovému zákazníkovi systém umožní zvolit si zejména dřevinu, případně barevnou variantu podlahy a lišt, tyto zobrazí v náhledu místnosti, jejíž parametry zadal. Díky vizualizaci má zákazník představu, jak bude vypadat nová podlaha právě v jeho místnosti. Pro zjednodušení pro začátek uvažujeme pouze obdélníkový nebo čtvercový tvar místnosti; podpora složitějších tvarů by měla být realizovatelná bez složitějších změn na úrovni datového modelu. Kromě výe uvedených základních součástí mohou být systémem nabízeny také další materiály k pokládce podlahy, stejně tak jako jiné doplňky. Kromě výběru krytiny a lišt podle vzhledu může klient upravovat tloušťku podlahy pomocí různě silných podložek nebo přizpůsobit podlahu konkrétním podmínkám volbou vhodné izolace. Systém během návrhu zobrazuje vlastnosti celého projektu, které může ovlivnit kterákoli použitá součást. Výpočet hodnot je určen pro každou vlastnost a zároveň není nutné, aby každý materiál ovlivňoval všechny vlastnosti celku. Významnou vlastností je např. použitelnost navrhované podlahy (a všech jejích komponent) v kombinaci s podlahovým vytápěním. Systém by měl u materiálu být schopen evidovat jednu ze 3 hodnot: nevhodný, použitelný a (velmi) vhodný a celému projektu přiřadit hodnotu nejméně vhodného materiálu. Zároveň může zákazník průběžně kontrolovat celkovou cenu díla včetně nutných, případně doplňkových prací, jako je lakování, broušení nebo vlastní pokládka. V této fázi však cena může být ovlivněna faktem, že nebyl dosud vybrán dodavatel, a do kalkulace je zahrnuta nejnižší cena každého materiálu a práce. V této souvislosti je třeba vzít v úvahu fakt, že činnosti spojené s použitím některých materiálů jsou v praxi účtovány tak, že je do ceny práce (na metr čtverečný) započtena i spotřeba materiálu.
8
Takto se běžně účtují činnosti, jako je lakování, olejování nebo vyrovnání nerovností podkladu. Spotřeba takových materiálů bude tedy i v systému reprezentována související činností. Práce je možné sdružovat do tzv. balíčků nebo složitějších úkonů, které sestavuje správce katalogu, jedna činnost naaíc může být součástí více celků. Je také nutné evidovat vztahy mezi materiálem a činností. Některé podlahy se prodávají bez povrchové úpravy, tyto je tedy třeba nalakovat nebo naolejovat, naopak, některé dřeviny nemusí dobře snášet některé druhy laků či olejů. Jakmile je zákazník s výsledkem spokojen, může projekt (rozumějme navrhovanou místnost) objednat nebo začít s plánováním dalšího. Před odesláním objednávky má zákazník možnost porovnat kalkulace od různých podlahářů, z nichž si posléze vybere. Ke každému projektu lze napsat vzkaz pro podlaháře k případnému upřesnění nebo doplnění o položky, jež nejsou v nabídce systému. Klient může definovat více adres k instalaci podlah, objednávka může obsahovat projekty realizované na více adresách. Adresu pro fakturaci určí zákazník při registraci. Jak již bylo naznačeno, do systému lze zadat libovolné množství projektů podlah. Orientaci v nich usnadní popis (např. název místnosti). Před odesláním objednávky si zákazník ze svých projektů vybere ty, které chce skutečně realizovat. Po potvrzení objednávky klientem je tato postoupena maloobchodnímu prodejci, který taktéž realizuje pokládku podlahy. Prodejce objednávku zkontroluje, obsahuje-li všechny administrativní náležitosti a návrh podlahy je sestaven smysluplně. Je totiž například možné, že v systému chybí některé vazby materiálu na nutné práce. Objednávku poté telefonicky ověří u zákazníka, případně ji po dohodě upřesní, nebo doplní o materiál nebo činnosti, které v nabídce systému chybí. Maloobchodníkovi je navržena objednávka materiálu k předání dovozci. Tato velkoobchodní objednávka může obsahovat materiál z jediné objednávky od koncového zákazníka, nebo veškerý dosud neobjednaný materiál nutný k realizaci maloobchodních zakázek. Povolil-li to dovozce, může maloobchodník množství některých materiálů v objednávce snížit, případně materiál z objednávky odstranit. Toto je využito v případě, že má maloobchodník daného materiálu dostatek, nebo se jedná o materiál, jehož prodej není pro dovozce zajímavý a tedy jej maloobchodník může nakupovat jinde. Přidávat materiál do objednávky, ať už je nebo není v jejím návrhu, je možné vždy.
2.2 Uživatelé a jejich role 2.2.1 Dovozce materiálu • • •
Určuje velkoobchodní a maloobchodní ceny materiálu. Pro velkoobchod vytváří a spravuje různé skupiny odběratelů s různými VO cenami materiálu. Ke každé položce materiálu určí, zda smí být odstraněn z objednávky, nebo sníženo 9
jeho množství.
2.2.2 Správce katalogu • • •
Udržuje katalog materiálů a prací. Zejména tedy vkládá nové podlahové krytiny, jejich varianty a vlastnosti. Udržuje správné a přesné informace v databázi. Jedná se hlavně o eliminaci nesprávných nebo nekompletních vazeb materiálu na postup instalace, nebo stejných či velmi podobných názvů vlastností nestejného významu.
2.2.3 Maloobchodník (podlahář) • • •
Definuje vlastní maloobchodní ceny podlah, doplňků a sazeb za práci Po přijetí objednávky od koncového zákazníka vyžádá (zpravidla telefonicky) u zákazníka její potvrzení. Objednávku jakkoli nevyhovující (např. obsahuje-li nesmyslné či chybné údaje o zákazníkovi a nelze je opravit), může objednávku zrušit. Zkontroluje potřebné množství materiálu pro projekty objednané prostřednictvím systému, shlédne návrh objednávky materiálu, případně ji doplní dle vlastní potřeby a potvrdí ji, nečež je objednávka předána dovozci.
2.2.4 Koncový zákazník (neregistrovaný) • • •
má možnost procházet nabídku materiálu a doplňků. V katalogu lze vyhledávat podle výrobce a typu materiálu, případně podle parametrů. Může si taktéž sestavit vlastní návrh místnosti a shlédnout jeho náhled a sledovat kalkulaci. Má také možnost porovnat cenové nabídky více maloobchodníků. Realizaci takto vytvořeného projektu však nemůže objednat, dokud se nezaregistruje nebo nepřihlásí.
2.2.1 Koncový zákazník (registrovaný) • •
může navíc objednat realizaci navržené podlahy zvoleným podlahářem a sledovat stav vlastních objednávek. Nesmí však stornovat již odeslanou objednávku.
2.3 Události v systému 2.3.1 Dovozce materiálu 1. aktualizuje maloobchodní ceny materiálu 2. vytváří skupinu velkoobchodních odběratelů 3. definuje VO ceny pro spupinu 4. žádá informace o skupinách prodejců 5. mění informace o skupině
10
6. ruší skupinu 7. ptá se na objednávky materiálu 8. mění stav objednávky materiálu
2.3.2 Správce katalogu 9. zobrazzuje informace o materiálech v nabídce 10. vkládá so katalogu nové komponenty a informace o nich 11. upravuje informace o existujícím materiálu 12. zobrazuje informace o pracovních postupech 13. přidává nový pracovní postup 14. aktualizuje informace o činnosti 15. odstraňuje činnost
2.3.3 Maloobchodník 16. definuje maloobchodní ceny materiálu 17. definuje ceny za práci 18. přijímá objednávku realizace podlahy 19. mění stav objednávky (včetně jejího odmítnutí) 20. upřesňuje informace v objednávce 21. přijímá návrh objednávky materiálu 22. upřesňuje objednávku materiálu
2.3.4 Zákazník (nepřihlášený) 23. zadává parametry pro vyhledání materiálu nebo jiných komponent 24. prochází katalog podle kategorií 25. vytváří novou místnost k položení podlahy 26. vybírá místnost ze seznamu již vytvořených 27. vybírá komponenty k použití v projektované místnosti 28. žádá náhled místnosti 29. žádá předběžnou kalkulaci
11
2.3.5 Zákazník (přihlášený) 30. zadává parametry pro vyhledání materiálu nebo jiných komponent 31. prochází katalog podle kategorií 32. vytváří novou místnost k položení podlahy 33. vybírá místnost ze seznamu již vytvořených 34. vybírá komponenty k použití v projektované místnosti 35. žádá náhled místnosti 36. žádá předběžnou kalkulaci 37. objednává navrženou podlahu 38. žádá stav svých objednávek
2.4 Kontextový diagram Kontextový diagram1 je specifický typ diagramu datových toků, který zobrazuje toky informací mezi aplikací (zde chápána jako celek) a účastníky, s nimiž aplikace komunikuje. Bývá běžné, že kontextový diagram vychází ze seznamu událostí v systému, neprojevují se v něm však časem řízené události. Níže znázorněný diagram tedy obsahuje pět terminátorů, přičemž každý reprezentuje jednu ze skupin uživatelů. Terminátor „registrovaný zákazník“ obsluhuje všechny toky obsluhované terminátorem nepřihlášeného zákazníka, které navíc doplňuje o toky nutné k obsluze objednávek. Můžeme si všimnout, že mírně převládají toky informací do systému. To je způsobeno tím, že uživatelé ze systému dostávají adekvátní informace zakomponované do souvislých celků, jako jsou objednávky, detailní výpisy informací o materiálech, výpisy možných pracovních postupů, zpravidla v přehledných tabulkách.
1 [5]
12
Obrázek č. 1: Kontextový diagram
2.5 Diagram datových toků (Data-Flow Diagram Diagram datových toků vzniká funkční dekompozicí kontextového diagramu na jednotlivé procesy a rozhraní (datové toky) křes která si vzájemně předávají data.
13
Obrázek č. 2: Diagram datových toků (DFD)
14
3 Datový model Na základě rozboru požadovaných funkcí systému je možné vytvořit datový model. Jak již uvádí ve svých skriptech M. Duží [1], je entitně-relační model postaven na třech základních kontruktech, jimiž jsou entity, vztehy a atributy: Entitou rozumíme objekt reálného světa, ať už konkrétní či abstraktní, jenž může existovat nezávisle na ostatních a je jednoznačně identifikovatelný. V případě pokládky podlah tedy budeme pravděpodobně mít entity jako materiál, pracovní postup, dílo, objednávka, dodavatel, řemeslník, zadavatel, apod. Vztah, neboli relace, propojuje dvě nebo více entit, může být navíc ohodnocena nějakými atributy. Tak můžeme například mít relace „k realizaci díla je potřeba materiál (o určitém množství)“, „objednávka obsahuje materiál (o nějakém množství, v nějaké ceně)“, „materiál má vlastnost (o hodnotě...)“ „zadavatel objednává dílo od řemeslníka (dne...)“. Atribut přiřazuje entitě nebo relaci hodnotu nějaké výzmamné vlasztnosti. Atributů lze v jakékoli výrobě najít nespočet. Každá zúčastněná osoba má jako atributy své jméno, adresu, telefon; podnikatelské subjekty mají navíc fakturační údaje, tedy IČO a DIČ; dílo (instalovaná podlaha) má zejména šířku, délku a tlouˇšťku. Materiál má značné množství vlastností, navíc zde záleží o jaký druh materiálu se jedná (podlahy, lišty, izolační materiál). Vzhledem ke značnému významu vlastností matierálu na celé dílo je ve své práci neobsluhuji pomocí atributů díla, ale poměrně rozdílným způsobem, jenž bude popsán později v této kapitole. Jak je patrné z kontextového diagramu, se systémem by mělo pracovat celkem 5 skupin uživatelů. Neregistrovaného zákazníka není třeba (a prakticky nelze) evidovat, jeho činnost se projeví vytvořením objektů vázaných na jejich sezení. Poměrně malou skupinou jsou správci katalogu. Jedná se obvykle o jednotlivce, z pohledu systému jde obecně o osobu a nezáleží na tom, zda tato je sama prodejcem či nikoli. Člověk pověřený ke správě katalogu potřebuje přístup k administrativnímu rozhraní, k tomu stačí příznak v entitě evidující uživatele. Důležité je odlišení zákazníků od podlahářů a dovozce materiálu. Hlavní rozdíl spočívá v tom, že koncový zákazník prostřednictvím systému objednává kompletní realizaci podlahy, kdežto obchodník (podlahář) objednává od dovozce potřebný materiál. Navíc je třeba přiřadit prodejce k nějaké skupině vvelkoodběratelů. V případě pokládky podlahy svépomocí může zákazník objednat materiál přímo od dovozce (za maloobchodní ceny). Dovozce tedy stačí od maloobchodníků odlišit pouze příznakem v jeho záznamu. Základním prvkem každého díla je materiál. Ten má více variant, každá varianta má nějaké vlastnosti. Podle těchto vlastností je třeba materiály vyhledávat a navíc se některé vlastnosti přenáš na hotovou podlahu. Vlastnost tedy definujeme jako zvláštní entitu, mezi níž a variantou materiálu
15
zavedeme M:N vazbu nesoucí hodnotu dané vlastnosti pro daný materiál. Mějme tedy například vlastnost „tloušťka“, jejíž jednotkou je milimetr a tloušťky všech použitých komponent se sčítají.
Název vlastnosti Jednotka
Funkce
Tloušťka
mm
(+)
Počet lamel
NULL
NULL
Počet lamel je pouze informativní vlastností, systém se jí blíže nezabývá. Následuje vlastní ilustrace možného výsledného zobrazení vlastností:
Produkt (materiál)
Vlastnost
Hodnota
1. podlaha
Tloušťka
22
2. podlaha
Počet lamel
3
podložka
Tloušťka
12
Použijeme-li tedy první podlahu z tabulky a podložku, jejich tloušťky se tedy sečtou a výsledná položená podlaha bude 34mm silná.
Důležitým prvkem v systému je klientem vytvářený návrh podlahy. Zákazník zadává parametry místosti, v níž by měla být podlaha instalována; k takto vytvořenému základu je třeba přiřadit potřebné množství zákazníkem požadované krytiny a dalších komponent a pokud nejde o instalaci svépomocí, také nutné nebo zvolené pracovní postupy. Pracovní postupy je třeba evidovat nejen samostatně k výběru zákazníkem k projektu, ale hlavně v závislosti s podlahovými krytinami. Ty je třeba nejen instalovat, ale často určitým způsobem upravit. Způsoby úpravy mohou být různě kombinovány. Ke každému druhu podlahy je tedy třeba znát možné nutné i volitelné kombinace pracovních postupů. Jako vhodné řešení tohoto problému se zdá být reprezentace logickým výrazem. K tomu se hodí entita se dvěma self-relacemi, označenými AND a OR. Jejím použitím vznikne strom, jehož každý uzel je ohodnocen logickým operátorem a listy odkazují na pracovní postupy. Mějme tedy například podlahu dodávanou bez povrchové úpravy. Tu je třeba „položit“ a poté se provádí lakování nebo olejování. Prezentaci této informace v databázi ilustruje následující tabulka. Pro přehlednost místo číselných klíčů entit varianty materiálu (#prod_version) a činnosti (#operation) uvádím popis podlahy, respetive názvy činností.
16
ID materiál 1 2
Rodič AND
Rodič OR
činnost
Podlaha bez povrchové úpravy 1
pokládka
3
1
lakování
4
1
olejování
Ekvivalentně lze celou relaci vyjádřit n-árním stromem, výsledkem je výraz
pokládka AND ( lakování OR olejování ) Nabízí se varianta, popisující vztah materiálu a předepsaného postupu pomocí binárního stromu. Pro jeho implementaci stačí jedna relace odkazující na poduzly každého uzlu a logický operátor by byl uložen jako atribut vnittřního uzlu.
Obrázek č. 3: biární strom pro volbu úprav Upřednostnil jsem však n-ární strom, poněvadž lze díky němu znatelně snížit potenciální hloubku stromu a tedy i počet kroků při jeho procházení. Lze navíc předpokládat, že budou vytvářeny především uzly s více možnostmi výběru, případně s více povinně použitými poduzly. Implementace komponent obsluhujících tuto strukturu se ukázala jako srovnatelně náročná jako u binárního stromu.
Obrázek č. 4: n-ární strom pro volbu úprav
17
3.1.1 Entitně relační diagram
Obrázek č. 5: Entitně-relační model
18
3.1.2 Entity Person Typ: kernel Entitou (#person) je každá osoba nebo subjekt pracující se systémem. Entita eviduje základní informace o osobě nebo firmě, jako jsou jméno, příjmení, respektive název firmy, fakturační údaje (IČO a DIČ), dále e-mailovou adresu a telefon pro ověření objednávek. Client Typ: weak-entity
Entitou (#Client) je osoba zaregistrovaná za účelem navržení a objednání dodávky podlahy, jedná se o rozšíření entitní sorty (#person). Mezi entitou (#Client) a (#Osoba) je vazba arity 1:1, proto je v entitě (#Client) primárním klíčem ideitifikace osoby v entitě (#Osoba). Dealer Typ: weak-entity
Entitou (#Dealer) je jednotlivec nebo firma realizující prodej a pokládku podlahových krytin, jedná se o rozšíření entitní sorty (#person). Nese textovou informaci o působnosti. I u prodejců sice systém eviduje adresu (případně více adres více provozoven), ta však nemusí klientovi při výběru dodavatele být platná, zejména pokud má obchodník provozovni v méně známém místě. Navíc i prodejce sídlící v Brně může být schopen efektivně působit v rámci celé republiky a pokud by měl více provozoven, klient nepotřebuje vědět, odkud k němu řemeslník dorazí. Entita (#Dealer) používá, podobně jako (#client), jako primární klíč ideitifikaci osoby. Dealer_group Typ: kernel Entitou (#dealer_group) je taková skupina obchodníků (#dealer), která má stejnou úroveň velkoobchodních cen.
Address Typ: kernel Entitou (#address) je každá (klasická) adresa osoby nebo jiného subjektu (#person) pracujícího se systémem. Eviduje zejména adresy klientů, kde mají být realizovány jejich projekty. Product Typ: kernel
19
Entitou (#Product) je každý velkoobchodníkem nabízený výrobek, zpravidla, ne však nutně materiál. Entita obsahuje zejména základní popis produktu (materiálu), odkazy na kategorii v níž je zařazen a výrobce. Pojmenování této entity vychází z toho, že investor, tedy dovozce chápe dodávaný materiál jako obchodované zboží. Navíc má být zachována možnost volného prodeje artiklů, které nemají charakter meteriálu.
Category Typ: kernel
Entita (#Category) je každá kategorie materiálů majících určité společné znaky. Kategorie může mít žádnou nebo více podkategorií. Entita Category obsahuje atributy tract a girt, které signalizují použití výpočtu množství materiálu podle plochy (tract), respektive obvodu (girt) projektované místnosti. Jiným možným řešením by bylo použití jediného atributu, který by pak nabýval více hodnot reprezentujících jednotlivé možnosti, navíc by se tak zamezilo možnosti nahrání nevalidních dat. K tomu dojde např. nastavíme-li, že je povoleno libovolné množství materiálu a zároveň, že je třeba počítat množství podle plochy. Na druhou stranu, řešení pomocí více atributů je přehlednější zejména při psaní dotazů na databázi; správnost dat zaručí jednoduchá spoušť. Vyhneme se tak také nutnosti použití různých číselných konstant pro různé způsoby výpočtu.. Property Typ: kernel Entita (#Property) - vlastnost - reprezentuje nějakou vlastnost materiálu. Kromě názvu a měrné jednotky nese také informaci o tom, jak se tato vlastnost materiálu přenáší na celý projekt. Konkrétně u podlah můžeme takto evidovat tloušťku (sčítá se tloušťka podlahy s tloušťkou podložek) nebo vhodnost krytin pro podlahové vytápění. Zde jsou proti původnímu předpokladu (vhodné - nevhodné) podle zadavatele potřeba evidovat tři úrovně (vhodné - použitelné - nevhodné). Proto bude místo logického součinu nutné brát zde v úvahu minimální hodnotu ze seznamu.
Image Typ: kernel Entitou (#image) je každý obrázek nabízeného materiálu (#product). Kromě cesty k vlastnímu obrázku obsahuje také popis a informace o jeho účelu.
Prod_version Typ: kernel Entita (#prod_version) představuje určitou verzi produktu; obsahuje stručný (často jednoslovný nebo heslovitý) popis odlišnosti a nese informace o velkoobchodních cenách a vlastnostech různých variant
20
produktů. Jeden produkt má jednu nebo více různých variant. Evidují se zde zejména odlišnosti povrchových úprav, různé rozměry podlahových dílců, ale i kvalitativní odlišnosti týkající se vzhledu.
Prod_version_has_property Typ: associative Entita (#prod_version_has_property) – „varianta má vlastnost“ –
je vazební entitou mezi verzí
produktu (#Prod_version) a vlastností (#Property). Vazba nese informaci o hodnotě dané vlastnosti u dané varianty produktu. Tak je správci umožněno zadat ke každému produktu libovolný počet vlastností při zachování možnosti třídění či vyhledávání podle nich.
Operation Typ: kernel
Entitou (#Operation) je každý výkon spojený s instalací některé součásti podlahy. Entita obsahuje název, marketingový popis činnosti a detailní popis pracovního postupu pro podlaháře. Sub_operation Typ: associative
Entita (#sub_operation) reprezentuje vazbu mezi rodičovskou a dceřinnou činností (#operation). Umožňuje tak definovat fakt, že daný úkon se skládá z několika dílčích prací a zároveň lze použít jednu činnost jako součást více nadřazených postupů. Podrobnost dělení na dílčí pracovní procesy záleží na správci katalogu. Required_operation Typ: kernel Entita (#required_operation) umožňuje propojení varianty materiálu s činností nutnou k jeho správné instalaci. Nejedná se však o slabou entitu. Vlastní identifikace je nutná pro další větvení a sestavení logického výrazu reprezentujícího všechny možná konfigurace.
Retail_price Typ: kernel
Entita (retail_price) přesdstavuje maloobchodní cenu dané varianty materiálu (Prod_version), nebo činnosti (Operation) u daného maloobchodníka (Dealer). Podle využití entiy se zdá, že by měla být slabou entitou. Vzhledem k tomu, že nikdy nejsou propojeny všechny entity, nelze použít identifikující vazby a entita (#retail_price) tedy musí mít vlastní identifikaci. Project Typ: kernel
21
Entita (#Project) je každý, v systému vytvořený, i započatý návrh podlahy. Nese informaci o použitých součástech (varianta) a činnostech spojených s jejich instalací. Celkovou cenu projektu počítá systém v závislosti na (ne)existenci propojení projektu s maloobchodním dodavatelem. Nezná-li jej, vyhledá a započte nejnižší maloobchodní cenu každé položky materiálu. V případě výběru podlaháře, kdy chce zákazník vidět jeho cenu, nebo je-li již podlahář vybrán, je nutné brát v úvahu jeho ceník. Toto zajišťuje pohled project_dealer_prices:
create view project_dealer_prices (dealer_id, project_id, price) as select retail_price.dealer_id as dealer_id, project_has_prod_version.project_id, sum(retail_price.price*project_has_prod_version.amount) as price from retail_price, prod_version, project_has_prod_version where retail_price.prod_version_id=prod_version.id and prod_version.id=project_has_prod_version.prod_version_id group by project_id, dealer_id;
Project_order Typ: kernel
Entita (#project_order) reprezentuje objednávku pokládky podlahy koncového zákazníka. Entita samotná nese pouze základní informace o objednávce jako je datum a čas jejího předání systému a libovolnou textovou informaci od klienta. Cizími klíči se odkazuje na zákazníka a prodejce. Project_has_prod_version Typ: associative
Entita (#Project_has_prod_version) je vazební entitou mezi entitami (#Project) a (#Prod_version). Indikuje použití určitého množství materiálu projektem včetně aktuální ceny. Ta se mění podle aktuální ceny dané verze produktu až do objednání díla. Project_has_operation Typ: associative Entita (#Project_has_operation) tvoží vazbu mezi (#Project) a (#Operation). Vyjadřuje tedy fakt, že daná činnost je součástí daného projektu. Vazba je ohodnocenáaktuální cenou a kvantitou práce. Zpravidla tedy jde o obsah nebo obvod místnosti. Tato informace se ukládá pro jednodušší pozdější zpracování.
Manufacturer Typ: kernel
22
Entitou (#Manufacturer) je každý výrobce dodávající dovozci jakýkoli materiál evidovaný v systému. Entita uchovává název výrobce a jeho webovou adresu. Po přidání dalších atributů je možné implementovat tisk objednávek.
WS_order Typ: kernel Entita {#WS_order) reprezentuje velkoobchodní objednávku od podlaháře dovozci. Podobně jako objednávka projektu eviduje datum podání, variabilní symbol apod.
WS_price Typ: associative Entita (#ws_price) je vazební entitou mezi variantou produktu (#prod_version) a skupinou dealerů (#dealer_group). Značí cenu daného výrobku (přesněji jeho verze) pro danou kategorii obchodníků. Namísto této vazební entity se nabízí nastavení marže pro každou skupinu obchodníků a následné dopočtení cen. Toto řešení však dává dovozci více volnosti v určování cen.
3.1.3 Relace mezi entitami Ref. 1 Adresy (#address) dané osoby (#person) / 1,1:1,M
Ref. 2 Daná osoba (#person) je dealerem (#dealer) / 1,1:0,1
Ref. 3 Prodejci (#dealer) patřící do dané cenové skupiny (#dealer_group) / 0,M:1,1
Ref. 4 Daná osoba (#person) je koncovým zákazníkem (#client) 1,1:0,1
Ref. 5 Velkobchodní objednávky (#WS_order) dané osoby (#person) / 0,M:1,1
Ref. 6 Velkoobchodní objednávky (#WS_order) pro daného dealera (#dealer). / 0,M:1,1
23
Ref. 7 Objednávky (#project_order) daného klienta (#client) / 0,M:1,1
Ref. 8 Objednávky (#project_order) pro daného MO prodejce (#dealer) / 0,M:1,1
Ref. 9 Maloobchodní ceny (#retail_price) daného prodejce (#dealer) / 0,M:1,1
Ref. 10 Projekty podlah (#project) realizované na dané adrese (#address) / 0,M:1,1
Ref. 11 Ceny (#retail_price) dané činnosti (#operation) – cenové nabídky jednotlivých podlahářů / 0,M:0,1
Ref. 12 Projekty (#project) objednané v rámci jedné objednávky (#project_order) / 1,M:0,1
Ref: 13 Kombinace prací (#required_operation), jejichž součástí je daný postup (#operation) / 0,M: 0,1
Ref. 14 Kombinace pracovních postupů (#required_operation), jejichž povinnou součástí je daná kombinace (#required_operation). Jde o výše uvedenou „AND“ vazbu. / 0,1:0,M
Ref. 15 Kombinace pracovních postupů (#required_operation), jejichž volitelnou součástí je daná kombinace (#required_operation) / 0,1:0,M
Ref. 16 Maloobchodní ceny (#retail_price) dané varianty produktu (#prod_version) / 0,M:1,1
Ref. 17 Vazaba mezi nutnou činností (#required_operation) a verzí produktu (#prod_version) odkazuje na reprezentaci potřebného postupu instalace daného materiálu. Nabízí se zde úvaha, zda není třeba vazna o kardinalitě M,N; může být totiž třeba více prací. Podobní případy však je schopna zaevidovat sama entita (#required_operation). / 0,1:1,M
24
Ref. 18 Výrobce (#manufacturer) daného materiálu (#product) / 1,1:0,M
Ref. 19 Obrázky (#image) daného materiálu (#product) / 0,M:1,1
Ref. 20 Varianty (#prod_version) daného materiálu (#product) / 1,M:1,1
Ref. 21 Kategorie (#category) daného materiálu (#product) / 1,1:0,M
Ref. 22 Podkategorie (#category) dané kategorie (#category) / 0,M:0,1
4 Realizace systému 4.1 Programové vybavení na úrovni databáze Jako databázový systém bylo zvoleno řešení s otevřeným kódem, Firebird2 verze 1.5, který vychází z komerčních systémů InterBase. Díky tomu je celý IS snadno přenositelný na tyto databázové servery. Server Firebird podporuje užitečné moderní postupy, jako jsou vnořené výběry, procedurální SQL (PL/SQL) včetně triggerů a v neposlední řadě generátory primárních klíčů. Na úrovni databáze je implementována většina komponent, které provádějí složitější postupy na skupinách několika tabulek. Tím je zajištěno, že jednotlivé objekty aplikační vrstvy přistupují pouze k jedné nebo dvěma úzce souvisejícím entitám. To bude výhodou v případě změny atributů těchto entit, poněvadž se dotkne jen malé části aplikace. Na této úrovni probíhá zejména kontrola a úprava některých uživateli zadaných dat, jako je např. množství materiálu nebo rozsah prací v závislosti na parametrech místnosti, případně kombinace postupů instalace.
Aktuální ceny materiálu objednaného v rámci projektu zaručuje spoušť ASSIGN_PRICE, které sleduje vklady a úpravy na entitě (#Project_has_prod_version). Je-li již určen maloobchodní dodavatel, je nutné brát v úvahu jeho ceník. V opačném případě je pomocí pohledu project_dealer_prices vybrán obchodník s nejnižší cenou projektu v editované relaci a dále pokračuje stejně jako v případě předem určeného maloobchodníka. SET TERM ^ ; CREATE TRIGGER ASSIGN_PRICE ACTIVE before INSERT OR UPDATE POSITION 1 2 [9]
25
AS declare variable rPrice numeric(9,2); declare variable projectOrderId integer; BEGIN for select project.project_order_id from project where id=new.project_id into :projectOrderId do begin if (:projectOrderId is null) then begin for select min(retail_price.price) from retail_price where operation_id is null and prod_version_id=new.prod_version_id into :rPrice do new.price = :rPrice; end else begin for select retail_price.price from retail_price where dealer_id=( select project_order.dealer_id from project_order, project where project.project_order_id=project_order.id and project_order.status=0 and project.id=new.project_id ) and operation_id is null and prod_version_id=new.prod_version_id into :rPrice do new.price = :rPrice; end end new.price=:rPrice; END^ SET TERM ; ^
Další trigger, CHECK_AMOUNT, kontroluje, případně opravuje množství použitého materiálu. U některých materiálů, jako jsou podlahové krytiny, lišty či podložky, je v kategorii (#Category) zadán způsob výpočtu množství (viz výše). Podle těchto pravidel spoušť může dopočítat množství podle parametrů díla, nebbo je nechat na volbě klienta. SET TERM ^ ; CREATE TRIGGER check_amount FOR project_has_prod_version ACTIVE before INSERT POSITION 1 AS declare variable useable integer; declare variable isTract smallint; declare variable isGirt smallint; declare variable amount integer; BEGIN for select category.amount_usable, category.tract, category.girt from category, product, prod_version where prod_version.id=new.prod_version_id and prod_version.product_id=product_id and product.category_id=category.id into :useable, :isTract, isGirt do begin if (:useable = 2) then begin -- calculate uasing project's tract if (:isTract>0) then begin for select cast((width*roomlength+0.4999) as integer) from project where id=new.project_id into :amount do new.amount = :amount; end else if (:isGirt>0) then begin for select cast((2*(width+roomlength)+0.4999) as integer) from project where id=new.project_id into :amount do new.amount = :amount; end end end END^
26
SET TERM ; ^ To, zda jsou vybrány všechny potřebné kroky instalace ověřuje metoda is_installed() mající za parametr identifikátor záznamu v tabulce required_operation. Metoda rekurzivně volá sebe sama podle následujícího předpisu:
4.2 Aplikační vrstva v prostředí JavaBeans Objektový model JavaBeans3 umožňuje komponent v prostředí jazyka Java. Objektem modelu JavaBeans je třída, která splňuje určité programové konvence definované ve specifikaci aplikačního rozhraní4. Třemi nejdůležitějšími prvky JavaBeans jsou z vnějšího kódu přístupné vlastnosti, veřejné metody a události, které objekt vyvolává. Vlastnost je pojmenovaný atribut objektu, který může být čten nebo měněn voláním k tomu určených metod. Jedná se o metodu zápisu (setter method) a metodu čtení (getter method). Z anglických označení metod plyne konvence pro jejich pojmenování, kdy před název odpovídající vlastnosti přidáváme předponu get, set nebo is, která se používá u metod pro čtení atributů booleovského typu. Máme-li tedy např. atribut name, nastavíme jej metodou setName() a jeho hodnotu zjistíme metodou getName().
4.2.1 Objektová hierarchie Celá aplikační vrstva systému je rozdělena do objektů, které více či méně odpovídají reálným objektům zúčastněným v procesu návrhu a realizace podlah. Členění objektů většinou kopíruje entity datového modelu. Optimální případ nastává, pokud každý objekt aplikace pracuje právě nad jednou entitou. Tento přístup však značně omezuje využití široké škály funkcí nabízené moderními databázemi. Z tohoto důvodu bylo nutné vytvořit objekty, které pracují nad několika málo entitami v databázi. Často se jedná o třídu pracující nad jedinou základní entitou, přičemž tato třída má potomky rozšiřující její funkce o operace nad vazbami. Podle tohoto modelu byla vytvořena např. třída UsedVersion jako potomek třídy Version implementující možnosti použít určitou variantu materiálu v projektu. Při vývoji aplikací v jazyce Java je dobrým zvykem členit třídy tematicky do tzv. balíků (packages). Tím je dosaženo přehlednosti větších programových celků, mimoto je díky balíkům možná snadná distribuce celých aplikací i jejich částí. Pro zkrácení budu v textu vypisovat jen vlastní názvy jednotlivých balíčků, název včetně nadřazeného balíku name.webdeveloper uvádím pro úplnost v popisu obrázků. 3 [2] 4 [7]
27
Obrázek č.6: balík name.webdeveloper.order Balík order obsahuje důležité třídy nutné k vytvoření objednávky projektu a práci s ní. Může se zdát nelogické, že obsahuje také samotnou třídu Project, ta je však základem samotné objednávky. Třída Project3D rozšiřuje Project o atributy, které nejsou důležité pro samotnou pokládku, ale jsou třeba k přesnější vizualizaci. Jedná se o výšku místnosti a barvu stěn. Třída Project3D dále poskytuje některé funkce nutné pro co nejvěrnější náhled výsledné podlahy, jako je počet opakování textury podle rozměrů podlahového dílce apod. Třída UsedVersion obsluhuje vazbu mezi variantou materiálu a projektem v němž je použita. Jak již bylo zmíněno, jedná se o potomka třídy Version, která je však v balíku catalogue. Mimo tříd reprezentujících objekty reálného světa je vhodná třída ProjectLister používaná k výpisu projektů splňujících určitá kritéria, jimiž je nejčastěji příslušnost k sezení, zákazníkovi nebo objednávce. Tato a jí podobné třídy zajišťují, aby jednou instancí vytvářené objekty nezavíraly výsledkové sady z databáze otevřené mateřskou instancí. Toto uzavírání totiž předepisuje specifikace rozhraní JDBC5.
Obrázek č.7: balík name.webdeveloper.catalogue Balík catalogue poskytuje potřebné komponenty k procházení katalogu, kategorizaci produktů (materiálů) a vyhledávání. Nejdůležitějšími součástmi jsou třídy reprezentující produkty, 5 [12]
28
jejich verze a vlastnosti, dále pak objekty ke kategorizaci, jako jsou Category nebo Manufacturer.
Obrázek č. 8: balík name.webdeveloper.person Jak již název napovídá, děje týkající se uživatelů obsluhují třídy obsažené v balíku user. Jeho základem je třída person, reprezentující obecně kteroukoli osobu používající systém. Osoba může být navíc klientem nebo dealerem. Podobně jako na úrovni databáze, další rozdělení uživatelů (správce katalogu a dodavatel materiálu), je realizováno pomocí atributů.
Obrázek č. 9: balík name.webdeveloper.service Balík service nabízí komponenty obsluhující pracovní postupy při pokládce podlahových krytin. Třída Operation reprezentuje jeden postup, včetně odkazů na jeho dílčí práce, které jsou opět reprezentované instancemu uvedené třídy. Neméně důležitá je třída Node, která tvoří základ (uzel) logického výrazu reprezentujícího kombinaci nutných a volitelných dílčích postupů instalace daného materiálu Metoda is_installed(), uvedená v kapitole věnované aplikační logice na straně databáze, je reprezentována metodou isInstalled() v objektech Node a Version, odkud je pro dosažení vyššího výkonu volána. Je zřejmé, že metoda Version.isInstalled() volá stejnojmennou metodu kořenového uzlu, na nějž odkazuje atribut requiredOperationID. Pomocí funkce Node.isInstalled() je vhodné zákazníkovi během přípravy objednávky znázornit, zda a které povinné operace již zvolil.
29
4.3 Vizualizace Vzhledem k tomu, že rozhraní webových stránek bylo původně navrženo k šíření informací v textové podobě, případně formou dvojrozměrných obrázků, zdálo se přání, umožnit zákazníkovi nahlédnout na vytvářený projekt, značně obtížné. Jistou nadstavbu nabízí jazyk VRML6 (z anglického Virtual Reality Modelling Language). Jedná se o normu ISO (specifikace ISO/IEC 14772-1:1997) pro popis statických i dynamických světů. Nabízí se také novější jazyk X3D7, vybudovaný na základě značkovacího jazyka XML.
Obrázek č. 10: jednoduchá ukázka vizualizace Ke zběžné demonstraci a odzkoušení možností byl vytvořen jednoduchý JSP skript generující VRML kód, který zobrazí náhled navrhované podlahy. VRML skripty je možné zobrazit například pomocí programů Cortona VRML Client nebo Cosmo Player, který však dnes již není výrobcem podporován.
5 Závěr 5.1 Přínos práce V rámci této práce byl navržen velmi robustní informační systém, jenž je využitelný nejen k podpoře prodeje podlahových krytin, ale s jistými úpravami i v dalších oblastech zakázkové výroby. Byl taktéž vytvořen základ vlastní aplikace, který poskytuje důležitou podporu pro koncové zákazníky. Umožňuje jim vytvořit si model místnosti, v níž chtějí novou podlahu, poskytne jim kalkulaci s ohledem na zvolené materiály, jejich instalaci a úpravy.
5.2 Možnosti rozšíření Přímo se nabízí dodatečná implementace těch funkcí, které byly z časových důvodů odloženy. Patří k nim zejména rozhraní pro správu katalogu nebo doplnění a vylepšení dosavadních uživatelských rozhraní z důvodu lepší uživatelské přítulnosti. 6 [4] 7 [10]
30
Integraci systému by přispěla například podpora automatizovaného tisku objednávek materiálu pro výrobce. Tato funkce je realizovatelná přidáním atributů, případně připojení jediné entity do E-R diagramu (to pokud by měl výrobce více provozoven nebo odběrných míst). Mnozí zákazníci by jistě uvítali možnost vytvářet projekty složitějších tvarů, mnohdy i nepravoúhlých. Na úrovni aplikační logiky by ani toto neměl být velký problém, avšak povaha systému postaveného na bázi webu značně stěžuje, ne-li znemožňuje návrh složitých tvarů.
6 Použité informační zdroje 6.1 Literatura [1] RNDr. Marie Duží, Csc., Konceptuální modelování - datový model HIT [2] Barry Burd, JSP Java Server Pages - Podrobný průvodce [3] Pavel Císař, InterBase a FireBird - Tvorba, administrace a programování databází [4] Jiří Žára, VRML97 – laskavý průvodce virtuálními světy
6.2 Internetové zdroje [5] http://www.sei.cmu.edu/domain-engineering/context_diag.html [6] http://www.agilemodeling.com/artifacts/dataFlowDiagram.htm [7] http://java.sun.com/products/javabeans/docs/spec.html [8] http://www.fi.muni.cz/~racek/vyuka/ananas/an_03_dfd.pdf [9] http://www.firebirdsql.org [10] http://www.web3d.org/x3d/specifications/x3d/ [11] http://www.parallelgraphics.com/products/cortona/ [12] http://java.sun.com/products/jdbc/download.html#corespec30
31
7 Přílohy Obrázek č. 1: Kontextový diagram
32
Obrázek č. 2: Diagram datových toků (DFD)
33
Obrázek č. 5: Entitně-relační model
34
Metoda is_installed() SET TERM ^ ; CREATE PROCEDURE is_installed (node_id int, p_id int) RETURNS (installed int) AS DECLARE VARIABLE op_id int; DECLARE VARIABLE i int; DECLARE VARIABLE j int; BEGIN i=0; installed=0; for select operation_id from required_operation where id=:node_id into :op_id do begin if (op_id is not null) then begin for select count(*) from project_has_operation where project_id=:p_id and operation_id=:op_id into :i do begin if (i>0) then installed=1; else installed=0; suspend; end end else begin installed=0; j=0; for select id from required_operation where or_parent=:node_id into i do for select installed from is_installed(:i, :p_id) into :j do if (installed<j) then installed=j; installed=0; j=0; for select id from required_operation where and_parent=:node_id into i do for select installed from is_installed(:i, :p_id) into :j do if (j=0) then installed=0; suspend; end end END^ SET TERM ; ^
Trigger set_operation_price SET TERM ^ ; CREATE TRIGGER set_operation_price FOR project_has_operation ACTIVE BEFORE INSERT OR UPDATE
35
POSITION 1 AS DECLARE VARIABLE po integer; DECLARE VARIABLE new_price integer; BEGIN for select project_order_id from project where id=new.project_id into :po do begin if (po is null) then begin for select min(price) from retail_price where operation_id=new.operation_id into :new_price do new.price=new_price; END ELSE BEGIN for select price from retail_price where operation_id=new.operation_id and dealer_id=( select dealer_id from project_order where id=:po ) into :new_price do new.price=new_price; end end END^ SET TERM ; ^
Metoda root_category Tato metoda vrací identifikátor kořenové kategorie za účelem dědění parametrů pro výpočet množství materiálu, ověření přítomnosti materiálu omezeného na jeden typ v projektu SET TERM ^ ; ALTER PROCEDURE ROOT_CATEGORY ( MY_ID Integer ) RETURNS ( CAT_ID Integer ) AS declare variable CAT1 int; BEGIN for select category_id from category where id=:MY_ID into :CAT1 do begin if (CAT1 is not null) then execute procedure root_category CAT1 returning_values CAT_ID; else CAT_ID=MY_ID; end suspend; END^ SET TERM ; ^
36
Třída name.webdeveloper.order.UsedVersion package name.webdeveloper.order; import name.webdeveloper.catalogue.*; import name.webdeveloper.*; import java.sql.SQLException; import java.sql.ResultSet; /** * This class extends basic Version providing methods * which enable client to
use a material within a project. * * @author Antonín Klein
* @version 27. 12. 2006 */ public class UsedVersion extends Version { private int projectId=0; private int count; private float price; private boolean editted=false; /** * Constructor without parameters should * be used especially to list through * a set of UsedVersion's identificators. * In this case, setId() and setProjectId() should be used. */ public UsedVersion() { super(); } /** * this constructor is used while adding * @param vid version's ID * @param pId project's ID */ protected UsedVersion(int vid, int pId) { super(vid); setEditted(true); setProjectId(pId); } /** * sets the project's identificator */ public void setProjectId(int pId) { projectId=pId; synchronize(); } /** * sets the identificator of the Version */ public void setId(int i) {
37
super.setId(i); synchronize(); } public void resetDefaults() { super.resetDefaults(); projectId=0; count=0; price=0; } private void synchronize() { if ((getId()>0) && (getProjectId()>0)) { // we can identify relation if (parametersSet() && isEditted()) { // mandatory vars are set and object's been editted writeToDB(); }; loadFromDB(); } // else we cannot identify the relation, so we cannot do anything. } /** * @return true if the mandatory parameters are set * the object can be stored then */ public boolean parametersSet() { return ((super.parametersSet()) && (getProjectId()>0)); } private void writeToDB() { ResultSet rs = db.executeQuery("select count(*) as cnt from project_has_prod_version"+ " where project_id="+getProjectId()+" and prod_version_id="+getId()); try { if ((rs!=null) && (rs.next()) && (rs.getInt("cnt")>0)) { // exists, update amount, ... (price will be updated by trigger) db.executeUpdate("update project_has_prod_version set amount=" +getCount()+" where prod_version_id="+getId()+" and project_id="+getProjectId()); } else { db.executeUpdate( "insert into project_has_prod_version "+ "(project_id, prod_version_id, amount) "+ "values ("+getProjectId()+", "+getId()+", "+getCount()+")"); } setEditted(false); } catch (SQLException e) { e.printStackTrace(); }
38
} private void loadFromDB() { ResultSet rs = db.executeQuery("select * from project_has_prod_version"+ " where prod_version_id="+getId()+" and project_id="+getProjectId()); try { if ((rs!=null) && (rs.next())) { count=rs.getInt("amount"); price=rs.getFloat("price"); } } catch (SQLException e) { e.printStackTrace(); } } public boolean isUsedBy(int pId) { ResultSet rs = db.executeQuery( "select count(*) as cnt from project_has_prod_version "+ "where project_id="+pId+" and prod_version_id="+getId()); try { if ((rs!=null) && (rs.next())) { return (rs.getInt("cnt")>0); } } catch (SQLException e) { e.printStackTrace(); } return false; } /** * @return identificator if the project current UsedVersion is used by */ public int getProjectId() { return projectId; } private void setEditted(boolean e) { editted=e; } public boolean isEditted() { return editted; } protected void resetPrice() { price=getPrice(); } protected void setCount(int newCount) { count=newCount; setEditted(true); synchronize(); }
39
/** * @return * used in */ public int return }
amount of the material (represented by UsedVersion) a project set by setProjectId() lastly getCount() { count;
}
40
