Masarykova univerzita Fakulta informatiky. Diplomová práce. Systém pro správu a hromadné zpracování poštovních zásilek

Transkript

1 Masarykova univerzita Fakulta informatiky Diplomová práce Systém pro správu a hromadné zpracování poštovních zásilek Vypracoval: Roman Melichar Brno, 2012

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.

3 Poděkování Na tomto místě bych rád poděkoval nejprve vedoucímu mé diplomové práce panu RNDr. JUDr. Vladimíru Šmídovi, CSc. za jeho vstřícnost, cenné rady a věnovaný čas. Dále bych chtěl poděkovat mému zaměstnavateli Bc. Martinovi Antošovskému za nepostradatelné znalosti a velmi cenné zkušenosti, které jsem pod jeho několikaletým vedením získal. V neposlední řadě bych velice rád poděkoval Lucii Vaňkové za grafiku.

4 Shrnutí Cílem práce je prozkoumat existující systémy pro správu a hromadné zpracování pošty a analyzovat aktuální požadavky trhu v této oblasti. Výsledkem práce bude specifikace konkrétních požadavků na nový systém, popis vybraných technologií umožňujících jeho implementaci a v neposlední řadě jeho návrh pomocí UML jazyka. Součástí práce je krátké pojednání o návrhových vzorech. Klíčová slova pošta, zásilka, dopis, balík, informační systém

5 Obsah Úvod... 7 Historie... 7 Návrhové vzory... 9 Adapter Pattern... 9 Facade Pattern Chain Of Responsibility Pattern Observer Pattern Strategy Pattern Existující systémy Podání Online Poštmistr Bundler DHL Online Shipping Softwarové produkty společnosti TNT Softwarová podpora dalších významných přepravních společností ProfiPost Popis Systému Analýza systému Správa zásilek Správa adresáře Správa exportů a importů Správa tisků Správa středisek Správa uživatelů Správa podavatelského nastavení Správa superpodavatelského nastavení Správa licencí Uživatelská správa správce systému Správa systému... 38

6 Použité technologie Java JAAS Hibernate Web services Návrh systému Modul zásilek Modul uživatelů Modul adresáře Modul kontrol Modul exportů a importů Modul notifikace Modul archivace Struktura a rozmístění systému Závěr Použité zdroje... 63

7 Úvod Rozvoj IT během posledních dvou desetiletí způsobil v mnoha oblastech doslova revoluci. Virtualizaci dat a automatickému zpracování se nevyhnula ani oblast poštovních služeb, kde byl pro aplikaci informačních technologií obrovský potenciál. Zprvu se jednalo především o problém uchování dat a jejich přenos pro potřeby poskytovatele těchto služeb. Čím více se ale výpočetní technika a internet stávaly dostupnějšími, tím více sílil tlak na usnadnění a zautomatizování často se opakujících identických procesů i na straně podavatelů. Tento tlak byl dále umocněn mnoha dalšími aspekty, jako např. rozvojem internetového nakupování, které odstartovalo boom v oblasti elektronických obchodů, jež se bez poštovních služeb neobejdou. V současné době na trhu existuje několik málo systémů, které umožňují správu a hromadné podání poštovních zásilek. Dominantní místo na trhu však mají systémy adaptované pro správu a podání zásilek České pošty. Cílem této práce je prozkoumat současnou situaci na trhu v oblasti softwaru určeného pro podavatele a sloužícího pro komplexní správu a hromadné zpracování pošty. Dále pak analyzovat požadavky trhu v této oblasti a vzhledem k možnostem, které nabízejí dnešní moderní technologie, navrhnout nový systém splňující tyto požadavky. Historie Prvním veřejně dostupným systémem pro zpracování a podání pošty byla aplikace Zásilka. Její vývoj byl dokončen v devadesátých letech minulého století, odkdy byla také Českou poštou distribuována jejím klientům. Dostupnost IT však v té době nebyla velká a vzhledem k tomu, že tato aplikace byla určena jen pro operační systém MS DOS, což nebylo z uživatelského hlediska příliš přívětivé prostředí, nemohla být tato aplikace využívána velkým počtem podavatelů. Až masové rozšíření nového operačního systému Windows donutilo Českou poštu odstartovat vývoj nového systému, který měl v té době díky stále větší dostupnosti počítačového vybavení a malých nároků na obsluhu obrovský potenciál. V roce 2000 uzavřela Česká pošta kontrakt s firmou STUAREPost s.r.o. na vývoj programu Pošta Tato aplikace byla v oblasti hromadného zpracování a podání zásilek doslova revolucí. Virtualizace poštovních služeb bylo přesně to, co na trhu chybělo, a na co společnost STUAREPost dokázala odpovědět, když v roce 2002 uvedla svůj nový systém na trh. Jednalo se opět o desktopovou aplikaci, která však byla provozována už na platformě Windows. Deset let byla tato aplikace prakticky nejlepším řešením v dané oblasti u nás a získala si mnoho zákazníků. Vývoj v ICT však přinášel nové možnosti, a tím vznikaly i nové požadavky na software. To vyústilo v roce 2009 v rozhodnutí České pošty přestat podporovat vývoj Pošty 2002 a začít vyvíjet vlastní systém s názvem Podání Online. Tento systém měl odpovědět na nejnovější požadavky a trendy, tzn. platformově nezávislá webová aplikace, provozovaná centralizovaně na serverech České pošty. Tyto události však odstartovaly i vývoj jiné aplikace, jakožto pokračovatele úspěšného systému Pošta Jednalo se 7

8 o desktopovou aplikaci, kterou začala vyvíjet společnost ATAX SOFTWARE s.r.o. v roce Ta byla na trh uvedena v roce 2010, což bylo ve stejný rok jako uveřejnění aplikace Podání Online. V současné době je pro používání systému Podání Online nabízena bezplatná licence a i přes využití moderní architektury, která nabízí mnoho nesporných výhod, si v oblasti správy a hromadného podání zásilek drží vedoucí místo na trhu společnost ATAX SOFTWARE s.r.o. a to díky své desktopové aplikaci nazvané Poštmistr. 8

