bakalářská práce - Unicorn College

Transkript

BAKALÁŘSKÁ PRÁCE
Příprava a anonymizace
datových souborů
určených pro vývoj a
testování
Preparation and
anonymization of data files
for development and
testing
Patrik Jankovský
Unicorn College © 2010
Unicorn College, V kapslovně 2767/2, Praha 3, 130 00
Název práce v ČJ:
Příprava a anonymizace datových
souborů určených pro vývoj a
testování
Název práce v AJ:
Preparation and anonymization of
data files for development and
testing
Autor:
Patrik Jankovský
Akademický rok:
2012
Kontakt:
[email protected]
(+420) 603 111 034
Bakalářská práce
Příprava a anonymizace datových souborů určených pro vývoj a testování
Preparation and anonymization of data files for development and testing
1.
ABSTRAKT
Práce se bude nejprve zabývat teorií datové anonymizace, kde se nejprve pokusím vysvětlit datovou
anonymizaci jako pojem a nastíním, kde se s ní můžeme setkat. Poté v celku detailně popíši a
vysvětlím zákon o ochraně osobních údajů, který je platný v České republice. Dále se zaměřím na
samotné techniky, které je možné zvolit při anonymizaci datových souborů. V závěru první části pak
zvolím techniky, které budou použity v samotné aplikaci. Tato část má především informativní
charakter, aby každý, kdo práci bude číst, věděl, proč je vůbec nutné anonymizovat datové soubory.
V další části práce jde o popis situace přímo na problémové doméně jedné společnosti. Z této situace
vyplývají určité možnosti, jak ji řešit a tak je potřeba definovat požadavky na aplikaci. Rozdělím
jednotlivé požadavky, které popíši a navrhnu podle nich všechny potřebné use-case. Několik málo
požadavků se týká i grafického rozhraní aplikace. V této části navrhnu velmi abstraktní podobu
architektury aplikace a začnu se zabývat zásuvnými moduly, které jsou pro aplikaci velmi důležité.
V implementační části práce se podíváme již na opravdovou architekturu aplikace a stručně popíši
všechny důležité třídy aplikace. Větší pozornost je věnována XML šabloně a zásuvným modulům.
Hned po implementační části následuje ukázka hotového řešení, kde ukážu, zda byly všechny
požadavky na aplikaci opravdu splněny.
Poslední částí je dokumentace, respektive návod k použití aplikace, kde popisuji jednotlivé funkčnosti
práce s XML šablonou a zásuvnými moduly. Krok po kroku předvedu, jak se má aplikace správně
používat a jak je nastavené její workflow. V závěru práce shrnuji všechny poznatky, které jsem získal
během psaní této práce, ale hlavně během implementace samotné aplikace. A také pouvažuji o
dalším možném rozvoji aplikace.
Klíčová slova: data, anonymizace, ochrana osobních údajů, testování, vývoj, XML, .NET Framework,
Windows Presentation Foundation, C#, zásuvný modul
-5-
2.
ABSTRACT
First thing in this bachelor thesis we take a look at is a data anonymization, where I first explain data
anonymization as a term and where one could meet it. After that I describe and explain a privacy
policy law in further details that is currently of validity in Czech Republic. Then I describe some of the
techniques one could use to anonymize data files. At the end of the first part of this bachelor thesis, I
choose the techniques which will be used in the application. This first chapter has mostly informative
character to give an explanation to everyone who reads this bachelor thesis of why is so important to
anonymize data files.
In the next chapter I start with an explanation of the problem related to one company business. This
problem situation leads us to explore all the options how to solve it and we need to specify all
requirements for the application. As soon as we have all requirements I can sort them and define all
use-cases accordingly. Few requirements are related to a graphic user interface. In this chapter I also
design a high level architecture of the application and I start to talk about plugins which are really
important for the application.
Within the implementation chapter we take a look at the real architecture of the application and I briefly
describe the most important classes. Main focus is dedicated to both XML template and plugins. Right
after this part I show you an example of final application to prove that I have implemented all
requirements.
Last chapter is basically user documentation, where I explain how to use all the features and work with
XML template and plugins. I show how to use the application step by step and how its workflow has
been set up. At the end of this bachelor thesis could be found all findings I have taken when writing
this bachelor thesis, but mostly when implementing the application. Last thing I do is to think about the
possible future development.
Keywords: data, anonymization, privacy policy, testing, development, XML, .NET Framework,
Windows Presentation Foundation, C#, plugin
-6-
3.
PROHLÁŠENÍ
Prohlašuji, že svou bakalářskou práci na téma Příprava a anonymizace datových souborů určených
pro vývoj a testování jsem vypracoval samostatně pod vedením vedoucího bakalářské práce a s
použitím odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a jsou též
uvedeny v seznamu literatury a použitých zdrojů.
Jako autor uvedené bakalářské práce dále prohlašuji, že v souvislosti s vytvořením této bakalářské
práce jsem neporušil autorská práva třetích osob, zejména jsem nezasáhl nedovoleným způsobem do
cizích autorských práv osobnostních a jsem si plně vědom následků porušení ustanovení § 11 a
následujících autorského zákona č. 121/2000 Sb.
K této bakalářské práci je přiložena Příloha 2, která mi umožňuje využívat data společnosti SSE jako
příklad.
…….……………….
V Praze dne
Patrik Jankovský
-7-
4.
PODĚKOVÁNÍ
Děkuji vedoucímu bakalářské práce Ing. David Hartman Ph.D. za účinnou metodickou, pedagogickou
a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.
-8-
5.
OBSAH
1.
Abstrakt ....................................................................................................................................... - 4 -
2.
Abstract ....................................................................................................................................... - 6 -
3.
Prohlášení .................................................................................................................................... - 7 -
4.
Poděkování .................................................................................................................................. - 8 -
5.
Obsah........................................................................................................................................... - 9 -
6.
Úvod .......................................................................................................................................... - 13 -
7.
6.1
Popis jednotlivých kapitol práce........................................................................................ - 14 -
6.2
Konvence používané v této práci ...................................................................................... - 14 -
6.3
Konvence ........................................................................................................................... - 14 -
datová anonymizace.................................................................................................................. - 15 7.1
Teorie datové anonymizace .............................................................................................. - 15 -
7.1.1
Vysvětlení pojmu datová anonymizace ..................................................................... - 15 -
7.1.2
Proč a kde se datová anonymizace používá .............................................................. - 16 -
7.2
Právní pohled v České republice ....................................................................................... - 16 -
7.2.1
Osobní údaj................................................................................................................ - 17 -
7.2.2
Citlivý osobní údaj ..................................................................................................... - 17 -
7.2.3
Anonymní osobní údaj............................................................................................... - 17 -
7.2.4
Zveřejněný osobní údaj ............................................................................................. - 17 -
7.2.5
Subjekt údajů ............................................................................................................. - 17 -
7.2.6
Shromažďování osobních údajů ................................................................................ - 17 -
7.2.7
Zpracovávání osobních údajů .................................................................................... - 18 -
7.2.8
Uchovávání osobních údajů ...................................................................................... - 18 -
7.2.9
Správce osobních údajů ............................................................................................. - 18 -
7.2.10
Zpracovatel osobních údajů ...................................................................................... - 18 -
7.2.11
Souhlas se zpracováním osobních údajů ................................................................... - 18 -
7.2.12
Příjemce osobních údajů ........................................................................................... - 18 -
7.2.13
Likvidace osobních údajů........................................................................................... - 19 -
7.3
Další právní předpisy upravující ochranu osobních údajů................................................. - 19 -
7.3.1
7.4
Seznam dalších zákonů .............................................................................................. - 19 -
Principy datové anonymizace ............................................................................................ - 20 -
7.4.1
Přímé datové identifikátory....................................................................................... - 20 -9-
7.4.2
Nepřímé datové identifikátory .................................................................................. - 20 -
7.4.3
Faktory a hrozby narušení osobních údajů ............................................................... - 21 -
7.5
7.5.1
Technika redukce datových záznamů........................................................................ - 22 -
7.5.2
Technika pozměňování datových záznamů ............................................................... - 23 -
7.6
8.
Techniky datové anonymizace .......................................................................................... - 22 -
Vybrané principy a techniky .............................................................................................. - 24 -
Analýza a návrh řešení............................................................................................................... - 26 8.1
Problémová doména ......................................................................................................... - 26 -
8.1.1
Popis společnosti ....................................................................................................... - 27 -
8.1.2
Dokumentová kompozice .......................................................................................... - 27 -
8.1.3
Ukázka výstupu .......................................................................................................... - 29 -
8.1.4
Ukázka dat ................................................................................................................. - 30 -
8.2
Definice cílů práce ............................................................................................................. - 31 -
8.2.1
Rozsah práce.............................................................................................................. - 32 -
8.2.2
Výstupy práce ............................................................................................................ - 32 -
8.2.3
Mimo rozsah práce .................................................................................................... - 32 -
8.3
Správa požadavků .............................................................................................................. - 33 -
8.3.1
Identifikované požadavky .......................................................................................... - 33 -
8.3.2
Prioritizované požadavky .......................................................................................... - 34 -
8.4
Navrhované řešení ............................................................................................................ - 35 -
8.4.1
Popis navrhovaného řešení ....................................................................................... - 35 -
8.4.2
XML šablona .............................................................................................................. - 35 -
8.4.3
Zásuvný modul........................................................................................................... - 35 -
8.4.4
Architektura navrhovaného řešení............................................................................ - 36 -
8.4.5
Návrh GUI .................................................................................................................. - 37 -
8.5
Popis použitých technologií ............................................................................................... - 38 -
8.5.1
XML ............................................................................................................................ - 38 -
8.5.2
WPF............................................................................................................................ - 39 -
8.6
Use-case specifikace .......................................................................................................... - 40 -
8.6.1
Přehled aktérů ........................................................................................................... - 40 -
8.6.2
Přehled use-case........................................................................................................ - 40 -
8.6.3
Přehled mapování požadavků na use-case ............................................................... - 41 -
8.6.4
Use-case diagramy..................................................................................................... - 42 - 10 -
9.
Implementace aplikace ............................................................................................................. - 44 9.1
Architektura aplikace......................................................................................................... - 44 -
9.2
Vytváření XML šablony ...................................................................................................... - 45 -
9.2.1
Princip ........................................................................................................................ - 45 -
9.2.2
Objekt šablony XmlTemplateItem ............................................................................. - 45 -
9.2.3
Popis algoritmu.......................................................................................................... - 46 -
9.3
Zásuvné moduly................................................................................................................. - 47 -
9.3.1
Rozhraní IPluginable .................................................................................................. - 47 -
9.3.2
Implementace zásuvného modulu ............................................................................ - 48 -
9.4
Popis důležitých tříd .......................................................................................................... - 51 -
9.4.1
Plugin Manager.......................................................................................................... - 51 -
9.4.2
XML Manager ............................................................................................................ - 51 -
9.4.3
Data Manager ............................................................................................................ - 52 -
9.4.4
IO Manager ................................................................................................................ - 53 -
9.5
Serializace a Deserializace ................................................................................................. - 54 -
9.6
Aplikace XML šablony při anonymizaci ............................................................................. - 55 -
9.6.1
10.
Popis algoritmu.......................................................................................................... - 55 -
Hotové řešení ........................................................................................................................ - 57 -
10.1
Náhled hotové aplikace ..................................................................................................... - 57 -
10.2
Test anonymizace .............................................................................................................. - 58 -
10.2.1
Vstupní data .............................................................................................................. - 58 -
10.2.2
Nastavení XML šablony ............................................................................................. - 58 -
10.2.3
Výstupní data............................................................................................................. - 59 -
11.
Uživatelská dokumentace ..................................................................................................... - 60 -
11.1
XML Šablona ...................................................................................................................... - 60 -
11.1.1
Vytvoření XML šablony .............................................................................................. - 60 -
11.1.2
Funkčnosti nad XML šablonou................................................................................... - 60 -
11.1.3
Vlastnosti prvků XML šablony ................................................................................... - 60 -
11.2
Zásuvné moduly................................................................................................................. - 61 -
11.2.1
Birthnumber .............................................................................................................. - 62 -
11.2.2
Custom....................................................................................................................... - 62 -
11.2.3
Date ........................................................................................................................... - 62 -
11.2.4
Name ......................................................................................................................... - 62 - 11 -
11.2.5
Number...................................................................................................................... - 63 -
11.2.6
Text ............................................................................................................................ - 63 -
11.3
Správa instancí zásuvných modulů .................................................................................... - 63 -
11.3.1
Vytvoření konkrétní instance zásuvného modulu ..................................................... - 64 -
11.3.2
Přiřazování instancí k prvkům šablony ...................................................................... - 65 -
11.3.3
Zobrazení náhodných hodnot ................................................................................... - 65 -
11.3.4
Zobrazení všech referencí ......................................................................................... - 65 -
11.4
Anonymizace XML souboru ............................................................................................... - 66 -
11.5
Minimální systémové požadavky ...................................................................................... - 66 -
11.6
Workflow aplikace ............................................................................................................. - 67 -
12.
Závěr ...................................................................................................................................... - 68 -
13.
Conclusion ............................................................................................................................. - 70 -
14.
Seznam použité literatury ..................................................................................................... - 72 -
15.
Seznam použitých symbolů a zkratek.................................................................................... - 73 -
16.
Seznam obrázků .................................................................................................................... - 74 -
17.
Seznam tabulek ..................................................................................................................... - 75 -
18.
Seznam příloh ........................................................................................................................ - 76 -
18.1
Příloha 1 – Hodnocení od Titio s.r.o. ................................................................................. - 77 -
18.2
Příloha 2 – Povolení od SSE ............................................................................................... - 78 -
18.3
Příloha 3 – CD .................................................................................................................... - 79 -
- 12 -
6.
ÚVOD
Práce se bude zabývat problematikou ochrany osobních údajů a z ní vyplívající
anonymizace citlivých dat fyzických osob. Postupně bude rozebrán již právě zmíněný pojem
- datová anonymizace. Rozeberu její možné přístupy, subjekty, kterých se tato problematika
týká, jednotlivé zákony, respektive právní stránku věci a v neposlední řadě její samotnou
aplikaci, kterou se bude zabývat převážná většina této práce.
Samotným cílem je tedy navrhnout a implementovat desktopovou aplikaci, kde hlavní
funkčnost bude právě samotné aplikování datové anonymizace. Na větší úrovni abstrakce
lze aplikaci popsat vcelku jednoduše – na vstupu se očekává soubor obsahující citlivá data
určená k anonymizaci, kde na základě konfigurace aplikace a namapování vstupního
souboru dostaneme soubor výstupní, který po aplikaci anonymizačního algoritmu bude
obsahovat již výsledná data v požadované míře anonymity.
1
Celé řešení bude postaveno na .NET platformě s využitím programovacího jazyka C# , který
2
některými svými technologiemi, jako například LINQ , umožňuje velmi elegantní řešení
problému. Bude se jednat o desktopovou aplikaci, pro jejíž implementaci byla zvolena
technologie Windows Presentation Foundation.
3
Za vstupní a výstupní soubor se v první fázi aplikace předpokládá jen soubor typu XML, ale
aplikace by v budoucnu měla být rozšiřitelná o podporu souborů dalších typů, jako například
4
5
delimiter a columnar . Ale jako první je zvolen XML soubor pro svou největší rozšířenost.
Velmi důležitou rolí jsou generovaná data ve výstupním souboru. Data musí dávat smysl a
nesmí pozměnit vstupní soubor jen na hromadu náhodně generovaných znaků. Nesmí se
tak porušit význam hodnot v souboru – když se anonymizuje jméno, tak je potřeba aby tam
opět bylo jméno i po aplikaci anonymizačního algoritmu, ale nyní náhodně vygenerované.
Určité typy hodnot by tedy měly být založeny na reálných podkladech.
1
NASH, Trey. C# 2010 : Nejlepší průvodce novinkami a nejlepšími postupy. 1. vyd.
Brno : Computer Press, 2010. 624 s. ISBN 978-80-251-3034-6
2
PIALORSI, Paolo, RUSSO, Marco. Microsoft LINQ : Kompletní průvodce programátora. 1. vyd.
3
PETZOLD, Charles. Mistrovství ve Windows Presentation Foundation. 1. vyd.
4
Textový soubor, kde jsou jednotlivé záznamy odděleny určitým znakem. Příkladem může být CSV, kde jsou
záznamy odděleny čárkou.
5
Textový soubor, kde jsou jednotlivé záznamy rozloženy do sloupců o předem definované délce počtu znaků.
- 13 -
6.1 Popis jednotlivých kapitol práce

