}w!"#$%&'()+,-./012345<ya

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY }w!"#$%&'()+,-./012345<ya Interaktivní vizualizace 3D molekulárních motivů BAKALÁŘSKÁ PRÁCE Jan Richter Brno, jaro 2013

2 Prohlášení Prohlašuji, že tato bakalářská práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Vedoucí práce: RNDr. David Sehnal ii

3 Poděkování Rád bych poděkoval vedoucímu své práce RNDr. Davidu Sehnalovi za jeho rady při řešení této práce a ochotu komunikovat větší, než jsem měl já. Dále bych chtěl poděkovat své rodině za to, že to se mnou vydrželi po celou dobu studia a neustále se ptali, kdy bude tato práce hotová. iii

4 Shrnutí V dnešní době je velmi snadné získat rozmanitá molekulární data. Tato data jsou povětšinou v textovém formátu a mají specifické vlastnosti. Úkolem této práce je navrhnout a implementovat webovou aplikaci v jazyce C# využívající technologie ASP.NET MVC, která bude poskytovat potřebná API pro vizualizaci těchto dat (na základě jejich atributů) a rozhraní pro jejich interaktivní prohlížení. Dalším požadavkem na aplikaci je její rozšiřitelnost a tudíž také možnost měnit jednotlivé komponenty za účelem změny formátu dat či způsobu vizualizace samotné. iv

5 Klíčová slova vizualizace, molekulární motiv, C#, ASP.NET MVC, pdb, webová aplikace, html5, pivot viewer v

6 Obsah 1 Úvod Požadavky na aplikaci Struktura práce Struktura a reprezentace proteinů Reprezentace proteinové struktury Formát PDB (Protein Data Bank) Nástroje na vizualizaci proteinových struktur Strukturální motivy a jazyk Motive Query Shlukování a vizualizace dat Techniky shlukování dat Hierarchické metody Nehierarchické metody Použité metody vizualizace Čtyři kroky vizualizace Složitost zpracování Použité nástroje a technologie Perzistence dat Technologie bussiness logiky Nástroje prezentační vrstvy Návrh, implementace, testování Návrh zaměřený na rozšiřitelnost Návrh zaměřený na výkon Implementace Backend Loader API Frontend Testování aplikace Výsledky testů Závěr A Snímky obrazovek z jednotlivých kroků vizualizace B Hierarchický pohled na testovací data a aplikace filtrů C Elektronické přílohy vi

7 Kapitola 1 Úvod Zvláště díky neustálému rozmachu internetových služeb a také postupujícímu výzkumu v oblasti chemie a biologie je dnes dostupnost molekulárních dat velmi vysoká. Díky projektům internetových databází molekulárních struktur, jako například Protein Data Bank(PDB), Molecular Modeling Database (MMDB) či PubChem, je velmi jednoduché získat data o daných molekulárních strukturách. První dvě zmiňované databáze obsahují přibližne 90 tisíc proteinových struktur, třetí pak desítky milionů různých molekul. Jednoduše dosažitelných dat je tedy v tomto směru nepřeberné množství. Tato data mohou obsahovat záznamy koordináty atomů a vazbami počínaje, výsledky nejrůznějších experimentů konče (např. výsledky neutronové difrakce) [1]. Takový soubor dat bývá vhodný pro strojové zpracování, mimo jiné je možné z něj zjistit, z jakých motivů se daná struktura skládá, nicméně na prohlížení uživatelem je značně nevhodný. Člověku je mnohem přívětivější práce s interaktivními grafickými modely daných struktur či motivů. Proto také většina na webu dostupných databází molekul poskytuje služby na zobrazení vybraného výsledku dotazu, případně i dat ze souboru nahraného z lokálního počítače. Tyto nástroje poskytují interaktivní trojrozměrný model struktur, nicméně jsou značně limitované schopností zobrazit vždy jen jeden objekt. Pro vizualizaci většího souboru dat je nutné bud nechat zobrazit každou strukturu zvlášt, nebo zvolit jiné řešení. Jednou z možností je použití nějaké z existujících desktopových aplikací pro vizualizaci molekulárních struktur, kterých je dostupné nemalé množství, a to jak komerčních (například ChemDoodle), tak volně distribuovaných (např. RasMol, Jmol, PyMOL). Alternativou je využití webových aplikací/služeb, které mají tu výhodu, že nevyžadují instalaci na lokální počítač, a nezatěžují tak uživatele, který chce pouze vidět danou vizualizaci (ovšem za cenu nutnosti internetového připojení). Cílem této práce je vytvoření právě webové aplikace v jazyce C# (s použitím technologie ASP.NET MVC) pro interaktivní vizualizaci 3D molekulárních motivů[2]. 3D molekulární motiv je postruktura (obvykle s desítkami atomů) větších molekul (např. proteinů), pro kterou lze definovat různé deskriptory (náboje, fingerprint, atd.) a metriky (počet společných atomů, RMSD, rozdíl nábojů, atd.). Navržené řešení umožňuje uživateli vizuálně prozkoumat prostor molekulárních motivů, který je definován výše zmíněnými deskriptory a metrikami. 1

8 1. ÚVOD 1.1 Požadavky na aplikaci Prvotní účel vytvářené aplikace je vizualizace dat vyprodukovaných jíž existující webovou aplikací. To s sebou přináší dva zásadní nefunkční požadavky: 1. Vzhledem k tomu, že velikost očekávaných výstupů původní aplikace může značně přesáhnout pamět ové možnosti klientského počítače, bylo nutné vytvářenou aplikaci přizpůsobit tak, aby nekladla přílišnou zátěž na klienta a zároveň stále odpovídala v přijatelném čase. Tohoto bylo docíleno rozdělením vizualizace do více kroků. V prvním kroku je uživateli zobrazen pohled na hierarchii dat, skrz kterou uživatel projde až ke konkrétní podmnožině motivů, které jsou mu následně (v druhém kroku) zobrazeny jako pivot view. Další částí řešení tohoto požadavku je uložení načtených motivů do datového úložiště, ke kterému je přistupováno, až když je to nutné. Tím pádem je minimalizována celková pamět ová náročnost aplikace, data se do paměti načítají až ve chvíli, kdy klient vyšle požadavek na konkrétní podmnožinu dat. 2. Aby bylo aplikaci možné používat obecněji, bylo nutné zaměřit se při návrhu na její rozšiřitelnost. Řešením je co nejvolnější vazba mezi komponentami, závislosti komponent jsou definovány nikoli skrz jejich implementace, ale skrz jejich rozhraní. Hojně je používáno principu Inversion of Control a Dependency Injection [3]. Celá aplikace je pak rozdělena do čtyř modulů, které lze kdykoli nahradit jinou implementací. 1.2 Struktura práce Práce je rozdělena do čtyř kapitol, které reflektují postup při vývoji aplikace. V první kapitole je rozebírána struktura proteinů a molekulárních motivů a jejich datová reprezentace. Druhá kapitola se zabývá algoritmy na shlukování a vizualizaci dat a vysvětluje, jaké je jejich použití ve vytvářené aplikaci. Třetí kapitola analyzuje dostupné technologie a jejich použití při implementaci. Čtvrtá kapitola je pak věnována detailnímu popisu návrhu, implementace a testování aplikace. 2

9 Kapitola 2 Struktura a reprezentace proteinů Proteiny se skládají z jednoho nebo více polypeptidových řetězců, čili polymerů aminokyselinových zbytků. Prostorová struktura proteinu lze rozdělit do několika úrovní: primární, sekundární, terciární a kvartérní. [4] Primární strukturu proteinu představuje pořadí aminokyselin v polypeptidovém řetězci. Z primární struktury je možné bez dalších znalosté odvodit prostorovou strukturu proteinu a také vzájemné vztahy vůči jiným proteinům v evoluci. Jako sekundární struktura se označuje lokální sbalení polypeptidického řetězce vlivem vytváření vodíkových vazeb mezi karbonylovými a imdiovými skupinami hlavního řetězce proteinu. V proteinech se obvykle vyskytují tři typy sekundární struktury: alfa helixy, beta listy a ohyby [4]. Helixy jsou klasifikovány jako repetitivní sekundární struktura, protože dihedrální úhly hlavního řetězce se neustále opakují. Nejčastější helikální konfigurace je alfa helix. Průměrná délka alfa helixu je 10 zbytků. Dalším druhem sekundární struktury je skládaný list (také beta list). Základním prvkem beta listu je beta vlákno s dihedrálními úhly přibližně -120 a +120 stupňů. Jedná se o nataženou strukturu, která není stabilizována vnitřními vodíkovými vazbami. Tato struktura je stabilní pouze jako součást beta listu, který je stabilizován vodíkovými vazbami a van der Waalsovými interakcemi mezi sousedními vlákny. [4] Posledním typem sekundární struktury jsou ohyby. Často se nalézají u globulárních proteinů v místech, kde je nutné obrátit směr polypeptidového řetězce. Ohyby se nejčastěji nalézají na povrchu proteinů a obsahují převážně polární a nabité aminokyseliny. Terciální struktura je tvořena uspořádáním všech atomů v jednom řetězci aminokyselin. Dále se dělí na supersekundární strukturu (strukturní motivy), což je spojení několika málo elementů sekundární struktury skrze interakce postranních řetězců, a domény, což jsou shluky strukturních motivů. Právě strukturní motivy se stávají předmětem zájmu této práce. Kvarterní struktura vzniká u proteinů, které se skládají ze dvou a více polypeptidových řetězců, a je vyjádřena jako uspořádání jednotlivých peptidických řetězců v prostoru při jeho vytváření. 3

10 2.1 Reprezentace proteinové struktury 2. STRUKTURA A REPREZENTACE PROTEINŮ Je zřejmé, že aby bylo možné struktury proteinů strojově zpracovávat, je nutné jejich data vyjádřit v nějakém příhodném formátu. Obecně pro ukládání chemických sloučenin dnes existuje velká řada formátů. Tyto formáty lze rozdělit do několika kategorií podle způsobu zápisu jednotlivých prvků dané struktury. Velmi významnou vlastností formátu je použitý systém souřadnic [5]. Nejrozšířenější souřadné systémy jsou kartezský a vnitřní (interní). Kartézské souřadnice Použití kartézských souřadnic je nejpřímější a také nejpoužívanější způsob, jak popsat pozice prvků (například atomů) struktury. Každý prvek (atom) je zapsán pomocí trojice souřadnic, které udávají jeho polohu v prostoru. Vazby mezi jednotlivými prvky (např. chemické vazby mezi atomy) lze potom vyjádřit kupříkladu jako dvojice bodů (počáteční a koncový) nebo jako seznam sousedů náležící danému prvku. Velkou výhodou tohoto systému je nezávislost jednotlivých záznamů, je tedy velmi jednoduché přidávat či mazat například jednotlivé atomy a vazby bez nutnosti přizpůsobovat změnám zbytek dat. Naproti tomu při rozsáhlejší úpravě struktury je nutné přepočítat souřadnice velkého množství atomů/prvků. Vnitřní souřadnice Ve vnitřních souřadnicích jsou atomy proteinu reprezentovány jako seznam prvků obsahující délku vazby k atomu následujícímu, úhel svíraný dvěma po sobě jdoucími vazbami a torzní úhel mezi třemi vazbami. Je zřejmé, že na rozdíl od kartézských souřadnic jsou data o atomech v tomto systému na sobě závislá. Přidávání nových prvků vyžaduje dopočítat údaje o jejich poloze vzhledem k ostatním prvkům. Stejně tak odebírání a úprava záznamů vede k přepočtu souřadnic prvků na nich závislých. Naopak operace jako změna úhlu či délky vazby je ve vnitřních souřadnicích mnohem efektivnější, než v souřadnicích kartézských. Jiné systémy souřadnic Vzhledem k tomu, že existuje široké spektrum využití a operací s proteinovými daty, bývá vhodné zvolit nebo zadefinovat jinou, nepříliš používanou reprezentaci souřadnic prvků. Tento přístup může být užitečný zejména tam, kde je nutné provádět velké množství specifických operací s daty. Systém navržený pro nejvyšší možnou optimalitu při těchto operacích může výrazně zvýšit jejich efektivitu. Příkladem je použití částečných objektových souřadnic. V částech řetězce, které se vyznačují výskytem opakujících se prvků sekundární struktury se ukládají pouze informace o umístění těchto prvků. Tyto způsoby reprezentace obecně předpokládají určitou předem známou vlastnost dat, jsou tedy vhodné jen ve specifických případech, tudíž zřídka využívané. 4