9 Návrhové vzory Pojem návrhový vzor lze chápat jako do jisté míry obecné řešení určité skupiny problémů podobného charakteru. Tento pojem sám o sobě nesouvisí pouze s návrhem softwaru, ale je možné ho najít ve spoustě jiných mnohem starších odvětvích jako je např. stavitelství. V informatice byl tento fenomén formalizován relativně nedávno. Bylo to koncem 70. let minulého století. Popularizován byl ale až v polovině let devadesátých. Předcházel tomu však relativně dlouhotrvající vývoj procesu návrhu softwaru, kdy systémoví architekti často naráželi na podobné problémy, jejichž řešení se dalo zobecnit. V průběhu času tak vykrystalizovala některá obecnější řešení určitých problémů. V tomto smyslu by se návrhové vzory tedy daly definovat jako zobecněná řešení často opakujících se skupin netriviálních problémů, jejichž konečné řešení se sice může do určité míry lišit, ale jich podstata je stejná. Z toho plyne, že se nejedná o žádný konkrétní algoritmus nebo již hotový návrh, ale pouze o popis či vzor řešení problému natolik obecný, že je možné ho použít v různých situacích. Jejich přínos při správné aplikaci na daný problém spočívá nejen ve zobecnění a zpřehlednění systému, ale představují již prověřené postupy, zaručující určité vlastnosti, kterých je daným návrhovým vzorem docíleno. Porozumění jejich podstatě tedy představuje znalost řešení často opakujících se problémů, a tak usnadňují pochopení systému jako celku. Návrhových vzorů bylo popsáno relativně velké množství, a protože cílem této práce není pojednání o všech těchto konceptech, následující podkapitoly rozebírají pouze některé z nich. Adapter Pattern Cíl: Cílem tohoto návrhového vzoru je poskytnout koncept umožňující především znovupoužitelnost starších komponent nebo pro jiný účel navrhnutých komponent. Motivace: Při vývoji mnoha systémů se často řeší otázka znuvupoužitelnosti už existujících řešení. To však s sebou někdy přináší určité komplikace vyplývající z faktu, že dané komponenty byly navrženy pro jiný systém či jiný účel. V těchto případech je potřeba mezi nově navrhovaným systémem a starou komponentou vytvořit tzv. adaptér, který zajistí potřebnou kompatibilitu. Použití: Obecně se jedná se hlavně o konverzi rozhraní staré komponenty na rozhraní vyžadované klientem, pro kterého se daná komponenta adaptuje. V podstatě jde o to, aby adaptér delegoval či určitým způsobem transformoval klientem volané metody na metody cílové komponenty. Tohoto může být docíleno buď dědičnosti, nebo agregací. Struktura: Na následujícím obrázku je zobrazen diagram tříd popisující řešení pomocí dědičnosti. Jedná se o tzv. object adapter. 9

10 obr. 1: Struktura návrhového vzoru Adapter Pattern řešení za použití dědičnosti Třída Adaptor zprostředkovává interakci mezi klientem a příslušným objektem třídy Adaptee. Klient však nevolá přímo Adaptor, ale rozhraní Target, které klient pro tuto interakci vyžaduje. Samotný Adaptor má za úkol delegovat či transformovat toto volání klienta na volání příslušného objektu Adaptee, kterého si drží jako atribut. Adaptor si v tomto případě může držet reference na více objektů Adaptee a zajišťovat tak komunikaci s více objekty. Druhou variantou je tzv. class adapter. obr. 2: Struktura návrhového vzoru Adapter Pattern varianta class adapter V tomto případě si Adaptor nedrží reference na Adaptee, ale rozšiřuje původní starší komponentu tak, aby vyhovovala rozhraní Target. Význam Adaptoru je obdobný jako v předešlém případě transformovat volání klienta na volání Adaptee. Důsledky: Použití tohoto vzoru umožňuje opětovné použití starších komponent s jiným rozhraním, než jaké je vyžadováno, a to bez nutnosti měnit či jakkoli upravovat tyto komponenty. Facade Pattern Cíl: Cílem je zjednodušit klientům práci se systémem. Vhodnou implementací tohoto návrhového vzoru může být klient odstíněn od složitostí vnitřní struktury systému a pro využití jeho funkcí tak nebude muset mít povědomí o jeho komponentách a jejich provázanosti. 10

11 Motivace: Jednoduchým příkladem využití tohoto návrhového vzoru je opět knihovna Swing v Javě. Jedná se o obecnou, a proto poměrně složitou knihovnu, pomocí které je možné implementovat grafické uživatelské rozhraní s nejrůznějšími požadavky. Pro případ, že je ale potřeba pouze zobrazit v okně nějakou jednoduchou zprávu popř. získat od uživatele i odpověď v podobě kliknutí na příslušné tlačítko, není nutné znát způsob, jakým se okna vytváří, ale místo toho jen použít jednoduchou třídu JOptionPane, která toto všechno udělá za klienta. Použití: Na případy, kdy je potřeba využít složitější systém pro relativně jednoduché úkoly, se naráží poměrně často. Aby bylo možno takto systém použít, je třeba znát jeho komponenty, jejich funkce, způsob jakým s nimi pracovat a provázanost s ostatními částmi systému. To může představovat značné množství informací. Proto je vhodné implementaci těchto jednoduchých úkolů zapouzdřit pomocí jednotného rozhraní do jedné nebo několika málo tříd, které by pak klienti mohli využívat, aniž by museli znát vnitřní strukturu systému. Zde rozhraním není myšlen interface v Javě, ale jakési rozhraní vyšší úrovně, které se může skládat z jedné či více tříd nebo rozhraní (interfaců). Struktura: Na následujícím diagramu tříd je zobrazen způsob, jak klient využívá systém se znalostí jeho vnitřní struktury. Z vazeb je vidět úzké provázání komponent spolu s klientem. obr. 3: Příklad nevhodně navrženého systému Pokud se v systému vytvoří rozhraní, které poskytuje potřebnou funkcionalitu využívanou klientem, odstíní se klient od složitosti celého systému a není tak úzce provázán se systémem. Ve skutečnosti nemusí mít vůbec ponětí, co se za příslušným rozhraním skrývá. 11

12 Názorným příkladem v Javě je třída System zprostředkovávající nějaké služby operačního systému. Pro jejich využití není vůbec nutné vědět, nad jakým operačním systémem je program spuštěn. Na následujícím diagramu tříd představuje ono rozhraní systému třída Facade. Ve skutečnosti se však může jednat o více tříd či rozhraní (interfaců). obr. 4: Příklad aplikace návrhového vzoru Facade Pattern Důsledky: Aplikací tohoto návrhového vzoru může být docíleno snížení provázanosti klienta se systémem tím, že klient využívá jen jednu či několik málo jednoduchých rozhraní systému. To pak umožňuje poměrně jednoduché nahrazení části popř. celého systému jiným, aniž by to ovlivnilo klienty, kteří ho využívají. Dalším příznivým důsledkem je skrytí vnitřní složitosti systému, což klientovi zjednodušuje způsob jeho využití. Ten pak nemusí znát vnitřní strukturu systému, funkce jednotlivých komponent a jejich provázanost, ale pouze dané rozhraní systému. Tento koncept má představovat alternativu k dosavadnímu způsobu přístupu k funkcím systému. Nijak tedy neomezuje stávající způsob využití. Naopak, může stávající funkcionalitu rozšiřovat. Příkladem může být již zmiňovaná knihovna Swing v Javě a její třída JOptionPane poskytující jednoduché metody pro zobrazování oken se zprávami či očekávající odpověď uživatele. Chain Of Responsibility Pattern Cíl: Cílem tohoto návrhového vzoru je poskytnout popis řešení specifického způsobu komunikace mezi objekty, kdy odesílatel není pevně svázán s příjemcem a informaci předává skupině objektů, aniž by řešil, který z nich by ji měl zpracovat. 12

