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

Transkript

1 Č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

2 iv

3 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.

4 vi

5 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

6 viii

7 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

8 x

9 Obsah 1 Úvod 1 2 Použité technologie Java EE Spring Framework Hibernate Webové služby Vaadin PostgreSQL Tomcat Maven Úvodní studie Úvod do problematiky vydávání karet Výdej karet licenčními autoritami CardMaster.NET Střední školy Univerzitní karty Rozbor evidence karet Identifikační karty ISIC Čísla karet Platnost karet Vydavatelé karet Rozsahy licenčních čísel Současný stav Deklarace záměru Rozbor a definice požadavků Uživatelské role Funkční požadavky Správa karet Správa rozsahů Verifikace karet Track & Trace Synchronizace s CardMaster.NET Migrace dat xi

10 xii OBSAH Obecné požadavky na funkčnost Nefunkční požadavky Případy užití nejvyšší úrovně Návrh architektury Analýza rizik Š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 Slovník pojmů Analýza a návrh řešení Analýza současného systému Existující data Tabulka SerialNumbers Tabulka CardsIssued Tabulka Issuers Tabulka Providers Tabulka logupdates Identifikované problémy současné evidence Webové služby CCDB UpdateCardV VerifyCard UpdateCard Identifikované nedostatky webových služeb Synchronizace s CardMaster.NET Závěr analýzy Konceptuální datový model Popis modelu Entity Vztahy mezi entitami Popis případů užití Strojové rozhraní UC001 - Vytvoření nové karty UC002 - Ověření platnosti karty Grafické uživatelské rozhraní UC101 Přihlášení do systému UC102 Odhlášení ze systému UC103 Prohlížení seznamu karet UC104 Zobrazení detailu karty UC105 Smazání karty UC106 Zrušení karty

11 OBSAH xiii UC107 Ověření platnosti karty UC108 Import karet z XLS UC109 Prohlížení seznamu rozsahů UC110 Vytvoření nového rozsahu UC111 Editace rozsahu UC112 Smazání rozsahu UC113 Prohlížení seznamu událostí UC114 Zaznamenání nové události UC115 Editace události UC116 Smazání události Implementace CCDB Core Databázová vrstva Doménové objekty Fyzický datový model DAO Vrstva business logiky Webové služby REST SOAP Struktura tříd CCDB Web UI Migrační nástroj Závěr 75 Literatura 77 A Uživatelská příručka 79 B Obsah přiloženého CD 83

12 xiv OBSAH

13 Seznam obrázků 2.1 Přehled komponent Spring frameworku Existující způsoby vydávání karet Případy užití nejvyšší úrovně Diagram komponent Diagram nasazení Diagram aktivit zpracování požadavku webovou službou UpdateCardV Diagram aktivit zpracování požadavku webovou službou VerifyCard Tok dat při synchronizaci karet z CardMaster.NET Konceptuální datový model Diagram aktivit pro UC001 Vytvoření nové karty 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 xv

14 xvi SEZNAM OBRÁZKŮ

15 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

16 2 KAPITOLA 1. ÚVOD

17 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 CCDB Java EE Java Platform, Enterprise Edition (zkráceně Java EE 1 ) 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 EJB 2. 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 ve svých dřívějších verzích byla také označována jako Java 2 Platform, Enteprise Edition nebo jen J2EE 2 Enterprise JavaBeans jedna ze specifikací Java EE určená k zapouzdření logiky na straně serveru. 3

18 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 Česky bychom ji mohli nazvat jako vsazování závislostí. 4 Objekty vytvářené v aplikačním kontextu frameworku se nazývají Beans.

19 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.

20 6 KAPITOLA 2. POUŽITÉ TECHNOLOGIE 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 objekty 6 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 HTTP 7.[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. 7 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.

21 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ř. 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é aplikace 8, 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í.

22 8 KAPITOLA 2. POUŽITÉ TECHNOLOGIE 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.

23 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 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 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

24 10 KAPITOLA 3. ÚVODNÍ STUDIE CardMaster.NET 2 a speciální tiskárnu štítků na karty 3. 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 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 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 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 zkráceně CM.NET, dostupná na 3 Používají se termotransferové tiskárny pro tisk na prázdné etikety

25 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.

26 12 KAPITOLA 3. ÚVODNÍ STUDIE 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 ), 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 ), 6. průkazová fotografie držitele, 7. ochranné prvky a loga Čí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 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

