Informační systém pro rozhodčí řízení

Bankovní institut vysoká škola Praha Katedra informačních technologií

Informační systém pro rozhodčí řízení Diplomová práce

Autor:

Bc. Michal Vodička Informační technologie a management

Vedoucí práce:

Praha

Ing. Michal Valenta, Ph.D.

Červen, 2009

Prohlášení

Prohlašuji, že jsem tuto diplomovou práci zpracoval samostatně a s použitím uvedené literatury.

V Praze, dne 29.6.2009

Michal Vodička

Informační systém pro rozhodčí řízení

Poděkování Na tomto místě bych chtěl poděkovat vedoucímu diplomové práce Ing. Michalovi Valentovi, Ph.D za odborné vedení během vypracování diplomové práce, věcné připomínky a řadu podnětů a užitečných připomínek. Dále bych chtěl poděkovat Ing. Ondřeji Novákovi, CSc. z předsednictva Rozhodčího soudu při HK ČR a AK ČR a celému předsednictvu za to, že mi schválili a umožnili vypracovat diplomovou práci na téma, které mi je blízké a výsledný produkt budu moci implementovat v praxi a dále jej rozvíjet. Velké poděkování náleží i mé přítelkyni Radce za trpělivost a podporu nejen během psaní této práce, ale po celou dobu studia.


Anotace V dnešní době je informační systém ve firmě nezbytností a samozřejmostí. Tato práce se zabývá návrhem a implementací informačního systému pro rozhodčí řízení, který nahradí starý systém, který sloužil pro potřeby Rozhodčího soudu při Hospodářské komoře České republiky a Agrární komoře České republiky 15 let. Nový informační systém je postaven na zkušenostech získaných během vývoje a provozu starého systému, ale je postaven na moderních technologiích, čímž je umožněn další rozvoj systému.

Annotation Information system is in nowdays for company necessary and obvious. This thesis describes design and implementation of information system for arbitration proceeding, which replace old information system that was using on Czech Arbitration Court 15 years. During building of new information system was used know-how from previous system, but new system use modern technologies and next progress is possible.

5


Obsah 1

2

Úvod....................................................................................................................................8 1.1

Cíl práce......................................................................................................................8

1.2

Přehled použitých výrazů z oblasti rozhodčího řízení ................................................8

Analýza požadavků na aplikaci ........................................................................................11 2.1

2.1.1

Informační systém Evidence sporů......................................................................11

2.1.2

Ekonomický software ..........................................................................................18

2.2

Obecné požadavky na nový systém ..........................................................................18

2.3

Role uživatelů ...........................................................................................................19

2.3.1

Popis role referenta sporů ....................................................................................20

2.3.2

Popis role zapisovatelky ......................................................................................21

2.3.3

Popis role účetní...................................................................................................22

2.3.4

Popis role pracovníka podatelny..........................................................................23

2.3.5

Popis role tajemníka.............................................................................................24

2.3.6

Popis role rozhodce..............................................................................................25

2.3.7

Popis role strany sporu.........................................................................................25

2.4

3

Popis současného stavu.............................................................................................11

Podrobná specifikace jednotlivých modulů ..............................................................25

2.4.1

Modul Spory ........................................................................................................25

2.4.2

Modul Adresář .....................................................................................................29

2.4.3

Modul Ústní jednání ............................................................................................30

2.4.4

Modul Honoráře rozhodců...................................................................................31

2.4.5

Modul Generování dokumentů ............................................................................31

2.4.6

Modul Statistiky...................................................................................................32

Návrh řešení ......................................................................................................................34 3.1

Spuštění a přihlášení do IS........................................................................................34

3.2

Modul Spory .............................................................................................................34

3.3

Adresář......................................................................................................................35

3.4

Ústní jednání .............................................................................................................36

3.5

Honoráře rozhodců ...................................................................................................40

3.6

Kurzovní lístek ČNB ................................................................................................40

3.7

Systémové požadavky...............................................................................................40 5


4

3.7.1

Server (hardware) ................................................................................................41

3.7.2

Serverový software ..............................................................................................42

3.7.3

Pracovní stanice ...................................................................................................43

Realizace řešení ................................................................................................................44 4.1

Použité technologie...................................................................................................44

4.1.1

Visual Studio .NET 2008.....................................................................................44

4.1.2

Microsoft .NET Framework ................................................................................45

4.1.3

ADO.NET ............................................................................................................46

4.1.4

Jazyk C#...............................................................................................................47

4.1.5

Microsoft SQL Server 2005.................................................................................48

4.1.6

Microsoft Windows Server..................................................................................49

4.2

Databáze....................................................................................................................51

4.2.1

Struktura databáze................................................................................................51

4.2.2

Normalizace databáze ..........................................................................................51

4.2.3

Zálohování databáze ............................................................................................54

4.3

Uživatelské rozhraní .................................................................................................55

4.4

Vnitřní uspořádání aplikace ......................................................................................56

4.4.1

Obecný popis .......................................................................................................56

4.4.2

Režimy prohlížení a editace.................................................................................57

4.4.3

Načítání dat do formuláře a ukládání dat do databáze.........................................57

4.4.4

Validace dat před uložením .................................................................................58

4.4.5

Ošetření chybových událostí................................................................................58

4.4.6

Globální funkce a proměnné................................................................................59

4.5

Zabezpečení aplikace ................................................................................................59

4.5.1

Přihlašování uživatelů..........................................................................................59

4.5.2

Zabezpečení dat ...................................................................................................60

4.6

Práce s daty ...............................................................................................................61

4.6.1 5

Konvence pro názvy ovládacích prvků a proměnných ........................................62

Implementace řešení .........................................................................................................65 5.1

Metodiky způsobu vývoje aplikace ..........................................................................65

5.2

Časový harmonogram vývoje a zavedení aplikace...................................................69

5.3

Zkušební provoz .......................................................................................................70

5.4

Vyhodnocení zkušebního provozu a uvedení aplikace do provozu..........................70 6

Informační systém pro rozhodčí řízení 6

Zhodnocení a závěr...........................................................................................................71 6.1

Průběh vývoje aplikace a projektu............................................................................71

6.2

Přínosy aplikace........................................................................................................71

6.3

Budoucí rozvoj aplikace ...........................................................................................72

7

Seznam použité literatury a informačních zdrojů .............................................................73

8

Seznam obrázků a tabulek ................................................................................................75

9

Přílohy...............................................................................................................................77 9.1

Relační schéma databáze ..........................................................................................78

9.2

Popis tabulek databáze..............................................................................................79

9.3

Funkce FormFromEdit() ...........................................................................................83

9.4

Funkce pro vytvoření SQL dotazu............................................................................84

9.5

CD-ROM se zdrojovým kódem aplikace..................................................................85

7


1 Úvod V úvodu diplomové práce je popsán cíl práce a dále jsou zde vysvětleny základní pojmy z prostředí rozhodčího řízení, jež se budou v diplomové práci v dalších kapitolách vyskytovat a je vhodné s těmito pojmy seznámit.

1.1 Cíl práce Cílem diplomové práce je vytvořit nový informační systém zajišťující veškerou agendu sporů Rozhodčího soudu při Hospodářské komoře České republiky a Agrární komoře České republiky. Cílem nové aplikace bylo vytvoření aplikace pro uživatele co nejvíce podobné předchozí aplikaci jak designem, tak způsobem ovládání, aby byly na uživatele kladeny co nejmenší nároky při přechodu na nový systém. Naopak co se týče použitých technologií, tak systém byl zcela přepracován s využitím know-how z dlouholetého vývoje předchozí aplikace. Aplikace je koncipována jako třívrstvá architektura možnému napojení na databázi jinými aplikacemi než Evidence sporů a zejména je kladen důraz na integraci se systémem pro spory on-line a dále budoucí napojení na aplikace třetích stran, jako např. dokument server, recognition serveru, aplikaci V2T (Voice to text) a další. Tento systém nahradí stávající systém Evidence sporů, který byl poprvé implementován v roce 1995. Stará aplikace je založena na prostředí databázové aplikace Microsoft Access, která je součástí Microsoft Office 2003 Professional. Nový systém bude navazovat na stávající aplikaci a bude předělán ve vývojovém prostředí Microsoft .NET.

1.2 Přehled použitých výrazů z oblasti rozhodčího řízení Rozhodčí řízení Rozhodčí řízení v České republice je upraveno zákonem č. 216/1994 Sb., o rozhodčím řízení a o výkonu rozhodčích nálezů. Do 1.1.1995 (před nabytím účinnosti zákona 216/1994 Sb.) se rozhodovaly u Rozhodčího soudu jen spory z mezinárodního obchodního styku. S přijetím nového zákona o rozhodčím řízení se značně rozšířila oblast možného rozhodování sporů touto cestou mimo státní soudy, neboť současná

8

