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

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 

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. 

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.   

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     

 

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

Použité technologie .................................................................................................................. 40  Java ....................................................................................................................................... 40  JAAS ...................................................................................................................................... 40  Hibernate .............................................................................................................................. 41  Web services ......................................................................................................................... 41  Návrh systému .......................................................................................................................... 42  Modul zásilek ........................................................................................................................ 42  Modul uživatelů .................................................................................................................... 49  Modul adresáře .................................................................................................................... 50  Modul kontrol ....................................................................................................................... 51  Modul exportů a importů ..................................................................................................... 53  Modul notifikace ................................................................................................................... 57  Modul archivace ................................................................................................................... 59  Struktura a rozmístění systému ............................................................................................ 60  Závěr ......................................................................................................................................... 62  Použité zdroje ........................................................................................................................... 63 

Ú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  2002.  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  2002.  Jednalo  se  7   

o desktopovou aplikaci, kterou začala vyvíjet společnost ATAX SOFTWARE s.r.o. v roce 2009.  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   

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   

  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   

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   

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   

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   

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   

  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   

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   

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   

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   

„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   

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   

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   

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  klient‐ server.  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   

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   

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   

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   

  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   

•

• •

• •

•

• •

•

•

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í  emailové 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   

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   

• • • •

•

•

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   

  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   

• •

•

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   

  obr. 15: Use‐case diagram správy středisek 

Význam jednotlivých případů užití je uveden níže:  • Vytvoření střediska: představuje vytvoření nového střediska.  • Editace  střediska:  edituje  údaje  střediska,  jako  např.  adresu  odesílatele  a  nastavení  smlouvy.  • Smazání střediska: vymaže středisko ze systému včetně jeho nastavení (podací řady  apod.). 

Správa uživatelů  Aktér  Superpodavatel  je  nejen  zodpovědný  za  správu  a  nastavení  středisek,  ale  také  za  správu uživatelů. U větších podavatelů to bude v praxi vypadat tak, že po zakoupení licence  si k ní podavatel bude moci vytvořit libovolný počet superpodavatelských účtů, které budou  představovat  osoby  zodpovědné  za  podej  zásilek.  Ti  provedou  všechna  potřebná  důležitá  nastavení  a  vytvoří  podavatelské  účty,  jež  budou  sloužit  především  ke zpracovávání  a  podávání zásilek bez toho, aniž by mohly měnit důležitá nastavení, za která je zodpovědný  Superpodavatel.  Na  následujícím  diagramu  případů  užití  jsou  zobrazeny  základní  funkce  systému související se správou uživatelů.    

32   

  obr. 16: Use‐case diagram správy uživatelů 

Případy užití související se správou uživatelů:  • Vytvoření podavatele: založení nového podavatelského účtu.  • Editace podavatele: editace údajů podavatelského účtu.  • Smazání podavatele: deaktivace či smazání podavatelského účtu. 

Správa podavatelského nastavení  Část systému pro správu podavatelského nastavení obsahuje nastavení parametrů systému,  ke  kterým  je  oprávněn  i  běžný  Podavatel.  Zpravidla  se  jedná  o  parametry,  jejichž  hodnoty  v praxi  nastavuje  běžný  uživatel  systému  a  jejich  častá  změna  nebo  relativní  nedůležitost  z hlediska  celkového  procesu  podeje  zásilek  by  zbytečně  zatěžovala  Superpodavatele.  Odpovědnost je tak přenechána na Podavateli.   

  obr. 17: Use‐case diagram správy podavatelského nastavení 

Funkce,  které  může  Podavatel  v rámci  správy  podavatelského  nastavení  využívat,  jsou  popsány následujícími případy užití:  33   

• • •

•

Nastavení  podavatelského  účtu:  reprezentuje  editaci  údajů  účtu  podavatele  zahrnujících např. změnu jména a hesla.  Nastavení aplikace: tento případ užití představuje běžná nastavení systémů týkající se  především vzhledu a chování aplikace, které je individuální pro daného Podavatele.  Nastavení  notifikace  adresátů:  notifikace  adresátů  je  funkce  týkající  se  odchozích  zásilek. Její smysl spočívá v upozornění adresátů zásilek na nějakou skutečnost. Touto  skutečností  může  být  například  změna  stavu  doručení  zásilky  zjištěná  od  poskytovatele.  Upozornění  samotné  je  většinou  realizováno  prostřednictvím  odeslané  emailové  zprávy.  Nastavení  notifikace  adresátů  zahrnuje  tedy  především  definici šablon, podle kterých se tyto emailové zprávy generují.  Nastavení předplnění: předplnění zásilek je jedna z doplňujících funkcí systému, které  zefektivňují proces vytváření nových zásilek. V podstatě se jedná o definici výchozích  údajů, které má zásilka po vytvoření obsahovat. V případě, že Podavatel zadává větší  množství  stejných  zásilek,  bylo  by  velice  neefektivní  vyplňovat  pokaždé  ty  stejné  údaje,  jako  je  např.  hmotnost,  cena  dobírky  a  typ  dobírkové  poukázky,  seznam  doplňkových služeb apod. Proto má podavatel možnost definovat výchozí nastavení  nově  vytvořené  zásilky,  které  se  bude  vztahovat  například  k  danému  středisku,  odesílateli,  adresátovi,  typu  zásilky  či  jejich  libovolné  kombinaci,  která  v  daném kontextu bude dávat smysl.  

Správa superpodavatelského nastavení  Podavatelova důležitá nastavení systému je oprávněn provádět pouze osoba přihlášená pod  superpodavatelským účtem, protože se jedná o nastavení významným způsobem ovlivňující  proces správy a podeje zásilek. Use‐case diagram níže zobrazuje ty nejdůležitější z nich.   

34   

  obr. 18: Use‐case diagram správy superpodavatelského nastavení 

Význam případů užití uvedených v předchozím use‐case diagramu:  • Nastavení smlouvy: smlouva představuje uzavřený kontrakt o podávání zásilek mezi  podavatelem a poskytovatelem poštovních služeb. Definuje způsob, jakým je možné  zásilky  podávat.  V případě  uzavření  smlouvy  podavatele  s  Českou  poštou  je  podavateli  přidělen  jednoznačný  identifikátor  (definovaný  tzv.  číslem  obvodu,  zákaznickým číslem a typem podavatele), který slouží např. pro generování podacích  řad,  dále  jsou  mu  v případě  potřeby  přiděleny  příslušné  podací  řady,  je  definováno  číslo  účtu  pro  platby  atp.  Případ  užití  Nastavení  smlouvy,  tak  reprezentuje  vložení  těchto údajů do systému. Nutno podotknout, že toto nastavení není pro podavatele  globální, ale týká se vždy daného střediska. Podřízená střediska mohou používat buď  smlouvu nadřazeného střediska, nebo svoji vlastní.   • Nastavení  podacích  čísel:  tento  případ  užití  zahrnuje  nastavení  řad  podacích  čísel,  které  se  týkají  opět  konkrétního  střediska.  Podací  řada  většinou  přísluší  k danému  typu zásilky. Ten může definovat odlišný formát podacího čísla, než jaký je definován  pro jiný typ zásilky. Dále platí, že typ zásilky může mít definováno více podacích řad,  jejichž konkrétní využití závisí na parametrech podávané zásilky. Například jiná podací  řada je použita pro Doporučenou zásilku (typ zásilky České pošty) s a bez dobírky.  Je zřejmé, že podací čísla musí být v rámci poskytovatele poštovních služeb unikátní.  Například u České pošty je tato jedinečnost omezena vždy pouze na jeden rok. Pokud  35   

