Informační systém pro správu mezinárodních studentských identifikačních karet (ISIC)

České vysoké učení technické v Praze Fakulta elektrotechnická Katedra počítačů

Diplomová práce

Informační systém pro správu mezinárodních studentských identifikačních karet (ISIC) Bc. Tomáš Jaroš

Vedoucí práce: Ing. Martin Molhanec, CSc.

Studijní program: Elektrotechnika a informatika, strukturovaný, Navazující magisterský Obor: Výpočetní technika prosinec 2010

iv

v

Poděkování Na tomto místě bych rád poděkoval vedoucímu své diplomové práce Ing. Martinu Molhancovi, CSc. za cenné rady a připomínky. Dále patří můj dík kolegům z Orchitech Solutions za poskytnutí zajímavého tématu a podnětných nápadů k jeho realizci. Rovněž děkuji své rodině a přítelkyni za neutuchající podporu nejen v době vytváření této práce, ale v celém průběhu studia.

vi

vii

Prohlášení Prohlašuji, že jsem práci vypracoval samostatně a použil jsem pouze podklady uvedené v přiloženém seznamu. Nemám závažný důvod proti užití tohoto školního díla ve smyslu §60 Zákona č. 121/2000 Sb., o právu autorském, o právech souvisejících s právem autorským a o změně některých zákonů (autorský zákon).

V Praze dne 3. ledna 2011

.............................................................

viii

Abstract This diploma thesis describes the design and implementation of an information system for managing international student identification cards, the ISIC, which replaces the existing solution managed by the International Association Services. The goal is to analyze the shortcomings of the current database and create a new system that eliminates the causes of the identified problems while maintaining maximum backwards compatibility of the public interfaces used by card issuers in many countries of the world. The work also includes the implementation of previously non-existent administration user interface in the form of a web application and implementation of a tool for migrating data from the old database.

Abstrakt Tato práce se zabývá návrhem a implementací informačního systému pro správu mezinárodních studentských identifikačních karet ISIC, který nahrazuje existující řešení spravované organizací International Association Services. Cílem práce je zanalyzovat nedostatky současné databáze ISIC karet a vytvořit systém, který příčiny zjištěných problémů odstraňuje při zachování maximální zpětné kompatibility veřejných rozhraní používaných vydavateli karet v mnoha zemích světa. Součástí práce je také implementace doposud neexistujícího administračního uživatelského rozhraní ve formě webové aplikace a implementace nástroje pro migraci dat z databáze starého systému.

ix

x

Obsah 1 Úvod

1

2 Použité technologie 2.1 Java EE . . . . . . 2.2 Spring Framework 2.3 Hibernate . . . . . 2.4 Webové služby . . 2.5 Vaadin . . . . . . . 2.6 PostgreSQL . . . . 2.7 Tomcat . . . . . . 2.8 Maven . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

3 3 3 6 6 7 7 8 8

3 Úvodní studie 3.1 Úvod do problematiky vydávání karet . . . . . . . 3.1.1 Výdej karet licenčními autoritami . . . . . 3.1.2 CardMaster.NET . . . . . . . . . . . . . . . 3.1.3 Střední školy . . . . . . . . . . . . . . . . . 3.1.4 Univerzitní karty . . . . . . . . . . . . . . . 3.2 Rozbor evidence karet . . . . . . . . . . . . . . . . 3.2.1 Identifikační karty ISIC . . . . . . . . . . . 3.2.1.1 Čísla karet . . . . . . . . . . . . . 3.2.1.2 Platnost karet . . . . . . . . . . . 3.2.2 Vydavatelé karet . . . . . . . . . . . . . . . 3.2.3 Rozsahy licenčních čísel . . . . . . . . . . . 3.3 Současný stav . . . . . . . . . . . . . . . . . . . . . 3.4 Deklarace záměru . . . . . . . . . . . . . . . . . . . 3.5 Rozbor a definice požadavků . . . . . . . . . . . . 3.5.1 Uživatelské role . . . . . . . . . . . . . . . . 3.5.2 Funkční požadavky . . . . . . . . . . . . . . 3.5.2.1 Správa karet . . . . . . . . . . . . 3.5.2.2 Správa rozsahů . . . . . . . . . . . 3.5.2.3 Verifikace karet . . . . . . . . . . 3.5.2.4 Track & Trace . . . . . . . . . . . 3.5.2.5 Synchronizace s CardMaster.NET 3.5.2.6 Migrace dat . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . .

9 9 9 9 10 10 10 10 12 13 13 13 14 14 15 15 16 16 17 18 18 19 19

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xi

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

xii

OBSAH

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

19 19 20 20 22 24 24 25 25 25 26 26 26 27

4 Analýza a návrh řešení 4.1 Analýza současného systému . . . . . . . . . . . . . . . . . 4.1.1 Existující data . . . . . . . . . . . . . . . . . . . . . 4.1.1.1 Tabulka SerialNumbers . . . . . . . . . . 4.1.1.2 Tabulka CardsIssued . . . . . . . . . . . . 4.1.1.3 Tabulka Issuers . . . . . . . . . . . . . . 4.1.1.4 Tabulka Providers . . . . . . . . . . . . . 4.1.1.5 Tabulka logUpdates . . . . . . . . . . . . 4.1.1.6 Identifikované problémy současné evidence 4.1.2 Webové služby CCDB . . . . . . . . . . . . . . . . . 4.1.2.1 UpdateCardV2 . . . . . . . . . . . . . . . . 4.1.2.2 VerifyCard . . . . . . . . . . . . . . . . . 4.1.2.3 UpdateCard . . . . . . . . . . . . . . . . . 4.1.2.4 Identifikované nedostatky webových služeb 4.1.3 Synchronizace s CardMaster.NET . . . . . . . . . . 4.1.4 Závěr analýzy . . . . . . . . . . . . . . . . . . . . . . 4.2 Konceptuální datový model . . . . . . . . . . . . . . . . . . 4.2.1 Popis modelu . . . . . . . . . . . . . . . . . . . . . . 4.2.2 Entity . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2.3 Vztahy mezi entitami . . . . . . . . . . . . . . . . . 4.3 Popis případů užití . . . . . . . . . . . . . . . . . . . . . . . 4.3.1 Strojové rozhraní . . . . . . . . . . . . . . . . . . . . 4.3.1.1 UC001 - Vytvoření nové karty . . . . . . . 4.3.1.2 UC002 - Ověření platnosti karty . . . . . . 4.3.2 Grafické uživatelské rozhraní . . . . . . . . . . . . . 4.3.2.1 UC101 – Přihlášení do systému . . . . . . . 4.3.2.2 UC102 – Odhlášení ze systému . . . . . . . 4.3.2.3 UC103 – Prohlížení seznamu karet . . . . . 4.3.2.4 UC104 – Zobrazení detailu karty . . . . . . 4.3.2.5 UC105 – Smazání karty . . . . . . . . . . . 4.3.2.6 UC106 – Zrušení karty . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29 29 29 29 31 33 34 36 36 38 38 40 42 42 42 43 43 43 45 46 47 47 47 48 49 49 50 50 51 51 52

3.6 3.7 3.8

3.9

3.5.2.7 Obecné požadavky na funkčnost 3.5.3 Nefunkční požadavky . . . . . . . . . . . Případy užití nejvyšší úrovně . . . . . . . . . . . Návrh architektury . . . . . . . . . . . . . . . . . Analýza rizik . . . . . . . . . . . . . . . . . . . . 3.8.1 Špatný odhad velikosti projektu . . . . . 3.8.2 Chybná analýza . . . . . . . . . . . . . . 3.8.3 Změna požadavků . . . . . . . . . . . . . 3.8.4 HW nebo SW nekompatibilita . . . . . . 3.8.5 Vada na HW nebo SW při vývoji . . . . . 3.8.6 Nedostatečná znalost technologií . . . . . 3.8.7 Odklon od požadavků . . . . . . . . . . . 3.8.8 Neoprávněný přístup k datům . . . . . . . Slovník pojmů . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

. . . . . . . . . . . . . .

OBSAH

xiii

4.3.2.7 4.3.2.8 4.3.2.9 4.3.2.10 4.3.2.11 4.3.2.12 4.3.2.13 4.3.2.14 4.3.2.15 4.3.2.16

UC107 UC108 UC109 UC110 UC111 UC112 UC113 UC114 UC115 UC116

– – – – – – – – – –

Ověření platnosti karty . . . Import karet z XLS . . . . . Prohlížení seznamu rozsahů Vytvoření nového rozsahu . Editace rozsahu . . . . . . . Smazání rozsahu . . . . . . . Prohlížení seznamu událostí Zaznamenání nové události . Editace události . . . . . . . Smazání události . . . . . .

5 Implementace 5.1 CCDB Core . . . . . . . . . . . . . . . 5.1.1 Databázová vrstva . . . . . . . 5.1.1.1 Doménové objekty . . 5.1.1.2 Fyzický datový model 5.1.1.3 DAO . . . . . . . . . 5.1.2 Vrstva business logiky . . . . . 5.1.3 Webové služby . . . . . . . . . 5.1.3.1 REST . . . . . . . . . 5.1.3.2 SOAP . . . . . . . . . 5.1.4 Struktura tříd . . . . . . . . . . 5.2 CCDB Web UI . . . . . . . . . . . . . 5.3 Migrační nástroj . . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

. . . . . . . . . . . .

. . . . . . . . . .

52 53 53 54 55 55 56 56 57 58

. . . . . . . . . . . .

59 59 59 60 61 65 66 67 67 69 70 71 73

6 Závěr

75

Literatura

77

A Uživatelská příručka

79

B Obsah přiloženého CD

83

xiv

OBSAH

Seznam obrázků 2.1

Přehled komponent Spring frameworku . . . . . . . . . . . . . . . . . . . . . .

3.1 3.2 3.3 3.4

Existující způsoby vydávání karet Případy užití nejvyšší úrovně . . Diagram komponent . . . . . . . Diagram nasazení . . . . . . . . .

4.1 4.2 4.3 4.4 4.5 5.1 5.2 5.3 5.4

. . . .

. . . .

. . . .

. . . .

. . . .

11 21 22 23

Diagram aktivit – zpracování požadavku webovou službou Diagram aktivit – zpracování požadavku webovou službou Tok dat při synchronizaci karet z CardMaster.NET . . . . Konceptuální datový model . . . . . . . . . . . . . . . . . Diagram aktivit pro UC001 – Vytvoření nové karty . . . .

UpdateCardV2 VerifyCard . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . .

. . . . .

39 41 43 44 48

Diagram tříd doménových objektů . . . . . . Fyzický datový model . . . . . . . . . . . . . Použití návrhového vzoru Data Access Object Diagram tříd reprezentujících úlohy migrace .

. . . .

. . . .

. . . .

60 62 65 73

xv

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

4

. . . .

. . . .

xvi

SEZNAM OBRÁZKŮ

Kapitola 1

Úvod Brána do světa benefitů. Tak zní motto mezinárodních studentských identifikačních karet ISIC (International Student Identity Card). Studenti s těmito kartami mohou využívat řady výhod u nasmlouvaných partnerů po celém světě. Tyto výhody mají nejčastěji podobu slev na služby či zboží, běžně se s nimi lze potkat v oblasti cestování, kultury, sportu a volného času. Průkazy ISIC jsou jedinými globálně uznávanými studentskými identifikačními kartami ve 120 zemích světa, i u nás v České Republice si každý pod pojmem „studentská karta“ představí ISIC. ISIC karty mají za sebou více než 50letou historii. Na svém počátku mohli držitelé ISIC karet využívat slevy pouze v letecké dopravě. Dnes po světě chodí přibližně 5 milionů studentů s aktivními ISIC kartami, kteří ročně ušetří cca $500 mil. na více než 40 tisících slevách. Tento business s benefitními kartami je úspěšný a stále se rozrůstá. Za vším stojí společnost ISIC Association, která je členem neziskové organizace World Youth Student and Educational Travel Confederation (WYSETC), jejímž cílem je zvyšovat míru vzájemného dorozumění mezi lidmi po celém světě. Pro studenty a mládež zpřístupňují speciální služby jako např. jazykové pobyty, pracovní pobyty, Au Pair praxe, cestovní pojištění a v neposlední řadě jim také nabízejí studentské identifikační průkazy. ISIC Association i WYSETC jsou spravovány organizací International Association Services (IAS), sídlící v Amsterodamu, která se stala klientem společnosti Orchitech Solutions s.r.o., v níž pracuji. Organizaci IAS dodáváme IT řešení šitá na míru. Informační systém spravující identifikační karty je základním prvkem IT infrastruktury organizace IAS, která stojí v pozadí veškerých aktivit spojených s těmito kartami. Na tomto systému závisí všechny ostatní softwarové komponenty, které se nějakým způsobem váží k ISIC kartám, např. spravují benefity poskytované ke kartám nebo organizace, které tyto benefity nabízejí. Nejdůležitější úlohou je samotné uchovávání informací o kartách a jejich držitelích, bez této centrální databáze karet (Central Card Database - CCDB) by organizace IAS nemohla fungovat. Důležitost tohoto systému tak na něj samotný klade požadavky stability, spolehlivosti a konzistence dat. Současná evidence karet je v těchto ohledech nevyhovující, proto bylo rozhodnuto o nahrazení stávajícího systému novou implementací, která pracovníkům IAS umožní spravovat ISIC karty komfortněji a bezpečněji. Návrh, vývoj a nasazení nového IT řešení pro správu identifikačních karet je obsahem této diplomové práce. Nový systém plnící úlohu centrální databáze je zkráceně označován jako CCDB2.

1

2

KAPITOLA 1. ÚVOD

Kapitola 2

Použité technologie V této kapitole jsou popsány softwarové technologie a nástroje, které byly použity pro návrh a realizaci CCDB2.

2.1

Java EE

Java Platform, Enterprise Edition (zkráceně Java EE1 ) je standardizovaná platforma pro vytváření a provoz vícevrstvých distribuovaných aplikací a podnikových informačních systémů. Je nadstavbou platformy Java SE (Java Platform, Standard Edition), která je široce používaným standardem pro vývoj přenositelných aplikací v programovacím jazyce Java. Běhovým prostředím aplikací vyvinutých pro platformu Java EE jsou tzv. aplikační servery, které implementují služby definované rozhraním platformy Java EE. Aplikace nasazené na aplikační server pak mohou těchto služeb využívat. Součástí aplikačního serveru je mimo jiné také webový kontejner (servletový kontejner), v němž mohou být spuštěny webové komponenty implementující patřičná rozhraní Jave EE – servlety, JSP. Tyto kontejnery mohou být dostačující pro provoz některých webových aplikací, proto jsou výrobci dodávány také samostané webové kontejnery, které neimplementují kompletní specifikaci Java EE aplikačních serverů.

2.2

Spring Framework

Spring Framework je velmi rozšířeným aplikačním rámcem pro systémy postavené na Java platformě. Má za sebou více než 8letou historii svého vývoje a rozsáhlou komunitu uživatelů, kteří s oblibou používají tento open-source projekt ve svých Java aplikacích. Jednotlivé komponenty tohoto frameworku mohou být použity v jakékoli Java aplikaci, z výhod většiny z nich lze ale těžit zejména při vývoji webových aplikací na platformě Java EE. Spring je často považován za plnohodnotnou alternativu k modelu architektury EJB2 . Největší výhodou tohoto frameworku je jeho modulární architektura rozložená do vrstev, jejichž komponenty mohou být využívány samostatně.[9] 1 2

ve svých dřívějších verzích byla také označována jako Java 2 Platform, Enteprise Edition nebo jen J2EE Enterprise JavaBeans – jedna ze specifikací Java EE určená k zapouzdření logiky na straně serveru.

3

4

KAPITOLA 2. POUŽITÉ TECHNOLOGIE

Spring obsahuje mnoho užitečných technických řešení pro obvyklé součásti enterprise aplikací. Jsou organizovány do samostatných modulů, které jsou seskupeny do logických celků (viz obrázek 2.1), jejichž stručný popis je uveden níže.

Obrázek 2.1: Přehled komponent Spring frameworku. Obrázek byl převzat z [7].

Core Container Jádro Spring frameworku je tvořeno implementací návrhového vzoru Inversion of Control (IoC), která je označována jako IoC kontejner. Ten poskytuje konzistentní přístup k vytváření a konfiguraci jednotlivých komponent aplikace, jejichž vazby na ostatní komponenty jsou řízeny metodou Dependency Injection 3 . Tento princip ja založen na přesunutí zodpovědnosti za vytváření objektů a jejich provázání mezi sebou z kódu aplikace na aplikační framework (IoC kontejner). Jednotlivé objekty pouze definují rozhraní svých závislostí na jiných objektech, IoC kontejner pak tyto objekty vytvoří4 a jejich závislosti splní vsazením ostatních objektů rovněž vytvořených tímto kontejnerem. Konfigurace IoC kontejneru je umístěna v XML souborech, lze ale využít i Java anotace v samotném kódu, které výrazně přispívají k větší přehlednosti a jednoduchosti konfigurace.

Data Access/Integration Tato vrstva reprezentuje množinu technologií pro přístup k datům uloženým v databázových systémech a pro interakci datové vrstvy aplikace s business vrstvou. Obsahuje tyto moduly: 3 4

Česky bychom ji mohli nazvat jako „vsazování závislostí“. Objekty vytvářené v aplikačním kontextu frameworku se nazývají Beans.

2.2. SPRING FRAMEWORK

5

• JDBC modul poskytuje abstraktní JDBC vrstvu, díky které mohou vývojáři snadněji využívat rozhraní JDBC, např. odstraňuje nutnost odchytávat výjimky specifické pro daný databázový systém. • ORM modul poskytuje podporu pro integraci populárních rozhraní objektově relačního mapování, jakými jsou např. JPA, Hibernate, JDO či iBatis. • OXM modul definuje abstraktní vrstvu pro Object/XML mapování5 nad implementacemi JAXB, Castor, XMLBeans, JiBX a XStream. • JMS modul (Java Messaging Service) obsahuje funkce zjednodušující práci s JMS API pro tvorbu a příjem zpráv. • Modul správy transakcí podporuje programové i deklarativní řízení databázových transakcí. Web Základní komponentou vrstvy webově orientovaných funkcí Spring frameworku je implementace architektonického vzoru Model-View-Controller (MVC). Centrálním prvkem tohoto modulu je implementace návrhového vzoru Front Controller v podobě třídy nazvané DispatcherServlet. Dále je v této vrstvě realizována podpora pro integraci s mnoha webovými technologiemi, např. Struts, JSF, Tapestry a další. AOP Spring disponuje vlastním AOP (Aspect-Oriented Programming) frameworkem pro podporu aspektově orientovaného programování. Tato technika umožňuje zvýšit modularitu systému pomocí separace částí kódu prolínajících se celou aplikací a tvořících jednotnou funkční oblast do tzv. aspektů. Tyto aspekty pak mohou být použity pro změnu chování základního kódu pomocí jejich aplikace na stanovené přípojné body ve struktuře provádění programu. AOP modul je klíčovou komponentou Spring frameworku, která je běžně používaná pro zajištění transakčního zpracování operací nebo logování informací do souborů. Test Tento modul poskytuje podporu pro testování jednotlivých komponent aplikace postavené na Spring frameworku pomocí JUnit nebo TestNG.