13 Motivace: V případě komunikace jednoho objektu s více objekty, kdy při předávání konkrétní informace není schopen rozhodnout, kterému objektu má danou informaci předat, může za určitých podmínek přenechat odpovědnost samotným objektům této skupiny, které zajistí, že informace bude zpracována na správném místě. Použití: Tento návrhový vzor lze použít, je li předávána informace více objektům, jejichž počet nemusí být předem znám, a pokud dále platí, že tyto objekty jsou uspořádány do určité hierarchie, na základě které je možné rozhodnout, který z nich má danou informaci zpracovat. Struktura: Následující class diagram popisuje obecně strukturu a uspořádání řešení pomocí tohoto návrhového vzoru. obr. 5: Struktura návrhového vzoru Chain Of Responsibility Pattern Client reprezentuje objekt předávající informaci skupině tzv. Handlerů. Toto rozhraní je společné pro všechny potenciálními příjemce informace. Client si drží referenci pouze na jednoho z nich. Všichni ostatní jsou spolu provázáni lineárně do seznamu pomocí atributu successor, který vždy obsahuje odkaz na následníka. V případě, že Client předá informaci jednomu Handleru, ten se pokusí sám informaci zpracovat a pokud zjistí, že k tomu není oprávněn, předá tuto informaci dále. Informace tak putuje, dokud se nenajde příslušný objekt, který je schopen ji zpracovat. Důsledky: Vyvarování se přímého propojení typu odesílatel příjemce tím, že je znám pouze první z možných příjemců. Skutečný příjemce nemusí být znám např. proto, že může být závislý na konkrétní informaci. Client se nemusí zabývat, se kterým konkrétním objektem má komunikovat. Toto rozhodnutí je ponecháno už na skupině samotné. Seznam potenciálních příjemců je vytvářen dynamicky. 13

14 Observer Pattern Cíl: Hlavní myšlenkou tohoto návrhového vzoru je definovat vazbu mezi jedním tzv. pozorovaným objektem a skupinou tzv. pozorujících objektů, která umožní této skupině reagovat na určité události generované pozorovaným objektem. Událostmi mohou být změny stavu pozorovaného objektu nebo jiné události, na které tento objekt reaguje. Vazby mezi objekty jsou vytvářeny dynamicky. Motivace: V praxi se tento problém vyskytuje poměrně často. V Javě je na něm založené celé událostmi řízené programování uživatelského rozhraní např. pomocí knihovny Swing, kde se řeší pomocí tzv. listenerů. Podstatou je umožnit určitým objektům pozorovat nezávislý objekt a zajistit tak, aby byly tímto objektem informovány na vznik určitých událostí vždy, když nastanou. K tomu je ale nejprve třeba, aby se pozorující objekt u pozorovaného přihlásil. Pozorovaný objekt je nezávislý na svých pozorovatelích. Jeho úkolem je pouze informovat tyto objekty. Jejich reakce je už věcí jejich konkrétní implementace a nemá na pozorovaný objekt vliv. Použití: Toto obecné řešení je možné použít pro situace, kdy existuje závislost jednoho objektu na druhém a je potřeba zajistit, aby se informace o dané události dostala k druhému. Tato závislost vzniká až za běhu programu, může být pouze dočasná a je charakteristická tím, že na jednom objektu může záviset libovolný počet objektů a naopak jeden objekt může záviset na více objektech. Specifickou vlastností tohoto konceptu je nezávislost pozorovaného objektu na způsobu zpracování informace pozorujícími objekty. Struktura: Pozorovaný objekt představuje rozhraní Subject. Jeho pozorovatelé jsou pak reprezentováni rozhraním Observer, které musí obsahovat metodu, prostřednictvím níž jsou pozorovatelé informováni oudálostech, jež sledují. Samotné informování všech Observerů provádí metoda notifyobservers. Konkrétní implementace Subjectu pak už musí jen zajistit, aby se tato metoda prováděla na správných místech. Mnohdy je třeba, aby Observeři reagující na událost související s pozorovaným objektem měli k dispozici určité informace týkající se této události. Může se jednat o jeho stav popř. jiná data související s danou událostí. Existují dva způsoby, jak se tyto informace dostanou k Observerovi. První z nich je zobrazena na následujícím class diagramu. Běžně se označuje anglickým slovem pull, které v tomto případě vyjadřuje, že si Observer musí dané informace od Subjectu zjístit ( natáhnout ) sám. Rozhraní Subject tedy deklaruje metodu getstate, která tyto informace Observeru poskytne, a je na samotném Observerovi, jestli o tyto informace požádá nebo ne. 14

15 obr. 6: Struktura návrhového vzoru Observer Pattern pull varianta Existuje i druhá (tzv. push) varianta, kdy jsou Observeru předány informace o události vždy, když tato událost nastane. To je znázorněno na diagramu níže. obr. 7: Struktura návrhového vzoru Observer Pattern push varianta Druhým parametrem předávaným Observeru by měl být samotný zdroj události, tj. Subject. V případě pull varianty je důvod zřejmý Observer musí mít odkaz na Subject, aby mohl získat jeho stav. Co se týče push varianty, může to být nezbytné, pokud je jeden Observer přihlášen u více Subjectů, kteří ho informují prostřednictvím té stejné metody. Důsledky: Koncept, který tento návrhový vzor představuje, se dá s výhodou využít pro přidání nové funkcionality do stávajícího systému, aniž by se nutně musel měnit. Stávající funkcionalita tak může zůstat nezávislá na konkrétní implementaci svých pozorovatelů. Hlavní myšlenkou je umožnit určité části systému reagovat na události v jiné části systému. To může při nevhodné implementaci způsobovat jisté problémy (výkonnostní či funkční). Problémy s výkonem mohou nastat, pokud jsou reakce pozorovatelů implementovány jako 15