•

•

•

•

•

•

je  podavateli  pro  konkrétní  typ  zásilky  přidělena  pouze  jedna  nebo  několik  málo  souvislých podacích řad a na zadávání zásilek do systému a jejich podeji by pracovalo  více  Podavatelů,  je  nezbytné  zajistit  rozdělení  konkrétní  řady  na  více  souvislých  segmentů. Důvodem je skutečnost, že podavateli je nejen přidělena konkrétní řada,  ale  může  dostat  i  lepící  štítky  obsahující  konkrétní  čísla  spolu  s čárovými  kódy.  Tyto  štítky jsou mezi Podavatele rozděleny po určitých souvislých segmentech, a proto je  to stejné potřeba provést i v systému. Nastavení podacích čísel tedy bude zahrnovat i  nepovinnou definici intervalu přidělovaných podacích čísel.  Nastavení  poukázek:  tento  případ  užití  sdružuje  jednotlivá  nastavení  pro  správu  a  podej poštovních poukázek. Jedná se o specifikum České pošty a proto se v základním  nastavení  aplikace  ani  nebude  zobrazovat.  Bude  rozděleno  podle  jednotlivých  typů  poukázek,  např.  poukázky  B,  poukázky  A.  V rámci  nastavení  poukázek  B  bude  obsahovat  například  číslo  smlouvy  pro  podej  poukázek,  způsob  podeje  a  jeho  nastavení, čísla účtů ap.  Nastavení  stavů  zpracování:  stavy  zpracování  zásilek  jsou  jedním  z nástrojů,  jak  rozdělit proces zpracování zásilek mezi více Podavatelů. Konkrétní seznam stavů má  možnost  si  nadefinovat  sám  Superpodavatel.  Jejich  konkrétní  podoba  většinou  odpovídá  stavu  zpracování,  tj.  např.  Importováno,  Zadáno,  Zváženo,  Odbaveno,  Připraveno k podání či Podáno.  Nastavení upozornění na změnu stavu zásilek: upozornění na změnu stavu zásilek se  do  značné  míry  podobá  již  popsané  notifikaci  adresátů.  Týká  se  ale  tentokrát  odchozích  i  došlých  zásilek.  Opět  je  podle  nadefinované  šablony  odeslána  buď  adresátovi,  nebo  v tomto  případě  odesílateli  emailová  zpráva  informující  o  změně  stavu  zpracování  zásilky.  Stejně  jako  v případě  notifikace  adresátů  je  možné  nadefinovat, zda má být toto upozornění prováděno automaticky, a pokud ano, tak  jak  často,  tj.  jestli  ihned  po  změně  stavu,  nebo  po  určité  době  případně  za  splnění  obou podmínek.  Nastavení emailového účtu: provede nastavení emailových účtů pro odesílání zpráv.  Toto  nastavení  je  prováděno  pro  jednotlivá  střediska  a  opět  s možnosti  použít  nastavení z nadřazeného střediska.  Nastavení archivace dat:u některých podavatelů může archivace dat hrát ve správě a  podeji  zásilek  důležitou  roli.  Například  přestože  už  byly  odchozí  zásilky  podány  a  doručeny  adresátům,  je  potřeba  je  po  nějakou  dobu  stále  evidovat.  Nebudou  v systému hrát už žádnou roli, ale v případě potřeby je nutné mít je k dispozici. Jak už  bylo  uvedeno  v úvodním  use‐case  diagramu,  tuto  archivaci  provádí  Superpodavatel  nebo  je  prováděna  automaticky  systémem.  Za  její  nastavení  je  odpovědný  Superpodavatel.  Obecné  nastavení  aplikace:  tento  případ  užití  definuje  obecná  nastavení  systému,  která  se  mohou  týkat  i  nastavení  jednotlivých  poskytovatelů.  Definuje  se  zde  například seznam používaných funkcí a modulů, které určují vzhled a obsah aplikace. 

36   

Správa licencí  Licence  reprezentuje  podavatele  zaregistrovaného  v systému.  Aby  mohl  aplikaci  využívat,  potřebuje  získat  oprávnění  k využívání  systému,  které  definuje,  jakým  způsobem  může  aplikaci  využívat,  tj.  na  jak  dlouho,  s  jakými  funkcemi  (moduly),  s kolika  středisky,  podavatelskými účty apod.   

  obr. 19: Use‐case diagram správy licencí 

Správa licencí zahrnuje tyto případy užití:  • Zaslat  žádost  o  aktivační  kód:  aktivační  kód  představuje  sériový  klíč  opravňující  k využívání  aplikace.  Obsahuje  zašifrované  informace  o  době  expirace,  modulech  či  funkcích,  které  je  podavatel  oprávněn  využívat,  a  ostatní  výše  zmíněné  parametry.  Tento případ užití je tedy objednávkou práv k využívání aplikace.   • Zaslat  žádost  o  technickou  podporu:  znalost  obchodních  podmínek  jednotlivých  poskytovatelů poštovních služeb souvisejících s funkcemi tohoto systému je nezbytná  nejen  pro  pracovníky,  kteří  se  podílejí  na  jeho  tvorbě  a  údržbě,  ale  i  pro  mnoho  podavatelů.  Stejně  tak  nedostatečná  znalost  obsluhy  aplikace  může  negativně  ovlivňovat efektivitu procesu zpracování a podeje zásilek. Proto se autor domnívá, že  by bylo vhodné provozovat call centrum, kde by každý den byli operátoři připraveni  řešit  individuální  problémy  podavatelů.  Samozřejmě  by  se  jednalo  o  nadstandardní  službu, protože ne u každého podavatele by se to vyplatilo. Objednávka této služby je  realizována prostřednictvím tohoto případu užití.  • Zaslat  žádost  o  kredity:  jedním  ze  způsobů,  jak  zpoplatnit  využívání  aplikace  je  pomocí  tzv.  kreditů.  Ty  určují,  kolik  je  podavatel  oprávněn  vytvořit  zásilek.  Tento  37   

• •

koncept  je  určen  především  podavatelům  zpracovávající  menší  množství  zásilek  a  nevyplatila  by  se  jim  tak  roční  licence.  Tento  případ  užití  tedy  reprezentuje  objednávku kreditů.  Tisk faktury: jedná se o vygenerování PDF dokumentu obsahujícího fakturu související  s konkrétní objednávkou.  Zobrazení  podrobností  o  licenci:  umožní  superpodavateli  prohlížet  popř.  editovat  údaje licence, zobrazit informace o aktuálně objednaných či zakoupených službách a  historie těchto objednávek a nákupů včetně plateb. 

Uživatelská správa správce systému  V této části jsou uvedeny některé z nejdůležitějších funkcí správce systému týkající se správy  uživatelů.   

  obr. 20: Use‐case diagram uživatelské správy správce systému 

Případy užití:  • Správa  uživatelských  účtů:  zahrnuje  vytváření,  editaci  a  mazání  všech  uživatelských  účtů.  • Úplná správa licencí: obsahuje zakládání nových licencí, jejich úpravu a odstraňování. 

Správa systému  Následující  use‐case  diagram  reprezentuje  funkce  systému,  ke  kterým  je  oprávněn  pouze  správce systému. Jedná se o celkové nastavení a správu systému.   