Informační systém pro rozhodčí řízení právní úprava umožňuje rozhodovat v rozhodčím řízení veškeré spory majetkové povahy s výjimkou sporů vzniklých v souvislosti s výkonem rozhodnutí a sporů vyvolaných prováděním konkurzu nebo vyrovnání, pokud se strany těchto sporů na tom dohodnou. Tradiční oblastí rozhodování sporů cestou rozhodčího řízení však nepochybně zůstává i nadále obchodní oblast, dnes díky současné právní úpravě neomezená již pouze na zahraniční obchod, ale zahrnující i obchod vnitrostátní. Rozhodčí řízení může probíhat jako řízení před jedním nebo více rozhodci jmenovanými stranami sporu pro tento konkrétní spor (řízení „ad hoc") nebo může mít podobu řízení před institucionálním rozhodčím soudem založeným na základě zákona (rozhodčí řízení institucionální). Rozhodčí řízení je neveřejné a podmínkou pro rozhodování sporu u Rozhodčího soudu je mít sjednanou rozhodčí doložku. Rozhodčí soud Rozhodčí soud byl založen v r. 1949 a působil v té době při Československé obchodní komoře. Později v r. 1980 byl jeho název změněn na Rozhodčí soud při Československé obchodní a průmyslové komoře a s účinností od 1.1. 1995 došlo ke změně názvu na Rozhodčí soud při Hospodářské komoře České republiky a Agrární komoře České republiky (dále jen Rozhodčí soud). Přes uvedené změny názvu jde stále o týž soud, který si vydobyl za dobu své existence významné postavení zejména mezi evropskými rozhodčími soudy. Velké vážnosti se však těší i mimo kontinent, neboť jsou před ním rozhodovány spory subjektů z celého světa. Dobrou pověst založil Rozhodčí soud zejména na činnosti rozhodců, zapsaných na listině rozhodců, kterou vede. Rozhodci jsou většinou advokáty, universitními pedagogy apod. Na listině rozhodců je zapsáno 216 rozhodců českých i zahraničních. Rozhodčí doložka Rozhodčí doložka se vkládá zpravidla do úvodních nebo závěrečných ustanovení příslušné smlouvy majetkové povahy. Je v ní stanoveno, že veškeré spory, které vzniknou v budoucnu při plnění smlouvy se budou řešit s konečnou platností u stálého Rozhodčího soud při Hospodářské komoře České republiky a Agrární komoře České

9

Informační systém pro rozhodčí řízení republiky. Strany se mohou dohodnout i na místě konání rozhodčího řízení. Rozhodce Rozhodce je obdoba soudce u běžného soudu. Rozhodce je zapsán na listině rozhodců a je jmenován stranou sporu, případně předsedou Rozhodčího soudu. Rozhodce není zaměstnancem Rozhodčího soudu. Rozhodci jsou renomovaní právníci a odborníci. Takže při rozhodování sporu si může strana vybrat z Listiny rozhodců rozhodce, který bude pro problematiku sporu odborně vyhovující. Intervenient Jedná se o osobu ve sporu, která nemá přímou souvislost se žalující nebo žalovanou stranu, ale je nějakým způsobem „zahrnuta“ ve sporu. Opatrovník Opatrovník k přijímání písemností může být jmenován předsedou Rozhodčího soudu dle Řádu, jestliže se nepodařilo doručit na poslední známou adresu účastníka, který nezvolil ani právního zástupce, ani zmocněnce k přijímání písemností. Rozhodčí senát Je zpravidla tříčlenný a skládá se z rozhodců zvolených stranami (nebo jmenovanými předsedou RS) a předsedou rozhodčího senátu, který je volen rozhodci, případně předsedou RS. Rozhodčí senát vydává rozhodčí nález. Strany se mohou dohodnout na jediném rozhodci, který rozhoduje spor sám. Rozhodčí nález Rozhodčí nález je obdobou rozsudku u běžného soudu. Rozhodčí nález je konečný a nelze se proti němu odvolat. Rozhodčí nález je současně exekučním titulem využitelným pro zahájení exekučního řízení v případě, že povinná strana rozhodnutí rozhodčího soudu nerespektuje a neplní.

10


2 Analýza požadavků na aplikaci V této kapitole je popsán starý systém a následně jsou popsány požadavky na nový systém, který je předmětem této diplomové práce.

2.1 Popis současného stavu 2.1.1 Informační systém Evidence sporů V současné době je na Rozhodčím soudě informační systém Evidence sporů, který jsem vytvořil a implementoval v roce 1996 a dodnes se průběžně tento program vyvíjí dle požadavků RS. Informační systém je naprogramován v Microsoft Access 2003, data jsou sdílena prostřednictvím serveru. Jedná se o dvouvrstvou architekturu. Tento software zpracovává veškerou agendu sporů a je rozdělen do následujících základních modulů. Spory V tomto modulu jsou základní informace o sporu, jako je datum podání žaloby, hodnota sporu, žalující a žalované strany, lhůty, přehled poplatků za spor, přehled ústních jednání, všechny dokumenty vztahující se ke sporu a další procesní data. Na obrázku č. 1 je ukázka obrazovky modulu spory programu Evidence sporů.

11


Obrázek 1. Ukázka programu Evidence sporů – modul spory

Adresář V tomto modulu jsou uloženy adresy všech rozhodců, stran, zástupců stran a dalších subjektů, které ani nemusí mít nic společného s rozhodčím řízením. Adresář disponuje mnoha funkcemi, jako např. hromadná korespondence, hromadné maily, ukládání výběrů adres a pod. Adresy se rozlišují na stranu, rozhodce, zástupce, cizí soud, složku Hospodářské komory a ostatní. V adresáři není rozlišení mezi fyzickými a právnickými osobami. Ukázka modulu adresář je na obrázku č. 2.

12


Obrázek 2. Ukázka modulu adresáře Ekonomická část Zde jsou prováděna konečná vyúčtování poplatků v rozhodčím řízení, vyúčtování zálohových plateb, výpočty honorářů rozhodců a jejich evidence včetně následného exportu do bankovního software Eltrans. Ekonomická část je rozdělena následovně: Interní sdělení účtárně Zde se provádí po ukončení sporu závěrečné vyúčtování sporu, sečtou se všechny zaplacené poplatky, paušály a zálohy a vyúčtují se skutečnými výdaji. Výstupem je sestava Interní sdělení účtárně, která slouží jako účetní doklad pro zaúčtování do výnosů v ekonomickém software. Předpokládané výnosy Jedná se o pomocný nástroj pro výpočet předpokládaných výnosů za vybrané období. Výpočet je pouze orientační a vychází pouze z hodnoty sporu a kalkuluje se standardními poplatky a honoráři rozhodcům. Přesto ale poskytuje poměrně přesný

13

Informační systém pro rozhodčí řízení odhad budoucího hospodářského výsledku, jelikož nestandardní náklady a výnosy celkový odhad příliš nezkreslí. Faktury V tomto modulu se vystavovaly faktury za nestandardní poplatky, které se netýkaly přímo rozhodčího řízení. Tento modul se již přestal používat, jelikož se faktury vystavují přímo v ekonomickém software. Honoráře Modul honoráře je rozdělen na tři části. První část je výpočet honorářů při ukončení sporu a přenos vypočtených částek do druhé části (rozpracované honoráře), kde se tiskne účetní doklad pro rozhodce a následně se hromadně přenáší vystavené honoráře k výplatě (přenos do platebních příkazů). Třetí část je archiv vyplacených honorářů a je zde možné filtrovat záznamy dle data vyplacení honoráře, čísla sporu, jména rozhodce a funkce rozhodce. Dále je zde možný tisk souhrnného přehledu vyplacených honorářů pro jednotlivé rozhodce za zvolené období, zpravidla to bývá kalendářní rok a hlášení o součinnosti dle § 34 zákona 337/1992 Sb. (Zákon o správě daní a poplatků). Platební příkazy Modul platebních příkazů byl dříve požíván pro vytváření hromadných i jednoduchých platebních příkazů a následný tisk. Po zavedení elektronického bankovnictví přibyla funkce exportu platebního příkazu do souboru. Přestože je tento modul již nepotřebný, jelikož export plateb do elektronického bankovnictví by se mohl provádět přímo z modulu honorářů a ušetřilo by se několik kliknutí, tak na přání uživatelů byl postup honoráře → platební příkazy → export do elektronického bankovnictví zachován. Poplatky za překlady V tomto modulu se průběžně sledují poplatky za překlady u cizojazyčných sporů, zda-li nepřekročily zaplacenou zálohu za překlady a dále se pak záznamy o jednotlivých platbách za překlady přenášejí do závěrečného vyúčtování sporu (Interní sdělení účtárně).

14


Poplatky za znalečné Jedná se o úplně stejný modul jako předchozí modul, jen s tím rozdílem, že se sleduje čerpání poplatků za znalecké posudky. Kurzy ČNB Tento modul umožňuje vyhledat dle data a požadované měny kurz České národní banky (ČNB). Jedná se spíše o doplňkovou funkci, kde se využívá toho, že jsou kurzy ČNB uloženy v databázi. Ty jsou automaticky každý den stahovány z webových stránek ČNB a uloženy v databázi. Používají se pro automatický přepočet plateb v cizí měně na koruny. Dokumenty V modulu dokumentů se vytvářejí automatické dokumenty na základě dat uložených v programu Evidence sporů. Dokumenty se vytvářejí pomocí průvodce, kde si uživatel zvolí druh dokumentu a jazykovou verzi dokumentu, který chce vytvořit (obrázek č. 3).

Obrázek 3. Průvodce formulářem - výběr šablony dokumentu Následuje výběr adresáta (obrázek č. 4) a následně jsou do příslušného dialogového

15

Informační systém pro rozhodčí řízení okna, doplněna data z databáze, která referent zkontroluje a poté se vygeneruje dokument v aplikaci MS Word (obrázek č. 5). V posledním dialogu se zvolí způsob odeslání dokumentu a případný popis.

Obrázek 4. Průvodce formulářem - výběr adresáta

Obrázek 5. Průvodce formulářem - kontrola a doplnění dat z databáze Ústní jednání Modul ústní jednání slouží pro plánování a zobrazování nařízených ústních jednání.

16

Informační systém pro rozhodčí řízení Náhled na modul Ústní jednání je na obrázku č. 6. Formulář pro prohlížení ústních jednání je podobný kalendáři MS Outlook. Pohled je možný na konkrétní vybraný den, týden a měsíc. Ve formuláři lze filtrovat data podle referenta, kterému spor patří, tak rozhodce, který je v rozhodčím senátu.

Obrázek 6. Formulář ústní jednání, pohled na jeden den Statistiky V tomto modulu má uživatel možnost zobrazení a tisku mnoha statistik sporů. Jedná se např. o statistiky počtu sporů, jmenování rozhodců, počty aktivních a ukončených sporů pro jednotlivé referenty sporů a mnoho dalších statistik. Tiskové sestavy V tomto modulu jsou různé tiskové sestavy, které nebyly zařazeny přímo do jednotlivých modulů. Jedná se např. o sestavy na označení spisu, statistické sestavy pro předsednictvo (počty sporů dle rozhodců, přehledy usnesení apod.). Nástroje Jedná se o pomocný modul s nástroji pro nastavování parametrů. Je zde např. změna hesla, možnost zvolit zástupce referenta po dobu nepřítomnosti a dále jsou zde administrátorské funkce, jako je správa uživatelů, měn, bankovních účtů apod.

17


2.1.2 Ekonomický software Altus Vario Jedná se o systém pro vedení podvojného účetnictví a zpracování mezd. Tento systém je síťový a slouží převážně externí účetní firmě, která zpracovává účetní agendu. Je postaven na stejné architektuře jako IS Evidence sporů. Používá také databázový soubor ve formátu MS Access mdb, čímž je možné číst některá data z tohoto programu. Konkrétně se využívají data platebních příkazů, které se pomocí programu Evidence sporů exportují do Eltransu. Eltrans 2000 Jedná se o systém elektronického bankovnictví Gemini firmy BSC Praha, který UniCredit Bank (dříve systém Živnostenské banky) nabízí klientům pod názvem Eltrans 2000. Jedná se standardní bankovní aplikaci, kde jsou data uložena u klienta a s bankou probíhá spojení a výměna dat prostřednictvím protokolu TCP/IP. V tomto systému probíhá zpracování platebních příkazů a bankovních výpisů. Bankovní výpisy se exportují do souboru, který se zpracovává v ekonomickém software Altus Vario. Platební příkazy týkající se sporů se importují do Eltransu přímo z Evidence sporů. V Eltransu probíhá pouze autorizace oprávněným uživatelem a odeslání do banky.

2.2 Obecné požadavky na nový systém Vzhledem k technologické zastaralosti stávající aplikace je z hlediska budoucího rozvoje aplikace přejít na nové moderní technologie. Rozhodčí soud má na nový informační systém následující požadavky, které jsou současně i zadáním pro vývoj nového IS. •

IS musí vycházet ze stávajícího systému Evidence sporů, který byl průběžně vyvíjen a uživatelé jsou zvyklí na způsob používání a ovládání Evidence sporů.

•

Jako databázový stroj bude použit MS SQL Server 2005, ale systém musí být

18

Informační systém pro rozhodčí řízení přizpůsobitelný i na jiný databázový stroj bez velmi rozsáhlých změn v aplikaci. •

Musí být zachovány stávající moduly, z větší části i design a způsob ovládání. U designu a způsobu ovládání se nepředpokládá, že půjde o přesnou kopii stávajícího stavu, ale jde o to, aby uživatelům činil co nejmenší problém přechod na nový IS.

•

Musí být zajištěn plynulý přechod na nový systém. Ideální by byl stav, kdy by po přechodnou dobu byla nová aplikace provozována se starými zdrojem dat a po odladění a zaškolení uživatelů na novou aplikaci se provede přechod na jiný databázový stroj.

•

V databázi musí být zahrnuta částečně i business logika, aby bylo možné využívat databázi případně i jinými programy. Zejména se počítá s webovou aplikací pro přístup k informacím o sporech ze sítě Internet.

•

IS bude vytvořen v Microsoft Visual Studio .NET 2008, aby došlo k nezávislosti na MS Access a mohlo se při budoucím upgradu MS Office přejít z verze Professional na verzi Standard, která neobsahuje MS Access.

•

IS musí mít uživatelské role závislé na přihlášeném uživateli. Definice jednotlivých rolí a práva budou součástí technické specifikace.

•

Data musí být zabezpečena před neoprávněným použitím a zkopírováním.

•

IS musí být jednoduše upgradovatelný na novější verzi, klientské stanice se musí upgradovat automaticky při vydání nové verze IS a jejím nainstalování na server.

2.3 Role uživatelů S IS budou pracovat všichni zaměstnanci Rozhodčího soudu a také musí být zajištěno, aby mohli k databázi přistupovat v budoucnu i další uživatelé, zejména pomocí webových služeb, a proto je třeba rozdělit uživatele IS do několika rolí. Níže je uveden popis jednotlivých rolí uživatelů.

19


2.3.1 Popis role referenta sporů Referent sporů využívá IS jako hlavní pracovní nástroj a provádí v IS veškeré úkony spojené s agendou sporu. Každý referent má přidělené spory, za které zodpovídá. Spor je referentovi přidělen až po zaplacení poplatků za spor. V IS sleduje průběh sporu, kontroluje dodržování lhůt u svých sporů a vytváří pomocí nástrojů IS dokumenty. Referent sporu si plánuje a nařizuje ústní jednání u svých sporů. Po přidělení sporu referentovi (provádí tajemník nebo účetní) může spor editovat pouze referent, jemuž byl spor přidělen. V případě jeho nepřítomnosti (dovolená, nemoc atd.) si referent zvolí svého zástupce, na kterého deleguje veškeré své práva ke svým sporům. Delegovanému referentovi se automaticky přiřadí práva pro editaci těchto sporů a zároveň se mu do jeho seznamů lhůt a notifikací zahrnou i lhůty referenta, jenž mu přidělil své spory. V případě editace přidělených sporů provádí referent úkony svým jménem. Referenti mohou nahlížet i do jiných sporů s výjimkou těch údajů, na která je třeba zvláštní práva. Role referenta je znázorněna pomocí jazyka UML použitím Use Case Diagramu na obrázku č. 7.

20


Obrázek 7. Use Case diagram role referenta sporů

2.3.2 Popis role zapisovatelky Zapisovatelka má právo pro čtení údajů o sporech a má povoleno pouze vytvářet a editovat zápisy z ústních jednání. Tyto dokumenty vytváří pod svým jménem. Zapisovatelka nemá právo editace ústních jednání. Role zapisovatelky je znázorněna na obrázku č. 8.

21


Obrázek 8. Use Case diagram role zapisovatelky

2.3.3 Popis role účetní Účetní má na starosti u sporů vše spojené s financemi. Tato role je rozdělena mezi dvě zastupující se osoby a dále popsané činnosti si dělí mezi sebou dle potřeby. U nových sporů generuje výzvu k platbě a následně sleduje lhůty na zaplacení poplatků za spory. Po zaplacení sporu přiděluje spor dle pokynu tajemníka přidělenému referentovi. Po ukončení sporu (po vydání rozhodčího nálezu nebo usnesení o zastavení rozhodčího řízení) přechází spor z procesní aktivity do ekonomické aktivity a je třeba spor ukončit účetně. Jedná se zejména o vyplacení honorářů rozhodčímu senátu, vyúčtování záloh na překlady, znalce apod. Po provedení těchto vyúčtování a vyplacení honorářů se vystaví souhrnný účetní doklad ke sporu. Platby vytvořené v IS přenese do bankovního software pro elektronický platební styk, kde se platby následně zpracovávají. Role účetní je znázorněna na obrázku č. 9.

22


Obrázek 9. Use Case diagram role účetní

2.3.4 Popis role pracovníka podatelny Pracovnice podatelny zakládají v IS nové spory na základě došlých žalob. U nových sporů přidělují číslo sporu a zapisují do IS zúčastněné strany. K ostatním sporům pouze přístup pro čtení. U nařízených ústních jednání mohou měnit pouze zasedací místnost. Termíny ústních jednání jsou plánovány referenty, ale pracovnice podatelny může operativně změnit zasedací místnost. Dále pracovnice podatelny tiskne informační ceduli ke konanému ústnímu jednání, kterou následně vyvěšuje u zasedací místnosti. Pracovnice podatelny si generují na základě vytvořených dokumentů všech referentů ve zvoleném období (zpravidla jeden den) sestavu podacího listu pro podání na České poště. Role pracovníka podatelny je znázorněna na obrázku č. 10.

23


Obrázek 10. Use Case diagram role pracovníka podatelny

2.3.5 Popis role tajemníka Tajemník má oprávnění nahlížení a editace do všech údajů o sporu, ale jeho role je zejména kontrolní a dohlíží na práci jednotlivých referentů sporů. Tajemník má k dispozici pomocné nástroje na sledování lhůt u jednotlivých referentů s možností filtrování dle referenta, poplatkových lhůt a lhůt na vyplacení honorářů rozhodčím senátům. Dále jsou tajemníkovi k dispozici statistické sestavy sporů, jako počty sporů s rozlišením na vnitrostátní, mezinárodní a on-line spory, statistiky počtů sporů jednotlivých referentů, počtu vygenerovaných dokumentů atd. Role tajemníka je znázorněna na obrázku č. 11.

24


Obrázek 11. Use Case diagram role tajemníka

2.3.6 Popis role rozhodce Rozhodce nemá v IS popisovaném v této práci žádnou roli, ale je sním počítáno v jiné webové aplikaci, kde bude mít možnost nahlížení do spisu pomocí dálkového přístupu.

2.3.7 Popis role strany sporu Strana sporu (žalující nebo žalovaná) nemá v IS popisovaném v této práci žádnou roli, ale je sním počítáno v jiné webové aplikaci, kde bude mít možnost nahlížení do spisu pomocí dálkového přístupu.

2.4 Podrobná specifikace jednotlivých modulů 2.4.1 Modul Spory Tento modul je hlavním modulem pro práci s aplikací. Zde jsou obsaženy všechny informace o sporu. Formulář modulu sporů je logicky rozdělen pomocí přepínacích

25

Informační systém pro rozhodčí řízení karet na základní informace, průběh sporu a platby, lhůty a ústní jednání, dokumenty a ostatní zúčastněné osoby. Vlevo je rychlý navigační pruh s čísly sporů dle aktuálního výběru, který je zobrazen nezávisle na zvolené kartě pohledu, není však zobrazován při editaci sporu. Níže je uveden výčet jednotlivých ovládacích prvků s popisem. Karta Základní informace Číslo sporu Jedná se o pořadové číslo sporu počítané každý kalendářní rok od jedničky. Formát čísla je ve formátu X / RR, kde X je pořadové číslo a RR poslední dvojčíslí roku, ve kterém byla podána žaloba. Hodnota sporu a protižaloba Hodnota sporu se vyjadřuje v částce a měně, která je uvedena v žalobě. Tato hodnota je uváděna i v přepočtu na Kč dle aktuálního kurz ČNB v den podání žaloby. Dále je u hodnoty sporu uváděno zda-li je hodnota sporu s příslušenstvím (úroky, penále). Kromě hodnoty sporu se u některých žalob může vyskytovat protižaloba, která má stejné položky jako hodnota sporu. U žalované hodnoty sporu je uvedeno datum podání žaloby, případně datum podání protižaloby. Datum podání žaloby, protižaloby a ukončení sporu Datum podání žaloby je povinné pole, datum podání protižaloby je povinné, pokud je zadána protižaloba. Dle tohoto data se počítá převodní kurz pro spory nevedené v korunách. Ukončení sporu je datum vydání rozhodčího nálezu nebo usnesení o zastavení rozhodčího řízení a pod tímto datem je způsob ukončení sporu. Po zadání data ukončení se automaticky při ukládání sporu zruší procesní aktivita sporu. Informace o druhu řízení a referentovi Mezinárodní nebo vnitrostátní spor má v databázové tabulce své pole, ale explicitně se nezadává, ale je při ukládání sporu zkontrolováno, zda-li jsou všechny žalující a žalované strany tuzemské a podle toho se nastaví booleovská hodnota VnitrSpor v tabulce tblSpory. Na formuláři je vnitrostátní spor vizuálně znázorněn malým obrázkem české vlajky a mezinárodní obrázek zeměkoule.

26

Informační systém pro rozhodčí řízení Druh řízení informuje jestli se jedná o standardní rozhodčí řízení nebo urychlené, případně on-line řízení nebo spotřebitelský spor. Dále je uveden referent sporu a datum podepsání rozhodčí doložky. Žalující a žalované strany V každém sporu je uvedena minimálně jedna žalující a žalovaná strana. U každé žalující nebo žalované strany může být uveden zástupce strany a datum podepsání plné moci pro zastupování strany. Rozhodčí senát Rozhodčí senát je buď tříčlenný, skládající se ze dvou rozhodců za žalující a žalovanou stranu a předsedy rozhodčího senátu, kterého si volí rozhodci za žalující a žalovanou stranu. Dohodnou-li se strany na jediném rozhodci, je jmenován pouze jeden jediný rozhodce. U rozhodců (včetně jediného rozhodce) se eviduje údaj o datu jmenování a kým byli jmenováni (stranou nebo předsedou Rozhodčího soudu) a u předsedy senátu se eviduje datum zvolení. U předsedy a rozhodců se eviduje datum expedice jmenování nebo oznámení o zvolení. Dále je u rozhodců nebo předsedy evidován údaj o jmenování (zvolení) ad hoc. To znamená, že rozhodce není zapsán na stálé listině rozhodců. U sporu jsou dále evidovány položky o druhu řízení (běžné, urychlené, on-line, spotřebitelský spor), referent, který má spor přidělen, datum podepsání rozhodčí doložky, datum vydání usnesení o zastavení řízení nebo datum vydání rozhodčího nálezu a způsob ukončení (rozhodčí nález nebo usnesení). V tomto modulu se dále evidují všechny procesní data, vyměřené poplatky za žalobu včetně měny, lhůty zaplacení a data zaplacení. Dále se evidují procesní lhůty s datem vypršení lhůty a příznakem splnění a nařízená ústní jednání. V modulu Spory se evidují další zúčastněné osoby ve sporu, jako jsou znalci, opatrovník, likvidátor nebo vedlejší intervenient. Ústní jednání může nařizovat uživatel jen pro své spory nebo pro spory referenta kterého zastupuje.

27


Karta Průběh sporu a platby Na této kartě jsou zobrazena procesní data, která jsou logicky, případně, pokud je to možné, chronologicky uspořádána. V dolní části formuláře jsou vystavené poplatky. Zobrazuje se datum výzvy, lhůta, druh poplatku, částka, měna, kurz, datum zaplacení a poznámka. Kurz se doplňuje automaticky dle data výzvy k zaplacení poplatku. Karta Lhůty a ústní jednání Na této kartě se zobrazují společně lhůty a procesní události, kde se zobrazuje popis události, datum (lhůta), poznámka a příznak, zda-li byla lhůta splněna. V tabulce č. 1 jsou uvedeny lhůty, které systém nastavuje automaticky na základě nějaké procesní události. Zkratky použité v tabulce č. 1. VS – vnitrostátní spory, MS –mezinárodní spory, UR1 – urychlené řízení s vydáním rozhodčího nálezu do 1. měsíce, UR3 - urychlené řízení s vydáním rozhodčího nálezu do 3. měsíců Popis

Nastavení

Lhůta

Lhůta na žalobní odpověď

Vygenerování dokumentu žalované straně o oznámení o podání žaloby Po najmenování druhého rozhodce za žalující nebo žalovanou stranu Po zadání data ukončení projednávání sporu Po zaplacení poplatku za žalobu

30 (MS) 15 (VS)

Lhůta zvolení předsedy

Lhůta pro vypracování rozhodčího nálezu Lhůta jmenování rozhodce za žalující stranu Lhůta jmenování rozhodce za žalovanou stranu

Po doručení žalobní odpovědi

Po potvrzení závazného termínu Lhůta pro obeslání účastníků řízení k dostavení se na ústní ÚJ rozhodčím senátem jednání Lhůta pro obeslání účastníků Po odročení ústního jednání řízení při odročení ústního jednání

15

30 30 (MS) 15 (VS) 30 (MS) 15 (VS) 2

2

Tabulka 1. Přehled automaticky nastavovaných procesních lhůt

28


Ústní jednání jsou zobrazena jednoduše pro přehled, kdy byla a jsou v aktuálním sporu nařízena ústní jednání. Tato část pohledu na ústní jednání neslouží pro nařizování a editaci ústních jednání, k tomu je určen samostatný modul. Je však možné se z tohoto místa přepnout do modulu ústních jednání a ihned zadávat ústní jednání pro aktuální spor. Karta Dokumenty Na této kartě jsou zobrazeny všechny dokumenty k aktuálnímu sporu. Dokumenty lze zde zobrazit, mazat, odeslat e-mailem, nebo vložit dokument z libovolného úložiště. Karta Ostatní zúčastněné osoby Zde jsou zobrazeny informace o ostatních zúčastněných osobách ve sporu, které se ale vyskytují zřídka, proto je tato karta umístěna na konec. Jedná se o vedlejšího intervenienta, likvidátora, opatrovníka a znalce.

2.4.2 Modul Adresář Adresář je nezbytnou součástí téměř každého informačního systému. V adresáři pro Evidenci spor se ukládají položky jméno, název firmy, adresa sídla a korespondenční adresa, stát, IČ, DIČ, rodné číslo a datum narození (u fyzických osob), číslo účtu, kontakty (telefon, fax, mobil, e-mail, web a dále příznaky pro filtrování (rozhodce, strana, zástupce, sudiště). Kromě výše uvedených standardních informací musí splňovat následující požadavky kladené ze strany Rozhodčího soudu. Možnost vkládání adresy pomocí zadání IČ a následné získání adresy z veřejné databáze ARES pomocí XML služby Musí být zabezpečeno aby nešla smazat adresa, která je součástí nějakého sporu. Adresář musí umožňovat vytváření uživatelem definovaných výběrů, se kterými se následně pracuje při exportu data a hromadných e-mailech. Při vkládání nové adresy se provádí kontroly na již existující podobné záznamy.

29

Informační systém pro rozhodčí řízení U starého systému byly problémy s tím, že uživatelé nekontrolovali při zadávání zda-li již adresa není v adresáři. Při vkládání a změnách v adresáři je požadováno zalogování kdy a kdo změnu provedl včetně opisu dat, která byla vložena nebo změněna. Při vkládání adresy sídla (toto pole je v tabboxu viditelné) se automaticky propíše vložená adresa do korespondenční adresy. V případě pozdější editace adresy sídla (kdy je už zadána korespondenční adresa) je třeba uživatele upozornit aby zkontroloval korespondenční adresu. Automatický přepis není vhodný, jelikož se ve staré verzi toto neosvědčilo. Při přepisu korespondenční adresy se dotaz na kontrolu adresy sídla nezobrazuje.

2.4.3 Modul Ústní jednání V tomto modulu se zobrazuje přehled nařízených ústních jednání (dále jen ÚJ). Pro přehlednost se ÚJ zobrazují jako v kalendáři MS Outlooku. Uživatel si může volit mezi zobrazením dne, týdne nebo měsíce. Uživatel musí mít možnost zobrazení ÚJ za vybrané období pro jednoho rozhodce nebo dle sporů vybraného referenta. Nařízené ÚJ je třeba rozlišit dle místa konání ÚJ a dále odlišit nepotvrzená ÚJ a odročená ÚJ (ty se budou zobrazovat jen po explicitní volbě). Každý uživatel si bude moci tisknout přehled nařízených ÚJ a dále se z tohoto modulu budou tisknout informační cedule na dveře zasedacích místností s informacemi o probíhajícím sporu a zasedajícím senátu. Po nařízení ÚJ se automaticky vytvoří lhůta pro obeslání účastníků řízení. Tato lhůta je jedna z nejdůležitějších a na její splnění bude referent sporu automaticky upozorňován až do její splnění. Při nařizování a editaci ÚJ je třeba respektovat následující požadavky: ÚJ může nařizovat nebo editovat pouze uživatel s příslušnými právy. Referent sporu může editovat pouze poznámku u nařízeného ÚJ a to pouze u svých sporů. Při přidání ÚJ se vytvoří lhůta pro obeslání stran, v případě, že je ÚJ nařízeno protokolem, tak se tato lhůta nevytváří.

30


2.4.4 Modul Honoráře rozhodců Pokud se spor účetně ukončí, tak v tomto modulu se provede vyúčtování odměn rozhodčího senátu, případně dalších odměn, jako jsou odměny za projednání a vypracování námitek nepříslušnosti pravomoci rozhodování Rozhodčího soudu. Nejprve se provede výpočet honorářů dle sazebníku odměn. U honorářů je nutné evidovat datum vystavení, datum podepsání rozhodcem, za co je honorář vyplácen a jméno rozhodce. Aplikace musí umožňovat hromadné vystavování odměn rozhodců a následný dávkový přenos do bankovního software Eltrans 2000. Data musí být archivována a na konci kalendářního roku se vytisknou souhrnné doklady o vyplacených honorářích.

2.4.5 Modul Generování dokumentů Jedná se o nástroj pro automatizované vytváření dokumentů. Dokument se vytváří pomocí průvodce, kde se nejprve vybere jazyková verze a šablona dokumentu. Následně se zvolí adresát, kterému bude dokument určen, a poté se dle zvolené šablony zobrazí dialogové okno, kde jsou již předvyplněna data z databáze, která referent zkontroluje a po potvrzení se vygeneruje dokument v MS Wordu, který může referent dále editovat. Dokument se automaticky ukládá na server a název a cestu souboru určuje aplikace a referent toto nemůže ovlivnit. Postup generování dokumentu je znázorněn pomocí jazyka UML použitím Activity Diagramu na obrázku č. 12.

31


Obrázek 12. Activity diagram generování dokumentu

2.4.6 Modul Statistiky V tomto modulu jsou předdefinovány statistické sestavy, které jsou pravidelně předkládány předsednictvu Rozhodčího soudu, nebo slouží pro rozhodování tajemníka např. při přidělování sporů. Zadavatel požaduje implementovat následující statistické sestavy:

32

Informační systém pro rozhodčí řízení - Přehled počtu sporů za vybrané období s rozčleněním na mezinárodní a vnitrostátní spory, počet otevřených sporů, vydaných rozhodčích nálezů, počet nezaplacených sporů, počet zpětvzetí a počet vydaných usnesení za zvolené období. - Přehled ústních jednání dle místa konání za zvolené období. - Přehled sporů u jednotlivých referentů s rozdělením na probíhající spory, spory čekající na vyúčtování a spory čekající na nabytí právní moci.

33


3 Návrh řešení 3.1 Spuštění a přihlášení do IS Aplikace se bude spouštět standardním způsobem, ikona bude umístěna nejspíše na pracovní ploše. Vzhledem k tomu, že IS je hlavní používanou aplikací na RS, je možné aplikaci spouštět při startu systému. Po spuštění aplikace dojde k zalogování uživatele, čímž se jednoznačně při přihlášení určí jeho role a následné oprávnění do jednotlivých modulů IS. Při analýze IS je třeba zvážit použití klasického přihlašování do aplikace jménem a heslem, nebo využít možnosti integrovaného přihlášení do Windows, tzv. single sign on. Přestože použité technologie umožňují použití single sign-on, v aplikaci bylo zvoleno klasické přihlášení do aplikace a ověřování samotnou aplikací, a to zejména z důvodu, že tomu tak bylo v předchozí aplikaci a vzhledem k maximálnímu možnému přebírání ověřených postupů bylo přijat i tento způsob přihlašování, i když není vyloučen v budoucnu přechod na single sign-on přihlašování.

3.2 Modul Spory Modul sporů je hlavním modulem aplikace a formulář sporů se spouští jako první při spuštění aplikace. Design formuláře byl zvolen obdobně jako u předchozí aplikace a je rozdělen pomocí karet na skupiny základní informace o sporu, průběh sporu a platby, lhůty a ústní jednání, dokumenty a ostatní zúčastněné osoby. V záhlaví formuláře pod menu jsou odkazy pro rychlé spouštění nejčastěji používaných modulů a funkcí. Po levé straně je seznam sporů dle aktuálního výběru, který je skryt při přechodu do režimu editace záznamu. Po pravé straně jsou ovládací tlačítka, která se dynamicky přizpůsobují buď podle zvolené karty nebo dle režimu (prohlížení/editace). Při spuštění jiného modulu je tento modul spuštěn v modálním okně, to znamená, že není možné kliknutím přejít zpět do formuláře sporů, aniž by se uzavřelo zobrazené okno. Ukázka formuláře sporů je zobrazena na obrázku č. 13.

34


Obrázek 13. Formulář hlavního modulu Spory

3.3 Adresář Design formuláře byl opět převzat z původní aplikace a je zobrazen na obrázku č. 14. U adresáře se mění ovládací tlačítka a skrývají ovládací prvky v závislosti na režimu zobrazení. Adresář je zobrazován buď standardně po stisku tlačítka v menu nebo nástrojovém pruhu, dále se zobrazuje při vkládání rozhodců, stran a dalších osob ve sporu a také při kliknutí na detail adresy. V každém režimu se zobrazí jen ty ovládací prvky, které jsou potřeba pro další práci s vybranou, editovanou nebo vkládanou adresou.

35


Obrázek 14. Formulář modulu Adresář

3.4 Ústní jednání Ovládací prvky Na formuláři pro ústní jednání nejvíce prostoru je určeno pro zobrazování ústních jednání. Vlevo je umístěn ovládací prvek kalendář, kde si uživatel volí den, pro který chce zobrazit ústní jednání. Při spuštění formuláře se defaultně nastavuje aktuální den. V záhlaví jsou přepínací tlačítka, která se při zavedení formuláře dynamicky popíší dle aktuálního data, aby mohl uživatel rychle volit pohled mezi dnem, týdnem, příštím týdnem, aktuálním měsícem a následujícími dvěma měsíci za aktuálním měsícem. Za přepínacími tlačítky jsou rozbalovací seznamy pro možnost filtrování ústních jednání dle referenta nebo rozhodce, který je členem senátu. V pravé části jsou tlačítka pro přidání ústního jednání a tisk přehledu ústních jednání. Dále je použito při kliknutí pravým tlačítkem myši kontextové menu, které umožňuje tisk informační cedule na zasedačku s popisem ústního jednání, přechod na spor v hlavním formuláři sporů a dále editace nebo smazání ústního jednání. Pro vizuální přehlednost jsou pole zobrazující ústní jednání podbarvena. Popis barev je v zápatí formuláře. Barevně se odlišují nepotvrzená ústní jednání (šedá barva), odročená ústní jednání (červená barva) a ústní jednání konaná mimo Prahu v regionálních

36

Informační systém pro rozhodčí řízení sudištích (zelená barva). Odročená ústní jednání se standardně nezobrazují. Popis jednotlivých pohledů Pro ústní jednání byl navržen formulář ve stylu kalendáře MS Outlooku, který se přepíná do tří pohledů, a to na denní pohled, kde se zobrazují ústní jednání pro vybraný den a první tři sloupce jsou rozděleny dle zasedaček, čtvrtý sloupec je rezervní místnost v knihovně nebo v pracovně rozhodců a v posledním sloupci se zobrazují ústní jednání mimo Prahu v regionálních sudištích. Těchto ústních jednání nebývá zpravidla mnoho, proto je možné je zobrazit v jednom sloupci. Formulář pro ústní jednání v denním pohledu je zobrazen na obrázek č. 15.

Obrázek 15. Návrh formuláře ústních jednání – pohled na jeden den Týdenní pohled na ústní jednání je zobrazen na obrázku č. 16. Na první pohled zaujme jiná barva pozadí, což je úmyslně, aby bylo referentovi na první pohled patrné v jakém pohledu se nachází. Způsob ovládání je stejný jako u denního pohledu.

37


Obrázek 16. Návrh formuláře ústních jednání – pohled na týden U měsíčního pohledu na ústní jednání (obrázek 17) se již nevypisují detaily sporů a nevykreslují se dle času, ale pouze se v matici dnů, které se zobrazí při přepnutí na tento pohled, zobrazí čísla sporů. V matici se nezobrazují soboty a neděle jednak z důvodu úspory místa plochy formuláře a také z důvodu, že o sobotách a nedělích se ústní jednání nekonají.

Obrázek 17. Návrh formuláře ústních jednání – pohled na kalendářní měsíc

38

Informační systém pro rozhodčí řízení Vkládání a změna ústních jednání Po kliknutí na tlačítko Přidat ÚJ (toto tlačítko je k dispozici i v hlavním formuláři sporů na kartě s ústními jednáními.se zobrazí formulář pro přidání nebo editaci ústního jednání, který je zobrazen na obrázku č. 18. Opět využívá jednoho formuláře, který je při režimu vkládání zobrazen prázdný (resp. jen s číslem sporu) a při režimu editace je naplněn aktuálními daty.

Obrázek 18. Formulář pro editaci ústního jednání Kontrola dat při ukládání - Kontrola, zda-li ÚJ není nařízeno dříve než za 20 dnů u vnitrostátních sporů a 40 dnů u mezinárodních z důvodu doručení předvolání ve lhůtě dle Řádu. - Kontrola na kolizi zasedací místnosti v den a hodinu. - Po úspěšné kontrole se vkládá lhůta pro obeslání stran v případě, že je ÚJ potvrzené.

39


3.5 Honoráře rozhodců Pro výpočet honorářů rozhodcům slouží tři formuláře. První formulář je pro výpočet honorářů jednotlivým členům rozhodčího senátu, druhý je pro práci s honoráři od vyměření honoráře do jeho vyplacení a třetí formulář slouží jako archiv vyplacených honorářů.

3.6 Kurzovní lístek ČNB Formulář pro kurzovní lístky je spíše doplňkem aplikace, jelikož vyhledávání kurzu pomocí tohoto formuláře probíhá spíše výjimečně. Kurzy se do databáze stahují přímo z webu ČNB a v případech, kdy se používá kurz ČNB si aplikace vyhledá požadovaný kurz přímo v tabulce a dále s ním pracuje. Kontrola, zda-li je v databázi aktuální kurz probíhá vždy při startu aplikace, a to na každé stanici. ČNB vydává aktuální kurzy pro daný den až odpoledne po 14. hodině. Kurz není potřeba stahovat ihned, jelikož praxe ukázala, že se téměř nestane, aby bylo zapotřebí po 14.hodině použít aktuální kurz. Funkce pro stažení kurzu z webu ČNB stahuje kurzovní lístek jako textový soubor, který

je

umístěn

na

webu

České

národní

banky

a

má

adresu

adresu

http://www.cnb.cz/cs/financni_trhy/devizovy_trh/kurzy_devizoveho_trhu/denni_kurz.txt a jako

parametr se přidá ?date=yyyymmdd. Jelikož se již v minulosti stalo, že cesta byla změněna,

je

tento

parametr

uložen

v tabulce

s globálním

nastavením

ptblGlobalniNastaveni. Pro import kurzu se používají následující funkce. KontrolaKurzu – funkce zkontroluje, zda-li je v tabulce kurzů zapsán kurz pro aktuální den ImportzWebu – sestaví dle požadovaného data URL adresu s kurzem a provede jeho stažení do pracovního adresáře ImportKurzuCNB – funkce naimportuje textový soubor do tabulky tblKurzListekCNB

3.7 Systémové požadavky Nasazení nové aplikace vyžaduje server MS Windows Server 2003 nebo 2008 a

40

Informační systém pro rozhodčí řízení databázový server MS SQL Server 2005. Na pracovních stanicích je vyžadován operační systém Microsoft Windows XP nebo Vista. Bližší popis použitých verzí je uveden v kapitole 4.1, která pojednává o použitých technologiích.

3.7.1 Server (hardware) Servery, které budou zajišťovat provoz této aplikace a dalších síťových služeb, musí být umístěny v uzamykatelné a klimatizované místnosti, kam mají přístup jen oprávněné osoby. Server musí být dostatečně výkonný s rezervou pro budoucí rozšiřování. Jak u primárního řadiče domény, tak i u dalších serverů je vyžadována vysoká míra dostupnosti a spolehlivost a dostupnosti. Server musí být napájen z nepřetržitého zdroje elektrické energie UPS. Nutností je možnost zapojení disků minimálně do pole RAID 1 (zrcadlení) a dále je vyžadována záruka s odstraněním závady u zákazníka nejpozději následující pracovní den. Jako server by použit server IBM Express x3650 v konfiguraci uvedené v tabulce . Tento server umožňuje do budoucna přidání druhého procesoru, rozšíření paměti až do 48 GB a v provedení výšky 2U poskytuje i dostatečný počet volných pozic pro rozšíření diskové kapacity serveru. Technická specifikace serveru je v tabulce č. 2.

Procesor Pevný disk Paměť LAN Video Optická mechanika Napájení Hmotnost Typ skříně

1x Intel Xeon Quad Core E5410, 2330 MHz s možností osazení druhým procesorem 2x SAS Hot Swap Maximální kapacita úložiště 1 168 GB 4 GB ECC PC2-5300 DDR2 SDRAM 12 paměťových slotů 2x RJ-45 Gigabit Ethernet ATI RN50 16MB CD-RW/DVD-ROM Combo 835 W 29,6 kg Rack mount 2U

Tabulka 2. Technická specifikace serveru

41


3.7.2 Serverový software Počítačová síť se sestává z několika serverů, které zajišťují síťové služby. Jako hlavní server slouží primární řadič domény, dále je zde server pro terminálový přístup a zároveň jako záložní řadič domény. jako databázový server je vyčleněn samostatný server. Dále se v síti nachází poštovní server, který je v demilitarizované zóně. Schéma uspořádání sítě je znázorněno na obrázku č. 19.

Obrázek 19. Schéma uspořádání sítě V tabulce č. 3 je uveden přehled instalovaného software, který je nainstalován na jednotlivých serverech.

42


Popis serveru Hlavní server (primární řadič domény) SQL server Poštovní server Web server pro předsednictvo

Web server spory on-line

Operační systém MS Windows 2003 Server Standard CZ MS Windows 2003 Server Standard CZ MS SQL Server 2005 Open SuSE 11.1 Kerio Mail Server 6.6.2 Open SuSE 10.5 Apache 2.2.4 PHP 5.2.5 MS Windows 2003 Server Web Edition

Tabulka 3. Přehled instalovaného software

3.7.3 Pracovní stanice Na hardwarové vybavení pracovních stanic nejsou kladeny žádné nestandardní požadavky a pro práci vyhovuje standardní kancelářské PC. Jako operační systém je doporučen Windows XP SP2 a vyšší nebo Windows Vista Business. Pro vytváření dokumentů je třeba nainstalovat Microsoft Word 2003, doporučen je balík MS Office 2003. Minimální doporučená minimální konfigurace pracovní stanice je uvedena v tabulce č. 4.

Procesor:

Intel Pentium 4, 2GHz

RAM:

1 GB, pro MS Vista 2 GB

Hardisk:

80 GB

Grafická karta

postačí integrovaná, min. 32 MB

Obrazovka:

LCD 19“ s rozlišením min. 1024 x 768

Tabulka 4. Minimální doporučená konfigurace pracovní stanice

43


4 Realizace řešení 4.1 Použité technologie 4.1.1 Visual Studio .NET 2008 Microsoft Visual Studio je integrované vývojové prostředí, které umožňuje vytvářet aplikace s grafickým uživatelským rozhraním, konzolové aplikace, webové aplikace, služby a další. Ve Visual Studiu 2008 Professional je možné programovat v programovacích jazycích Visual Basic, Visual C# a Visual C++. Pro vývojáře je k dispozici několik edic Visual Studia, jejichž přehled je v tabulce č. 5.

Produktová řada

Určeno pro

Charakteristika

Visual Studio Začátečníky, studenty, Express na vyzkoušení

Jednotlivě oddělené produktové řady zaměřené na výuku jazyků C++, C# a Visual Basic případně web technologií.

Příležitostné Visual Studio programátory a Standard neprofesionály

Jednotné, komplexní prostředí pro tvorbu webových i desktopových aplikací.

Visual Studio Profesionály pracující Professional jednotlivě - samostatně

Profesionální nástroj pro tvorbu mobilních, webových desktopových a víceúrovňových aplikací s integrovanou podporou vývoje pro MS Office.

Všechny vývojáře, architekty, testery, Visual Studio projektové manažery a Team System ostatní, zejména ty, kteří pracují ve skupině

Komplexní balík toho nejlepšího co lze nabídnout pro opravdové vývojáře a celé vývojové týmy včetně týmové infrastruktury.

Zdroj: Microsoft [online].[cit. 10.4.2009] Dostupný z www: Tabulka 5. Přehled verzí Visual Studia 2008 a jejich určení Jednotlivé edice se liší kromě ceny množstvím poskytovaných nástrojů, zejména pro 44

Informační systém pro rozhodčí řízení práci s databází, dále je od verze Professional k dispozici Crystal Report pro tvorbu sestav. Popisovaná aplikace byla vyvíjena ve Visual Studiu 2008 Professional. Podrobný popis jednotlivých verzí včetně podrobného přehledu vlastností, cen a způsobu

licencování

je

uveden

na

webu

firmy

Microsoft

na

adrese

http://www.microsoft.com/cze/msdn/produkty/vstudio/porovnani.mspx.

4.1.2 Microsoft .NET Framework Ústředím pracovního prostředí .NET Framework je jeho operační prostředí označované jako modul CLR (Common Language Runtime) nebo taky operační prostředí .NET. Kód spuštěný pod kontrolou operačního prostředí .NET se často označuje pojmem spravovaný kód (managed code). Předtím, než se kód v prostředí .NET (CLR) spustí, je třeba kód napsaný v nějakém podporovaném jazyce přeložit. Překlad (kompilace) programů v .NET má dva stupně. 1. Nejprve se kód přeloží do jazyka MSIL (Microsoft Intermediate Language). 2. Následně se kód MSIL přeloží modulem CLR na kód specifický pro danou platformu. Mezi výhody spravovaného kódu patří nezávislost na platformě, vylepšení výkonu a hlavně interoperabilita jazyků, takže je možný „stejný“ kód vytvářet v několika jazycích. Schéma prostředí .NET Frameworku je zobrazeno na obrázku č. 20.

45


Zdroj: Portál Programujte.[cit. 10.4.2009] Dostupný z www: http://programujte.com/?akce=clanek&cl=2008120700--net-framework Obrázek 20. Schéma prostředí .NET Framework První verze .NET Frameworku označovaná 1.0 se objevila v roce 2002 ve vývojovém prostředí Visual Studia .NET a s ním byl uveden i jazyk C# 1.0. Následovaly další verze 1.1. - rok 2003, Visual Studio 2003, verze 2.0 – rok 2005, Visual Studio 2005 a nová verze C# 2.0, verze 3.0 – rok 2007, Visual Studio 2005 nebo 2008 a poslední verzí je 3.5 z roku 2007, kterou podporuje Visual Studio 2008 a obsahuje i novou verzi jazyka C# 3.0.

4.1.3 ADO.NET ADO.NET je součást nového .NET Frameworku společnosti Microsoft k přístupu k datům. Přístup k datům se zcela liší od předchozí technologie ADO. Technologie ADO.NET poskytuje čtyři jmenné prostory pro klientské databáze a to .NET Framework Data Provider for SQL Server, .NET Framework Data Provider for OLE DB, .NET Framework Data Provider for ODBC a.NET Framework Data Provider for Oracle

46


4.1.4 Jazyk C# Programovací jazyk C# je poměrně nový objektově orientovaný jazyk určený k programování v prostředí .NET. Na první pohled je podobný jazyku C++ nebo Javě. Pominu-li tuto podobnost, je jazyk C# mnohem jednodušší než C++ a mezi programátory si získává stále větší oblibu. Zpočátku jsem měl v úmyslu psát aplikaci ve Visual Basicu. K tomuto rozhodnutí mě vedl fakt, že mám větší znalosti Visual Basic for Application, ve kterém jsem vyvíjel předchozí verzi Evidence sporů. Důvodem byla domněnka, že vývoj bude rychlejší, jelikož se budou moci jednodušeji přepisovat mnohé funkce a procedury z předchozí aplikace. Nakonec se ukázalo, že kromě syntaxe se jedná u Visual Basicu .NET o úplně jiný způsob programování. Proto jsem usoudil, že časová úspora bude ve vývoji aplikace minimální provedl jsem porovnání výhod a nevýhod mezi Visual Basicem a Visual C#. V tabulkách 6 a 7 jsem shrnul výhody a nevýhody obou jazyků a následně jsem se rozhodl vyvíjet aplikaci ve Visual Studiu C#. Uvedené výhody a nevýhody jsou mým pohledem na danou věc, takže se jedná o subjektivní posouzení. Dále jsem čerpal informace

při

rozhodování

z

diskusních

fór

na

Internetu

(http://forum.builder.cz/read.php?31,2678064, březen 2009) a konzultací se známými vývojáři. Visual C# Výhody - přehlednější syntaxe díky uzavírání bloků do složených závorek a ukončování píkazů středníkem - více dostupné literatury - více dostupných ukázkových řešení na Internetu - na složitost učení není těžší než VB - z diskuzí mám dojem, že Microsoft do budoucna sází více na C# a VB udržuje jen kvůli zatím stále početné skupině programátorů ve VB .NET i VB6

Nevýhody - menší znalosti a zkušenosti oproti VB, v C# vytvořeny jen menší projekty za účelem poznávání C# - méně flexibilní příkaz switch - absence příkazu with

Tabulka 6. Výhody a nevýhody Visual C#

47

Informační systém pro rozhodčí řízení Visual Basic .NET Výhody - podobná syntaxe jako u VB6 nebo VBA - více funkcí pro práci s řetězci - flexibilnější příkaz select case

Nevýhody - příliš velký rozdíl mezi Visual Basic a Visual Basic .NET (prakticky se VB .NET dá považovat za zcela nový jazyk) - méně dostupné literatury a příkladů na Interneu - hůře čitelný kód (příkazy nejsou ukončeny středníkem) - standardní datové typy tohoto jazyka nejsou plně kompatibilní s .NET Framework - neumožňuje implementaci dědičnosti

Tabulka 7. Výhody a nevýhody Visual Basic .NET

4.1.5 Microsoft SQL Server 2005 Jako databázový stroj pro aplikaci byl zvolen Microsoft SQL Server 2005 Standard. Firma Microsoft nabízí několik variant licencí tohoto produktu a dále je MS SQL server rozdělen do edicí Express, Workgroup, Standard a Enterprise. Stručný přehled jednotlivých edicí je uveden v tabulce č. 8. Po důkladné analýze bylo rozhodnuto pro nákup edice Standard a licence vztahující se na procesor, která je sice jedna z nejdražších, ale za předpokladu, že se bude SQL server používat v budoucnu i pro webovou aplikaci, tak to bylo optimální řešení licencování, jelikož u webové aplikace je těžko měřitelný počet přistupujících jedinečných uživatelů (licence per user). Druhá možnost licencování na koncová zařízení (per device) je pro webové aplikace zcela nevhodná. MS SQL 2005 byl zvolen jednak s ohledem na zadání ze strany Rozhodčího soudu a také proto, že se jedná v dnešní době již o poměrně vyspělý a rozšířený databázový stroj. Při výběru databázového stroje se zvažovala i možnost použití databáze FireBird či MySQL, ale nakonec bylo rozhodnuto ve prospěch MS SQL 2005 z důvodu provozování aplikace PCinfo MagicEYE na správu softwarových licencí a budoucího nasazení aplikace ELO Office pro Document Management System. Obě tyto aplikace

48

Informační systém pro rozhodčí řízení používají jako databázi MS SQL Server od verze 2000.

Škálovatelnost a výkon Funkce Express Workgroup Standard Enterprise Poznámky Počet CPU 1 2 4 bez limitu Obsahuje podporu vícejádrových (multicore) procesorů RAM 1 GB 3 GB bez bez limitu limitu 64-bit Windows WOW podpora on Windows (WOW) Velikost 4 GB bez limitu bez bez limitu databáze limitu Partitioning Popdpora pro rozsáhlé databáze Indexované Vytváření indexovaných pohledů pohledy je podporováno ve všech edicích, pouze edice Enterprise podporuje vytváření pomocí Query procesoru. Parallel Paralelní zpracování Index indexovacích operací Operations Zdroj: Microsoft. [cit. 11.4.2009] Dostupný z www: Tabulka 8. Porovnání edicí MS SQL Server 2005

4.1.6 Microsoft Windows Server Počítačová síť Rozhodčího soudu byla postavena na architektuře serverového operačního systému Microsoft Windows Small Business Server 2003 Premium (dále jen SBS). SBS integruje samotný operační systém MS Windows 2003 Server, MS SQL Server 2000, MS Exchange 2003 a MS ISA server. Tento balík serverových aplikací je za podstatně nižší cenu, než kdyby se kupovaly jednotlivé serverové produkty samostatně. Má to ovšem jistá omezení a odlišný způsob licencování, než u klasických serverových produktů. Licencování je na počet uživatelů, dá se přikupovat po pěti klientských licencích, maximálně však do počtu 75. Další podmínkou je, že všechny serverové aplikace musí být instalovány na jednom fyzickém hardwaru. Toto omezení

49

Informační systém pro rozhodčí řízení se stalo klíčovým pro rozhodnutí o nahrazení SBS. SBS byl nahrazen MS Windows 2003 Server Standard 32-bit verzí. Z hlediska uživatele se tedy nezměnilo vůbec nic, správa serveru je téměř stejná jako správa SBS, ale po změně je možné síť více rozšiřovat. Co se týče přístupových klientských licencí, tak byly zvoleny licence typu per device, což znamená, že licence jsou zakoupeny pro každý počítač v síti bez ohledu na to, kolik na něm pracuje uživatelů. Dále je možné s touto licencí přistupovat na více serverů MS Windows Server. Ještě bych zmínil důvody, které mě vedly k volbě Microsoft Windows 2003 Server, přestože v dané době byl na trhu již nový Microsoft Windows Server 2008. Původně jsem chtěl použít nejnovější dostupnou technologii vzhledem k tomu, že se plánoval i přechod na poštovní server MS Exchange 2007 Server, který je k dispozici jen v 64-bitové verzi. Po důkladné technické a finanční analýze byl nejprve zavržen MS Exchange 2007 Server, jelikož implementace a správa je podstatně složitější než u jiných poštovních serverů a hlavně byla příliš vysoká cena v přepočtu na jednoho uživatele. MS Exchange 2007 Server byl nakonec nahrazen Kerio Mail Serverem 6.2, který byl pro daný počet uživatelů za třetinovou cenu, běží na linuxovém serveru a co se týče správy a kompatibility s poštovními klienty včetně mobilních zařízení, tak v mnoha ohledech MS Exchange předčí. Dalším důvodem, proč setrvat u prověřené technologie Microsoft Windows 2003 Server ve 32-bitové verzi byla analýza kompatibility všech programů běžících na serveru. V 64-bitové nebyl dostupný program komunikující s telefonní ústřednou, což by se dalo obejít, ale největším argumentem bylo nedoporučení Windows 2008 Server a použití 32-bitové verze od firmy dodávající software Elo Office, s jehož implementací se v budoucnu počítá. Pro úplnost dodávám, že u serverových licencí byly zakoupeny Software Assurance (SA), což umožňuje přejít kdykoliv v průběhu platnosti SA na aktuální verzi serverové aplikace. Platnost SA je dva roky a po této době se musí znovu zakoupit.

50


4.2 Databáze 4.2.1 Struktura databáze Názvy tabulek jsou tvořeny prefixem tbl nebo ptbl a názvem tabulky, který vystihuje obsah tabulky. Pomocné tabulky (ptbl) jsou určeny pro ukládání pomocných dat, jako jsou chyby nebo nastavení aplikace. Prefixem ptbl je tak dosaženo oddělení těchto tabulek při práci s databázovými nástroji. V příloze č. 2 jsou uvedeny stručné popisy jednotlivých tabulek databáze. V levém sloupci je pod názvem tabulky je uveden primární klíč (PK) a případně cizí klíče (FK). Relační schéma databáze je zobrazeno v příloze č. 1.

4.2.2 Normalizace databáze V teorii databází je celkem šest normálních forem databáze. V běžné praxi se zpravidla normalizuje pouze do třetí normální formy. Zda striktně normalizovat, nebo v odůvodněných případech i denormalizovat databázi je věčné téma, které nemá jednoznačný závěr a názory se různí. Já osobně nejsem zastánce normalizace za každou cenu a databáze informačního systému byla normalizována do třetí normální formy s níže uvedenými a odůvodněnými výjimkami. Níže je uveden popis normálních forem s příkladem z použité databáze. První normální forma (1NF) První normální forma znamená, že každý atribut v tabulce je atomický, t.j.dále nedělitelný. V tabulce 9 je příklad tabulky, která není v 1NF a obsahuje 2 pole Jmeno a Adresa. V tabulce 10 je předchozí tabulka převedena do 1NF a jednotlivá pole jsou atomická. Takto je to striktně dle definice, já jsem u tabulky tblAdresy sloučil do pole Ulice i popisné číslo pro zjednodušení zadávání adres. První normální forma v databázi informačního systému není stoprocentně splněna z dále uvedeného důvodu. Jednak jak již bylo řečeno, v tblAdresy se používá ulice včetně čísla popisného a orientačního v jednom poli, ale co nesplňuje 1NF je problém v tabulce tblAdresy, kde se z historických důvodů kvůli kompatibilitě s jinými programy se

51

Informační systém pro rozhodčí řízení neprovedla atomizace polí jméno (toto pole obsahuje celé jméno včetně titulů) na titul, jméno, příjmení a titul za jménem. Dnes je zjevné, že ponechání této „kompatibility“ zadělalo na problém, jehož problém je s odstupem času a nárůstu počtu dat v databázi komplikovanější. Chtěl jsem to řešit již v průběhu vývoje nové aplikace, ale vzhledem k zachování kompatibility se starou aplikací bude problém řešen až následně po zavedení nové aplikace.

Jmeno

Adresa

Josef Novák

Dlouhá 13, 110 00 Praha 1

Tabulka 9. Tabulka v NFNF – non first normal form

AdresaID

Jmeno

Prijmeni

Ulice

CP

PSC

Mesto

1

Josef

Novák

Dlouhá

13

110 00

Praha 1

Tabulka 10. Tabulka 8 převedená do 1.NF

Druhá normální forma (2NF) Druhá normální forma (2NF) znamená že tabulka je v 1NF a navíc platí, že každý neklíčový atribut je plně závislý na primárním klíči, a to na celém klíči a nejen na nějaké jeho podmnožině. V databázi informačního systému bylo při návrhu počítáno s tím, aby se nevyskytovaly neklíčové atributy. Příkladem 2NF jsou například tabulky tblZalujiciStrany a tblZalovaneStrany. Příklad převedení tabulky do 2NF je uveden v tabulkách 11 - 14. Pro lepší přehlednost uvádím názvy žalujících a žalovaných stran, jinak by bylo v poli jen ID žalující nebo žalované strany.

52


SporID 1111 1111 1112 1112

Rsp 1/09 1/09 2/09 2/09

HodnotaSporu 100 Kč 100 Kč 200 Kč 200 Kč

ZalujiciStrana Firma 1 Firma 1 Firma 4 Firma 3

ZalovanaStrana Firma 2 Firma 3 Firma 1 Firma 1

Tabulka 11. Příklad tabulky sporů před úpravou do 2NF

PKID 1 2 3

SporID 1111 1112 1112

AdresaID 11 14 13

Tabulka 12. Pomocná tabulka tblZalujiciStrany

PKID 1 2 3

SporID 1111 1111 1112

AdresaID 12 13 11

Tabulka 13 Pomocná tabulka tblZalovaneStrany

AdresaID 11 12 13 14

Firma Firma 1 Firma 2 Firma 3 Firma 4

Ulice Ulice 84 Ulice 54 Ulice 45 Ulice 548

CP 111 254 54 874

PSC 123 45 567 89 789 01 987 65

Mesto Město 1 Město 2 Město 3 Město 4

Tabulka 14 Tabulka tblAdresy

Třetí normální forma (3NF) Třetí normální forma (3NF) znamená, že neklíčová data jsou závislá jen na klíči a ne mezi sebou a tabulka splňuje 1NF a 2NF. Zde je opět diskuze, zda-li je praktické se striktně držet 3NF. Pokud by se striktně měla 53

Informační systém pro rozhodčí řízení normalizovat do 3NF tabulka tblAdresy, tak např. pole PSČ a město by muselo mít svoji vlastní tabulku s PSČ a městy. V tomto případě jsem se rozhodl nepřevádět tabulku tblAdresy do 3NF. Další normální formy Boyce-Coddova normální forma je v podstatě považuje jen za jistou variantu třetí normální formy. Čtvrtá normální forma se zabývá otázkami závislosti na více hodnotách. Pátá normální forma se zabývá bezztrátové a ztrátové dekompozice, což znamená, když dekomponujeme relaci, tak ji dokážeme spojit zpět do původní podoby.

4.2.3 Zálohování databáze Zálohování dat je v dnešní době již samozřejmostí a přestože se spolehlivost hardwaru neustále zvyšuje a na serveru je použita technologie RAID 1 (zrcadlení disků), která do jisté míry eliminuje selhání jednoho z pevných disků s daty, tak i přes tato opatření je nezbytné zálohovat data na jiné médium a mít záložní kopii i mimo budovu sídla organizace pro případ živelní pohromy, krádeže serveru jako celku nebo i pro neúmyslné či úmyslné smazání dat. Pro zálohování dat byla zvolena strategie zálohování na externí diskové pole a jednou měsíčně je záloha zkopírována na externí harddisk, který je mimo budovou organizace. Donedávna byly používány pásky, které již přestaly vyhovovat a byly nahrazeny přenosným diskem, který má daleko vyšší rychlost, spolehlivost a také kapacitu. Jako zálohovací software je použit Acronis True Image Echo Server, který zálohuje celý image disku nebo jednotlivé zvolené složky. V případě selhání hardware je tedy možné obnovit celý svazek disku bez nutnosti instalace operačního systému a zdlouhavého nastavování a odlaďování všech parametrů, které v případě havárie zdrží obnovení systému až o několik pracovních dnů. Dále je možné dokoupit produkt Acronis Universal Restore, který dokáže přenést konfiguraci serveru na nový hardware, což ušetří spoustu času a finančních prostředků.

54

Informační systém pro rozhodčí řízení V tabulce č. 15 je přehled zálohování dat. Používá se kombinace plné zálohy a přírůstkové zálohy, což v případě selhání znamená obnovu dat z poslední plné zálohy (celý image disku) a poslední přírůstkové zálohy. Po každé záloze je odesílán e-mailem log soubor administrátorovi, který v případě chyby zjedná nápravu.

Interval

Typ zálohy

Každý den ve 23.00 hod.

Přírůstková záloha celého disk (cca 2 GB)

1x týdně v sobotu v 2.00 hod.

Plná záloha všech svazků pevných disků (cca 40 GB)

1x měsíčně

Kopie poslední plné zálohy na externí pevný disk a uložení této zálohy mimo sídlo organizace

Tabulka 15. Přehled zálohování dat

4.3 Uživatelské rozhraní Visual Studio .NET umožňuje použití daleko většího množství ovládacích prvků, čímž by se nabízela možnost zcela přepracovat uživatelské formuláře. Vzhledem k požadavku, aby bylo uživatelské prostředí co nejvíce podobné předchozí aplikaci, jsem se snažil o zachování vzhledu. Hlavní formulář frmSpory zůstal téměř beze změny a tento formulář se zobrazuje jako první formulář po přihlášení do aplikace a obsahuje klasické menu a pod ním je umístěn pruh nástrojů pro spouštění nejvíce používaných modulů. V předchozí aplikaci bylo toto menu v hlavním okně a bylo tedy dostupné ze všech otevřených oken a muselo být ošetřeno, zda-li jsou volby menu dostupné dle stavu aplikace. Nyní se všechny další formuláře otevírají z hlavního formuláře frmSpory a obsahují pouze tlačítka pro zavírání, případně jiná funkční tlačítka. Tím je zabráněno nechtěnému spuštění příkazu v menu, když je uživatel v jiném formuláři. Každé uživatelské okno má umístěny

55

Informační systém pro rozhodčí řízení vpravo ovládací tlačítka (OK, Strono, Změny atd.) Na obrázku č. 21 je zobrazeno základní uživatelské rozhraní aplikace.

Obrázek 21. Ukázka uživatelského rozhraní aplikace

4.4 Vnitřní uspořádání aplikace 4.4.1 Obecný popis V aplikaci bylo použito řešení nevázané na data. Toto řešení je sice v některých částech komplikovanější a je třeba napsat více programového kódu, ale vývojář má větší kontrolu nad aplikací a hlavně je téměř bezproblémový přechod na jiný databázový server, což bylo jedním z hlavních důvodů zvolení tohoto řešení. Dalším neméně podstatným důvodem bylo to, že toto řešení bylo použit v předchozí aplikaci a přestože se nedaly funkce prostě překopírovat, tak principy a algoritmy zůstaly s drobnými úpravami zachovány. Nástroje Visual Studia .NET 2008 umožňují sice rychlejší práci a vývoj aplikace s napojením na data, ale zvolené řešení bylo léty osvědčené a byl požadován co nejrychlejší přechod na verzi v .NET. Aplikace se bude samozřejmě dále rozvíjet a je pravděpodobné, že mnohé funkce a způsoby ovládání aplikace bude 56

Informační systém pro rozhodčí řízení přepracováno.

4.4.2 Režimy prohlížení a editace V požadavcích na aplikaci je v hlavních formulářích požadavek na oddělení režimu prohlížení dat a režimu editace dat. Toto řeší dvě funkce pro přepínání formuláře mezi režimem prohlížení a režimem editace. Funkce JmenoFormulareFromEdit() přepíná formulář

do

režimu

prohlížení.

Funkce

zavolá

funkci

FormFromEdit()

z ClassObecneFunkce, která projde rekurzivně všechny prvky formuláře a dle přípony ovládacího prvků skryje ovládací prvky, které jsou zobrazeny pouze při editaci (_EV), zobrazí prvky skryté při editaci (_EU) a editační pole přepne do režimu pro čtení (_ED). Funkce

dále

nastaví

booleovský

příznak

režimu

editace

formuláře

bolFrm_NazevFormulere_Edit na hodnotu false. Funkce FormFromEdit() je uvedena v příloze č. 3. Funkce JmenoFormulareToEdit() naopak přepíná formulář z režimu prohlížení do režimu editace. Stejně jako funkce JmenoFormulareFromEdit() zavolá FormToEdit() z ClassObecneFunkce a projde rekurzivně všechny prvky formuláře a dle přípony ovládacích prvků zobrazí prvky viditelné při editaci (_EV), skryje prvky neviditelné při editaci (_EU) a povolí změnu editačních ovládacích prvků (_ED). Funkce dále nastaví booleovský příznak režimu editace formuláře bolFrm_NazevFormulare_Edit na hodnotu true, případně při vkládání nového záznamu se nastavuje příznak bolFrm_NazevFormulare_Add na true.

4.4.3 Načítání dat do formuláře a ukládání dat do databáze Zobrazení dat ve formuláři je provedeno pomocí funkce Nazev_Formulare_FromDB(). Tato funkce sestaví SQL dotaz, kde je v podmínce WHERE ID požadovaného záznamu. Dále se vytvoří spojení a vytvoří se objekt Reader, který obsahuje pouze jeden záznam. Funkce ToForm() přečte všechna požadovaná data a zobrazí je ve formuláři. Narozdíl do funkcí FromEdit() a ToEdit(), které jsou univerzální a paramatrem je formulář, který se přepíná z nebo do editace, jsou funkce ToForm() a FromForm() vytvořeny pro každý formulář, jelikož zde nelze prvky procházet a naplňovat daty automaticky. Naopak 57

Informační systém pro rozhodčí řízení každý formulář je specifický a může obsahovat nestandardní prvky, které je třeba ošetřit. Ukládání dat z formuláře do databáze zajišťuje funkce FromEdit(), která sestaví SQL UPDATE, nebo INSERT při vkládání, a uloží data do databáze. Funkce je volána zpravidla po stisku tlačítka btnOK_EU a funkce jsou volány v následujícím pořadí.

4.4.4 Validace dat před uložením Funkce CheckData() zkontroluje data v polích, která musí být vyplněna, nebo musí splňovat nějakou podmínku, zda-li jsou data validní. Pokud tomu tak není, tak se u špatně vyplněných polí zobrazí symbol ErrrorProvider (červený vykřičník), který je doplněn o popis, proč pole neprošlo validací. Funkce CheckData() je typu string a vrací OK nebo Error v případě výskytu alespoň jedné chyby.

Obrázek 22. Ukázka upozornění na chybu s jejím popisem po kontrole dat Pokud

jsou

data

vyplněna

korektně,

tak

je

následně

volána

funkce

NazevFormulareToDB() a pokud nedojde k nějaké chybě, tak je možné formulář přepnout z režimu editace do režimu prohlížení. Pokud byl přidáván nový záznam, tak je ještě proveden přepočet počtu záznamů a pokud formulář používá navigační seznam, tak se provede jeho znovunačtení a přechod na právě vložený záznam.

4.4.5 Ošetření chybových událostí K ošetření chybových událostí se používá standardních bloků Try, Catch a Finally. Přičemž v bloku Catch, kde se ošetřuje chybová událost, se nejprve ošetří možné předpokládané chybové stavy a pokud se vyskytne neočekávaná chyba, tak je zobrazeno chybové hlášení a zároveň je volána funkce LogError, která zapíše do tabulky ptblErrorLog údaje číslo chyby, popis chyby, datum a čas chybové události, jméno

58

Informační systém pro rozhodčí řízení funkce, ve které došlo k vyvolání chybové události a jméno uživatele, který v době chybové události pracoval s programem. Z tabulky ptblErrorLog pak správce nebo vývojář čerpá informace při odstraňování problému, jelikož uživatel většinou nahlásí, že v aplikaci byla „nějaká“ chyba a „něco“ mu to psalo na obrazovku.

4.4.6 Globální funkce a proměnné V aplikaci je použito mnoho funkcí, které se využívají ve více modulech a dále se používají globální proměnné, u kterých je třeba zajistit přístup ze všech modulů aplikace. Globálně používané proměnné jsou uloženy v ClassGlobalniPromenne. Jako příklad globální proměnné uvedu např. lngSporID, která se nastavuje v hlavním formuláři frmSpory a pracuje se sní téměř ve všech modulech. Co se týče globálních funkcí, ke kterým se přistupuje z více modulů a nevztahují se ke konkrétnímu modulu, tak ty jsou uloženy ClassObecneFunkce. Dále se vyskytují globální funkce vztahující se k jednotlivým modulům, ale jsou volány z více míst. Pro přehlednější uspořádání aplikace jsou tyto globální funkce nebo globální proměnné uloženy v class, ketré jsou pojmenovány tak, aby vystihovaly svým názvem logickou návaznost k modulu. Např. ClassAdresy, ClassDokumenty apod. Přehled vlastních tříd používaných v aplikaci: Adresa – pro vytvoření objektu s informacemi o vybrané adrese PrihlasenyUzivatel - pro vytvoření objektu s informacemi o přihlášeném uživateli SablonaDokumentu - pro vytvoření objektu s informacemi o šabloně Spor - pro vytvoření objektu s informacemi o sporu

4.5 Zabezpečení aplikace 4.5.1 Přihlašování uživatelů Použité technologie MS Windows, Visual .NET a MS SQL Server umožňují dva možné způsoby autentizace uživatele. První způsob je integrované přihlašování, kdy se uživatel přihlásí pouze jednou do Windows a do Evidence sporů se již logovat nemusí. Druhý 59

Informační systém pro rozhodčí řízení způsob je přihlašování se do aplikace bez ohledu na to, zda-li je již do Windows přihlášen. Každý z výše uvedených způsobů přihlašování má své výhody i nevýhody. Rozhodl jsem se použít druhý způsob přihlašování z následujících níže uvedených důvodů, i když se první způsob (integrované přihlášení přes Windows) zdá na první pohled výhodnější. v aplikaci jsou požity procesy pro zjišťování oprávnění přístupu uživatele k objektu na základě práv definovaných v tblPrava a tento způsob byl z větší části převzat z původní aplikace v zasedacích místnostech se používá jednotné přihlášení pro zapisovatelku a z bezpečnostních důvodů jsou na těchto počítačích omezena přístupová práva k síťovým prostředkům a do Evidence sporů se již hlásí uživatel pod svým jménem Přestože jsem se rozhodl nepoužít integrované zabezpečení NT, tak i tak jsou nastaveny k tabulkám a dalším objektům SQL databáze práva pro skupiny NT z důvodu snadného přechodu na integrované zabezpečení v případě budoucího požadavku. Dále se při provádění SQL dotazů v kódu aplikace používá connection string, který obsahuje jméno přihlášeného uživatele. Zvážit možnost použití integrovaného přihlášení při posílání connection stringu na server a ošetření přístupu v aplikaci na základě přihlášeného uživatele.

4.5.2 Zabezpečení dat Data uložená na MS SQL serveru jsou zabezpečena mnohonásobně lépe, než u původní aplikace s daty uloženými v souboru MS Access. V tomto případě i když byl soubor s daty skrytý si ho mohl zkušenější uživatel jednoduše zkopírovat a pomocí nástrojů na odstranění hesla měl přístup ke všem datům. MS SQL databázi nelze již takto jednoduše zkopírovat a zcizit tak firemní data. Ale i MS SQL má svá bezpečnostní rizika, se kterými je třeba počítat. Jednak porty TCP 1433 a UDP 1434, na kterých MS SQL běží, jsou z vnější sítě blokovány firewallem. Administrátorský účet SA má nastaven silné heslo, které je neprolomitelné pomocí nástrojů pro hádání hesel nebo útok slovníkovou metodou.

60


4.6 Práce s daty S ohledem na požadavek odladění aplikace souběžně s fungováním předchozí aplikace a následně co nejjednodušší přechod na databázový stroj MS SQL bylo zvoleno trochu netypické řešení, které používá ovládací prvky nevázané na data, ale používá se pouze DataReader, u kterého se implementace neliší v závislosti na použitém zdroji dat. Při vývoji aplikace ve fázi používání dat MS Access jsem dal přednost připojeni ODBC před OleDB. Sice bylo nutné na každé stanici, kde probíhalo testování nastavit ODBC připojení v ovládacích panelech, ale bylo možné nadefinovat použití souboru pro zabezpečení (např. system.mdw). V případě použití OleDB toto možné nebylo a muselo by se podstoupit bezpečnostní riziko a odstranit ochranu databáze. Přestože v dnešní době ochrana databáze na úrovni uživatelských práv je nedostačující, tak i přesto jsem nechtěl , byť by to bylo po přechodnou dobu, snižovat úroveň zabezpečení staré aplikace. Pro připojení k MS Access datům bylo použito rozhraní ODBC. Příklad connection stringu a následného přístupu k datům vypadá následovně: using System.Data.Odbc; string cnStr = @"Data Source=PC2\SQLEXPRESS;Initial string strSQL = "SELECT příkaz....."; OdbcConnection dbConnection = new OdbcConnection(cnStr); OdbcCommand selectCommand = new OdbcCommand(strSQL, dbConnection); dbConnection.Open(); OdbcDataReader myDataReader = selectCommand.ExecuteReader(); while (myDataReader.Read()) { //zde se pracuje se čtenými daty z myDataReader } myDataReader.Close(); dbConnection.Close();

Pro připojení k MS SQL serveru datům bylo použito třídy SqlClient obsažené ve Visual Studiu. Příklad connection stringu a následného přístupu k datům vypadá následovně:

61

Informační systém pro rozhodčí řízení using System.Data.SqlClient; string cnStr = @"Data Source=PC2\SQLEXPRESS;Initial Catalog=DataSQL;Integrated Security=True"; string strSQL = "SELECT příkaz....."; SqlConnection dbConnection = new SqlConnection(cnStr); dbConnection.Open(); SqlCommand selectCommand = new SqlCommand(strSQL, dbConnection); SqlDataReader myDataReader = selectCommand.ExecuteReader(); while (myDataReader.Read()) { //zde se pracuje se čtenými daty z myDataReader } myDataReader.Close(); dbConnection.Close();

Z výše uvedených příkladů je zřejmé, že přechod na jiný zdroj dat není složitý a nemusí se přepisovat část kódu, kde se pracuje s daty.

4.6.1 Konvence pro názvy ovládacích prvků a proměnných Aby byla aplikace přehledná a pro jiné programátory dobře čitelná, používá se následujících standardů pro pojmenovávání ovládacích prvků. Jméno každého ovládacího prvku, tabulky, formuláře atd. začíná předponou, která vyjadřuje typ objektu a je to z důvodu přehlednosti kódu. Výjimku tvoří ovládací prvky, které se nevyskytují často, nebo jsou na formuláři umístěny zpravidla jen jedenkrát, jako je například TabControl nebo ErrorProvider. u těchto prvků je ponecháno implicitní pojmenování, případně je doplněno číslicí (TabControl1). Přehled konvencí pro pojmenování ovládacích prvků je uveden v tabulce č. 16.

62


Objekt Tabulka Formulář Třída Popisek (Label) Editační bole (TextBox) Seznam (ListView) Kombin. seznam (ComboBox) Tlačítko (Button) Zaškrt. pole (CheckBx) Přepínací tlačítko (RadioButton) Seskupení (GroupBox)

tblJmenoTabulky frmJmenoFormulare classJmenoTridy lblJmenoPopisku txtJmenoPole lstJmenoSeznamu cmbJmenoKombinPole btnJmenoTlacitka chkJmeno optJmenoTlacitka grpJmenoSeskupeni

Tabulka 16. Přehled konvencí pro pojmenování ovládacích prvků

Dále se u některých ovládacích prvků používá za názvem přípona, která se týká ovládacích prvků, u kterých se automaticky mění některé z vlastností v závislosti na režimu (editace nebo prohlížení). Přípony jsou _ED - editační pole, používá se zejména u textových polí a funkce ToEdit nebo FromEdit u tohoto pole zapíná, respektive vypíná, vlastnost ReadOnly. _EV - pole při editaci viditelné – u těchto polí změní funkce ToEdit vlastnost Visible na True a funkce FromEdit změní vlastnost Visible na False. Používá se jak u editačních polí, tak i u dalších objektů jako jsou například příkazová tlačítka. _EU - pole při editaci skryté – u těchto polí změní funkce ToEdit vlastnost Visible na False a funkce FromEdit změní vlastnost Visible na True. Používá se jak u editačních polí, tak i u dalších objektů jako jsou například příkazová tlačítka. Pokud ovládací prvek nemá příponu, tak hofunkce ToEdit a FromEdit při průchodu všemi prvky ignorují a ponechávají nastavené vlastnosti, pokud není explicitně

63

Informační systém pro rozhodčí řízení stanoveno jinak. Pro názvy proměnných je pro zlepšení přehlednosti kódu zvoleno následující označení proměnných, kde se pře název proměnné vloží zkratka, která určuje typ proměnné. Jména proměnných jsou v kódu psána bez diakritických znamének.

String Long Integer DateTime Array

strJmenoPromenne lngJmenoPromenne intJmenoPromenne datJmenoPromenne arrJmenoPromenne

Tabulka 17. Přehled konvencí pro pojmenování proměnných Výjimku tvoří případy, kde je typ proměnné zcela jednoznačný nebo je označování proměnné zažité, jako je např. použití proměnné typu integer v cyklech, kde se používá jen malé písmeno (i, j, k atd.).

64


5 Implementace řešení V této kapitole jsou v úvodu popsány některé metodiky vývoje softwarových aplikací, jelikož vývoj aplikace neprobíhal striktně dle jedné metodiky, ale byly použity způsoby z jednotlivých metodik, přičemž celkově se způsob vývoje aplikace nejvíce přibližoval agilnímu vývoji software. Dále následuje časový harmonogram vývoje a implementace řešení.

5.1 Metodiky způsobu vývoje aplikace Jak efektivně a jakými metodami vyvíjet software se zabývá vědní obor softwarové inženýrství. Hlavní problém, se kterým se při zkoumání metodik budování IS/ICT setkáváme, spočívá v tom, že metodik je velké množství, nejsou dobře kategorizovány ani jednotným způsobem popsány. Tato skutečnost velmi znesnadňuje vyhledání vhodné metodiky pro určitý typ projektu1. Existence různých metodik je dána těmito skutečnostmi: - různé technologie vyžadují různé techniky a metody - každý jedinec a každý tým je jedinečný - projekty se liší svou důležitostí - projekt existuje v rámci určitého specifického vnějšího prostředí

Níže je popsáno stručně pouze několik základních metodik, jelikož podrobnější popis a rozbor jednotlivých metodik by přesahoval rámec této diplomové práce.

Vodopádový model vývoje aplikace Jedná se o klasický vývoj, který postupuje od specifikace požadavků až po zavedení a údržbu aplikace. 1

BUCHALCEVOVÁ, Alena. Metodiky vývoje a údržby informačních systémů. 1. vyd.

Praha : Grada, 2005. 163 s. Management v informační společnosti. ISBN 80-247-107-7.

65


Obrázek 23. Vodopádový model vývoje aplikace Problémy vodopádového modelu: - předpokládá se, že všechny požadavky se specifikují na začátku projektu - iterace jsou možné jen v rámci jedné fáze a je možné se vrátit zpět maximálně k předchozí fázi - není zpětná vazba od zákazníka, jelikož zákazník není přímo zapojen do týmu vývojářů - pozdní integrace systému, ke které dochází až po naprogramování všech modulů Tento model mně osobně nevyhovuje a rozhodně není vhodný pro projekt popisovaný v této diplomové práci. V praxi se často stává, že zákazník při aplikaci toho modelu dostane produkt, který neodpovídá jeho představám a po implementaci probíhá často k jeho následným úpravám, které jsou řešeny novým projektem a tím se zvyšují celkové náklady. Jako jediná výhoda vodopádového modelu je to, že zákazník dostane „přesnou kalkulaci“ nákladů, ale jak jsem již uvedl, tyto náklady pak nemusí odpovídat celkovým nákladům kvůli následným úpravám. Bohužel u velkých projektů a zejména státních zakázek se tento přístup vyžaduje.

Iterativní model vývoje aplikace Podstatou iterativního vývoje je to, že člověk řeší lépe menší problémy a snahou je

66

Informační systém pro rozhodčí řízení rozložit velký softwarový projekt na řadu menších miniprojektů (iterací). Iterace obsahuje všechny fáze softwarového projektu a výsledkem každé iterace je funkční část systému (release). Tento způsob vývoje byl přiměřeně použit při vývoji aplikace, jelikož po návrhu „kostry“ aplikace probíhaly vývoje jednotlivých modulů po iteracích. Byly zde ovšem výjimky, jelikož některé moduly nemohly být zcela samostatně vyvíjeny, jelikož byly silně provázány s jiným modulem (např. modul pro vytváření dokumentů).

Rigorózní metodiky versus agilní metodiky V současnosti můžeme sledovat dva hlavní proudy v metodických přístupech, které jsou označovány jako rigorózní metodiky a agilní metodiky. Hlavním kritériem, které tyto dva proudy odlišuje je váha metodiky a liší se dalšími hledisky. Rigorózní metodiky vycházejí z přesvědčení, že procesy při budování IS/ICT lze popsat, plánovat, řídit a měřit. Jsou založeny zpravidla na vodopádovém vývoji, ale existují i metodiky založené na iterativním a inkrementálním vývoji. Příkladem těchto metodik jsou Rational Unifed Process (RUP), Enterprise Unified Process (EUP). Agilní metodiky, narozdíl od rigorózních metodik, umožňují vytvářet řešení velmi rychle a pružně se přizpůsobují měnícím se požadavkům. Agilní metodiky vznikaly od druhé poloviny 90. let a prosazují myšlenku, že jedinou cestou, jak prověřit správnost navrženého systému, je vyvinout jej co nejrychleji, předložit zákazníkovi a na základě zpětné vazby jej upravit. Každá z agilních metodik je svým způsobem specifická, ale všechny jsou postaveny na stejných principech a hodnotách. V únoru roku 2001 se sešli představitelé těchto přístupů a podepsali „manifest agilního vývoje software“ a vytvořili „Alianci pro agilní vývoj software“. Hlavní principy agilních metodik dávají přednost: - individualitám a komunikaci před procesy a nástroji - provozuschopnému software před obsažnou dokumentací - spolupráci se zákazníkem před sjednáváním kontraktu - reakci na změnu před plněním plánu

67


Ačkoli by se na první pohled mohlo zdát, že aplikace byla programována klasickou metodou zadání – analýza – návrh řešení – implementace řešení, tak ve skutečnosti způsob vývoje probíhal po iteracích a přestože použitá metoda nebyla striktně vedena dle konkrétní metodiky, tak by ji nejvíce charakterizovaly metodiky agilního programování. Při vývoji aplikace byly použity následující principy, které se slučují převážně s agilními metodikami. Vývoj aplikace probíhal v úzké spolupráci s budoucími uživateli. Pravidelně se pořádaly pracovní schůzky, na kterých bylo zpřesňováno zadání a změny byly ihned implementovány při vývoji aplikace. Vzhledem

k dlouhodobým

osobním

vztahům

byla

absolutně

bezproblémová

komunikace a členové týmu si řekli bez rozpaků i negativní věci, které by při pozdějším řešení způsobily větší komplikace, než za včasného zachycení. Prioritou bylo vyvinout rychle funkční software, nebyl kladen důraz na programovou dokumentaci, která nebyla neexistovala nikdy v životním cyklu předchozí aplikace. Požadavek na dokumentaci se jeví jako zbytečné plýtvání časem i u nové verze, jelikož při budoucím následném vývoji software by bylo opět plýtváno časem při aktualizaci dokumentace. V případě přijetí nového zaměstnance se tento zaměstnanec neseznamuje se softwarem pomocí dokumentace, ale pracuje společně se stávajícím zaměstnancem a je za provozu zaškolen. Testování aplikace probíhalo během vývoje i v průběhu celého životního cyklu.

Popis iterací Při vývoji byla délka iterace přibližně 3 - 5 týdnů. Na začátku vývoje byly iterace poněkud delší, jelikož se vytvářela struktura aplikace a nebylo vhodné v počáteční fázi zatahovat budoucí uživatele do vývoje, jelikož se jednalo o zcela odbornou práci na databázi a „kostře“ budoucí aplikace. V momentě, kdy se začaly programovat a „oživovat“ jednotlivé moduly, tak se délky iterací zkracovaly a mohlo se již konzultovat

68

Informační systém pro rozhodčí řízení s budoucími uživateli nad vyvíjenou aplikací. Iterační způsob vývoje aplikace mi přijde pro tento rozsah aplikace jako nejvhodnější, jelikož jak v minulosti, tak při dalším vývoji aplikace, se vždy na základě potřeb a požadavků uživatele vytvářely nebo upravovaly jednotlivé části aplikace.

5.2 Časový harmonogram vývoje a zavedení aplikace Způsob vývoje aplikace se blížil spíše agilním metodikám vývoje software, takže nebylo snadné přesně stanovit časový harmonogram, jelikož v průběhu vývoje docházelo k dodatečným změnám a upřesnění zadání a vývoj se tomu musel okamžitě přizpůsobit. V tabulce č. 18 jsou uvedeny popisy jednotlivých etap vývoje aplikace tak jak probíhaly od započetí přípravných prací až po nasazení do ostrého provozu. Doba trvání jednotlivých etap je uvedena orientačně a součet trvání všech etap vývoje neodpovídá délce trvání implementace aplikace, jelikož se jednotlivé etapy vývoje zčásti překrývaly a etapa III byla dělána současně během etapy II. Etapa I. Příprava, analýza a návrh řešení II. Realizace návrhu řešení III. Příprava a konfigurace sítě IV. Testování a zkušební provoz

V. Doladění aplikace VI. Zahájení ostrého provozu

Doba trvání 2 měsíce

Popis etapy Analýza požadavků na aplikaci, návrh řešení, sestavení plánu vývoje a implementace software. 8 měsíců Vytvoření aplikace, aktualizace a bližší specifikace návrhu řešení a reakce na nové připomínky k návrhu řešení. 2 měsíce Změny v topologii sítě, instalace a konfigurace dedikovaného SQL serveru, příprava a kontrola pracovních stanic. Průběžně během Testování se provádí již během vývoje realizace, aplikace, uživatelské testování s vybranými uživateli nejprve na testovacích datech a ve uživatelské tetování 2 měsíce finální části již na ostrých datech. 1 měsíc Zapracování připomínek a odladění případných chyb na připomínek před uvedením aplikace do ostrého provozu. 2 týdny Zaškolení uživatelů pro práci s novou aplikací a přechod všech uživatelů na novou aplikaci. Stará aplikace bude odinstalována a data zaarchivována.

Tabulka 18. Etapy vývoje aplikace 69


5.3 Zkušební provoz V první fázi zkušebního provozu byla nová aplikace předvedena dvěma vybraným uživatelům, kteří měli nejvíce zkušeností se starou aplikací a byli u konzultací při vývoji a specifikaci nové aplikace. První seznámení a zaškolení s novou aplikací proběhlo na zkušebních datech, kdy si mohli uživatelé dělat „co chtěli“ a mohli si tak aplikaci osahat. Následně po uplynutí jednoho týdne byla aplikace napojena na ostrá data a uživatelé tak mohli vykonávat běžné pracovní úkony. K dispozici měli i starou aplikaci pro případ, že by některé funkce nefungovaly správně. Během zkušebního provozu byly shromaždovány připomínky a chyby, které byly průběžně vyhodnocovány. Připomínky byly zapracovány a chyby byly odstraněny. Nejčastěji se vyskytovaly připomínky k ovládání aplikace, kdy některé ovládací prvky fungovaly rozdílně než ve staré aplikaci. Nové opravené verze byly instalovány průběžně během zkušebního provozu. Po cca jednom měsíci byla aplikace ve stavu, kdy ji bylo možné instalovat i na ostatní stanice. Bylo provedeno seznámení a zaškolení ostatních uživatelů s novou aplikací a na zkušebním provozu se již podíleli všichni uživatelé. Celkem trval zkušební provoz 3 měsíce.

5.4 Vyhodnocení zkušebního provozu a uvedení aplikace do provozu Po úspěšném zvládnutí zkušebního provozu byl domluven termín přechodu na novou aplikaci. Vzhledem k tomu, že nová aplikace se nelišila výrazně od původní aplikace, tak bylo seznámení a přechod na novou aplikaci bezproblémové. Termínem přechodu na novou aplikaci byl myšlen stav, kdy se bude používat jen nová aplikace a stará aplikace byla odstraněna. Dále následoval převod dat na SQL server a změny zdroje dat, který však uživatelé ani nepostřehli, jelikož aplikace byla od počátku vyvíjena tak, aby bylo možné používat bez podstatné změny aplikace různé databázové systémy.

70


6 Zhodnocení a závěr 6.1 Průběh vývoje aplikace a projektu Kromě vytvoření nového moderního informačního systému byl jedním z hlavních požadavků na aplikaci co nejmenší dopad na zaměstnance při přechodu na novou aplikaci. To se úspěšně zdařilo díky použité technologii bylo možné aplikaci po nějakou dobu testovat za současného provozu staré aplikace. Po odladění bylo možné přejít na novou aplikaci a změnit databázový stroj. Při vývoji byly výhodou dlouholeté zkušenosti s vývojem předchozí aplikace a výborné znalosti jednotlivých procesů na Rozhodčím soudě. Testování v provozu probíhalo se dvěmi vybranými pracovnicemi, které byly ochotny i přes vysoké pracovní vytížení pracovat se dvěma systémy a díky nim došlo k rychlému odladění nové aplikace a následnému zkušebnímu provozu u ostatních uživatelů.

6.2 Přínosy aplikace Přínosy nové aplikace by se daly rozdělit na dvě části. Jednak z pohledu uživatele aplikace, kde přínosy nejsou na první pohled velké, jelikož jedním z hlavních požadavků na aplikaci byl co nejmenší dopad na uživatele. Došlo sice k drobným úpravám designu a způsobu ovládání, ale v zásadě se uživatelé nemuseli učit pracovat s novým informačním systémem. Z pohledu uživatelů je rozhodně přínosem to, že se nemuseli přeškolovat na zcela nový informační systém a po odladění aplikace ve zkušebním provozu přešli plynule na novou aplikaci. Z pohledu systémového jsou přínosy nové aplikace nejvýznamnější, zejména s výhledem na budoucí rozvoj aplikace. Aplikace v MS Access již přestávala vyhovovat a s přibývajícími daty bylo zpracování některých dotazů, zejména při práci s dokumenty, již dosti pomalé. Oproštění se od závislosti na MS Accessu přinese úsporu při pořizování nových licencí MS Office, kde bude postačovat verze Standard, nebo jiná verze bez MS Accessu. Bezesporu nejvyšší výhodou je použití robustního a výkonného SQL serveru, čímž došlo ke zrychlení odezvy aplikace při zpracovávání SQL dotazů

71

Informační systém pro rozhodčí řízení nad objemnými tabulkami, dále spatřuji přínos ve vyšším zabezpečení zdrojových dat před neoprávněným přístupem. MS SQL server umožňuje napojení dalších aplikací, zejména webové aplikace pro rozhodčí řízení on-line. Budoucí aplikace tak budou využívat pouze jediný zdroj dat, což přinese úspory na údržbu systému a hlavně zjednodušení správy systému.

6.3 Budoucí rozvoj aplikace V dnešní době snad nelze o žádné aplikaci tohoto druhu říci, že je hotova a po předání uživatelům již není třeba nic vylepšovat. Stejně tak to platí o nové aplikaci pro rozhodčí řízení. Předěláním aplikace na novou technologii se nyní otevírají dveře pro další rozvoj a použití ovládacích prvků a technologií, které již nebylo možné na platformě MS Access použít. Následující vývoj bude zaměřen na zcela novou část aplikace, která poběží jako webová aplikace a přibudou tak nové uživatelské role rozhodců a zúčastněných stran ve sporu, kteří budou moci pasivně i aktivně pracovat se aplikací. Zejména půjde o nahlížení do vlastních sporů a zjišťování informací o sporech 24 hodin denně a 7 dní v týdnu. Aplikace bude rozšířena i o možnosti editovat vybraná data, zejména půjde o vkládání dokumentů do sporu a pro rozhodčí senát i možnost se pomocí aplikace domluvit přímo na termínu ústního jednání. Dalším požadavkem, se kterým se již počítalo v průběhu návrhu aplikace bude propojení na Document Management System (dále jen DMS). Vyvíjení vlastního DMS by bylo neefektivní, proto bude zvoleno řešení použití již hotového řešení a propojení aplikace pro rozhodčí řízení s DMS pomocí middlewaru. V současné době již probíhá podrobná analýza a testování DMS Elo Office verze 6.0 Enterprise. Díky použitým technologiím se vytvořila nová aplikace, kterou bude možné během následujících let nadále rozšiřovat a přizpůsobovat požadavkům doby a potřebám Rozhodčího soudu.

72


7 Seznam použité literatury a informačních zdrojů [1]

Vieira R.: SQL Server 2000 Programujeme profesionálně, Computer Press Praha 2001

[2]

Robinson S. a kolektiv: C# Programujeme profesionálně , vydavatelství Computer Press Brno 2003

[3]

Bayer J.: C# Velká kniha řešení, vydavatelství Computer Press Brno 2007

[4]

Lacko L.: SQL Hotová řešení, vydavatelství Computer Press Brno 2003

[5]

Petzold Ch.: Programování Microsoft Windows Form v jazyce C#, vydavatelství Computer Press Brno 2006

[6]

Agarwal V., Huddleston J.: Databáze v C# 2008 Průvdce programátora, vydavatelství Computer Press Brno 2009

[7]

Virius M.: C# Hotová řešení, vydavatelství Computer Press Brno 2006

[8]

Pirkl J.: C# skutečně prakticky, nakladatelství Kopp České Budějovice 2005

[9]

Mareš A.: 1001 tipů a triků pro C#, vydavatelství Computer Press Brno 2008

[10]

Dostálek L. a kolektiv: Velký průvodce protokoly TCP/IP - bezpečnost , vydavatelství Computer Press Brno 2003

[11]

Gürtler M., Kocich P.: Visual Basic .NET Hotová řešení, CP Books 2005

[12]

Barker F.: Microsoft Access 2002 Programování databázových aplikací, Computer Press Praha 2002

[13]

Halvorson M.: Microsoft Visual Basic 2008 Krok za krokem, Computer Press Brno 2008

[14]

Riordan R.: Microsoft ADO.NET krok za krokem, Mobil Media Praha 2002

[15]

Garfinkel S., Spafford G.: Bezpečnost v UNIXU a internetu v praxi, vydavatelství Computerpress Praha 1998

[16]

Kanisová H., Müller M.: UML srozumitelně, Computer Press Brno 2006

[17]

Buchalcevová A., Metodiky vývoje a údržby informačních systémů. 1. vyd., Grada Praha 2005

[18]

Internet: http://php.vrana.cz

[19]

Internet: msdn1.microsoft.com/en-us

73

Informační systém pro rozhodčí řízení [20]

Internet: www.developer.sk

[21]

Internet: http://phpmailer.sourceforge.net

[22]

Internet: http://www.pcsvet.cz – Seriál PHP pro začátečníky

[23]

Internet: http://cs.wikipedia.org/wiki

[24]

Internet: http://www.soud.cz

[25]

Internet: http://www.security-portal.cz/clanky/metody-utoku-na-microsoft-sqlservery.html 11.1.2009

[26

Internet: http://interval.cz/clanky/zabezpeceni-ms-sql-serveru-zakladnikonfigurace/ 11.1.2009

[27]

Internet: 16.4.2009

[28]

Internet: http://programujte.com/?akce=clanek&cl=2008120700--net-framework 16.4.2009

[29]

Internet: http://forum.builder.cz/read.php?31,2678064, 17.3.2009

http://www.microsoft.com/cze/msdn/produkty/vstudio/default.mspx

74


8 Seznam obrázků a tabulek Obrázky Obrázek 1. Ukázka programu Evidence sporů – modul spory ....................................... 12 Obrázek 2. Ukázka modulu adresáře .............................................................................. 13 Obrázek 3. Průvodce formulářem - výběr šablony dokumentu ...................................... 15 Obrázek 4. Průvodce formulářem - výběr adresáta ........................................................ 16 Obrázek 5. Průvodce formulářem - kontrola a doplnění dat z databáze......................... 16 Obrázek 6. Formulář ústní jednání, pohled na jeden den ............................................... 17 Obrázek 7. Use Case diagram role referenta sporů ........................................................ 21 Obrázek 8. Use Case diagram role zapisovatelky........................................................... 22 Obrázek 9. Use Case diagram role účetní....................................................................... 23 Obrázek 10. Use Case diagram role pracovníka podatelny ............................................ 24 Obrázek 11. Use Case diagram role tajemníka............................................................... 25 Obrázek 12. Activity diagram generování dokumentu................................................... 32 Obrázek 13. Formulář hlavního modulu Spory .............................................................. 35 Obrázek 14. Formulář modulu Adresář .......................................................................... 36 Obrázek 15. Návrh formuláře ústních jednání – pohled na jeden den............................ 37 Obrázek 16. Návrh formuláře ústních jednání – pohled na týden .................................. 38 Obrázek 17. Návrh formuláře ústních jednání – pohled na kalendářní měsíc................ 38 Obrázek 18. Formulář pro editaci ústního jednání ......................................................... 39 Obrázek 19. Schéma uspořádání sítě .............................................................................. 42 Obrázek 20. Schéma prostředí .NET Framework........................................................... 46 Obrázek 21. Ukázka uživatelského rozhraní aplikace .................................................... 56

75

Informační systém pro rozhodčí řízení Obrázek 22. Ukázka upozornění na chybu s jejím popisem po kontrole dat.................. 58 Obrázek 23. Vodopádový model vývoje aplikace .......................................................... 66

Tabulky Tabulka 1. Přehled automaticky nastavovaných procesních lhůt ................................... 28 Tabulka 2. Technická specifikace serveru ...................................................................... 41 Tabulka 3. Přehled instalovaného software .................................................................... 43 Tabulka 4. Minimální doporučená konfigurace pracovní stanice................................... 43 Tabulka 5. Přehled verzí Visual Studia 2008 a jejich určení.......................................... 44 Tabulka 6. Výhody a nevýhody Visual C#..................................................................... 47 Tabulka 7. Výhody a nevýhody Visual Basic .NET....................................................... 48 Tabulka 8. Porovnání edicí MS SQL Server 2005 ......................................................... 49 Tabulka 9. Tabulka v NFNF – non first normal form .................................................... 52 Tabulka 10. Tabulka 8 převedená do 1.NF..................................................................... 52 Tabulka 11. Příklad tabulky sporů před úpravou do 2NF.............................................. 53 Tabulka 12. Pomocná tabulka tblZalujiciStrany............................................................ 53 Tabulka 13 Pomocná tabulka tblZalovaneStrany .......................................................... 53 Tabulka 14 Tabulka tblAdresy ...................................................................................... 53 Tabulka 15. Přehled zálohování dat................................................................................ 55 Tabulka 16. Přehled konvencí pro pojmenování ovládacích prvků................................ 63 Tabulka 17. Přehled konvencí pro pojmenování proměnných ....................................... 64 Tabulka 18. Etapy vývoje aplikace................................................................................. 69

76


9 Přílohy

77


Příloha č. 1 9.1 Relační schéma databáze

78


Příloha č. 2 9.2 Popis tabulek databáze

Název tabulky ptblErrorLog PK: ErrorLogID ptblFormaRozsudku PK: FormaRozsudkuID

Popis tabulky V tabulce jsou uloženy zalogované chyby aplikace.

ptblGlobalniNastaveni

Pomocná tabulka, kde jsou uložena globální nastavení, např. cesty k webu ČNB, cesty k dokumentům na serveru atd. Pomocná tabulka, kde jsou uložena nastavení např. posledních zobrazených záznamů ve formulářích pro každého uživatele. Zde jsou uvdedeny texty, které se zobrazují v kombinovaném seznamu s texty návratek u odeslané pošty. Možnosti způsobů odeslaní dokuentu pro kombinovaný seznam.

ptblLokalniNastaveni

ptblPostaTextyNavratek PK: PostNavratkaID ptblZpusobyOdeslaniPosty Pk: TypOdeslaniID tblAdresy PK: AdresaID FK: StatID tblAdresyUlozeneVybery PK: VyberAdresID FK: PracovnikID tblUlozeneVybery_Polozky FK: VyberAdresID, AdresaID tblAdresyZmeny PK: AdresaZmenaID FK: AdresaID, PracovnikID tblHonorare PK: HonorarID

Pomocná tabulka, kde jsou uloženy formy rozsudku, které se zobrazují v rozbalovacích seznamech.

Zde jsou uloženy hlavní informace pro adresář. Jedná se o seznam ID adres, které si uživatel vybral pro další zpracování – zde se ukládá pouze ID pracovníka a popis výběru. Zde jsou uloženy konkrétní ID adres, které jsou součástí výběru tabulky tblAdresyUlozeneVybery. Do této tabulky se ukládají provedené změny v tblAdresy. Je to v podstatě logování změn. Zde jsou uloženy honoráře rozhodcům. Pomocí příznaků Print a

79

Informační systém pro rozhodčí řízení FK: SporID, AdresaID, FunkceID

tblHonorareFunkce PK: FunkceID tblInterniSdeleniUctarne PK: IntSdeleniID FK: SporID, PracovnikID tblInterniSdeleniUctarnePoplatky FK: IntSdeleniID, TypPoplatkuID, PoplatekID, MenaID tblInterniSdeleniUctarneVyuctovani FK: IntSdeleniID tblKurzListekCNB PK: Datum tblMeny PK: MenaID

tblPlatebniPrikazy PK: PlatPrikazID tblPlatebniPrikazyPolozky FK: PlatPrikazID tblPoplatky PK: PoplatekID FK: SporID, MenaID, TypID tblPoplatkyPreklady FK: SporID

tblPoplatkyZnalci FK: SporID

PlatPrikaz se provádí tisky a přenos do platebních příkazů a následně do účetního software. Zde je uložen seznam funkcí, za kterou je rozhodce honorován. Interní doklady účtárně se používají při ukončení sporu jako závěrečné vyúčtování příjmů a výdajů a slouží jako doklad pro zaúčtování do účetní evidence. Zde jsou uloženy jednotlivé položky interního sdělení účtárně, jelikož jich může být několik. Zde se ukládají k interním sdělení částky které jdou do výnosů a které se vrací stranám. Zde uloženy stažené kurzy z webu ČNB pro rychlejší off-line vyhledání kurzu. Seznam měn, ve kterých byla podána nějaká žaloba. Seznam se doplňuje správcem dle požadavků, jsou zde jen ty měny, ve kterých v minulosti byla podána nějaká žaloba – tabulka obsahuje i již neplatné nebo zaniklé měny. Zde se ukládají položky hlavičky platebních příkazů jako je číslo, datum, vrubový účet apod. Zde se ukládají jednotlivé řádky platebních příkazů jako je částka, číslo účtu příjemce apod. Zde se ukládají všechny vyměřené poplatky ke sporu. Poplatky jsou rozlišeny podle typu poplatku TypID. Zde se ukládají ke sporům poplatky vyplacené za překlady, aby se dalo sledovat čerpání zálohy zaplacené na překlady. Zde se ukládají ke sporům poplatky vyplacené za znalecké posudky, aby se dalo sledovat čerpání zálohy zaplacené na znalecké posudky. 80

Informační systém pro rozhodčí řízení tblPracovniciRS PK: PracovnikID

tblPracovniciZastupitelnost tblPrava PK: PravoID FK: PracovnikID tblPredmetSporu PK: PredmetSporuID

tblPrubehSporu PK: PrubehSporuID FK: SporID tblSpory PK: SporID FK: MenaID, ProtiZalobaMenaID, PredmetSporuID, PredSenID, RozhZalstrID, RozhZalovstrID, JedinyRozhID, OpatrovnikZalstrID, OpatrovnikZalovstrID, ZnalecZalstrID, ZnalecZalovsrtrID, IntervZalstrID, IntervZalovstrID tblStaty PK: StatID

tblTypyPrubehuaPoplatku PK: TypID tblUcty PK: CisloUctu tblUstniJednani PK: UstniJednaniID FK: SporID, MistoKonaniID

V této tabulce jsou záznamy o pracovnících Rozhodčího soudu, kteří mohou pracovat s databází. Je zde i uložen hash hesla a další údaje jako jsou kontakty apod. Zde se uchovává informace pokud si referent zvolí svého zástupce. Zde uloženy informace o právech pracovníka do jednotlivých modulů programu. Předměty sporů pro kombinovaný seznam a možnost statistického vyhodnocování sporů dle předmětu sporu. Do této tabulky se zaznamenávají různé procesní události, které se mohou vyskytovat opakovaně a dále se zde ukládají procesní lhůty. Hlavní tabulka modulu sporů, kde se ukládají informace o sporech.

Seznam států, které se zobrazují v rozbalovacím seznamu; státy nejsou všechny, ale jen ty, které v minulosti podávaly žalobu u RS a je možné je doplňovat v případě potřeby v administračním rozhraní aplikace. Zde je seznam opakujících se procesních událostí a lhůt pro vyplnění kombinovaného seznamu. Seznam bankovních účtů RS pro zobrazování v rozbalovacích seznamech. V této tabulce jsou uložena ústní jednání ke sporu.

81

Informační systém pro rozhodčí řízení tblUstniJednaniMistaUJ PK: MistoKonaniID tblUstniJednaniPoznamky PK: UstniJednaniPoznamkaID FK: UstniJednaniID tblWordDokumenty PK: DokumentID FK: SporID, TypOdeslaniID, PracovnikID, FormularID, AdresaID tblWordSeznamFormularu PK: FormularID

tblZalovaneStrany PK: ZalovstrID FK: SporID, AdresaID, ZastupceID tblZalujiciStrany PK: ZalstrID FK: SporID, AdresaID, ZastupceID

Seznam míst, kde se konají ústní jednání pro zobrazování v rozbalovacích seznamech. V této tabulce jsou uloženy poznámky k ÚJ; samostatná tabulka z důvodu zajištění oprávnění na úrovni tabulky – viz. práva uživatelů v technické specifikaci. Zde jsou uloženy odkazy na vytvořené nebo vložené dokumenty do apliakce. Zde je seznam všech šablon pro vytváření dokumentů včetně booleovského příznaku v jakém jazyce je šablona dostupná. Zde se ukládají odkazy na žalované strany. Zde se ukládají odkazy na žalující strany.

82


Příloha č. 3 9.3 Funkce FormFromEdit() public static void FormFromEdit(Control.ControlCollection Controls) { foreach (Control c in Controls) { string strTypControlu = ClassObecneFunkce.Right(c.Name.ToString(), 3); if (strTypControlu == "_ED") { //text box if (c.GetType().Name.ToString() == "TextBox") { TextBox t = (TextBox)c; t.ReadOnly = true; t.BackColor = Color.White; } //combo box if (c.GetType().Name.ToString() == "ComboBox") { ComboBox cb = (ComboBox)c; cb.Enabled = false; cb.BackColor = Color.White; } //group box if (c.GetType().Name.ToString() == "GroupBox") { GroupBox gpb = (GroupBox)c; gpb.Enabled = false; gpb.BackColor = Color.Transparent; } //check box if (c.GetType().Name.ToString() == "CheckBox") { CheckBox chk = (CheckBox)c; chk.Enabled = false; } } else if (strTypControlu == "_EU") { c.Show(); } else if (strTypControlu == "_EV") { c.Hide(); } else ClassObecneFunkce.FormFromEdit(c.Controls); } }

83


Příloha č. 4 9.4 Funkce pro vytvoření SQL dotazu private string MakeUpdateSQL(long lngAdresaID) { string strSQL = "UPDATE tblAdresy SET "; string strSQL_WHERE = "WHERE (tblAdresy.AdresaID=" + lngAdresaID + ")"; //naplneni jednotlivych poli SQL dle vyplnenych poli ve frm strSQL = strSQL + "Nazev = " + ClassObecneFunkce.StringToSQL(this.txtNazev_ED.Text); strSQL = strSQL + "Jmeno = " + ClassObecneFunkce.StringToSQL(this.txtJmeno_ED.Text); strSQL = strSQL + "Ulice = " + ClassObecneFunkce.StringToSQL(this.txtUlice_ED.Text); strSQL = strSQL + "UliceKorespondence = " + ClassObecneFunkce.StringToSQL(this.txtUliceKorespondence_ED.Text); strSQL = strSQL + "Mesto = " + ClassObecneFunkce.StringToSQL(this.txtMesto_ED.Text); strSQL = strSQL + "MestoKorespondence = " + ClassObecneFunkce.StringToSQL(this.txtMestoKorespondence_ED.Text); strSQL = strSQL + "PSC = " + ClassObecneFunkce.StringToSQL(this.txtPSC_ED.Text); strSQL = strSQL + "PSCKorespondence = " + ClassObecneFunkce.StringToSQL(this.txtPSCKorespondence_ED.Text); strSQL = strSQL + "Telefon1 = " + ClassObecneFunkce.StringToSQL(this.txtTelefon1_ED.Text); strSQL = strSQL + "Telefon2 = " + ClassObecneFunkce.StringToSQL(this.txtTelefon2_ED.Text); strSQL = strSQL + "Fax = " + ClassObecneFunkce.StringToSQL(this.txtFax_ED.Text); strSQL = strSQL + "Mobil = " + ClassObecneFunkce.StringToSQL(this.txtMobil_ED.Text); strSQL = strSQL + "Email = " + ClassObecneFunkce.StringToSQL(this.txtEmail_ED.Text); strSQL = strSQL + "Web = " + ClassObecneFunkce.StringToSQL(this.txtWeb_ED.Text); strSQL = strSQL + "IC = " + ClassObecneFunkce.StringToSQL(this.txtIC_ED.Text); strSQL = strSQL + "DIC = " + ClassObecneFunkce.StringToSQL(this.txtDIC_ED.Text); strSQL = strSQL + "KontoPredcisli = " + strSQL = strSQL + "Aktivni = " + Convert.ToBoolean(this.chkNeaktivniAdresa_ED.Checked) + ", "; strSQL = strSQL + "Poznamka = " + ClassObecneFunkce.StringToSQL(this.txtPoznamka_ED.Text); //oriznuti posledni carky ze strSQL strSQL = strSQL.Substring(0, strSQL.Length - 2) + " "; //spojeni SQL return strSQL + strSQL_WHERE; }

84


Příloha č. 5 9.5 CD-ROM se zdrojovým kódem aplikace Na přiloženém CD-ROM jsou všechny zdrojové kódy aplikace popsané v této diplomové práci.

85

Informační systém pro rozhodčí řízení

Recommend Documents