16 výkonově náročnější operace a k událostem, na které takto reagují, dochází poměrně často. V takovém případě by bylo vhodné zvážit, jestli mají být pozorovatelé informováni o každé této události nebo vždy až po určitém jejich počtu. Proto bývá občas v popisu tohoto návrhového vzoru zmiňován příznak Subjectu, který určuje, zda mají být pozorovatelé upozorněni či nikoli. K funkčním problémům může docházet např. tehdy, pokud se reakce na událost šíří systémem nekontrolovatelně a vrací se zpět do části systému, která je začala šířit. Strategy Pattern Cíl: Cílem je definovat skupinu různých řešení stejného problému tak, aby byla zajištěna jejich jednoduchá zaměnitelnost nebo rozšiřitelnost nezávisle na klientech, kteří je využívají. Motivace: V mnoha případech se při návrhu naráží na situaci, kdy existuje několik různých algoritmů řešících stejný problém často nad stejnými daty, nebo kdy je potřeba v návrhu počítat s tímto možným rozšířením. Nezáleží už na tom, jestli konkrétní výběr strategie provede klient využívající těchto služeb nebo ho přenechá jinému objektu. Důležité je návrh vhodně rozdělit, čímž se zajistí jednoduchost a nezávislost klienta na konkrétním řešení, a tím tedy i snadná rozšiřitelnost. Použití: Tento návrhový vzor je vhodný pro situace, kdy je k dispozici více implementací řešících daný problém a ta konkrétní z nich, která má být použita v dané situaci, může být známa až v době běhu programu. Koncepce, kterou poskytuje, umožňuje rozvrstvení jednotlivých částí daného řešení problému, a takstrategypatternzároveň řeší i problém oddělení dat od samotného algoritmu, který je zpracovává. Struktura: Následující diagram vystihuje koncept tohoto návrhového vzoru, kdy za výběr konkrétního algoritmu zpracování je zodpovědný klient. obr. 8: Struktura návrhového vzoru Strategy Pattern, kde za výběr strategie je zodpovědný Client Třída Client představuje objekty, které potřebují použít konkrétní algoritmy. Komunikuje však pouze s objektem Context. Až v tomto objektu probíhá samotná interakce s objektem 16

17 Strategyimplementation, který představuje konkrétní řešení problému. Jak bylo uvedeno výše, může existovat více variant, a proto je nutné, aby pro ně existovalo společné rozhraní, přes které by s nimi Context mohl komunikovat. Tím je právě rozhraní Strategy. Client má referenci na objekt třídy Context buď uložený v sobě, nebo ho nějakým způsobem získá. Vybere si konkrétní Strategyimplementation a předá ji Contextu. Ten už pak zajistí, že se daný algoritmus definovaný v Strategyimplementationprovede se správnými daty. Může je buď předat Strategyimplementation, nebo tomuto objektu může předat sám sebe a nechat na něm, aby si zjistil potřebná data. Druhou variantou tohoto obecného konceptu je, že si Client nevybírá konkrétní Strategyimplementation sám, ale výběr přenechá na objektu třídy Context. To je zachyceno na následujícím diagramu. obr. 9: Struktura návrhového vzoru StrategyPattern, kde výběr strategie provádí Context Důsledky: Umožňuje dynamický výběr konkrétního řešení. Dokonce může oddělit logiku zpracování od zpracovávaných dat. Na obojím pak nemusí být klient závislý. Rozšíření o další Strategie neovlivní ostatní části systému Clienta, Context a ani ostatní Strategie. 17

18 Existující systémy V současné době je trh poštovních služeb z části regulován. Existuje zde tzv. poštovní výhrada, jejímž držitelem je Česká pošta s. p. Jedná se o monopol na doručování poštovních zásilek ve vnitrostátním styku, jejichž hmotnost je menší než 50 g a cena nižší než 18 Kč. Mimo tuto oblast působí na trhu řada dalších společností, které úspěšně konkurují České poště. Řada z nich nabízí vlastní softwarové řešení pro správu a podání zásilek. Cílem této podkapitoly je popsat existující systémy pro podej, případně i správu zásilek většiny významných poskytovatelů poštovních služeb u nás. Podání Online Podání Online je aplikace určená pro hromadné podávání zásilek České pošty. Vlastníkem je Česká pošta a je určena pro podavatele, kteří jsou smluvními partnery České pošty. Její používání je zdarma. Jedná se o webovou aplikaci typu klient server, kde úlohu klienta plní webový prohlížeč. Odráží tedy nejnovější trendy a přináší tak všechny výhody s tím spojené, jako je např. nezávislost na platformě, na které je využívána, absence nutnosti instalace klienta aplikace na pracovních stanicích (webový prohlížeč je základní součástí většiny operačních systémů) a provádění zde jakýchkoli aktualizací klienta. Slouží pro zpracování podkladů potřebných k podání poštovních poukázek, zásilek, archivaci dat o podaných zásilkách a tisk adresních štítků. Je navržena tak, aby umožnila snadné a rychlé zadávání detailů jednotlivých adresátů a zásilek, či jejich import ze souborů na přípravu podkladů pro hromadná podání. [3] Poštmistr Aplikace Poštmistr byla vyvinuta firmou ATAX SOFTWARE s.r.o. a je v provozu již třetím rokem. Během této doby byla stále rozšiřována a vylepšována a nyní nabízí prakticky nejkomplexnější způsob zpracování poštovních zásilek České pošty u nás. Co se týče funkčních požadavků, je mnohem vyspělejším systémem než Podání Online. Avšak pokud jde o její architekturu, je Podání Online s architekturou klient server o krok dále. Aplikace Poštmistr zachovala koncept svého předchůdce a byla opět navržena jako desktopové aplikace. Tím vzniká nutnost instalace na pracovních stanicích a zabezpečení distribuce aktualizací. Centralizace dat je možná pouze lokální, to znamená, že nejsou centralizována všechna data na jednom místě, ale tato možnost je přenechána na jednotlivých podavatelích. Úložiště tak bývá zpravidla sdíleno v rámci organizace. Aplikace byla vyvinuta na platformě Java. To s sebou přináší určité výhody i nevýhody. Mezi nevýhody, které dosud nebyly zmíněny, patří například vyšší nároky na hardwarové vybavení pracovních stanic. Výhodou je jednoznačně příjemnější uživatelské rozhraní, které obecně může nabízet více možností. Aplikace v současné době podporuje operační systémy MS Windows XP, Vista a Windows 7, což vzhledem k rozšíření těchto operačních systémů v dnešní době není velkou nevýhodou. 18