38   

  obr. 21: Use‐case diagram správy systému 

Správa systému zahrnuje:  • Nastavení  archivace  dat  a  celkového  čištění:  případ  užití  určený  pro  nastavení  archivace dat a celkového čištění databáze. Zpravidla se jedná o naplánované úlohy  prováděné buď jednorázově, nebo pravidelně. Za zmínku stojí čištění databáze, které  je  realizováno  pomocí  sofistikovaných  algoritmů,  snažících  se  mimo  jiné  najít  a  odstranit  nepoužívaná  data,  kontrolujících  integritu  dat,  jejich  duplicitu  a  nakonec  vhodným způsobem provede a zobrazí analýzu stavu a využití úložiště.   • Globální  nastavení  systému:  tento  případ  užití  zahrnuje  možnost  provést  nastavení  globálních parametrů systému souvisejících s jeho provozem.    

39   

Použité technologie  Tato podkapitola obsahuje stručné pojednání o některých vybraných technologiích použitých  pro vývoj systému, který je předmětem této práce. 

Java  Java je v dnešní době jedním z nejpopulárnějších programovacích jazyků a to i přesto, že byla  vyvinuta již v roce 1995. Jednou z jeho vlastností, díky které je tak rozšířen, je nezávislost na  platformě,  což  v jejím  případě  znamená  nejen  nezávislost  na  operačním  systému,  ale  i  na  zařízení,  kde  je  výsledný  kód  prováděn.  To  je  zabezpečeno  pomocí  tzv.  JVM  (angl.  Java  Virtual  Machine),  který  představuje  virtuální  stroj,  kde  běží  výsledné  programy  napsané  v  Javě. Přeložený program tedy není možné spustit bez JVM.  Od  roku  2007  je  Java  vyvíjena  jako  open  source  a  v současnosti  existují  z hlediska  druhu  zařízení, pro která jsou aplikace v Javě vyvíjeny, 4 různé varianty. Jedná se:  • JavaCard – edice určená do malých vestavěných zařízení typu např. kreditních karet,  SIM karet a podobných platforem s vlastní pamětí.  • Java  ME  –  mobile  edice  umožňující  vývoj  aplikací  určených  pro  mobilní  zařízení  –  především pro mobilní telefony, PDA apod.,  •  Java  SE  –  standardní  edice  určená  převážně  pro  vývoj  desktopových  aplikací  na  běžných stolních počítačích,  • Java  EE  –  enterprise  edice  určená  pro  náročnější  aplikace  vykazující  rysy  vícevrstvé  architektury, klient‐server architektury, či rozsáhlejší distribuované systémy.  Dalším  rysem  tohoto  jazyka  je  objektově  orientované  paradigma,  které  v případě  většiny  modelovaných  informačních  systémů  dokáže  oproti  ostatním  paradigmatům  snadněji  vystihnout, namodelovat a implementovat jejich strukturu.  Tento  jazyk  však  kromě  svých  nemalých  výhod  přináší  i  nějaké  nevýhody.  Ty  jsou  spojeny  hlavně  s paměťovou  náročností  zapříčiněnou  především  nutností  provozu  virtuálního  prostředí (JVM), pomalejším startem aplikací z důvodů potřeby překladu programu před jeho  samotným spuštěním a syntaxí chudší o jazykové konstrukce, které nebyly implementovány  záměrně kvůli možnosti jejich zneužití nebo nepříznivého vlivu na samotnou strukturu kódu. 

JAAS  JAAS představuje framework jazyka Java, který je nástrojem pro autentizaci a autorizaci. Od  verze  1.4  se  stal  standardní  součástí  Javy  a  rozšiřuje  předchozí  způsob  řízení  přístupu  o  možnost rozhodnutí na základě informace o tom, kdo nebo jaká služba daný kód provádí.  Tento  framework  zabezpečuje,  že  způsob  autentizace  je  na  samotné  aplikaci  nezávislý.  Je  možné  upravit  nebo  přidat  nový  způsob  autentizace  bez  nutnosti  jakéhokoli  zásahu  do  aplikace. Konfigurace autentizace a přístupových práv tedy probíhá mimo samotnou aplikaci. 

40   

Hibernate  Představuje  konkrétní  implementaci  JPA  (Java  Persistence  API),  což  je  specifikace  frameworku pro programovací jazyk Java, který zabezpečuje tzv. objektově relační mapování  (používaná  angl.  zkratka  ORM).  Toto  mapování  provádí  převod  javovských  objektů  na  záznamy  v relační  databázi.  Převod  je  však  oboustranný,  tedy  umožňuje  nejen  konverzi  objektů na záznamy relační databáze, ale i transformaci dat z databázových tabulek zpět na  objekty v Javě. JPA tedy reprezentuje vrstvu mezi aplikační logikou systému a databází, kde  jsou  ukládány  informace,  se  kterými  pracuje  a  usnadňuje  tak  vývoj  aplikací.  V kontextu  vícevrstvé  architektury  tedy  představuje  rozhraní  mezi  aplikační  a  presistentní  vrstvou  aplikace.  Další  neopomenutelnou  výhodou  tohoto  frameworku  je  nezávislost  na  druhu  použitého  databázového  stroje.  Po  namapování  konkrétních  tříd  na  tabulky  databáze  je  v případě  Hibernatu  manipulace  s informacemi  uloženými  v databázi  realizovaná  pomocí  speciálního  jazyka  HQL  (Hibernate  Query  Language)  odvozeného  z SQL.  Ten  je  nezávislý  na  konkrétní  databázi.  Samotné  mapování  může  být  realizováno  dvěma  způsoby.  Buď  pomocí  tzv.  mapovacích  souborů,  kde  je  předepsaným  způsobem  specifikováno,  jak  se  mají  data  mezi  sebou  transformovat,  nebo  pomocí  anotací,  které  z hlediska  přehlednosti  kódu  představují  vhodnější způsob. Jedná se o jazykové konstrukce umožňující definovat mapování přímo ve  zdrojovém kódu samotných tříd. 

Web services  Webové  služby  (angl.  web  services)  představují  nástroj  pro  komunikaci  dvou  zařízení  prostřednictvím sítě, kde jedním ze zařízení je žadatel o službu a druhým je její poskytovatel.  Tato  komunikace  musí  probíhat  pomocí  zpráv  ve  strojově  zpracovatelném  formátu.  Nejrozšířenější z protokolů pro výměnu těchto zpráv je protokol SOAP, jež je založen na XML.  Jejich samotný přenos je však řešen pomocí protokolů nižší úrovně (např. HTTP).   Využívání  webových  služeb  žadatelem  předpokládá  znalost  jejich  definice.  Ta  je  popsána  pomocí jazyka WSDL opět založeného na XML formátu. Definici webové služby publikuje její  poskytovatel  v  UDDI registru,  kde  ji  může  žadatel  vyhledat.  Samotná  komunikace  s UDDI  registrem je realizována opět jako webová služba a je tedy také definována pomocí WSDL.  Jedná  se  o  koncept  nezávislý  na  konkrétní  platformě  a  jeho  využití  tak  umožňuje  jednoduchou komunikaci v síti mezi aplikacemi v heterogenním prostředí. 

41   

 