Sesterské Spring projekty Spring framework slouží také jako výchozí platforma pro další podprojekty, které adresují konkrétní otázky a problémy při vývoji Java EE aplikací. Uvádím pouze podprojekty, které byly použity pro realizaci CCDB2: Spring Security Framework pro zabezpečení aplikací a řízení přístupu k jednotlivým částem systémů. Spring Web Services Knihovna pro implementaci webových služeb. 5

Zkráceně též O/X mapování. Spočívá v mapování XML dokumentů na Java objekty.

6


2.3

Hibernate

Hibernate je knihovna objektově relačního mapování pro převod objektového doménového modelu Java aplikace na datovou strukturu tradiční relační databáze a zpět. Použitím tohoto ORM (Object-Relational Mapping) frameworku lze reprezentovat tabulky relační databáze jako běžné POJO objekty6 a usnadnit si tak práci při vývoji databázové vrstvy Java aplikací, které manipulují s perzistentními daty. Hibernate dále poskytuje užitečné nástroje pro práci s mapovanými daty, zejména pak jazyk HQL (Hibernate Query Language), který vychází ze standardního SQL a umožňuje psát dotazy na relační data v objektové notaci. Způsob mapování jednotlivých entit na databázové tabulky lze definovat buď pomocí konfiguračních souborů ve formátu XML, nebo může být kód doménových objektů doplněn o Hibernate anotace. Druhý způsob je přehlednější a jednodušší, je proto použit i pro objektově relační mapování doménových objektů CCDB2. V neposlední řadě Hibernate díky svému propracovanému API odstraňuje závislost Java aplikace na konkrétním databázovém systému, přechod na jiný RDBMS tak spočívá v jednoduchém zásahu do konfigurace Hibernate. Hibernate framework od verze 3 splňuje požadavky na implementaci standardizovaného rozhraní JPA (Java Persistence API ), které je navržené pro správu relačních dat na platformách Java EE i Java SE.

2.4

Webové služby

Webové služby jsou softwarové komponenty umožňující vzájemnou komunikaci mezi distribuovanými aplikacemi. Tyto komponenty zpřístupňují rozhraní k určitým službám vzdáleného systému, ke kterým je přistupováno přes aplikační protokol HTTP, jenž je běžně používaným protokolem pro uživatelskou interakci s webovými aplikacemi. Dle konsorcia W3C[8] lze v současnosti webové služby rozdělit do dvou velkých oblastí: • webové služby vyhovující standardům REST architektury, jejichž primárním účelem je manipulace s webovými zdroji pomocí jednotné množiny bezestavových operací, • webové služby libovolného charakteru, které zpřístupňují libovolné funkce systému. Ty bývají postaveny na protokolu SOAP.

SOAP SOAP (Simple Object Access Protocol) je protokolem pro výměnu zpráv mezi webovými službami. SOAP definuje vzdálené volání služby (funkce) jako jednoduchou XML zprávu, pro jejíž transport na rozhraní webové služby je použit aplikační protokol HTTP7 .[6] Při implementaci webových služeb komunikujících pomocí protokolu SOAP je využíván jazyk WSDL (Web Services Description Language), který definuje strukturu přijímaných a odesílaných SOAP zpráv. 6

Plain Old Java Objects – běžné Java objekty nepodléhající žádným speciálním konvencím. K tomuto účelu může sloužit i protokol SMTP, nicméně HTTP je uznávaným standardem pro SOAP zprávy zejména díky své rozšířenosti a snadné propustnosti přes síťové firewally. 7

2.5. VAADIN

7

REST REST (Representational State Transfer) je datově orientovaná architektura rozhraní navržená pro distribuovaná prostředí. Základním konceptem REST architektury je existence tzv. informačních zdrojů (resources), kdy každý zdroj má svůj jedinečný globální identifikátor, např. URI v HTTP protokolu. Pro manipulaci se zdroji je definován jednotný přístup v podobě čtyř operací CRUD (Create, Read, Update a Delete). Komunikace distribuovaných REST komponent pak spočívá ve výměně datových reprezentací zdrojů (HTML, XML, JSON, atd.) a je bezestavová. RESTful webové služby jsou webové služby využívající protokolu HTTP a principů REST architektury. RESTful webová služba je množina zdrojů (resourců), která definuje: • základní URI služby, např. http://example.org/ccdb2/resources/, • datový typ reprezentace resourců, např. XML nebo JSON, • sadu dostupných CRUD operací proveditelných pomocí různých typů HTTP metod – GET, POST, PUT, DELETE.

2.5

Vaadin

Vaadin je komponentový aplikační framework pro vývoj webových aplikací na platformě Java. Hlavním cílem tvůrců tohoto frameworku bylo poskytnout vývojářům jednoduchý způsob, kterým by mohli vytvořit uživatelsky bohaté webové aplikace8 , které poběží v internetových prohlížečích bez dodatečných zásuvných modulů. Tento způsob je blízký běžnému desktopovému programování (struktura Vaadin aplikace je podobná zejména klasickým Swing aplikacím), vývojáři jsou odstíněni od tradičních webových technologií, jako jsou HTML, CSS či JavaScript. Největší výhodou Vaadin frameworku je možnost použít pro vývoj webové aplikace pouze programovací jazyk Java. Vaadin obsahuje událostmi řízený programovací model, který je znám spíše z klasických Java SE aplikací. Uživatelské rozhraní (webové stránky) výsledné aplikace je vyrenderováno využitím technologie Google Web Toolkit.

2.6

PostgreSQL

PostgreSQL je výkonný objektově-relační databázový systém (ORDBMS) vydávaný jako open-source software, na jehož vývoji se podílí globální komunita programátorů. Během více než 15leté historie získal pověst kvalitního, rychlého a bezpečného databázového systému, který je velice populární mezi uživateli. PostgreSQL lze provozovat na všech významných operačních systémech. Kromě standardních funkcí všech relačních databází disponuje velkou množinou užitečných vlastností a nástrojů, např. podporou pro procedurální programování v zabudovaném jazyce PL/pgSQL. 8

Rich Internet Application, webové aplikace přebírající mnoho vlastností klasických desktopových aplikací.

8


2.7

Tomcat

Apache Tomcat je jeden z nejoblíbenějších Java EE webových kontejnerů, který je považován za referenční implementaci specifikací Java Servlet a JavaServer Pages (JSP). Tomcat je psaný v Javě, což mu zajišťuje platformní nezávislost. Dalšími jeho výhodami jsou jednoduchost, snadná konfigurovatelnost a relativní nenáročnost.

2.8

Maven

Apache Maven je softwarový nástroj pro správu projektů a automatizaci činností spojených s vývojem, testováním a údržbou aplikací psaných v Javě9 . Největší výhodou užití tohoto nástroje je princip, kterým zjednodušuje práci při sestavování aplikace, zejména pak způsob řešení závislostí na jiných knihovnách a projektech. Centrálním bodem pro Maven je povinný konfigurační soubor pom.xml, který reprezentuje popis projektu pomocí Project Object Model. V něm jsou mimo jiné uváděny reference na knihovny, které jsou v projektu používány. Maven automaticky stáhne příslušné verze knihoven z definovaných veřejných repozitářů a uloží je do lokálního repozitáře, odkud jsou při sestavování aplikace kopírovány do výsledné formy distribuce projektu. Vývojářům tak odpadá nutnost ručně stahovat a kopírovat používané knihovny mezi svými projekty. Maven sám je postaven na modulární architektuře a funguje na principu volání jednotlivých zásuvných modulů – pluginů. Např. využitím Hibernate pluginu lze vygenerovat SQL schéma z namapovaných entit, JAXB plugin dokáže z XML schematu vygenerovat množinu Java tříd.

9

Primárně je určen pro projekty stavěné na Java platformě, lze jej ale využít také při psaní aplikací v některých dalších programovacích jazycích.

Kapitola 3

Úvodní studie 3.1

Úvod do problematiky vydávání karet

Centrální evidence držitelů karet uchovává data o všech vydaných ISIC kartách z celého světa. V současnosti obsahuje přibližně 10 mil. karet, přičemž velkou část z nich tvoří karty s již prošlou platností. Vzhledem k rozšířenosti těchto karet si lze jen těžko představit, že by se o jejich vydávání starala jedna organizace a rozesílala je klientům do všech koutů světa. Proto je distribuce karet ve většině zemí řízena jednou společností, která drží licenční práva pro vydávání, propagaci a rozvoj studentských průkazů ISIC pro území dané země1 . Tyto organizace jsou nazývány licenční autority a jsou podřízeny společnosti IAS. Možné způsoby vydávání karet a jejich zaevidování v centrální databázi znázorňuje obr. 3.1.

3.1.1

Výdej karet licenčními autoritami

Licenční autority přijímají objednávky na nové karty od koncových zákazníků – budoucích držitelů – a starají se o jejich fyzický tisk a distribuci. Tyto karty hned při vydání vytvářejí v centrální databázi, nebo je evidují ve svých vlastních informačních systémech. V tomto případě jsou ale poviny informace o všech vydaných kartách pravidelně posílat do centrální databáze, kterou provozuje společnost IAS. Poskytovatelé výhod z celého světa ověřují platnost karet právě vůči této databázi. Lokální IS licenčních autorit pro správu vydaných karet se nazývají NCDB – National Card Database.

3.1.2

CardMaster.NET

Dalším způsobem, kterým mohou zájemci získat ISIC kartu, je návštěva akreditovaného prodejního místa, které je dle smlouvy přímo s IAS nebo s licenční autoritou pro danou zemi oprávněno vydávat identifikační karty. Většinou se jedná o pobočky cestovních kanceláří a dopravních podniků či městská informační centra. Zaměstnanci takových podniků mohou obsloužit zájemce o vydání ISIC karty na počkání, používají k tomu B2B online aplikaci 1

Např. pro Českou Republiku je to společnost GTS ALIVE s.r.o.

9

10

KAPITOLA 3. ÚVODNÍ STUDIE

CardMaster.NET2 a speciální tiskárnu štítků na karty3 . V aplikaci CardMaster vyplní osobní údaje držitele karty, vytisknou transparentní štítek s iniciály držitele a spolu s jeho fotkou jej nalepí na připravenou prázdnou kartu. Zásoby prázdných karet tato prodejní místa nakupují od své licenční autority nebo od IAS.

3.1.3

Střední školy

V zemích, kde licenční autority provozují svůj lokální IS pro evidenci a správu karet, je umožněno středním školám objednávat identifikační karty přímo v grafickém uživatelském rozhraní k NCDB. Pracovník školy v tomto systému zadá hromadnou objednávku nových karet, tu pak převezme licenční autorita, zpracuje ji a vytiskne karty, které poté pošle spolu s fakturou do školy.

3.1.4

Univerzitní karty

Organizace s větším počtem případných zájemců o mezinárodní identifikační průkazy ISIC jsou cílem dohod o nezávislé distribuci karet, která napomáhá jejich rozšíření. Typicky to bývají univerzity a vysoké školy, které pro své interní potřeby již používají nějaké identifikační studentské karty a je snadné tak zájemcům nabízet integrovaný průkaz ISIC spolu s povinnou identifikační kartou dané univerzity. Licenční autorita univerzitám poskytne sadu licenčních čísel, která mohou pro ISIC průkazy použít, a školy si karty již tisknou samy. Všechny takto vydané karty musejí univerzity exportovat do centrální databáze, příp. do lokální databáze karet licenční autority, která se o jejich předání do CCDB postará sama. Výhoda tohoto přístupu je zřejmá – studenti používají svoji ISIC kartu i pro účely jejich vzdělávací instituce a řada držitelů karet se tak úspěšně rozrůstá.

3.2 3.2.1

Rozbor evidence karet Identifikační karty ISIC

ISIC Association vydává vydává několik typů mezinárodních osobních průkazů, se kterými lze čerpat různé druhy benefitů. Jde o tyto karty: • ISIC - karty pro studenty denní formy studia. ISIC kartu může získat každý student SŠ, SOŠ, gymnázia, VŠ, VOŠ, nebo i vybraných pomaturitních jazykových kurzů a jednoletých studijních oborů. Horní věková hranice pro získání ISIC karty není stanovena, minimální věk držitele karty je 12 let (tato hranice se týká pouze studentů víceletých gymnázií). Tento typ karet je zdaleka nejrozšířenější, tvoří přibližně 95% podíl prodeje všech karet. • ITIC - karty pro pedagogy. Nárok na ITIC mají pedagogičtí a akademičtí pracovníci, kteří učí min. 15 hodin týdně na MŠ, ZŠ, SŠ, VOŠ nebo VŠ. Spodní ani horní věková hranice není stanovena. 2 3

zkráceně CM.NET, dostupná na https://www.isiccardmaster.net Používají se termotransferové tiskárny pro tisk na prázdné etikety

3.2. ROZBOR EVIDENCE KARET

11

Obrázek 3.1: Existující způsoby vydávání karet. Pravá část obrázku znázorňuje výdej karet v jedné zemi s licenční autoritou a lokální NCDB. Licenční autorita a univerzity posílají informace o vydaných kartách do lokální databáze NCDB, která je předává CCDB voláním webových služeb. V případě, že v dané zemi není žádný lokální systém pro správu karet zaveden, volají tito vydavatelé webové služby CCDB přímo.

12


• IYTC - mezinárodní karty mládeže. IYTC kartu může získat každý člověk, který ještě nedosáhl 26 let. Spodní věková hranice není stanovena. Kromě těchto třech hlavních druhů karet existují ještě další méně významné identifikační průkazy, se kterými mohou jejich držitelé rovněž využívat některých výhod: • SCHOLAR karty - podtyp ISIC karet určený pro žáky základních škol. • STAFF karty - identifikační zaměstnanecké karty určené pro větší společnosti. Všechny tyto identifikační průkazy tvoří množinu tzv. WYSETC karet, vzhledem k naprosté převaze ISIC karet nad ostatními typy ale bývají pojmem „ISIC karty“ souhrnně označovány všechny karty vydáváné ISIC Association. Karty obsahují tyto náležitosti: 1. celé jméno držitele karty, 2. datum narození držitele karty, 3. identifikační číslo karty (viz 3.2.1.1), 4. organizace, pod kterou držitel spadá (kromě IYTC karet): • • • •

ISIC a SCHOLAR karty - název školy, kterou student/žák navštěvuje, ITIC - název školy, ve které učitel učí, STAFF - název společnosti, ve které je držitel zaměstnán. IYTC - nemají tento parametr.

5. platnost karty (viz 3.2.1.2), 6. průkazová fotografie držitele, 7. ochranné prvky a loga. 3.2.1.1

Čísla karet

Každý identifikační průkaz musí mít nějaký unikátní identifikátor, který jej odlišuje od ostatních průkazů. V případě ISIC karet to jsou sériová čísla vytištěná na kartě pod fotkou jejího držitele. Jsou ve formátu: [typové písmeno][12ciferné licenční číslo][kontrolní písmeno] Prefix licenčních čísel odpovídá mezinárodnímu telefonickému předčíslí pro zemi, ve které je karta vydána, číslo české karty tak může vypadat např.: S 420 123 456 789 H. Typová písmena jsou dána druhem karty (ISIC - S, ITIC - T, IYTC - Y, SCHOLAR - H, STAFF - E) a kontrolní písmena jsou vypočítána z licenčního čísla pomocí tajného kontrolního algoritmu, aby se zmenšilo riziko padělání karet. Princip kontrolního písmene byl zaveden dodatečně, existují starší karty, jejichž čísla toto písmeno neobsahují. V současných datech je navíc mnoho karet, které nemají ani typové písmeno a nelze u nich ani spolehlivě určit, jakého jsou druhu. Více o problémech současné CCDB je psáno v kapitole 4.1.1.6.

3.2. ROZBOR EVIDENCE KARET

3.2.1.2

13

Platnost karet

Platnost karty je časové období, po které je karta platná a je možné na ni využívat výhody u obchodníků. Vzhledem k provázanosti se školním systémem je platnost odvozena od školního/akademického roku (neplatí pro IYTC a STAFF karty). Jelikož se v tomto ohledu jednotlivé země světa liší, není období platnosti jednotně stanoveno. Např. pro Českou Republiku začíná platnost ISIC a ITIC karet v září a končí až na konci prosince dalšího kalendářního roku, tj. celkem 16 měsíců. Platnost IYTC a STAFF karet je standardně omezena na 13 měsíců (od začátku aktuálního měsíce do konce stejného měsíce v příštím roce). Pro ušetření nákladů a zjednodušení procesu vydávání karet se pro prodlužování platností karet používají tzv. revalidační známky. Držitel karty, které platnost brzy končí nebo již skončila, může platnost své karty prodloužit na další akademický rok zakoupením známky, která se lepí na zadní stranu ISIC karet. Tímto způsobem je zajištěno, že lidé nemusejí každý rok žádat o vydání nové karty, stačí si objednat její prodloužení u svého vydavatele karet (viz kapitola 3.2.2), pokud mají na prodloužení platnosti karty právo, tj. pokud nepominuly podmínky, které držitel karty musí splňovat pro její získání. Prodloužení platnosti karty pomocí revalidační známky se do centrální databáze promítne pouze tak, že je upravena platnost karty na nové období. Na kartách je platnost uvedena s přesností na měsíce, tedy např. „09/10 - 12/11“ – taková karta je platná od začátku září roku 2010 do konce prosince roku 2011. V centrální databázi jsou data vydání a expirace specifikována přesným datem. Mnoho partnerů poskytuje slevy držitelům ISIC karet pouze na základě elektronického ověření platnosti karty. Pro tyto verifikace karet je používána webová služba CCDB, která ověří kartu podle jejího identifikačního čísla a porovnává datum expirace karty s aktuálním datem.

3.2.2

Vydavatelé karet

Pojmem vydavatel karet (Card Issuer) je označována společnost, která zajišťuje fyzický tisk karet a jejich distribuci svým držitelům. Tyto subjekty pak mají povinnost posílat informace o vydaných kartách do centrální databáze. Z pohledu CCDB jsou tak vydavateli všichni, kdo do centrální databáze posílají nové karty. Nejčastěji to bývají licenční autority, které mohou např. přijímat objednávky na karty online, či je prodávat v jedné ze svých kamenných poboček. Mohou to ale být i univerzity, které se o tisk svých kombinovaných studenstkých průkazů starají samy. V případě, že univerzity posílají data nejprve do lokální databáze karet (NCDB) spravované licenční autoritou pro danou zemi, je pro CCDB vydavatelem takových karet ona licenční autorita, která údaje předává do CCDB. Vydavatelé karet musejí mít vytvořen účet v CCDB, aby mohli volat zabezpečené webové služby pro vytváření a aktualizaci karet.