11 2.2 Formát PDB (Protein Data Bank) 2. STRUKTURA A REPREZENTACE PROTEINŮ PDB je textový formát určený pro reprezentaci trojrozměrných makromolekulárních struktur [1]. Byl vyvinut jako formát pro ukládání experimentálně zjištěných struktur v online databázi proteinových struktur Protein Data Bank. Databáze Protein Data Bank slouží jako volně přístupný archiv proteinových struktur ve formátu PDB. Byla založena roku 1971 laboratoří Brookhaven National Laboratory se sedmi zveřejněnými strukturami, následně její správu převzala organizace Research Collaboratory for Structural Bioinformatics. Ke dni obsahuje téměř modelů struktur proteinů. K získání většiny záznamů byla použita metoda rentgenové krystalografie. Každý soubor je jednoznačně odlišitelný podle názvu, který se skládá vždy ze čtyř znaků. Celkový počet unikátních struktur proteinů je však nižší. Důvodem je různé označení dvou stejných struktur, kreré byly získány různými metodami nebo s různou přesností, což zapříčiňuje vznik duplicitních záznamů. Obrázek 2.1: Aktuální statistiky Protein Data Bank ke dni [6] Data obsažená v PDB souborech zahrnují souřadnice atomů, faktory krystalografických struktur či experimentální data nukleární magnetické rezonance. Mimo koordinátů (je zde použit kartézský systém) obsahuje každý záznam například také jména molekul, informace o primárních a sekundárních strukturách, název aminokyselinového zbytku, číslo řetězce, chemický prvek a další, mimo jiné i volitelné informace. Každý záznam o struktuře je reprezentován jedním řádkem textu délky 80, přičemž možné znaky jsou zde neřídící ASCII znaky, mezera a konec řádku. Každý řádek začíná nejvýše šestiznakovým klíčovým slovem udávajícím typ záznamu (např. ATOM). Zbytek řádku pak tvoří údaje, jejichž syntaxe je definována na základě daného klíčového slova na začátku řádku. Data o chemických vazbách mezi jednotlivými atomy jsou v případě proteogenních aminokyselin vynechána a k rekonstrukci vazeb postačí pořadí atomů v souboru a jejich jména. V ostatních případech je chemická vazba atomů reprezentována zvláštním záznamem s klíčovým slovem connect obsahujícím sekvenci identifikátorů jednotlivých atomů spojených touto vazbou. Dle standardu musí 5

12 2. STRUKTURA A REPREZENTACE PROTEINŮ každý soubor také obsahovat údaj o jméně autora, datu publikování, použité technice a přesnosti, se kterou byla struktura získána. Tato data ovšem nejsou nutná pro další zpracování souboru. Celý soubor ja pak ukončen řádkem obsahujícím pouze klíčové slovo END. Obrázek 2.2: Ukázka reprezentace atomů v pdb souboru 2.3 Nástroje na vizualizaci proteinových struktur Aplikací a nástrojů na trojrozměrnou vizualizaci proteinových struktur dnes existuje celá řada, od komerčních, přes volně dostupné, až po open source projekty. Tyto aplikace obvykle poskytují rozsáhlé možnosti zobrazení rozmanitých molekul uložených v různých formátech. RasMol RasMol je volně dostupný program zaměřený na zobrazování proteinů, nukleových kyselin a malých molekul. Je zaměřený na výukové účely a generování obrázků ve vysoké kvalitě [7]. RasMol běží na široké škále architektur a operačních systémů včetně MS Windows, Apple Macintosh a UNIXových systémů. Program je schopen přečíst data z množství formátů (např. PDB, MOL, MDL a další) a interaktivně je zobrazit. Načtená molekula pak může být vizuálně reprezentována jako drátěný model, tyčkový model, ball-and-stick model, sférický model a podobně. Mimo standardní verzi RasMol existuje také open source verze OpenRasMol. JMol JMol je open source projekt na zobrazování molekul psaný v jazyce Java [8]. Jedná se čistě o vizualizér, neumožňuje editaci vlastností zobrazované molekuly. Aplikace je multiplatformní a lokalizovaná do mnoha jazyků včetně češtiny. Webová část projektu podporuje všechny běžně používané prohlížeče (Internet Explorer, Mozilla Firefox, Safari, Google Chrome, Opera). Podporuje také velké množství formátů a umožňuje nastavit různé způsoby zobrazení molekul. Celý projekt zahrnuje tyto části: JmolApplet applet integrovatelný do webových stránek. 6

13 2. STRUKTURA A REPREZENTACE PROTEINŮ Jmol aplikace samostatně stojící desktopová aplikace v jazyce Java. JmolViewer komponenta začlenitelná do dalších javovských aplikací PyMOL Jedná se o velmi populární multiplatformní aplikaci pro vizualizaci a editaci molekulárních struktur napsaná v jazyce Python. PyMOL je postaven na open source platformě, nicméně aplikace samotná je volně dostupná jen pro studijní účely, pro ostatní použití je zpoplatněna. Momentálně je dostupná pro systémy Windows XP a novější, Mac OS a Linux. Velkou výhodou této aplikace je široká nabídka možností vizualizace, animace struktur či možnost selekce a editace určité části molekuly. Velmi příjemná je jednoduchá možnost exportu molekuly do obrázku ve formátu PNG, případně videa. Dalším vítaným rysem je schopnost zobrazení několika molekul zároveň. Navíc je k aplikaci dostupné množství pluginů rozšiřujících základní funkcionalitu. Nevýhodou PyMOLu zůstává pro nového uživatele celkem nepřívětivé rozhraní. ChemDoodle Desktopová aplikace společnosti ichemlabs se řadí mezi komerční zástupce software na vizualizaci molekul. V první verzi poskytovala pouze jednoduchý nástroj na kreslení molekul. Dnes se ChemDoodle nachází ve verzi 5 a jeho funkcionalita je vskutku široká. Mezi hlavní přednosti patří detailní vizualizér a editor molekul s možností optimalizace dat pro webové aplikace, schopnost načítat struktury přímo z Protein Data Bank, simulace interakcí atomů nebo příjemné uživatelské rozhraní. Opět je podporována řada formátů a vizualizačních technik. Nevýhodou může být pořizovací cena. Velmi užitečnou a zajímavou odnoží ChemDoodle je balíček ChemDoodle Web Components. Jedná se o javascriptovou knihovnu, která umožňuje zobrazovat molekuly na webových stránkách použitím HTML5, Javascriptu a WebGL. Obsahuje sadu nástrojů určených na načtení molekul bud ze souboru, nebo přímo z javascriptové proměnné a jejich 2D nebo 3D zobrazení. Další možností je načítání struktur přímo z Protein Data Bank, nicméně je nejprve nutné zajistit potřebnou licenci pro danou doménu. 2.4 Strukturální motivy a jazyk Motive Query Tato práce se zabývá vizualizací strukturálních motivů obsažených v proteinech. Je tedy nutné motivy v těchto proteinech nalézt. Jedním z významných hledisek při analýze těchto motivů je nutnost jejich popisu a následně identifikace. Pro popis motivů je dostupná řada zaběhnutých jazyků, je tedy možné k vyjádření konkrétního dotazu použít jeden z těchto jazyků. 7

14 2. STRUKTURA A REPREZENTACE PROTEINŮ Nicméně motivy zpracovávané touto aplikací jsou výsledkem dotazů nově vytvořeného dotazovacího jazyka zvaného Motive Query [23], který poskytuje bohatší prostředky pro specifikaci dotazů. Pomocí Motive Query je možné specifikovat strukturu motivů deklarativním přístupem (například motiv PA-IIL je popsán dotazem $(Near(4, [Ca], [Ca], Ring(4-[C],[N])))). Účelem Motive Query je poskytnout jednoduché geometrické dotazy jako Near( v okolí ), vše v daném okruhu či topologický prvek Ring (prstenec). Další možnosti dotazů tvoří například Chain (motivy ve výsledku musí být spojeny vazbou), Fork (motivy splňující první z parametrů musí být spojeny s ostatními výslednými motivy vazbou) a Glue (motivy vrácené dotazem musí sdílet určené atomy). Pomocí těchto primitiv je možné reprezentovat jakoukoli molekulu použitím výrazu Motive Query. Obrázek 2.3: Výsledek dotazu $(Near(4, [Ca], [Ca], Ring(4-[C],[N]))) (vpravo) realizovaném na proteinu s PDB ID 1GZT (vlevo) [23] 8

15 Kapitola 3 Shlukování a vizualizace dat Je-li třeba zobrazit velké množství dat, nebývá moudré činit tak bez předchozího seskupení a uspořádání těchto dat. Často k tomuto účelu používanou technikou je shlukování dat, neboli data clustering. Shlukování dat je proces seskupování objektů do tzv. clusterů podle vzájemné podobnosti. Platí, že prvky uvnitř clusteru jsou si v určitém smyslu podobné, zatímco prvky různých clusterů se v tomto ohledu liší. Jedná se o hlavní proces při data miningu a běžnou techniku statistické datové analýzy [9]. Výstupem shlukování jsou tedy data seskupená do clusterů, které již lze většinou přehledně a efektivně vizualizovat. Důležitou součástí data clusteringu je analýza dat a jejich klíčových vlastností, které budou rozhodovat, z jakých dat se budou jednotlivé skupiny skládat. Mezi nejčastěji používaná měřítka patří například vzdálenosti prvků, hustota dat v prostoru či dělení prostoru na intervaly nebo na základě konkrétních statistických rozložení dat. Vhodnost konkrétního algoritmu shlukování a nastavení parametrů závisí na konkrétní podobě vstupních dat a také na očekávaném výstupu. 3.1 Techniky shlukování dat Existuje řada různých metod rozpoznávání a shlukování dat. Každá z nich může danou množinu dat seskupit jinak. Výběr konkrétní metody závisí na množství parametrů (např. očekávaný typ výstupu, rychlost metody na daných vstupních datech a podobně). Obecně lze tyto techniky rozdělit do dvou kategorií na základě struktury, kterou produkují, a to na metody hierarchické a nehierarchické [10] Hierarchické metody Hierarchické algoritmy vytváří hierarchickou strukturu objektů. Podle směru postupu daného algoritmu se dělí na aglomerativní (zdola nahoru) a divizivní (shora dolů) [12]. Aglomerativní algoritmy na začátku identifikují každý objekt jako samostatný cluster a následně spojují jednotlivé skupiny na základě zvoleného měřítka podobnosti prvků. Shlukování touto metodou je možné zastavit v libovolném kroku. Není-li tento specifikován, výpočet se zastaví ve chvíli, kdy všechny objekty náleží jediné skupině. Tento přístup je v praxi nejčastěji používán. 9