Návrh systému  Tato  podkapitola  představuje  jádro  celé  práce.  Obsahuje  analytický  návrh  nejdůležitějších  částí aplikační logiky systému pomocí diagramů tříd a sekvenčních diagramů. Jádro aplikace  je  rozděleno  do  spolupracujících  modulů,  jejichž  vzájemná  provázanost  a  závislost  je  minimalizována.  Důsledkem  je  tak  nejen  větší  přehlednost  aplikace,  ale  také  možnost  snadnější rozšiřitelnosti a znovupoužitelnosti jejich komponent. Na konci této podkapitoly je  specifikováno rozvrstvení aplikace a její konkrétní rozmístění pomocí diagramu nasazení. 

Modul zásilek  Jádro celé aplikace představuje modul zásilek. Ten je v této podkapitole logicky rozčleněn a  namodelován pomocí 4 relativně samostatných diagramů tříd. První z nich je zobrazen níže  na obr. 22.   

42   

  obr. 22: Class diagram zásilek 

Hlavní částí tohoto diagramu je rozhraní Mail reprezentující zásilku. Protože je kladen důraz  na  rozšiřitelnost  systému  o  téměř  libovolný  typ  zásilky,  jedná  se  v tomto  případě  právě  o  rozhraní  a  ne  třídu.  Toto  rozhraní  má  jednu  abstraktní  implementaci  obsahující  logiku  společnou všem dosud známým a do systému implementovaným zásilkám. Z této abstraktní  třídy  dědí  buď  zásilky  už  konkrétních  poskytovatelů  poštovních  služeb  (v  diagramu  např.  MailPPL),  nebo  specializovanější  třídy  obsahující  společnou  logiku  zásilek  několika  poskytovatelů.  V druhém  zmíněném  případě  je  to  v diagramu  právě  třída  43   

AdditionalServiceMail,  která  je  určena  pro  dědění  zásilek,  které  budou  využívat  konceptu  doplňkových  služeb,  což  je  specifické  např.  pro  zásilky  České  pošty.  V případě,  že  bude  potřeba  systém  rozšířit  o  nový  typ  zásilky,  který  však  nebude  koncepčně  vyhovovat  ani  již  zmíněné abstraktní implementaci rozhraní Mail, jednoduše se vytvoří nová implementace.  Rozhraní Mail má dvě rozšíření. Jedná se o odchozí a došlou zásilku, které pak implementují  zásilky  konkrétního  poskytovatele.  Na  obrázku  jsou  nazvány  jako  IncomingMail  a  OutgoingMail.  Nedílnou  součástí  zásilky  je  vždy  středisko,  které  je  v diagramu  reprezentované  třídou  Department.  V případě  odchozí  pošty  bude  reprezentovat  odesílatele  a  v případě  došlé  adresáta.  Proto  musí  obsahovat  konkrétní  adresu,  která  je  reprezentována  třídou  Contact,  které je věnován samostatný diagram, popisující modul adresář. Zásilka tedy kromě vazby na  středisko obsahuje i vazbu na odesílatele a adresáta, z nichž jedna je odvozená od střediska,  takže nebude reálně implementována.  V diagramu  se  nachází  další  rozhraní  pojmenované  ColumnsElement,  které  implementuje  každá zásilka a kontakty. Jeho implementací v libovolné třídě je možné tuto třídu napojit na  modul  exportů  a  importů,  který  obsahuje  algoritmy  pro  výměnu  dat  mezi  různými  zdroji  a  cíli. Tomuto modulu je věnována samostatná podkapitola.  Zásilka  dále  obsahuje  stav  doručení  (v  diagramu  reprezentován  třídou  DeliveryState)  a  seznam  příloh  (rozhraní  MailAttachment).  Přílohy  jsou  namodelovány  jako  rozhraní  opět  z důvodů  jejich  snadné  rozšiřitelnosti.  Může  se  jednat  jak  o  obyčejnou  poznámku  (NoteMailAttachment), tak např. o soubor (FileMailAttachment).  Poslední  v diagramu  uvedenou  vazbou  a  jednou  z nejdůležitějších,  bez  které  se  podávaná  zásilka  neobejde,  je  vazba  na  typ  zásilky,  jež  je  v diagramu  reprezentován  rozhraním  MailType. Následující diagram zobrazený na obr. 23 zachycuje způsob implementace ceníku  a to nejen pro typy zásilek, ale i pro již zmíněné doplňkové služby.   

44   

  obr. 23: Class diagram typů a ceníků zásilek 

Samotný  ceník  je  v případě  typu  zásilky  reprezentován  rozhraním  MailTypePriceList,  které  implementují  ceníky  už  konkrétních  poskytovatelů.  Je  možné  opět  definovat  obecnější  implementaci,  která  obsahuje  funkcionalitu  společnou  více  poskytovatelům.  Takovým  příkladem  je  ceník  typů  zásilek  podporujících  doplňkové  služby  –  v diagramu  pojmenován  jako AdditionalServiceMailType. Ceník obsahuje metody pro výpočet ceny zásilky. K tomu je  třeba  nějakým  způsobem  definovat  parametry  zásilky,  které  odpovídají  konkrétní  ceně  zásilky. Takovým parametrem může být třeba rozsah hmotnosti, který zásilka musí splňovat.  V diagramu jsou tyto parametry reprezentovány rozhraním MailParameter. Ceník tedy určí,  jaké parametry daná zásilka splňuje a na základě toho stanoví cenu.  Doplňkové  služby  jsou  spolu  se  svými  ceníky  (třída  AdditionalServicePriceList)  definovány  obdobným  způsobem  jako  typy  zásilek.  Tyto  ceníky  jsou  charakteristické  tím,  že  využívají  parametry MailTypeParameter a ExclusionAdditionalServiceMailParameter, jež implementují  rozhraní MailParameter. První z těchto dvou tříd umožňuje, aby byla cena doplňkové služby  definována  v závislosti  na  typu  zásilky,  což  odráží  např.  obchodní  podmínky  České  pošty.  45   

Druhý  z parametrů  definuje  výlučný  vztah  mezi  doplňkovými  službami.  V případě  České  pošty se jedná například o doplňkové služby Uložit jen 10 dní a Uložit jen 3 dny.  Každá  podávaná  zásilka  obsahuje  podací  číslo,  které  je  jedinečným  identifikátorem  zásilky.  Logika  definice  a  přidělování  těchto  čísel  je  natolik  sofistikovaná,  že  jí  byl  věnován  samostatný diagram tříd, jež je zobrazen níže na obr. 24.   

  obr. 24: Class diagram podacích čísel 

Nastavení  podacích  čísel  reprezentované  rozhraním  ProcessNumberSettings  je  individuální  pro  každý  typ  zásilky.  Z diagramu  je  vidět,  že  z důvodů  rozšiřitelnosti  systému  není  definována  přímá  vazba  podacích  čísel  na  každý  typ  zásilky,  ale  jen  na  implementace  rozhraní  ProcessNumberMailType.  Již  zmíněné  rozhraní  ProcessNumberSettings  je  implementováno třídami, které slouží pro obsluhu podacích číseluž konkrétních podavatelů  (v  diagramu  zobrazeno  jako  třídy  ProcessNumberSettingsCP  a  ProcessNumberSettingsPPL).  Z popisu podacích čísel uvedeného v podkapitole Správa superuživatelského nastavení plyne  význam vazby střediska na rozhraní ProcessNumberSettings. Pro připomenutí – je tu proto,  že  podací  řady  jsou  přidělovány  na  základě  smlouvy  s poskytovatelem  a  tyto  smlouvy  jsou  nastaveny  jednotlivým  střediskům.  Nemůže  tedy  existovat  nastavení  podacích  řad  (ProcessNumberSettings) bez smlouvy, tzn. střediska. 