Kapitola 8: Datová anonymizace – V této kapitole se podíváme na teoretickou část
problému a vydefinujeme základní pojmy.

Kapitola 9: Analýza a návrh řešení – Zde se budeme věnovat návrhu samotné
aplikace v několika úrovních abstrakce a také se podíváme na technologie, které
budou použity pro implementaci řešení.

Kapitola 10: Implementace aplikace – Kapitola o implementaci aplikace, která
pojednává o hlavních částích a třídách aplikace a popíše práci se zásuvnými moduly
z pohledu implementace.

Kapitola 11: Hotové řešení – V této kapitole si již ukážeme hotové finální řešení a
popíšeme proces od vstupních dat po výstupní data.

Kapitola 12: Uživatelská dokumentace – Návod jak aplikaci nainstalovat a
efektivně používat. Také se zaměříme na workflow celé aplikace.
6.2 Konvence používané v této práci
Práce je psaná velmi srozumitelně a pro rychlejší pochopení její typografické struktury
doporučuji přečíst si následující typografické konvence, které se v práci vyskytují.
6.3 Konvence
Tučné písmo – slouží ke zvýraznění v samotném textu práce, kde dává důraz důležitým
pojmům, které jsou v práci použity.
Kurzíva – je v práci použita pro vyčlenění částí textu, které přímo souvisejí například
s aplikací, či jde o názvy různých objektů.
Neproporcionální písmo – používá se pro zobrazení zdrojového kódu, respektive pro
zobrazení jmenných prostorů, tříd, atributů, proměnných, metod, objektů, událostí, vlastností
atd.
- 14 -
7.
DATOVÁ ANONYMIZACE
Tato kapitola má za cíl vysvětlit potřebnou teorii již nastíněného problému ochrany osobních
údajů. Zaměřím se na teorii jen nezbytně nutnou k pochopení této problematiky – vysvětlím
důležité pojmy, vydefinuji a popíši zainteresované subjekty a lehce rozeberu právní stránku
věci. Dále bude popsáno několik příkladů z praxe, aby v závěru této kapitoly již bylo jasné,
proč jsem se rozhodl právě pro toto téma a implementaci samotné aplikace pro jeho řešení.
7.1 Teorie datové anonymizace
7.1.1 Vysvětlení pojmu datová anonymizace 6
Hlavním cílem datové anonymizace je skrytí citlivých údajů a znemožnit tak třetí straně
jakékoliv propojení s osobou, ke které se daná data vztahují. Citlivým údajem může být
například rodné číslo – na kompletní výčet citlivých údajů se podíváme později, až budu
popisovat anonymizaci dat ve vztahu k zákonům ČR.
Obrázek 1 - Úvod do datové anonymizace
Zdroj: Vlastní tvorba
Nahradit rodné číslo jiným však není dostatečná anonymizace, protože třetí straně by se
mohlo podařit identifikovat danou osobu díky kombinaci ostatních údajů. Dobrým příkladem
může být jméno a příjmení, spolu s trvalým bydlištěm. Díky těmto informacím je velmi
jednoduché si danou osobu dohledat.
K takovéto situaci však nesmí v žádném případě dojít a třetí strana, které byly data
poskytnuty, by nikdy neměla být schopna identifikovat a přiřadit jednotlivé datové záznamy
ke konkrétním osobám a to za použití libovolné kombinace údajů z dat.
6
INFA Partner s.r.o [online]. c2010 [cit. 2012-04-08]. Dostupný z WWW: http://www.infapartner.cz/datamasking/
- 15 -
7.1.2 Proč a kde se datová anonymizace používá
Tento problém musí řešit každý subjekt, který shromažďuje osobní údaje, ke kterým se
může dostat i nějaká další třetí strana, která však nemá souhlas o poskytnutí osobních údajů
od jejich majitelů.
Příkladem může být mobilní operátor, který by si rád nechal vyvinout informační systém pro
svou společnost. Informační systém bude obsahovat i různé funkce jako je například správa
zákazníků. Mobilní operátor však nemá dostatečné vnitřní zdroje a tak si informační systém
musí nechat vyvinout jinou společností.
Společnost implementující daný informační systém je z pohledu zákaznických dat již třetí
strana a tak by k nim neměla mít přístup. Problém však může nastat v okamžiku, kdy je
potřeba provést analýzu, design a implementaci konkrétního modulu, který se zabývá právě
zákazníky dané společnosti. Ten samý problém nastane při testování naimplementovaného
modulu. Společnost potřebuje pro vývoj přesná data, která odpovídají reálným datům.
V tomto okamžiku přichází na řadu již zmiňovaná datová anonymizace, která umožňuje
poskytnutí upravených dat i třetím stranám bez souhlasu jejich majitelů. Společnosti
implementující takovýto informační systém je jedno, zda se jedná o ostré či anonymizované
data. Hlavním a nejdůležitějším požadavkem na tyto data je jejich struktura, která musí
odpovídat ostrým datům.
Mobilní operátor je jen jeden z mnoha případů. Z těch větších odvětví můžeme jmenovat
například banky, pojišťovny, zdravotní zařízení, státní instituce atd.
7.2 Právní pohled v České republice 7
V České republice se ochranou osobních údajů zabývá Úřad pro ochranu osobních údajů,
který vznikl na základě zákona č. 101/2000 Sb., o ochraně osobních údajů. Tento zákon se
vztahuje na veškeré zpracování osobních údajů, které provádějí státní instituce, fyzické i
právnické osoby, s výjimkou fyzických osob, které provádějí zpracování osobních údajů pro
vlastní potřebu (v tomto případě dochází ke zpracování osobních údajů pro nekomerční
užití).
Zákon upravuje zpracování osobních údajů automatizovaně či jinými prostředky a jeho
primárním cílem je ochrana osobních údajů, způsob zpracování údajů v České republice, ale
také předávání osobních údajů do zahraničí.
V několika následujících podkapitolách bych rád vymezil důležité pojmy, které se k této
problematice vážou a je potřeba je znát.
7
Úřad pro ochranu osobních údajů [online], c2012 [cit. 2012-04-08]. Dostupný z WWW:
http://www.uoou.cz/uoou.aspx?menu=4&submenu=5&loc=20>
- 16 -
7.2.1 Osobní údaj
Je to jakákoliv informace, podle které lze subjekt identifikovat a to na základě jednoho prvku,
nebo i na základě jejich kombinace. Jedná se především o čísla a kódy vypovídající o
fyzické, fyziologické, psychické, ekonomické, kulturní nebo sociální identitě. Díky tomu se
subjekt údajů považuje za určený nebo určitelný, pokud ho lze přímo či nepřímo
identifikovat.
7.2.2 Citlivý osobní údaj
Mezi citlivé údaje patří například informace o národnostním, rasovém nebo etnickém
původu. Dále se za citlivé údaje považují informace o politickém postoji, zdravotním stavu,
náboženství, trestné činnosti, sexuálním životě, genetických, ale také biometrických údajích
subjektu, podle kterých lze subjekt identifikovat nebo autentizovat.
7.2.3 Anonymní osobní údaj
Anonymní údaj je jednoduše takový kus informace, podle kterého není možné zpětně určit
subjekt údajů. Jedná se tedy především o pozměněné údaje (informace na kterou byl
například použit nějaký anonymizační algoritmus), ale také o údaje v nezměněné podobě,
které nevypovídají o identitě subjektu údajů.
7.2.4 Zveřejněný osobní údaj
Zveřejněným údajem se rozumí takový údaj, který je zpřístupněný hromadným sdělovacím
prostředkem dalším subjektům, než je jejich správce či zpracovatel. K veřejnému
zpřístupnění může dojít například na poradě, umístěním na webové stránky, ale také může
jít o údaje na úředním seznamu.
7.2.5 Subjekt údajů
Každá fyzická osoba, ke které se vztahují osobní údaje, je subjektem údajů.
7.2.6 Shromažďování osobních údajů
Jedná se o proces, během kterého dochází ke sběru osobních údajů a jejich zaznamenání
na nosič informací. Tento proces je vykonáván za účelem okamžitého nebo dalšího použití
nasbíraných osobních údajů.
- 17 -
7.2.7 Zpracovávání osobních údajů
Zpracováním osobních údajů se rozumí operace nebo soustava operací, které se vztahují
k práci s osobními údaji. Může se jednat o jejich shromažďování, ukládání na nosiče
informací, zpřístupňování, úprava, vyhledávání, používání, šíření, zveřejňování, uchovávání,
výměna, kombinování či jejich likvidace. Tyto operace s osobními údaji provádí jejich
správce či zpracovatel. Může jít o manuální provádění těchto operací, ale také o jejich plně
automatizované provádění.
7.2.8 Uchovávání osobních údajů
Uchovávání osobních údajů je jejich udržování v podobě, ve které je možné jejich
zpracovávání, které je popsané v předešlé kapitole.
7.2.9 Správce osobních údajů
Jedná se o subjekt, který je kompetentní za zpracování osobních údajů. Může zpracování
osobních údajů sám vykonávat, nebo tím může pověřit zpracovatele, pokud však zvláštní
zákon nestanoví jinak. Správce také rozhoduje o účelu zpracování osobních údajů a o
prostředcích, které ke zpracování budou použity.
7.2.10
Zpracovatel osobních údajů
Zpracovatel je subjekt zpracovávající osobní údaje. Zpracováním může být pověřen na
základě zvláštního zákonu nebo může být pověřen správcem osobních údajů.
7.2.11
Souhlas se zpracováním osobních údajů
Správce může osobní údaje zpracovávat až v okamžiku, kdy má souhlas od subjektu údajů.
Souhlasem se rozumí svobodné a vědomé projevení vůle subjektu údajů, ve kterém dá
subjekt údajů souhlas ke zpracování osobních údajů.
7.2.12
Příjemce osobních údajů
Příjemcem osobních údajů je každý subjekt, kterému jsou osobní údaje poskytnuty a to
nezávisle na formě zpřístupnění. Příjemcem se podle zákona č. 101/2000 Sb., o ochraně
osobních údajů, § 3 odst. 6 písm. g) nerozumí subjekt, který je pověřen zpracováním
osobních údajů.
- 18 -
7.2.13
Likvidace osobních údajů
Likvidací se rozumí úplné fyzické odstranění z nosičů informací, nebo přímo fyzické zničení
nosičů informací, které obsahují osobní údaje. Dále se likvidací může rozumět i jejich trvalé
vyloučení z dalšího zpracování osobních údajů.
7.3 Další právní předpisy upravující ochranu
osobních údajů 8
V České republice je mnoho dalších zákonu, které nějakým způsobem pracují s osobními
údaji. Následující seznam je jen příklad těch několika největších zákonů.
7.3.1 Seznam dalších zákonů

Občanský zákoník – upravuje ochranu osobnosti.

Obchodní zákoník – zde je upravena ochrana osobních údajů ve vztahu
k právnickým osobám, kde jde zejména o ochranu obchodního tajemství a právo
podnikatele na ochranu obchodního tajemství před porušením či ohrožením.

Zákon č. 89/1995 Sb. o státní statistické službě – upravuje ochranu osobních
údajů, které od subjektu údajů shromažďuje Český statistický úřad či jiné státní
instituce, které vykonávají státní statistickou službu.

Zákon o péči o zdraví lidu – stanovuje povinnost zdravotnickým pracovníkům
zachovat mlčenlivost o skutečnostech, které souvisí s výkonem jejich povolání.
Výjimkou je případ, kdy mají od ošetřované osoby vědomý souhlas, nebo pokud jsou
zproštěni této povinnosti nadřízeným orgánem v důležitém státním zájmu.

Zákon o bankách – upravuje ochranu bankovního tajemství, které se vztahuje na
veškeré bankovní obchody, peněžní služby bank, včetně stavů na účtech a depozit.

Zákon o advokacii – se vztahuje na advokáta, na jeho právní koncipienty, ale i na
jeho samotný personál, kterým ukládá povinnost mlčenlivosti.