16 3. SHLUKOVÁNÍ A VIZUALIZACE DAT Divizivní algoritmy postupují zcela opačně. Na počátku existuje jedna skupina obsahující všechny objekty. Ta je v průběhu výpočtu rozdělována do menších skupin až do chvíle, kdy každý objekt tvoří samostatnou skupinu, není-li specifikováno jinak. Skupiny vytvořené v každém kroku jsou vzájemně disjunktní. Příklady shlukovacích kritérií [10] Metoda nejbližšího souseda (Single Link) zřejmě nejznámější hierarchická metoda, která v každém kroku spojuje dva nejpodobnější objekty, jež nenáleží stejné skupině. Metoda nejvzdálenějšího souseda (Complete Link) pracuje podobně jako metoda nejbližšího souseda. Liší se v tom, že používá pár nejméně podobných objektů mezi dvěma skupinami ke zjištění podobnosti uvnitř skupiny. Pro tuto metodu je charakteristické vytváření malých, pevně spjatých skupin. Metoda skupinový průměr (Group Average) spíše než na maximální nebo minimální hodnoty podobnosti (jako u předchozích metod) se tato metoda spoléhá na průměrnou hodnotu páru objektů ve skupině. Vzhledem k tomu, že každý prvek přispívá k vnitřní podobnosti skupiny, je každý objekt průměrně podobnější ostatním členům své skupiny než objektům náležícím jiné skupině. Metody pro textové dokumenty v textových dokumentech mohou být skupiny tvořeny například pomocí klíčových slov, která se v textu nachází vícekrát, než je stanovené minimum. Tato technika je velmi vhodná pro dotazování na dokumenty v databázích. Při dotazu na určité slovo bude prohledán pouze cluster, který toto slovo má jako klíčové. Výsledky pak lze uspořádat například podle četnosti klíčového slova Nehierarchické metody Nehierarchické metody rozdělují množinu dat obsahující určité množství objektů do jiného množství skupin. Tyto metody se rozdělují na rozdělující (partitioning) a shlukující (clumping). Rozdíl spočívá v tom, zda metoda umožňuje překrývání skupin. Partitioning metody jej neumožňují, clumping algoritmy ano. Rozdělující (partitioning) metody Z množiny N objektů rozdělující algoritmus vyprodukuje M skupin dat, kde v každém clusteru je splněna daná podmínka (např. minimální součet vzdáleností od počátku). Jednotlivé clustery mohou být představovány svými reprezentanty (prvky zvolenými pro dané skupiny) nebo objekty představujícími jejich středy. 10

17 3. SHLUKOVÁNÍ A VIZUALIZACE DAT Značnou nevýhodou tohoto přístupu je kompexnost algoritmů. Některé z nich musí vyčerpávajícím způsobem simulovat všechna možná seskupení objektů a následně najít optimální řešení. Počet možných uspořádání je obrovský i pro poměrně malé množství objektů. Proto obvykle metoda začíná s počátečním, často náhodně zvoleným seskupením, které postupně zpřesňuje. Algoritmus se snaží lokálně zlepšovat výsledky na základě určitého kritéria. Nejprve spočte hodnoty podobnosti či vzdálenost, setřídí výsledky a vybere ten, který nejlépe splňuje dané kritérium [12]. Příklady nehierarchických algoritmů Algoritmus iterativní relokace tento proces začíná s počátečním seskupením. Kvalita tohoto seskupení je následně zvyšována pomocí lokálních vyhledávacích algoritmů a přepočítávání členství jednotlivých objektů ve skupinách na základě jejich výsledků. Proces končí, pokud po provedení poslední iterace nenastala žádná změna stávajícího seskupení [13]. Algoritmus K-means K-means je iterativní proces, který rozděluje množinu dat do K disjunktních skupin na základě vlastností jednotlivých objektů. Každý objekt je přiřazen do skupiny, jejímuž středu je nejblíže. Středy skupin se při každé iteraci spočítají jako průměry všech bodů skupiny. Jde o velmi široce užívaný postup shlukování dat. Nevýhodou tohoto přístupu je jeho značná složitost. Metoda Single Pass velmi jednoduchá nehierarchická metoda. První načtený objekt je označen za střed počátečního shluku. Pro každý další objekt spočte podobnost s každým již existujícím středem shluku. Pokud je nejvyšší spočtená podobnost větší než stanovený práh, přidá objekt do daného shluku. Jinak se objekt stává středem nového shluku. Algoritmus končí ve chvíli, kdy byly všechny prvky zpracovány. Obrázek 3.1: Ukázka taxonomie shlukovacích metod [11] 11

18 3. SHLUKOVÁNÍ A VIZUALIZACE DAT 3.2 Použité metody vizualizace Jak již bylo zmíněno, aplikace vyvíjená v rámci této práce očekává na vstupu velké množství objektů (motivů). Jednou z možných reprezentací těchto dat je textový zápis ve formátu XML (Extensible Markup Language) nebo CSV (Comma Separated Values) a k nim přidružený zápis koordinátů atomů například ve formátu PDB. Obrázek 3.2: Ukázka vstupních dat ve formátu CSV Data v tomto formátu je sice snadné parsovat a za přítomnosti souboru obsahujícího koordináty atomů jednotlivých motivů také bez problémů zobrazit. Nicméně kvůli předpokládanému množství těchto objektů na vstupu nelze očekávat, že by bylo možné tak učinit zároveň pro všechny načtené objekty. Jejich vizualizaci tedy bylo nutné rozdělit do více kroků, samotné objekty rozdělit do separátních skupin, což implikuje použití metod shlukování dat. Díky jednoduchému formátu, ve kterém jsou data uložena, bylo možné identifikovat dostatečný počet atributů objektů pro provedení jednoduchého hierarchického shlukování dat zdola nahoru na základě hodnot těchto atributů. Objekty pak tvoří stromovou strukturu, ukázková hierarchie je znázorněna na obrázku 3.3. Obrázek 3.3: Hierarchie dat použitá v aplikaci 12

19 3. SHLUKOVÁNÍ A VIZUALIZACE DAT Signature distance značí vzdálenost, neboli počet různých residuí v signatuře daného molekulárního motivu. Kupříkladu vzdálenost signatury 1xGLU-1xHOH-1xZN je rovna 3. Tyto vzdálenosti jsou uspořádány ve skupinách vyjadřujících vždy interval, kde obsažené vzdálenosti jsou větší nebo rovny stanovenému minimu a menší nebo rovny danému maximu. Tyto skupiny pak obsahují shluky pro jednotlivé signatury. Další úrovní jsou clustery představující jednotlivé struktury, kterým dané motivy náleží (v textové reprezentaci motivů je struktura vyjádřena sloupcem ParentId). Ty pak obsahují konkrétní motivy splňující zároveň všechny výše uvedené podmínky (mezi jednotlivými skupinami však může nastat překryv v rámci některého z atributů). Díky tomuto rozdělení je možné vyhledat skupinu motivů splňujících určité podmínky relativně snadno a hlavně je možné filtrovat ostatní objekty. Relativně malé množství motivů, které projdou filtrem, je následně výrazně rychlejší a méně náročné vizualizovat (vizualizace všech načtených motivů zároveň by zřejmě byla nad pamět ové možnosti některých počítačů) Čtyři kroky vizualizace Tato aplikace je navržena tak, aby vizualizace motivů byla rozdělena do čtyř kroků, kde hlavním důvodem tohoto rozdělení je minimalizace odezvy aplikace při interakci s uživatelem. V každém kroku je totiž zobrazení nejen zpřesněno a konkretizováno, ale je také omezena množina zobrazovaných objektů. Tyto kroky zahrnují: Hierarchický pohled na data Zobrazení objektů v mřížce pomocí pivot view Dvojrozměrnou vizualizaci jednotlivých motivů Trojrozměrnou vizualizaci vybraného motivu Hierarchický pohled První ze čtyř kroků vizualizace se zabývá vhodným zobrazením hierarchie dat vzniklé výše uvedenou metodou shlukování dat. Zásadním účelem tohoto kroku je omezit data ze vstupu na sérii reprezentantů, které budou odkazovat na dané podmnožiny dat. Je tedy nutné poskytnout uživateli vhodnou vizuální reprezentaci této hierarchie a umožnit mu jednoduchou navigaci mezi jednotlivými prvky. Pro tento účel byla zvolena kruhová reprezentace. Každý uzel v hierarchii je pak představován jedním kruhem. Kruhy se do sebe vnořují v závislosti na tom, která skupina kam patří. Velmi vhodné je v tuto chvíli použít při vykreslování kruhů jisté míry průhlednosti a pouze koncové uzly nechat zcela neprůhledné. Tímto uživatel získává náhled do celého uspořádání namísto toho, aby viděl pouze nejvyšší vrstvu. Přidáním možnosti výběru libovolného prvku a přiblížení na něj dostává uživatel možnost plynule procházet touto strukturou a v jediném kroku se zaměřit na prvek, který ho zajímá. Největší nevýhodou 13

20 3. SHLUKOVÁNÍ A VIZUALIZACE DAT tohoto přístupu je jeho prostorová náročnost, protože k zobrazení vyžaduje čtvercové pole, což v době širokoúhlých displejů značně limituje jeho rozměry, zejména kvůli dostupné výšce. Dalším dílčím problémem je obtížnější zobrazování popisků. Postup jejich vytváření musí být navržen tak, aby nezahlcovaly celou strukturu a pokud možno se nepřekrývaly. Možným řešením této situace je vykreslení jen té části textu, která se vejde do přidruženého uzlu, a následné přepočítávání dostupné délky textu při přiblížení. I přes tyto nedostatky lze pomocí kruhové reprezentace uzlů poskytnout přehledný a názorný náhled na data. Obrázek 3.4: Kruhová reprezentace hierarchie dat Pivot view Při rozbalení uživatelem vybraného koncového uzlu hierarchie dochází ke spuštění druhého vizualizačního kroku. Hierarchický pohled na data se zavírá a místo něj se otevírá pivot view obsahující molekulární motivy splňující všechny podmínky kladené na prvky tohoto uzlu. Díky tomuto filtrování je uživateli zobrazena pouze specifická podmnožina objektů a reakce aplikace je výrazně rychlejší než na celé množině vstupních dat. Navíc je možné, že uživatel má zájem o prohlížení pouze specifických motivů, což mu tento krok umožňuje. Na druhou stranu je v této konfiguraci nutný návrat na hierarchický model pokaždé, když chce uživatel nahlédnout na jinou skupinu motivů (pokud ovšem nezná URL dané skupiny). V pivot view jsou prvky uspořádány v mřížce, se kterou je možné interaktivně manipulovat (pohybovat, přibližovat) a třídit či filtrovat prvky podle jejich atributů. Mimo klasické zobrazení do mřížky umožňuje také grafové zobrazení, kde se prvky setřídí do sloupcového grafu podle zadaných atributů. 14

21 3. SHLUKOVÁNÍ A VIZUALIZACE DAT Dvojrozměrná vizualizace motivů Další krok je velmi pevně spjat s krokem předchozím. V této fázi se načítají z příslušných souborů koordináty a vlastnosti atomů jednotlivých molekulárních motivů a následně se zobrazují na příslušné dlaždice mřížky. Provádění tohoto kroku začíná ihned po zaznamenání události kompletního načtení objektových dat (všech dat asociovaných s danými motivy) do pivot view. Zde je použito dvojrozměrné projekce motivu na plátno (HTML5 canvas) na základě souřadnic atomů a jejich posloupnosti v molekulách. Obarvení probíhá na základě chemických prvků těchto atomů. 3D zobrazení vybraného motivu Poslední fází vizualizace je pak zobrazení tojrozměrného modelu vybraného motivu pomocí WebGL na stejném principu jako dvojrozměrná projekce z předchozího kroku. Trojrozměrné zobrazení je kvůli náročnosti na prohlížeč možné pouze pro jeden objekt z mřížky, a to navíc jen ve stavu vybráno, což je situace, která nastane při zmáčknutí na danou dlaždici mřížky. Uživatel totiž má možnost s mřížkou manipulovat, posouvat a zvětšovat objekty, přičemž každá taková operace vyžaduje překreslení dané dlaždice. Udržování a překreslování většího počtu WebGl kontextů značně zatěžuje prohlížeč, což vede k velmi dlouhé reakční době. Obrázek 3.5: Ukázka 2D a 3D reprezentace molekul 3.3 Složitost zpracování Z hlediska časové složitosti je nejnáročnější operací zpracování hierarchického pohledu. Při této operaci je využito metody hierarchického shlukování dat zdola nahoru. neboli aglomerativního shlukování. Složitost tohoto přístupu je O(n 3 ). Bylo tedy nutné proces 15