46   

Nastavení  podacích  řad  je  v podstatě  kompozicí  jednotlivých  podacích  řad,  které  jsou  v diagramu reprezentovány rozhraním ProcessNumber. Jde opět o rozhraní, protože podací  řady  konkrétních  podavatelů  se  budou  lišit.  V diagramu  je  pomocí  rozhraní  ProcessNumberCP  naznačena  struktura  podacích  řad  České  pošty,  které  se  dají  rozdělit  na  obecné řady (ProcessNumberCPGeneral) a přidělené (ProcessNumberCPAssigned).  Další  část  modulu  zásilek  se  týká  uzávěrek  a  je  popsána  diagramem  tříd  na  následujícím  obrázku.    

  obr. 25: Class diagram uzávěrek 

Třída  reprezentující  uzávěrky,  jež  je  v  diagramu  pojmenovaná  jako  Deadline,  obsahuje  tzv.  číslo  uzávěrky,  které  není  nic  jiného  než  její  pojmenování.  Dále  je  tato  třída  specifikována  podavatelem (třída Customer), který ji vytvořil, a může obsahovat libovolný počet příloh, což  v  diagramu  představuje  vazba  na  rozhraní  DeadlineAttachment,  jež  je  zatím  implementováno  jako  obyčejná  poznámka  (třída  NoteDeadlineAttachment)  a  soubor  (třída  FileDeadlineAttachment). Hlavními vazbami a atributy určujícími, jaké zásilky daná uzávěrka  obsahuje, jsou atribut datum, odkaz na středisko a v případě, že by předchozí dvě specifikace  nestačily, může obsahovat přímo odkaz na seznam relevantních zásilek.  Poslední  esenciální  část  modulu  zásilek  představuje  funkcionalitu,  která  sloužící  k předplňování zásilek. Její class diagram je zobrazen níže na obr. 26.   

47   

  obr. 26: Classdiagrampředplnění zásilek 

Ústřední  entitou  je  rozhraní  MailFilling,  které  představuje  konkrétní  nastavení  předplnění  zásilek. Předplnění je definováno dvěma skupinami informací. Jsou to jednak ty, které určují,  co  se  má  předplňovat,  a  také  ty,  které  určují,  za  jakých  podmínek  se  tak  má  dít.  Obě  tyto  skupiny  mohou  být  definovány  a  modifikovány  v jednotlivých  implementacích  rozhraní  MailFilling,  případně  v  jejich  potomcích.  Základní  sadou  údajů,  které  se  mají  předplňovat,  jsou  středisko,  typ  zásilky,  adresát  či  příjemce,  země  adresáta  či  příjemce  a  jsou  implementovány  v základní  třídě  pro  předplnění  nazvané  MailDefaultFilling.  Zbylé  údaje,  jako  např.  hmotnost,  dobírka,  udaná  cena  a  mnoho  dalších,  jsou  definovány  v  rozšířeních  této  třídy  odpovídajících  už  konkrétním  poskytovatelům  nebo  v rozšířeních  agregujících  společnou  funkcionalitu  odpovídající  více  poskytovatelům.  Příkladem  předplnění  agregujícího  funkcionalitu,  jež  odpovídá  několika  poskytovatelům,  je  třída  AdditionalServiceFilling, jež rozšiřuje svého rodiče o možnost předplnění doplňkových služeb.  Jak  již  bylo  zmíněno  výše,  druhou  skupinou  informací,  které  definují  předplnění,  údaje  určující,  za  jakých  podmínek  má  být  zásilka  předplněna.  V případě  základní  implementace  předplnění se jedná o specifikaci střediska, odesílatele či adresáta, jeho země a typu zásilky.  48   

Co  se  týče  zbylých  údajů  (hmotnost,  dobírka  ap.)  je  situace  obdobná,  jako  v případě  předplňovaných údajů, které byly popsány výše. 

Modul uživatelů  Modul uživatelů definuje základní uživatelské typy účtů, které odpovídají jednotlivým rolím,  a s nimi související vazby. Jeho jádro je zachyceno pomocí diagramu tříd na následujícím obr.  27.    

  obr. 27: Class diagram modulu uživatelů 

Všechny role systému mají společného předka v podobě třídy User, který obsahuje základní  údaje  a  funkcionalitu  sloužící  především  pro  autentizaci  a  autorizaci.  V systému  jsou  k jednotlivým uživatelům evidovány s nimi související události jako např. událost o přihlášení  a  odhlášení.  Konkrétní  rozšířeními  třídy  User  představujícími  uživatelské  typy  účtů  jsou  Manager,  Provider  a  Customer,  jež  je  ještě  dále  rozšířen  jako  SuperCustomer.  Manager  reprezentuje  aktéra  z úvodního  diagramu  případů  užití,  který  má  přístup  ke  statistikám  systému  a  správě  ceníků.  Třída  Provider  zastupuje  konkrétního  poskytovatele  poštovních  služeb,  jež  v systému  spravuje  ceníky  a  upravuje  podmínky  týkající  se  typů  zásilek,  které  nabízí.   49   

Důležitým typem uživatelského účtu je podavatel, který je v diagramu reprezentován třídou  Customer.  Podavatel  nemůže  v systému  existovat  samostatně,  ale  musí  být  vždy  vázán  na  konkrétní licenci (třída Licence), která ho opravňuje k využívání systému. Nepovinnou vazbu  poskytovatele představuje vazba na jedno nebo více středisek, které má právo využívat.   Posledním  typem  uživatelského  účtu  je  správcovský  účet  podavatele,  který  je  v use‐case  diagramu  celého  systému  (obr.  10)  označen  jako  aktér  Superpodavatel.  Je  definován  jako  potomek třídy Customer a obsahuje navíc vazbu na události týkající se licencí, např. událost  o objednání aktivačního kódu apod. Tyto licence představují objekty třídy LicenceEvent. 

Modul adresáře  Jednou  ze  základních  funkcí  systému  je  evidence  adres,  které  jsou  používány  při  správě  zásilek.  Jedná  se  o  samostatný  modul,  jehož  využívání  je  však  nepostradatelnou  součástí  kteréhokoli  netriviálního  systému  pro  efektivní  zpracování  a  podej  zásilek.  Jeho  hlavní  struktura je popsána diagramem tříd na následujícím obr. 28.   

  obr. 28: Class diagram modulu adresář 

Konkrétní položka adresáře je reprezentována třídou Contact. Obsahuje nejen adresu, ale i  relativně velké množství doplňujících údajů, jako jsou například kontaktní osoba, specifikace  50   