Trestní zákoník a zákon o přestupcích – upravuje například neoprávněný přístup
do počítačového systému či k nosiči informací. Dále pak definuje trestný čin při
neoprávněném nakládání s osobními údaji.
8
BusinessInfo.cz [online], c2011 [cit. 2012-04-08]. Dostupný z WWW:
http://www.businessinfo.cz/cz/clanek/orientace-v-pravnich-ukonech/ochrana-osobnich-udajuopu/1000818/51144/>
- 19 -
7.4 Principy datové anonymizace 9
Pokud mají být zveřejněna data, která obsahují osobní či citlivé údaje, je potřeba tyto data
nejprve anonymizovat. Anonymizační proces musí odstranit, respektive znemožnit zpětnou
identifikaci subjektu údajů ze zveřejněných dat.
Tyto identifikátory se dělí na dvě skupiny.
Přímé
Datové
identifikátory
Nepřímé
Obrázek 2 - Rozdělení datových identifikátorů
7.4.1 Přímé datové identifikátory
V případě přímých datových identifikátorů se jedná o proměnné typu jméno a příjmení,
adresa, rodné číslo, číslo pasu, číslo občanského průkazu, identifikační číslo atd. V mnoha
případech nám stačí pouze jeden takový údaj, abychom mohli identifikovat subjekt údajů.
Příkladem může být rodné číslo či identifikační číslo.
Pokud máme k dispozici jen jméno a příjmení, tak s největší pravděpodobností nejsme
stoprocentně schopni subjekt údajů identifikovat – za předpokladu, že dané jméno a příjmení
naleží alespoň dvěma subjektům údajů. V kombinaci s kompletní adresou už ale identifikaci
můžeme provést velmi snadno.
Pro data, která budou sloužit jen pro statistické účely, tyto identifikátory nemají žádný
význam a je nutné je anonymizovat. Pokud budou ale data použita pro testovací účely, tak je
nutné zachovat validní formát všech daných identifikátorů
7.4.2 Nepřímé datové identifikátory
Jedná se o kombinaci identifikátorů, které může vzájemně sdílet hned několik subjektů
údajů. Díky tomu není většinou možné provést zpětně jednoznačnou identifikaci.
Příkladem nepřímých datových identifikátorů je například věk, pohlaví, profese a místo
výkonu profese. Pro lepší představu si můžeme popsat menší příklad na již uvedených
příkladech nepřímých datových identifikátorů.
9
International Household Survey Network [online], c2009 [cit. 2012-04-08]. Dostupný z WWW:
http://www.ihsn.org/HOME/index.php?q=tools/anonymization/principles
- 20 -
Datový soubor obsahuje data o účastnících ve výzkumu, který se zabývá výší měsíčního
příjmu. Nyní doplníme proměnné za hodnoty z výzkumu, které mezi sebou sdílí více
subjektů údajů.
Obrázek 3 - Anonymizace nepřímých datových identifikátorů
Obrázek 3 nám zobrazuje výše popsané nepřímé identifikátory. V jeho levé části vidíme, že
na základě těchto údajů jsme schopni identifikovat subjekt údajů, protože víme, že v obci
Kounov je jen jeden účetní, který je muž. Naším úkolem je anonymizace co nejmenšího
počtu identifikátorů tak, aby žádná z kombinací identifikátorů zachovalých neumožňovala
identifikovat pouze jeden subjekt údajů.
Protože v obci Kounov jsou celkem tří účetní, Jan Novák a další dvě ženy, které jsou
stejného věku, tak se nám přímo nabízí odstranění, respektive anonymizování identifikátoru
odkazující na místo výkonu profese. Po odstranění se kombinace údajů již vztahuje na
skupinu o počtu tří subjektů údajů.
Data tak zůstávají v konzistentní podobě, ale zároveň není možné zpětně identifikovat
jednotlivé subjekty údajů, kteří se zúčastnili daného výzkumu. Zároveň se nám podařilo
zachovat ty nejrelevantnější údaje pro výzkum. Nutno podotknout, že ne vždy je to tak
jednoduché, jak nám demonstruje tento příklad. Ve většině případů jde o obrovské množství
informací a subjektů a je opravdu velmi obtížné zajistit, aby žádný ze subjektů nemohl být
zpětně identifikován a zároveň byly zachovány všechny relevantní identifikátory pro daný
účel.
7.4.3 Faktory a hrozby narušení osobních údajů
Pří anonymizaci přímých i nepřímých identifikátorů se také bere v úvahu, co by dotyčná
osoba (dále jen „Narušitel“), které se povede provést zpětnou identifikaci subjektu údajů,
získala a jaká je jejich motivace. V případě, že půjde o firemní data, tak je tu velké riziko, že
se data dají zneužít ve prospěch narušitele a motivace může být veliká. Motivačním
faktorem v tomto případě bude například zničení či poškození konkurenční společnosti.
- 21 -
V případě dat z výzkumu o výši měsíčního příjmu, který byl demonstrován v předchozí
kapitole, nebude motivace taková, protože zpětná identifikace subjektu údajů ve své
podstatě Narušiteli nic nepřináší. Dalším faktorem je cena a čas, které by Narušitel musel
vynaložit na zpětnou identifikaci.
Při zveřejňování již anonymizovaných dat musíme mít na paměti, že Narušitel může ke
zpětné identifikaci použít i další volně dostupné zdroje, než jsou daná data. Příkladem může
být veřejně dostupný registr, kde se nachází i přímé identifikátory. Zde je pak riziko vytvoření
vazby mezi daty a registrem, která by mohla jasně identifikovat subjekt údajů. Narušitel tak
může zkoušet přiřazování záznamů ze dvou či více zdrojů a nalézt mezi nimi vazbu, která
mu umožní zpětně identifikovat subjekt údajů.
7.5 Techniky datové anonymizace 10
Datová anonymizace má dvě hlavní techniky, kterými je prováděna. Jedna z nich je
založena na redukci datových záznamů a druhá spočívá v jejich pozměňování. Cílem této
kapitoly je si obě techniky představit, rozebrat jejich jednotlivé metody a ukázat si je na
příkladech.
7.5.1 Technika redukce datových záznamů
Cílem této techniky je odstraňování přímých datových identifikátorů (rodné číslo, číslo
občanského průkazu, identifikační číslo atd.). Výsledkem je neustále rostoucí množina
subjektů údajů, na kterou se daná data mohou vztahovat. Jednoduše řečeno snahou této
techniky je odstranění přítomnosti všech vzácných a unikátních informací, které mohou
subjekt údajů odhalit. To může být zajištěno několika způsoby.

Odstraňování proměnných – Metoda, která jak již je výše zmíněno, odstraňuje
přímé identifikátory z datových záznamů. Používá se především tehdy, když je
jednoznačně identifikující či není možné použít jiné bezpečnostní opatření. Dalším
důvodem může být fakt, že daná proměnná je citlivý údaj, který by neměl být
zveřejněn, nebo se jedná o proměnnou, která nemá pro daný účel žádný význam.
Příkladem je například informace o náboženství, které nemusí být přístupné ve
zveřejněném datovém souboru, ale naopak se může nacházet v licencovaném
datovém souboru.

Odstraňování záznamů – Tato metoda je považována za extrémní případ redukce
dat, které bychom se měli co nejvíce vyhýbat. Pokud je určitá množina záznamů
z datového souboru identifikovatelná díky jednomu identifikátoru, ale zbytku
10
International Household Survey Network [online], c2009 [cit. 2012-04-08]. Dostupný z WWW:
http://www.ihsn.org/home/?q=tools/anonymization/techniques
- 22 -
záznamů se to netýká, tak raději odstraníme kompletní množinou postižených
datových záznamů, než abychom odstraňovali daný identifikátor ze všech záznamů
v datovém souboru. Pro statistické účely však tato metoda může způsobit
nekonzistentnost či přímo nepoužitelnost dat.

Globální záznamy – Metoda spočívající v agregaci hodnot napříč datovým
souborem u jednotlivých záznamů a jejich identifikátorů. Je aplikovatelná na
všechny numerické záznamy, ale i některé další, například na výčtové typy. Tuto
metodu lze velmi snadno představit na příkladě, kde si zvolíme identifikátor
vyjadřující počet zaměstnanců společnosti. Ten se většinou zadává jako celočíselná
hodnota. Co se ale stane, když jej budeme vyjadřovat pomocí tří kategorií – málo,
středně, hodně? Okamžitě se nám jednotlivé záznamy začnou vztahovat k více
subjektům. Podobné je to v případě výčtových typů, kde můžeme velmi jednoduše
sloučit dvě kategorie do jedné a dosáhneme podobného výsledku. Tato metoda
musí být vždy provedena nad celým datovým souborem, aby měla požadovaný efekt
a byl uchován její význam.

Horní a spodní mez – Velmi se podobá předchozí metodě. Rozdíl spočívá v tom,
že nahrazujeme pouze horní a spodní extrémy, které si určíme. Příkladem může být
měsíční hrubý příjem zaměstnanců společnosti. Hodnoty mezi 20 až 30 tisíci
ponecháme beze změny, oproti tomu všechny hodnoty pod 20 tisíc změníme
například na ‘méně než 20 tisíc’ a naopak všechny hodnoty nad 30 tisíc změníme na
‘více než 30 tisíc’.

Lokální omezení – Jako jediná z výše popsaných metod se aplikuje na jednotlivé
záznamy napříč datovým souborem dle potřeby. Jejím cílem je odstranit vzácné
kombinace identifikátorů tím, že nějaký z nich nahradí prázdnou hodnotou. Měla by
být aplikována pouze na záznamy, které mají vybranou kombinaci identifikátorů
jedinečnou a bylo by je možné zpětně identifikovat.
7.5.2 Technika pozměňování datových záznamů
Technika je založená na pozměňování dat. Důležité je si uvědomit, že pokud Narušitel přijde
na algoritmus, který byl použit pro pozměnění dané proměnné, tak si nikdy nemůže být jist,
zda nějaký další údaj nebyl pozměněný taktéž. V tomto případě by sice mohl identifikovat
subjekt údajů, ale velmi pravděpodobně by mohl mít nekorektní zbylé data. K pozměňování
může docházet několika různými metodami, které si popíšeme v následujících řádcích.

Mikro-agregace – Tato technika je použitelná na číselné záznamy. Příkladem může
být příjem subjektů. Nejprve je potřeba subjekty dle příjmu seřadit a poté rozdělit na
k skupin, kde k je nejméně 3. Seřazením získáme co možná nejpodobnější hodnoty
v jednotlivých skupinách. Podle počtu záznamů je potřeba upravit velikost skupiny
- 23 -
pro první či poslední skupinu. V jednotlivých skupinách pak provedeme klasický
aritmetický průměr.
Obrázek 4 - Ukázka mikro-agregace
Zdroj: Převzato z http://www.ihsn.org/home/?q=tools/anonymization/techniques

Prohazování hodnot – Spočívá v záměně hodnot v páru s jiným záznamem
v datovém souboru. Jedná se zejména o záměnu hodnot, které dělají záznam
vzácný či unikátní a tak snižují riziko zpětné re-identifikace. Na druhou stranu je tato
metoda nevhodná pro statistické účely, protože může velmi pozměnit význam dat
v případě, že dané hodnoty jsou nutné pro danou statistiku.

Náhodné prohazování hodnot – Jedná se o obdobu předchozí metody, kdy k
prohazování hodnot dochází čistě náhodně a v případě zpětné identifikace si
Narušitel nemůže být jistý, zda je ta či ona hodnota v datech správná.

Přidávání šumu – Není nejbezpečnější metodou, pokud jde o ochranu dat. Ve své
podstatě jde například jen o přidávání nul do všech vybraných záznamů či přidávání
jiného náhodně generovaného řetězce.

Pře-vzorkování – Jde o náhradu t záznamů a s hodnot z originálních dat, jejich
seřazení a zprůměrování. Rozhodnu-li se upravit 10 záznamů a u každého z nich 2
hodnoty, tak si všech 20 hodnot seřadím, každé dvě hodnoty zprůměruji a nahradím
jimi původní dvojice hodnot pro každý záznam.
7.6 Vybrané principy a techniky
Nyní je čas si říci, které z výše popsaných principů a technik budou použity při implementaci
aplikace a zároveň si odůvodnit proč tomu tak je.
- 24 -
V případě principů je to velmi jednoduché, protože aplikace bude umožňovat se zaměřovat
jak na přímé, tak na nepřímé identifikátory. Díky tomu má uživatel aplikace maximální
svobodu při rozhodování, co by mělo být anonymizováno, respektive chráněno před
zneužitím Narušitelem. Důraz je kladen na přímé identifikátory, které by měly jít nahradit
jinými náhodnými hodnotami, na základě kterých nebude možné provést zpětnou identifikaci
subjektu údajů.
U technik se nedá přesně říci, která z výše popsaných je vlastně v aplikaci použita, protože
se nejedná o aplikaci k anonymizování datových souborů pro statistické účely. Díky tomu
bylo možné si vzít z každé z nich něco, upravit to pro vlastní potřebu a spojit to do jednoho
celku. Aplikace umožňuje jak odstraňování hodnot (jejich vymazání, respektive jejich
nahrazení prázdnou či jinou hodnotou), tak prohazování hodnot. Nikoliv však mezi
jednotlivými záznamy v datovém souboru, ale s listem nadefinovaných objektů v aplikaci.
- 25 -
8.
ANALÝZA A NÁVRH ŘEŠENÍ
Cílem této kapitoly je seznámení s analýzou problému, vysvětlení problémové domény a
následným návrhem řešení daného problému. Tato kapitola se již tedy aplikací jako takovou
zabývá, avšak na vyšší úrovni abstrakce. Následující kapitola se pak bude věnovat samotné
implementační části.
8.1 Problémová doména
Finální aplikace by měla řešit potřeby reálných uživatelů a je přímo implementována pro
společnost Titio s.r.o., ve které jsem byl zaměstnán a nyní tam působím už jen jako externí
konzultant.
Zdrojem dat však není tato společnost, ale její zákazníci, kterými jsou především bankovní a
finanční instituce, telefonní operátoři a energetické společnosti. Firma má v mnoha
případech problém dostat od zákazníka včas data, která by mohla použít pro vývoj a
testování aplikací.
Obrázek 5 - Abstraktní schéma problémové domény mezi Titio s.r.o. a zákazníkem
Obrázek 5 demonstruje na vyšší úrovni abstrakce činnost divize print. Ta na prostřednictvím
konzultačních služeb spravuje a implementuje aplikace přímo u zákazníka. V tomto případě
se jedná o britskou společnost Scottish and Southern Energy (zkráceně jen „SSE“).
- 26 -
Na obrázku 5 je vidět kompetentnost dílčích subjektů. Titio s.r.o. vyvíjí v testovacím,
respektive pre-produkčním prostředí a pro svou potřebu používá anonymizovaná data, ze
kterých dostane testovací výstupní soubory.
SSE však používá produkční aplikaci, do které vstupují originální data a výstupní soubory
jsou určeny k dalšímu zpracování – doručení zákazníkovi či archivaci.
Úzkým hrdlem je právě dodání testovacích dat, které je většinou velmi zdlouhavé a
produkční data není možné z bezpečnostních důvodů použít. Na druhou stranu i dodaná
anonymizovaná data jsou v několika případech nedostačující, z důvodu aplikace nevhodné
anonymizace, která většině údajů v datovém souboru úplně sebere jejich význam a s daty,
respektive s výstupy z nich vyprodukovaných, se pak hůře pracuje. V oblasti dokumentové
kompozice je velmi důležité, aby data dávala smysl a neztratila význam jako celek. Doposud
jsem se bohužel setkal jen s řešeními, která například nahrazují vybraná pole v datech za
spleť znaků, což rozhodně není vhodná metoda pro tyto účely. Všechna řešení byla navíc
vždy určena jen pro jednu strukturu dat a nedala se aplikovat na jiná data, než pro které bylo
řešení implementováno.
8.1.1 Popis společnosti 11
Společnost Titio s.r.o. se skládá ze tří divizí.

Titio group – Jde o hlavní řídící orgán společnosti, který je nadřazený následujícím
dvoum divizím.

Titio print – V tomto případě jde o divizi poskytující tisková řešení a konzultace
12 13
svým zákazníkům, převážně postavených na HP Exstream .