19 Program Poštmistr byl navržen tak, aby umožňoval snadnou a rychlou evidenci došlé a odeslané pošty, vykonával automaticky rutinní úkony a byl výkonným pomocníkem pro podej jakékoliv zásilky. Moderní uživatelné prostředí, intuitivní ovládání a vždy platné podmínky ČP, Vám každý den ušetří mnoho starostí a čas při práci s poštovními zásilkami. [4] Za zmínku stojí i fakt, že aplikace Poštmistr existuje ve dvou variantách. Kromě české verze adaptované na produkty České pošty existuje i její slovenská verze podporující evidenci a podání zásilek Slovenské pošty. Bundler Jedná se opět o produkt společnosti STUAREPost, ze které následně vznikla společnost ATAX SOFTWARE s.r.o. Tato aplikace představuje specifičtější řešení než Poštmistr nebo Podání Online. Slouží především k hromadnému podání velkého množství letáků, obchodních sdělení apod. Aplikace je určena pro zpracování zásilek služby České pošty, s.p. s názvem Obchodní psaní. Oceníte ji, pokud rozesíláte katalogy, nabídky, dotazníky či jiné zásilky s identickým obsahem více než 500 adresátům. Procesem automatické aktualizace jsou pravidla pro zpracování zásilek (třídění do "svazků", seznam PSČ a tiskové výstupy) udržována a odpovídají číselníkům České pošty, s.p. [4] Opět existuje i slovenská verze této aplikace, která je určená pro podávání zásilek Slovenské pošty. DHL Online Shipping Tato webová aplikace společnosti DHL slouží pro vytvoření, objednání, sledování a správu expresních zásilek společnosti DHL. K tomu nabízí několik rozšiřujících služeb jako vedení adresáře, evidenci historie zásilek po dobu 90 dnů, zjišťování stavu zásilky apod. S jeho pomocí můžete tisknout štítky, plánovat vyzvednutí zásilek kurýrem, ukládat adresy, sledovat zásilky a mnoho dalšího. Pokud je rychlost a přesnost Vaše priorita, DHL Online Shipping zjednoduší proces přípravy Vašich zásilek a eliminuje papírování. Toto řešení je ideální pro malé a středně velké společnosti, vedoucí administrativy, recepční, obchodníky na pracovních cestách či pro kohokoli, kdo je často v terénu. Řešení DHL Online Shipping se snadno používá a není k němu nutné žádné školení. [5] Ve srovnání s aplikací Poštmistr se jedná o jednoúčelový software sloužící primárně pro podávání zásilek a jejich jednoduchou evidenci. Podstatným rozdílem je centralizace dat a klient server architektura, kde funkci klienta plní webový prohlížeč. Softwarové produkty společnosti TNT Přepravní společnost TNT nabízí ve srovnání s ostatními významnými hráči na našem trhu v oblasti poskytování poštovních a přepravních služeb řadu softwarových produktů, které nabízejí služby od jednoduchého sledování zásilky a zjištění ceny až po sofistikované integrace s podnikovými informačními systémy. 19

20 mytnt Aplikace ExpressManager je univerzální online aplikací umožňující komunikaci s TNT z jakéhokoli místa na světě. Toto bezpečné, na míru šité, dynamické a pro uživatele snadné řešení je ideální pro všechny zákazníky s přístupem na Internet, nehledě na objem přepravovaných zásilek. Online sledování pohybu zásilky, vlastní adresář příjemců a integrovaný nástroj pro zjišťování cen za přepravu jsou samozřejmostí. [6] Jedná se tedy o obdobu aplikace DHL Online Shipping. ExpressShipper Jedná se o aplikaci z nabídky společnosti TNT rozšiřující možnosti webové aplikace mytnt. Ideální offline aplikace pro zákazníky se střední frekvencí přepravních požadavků, která umožňuje instalaci na PC bez připojení k internetu. Stejně jako produkt mytnt, nahrazuje ExpressShipper telefonování na Oddělení služeb zákazníkům TNT a rukou psané přepravní dokumenty. Jako volitelné komponenty jsou k dispozici online žádost o vyzvednutí, personalizovaný ceník a sledování stavu zásilek. [6] Stejně jako aplikace Poštmistr či ProfiPost nabízí možnost instalace lokálně nebo se sdílením dat v rámci lokální sítě. Obsahuje evidenci adresátů, zásilek a podporu pro přenos dat o podaných zásilkách do centrálního systému společnosti TNT, objednávku jejich vyzvednutí a přenos potvrzení o objednaných zásilkách zpět z centrálního systému do aplikace. ExpressManager Nejpokročilejším systémem pro správu a hromadné podání zásilek společnosti TNT je aplikace ExpressManager. Jedná se o robustní systém navržený pro instalaci na serveru, umožňující integraci s firemními systémy zákazníka. Stěžejní vlastností tohoto produktu je schopnost automatického importu a exportu dat v libovolném formátu, validace adres a tisk štítků pro označení vašich balíčků. Tato volba je ideální pro velké zákazníky s náročnými požadavky na automatizaci logistických procesů. [6] Tento systém je určen pro zákazníky s velkým počtem podávaných zásilek, kde má smysl se zaměřit na integraci a automatizaci procesů správy a podání zásilek v co možná největší míře. Architektura klient server umožňuje, aby se na zmíněných procesech podílelo více pracovních stanic uvnitř lokální sítě. Kromě online komunikace s centrálním systémem TNT nabízí tato aplikace přibližně stejné funkce, jako Podání Online České pošty. ExpressConnect Tato aplikace je určena pro integraci s vlastním informačním systémem, kterým může být např. elektronický obchod. Propojuje tak firemní procesy (např. prodej v e shopu) s přepravními procesy společnosti TNT. Integrace umožňuje začlenění procesů výpočtu ceny zásilky, objednání její přepravy a možnost sledování jejího stavu. Komunikace probíhá pomocí XML zpráv. Softwarová podpora dalších významných přepravních společností V současnosti na našem trhu v dané oblasti existují i další přepravní společnosti, jejichž celkový podíl na přepravě není zdaleka zanedbatelný. Jedná se především o společnosti PPL 20

21 CZ, s.r.o., TOPTRANS EU, a.s. a DPD. Všechny tři nabízejí na svých webových stránkách softwarovou podporu pro podání zásilek a sledování jejich stavu prostřednictvím jednoduchých webových aplikací. Ty ale neslouží pro evidenci zásilek. ProfiPost Aplikace ProfiPost společnosti Albacon představuje do značné míry obdobu programu Poštmistr. Umožňuje připojit počítač jako terminál frankovacích strojů ULTIMAIL a OPTIMAIL a slouží k přípravě poštovních zásilek k odeslání a evidenci veškeré firemní pošty. [7] Nenabízí žádnou významnou funkci navíc. Jedná se opět o desktopovou aplikaci s možností sdílení dat mezi více pracovními stanicemi v rámci firemní sítě. Nejpodstatnější rozdíl se týká podpory frankovacích strojů. Aplikace ProfiPost slouží především jako softwarová podpora pro frankovací stroje společnosti Francotyp Postalia AG, narozdíl od programu Poštmistr, který podporuje frankovací stroje společnosti Neopost. 21