bankovního  účtu,  telefon,  email,  fax,  id  datové  schránky  apod.  Samotná  adresa  kontaktu  není jeho součástí, ale je reprezentována jinou třídou, na kterou si kontakt drží referenci. Je  to  z důvodů  využití  DDM  databáze  České  pošty,  která  zahrnuje  adresy  používané  Českou  poštou,  což  jsou  v dnešní  době  všechny  známé  adresy.  Česká  pošta  tuto  databázi  sice  neustále  udržuje,  aby  byla  co  nejvíce  aktuální,  ale  i  přesto  může  být  potřeba  použít  jinou  adresu, a z toho důvodu bude mít podavatel možnost definovat vlastní. Adresa je definována  pomocí  třídy  AddressDDM  a  práce  s  jejími objekty  je  delegována  na  knihovní  třídu  AddressDDMAPI. Konkrétní funkcionalita pro práci s nimi však v diagramu uvedena záměrně  není, protože není nijak sofistikovaná.  Způsob  aktualizace  zásilek  při  změně  kontaktu,  na  který  se  odkazují,  byl  už  popsán  v podkapitole  Správa  adresáře.  S touto  aktualizací  souvisí  vazba  kontaktu  na  sebe  sama,  která  vyjadřuje,  že  daný  kontakt  je  pouhou  editací  jiného  kontaktu,  který  sám  nemohl  být  editován, protože se na něj odkazuje nějaká zásilka.  Kontakt  může  obsahovat  poznámky  reprezentované  rozhraním  ContactAttachment,  jehož  implementace jsou obdobné jako v případě zásilek či uzávěrek, tj. obyčejná poznámka nebo  soubor.  

Modul kontrol  Kontrola  zásilek  je  při  zpracování  a  jejich  hromadném  podeji  téměř  nepostradatelnou  součástí.  Tyto  kontroly  jsou  prováděny  nejčastěji  před  samotným  podejem,  aby  měl  podavatel možnost doplnit či opravit údaje zásilek, které by jinak nebyly doručeny, a byly tak  podavateli  vráceny  zpět.  Kontrola  se  však  netýká  pouze  zásilek,  ale  i  kontaktů  a  celkové  správy  adresáře,  a  měla  by  být  rozšiřitelná  i  na  další  potřebné  oblasti  (např.  správa  středisek).  V případě  kontaktů  podavatelé  ocení  nejen  kontrolu  adres,  ale  např.  možnost  odstranění  duplicitních  záznamů.  Na  obr.  29  je  diagram  tříd  popisující  základní  strukturu  tohoto modulu.    

51   

  obr. 29: Class diagram modulu kontrol 

Z diagramu  je  vidět,  že  tento  modul  strukturou  odpovídá  návrhovému  vzoru  Strategy  Pattern.  Rozhraní  CheckStrategyreprezentuje  samotnou  kontrolu.  Stačí  mu  předat  pouze  zdroj  dat  reprezentovaný  rozhraním  DataSource  a  konkrétní  implementace  rozhraní  CheckStrategy  už  vykoná  pomocí  metody  check  nad  specifikovanými  objekty  daný  typ  52   

kontroly.  Obě  tato  rozhraní  jsou  definována  jako  generické  typy,  kde  parametrizovaným  typem  jsou  třídy  konkrétních  objektů,  nad  kterými  se  má  kontrola  provádět.  Jak  bylo  uvedeno výše, jedná se zejména o zásilky a kontakty.  Díky použití rozhraní CheckStrategy je tedy možné implementovat libovolný koncept kontrol.  V diagramu je uveden jeden z nich. Je reprezentován třídou CheckupStrategy, která je opět  generickým typem kontroly. Sama tato třída neimplementuje žádný konkrétní algoritmus pro  kontrolu, ale místo toho obsahuje odkazy na seznamy objektů, které představují jednotlivé  kontroly.  Všechny  tyto  objekty  se  dají  obecně  rozdělit  do  dvou  skupin  v diagramu  reprezentovaných  rozhraními  SingleCheckup  a  MultipleCheckup.  Liší  se  v počtu  kontrolovaných  instancí.  Podstata  některých  kontrol  vyžaduje,  aby  byly  prováděny  nad  skupinou objektů, jiné kontroly je možné provádět nad jednotlivými objekty zvlášť. Protože  se  jedná  o  obecnou  reprezentaci  kontrol  prováděných  nad  objekty  různých  tříd,  jsou  tato  rozhraní  definována  opět  jako  generické  typy.  Implementace  těchto  rozhraní  už  musí  specifikovat, nad jakými daty se bude konkrétní kontrola provádět. V diagramu je uvedeno  pár příkladů. Třída MailTypeCheckup je kontrolou typu zásilky, kde je za parametr generické  definice  dosazeno  rozhraní  Mail.  Obdobně  jsou  definovány  další  příklady  zobrazené  v diagramu.  Kromě  specifikace, jaké kontroly  mají  být  provedeny,  je  třeba  specifikovat  i  příslušná  data,  nad  kterými  dané  kontroly  poběží.  K tomuto  účelu  je  definováno  (opět  s použitím  generik)  rozhraní DataSource a jeho negenerické implementace MailDataSource a ContactDataSource  odpovídající zásilkám a kontaktům.  Poslední  částí,  která  ve  výsledku  propojuje  celý  model,  jsou  neparametrizovaná  rozšíření  třídy CheckupsStrategy, která se v případě ContactCheckStrategy týkají kontaktů a v případě  MailCheckStrategy zásilek. 

Modul exportů a importů  Exporty a importy představují prostředek propojení systému s okolním prostředím, zejména  s tzv.  spisovými  službami,  jež  byly  popsány  v podkapitole  Popis  systému,  a  pro  řadu  podavatelů  tak  budou  představovat  nepostradatelnou  část procesu  zpracování  zásilek.  Protože se jedná o obecný návrh pro různé typy exportů, musel být rozdělen do tří diagramů  tříd. První část tohoto modelu popisuje reprezentaci dat, které budou načítány pro následné  další zpracování (import nebo export).  Struktura je zachycena na následujícím obrázku.   

53   

  obr. 30: Class diagram zdroje dat exportu a importu 

Reprezentantem  dat  je  v tomto  případě  generické  rozhraní  ExchangeSource.  Generické  proto, že není specifikováno, s jakými konkrétními daty bude pracovat. Toto rozhraní má dvě  přímé  negenerické  implementace.  Jedná  se  o  třídu  TextFileSource,  která  reprezentuje  textový soubor, a XMLFileSource představující soubor ve formátu XML. Data, se kterými tyto  třídy  pracují,  jsou  v případě  textového  souboru  obyčejné  řádky,  tj.  objekty  typu  String,  a  v případě XML souboru to je XMLElement.  Dále  je  definováno  jedno  generické  rozšíření  rozhraní  ExchangeSource  s názvem  ColumnsExchangeSource,  které  klade  na  třídu,  jež  je  v generické  definici  reprezentována  parametrem,  omezení,  aby  implementovala  rozhraní  ColumnsElement.  Toto  rozhraní  představuje objekt, jehož stav, tj. data, se dají popsat pomocí sloupců. Dá se tedy využít pro  databázové  záznamy  či  řádky  načítané  z CSV  souborů.  Implementace  rozhraní  ColumnExchangeSource  tedy  představují  zdroje  dat  uložených  v databázi  (potomci  třídy  DataExchangeSource),  v CSV  souboru  (třída  CSVFileTarget)  a  v textovém  souboru  s pevnou  šířkou  sloupce  (třída  s názvem  FixedColumnsLengthFileTarget).  Tato  zdánlivě  složitá  54   

struktura slouží pro zobecnění exportů a importů umožňující výměnu dat mezi různými zdroji  a cíli. Definice cílového umístění dat je zachycena na následujícím obrázku.    

  obr. 31: Class diagram cíle dat exportu a importu 

Struktura  je  obdobná  definici  zdroje  dat  a  není  třeba  ji  tedy  popisovat.  Jediné,  co  je  třeba  zmínit, je rozdíl mezi rozhraními ExchangeSource a ExchangeTarget. První z nich definovalo  metody pro získávání dat, druhé ze zmíněných rozhraní definuje metodu pro uložení dat.  Poslední  a  nejdůležitější  částí  tohoto  modulu  jsou  samotné  algoritmy  provádějící  export  a  import. Ty jsou zobrazeny na obrázku níže. 