27 3.2. ROZBOR EVIDENCE KARET 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 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 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 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

28 14 KAPITOLA 3. ÚVODNÍ STUDIE 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 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.

29 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 ). 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ě 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.

30 16 KAPITOLA 3. ÚVODNÍ STUDIE 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 OM 4, 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 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 ), typ karty, osobní údaje držitele karty (jméno, příjemní, datum narození, ), platnost karty (viz ), 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ů

31 3.5. ROZBOR A DEFINICE POŽADAVKŮ 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 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í CRUD 5 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

32 18 KAPITOLA 3. ÚVODNÍ STUDIE 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 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 ) 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 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ů karet 6. 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.

33 3.5. ROZBOR A DEFINICE POŽADAVKŮ 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 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 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 Nefunkční požadavky Základní nefunkční požadavky nového IS pro evidenci ISIC karet jsou:

34 20 KAPITOLA 3. ÚVODNÍ STUDIE 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 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 Rozmístění modulů systému na hardwarových zdrojích zachycuje diagram nasazení na obr 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.

35 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í.

36 22 KAPITOLA 3. ÚVODNÍ STUDIE 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ý.

37 3.8. ANALÝZA RIZIK 23 Obrázek 3.4: Diagram nasazení

38 24 KAPITOLA 3. ÚVODNÍ STUDIE 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 procesní 30% kritický Chybná analýza procesní 10% katastrofální Změna požadavků procesní 5% kritický HW nebo SW nekompatibilita technologická 1% kritický Vada na HW nebo SW při vývoji technologická 5% marginální Nedostatečná znalost technologií implementační 15% marginální Odklon od požadavků implementační 3% kritický Neoprávněný přístup k datům bezpečnostní 4% kritický Š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: 30% Dopad: 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%

39 3.8. ANALÝZA RIZIK 25 Dopad: 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: 5% Dopad: 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: 1% Dopad: 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.

40 26 KAPITOLA 3. ÚVODNÍ STUDIE Řešitel problémů: realizátor Pravděpodobnost výskytu: 5% Dopad: 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: 15% Dopad: 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: 3% Dopad: 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

41 3.9. SLOVNÍK POJMŮ 27 Pravděpodobnost výskytu: 4% Dopad: kritický 3.9 Slovník pojmů Pojmy používané v textu práce jsou pro přehlednost shrnuty v následující tabulce. Termín Význam WYSETC World Youth Student and Educational Travel Confederation, nezisková organizace vlastnící ISIC licence. IAS International Association Services, dceřiná společnost WYSETC založena za účelem řízení distribuce průkazů ISIC. ISIC International Student Identity Card, mezinárodní studentská identifikační karta. ITIC International Teacher Identity Card, mezinárodní identifikační karta pro učitele. IYTC International Youth Travel Card, mezinárodní identifikační karta pro mládež do 26 let. SCHOLAR Identifikační karta pro žáky základních škol. STAFF Zaměstnanecká identifikační karta. WYSETC karty Všechny identifikační karty vydávané ISIC Association s licencí patřící společnosti WYSETC, také označovány jen jako ISIC karty. Licenční autorita 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ě. CCDB Central Card Database, centrální databáze WYSETC karet spravovaná společností IAS. CCDB2 Nový IT systém pro evidenci a správu WYSETC karet, který nahrazuje původní CCDB. NCDB National Card Database, lokální databáze karet spravovaná licenční autoritou v jedné konkrétní zemi. CardMaster.NET B2B aplikace pro vydávání karet na prodejních místech u nasmlouvaných partnerů. identifikační číslo karty Číslo karty ve formátu S H. sériové číslo karty Viz. identifikační číslo karty. licenč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.

42 28 KAPITOLA 3. ÚVODNÍ STUDIE 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.

43 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 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 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ů 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íč: (OrderNr, LineNrID, LineNr) Atribut Datový typ Význam, vlastnosti a četnosti hodnot CompanyID varchar(10) 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