22 3. SHLUKOVÁNÍ A VIZUALIZACE DAT vytváření hierarchie optimalizovat. Zásadním krokem k docílení kratšího výpočetního času je přesunutí zpracování objektů přímo do metody, která zároveň zajišt uje jejich ukládání do datového úložiště. Není tedy třeba k objektům zvlášt přistupovat, údaje potřebné k vytvoření skupin jsou drženy v paměti a jsou postupně rozšiřovány na základě zpracovaných objektů. Samotné vytváření skupin pak již nepracuje s celou datovou množinou, nýbrž s množinou údajů nezbytně nutných k určení podobnosti objektů a vztahů skupin. Tento proces je obdobou metody nejbližšího souseda (Single Link), jejíž časovou složitost je možné redukovat na O(n 2 ). Ostatní kroky v procesů zpracování motivů již nejsou takto časově náročné. Ukládání do databáze je lineární vzhledek k počtu objektů, stejně tak jako předávání dat do pivot view a následná vizualizace motivů. Vytváření databáze je pak operace s konstantní složitostí. 16

23 Kapitola 4 Použité nástroje a technologie Jedním z požadavků na vývoj aplikace v rámci této práce je použití programovacího jazyka C# a technologie ASP.NET verze 4. V jazyce C# stejně jako ve většině vysokoúrovňových objektových jazyků je dostupná široká škála kvalitních knihoven pro rozmanité účely. Je tedy vhodné řídit se heslem nevynalézejme znovu kolo a použít nějakou z již existujících knihoven či frameworků, které jsou většinou odladěné a optimalizované, ušetřit si tak práci a zároveň získat záruku určité kvality provedení. Zvlášt příhodná je možnost použití technologie NuGet, která zajišt uje kompletní stažení vybraného balíčku z databáze knihoven a jeho instalaci přímo do projektu. Krom sestavení aplikace na platformě.net Framework a použití dnes už takřka nezbytných knihoven (jako například JQuery), bylo při implementaci využito také několik méně standardních technologií. 4.1 Perzistence dat Jelikož na platformě.net Framework doposud neexistuje standard pro perzistenci dat, obdobný například JPA (Java Persistence API) poskytovanému Java Enterprise Edition, bylo nutné pro tento účel použít framework třetí strany, který nabízí vyžadovanou funkcionalitu. Entity Framework První verze aplikace ukládala objekty do databáze pomocí technologií ADO.NET Entity Framework (EF). Jedná se o společností Microsoft doporučený framework pro perzistenci dat v jazycích na platformě.net. Umožňuje pracovat s daty ve formě doménově specifických objektů a jejich vlastností bez nutnosti zabývat se strukturou databázových tabulek a jejich sloupců [14]. Poskytuje tedy abstrakci datového modelu na úrovni objektů, což je velmi přívětivé pro vývojáře v objektových jazycích jako C#. Entity Framework pracuje na principu objektově relačního mapování (ORM), kdy mapuje relační tabulky, sloupce a omezení cizích klíčů v logických modelech na entity a vztahy mezi nimi v doménových modelech (v terminologii EF označované jako konceptuální modely). Takto je výrazně zjednodušena manipulace s daty oproti standardnímu přístupu, protože není nutné definovat databázové operace a vztahy mezi 17

24 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE tabulkami. Mapování probíhá automaticky, hojně navíc používá princip convention over configuration, který při použití stanovených postupů například při pojmenovávání entitních objektů a jejich vlastností zaručuje jejich zachování při mapování. Změna tohoto modelu je možná pomocí speciálních atributů. EF ke své funkci vyžaduje použití tzv. POCO (Plain Old CLR Object) tříd, které definují jednoduché entitní objekty s bezparametrickým konstruktorem a veřejně přístupnými vlastnostmi. Díky tomu je možné pro návrh entit použít designér s grafickým rozhraním, který na základě nastavených hodnot vygeneruje kód. Alternativou je pak code first přístup, kde vývojář přímo píše kód třídy a podle něj je vytvořeno mapování. Celkově je Entity Framework pro vývojáře příjemný nástroj pro perzistenci dat, napomáhá zkracování kódu a jeho celkové přehlednosti, stále však má zásadní nevýhody. První z nich je jeho výkon, který i přes neustálé vylepšování frameworku zaostává za konkurenčními produkty. Druhým zásadním nedostatkem je úzká nabídka funkcionality a nemožnost aplikace některých omezení na sloupce tabulek. Kupříkladu stále není k dispozici možnost označit hodnoty sloupce za unikátní, editace záznamů je poměrně složitá, je-li třeba upravit větší počet sloupců, slabá podpora transakcí, obtížná migrace a podobně. Raven DB Technologií použitou na perzistenci dat ve finální verzi aplikace je RavenDB, open source transakční dokumentová databáze na platformě.net založená na architektuře klient-server. Data uložená na serveru jsou přístupná skrze klientské API dostupným jakékoli aplikaci běžící na.net Frameworku, nebo vzdáleným přístupem přes serverové REST API, které umožňuje přístup aplikacím běžícím na libovolné platformě [15]. RavenDB mimo jiné podporuje dva režimy: testovací a produkční. Testovací režim využívá zabudované nástroje Windows a je v něm možné využít in-memory operace (běžící v paměti). Největším rozdílem oproti předchozímu frameworku je skutečnost, že RavenDB využívá NoSQL schema-less databázi. Jednotlivé záznamy, označované zde jako dokumenty, tedy nejsou uloženy v tabulkách. Každý záznam je uložen jako samostatný dokument ve formátu JSON (JavaScript Object Notation). Důvod použití tohoto formátu je jeho schopnost uchovávat hierarchie, čitelnost a minimalistický přístup. Každý dokument obsahuje také metadata, implicitně jde pouze o data zpracovávaná interně RavenDB (například jméno entity). Hlavně ale obsahuje své unikátní ID, a to v poněkud neobvyklém formátu jméno entity/sériové číslo. Ukládání dokumentů v tomto formátu přináší dvě zásadní výhody: flexibilní datový model (provádět změny modelu je vskutku velmi jednoduché) a vysoký výkon a škálovatelnost s nízkou odezvou. Jedním z hlavních principů RavenDB je tzv. safe by default, tedy implicitně bezpečný. Tento princip zahrnuje řešení problémů s neomezenými výsledky dotazů, automatické optimalizace požadavků na co nejmenší zátěž databáze atd. 18

25 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE Začlenění databáze do aplikace v jazyce C# se provádí jednoduše pomocí instance třídy implementující rozhraní IDocumentStore. Tato třída je zodpovědná za veškerou komunikaci mezi klientem a serverem a také za veškerou globální konfiguraci databáze. Je nutné, aby tato třída byla instanciována jako singleton (tj. smí existovat pouze jedna instance této třídy). Entity jsou opět reprezentovány POCO třídami s tou podmínkou, že vlastnost ID musí být uložena jako textový řetězec, nikoli jako číslo, jak je tomu u většiny systémů pro perzistenci dat. Důvodem tohoto nestandardního postupu je zvolený formát identifikátoru. Obrázek 4.1: Inicializace RavenDB a následné uložení entity motive 4.2 Technologie bussiness logiky Unity Application Block Unity Application Block je jedním z nejoblíbenějších rámců poskytujících dependency injection kontejner pro aplikace psané v jazyce C#. Jedná se o jednoduchý, rozšiřitelný lightweight IoC (Inversion of Control) kontejner, který podporuje injekci závislostí do konstruktoru, vlastností a volání metod [16]. Princip inversion of control umožňuje dynamické přidělování zdrojů komponentám bez nutnosti starat se programaticky o jejich životní cyklus. V případě objektového programování jde o řešení vazeb mezi objekty za běhu programu obvykle nějakým dependency injection kontejnerem. Tyto vazby zpravidla nejsou známy při kompilaci. Dependency injection je tedy návrhový vzor, jenž umožňuje odstranění těsných vazeb určených staticky v kódu za volné vazby, které lze měnit jak za chodu, tak při kompilaci. Pomocí tohoto návrhového vzoru je možné injektovat danou závislost (referenci na objekt) automaticky do cílové proměnné na základě znalosti jejího typu, případně dalších omezujících podmínek. Unity jakožto implementace těchto principů tedy přináší následující výhody: Poskytuje zjednodušený proces vytváření objektů, zvláště pro hierarchické struktury objektů 19

26 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE a závislostí. Podporuje abstrakci požadavků, což umožňuje vývojáři specifikovat závislosti za běhu programu nebo v konfiguraci. Zvyšuje flexibilitu přenesením konfigurace komponent a správy jejich životního cyklu na kontejner. Unity podporuje dva režimy řešení závislostí: Kontejner bud zcela převezme správu injektované komponenty, nebo na ni pouze vytvoří volnou vazbu. Ve většině případů je nejvýhodnější použití první varianty, nicméně je-li nutnost starat se o životní cyklus komponenty programaticky, řešením je možnost druhá. Další užitečnou schopností Unity je instanciace závislého objektu jako singletonu. K začlenění Unity do aplikace existují dvě varianty. První možností je definice řešení závislostí přímo v kódu pomocí metod třídy UnityContainer. Tento přístup je velmi jednoduchý a chyby v zápisu jsou odhaleny při kompilaci. Nevýhodou této varianty je nutnost udržovat referenci na část kódu, ve kterém je specifikován způsob řešení závislosti. Tímto mohou vznikat nechtěné vazby mezi komponentami, protože je-li třeba vytvořit instanci jiné komponenty, je při použití definice závislostí v kódu nutné držet referenci na tuto komponentu. Řešením pro tuto situaci je použití konfigurace IoC kontejneru pomocí nezávislého XML konfiguračního souboru, což ovšem vyžaduje větší námahu a také případné chyby se projeví až za běhu programu. Obrázek 4.2: Příklad definice závislosti v kódu File Helpers Jedním z možných zdrojů dat pro aplikaci jsou soubory ve formátu CSV. Tyto soubory se sice velmi jednoduše parsují, nicméně existence frameworků, které tuto činnost ještě zjednodušují, vznáší otázku, proč je nevyužít. File Helpers je univerzální knihovna pro načítaní či ukládání dat do rozmanitých formátů souborů, datových proudů nebo textových řetězců. Tato knihovna je vybavena sadou převodníků pro základní datové typy, kterou lze také snadno rozšířit o vlastní konvertory. Podporuje řadu formátů (např. CSV, XLS, XML apod.) a umožňuje definovat vlastní oddělovače záznamů v souboru. Vítaná je možnost úpravy záznamů přímo při načítání či ukládání. Dalším rysem je schopnost přímého ukládání do databáze či dokonce výměna dat mezi dvěma databázemi, přičemž je knihovna schopna poradit si i s null hodnotami. 20