22 Popis Systému Z analýzy dostupných konkurenčních systémů plyne, že drtivá většina poskytovatelů poštovních služeb nabízí více či méně sofistikované řešení pro podej a případně i správu zásilek. Systémy, které nepředstavují nástroj pro správu zásilek, zpravidla jsou nějakým způsobem integrovány s interními informačními systémy, které tyto funkce poskytují. Může se jednat jednoduše například o vhodné propojení elektronického obchodu za účelem částečného zautomatizování procesů podávání zásilek nebo o informační systém, jehož účelem je primárně správa zásilek. Tyto systémy se v praxi zpravidla označují termínem spisová služba. U většiny systémů zmíněných poskytovatelů existuje potenciál pro rozšíření služeb souvisejících se správou a hromadným podáním zásilek. Do jaké míry by však vývoj aplikace adaptované na služby určitého poskytovatele dokázal rozšířit funkcionalitu, záleží na konkrétním poskytovateli. V případě České pošty nebo např. TNT by to nebylo až tak zásadní. Naopak u PPL či DPD je tento prostor relativně velký. Co však na trhu chybí, a v čem je velký obchodní potenciál, je systém, který by umožňoval správu a hromadné podání zásilek všech poskytovatelů poštovních služeb. Přínosem by nebyla pouze integrace služeb všech významných poskytovatelů za účelem možnosti zpracování a podání zásilky jakéhokoli poskytovatele, což je zřejmý požadavek např. velkého počtu provozovatelů elektronických obchodů, ale i značná úspora na vývoji a údržbě takovéto aplikace. Vhodným návrhem je možné docílit otevřenosti systému pro další poskytovatele a jejich nabízené služby. Dalším charakteristickým rysem aplikace přinášejícím nesporné výhody by bylo vytvoření jednotného rozhraní pro zadávání a aktualizaci nabízeného portfolia zásilek včetně jejich cen, parametrů a ostatních podmínek. To by mělo za důsledek nejen úsporu při údržbě aktualizace, ale pokud by na tom byli zainteresováni sami poskytovatelé, byly by tyto informace s velkou pravděpodobností aktualizovány s menším zpožděním než v případě, kdyby je aktualizovali sami podavatelé nebo by tato údržba byla prováděna jiným subjektem. Z autorových zkušeností s aktualizací cen a typů zásilek České pošty je zřejmé, že při podpoře tolika poskytovatelů by se mohla aktualizace obchodních podmínek stát palčivým problémem vedoucím k nespokojenosti uživatelů. Stačí si představit např. nějaký elektronický obchod, který nabízí možnost doručení zásilky pomocípěti různých společností, a že každá z nich provede aktualizaci cen dvakrát za rok. Pokud by změna obchodních podmínek byla uveřejněna těsně před jejich samotnou změnou, jako to nejednou udělala Česká pošta, v nejhorším případě by tento elektronický obchod musel řešit skoro každý měsíc problémy s podejem zásilek. S implementací jednotného rozhraní pro aktualizaci typů zásilek, jejich cen a další podmínek, jež by byla prováděna např. samotnými poskytovateli poštovních služeb, vyvstává otázka, jak tyto informace dostat do systému. Odpověď na tuto otázku poskytne vhodný návrh architektury aplikace. Nabízí se dvě základní varianty. Buď implementace systému převážně jako desktopové aplikace, nebo využít v dnešní době velmi populární architektury klientserver. Každá z těchto variant má svoje výhody i nevýhody. Výhodou řešení pomocí architektury desktopové aplikace je jednoznačně menší závislost na jiných systémech, 22

23 počítačích či počítačové síti. To se projevuje nejen ve větší spolehlivosti aplikace např. na výpadky sítě nebo zahlcení serveru, ale i v lepší interakci se systémem, a to zejména co se týče odezvy systému na požadavky uživatele. Odpadá zde i problém přenosu většího objemu dat. Dalším pozitivním přínosem je více možností při vývoji uživatelského rozhraní, což má za následek subjektivně příjemnější pocit při ovládání aplikace. Současný trend vývoje aplikací však ve většině případů upřednostňuje architekturu klient server. Není tomu tak náhodou. V dnešní době jsou počítačové sítě dimenzovány na přenos velkých objemů dat, malé odezvy a celkově jsou relativně spolehlivé. Stejně tak i vývoj uživatelského rozhraní zaznamenal pokrok. Sice pořád nedokáže poskytnout takový komfort jako v případě desktopových aplikací, ale výhody architektury klient server přesto jednoznačně převyšují nad jejími negativy. Hlavními problémy, kterými trpí desktopové aplikace, a které řeší architektura klient server, jsou zejména platformová nezávislost, absence nutnosti instalace aplikace a distribuce jejich aktualizací a dostupnost aplikace z jakéhokoli počítače v dané síti (v případě internetu je to na celém světě). Kontroverzní výhodou je centralizace dat. Je snadné si představit situace, kdy je tohle spíše nevýhodou. Např. při velkých objemech dat, kdy v kombinaci s velkým množstvím uživatelů rostou nároky na hardwarové vybavení pro provoz takového systému. Nebo v případě požadavků na zvýšení zabezpečení dat, kdy uživatelé nemusejí být ochotní data nechat spravovat jinými subjekty, popř. kdy je třeba zabezpečit sofistikovanější mechanismy pro zvýšení bezpečnosti. Výhodou centralizace dat je ještě větší nezávislost aplikace, kdy není třeba řešit, kam a jakým způsobem umístit uložiště dat. Tato nezávislost řeší i problém, jak jednoduše v případě aktualizace aplikace aktualizovat i samotnou strukturu uložiště, popř. data v něm. Centralizace dat je tedy jedna z možných odpovědí na výše položenou otázku, jak zabezpečit distribuci změn obchodních podmínek projevujících se v aktualizaci typů zásilek, jejich cen a další parametrů systému. Další výhodou faktu, že všechna data jsou uložena pohromadě, je možnost jejich zpracování pro další účely, jako např. vyhodnocování chování zákazníků v reakci na změnu podmínek poskytovatelů, vyhodnocování jejich preferencí, vedení statistik o rychlosti a spolehlivosti doručování zásilek a vytváření dalších statistik. Tato data, získaná od velkého počtu uživatelů, by mohla být velice cenná a vzhledem k tomu, že by v případě jejich nezveřejnění představovalo jejich vlastnictví nemalou konkurenční výhodu, mohla by být snadno zpeněžena, případně se stát nástrojem ovlivňování situace na trhu poštovních služeb. Centralizace dat zjevně v tomto případě nabízí obrovské přínosy, které převažují nad jejími nevýhodami, a proto je architektura klient server s centralizací dat pro tento systém nejvhodnější volbou. Nejedná se však ve všech případech o ideální řešení. Příkladem mohou být pracoviště bez možnosti připojení k internetu. Proto musí výsledný návrh umožňovat i implementaci systému čistě jako desktopové aplikace. Navrhovaná aplikace by neměla představovat uzavřený systém. Vhodným návrhem by bylo dobré zohlednit i možnost využívání funkcí systému jinými systémy. Může se například jednat o již existující systémy pro správu zásilek, kde chybí pouze funkce zjišťování stavu zásilky popř. kontrola adres. S výhodou lze tento způsob využívání systému implementovat např. přes rozhraní webových služeb. 23

24 Analýza systému V této podkapitole jsou popsány a specifikovány konkrétní požadavky uživatelů kladené na systém. Cílem práce však není uvést jejich kompletní výčet a úplnou specifikaci každého z nich. Práce se omezuje pouze na ty nejdůležitější z nich formující charakter celého systému, který je nutno znát pro vytvoření vhodného návrhu aplikace. Specifikace požadavků a určení typů uživatelů zároveň definuje hranice systému. Uživatelem je myšlen subjekt, který nějakým způsobem využívá funkce systému. Největší část požadavků představuje funkcionalita zabezpečující správu a podej zásilek, tj. funkce určené pro podavatele. Dalšími subjekty využívajícími systém budou poskytovatelé poštovních služeb spravující své portfolio nabízených služeb, manažeři generující statistiky a externí uživatelé využívající určité části systému přes rozhraní webových služeb. To, za jakým účelem budou jednotliví uživatelé systém využívat, lze definovat pomocí rolí. V terminologii UML se jedná o tzv. aktéry. Následující obrázek představuje use case diagram celého systému zachycující jednotlivé aktéry, jejich požadavky a vymezuje tak hranice celého systému. obr. 10: Use case diagram celého systému 24