55   

  56   

obr. 32: Class diagram modulu exportů a importů 

Celý  koncept  importů  a  exportů  je  založen  na  oddělení  zdroje,  jejich  cíle  a  samotných  algoritmů  exportujících  (importujících)  data.  Do  třídy  provádějící  export  se  vloží  zdroj  a  cíl  dat, jako dvě černé skříňky, a ta bez znalosti jejich vnitřní struktury provede požadovaným  způsobem  danou  výměnu  dat  (export  či  import).  Opět  je  kladen  důraz  na  snadnou  rozšiřitelnost  o  další  způsoby  exportů  a  importů  a  proto  je  algoritmus  pro  výměnu  dat  definován  pomocí  rozhraní,  které  je  pojmenováno  ExchangeStrategy.  Z důvodů  rozšiřitelnosti  na  jakýkoli  typ  dat,  nad  kterým  by  bylo  možné  tuto  výměnu  provést,  je  zmíněné rozhraní definováno jako generické.  Výchozí,  taktéž  generická  implementace  rozhraní  ExchangeStrategy  je  nazvána  LineExchangeStrategy.  Z této  pak  dědí  konkrétní  druhy  exportů.  Tím  je  např.  třída  ExportDoDatovéhoSouboru,  jež  představuje  datový  výstup  sloužící  pro  podej  zásilek  České  pošty.  Co  se  týče  generických  parametrů,  je  specifikován  zásilkami  České  pošty  (jakožto  vstupními daty) a třídou String (reprezentující řádek výstupního textového souboru).  Dalším  příkladem  rozšíření  LineExchangeStrategy  je  třída  nazvaná  ColumnsLineExchangeStrategy sloužící pro přenos objektů takových tříd, které implementují  rozhraní  ColumnsElement,  jež  definuje  strukturu  dat  jako  jednoduchý  seznam  atributů.  Příkladem může být databázová tabulka tvořená sloupci či obdobně definovaný CSV soubor.  Jedná se tedy o relativně obecný export či import. Tato třída načítá data ze zdroje, pomocí  objektů třídy ColumnsElementTransformator je nějakým způsobem transformuje (což může  zahrnovat  i  popřehazování  sloupců),  a  poté  je  pomocí  cíle  ukládá  do  příslušného  úložiště.  Jedná se o relativně obecný přenos dat, který umožňuje zvolit, jaký druh dat a odkud se bude  jakým způsobem transformovat, a poté ukládat v jakém formátu a kam. Vzhledem k někdy  složitému  procesu  nastavení  výše  popsaného  přenosu  dat  je  žádoucí,  aby  si  aplikace  dokázala konkrétní nastavení pamatovat, a tak umožňovala jejich opětovné použití. 

Modul notifikace  Modul  notifikace  představuje  opět  obecný  koncept,  který  je  v tomto  případě  využit  pro  upozornění  adresátů  zásilek  na  změnu  jejich  stavu  doručení  či  zpracování,  ale  je  snadné  uvést  řadu  dalších  způsobů  využití  a  v praxi  se  tyto  požadavky  pravděpodobně  objeví.  Strukturu tohoto modulu vystihuje diagram tříd na následujícím obr. 33.   

57   

  obr. 33: Class diagram modulu notifikace 

Jedná  se  o  řešení  koncepcí  do  značné  míry  podobné  dvěma  předcházejícím  modulům,  tj.  modulu  kontrol  a  modulu  exportů  a  importů.  Rozhraní  NotificationStrategy  reprezentující  konkrétní  algoritmus  pro  notifikaci  je  definován  za  použití  generik,  aby  bylo  docíleno  nezávislosti  jeho  implementací  na  konkrétní  třídě  objektů,  které  mají  být  notifikovány.  Zmíněné  rozhraní  tak  může  představovat  jak  notifikaci  zásilek,  tak  i  adresátů  či  středisek.  Přitom  je  opět  dodržen  koncept  oddělení  závislosti  algoritmu  na  datech  a  to  tím,  že  je  pomocí  generik  definován  obecný  zdroj  dat,  který  je  objektu  typu  NotificationStrategy  předáván.  V diagramu  je  uvedena  jediná  implementace  NotificationStrategy,  jež  je  opět  generická,  a  představuje  notifikaci  realizovanou  prostřednictvím  odesílání  emailů.  Konkrétní  podoba  emailu  závisí  na  notifikovaných  objektech,  ale  pravidla,  podle  kterých  je  vytvářen,  jsou  definována  pomocí  rozhraní  EmailTemplate.  Příkladem  je  jeho  implementace  MailSenderNotificationTemplate,  která  vytvoří  email,  jehož  příjemcem  je  adresát  zásilky,  a  v těle  jsou  informace  o  zásilce  a  jejím  stavu.  Rozšíření  EmailNotificationStrategy  s  názvem  MailSenderNotificationStrategy  pak  definuje  samotný  proces  odesílání  emailů,  tj.  například  58   

definuje,  které  zásilky  mají  být  z notifikace  vynechány,  nebo  to,  jestli  má  být  adresát  notifikován souhrnným mailem o všech jeho zásilkách podle data nebo samostatně. 

Modul archivace  Význam  a  důvody  archivace  dat  byly  popsány  v podkapitole  Správa  superpodavatelského  nastavení.  Funkce  tohoto  relativně  jednoduchého  modulu  jsou  přístupné  pouze  Superpodavatelům. Struktura je definována na následujícím obr. 34, jež představuje diagram  tříd.   

  obr. 34: Class diagram modulu archivace 

Předmět archivace definuje třída Archive, která má jednoho potomka rozšiřující tuto třídu o  možnost  pravidelných  archivací.  Samotná  archivace  je  definována  prostřednictví  seznamu  archivačních  komponent,  tj.  specifikací,  co  se  má  archivovat.  Archivační  komponenta  je  z důvodů rozšiřitelnosti systému definována jako rozhraní, které je v diagramu pojmenováno  jako  ArchiveComponent.  Implementací  je  například  archivace  nastavení  systému  (rozhraní  SettingsArchive)  nebo  samotná  archivace  zásilek.  V diagramu  je  pro  jednoduchost  namodelována  základní  podoba  archivace  zásilek,  která  je  určena  datem  a  střediskem.  V praxi  může  být  rozšířena  o  další  potřebné  údaje  a  reference,  aby  dokázala  dostatečně  specifikovat archivované zásilky podle konkrétních potřeb podavatelů. 

59   

Struktura a rozmístění systému  Pro  definici  základní  struktury  z hlediska  rozmístění  komponent  aplikace  a  jejich  propojení  slouží  následující  diagram  rozmístění  (obr.  35),  ze  kterého  je  patrná  třívrstvá  architektura  systému.  Konkrétně  se  jedná  o  vrstvu  prezentační,  aplikační  a  persistentní.  Nezávislost  aplikační vrstvy na prezentační umožňuje implementaci více druhů prezentačních vrstev, což  zobecňuje možnosti využití aplikace. Na diagramu je zobrazena vedle webové implementace  i  desktopová,  která  komunikuje  se  systémem  prostřednictvím  webových  služeb  přes  protokol  SOAP.  Protože  bude  aplikace  v mnoha  případech  integrována  přímo  do  již  existujících  systémů,  je  vhodné  definovat  kromě  webových  služeb  i  jiná  rozhraní  a  komunikační protokoly jako je např. REST či jednoduché HTTP požadavky.   

  obr. 35: Diagram nasazení distribuovaného řešení 