44 30 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ FirstNo varchar(12) počáteční licenční číslo rozsahu 0 null všechny hodnoty mají formát 12ciferného čísla LastNo varchar(12) koncové licenční číslo rozsahu 0 null všechny hodnoty mají formát 12ciferného čísla FirstSerialNo varchar(20) 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ř. S LastSerialNo varchar(20) 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ř. S EntryDate datetime datum a čas vytvoření rozsahu 0 null RangeID varchar(25) identifikátor rozsahu v původní aplikaci pro správu rozsahů 0 null všechny hodnoty mají délku 25 znaků např. ISIC companyname varchar(30) obsahuje pouze null hodnoty OrgID varchar(20) obsahuje pouze null hodnoty OrderNr varchar(20) význam neznámý LineNrID int význam neznámý LineNr int význam neznámý ItemNo varchar(20) význam neznámý Description varchar(30) textový popis rozsahu Qty decimal(10,2) velikost rozsahu duplicitní informace, lze zjistit z FirstNo a LastNo CardType varchar(1) typ karet v rozsahu 312 null obsahuje hodnoty S, T, Y, H, E IsExpired tinyint příznak určující, zda je rozsah zastaralý Expired tinyint příznak určující, zda je rozsah zastaralý Status tinyint obsahuje pouze null hodnoty HasCheckLetter tinyint příznak určující, zda čísla karet z rozsahu mají kontrolní písmena obsahuje pouze hodnoty 0

45 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 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 Tabulka CardsIssued Tato tabulka obsahuje ty nejdůležitější informace data vydaných karet a jejich držitelů. Počet záznamů: Primární klíč: CardNumber Atribut Datový typ Význam, vlastnosti a četnosti hodnot CardNumber char(12) 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í CardType char(1) typ karty (typové písmeno) null 427 E 3648 H T Y S CardName varchar(30) celé jméno držitele karty tak, jak je natisknuto na kartě 5 null prázdný řetězec hodnota o maximálně dvou znacích

46 32 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ StudiesAt varchar(30) název školy, na které je držitel studentem/učitelem 6 null prázdný řetězec hodnota o maximálně dvou znacích DOB smalldatetime datum narození držitele 19 null DateOfBirth char(10) zformátované datum narození držitele 19 null 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) EXP smalldatetime datum expirace karty 13 null ExpireDate char(10) datum expirace ve formátu dd/mm/yyyy hodnoty duplikují informaci v EXP IssuedBy char(10) název vydavatele karty 43 null prázdný řetězec RangeID char(25) 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ů OrgID char(4) identifikátor vydavatele karty v OM null unikátních číselných hodnot IssGID char(9) Issuer Global ID, globální identifikátor vydavatele, který kartu vydal null 79 unikátních hodnot, většina ve shodném formátu (např. I ) Status varchar(5) poznámka ke stavu karty null 8159 DtFix IssueDate smalldatetime datum vydání karty 349 null Remark varchar(50) poznámka

47 4.1. ANALÝZA SOUČASNÉHO SYSTÉMU null LastUpdate datetime datum a čas poslední aktualizace záznamu null IssueCount tinyint význam neznámý UpdCount tinyint význam neznámý Zjištěné vztahy a statistiky: karet nemá vyplněn atribut IssGID ani OrgID záznamů má vyplněno OrgID, ale nemá IssGID. Všechny karty s LastUpdate > 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 ) 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ů: 98 Primární klíč: IssGID Atribut Datový typ Význam, vlastnosti a četnosti hodnot IssGID varchar(9) 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 Password varchar(50) heslo přidělené vydavateli pro upload karet do CCDB 8 null 86 unikátních hodnot hesla jsou uvedena v textové podobě OrgID varchar(4) identifikátor licenční autority, pod kterou vydavatel patří 7 null 57 unikátních hodnot v číselném formátu Organisation varchar(50) název vydavatele 8 null 3 hodnoty použity dvakrát, jinak jsou unikátní

48 34 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Folder varchar(256) význam neznámý 34 null 10 unikátních hodnot formát shodný jako u IssGID Target varchar(10) význam neznámý obsahuje pouze null hodnoty Status char(1) význam neznámý 62 null 2 T 3 U 31 Y CurrentFile varchar(50) význam neznámý obsahuje pouze null hodnoty Contact varchar(50) jméno kontaktní osoby 86 null varchar(50) kontaktní osoby 91 null Tel varchar(50) telefon kontaktní osoby 92 null Comment varchar(50) textová poznámka 75 null Country varchar(50) název země, ve které vydavatel působí 7 null Yearly int význam neznámý 50 null DefaultAction varchar(20) význam neznámý 41 null 52 Notify 5 Upload SplitType char(11) význam neznámý 89 null Notify varchar(150) 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 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.