25 V systému se nachází 6 důležitých aktérů: Podavatel: jedná se o podavatele, který zpracovává a podává zásilky, ale nemá možnost měnit důležitá nastavení systému. Superpodavatel: představuje podavatele s oprávněním upravovat nastavení systému. Poskytovatel služeb: tento aktér reprezentuje poskytovatele poštovních služeb, jehož hlavní funkcí je udržovat nastavení typů zásilek, jejich parametrů, cen apod. aktuální. Manažer: role, která umožňuje generování a celkovou správu statistik. Může být dále dekomponována podle toho, jaké statistiky může využívat. Správce systému: uživatel, který je zodpovědný za správu systému jako celku. Jedním z aktérů zobrazených v diagramu je i Čas. Nepředstavuje žádného uživatele, ale pouze fakt, že některé funkce systému jsou ovládány časem. V případě tohoto systému se jedná o archivaci dat, kterou je možné nastavit tak, aby se spouštěla sama pravidelně v určitý čas. Posledním zobrazeným aktérem je Uživatel. Také nereprezentuje žádného konkrétního uživatele. Slouží pouze jako prostředek abstrakce, tj. v tomto případě jako předek většiny ostatních aktérů. Většina ze zobrazených případů užití je dekomponována a popsána níže. Ostatní případy užití: Registrace: představuje registraci podavatele. Ten si pak může zakoupit licenci opravňující ho využívat systém podle typu zakoupené licence. Přihlášení: jedná se o přihlášení se uživatele do systému. Je společné všem aktérům až na Čas a Externího uživatele, kde postrádá smysl. Odhlášení: podobné jako v předchozím případě. Tentokrát se ale jedná o odhlášení uživatele ze systému. Reportování problému: tento případ užití reprezentuje proces nahlášení problému s obsluhou aplikace. Správa statistik: jedná se o případy užití související s využíváním statistik, tj. jejich zobrazování případně exportování. Archivace dat: funkce archivace dat uloží specifikované zásilky včetně všech s nimi souvisejících informací do archívu a podavatelům se budou zobrazovat pouze po vstupu do tohoto archívu. Správa zásilek Následující use case diagram zobrazuje souhrn případů užití představujících jádro aplikace. Jedná se o funkce sloužící především pro správu zásilek, tj. funkce využívané podavatelem. 25

26 obr. 11: Use case diagram správy zásilek Popis jednotlivých případů užití: Vytvoření zásilky: proces vytvoření zásilky představuje nejen vytvoření nového objektu zásilky, ale i vyplnění základních údajů podle aktuálního nastavení aplikace, tj. například údajů o odesílateli, příjemci či typu zásilky. Editace zásilky: představuje úpravu údajů o zásilce. Smazání zásilky: smazáním zásilky je tento záznam trvale odstraněn z aplikace. Kontrola zásilek: pomocí této funkce jsou zkontrolovány dané zásilky podle předem daných kritérií. To znamená, že si uživatel může předem zvolit, které druhy kontroly chce nad danými zásilkami provést. Může se jednat o kontroly hmotností, dobírkových částek, udaných cen, adres ap. Stejně tak musí mít podavatel možnost výběru jen určitých zásilek podle daných kritérií. Toho se docílí implementací tzv. filtrů na zásilky. Filtr může představovat např. časové rozmezí, seznam odesílatelů čí příjemců nebo typ zásilky. Tyto filtry budou využívány nejen pro zobrazování zásilek a v tomto případě i jejich kontrolu, ale i pro mnoho dalších funkcí, jako např. smazání zásilek, jejich hromadná změna, vyhledávání atd. 26

27 Vyhledávání zásilky: bez funkce vyhledávání zásilek podle zadaných údajů by se v mnoha případech stala správa zásilek těžkopádnou, a proto tato funkce musí být dostatečně robustní, aby dokázala seznamy zásilek prohledávat inteligentně. Příkladem může být rozdělení slov, ze kterých se skládá název města, a vyhledávání podle těchto jednotlivých částí. Hromadná změna zásilek: jedná se o hromadnou editaci zásilek. Zjištění stavu doručení zásilky: pokud bude poskytovatel umožňovat zjištění stavu zásilky, aplikace se na žádost podavatele pokusí pro dané zásilky tento stav zjistit a uložit ho. Zobrazení pohybu zásilky: zobrazí přehledně dostupné stavy o doručení zásilky včetně relevantních časových údajů. Přidělení podacího čísla: podacím číslem se rozumí identifikátor zásilky sloužící poskytovateli pro manipulaci s ní. V případě České pošty je u větších podavatelů běžný postup takový, že je podavateli přidělen určitý prostor těchto podacích čísel a je na něm, jak tato čísla jednotlivým zásilkám přiděluje. Funkce přidělení podacího čísla tedy vygeneruje nové číslo podle konkrétního nastavení řad podacích čísel pro daný typ zásilky. Uzavření podeje: uzavření podeje představuje označení zásilek za dostatečně vyplněné a připravené k podání. Tyto zásilky už potom není možné běžným způsobem editovat. Uzávěrky jsou pak využívány jako sdružený seznam zásilek, pro které bude například generován nějaký tisk či elektronický výstup sloužící pro podání. V podstatě se jedná jeden z filtrů popsaných výše. Úprava uzávěrky: proces sloužící pro editaci již uzavřených zásilek. Notifikace adresátů zásilek: notifikace adresátů je jednou z více funkcí pro notifikaci, avšak zde je pro jednoduchost uvedena jako jediná. Jedná se např. o odeslání ové zprávy adresátům zásilek podle předem definované šablony. Adresáti takto mohou být informováni například o odbavení zásilky a jejich konkrétních parametrech, datu expedice apod. Stejně tak by v aplikaci neměla chybět notifikace odesílatelů, která by měla smysl pro došlé zásilky. Upozornění o změně stavu zásilky: jedná se opět o jeden z druhů notifikace popsané u předešlého případu užití. V tomto případě je odesílána zpráva adresátům o změně stavu zásilek. Systém by měl být vhodně navržen tak, aby umožňoval jednoduché rozšíření o způsob doručení dané zprávy. Evidenční a dekádní lístky: tento případ užití se týká generování, zobrazování, tisku a celkové správy evidenčních a dekádních lístků. Správa adresáře Správa adresáře zahrnuje především udržování seznamu kontaktů, které je možné využít hlavně jako odesílatele či příjemce zásilek. Obsahuje však i podpůrné funkce, jako například kontrolu kontaktů, jejich adres a adresáře jako celku, či přímo doplňování adresy pomocí 27