3.2.3

Rozsahy licenčních čísel

Aby nedocházelo ke konfliktům identifikačních čísel na kartách, je každému vydavateli přidělen rozsah licenčních čísel, ze kterého smí používat čísla pro své karty. Tyto rozsahy

14


rozděluje organizace IAS mezi jednotlivé vydavatele, kteří jsou zodpovědni za jejich další dělení a využívání. Vydavatelé nakupují rozsahy licencí od IAS a dostávají od nich prázdné plastové karty se standardizovaným grafickým potiskem, na které tisknou údaje o držitelích přímo na speciálních tiskárnách – včetně čísla karty a fotografie studenta. Anebo dostanou karty s již předtištěným číslem a tisknou pouze štítky s údaji o držiteli, které na kartu nalepují spolu s jeho fotografií.

3.3

Současný stav

Za dobu 50leté historie vydávání karet společností ISIC Association byla podpora firemních procesů ze strany informačních technologií značně podceňována. Karty jsou vydávány mnoha institucemi po celém světě, jejichž úroveň počítačové vyspělosti je různá. Některé vydané karty se evidují ručně v XLS souborech a jiné v centrální databázi, která je zastaralá a obsahuje z velké části chybná a nekonzistentní data. Správa rozsahů licenčních čísel je realizována dosti chaoticky, některé rozsahy jsou rovněž evidovány v XLS souborech, jiné pak v samostatné aplikaci, ze které jsou exportovány do centrální databáze karet. Toto činí z vytváření a přidělování dávek karet proces značně neprůhledný a komplikovaný, při kterém se nelze vyvarovat chyb (např. překrývající se rozsahy). IT prostředí společnosti IAS prošlo v nedávné době značnou obměnou, zastaralé informační systémy byly nahrazeny novými a byla vytvořena poměrně komplexní struktura vzájemně komunikujících aplikací – IAS Platforma. Nejdůležitější prvek této platformy je právě centrální databáze karet, jejíž přestavba dostala nižší prioritu než většina ostatních částí platformy, přestože je tento systém v nevyhovujícícm stavu a je nadále neudržovatelný. Důvodem je relativní funkčnost evidence, kterou IAS považovala dlouhou dobu za dostačující. Dalším možným důvodem pro odložení reformy CCDB do pozdější fáze mohl být fakt, že společnost IAS nechtěla svěřit tuto zásadní akci do rukou svého nového a jimi dosud neprověřeného IT dodavatele. Stávající systém pro evidenci WYSETC karet je tvořen instancí databáze Microsoft SQL Server a implementací strojového rozhraní (webové služby) v jazyce C#. Pro CCDB nebylo vytvořeno žádné administrační grafické rozhraní, ve kterém by uživatelé mohli nahlížet do evidence karet a případně provádět nějaké modifikace dat. K implementovaným webovým službám existuje pouze webové rozhraní, kde je možné jednotlivé služby volat vyplněním údajů do formulářů a jejich odesláním. Odpovědi webových služeb jsou poté nabídnuty uživateli v podobě dat v XML formátu, což je vhodné pouze pro nějaké další zpracování, za plnohodnotné rozhraní k datům to rozhodně nelze považovat. Toto webové rozhraní je proto většinou využíváno jen k testovacím účelům. Podrobná analýza současného systému pro správu ISIC karet je popsána v kapitole 4.1.

3.4

Deklarace záměru

Nový informační systém pro správu mezinárodních studentských identifikačních karet (dále jen CCDB2) bude klíčovým prvkem v IT infrastruktuře organizace IAS. Hlavním úkolem je spolehlivá evidence všech vydaných ISIC karet z celého světa, která zavede pevná pravidla týkající se správného formátu a konzistence dat.

3.5. ROZBOR A DEFINICE POŽADAVKŮ

15

CCDB2 poskytne strojové rozhraní pro vytváření nových karet a aktualizaci již vydaných karet ve stejné podobě, v jaké je implementováno v současné aplikaci – webové služby. Toto rozhraní je hojně využíváno externími systémy v jednotlivích zemích světa a představuje základní způsob, kterým se vydané karty dostávají do centrální evidence. Vedle tohoto strojového rozhraní bude zprovozněno také grafické uživatelské rozhraní pro jednoduché prohlížení a správu evidovaných dat. Uživatelé budou moci ovládat toto rozhraní přes webový prohlížeč, je požadováno, aby bylo funkční ve všech hlavních prohlížečích. V CCDB2 bude zavedena podpora pro správu rozsahů licenčních čísel karet, které představují obchodní artikl prodávaný jednotlivým vydavatelům. Rovněž bude implementována funkcionalita Track & Trace – sledování stavů a pohybů karet, resp. rozsahů karet. Systém dále umožní ověřovat platnost karet a zajistí, že všechny provedené operace budou dohledatelné pro účely případného auditu. Nový systém bude začleněn do existující platformy informačních systémů, které dohromady slouží pro řízení obchodu s kartami a správu k nim se vážících výhod. CCDB2 zároveň implementuje podporu pro integraci nově vyvíjené aplikace online vydávání karet, která v budoucnu nahradí aplikaci CardMaster.NET (viz. 3.1.2). V neposlední řadě je nutné navrhnout plán přechodu na nový systém a zrealizovat migraci stávajících dat z databáze starého systému do databáze CCDB2, nový systém tak musí umožnit evidovat zastaralé karty, u nichž jsou např. údaje nekompletní nebo ve špatném formátu. Zpětná kompatibilita je cíl, na který je kladen veliký důraz s ohledem na důležitost a nepostradatelnost existujících dat.

3.5

Rozbor a definice požadavků

Hlavním úkolem informačního systému pro správu studentských karet je evidovat data všech existujících karet a jejich držitelů. Jelikož jsou karty fyzicky vydávány několika organizacemi po celém světě (viz kapitola 3.1), je nutné mít jednu centrální databázi, která figuruje jako autoritativní úložiště dat a která shromažďuje údaje o vydaných kartách v jednotlivích zemích. Bez takové centrální databáze by organizace IAS jen stěží mohla řídit obchod se studentskými kartami a držitelé benefitních karet by nemohli spoléhat na globální využitelnost slev u obchodníků po celém světě.

3.5.1

Uživatelské role

Aplikaci CCDB2 budou přímo využívat uživatelé těchto základních rolí: • Administrátoři – zaměstnanci organizace IAS. Tito uživatelé budou mít neomezený přístup k datům všech karet, která mohou libovolně editovat. Zároveň jim bude poskytnuto rozhraní pro správu rozsahů licenčních čísel. • Vydavatelé karet – uživatelům vydavatelů bude umožněno v evidenci vytvářet a aktualizovat záznamy o jimi vydaných kartách. • Poskytovatelé výhod – pro uživatele nasmlouvaných partnerů bude k dispozici rozhraní pro ověřování platnosti karet.

16


• Výrobci karet – výrobci karet budou moci evidovat jednoduché záznamy pro sledování stavů a pohybů vyrobených karet. Práva jednotlivých uživatelů budou přidělována s jemnější granularitou tak, aby např. jen někteří administrátoři mohli libovolně vytvářet rozsahy licenčních čísel, zatímco jiní budou mít pouze read-only přístup do evidence rozsahů. Autentizace a autorizace uživatelů bude zaintegrována do existujícího systému OM4 , pomocí nějž jsou spravovány všechny organizace a jejich uživatelé, které jsou jakýmkoliv způsobem zainteresované v obchodních aktivitách kolem ISIC karet.

3.5.2 3.5.2.1

Funkční požadavky Správa karet

Nejzásadnější funkčností CCDB2 je evidence vydaných ISIC průkazů. U každé karty je požadováno evidovat tyto parametry: • číslo karty (viz 3.2.1.1), • typ karty, • osobní údaje držitele karty (jméno, příjemní, datum narození, e-mail), • platnost karty (viz 3.2.1.2), • název instituce, pod kterou držitel karty patří (např. název školy), • vydavatel, který kartu vydal, • datum vydání karty. Vytvoření nové karty a aktualizace existujícího záznamu bude možné provést dvojím způsobem: 1. voláním webové služby (viz 4.1.2), 2. hromadným vytvořením/aktualizací karet z XLS souboru. Identifikační čísla karet musejí být v předepsaném formátu a musejí být unikátní, tj. existence duplicitních karet není přípustná. Vydavatelé smějí vytvořit kartu jen s takovým sériovým číslem, které patří do jejich rozsahu licenčních čísel, tj. do rozsahu, jenž jim byl přiřazen organizací IAS. Tímto bude zabráněno, aby si vydavatelé mezi sebou „kradli“ ISIC licence. Aktualizovat karty mohou vydavatelé pouze ty, které sami vydali, je nutné zabránit modifikacím údajů cizích karet. Administrátoři IAS mohou vytvářet a editovat libovolné karty za předpokladu, že tím neporuší konzistenci dat. Navíc jim bude umožněno zrušit karty, které byly chybně vydány a které jsou znehodnoceny, tj. jejich identifikační čísla již nelze použít pro jiné karty. Prohlížení evidovaných karet bude realizováno pomocí stránkované a seřaditelné tabulky. Filtrovat záznamy bude možné podle: 4

Organization Manager, prvek IAS platformy pro správu organizací, jejich uživatelů a kontaktů


17

• jména držitele karty, • čísla karty, • vydavatele karty (pouze pro administrátory IAS), • instituce – školy, • data vydání, • data expirace. Z této tabulky bude možné přejít na detail karty, kde budou zobrazeny všechny dostupné informace o kartě. Zavedena bude podpora tzv. dočasných karet. Jelikož bude v budoucnu implementován systém pro online objednávání karet (pracovní název je OO – Online Ordering), byl definován požadavek na podporu dočasných karet, které budou držitelům vystaveny do doby, než si převezmou fyzickou kartu. Tyto dočasné karty budou pouze virtuální, po vytvoření objednávky na novou kartu obdrží zákazník unikátní číslo virtuální karty, které bude moci použít pro okamžité čerpání výhod, aniž by čekal na vydání skutečné karty. 3.5.2.2

Správa rozsahů

V CCDB2 bude implementováno uživatelské rozhraní pro správu rozsahů licenčních čísel, která odstraní nedostatky současného způsobu evidování alokovaných čísel karet. Tato funkčnost bude dostupná pouze pro administrátory systému (zaměstnance IAS) a umožní jim provádět standardní CRUD5 operace nad rozsahy. Evidence rozsahů bude rovněž použita pro kontrolu konzistence dat tak, aby nedocházelo k neoprávněnému vydávání karet s nesprávnými sériovými čísly. Požadavky na evidenci rozsahů: • rozsahy jsou zadány počátečním a koncovým licenčním číslem, • každý rozsah obsahuje karty pouze jednoho druhu, • rozsahy se nesmějí překrývat – každé licenční číslo může patřit pouze do jednoho rozsahu čísel, • minimální velikost rozsahu je jedna karta, • každý rozsah je přidělen vydavateli, který jej smí využívat, • všechny karty mající čísla z daného rozsahu musí patřit stejnému vydavateli jako tento rozsah, • rozmezí licenčních čísel v rozsahu lze upravit, nesmí však při tom být porušeny předchozí podmínky. 5

Create, Read, Update, Delete – vytváření, prohlížení, editace a mazání rozsahů čísel

18


Při vytváření nového rozsahu bude umožněno zadat jen jeho velikost místo intervalu čísel, v takovém případě se systém pokusí vytvořit rozsah navazující na posledně přidělený rozsah stejnému vydavateli. K prohlížení existujících rozsahů bude použita stránkovaná a seřaditelná tabulka. Filtrovat seznam rozsahů bude možné podle: • vydavatele – majitele rozsahu, • typu karet v rozsahu, • licenčního čísla omezující nalezené rozsahy zdola, • licenčního čísla omezující nalezené rozsahy shora, • licenčního čísla obsaženého v rozsahu. 3.5.2.3

Verifikace karet

Pojmem verifikace karet rozumíme ověřování platnosti karty podle jejího sériového čísla. Kromě ověřování platnosti standardních WYSETC karet umožňuje současná verifikační webová služba (viz 4.1.2.2) také ověřovat platnost CJP a NUS karet. Tyto karty nejsou vydávány společností ISIC Association, jsou to speciální benefitní karty mládeže v Holandsku a Velké Británii. Nejsou evidovány v centrální databázi ISIC karet, organizace IAS jen začlenila jejich verifikaci do systému ověřování ISIC karet ve formě volání externích webových služeb. Stejným způsobem bude i nová CCDB2 podporovat verifikaci CJP a NUS karet. 3.5.2.4

Track & Trace

Pro sledování aktuálního stavu a pohybu vyrobených dávek karet bude zpřístupněno rozhraní Track & Trace, které budou moci používat kromě administrátorů také uživatelé výrobců karet6 . Tato funkcionalita bude spočívat v evidenci jednoduchých záznamů o provedených operacích s dávkami karet nebo o změně jejich stavu. Každý takový záznam (událost) bude obsahovat: • referenci na rozsah čísel, kterého se událost týká, • datum a čas události, • titulek události, • volitelný detailnější popis události. Při vytváření nové události musí uživatel nejprve vybrat konkrétní rozsah licenčních čísel, ke kterému se událost váže, a poté vyplnit požadované atributy. Seznam událostí k jednotlivým rozsahům bude zobrazen v přehledné seřaditelné tabulce. Existující události bude možné také editovat či smazat. 6

Výrobci karet jsou společnosti, kterým IAS zadává objednávky na výrobu prázdných karet v zadaném rozsahu licenčních čísel.


3.5.2.5

19

Synchronizace s CardMaster.NET

Aplikace CardMaster.NET (více v kapitole 3.1.2) disponuje svou vlastní databází karet, do níž ukládá karty, které uživatelé této aplikace prodají klientům na přepážkách svých prodejních míst. Tyto karty je nutné pravidelně importovat do CCDB2, aby byly centrálně zaevidované a pro své držitele použitelné. Synchronizace bude docíleno opakovaným a dostatečně častým voláním webové služby, kterou CardMaster.NET poskytuje pro získání dat vydaných karet. 3.5.2.6

Migrace dat

Pro úspěšný přechod ze starého systému na nový je nutné přenést existující data do nové prázdné databáze. Tato operace se obejde bez uživatelské interakce, je nutné ji provést pouze jednou před spuštěním nového IS do provozu. Cílem je zmigrovat co největší možný počet evidovaných karet a rozsahů. Vzhledem ke stavu dat v CCDB je předpokládáno, že některé záznamy nebude možné vytvořit v CCDB2 díky jejich neúplnosti, příp. díky špatnému formátu evidovaných parametrů. Zákazníkem je požadováno, aby během migrace dat průběžně vznikal zápis ve formě log souboru, který bude obsahovat veškeré informace o neúspěšně přenesených datech a informace o dodatečných operacích, které musely být v rámci migrace provedeny (např. vytvoření rozsahu čísel pro kartu, která do žádného rozsahu nepatří). Po skončení migrace je také nutné předložit statistiku zmigrovaných dat. 3.5.2.7

Obecné požadavky na funkčnost

Karty, rozsahy čísel i události bude možné z evidence odstranit. Nebude však docházet k fyzickému odstranění údajů z databáze, pouze se záznamy označí za smazané a budou tak v případě potřeby stále dohledatelné. Takto smazané objekty budou pro uživatelské i strojové rozhraní neviditelné. Veškeré provedené operace budou zaznamenány, aby mohly být na žádost vystopovány a pracovníkům IAS poskytnuty informace o realizovaných změnách v evidenci. K takovým požadavkům bude docházet pouze v ojedinělých případech, kdy je nutné řešit nějaký provozní incident. Pro tyto účely postačí zapisovat informace o prováděných operacích do vyhrazeného logovacího souboru. Výjimkou je ověřování platnosti karet, u nějž lze předpokládat, že bude v budoucnu implementováno uživatelské rozhraní pro náhled do záznamů provedených verifikací. Proto budou všechna vyžádaná ověření karet zaznamenána přímo v databázi CCDB2. Rozhraní veřejných webových služeb (podrobněji v kapitorle 4.1.2) musí zůstat nezměněná, aby tyto webové služby byly kompatibilní s formátem, v jakém vydavatelé posílají nové požadavky do centrální databáze. Kdyby došlo k nějaké změně na veřejném rozhraní, mohlo by to způsobit problémy vydavatelům po celém světě a tím značné ztráty organizaci IAS.

3.5.3

Nefunkční požadavky

Základní nefunkční požadavky nového IS pro evidenci ISIC karet jsou:

20


• data budou uložena v relační databázi (bude použita ověřená open-source relační databáze PostgreSQL), • serverová část aplikace bude implementována na platformě J2EE, pro provoz je vyžadováno, aby na serveru bylo nainstalováno běhové prostředí Java verze 6 od společnosti Sun Microsystems (resp. Oracle), • uživatelské rozhraní bude realizováno formou webové aplikace, která bude funkční ve všech hlavních internetových prohlížečích. Nebude tak nutné instalovat žádný software na klientské stanici, uživatelé musejí mít pouze ve svém prohlížeči povolený Javascript a cookies, • webové služby s veřejným rozhraním budou pro posílání zpráv používat protokol SOAP, o přenos takto strukturovaných požadavků a odpovědí se postará protokol HTTP, • uživatelské rozhraní nebude svázáno se serverovou částí aplikace, bude implementováno jako samostatná aplikace, která s centrální databází komunikuje pomocí REST webových služeb. Tímto bude umožněno ostatním aplikacím IAS platformy využívat prostředků centrální databáze karet a v budoucnu realizovat jednotné administrační rozhraní pro všechny systémy z této platformy, • nástroj pro migraci dat bude implementován v jazyce Java jako konzolová aplikace bez uživatelského rozhraní.

3.6

Případy užití nejvyšší úrovně

Na základě definovaných funkčních požadavků byly identifikovány případy užití, které bude systém pro správu ISIC karet podporovat. Jsou zachyceny ve vizuální podobě diagramem případů užití (Use Case diagram) na obr. 3.2. Detailní popis jednotlivých případů užití se nachází v kapitole Popis případů užití.

3.7

Návrh architektury