Titio digital – Tato divize poskytuje vývoj aplikací a informačních systému na
zakázku, postavených na Microsoft technologiích. Zároveň poskytuje konzultace pro
Microsoft SharePoint a další.
8.1.2 Dokumentová kompozice
Dokumentová kompozice je obor, ve kterém dochází k transformaci vstupních dat na
výstupní soubory určené k doručení zákazníkovi či k archivaci. Zajišťuje kompletní
komunikaci mezi společností a jejími partnery či zákazníky. Ve většině případů jde tedy o
B2B a B2C komunikaci. Řešení dokumentové kompozice se implementuje převážně přímo
11
Titio s.r.o. [online], c2011 [cit. 2012-04-10]. Dostupný z WWW: http://www.titio.cz/
12
Jedná se o softwarové řešení společnosti Hewlett-Packard, které implementuje veškeré potřebné procesy
dokumentové kompozice
13
Hewlett-Packard. [online], c2009 [cit. 2012-04-10]. Dostupný z WWW:
http://welcome.hp.com/country/us/en/prodserv/software/eda/products/hpexstream.html
- 27 -
v prostředí zákazníka, který si zajistí vlastní zdroje pro jeho chod, nebo i po realizace dále
setrvává v rukou konzultantů dodavatele řešení, ovšem spravovaného v prostředí zákazníka.
Obrázek 6 - Transformační proces dokumentové kompozice
Výstupním souborem je sdělení informace druhé straně, nejčastěji nabývá podob klasických
dopisů, obchodních sdělení, faktur, výpisů z účtů či formulářů. Ve své podstatě jde o
jakoukoliv informaci od společnosti směrem k zákazníkovi.
Tiskové soubory
Elektronické soubory
• AFP
• PostScript
• PCL
• IJPDS
• ...
• PDF
• HTML
• TIFF
• Formulářový
soubor
• ...
Obrázek 7 - Rozdělení výstupních souborů pro dokumentovou kompozici
Standardně se produkují dva druhy výstupních souborů a to soubor určený k tisku a
elektronický soubor, například HTML soubor, který může být doručen elektronicky. Tím se
dostáváme k rozdělení výstupních souborů.
Výše uvedený seznam zmiňuje jen ty nejčastěji používané typy výstupních souborů, které se
mohou produkovat. HP Exstream například umožňuje produkci až 22 typů výstupních
souborů. Každá společnost si vybírá tiskový formát podle svých možností – závisí například
na typu tiskárny a typech souborů, které daná tiskárna podporuje. Společnost si tisk může
řešit vlastními zdroji, ale ve většině případů tuto část svěřuje třetí straně, která se rovnou
stará o následnou distribuci výstupů.
U elektronických typů souborů se obvykle jedná o PDF, které slouží k archivaci, ale i
k elektronické komunikaci se zákazníkem. Další možností je PDF uchovávat čistě k archivaci
a generovat HTML výstup pro elektronickou komunikaci se zákazníkem prostřednictvím
emailu. PDF je také nejpoužívanějším výstupem pro testovací účely, protože se s ním
pracuje daleko rychleji a jednodušeji, než se soubory, které jsou určeny přímo k tisku.
- 28 -
8.1.3 Ukázka výstupu
Následující obrázek je ukázkou tiskového výstupu společnosti SSE, který byl manuálně
anonymizovaný. Jedná se o první stranu přehledu o spotřebě elektřiny. Výstup byl
vyprodukován aplikací HP Exstream.
Obrázek 8 - Zdroj tiskového výstupu společnosti SSE
Zdroj: SSE
- 29 -
8.1.4 Ukázka dat
Následující obrázek demonstruje strukturu datového souboru ve formátu XML, který
uchovává všechny potřebné informace o zákaznících společnosti a je vždy generován
z databáze společnosti a to jen za cílem, aby byl použit jako vstupní datový soubor
v procesu
dokumentové
kompozice.
Níže
uvedený
datový
soubor
byl
manuálně
anonymizován a byl použit pro vyprodukování výstupu, který je na obrázku č. 8. Tag
<Document> je vždy právě jeden zákazník a <Page> obsahuje informace pro jednotlivé
stránky výstupu.
Obrázek 9 - Ukázka datové struktury společnosti SSE
Zdroj: SSE
- 30 -
8.2 Definice cílů práce
Samotným cílem práce je navrhnout a implementovat aplikaci, která zajistí snadné
anonymizování vstupních souborů, určených primárně pro vývoj a testování dalších aplikací
v oblasti dokumentové kompozice. Na větší úrovni abstrakce lze aplikaci popsat vcelku
jednoduše – na vstupu se očekává soubor obsahující citlivá data určená k anonymizaci, kde
na základě konfigurace aplikace a šabloně vstupního souboru, dostaneme soubor výstupní,
který po aplikaci anonymizačního algoritmu bude obsahovat již požadované fiktivní údaje.
Obrázek 10 - Procesní schéma aplikace
Celé řešení bude postaveno na .NET platformě s využitím programovacího jazyka C#.
Z důvodu možných velikostí vstupních, respektive výstupních souborů, není možné, aby bylo
řešení implementováno jako webová aplikace. Bude se tedy jednat o klasickou desktopovou
aplikaci, pro jejíž vývoj byl zvolen Windows Presentation Foundation (zkráceně „WPF“)
Aplikace by měla být především velmi jednoduchá na ovládání a velmi snadno rozšiřitelná o
další typy hodnot, které je možné generovat. Další velmi důležitou rolí je nepozměněný
význam dat ve výstupním souboru. Data by měla dávat smysl a nepozměnit vstupní soubor
jen na hromadu náhodně generovaných znaků.
- 31 -
8.2.1 Rozsah práce
Rozsah projektu je omezen na implementaci funkční aplikace, která ovšem nemůže fungovat
zcela samostatně, protože její nedílnou součástí jsou zásuvné moduly, které se starají o
generování hodnot, dle jejich nastavení.
Samotné zásuvné moduly však do rozsahu projektu spadají taktéž. V této fázi se počítá
s několika základními, které jsou vypsány níže.

Vlastní

Číslo

Datum

Jméno

Rodné číslo