49 4.1. ANALÝZA SOUČASNÉHO SYSTÉMU 35 Počet záznamů: 110 Primární klíč: ProID Atribut Datový typ Význam, vlastnosti a četnosti hodnot ProID char(11) 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 Password varchar(20) heslo přidělené poskytovateli pro verifikaci karet v CCDB 0 null hesla jsou uvedena v textové podobě Authorisation varchar(10) úroveň autorizace pro verifikační službu 0 null 5 SUMMARY 31 FULL 74 YESNO Profile varchar(10) význam neznámý 0 null 2 STRICT 108 GENERAL Status varchar(10) význam neznámý 91 null 1 OBSOLETE 18 ACTIVE Comment varchar(255) 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.

50 36 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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ů: Primární klíč: ID Atribut Datový typ Význam, vlastnosti a četnosti hodnot ID int umělý identifikátor záznamu IssGID varchar(9) Issuer Global ID, globální identifikátor vydavatele, který webovou službu zavolal 0 null OrgID char(4) identifikátor organizace obsahuje pouze null hodnoty ts timestamp časové razítko zavolání webové služby UpdateCard 0 null minimální hodnota je :51:24 CardNumber char(20) číslo karty tak, jak bylo zadáno jako parameter webové služby 0 null znaková hodnota znaková hodnota znaková hodnota 35 15znaková hodnota hodnot nezačíná typovým písmenem karty, ostatní jej mají Result varchar(256) textový návratový kód webové služby 0 null všechny hodnoty obsahují text success Zjištěné vztahy a statistiky: Čísla karet z tabulky CardsIssued lze najít v hodnotách CardNumber v této tabulce 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 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,

51 4.1. ANALÝZA SOUČASNÉHO SYSTÉMU 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.

52 38 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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-SQL 1. Následuje popis jednotlivých dostupných webových služeb 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 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.

53 4.1. ANALÝZA SOUČASNÉHO SYSTÉMU 39 Obrázek 4.1: Diagram aktivit zpracování požadavku webovou službou UpdateCardV2

54 40 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ #1#Success - Card Added to CCDB #2#Success - Card Updated in CCDB #9#Failure - Invalid IssGID/Password combination #7#Invalid Card number format #7#Invalid 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 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.

55 4.1. ANALÝZA SOUČASNÉHO SYSTÉMU 41 Obrázek 4.2: Diagram aktivit zpracování požadavku webovou službou VerifyCard

56 42 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 UpdateCardV 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 Synchronizace s CardMaster.NET V současné době je přes B2B 2 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 Zkratka pro Business to Business, označuje komerční aktivity mezi firmami, do kterých nejsou zapojeni koncoví spotřebitelé služeb či zbočí.

57 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 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 CCDB 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 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í

58 44 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ Obrázek 4.4: Konceptuální datový model

59 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ů 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, 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 standardní vydaná karta. CardRange 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.

60 46 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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.

61 4.3. POPIS PŘÍPADŮ UŽITÍ 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 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 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 Průběh zpracování odeslaného požadavku na vytvoření karty je znázorněn na obr Vstupní podmínky: Žádné. Aktéři: 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 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.

62 48 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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-

63 4.3. POPIS PŘÍPADŮ UŽITÍ 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 Vstupní podmínky: Žádné. Aktéři: 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 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í 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é.

64 50 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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: Přihlášený uživatel. Aktéři: 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: 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: Přihlášený uživatel s právem pro prohlížení karet. Aktéři: 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.

65 4.3. POPIS PŘÍPADŮ UŽITÍ 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ů 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: Přihlášený uživatel s právem pro prohlížení karet. Aktéři: 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: 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: Přihlášený uživatel s právem pro mazání karet. Aktéři: 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.

66 52 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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: Přihlášený uživatel s právem pro mazání karet. Aktéři: 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 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: Přihlášený uživatel s právem pro verifikaci karet. Aktéři: 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.

67 4.3. POPIS PŘÍPADŮ UŽITÍ 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: Přihlášený uživatel s právem pro vytváření karet. Aktéři: 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 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ů.

68 54 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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ů 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: Přihlášený uživatel s právem pro vytváření rozsahů. Aktéři: 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.

69 4.3. POPIS PŘÍPADŮ UŽITÍ 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: Přihlášený uživatel s právem pro editaci rozsahů. Aktéři: 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 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: Přihlášený uživatel s právem pro mazání rozsahů. Aktéři: Administrátor IAS

70 56 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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 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: Přihlášený uživatel s právem pro prohlížení událostí. Aktéři: 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ů 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: Přihlášený uživatel s právem pro vytváření událostí. Aktéři: Administrátor IAS, Výrobce karet.