Aplikace CCDB2 bude modulárně strukturována tak, aby byla důsledně oddělena datová vrstva, business logika aplikace a uživatelské rozhraní pro interakci s aplikací. Jednotlivé komponenty jsou znázorněny na diagramu komponent, obr. 3.3. Rozmístění modulů systému na hardwarových zdrojích zachycuje diagram nasazení na obr. 3.4. Následuje popis komponent, které tvoří informační systém pro správu ISIC karet. CCDB databáze Data jsou uchována v relační databázi a přístup k nim je umožněn přes JDBC API pouze z komponenty CCDB Core. CCDB Core Představuje aplikační vrstvu systému. Obsahuje business logiku pro správu jednotlivých entit a ověřování platností karet. Zároveň se stará o autentizaci a autorizaci uživatelů a zajišťuje synchronizaci s CardMaster.NET.

3.7. NÁVRH ARCHITEKTURY

21

Obrázek 3.2: Případy užití nejvyšší úrovně

CCDB REST WS Komponenta zpřístupňující webové služby s REST rozhraním. Tyto služby jsou pouze privátní, jsou určeny pouze pro ostatní komponenty IAS platformy.

CCDB SOAP WS Komponenta zpřístupňující webové služby se SOAP rozhraním. Tyto služby jsou veřejné, mohou je volat např. informační systémy vydavatelů karet či poskytovatelů výhod.

CCDB Administrační UI Webové uživatelské rozhraní využívající pro komunikaci s aplikační vrstvou CCDB webové služby (REST i SOAP).

Organization Manager Existující komponenta IAS platformy, která poskytuje rozhraní pro autentizaci uživatelů jednotlivých organizací.

22


Obrázek 3.3: Diagram komponent

CardMaster.NET Existující systém, jehož webovou službu volá komponenta CCDB Core pro synchronizaci databází karet.

3.8

Analýza rizik

Realizace informačního systému pro správu mezinárodních studentských karet s sebou nese celou řadu rizik, které je nutné identifikovat, ohodnotit závažnost a pravděpodobnost výskytu a navrhnout opatření, kterými bude předcházeno vzniku daného problému. Hodnocení závažnosti rizika je provedeno stanovením míry dopadu na úspěšnost projektu, dopad může být: 1. zanedbatelný, 2. marginální, 3. kritický, 4. katastrofický.

3.8. ANALÝZA RIZIK

23

Obrázek 3.4: Diagram nasazení

24


Přehled rizik spojených s realizací projektu je uveden v následující tabulce, ve sloupci P. výskytu je uvedena procentuální pravděpodobnost výskytu rizika. Riziko

Kategorie

P. výskytu

Dopad

Špatný odhad velikosti projektu Chybná analýza Změna požadavků HW nebo SW nekompatibilita Vada na HW nebo SW při vývoji Nedostatečná znalost technologií Odklon od požadavků Neoprávněný přístup k datům

procesní procesní procesní technologická technologická implementační implementační bezpečnostní

30% 10% 5% 1% 5% 15% 3% 4%

kritický katastrofální kritický kritický marginální marginální kritický kritický

3.8.1

Špatný odhad velikosti projektu

Odhad velikosti a náročnosti projektu vychází z požadavků definovaných zákazníkem, následné analýzy a použitých technologií. V případě, že by se odhad náročnosti ukázal jako podhodnocený, byl by značně ohrožen termín odevzdání. Je proto nutné analýzu provést důkladně a do odhadu velikosti projektu započítat patřičné časové rezervy. Přestože jsem s většinou technologií plánovaných k použití již obeznámen, mnoho zkušeností s odhadováním náročností projektů nemám, a tudíž považuji toto riziko za vysoké. Řešitel problémů: realizátor Pravděpodobnost výskytu: Dopad:

3.8.2

30%

kritický

Chybná analýza

Současná centrální databáze karet není nikterak zdokumentována a zaměstnanci organizace IAS sami nevědí, jak jsou některé funkčnosti realizované. Rovněž data v databázi CCDB jsou z velké části chybná a nekompletní, obsahují údaje, o kterých nikdo neví, co znamenají. Jestliže analýza současné CCDB nebude provedena správně, je pravděpodobné, že vyvstanou problémy při migraci dat z CCDB do CCDB2, nebo se přechodem na CCDB2 poruší zpětná kompatibilita veřejných rozhraní. Analýza je tak zcela zásadní částí řešení, kterou je nutné provést obvzlášť pečlivě. Výsledky analýzy musí být pravidelně konzultovány se zákazníkem, aby se nesrovnalosti odhalily co nejdříve. Řešitel problémů: realizátor, zákazník Pravděpodobnost výskytu:

10%

3.8. ANALÝZA RIZIK

Dopad:

3.8.3

25

katastrofální

Změna požadavků

Snad neexistuje projekt, u kterého by v průběhu jeho realizace nedocházelo ke změnám požadavků. Zákazníci při definování požadavků na informační systém mnohdy na počátku přesně nevědí, co sami chtějí. Pravidelnou komunikací se zákazníkem a diskutováním stavu projektu bude předcházeno změnám v zadání. Jestliže zákazník přesto definuje nový požadavek na funkčnost, bude realizován v pozdější fázi jako změnový požadavek nad rámec dohodnutého rozsahu projektu a neohrozí tak termín dodání. Pokud by zákazník přišel s novým požadavkem natolik zásadním, že bez něj nelze implementovat správnou funkčnost systému, bude nutné jej včlenit do současného harmonogramu projektu. Toto nicméně považuji za málo pravděpodobnou situaci. Řešitel problémů: realizátor, zákazník Pravděpodobnost výskytu: Dopad:

3.8.4

5%

kritický

HW nebo SW nekompatibilita

Systém CCDB2 bude z velké části implementován s použitím prověřených technologií, které již byly použity pro jiné prvky IAS platformy. HW zdroje, které budou pro CCDB2 využity, jsou spravovány organizací IAS a neměl by tak být problém s doinstalováním potřebných verzí softwarového vybavení. Veškeré SW součásti nutné pro provoz CCDB2 jsou zdarma dostupné pro různé platformy. Systém CCDB2 není závislý na použitém operačním systému, hardwarové nároky odpovídají současným standardům pro běh podobných IS. Z tohoto pohledu považuji tyto problémy za velmi nepravděpodobné. Řešitel problémů: realizátor, zákazník Pravděpodobnost výskytu: Dopad:

3.8.5

1%

kritický

Vada na HW nebo SW při vývoji

Spolehlivost hardware není stoprocentní, životnost strojů není neomezená. Proto je nutné počítat s tím, že v průběhu realizace projektu může dojít k technickým problémům, které práci zpomalí či dokonce zastaví. Dopad těchto problémů minimalizuji centralizovanou správou zdrojových kódů aplikace a používáním ověřených softwarových produktů pro vývoj aplikace. V záloze mám rovněž připraven náhradní notebook, který lze okamžitě použít pro práci na projektu.

26


Řešitel problémů: realizátor Pravděpodobnost výskytu: Dopad:

3.8.6

5%

marginální

Nedostatečná znalost technologií

Toto riziko výrazně ovlivňuje rychlost vývoje a řešení případných problémů. Pro implementaci byly vybrány pouze technologie, se kterými již mám nějaké zkušenosti. Výjimku tvoří pouze Vaadin framework (viz kapitola 2.5), na jehož studium jsem si vyhradil více času. K minimalizaci dopadu tohoto rizika přispívá také fakt, že veškeré použité technologie jsou dobře zdokumentovány. Řešitel problémů: realizátor Pravděpodobnost výskytu: Dopad:

3.8.7

15%

marginální

Odklon od požadavků

Požadavky zákazníka na nový informační systém byly jasně definovány, nelze ale vyloučit, že dojde k chybě v implementaci. Navíc je toto riziko ovlivněno také potenciálním nedorozuměním při komunikaci se zákazníkem – komunikace probíhala v anglickém jazyce, což není mateřský jazyk ani můj, ani zákazníka. Případné vzdálení se od požadavků musí být odhaleno během testování systému. Řešitel problémů: realizátor, zákazník Pravděpodobnost výskytu: Dopad:

3.8.8

3%

kritický

Neoprávněný přístup k datům

Informace o držitelích karet spravované systémem CCDB2 mají charakter osobních údajů, které by mohly být zneužity nepovolanou osobou. Proto je potřeba zabezpečit všechny operace pracující s daty tak, aby je mohl provádět pouze uživatel, který k tomu má oprávnění. Autentizaci uživatelů a autorizaci prováděných operací je proto nutné věnovat více než přiměřenou pozornost. Řešitel problémů: realizátor

3.9. SLOVNÍK POJMŮ

27

Pravděpodobnost výskytu: Dopad:

3.9

4%

kritický

Slovník pojmů

Pojmy používané v textu práce jsou pro přehlednost shrnuty v následující tabulce.

Termín WYSETC IAS

ISIC ITIC IYTC SCHOLAR STAFF WYSETC karty

Licenční autorita

CCDB CCDB2 NCDB CardMaster.NET identifikační číslo karty sériové číslo karty licenční číslo karty

Význam World Youth Student and Educational Travel Confederation, nezisková organizace vlastnící ISIC licence. International Association Services, dceřiná společnost WYSETC založena za účelem řízení distribuce průkazů ISIC. International Student Identity Card, mezinárodní studentská identifikační karta. International Teacher Identity Card, mezinárodní identifikační karta pro učitele. International Youth Travel Card, mezinárodní identifikační karta pro mládež do 26 let. Identifikační karta pro žáky základních škol. Zaměstnanecká identifikační karta. Všechny identifikační karty vydávané ISIC Association s licencí patřící společnosti WYSETC, také označovány jen jako „ISIC karty“. Společnost, která je na základě licenční smlouvy s IAS držitelem práv pro distribuci, vydávání, propagaci a rozvoj mezinárodních studentských průkazů ISIC pro území jedné země. Central Card Database, centrální databáze WYSETC karet spravovaná společností IAS. Nový IT systém pro evidenci a správu WYSETC karet, který nahrazuje původní CCDB. National Card Database, lokální databáze karet spravovaná licenční autoritou v jedné konkrétní zemi. B2B aplikace pro vydávání karet na prodejních místech u nasmlouvaných partnerů. Číslo karty ve formátu S 420 123 456 789 H. Viz. identifikační číslo karty. Číselná část sériového čísla karty, tj. 12ciferné číslo začínající mezinárodním telefonickým předčíslím země, ve které byla karta vydána.

28


revalidační známka vydavatel karet

rozsah čísel

Známka, která se lepí na zadní stranu identifikačních karet pro prodloužení jejich platnosti. Společnost, která vydává karty (na kartu tiskne údaje o jejím držiteli) a komunikuje s CCDB. Většinou to bývají licenční autority. Interval licenčních čísel karet, který je poskytován vydavatelům karet.

Kapitola 4

Analýza a návrh řešení 4.1

Analýza současného systému

Pro pochopení struktury a významu existujících dat je nutná detailní analýza současné centrální databáze karet – CCDB. Na základě zjištěných vlastností a problémů bude možné navrhnout strukturu nové databáze a proces migrace dat.

4.1.1

Existující data

Veškerá data, se kterými CCDB operuje, jsou v současnosti evidována v relačním databázovém systému MS SQL Server 2008. Databáze CCDB obsahuje 21 relací, ty s důležitými daty, které je nutné brát v úvahu, jsou detailně zanalyzovány níže. V celé databázi neexistuje jediný cizí klíč, referenční integrita byla pro autory původní CCDB zřejmě podřadnou vlastností databázových systémů. 4.1.1.1

Tabulka SerialNumbers

V této tabulce jsou evidovány rozsahy licenčních čísel, které jsou zadány počátečním a koncovým číslem. Počet záznamů: Primární klíč: Atribut CompanyID

48579 (OrderNr, LineNrID, LineNr) Datový typ varchar(10)

Význam, vlastnosti a četnosti hodnot identifikátor vydavatele, kterému je rozsah přidělen → 0 × null → 262 × prázdný řetězec → 215 unikátních hodnot, všechny mají délku 7 znaků, formát Rxxxxxx, kde xxxxxx jsou číslice

29

30

KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ

FirstNo

varchar(12)

LastNo

varchar(12)

FirstSerialNo

varchar(20)

LastSerialNo

varchar(20)

EntryDate

datetime

RangeID

varchar(25)

companyName OrgID OrderNr LineNrID LineNr ItemNo Description Qty

varchar(30) varchar(20) varchar(20) int int varchar(20) varchar(30) decimal(10,2)

CardType

varchar(1)

IsExpired Expired Status HasCheckLetter

tinyint tinyint tinyint tinyint

počáteční licenční číslo rozsahu → 0 × null → všechny hodnoty mají formát 12ciferného čísla koncové licenční číslo rozsahu → 0 × null → všechny hodnoty mají formát 12ciferného čísla zformátované počáteční licenční číslo rozsahu → 0 × null → všechny hodnoty mají 16 znaků a začínají typovým písmenem karet → např. ’S700 100.200.300’ zformátované koncové licenční číslo rozsahu → 0 × null → všechny hodnoty mají délku 16 znaků a začínají typovým písmenem karet → např. ’S700 100.200.399’ datum a čas vytvoření rozsahu → 0 × null identifikátor rozsahu v původní aplikaci pro správu rozsahů → 0 × null → všechny hodnoty mají délku 25 znaků → např. ’ISIC01003-0010000-0010000’ obsahuje pouze null hodnoty obsahuje pouze null hodnoty význam neznámý význam neznámý význam neznámý význam neznámý textový popis rozsahu velikost rozsahu → duplicitní informace, lze zjistit z FirstNo a LastNo typ karet v rozsahu → 312 × null → obsahuje hodnoty ’S’, ’T’, ’Y’, ’H’, ’E’ příznak určující, zda je rozsah zastaralý příznak určující, zda je rozsah zastaralý obsahuje pouze null hodnoty příznak určující, zda čísla karet z rozsahu mají kontrolní písmena → obsahuje pouze hodnoty 0

4.1. ANALÝZA SOUČASNÉHO SYSTÉMU

31

Zjištěné vztahy a statistiky: • Hodnoty sloupce CompanyID obsahují textový identifikátor organizace, podle kterého ji lze ve většině případů najít v systému OM. • Pro všechny záznamy platí, že FirstNo ≤ LastNo. • 40042 záznamů reprezentuje rozsah velikosti 1, kdy FirstNo = LastNo. • Žádné dva záznamy se svými čísly nepřekrývají. • Pro všechny záznamy, kde CardType není null, platí, že první písmeno FirstSerialNo = první písmeno LastSerialNo = CardType. 4.1.1.2

Tabulka CardsIssued

Tato tabulka obsahuje ty nejdůležitější informace – data vydaných karet a jejich držitelů. Počet záznamů:

10013408

Primární klíč:

CardNumber

Atribut CardNumber

Datový typ char(12)

CardType

char(1)

CardName

varchar(30)

Význam, vlastnosti a četnosti hodnot licenční číslo karty → 0 × null → 1 × prázdný řetězec → 1 × 7ciferné číslo → 92 × 9ciferné číslo → 15 × 11ciferné číslo → ostatní hodnoty jsou 12ciferná čísla → všechny hodnoty jsou unikátní typ karty (typové písmeno) → 5215642 × null → 427 × ’E’ → 3648 × ’H’ → 130778 × ’T’ → 306497 × ’Y’ → 4356413 × ’S’ celé jméno držitele karty tak, jak je natisknuto na kartě → 5 × null → 75466 × prázdný řetězec → 1260837 × ’-’ → 1337523 × hodnota o maximálně dvou znacích

32


StudiesAt

varchar(30)

DOB

smalldatetime

DateOfBirth

char(10)

EXP

smalldatetime

ExpireDate

char(10)

IssuedBy

char(10)

RangeID

char(25)

OrgID

char(4)

IssGID

char(9)

Status

varchar(5)

IssueDate

smalldatetime

Remark

varchar(50)

název školy, na které je držitel studentem/učitelem → 6 × null → 74184 × prázdný řetězec → 1666462 × ’-’ → 1764702 × hodnota o maximálně dvou znacích datum narození držitele → 19 × null → 2946751 × 1.1.1900 zformátované datum narození držitele → 19 × null → 75428 × prázdný řetězec → když je hodnota vyplněna, duplikuje informaci v DOB → formát data není homogenní (někdy yyyy-MM-dd, jindy dd/MM/yyyy) datum expirace karty → 13 × null datum expirace ve formátu dd/MM/yyyy → hodnoty duplikují informaci v EXP název vydavatele karty → 43 × null → 85269 × prázdný řetězec → 5647692 × ’-’ identifikátor rozsahu, do kterého karta patří → 0 × null → 0 × prázdný řetězec → většina hodnot (> 8 mil.) je 25 znakovový identifikátor používaný ve starém systému pro správu rozsahů identifikátor vydavatele karty v OM → 4116259 × null → 168352 × ’.’ → 127 unikátních číselných hodnot Issuer Global ID, globální identifikátor vydavatele, který kartu vydal → 519061 × null → 79 unikátních hodnot, většina ve shodném formátu (např. I01090002) poznámka ke stavu karty → 7478885 × null → 8159 × ’DtFix’ datum vydání karty → 349 × null poznámka


LastUpdate

datetime

IssueCount UpdCount

tinyint tinyint

33

→ 5431557 × null datum a čas poslední aktualizace záznamu → 137837 × null význam neznámý význam neznámý

Zjištěné vztahy a statistiky: • 511714 karet nemá vyplněn atribut IssGID ani OrgID. • 7347 záznamů má vyplněno OrgID, ale nemá IssGID. • Všechny karty s LastUpdate > 31.7.2010 mají vyplněn IssGID. • Nejnovější karty nemají vyplněn OrgID. • 21 různých hodnot IssGID se nevyskytuje v tabulce Issuers ve sloupci IssGID (např ’CMNDirect’, ’CMNetBulk’). 4.1.1.3

Tabulka Issuers

Zde jsou evidována data vydavatelů karet včetně jejich autentizačních údajů pro volání webových služeb CCDB. Počet záznamů: Primární klíč:

98 IssGID

Atribut IssGID

Datový typ varchar(9)

Password

varchar(50)

OrgID

varchar(4)

Organisation

varchar(50)

Význam, vlastnosti a četnosti hodnot Issuer Global ID, globální identifikátor vydavatele → 0 × null → všechny hodnoty jsou unikátní → je použito jako název účtu pro upload karet do CCDB heslo přidělené vydavateli pro upload karet do CCDB → 8 × null → 86 unikátních hodnot → hesla jsou uvedena v textové podobě identifikátor licenční autority, pod kterou vydavatel patří → 7 × null → 57 unikátních hodnot v číselném formátu název vydavatele → 8 × null → 3 hodnoty použity dvakrát, jinak jsou unikátní

34


Folder

varchar(256)

Target

varchar(10)

Status

char(1)

CurrentFile

varchar(50)

Contact

varchar(50)

Email

varchar(50)

Tel

varchar(50)

Comment

varchar(50)

Country

varchar(50)

Yearly

int

DefaultAction

varchar(20)

SplitType