Text
Zásuvné moduly musí být kompletní, to znamená včetně vlastních validací vstupních dat,
které proběhnou při vytváření instance konkrétního zásuvného modulu.
8.2.2 Výstupy práce
Název
Popis
Aplikace
Samotná aplikace, která svou funkčnost bude poskytovat d íky vloženým
zásuvným modulům.
DLL zásuvných
modulů
Jednotlivé DLL soubory, které představují vždy právě jeden konkrétní typ
objektu, který je možné anonymizovat.
Uživatelská
dokumentace
Stručný popis, jak aplikaci používat z uživatelského pohledu.
Dokumentace
Díky použití XML komentářů přímo ve zdrojovém kódu aplikace, bude
dokumentace automaticky vygenerována v MS Visual Studio.
Tabulka 1 - Výstupy práce
8.2.3 Mimo rozsah práce
Práce v první fázi neřeší přímé vytváření souborů, do kterých by bylo možné data generovat.
Je tedy vždy nutné mít vstupní soubor, který bude pro aplikaci sloužit jako šablona pro
výstupní anonymizovaný soubor.
Aplikace v první fázi také nebude podporovat další typy souborů, které se v dokumentové
kompozici také velmi často používají – columnar a delimited. V této fázi bude primárně
pracovat jen s XML soubory a implementace těchto typů souborů proběhne až v budoucích
rozšířeních aplikace, kde se zároveň počítá s implementací dalších zásuvných modulů.
- 32 -
8.3 Správa požadavků
8.3.1 Identifikované požadavky
ID
Název
Popis
REQ01
Desktopová aplikace
Aplikace bude implementována formou desktopové
aplikace, protože není třeba sdílet data napříč jejími
uživateli.
+
REQ02
Požadované
technologie
Aplikace musí být postavena na .NET platformě.
+
Podpora dat
V první fázi se počítá pouze s podporou souboru XML.
Tento typ souboru bude jako vstupní soubor do aplikace
a po následném procesu anonymizace bude výstupním
souborem opět vstupní XML soubor.
S
Variabilní architektura
Aplikace bude snadno rozšiřitelná o další podporované
typy objektů. Je tedy nutná podpora nových zásuvných
modulů, které se budou pro aplikaci jednoduše
implementovat. Přidání funkčního zásuvného modulu
nabízející standardní funkcionalitu je možné bez zásahu
do aplikace samotné.
S
REQ05
Vytváření šablon
Aplikace po načtení XML souboru projede načtené XML
a vytvoří k němu odpovídající šablonu, která je
zobrazena v hierarchické podobě jako XML soubor.
Šablona představuje obdobu schématu XML souboru.
F
REQ06
Podporované typy
objektů (zásuvné
moduly)
Aplikace musí podporovat několik typů objektů, které je
možné anonymizovat - číslo, text, jméno, datum, vlastní,
rodné číslo.
S
GUI
Aplikace bude rozložena do dvou vertikálních sloupců pravý bude pevný a bude v něm umístěn panel vlastností
instancí zásuvných modulů, list instancí a další
doplňkové panely. Levý panel bude vždy roztažen dle
velikosti okna a bude se v něm nacházet strom se
strukturou šablony daného XML souboru. Samozřejmostí
je menu v horní části okna a stavový řádek v dolní části
okna.
U
REQ08
Drag and Drop
Aplikace je určena pro business uživatele a je tedy
potřeba, aby byla co nejvíce uživatelsky přívětivá a práce
s ní byla jednoduchá, rychlá a efektivní. Pro dosažení
tohoto stavu je potřeba implementovat drag and drop
funkcionalitu při přiřazování nastavených instancí k
objektům zobrazených ve stromu, tedy do šablony.
U
REQ09
Správa objektů
Aplikace musí umožňovat CRUD jednotlivých typů
zásuvných modulů. Tedy vytvoření instance, její ukládání
do seznamu instancí, mazání a editaci.
F
REQ10
Dokumentace
Aplikace bude plně komentovaná, aby bylo možné
nechat vygenerovat dokumentaci přímo ve Visual Studiu.
U
Rychlost
Odezva aplikace bude v řádech sekund na dnešním
průměrném HW. Výjimku tvoří pouze algoritmus, který
prochází vstupní XML soubor a vytváří z něho šablonu a
samozřejmě samotný anonymizační algoritmus. Oba tyto
algoritmy by však měly být optimalizovány, aby jejich
P
REQ03
REQ04
REQ07
REQ11
Kategorie
- 33 -
provedení netrvalo v řádech desítek minut.
Ukládání
Aplikace musí umožňovat ukládání již nakonfigurovaných
instancí v listu - jde tedy o import a export těchto listů.
Důvodem je jejich možná znovu použitelnost pro více
XML souborů.
F
REQ13
Anonymizace
Aplikace musí disponovat algoritmem pro anonymizování
vstupního XML souboru na základě nadefinovaných
instancí, které budou přiřazené k elementům šablony,
která je vytvořena ze vstupního XML souboru.
F
REQ14
Unikátnost
Aplikace musí podporovat generování unikátních hodnot
pro všechny podporované typy objektů (zásuvné
moduly). Defaultním nastavením však bude možnost
opakování již vygenerovaných hodnot.
F
REQ15
Nad jednotlivými nadefinovanými instancemi v listu
Náhled generovaných
instancí bude možné volat funkci, která dle nastavení této
hodnot
instance vygeneruje náhodnou hodnotu.
F
REQ16
Jazykové mutace
Aplikace bude lokalizována v anglickém jazyce. S
žádným dalším jazykem se nepočítá.
+
REQ17
Náhlé ukončení
Aplikace se nesmí ukončit po nesprávně vyplněném
formuláři.
R
REQ18
Neporušení souboru
Při náhlém ukončení aplikace nesmí dojít k aplikaci
jakýchkoliv změn do vstupního XML souboru, aby
nedošlo k porušení integrity dat.
R
Práce s XML
Aplikace musí umožňovat otevírání souborů XML pomocí
open dialogu, kde bude filtr omezen jen na XML soubory.
Aplikace také musí podporovat ukládání XML souborů,
které bude potřebné po provedení anonymizace.
F
REQ12
REQ19
Tabulka 2 - Přehled jednotlivých požadavků
8.3.2 Prioritizované požadavky
Aplikace je funkční jen jako celek a musí být tedy dodána jen jako kompletní řešení. Při
vypuštění jakéhokoliv požadavku již aplikace nebude poskytovat takovou přidanou hodnotu,
která se od ní očekává.
ID
Priorita
Dodávka
REQ06
1
A
REQ11
1
A
REQ14
1
A
REQ18
1
A
REQ19
1
A
REQ20
2
A
REQ25
1
A
Tabulka 3 - Přehled prioritizace požadavků
- 34 -
8.4 Navrhované řešení
8.4.1 Popis navrhovaného řešení
Na základě problému a jeho analýzy je řešením implementace desktopové aplikace. Z
důvodu velikosti vstupních a výstupních dat, která se může pohybovat až ve stovkách MB,
nelze aplikaci implementovat formou webové aplikace, kde by samotná aplikace běžela na
serveru či v cloudu. U cloudu by nastal další problém kvůli přítomnosti citlivých informací.
Hlavní výhodou aplikace je její architektura podporující dohrávání nových zásuvných modulů
bez zásahu do aplikace samotné a jednoduché uživatelské rozhraní, které umožní pracovat
s aplikací jednoduše a efektivně i business uživatelům.
Hlavní přidanou hodnotou je především její vysoká efektivita při anonymizování XML
souborů, která několikanásobně zkrátí proces získání dat od zákazníka, které jsou potřebné
pro vývoj či testování.
8.4.2 XML šablona
Pod tímto pojmem se bude skrývat objekt s vlastní strukturou, která bude závislá na
vstupním XML souboru. Implementovaný algoritmus by měl být schopný z každého
vstupního XML souboru vytvořit hierarchickou strukturu objektů, v které obsáhne všechny
potřebné kombinace elementů a atributů. Poté bude sloužit pro přiřazování instancí
zásuvných modulů.
Ve finále bude především použita pro anonymizační algoritmus, kde bude tato vytvořena a
uživatelem nastavená šablona aplikována na zvolený vstupní XML soubor. Provede tak
vygenerování dle nastavení jednotlivých instancí zásuvných modulů a těmito hodnotami
přepíše hodnoty, které se nachází ve vstupním XML souboru. Podle požadavků na aplikaci
však neporuší vstupní soubor a vše uloží jako nový výstupní XML soubor.
Šablona by měla jít uložit jako rozdělaný projekt, aby bylo možné ji jednou vytvořit, nastavit
dle přání uživatele a poté ji vždy jen otevřít a aplikovat na požadovaný vstupní XML soubor.
8.4.3 Zásuvný modul
Zásuvným modulem se rozumí DLL
14
knihovna, kterou lze vyvíjet nezávisle na aplikaci.
Touto formou budou řešeny všechny typy objektů, které lze anonymizovat, respektive
generovat. Tyto zásuvné moduly pak mohou být k aplikaci kdykoliv připojeny, aby s nimi
uživatel mohl pracovat. Cílem je, aby uživatel aplikace mohl vytvářet jednotlivé instance
těchto zásuvných modulů, které si nastaví dle své potřeby. Poté by tyto instance mohl
přiřazovat elementům či atributům v XML souboru, kde by chtěl daný typ hodnot generovat.
14
Jedná se o knihovnou, která není samostatně spustitelná.
- 35 -
Obrázek 11 - Uživatel vytváří instanci zásuvného modulu
8.4.4 Architektura navrhovaného řešení
Architektura aplikace by měla být velmi jednoduchá. Datová vrstva v pravém slova smyslu
není potřeba, místo ní bude v aplikaci datová třída, která bude uchovávat objekty za běhu
apliakce. Business vrstva bude obstarávat všechny nezbytné operace a IO vrstva bude mít
na starost načítání zásuvných modulů, serializaci a deserializaci objektů atd.
Všechny ucelené části aplikace by měly být rozděleny do separátních projektů v rámci
jednoho řešení ve Visual Studiu. Každý zásuvný modul musí být také separátní projekt a
požadavkem je, aby byl naprosto nezávislý na samotné aplikaci. Jediné co musí zásuvný
modul splňovat, je implementace rozhraní – detailní popis implementace zásuvného modulu
bude ale popsána.
Obrázek 12 - Abstraktní schéma architektury aplikace
- 36 -
Uživatel tedy bude komunikovat pouze s prezenční vrstvou aplikace, které bude předkládat
XML soubor, který potřebuje anonymizovat. Prezenční vrstva bude komunikovat s vrstvou
obchodní logiky, které bude vše řídit. Nejprve bude vytvořena XML šablona ze vstupního
XML souboru vloženého uživatelem. Následně bude mít uživatel prostor pro vytvoření
vlastních instancí zásuvných modulů, které si nadefinuje dle své potřeby a poté je přiřadí
jednotlivým elementům v XML šabloně. V tuto chvíli bude aplikace již připravena
anonymizovat data a bude nutné zadat vstupní a výstupní XML soubor.
8.4.5 Návrh GUI
Grafické rozhraní by mělo být především jednoduché, intuitivní a použitelné. Žádné
specifičtější požadavky nebyly v rámci analýzy zjištěny, takže se návrh GUI snaží vycházet
z klasických aplikací, aby si uživatelé nemuseli zvykat na zcela nový přístup ovládání
aplikace.
Obrázek 13 - Návrh grafického rozhraní aplikace
Na obrázku výše je vidět, že rozpoložení panelů opravdu odpovídá jiným aplikacím a
nejedná se tak o nic unikátního. Nahoře jde o klasickou hlavní nabídku, odkud by měly být
přístupné všechny funkčnosti aplikace. Ve spodní části se nachází stavový řádek, který by
měl zobrazovat informace směrem k uživateli aplikace a zajistit tak jakousi komunikaci mezi
uživatelem a aplikací.
Dále je aplikace rozdělena vertikálně na dvě části. Levá část bude sloužit k zobrazení
hierarchické struktury vstupního XML souboru, respektive šablony, která z něj bude
vytvořena. Pravá část potom slouží k práci se zásuvnými moduly. Ve spodní části bude
možné jednotlivé instance všech zásuvných modulů vytvářet a editovat. V horní části pak
- 37 -
bude zobrazen seznam všech vytvořených instancí zásuvných modulů a bude zde možné
volat různé funkčnosti nad těmito objekty.
Mezi oknem pro zobrazení šablony XML souboru a oknem pro zobrazení listu již
vytvořených instancí zásuvných modulů by měla být implementována Drag&Drop
funkcionalita pro přiřazování jednotlivých instancí k uzlům XML šablony.
8.5 Popis použitých technologií
8.5.1 XML 15
XML je zkratka pro eXtensible Markup Language. Jedná se o značkovací jazyk, který se
velmi podobá jazyku HTML. Je tvořen hierarchickou strukturou tzv. elementů. Není však
určen k tomu, aby data zobrazoval, ale aby je udržoval v podobě, která je snadno čitelná jak
strojově, tak lidským okem. V dnešní době se jedná o nejvíce používaný způsob výměny dat
mezi různými aplikacemi a to především na internetu. Díky předem definované struktuře
elementů a jejich názvů je tak pro druhou stranu velmi jednoduché s takovýmto souborem
pracovat.
Obrázek 14 - Ukázka struktury XML souboru
Pro potřebu této práce není třeba zacházet do větších detailů, protože aplikace bude
pracovat pouze s jednotlivými elementy a atributy souborů. Nebude se zabývat dalšími
vlastnostmi, jako jsou komentáře, schémata, jmenné prostory a podobně.
Spíše je vhodné si říci, jak se bude s XML souborem pracovat. K práci s XML souborem byl
vybrán přístup DOM. Tento přístup nám poskytuje objektově orientované rozhraní a celá
hierarchická struktura dokumentu je tak načtena v paměti – to může mít negativní dopad při
dostupném menším množství paměti a při práci s objemnějšími soubory. Výhodou však je
samotná práce s XML souborem, protože nám to umožňuje dynamický a rychlý průchod
souborem či jeho úpravu.
15
POKORNÝ, Jaroslav. XML technologie – principy a aplikace v praxi. 1. vyd.
Praha : Grada, 2008. 272 s. ISBN 978-80-247-2725-7
- 38 -
K procházení hierarchickou strukturou dokumentu nám poslouží jazyk XPath. Jedná se o
prostředek, který umožňuje vybírat jednotlivé části XML dokumentu. My ho budeme využívat
k získávání kolekce elementů ze vstupního souboru, které mají být dle nadefinované šablony
anonymizovány. Vystačíme si tak s dvěma typy XPath výrazů, které budou použity jako
vstup pro DOM metody nad vstupním XML souborem.
Element - /zakaznici/zakaznik/jmeno
Tento XPath výraz nám vrátí kolekci všech elementu s názvem zakaznik z obrázku č. 13.
Lomítko na začátku výrazu symbolizuje absolutní cestu, bez něho by se jednalo o cestu
relativní a nezáleželo by tak na umístění elementu zakaznici v dokumentu.
Atribut - /zakaznici/zakaznik[@id]
Zde jde o výraz, který nám vrátí kolekci všech elementů s názvem zakaznik, které obsahují
atribut s názvem id. Opět se díky počátečnímu lomítku jedná o absolutní cestu.
8.5.2 WPF
WPF je zkratka pro Windows Presentation Foundation. Microsoft tuto technologii představil
v roce 2007 jako součást .NET Frameworku 3.0. Díky WPF je možné vytvářet aplikace
s bohatým grafickým rozhraním a vývojář tak není omezen vzhledem standardních prvků,
jako je tomu v případě Windows Forms. Pro vykreslování používá DirectX a nemá tak
problém pracovat s 2D či 3D grafikou, nebo dokonce s vektory, audiem a videem.
Podstatnou změnou je však zcela nový způsob tvorby grafického rozhraní, které je ve WPF
zcela oddělené od samotného kódu. Spolu s WPF je tak představen značkovací jazyk
XAML, který vychází z jazyka XML. V určitých případech je možné tvořit aplikaci pouze
pomocí XAML, protože disponuje velkou podporou tzv. bindingu. Ve většině případů ale
XML obstarává pouze tu zobrazovací část a v kódu se implementují potřebné handlery a
samotná logika dané aplikace.
Obrázek 15 - Ukázka grafického rozhraní WPF aplikace
Zdroj: Převzato z http://blogs.jp.infragistics.com/blogs/andrew_flick/archive/2008/01/29/netadvantagefor-wpf-rtm.aspx
- 39 -
8.6 Use-case specifikace
8.6.1 Přehled aktérů
Název
Popis
Cíle
Uživatel
Uživatelem aplikace může být
téměř kdokoliv, ale nejčastěji
se bude jednat o software
konzultanta či analytika,
pracujících v oblasti
dokumentové kompozice.
Na základě obdrženého XML
souboru, který načte do
aplikace, musí uživatel vytvořit
požadované objekty, přiřadit je
k šabloně a nechat proběhnout
anonymizační algoritmus, který
mu vrátí požadovaný finální
XML soubor.
Tabulka 4 - Přehled aktérů aplikace
8.6.2 Přehled use-case
Název
Popis
UC01
Anonymizuj
Aplikuje anonymizační algoritmus na XML
soubor, který je kompatibilní s vytvořenou
šablonou. Dle nastavení jednotlivých objektů
vygeneruje požadované hodnoty.
UC02
Otevři XML
Otevře open dialog a umožní tak uživateli
vybrat libovolný XML soubor, který chce v
aplikaci otevřít.
UC03
Ulož XML
Ukládá již anonymizovaný XML soubor.
Uživateli umožní zvolit cestu, kam se má
výstupní XML soubor uložit.
UC04
Vytvoř XML šablonu
Projede otevřený XML soubor a na základě
jeho vnitřní struktury vytvoří šablonu, která
bude sloužit pro mapování souboru v aplikaci,
kde se na ni budou přiřazovat jednotlivé
objekty.
UC05
Vytvoř objekt
Vytvoří požadovanou instanci zásuvného
modulu (objekt), kde uživatel vyplní potřebné
vstupní parametry a objekt uloží do listu všech
objektů.
Uprav objekt
Z listu objektů načte požadovaný objekt zpět do
panelu vlastností, kde má uživatel možnost
upravit jednotlivé vstupní parametry a následné
jen uloží provedené změny objektu.
Smaž objekt
Smaže požadovaný objekt z listu objektů a v
případě, že je daný objekt již přiřazen, tak se
uživatele dotáže, zda se má daný objekt
zachovat, nebo zda se má opravdu smazat
včetně všech jeho přiřazení.
Ukaž příklad
Částečně spustí UC01 nad požadovaným
objektem v listu objektů a zobrazí uživateli
náhled možné hodnoty objektu, dle jeho
nastavených parametrů.
Zajisti unikátnost
V případě, že instance přiřazení objektu
k šabloně má nastavenou vlastnost unikátnost
na ano, tak se při anonymizaci kontroluje, aby
ve výsledném souboru byla každá hodnota
tohoto objektu opravdu unikátní – za
ID
UC06
UC07
UC08
UC09
- 40 -
předpokladu, že množina možných hodnot je
stejná nebo větší, než počet výskytů v XML
souboru.
UC10
Referencuj objekt
Uskutečněno drag and drop funkcionalitou. Z
listu objektů uloží referenci na daný objekt do
vybraného nodu nebo atributu v šabloně.
UC11
Odreferencuj objekt
Smaže přiřazení na objekt pro daný node nebo
atribut v šabloně.
UC12
Ulož list
Uloží danou instanci všech objektů v listu
objektů.
Nahraj list
Nahraje požadovaný uložený list zpět do listu
objektů v aktuálně otevřeném projektu –
přepíše stávající objekty, nebo je do listu přidá
k těm stávajícím.
UC13
Tabulka 5 - Přehled jednotlivých use-case
8.6.3 Přehled mapování požadavků na use-case
REQ05
REQ09
REQ12
UC01
REQ13
REQ14
REQ15
REQ19
X
UC02
X
UC03
X
UC04 X
UC05
X
UC06
X
UC07
X
UC08
X
UC09
X
UC10
X
UC11
X
UC12
X
UC13
X
Tabulka 6 - Mapování požadavků na jednotlivé use-case
- 41 -
8.6.4 Use-case diagramy
První use-case diagram zachycuje část aplikace, kde uživatel spouští funkčnosti nad XML
soubory. Druhý use-case diagram pak demonstruje případy užití, které se vztahují
k zásuvným modulům a poslední se ukazuje IO funkčnosti a přiřazování instancí zásuvných
modulů.
Obrázek 16 - Use case diagram XML části aplikace
Obrázek 17 - Use case diagram pro instance zásuvných modulů
- 42 -
Obrázek 18 - Use case diagram pro IO případy užití a přiřazování instancí zásuvných modulů
- 43 -
9.
IMPLEMENTACE APLIKACE
Tato kapitola se věnuje implementaci samotné aplikace. Podíváme se nejprve na finální
architekturu aplikace a poté si podrobněji popíšeme dva hlavní a důležité celky – XML
šablona a zásuvné moduly. Následovat bude stručný popis důležitých tříd aplikace.
9.1 Architektura aplikace
Architektura aplikace vychází z předchozího návrhu, ale na následujícím obrázku je možné
již vidět 5 tříd, reprezentující jednotlivá okna aplikace, které bylo potřeba implementovat pro
splnění všech požadavků na aplikaci. Jedná se o hlavní okno aplikace, skrze které uživatel
s aplikací pracuje a v průběhu práce s aplikací se setká i dalšími 4 podokny.
Obrázek 19 - Architektura aplikace
- 44 -
Na obrázku je rozdělena aplikační logika a datová vrstva na dvě separátní části. V aplikaci
se ovšem jedná o jeden projekt s názvem DataAnonymizer.BLL. IPluginable je součástí
projektu
DataAnonymizer.Interfaces
a
XmlTemplateItem
je
součástí
projektu
DataAnonymizer.Entities.
Dále je součástí řešení ještě jeden projekt s názvem DataAnonymizer.Constants, který však
není z architektonického pohledu nikterak důležitý a tak je jak z obrázku, tak z dalších kapitol
vynechán. Jedná se jen o třídu obsahující konstanty, které se poté používají v aplikaci.
9.2 Vytváření XML šablony
9.2.1 Princip
Principem vytváření XML šablony je vytvoření hierarchické struktury objektů, která bude
kopírovat strukturu samotného vstupního XML souboru a vytvoří všechny možné kombinace
elementů a atributů, které se v něm nachází.
9.2.2 Objekt šablony XmlTemplateItem
Pro sestavení a uchování šablony v aplikaci je použit vlastní objekt XmlTemplateItem, který
obsahuje všechny potřebné vlastnosti.
Ve fázi sestavování nás především zajímají vlastnosti Name, Type, IsRoot, XPath a
ParentXPath. Tyto vlastnosti dokážou zajistit fungující hierarchickou strukturu, která
odpovídá požadavkům a potřebám aplikace. Ukládáme tedy jen unikátní elementy a zajímá
nás, zda jde o kořen XML souboru, samotný název elementu a jeho typ – node nebo atribut.
Důležitá vlastnost je pak XPath, podle které poznáme, které elementy již v šabloně máme.
Při anonymizaci je neméně důležitá, protože se díky ní vybírají elementy ze vstupního XML
souboru. ParentXPath pak slouží pro schopnost aplikace vykreslit tuto hierarchii objektů jako
strom elementů.
Obrázek 20 - Třída XmlTemplateItem reprezentuje XML šablonu
- 45 -
IsAnonymizable se nastavuje automaticky při sestavování XML šablony, protože algoritmus
pozná, které části souboru lze anonymizovat a které naopak nelze. IsUnique je již plně
v režii uživatele a určuje, zda přiřazená instance zásuvného modulu má být při anonymizaci
unikátní hodnota. Tyto instance se nastavují do vlastnosti PluginInstace.
9.2.3 Popis algoritmu
Sestavování XML šablony probíhá díky rekurzivní metodě, která má vždy jen jeden vstupní
parametr a to je element v rámci vstupního XML souboru. Sama sebe pak zavolá postupně
pro všechny předky daného elementu. Tím je ošetřen průchod celou strukturou souboru.
private static void ProcessNode(XmlNode node)
{
// Zajímáme se pouze elementy typu Element
if (node.NodeType == XmlNodeType.Element)
{
// Získání XPath pro daný element
string nodePath = GetNodePath(node, "");
// Pokud již tento element není uložen, tak pokračujeme dále
if (!DataManager.Instance.XmlTemplateItemList.Any(x => x.XPath ==
nodePath && x.Type == XmlTemplateItemType.Node))
{
// Získání XPath předka daného elementu
string parentNodePath = GetNodePath(node.ParentNode, "");
// Zjištění, zda element může být anonymizován -> zajímají
nás pouze elementy typu Text
bool isAnonymizable = false;
if (node.HasChildNodes)
{
foreach (XmlNode n in node.ChildNodes)
if (n.NodeType == XmlNodeType.Text)
isAnonymizable = true;
}
else
isAnonymizable = true;
// Vytvoření nového objektu XmlTemplateItem
DataManager.Instance.XmlTemplateItemList.Add(new
XmlTemplateItem()
{
// Nastavování jednotlivých vlastností pro typ Node
});
}
// Procházení všech atributů pro daný element
foreach (XmlAttribute attr in node.Attributes)
{
// Pokud tento atribut pro daný element ještě nemáme,
pokračujeme dále
if (!DataManager.Instance.XmlTemplateItemList.Any(x =>
x.ParentXPath == nodePath && x.Name == attr.Name &&
x.Type == XmlTemplateItemType.Attribute))
{
// Vytvoření nového objektu XmlTemplateItem
- 46 -
DataManager.Instance.XmlTemplateItemList.Add(new
XmlTemplateItem()
{
// Nastavování jednotlivých vlastností pro
typ Attribute
});
}
}
}
// Rekurzivní volání metody ProcessNode pro každého předka daného
elementu
foreach (XmlNode childNode in node.ChildNodes)
ProcessNode(childNode);
}
9.3 Zásuvné moduly
9.3.1 Rozhraní IPluginable
Jde o jediné, ale zároveň velmi důležité rozhraní, které musí implementovat každý zásuvný
modul, aby s ním bylo možné v aplikaci dále pracovat.
Obrázek 21 - IPluginable rozhraní
ImagePath - Každý zásuvný modul může mít svou vlastní ikonku, kterou se pak budou
všechny jeho instance odlišovat od ostatních. Tato vlastnost musí vrátit cestu k této ikonce.
InstanceName - Vlastnost, do které se za běhu aplikace ukládá název vytvořené instance.
IsValid – Tato vlastnost vrací true, pokud se jí podaří vygenerovat náhodnou hodnotu
z jejího aktuálního nastavení, jinak vrací false.
PluginAuthor – Jednoduše vrací řetězec obsahující jméno autora zásuvného modulu.
PluginDescription – Vrací řetězec obsahující popis daného zásuvného modulu.
- 47 -
PluginName – Vrací název daného zásuvného modulu.
PluginVersion – Vrací řetězec obsahující verzi daného zásuvného modulu.
Properties – Jedná se o slovník, který bude obsahovat jednotlivé vlastnosti zásuvného
modulu. Tyto vlastnosti se ve slovníku vytvoří v konstruktoru daného zásuvného modulu.
ValidityImagePath – Vrací cestu k zelené či červené ikonce. Záleží, zda je daná instance
korektně nastavena.
Anonymize() – Metoda, která provádí hlavní logiku zásuvného modulu. Z daného nastavení
instance musí vygenerovat náhodnou hodnotu konkrétního typu a poté ji vrátit jako řetězec.
BuildPropertiesPanel() – Tato metoda musí programově vytvořit potřebné ovládací prvky,
které povedou ke správnému nastavení zásuvného modulu.
9.3.2 Implementace zásuvného modulu
Vývoj nového zásuvného modulu je velmi jednoduchý. Ve své podstatě je potřeba dodržet
jen dvě věci a to korektně implementovat rozhraní IPluginable.
Prvním krokem je vytvoření nového projektu typu Class Library, v našem případě si
ukážeme tvorbu nového zásuvného modulu na jednoduchém modulu Custom, který
uživatele nechá zadat libovolný řetězec a v něm pak předdefinované značky zamění za
odpovídající hodnotu. Do projektu přidáme referenci na DataAnonymizer.Interfaces,
abychom mohli použít rozhraní IPluginable. Dále vytvoříme následující třídu, která musí být
serializovatelná, aby ji bylo možné serializovat při ukládání vytvořené instance zásuvného
modulu.
[Serializable]
public class Custom : IPluginable
{
}
Nyní je třeba začít postupně implementovat vlastnosti a metody z rozhraní. Začneme s těmi
nejjednoduššími, kde je nutné nastavit popisné vlastnosti zásuvného modulu, tedy jeho
název, popis, verzi, autora a cestu k ikonce. Pro korektní zobrazování názvu zásuvného
modulu v GUI aplikace, je nutné přetížit metodu ToString().
public string PluginName { get { return "Custom"; } }
public string PluginDescription
{
get
{
return "Creates combinations of random digits and characters,
Could be used to generate ID etc.";
}
}
public string PluginVersion { get { return "1.0"; } }
public string PluginAuthor { get { return "Patrik Jankovský"; } }
- 48 -
public string ImagePath { get { return "../Resources/Image/plugin.png"; } }
public override string ToString()
{
return PluginName;
}
Aby PluginManager mohl dynamicky číst a ukládat vlastnosti z vygenerovaných ovládacích
prvků, tak je velmi důležité, aby měl každý ovládací prvek totožný název jako má vlastnost,
kterou nastavuje. Dobrým zvykem je vytvoření konstant řetězců a ty pak používat dále
v rámci celého zásuvného modulu, aby se názvy nikde nelišily.
private const string C_INPUTSTRING = "INPUTSTRING";
V našem případě máme tedy jen jednu vlastnost, kterou budeme zásuvnému modulu
nastavovat. Dále je potřeba implementovat vlastnost pro názvy jednotlivých instancí a
vytvoření slovníku vlastností, který se bude inicializovat v konstruktoru třídy.
public string InstanceName { get; set; }
public Dictionary<string, object> Properties { get; set; }
public Custom()
{
Properties = new Dictionary<string, object>();
Properties.Add(C_INPUTSTRING, null);
}
Nyní můžeme implementovat metodu pro sestavení ovládacích prvků, které slouží pro
uživatelské nastavení instance zásuvného modulu. Pro náš příklad potřebujeme nastavovat
jen jednu vlastnost a to je řetězec, který uživatele necháme zadat do TextBoxu.
public StackPanel BuildPropertiesPanel()
{
StackPanel sp = new StackPanel()
{ Orientation = Orientation.Horizontal };
StackPanel spPanelLeft = new StackPanel();
StackPanel spPanelRight = new StackPanel() { Name = "propertyPanel" };
Label lblInString = new Label() { Content = "Input string:" };
spPanelLeft.Children.Add(lblInString);
TextBox txtInString = new TextBox() { Name = C_INPUTSTRING };
spPanelRight.Children.Add(txtInString);
sp.Children.Add(spPanelLeft);
sp.Children.Add(spPanelRight);
return sp;
}
Metoda pro sestavení ovládacích prvků musí vždy vracet objekt StackPanel, který musí
obsahovat další dva objekty totožného typu, které jsou pozicovány horizontálně vedle sebe.
Levý slouží pro název požadované vlastnosti a pravý slouží pro samotný ovládací prvek.
- 49 -
Pokud už je možné nastavit potřebné vlastnosti instance zásuvného modulu, tak se můžeme
pustit do implementace metody pro generování anonymizovaných hodnot.
public string Anonymize()
{
try
{
if (!Properties.Any(x => x.Value == null))
{
string result = Properties[C_INPUTSTRING].ToString();
// Zde je nutné provést vlastní logiku pro generování
// hodnot dle nastavení dané instance
return result;
}
else
{
throw new ArgumentException();
}
}
catch (Exception)
{
return "%ERROR%";
}
}
Hned první podmínkou se v metodě Anonymize() kontroluje, zda byly všechny vlastnosti
korektně nastaveny. Pokud ano, tak je možné si ze slovníku vlastností vytáhnout
požadované hodnoty, které uživatel instanci nastavil a vygenerovat podle nich odpovídající
náhodnou hodnotu, kterou vrátí jako řetězec. Pokud všechny vlastnosti nebyly korektně
nastaveny či v průběhu metody došlo k nějaké chybě, tak je potřeba odchytnout výjimku a
vrátit následující řetězec "%ERROR%", který zaručí správnou interpretaci dále v aplikaci.
V tuto chvíli již máme všechny důležité části rozhraní implementované a zbývají nám
poslední dvě vlastnosti, které signalizují, zda je instance korektně nastavena, či nikoliv. Na
základě této signalizace se tato skutečnost může i vizualizovat ikonkou.
public bool IsValid
{
get
{
return this.Anonymize() == "%ERROR%" ? false : true;
}
}
public string ValidityImagePath
{
get
{
if (IsValid)
return string.Format("../Resources/Image/valid.png");
return string.Format("../Resources/Image/not_valid.png");
}
}
- 50 -
Po dokončení implementace všech částí rozhraní IPluginable je nutné celý projekt se
zásuvným modulem nechat zkompilovat a výstupní DLL soubor umístit do složky Plugins
v aplikaci.
9.4 Popis důležitých tříd
9.4.1 Plugin Manager
Jedná se o statickou třídu, která se stará o dvě velmi důležité věci a tím je ukládání a
nahrávání hodnot nastavení jednotlivých instancí zásuvných modulů. Momentálně podporuje
4 ovládací prvky a to TextBox, ComboBox, CheckBox, DatePicker.
Obě metody SaveProperties() i LoadProperties() dokážou dynamicky uložit respektive načíst
všechny potřebné hodnoty z nastavení instance. Pokud zásuvný modul implementuje i jiný
ovládací prvek, než ty které jsou podporovány, tak toto nastavení bude jednoduše
ignorováno.
Obrázek 22 - Třída PluginManager
9.4.2 XML Manager
XmlManager je další statická třída, která se stará o práci s XML soubory a z nich vytvořenou
XML šablonou. V první řadě se tedy postará o samotné vytvoření XML šablony ze vstupního
XML souboru, to bude však popsáno až později. Tato třída je velmi bohatá na rekurzi,
protože většina metod se volá právě rekurzivně.
Obrázek 23 - Třída XmlManager
- 51 -
Vedle metody pro sestavení XML šablony je také velmi důležitá metoda pro sestavení
hierarchie stromu, která bude uživateli vizuálně zobrazena. Jedná se o metodu
BuildXmlTemplateHierarchy().
Tato
metoda
vytvoří
strom
z uložených
objektů
XmlTemplateItem a to díky jejich vlastnosti ParentXPath.
Metoda GetNodePath() slouží pro získání XPath výrazu pro konkrétní element v XML
souboru. Jde o rekurzivní metodu, která postupuje od daného elementu směrem nahoru ke
kořenovému elementu souboru a díky tomu dokáže poskládat řetězec obsahující právě
XPath výraz.
Dalšími dvěma metodami jsou CollapseItems() a ExpandItems(), které jsou také rekurzivní a
zajišťují rozevírání či zavírání všech předků pro konkrétní prvek v hierarchii stromu objektů.
9.4.3 Data Manager
Obrázek 24 - Třída DataManager
Třída DataManager není statická jako ty předchozí, ale jde o implementaci návrhového
vzoru Singleton. To znamená, že poprvé, co se s třídou začne pracovat, se vytvoří její první
a jediná instance v rámci aplikace. Při každém dalším volání metody v této třídě se bude
vždy jednat o instanci, která byla vytvořena při prvním volání. Důvodem je její použití, které
- 52 -
spočívá v uchovávání objektů za běhu aplikace. Není tedy žádoucí, aby v aplikaci bylo více
než jedna instance této třídy.
Nejdůležitější části této třídy jsou dvě vlastnosti XmlTemplateItemList a PluginInstanceList,
které uchovávají dané objekty vytvořené uživatelem za běhu aplikace. Všechny metody
dané třídy pak provádějí operace pouze nad těmito dvěma vlastnostmi. V obou případech
jde o list objektů konkrétního typu.
Metody se starají o vytváření a přiřazování nových objektů, o mazání objektů a jejich úpravu.
Dále také například o získávání všech referencí konkrétní instance zásuvného modulu
v XML šabloně.
9.4.4 IO Manager
Obrázek 25 - Třída IOManager
V tomto případě jde opět o statickou třídu, která v aplikaci obstarává vstupně-výstupní
operace. Metoda LoadPlugins() je volána vždy při startu aplikace a načte všechny dostupně
zásuvné moduly, které se v tu chvíli nacházejí ve složce Plugins.
public static List<IPluginable> LoadPlugins()
{
List<IPluginable> plugins = new List<IPluginable>();
foreach (string Filename in
Directory.GetFiles(System.IO.Path.Combine(AppDomain.CurrentDomain.BaseD
irectory, Constants.PLUGIN_FOLDER), Constants.PLUGIN_FILE))
{
try
{
Assembly ass = Assembly.LoadFile(Filename);
foreach (Type asmType in ass.GetTypes())
{
if (typeof(IPluginable).IsAssignableFrom(asmType))
{
IPluginable plugin =
(IPluginable)Activator.CreateInstance(asmType);
- 53 -
plugins.Add(plugin);
}
}
}
catch (Exception)
{
// Jeden zásuvný modul nebyl načten
throw;
}
}
return plugins;
}
Kromě načítání zásuvných modulů, se třída IOManager stará ještě o serializaci a
deserializaci objektů v aplikaci, za účelem uložení XML šablony či listu instancí zásuvných
modulů uživatelem. V obou případech je serializace i deserializace řešena stejným
způsobem a tak si vystačíme s ukázkou zdrojového kódu pro serializaci XML šablony.
public static bool SaveProject(string path, List<XmlTemplateItem>
xmlTemplateItemsToSave)
{
try
{
MemoryStream stream = new MemoryStream();
BinaryFormatter formatter = new BinaryFormatter();
formatter.AssemblyFormat =
System.Runtime.Serialization.Formatters.FormatterAssemblyStyle.Si
mple;
formatter.Serialize(stream, xmlTemplateItemsToSave);
File.WriteAllBytes(path, stream.ToArray());
return true;
}
catch (Exception)
{
return false;
}
}
Jediným rozdílem v obou případech je list objektů, který je serializován. Je tedy nutné, aby
objekt XmlTemplateItem a všechny zásuvné moduly byly serializovatelné. V případě
ukládání XML šablony však automaticky dochází i k ukládání instancí zásuvných modulů,
které jsou přiřazeny k daným objektům.
9.5 Serializace a Deserializace
Jak již bylo popsáno v IOManager třídě, tak načítání a ukládání se v rámci aplikace řeší
serializací a deserializací objektů. Nyní už je jen nutné dodat názvy typů souborů.
- 54 -
*.das
*.dap
• Data Anonymizer Solution
• Obsahuje XML šablonu a všechny
instance zásuvných modulů, které
jsou k ni přiřazeni
• Data Anonymizer Plugins
• Obsahuje pouze list vytvořených
instancí zásuvných modulů
Obrázek 26 - Typy souborů pro serializaci a deserializaci
V rámci aplikace je možné se setkat se dvěma typy souborů. Důvodem je možnost uložení
celého projektu, to znamená uložení XML šablony a všech přiřazených instancí zásuvných
modulů, ale také uložení pouze samostatných zásuvných modulů, které chce uživatel
například použít i pro jiný projekt.
9.6 Aplikace XML šablony při anonymizaci
Vytvořená a nastavená XML šablona může být aplikována na jakékoliv vstupní XML
soubory. Principem je získávání elementů ze vstupního souboru na základě XPath výrazů
v šabloně. Aplikace vždy načte kolekci elementů, které se mají anonymizovat dle šablony a
vygeneruje pro ně nové hodnoty, které splňují nastavení přiřazené instance zásuvného
modulu. Obdobně aplikace zpracuje i všechny potřebné atributy. Vybírání elementů pomocí
XPath je bezpečný způsob, protože pokud je struktura vstupního XML souboru naprosto
odlišná od struktury souboru ze kterého byla vytvořena šablona, tak nedojde k žádné změně
a na výstupu dostaneme nezměněný vstupní soubor.
Získávání nových hodnot je provedeno rekurzivně, abychom mohli zabezpečit unikátní,
pokud mají být použity. Po dokončení anonymizace se nově vytvořený výstupní XML soubor
uloží do uživatelem definované složky.
9.6.1 Popis algoritmu
// Vytvoření listu pro ukládání použitých hodnot a získání listu s objekty XML
šablony
List<string> usedValues = new List<string>();
List<XmlTemplateItem> allXmlTemplateItems =
dataManager.XmlTemplateItemList.FindAll(x => x.PluginInstance != null);
// Kód odstraněn pro větší přehlednost
//Procházení listu XML šablony
foreach (XmlTemplateItem xmlItem in allXmlTemplateItems)
{
// Pokud je objekt šablony typu Node
- 55 -
if (xmlItem.Type == XmlTemplateItemType.Node)
{
// Získání všech elementů ze vstupního XML souboru na základě
XPath výrazu
XmlNodeList nodeList = xmlDoc.SelectNodes(xmlItem.XPath);
// Procházení listu získaných elementů
foreach (XmlNode node in nodeList)
{
// Pro každý element je potřeba získat novou
hodnotu
node.InnerText = GetNewValue(xmlItem, usedValues);
}
}
// Pokud jde o atribut
else
{
// Získání všech elementů, které mají daný atribut
XmlNodeList nodeList =
xmlDoc.SelectNodes(xmlItem.ParentXPath);
// Procházení všech získaných elementů
foreach (XmlNode node in nodeList)
// Procházení všech atributů daného elementu
foreach (XmlAttribute attr in node.Attributes)
{
// Pokud se jedná o námi hledaný atribut
if (attr.Name == xmlItem.Name)
{
// Pro atribut je potřeba získat novou
hodnotu
attr.Value = GetNewValue(xmlItem,
usedValues);
}
}
}
}
- 56 -
10. HOTOVÉ ŘEŠENÍ
Tato kapitola má za úkol představit již hotovou aplikaci a na ukázkovém datovém souboru
demonstrovat její funkčnost. Zabývat se tedy budu jen hlavním oknem aplikace, abychom
mohli porovnat požadovaný návrh GUI a finální podobu GUI aplikace. Poté bude následovat
ukázka samotné funkčnosti, kdy nejprve představím mnou vytvořený testovací XML soubor,
který jsem pro tuto ukázku použil. Dalším krokem bude popis nastavení XML šablony
v aplikaci, respektive všech instancí zásuvných modulů, které jsou v šabloně přiřazeny. A
jako poslední krok je ukázka výstupního XML souboru, který již bude obsahovat údaje
generované samotnou aplikací.
10.1
Náhled hotové aplikace
Na následujícím obrázku lze vidět finální podobu GUI aplikace. Již na první pohled je patrné,
že prvotní požadavek na vzhled, respektive rozmístění prvků aplikace, byl dodržen. V horní
části se nachází hlavní nabídka, ve spodní se naopak nachází stavový řádek. Levé části
dominuje hierarchická struktura XML šablony a na pravé straně se nachází seznam všech
vytvořených instancí zásuvných modulů, spolu s panelem pro jejich vytváření a úpravu.
Jediným rozdílem je přítomnost panelu úplně vlevo, který zobrazuje nastavení vybraného
elementu v šabloně.
Obrázek 27 - Náhled GUI hotové aplikace
- 57 -
10.2
Test anonymizace
10.2.1
Vstupní data
Obrázek níže slouží jako ukázkový XML soubor pro demonstraci funkčnosti aplikace. Soubor
byl ručně vytvořen jen pro tento účel. Lze si všimnout, že ne každý zákazník má stejnou
vnitřní strukturu – jejich elementy nejsou shodné. Tato skutečnost nám umožňuje
vyzkoušení algoritmu pro vytváření XML šablony, zda opravdu dokáže sestavit šablonu tak,
aby obsahovala všechny elementy, které se v daném souboru nachází.
Obrázek 28 - Vstupní XML soubor
10.2.2
Nastavení XML šablony
Pro danou šablonu bylo nutné vytvořit 7 instancí zásuvných modulů a jejich nastavení bylo
následující.
Identifikační číslo (Custom) – použito pro generování ID zákazníka. Instance nastavena
maskou „{L}{L}-{D}{D}{D}“. Tento zásuvný modul ponechává vlastní zadaný řetězec a pouze
nahrazuje {L} za libovolné písmeno v rozsahu A až B a {D} za libovolnou číslici v rozmezí 0
až 9.
Jméno (Name) – nastaveno pro generování pouze křestních jmen.
- 58 -
Příjmení (Name) – nastaveno pro generování pouze příjmení.
Datum narození (Date) – dle nastavení bude generovat datum v rozmezí od 16.3.1979 až
25.3.1994. Jako formát byla zvolena maska „ddmmyyyy“ a tečka jako oddělovač jednotlivých
částí data.
Hotovost (Number) – nastaveno pro generování celých čísel v intervalu od 100000 do
1000000. Zároveň se za číslo bude vždy přidávat řetězec „ CZK“.
Poznámka (Text) – dle nastavení bude generovat text založený na Lorem ipsum a jeho
délka bude v rozmezí od 10 do 50 znaků.
Rodné číslo (BirthNumber) – nastaveno pro generování rodných čísel v rozmezí od
8.2.1989 do 14.6.1990. Může se jedna o ženské i mužské a na výstupu bude přítomné
oddělovací lomítko.
10.2.3
Výstupní data
Následující obrázek je již výstupní soubor, na který byla aplikována anonymizační šablona.
Můžeme se všimnout, že struktura dat zůstala nepozměněna a rozdílné jsou akorát hodnoty.
Dle zpětné kontroly jsou všechny vygenerované hodnoty korektní a v rámci svého nastavení.
Zároveň je vidět, že si aplikace poradila i se sestavením šablony pro strukturu, která je
různorodá a elementy nejsou vždy shodné.
Obrázek 29 - Výstupní XML soubor
- 59 -
11. UŽIVATELSKÁ DOKUMENTACE
Závěrečná kapitola je věnována uživatelské dokumentaci. Nejprve vysvětlím, jak vytvořit a
pracovat s XML šablonou a poté se podívám na jednotlivé zásuvné moduly, respektive jejich
vytváření a práce s nimi. Na závěr ukážu workflow diagram aplikace.
XML Šablona
11.1
Slouží po boku zásuvných modulů jako hlavní prvek celé aplikace, který je potřeba vytvořit,
nastavit a poté je možné podle něj nechat požadovaný XML soubor anonymizovat.
Vytvoření XML šablony
11.1.1
Vytvoření XML šablony je stejně jako všechny další funkčnosti aplikace velmi jednoduché.
Stačí z hlavní nabídky vybrat New Project a zvolit XML, dle kterého by měla být šablona
vygenerována.
Až skončí algoritmus pro vytvoření šablony, tak se šablona automaticky zobrazí v hlavní
části pracovní plochy aplikace a to ve stromové hierarchii.
11.1.2
Funkčnosti nad XML šablonou
Nad samotnou šablonou se dá spouštět jen pár funkčností a to:

Expand All items – Rozevře kompletní hierarchickou strukturu šablony.

Collapse All items – Zavře kompletní hierarchickou strukturu šablony.

Expand Child items – Rozevře kompletní hierarchickou strukturu pro vybraný prvek
šablony.

Collapse Child items – Zavře kompletní hierarchickou strukturu pro vybraný prvek
šablony.
Dále je možné šablonu uzavřít, uložit či otevřít již uloženou. Vše je dostupné v hlavní
nabídce aplikace v místě, kde se nachází i vytvoření zcela nové šablony.
11.1.3
Vlastnosti prvků XML šablony
Následující obrázek demonstruje část již vytvořené a nastavené šablony, která byla použita
pro testovací příklad v předešlé kapitole. Je třeba rozlišit, které prvky mohou mít hodnoty a
které je mít nemohou. Aplikace to vizuálně rozlišuje za uživatele, a pokud je možné daný
prvek šablony anonymizovat, tak je vedle jeho názvu zelená ikonka, v opačném případě se
tam nachází červená ikonka.
- 60 -
Aplikace také vizuálně rozlišuje, který prvek je elementem a který atributem. Jako poslední
zobrazená informace je XPath prvku v XML souboru.
Obrázek 30 - Ukázka XML šablony a panelu s vlastnostmi aktivního prvku
V levé části obrázku se nachází panel s vlastnostmi konkrétního prvku šablony. Zobrazuje
název, typ prvku a možnost zvolit generování pouze unikátních hodnot. Dále zobrazuje
případnou referenci na instanci zásuvného modulu, kterou je možné odstranit přímo z tohoto
panelu.
11.2
Zásuvné moduly
K tomu, aby bylo možné nastavit šablonu a při anonymizaci generovat nějaká data, tak je
potřeba mít alespoň jeden zásuvný modul. V této verzi, je k aplikaci dodáno 6 základních a
já nyní projdu všechny z nich, abych uvedl jejich význam a možnosti.
Pro dostupné zásuvné moduly je možné v hlavní nabídce spustit Plugin Manager, který
zobrazí všechny aktivní zásuvné moduly s jejich popisem, autorem a verzí.
Obrázek 31 - Plugin Manager okno v aplikaci
- 61 -
11.2.1
Birthnumber
Slouží pro generování rodných čísel v českém formátu. Jeho možnosti nastavení jsou
následující:

Minimal value – Datum od kterého je potřeba rodná čísla generovat.

Maximal value – Datum do kterého je potřeba rodná čísla generovat.

Sex – Typ rodného čísla vzhledem k pohlaví.

Show slash – Určí, zda bude rodné číslo zobrazeno s lomítkem, či nikoliv.
11.2.2
Custom
V současné verzi se jedná o opravdu velmi jednoduchý zásuvný modul, který dovoluje
uživateli zadat libovolný řetězec a do něho zakomponovat určité značky, které budou
v průběhu generování hodnot nahrazeny. Cílem je například možnost generovat různá ID,
která mají mít specifický tvar. Nyní jsou podporovány tyto značky:

{D} – Bude nahrazeno za náhodné číslo v intervalu 0 až 9.

{L} – Bude nahrazeno za náhodné písmeno v rozmezí A až Z.

{l} – Bude nahrazeno za náhodné písmeno v rozmezí a až z.
11.2.3
Date
Slouží pro generování náhodného data v určitém intervalu a formátu.

Minimal value – Datum od kterého je potřeba generovat.

Maximal value – Datum do kterého je potřeba generovat.

Format – Výstupní formát vygenerovaného data, který určuje kombinace dnů,
měsíců a roků.

Delimiter – Doplňuje výstupní formát a určuje, zda má být použit nějaký oddělovač
mezi dny, měsíci a roky.
11.2.4
Name
Tento zásuvný modul generuje náhodná jména – dochází ke kombinaci dvou souborů, kde
první z nich obsahuje sadu českých křestních jmen a ten druhý sadu anglických příjmeních.
Nastavení zásuvného modulu je jednoduché.

Format – Určuje, zda se bude generovat pouze křestní jméno, pouze příjmení, nebo
jejich kombinace.
- 62 -
11.2.5
Number
Slouží pro generování náhodných čísel v určitém zvoleném rozsahu, typu a případně i
v kombinaci s libovolným řetězcem.

Minimal value – Hodnota od kterého je potřeba čísla generovat.

Maximal value – Hodnota do kterého je potřeba čísla generovat.

Value type – Volí mezi celým číslem a číslem s plovoucí desetinou čárkou.

Symbol to include – Umožňuje zadat libovolný řetězec, který lze přidat
k vygenerovanému číslu.

11.2.6
Symbol position – Určuje pozici zadaného řetězce.
Text
Generuje náhodný textový řetězec v určité délce, založený na sadě Lorem ipsum slovech.

Minimal value – Minimální požadovaná délka textového řetězce.

Maximal value – Maximální požadovaná délka textového řetězce.
11.3
Správa instancí zásuvných modulů
Všechny vytvořené instance zásuvných modulů se automaticky ukládají do listu, který je
zobrazen na následujícím obrázku. Zde je možné volat všechny potřebné funkčnosti a to
z hlavní nabídky, panelu nad listem či kontextové nabídky přímo nad konkrétní instancí.
Aplikace vizuálně rozlišuje typy jednotlivých instancí a úplně vpravo se zobrazuje zelená
ikonka v případě, že instance je již korektně nastavena, jinak se zobrazuje červená ikonka a
nastavení je nutné doplnit, aby bylo možné danou instanci použít při anonymizaci, protože
bez něho není instance schopna generovat hodnoty.
Obrázek 32 - Ukázka panelu s již vytvořenými instancemi zásuvných modulů
- 63 -

Open object list – Otevře již uložený list instancí.

Save object list – Uloží aktuální list instancí.

Add new object – Zobrazí panel pro vytvoření nové instance.

Delete All objects – Odstraní všechny instance, které nemají žádnou referenci.

Show example – Otevře okno s nastavením instance a možností generovat
náhodné hodnoty dle daného nastavení.

Edit object – Zobrazí panel pro úpravu nastavení instance.

Reference object – Přiřadí instanci vybranému prvku v XML šabloně. (Slouží jako
alternativní způsob k Drag&Drop funkcionalitě)


Where referenced – Otevře okno s listem všech referencí instance.


Unreference object – Odstraní všechny reference instance.

Delete object – Odstraní instanci.
11.3.1
Vytvoření konkrétní instance zásuvného modulu
Vytvoření nové instance je velmi jednoduché. Stačí zvolit Add new object a zobrazí se panel,
kde je potřeba vybrat typ, respektive zásuvný modul, který chceme pro novou instanci
použít. Poté je potřeba dát instanci jméno, které musí být v rámci aktuálního listu unikátní.
Jednotlivé nastavení instance není potřeba vyplňovat hned a je tedy možné si nejprve
předpřipravit všechny instance a až poté se věnovat jejich nastavení.
Obrázek 33 - Panel pro vytvoření nové instance vybraného zásuvného modulu
- 64 -
11.3.2
Přiřazování instancí k prvkům šablony
Tato funkcionalita má dva způsoby, jak ji uskutečnit. Prvním z nich je velmi jednoduchý
způsob Drag&Drop, kdy stačí přetáhnout požadovanou instanci zásuvného modulu v listu a
přetáhnout ji na konkrétní prvek v XML šabloně.
Druhým způsobem je označení požadovaného prvku v XML šabloně a poté spustit funkčnost
Reference object nad konkrétní instancí zásuvného modulu.
11.3.3
Zobrazení náhodných hodnot
Funkčnost slouží pro generování náhodných hodnot instance dle aktuálního nastavení. Je
možné ji pro konkrétní instanci spustit díky Show example.
Obrázek 34 - Okno pro generování náhodných hodnot instance
11.3.4
Zobrazení všech referencí
Pokud je potřeba zjistit, kde všude je instance v XML šabloně přiřazena, tak není potřeba
procházet jednotlivé prvky XML šablony a kontrolovat, zda daná instance je či není
přiřazena. Je totiž možné spustit funkčnost Where referenced, která to udělá za uživatele a
zobrazí okno se seznamem všech prvků šablony, kde se daná instance nachází. Zároveň je
možné jednotlivé přiřazení odstranit přímo z tohoto okna.
Obrázek 35 - Okno pro zobrazení všech referencí instance
- 65 -
11.4
Anonymizace XML souboru
Za předpokladu, že má uživatel vytvořenou XML šablonu a vytvořený minimálně jednu
instanci zásuvného modulu, která je v šabloně přiřazená, tak může dle této šablony nechat
anonymizovat vybraný XML soubor. Stačí spustit funkčnost Anonymize a objeví se okno,
které je vidět na následujícím obrázku.
Obrázek 36 - Anonymizační okno
Před samotnou anonymizací je nejprve nutné vybrat XML soubor, který se má anonymizovat
a poté soubor, do kterého bude uloženo výsledné XML po anonymizaci. Během
anonymizačního algoritmu aplikace uživatele informuje o aktuálním dění a například
vypisuje, který prvek zrovna zpracovává a jaké hodnoty pro něj generuje.
11.5
Minimální systémové požadavky 16
Systémové požadavky se v podstatě shodují s minimálními systémovými požadavky pro
.NET Framework 4.
16

Procesor: 1 GHz a více

Operační paměť: 512 MB a více

Volné místo na disku: 850 MB pro 32-bit OS, 2 GB pro 64-bit OS