71 4.3. POPIS PŘÍPADŮ UŽITÍ 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 UC115 Editace události Stručný popis: Zaznamenané události k rozsahům čísel lze dodatečně upravit. Vstupní podmínky: Přihlášený uživatel s právem pro editaci událostí. Aktéři: Administrátor IAS, Výrobce karet. 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: události. Shodné s alternativními scénáři pro UC114 Zaznamenání nové

72 58 KAPITOLA 4. ANALÝZA A NÁVRH ŘEŠENÍ 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: Přihlášený uživatel s právem pro mazání událostí. Aktéři: Administrátor IAS, Výrobce karet. 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.

73 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 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é objekty 1, které 1 též označované jako business objekty nebo modelové objekty 59

74 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) 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ů

75 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 discriminatortype=discriminatortype.string, length=9) public abstract class Card extends BaseModifiableObject implements Serializable generator="seq_card") private int private length=16) private 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 public class RegularCard extends Card private CardRange cardrange; 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.

76 62 KAPITOLA 5. IMPLEMENTACE Obrázek 5.2: Fyzický datový model

77 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 Povinný Význam card_id ano unikátní umělý identifikátor _type ano určuje, zda je karta dočasná (hodnota TEMPORARY) nebo normální (hodnota REGULAR) type_letter ne typové písmeno čísla karty licence_number ano licenční číslo karty, normální karty mají 12ciferné číslo, dočasné karty mají 13ciferné číslo check_letter ne kontrolní písmeno čísla karty card_type ne typ karty (ISIC, ITIC, atd.) first_name ne křestní jméno držitele karty last_name ne příjmení držitele karty printed_name ano jméno držitele karty tak, jak je natištěno na kartě birth_date ne datum narození držitele karty ne držitele karty valid_from ano datum začátku platnosti valid_to ano datum expirace status ano stav karty, může být vydaná (ISSUED) nebo zrušená (VOIDED) origin ano původ karty, podle kterého lze rozlišit, jakým způsobem se karta do databáze dostala institution_name ano název školy/společnosti issuer_organization_id ano identifikátor vydavatele karet issued_by ano název vydavatele karet issued_on ano datum vydání card_range_id ne identifikátor rozsahu, do kterého karta patří temporary_card_id ne identifikátor dočasné karty, kterou tato karta nahrazuje created_on ano datum vytvoření created_by_user_id ano identifikátor uživatele, který kartu vytvořil last_modified_on ano datum poslední aktualizace last_modified_by_user_id ano identifikátor uživatele, který provedl poslední aktualizaci deleted ano příznak určující, zda je karta smazaná

78 64 KAPITOLA 5. IMPLEMENTACE Tabulka card_range Tabulka rozsahů licenčních čísel karet. Atribut Povinný Význam card_range_id ano unikátní umělý identifikátor range_start ano počáteční číslo rozsahu range_end ano koncové číslo rozsahu preprinted ano příznak určující, zda jsou karty tohoto rozsahu předtištěny check_letter_required ano příznak určující, zda čísla karet z tohoto rozsahu mají kontrolní písmena issuer_organization_id ano identifikátor vydavatele, kterému rozsah patří external_id ne externí identifikátor používaný v původní aplikaci pro správu rozsahů created_on ano datum vytvoření created_by_user_id ano identifikátor uživatele, který rozsah vytvořil last_modified_on ano datum poslední aktualizace last_modified_by_user_id ano identifikátor uživatele, který provedl poslední aktualizaci deleted ano 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 Povinný Význam card_range_event_id ano unikátní umělý identifikátor event_date ano datum a čas události title ano titulek události description ne detailní popis události card_range_id ano identifikátor rozsahu, ke kterému se událost vztahuje created_on ano datum vytvoření created_by_user_id ano identifikátor uživatele, který událost vytvořil last_modified_on ano datum poslední aktualizace last_modified_by_user_id ano identifikátor uživatele, který provedl poslední aktualizaci deleted ano příznak určující, zda je událost smazaná

79 5.1. CCDB CORE 65 Tabulka verification_log Tabulka záznamů o vyžádaných ověření platností karet. Atribut Povinný Význam verification_log_id ano unikátní umělý identifikátor card_number ano zadané číslo karty k ověření card_holder_name ne zadané jméno držitele karty k ověření result ano výsledek verifikace card_id ne identifikátor karty, jejíž platnost byla při ověřování vyhodnocována verified_on ano datum a čas vyžádání verifikace verified_by_user_id ano 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 operace 2 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.