char(11)

Notify

varchar(150)

význam neznámý → 34 × null → 10 unikátních hodnot → formát shodný jako u IssGID význam neznámý → obsahuje pouze null hodnoty význam neznámý → 62 × null → 2 × ’T’ → 3 × ’U’ → 31 × ’Y’ význam neznámý → obsahuje pouze null hodnoty jméno kontaktní osoby → 86 × null e-mail kontaktní osoby → 91 × null telefon kontaktní osoby → 92 × null textová poznámka → 75 × null název země, ve které vydavatel působí → 7 × null význam neznámý → 50 × null význam neznámý → 41 × null → 52 × ’Notify’ → 5 × ’Upload’ význam neznámý → 89 × null význam neznámý → 97 × null

Zjištěné vztahy a statistiky: • 3 různé hodnoty OrgID nebyly nalezeny v databázi systému Organization Manager. 4.1.1.4

Tabulka Providers

Tato tabulka obsahuje údaje o poskytovatelích výhod, kteří mohou volat webovou službu CCDB pro ověřování platnosti karet. Zahrnuje rovněž jejich autentizační údaje pro volání této služby.


Počet záznamů: Primární klíč:

35

110 ProID

Atribut ProID

Datový typ char(11)

Password

varchar(20)

Authorisation

varchar(10)

Profile

varchar(10)

Status

varchar(10)

Comment

varchar(255)

Význam, vlastnosti a četnosti hodnot textový identifikátor poskytovatele → 0 × null → všechny hodnoty jsou unikátní → je použito jako název účtu pro verifikační webovou službu heslo přidělené poskytovateli pro verifikaci karet v CCDB → 0 × null → hesla jsou uvedena v textové podobě úroveň autorizace pro verifikační službu → 0 × null → 5 × ’SUMMARY’ → 31 × ’FULL’ → 74 × ’YESNO’ význam neznámý → 0 × null → 2 × ’STRICT’ → 108 × ’GENERAL’ význam neznámý → 91 × null → 1 × ’OBSOLETE’ → 18 × ’ACTIVE’ poznámka → 54 × null

Zjištěné vztahy a statistiky: • Nebyla zjištěna žádná spojitost s organizacemi evidovanými v databázi systému Organization Manager.

36


4.1.1.5

Tabulka logUpdates

V této tabulce se nachází záznamy o úspěšném volání webové služby UpdateCard (více v kapitole 4.1.2), které mělo za násladek vytvoření nebo aktualizaci karty. Počet záznamů:

636208

Primární klíč: ID Atribut ID IssGID

Datový typ int varchar(9)

OrgID

char(4)

ts

timestamp

CardNumber

char(20)

Result

varchar(256)

Význam, vlastnosti a četnosti hodnot umělý identifikátor záznamu Issuer Global ID, globální identifikátor vydavatele, který webovou službu zavolal → 0 × null identifikátor organizace → obsahuje pouze null hodnoty časové razítko zavolání webové služby UpdateCard → 0 × null → minimální hodnota je ’2009-06-09 14:51:24’ číslo karty tak, jak bylo zadáno jako parameter webové služby → 0 × null → 49782 × 12znaková hodnota → 323876 × 13znaková hodnota → 262515 × 14znaková hodnota → 35 × 15znaková hodnota → 107137 hodnot nezačíná typovým písmenem karty, ostatní jej mají textový návratový kód webové služby → 0 × null → všechny hodnoty obsahují text success

Zjištěné vztahy a statistiky: • Čísla 799949 karet z tabulky CardsIssued lze najít v hodnotách CardNumber v této tabulce. 797981 z těchto karet nemá uveden typ karty, k určení typu takových karet může napomoci právě záznam v tabulce logUpdates. 4.1.1.6

Identifikované problémy současné evidence

Obecnými problémy dat v CCDB jsou: 1. vysoká míra redundance informací, 2. chybějící integritní omezení – nejsou zavedeny ani již zmíněné cizí klíče, ani omezení na formát hodnot,


37

3. nejednotný formát údajů ve sloupcích – většina údajů je v textové podobě (datové typy char nebo varchar), přestože reprezentují např. datum, 4. nepoužívané atributy – některé sloupce tabulek neobsahují žádné hodnoty nebo hodnoty mající nulový význam, 5. nepoužívané tabulky – mnoho tabulek obsahuje zastaralá data, jejichž účel ani zákazníkovi není znám. Dále jsem v datech jednotlivých entit identifikoval konkrétní problémy, ke kterým je nutné při návrhu nové databáze a plánu migrace dat přihlédnout. Uvádím pouze závažné nedostatky: karty • sériová čísla některých karet nejsou ve formátu 12ciferného čísla, • u více než poloviny karet není uveden typ karty (ISIC, ITIC, atd.), • jména držitelů karet obsahují neplatné hodnoty, • názvy škol obsahují neplatné hodnoty, • názvy vydavatelů karet obsahují neplatné hodnoty, • identifikátory rozsahů obsahují neexistující hodnoty, • mnoho karet nemá uvedenu žádnou informaci, podle které by bylo možné zjistit, který vydavatel kartu vydal, • u 13 karet chybí datum expirace. rozsahy licenčních čísel • některé rozsahy nejsou přiděleny žádnému vydavateli (reference na vydavatele chybí). vydavatelé karet • prázdné jméno vydavatele, • prázdné heslo pro autentizaci při volání webové služby UpdateCard, • chybějící reference na licenční autoritu, • identifikátory organizací obsahují hodnoty nenalezené v databázi OM. poskytovatelé výhod • chybějící spojitost s organizacemi v OM.

38


4.1.2

Webové služby CCDB

Webové služby (Web Services) představují jediné rozhraní k datům v centrální evidenci karet. Vydavatelé karet využívají tyto služby pro posílání údajů o vydaných kartách do CCDB. Partneři poskytující slevy mohou volat webové služby pro ověřování platnosti karet. Všechny tyto služby jsou zabezpečené, pro úspěšné vyřízení požadavků musejí být vydavatelé i partneři autentizováni pomocí svých přihlašovacích údajů. Přenos informací webovými službami je realizován pomocí zpráv protokolu SOAP vázáného na aplikační protokol HTTP (více informací v kapitole 2.4). Navíc lze komunikovat s CCDB pomocí jednoduchých požadavků HTTP metod GET a POST, jejichž obsah kopíruje strukturu informací v SOAP zprávách. Současné webové služby jsou implementovány na platformě Microsoft .NET v jazyce C#. S centrální databází karet komunikují pomocí volání uložených procedur (Stored Procedure) psaných v jazyce T-SQL1 . Následuje popis jednotlivých dostupných webových služeb. 4.1.2.1

UpdateCardV2

Webová služba UpdateCardV2 slouží pro vytvoření záznamu nové karty nebo aktualizaci již existující karty. Vstupními parametry jsou: • CardNumber – identifikační číslo karty, • CardName – celé jméno držitele karty, • StudiesAt – název instituce, na které je držitel veden jako student nebo učitel, • DateOfBirth – datum narození držitele karty, • ExpireDate – datum expirace karty, • IssuedBy – název vydavatele, • IssueDate – datum vydání karty, • IssGID – Issuer Global ID, přidělený identifikátor vydavatele pro autentizaci, • Password – přidělené heslo vydavatele pro autentizaci. Webová služba po přijetí požadavku s těmito parametry nejprve provede pokus o autentizaci vydavatele dle zadaných hodnot parametrů IssGID a Password. Ta spočívá v nalezení shodné dvojice hodnot v tabulce Issuers. V případě, že je tento proces úspěšný, následuje zpracování požadavku v krocích znázorněných diagramem aktivit na obr. 4.1. Do odpovědi webové služby pro vytvoření/update karty je zařazen pouze textový řetězec informující o výsledku zpracování požadavku, který je rovněž v případě úspěšného zpracování zaznamenán do tabulky logUpdates. Tato návratová hodnota začíná zadaným číslem karty, za které je připojen jeden z těchto stavových kódů: 1

Transact SQL je procedurální rozšíření jazyka SQL od společnosti Microsoft používané v MS SQL Serveru.


Obrázek 4.1: Diagram aktivit – zpracování požadavku webovou službou UpdateCardV2

39

40


#1#Success #2#Success #9#Failure #7#Invalid #7#Invalid

4.1.2.2

- Card Added to CCDB - Card Updated in CCDB - Invalid IssGID/Password combination Card number format Expiration Date

VerifyCard

Voláním této webové služby mohou partneři – poskytovatelé výhod – ověřovat platnost karet, s kterými se jejich klienti dožadují uplatnění slevy. Vstupními parametry jsou: • CardNumber – identifikační číslo karty, • ProGID – Provider Global ID, přidělený identifikátor partnera pro autentizaci, • Password – přidělené heslo partnera pro autentizaci. Po přijetí požadavku na ověření platnosti karty je nejprve proveden pokus o autentizaci volajícího dle zadaných hodnot parametrů ProGID a Password. Pokud je v tabulce Providers nalezena shodná dvojice hodnot (atributy ProID a Password), následuje zpracování požadavku v krocích znázorněných diagramem aktivit na obr. 4.2. Pro verifikaci CJP a NUS karet jsou volány externí webové služby systémů spravujících tyto druhy karet. Při sestavování odpovědi webové služby se ještě přihlíží k úrovni autorizace pro verifikaci karet (různé hodnoty ve sloupci Authorisation). Odpověď je tvořena návratovým kódem odpovídajícím výsledku verifikace karty a případně ještě údaji nalezené karty. Pro poskytovatele s úrovní autorizace FULL jsou používány tyto návratové kódy: • INVNO – neplatné číslo karty, • EXPCD – karta má prošlou platnost, • VALCD – karte je platná, • EXTCD – karta nebyla nalezena, ale zadané číslo karty patří do existujícího rozsahu, • NEXCD – nebyla nalezena ani karta, ani rozsah obsahující zadané licenční číslo, • NORNG – karta byla nalezena, ale neobsahuje referenci na rozsah, do kterého patří, • ERROR – došlo k neočekávané chybě při verifikaci karty. Pro ostatní úrovně autorizace jsou návratové kódy zjednodušeny na VALID (platná karta) a INVLD (všechny ostatní možné výsledky verifikace karet). Zároveň nejsou připojovány údaje o nalezených kartách. V případě, že autentizace poskytovatele neproběhla úspěšně, je vrácen kód NOAUT.


Obrázek 4.2: Diagram aktivit – zpracování požadavku webovou službou VerifyCard

41

42


4.1.2.3

UpdateCard

UpdateCard je starší, leč stále používaná, verze webové služby UpdateCardV2. Oproti novější verzi ji chybí vstupní parametr pro datum vydání karty, jako datum vydání tato webová služba proto nastavuje aktuální datum. Průběh zpracování požadavků je kromě této vlastnosti shodný s UpdateCardV2. 4.1.2.4

Identifikované nedostatky webových služeb

Poměrně závažné problémy vidím ve fungování webové služby UpdateCardV2. Ta totiž umožňuje všem autentizovaným vydavatelům vytvořit libovolnou kartu a co víc, také libovolnou kartu v centrální evidenci zmodifikovat. Není přípustné, aby vydavatelé měli přístup k editaci karet, které sami nevydali. Zároveň není žádným způsobem kontrolováno číslo nové karty, vydavatelé mohou vytvořit kartu s libovolným číslem. Očekával bych, že webová služba bude kontrolovat, zda vydavatelé mají právo vydat kartu se zadaným licenčním číslem, tj. že vlastní rozsah, který toto číslo obsahuje. Neméně závažným problémem je fakt, že při vytváření a aktualizace karet není znám typ karet. Klienti sice mohou zadat číslo karty včetně jejího počátečního typového písmena, nicméně toto je odstraněno hned v úvodu zpracování požadavku a dále se s ním nepracuje. Pro migraci existujících dat je podstatné, že do tabulky logUpdates se zapisují čísla karet tak, jak se vyskytují v odeslaných požadavcích na tuto webovou službu. Verifikační webová služba byla navržena s ohledem na nedokonalou evidenci karet. Umožňuje tedy prohlásit kartu za platnou i v případě, že se karta v databázi nenachází, ale byl vytvořen rozsah licenčních čísel, který byl předán nějakému vydavateli, jenž kartu s daným číslem již mohl vydat. Toto chování bude muset být zachováno i v nové implementaci webových služeb.

4.1.3

Synchronizace s CardMaster.NET

V současné době je přes B2B2 aplikaci CardMaster.NET vydáváno přibližně 40% všech ISIC karet. Data karet vydaných touto cestou musejí být v pravidelných, dostatečně krátkých intervalech exportována do centrální databáze karet, aby je mohli jejich držitelé ihned využívat. Přestože CardMaster.NET poskytuje webové služby pro přístup k datům vydaných karet, nejsou pro synchronizaci s CCDB využívány, jelikož byly zprovozněny v relativně nedávné době, tedy později, než bylo synchronizaci nutné zajistit. Pro účely přenosu dat z CM.NET do CCDB byla na stejném databázovém serveru vytvořena databáze CM_CCDB, která v pravidelných intervalech 20 minut volá uloženou proceduru meziskladové databáze CM.NET (rovněž pojmenovaná CM_CCDB). Ta vytvoří prázdnou tabulku, do které nakopíruje karty vydané po zadaném datu z hlavní databáze CM.NET. Z této tabulky jsou data přenesena do meziskladu CCDB a uložena ve stejném formátu, v jakém jsou evidována v hlavní databázi CCDB. V poslední fázi jsou karty z meziskladu zaevidovány v hlavní databázi CCDB. Tok dat během procesu synchronizace je zjednodušeně zobrazen na obr. 4.3. 2

Zkratka pro Business to Business, označuje komerční aktivity mezi firmami, do kterých nejsou zapojeni koncoví spotřebitelé služeb či zbočí.

4.2. KONCEPTUÁLNÍ DATOVÝ MODEL

43

Obrázek 4.3: Tok dat při synchronizaci karet z CardMaster.NET

Přenos karet z CardMaster.NET do CCDB je příliš komplikovaný, je využito 4 různých databází a několika uložených procedur. Kromě toho nepovažuji tento způsob synchronizace za bezpečný, protože se jím obchází veřejné rozhraní CardMaster.NET a k datům je přistupováno na úrovni, jejíž změny mohou být pro veřejné rozhraní transparentní, nicméně na synchronizační proces mohou mít negativní vliv.

4.1.4

Závěr analýzy

Důkladnou analýzou současné centrální databáze karet jsem se seznámil se stavem a s vlastnostmi procesů zajišťujících její stávající funkčnost. To bylo nezbytné pro správný návrh implementace nového systému, který ten současný bude nahrazovat a který musí zůstat v mnoha ohledech zpětně kompatibilní. Zároveň jsem odhalil problémy, které musí nová implementace CCDB odstranit. Na základě nabytých poznatků mohu navrhnout strukturu nové databáze a připravit plán migrace dat z CCDB do CCDB2.

4.2

Konceptuální datový model

K popisu modelované reality se používají konceptuální modely, jejichž cílem je identifikovat entity jako množiny objektů stejného typu, jejich atributy a vztahy mezi těmito entitami. Konceptuální modely jsou nezávislé na způsobu, jakým budou data uložena a manipulována. Konceptuální datový model informačního systému pro správu ISIC karet je zobrazen na obr. 4.4, pro přehlednost nejsou v této vizuální podobě konceptuálního modelu znázorněny atributy entit.

4.2.1

Popis modelu

Základním objektem, se kterým bude systém pro správu karet operovat, bude bez pochyb objekt karty (Card). Vzhledem k definovanému požadavku na zavedení dočasných karet (více v kapitole 3.5) budou rozlišovány karty dočasné (TemporaryCard) a stadardní vydané karty (RegularCard). Každá karta patří organizaci, která reprezentuje vydavatele karet (CardIssuer). Těmto vydavatelům jsou přiřazeny rozsahy licenčních čísel (CardRange), z nichž mohou používat čísla pro své karty. Každá normální karta musí mít přiřazen rozsah, do kterého její číslo spadá. K rozsahům jsou evidovány události (CardRangeEvent), které představují

44


Obrázek 4.4: Konceptuální datový model

4.2. KONCEPTUÁLNÍ DATOVÝ MODEL

45

jednotlivé záznamy pro Track & Trace funkcionalitu. Při ověření platnosti karty vzniká záznam o verifikaci (VerificationLog). Uživatelé (User) a organizace vydavatelů a poskytovatelů výhod (BenefitProvider) jsou spravovány v systému Organization Manager, entity aplikace CCDB2 s nimi budou tvořit vazby, jejichž integrita bude zajištěna díky společnému datovému úložišti obou systémů.

4.2.2

Entity

Card

– identifikační karta. Evidovanými atributy jsou:

• sériové číslo karty, • typ karty, • platnost karty (od - do), • název školy, • jméno držitele karty, • datum narození držitele karty, • e-mail držitele karty, • původ vzniku karty, • příznak, zda byla karta zrušena. TemporaryCard – dočasná virtuální karta s omezenou platností. Licenční čísla těchto karet budou mít odlišný formát od čísel standardních karet. RegularCard CardRange

– standardní vydaná karta. – rozsah licenčních čísel, atributy:

• počáteční číslo, • koncové číslo, • typ karet, pro které jsou čísla určena, • identifikátor používaný v původní aplikaci pro správu rozsahů, • příznak určující, zda jsou karty v tomto rozsahu předtištěny včetně jejich čísla, • příznak určující, zda čísla karet v tomto rozsahu obsahují kontrolní písmeno.

46


CardRangeEvent

– záznam události o změně stavu rozsahu čísel, atributy:

• datum a čas události, • název události, • detailní popis. VerificationLog

– záznam o provedeném ověření platnosti karty, atributy:

• datum a čas verifikace karty, • ověřované číslo karty, • zadané jméno držitele karty, • výsledek verifikace.

4.2.3

Vztahy mezi entitami

• Card → issued by → CardIssuer – každá karta je vydána nějakým vydavatelem karet, vydavatel může vydat více karet. Kardinalita 1:N. • RegularCard → belongs to → CardRange – standardní karta patří právě do jednoho rozsahu licenčních čísel, z rozsahu nemusí být vydána žádná karta. Kardinalita 1:N. • RegularCard → replaces → TemporaryCard – standardní karta může nahrazovat a rušit kartu dočasnou, dočasná karta může být nahrazena právě jednou kartou standardní. Kardinalita 1:1. • CardRange → owned by → CardIssuer – každý rozsah patří nějakému vydavateli karet, který je oprávněn používat licenční čísla z tohoto rozsahu. Vydavatel může mít žádný nebo více rozsahů. Kardinalita 1:N. • CardRangeEvent → tracks → CardRange – záznam události o změně stavu se vztahuje k jednomu rozsahu čísel. Ke každému rozsahu může být evidováno několik záznamů událostí. Kardinalita 1:N. • CardRangeEvent → recorded by → User – záznam události o změně stavu rozsahu čísel je vždy vytvořen nějakým uživatelem. Kardinalita 1:N. • VerificationLog → tracks verification of → Card – záznam o verifikaci může referencovat kartu nalezenou podle zadaného čísla pro ověření platnosti. Karty mohou být ověřovány opakovaně. Kardinalita 1:N. • VerificationLog → verified by → User – záznam o verifikaci je uložen po odeslání požadavku na ověření platnosti nějakým uživatelem. Kardinalita 1:N.