Druhým  příkladem  výsledné  podoby  systému  je  čistě  desktopové  řešení,  zobrazené  na  následujícím obr. 36. Všechny části aplikace jsou umístěny na jednom počítači. Toto řešení je  vhodné např. pro situace, kde není možné zabezpečit stálé a spolehlivé připojení k internetu.  Je  zde  však  nutno  řešit  aktualizaci  ceníků  jednotlivých  poskytovatelů.  Ta  bude  realizována  60   

jednou za čas a to buď pomocí webových služeb, nebo např. pomocí instalačního souboru,  který by po spuštění aktualizoval potřebné části systému.   

  obr. 36: Diagram nasazení desktopového řešení 

 

 

61   

Závěr  V dnešní  době  je  u  nás  trh  poštovních  služeb  regulován  jen  částečně,  a  to  jen  v oblasti  doručování listovních zásilek, na které vlastní monopol státní podnik Česká pošta. Z hlediska  zisků  se  ale  nejedná  o  hlavní  oblast  tohoto  trhu,  což  přirozeně  vedlo  k vytvoření  nemalé  konkurence, která představuje příznivý jev, jež měl vliv na rozsah služeb, jejich kvalitu a cenu.  V současnosti  se  na  našem  trhu  nacházejí  jak  tuzemští,  tak  i  zahraniční  přepravci,  jejichž  počet se pohybuje v desítkách.   Z analýzy existujících systémů, které byla v této práci věnována samostatná kapitola, vyplývá,  že co se týče softwarového vybavení sloužícího pro zpracování a podej zásilek jednotlivých  významnějších poskytovatelů, je trh z převážné míry pokrytý. Jedná se však vždy o systémy  určené  pouze  zásilkám  konkrétních  poskytovatelů.  Na  trhu  tedy  chybí  systém,  který  by  v sobě  sdružoval  služby  jednotlivých  poskytovatelů  a  nabídl  tak  unifikovaný  nástroj  pro  správu  a  podej  zásilek  libovolných  typů,  který  by  v současné  době  hojně  využívaly  např.  elektronické  obchody,  jež  častokrát  nabízejí  možnost  doručení  balíků  prostřednictvím  různých přepravců. Tento systém by se stal zároveň i jednoduchým nástrojem porovnání cen  služeb nabízených více poskytovateli.  Na  základě  tohoto  faktu  a  analýzy  současných  systémů  byla  provedena  specifikace  požadavků na tento nový systém a byl vytvořen jeho analytický návrh, jež odpovídá konceptu  vícevrstvé architektury. Rozsah práce byl omezen pouze na návrh aplikační logiky a nijak tedy  nespecifikoval strukturu a způsob implementace prezentační vrstvy či vrstvy persistence dat.  Byl tak navržen systém splňující základní aktuální potřeby trhu v této oblasti. Největší důraz  byl  kladen  na  jeho  rozšiřitelnost  o  nové  služby  nabízené  např.  poskytovateli  poštovních  služeb, kteří na trhu doposud nepůsobí. K této situaci bude zcela jistě docházet, a proto by se  tyto  nevyhnutelné  úkony  měly  stát  součástí  údržby  aplikace.  Tím  byl  tedy  hlavní  cíl  práce  splněn.  Dalším cílem práce bylo pojednat o technologiích, které by bylo možné využít pro samotnou  implementaci  systému,  a  vypracovat  teoretickou  část  pojednávající  o  návrhových  vzorech,  které  v konečném  důsledku  usnadnily,  zpřehlednily  a  zobecnily  samotný  návrh  systému  a  jejichž pomocí tak bylo dosaženo většiny základních požadovaných vlastností systému.     

62   

Použité zdroje  [1] [2] [3]

[4] [5] [6]

[7] [8]

[9]

[10] [11] [12]

[13] [14]

[15]

Arlow,  J.,  Neustadt,  I.  2007.  UML  2  a  unifikovaný  proces  vývoje  aplikací.  Computer  Press, a.s. Brno. 567 s. ISBN: 978‐80‐251‐1503‐9.  Pecinovský,  R.  2007.  Návrhové  vzory.  Computer  Press,  a.s.  Brno.  527  s.  ISBN:  978‐80‐ 251‐1582‐4.  Česká  pošta,  s.  p.  Podání  Online  |  Česká  pošta  [online].  c2011  [cit.  2012‐01‐21].  Dostupné  na  World  Wide  Web:  .  ATAX  Software  s.r.o.  Produkty  společnosti  [online].  [cit.  2012‐04‐19].  Dostupné  na  World Wide Web: .  DHL International Gmbh. DHL | Zasílání online | Česky [online]. c2012 [cit. 2012‐02‐11].  .  TNT  holdings  B.V.  TNT  Express  –  Elektronická  řešení  [online].  c2011  [cit.  2012‐02‐11].  Dostupné  na  .  Albacon, s.r.o. software ProfiPost [online]. [cit. 2012‐02‐11]. Dostupné na World Wide  Web: < http://www.albacon.eu/viewfile.asp?file=1500>.  Software Design Pattern [online]. poslední aktualizace 4. prosince 2011 [vid. 2011‐12‐ 05].  Dostupné  na  World  Wide  Web:  .  Návrhový  vzor  [online].  poslední  aktualizace  8.  listopadu  2011  [vid.  2011‐12‐04].  Dostupné  na  World  Wide  Web:  .  Objekty ‐ vzory [online]. poslední aktualizace 2. února 2008 [vid. 2011‐12‐14]. Dostupné  na World Wide Web: .  Hibernate [online]. poslední aktualizace 13. února 2012 [vid. 2012‐04‐07]. Dostupné na  World Wide Web: .  Java (programovací jazyk) [online]. poslední aktualizace 3. dubna 2012 [vid. 2012‐04‐7].  Dostupné  na  World  Wide  Web:  .  Česká  pošta  [online].  poslední  aktualizace  15.  prosince  2008  [vid.  2012‐01‐08].  Dostupné na World Wide Web: .  JAAS Reference Guide [online]. c2011 [vid. 2011‐12‐14]. Dostupné na World Wide Web:  .  Java Development News [online]. poslední aktualizace 1. ledna 2000 [vid. 2011‐11‐26].  Dostupné  na  World  Wide  Web:  . 

63   

[16] Authentication  Package  Refactoring  [online].  poslední  aktualizace  9.  července  2007  [vid.  2011‐11‐26].  Dostupné  na  World  Wide  Web:  .  [17] Design  patterns  [online].  [vid.  2011‐12‐14].  Dostupné  na  World  Wide  Web:  .  [18] Java  Persistence  API  [online].  poslední  aktualizace  12.  ledna  2012  [vid.  2012‐04‐08].  Dostupné na World Wide Web: .  [19] Webová služba [online]. poslední aktualizace 13. října 2011 [vid. 2012‐04‐10]. Dostupné  na World Wide Web: < http://cs.wikipedia.org/wiki/Webov%C3%A1_slu%C5%BEba>.  [20] Využití  webových  služeb  a  protokolu  SOAP  při  komunikaci  [online].  [vid.  2012‐04‐10].  Dostupné  na  World  Wide  Web:  . 

64