80 66 KAPITOLA 5. IMPLEMENTACE Vrstva business logiky Vrstva business logiky 3 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 { Card createcard(cardvo cardvo) throws List<Card> getcards(cardsearchcriteria searchcriteria, PagingParams pagingparams, SortParams 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í 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 Basic 4, 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 též označována jako vrstva aplikační logiky, logická vrstva nebo business vrstva 4 popsaný v RFC 2617 "HTTP Authentication: Basic and Digest Access Authentication"

81 5.1. CCDB CORE 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 (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. <aop:config> <aop:pointcut id="servicemethods" expression="@within(org.springframework.stereotype.service)" /> <aop:advisor id="servicemanagertx" advice ref="servicetxadvice" pointcut ref="servicemethods" order="2" /> </aop:config> <tx:advice id="servicetxadvice"> <tx:attributes> <tx:method name="get " read only="true" /> <tx:method name=" " rollback for="net.orchitech.base.validation.validationexception" /> </tx:attributes> </tx:advice> 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) 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 Jersey 5, 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 Jackson 6. Implementace REST zdroje (REST resource) s metodou pro získávání informací o konkrétní kartě vypadá takto:

82 68 KAPITOLA public class CardResource 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žadavku 7 na adresu Obdržená odpověď může vypadat např. následovně: { } "cardtype": "ISIC", "issuedby": "c01 issued by", "printedname": "c01 name c01 surname", "birthdate": " ", " ": "c01 test@example.org", "institutionname": "c01 institution name", "issuerorganizationid": , "validfrom": " ", "cardnumber": "S H", "temporarycardid": null, "voided": false, "firstname": "c01 name", "lastname": "c01 surname", "validto": " ", "cardorigin": "IMPORT", "issuedon": , "cardid": 1, "cardstatus": "VALID", "temporary": false, "createdon": , "createdbyuserid": 1, "lastmodifiedon": , "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č

83 5.1. CCDB public class CardRangeResource { 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(); } 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=" targetnamespace=" xmlns:tns=" 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:sequence> </s:complextype> </s:element> <s:element name="verifycardresponse"> <s:complextype> <s:sequence> <s:element minoccurs="0" maxoccurs="1" name="verifycardresult" type="s:string" /> </s:sequence> </s:complextype> </s:element> </s:schema> 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

84 70 KAPITOLA 5. IMPLEMENTACE 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 VerifyCard = "", proporder = { "cardnumber", "progid", "password" = "VerifyCard") public class VerifyCard { = "CardNumber") protected String = "ProGID") protected String = "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 public class VerificationSrvEndpoint { = "VerifyCard", namespace = " public VerifyCardResponse verifycard(final VerifyCard verifycard) { // process request, return response } 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.

85 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.

86 72 KAPITOLA 5. IMPLEMENTACE 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 API 9 knihovny jxls 10, 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ě: <?xml version="1.0" encoding="utf 8"?> <workbook> <worksheet name="cards"> <section startrow="0" endrow="0" /> <loop startrow="1" endrow="1" items="entries" var="entry" vartype="net.orchitech.ias.ccdb2.ui.xls.cardvo"> <section startrow="1" endrow="1"> <mapping row="1" col="0">entry.cardnumber</mapping> <mapping row="1" col="1">entry.cardtype</mapping> <mapping row="1" col="2">entry.cardholderfirstname</mapping> <mapping row="1" col="3">entry.cardholderlastname</mapping> <mapping row="1" col="4">entry.dateofbirth</mapping> <mapping row="1" col="5">entry. </mapping> <mapping row="1" col="6">entry.cardissuername</mapping> <mapping row="1" col="7">entry.institutionname</mapping> <mapping row="1" col="8">entry.validfrom</mapping> <mapping row="1" col="9">entry.validto</mapping> <mapping row="1" col="10">entry.issuedon</mapping> <mapping row="1" col="11">entry.issuedby</mapping> <mapping row="1" col="12">entry.status</mapping> <mapping row="1" col="13">entry.temporary</mapping> </section> <loopbreakcondition> <rowcheck /> </loopbreakcondition> </loop> </worksheet> </workbook> 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 Application Programming Interface, rozhraní komponent pro programování aplikací. 10

87 5.3. MIGRAČNÍ NÁSTROJ 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-of- Control 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