4.3. POPIS PŘÍPADŮ UŽITÍ

4.3

47

Popis případů užití

V následujících sekcích jsou detailně popsány případy užití (Use Cases) informačního systému pro správu identifikačních karet, které vycházejí z analýzy požadavků a z modelu užití na obrázku 3.2.

4.3.1

Strojové rozhraní

Veřejné strojové rozhraní aplikace CCDB2 je její nejdůležitější částí, která umožňuje vydavatelům vytvářet a aktualizovat jimi vydané karty. Jelikož se jedná o strojové rozhraní, není uživatelská interakce během těchto případů užití umožněna. Uživatelé pouze odešlou požadavek na webovou službu, ta jej zpracuje a vrátí výsledek zpracování. Aktéři volající tyto webové služby jsou většinou reprezentováni nějakým informačním systémem, který využívá služeb centrální databáze karet.

4.3.1.1

UC001 - Vytvoření nové karty

Stručný popis: Vytvoření nového záznamu v evidenci karet je realizováno voláním webové služby UpdateCardV2. Základní princip této funkčnosti zůstává stejný s existující webovou službou popsanou v kapitole 4.1.2. Průběh zpracování odeslaného požadavku na vytvoření karty je znázorněn na obr. 4.5. Vstupní podmínky: Aktéři:

Žádné.

Vydavatel karet.

Hlavní scénář: 1. Vydavatel karty odešle na adresu webové služby UpdateCardV2 požadavek na vytvoření karty. 2. Systém provede autentizaci uživatele podle vstupních parametrů IssGID a Password. 3. Systém zkontroluje formát hodnot jednotlivých vstupních parametrů. 4. Pokud není zadáno datum narození držitele karty, je použita výchozí hodnota 1.1.1900. 5. Pokud není zadáno datum vydání karty, je použito aktuální datum. 6. Systém požadavek zpracuje a vytvoří v evidenci nový záznam karty. 7. Do odpovědi webové služby systém vloží informaci potvrzující úspěšné zpracování požadavku.

48


Alternativní scénáře: • Požadavek neobsahuje všechny povinné atributy → Odpověď webové služby indikuje chybu pomocí chybového elementu SOAP Fault. • Autentizace uživatele není úspěšná → Odpověď webové služby obsahuje informaci o neplatné kombinaci IssGID a Password. • Atributy požadavku nemají požadovaný formát → Odpověď webové služby obsahuje informaci o neplatném formátu požadavku. • Vydavatel není oprávněn vytvořit kartu se zadaným číslem → V případě, že vydavateli není přiřazen rozsah licenčních čísel, který obsahuje zadané číslo karty, je vytvoření karty odmítnuto. • Číslo karty zadané v požadavku je použito na existující kartě → Pokud nalezená karta patří vydavateli, který požadavek odeslal, provede se aktualizace údajů karty podle poskytnutých hodnot. V opačném případě není update karty povolen.

Obrázek 4.5: Diagram aktivit pro UC001 – Vytvoření nové karty

4.3.1.2

UC002 - Ověření platnosti karty

Stručný popis: Ověřit platnost karty (verifikovat kartu) mohou uživatelé s patřičnými právy voláním verifikační webové služby VerifyCard. Zpracování požadavku na ověření plat-


49

nosti karty s daným číslem má stejný průběh jako zpracování požadavku existující webovou službou popsanou v kap. 4.1.2. Vstupní podmínky: Aktéři:

Žádné.

Poskytovatel výhod.

Hlavní scénář: 1. Uživatel odešle na adresu webové služby VerifyCard požadavek na ověření karty. 2. Systém provede autentizaci uživatele podle vstupních parametrů ProGID a Password. 3. Systém zkontroluje správnost formátu čísla karty. 4. Systém vyhledá kartu podle zadaného čísla a vyhodnotí její platnost. 5. Systém vytvoří záznam o vyžádané verifikaci karty. 6. Do odpovědi webové služby systém vloží výsledek verifikace karty. Alternativní scénáře: • Požadavek neobsahuje všechny povinné atributy → Odpověď webové služby indikuje chybu pomocí chybového elementu SOAP Fault. • Autentizace uživatele není úspěšná → Odpověď webové služby obsahuje informaci o neplatné kombinaci ProGID a Password. • Číslo karty není ve správném formátu → Odpověď webové služby obsahuje informaci o neplatném číslu karty. • Číslo karty odpovídá formátu čísel CJP/NUS karet → Systém zavolá webovou službu pro ověřování platnosti CJP/NUS karet, zpracuje obdrženou odpověď a vyhodnotí platnost karty.

4.3.2

Grafické uživatelské rozhraní

V této sekci jsou popsány případy užití systému pro správu karet přes jeho webové rozhraní. 4.3.2.1

UC101 – Přihlášení do systému

Stručný popis: Veškeré funkčnosti grafického rozhraní k CCDB jsou dostupné až po přihlášení uživatele do systému. Požadavek na autentizaci uživatele je odeslán do systému Organization Manager, který podle poskytnutých přihlašovacích údajů vyhledá uživatele ve své databázi a vrátí seznam oprávnění, které jsou uživateli s daným jménem a heslem přiděleny. Vstupní podmínky:

Žádné.

50


Aktéři:

Administrátor IAS, Vydavatel karet, Poskytovatel výhod, Výrobce karet.

Hlavní scénář: 1. Systém zobrazí přihlašovací formulář. 2. Uživatel vyplní uživatelské jméno a heslo a formulář potvrdí. 3. Systém ověří zadané údaje a uživatele přihlásí do systému. Alternativní scénáře: • Zadaná kombinace uživatelského jména a hesla není platná → Systém zobrazí upozornění o neplatných přihlašovacích údajích. 4.3.2.2

UC102 – Odhlášení ze systému

Stručný popis: K ukončení práce s aplikací CCDB2 slouží procedura odhlášení uživatele ze systému. Po jejím dokončení je vyžadováno nové přihlašení. Vstupní podmínky: Aktéři:

Přihlášený uživatel.

Administrátor IAS, Vydavatel karet, Poskytovatel výhod, Výrobce karet.

Hlavní scénář: 1. Uživatel klikne na odkaz k odhlášení. 2. Systém odstraní uživatelovu session a zobrazí přihlašovací formulář. Alternativní scénáře: 4.3.2.3

Nejsou.

UC103 – Prohlížení seznamu karet

Stručný popis: Přehled evidovaných karet podává stránkovaná a seřaditelná tabulka karet. Zobrazené záznamy lze filtrovat podle několika dostupných kritérií. Uživatelům vydavatelů karet jsou zobrazeny pouze karty, které jejich organizace vydala. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro prohlížení karet.

Administrátor IAS, Vydavatel Karet.

Hlavní scénář: 1. Uživatel v hlavním menu zvolí položku označující seznam karet. 2. Systém zobrazí formulář s parametry vyhledávání. 3. Uživatel vyplní filtrovací kritéria a potvrdí zobrazení karet. 4. Systém zobrazí karty vyhovující zadaným kritériím v tabulce pod filtrovacím formulářem.


51

Alternativní scénáře: • Vyplněné hodnoty filtrovacích parametrů mají neplatný formát → Pole formuláře s chybnými hodnotami jsou zvýrazněna a uživatel je upozorněn na chybu v zadání vyhledávacích parametrů. 4.3.2.4

UC104 – Zobrazení detailu karty

Stručný popis: V tabulce se seznamem karet jsou zobrazeny pouze základní údaje o kartách. Pro podrobný výpis parametrů karty slouží obrazovka s detailem karty. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro prohlížení karet.

Administrátor IAS, Vydavatel Karet.

Hlavní scénář: 1. Uživatel klikne na ikonku detailu na konkrétním řádku v tabulce karet. 2. Systém zobrazí výpis parametrů karty. Alternativní scénáře: 4.3.2.5

Nejsou.

UC105 – Smazání karty

Stručný popis: Administrátoři IAS mohou evidované karty smazat. Smazaná karta není v grafickém rozhraní aplikace viditelná, v databázi systému přesto nadále existuje. Číslo smazané karty může být dále použito pro jinou kartu. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro mazání karet.

Administrátor IAS.

Hlavní scénář: 1. Uživatel klikne na ikonku odstranění na konkrétním řádku v tabulce karet. 2. Systém zobrazí potvrzující dialog a upozornění, že tato operace je nevratná. 3. Uživatel zobrazený dialog potvrdí kliknutím na OK. 4. Systém označí vybranou kartu za smazanou a skryje daný řádek tabulky karet. Alternativní scénáře: • Uživatel zruší operaci smazání karty → Kliknutím na Cancel v potvrzovacím dialogu může uživatel odvrátit smazání karty.

52


4.3.2.6

UC106 – Zrušení karty

Stručný popis: Administrátoři IAS mohou evidované karty rušit. Zrušení karty má význam jejího zneplatnění, při verifikaci karet jsou zrušené karty vyhodnoceny jako neplatné. Zrušené karty se narozdíl od smazaných nadále zobrazují v přehledu karet. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro mazání karet.

Administrátor IAS.

Hlavní scénář: 1. Uživatel klikne na ikonku zrušení na konkrétním řádku v tabulce karet. 2. Systém zobrazí potvrzující dialog a upozornění, že tato operace je nevratná. 3. Uživatel zobrazený dialog potvrdí kliknutím na OK. 4. Systém označí vybranou kartu za zrušenou a aktualizuje daný řádek tabulky karet. Alternativní scénáře: • Uživatel zruší operaci zrušení karty → Kliknutím na Cancel v potvrzovacím dialogu může uživatel odvrátit zrušení karty. 4.3.2.7

UC107 – Ověření platnosti karty

Stručný popis: Platnost karet lze kromě volání webové služby VerifyCard zjišťovat také přes uživatelské rozhraní. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro verifikaci karet.

Administrátor IAS, Vydavatel karet, Poskytovatel výhod.

Hlavní scénář: 1. Uživatel zvolí v hlavním menu položku pro ověřování platnosti karet. 2. Systém zobrazí formulář s textovým polem pro číslo karty. 3. Uživatel vyplní číslo karty a formulář potvrdí. 4. Systém vyhledá kartu podle zadaného čísla a zobrazí údaje o její platnosti pod vyplněným formulářem. Alternativní scénáře: • Zadané číslo karty nemá správný formát → Systém informuje uživatele o odeslání neplatného čísla karty. • Karta s daným číslem není nalezena → Systém pod vyplněným formulářem zobrazí informaci o neúspěšném vyhledání karty.


4.3.2.8

53

UC108 – Import karet z XLS

Stručný popis: K aktualizaci evidence karet lze kromě webové služby UpdateCardV2 využít také rozhraní pri import souborů ve formátu XLS. Importované soubory mají pevně definovanou strukturu, při jejímž dodržení lze karty v CCDB vytvářet a aktualizovat hromadně. Zpracování jednotlivých záznamů (řádků v XLS souboru) probíhá stejným způsobem jako zpracování přijatého požadavku webovou službou pro upload karet (viz diagram aktivit na obr. 4.5). Jelikož je pro každý jednotlivý záznam v XLS volána interní REST webová služba pro vytvoření karty, není zajištěno transakční zpracování celého importovaného souboru. Import z XLS proto může být v některých případech úspěšný jen z části, seznam položek, které se kvůli validačním pravidlům evidence karet nepodaří zpracovat, je vypsán po dokončení importu. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro vytváření karet.

Administrátor IAS, Vydavatel karet.

Hlavní scénář: 1. Uživatel zvolí v hlavním menu položku pro XLS import. 2. Systém zobrazí formulář s polem pro výběr souboru. 3. Uživatel vyplní cestu k souboru na svém PC a požadavek na import odešle. 4. Systém zpracuje všechny položky ve vybraném souboru a karty vytvoří nebo aktualizuje. 5. Uživateli je zobrazena statistika zahrnující počet úspěšně vytvořených karet a seznam položek, které se nepodařilo naimportovat. Alternativní scénáře: • Neplatný výběr souboru → Nechá-li uživatel pole pro výběr souboru prázdné nebo zadá-li cestu k souboru v jiném formátu než XLS, systém zobrazí upozornění na neplatný výběr souboru. • Chybná struktura dat v XLS souboru → V případě, že první řádek zvoleného XLS souboru neobsahuje přesně definovanou množinu názvů sloupců, je import zamítnut a uživatele systém upozorní na neplatnou strukturu dat v importovaném souboru. 4.3.2.9

UC109 – Prohlížení seznamu rozsahů

Stručný popis: Přehled existujících rozsahů licenčních čísel je zobrazen formou stránkované a seřaditelné tabulky. Zobrazenou množinu rozsahů lze omezit pomocí parametrů pro vyhledání rozsahů. Vstupní podmínky:

Přihlášený uživatel s právem pro prohlížení rozsahů.

54


Aktéři:

Administrátor IAS.

Hlavní scénář: 1. Uživatel zvolí v hlavním menu položku pro seznam rozsahů. 2. Systém zobrazí formulář s parametry vyhledávání. 3. Uživatel vyplní filtrovací kritéria a potvrdí zobrazení rozsahů. 4. Systém zobrazí rozsahy vyhovující zadaným kritériím v tabulce pod filtrovacím formulářem. Alternativní scénáře: • Vyplněné hodnoty filtrovacích parametrů mají neplatný formát → Pole formuláře s chybnými hodnotami jsou zvýrazněna a uživatel je upozorněn na chybu v zadání vyhledávacích parametrů. 4.3.2.10

UC110 – Vytvoření nového rozsahu

Stručný popis: Administrátoři mohou vytvářet nové rozsahy licenčních čísel a přidělovat je vydavatelům karet. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro vytváření rozsahů.

Administrátor IAS.

Hlavní scénář: 1. Uživatel klikne na ikonku nového rozsahu na stránce se seznamem rozsahů. 2. Systém zobrazí prázdný formulář pro vyplnění atributů nového rozsahu. 3. Uživatel vyplní do formuláře údaje nového rozsahu a požadavek odešle. 4. Systém vytvoří nový rozsah se zadanými parametry, zobrazí seznam rozsahů a informuje uživatele o úspěšně vytvořeném rozsahu. Alternativní scénáře: • Nevyplněné povinné atributy rozsahu → Systém zvýrazní pole s chybějícími hodnotami a vyzve uživatele k doplnění údajů. • Špatný formát atributů rozsahu → Systém zvýrazní pole s neplatnými hodnotami a vyzve uživatele k opravě údajů. • Kolize rozsahů → Pokud zadaný rozsah obsahuje licenční čísla, která patří do jiného již existujícícho rozsahu, systém upozorní uživatele na koflikt rozsahů a vyzve jej ke změně mezí nového rozsahu.


4.3.2.11

55

UC111 – Editace rozsahu

Stručný popis: Vytvořené rozsahy lze dodatečně editovat za předpokladu, že se úpravou neporuší konzistence dat, zejména vztah rozsah – vydané karty z rozsahu. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro editaci rozsahů.

Administrátor IAS.

Hlavní scénář: 1. Uživatel klikne na ikonku editace na konkrétním řádku v tabulce rozsahů. 2. Systém zobrazí formulář s atributy daného rozsahu. 3. Uživatel upraví vlastnosti rozsahu a formulář odešle. 4. Systém zaktualizuje rozsah, zobrazí seznam rozsahů a informuje uživatele o úspěšné modifikaci rozsahu. Alternativní scénáře: • Nevyplněné povinné atributy rozsahu → Systém zvýrazní pole s chybějícími hodnotami a vyzve uživatele k doplnění údajů. • Špatný formát atributů rozsahu → Systém zvýrazní pole s neplatnými hodnotami a vyzve uživatele k opravě údajů. • Kolize rozsahů → Pokud upravené meze rozsahů zasahují do jiných rozsahů, systém upozorní uživatele na koflikt rozsahů. • Porušení konzistence dat → Jestliže z editovaného rozsahu již byly vydány nějaké karty a uživatel přiřadí rozsah jinému vydavateli, systém úpravu odmítne a uživatele upozorní na neproveditelnost takové úpravy. → Jestliže uživatel upraví meze rozsahu tak, že číslo nějaké vydané karty z daného rozsahu do nového intervalu nespadá, systém úpravu odmítne a uživatele upozorní na neproveditelnsot takové úpravy. 4.3.2.12

UC112 – Smazání rozsahu

Stručný popis: Administrátoři systému mohou existující rozsahy smazat a vydavatelům tak znemožnit další vydávání karet s čísly z daného rozsahu. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro mazání rozsahů.

Administrátor IAS

56


Hlavní scénář: 1. Uživatel klikne na ikonku odstranění na konkrétním řádku v tabulce rozsahů. 2. Systém zobrazí potvrzující dialog s upozorněním, že tato operace je nevratná. 3. Uživatel zobrazený dialog potvrdí kliknutím na OK. 4. Systém označí vybraný rozsah za smazaný a skryje daný řádek tabulky rozsahů. Alternativní scénáře: • Uživatel zruší operaci smazání rozsahu → Kliknutím na Cancel v potvrzovacím dialogu může uživatel odvrátit smazání rozsahu. 4.3.2.13

UC113 – Prohlížení seznamu událostí

Stručný popis: Uživatelům je umožněno nahlížet do seznamu událostí zaznamenaných k jednotlivým rozsahům. Události jsou zobrazeny ve stránkované a seřaditelné tabulce, jejíž obsah lze omezit pomocí filtrovacích kritérií. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro prohlížení událostí.

Administrátor IAS, Výrobce karet

Hlavní scénář: 1. Uživatel zvolí v hlavním menu položku pro seznam událostí. 2. Systém zobrazí formulář s parametry vyhledávání. 3. Uživatel vyplní filtrovací kritéria a potvrdí zobrazení událostí. 4. Systém zobrazí události vyhovující zadaným kritériím v tabulce pod filtrovacím formulářem. Alternativní scénáře: • Vyplněné hodnoty filtrovacích parametrů mají neplatný formát → Pole formuláře s chybnými hodnotami jsou zvýrazněna a uživatel je upozorněn na chybu v zadání vyhledávacích parametrů. 4.3.2.14

UC114 – Zaznamenání nové události

Stručný popis: Možnost vytvořit záznam o události k rozsahu licenčních čísel mohou využívat uživatelé výrobců karet. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro vytváření událostí.