27 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE Použití této knihovny v aplikaci je velmi snadné, stačí definovat třídu s atributy stejného názvu jako jsou názvy sloupců v souboru. File Helpers pak dokáže načíst soubor a hodnoty přímo vložit do objektu dané třídy včetně převodu textových řetězců například na číselné hodnoty. Pro specifikaci převodu do určitých typů je nutné označit dané proměnné této třídy speciálními atributy. V tomto místě spočívá největší nevýhoda této knihovny. Jediné prvky třídy, které lze anotovat těmito atributy jsou totiž proměnné (fields). Nicméně standardní praxí pro POCO třídy je použití vlastností (properties). Není tudíž možné použít tyto POCO třídy jako referenci pro složitější převody a nezbývá tedy než vytvořit speciální třídu, která bude sloužit výhradně pro načítání dat. 4.3 Nástroje prezentační vrstvy ASP.NET MVC Framework ASP.NET MVC je alternativou klasického ASP.NET Web Forms, technologie pro vývoj webových aplikací na platformě.net. Hlavním znakem ASP.NET MVC je využití návrhového vzoru Model-View-Controller (MVC). Model představují ty části aplikace implementující logiku nad aplikačními daty. View, neboli pohled, je tvořen komponentami, které zobrazují uživatelské rozhraní, typicky na základě dat z modelu. Controller pak označuje ty komponenty, které obsluhují uživatelské požadavky, pracují s daty modelu a vybírají, které pohledy (views) budou zobrazeny. Tento přístup přináší následující rysy [17]: Oddělení jednotlivých úloh aplikace na logiku vstupů, bussiness logiku a logiku uživatelského rozhraní; dále testovatelnost a s ní možnost použití principů testdriven development (TDD). Všechny hlavní kontrakty frameworku jsou založeny na rozhraních (interface), jejich testování je možné užitím mock objektů (simulovaných objektů, které napodobují chování skutečných objektů v aplikaci). Rozšiřitelnost a začlenitelnost frameworku; komponenty ASP.NET MVC jsou navrženy tak, aby byly snadno nahraditelné či upravitelné. Framework navíc podporuje užití principů dependency injection a inversion of control. Jednoduché vytváření silně typovaných pohledů; framework je na základě zvoleného modelu schopen vygenerovat pohled, který zobrazí veškeré informace o objektech obsažených v modelu společně s ovládacími prvky pro manipulaci s objekty. Data-Driven Documents D3.js D3.js je javascriptová knihovna zaměřená na manipulaci dokumentů na základě dat. Jedná se o velmi mocný nástroj pro vizualizaci nejrůznějších dat pomocí HTML, škálovatelné vektorové grafiky (SVG) a kaskádových stylů (CSS). Díky důrazu na užití webových standardů je tato knihovna dostupná pro všechny moderní webové prohlížeče [18]. Díky minimální režii je knihovna D3 velmi rychlá, podporuje manipulaci velkého množství dat a dynamické chování pro interakci a animaci. 21

28 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE D3 umožňuje přiřazení libovolných dat do objektového modelu dokumentu (DOM) a následně aplikovat datové transformace na dokument. Například je možné z pole hodnot vygenerovat sloupcový graf. Modifikace dokumentů skrz DOM API je obvykle velmi namáhavá. V imperativním přístupu vyžaduje manuální iteraci přes všechny dané prvky a udržování dočasného stavu. Proto D3 využívá deklarativního přístupu a pracuje nad množinami prvků, tzv. selekcemi (selections). K tomuto účelu používá selektory specifikované ve W3C Selectors API. Prvky dokumentu mohou být vybírány na základě jména tagu (např. p, body, canvas), třídy, identifikátoru nebo libovolného jiného predikátu. Pro editaci prvků D3 poskytuje početnou sadu metod: změnou atributů a stylů počínaje, přidáváním, odebíráním či tříděním prvků konče. Významnou vlastností D3 při úpravě vlastností prvků tvoří možnost nezadávat je jako konstanty, nýbrž jako funkce nad daty, tudíž vytvářet obsah dokumentu dynamicky. Použitím tzv. enter ( vstupních ) a exit ( odchozích ) selekcí je možné přidávat nové prvky pro příchozí data, resp. odebírat již nepotřebné prvky. V momentě, kdy jsou data svázána s určitou selekcí, jsou všechny objekty v poli dat spárovány s odpovídajícím prvkem v selekci. Je-li těchto prvků méně než objektů, přebývající prvky vytváří enter selekci, kterou lze instanciovat připojením prvku k této enter selekci. Obdobně pak funguje exit selekce. Doporučený postup je tyto selekce řešit odděleně a stanovit tak přesně, které operace budou na jakých prvcích probíhat. Obrázek 4.3: Příklad použití enter selekce [19] Díky těmto funkcím se D3 stává velmi mocným nástrojem pro vizualizaci dat, protože je možné každému objektu přiřadit nějakou grafickou reprezentaci pomocí SVG, následně jí nastavit požadované atributy a styly, případně se na ni dále odkazovat pomocí jakéhokoli vhodného predikátu. Navíc D3 obsahuje velmi výkonné funkce pro načítání dat z javascriptových proměnných (funkce data), nebo ze souborů formátu JSON (funkce d3.json). D3 tedy umožňuje vizuálně transformovat dokumenty na základě dat, tedy přidáváním a odebíráním prvků, změnou dokumentu na základě uživatelských vstupů a podobně. LobsterPot Pivot Viewer LobsterPot PivotViewer je multiplatformní open source alternativa produktu Silverlight PivotView Control, vytvořeného společností Microsoft. Byl vyvinut jako webový plugin založený na knihovně JQuery využívající možnosti HTML5. PivotViewer je vizualizační nástroj, který umožňuje uživateli vidět data jako kolekci dlaždic v mřížce, 22

29 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE filtrovat je a třídit. Jde tedy o nástroj na prozkoumávání dat [20], který nabízí velmi uživatelsky přívětivé rozhraní s širokými možnostmi interakce. Zásadní výhodou tohoto pluginu, krom multiplatformity a podpory všech moderních prohlížečů, je jeho rozšiřitelnost. Všechny základní implementace důležitých komponent je možné vyměnit za jiné implementace se stanoveným API. Obvykle je třeba překrýt jednu ze součástí Image Controller nebo Collection Loader. Image Controller je komponenta odpovědná za zobrazení každého pole v mřížce. Implicitní implementace pracuje s obrázky ve formátu DZI (Deep Zoom Image), předpokládá tedy existenci obrázků v určeném formátu. Je-li zapotřebí zobrazit data jiným způsobem, musí být tato implementace nahrazena jinou, specializovanou pro daný postup. Collection Loader je druhou významnou částí, kterou bývá potřeba změnit například kvůli specifickému způsobu načítání dat. Standardní implementace této komponenty předpokládá existenci kolekce dat v souboru formátu CXML s konkrétní strukturou. Důvodem k použití tohoto formátu je kompatibilita se Silverlight PivotView. LobsterPot PivotViewer funguje na principu event driven, tedy událostmi řízené aplikace pomocí principu publishsubscribe a s ním spjaté funkcionality poskytované knihovnou JQuery. Využití těchto událostí je velmi výhodné při implementaci vlastních komponent. LobsterPot PivotViewer Control se vkládá do webové stránky jako blokový element s identifikátorem "pivotviewer". Není-li stanoveno jinak, tento blok převezme rozměry nadřazeného elementu stránky. Je-li nadřazeným elementem tělo dokumentu (tedy tag body), zaplní pivot view celé okno prohlížeče. Inicializace pivot view se realizuje následujícím skriptem. Obrázek 4.4: Inicializace LobsterPot PivotView [21] ChemDoodle Web Components Již zmiňovaná javascriptová knihovna určená pro vizualizaci molekulárních dat umožňuje načíst a zobrazit molekuly jak dvojrozměrnou projekcí, tak jako torjrozměrný model. Velkou výhodou tohoto nástroje je zajisté vysoká kvalita zobrazení a také široká škála podporovaných formátů a vizualizačních technik, statickým zobrazením počínaje, plně interaktivním trojrozměrným modelem konče. Naopak hlavní nevýhodou této knihovny je nutnost instanciace daného plátna a jeho párování s existujícím prvkem v DOM. Tento přístup výrazně komplikuje dynamické generování vizualizací na stránce. 23

30 4. POUŽITÉ NÁSTROJE A TECHNOLOGIE Twitter Bootstrap Velmi oblíbená sada HTML šablon, kaskádových stylů a javascriptových pluginů usnadňuje vytváření webových stránek s konzistentním vzhledem, který se bude zobrazovat stejně ve všech prohlížečích. Obsahuje řadu rozmanitých komponent pro stavbu přívětivého uživatelského rozhraní. Twitter Bootstrap poskytuje vlastní mřížkové rozvržení stránky; obrazovka je rozdělena do mřížky pomocí tagů <div> pozicovaných kaskádovými styly. Tento systém se skládá z mřížky o 12 sloupcích a je dostupný ve čtyřech vzorech pro různé velikosti obrazovky. Obrázek 4.5: Mřížkové uspořádání Twitter Bootstrap [22] 24

31 Kapitola 5 Návrh, implementace, testování 5.1 Návrh zaměřený na rozšiřitelnost Jedním ze zásadních požadavků na vyvíjenou aplikaci je její rozšiřitelnost a možnost měnit jednotlivé komponenty. Byla tedy navržena tak, aby bylo možné jednoduše měnit implementace součástí, upravovat vlastnosti entit, přidávat či odebírat entity a v neposlední řadě také migrovat na jiný způsob perzistence dat. Celá aplikace je rozdělena do čtyř základních součástí spojených co nejvolnějšími vazbami. Tyto součásti jsou: Backend, Loader, Frontend a API. Backend Součást Backend je zodpovědná za perzistenci dat a bussiness logiku aplikace. Využívá návrhového vzoru DAO (Data Access Object). Princip DAO spočívá v oddělení vrstvy perzistence dat od aplikační logiky vytvořením komponenty zaměřené výhradně na komunikaci aplikace s datovým úložištěm. Tato komponenta je pak do zbytku aplikace začleněna pomocí závislosti na své rozhraní, nikoli přímo na implementaci. Tato vazba umožňuje libovolně měnit implementace DAO a tudíž také použití různých technologií perzistence dat, protože DAO komponenta zcela pokrývá operace nad datovým úložištěm a není tedy na dané úložiště nutné udržovat referenci ve vyšších vrstvách aplikace. Navíc při použití dynamické alokace zdrojů, například pomocí IoC kontejneru, je možné střídat jednotlivá datová úložiště za běhu aplikace pouze přidělením příslušné DAO implementace. DAO vrstva předává svá data vrstvě servisní. Ta odpovídá za provádění aplikační logiky a také za řízení transakcí. Na první pohled se může zdát, že tato vrstva nemá v relativně jednoduché aplikaci přílišného využití, protože v prvotní verzi neprovádí žádnou speciální logiku, ale spíše jen deleguje požadavky na DAO vrstvu. Hlavní účel servisních komponent v tuto chvíli spočívá v poskytování možností dalšího rozšiřování aplikace, například zavedení nových entit nebo řízení transakcí nad více enntitami či přímo více datovými úložišti. Další důležitou roli hraje servisní vrstva jako rozhraní pro komunikaci s ostatními součástmi aplikace. Posledním významem této vrstvy pak je využití návrhového vzoru DTO (Data Transfer Object). DTO představuje jednoduché datové objekty, které neobsahují žádnou aplikační logiku, pouze se do nich ukládají načtená data a jednotlivé součásti aplikace poté komunikují předáváním těchto objektů, 25