Operační systém: Microsoft Windows XP (po aplikaci Service Pack 2) a vyšší
.NET Framework System Requirments [online], c2012 [cit. 2012-05-11]. Dostupný z WWW:
http://msdn.microsoft.com/en-us/library/8z6watww.aspx
- 66 -
11.6
Workflow aplikace
Na obrázku 37 je vidět jednoduché workflow aplikace. Nejprve je nutné zvolit vstupní XML
soubor, dle kterého chceme vytvořit XML šablonu, a aplikace ji sama pro tento soubor
vytvoří. Poté si uživatel vydefinuje všechny potřebné instance zásuvných modulů, které chce
v rámci vytvořené šablony aplikovat a může je přiřadit k daným elementům či atributům
v šabloně. Posledním krokem je spuštění samotné anonymizace, kde uživatel zadá vstupní
a výstupní XML.
Nastavení
instancí
Vytvoření
XML
šablony
Přiřazení
instancí
prvkům
šablony
Výběr XML k
anonymizaci
a určení
výstupního
XML
Vytvoření
instancí
zásuvných
modulů
Obrázek 37 - Workflow aplikace
Workflow aplikace se může lišit v případě, kdy uživatel již má nějakou XML šablonu
uloženou jako rozpracovaný projekt. V tomto případě ji stačí jen nahrát do aplikace a ihned
se může přistoupit k poslednímu kroku. Stejně tak může být přeskočen pouze krok
s vytvářením jednotlivých instancí zásuvných modulů, pokud již má uživatel například
předpřipravenou a uloženou paletu zásuvných modulů, které chce používat, tak je může
opět lehce nahrát do aplikace.
- 67 -
12. ZÁVĚR
V průběhu této bakalářské práce vznikl prototyp aplikace, sloužící k anonymizování XML
souborů. Aplikace byla implementována nad .NET Frameworkem, přesněji pak na
technologii WPF a pro psaní samotného zdrojového kódu posloužil objektově orientovaný
jazyk C#. Využití .NET Frameworku byl přímo jeden z požadavků na aplikaci, ale WPF a C#
jsem si zvolil sám. WPF jsem dal přednost před Windows Forms a to z důvodu větší
flexibility při návrhu uživatelského rozhraní díky jazyku XAML, ale především se jedná o
novější a modernější technologii.
Cílem aplikace je anonymizování XML souborů dle požadavků uživatele. Tento cíl jsem
splnil a navíc se mi podařilo dodržet přívětivé uživatelské rozhraní, takže s aplikací může
pracovat i kterýkoliv administrativní pracovník. Aplikace na vstupu načte uživatelem vybraný
XML soubor a vytvoří z něho XML šablonu, která obsahuje hierarchickou strukturu
unikátních elementů a atributů daného XML souboru. Poté je uživateli umožněno vytváření
vlastních instancí zásuvných modulů, které v aplikaci přiřadí do patřičných elementů či
atributů. Aplikace v této verzi uživateli nabídne 6 základních zásuvných modulů, kde každý
z nich představuje jeden konkrétní typ hodnot (číslo, text, jméno, datum, …), které lze
generovat. Důvodem zvolení tak zvané plugin-ready architektury byl požadavek na snadnou
rozšiřitelnost aplikace. Díky tomu je možné vytvořit nový zásuvný modul, který je na samotné
aplikaci zcela nezávislý. Aplikace umožňuje XML šablonu či vytvořené instance zásuvných
modulů uložit, aby je bylo možné používat opakovaně. Z toho vyplývá výhoda znovupoužití
již nastavené XML šablony na více vstupních XML souborů v libovolném časovém
rozestupu.
Po nastavení XML šablony může uživatel anonymizovat libovolné množství vstupních XML
souborů. Aplikace vždy načte vstupní soubor, na který aplikuje nadefinovanou XML šablonu
a výsledek uloží do uživatelem zvoleného nového XML souboru. Aplikace šablony znamená
získání všech elementů a atributů, které jsou obsaženy ve vstupním XML souboru a
vygenerovat pro ně novou náhodnou hodnotu, o kterou se postará instance zásuvného
modulu, která je k danému elementu či atributu přiřazena. Pro komunikaci mezi vstupním
XML souborem a XML šablonou je využit jazyk XPath.
Jelikož se zatím jedná pouze o prototyp aplikace, tak je do budoucna potřeba provést ještě
spoustu dalších rozšíření. Prvním z nich bude rozšíření palety podporovaných zásuvných
modulů, kde je potřeba implementovat mnoho nových. Příkladem může být možnost
generování adres, takový zásuvný modul by měl dovolovat generovat adresy založené na
reálných podkladech a formátovat je dle uživatelovy potřeby. Navíc by měl umožňovat pro
jednotlivé instance vytvořené z tohoto zásuvného modulu generovat jen konkrétní část
adresy. Dalším příkladem může být generování různých identifikátorů, například True a
False a jim obdobné. Implementace by mohla být provedena tak, že nastavení instance
- 68 -
zásuvného modulu uživateli dovolí nadefinovat list konkrétních řetězců a zásuvný modul pak
bude vybírat náhodný z nich.
Dalším vylepšením na straně zásuvných modulů může být napojení slovníkových typů, jako
jsou například jména a adresy, na veřejně dostupné databáze, místo čerpání z vlastních
lokálních zdrojů aplikace.
Důležité rozšíření však čeká i XML šablonu. Jedním z nich je možnost přiřazování více
instancí zásuvných modulů do jednoho elementu či atributu a zvolit metodu, která bude
zvolena pro jejich střídání při anonymizaci – náhodně, postupně. To hlavní ale bude možnost
aritmetických operací nad číselnými hodnotami. Příkladem může být tabulka s výčtem
bankovních transakcí za jeden měsíc, kde chceme, aby na konci byl součet hodnot všech
transakcí. Uživatel tedy bude schopný na daném elementu či atributu nastavit seznam
požadovaných elementů a atributů, které ponesou instanci zásuvného modulu číselného
typu a určit, jaká aritmetická operace se má provést.
Tohle je výčet těch nejdůležitějších rozšíření, která se musí implementovat, aby se
z prototypu aplikace stala opravdu plnohodnotná aplikace, která pomůže firmám
k rychlejšímu dodání svých XML datových souborů třetím stranám a splnila tak svůj
počáteční záměr.
- 69 -
13. CONCLUSION
During this bachelor thesis has been created a prototype of an application for XML data files
anonymization. This application has been implemented in .NET Framework with WPF
technology and object oriented language called C# has been used for writing all source
codes. Usage of .NET Framework was one of the requirements, but both WPF and C# have
been chosen by me. I have chosen WPF instead of Windows Forms, because it is more
flexible when designing the user interface thanks to XAML, but the main reason was it is
much more later and modern technology.
Aim of this application is anonymization of XML data files according to user’s needs. This
goal has been accomplished and on top of that I have still managed to preserve the affability
and simplicity of the application, therefore even business users could easily work with the
application. Application loads an input XML data file which is being selected by user and
then creates an XML template for it, which contains hierarchical structure of unique elements
and attributes from the input XML data file. As soon as this is done user is able to create his
own plugin instances, which could be referenced into requested elements and attributes.
This version of the application offers 6 basic plugins and each of these plugins represents
particular value type (number, text, name, date, …), that will be generated. Reason for this
so called plugin-ready architecture was a requirement for easy expandability of the
application. Thanks to that a new plugin could be implemented without any dependencies on
the application itself. Application allows to save both the XML template and plugin instances,
so they could be reused in future. This means XML template has an advantage of reusability
so user could use it for many different XML data files and whenever he needs.
After the XML template has been set up the user is able to anonymize any input XML data
file he wants. Application loads the input XML data file every time and applies the XML
template on it. Result is being saved into new XML data file, which is selected by user. XML
template application means to select all elements and attributes which are present within the
input XML data file and generate for them new random value according to the plugin
instance that is referenced in the element or attribute. For communication between the XML
template and the input XML data file is used XPath.
Because this is just a prototype of the application, I already know a lot of other features need
to be implemented. First of them would be to extend the range of supported plugins with
some new ones. As an example could be used plugin which would generate addresses. This
plugin would need to generate addresses based on real data and display them as user
needs them to be displayed. In addition to that it should allow to select a particular part of the
address for individual plugin instances. Another example could be generating of random
identifiers – True, False and so on. Implementation of this plugin could be done in way that
- 70 -
allows user to add random strings into one list and the plugin instance would be generating a
random string from the defined list.
Next improvement for plugins would be for dictionary type plugins, for example name and
address, so they could be linked to some public database source and take data from there
instead of using the local data.
Important extension is needed for the XML template as well. One of them is referencing
more than just one plugin instance into one element or attribute with method that could be
selected by user to set how the instances should be taken – randomly, in order. The main
extension would be a feature that would allow to apply arithmetical operations on numerical
value types. For example imagine some table with few rows and each of those rows contains
bank transaction information and amount. At the end of the table should be a summary row
and total amount. Therefore the application should allow user to select some elements and
attributes which have referenced a plugin instance of some numerical type and say what
kind of numerical operation should be used.
This is a list of the most important features which need to be implemented so the prototype
could be transformed into full-value application that helps companies to improve the process
when delivering their XML data files to third parties and also all these features would
accomplish the original purpose.
- 71 -
14. SEZNAM POUŽITÉ LITERATURY
1. NASH, Trey. C# 2010 : Nejlepší průvodce novinkami a nejlepšími postupy. 1. vyd.
2. PETZOLD, Charles. Mistrovství ve Windows Presentation Foundation. 1. vyd.
3. PIALORSI, Paolo, RUSSO, Marco. Microsoft LINQ : Kompletní průvodce
programátora. 1. vyd. Brno : Computer Press, 2009. 615 s. ISBN 978-80-251-2735-3
4. POKORNÝ, Jaroslav. XML technologie – principy a aplikace v praxi. 1. vyd.
Praha : Grada, 2008. 272 s. ISBN 978-80-247-2725-7
5. Úřad pro ochranu osobních údajů [online], http://www.uoou.cz/
6. BusinessInfo.cz [online], http://www.businessinfo.cz
7. International Household Survey Network [online], http://www.ihsn.org/
8. INFA Partner s.r.o [online]. http://www.infapartner.cz/
9. Titio s.r.o. [online], http://www.titio.cz/
10. Hewlett-Packard [online], http://www.hp.com
11. Microsoft Developer Network [online], http://msdn.microsoft.com/
- 72 -
15. SEZNAM POUŽITÝCH SYMBOLŮ A ZKRATEK
Zkratka
Popisek
B2B
Business to Business
B2C
Business to Customer
BLL
Business Logic Layer
CRUD
Create Read Update Delete
CSV
Comma Separated Values
DLL
Dynamic Link Library
DOM
Document Object Model
GHz
Gigahertz
GUI
Graphic User Interface
HP
Hewlett-Packard
HTML
Hyper Text Markup Language
IO
Input and Output
LINQ
Language Integrated Query
MB
Megabyte
MS
Microsoft
OS
Operation System
PDF
Portable Document Format
REQ
Requirment
SSE
Scottish and Southern Energy
UC
Use case
WPF
Windows Presentation Foundation
XAML
eXtensible Application Markup Language
XML
eXtensible Markup Language
- 73 -
16. SEZNAM OBRÁZKŮ
Obrázek 1 - Úvod do datové anonymizace ........................................................................ - 15 Obrázek 2 - Rozdělení datových identifikátorů.................................................................. - 20 Obrázek 3 - Anonymizace nepřímých datových identifikátorů.......................................... - 21 Obrázek 4 - Ukázka mikro-agregace .................................................................................. - 24 Obrázek 5 - Abstraktní schéma problémové domény mezi Titio s.r.o. a zákazníkem ....... - 26 Obrázek 6 - Transformační proces dokumentové kompozice ........................................... - 28 Obrázek 7 - Rozdělení výstupních souborů pro dokumentovou kompozici ...................... - 28 Obrázek 8 - Zdroj tiskového výstupu společnosti SSE........................................................ - 29 Obrázek 9 - Ukázka datové struktury společnosti SSE ....................................................... - 30 Obrázek 10 - Procesní schéma aplikace ............................................................................. - 31 Obrázek 11 - Uživatel vytváří instanci zásuvného modulu ................................................ - 36 Obrázek 12 - Abstraktní schéma architektury aplikace ..................................................... - 36 Obrázek 13 - Návrh grafického rozhraní aplikace .............................................................. - 37 Obrázek 14 - Ukázka struktury XML souboru .................................................................... - 38 Obrázek 15 - Ukázka grafického rozhraní WPF aplikace .................................................... - 39 Obrázek 16 - Use case diagram XML části aplikace ........................................................... - 42 Obrázek 17 - Use case diagram pro instance zásuvných modulů ...................................... - 42 Obrázek 18 - Use case diagram pro IO případy užití a přiřazování instancí zásuvných modulů
........................................................................................................................................... - 43 Obrázek 19 - Architektura aplikace .................................................................................... - 44 Obrázek 20 - Třída XmlTemplateItem reprezentuje XML šablonu .................................... - 45 Obrázek 21 - IPluginable rozhraní ...................................................................................... - 47 Obrázek 22 - Třída PluginManager .................................................................................... - 51 Obrázek 23 - Třída XmlManager ........................................................................................ - 51 Obrázek 24 - Třída DataManager ....................................................................................... - 52 Obrázek 25 - Třída IOManager ........................................................................................... - 53 Obrázek 26 - Typy souborů pro serializaci a deserializaci.................................................. - 55 Obrázek 27 - Náhled GUI hotové aplikace ......................................................................... - 57 Obrázek 28 - Vstupní XML soubor ..................................................................................... - 58 Obrázek 29 - Výstupní XML soubor.................................................................................... - 59 Obrázek 30 - Ukázka XML šablony a panelu s vlastnostmi aktivního prvku ...................... - 61 Obrázek 31 - Plugin Manager okno v aplikaci .................................................................... - 61 Obrázek 32 - Ukázka panelu s již vytvořenými instancemi zásuvných modulů ................. - 63 Obrázek 33 - Panel pro vytvoření nové instance vybraného zásuvného modulu ............. - 64 Obrázek 34 - Okno pro generování náhodných hodnot instance ...................................... - 65 Obrázek 35 - Okno pro zobrazení všech referencí instance .............................................. - 65 Obrázek 36 - Anonymizační okno ...................................................................................... - 66 Obrázek 37 - Workflow aplikace ........................................................................................ - 67 -
- 74 -
17. SEZNAM TABULEK
Tabulka 1 - Výstupy práce .................................................................................................. - 32 Tabulka 2 - Přehled jednotlivých požadavků ..................................................................... - 34 Tabulka 3 - Přehled prioritizace požadavků ....................................................................... - 34 Tabulka 4 - Přehled aktérů aplikace ................................................................................... - 40 Tabulka 5 - Přehled jednotlivých use-case ......................................................................... - 41 Tabulka 6 - Mapování požadavků na jednotlivé use-case ................................................. - 41 -
- 75 -
18. SEZNAM PŘÍLOH

Příloha 1 – Hodnocení od Titio s.r.o.

Příloha 2 – Povolení od SSE

Příloha 3 – CD
- 76 -
18.1
Příloha 1 – Hodnocení od Titio s.r.o.
- 77 -
18.2
Příloha 2 – Povolení od SSE
- 78 -
Příloha 3 – CD
18.3
CD je přiloženo u tištěné verze bakalářské práce.
Obsah CD:

Aplikace
o

o

Obsahuje finální prototyp aplikace Data Anonymizer.
Obsahuje digitální verzi bakalářské práce v PDF.
Přílohy
o
Obsahuje hodnocení od Titio s.r.o. a povolení od SSE v digitální podobě
v PDF.

Data
o
Obsahuje testovací vstupní XML soubor a uloženou XML šablonu
z aplikace.

Zdrojové kódy
o
Obsahuje kompletní zdrojové kódy aplikace, respektive projekt, který je
možné spustit v Microsoft Visual Studio 2010 a vyšším.
- 79 -

bakalářská práce - Unicorn College

Transkript

Podobné dokumenty

Bakalářka ver01 - České vysoké učení technické v Praze

Převod Windows Forms do Windows Presentation

Analýza a návrh systému pro SelfTesty

Já vám nevím, co je to dneska za módu vybírat si pro

Přednáška 13