Administrátor IAS, Výrobce karet.


57

Hlavní scénář: 1. Uživatel zvolí v hlavním menu položku pro záznam nové události. 2. Systém zobrazí formulář pro vytvoření nové události. 3. Uživatel vyplní požadované parametry události a akci potvrdí kliknutím na tlačítko Create. 4. Systém vytvoří novou událost, zobrazí seznam událostí a informuje uživatele o úspěšně zaznamenané události. Alternativní scénáře: • Nevyplněné povinné atributy události → Systém zvýrazní pole s chybějícími hodnotami a vyzve uživatele k doplnění údajů. • Špatný formát atributů události → Systém zvýrazní pole s neplatnými hodnotami a vyzve uživatele k opravě údajů. • Neexistující rozsah licenčních čísel → Jestliže vyplněné meze rozsahu čísel neodpovídají žádnému existujícímu rozsahu, systém zobrazí upozornění na chybně zadaný rozsah. 4.3.2.15

UC115 – Editace události

Stručný popis:

Zaznamenané události k rozsahům čísel lze dodatečně upravit.

Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro editaci událostí.


Hlavní scénář: 1. Uživatel v seznamu událostí vybere jednu konkrétní událost kliknutím na příslušný řádek v tabulce. 2. V zobrazeném detailu klikne uživatel na tlačítko pro editaci zvolené události. 3. Systém zobrazí formulář pro editaci události a předvyplní jej parametry zvolené události. 4. Uživatel hodnoty ve formuláři upraví a editaci potvrdí kliknutím na tlačítko Save. 5. Systém zaktualizuje událost, zobrazí seznam událostí a informuje uživatele o úspěšné modifikaci události. Alternativní scénáře: Shodné s alternativními scénáři pro UC114 – Zaznamenání nové události.

58


4.3.2.16

UC116 – Smazání události

Stručný popis: Existující rzzsahy mohou privilegovaní uživatelé smazat a odstranit je tak ze seznamu evidovaných událostí k danému rozsahu. Vstupní podmínky: Aktéři:

Přihlášený uživatel s právem pro mazání událostí.


Hlavní scénář: 1. Uživatel v seznamu událostí vybere jednu konkrétní událost kliknutím na příslušný řádek v tabulce. 2. V zobrazeném detailu klikne uživatel na tlačítko pro smazání zvolené události. 3. Systém zobrazí potvrzující dialog s upozorněním, že tato operace je nevratná. 4. Uživatel zobrazený dialog potvrdí kliknutím na OK. 5. Systém označí vybranou událost za smazanou a skryje příslušný řádek v seznamu událostí. Alternativní scénáře: • Uživatel zruší operaci smazání události → Kliknutím na Cancel v potvrzovacím dialogu může uživatel odvrátit smazání události.

Kapitola 5

Implementace V této kapitole je popsána implementace systému pro správu identifikačních karet. Realizované řešení vychází z navržené architektury (kapitola 3.7), výsledný produkt je tvořen třemi samostatnými aplikacemi: • CCDB Core – jádro systému pro správu karet zajišťující veškerou aplikační logiku systému. • CCDB Web UI – webové uživatelské rozhraní pro administraci CCDB. • Migrační nástroj – konzolová aplikace pro jednorázové zmigrování dat ze starého systému do nového. Oddělením jádra systému od uživatelského rozhraní je zajištěna modulární struktura, díky které může být systém pro správu karet jednoduše integrován do existujícího IT prostředí organizace IAS. Ostatní informační systémy tak mohou s CCDB komunikovat přes poskytnuté strojové rozhraní. Tento přístup k údajům v centrální databázi karet bude také využit pro implementaci jednotného administračního rozhraní, pomocí kterého bude zaměstnancům IAS umožněno spravovat všechny své informační systémy z jedné aplikace.

5.1

CCDB Core

Jádro systému pro správu karet je implementováno jako aplikace běžící v servletovém kontejneru Tomcat. Tato aplikace pomocí Java servletů zpřístupňuje webové služby, které jsou jejím jediným veřejným rozhraním. Jádro CCDB je jedinou komponentou, která operuje s daty v databázi CCDB.

5.1.1

Databázová vrstva

Během analýzy systému byly identifikovány entity, které tvoří problémovou doménu a představují typy objektů reálného světa (více v kapitole Konceptuální datový model). Na základě tohoto návrhu entit jsou v databázové vrstvě aplikace deklarovány doménové objekty1 , které 1

též označované jako business objekty nebo modelové objekty

59

60

KAPITOLA 5. IMPLEMENTACE

definují strukturu persistentních dat, s nimiž aplikace manipuluje. Pomocí objektově relačního mapování je z množiny doménových objektů vytvořena fyzická reprezentace dat v relační databázi. Pro CRUD operace s entitami jsou používány třídy implementující návrhový vzor Data Access Object (DAO). 5.1.1.1

Doménové objekty

Na obrázku 5.1 je zobrazen diagram tříd použitých doménových objektů, které obsahují pouze atributy a přístupové metody k těmto atributům (getters/setters). Všechny doménové objekty jsou definovány v balíku net.orchitech.ias.ccdb2.core.model.

Obrázek 5.1: Diagram tříd doménových objektů

5.1. CCDB CORE

61

K doménovým objektům jsou připojeny JPA anotace, které definují způsob mapování objektů na databázové tabulky. Těmito anotacemi lze řídit názvy tabulek a atributů, datové typy atributů a některá integritní omezení. Pro ukázku uvádím výtah z mapování doménového objektu karty: @Entity @Table(name=CCDB2_PREFIX + "card") @Inheritance(strategy=InheritanceType.SINGLE_TABLE) @DiscriminatorColumn(name="_type", discriminatorType=DiscriminatorType.STRING, length=9) public abstract class Card extends BaseModifiableObject implements Serializable { @Id @Column(name="card_id", nullable=false) @GeneratedValue(strategy=GenerationType.AUTO, generator="SEQ_CARD") private int cardId; @Embedded private CardNumber cardNumber; @Enumerated(EnumType.STRING) @Column(name="card_type", length=16) private CardType cardType; @Temporal(TemporalType.DATE) @Column(name="valid_to", nullable=false) private Date validTo; }

Vztahy mezi jednotlivými entitami lze rovněž namapovat použitím k tomu určených anotací, např. vztah karta – rozsah čísel je realizován takto: @Entity @DiscriminatorValue("REGULAR") public class RegularCard extends Card { @ManyToOne(fetch=FetchType.LAZY) @JoinColumn(name="card_range_id") private CardRange cardRange; }

5.1.1.2

Fyzický datový model

Fyzická reprezentace dat byla vytvořena Hibernate frameworkem z definovaných doménových objektů. Třídy s JPA anotacemi jsou zařazeny do objektově relačního mapování uvedením jejich plného jména v konfiguračním souboru hibernate.cfg.xml. Vygenerovaný fyzický model je zobrazen na obrázku 5.2. Základní princip ORM spočívá v mapování tříd na databázové tabulky a atributů tříd na sloupce tabulky. V následujících odstavcích jsou popsány významy jednotlivých atributů tabulek.

62


Obrázek 5.2: Fyzický datový model

5.1. CCDB CORE

63

Tabulka card V této tabulce jsou evidovány dočasné i standardní karty, rozlišeny jsou pomocí atributu _type. Atribut card_id _type

Povinný ano ano

type_letter licence_number

ne ano

check_letter card_type first_name last_name printed_name

ne ne ne ne ano

birth_date email valid_from valid_to status

ne ne ano ano ano

origin

ano

institution_name issuer_organization_id issued_by issued_on card_range_id temporary_card_id

ano ano ano ano ne ne

created_on created_by_user_id last_modified_on last_modified_by_user_id

ano ano ano ano

deleted

ano

Význam unikátní umělý identifikátor určuje, zda je karta dočasná (hodnota TEMPORARY) nebo normální (hodnota REGULAR) typové písmeno čísla karty licenční číslo karty, normální karty mají 12ciferné číslo, dočasné karty mají 13ciferné číslo kontrolní písmeno čísla karty typ karty (ISIC, ITIC, atd.) křestní jméno držitele karty příjmení držitele karty jméno držitele karty tak, jak je natištěno na kartě datum narození držitele karty e-mail držitele karty datum začátku platnosti datum expirace stav karty, může být vydaná (ISSUED) nebo zrušená (VOIDED) původ karty, podle kterého lze rozlišit, jakým způsobem se karta do databáze dostala název školy/společnosti identifikátor vydavatele karet název vydavatele karet datum vydání identifikátor rozsahu, do kterého karta patří identifikátor dočasné karty, kterou tato karta nahrazuje datum vytvoření identifikátor uživatele, který kartu vytvořil datum poslední aktualizace identifikátor uživatele, který provedl poslední aktualizaci příznak určující, zda je karta smazaná

64


Tabulka card_range Tabulka rozsahů licenčních čísel karet. Atribut card_range_id range_start range_end preprinted

Povinný ano ano ano ano

check_letter_required

ano

issuer_organization_id external_id

ano ne


ano ano ano ano

deleted

ano

Význam unikátní umělý identifikátor počáteční číslo rozsahu koncové číslo rozsahu příznak určující, zda jsou karty tohoto rozsahu předtištěny příznak určující, zda čísla karet z tohoto rozsahu mají kontrolní písmena identifikátor vydavatele, kterému rozsah patří externí identifikátor používaný v původní aplikaci pro správu rozsahů datum vytvoření identifikátor uživatele, který rozsah vytvořil datum poslední aktualizace identifikátor uživatele, který provedl poslední aktualizaci příznak určující, zda je rozsah smazaný

Tabulka card_range_event Tabulka událostí zaznamenaných k rozsahům licenčních čísel. Atribut card_range_event_id event_date title description card_range_id

Povinný ano ano ano ne ano


ano ano ano ano

deleted

ano

Význam unikátní umělý identifikátor datum a čas události titulek události detailní popis události identifikátor rozsahu, ke kterému se událost vztahuje datum vytvoření identifikátor uživatele, který událost vytvořil datum poslední aktualizace identifikátor uživatele, který provedl poslední aktualizaci příznak určující, zda je událost smazaná

5.1. CCDB CORE

65

Tabulka verification_log Tabulka záznamů o vyžádaných ověření platností karet. Atribut verification_log_id card_number card_holder_name result card_id

Povinný ano ano ne ano ne

verified_on verified_by_user_id

ano ano

5.1.1.3

Význam unikátní umělý identifikátor zadané číslo karty k ověření zadané jméno držitele karty k ověření výsledek verifikace identifikátor karty, jejíž platnost byla při ověřování vyhodnocována datum a čas vyžádání verifikace identifikátor uživatele, který kartu ověřoval

DAO

Operace s daty doménových objektů jsou implementovány podle návrhového vzoru Data Access Object. Pro každou entitu je vytvořen DAO objekt, jenž poskytuje rozhraní pro CRUD operace2 nad danou entitou. Business logika aplikace pak volá tyto DAO objekty pro manipulaci s persistentními daty. Implementace DAO objektů používají třídu HibernateTemplate z knihovny Spring frameworku, která zjednodušuje práci s Hibernate API. Diagram tříd databázové vrstvy aplikace CCDB je zobrazen na obrázku 5.3.

Obrázek 5.3: Použití návrhového vzoru Data Access Object 2

Operace Create, Read, Update a Delete.

66


5.1.2

Vrstva business logiky

Vrstva business logiky3 aplikace CCDB definuje rozhraní pro komplexní operace vyvolávané uživateli přes veřejné rozhraní. Mohli bychom ji nazvat „mozkem“ aplikace, ve kterém probíhají všechny procesy zajišťující její funkčnost. Tato část aplikace se také stará o transakční zpracování prováděných operací a o jejich zabezpečení. Implementace business logiky je závislá na DAO objektech, které volá za účelem manipulace s persistentními daty. Jako vstupní parametry modifikačních operací (vytvoření nebo aktualizace entit) jsou použity tzv. hodnotové objekty – Value Objects. Ty obsahují údaje zadané v uživatelském rozhraní k CCDB. Implementační třídy business vrstvy je zvalidují a naplní doménový objekt, který pošlou příslušnému DAO k uložení do databáze. Vrácen je nově vytvořený nebo aktualizovaný doménový objekt. Pro příklad uvádím ukázku rozhraní logické vrstvy: public interface ManagementService { @Secured(Authority.CCDB2_CARD_CREATE) Card createCard(CardVo cardVo) throws ValidationException; @Secured(Authority.CCDB2_CARD_READ) List getCards(CardSearchCriteria searchCriteria, PagingParams pagingParams, SortParams sortParams); @Secured(Authority.CCDB2_CARDRANGE_UPDATE) CardRange updateCardRange(int cardRangeId, CardRangeVo cardRangeVo) throws ValidationException, InvalidIdentifierException; }

Zabezpečení Zabezpečení operací je řešeno na úrovni volání jednotlivých metod, jsou k tomu použity prostředky Spring Security frameworku. Každá metoda rozhraní business vrstvy má pomocí anotace @Secured definováno, jaká oprávnění musí autentizovaný uživatel mít, aby mohl danou operaci vykonat. Samotná autentizace uživatelů je realizována již při přístupu k servletům aplikace pomocí autentizačního schématu HTTP Basic4 , kdy jsou přihlašovací údaje uživatele zařazeny do hlavičky HTTP požadavku. Servletový filtr se pak postará o jejich zpracování následujícím způsobem: 1. Zadané uživatelské jméno je odesláno v požadavku na webovou službu systému Organization Manager, 2. Organization Manager vyhledá uživatele s daným uživatelským jménem ve své databázi, 3. pokud jej najde, vrátí v odpovědi své webové služby načtené detaily o daném uživateli, včetně seznamu přiřazených práv, 3 4

též označována jako vrstva aplikační logiky, logická vrstva nebo business vrstva popsaný v RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication"

5.1. CCDB CORE

67

4. CCDB porovná zadané heslo a heslo vrácené v detailech uživatele z OM, 5. CCDB úspěšně autorizuje uživatele k provedení vyžádané operace jen tehdy, vrátí-li se z OM načtené detaily o uživateli, zadané a skutečné heslo jsou shodné a daný uživatel má oprávnění, které je pro danou operaci vyžadováno (např. CCDB2_CARD_READ). Transakce Transakční bezpečnost je základním předpokladem pro zajištění konzistence dat. Všechny operace manipulující s persistentními daty musejí být vykonávány v rámci databázové transakce, která je v případě chybných stavů odvolána (rollback) a dojde k obnovení stavu databáze před zahájením dané operace. Transakčního zpracování je dosaženo nakonfigurováním deklarativního řízení transakcí pomocí AOP – Aspect Oriented Programming. Následujícím výpisem z XML konfigurace aplikačního kontextu je zaručeno, že zavoláním každé metody z třídy s anotací @Service (třídy business vrstvy) je spuštěna databázová transakce, která je potvrzena při opuštění dané metody. V případě, že je vyvolána specifikovaná výjimka, je transakce odvolána.

5.1.3

Webové služby

Jediným vnějším rozhraním ke komponentě CCDB Core jsou webové služby dvou různých architektur – REST a SOAP (tyto technologie jsou podrobněji popsány v kapitole 2.4). 5.1.3.1

REST

RESTful webové služby jsou zaměřeny na interní použití v rámci IAS platformy. Pomocí HTTP požadavků odeslaných na příslušné adresy zdrojů lze provádět CRUD operace nad jednotlivými entitami. Pro vytvoření RESTful webových služeb byla zvolena referenční implementace JAX-RS – Jersey5 , formátem předáváných strukturovaných dat je JSON. O mapování dat v tomto formátu na objekty v jazyce Java se stará knihovna Jackson6 . Implementace REST zdroje (REST resource) s metodou pro získávání informací o konkrétní kartě vypadá takto: 5 6

http://jersey.java.net http://jackson.codehaus.org

68


@Path("/cards/") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) @Component public class CardResource { @GET @Path("{cardId}") public CardTo getCard(@PathParam("cardId") int cardId) { Card card = managementService.getCardById(cardId); if (card == null) { throw new NotFoundException(); } return new CardToMapper().map(card); } }

Za asistence Jersey servletu lze pak údaje o kartě s ID=6 obdržet odesláním HTTP GET požadavku7 na adresu http://ccdb-core-base-url/cards/6. Obdržená odpověď může vypadat např. následovně: { "cardType": "ISIC", "issuedBy": "c01−issued−by", "printedName": "c01−name c01−surname", "birthDate": "1992−04−23", "email": "c01−[email protected]", "institutionName": "c01−institution−name", "issuerOrganizationId": 100025, "validFrom": "2010−09−01", "cardNumber": "S420111222330H", "temporaryCardId": null, "voided": false, "firstName": "c01−name", "lastName": "c01−surname", "validTo": "2011−12−31", "cardOrigin": "IMPORT", "issuedOn": 1288652400000, "cardId": 1, "cardStatus": "VALID", "temporary": false, "createdOn": 1290207600000, "createdByUserId": 1, "lastModifiedOn": 1290207600000, "lastModifiedByUserId": 1 }

Rozhraní metod webových služeb REST používá tzv. datové transfer objekty (DTO – Data Transfer Object), které obsahují atributy doménových objektů upravené do podoby vhodné pro přenos dat v distribuovaném prostředí. Ty se objevují i jako vstupní parametry, např. metoda pro vytvoření nového rozsahu licenčních čísel: 7

HTTP GET požadavky lze generovat přímo přes internetový prohlížeč

5.1. CCDB CORE

69

@Path("/cardRanges/") @Consumes(MediaType.APPLICATION_JSON) @Produces(MediaType.APPLICATION_JSON) @Component public class CardRangeResource { @POST public Response addCardRange(@Context UriInfo uriInfo, CardRangeTo cardRangeTo) throws ValidationException { CardRange cardRange = managementService.createCardRange( new CardRangeVoMapper().map(cardRangeTo)); URI uri = uriInfo.getAbsolutePathBuilder().path( String.valueOf(cardRange.getCardRangeId())).build(); return Response.created(uri).build(); } }

5.1.3.2

SOAP

Webové služby založené na protokolu SOAP jsou vystaveny na veřejně přístupné adrese a jejich popis v jazyce WSDL je rovněž dostupný pro případné volající. Jelikož jsou obsahem SOAP zpráv data formátovaná v XML, je jejich struktura nejprve definovaná pomocí XML schématu. Např. pro verifikační službu je formát požadavků a odpovědí stanoven obsahem XSD (XML Schema Definition) souboru: <s:schema xmlns:s="http://www.w3.org/2001/XMLSchema" targetNamespace="http://verify.isic.org/" xmlns:tns="http://verify.isic.org/" elementFormDefault="qualified"> <s:element name="VerifyCard"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="CardNumber" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="ProGID" type="s:string" /> <s:element minOccurs="0" maxOccurs="1" name="Password" type="s:string" /> <s:element name="VerifyCardResponse"> <s:complexType> <s:sequence> <s:element minOccurs="0" maxOccurs="1" name="VerifyCardResult" type="s:string" />