32 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ nikoli přímo entitních objektů. To zajišt uje jednotnou komunikaci při použití jakékoli technologie perzistence dat, různé technologie mají totiž různé požadavky na entitní objekty. Příkladem významu DTO může být použití s Enterprise Java Beans verze 3.0 a starší tyto objekty nejsou serializovatelné, tudíž je jejich použití pro webovou aplikaci velmi omezené. Data transfer objekty tento nedostatek bez problémů řeší. Kvůli tomu, že DAO vrstva pracuje s entitními (bussiness) objekty a servisní vrstva vyžaduje data transfer objekty, je nutné mezi tyto dvě vrstvy umístit další komponentu známou jako Adaptér. Návrhový vzor Adaptér představuje komponentu, která přizpůsobuje rozhraní jedné třídy či součásti tak, aby bylo kompatibilní s rozhraním jiné třídy. Umožňuje tedy třídám s nekompatibilním rozhraním komunikaci poskytnutím svého vlastního rozhraní, které pouze překládá vstupy z původních rozhraní. V tomto případě tedy Adaptér zajišt uje překlad mezi bussiness objekty a data transfer objekty, tudíž i správnou komunikaci mezi DAO a servisní vrstvou. Loader Loader představuje komponentu zajišt ující načítání dat z externího zdroje. Stejně jako u předchozích komponent je kontrakt této součásti založen nikoli na implementaci, ale na rozhraní. Třídy implementující toto rozhraní tedy musí poskytovat danou funkcionalitu nehledě na to, z jakého zdroje čerpají data či jakým způsobem je zpracovávají. Vstupní data pak mohou pocházet z libovolného zdroje (soubor, databáze, webové služby,...) a mít libovolný formát; pro každý případ je možné vytvořit implementaci schopnou jej zpracovat a přitom neovlivnit zbytek aplikace. Frontend Frontend, neboli webové rozhraní aplikace odpovídá za zobrazení dat uživateli. Samotné webové rozhraní neimplementuje žádnou aplikační či datovou logiku, využívá pouze rozhraní ostatních komponent pro volání jejich služeb na základě interakce s uživatelem a zobrazuje jejich výsledky. V prvotní verzi nabízí dva pohledy: hierarchiký a pivot view. Oba tyto pohledy jsou generovány na základě dat získaných z ostatních komponent a je možné zcela změnit jak strukturu hierarchikého pohledu, tak způsob zobrazení dat v pivot view při zachování stávajícího rozhraní. API API tvoří velmi důležitou součást aplikace zajišt ující co nejvolnější vazby mezi komponentami a jejich jednoduché rozšíření či výměnu implementací. Účel spočívá v oddělení modulů aplikační logiky, načítání dat a webového rozhraní a definování rozhraní, skrz která budou komunikovat. Je tedy možné vyměnit nejen implementace jednotlivých komponent, ale přímo celých modulů. Všechny moduly potom udržují referenci na modul API, nicméně nepotřebují udržovat reference na ostatní moduly, čímž se stávají vzájemně nezávislými. Samotné API nesmí udržovat odkazy na žádný další modul 26

33 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ kvůli vzniku cyklických odkazů. Z hlediska tříd tento modul neobsahuje velké množství součástí. Účelem je identifikovat třídy, kterými jsou ostatní moduly schopny vzájemně komunikovat a v rámci API definovat jejich rozhraní. Závislosti modulů jsou pak zásadně směrovány na tato rozhraní. Ideální je v tomto případě využít IoC framework a nechat jeho kontejner řešit tyto závislosti za běhu programu. Kritickou roli v komunikaci modulů hraje servisní vrstva, jejíž rozhraní slouží k výměně dat mezi všemi součástmi aplikace, další komponentou vystavující své rozhraní v API je Loader. Posledním důležitým prvkem API je definice data transfer objektů, které jsou vyžadovány při komunikaci ve všech součástech aplikace. Obrázek 5.1: Pohled na strukturu aplikace Všechny navržené komponenty mají specifikována svá rozhraní. Tento fakt tvoří základ nezávislosti aplikace na konkrétních implementacích komponent díky tomu, že všechny jejich závislosti jsou založeny na těchto rozhraních. Výměna implementace pak znamená odkazování se na jinou třídu implementující dané rozhraní. Použití dependency injection pak přináší schopnost měnit tyto součásti za běhu programu. 27

34 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ 5.2 Návrh zaměřený na výkon Druhým kritickým požadavkem, který musí aplikace splňovat, je schopnost zpracovat naráz velké množství dat, reagovat přitom v dostatečně krátké době a navíc nezahltit prostředky klienta při prohlížení dat. Prvním krokem je tedy vytvoření hierarchie dat pomocí jednoduchého hierarchického shlukování dat. Uživatel pak namísto celého objemu dat pracuje pouze s reprezentanty jednotlivých kategorií, které následně odkazují na určité podmnožiny dat. Idea tohoto postupu spočívá v rozdělení vizualizace načtených dat do několika kroků, přičemž v každé fázi je množina dat filtrována, tudíž konkrétnější a přesnější vizualizace pracují se stále menšími podmnožinami dat. Kvůli redukci časově náročných přístupů do datového úložiště, byla přesunuta logika prvního kroku, tedy vytváření datové hierarchie na komponentu načítající vstupní data. Každý záznam vyparsovaný ze vstupu je ihned předán ke zpracování a podle svých vlastností je začleněn do již existující části hierarchie a následně je vložen do datového úložiště. Dokončená hierarchie je pak předána webovému rozhraní k zobrazení. Tento přístup je sice pamět ově náročnější, protože je nutné udržovat v paměti jak určitou množinu objektů, tak celou hierarchii. Nicméně oproti přístupu, kdy se pouze uloží data a hierarchie je následně budována nad výsledky dotazů nad databází, výrazně šetří čas strávený přístupy na disk. Navíc pamět aplikačního serveru je zpravidla schopna takové požadavky obsloužit, zatímco nutnost neustále čekat na vstup-výstupní operace vede ke zvýšení prodlevy při zpracování požadavku. Nyní tedy uživatel pracuje pouze s reprezentanty celé datové množiny, které lze pomocí odpovídajících metod dále filtrovat a třídit. Je dobré připomenout, že od chvíle, kdy byla načtena vstupní data, nebylo přistupováno do datového úložiště. Minimalizace těchto přístupů vede k celkovému zvýšení datové propustnosti aplikace. Až ve chvíli, kdy je uživatel odkázán jedním z reprezentantů na odpovídající skupinu dat, je do databáze zavolán dotaz na data s danými vlastnostmi. Tato podmnožina dat je díky svým specifickým vlastnostem značně omezena, představuje tedy relativně malé zatížení klienta (vizualizace dat probíhá na klientské straně). V tomto momentě je možné začít s vizualizací konkrétních dat. Stále je však třeba mít na paměti, že zobrazení bude probíhat v prohlížeči pomocí JavaScriptu, což na ni klade výraznější omezení než kupříkladu na zobrazení v OpenGL. Momentálně načtené množství dat by mělo být vhodné pro dvojrozměrnou statickou vizualizaci, která neklade přílišné nároky na prohlížeč. I přes limitovanost této podmnožiny dat není jisté, zda počet jejích prvků nebude pro složitější zobrazení příliš vysoký. Je-li tedy třeba zobrazit tato data nějak komplexněji, například trojrozměrně pomocí WebGL, případně je ještě animovat, nároky na prohlížeč budou s největší pravděpodobností příliš vysoké. Proto pokud je zapnuta takto složitá vizualizace, je nutné zbývající prvky znovu filtrovat, nejlépe tak, aby toto zobrazení zahrnovalo jediný, uživatelem zvolený prvek. 28

35 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ 5.3 Implementace Tato sekce popisuje principy použité při implementaci aplikace a vysvětluje rozhodnutí učiněná v procesu vývoje. Celá aplikace se skládá ze čtyř vzájemně nezávislých modulů popisovaných v sekci o návrhu aplikace. Každý z nich je reprezentován jedním artefaktem (projektem). Mimo modul obsahující webové rozhraní jsou všechny artefakty kompilovány jako knihovny tříd Backend Perzistence dat Pro perzistenci dat byla použita technologie RavenDB. Hlavním důvodem k použití právě tohoto úložiště je jeho minimalistický přístup k ukládání dat a velmi vysoká rychlost. Další příjemnou vlastností je velmi jednoduchá manipulace s daty a také srozumitelnost jejich objektové reprezentace. Hlavní entitou této aplikace je molekulární motiv, reprezentovaný třídou Motif. Tato třída splňuje požadavky RavenDB na entitu je tedy POCO. Obsahuje pouze veřejně přístupné vlastnosti, které udávají atributy daného objektu, a také překryté metody Equals a GetHashCode. Překrytím metody Equals je zaručeno, že dva objekty tohoto typu jsou shodné právě tehdy, pokud mají stejný identifikátor. ID objektu musí být unikátní, tento postup tedy zabraňuje kolizím a navíc také ukazuje, kdy je třeba vytvořit nový dokument v databázi a kdy upravit stávající. Po překrytí metody Equals je nutné překrýt také metodu GetHashCode. Ta v tomto případě vrací stejný hash pro dva objekty se shodným identifikátorem. DAO vrstva Základním kamenem DAO vrstvy je její interface, tedy rozhraní. Všechny DAO komponenty jej musí implementovat, aby bylo možné zajistit nezávislost na konkrétním úložišti. Implementace DAO komponenty pro manipulaci s objekty třídy Motif obsahuje kromě standardních CRUD operací (tedy Create, Retrieve, Update a Delete) také metody pro načtení všech záznamů z databáze a hlavně několik dotazovacích metod, které vrací seznam objektů se zadanými parametry. K účelům testování zde existuje také metoda pro smazání všech dokumentů z databáze. Všechny metody validují své vstupní parametry a při chybném formátu vyhazují výjimky. Momentální verze aplikace obsahuje implementaci DAO třídy pracující se zmíněnou RavenDB. Komunikace s databází v tomto případě probíhá pomocí instance třídy implementující rozhraní IDocumentStore, která zajišt uje spojení s databázovým serverem. Ta je do třídy dynamicky injektována za běhu programu frameworkem Unity, který zároveň zajišt uje, že se jedná o singleton, a řídí její životní cyklus. Při jakémkoli požadavku na databázi je nutné pomocí volání metody OpenSession na této instanci získat objekt session představující spojení se serverem. Následné operace se provádí jako metody objektu session, k uložení změn je nutné zavolat metodu SaveChanges. Dotazování 29

36 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ se realizuje pomocí LINQ (Language Integrated Query). Menší nepříjemnosti působí editace dokumentů, protože RavenDB nepodporuje metodu Merge, tedy automatickou změnu všech atributů dokumentu na základě vstupního objektu. Metoda Update tedy využívá Reflection API kvůli možnosti budoucího rozšíření či změny vlastností entity. Obrázek 5.2: Příklad práce DAO komponenty vytvoření nového dokumentu v databázi Adaptér Komponenta adaptér je v tomto případě představována třídou DTOAssembler, která obsahuje metody pro konverzi bussiness objektů a data transfer objektů. Podle toho, zda má daný objekt již přiřazený identifikátor je schopna bud vytvořit, nebo upravit odpovídající objekt pro další zpracování. Pro jednodušší manipulaci s výsledky ve formě seznamů objektů obsahuje tato třída také metody pro konverzi mezi seznamy. Protože všechny metody poskytované touto třídou jsou statické, je implicitní veřejný bezparametrický konstruktor třídy překryt privátním bezparametrickým konstruktorem, aby nebylo možné třídu instanciovat. Servisní vrstva Servisní vrstva je opět určena svým interfacem, který se ovšem nalézá v modulu API. Mohlo by se zdát, že jde pouze o nadbytečnou režii, protože doposud jediná věc, kterou servisní vrstva provádí, je delegování požadavků na pod ní ležící DAO vrstvu. Tento 30