28 databáze DDM (Databáze Dodacích Míst) udržované Českou poštou. Následující use case diagram zobrazuje přehledně základní případy užití, které by v systému neměly chybět. obr. 12: Use case diagramsprávy adresáře Popis jednotlivých případů užití: Vytvoření kontaktu: založí nový kontakt. Před jeho uložením provede kontrolu, jestli se náhodou tento kontakt v databázi již nenachází. Editace kontaktu: upraví údaje již existujícího kontaktu. V souvislosti s touto funkcí vyvstává otázka, jakým způsobem budou udržovány informace o adresátech či odesílatelích zásilek. Buď se údaje z daného kontaktu nakopírují do zásilky, nebo zásilka bude obsahovat ukazatel na daný kontakt. Z hlediska návrhu databáze je čistějším řešením druhá varianta, která na rozdíl od první neporušuje tzv. 3. normální formu. Tím je eliminována redundance dat vznikajících např. vytvořením většího počtu zásilek se stejným adresátem. 3. normální forma má však za důsledek i odstranění tzv. aktualizačních anomálií, což je v případě správy zásilek naopak důležitým požadavkem. Je li evidována už odeslaná zásilka a po nějaké době se změní adresa kontaktu, kterému byla tato zásilka odeslána, neměla by se tato změna u zásilky nijak projevit. Ukládání odkazů na kontakt adresáta a odesílatele je jednoznačně výhodnějším řešením, ale je třeba vhodným návrhem vyřešit zmínění 28

29 problém s odstraněním aktualizačních anomálií. Toho lze docílit např. tak, že při editaci kontaktu se v případě, že tento kontakt obsahuje nějaká zásilka, vytvoří jeho kopie, která je následně editována, a původní kontakt už nebude mít podavatel možnost použít. Bude v databázi udržován, dokud budou existovat zásilky, které se na něj odkazují. Tohle řešení přináší i další výhodu. Pokud bude podavatel měnit adresu, na kterou se odkazují dosud nepodané zásilky, bude moci být změna provedena u všech těchto zásilek. Smazání kontaktu: provede kontrolu, jestli se na daný kontakt neodkazuje nějaká zásilka a v případě, že ano, kontakt se pouze skryje, pokud ne, kontakt bude vymazán. Uložení adresáta: uloží adresáta zásilky jako nový kontakt do adresáře. Uložení odesílatele: stejné jako v předešlém případě, ale jako nový kontakt uloží do databáze odesílatele zásilky. Vyhledání kontaktu: vyhledávání kontaktů je při správě objemnějšího adresáře důležité a proto je třeba stejně jako v případě vyhledávání zásilek implementovat toto vyhledávání jako dostatečně obecné. Kontrola kontaktů: funkce kontroly kontaktů zahrnuje jako kontrolu samostatných kontaktů, tak i adresáře jako celku, což znamená např. kontrolu duplicitních kontaktů. Opět je možné předem specifikovat, co všechno se má kontrolovat. Doplnění adresy: funkce přímo související s využitím DDM. Adresy kontaktů budou adresami shodnými s těmi, které jsou obsaženy v databázi DDM. Vyplňování adresy kontaktu v aplikaci tak bude představovat spíše výběr adresy z databáze DDM. Správa exportů a importů Modul exportů a importů dat je nepostradatelnou součástí systému pro podej zásilek. Zabezpečuje nejen propojení s externími systémy (většinou spisovými službami), ale i generování samotných výstupů nezbytných pro podej zásilek. Ty se samozřejmě liší podle konkrétního poskytovatele. Propojení s externími systémy může být realizováno výměnou zpráv např. prostřednictvím textového souboru, načítání z databáze, přes http požadavky atp. Návrh aplikace musí být dostatečně obecný, aby umožňoval snadné rozšíření o další způsoby exportů a importů. Následující diagram případů užití obsahuje kromě obecného exportu a importu představující výše zmíněné propojení s externími systémy také několik základních importů a exportů dat od, popř. pro Českou poštu. Nemá smysl jednotlivě popisovat tyto případy užití. 29

30 obr. 13: Use case diagram správy exportů a importů Správa tisků Správa tisků představuje jednoduchý modul, který je ale stejně jako v předchozím případě třeba navrhnout vhodným způsobem tak, aby byl snadno rozšiřitelný o další způsoby tisku. Na následujícím obrázku je zachycen use case diagram s třemi hlavními případy užití. obr. 14: Use case diagram správy tisků Význam těchto případů užití je následující: 30

31 Tisk výkazu: jedná se interní tisky aplikace, například různé statistiky podaných zásilek v podobě denních, týdenních či měsíčních výkazů apod. Tisk formuláře: představuje tisk formulářů specifických pro konkrétního podavatele. Mohou to být například adresní štítky, které se tisknou pro každou zásilku zvlášť, nebo soupisy podávaných zásilek v podobě podacích archů či různých průvodek atd. Nastavení tisku formuláře: tento případ užití reprezentuje proces nastavení parametrů tisku. Existují obecné parametry nastavení, které jsou společné všem tiskům, a potom individuální nastavení jednotlivých tisků. Správa středisek V případě větších podavatelů zásilek České pošty, je častokrát mezi tímto podavatelem a Českou poštou uzavřena smlouva a podavatel ke každému typu zásilky, který používá, dostane k dispozici určitý prostor podacích čísel (běžně nazýván termínem řada podacích čísel či zkráceně podací řada), který je unikátní a tato čísla nemohou být použita nikým jiným. Nastavení těchto údajů tedy přísluší jednomu odesílateli. Systém musí umožňovat správu zásilek s různými odesílateli a tedy různě nastavenými podacími řadami. Odesílatele a jeho nastavení tak reprezentuje právě tzv. středisko. Má však v aplikaci více funkcí než jen reprezentaci odesílatele. Slouží i jako příjemce u došlé pošty a je dokonce možné, aby jeden odesílatel byl reprezentován více středisky. To je výhodné např. v situaci, kdy odchozí poštu stejného odesílatele zpracovává více pracovníků. Každý z nich pak má možnost používat vlastní část přidělené podací řady. Středisko tedy může reprezentovat nejen odesílatele, ale i pracovníka. Dalším způsobem využití středisek může být situace, kdy jedna firma, která má smlouvu s Českou poštou, zpracovává poštu jiných firem. Pak odesílatel zásilky je reprezentován střediskem představujícím firmu, jejíž pošta je zpracovávána, ale podávána je jménem firmy zpracovávající tuto poštu. Jsou tedy použita její podací čísla. Střediska hrají při podávání zásilek důležitou roli a jejich správa by neměla být přístupná všem pracovníkům zpracovávající poštu. To je jeden z důvodů, proč jsou podavatelé rozděleni do dvou rolí Podavatelé a Superpodavatelé. Superpodavatel je tím, kdo je zodpovědný za správu a nastavení středisek a ostatních důležitých parametrů systému relevantních pro podavatele. V následujícím use case diagramu jsou uvedeny základní funkce pro správu středisek. 31