Takto definované struktury zpráv používaných webovými službami jsou zařazeny do statického formálního popisu služeb v jazyce WSDL. Následně byly z definovaného XML schématu vygenerovány Java třídy zavoláním překladače xjc, který je součástí JAXB (Java Architecture for XML Binding). Tato operace proběhla před vlastním sestavením aplikace zavoláním JAXB Maven pluginu. Vygenerované třídy

70


obsahují anotace definované JAXB specifikací, ty umožňují konkrétní JAXB implementaci mapovat strukturovaná data v XML na instance těchto tříd. Pro ukázku uvádím příklad vygenerované třídy, která je použita pro mapování požadavků odeslaných na webovou službu VerifyCard8 : @XmlAccessorType(XmlAccessType.FIELD) @XmlType(name = "", propOrder = { "cardNumber", "proGID", "password" }) @XmlRootElement(name = "VerifyCard") public class VerifyCard { @XmlElement(name = "CardNumber") protected String cardNumber; @XmlElement(name = "ProGID") protected String proGID; @XmlElement(name = "Password") protected String password; }

O zpracování přijatých požadavků na SOAP webové služby se stará MessageDispatcherServlet z knihovny Spring-WS, která je součástí Spring frameworku. Webové služby jsou implementovány jako tzv. endpointy, které představují cílové konzumenty požadavků odeslaných na jednu konkrétní URL. Následuje výtah použití Spring-WS anotací pro deklaraci endpointu služby pro ověřování platnosti karet: @Endpoint public class VerificationSrvEndpoint { @PayloadRoot(localPart = "VerifyCard", namespace = "http://verify.isic.org/") public VerifyCardResponse verifyCard(final VerifyCard verifyCard) { // process request, return response } }

5.1.4

Struktura tříd

Třídy jsou v Javě organizovány do tzv. balíků (packages), které obsahují třídy patřící do stejné kategorie nebo poskytující podobnou funkčnost. V CCDB Core jsou použity tyto balíky: net.orchitech.ias.ccdb2.core.model třídy doménových objektů, net.orchitech.ias.ccdb2.core.model.search třídy zapouzdřující parametry pro vyhledávání doménových objektů, 8 Název třídy, resp. název elementu v XML schématu, není sémantický přesný, vhodnější by bylo např. VerifyCardRequest. Nicméně přejmenovat tento parametr nebylo možné, porušila by se tím zpětná kompatibilita s webovými službami staré CCDB.

5.2. CCDB WEB UI

71

net.orchitech.ias.ccdb2.core.model.vo hodnotové objekty entit, net.orchitech.ias.ccdb2.core.config třídy s konfiguračními konstantami definující vlastnosti doménových objektů a uživatelská práva, net.orchitech.ias.ccdb2.core.dao DAO rozhraní pro jednotlivé doménové objekty, net.orchitech.ias.ccdb2.core.dao.impl třídy implementující DAO rozhraní, net.orchitech.ias.ccdb2.core.service rozhraní business vrstvy, net.orchitech.ias.ccdb2.core.service.impl třídy implementující business vrstvu, net.orchitech.ias.ccdb2.core.service.validator objekty vykonávající komplexní validaci při modifikačních operacích entit, net.orchitech.ias.ccdb2.core.utils pomocné třídy, net.orchitech.ias.ccdb2.ws.resource definice zdrojů RESTful webových služeb, net.orchitech.ias.ccdb2.ws.mapper třídy mapující transfer objekty na doménové a hodnotvé objekty, net.orchitech.ias.ccdb2.ws.to transfer objekty používané v rozhraní RESTful webových služeb, net.orchitech.ias.ccdb2.ws.endpoint endpointy SOAP webových služeb.

5.2

CCDB Web UI

Uživatelské rozhraní pro správu centrální databáze je tvořeno samostatnou webovou aplikací, která s jádrem CCDB komunikuje pomocí RESTful webových služeb. Stejně jako v případě CCDB Core je základním stavebním kamenem této webové aplikace IoC kontejner Spring frameworku. Pro implementaci prezentační vrstvy (GUI) byl použit Vaadin framework (více v kapitole 2.5).

Vrstva aplikační logiky Business logika této aplikace pro správu centrální databáze karet spočívá v sestavování a odesílání požadavků na RESTful webové služby CCDB Core. Informace prezentované v uživatelském rozhraní jsou naopak tvořeny z odpovědí těchto služeb, které obsahují data transfer objektů definovaných v CCDB Core. Komunikace s webovými službami je implementována využitím rozhraní knihovny Jersey, základní třídou zapouzdřující interakci se vzdáleným REST zdrojem je třída WebResource. Ta se stará o odesílání požadavků, zpracování přijatých odpovědí a mapování dat v JSON formátu na klasické POJO třídy. Zabezpečení aplikace, tj. přihlášení a odhlášení uživatele do/ze systému, je řešeno stejným způsobem jako v CCDB Core, pro autentizaci uživatelů je voláno RESTful rozhraní systému Organization Manager.

72


Prezentační vrstva Základním konceptem prezentační vrstvy postavené na frameworku Vaadin je jeho třída Application, jejíž instance je předána jako parametr servletu propojujícího Vaadin aplikaci se servletovým kontejnerem Tomcat – jedná se o třídu ApplicationServlet. V objektu třídy Application je manipulováno s okny, formuláři, tabulkami, grafickými rozloženími (layouty) a dalšími komponentami webového uživatelského rozhraní podobným způsobem, jakým jsou tyto prvky používány v kódu klasické desktopové aplikace. Import z XLS souborů Zajímavou částí implementace uživatelského rozhraní je realizace importu karet z XLS souborů. K tomtu účelů bylo využito jednoduchého API9 knihovny jXLS10 , která poskytuje prostředky pro vytváření XLS souborů pomocí šablon a čtení dat z XLS souborů do objektové podoby jazyka Java. Při zpracovávání souborů ve formátu XLS hraje hlavní roli objekt třídy XLSReader, který je nakonfigurován pomocí XML souboru. Pro import dat karet z XLS vypadá tato konfigurace následovně: <workbook> <worksheet name="Cards"> <section startRow="0" endRow="0" /> <section startRow="1" endRow="1"> <mapping row="1" col="0">entry.cardNumber <mapping row="1" col="1">entry.cardType <mapping row="1" col="2">entry.cardHolderFirstName <mapping row="1" col="3">entry.cardHolderLastName <mapping row="1" col="4">entry.dateOfBirth <mapping row="1" col="5">entry.email <mapping row="1" col="6">entry.cardIssuerName <mapping row="1" col="7">entry.institutionName <mapping row="1" col="8">entry.validFrom <mapping row="1" col="9">entry.validTo <mapping row="1" col="10">entry.issuedOn <mapping row="1" col="11">entry.issuedBy <mapping row="1" col="12">entry.status <mapping row="1" col="13">entry.temporary

Touto cestou je definováno mapování jednotlivých sloupců v XLS souboru na atributy Java objektu, v tomto případě hodnotového objektu CardVo. 9 10

Application Programming Interface, rozhraní komponent pro programování aplikací. http://jxls.sourceforge.net

5.3. MIGRAČNÍ NÁSTROJ

5.3

73

Migrační nástroj

Důležitou částí projektu, bez které by nebylo možné přejít ze starého systému pro evidenci karet na nový, je migrace dat z databáze CCDB do databáze CCDB2. Jelikož jsou existující data do značné míry nekonzistentní a stará evidence karet postrádá vlasnosti správně navržené databáze, je operace převedení starých dat do nové struktury relativně složitá. Proto není možné ji realizovat jednoduchým vyexportováním dat z databáze CCDB a jejich importem do databáze CCDB2 na úrovni ručně psaných a modifikovaných SQL skriptů. Bylo rozhodnuto, že migrace bude provedena samostatnou aplikací, která zajistí správnou transformaci dat, případné odfiltrování neplatných záznamů a vytvoření statistiky úspěšnosti migrace. Architektura aplikace Migrace dat byla implementována na platformě J2SE jako standardní konzolová aplikace bez grafického uživatelského rozhraní, jejíž spouštění je řízeno z příkazové řádky. Aplikace rovněž využívá základních výhod Spring frameworku jako jsou Spring JDBC (abstrakce JDBC rozhraní), podpora transakčního zpracování a Inversion-ofControl kontejner. Samotný proces migrace je rozdělen na dílčí úlohy realizující migraci entit jednoho konkrétního typu. Ty lze spouštět samostatně uvedením příslušného paramteru při spuštění aplikace. Struktura tříd implementujících jednotlivé migrační úlohy je znázorněna na obrázku 5.4.

Obrázek 5.4: Diagram tříd reprezentujících úlohy migrace

74


Manipulace s daty Pro přístup k datům v jednotlivých databázích je využíváno abstrakce JDBC rozhraní poskytované Spring frameworkem – třída JdbcTemplate. Na rozdíl od databázové vrstvy v CCDB Core není použito žádné objektově relační mapování (Hibernate), k načteným datům z databáze je přistupováno přes rozhraní SqlRowSet, které je rovněž součástí Spring JDBC frameworku. Veškeré databázové operace vykonané v průběhu migrace jsou zapouzdřeny do jedné velké databázové transakce, aby mohly být v případě vyskytnuvších se problémů hromadně zrušeny. Zároveň lze pomocí parametru aplikace spustit migraci v režimu simulace, kdy je bez ohledu na úspěšnost provedených operací transakce vždy zrušena (rollback). Této možnosti je využíváno v průběhu testování migrace.

Kapitola 6

Závěr Cílem práce bylo navrhnout a implementovat informační systém pro správu studentských karet, který by nahradil existující nedokonalé řešení a doplnil jej o uživatelsky přívětivé grafické rozhraní pro administraci evidovaných dat. Současná centrální databáze se po důkladné analýze ukázala být značně problematická, zejména díky chybnému návrhu relačního modelu a nekonzistenci obsažených dat. Dalším problémem, který tato práce adresuje, proto je i proces migrace existujících dat do nové centrální databáze karet. Vzhledem k nepostradatelnosti centrální databáze ISIC karet a k její důležité roli v obchodních aktivitách společnosti ISIC Association Services byl velký důraz kladen na analýzu starého a správný návrh nového systému. Na základě těchto procesů byly implementovány tři samostatné aplikace – jádro centrální databáze poskytující rozhraní ostatním komponentám přes webové služby, webové administrační rozhraní a konzolová aplikace pro migraci dat. Všechny tyto komponenty byly postaveny na platformě Java a s využitím populárního aplikačního frameworku Spring. Díky častým konzultacím se zákazníkem ve fázi návrhu nedošlo v pozdějších fázích ke změně požadavků na implementovaný systém. Očekávám nicméně, že se funkční záběr centrální databáze ISIC karet bude v budoucnu nadále rozšiřovat o nové prvky, důraz byl proto kladen na udržovatelnost a rozšiřitelnost systému. Úspěšnost projektu bude vyhodnocena až po nasazení do ostrého provozu, v době psaní této práce byly aplikace testovány pouze interně bez zpětné vazby od zákazníka. Je tedy pravděpodobné, že se při akceptačních testech objeví problémy a nedokonalosti, které bude nutné v nejbližší době dále řešit. Přesto považuji cíl této práce za úspěšně splněný. Největší přínos tohoto projektu vidím v načerpání cenných zkušeností se zásahem do reálného a funkčního informačního prostředí velké společnosti, jejíž systémy využívají partneři po celém světě. Věřím, že budou s výsledky mé práce spokojeni.

75

76

KAPITOLA 6. ZÁVĚR

Literatura [1] ARLOW, J. – NEUSTADT, I. UML2 a unifikovaný proces vývoje aplikací. Brno : Computer Press a.s., 2007. ISBN 978-80-251-1503-9. [2] BAUER, C. – KING, G. Java Persistence with Hibernate. Greenwich (Connecticut) : Manning Publications Co., 2006. ISBN 1932394885. [3] Vaadin Ltd. Vaadin Framework [online]. 2010. [cit. 3. 1. 2011]. Dostupné z: http: //vaadin.com. [4] Oracle. The Java EE 5 Tutorial [online]. 2010. [cit. 3. 1. 2011]. původně publikovala Sun Microsystems v roce 2007. Dostupné z: http://download.oracle.com/javaee/ 5/tutorial/doc/. [5] POKORNÝ, J. – HALAŠKA, I. Databázové systémy. Praha : Vydavatelství ČVUT, druhé vydání, 2003. ISBN 80-01-02789-9. [6] SNELL, J. – TIDWELL, D. – KULCHENKO, P. Programming Web Services with SOAP. Sebastopol, CA : O’Reilly Media, 2001. ISBN 978-0-596-00095-0. [7] Spring Source. The Spring Framework – Reference Documentation [online]. [cit. 3. 1. 2011]. Dostupné z: http://static.springframework.org/spring/docs/2. 5.x/reference. [8] W3C. Web Services Architecture [online]. 2004. [cit. 3. 1. 2011]. Dostupné z: http: //www.w3.org/TR/ws-arch/. [9] WALLS, C. – BREIDENBACH, R. Spring in Action. Greenwich (Connecticut) : Manning Publications Co., 2007. ISBN 1-933988-13-4. [10] Wikipedia. Wikipedia – zdroj obecných informací [online]. //wikipedia.org.

77

Dostupné z: http:

78

LITERATURA

Příloha A

Uživatelská příručka Přihlášení Pro práci se systémem je nutné se přihlásit. Na úvodní stránce zadejte své uživatelské jméno a heslo a potvrďte formulář kliknutím na tlačítko Login. Pokud jste zadali správné přihlašovací údaje, zobrazí se úvodní strana a hlavní menu aplikace v horní části stránky. Po ukončení práce s aplikací je doporučeno se odhlásit, přestože Vás systém po určité době nečinnosti sám automaticky odhlásí. Odhlásíte se kliknutím na odkaz Logout pod hlavním menu.

Správa karet Prohlížení karet V hlavním menu klikněte na ikonku označnou jako Cards, v hlavní části stránky se zobrazí seznam evidovaných karet a formulář pro zadání vyhledávacích kritérií. Pro zobrazení záznamů majících konkrétní parametry tyto vyplňte do filtru tabulkou a potvrďte. Tabulku karet můžete řadit podle jednotlivých parametrů kliknutím na příslušné záhlaví sloupce. Rovněž můžete pořadí sloupců měnit kliknutím na jejich záhlaví a přetažením na požadavou pozici (Drag & Drop). Vybráním jednoho řádku tabulky se v dolní části stránky zobrazí detailní informace o kartě a akční tlačítka. Pomocí těchto tlačítek můžete kartu zrušit nebo smazat máte-li potřebná oprávnění. Po kliknutí na akční tlačítka je před provedením dané operace zobrazen potvrzovací dialog.

Import karet z XLS V hlavním menu klikněte na ikonku označenou jako XLS Import, zobrazí se Vám jednoduchý formulář pro zvolení souboru na Vašem PC. Vyberte soubor ve formátu XLS a klikněte na tlačítko Submit. Po zpracování odeslaného souboru je zobrazena statistika vytvořených, aktualizovaných a ignorovaných záznamů.

79

80

PŘÍLOHA A. UŽIVATELSKÁ PŘÍRUČKA

Ověření platnosti karty V hlavním menu vyberte položku Card Verification, zobrazí se Vám formulář s textovým polem pro zadání čísla ověřované karty. Vyplňte číslo karty (můžete vyplnit číslo v plném formátu, např. S 420 123 456 789 G nebo pouze licenční číslo, tj. 420123456789) a formulář potvrďte. Po zpracování požadavku je zobrazen výsledek verifikace karty, v případě, že byla karta podle zadaného čísla nalezena, je rovněž zobrazeno datum její expirace.

Správa rozsahů licenčních čísel Prohlížení rozsahů Kliknutím na položku Card Ranges v hlavním menu systém zobrazí tabulku se seznamem evidovaných rozsahů. Zároveň je zobrazen formulář pro vyplnění parametrů vyhledávání, kterými můžete omezit množinu zobrazovaných dat. Vybráním konkrétního řádku tabulky se v dolní části stránky zobrazí detailní informace o zvoleném rozsahu a sada akčních tlačítek. Pomocí těchto tlačítek můžete rozsah upravit či smazat.

Vytvoření nového rozsahu V hlavním menu klikněte na ikonku popsanou jako Create Card Range. Pod seznamem rozsahů je zobrazen prázdný formulář s parametry vytvářeného rozsahu. Po jejich vyplnění potvrďte vytvoření rozsahu kliknutím na Create. Zrušit operaci přidání rozsahu můžete kliknutím na Cancel.

Editace rozsahu Po zvolení konkrétního rozsahu v seznamu evidovaných rozsahů klikněte na tlačítko Edit v části stránky s detailními informacemi o rozsahu. V zobrazeném formuláři upravte hodnoty atributů rozsahu a klikněte na Save. Zrušit editaci můžete kliknutím na Cancel.

Track & Trace Prohlížení událostí Stránku se seznamem zaznamenaných událostí k rozsahům licenčních čísel zobrazíte kliknutím na položku Track & Trace v hlavním menu. Výběrem konkrétního řádku tabulky systém zobrazí detailní parametry zvolené události a akční tlačítko pro úpravu a smazání události.

Vytvoření nové události V hlavním menu klikněte na ikonku popsanou jako Record Event. Pod seznamem událostí je zobrazen prázdný formulář pro zadání parametrů nové události. Po jejich vyplnění klikněte na tlačítko Submit, vytvoření nového záznamu do Track & Trace evidence můžete zrušit kliknutím na Cancel.

81

Editace události Po zvolení konkrétní události v seznamu evidovaných událostí klikněte na tlačítko Edit v části stránky s detailními informacemi o události. V zobrazeném formuláři upravte hodnoty parametrů události a klikněte na Save. Zrušit editaci můžete kliknutím na Cancel.

82

PŘÍLOHA A. UŽIVATELSKÁ PŘÍRUČKA

Příloha B

Obsah přiloženého CD Na přiloženém CD se nacházejí soubory v této adresářové struktuře:

|-| |-| \--

dist \-- core-sql doc \-- src src |-- ccdb2 |-- ccdb2-ui \-- migration

Sestavené aplikace ve formátu .war a .jar SQL skripty pro inicializaci databáze systému CCDB Core Tento dokument Zdrojové kódy tohoto dokumenut ve formátu LATEX Zdrojové kódy aplikace CCDB Core Zdrojové kódy aplikace CCDB Web UI Zdrojové kódy migrační aplikace

83

Informační systém pro správu mezinárodních studentských identifikačních karet (ISIC)

Recommend Documents