37 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ stav sice zatím přináší pouze nadbytečný krok při zpracování, ale do budoucna poskytuje možnost rozšíření aplikace o nové entity a dokonce použití více datových úložišt a transakční manipulaci s nimi. DAO vrstva totiž není schopná řídit transakce nad více entitami či databázemi, protože každá DAO komponenta je pevně svázána pouze s jedinou entitou a jednou databází. Servisní vrstva je tedy nejnižším bodem aplikace schopným řídit složitější transakce. Dalším důvodem její existence je potřeba zajistit jednotnou komunikaci s ostatními částmi aplikace prostřednictvím DTO. Z tohoto důvodu je servisní vrstva zvolena jako rozhraní pro komunikaci všech modulů. Servisní komponenta obsluhující operace nad molekulárními motivy vyžaduje ke své práci instanci odpovídající DAO komponenty. Tato závislost je opět dynamicky řešena a spravována IoC kontejnerem Unity za běhu aplikace. Pro přehlednost těchto komponent byly odpovídající si metody nazvány stejně, liší se pouze v typech vstupních či výstupních parametrů (entitní objekty versus data transfer objekty) Loader Modul loader odpovídá za načtení dat z libovolného zdroje. Se zbytkem aplikace komunikuje pomocí svého rozhraní, které je umístěné v modulu API, a také skrz rozhraní servisní vrstvy. Aplikace zatím obsahuje implementaci schopnou načíst data ze souboru ve formátu CSV. K tomuto účelu využívá knihovnu File Helpers, která jednoduše načte soubor a vyparsuje z něj objekty. Tyto objekty jsou definovány speciální třídou, která obsahuje pouze proměnné stejného jména, jako sloupce v souboru, a také metodu pro převedení na DTO. Během zpracovávání dat si tato komponenta vytváří statistiky o načtených objektech, které je možné zapsat do souboru pomocí určené metody. Pokud některá z metod selže, vyhodí výjimku LoaderException, která byla k tomuto účelu definována. Mimo to je úkolem této součásti vytvořit hierarchii reprezentující vstupní data. K tomu využívá tříd ParentNode a LeafNode, které rozšiřují třídu Node a představují jednotlivé prvky (uzly) hierarchie. Tyto třídy jsou kvůli využití více moduly definovány v modulu API. Při vytváření hierarchie postupuje následovně: Během načítání dat vytváří statistiky o počtu načtených objektů, ale mimo jiné také o rozdílných signaturách a strukturách objektů a počtu jim příslušících prvků. Následně pomocí těchto statistik vypočte jednotlivé vzdálenosti přítomných signatur, vytvoří kořenový prvek hierarchie a pak shora dolů vytváří hierarchii objektů. Výsledkem je uspořádání, na jehož vrcholu je kořenový prvek, pod ním se nachází uzly představující jednotlivé vzdálenosti signatur, ty obsahují uzly náležící příslušným signaturám a v nich se pak nachází koncové uzly reprezentující struktury s danými vlastnostmi. Hierarchii v tomto formátu pak uloží do jednoho kořenového uzlu a předá ji k dalšímu zpracování. K tomuto účelu existuje specializovaná třída schopná setřídit a filtrovat danou hierarchii podle zadaných rozsahů signaturových vzdáleností. Například existující singaturové vzdálenosti 1, 2, 4 a 6 31

38 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ je schopna spojit do shluků obsahujících vzdálenosti 1 4 a 6. Pokud zadaná rozmezí neobsahují všechny existující vzdálenosti, všechny uzly obsahující vzdálenosti mimo stanovený rozsah jsou filtrovány API Účelem tohoto modulu je odstranit vzájemné závislosti jednotlivých artefaktů a směřovat je výhradně na tento modul, aby bylo možné ostatní artefakty kdykoli změnit. Tento úkol však není možné splnit při použití naivního přístupu k přidělování zdrojů objektům. Je sice možné definovat závislost objektu na jiném objektu obsaženém v jiném modulu pomocí rozhraní, nicméně v určité chvíli bude nutné tuto závislost vyřešit a přidělit do ní konkrétní implementaci. V tomto bodě selhává naivní přístup, protože je-li daná implementace součástí jiného artefaktu, nezbývá než ji specifikovat v kódu, a tudíž vytvořit na daný artefakt referenci. Proto krom definice rozhraní komponent, které jsou používány ke komunikaci mezi moduly, je nutné k řešení závislostí použít IoC framework, a ten odpovídajícím způsobem nakonfigurovat. Tato aplikace pro účely dynamického přidělování zdrojů využívá imperativně konfigurovaný framework Unity Application Block Frontend Vzhledem ke skutečnosti, že předmětem této práce je vizualizace molekulárních motivů, je jasné, že implementace uživatelského rozhraní aplikace bude hrát zásadní roli v procesu vývoje. Vzhledem k využití technologie ASP.NET MVC se vývoj webového rozhraní dělí na vytváření modelu, pohledů a controllerů. Model v tomto případě tvoří data získaná z backendu aplikace ve formě seznamu data transfer objektů. Pohledy tato aplikace obsahuje dva: hierarchický a pivot view. Oba tyto pohledy spravuje jeden controller zaměřený na zpracování dat a požadavků zahrnujících molekulární motivy. Controller Controller je odpovědný za předávání dat pohledům a jejich korektní zobrazení uživateli. Aplikace obsahuje controller zaměřený na zpracování dat molekulárních motivů obsahující dvě základní metody: Index a Grid. Obě tyto metody jsou volány prostřednictvím Http Get requestu a vrací s nimi svázaný pohled. Výjimky vyhozené v rámci těchto metod jsou prozatím logovány na standardní výstup. Pohled Index je nastaven jako výchozí stránka při spuštění. Aplikace se stále nachází v testovacím režimu, zavolaná metoda Index tedy nejdříve zavolá metodu Store na přidělené instanci třídy Loader, která se nejprve pokusí vyprázdnit existující databázi a poté ji znovu naplnit daty ze zadaného souboru. Dalším krokem je získání objektu reprezentujícího hierarchii dat opět z této instance třídy Loader. Poslední úlohou této metody je setřídit obdrženou hierarchii a předat ji asociovanému pohledu ve formátu 32

39 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ JSON. Každý uzel v hierarchii je specifikován svým jménem a seznamem potomků. Jedná-li se o koncový uzel, místo seznamu potomků obsahuje záznam o počtu objektů, které mu náleží. Obrázek 5.3: Příklad hierarchie dat ve formátu JSON Metoda Grid zajišt uje zobrazení pohledu pivot view s daty odpovídajícími uživatelovu výběru. Protože je aplikace navržena tak, aby se tato metoda zavolala při výběru jednoho z koncových uzlů hierarchie, je třeba nejprve pomocí instance servisní komponenty získat z databáze seznam objektů se zadanými vlastnostmi. Tyto objekty musí obsahovat určenou signaturu a náležet dané struktuře. Poté je nutné tato data převést do formátu kompatibilního s použitým pivot view. Výchozím způsobem je předání dat ve formátu XML, resp. CXML. Model Část aplikace reprezentující model se v tomto případě nenalézá v rámci frontendu, ale tvoří ji bussiness logika backendu, potažmo data získaná voláním metod servisní vrstvy. Tato data jsou reprezentována pomocí DTO, které také slouží k vytvoření silně typovaného pohledu asociovaného s metodou Grid obsaženou v příslušném controlleru. View Z hlediska uživatele je view, neboli pohled nejdůležitější částí aplikace, protože poskytuje rozhraní pro interakci. Pohledy v sobě také skrývají hlavní smysl této aplikace, protože bez nich by nebylo možné data vizualizovat. Jak již bylo zmíněno, aplikace obsahuje dva hlavní pohledy. Prvním z pohledů je zmiňovaný hierarchický pohled. Jeho účelem je poskytnout přehledný náhled na načtená data jako na celek a zároveň umožnit filtrování výsledků tak, že se v další fázi zobrazí pouze ta část dat spadající do kategorie, kterou uživatel zvolil. Celá tato vizualizace je realizována pomocí knihovny D3.js, která nabízí velmi jednoduchý a mocný přístup k datům ve webové stránce. 33

40 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ Základ vizualizace tvoří tzv. pack layout, což je jedna z možností uspořádání dat do skupin, kterou D3.js nabízí. Prvním krokem je vytvořit blokový element, do kterého budou data zobrazena. Následně je třeba do něj pomocí D3 selektoru přiřadit SVG element, který bude sloužit jako kreslicí plátno. V tuto chvíli je možné začít načítat data z připraveného JSON objektu. Funkce d3.json je schopna pomocí AJAXových volání asynchronně načíst požadovaná data a přiřadit je do javascriptové proměnné, která v tuto chvíli bude představovat kořenový uzel celé hierarchie. Je-li načítání hotovo, je načase přiřadit jednotlivým uzlům v hierarchii nějakou vizuální reprezentaci pomocí enter selekcí a funkce append. Tato aplikace využívá kruhovou reprezentaci uzlů, kde každému kruhu je na základě vlastností daného uzlu přiřazena velikost a pozice uvnitř kořenového kruhu. Navíc jsou pomocí přiřazené třídy rozlišeny jak logicky, tak vizuálně kruhy koncové a nekoncové. Koncové kruhy jsou jediné prvky, které nejsou průhledné, uživatel je tedy schopen vidět skrz celou hierarchii až na její pomyslné dno. Nyní je třeba zajistit interakci s uživatelem, každému kruhu je tedy přiřazena akce při kliknutí, která plynule přiblíží pohled na vybraný prvek. Koncové uzly navíc při výběru odkazují na další fázi vizualizace, kterou tvoří pohled Grid. Při kliknutí na již přiblížený prvek nebo při kliknutí mimo hierarchii se pohled opět oddálí na původní úroveň. Posledním úkonem je přiřazení popisků jednotlivým uzlům, které je opět realizováno pomocí enter selekcí a znovu je rozlišeno zda je daný uzel koncový. Obrázek 5.4: Zobrazení hierarchie testovacích dat 34

41 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ Druhým pohledem je pak pivot view implementované pomocí open source projektu LobsterPot Pivot Viewer Control. Účelem tohoto pohledu je zobrazit jednotlivé molekulární motivy v mřížce společně s jejich vlastnostmi a umožnit uživateli je interaktivně prozkoumávat. Uživatel má možnost s mřížkou libovolně manipulovat posouvat a přibližovat, filtrovat a třídit prvky nebo přímo přepnout z mřížkového zobrazení na sloupcový graf, který uspořádá objekty podle určené vlastnosti. Pivot Viewer Control je do stránky vložen skrz element <div> s identifikátorem "pivotviewer", kterému lze bud nastavit napevno rozměry, nebo implicitně převezme rozměry nadřazeného blokového elementu. K jeho inicializaci je potřeba vložit do stránky skript v syntaxi knihovny JQuery, který při načtení dokumentu Pivot Viewer zobrazí a předá mu reference na objekty sloužící k načítání kolekce dat a mimo jiné také k zobrazení vizuálních reprezentací položek. Výchozí komponenta načítá data z formátu CXML, do kterého je aplikace schopna svá data převést. Nicméně tzv. Image Controller, neboli součást odpovědná za vizualizaci dat předpokládá existenci obrázků ve formě DZI, což není pro tuto aplikaci vhodné. Díky stanovenému rozhraní jednotlivých komponent Pivot View Control je možné vytvořit vlastní funkci pro vizualizaci molekulárních motivů v rámci tohoto pivot view. Nejprve je nutné definovat javascriptovou třídu, která bude implementovat rozhraní IImageController a tím pádem i funkci DrawLevel, která bude odpovídat za zobrazení jednotlivých dlaždic mřížky. Mezi vstupní parametry této funkce patří objekt, který má být zobrazen, kontext, jenž ho zobrazí, pozice v mřížce a rozměry dlaždice. Pro zobrazení molekulárních motivů tato aplikace pro začátek využívá knihovny ChemDoodle Web Components, která načítá data ve formátu PDB. Prvním krokem je načtení těchto dat do javascriptové proměnné. Zde je zapotřebí dávat pozor na zápis těchto dat. ChemDoodle je schopen bez problémů přečíst soubory, které byly pro tuto příležitost optimalizovány například desktopovou verzí ChemDoodle, běžně užívané soubory však mohou pro tuto knihovnu představovat problém. Není-li schopna daná data přečíst, je nutné se ujistit, že při uložení do proměnné jsou nové řádky označeny znakem "\n"a celý záznam končí klíčovým slovem END. Následně je třeba instanciovat interpret těchto dat, v ChemDoodle označený jako PDBInterpreter. Další fází je vytvoření instance kreslicího plátna, konkrétně tato aplikace využívá pro zobrazení motivů platno RotatorCanvas pro dvojrozměrné zobrazení, ViewerCanvas3D pro trojrozměrnou vizualizaci. Po vytvoření plátna je použit interpret, který přečte vstupní data a následně je předá plátnu k vykreslení. Bohužel je nutné plátno při vytvoření asociovat s již existujícím prvkem DOM, tedy je nutné pomocí tagu <canvas> mít někde na stránce přichystané plátno. To však může být schované za jiným prvkem stránky, tudíž nemusí být jeho existence vůbec znát. Větším problémem se stává nutnost při každé změně dlaždic překreslit nejprve toto plátno, následně získat referenci na jeho kontext a pomocí něj překreslit toto plátno na zadanou dlaždici. 35

