Sem vložte zadání Vaší práce.
České vysoké učení technické v Praze Fakulta informačních technologií Katedra softwarového inženýrství
Bakalářská práce
Informační systém pro realizaci obchodně-technických nabídek strojů Filip Měšťánek
Vedoucí práce: Ing. Jan Kunert
13. května 2013
Poděkování Rád bych poděkoval Ing. Janu Kunertovi za podnětné rady a připomínky při vedení mé bakalářské práce.
Prohlášení Prohlašuji, že jsem předloženou práci vypracoval samostatně a že jsem uvedl veškeré použité informační zdroje v souladu s Metodickým pokynem o etické přípravě vysokoškolských závěrečných prací. Beru na vědomí, že se na moji práci vztahují práva a povinnosti vyplývající ze zákona č. 121/2000 Sb., autorského zákona, ve znění pozdějších předpisů, zejména skutečnost, že České vysoké učení technické v Praze má právo na uzavření licenční smlouvy o užití této práce jako školního díla podle § 60 odst. 1 autorského zákona.
V Praze dne 13. května 2013
.....................
České vysoké učení technické v Praze Fakulta informačních technologií c 2013 Filip Měšťánek. Všechna práva vyhrazena.
Tato práce vznikla jako školní dílo na Českém vysokém učení technickém v Praze, Fakultě informačních technologií. Práce je chráněna právními předpisy a mezinárodními úmluvami o právu autorském a právech souvisejících s právem autorským. K jejímu užití, s výjimkou bezúplatných zákonných licencí, je nezbytný souhlas autora.
Odkaz na tuto práci Měšťánek, Filip. Informační systém pro realizaci obchodně-technických nabídek strojů . Bakalářská práce. Praha: České vysoké učení technické v Praze, Fakulta informačních technologií, 2013.
Abstract The aim of this thesis was to design and implement an information system that could use a few simple steps to create a business proposition. The system consists of two independent applications. The first is administrative, which manages the database of products and their prices, and the other can build a commercial offer of the products offered to end-users. The application is written in C# with help of Winforms framework. Keywords Commercial offers creation, information system, price calculation, Winforms, C#
Abstrakt Cílem této bakalářské práce bylo navrhnout a implementovat informační systém, který by dokázal pomocí několika jednoduchých kroků vytvořit obchodní nabídku. Systém se skládá ze dvou nezávislých aplikací. První je administrativní, ve které se spravuje databáze produktů a jejich cen, a ix
ve druhé již koncový uživatel může sestavit obchodní nabídku z nabízených produktů. Aplikace je psaná v jazyku C# s pomocí Winforms frameworku. Klíčová slova Tvorba obchodních nabídek, Informační systém, Kalkulace cen, Winforms, C#
x
Obsah Úvod
1
1 Popis aplikace
3
2 Požadavky a cíle 2.1 Flexibilita správy dat . . . . . . . . . 2.2 Rozložení produktu na podprodukty 2.3 Práce s více měnami . . . . . . . . . 2.4 Vícejazyčnost . . . . . . . . . . . . . 2.5 Vytváření nabídek . . . . . . . . . . . 2.6 Intuitivní rozhraní . . . . . . . . . .
. . . . . .
5 5 5 6 6 6 6
. . . . . .
9 9 10 11 12 15 18
. . . . . .
. . . . . .
3 Analýza a návrh 3.1 Programovací jazyk . . . . . . . . . . . . 3.2 Technologie . . . . . . . . . . . . . . . . 3.3 Uložiště dat . . . . . . . . . . . . . . . . 3.4 Uživatelské rozhraní . . . . . . . . . . . 3.5 Uživatelské rozhraní administrativní části 3.6 Objektový návrh . . . . . . . . . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
4 Realizace 23 4.1 Grafické prostředí tvorby opcí . . . . . . . . . . . . . . . . . 23 4.2 Serializace dat . . . . . . . . . . . . . . . . . . . . . . . . . . 24 4.3 Vytváření nabídky . . . . . . . . . . . . . . . . . . . . . . . 25 5 Testování
27 xi
Závěr
29
A Seznam použitých zkratek + vysvětlivky
31
B Obsah přiloženého CD
33
C Instalační příručka
35
D Uživatelská příručka
37
E Administrativní příručka
39
xii
Seznam obrázků 3.1 3.2 3.3 3.4 3.5 3.6
Uživatelské rozhraní aplikace Vlastnosti produktu . . . . . Diagram MLString . . . . . . Diagram ItemModel . . . . . Diagram ItemOption . . . . . Diagram Currency . . . . . .
. . . . . .
. . . . . .
. . . . . .
14 17 18 19 20 21
4.1
Opce produktu . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
xiii
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
. . . . . .
Úvod V době, kdy člověk začíná podnikat a zakládá firmu, je jeho portfolio produktů poměrně malé a tudíž je schopen udržet většinu informací jen ve své paměti. S tím jak firma roste, rozšiřuje se i sortiment výrobků a zvyšuje počet nabídek. Pokud společnost nepoužívá žádný software na správu nabízených produktů, může nastat chaos. Tomuto bychom rádi předešli např. v odvětví vodních technologií, kde se každý stroj skládá z desítky různých polotovarů a zároveň nabízí spoustu možností jeho uzpůsobení. V této fázi může být velmi složité kalkulovat cenu konečného produktu, protože není v lidských možnostech určit částku pro každou možnou existující kombinaci stroje. Někdy se může stát, že se stroj i nevědomě prodává pod jeho skutečnou hodnotou. Aby se tomuto zamezilo, začala vznikat tato aplikace, která funguje na jednu stranu jako kalkulační program, který dokáže vypočítat cenu každého produktu v jeho všech existujících mutacích, a zároveň dokáže vytvořit obchodní nabídku na nabízené produkty.
1
Kapitola
Popis aplikace Jak již bylo v úvodu zmíněno, aplikace by měla sloužit k vytváření obchodních nabídek. Součástí programu je databáze existujících produktů, které firma nabízí. Každý produkt má svoji základní cenu a zároveň může poskytovat spoustu možností navíc, jak si ho uzpůsobit. Nejlepší analogie by se dala představit u aut, kde každé auto má svou základní cenu, ale zároveň se může zákazník rozhodnout, jestli chce mít klimatizaci navíc či místo klasických sedaček sedačky kožené. Cílovou skupinou tohoto programu jsou obchodní zástupci firmy, kterým by měl tento program velmi usnadňovat tvorbu nabídky pro potenciální zákazníky. Obchodník pomocí GUI v několika krocích vybírá produkty, které dává do virtuálního košíku, jako to je běžné v internetových obchodech. Pokud je obchodník spokojen, může výběr potvrdit a jedním stisknutím tlačítka se mu vygeneruje nabídka ve formátu doc, který může ještě dále podle svého upravovat. Samozřejmostí je možnost přidat ke každému produktu či celkové nabídce slevu. Výhoda aplikace spočívá v tom, že odstiňuje obchodníka od všech výpočtů – všechno za něj dělá aplikace, tím pádem může nabídku vytvářet i méně zkušený člověk. Druhou předností je, že aplikace eliminuje chyby lidského faktoru. Těmi může být špatné určení ceny či přepočítání se, nebo např. špatně vyplněné rozměry v nabídce. Protože systém pracuje s databází produktů, bylo třeba vytvořit i aplikaci, která by ji dokázala spravovat. Mezi její základní funkce patří samozřejmě přidávání a mazání produktů, měnění jejich názvů a cen. Ke každému produktu lze přiřadit ikonu, která ho pak v seznamu reprezentuje. Mezi pokročilou funkci aplikace patří okno vlastností, ve kterém se spravují opce produktu. V aplikaci jsou podporovány 3 druhy opcí: 1. Check Box – dává nám na výběr mezi několika nezávislými prvky. Nemusí být vybraný žádný, ale zároveň můžou být vybrány všechny 3
1
1. Popis aplikace zároveň. Jako příklad jsou přídavné moduly k softwaru. Zákazník si může objednat čistý software bez modulů, ale zároveň má možnost si jakýkoliv modul nezávisle vybrat. 2. Radio Button – slouží k vybrání jedné možnosti z několika. Vždy musí být právě jedna možnost zvolená. Jako když například vybíráme barvu klávesnice, může být bílá nebo černá, nic mezi. 3. Combo Box – je úspornější varianta Radio Buttonu. Používá se častěji při větším počtu možností. V aplikaci jsou u této opce podporovány pouze číselné hodnoty, slouží tedy např. k výběru rozměrů stolu. Stejně jako produkty, tak i opce lze přidávat, mazat či upravovat. Ke každé opci pak můžeme přiřadit polotovary, ze kterých se tato skládá, a tím se i určí její výsledná hodnota. Většina opcí funguje nezávisle na sobě, některé však mají speciální význam. Například podle velikosti stolu (opce X a opce Y) se vypočítá celková plocha, která se předá jiné opci, která počítá hodnotu pomocí rozměrů m2 stolu. Úprava opcí probíhá také za pomoci GUI, je tedy celkově srozumitelná a intuitivní.
4
Kapitola
Požadavky a cíle 2.1
Flexibilita správy dat
Na tento bod byl kladen největší důraz. Protože trh je neustále v pohybu, je třeba reagovat rychle na jakékoliv jeho změny. Ceny jak od dodavatelů, tak prodejní se neustále mění a proto vzniká potřeba upravit i výslednou cenu dle aktuální situace. Vyvíjejí se nové produkty a zároveň staré zanikají. To nám klade jisté nároky na naši aplikaci. Přidat nějaký produkt či změnit jeho cenu by mělo být velmi jednoduché. Zároveň by měla být data co nejtransparentnější a měla by zobrazovat co nejvíce informací, aby se předešlo možným chybám lidského faktoru.
2.2
Rozložení produktu na podprodukty
Každý výsledný produkt se může skládat z dalších produktů – v aplikaci nazývaných jako polotovary. Jmenovitě např. čerpadlo se může skládat z rámu, motoru, multiplikátoru, elektrických součástek a kabeláže. Celková částka produktu se určí součtem všech jeho polotovarů. Toto umožnuje jednodušší reagování na změnu ceny, kde se nemusí sledovat cena celého produktu ale pouze jeho částí. Zároveň to je výhodné, pokud několik produktů sdílí stejný polotovar. Změna jeho ceny se projeví ve všech produktech, ve kterých je obsažen. Jak již bylo zmíněno, každý produkt může obsahovat další možnosti jeho uzpůsobení – opce. A každá opce je v aplikaci reprezentována jako produkt, tím pádem se také může skládat z libovolného počtu polotovarů. 5
2
2. Požadavky a cíle
2.3
Práce s více měnami
Protože jde o program, který by se měl používat i za hranicemi České republiky, je nezbytné pracovat s více měnami než korunou českou. Mezi měny se kterými aplikace umí aktuálně pracovat, patří česká koruna, dolar, euro a rubl. Cena jakéhokoliv polotovaru se dá zadat ve výše zmíněných měnách, to nám zaručuje cenovou flexibilitu vzhledem k neustálému pohybu kurzu měn. Protože se všechny materiály nejdříve kupují do Čech, kde se z nich montují stroje a až pak se zase posílají do zahraničí, je třeba všechny měny nejdříve přepočítat na Kč a pak zase třeba na jiné zahraniční měny. V aplikaci se dá také ke každé měně ještě nastavit procentuální přirážka, která reprezentuje clo nebo dovoz do České republiky. Při vystavování obchodní nabídky má také uživatel možnost zvolit, v jaké měně bude nabídka vystavena.
2.4
Vícejazyčnost
Protože program bude používat mnoho zástupců z jiných zemí, měl být lokalizován do cizích jazyků. Zde se jedná samozřejmě o GUI, ale hlavně o názvy a různé popisy produktů. Pokud například vytváříme nabídku pro ruského zákazníka, chceme, aby byly výsledné názvy a popisy strojů v azbuce. Mezi různými jazyky by mělo být možné jednoduše přepínat pomocí tlačítka.
2.5
Vytváření nabídek
Aby měla aplikace nějaký smysl, musí mít odpovídající výstup. Tím je právě nabídka ve formátu doc, která se vytvoří z vybraných produktů. Součástí obchodní nabídky by měla být předmluva, která představí firmu, shrnutí a ceník nabízených produktů, ke každému vybranému produktu technická specifikaci a platební podmínky. Tvorba nabídky by měla probíhat zcela automaticky a to bez nutnosti zásahu obchodníka. Automatické vytváření nabídek by mělo jak šetřit čas, tak zamezit chybám a zároveň unifikovat vzhledy nabídek celé firmy.
2.6
Intuitivní rozhraní
Pro usnadnění orientace v aplikaci musejí být všechny její prvky zřetelně graficky vyobrazeny. Ideální stav, kterého lze dosáhnout je, aby běžný uživatel dokázal program intuitivně ovládat, aniž by četl nějaký manuál či 6
2.6. Intuitivní rozhraní příručku. Aplikace by měla obchodníka sama navádět při sestavování nabídky, aby se nestalo, že by na některý z kroků zapomněl.
7
Kapitola
Analýza a návrh 3.1
Programovací jazyk
Jako u každého programu, první zásadní věcí, která se musí rozhodnout, je zvolení nejlepšího programovacího jazyka. U některých aplikací je tento výběr vzhledem k jejich povaze jasný. U ostatních se musejí provádět analýzy vzhledem k požadavku na výkon, platformu a délku vývoje. I když se tento krok zdá nevýznamným, nesprávné určení programovacího jazyka může vést k mnohým problémům během vývoje aplikace, případně ke značnému prodloužení doby vývoje. Pro správné zvolení jazyka si musíme nejdříve definovat, jakého typu je naše aplikace a co jsou její hlavní rysy. V našem případě se jedná o informační systém. Jeho rozsah je poměrně malý, měl by pracovat maximálně s desítkami produktů. Informační systémy jsou většinou nenáročné na výkon, zvláště když nepracují s velikými obsahy dat. Mezi jejich výpočetně nejnáročnější funkce často patří vyhledávání či řazení dat. Vzhledem k velikosti našeho systému si tedy neklademe žádné nároky na výkon. Operační systémy, na kterých má systém běžet jsou pouze Windows (od Windows XP po Windows 7), to nám tedy nechává poměrně širokou možnost výběru a nelimituje nás to pouze na multiplatformní jazyky. Jazyky, které ovládám a které zároveň přicházejí v úvahu, jsou C++, C# a Java. První zmiňovaný je nejstarší a zároveň nejvíce nízko-úrovňový jazyk z těchto tří. Mezi jeho hlavní přednost patří vysoký výkon, na druhou stranu dává programátorovi moc velikou volnost, což může vést k jednoduchému vzniku mnoha chyb. Navíc tento jazyk přestává být často podporován v oblasti business aplikací kvůli jeho složitější nátuře, hodí se tedy spíše na aplikace reálného času, které vyžadují co největší výkon. Druhým zmiňovaným jazykem je C#. Jedná se o poměrně moderní a robustní jazyk 9
3
3. Analýza a návrh z dílen Microsoftu. Syntaxí je velmi podobný C++, je však zjednodušený a typově bezpečný. To umožňuje programátorovi se soustředit výhradně na programování, a nerozptylovat se věcmi okolo jako je třeba správa paměti. Rychlostně sice zaostává za C++, vývoj aplikace trvá ale nesrovnatelně méně času. V jeho prospěch mluví současně veliká popularita a spousta různých frameworků. Posledním možným jazykem byla Java. To je jazyk velice podobný C# od společnosti Oracle. Jak syntaxí, tak výkonem jsou si velmi podobné. Jeho hlavní přednost je multiplaformnost, dokáže běžet téměř na každém systému počínaje mobilními telefony po desktopové systémy. Tato výhoda pro nás ale ztrácí váhu, protože chceme pracovat pouze na systémech s Windows. A vzhledem k tomu, že náš program vytváří nabídky ve WORD formátu, určitě je lepší pro větší kompatibilitu použít jazyk od stejného výrobce kterým je C#.
3.2
Technologie
Poté, co byl vybrán programovací jazyk, přichází volba vhodných technologií. Existuje spousta dostupných frameworků a knihoven, které nám mohou velmi zjednodušit práci. Jedná se o soubor objektů a metod, které mají usnadnit vývoj v konkrétní oblasti. A navíc většinu problémů, kterými se budeme při vytváření aplikace zabývat, řešil již někdo před námi, tudíž není třeba „znovu vynalézat kolo“. Mezi standartní frameworky, které společnost Microsoft pro správu oken nabízí, paří Windows API (Win API), Windows Forms (Winforms) a Windows Presentation Foundation (WPF). Windows API je ze všech zmiňovaných nejstarší. Jedná se o nízko úrovňové rozhraní obsahující základní funkce pro správu uživatelského rozhraní. Rozhraní funguje na principu zachytávání událostí (event driven) – konkrétní uživatelské interakce generují události, které jednotlivé komponenty zachytávají a příslušně na ně reagují. Windows API už však dlouho není podporováno ze strany Microsoftu, rychle tak zastarává a práce s ním je velice složitá. Winforms je novější rozhraní které staví na bázi Win API a je součástí .NET Frameworku. Výhodou Winforms je, že není tak nízko úrovňové jako Win API, tím značně zjednodušuje a urychluje práci. Nevýhodou je, že nepodporuje standardní 3vrstvou architekturu (Model-View-Controller), protože grafické a ovládací prvky jsou spolu spjaté. Tento nedostatek řeší WPF, které rozděluje uživatelské rozhraní od aplikační logiky. Nově je jako grafický systém použito DirectX, to umožňuje vykreslování náročnějších prvků a případně 3D modelů. Vykreslování přes DirectX probíhá na grafické kartě, což velmi snižuje náročnost na procesor, ale může to být zároveň problém na počítačích s in10
3.3. Uložiště dat tegrovanými grafickými kartami či laptopy. Toto sebou přináší také ztíženou náročnost při programování. Po pečlivém uvážení jsem pro svoji aplikaci zvolil Winforms. Vzhledem k velikosti aplikace je třeba brát největší ohled na náročnost programování, mezi čímž vychází toto rozhraní nejlépe. Mezi nejnáročnější grafické elementy, které aplikace používá, patří netransformované vykreslení obrázků, není tedy třeba vyššího výkonu, který by nabízel DirectX.
3.3
Uložiště dat
K součásti každého informačního programu patří databáze dat. Mezi možnosti patří zvolení databázového systému od různých výrobců (např. nejpopulárnější jako MySQL nebo Oracle), naprogramování si vlastního způsobu ukládání dat (např. pomocí XML) nebo binární serializace dat. Výběr závisí na objemu ukládaných dat, dostupnosti databáze (přes server či jen lokálně) a samozřejmě finanční dispozici. Prvně zmiňované, databázové systémy od velkých výrobců nabízí robustní software pro správu a uchovávání dat. Tyto systémy většinou běží na nějakém serveru, odkud jsou dostupné přes internet. To zajišťuje konzistenci dat mezi všemi instancemi aplikace. Takovéto systémy využívají převážně větší společnosti, které potřebují mít kontrolu nad velkým objemem dat. Databáze se aktualizuje několikrát denně. Může se jednat například o databázi pacientů u pojišťovny či seznam účtů u internetového obchodu. Druhou možností bylo naprogramovat si vlastní algoritmy ukládání a načítání dat. Jako nejběžnější způsob by se dalo označit ukládání do formátu XML. V XML se ukládá struktura pomocí značek v textovém formátu. Zde je ukázka kódu: <produkt>
Lenovo G550 notebook 10 000 <sDPH>11 900<sDPH> <mena>Kc <po pis >Tento notebook s e v y z n a c u j e .. „produkt“ je v tomto případě jméno objektu, „název“, „typ“, „cena“ a popis jsou jeho atributy. V případě ceny se jedná o další objekt, který ob11
3. Analýza a návrh sahuje vlastní atributy. Nevýhodou této metody je, že ke každému objektu, který chceme serializovat, musíme napsat samostatný kód pro jeho načtení a uložení. S počtem objektů a atributů nám tedy výrazně roste programovací složitost. Poslední variantou byla binární serializace dat, tak jak jí podporuje překladač daného jazyka. To je metoda, při které se uloží do souboru přesně ta část programu, která je nahraná v operační paměti. Když pak soubor deserializujeme, dané objekty se obnoví přesně do stavu, ve kterém byly při serializaci. Toto všechno probíhá podle vnitřních algoritmů překladače a samostatná struktura souboru není vůbec známá. Výhodou této metody je, že každý objekt, který se má serializovat stačí pouze označit tagem „[serializable]” (v jazyce C#) a zbytek již za nás udělá překladač. Takto se také dají uložit odkazy na jednu instanci. Více produktů tedy může sdílet jednu a tu samou instanci např. objektu finanční měny, kdežto u serializace pomocí XML by se každá měna uložila jako nezávislá instance. Mezi nevýhody patří nemožnost kontroly celého procesu. Pokud budeme razantně měnit strukturu objektů, je možné, že nebudeme moci serializovaná data použít a program nám spadne na výjimce. Další nevýhodou je, že při vytváření databáze se vždy vytváří celý soubor od začátku a nepřidávají se jen ty prvky, co byly změněny. To může být problém u opravdu velkých souborů, u databáze do několika MB by to ale problém být neměl. Shrneme-li potřeby tohoto systému, jedná se o databázi s maximální velikostí desítky produktů, s průměrnou frekvencí aktualizace cca jednou za čtvrtletí. Aplikace tedy nemá žádné velké nároky na databázi, tím pádem jsem zvolil binární serializaci dat. Je to jak časově, tak finančně nejvýhodnější řešení. Databázový systém by také přicházel v úvahu, je to však zbytečné přehnané, jako „použití kanónu na komára“.
3.4
Uživatelské rozhraní
V této části proberu návrh uživatelského rozhraní aplikace a jeho ovládacích prvků. Ovládání softwaru by mělo být co nejjednodušší a nejintuitivnější. Správný návrh rozhraní je velmi důležitý, určuje totiž, jak na nás aplikace působí a tím i celkový dojem. Špatné navržení prvků může znamenat, že se ovládání aplikace stane přímo peklem. Pokud se budeme řídit výše uvedenými pravidly, tak při otevření aplikace uživatel zjistí všechny základní informace. Jedná se o údaje jako název, logo, verze programu či verze databáze. Poslední údaj je zvláště důležitý, neboť sděluje uživateli, jestli nepoužívá zastaralou verzi databáze se starými cenami, což by mohlo vést k mnoha problémům, pokud by se nabídka dostala k zákazníkovi. Po přečtení těchto informací se uživatel dostane do 12
3.4. Uživatelské rozhraní sekce, kde jsou obsaženy produkty. Ty jsou zařazeny do kategorií podle typu (stroje, čerpadla, příslušenství) a dále se rozpadají na další podkategorie (např. výkon čerpadel – 22kW, 37kW, . . . ). Každý produkt je v seznamu reprezentován svojí ikonou (pokud ji má přiřazenou), jménem v daném jazyce a základní cenou. Slovo základní je v tomto případě velmi důležité, protože jak již bylo zmíněno, každý produkt může nabízet spoustu volitelného příslušenství. Proto by se jako výchozí cena počítala varianta bez všech opcí a v nejmenších rozměrech. Po zvolení produktu se otevře další okno, kde uživatel zvolí právě dané opce a určí, kolik kusů od daného produktu chce. Po potvrzení se mu produkt v dané podobě vloží do stávající nabídky. Aby měl uživatel průběžně přehled o nabídce, je třeba nějakého seznamu, který by zobrazoval obsažené produkty v nabídce a jejich ceny. Produkty budou seřazeny podle kategorií, které se dají rozbalovat a zabalovat. Samozřejmě by také seznam ukazoval celkovou aktuální cenu nabídky. Po poklikání na některý z produktů má uživatel možnost změnit jeho opce, či ho úplně odstranit z nabídky. Když je obchodní nabídka kompletně sestavená, program vyobrazí celkovou cenu nabídky a uživatel může zadat procentuální slevu, kterou zákazníkovi na danou nabídku nabízí. Po potvrzení se otevře poslední okno, které již slouží pro generování nabídky do formátu .doc. Zde může zadat údaje jako informace o zákazníkovi, číslo nabídky či předmět nabídky, ty se mu pak vytisknou do Word dokumentu. Zde by měla být také možnost zvolení jazyka, ve kterém se má nabídka vytvořit. Ten by měl být reprezentován ikonou vlajky daného státu. Když tyto informace opět potvrdí, automaticky se mu za pár vteřin vygeneruje Word dokument, který se zobrazí. Protože aplikace pracuje s více různými měnami, jako poslední ovládací prvek bude combobox, který umožní výběr měny. Ten bude stále přítomen, abychom měli možnost změny měny při celém procesu vytváření nabídky (i kvůli informativním účelům). Zde je obrázek jednoduchého návrhu aplikace:
13
3. Analýza a návrh
Obrázek 3.1: Uživatelské rozhraní aplikace Winforms nabízí spoustu různých komponent, které nám mají usnadnit vývoj aplikace. Jedná se o komponenty, které známe z běžného používání kterýchkoliv aplikací. Není tedy třeba komponenty samostatně programovat, stačí využít existující a případně je doplnit o další funkce. Mezi jednoduché ovládací prvky, které v aplikaci využijeme, patří: TextBox Umožňuje uživateli vepsat text do políčka. Toto se dá omezit například jen pro číselný vstup při zadávání ceny. Button Klasické tlačítko, které při stisknutí vyvolá přiřazenou událost. RadioButton Kulaté tlačítko které umožňuje volbu právě jedné možnosti z mnoha. CheckBox Čtvercové tlačítko které umožňuje zaškrtnutí některé nezávislé možnosti. ComboBox Při kliknutí vyjede drop-down list, který umožní uživateli výběru jedné možnosti. Label, PictureBox Jednoduché komponenty sloužící k vykreslení textu, případně obrázku. Dále oproti těmto jednoduchým ovládacím prvkům nabízí Winforms složitější ovládací struktury. Mezi ty použitelné patří: 14
3.5. Uživatelské rozhraní administrativní části ListView Jedná se o seznam, který zobrazuje prvky a jejich vlastnosti. Zobrazování vlastností probíhá po sloupcích, v našem případě tedy můžeme vykreslit jméno produktu a jeho cenu. ListView také podporuje ikony ke každému produktu. Dále pak obsahuje několik možností zobrazení, mezi ty patří zobrazení po řádcích, dlaždicové zobrazení či zobrazení po sloupcích. Pro nás je určitě nejvhodnější zobrazení po řádcích, kde všechny prvky jsou zobrazovány pod sebou, nalevo každého prvku je ikona a vpravo od ní pokračují atributy. ListView nabízí veškerou funkcionalitu, kterou potřebujeme, není třeba nic doprogramovávat (obr. 3.1 (1)). Tento způsob zobrazení je například známý z programu Windows Explorer, který zobrazuje adresářovou strukturu, ikona reprezentuje typ souboru/adresáře a dále jsou zobrazené vlastnosti jako název souboru/adresáře, datum změny, velikost atd. TreeView Komponenta, která umožnuje zobrazení kořenového stromu. Prvky jsou rozděleny na uzly a každý uzel může mít pod sebou neomezený počet dalších uzlů. Jednotlivé uzly se dají rozbalit a zabalit, tím se skryjí/odkryjí všechny jejich potomci. Tato komponenta nám poslouží k zobrazení produktů přidaných do nabídky. Bohužel TreeView nenabízí vícesloupcové zobrazení, tato funkcionalita se musí doplnit, abychom mohli ke každému produktu či kategorii zobrazit ještě celkovou cenu (obr 3.1 (2)).
3.5
Uživatelské rozhraní administrativní části
Jak jsem již dříve uvedl, administrativní část bude fungovat jako samostatný prvek aplikace a bude sloužit za účelem spravování databáze. Tento program bude dostupný pouze interně, to nám klade menší nároky na vzhled a tím pádem ho ani není třeba lokalizovat do více jazyků. Mezi jeho funkce by mělo patřit: • přidávání/mazání produktů podle kategorií • volení podskupiny jednotlivých produktů • definování polotovarů a jejich cen • volba ikony • přiřazení souboru s dokumentací 15
3. Analýza a návrh • definování procentuální přirážky
• přidávání/mazání/upravování opcí produktu
• ke každé opci zvolení polotovarů, ze kterých se skládá
• duplikace produktu a všech jeho vlastností
• nastavování aktuálního kurzu měn ve vztahu k CZK
Vzhled administrativní aplikace by mohl být velmi podobný té uživatelské s tím, že by bylo provedeno pár změn. Místo komponenty na zobrazování souhrnu nabídky (obr 3.1 (2)) by byla tlačítka obsluhující manipulaci s produkty. Seznam produktů (obr 3.1 (1)) zůstane nezměněný. Po rozkliknutí produktu se zobrazí nabídka, kde se dají definovat jeho vlastnosti. Viz následující obrázek. Většina vlastností je popsána, není tedy třeba dalšího vysvětlení. 16
3.5. Uživatelské rozhraní administrativní části
Obrázek 3.2: Vlastnosti produktu
Komponenta (1) je správce polotovarů, ze kterých se produkt skládá. Je možné je přidávat, mazat nebo upravovat stávající. Při přidání či upravení polotovaru se otevře další podokno, ve kterém se specifikuje jeho název, cena a měna ve které je cena zadávána. Při stisknutí tlačítka (2) se nám otevře další dialogové okno, ve kterém se spravují opce daného produktu. U tohoto okna je nutné dodržet stejné grafické rozvržení opcí, které bude v uživatelské části aplikace a zároveň musí obsahovat ovládací prvky pro manipulaci s těmito opcemi. Dodržení stejného vzhledu je důležité, aby ten co databázi vytváří, věděl, jak potom ve výsledku bude vypadat. 17
3. Analýza a návrh
3.6
Objektový návrh
V této sekci bych chtěl probrat objektový návrh nejdůležitějších a nejzajímavějších objektů v aplikaci. Půjde zde o jejich atributy a metody, a zároveň o roli, kterou zastávají v celém systému. U diagramů budou schválně vynechané gettery a settery, a zároveň nezajímavé metody a konstruktory.
3.6.1
MLString
Obrázek 3.3: Diagram MLString
MLString aneb Multi-Language String slouží pro ukládání jednoho stringu do více jazyků. Jednotlivé jazyky jsou uloženy v generické kolekci Dictionary, kde klíč reprezentuje zkratku jazyka a hodnota je string v daném jazyce. Když se MLString konstruuje, je nutné, aby do konstruktoru byl předán alespoň string pokud možno v defaultním jazyce (anglickém). To slouží k tomu, aby aplikace vždy měla uložený název nejméně v jednom jazyce a nestávalo se, že namísto jména by bylo prázdné místo. K získání stringu v nějakém jazyce se zavolá metoda GetLanguageByKey a jako její parametr se použije zkratka daného jazyka, to nám vrátí string v daném jazyce, pokud je v MLString obsažen. Pokud obsažen není, zavolá se metoda GetDefaultLanguage, která se nejdříve pokusí vrátit string v jazyce anglickém, a pokud ten tam také není, vrátí to první jazyk který je v kolekci strings. Metoda GetMLString slouží pro grafické vkládání jazyků. Po aktivování se otevře dialogové okno, ve kterém můžeme zadávat vstupy ve všech aplikaci známých jazycích. 18
3.6. Objektový návrh
3.6.2
ItemModel/Item
Obrázek 3.4: Diagram ItemModel Jedná se o třídu, která reprezentuje produkt s jeho vlastnostmi. V tomto případě představuje ItemModel jakousi šablonu produktu se všemi jeho opcemi které obsahuje, a Item je jeho konkrétní instance. Zároveň Item je potomek od ItemModel. Použijeme-li opět analogii s auty, ItemModel by představoval auto v katalogu, který by nabízel, že si můžeme k němu přikoupit rámy na kola či klimatizaci. Item by pak bylo to konkrétní auto, které jsme si zvolili, například pouze s klimatizací. Při tvorbě nabídky vybíráme ze seznamu produktů typu ItemModel, když pak nějaký označíme a chceme ho přidat do stávající nabídky, vytvoří se instance typu Item kde již vybíráme konkrétní opce. Atribut group reprezentuje hlavní kategorii, do které produkt patří (stoly, čerpadla, . . . ). Ty se pak mohou rozpadat na více podkategorií, které jsou zastoupeny atributem listViewGroup. DocumentationName je jméno Word souboru, který se vloží do nabídky. To může zůstat i prázdné pokud daný produkt žádná nabídka nereprezentuje. PercentProfit je částka, kterou se násobí cena produktu. To je zde proto, že do produktu se vyplní jeho veškeré náklady a ty se pak navyšují o tuto částku, abychom obdrželi potřebný zisk. Metoda GetBaseValue vrací nákladovou cenu produktu, metoda Ge19
3. Analýza a návrh tValue vrací prodejní cenu produktu. Mezi další zajímavé atributy patří listy options a polotovary. První obsahuje seznam opcí, které daný produkt nabízí. Polotovary jsou jednotlivé části a jejich ceny, ze kterých se produkt skládá. Po sečtení všech polotovarů nám vyjde celková nákladová cena produktu. Když při vytváření nabídky chceme vložit nějaký produkt, vytvoří se instance typu Item. Ta rozšiřuje ItemModel o atributy jako je discount a pieces. První udává procentuální slevu, kterou chceme na produkt dát (ta může být od 100 do -100, pokud chceme naopak produkt zdražit). Pieces znamená počet kusů od daného produktu, který je v nabídce.
3.6.3
ItemOption
Obrázek 3.5: Diagram ItemOption 20
3.6. Objektový návrh Abstraktní třída ItemOption zastupuje volitelné příslušenství k produktům. To se dále rozkládá do několika tříd podle jejich typu. Jméno potomků je odvozeno od jména System.Windows.Forms.Component, kterou daný objekt zastupuje. Abstraktní třída zahrnuje atributy, které jsou společné pro všechny potomky. Každý potomek si pak specifikuje další atributy a metody podle jeho funkčnosti. Nejdůležitější atribut je list nazvaný polotovary, který říká, z čeho se dané příslušenství skládá a tím i určuje jeho cenu. Abstraktní metoda GetPrices vrací cenu opce podle dané situace. Například u ItemOptionCheck se vrátí aktuální cena, pokud je opce zaškrtnutá, pokud však není, vrací metoda 0. Mezi nejzajímavějšího potomka patří ItemOptionComboBox který zastupuje seznam různých opcí. Z tohoto seznamu se pak vždy vybírá pouze jedna komponenta. Seznam je uložený v listu struktur data a selectedIndex je index aktuálně zvolené komponenty.
3.6.4
Currency
Obrázek 3.6: Diagram Currency Třída reprezentující peněžní měnu. V aplikaci jsou zatím dostupné 4 měny, a ve všech se dají zadávat částky a zároveň je možné zobrazit částky do každé měny. Musíme tedy znát přepočty mezi jednotlivými měnami. To se vyřeší tím, že se všechny měny nejdříve přepočítají na koruny, a pak se přepočítávají dál. Atribut ratio je typu double, který reprezentuje vztah měny ke koruně (u koruny je to 1). AdditionalFee zahrnuje procentuální částku, která se k částce vždy připočítá. To může zastupovat jak clo, tak i třeba 21
3. Analýza a návrh dopravu. Metoda Recalculate si bere jako vstupní parametr částku v korunách a přepočítává jí do dané měny. FormatValue, jak již název napovídá, vytvoří z částky string podle pravidel dané měny.
22
Kapitola
Realizace V této kapitole se pokusím popsat a vysvětlit postupy řešení jednotlivých úseků. Nebudu zde probírat aplikaci jako celek, ale její jednotlivé části. Zaměřím se hlavně na zajímavější problémy, nebo ty, které nemají tak intuitivní řešení.
4.1
Grafické prostředí tvorby opcí
Jedná se o samostatné okno v administrativní části, ve které může uživatel upravovat opce produktů. Musí obsahovat zároveň grafické vyobrazení opcí, tak i ovládací prvky na jejich editaci. Toto byla asi největší výzva, skloubit přehlednost a funkčnost. Zde je ukázka, jak rozhraní vypadá:
Obrázek 4.1: Opce produktu 23
4
4. Realizace V levé části okna je ovládací prvek, který opce zobrazuje, a v pravé části jsou ovládací prvky k opcím. Ovládací část se vždy vztahuje k opci, která je právě zvolená. Nejdříve vysvětlím, jak probíhá zobrazení opcí (levá část obrázku). V aplikaci jsou opce každého produktu reprezentovány třídou „ItemOption“. My však z nich potřebujeme vytvořit ovládací prvky, jaké jsou na obrázku (ComboBox, CheckBox, RadioButton) aby s nimi uživatel mohl interagovat. „ItemOption“ tedy obsahuje virtuální metodu public abstract Control CreateControl () která podle typu opce vytvoří příslušnou Windows.Forms.Control a naplní ji daty. Ovládací prvek takto projede všechny opce a vytvoří z nich Control, které pak už jen vyskládá do obdélníkového tvaru. Abychom však mohli zjistit, jakou opci právě uživatel vybral, je potřeba registrovat kliknutí myší na opci. Naštěstí Control nabízí událost „Click“. Ta se spustí vždy, když uživatel na ní klikne. Ovládací prvek má atribut Control s e l e c t e d C o n t r o l který se nastaví při kliknutí na příslušnou opci. Díky tomu známe právě zvolenou opci a můžeme podle ní příslušně nastavit ovládací prvky. To už je triviální záležitost.
4.2
Serializace dat
Serializace dat probíhá tak, že se z daného objektu vytvoří proud a ten se zapíše do souboru. Do jednoho souboru se dá serializovat pouze jeden objekt, pokud tedy chceme serializovat více objektů či struktur, je třeba vytvořit nějakou strukturu, která by je obsahovala. Touto strukturou je v této aplikaci „SerializableModule“. Třída, ve které se serializace provádí, se jmenuje „SerializationModule“. Hlavním bodem, který při serializaci musíme určit je, co všechno vlastně chceme serializovat. Pokud by to bylo moc různých typů objektů, musely by se „sbírat“ po celé aplikaci a to by bylo velmi náročné. Ostatně při mnoha objektech se doporučuje serializace do více nezávislých souborů. V tomto případě budeme serializovat seznamy „ItemModel“ a „Currency“ a k tomu pak datum vytvoření databáze aby uživatel věděl, jak starou databázi používá. Vzhledem k tomu, že správce produktů a správce měn jsou statické objekty, je velmi jednoduché z nich vybrat data. 24
4.3. Vytváření nabídky
4.3
Vytváření nabídky
Důvod, proč celá aplikace vznikla je vlastní tvorba obchodní nabídky do formátu doc, to se pokusím popsat dále. Abychom mohli vůbec pracovat s Microsoft Office dokumenty, musíme přidat do referencí projektu Microsoft.Office.Interop a konkrétně pro práci s Microsoft Word Microsoft.Office.Interop.Word. To nám umožní programově přistupovat a psát do Word dokumentu. Samozřejmostí je, když chceme vytvářet nebo nějak modifikovat Word dokumenty, musí být tento na operačním systému nainstalován. Pokud Word nainstalován není, nebude možné aplikaci vůbec spustit. Když jsem se snažil studovat, jak vlastně Word knihovna od Microsoftu pracuje, moc dokumentace jsem nenašel. Na MSDN jsou popsána rozhraní tříd a k nim kratičký popis, což je vše, s čím si člověk musí postačit. Proto jsem většinu postupů získal buď z internetových poraden, nebo metodou pokus-omyl kde jsem zkoušel, jak jednotlivé objekty fungují. Po zjištění faktu, že vnitřní struktura Word dokumentu je poměrně složitá a její plné pochopení bez pořádné dokumentace by trvalo několik týdnů, bylo třeba vymyslet nějaký chytrý způsob, kterým bych nabídky vytvářel. Ten se mi snad podařilo nalézt. Ideou bylo, že existuje nějaký dokument – šablona, do kterého by se pak vkládaly ostatní dokumenty s popisy a vlastnostmi strojů. Šablona by měla v sobě obsažené styly a záhlaví/zápatí, o které by se již dále nemuselo nijak starat. Několik tříd obsahuje metodu „InsertFile“, která na danou lokaci vloží dokument z disku. Tímto způsobem se vytváří obchodní nabídka. Otevře se šablona, tam se kurzorem skočí na konec, vytvoří se ceník nabídky, a pak už se jen vkládají další dokumenty do stávající nabídky. V okamžiku když je hotová, tak se uloží pod jiným jménem, aby se původní soubor šablony nepoškodil. Za tímto cílem existuje v aplikaci třída „OfferCreator“, která pomocí metody „CreateOffer “ podle výše popsaných kroků vygeneruje a uloží Word Dokument. Do metody se přidává třída „Offer“ (ta pracuje ale hlavně jako struktura), která obsahuje všechna potřebná data jako seznam produktů, jazyk nabídky, jméno firmy atd. Hlavní objekt, se kterým při vytváření nabídky pracuji, se jmenuje „Range“. Ten reprezentuje nějaký výběr. Pokud bychom v dokumentu označili například jeden řádek, tak objekt Range reprezentuje tento výběr, s tím že atribut Start ukazuje na začátek výběru a atribut End na konec výběru. Jako to můžeme dělat pomocí Word editoru, tak u výběru můžeme měnit font, velikost, barvu atd. A právě tato třída obsahuje metodu „InsertFile“, která vloží místo tohoto výběru jiný dokument. Takže v našem případě by to nahradilo vybraný řádek celým dokumentem. Vzhledem k tomu, že vždy vkládám dokument na konec, potřebuji nějak označit konec dokumentu. To zajistí metoda „GoToEnd“ v „OfferCreator“, 25
4. Realizace která vrací Range ukazující na konec: r e t u r n doc . Range ( doc . Content . End − 1 , doc . Content . End − 1 ) ; Tento proces je podobný přesunutí kurzoru na konec dokumentu. Tento proces se víceméně opakuje, dokud se nesestaví celá nabídka.
26
Kapitola
Testování Součástí vývoje každého softwaru jsou testy. Cílem testování je odhalit potencionální chyby v aplikaci a zároveň zjistit, zda aplikace splňuje všechny funkční požadavky. Po fázi testování by měl být software plně funkční a v ideálním případě i bez chyb. Podle softwarového inženýrství rozdělujeme testování na několik kategorií buď podle přístupu k testování, nebo podle rozsahu testování. Podle přístupu se dělí na white-box, black-box a greybox. Při white-box testování zná tester veškeré vnitřní struktury programu. Samozřejmostí je možnost přístupu ke kódu. Při tomto testování se spíše testují jednotlivé části aplikace. Podrobná znalost kódu může také vést k lepší možnosti nasimulování chyby. Při black-box testování nezná tester nic o vnitřku aplikace. Aplikace se jeví jako černá skříňka, do které po vložení informace cosi „vypadne“. Testují se tedy pouze data na výstupu, a ta se pak porovnávají s daty na vstupu. Když tato data nesedí, pak víme, že v aplikaci je nějaká chyba, ale její odhalení již přísluší programátorovi. Greybox je přesně něco mezi. Testerovi jsou známé struktury a algoritmy které aplikace využívá, nemusí mít však přístup do samotného kódu. Druhým typem testování jsou testy podle rozsahu. Ty se rozdělují na jednotkové testy, integrační testy, systémové testy a akceptační testy. Jednotkové testy testují vždy jednu část kódu (např. jednu třídu) bez závislostí na ostatních částech. Tyto testy slouží hlavně pro ujištění, že jednotlivé části pracují správně. Tyto testy jsou často psány samotnými programátory během vývoje. Integrační testy se oproti jednotkovým zaměřují na spolupráci mezi jednotlivými komponentami. Při provádění změn na aplikaci tyto testy můžou vést k rychlému odhalení chyb. Systémové testy testují aplikaci jako celek. Jde hlavně o to, jestli aplikace splňuje veškeré požadavky. Akceptační testy jsou podobné těm systémovým, jen je provádí zadavatel. Jak už jejich název vypovídá, zadavatel by se měl díky těmto testům rozhodnout, zda je 27
5
5. Testování již aplikace plně provozuschopná. Při vývoji aplikace jsem se zaměřil hlavně na integrační testy. Myslím si, že jednotkové nebyly tolik třeba, protože většina funkcí obecně v informačních systémech je poměrně jednoduchá a hlavní tíha spočívá na propojení jednotlivých objektů. Během testování jsem testoval aplikaci hlavně z uživatelského prostředí, abych si i ověřil funkčnosti ovládacích prvků. Naštěstí jsem se potýkal pouze s jednoduchými problémy, které mohly být odstraněny v rámci desítek minut. Ke konci jsem již prováděl systémové testy, kde jsem se vžil do role uživatele a snažil se provést všechny, i když někdy nesmyslné, kroky. Důležité je, aby aplikace reagovala na všechny možné situace a z nich nabízela nějaké východisko. Jako příklad uvedu, když uživatel chce vytvořit nabídku, zároveň má ale ten samý dokument otevřený ve Wordu. Nově vytvořená nabídka by chtěla přepsat bývalou, která je ale otevřená. To vyvolá výjimku, na kterou aplikace musí zareagovat a nesmí „spadnout“. Mým cílem při systémových testech bylo, zaměřit se právě na takovéto situace.
28
Závěr Celá tato aplikace se pro mě stala výzvou. Nikdy jsem ještě nepracoval sám na takto velkém úkolu, kde jsem musel provést vše sám od návrhu až po samotnou realizaci. Řekl bych, že aplikace je vcelku funkční a splnila všechny kladené požadavky. S čím však nejsem tolik spokojený, když se ohlédnu zpět, je její návrh a design. I když jsem se snažil při návrhu přemýšlet nad každým krokem, myslím si, že by to šlo provést mnohem lépe. Když se člověk pouští takto do neznáma, uvědomí si spoustu detailů až poté, co si sám zkusí provést vlastní práci. Správný návrh by měl splňovat skutečnost, že každá třída dělá pouze jednu činnost. To je sice utopická představa, ale výsledek by se k tomu měl aspoň trošku blížit. A sice neexistují žádné exaktní metody, jak měřit kvalitu kódu. Já si však myslím, že kvalitní kód se pozná podle toho, že když jej programátor několik týdnů nevidí, přesto se v něm po čase rychle zorientuje. V tomto ohledu si myslím, že mám ještě rezervy, protože některé třídy zastávají více úkonů a zároveň některé obsahují chaotické reference. Druhý zmiňovaný problém byl design. To je v tomto případě přímo uživatelské rozhraní a rozvržení prvků. Zvláště administrativní část působí poněkud chaoticky a chvíli to trvá, než se v ní uživatel zorientuje. U tohoto je však ospravedlňující, že design aplikací rozhodně není tím, čemu bych se rád věnoval a klidně jej přenechám lidem s větším uměleckým cítěním. Přesto si myslím, že je škoda, že v mém oboru není žádný takový předmět, jelikož také programátor by během vývoje měl mít základní přehled i o ostatních souvisejících činnostech. Když svoji práci shrnu, jsem vcelku spokojen. Během vývoje jsem se toho dost naučil a seznámil se s mnoha technologiemi, a to je podle mě cílem práce. Také mě těší, že jsem pracoval na reálném programu a netvořil aplikaci, jak se říká, jen tak „do šuplíku“. Bohužel během tvorby mé baka29
Závěr lářské práce nebylo na vývoj tolik času, kolik bych si představoval. Proto mám do budoucna v plánu ve vývoji aplikace pokračovat (a to již bez vlivu školy), případně díky získaným zkušenostem některé části přepracovat.
30
Příloha
Seznam použitých zkratek + vysvětlivky GUI Graphical user interface XML Extensible markup language .doc Přípona Microsoft Word souboru Opce Volitelný prvek / příslušenství
31
A
Příloha
Obsah přiloženého CD
readme.txt ................................ stručný popis obsahu CD exe.....................adresář se spustitelnou formou implementace src impl.................................zdrojové kódy implementace thesis....................zdrojová forma práce ve formátu LATEX text.....................................................text práce thesis.pdf...........................text práce ve formátu PDF 33
B
Příloha
C
Instalační příručka Tato příručka by vás měla provést instalací a úspěšným spuštěním aplikace. Varování: Pro spuštění aplikace je třeba mít nainstalovaný Microsoft Word ! Soubor s aplikací by měl obsahovat několik souborů. Těmi jsou • Tvorba obchodních nabídek.exe • Editor.exe • Database • Docs Tvorba obchodních nabídek.exe spouští uživatelskou část aplikace. Editor.exe spouští administraci dat, kde uživatel může upravovat jednotlivé produkty. Database je soubor s daty, obsahující veškeré produkty, jejich ceny a uložené měnové kurzy. Při spouštění uživatelské nebo administrativní části, tento soubor musí být ve stejné složce co aplikace! Jinak se databáze nenahraje a založí se nová prázdná. Poslední složka Docs obsahuje několik dalších podsložek (CZE, ENG, RUS, . . . ) rozdělených podle jazyků. Tyto složky pak obsahují Word Dokumenty s technickým popisem produktů. Ty se pak využívají při sestavování nabídky.
35
Příloha
Uživatelská příručka Tato příručka slouží jako manuál pro uživatelskou část aplikace. Ta se spouští přes soubor „Tvorba obchodních nabídek.exe“. Na úvodní stránce aplikace jsou vyobrazené základní informace, jako je verze programu či datum vytvoření databáze. Na pravé a levé straně jsou tlačítka s šipkami, která slouží pro navigaci po aplikaci. Když půjdeme dál, zobrazí se 2 hlavní ovládací prvky. Vlevo je seznam nabízených produktů a vpravo je shrnutí produktů přidaných do nabídky. Pro přidání produktu do nabídky je třeba ho vybrat ze seznamu a 2x na něj kliknout. Tím se otevře okno s parametry, kde se dají specifikovat volitelné opce, které produkt nabízí. V pravém dolním rohu také můžeme zadat, kolik kusů od daného produktu se má přidat do nabídky. Přidání produktu potvrdíme kliknutím na tlačítko „potvrdit“ v daném okně. Tím by se nám měl produkt přidat do shrnutí, kde vidíme i jeho aktuální cenu. V pravém horním rohu je comboBox, ve kterém můžeme změnit měnu, ve které se ceny zobrazují. Aktuální kurz se nedá nijak měnit, ten je zadán v souboru s databází. Pokud chceme produkt z nabídky smazat nebo upravit, je třeba ho najít ve shrnutí a tam na něj 2x kliknout. Otevře se zase okno s parametry, kde ale dole přibylo nové tlačítko Vymazat. To jej odstraní z nabídky. V okně shrnutí je ještě další údaj, který je defaultně nastavený na „0.0%“. Ten specifikuje slevu, kterou chceme na produkt stanovit. Tento údaj je možné změnit, pokud na něj 2x klikneme. Když máme nabídku sestavenou, klikáme opakovaně na pravé tlačítko, dokud se nedostaneme do okna „Shrnutí“. Tam se rekapituluje celková cena nabídky a v okně „Sleva“ můžeme nastavit slevu na celkovou nabídku. Kliknutí na tlačítko „Potvrdit“ nás zavede do okna, ve kterém se již vytváří nabídka. Zde stačí vyplnit jen několik údajů a zvolit dostupný jazyk, ve kterém se má nabídka vytvořit. Po kliknutí na tlačítko „Vytvořit nabídku“ se začne generovat nabídka, která se pak sama zobrazí. Tento proces může trvat i 37
D
D. Uživatelská příručka několik desítek vteřin podle obsáhlosti nabídky.
38
Příloha
Administrativní příručka Tato příručka slouží jako manuál k administrativní části aplikace. V této části můžeme přidávat/upravovat/mazat produkty či jakkoliv upravovat data. Administrativní část se spouští přes soubor „Editor.exe“. Při spuštění aplikace by to mělo vypadat takto:
1. Seznam strojů v dané kategorii (aktuálně čerpadla). Zobrazuje se jejich jméno v češtině a základní cena (cena bez všech opcí). 2. Navigační šipky. Těmi se mění aktuálně zvolená kategorie produktů. 3. Ovládací prvky. Přidat přidá nový produkt do aktuálně zvolené kategorie. 39
E
E. Administrativní příručka Upravit upraví aktuálně zvolený produkt Duplikovat vytvoří přesnou kopii aktuálně zvoleného produktu Odstranit vymaže aktuálně zvolený produkt Uložit uloží databázi. Soubor s databází se nachází v stejné složce jako aplikace. 4. Vyvolá dialogové okno, kde se dají upravit kurzy měn. Při přidání či upravení produktu se vyvolá okno s vlastnostmi produktu:
1. Změní jméno produktu. To se zadává ve více jazycích a nejméně angličtina musí být vyplněna. 2. Nahraje ikonu, která produkt reprezentuje v seznamu. 40
3. Jméno dokumentace bez přípony, která se má při vložení produktu přidat do nabídky. Dokumentace musí být dostupná v docs/“název jazyka“/ (např docs/CZE/Ovládací systém.doc). 4. Každá hlavní skupina (např. čerpadla) se může dále sestávat z podskupin. Když se zde něco vyplní, přiřadí se produkt do dané podskupiny. 5. Správce polotovarů. Obsahuje polotovary a jejich ceny, ze kterých se produkt skládá. Ceny můžou být zadávány ve více měnách a podle zadaného kurzu se přepočítávají. 6. Po té, co se vypočítají náklady na produkt, je možné k celkové ceně přidat procentuální přirážku. 7. Otevře nové okno, ve kterém se dají upravovat opce daného produktu. Při kliknutí na tlačítko Upravit opce se otevře toto okno:
1. Okno s opcemi. Pokud chceme nějakou opci upravit, je třeba na ní kliknout. Tím se zvýrazní modrou barvou. Pokud chceme opci odznačit, je třeba kliknout do velké šedé plochy okolo opcí. 2. Panel s ovládacími prvky Přidat přidá novou opci/možnost. Toto tlačítko funguje podle toho, co je právě vybrané. Pokud není žádná opce vybraná, můžeme přidat comboBox, GroupBox a CheckBox. Pokud je vybraný GroupBox, můžeme do něj přidat CheckBox a RadioButton. Pokud je vybraný comboBox, přidá se do něj další položka seznamu. 41
E. Administrativní příručka Odstranit podobně jako tlačítko „Přidat“, funguje na právě zvolený prvek. Pokud je zvolená některá opce, tak ji smaže. Pokud je vybraný prvek list v seznamu v comboBoxu, pak smaže tento prvek. Šipky Těmi se dají posouvat jednotlivé opce. Slouží hlavně pro grafické uspořádání. U radioButtonu je však ten úplně horní vybrán jako defaultní. 3. Správce polotovarů. Vztahuje se k aktuálně zvolené opci. Má stejnou funkci jako u vlastností produktu. 4. Názvy opcí. Zde se zadávají názvy aktuálně zvolené opce. Zase platí, že název musí být zadán aspoň v angličtině. ComboBox pod názvy umožňuje vybrat pro opci speciální vlastnost (u stolů to jsou např. rozměry X a Y, se kterými se pak dále počítá).
42