42 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ S trojrozměrnou vizualizací je postup velmi podobný, nicméně kvůli vysoké náročnosti zobrazení pomocí WebGL je nutné nejdříve specifikovat jeden prvek, který má být touto formou zobrazen. K tomu je využíváno událostí, které pivot view vytváří při určitých interakcích s uživatelem. Zásadní v tomto smyslu jsou dvě události: "Item/Selected" a "ZoomController/ZoomAndCentre". První událost dává najevo, že byl vybrán prvek, druhá pak že jeden z prvků se nachází na středu obrazovky a je na něj přiblíženo. Pomocí JQuery funkce subscribe je možné tyto události zachytit. Z první události funkce získává informace o právě vybraném objektu a zachycení druhé události pak iniciuje přechod na trojrozměrné zobrazení tohoto prvku. Kvůli nutnosti udržovat plátno, se kterým by byla asociována konkrétní instance ViewerCanvas3D, je třeba toto plátno po odznačení opět zrušit, aby zbytečně nezabíralo zdroje. K tomuto účelu je nasloucháno události "Item/Deselected". Obrázek 5.5: Zobrazení testovací molekuly v LobsterPot Pivot View Mimo tyto dva základní pohledy je třeba ještě zmínit dokument udávající společné rozvržení jednotlivých stránek. Ten je zkonstruován pomocí komponent poskytovaných balíčkem Twitter Bootstrap. Mimo jiné definuje společný vzhled navigační lišty nebo zápatí stránek. Důležitou součástí tohoto dokumentu je blok obsahující Body() představující tu část stránky, do které se zobrazí data aktuálního pohledu. 36

43 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ 5.4 Testování aplikace Z důvodu budoucího nasazení bylo nutné podrobit aplikaci zátěžovým testům a zjistit dobu odezvy na různě velkých datových množinách. Aplikace prošla profilovacími testy na testovacích datech čítajících přibližně 7 tisíc motivů (cca 50 MB) a 50 tisíc motivů (cca 210 MB). Testovací prostředí a podmínky Aplikace byla testována na stroji Lenovo R500 NP77UMC (procesor Intel Core Duo P GHz, 2 GB RAM, HDD 5400 ot./s) na systému Windows 7 32-bit. Aplikace byla nasazena na aplikační server IIS Express. Databáze RavenDB byla v tomto případě spuštěna v embedded režimu a byla při každém opětovném zpracování dat znovu vytvářena. Použitým profilovacím nástrojem se stala sada MS Visual Studio 2012 Ultimate Profiling Tools Výsledky testů Cílem testů bylo zjistit podíl jednotlivých kroků při zpracování motivů na celkovém času obsluhy požadavků a také možnosti prohlížeče při zobrazení jednotlivých kroků vizualizace. Testy zpracovávání dat přinesly následující výsledky. Podíl operací na času zpracování Stěžejním účelem testů bylo zjistit, kolik času jednotlivé operace při zpracování objektů spotřebují. Výsledky se nachází v tabulce 5.1. Operace Průměrný čas běhu (ms) Inicializace knihovny FileHelpers 12 Vytvoření databáze 7117 Uložení 1 motivu do databáze 1,4505 Celková doba zpracování 1 motivu 1,4516 Zpracování 7214 motivů Zpracování motivů Zápis statistik do souboru 9 Vytvoření clusteru struktury 0,0005 Vytvoření clusteru signatury 1,1349 Vytvoření clusteru vzdálenosti 1,6923 Zpracování hierarchie 7214 motivů 5842 Zpracování hierarchie motivů Tabulka 5.1: Časy spotřebované jednotlivými operacemi 37

44 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ Zátěž procesoru Dalším faktorem sledovaným při profilování je zatížení procesoru. Pro obě datové množiny nejvyšší zátěž nastává při startu aplikace, kdy IoC kontejner musí vyřešit závislosti jednotlivých komponent použitých v procesu zpracování dat a následně je vytvořena nová instance databázového serveru. Pro menší množinu pak po zbytek běhu (tj. při ukládání objektů a vytváření hierarchie) hodnota zátěže osciluje přibližně mezi 5% a 40%. Obrázek 5.6: Využití procesoru při zpracování menší množiny dat Pro větší množinu dat celková zátěž procesoru podle očekávání roste, navíc se větší počet prvků projevuje při zobrazení hierarchie v prohlížeči. Zatímco pro 7 tisíc objektů nebylo problémem hierarchii zobrazit, pro tuto množinu dat vzniká hierarchie, která klade viditelně vetší nároky na vizualizaci. To vede k výrazně vyšší zátěži procesoru, času zobrazení a také pamět ové náročnosti. Obrázek 5.7: Využití procesoru při zpracování větší množiny dat 38

45 5. NÁVRH, IMPLEMENTACE, TESTOVÁNÍ Pamět ová náročnost Z hlediska pamět ové náročnosti je možné konstatovat, že provoz této aplikace je zcela v možnostech dnešních počítačů. Testy prokázaly, že je možné tuto aplikaci nasadit i na osobním počítači. Využití paměti aplikačního serveru nepřesáhlo hodnotu 230 MB pro menší a 320 MB pro větší datovou množinu. Největší nároky na pamět však klade zobrazení hierarchického pohledu v prohlížeči. Například pro Mozilla Firefox se pamět ové požadavky pohybují mezi 200 MB a 500 MB (do této hodnoty je započtena pouze pamět nutná k zobrazení tohoto pohledu) podle velikosti datové množiny a také v závislosti na aplikaci filtrů. Nároky na zobrazení pohledu pivot view pak nepřesahují ty na zobrazení hierarchického pohledu, zejména diky poměrně jemné granularitě uzlů v hierarchii. Právě tato skutečnost způsobuje zvýšené nároky hierarchického pohledu, nicméně snižuje počet motivů v jednotlivých skupinách. Počty prvků ve skupině se totiž pohybují v řádu jednotek nebo několika desítek. Zobrazení hierarchie objektů Tento krok vizualizace je výpočetně nejnáročnější zejména kvůli vysokému počtu uzlů hierarchie. Pro uživatelsky přívětivou navigaci je nutné použít možnosti přibližování na jednotlivé prvky, což znamená překreslování celé hierarchie na základě zvoleného prvku. Testy ukázaly, že pro běžný osobní počítač leží hranice počtu zobrazených uzlů při plynulosti přechodů okolo 4 tisíc. Nicméně větší použitá testovací množina dat generuje i větší počty uzlů. Takto vysoké počty prvků mohou zahltit prohlížeč a znemožnit jakoukoli interaktivitu v závislosti na výkonu počítače. Pro tento případ je doporučeno nezobrazovat celou hierarchii, ale použít již zmíněné filtry. 39

46 Kapitola 6 Závěr Výsledkem této práce je webová aplikace napsaná v jazyce C# určená k vizualizaci molekulárních motivů. Umožňuje uživateli interaktivně prozkoumávat data těchto motivů a prohlížet jak jejich dvojrozměrné projekce, tak také trojrozměrné modely. Klíčovou vlastností této aplikace je její velmi snadná rozšiřitelnost a možnost vyměnit jakoukoli implementaci jakékoli komponenty za jinou, přičemž tyto implementace je možné střídat také za běhu pomocí IoC kontejneru. Druhým zásadním znakem této aplikace je schopnost zpracovat naráz velké množství dat s velmi nízkou dobou odezvy. Toho bylo docíleno použitím minimalistické, velice výkonné databáze, minimalizací vstup-výstupních operací při zpracování dat, velmi rychlou vizualizací za pomoci mocných javascriptových knihoven a také rozdělení vizualizace do několika kroků, které nejen zpřesňují a konkretizují zobrazení, ale také zmenšují množinu právě zpracovávaných dat. Výsledkem je i přes rostoucí náročnost vizualizace stále nízká odezva, protože množství zobrazovaných objektů klesá s komplexností zobrazení. Vytvořená aplikace tedy poskytuje pohodlný způsob vizualizace molekulárních motivů z textového formátu s příjemným, přehledným uživatelským rozhraním a vysokým výkonem při zpracovávání požadavků. 40

47 Příloha A Snímky obrazovek z jednotlivých kroků vizualizace Zde se nacházejí ukázky vizualizačních technik použitých v aplikaci. Obrázek A.1: První krok: kruhová reprezentace hierarchie dat 41

48 A. SNÍMKY OBRAZOVEK Z JEDNOTLIVÝCH KROKŮ VIZUALIZACE Obrázek A.2: Druhý a třetí krok: 2D zobrazení molekuly v pivot view Obrázek A.3: Čtvrtý krok: 3D zobrazení molekuly v pivot view 42

49 Příloha B Hierarchický pohled na testovací data a aplikace filtrů Tato příloha obsahuje snímky obrazovek pro srovnání zobrazené hierarchie při aplikaci různých filtrů. První obrázek představuje hierarchii vzniklou zpracováním množiny obsahující motivů, která byla vygenerována MotiveQuery výrazem "Rings(5 * ["C"] + ["O"]).AmbientResidues(4)". Následující snímky demonstrují stejnou hierarchii po aplikaci rozdílných filtrů, které manipulují s uzly na základě signaturové vzdálenosti a jsou schopny je seskupovat. Další snímky ukazují zadávání filtrovacích parametrů. Obrázek B.1: Nefiltrovaná hierarchie 43

50 B. H IERARCHICKÝ POHLED NA TESTOVACÍ DATA A APLIKACE FILTR U Obrázek B.2: Aplikace filtru (1, 2): pouze skupiny se signaturovou vzdáleností 1-2 Obrázek B.3: Aplikace filtru (3, 4, 5): skupiny se signaturovou vzdáleností 3-4 a 5 Obrázek B.4: Aplikace filtru (5): skupina se signaturovou vzdáleností 5 44

51 B. HIERARCHICKÝ POHLED NA TESTOVACÍ DATA A APLIKACE FILTRŮ Obrázek B.5: Snímek aplikace v hierarchickém pohledu Obrázek B.6: Zadávání filtrovacích parametrů 45

52 B. HIERARCHICKÝ POHLED NA TESTOVACÍ DATA A APLIKACE FILTRŮ Obrázek B.7: Zadání neplatných parametrů 46