Filtrovanie kauzálnych genetických variantov bakalárska práca

Transcription

1 Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky Filtrovanie kauzálnych genetických variantov bakalárska práca 2016 Ondrej Rudolf

2 Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky Filtrovanie kauzálnych genetických variantov bakalárska práca Študijný program: Študijný odbor: Školiace pracovisko: Školiteľ: Informatika 2508 Informatika Katedra informatiky Mgr. Jaroslav Budiš Bratislava, 2016 Ondrej Rudolf

3 Univerzita Komenského v Bratislave Fakulta matematiky, fyziky a informatiky ZADANIE ZÁVEREČNEJ PRÁCE Meno a priezvisko študenta: Študijný program: Študijný odbor: Typ záverečnej práce: Jazyk záverečnej práce: Sekundárny jazyk: Ondrej Rudolf informatika (Jednoodborové štúdium, bakalársky I. st., denná forma) informatika bakalárska slovenský anglický Názov: Cieľ: Filtrovanie kauzálnych genetických variantov Hypothesis driven filtering of genetic variants Rozšíriť aplikáciu Variant Annotation Analyser o cielené filtrovanie genetických variantov. Užívateľ podľa symptómov pacienta vyberie potenciálne ochorenia. Následne sa vyfiltrujú varianty v oblastiach génov, ktoré s nimi súvisia. Študent využije verejne dostupné databázy na získanie prepojenia medzi ochorením, jeho príznakmi a kauzálnymi génmi. Vedúci: Katedra: Vedúci katedry: Dátum zadania: Mgr. Jaroslav Budiš FMFI.KI - Katedra informatiky prof. RNDr. Martin Škoviera, PhD. Dátum schválenia: doc. RNDr. Daniel Olejár, PhD. garant študijného programu študent vedúci práce

4 Poďakovanie. Ďakujem svojmu školiteľovi Mgr. Jaroslavovi Budišovi za pomoc pri vypracovaní tejto bakalárskej práce.

5 Abstrakt Táto bakalárska práca patrí do oblasti bioinformatiky a zaoberá sa problematikou diagnostiky dedičných chorôb. Nadväzuje na predchádzajúce výsledky a zaoberá sa rozšírením aplikácie Variant Annotation Analyzer o novú funkcionalitu. Nový modul má na starosti diagnostiku dedičných chorôb na základe pacientovych príznakov a následné filtrovanie pacientovho variantu. Prvá časť práce sa zaoberá biologickým pozadím problému a rôznym prístupom pri diagnostike dedičných chorôb. Druhá časť obsahuje návrh a realizáciu algoritmického riešenia diagnostiky, podrobnejší popis jednotlivých použitých algoritmov a tiež vybrané ukážky ich použitia. V záverečných častiach práce popisujeme používateľské prostredie a návod pre prácu s aplikáciou. Kľúčové slová: bioinformatika, počítačová diagnostika, genetické choroby, variant, filtrovanie

6 Abstract This bachelor thesis belongs to the field of bioinformatics and deals with diagnostic problems of hereditary diseases. It build on previous results and discuss the extension of the Variant Annotation Analyzer application by new functionality. New module is in charge of diagnosis hereditary diseases, on base of patient sympotoms and filtration patient variant. First part of bachelor thesis focuse on biological background and different aproaches in diagnosis of hereditary diseases. Second part contains design and realization of algorithmical solution of diagnosis, more detailed description of used algorithms and selected previews. In the third part we describes the user interface and show how user interact with application. Keywords: bioinformatics, computer diagnostics, genetic diseases, variant, filtration

7 Obsah Úvod 1 1 Motivácia Biologický úvod Diagnostika pomocou modulu Popis aplikácie VAA Východiskový stav Štruktúra vstupných dát Ontológia ľudského fenotypu Popis tabuľky term a s ňou súvisiacich tabuliek Popis tabuľky chorôb a tabuľky anotácií Súbor vzťahov chorôb k génom VCF súbor Teoretická časť Výpovedná hodnota Najinformatívnejší spoločný predok Podobnosť v ontológii Pravdepodobnostné ohodnotenie Implementačné detaily Databáza Vkladanie závislostí iv

8 OBSAH v 4.3 Práca so súbormi Aktualizácie Udalosti Práce Filtre Používateľské rozhranie 26 Záver 29

9 Zoznam obrázkov 1.1 Prostredie VAA Schéma databázy HPO[7] Ukážka tabuľky term Príklad anotácií Príklad vytovrenia objektu spolu so statickým kontextom Príklad volania a registrovania udalosti Používateľské rozhranie - príznaky Používateľské rozhranie - choroby vi

10 Úvod Príchodom nových biochemických technológií, ktoré súhrnne označujeme ako Sekvenátory novej generácie (NGS - Next Generation Sequencing), sa výrazne urýchlil biomedicínsky výskum. V biomedicíne sa objavili požiadavky na software, ktorý by biológom v laboratóriach uľahčil prácu s množstvom dát získaných sekvenovaním. NGS sekvenátory našli využitie aj v rozličných odvetviach medicíny, medzi ktoré patrí aj diagnostika dedičných chorôb. Zmeny v ľudskom genóme majú rôzne významy. Niektoré z nich nemajú negatívny vplyv na zdravotný stav jedinca a spôsobujú iba odlišnosti ako napríklad farba očí, ale iné zmeny môžu zapríčiniť vážne ochorenia. Preto je dôležité vedieť tieto zmeny správne identifikovať, čo spolu s pozorovanými príznakmi pacienta môže dopomôcť lekárovi presnejšie diagnostikovať ochorenie. V súčasnosti musí lekár pracne vyhľadávať príznaky a choroby v externých databázach, ktoré musí manuálne porovnať s pacientovým variantom. Preto vznikla požiadavka na aplikáciu, ktorá by vedela pracovať s databázou chorôb a odbremenila lekára od časovo náročnej manuálnej práce. Táto bakalárska práca voľne nadväzuje na predchádzajúcu prácu [6], ktorej cieľom bolo vytvoriť modulárnu aplikáciu na zobrazenie variantov a informácií k nim z externých zdrojov. Cieľom tejto práce je rozšírenie aplikácie o modul, ktorý bude mať na starosti výber filtrovaciaho kritéria - chorôb, a následneho vyfiltrovania zmien viažucim sa k nim. 1

11 Kapitola 1 Motivácia V prvej kapitole sa budeme venovať motivácii, ktorá viedla k napísaniu tejto práce. V krátkosti načrtneme základné biologické pozadie, potrebné k jej pochopeniu. V druhej časti kapitoly predstavíme aplikáciu Variant Annotation Analyzer (VAA) [3], do ktorej je náš modul určený. 1.1 Biologický úvod Na svete je obrovské množstvo chorôb. Niektoré z nich sa viažu k zmenám v DNA (deoxyribonukleová kyselina) a sú dedičné. Na ilustráciu uvedieme dva známe príklady takýchto chorôb, jednou z nich je hemofília a druhou farbosleposť. Hemofília je recesívna dedičná choroba prenášaná pohlavným chromozómom X, ktorou trpia najmä muži. Najznámejšia dedičná línia tejto choroby je zrejme v anglickom kráľovskom rode, počínajúc od kráľovnej Viktórie a jej syna Leopolda. Prvý popis dedičnosti hemofílie pochádza z roku Prvé objavy DNA pritom pochádzajú až z roku 1869 a jej úloha pri dedičnosti bola vedecky dokázaná až v roku [13] Informácie v DNA sú zakódované v postupnosti štyroch dusíkatých báz (adenín, guanín, cytozín, tymín). Ľudská DNA pozostáva z asi 3 biliónov báz, z ktorých však väčšina je rovnaká u všetkých ľudí. V postupnosti a poradí týchto báz je zakódovaná informácia potrebná pre stavbu a chod organizmu. 2

12 KAPITOLA 1. MOTIVÁCIA 3 Gén je základná fyzická a funkčná jednotka dedičnosti. Ľudský gén sa môže skladať od niekoľkých stoviek báz, až po viac ako dva milióny. Každý človek má dve kópie toho istého génu, od každého rodiča jednu. Väčšina génov je rovnaká u všetkých ľudí, ale v malom množstve z nich sa odlišujeme. Varianty toho istého génu s malými zmenami sa nazývajú alely. Tieto zmeny sú zodpovedné za to, že sa odlišujeme, ale môžu mať na svedomí nielen odlišnosti, ale aj vážne choroby. 1.2 Diagnostika pomocou modulu Naprogramovaný modul môže slúžiť ako pomôcka pre diagnostiku dedičných chorôb. Mnohokrát ide o choroby, ktoré sa v populácii vyskytujú veľmi zriedkavo. Lekár počas svojej praxe s takouto chorobou prichádza do styku len ojedinele, prípadne s ňou nemusí prísť do styku vôbec. Preto pri jej diagnostikovaní nemôže vychádzať zo skúsenosti, ale musí použiť vhodný zdroj informácií. Pri diagnostikovaní pomocou nášho modulu lekár najprv zadá pozorované príznaky u pacienta (fenotypové abnormality). Modul mu vráti pravdepodobnostne ohodnotený zoznam možných chorôb, z ktorých si lekár vyberie tie, na ktoré sa chce zamerať. Následne sa mu zobrazia tie miesta variantov pacientovej DNA, ktoré sa zároveň viažu aj k nejakej z vybraných chrôb. Od modulu sa neočakáva jednoznačná diagnostika pacientovej choroby, kvôli povahe problému, ktorý podrobnejšie vysvetlíme ďalej v práci. Avšak pravdepodobnostné ohodnotenie možných chorôb a informácie k nim, by mali lekárovi pomôcť pri hľadaní správnej diagnózy. 1.3 Popis aplikácie VAA Aplikácia Variant Annotation Analyzer je naprogramovaná v objektovom jazyku Java a pri návrhu bol použitý framework Eclipse RCP [12]. Tento framework umožňuje tvorbu samostatnej modulárnej aplikácie. Aplikácia v

13 KAPITOLA 1. MOTIVÁCIA 4 súčasnom stave vie pracovať so štandardným textovým súborom vo formáte VCF (Variant Call Format), ktorý popisuje varianty a ich vlastnosti u pacienta. Tento textový súbor je vstupom do programu a získa sa z vyšetrenia pacienta (sekvenovaním pacientovej DNA). Informácie sú prezentované v tabuľke, pričom používateľ si môže vybrať, ktoré atribúty variantu sa mu budú zobrazovať. Okrem toho vie aplikácia načítať informácie k variantom z webových databáz. 1.4 Východiskový stav Aplikácia Variant Annotation Analyzer (VAA), je naprogramovaná v jazyku JAVA za pomoci frameworku Eclipse 4 RCP [12]. Vo východiskovom stave aplikácia vie načítať vstupný súbor typu.vcf. Tento súbor si volí používateľ a obsahuje zoznam variantov. Aplikácia následne používateľovi zobrazí súbor v grafickom rozhraní tabuľky, a poskytuje základné nástroje pomocou ktorých si používateľ zvolí stĺpce s informáciami, ktoré sa mu majú zobraziť. Na zostrojenie grafického prostredia využíva aplikácia rozšírenie Eclipse e4 tools, ktoré uľahčuje prográmatorovi vývoj používateľského rozhrania pomocou editorov aplikačného modelu. Základné časti používateľského rozhrania sú definované v súbore Application.e4xmi. Na obrázku 1.1 je zobrazené základné okno aplikácie. V hornej lište aplikácie sa nachádza menu a rýchle odkazy. Zvyšok okna tvorí PerspectiveStack, v ktorom môžeme definovať perspektívy (Perspektive). V rámci jednotlivých perspektív sa definuje, ako sa má ich obsah zobrazovať. Medzi perspektívami vie programátor voľne prepínať. Základná perspektíva VAA je rozdelená na štyri časti pomocou viacnásobného použitia prvku PartStashContainer, ktorý umožňuje vertikálne alebo horizontálne rozdelenie obrazovky na dve časti. Každá z týchto častí obsahuje PartStack, ktorý slúži na zobrazovanie samotných častí s obsahom (Part). V pravej hornej časti sa zobrazujú aktuálne otvorené súbory VCF. Vľavo od nich sa nachádza menu, v ktorom si môže používateľ vybrať, ktoré stĺpce s informáciami sa mu majú zobrazovať. Spodná polovica obsahuje informačné

14 KAPITOLA 1. MOTIVÁCIA 5 Obr. 1.1: Prostredie VAA okno, ktoré zobrazuje detailnejšie informácie o označenom objekte. Napríklad pri označení niektorej bunky tabuľky zobrazí presnejší popis k typu hodnoty. V druhej časti spodnej polovice je rozšírenie ProgressView ktoré slúži na zobrazenie informácie o prácach (Job). Práce sú nadstavbou vlákien a okrem iného obsahujú rozhranie IProgressMonitor, pomocou ktorého dokážu zobrazovať používateľovi informácie o priebehu práce. Používateľ môže mať otvorených viacero súborov variantov naraz, pričom každý súbor predstavuje z vnútorného pohľadu aplikácie prácu, ktorá má vlastné dáta. Teda v každom otvorenom súbore môže mať používateľ napríklad zobrazené rôzne stĺpce.

15 Kapitola 2 Štruktúra vstupných dát V tejto kapitole sa budeme venovať štruktúre a popisu vstupných dát nášho modulu. Základné vstupné dáta tvorí ontológia HPO a súbor variantov. Keďže niektoré výpočty nad vstupnými dátami trvajú príliš dlho na to, aby sa vykonávali priamo v aplikácii, predpočítali sme ich a uložili do súborov. Tieto súbory budú považované tiež ako vstupné súbory do modulu, ale ich obsah bude podrobnejšie popísaný až v teoretickej časti spolu s podrobnejším vysvetlením. 2.1 Ontológia ľudského fenotypu Ontológia v informatike formálne popisuje slovník určitej oblasti a vzťahy medzi jej prvkami. Fenotyp je súhrn vonkajších znakov a vlastností organizmu. Naša aplikácia bude využívať fenotypovú ontológiu človeka (Human Phenotype Ontology [7]), skrátene HPO, ktorá vznikla s cieľom štandardizácie slovníka fenotypových abnormalít, s ktorými sa stretávame pri ľudských ochoreniach. Termíny v ontológii sú usporiadané v acyklickom orientovanom grafe, v ktorom potomkovia zväčša predstavujú špecifickejší prípad rodiča. Tomuto vzťahu hovoríme že to je "je" (is_a) vzťah, teda dieťa "je" rodič. Napríklad naša ontológia HPO popisuje fenotypové príznaky dedičných chorôb. Prirodzene môžeme povedať, že prvky ontológie majú rôznu výpovednú 6

16 KAPITOLA 2. ŠTRUKTÚRA VSTUPNÝCH DÁT 7 hodnotu. V našom prípade špecifickejší príznak nám dopomôže ľahšie určiť pacientovu chorobu. Zároveň človek intuitívne považuje prvky ontológie za viac alebo menej podobné. Pre výber HPO sme sa rozhodli z viacerých dôvodov. Jedným z nich je fakt, že HPO je v súčasnosti stále sa rozvíjajúci a aktualizovaný projekt, plný odkazov a referencií na iné biologické ontológie a databázy. Ďalší významný dôvod je, že ontológia je voľne dostupná a ponúka viacero možností prístupu. Pre náš program je najvýhodnejšia možnosť stiahnutia databázy vo forme SQL dumpu a dodatočného textového súboru. Tieto súbory sú aktualizované pravidelne raz za mesiac na stránke HPO [1]. V nasledujúcej časti podrobnejšie popíšeme obsah vybraných tabuliek databázy. Kompletná schéma databázy je znázornená na obrázku 2.1, kvôli lepšej čitateľnosti obrázok 2.1 prezentujeme otočený o 90 stupňov Popis tabuľky term a s ňou súvisiacich tabuliek Tabuľky term a term2term sa dajú považovať za základné tabuľky. Tabuľka term obsahuje defínicie termínov. Medzi pre nás významné vlastnosti termínu patrí názov ( name ) a jedinečný identifikátor v rámci tabuľky ( id ). Pomocou tohoto identifikátoru sa na daný termín odkazujú ostatné tabuľky. Keďže sa databáza neustále vyvíja, môžu mať termíny viac identifikátorov. Alternatívne identifikátory sú zaznamenané v tabuľke term_alternative_id. Okrem toho má každý termín pridelený stabilný jedinečný identifikátor ( acc ), ktorý má tvar HP: V tabuľke term2term sú zaznamenané vzťahy medzi termínmi. V stĺpci term1_id je identifikátor termínu rodiča a v stĺpci term2_id je identifikátor dieťaťa. Termíny sú pomocou tejto tabuľky usporiadané v orientovanom acyklickom grafe. Koreňom grafu je všeobecný termín All. Má troch potomkov predstavujúcich korene troch subontológií, do ktorých je HPO rozdelená. Najväčšia z nich je ontológia fenotypových abnormalít (termín phenotypic abnormality ), ktorú budeme my využívať. Ukážka tabuľky term je na obrázku 2.2

17 KAPITOLA 2. ŠTRUKTÚRA VSTUPNÝCH DÁT 8 fk_termdefinition_term_id fk_termid_synonym fk_annotation_termid fk_onset_modifier_onsetterm fk_sentence2term_termid term id int name varchar(200) is_obsolete tinyint(1) is_root tinyint(1) subontologyvarchar(1) comment mediumtext acc varchar(10) fk_graph_path_term1 fk_term2external_termid fk_term2term_term1 fk_graph_path_term2 graph_path term1_id int term2_id int distance int annotation term_id int external_object_disease_idint evidence_code varchar(5) is_negative tinyint(1) frequency_modifier varchar(20) annotation_id int annotated_date date annotated_by varchar(100) comment mediumtext fk_annotation_disease_id external_object_disease external_object_idint disease_id varchar(20) db_name varchar(20) disease_title varchar(200) disease_longtitle varchar(1000) fk_external_obj_disease disease2pubmedref external_object_disease_idint external_object_pubmed_idint fk_onset_modifier_annotationid annotation_onset_modifier annotation_id int onset_term_id int comment mediumtext term2external_object term_id int external_object_id int fk_term2external_ext_id external_object id int external_id varchar(20) fk_disease_ext_object external_db varchar(20) fk_pubmed_external_object external_object_pubmed external_object_idint pubmed_id int fk_external_obj_pubmed pubmed_title varchar(500) fk_sentence_ext_obj_pubmed abstract_sentence external_object_pubmed_idint sentence sentence_id term_id start_in_sent end_in_sente is_negative sentence_number int fk_sentence2term_sentenceid sentence mediumtext sentence_id int Obr. 2.1: Schéma databázy HPO[7]

18 KAPITOLA 2. ŠTRUKTÚRA VSTUPNÝCH DÁT 9 Obr. 2.2: Ukážka tabuľky term Popis tabuľky chorôb a tabuľky anotácií V tabuľke external_object_disease sú uvedené choroby, ktoré pochádzajú z iných databáz, ako napríklad OMIM [4]( Online Mendelian Inheritance in Man ), Orphanet, DECIPHER. Pri každej chorobe je preto uvedená databáza, z ktorej pochádza ( db_name ) a identifikátor v rámci tejto databázy disease_id. Niektoré choroby z databázy Orphanet priamo zodpovedajú chorobe v databáze OMIM. V takom prípade sú tieto záznamy spojené a alternatívne identifikátory sú uvedené v dlhom názve (stĺpec disease_longtitle ). Tabuľka anotácií prepája tabuľku termínov a chorôb, na základe ich tabuľkových identifikátorov term_id a external_object_disease_id. Choroby sú anotované vždy k najšpecifickejšiemu termínu, pričom ku všetkým jeho predchodcom je choroba anotovaná implicitne.

19 KAPITOLA 2. ŠTRUKTÚRA VSTUPNÝCH DÁT Súbor vzťahov chorôb k génom Tento samostatný textový súbor je vo forme tabuľky, ktorá má stĺpce oddelené tabulátorom. V prvom stĺpci obsahuje identifikátor choroby, ktorý sa skladá z názvu databázy, z ktorej pochádza daná choroba, a identifikátoru choroby v rámci tejto databázy. Druhý stĺpec obsahuje identifikátor génu a tretí stĺpec symbol génu. Tento súbor je súčasťou HPO, ale nie je súčasťou SQL dumpu a treba ho stiahnuť samostatne. Keďže databázu pred vstupom do programu modifikujeme, obsah tohoto súboru uložíme do samostatnej tabuľky. 2.2 VCF súbor Súbor typu.vcf (skratka z anglického Variant Call Format), je textový súbor, ktorého dáta sú špeciálne naformátované. V úvode obsahuje hlavičku, ktorá obsahuje informácie o verzii formátovania, ktorá je použitá. Súčasťou hlavičky sú ďalej nadpisy a definície stĺpcov. V samotnom tele súboru zodpovedá každý riadok jednému variantu. Stĺpce sú v rámci riadku oddelené tabulátorom.

20 Kapitola 3 Teoretická časť 3.1 Výpovedná hodnota Určovaniu podobnosti v ontológii sa venuje Resnik v svojej práci [10], ktorej výsledky budeme využívať v našom programe. Definícia Frekvencia výskytu termínu f req(t), je podiel počtu chorôb ku ktorým je termín anotovaný a celkového počtu chorôb. Výpovednú hodnota termínu (fenotypovej abnormality) budeme označovať skrátene IC z anglického information content. Termíny sú usporiadané v stromovej štruktúre, v ktorej platí, že potomok je špecifickejším typom rodiča. Pokiaľ je choroba anotovaná k termínu, je implicitne anotovaná aj ku všetkým jeho rodičom. Čím menej chorôb sa viaže k danému termínu, tým väčšiu výpovednú hodnotu má skutočnosť, že práve táto fenotypová abnormalita bola u pacienta pozorovaná. Definícia Výpovedná hodnota termínu IC(t) je záporný logaritmus frekvencie výskytu. IC(t) = log(f req(t)) (3.1) Teda napríklad termín atrioventricular block je anotovaný k 21 chorobám z 8057 a teda jeho IC je log(21/8057) = 5, 94. Oproti nemu vše- 11

21 KAPITOLA 3. TEORETICKÁ ČASŤ 12 obecnejší termín abnormality of the skeletal system sa vzťahuje k 3792 chorobám a teda jeho IC je log(3792/8057) = 0, 75. Pri takejto definícii ak má ontológia iba jeden koreň, je jeho výpovedná hodnota 0. Vyplýva to z toho, že každý jeho potomok "je"koreň a teda jeho pravdepodobnosť výskytu je 1. Výpovedná hodnota teda podľa tejto definície zodpovedá intuícii, častejší výskyt znamená menšiu výpovednú hodnotu. V našom prípade sú termíny ontológie príznaky, ktoré sú anotované k chorobám, pričom platí, že choroby anotované k príznaku sú implicitne anotované aj k jeho všetkým rodičom. Pravdepodobnosť výskytu v našom prípade znamená počet chorôb, ku ktorým je termín anotovaný, ku celkovému počtu chorôb. Pri našej definícií teda naozaj platí, že IC potomka je väčšie ako IC rodiča, aj že IC koreňa je 0. Keďže je k nemu implicitne anotovaná ktorákoľvek choroba, ktorá je anotovaná k nejakému príznaku, tak sú k nemu anotované všetky choroby, ktoré sa vyskytujú v ontológii. 3.2 Najinformatívnejší spoločný predok V grafových štruktúrach sa často vyskytuje potreba nájsť najnižšieho spoločného predka dvoch vrcholov. Ako názov napovedá, najnižší spoločný predok (Lowest Common Ancestor) je taký spoločný predok dvoch vrcholov, ktorý sa nachádza najďalej od koreňa. Táto definícia sa nám však pre naše úvahy nehodí, a preto použijeme inú definíciu, ktorá je pre stromy ekvivalentná. Definícia Najnižší spoločný predok vrcholov u a v je taký ich spoločný predok, pre ktorý navyše platí, že žiaden z jeho synov nie je spoločným predkom vrcholom u,v. Podľa tejto definície môžu mať dva vrcholy v orientovanom acyklickom grafe viacero najnižších spoločných predkov, ktorí ale nemusia byť rovnako ďaleko od koreňa. V našom prípade tvoria vrcholy grafu príznaky, ktoré majú určenú svoju výpovednú hodnotu.

22 KAPITOLA 3. TEORETICKÁ ČASŤ 13 Definícia Najinformatívnejším spoločným predkom dvoch príznakov je spomedzi ich najnižších spoločných predkov ten, ktorý má najväčšiu výpovednú hodnotu. Najinformatívnejšieho spoločného predka budeme označovať MICA z anglického Most Informative Common Ancestor. Nájdenie najbližšieho spoločného predka je známy algoritmický problém, ktorému sa venovalo už viacero prác. Najlepšie riešenie (Harel, Tarjan [5]) pre nájdenie najbližšieho spoločného predka v stromovej štruktúre potrebuje čas O(n) na predspracovanie a potom vie ľubovolným dvom vrcholom v konštantnom čase nájsť odpoveď. Riešenie redukuje problém najbližšieho spoločného predka na problém nájdenia minimálneho prvku poľa medzi dvoma indexami. Zo stromovej štruktúry sa preorderovým čítaním vytvorí pole. V prípade stromov sú známe algoritmy, ktoré dokážú nájsť najnižšieho spoločného predka v konštantnom čase s predspracovaním v čase O(n). V prípade orientovaných acyklických grafov je však tento problém zložitejší. Všeobecný algoritmus využíva násobenie matíc a teda jeho zložitosť je aspoň O(n ) [9]. Hľadaniu najbližšieho spoločného predka v orientovanom acyklickom grafe sa venuje Czumaj [2], ktorý dosiahol zložitosť O(n ). Z dôvodu veľkej časovej náročnosti predvypočítavame najinformatívnejších spoločných predkov ako vstup do aplikácie. V našom prípade nás však bude zaujímať iba ich informačná hodnota a preto na uloženie použijeme binárny súbor, v ktorom budú uchované len tieto hodnoty v tabuľke. 3.3 Podobnosť v ontológii Resnik vo svojej práci použil výpovednú hodnotu na určenie podobnosti, a dosiahol zlepšenie očakávaného výsledku oproti dovtedy používajúcej metóde rátania hrán. Dva termíny považuje za tak podobné, koľko informácie zdieľajú. Ich zdieľaná výpovedná hodnota je pritom obsiahnutá v ich najinformatívnejšom spoločnom predkovi.

23 KAPITOLA 3. TEORETICKÁ ČASŤ 14 Na tento výsledok nadviazala Köhlerova práca [8], ktorá definuje podobnosť množiny príznakov a choroby ako priemernú podobnosť príznaku k chorobe, pričom podobnosť príznaku k chorobe je maximálna podobnosť príznaku a jednotlivých príznakov, ku ktorým je choroba anotovaná. Množinu príznakov zadaných lekárom budeme označovať písmenom Q (z anglického querry), a písmenom D budeme označovať množinu príznakov anotovaných k chorobe (disease). Definícia Podobnosť množiny Q ku množine D, označujeme sim(q D) z anglického similarity a je daná vzťahom: [ ] sim(q D) = avg max IC(MICA(t 1, t 2 )) t t 1 Q 2 D (3.2) Podľa definície dostaneme vyšší výsledok, keď pre každý zo zadaných termínov (z Q), bola nájdená dobrá zhoda. Táto definícia však neráta s tým, že ku chorobe môžu byť anotované aj iné termíny. Napríklad ak porovnávame Q s dvoma chorobami, pričom platí Q = D 1 a Q D 2, obidve vrátia rovnaký výsledok. Tento nedostatok odstránime definovaním symetrickej podobnosti nasledovne: Definícia Symetrická podobnosť množín Q a D je číslo sim(d Q) = 1 2 sim(q D) + 1 sim(d Q) (3.3) 2 Pomocou takto definovanej podobnosti avšak stále nevieme pre daný dotaz určiť, ktorá choroba je pravdepodobnejšia. Je to zapríčinené tým, že rozsah podobností, ktoré je choroba schopná nadobudnúť sa líši od choroby k chorobe. Pre jednu chorobu môže byť teda významné aj z celkového pohľadu pomerne nízke skóre podobnosti. Skoutočná podobnosť závisí od množstva faktorov, napríklad aj od počtu príznakov v dotaze alebo počtu príznakov, ku ktorým je choroba anotovaná. Nie je preto možné povedať aký výsledok podobnosti vlastne znamená dobrú zhodu. Z týchto dôvodov nie je možné stopercentne určiť chorobu k daným príznakom, odhliadnúc od toho, že samotný používateľ môže zadať príznaky

24 KAPITOLA 3. TEORETICKÁ ČASŤ 15 nepresne. Tento modul teda nemá za cieľ určiť pacientovu diagnózu, ale ponúknuť lekárovi pravdepodobnostné ohodnotenie chorôb, z ktorých si môže vybrať, čo mu môže dopomôcť pri určovaní ďalšieho postupu pri diagnostike pacienta. Napríklad môže zistiť, že je potrebné nejeké neštandardné vyšetrenie. 3.4 Pravdepodobnostné ohodnotenie Köhler preto vo svojej práci zahrnul aj štatistický model založený na distribúcii vypočítaných podobností pre dotazy, ktoré obsahujú náhodné príznaky. Náhodne príznaky dosahujú oproti reálnym príznakom danej choroby nižšie skóre a pokiaľ je nejaké skóre dosahované iba zriedkavo, pripisuje mu väčšia dôležitosť. Pre každý dotaz určí pravdepodobnostnú hodnotu (p value), ktorá určuje pravdepodobnosť, že daná choroba získa rovnaké alebo väčšie skóre s náhodným dotazom. Hodnotu p value určuje pomocou metódy Monte- Carlo, teda generovaním množstva náhodných dotazov, z ktorých výslednych podobností určí pravdepodobnosť. Keďže podľa vzťahov 3.2 a 3.3 je podobnosť založená na priemernej podobnosti termínu z dotazu, tak dosiahnutie nejakého skóre podobnosti pri dotaze s dvoma termínmi je rôzne od skóre podobnosti dosiahnutého pri dotaze s iným počtom termínov. To znamená že hodnoty p treba počítať pre každú možnú veľkosť dotazu zvlášť. To však nie je časovo zrealizovateľné, pretože počet všetkých možných dotazov rastie exponenciálne s veľkosťou dotazu. Preto využíva metódu Monte-Carlo, a aproximuje distribúciu podobnosti vypočítaním náhodných dotazov pre každú chorobu. Tento výpočet opakuje pre každú veľkosť dotazu od 1 po 10 a vypočítané hodnoty uloží na disk. Pri zisťovaní p hodnoty pre dotazy obsahujúce viac ako 10 termínov používa hodnoty predpočítané pre 10. V našom programe využijeme tento prístup v obmedzenejšej forme. Vypočítané hodnoty totiž zaberajú veľa miesta na disku, a aj samotný výpočet trvá pomerne dlho. Pre každú chorobu a veľkosť dotazu od 1 do 10, vypočítavame 1000 náhodných dotazov, ktorých podobnosti uložíme zoradené

25 KAPITOLA 3. TEORETICKÁ ČASŤ 16 do binárneho súboru. Kvôli lepšej reprezentácii sú hodnoty vynásobené 1000 a zaokrúhlené na celé číslo smerom nadol. Keďže maximálna podobnosť je okolo 9, na zápis jedného takto upraveného skóre nám postačia 2 bajty. Binárny súbor predpočítaných podobností pre jednu chorobu teda bude zaberať 20KB. Celkovo máme vyše 8000 chorôb, teda všetky súbory nám budú zaberať vyše 160MB. Pri určovaní pravdepodobnostnej hodnoty p dotazu k chorobe postupujeme nasledovne. Vypočítame podobnosť dotazu k chorobe, následne v súbore pre danú chorobu nájdeme kategóriu predvypočítaných hodnôt podľa veľkosti dotazu. V danej kategórii máme hodnoty uložené v usporiadanom poradí a preto na nájdenie pozície od ktorej sú všetky hodnoty väčšie ako podobnosť dotazu, využijeme binárne vyhľadávanie. Pomocou tejto pozície určíme hodnotu p nasledovne p = N n (3.4) N kde n je vyhľadaná pozícia a N celkový počet vygenerovaných náhodných dotazov s ktorými porovnávame, teda v našom prípade 1000.

26 Kapitola 4 Implementačné detaily 4.1 Databáza Databázu HPO potrebujeme mať vhodne uloženú, tak aby bola dostupná pre aplikáciu, ale zároveň skrytá pre používateľa. Keďže dáta v databáze sa nemenia príliš často a využíva sa z nich väčšina, najlepším riešením bude, ak bude databáza súčasťou programu. Využijeme na to takzvanú vloženú (embedded) databázu. Tieto databázy sú priamo súčasťou programu, nepotrebujú server a majú menšie nároky na procesor a pamäť. Výhodou tohoto riešenia oproti externej databáze je aj to, že aplikácia nemusí prenášať dáta cez sieť, čo v našom prípade prispeje k vyššej rýchlosti. Používateľ zároveň môže používať aplikáciu aj bez internetového pripojenia. Aby sme mohli pracovať s dátami z databázy, potrebujeme ich načítať (namapovať) do objektov. Proces mapovania javovských objektov na tabuľky a opačne sa nazýva objektovo-relačné mapovanie (ORM). K tomuto procesu existuje špecifikácia JPA (Java Persistence API), pomocou ktorej vieme mapovať, ukladať, čítať, aktualizovať dáta z relačných databáz do objektov a aj opačne. Konkrétna implementácia JPA, ktorú používame v našom programe, je EclipseLink. Na mapovanie sa využívajú perzistentné metadáta, v našom prípade sú metadáta definované pomocou anotácií priamo v Java triedach. Každá trieda, 17

27 KAPITOLA 4. IMPLEMENTAČNÉ @NamedQuery(name="Term.findAll", query="select t FROM Term t") public class Term implements Serializable { private static final long serialversionuid = private int private Double ic; private private String columndefinition="bit") private byte columndefinition="bit") private byte name="term2external_object", }, } ) private List<ExternalObject> externalobjects; Obr. 4.1: Príklad anotácií

28 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 19 ktorá má byť uchovaná v databáze, musí byť anotovaná ako javax.persistence. Entity. JPA mapuje tabuľky na triedy a dáta v tabuľkách na premenné podľa mena, preto by stačilo, aby tabuľky a ich stĺpce mali rovnaké mená, ako k nim prislúchajúce triedy a premenné. My však načítavame databázu zo súboru SQL, v ktorom sú už tabuľky pomenované, ale ich pomenovanie nedodržiava štandardy pomenovania tried a premenných jazyka Java. Preto používame atribút name tabuľky") stlpca"), na určeniu konkrétnej tabuľky respektíve stĺpca, a tie potom môžeme v programe premenovať tak aby spĺňali štandard. Medzi často používané anotácie ktoré slúžia na definovanie vzťahov medzi triedami. Konkrétne použitie anotácií znázorňuje zjednodušený úryvok kódu z našej práce na obrázku 4.1. Na obrázku je znázornená trieda Term, zodpovedajúca tabuľke term, ktorej ukážku sme uviedli na obrázku 2.2. pri premennej id hovorí, že táto hodnota je jedinečná pre každý riadok databázy a generuje sa automaticky. Pri reťazci acc nemusíme uviesť žiadnu anotáciu, pretože sa jedná o jednoduchú hodnotu patriacu len tejto triede a jej názov sa zhoduje s názvom stĺpca v tabuľke. Pri hodnote isroot sme použili anotáciu Column a jej atribút name, pretože sme túto premennú oproti názvu stĺpca tabuľky is_root premenovali, tak aby zodpovedala špecifikácii Java. Okrem toho sme v druhom atribúte columndefinition uviedli konkrétny typ o aký sa jedná, keďže v databáze by mohol byť uvedený pod rôznymi inými typmi. Pri nahrávaní SQL dumpu sme sa stretli s problémom kompatibility. SQL dump pochádza z databázy MySQL a využíva konštrukcie, ktoré nie sú kompatibilné s formátom SQLite. Z toho dôvodu bolo potrebné databázu premigrovať. Táto migrácia sa vykonáva v samostatnom programe, ktorého výstupom je SQLite databáza. Na migráciu využívame rovnaké technológie ako v hlavnej aplikácii, s tým rozdielom, že sa aplikácia navyše pripája na externú databázu MySQL. V prvom kroku migrácie chceme načítať obsah databázy do javovských tried a následne z týchto tried uložiť do databázy

29 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 20 SQLite. Na načítavanie a ukladanie sa používajú teda tie isté triedy. V tomto kroku by sme však radi do databázy pridali naše predvypočítané dáta, ako napríklad informačnú hodnotu príznakov (trieda term). Problém je v tom, že triedy pri načítavaní a ukladaní musia presne zodpovedať štruktúre tabuľky. Ak teda chceme rozšíriť triedu term o informačnú hodnotu, musíme pridať túto hodnotu aj do databázy MySQL. V prvom kroku teda rozšírime v MySQL tabuľku zodpovedajúcu triede term o nový stĺpec pre informačnú hodnotu, následne môžeme načítať celý obsah databázy do javovských tried. V ďaľšom kroku pre každý termín vypočítame jeho informačnú hodnotu a v poslednom kroku migrácie uložíme obsah tried do databázy SQLite. Databázu SQLite rozšírime ešte o tabuľku prepájajúcu choroby s génmi, ktoré sme načítali zo samostatného textového súboru. 4.2 Vkladanie závislostí Aplikácia využíva vkladanie závislostí (Dependency Injection). Závislosti sa vkladajú pomocou Okrem tejto anotácie môžeme využiť napríklad pri ktorej použití aplikácia nevyhlási chybu, ak sa anotovaný objekt nenájde. Objekty, na ktoré odkazujú závislosti, sa hľadajú v kontexte. Kontext sa vytvára pri spustení Eclipse aplikácie a ma štruktúru podobnú mape. Klúčom v kontexte je reťazec, vo väčšine prípadov využívame ako klúč plné meno triedy, ktoré sa používa štandardne. Pokiaľ chceme vložiť závislosť na objekt pomenovaný inak, potrebujeme pridať Na rozdiel od mapy má kontext aj stromovú štruktúru, ktorá zodpovedá hierarchii aplikácie. Uzly tejto štruktúry nazývame lokálne kontexty. Objekty sú vložené do tejto hierarchickej štruktúry, čo umožňuje aby jeden kľúč odkazoval na rôzne objekty. Objekty v kontexte sú uložené v pamäti a teda pri ukončení aplikácie je kontext zmazaný. Pri vkladaní závislosti sa objekt začína hladať v kontextovej štruktúre od lokálneho kontextu vkladajúcej časti. V prípade, že sa v tomto lokálnom

30 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 21 kontexte nenájde vhodný objekt na vloženie, postupuje sa v hierarchickej štruktúre ďalej smerom nahor. //LoadHpoJob.java public class LoadHpoJob extends Job{ public static final String TITLE = "Loading TreeNode t; HashMap<String, byte[]> map;... //DiagnosisPart.java IEclipseContext scontext = EclipseContextFactory.create(); scontext.set(treenode.class, t); LoadHpoJob job = ContextInjectionFactory.make(LoadHpoJob.class, context, scontext); Obr. 4.2: Príklad vytovrenia objektu spolu so statickým kontextom Ukážka kódu na obrázku 4.2 približuje použitie kontextu pri vytváraní objektov. Pri vytváraní objektu LoadHpoJob špeciálnu továreň, ktorá má ako triedu ktorá sa vytvára, kontext s ktorým sa má trieda vytvoriť a statický kontext. Statický kontext slúži na to, aby sme pri vytváraní objektu pomocou tejto továrne nemuseli pridávať potrebné objekty pre vytvorenie do kontextu. Napríklad v našom príklade objekt TreeNode nie je v kontexte, a ani ho tam nepotrebujeme a nechceme. Na tomto príklade je aj vidieť hierarchiu kontextu. Objekty sa hľadajú najprv v statickom kontexte čo je najšpecifickejší kontext. Ten však obsahuje iba objekt TreeNode, takže objekt HashMap sa následne hľadá v kontexte context. 4.3 Práca so súbormi Súbor, v ktorom sú uložené informáčné hodnoty najinformatívnejšieho spoločného predka je pomerne veľký, keďže príznakov máme v databáze uložených cez a pre každú dvojicu príznakov máme uloženú informačnú

31 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 22 hodnotu v 2 bajtoch. Celková veľkosť súboru je teda cez 242 MB. Takto veľký súbor, z ktorého potrebujeme len zopár hodnôt, sa neoplatí načítavať celý do operačnej pamäte. Preto použijeme na načítanie potrebných hodnôt takzvaný RandomAccessFile, ktorý vie čítať zo zadanej pozície. Hodnoty sú uložené v tabuľke, do ktorej indexujeme podľa id príznaku, pričom v samotnom súbore nie sú použité žiadne oddeľovacie znaky medzi hodnotami ani riadkami. Pre dva príznaky s identifikátormi 40 a 117, nájdeme teda pozíciu, z ktorej prečítame ich podobnosť ako ( ) 2. Následne nám stačí z danej pozície v súbore prečítať 2 bajty, ktoré udávajú podobnosť týchto termínov. Podobnosť dotazu ku chorobe sa teda v samotnom programe počíta rovnako, ako sme uvádzali v definícii Súbory predpočítaných podobností však na začiatku načítame do pamäte, a v pamäti následne binárne vyhľadáme pozíciu. Robíme tak preto, pretože do týchto súborov pristupujeme častejšie a ušetríme tak čas potrebný na ich opätovné otváranie a prácu s nimi. 4.4 Aktualizácie Databáza HPO je v nepravidelných intervaloch aktualizovaná a preto je potrebné do aplikácie naprogramovať mechanizmus, ktorý ju umožní používateľovi zaktualizovať. Na tento účel sme sa rozhodli použiť inštalačný a aktualizačný mechanizmus Eclipse p2. Tento mechanizmus umožňuje aktualizovať celú aplikáciu, alebo aj len určitú funkcionalitu. Pri vydaní novej verzie programu musí programátor pri exportovaní z Eclipse zaškrtnúť "Generate p2 repository", čo zabezpečí vygenerovanie aktualizačného adresára. Následne je potrebné tento adresár nahrať na server. Pre správne fungovanie je potrebné v súbore popisujúcom funkcionalitu alebo aplikáciu zvýšiť číslo verzie. Podľa tohto čísla sa určuje, či je potrebné stiahnuť nové aktualizácie. Pri aktualizovaní sa totiž aplikácia používateľa pripojí na server a hľadá aktualizácie s vyšším číslom verzie ako obsahuje ona, pokiaľ

32 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 23 také nenájde, oznámi používateľovi, že nie sú dostupné nové aktualizácie. 4.5 Udalosti Vzhľadom na to že aplikácia je rozdelená do viacero častí, vyskytuje sa pri programovaní nejakej časti potreba upozorniť inú časť na vykonané zmeny. Konkrétne v našom programe napríklad chceme, aby po označení príznaku alebo choroby, sa v časti Info zobrazili podrobnejšie informácie. Toto docielime použitím takzvaných udalostí (Events), ktoré sa používajú pomocou služby IEventBroker. Táto služba umožňuje registrovanie a posielanie udalostí v celej aplikácii. Udalosti môžeme posielať asynchrónne pomocou metódy post, alebo synchrónne pomcou metódy send, pri ktorej volajúci blok programu čaká na vykonanie metód registrovaných k tejto udalosti. Udalosti sa posielajú s dvoma parametrami. Prvým parametrom je téma udalosti vo forme reťazca a druhým je objekt. Na udalosť sa registruje metódou, ktorá má jediný parameter objekt rovnakého typu ako bol poslaný. Tento objekt je navyše označený špeciálnou s témou udalosti na ktorú je metóda registrovaná. //DiseaseTableViewer.java eventbroker.send(eventconstants.data_info_change, public void setinfo(@uieventtopic(eventconstants.data_info_change) String text) { infotext.settext(text); } Obr. 4.3: Príklad volania a registrovania udalosti Zjednodušený príklad použitia udalosti je na obrázku 4.3. Prvý riadok reprezentuje poslanie udalosti s témou a reťazcom, v druhej ukážke je metóda registrovaná k tejto udalosti.

33 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY Práce V aplikácii Eclipse RCP bežia procesy v jednom hlavnom vlákne, ktoré ako jediné umožňuje interakciu s používateľským rozhraním. To znamená, že pri dlhších vypočtoch je používateľské rozhranie blokované a musí čakať na ich dokončenie. Preto je dobré časovo náročné operácie, ako čítania zo súboru alebo databázy, spúštať v samostatnom vlákne. Pre prácu s vláknami využíva aplikácia framework Eclipse Jobs. Jeho základna trieda Job (práca) vie menežovať vlákno, poskytuje informácie o postupe práce a umožňuje vláknam nastaviť prioritu. Medzi ďalšie možnosti tejto triedy patrí možnosť vlákna zastaviť a opätovne spustiť. Na zobrazenie postupu práce používame tridu IProgressMonitor. Pri začatí práce spustíme monitor pomocou metódy begintask, ktorá má dva parametre. Prvým je meno práce, ktoré sa zobrazí používateľovi a druhým je celkový počet jednotiek práce. Pri niektorých prácach nevieme dopredu povedať celkový počet a rozdelenie na jednotky, preto využijeme možnosť nastavenia maximálnej práce na špeciálnu hodnotu IProgressMonitor.UNKNOWN. Po vykonaní časti práce zavoláme jeho metódu worked, ktorá má jediný parameter počet jednotiek vykonanej práce. Pre podrobnejšie informácie o aktuálnom stave práce ju môžeme rozdeliť na podúlohy. Podúlohy slúžia na vypísanie aktuálne vykonávanej časti práce používateľovi. Konkrétne napríklad v našom programe počítame podobnosť dotazu ku každej chorobe. Prácu teda máme rozdelenú na podúlohy, pre každú chorobu jednu, a používateľovi vieme zobraziť na ktorej chorobe sa aktuálne počíta podobnosť. 4.7 Filtre Aplikácia používa na zobrazenie variantu framework NatTable, ktorý je vhodný pre zobrazovanie veľkého množstva dát, pretože načítanie dát prebieha na vyžiadanie. NatTable podporuje knižnicu GlazedList, ktorá uľahčuje prácu s dátami. GlazedList používa na pridávanie novej funkcionality vrstvy. Zá-

34 KAPITOLA 4. IMPLEMENTAČNÉ DETAILY 25 kladnou vrstvou je vrstva EventList, nad ktorú sa pridávajú ďalšie vrstvy, ako napríklad FilterList. Kedže táto tabuľka s potrebnými vrstvami je už vytvorená, stačí nám vytvoriť filter. Avšak pomocou takéhoto filtra je obsah filtrovaný staticky, teda nevieme zmeniť filtrovacie kritérium. Na to aby sme docielili dynamické filtrovanie použijeme rozhranie MatcherEditor, ktoré sa postará o to, aby sa poslali udalosti pri zmene filtrovacieho kritéria. Pri zvolení choroby najprv zistíme, ku ktorím génom sa viaže. Pre každý gén následne vytvoríme vlastný filter na základe stĺpca ktorý obsahuje génový identifikátor (GI). Tieto filtre sú obalené skupinovým filtrom, ktorý má zvolenú stratégiu OR. Pri tejto stratégií stačí, aby riadok spĺňal podmienky aspoň jedného filtra zo zoznamu.

35 Kapitola 5 Používateľské rozhranie Používateľske rozhranie nášho modulu sa skladá z viacerých častí. Základnou časťou je part, v ktorom si používateľ vykliká pozorované príznaky. Tento part je je zobrazený na obrázku 5.1 na ľavej strane. Príznaky sú prezentované v stromovej štruktúre, kliknutím na príznak, ktorý má špecifickejších synov sa rozbalia synovia. V strome existujú dve hodnoty označenia, checked a grayed. Políčka označené checked sú políčka, ktoré vybral používateľ a berú sa do úvahy pri ďalšom spracovávaní. Políčka typu grayed slúžia výlučne na uľahčenie označovania a hľadania označených položiek v rámci stromu a pri ďalšom spracovaní sa neberú do úvahy. Pre označenie príznaku je potrebné zaškrtnúť jemu patriace políčko, pričom sa označia aj políčka všetkých rodičov na hodnotu grayed. V prípade, že používateľ odznačí políčko, odznačia sa aj jeho rodičia, pokiaľ to bol ich posledný označený syn. Používateľ sa môže rozhodnúť odznačiť aj políčko typu grayed, čo má za následok odznačenie všetkých jeho synov. Táto funkcia sa dá tým pádom jednoducho využiť na odznačenie všetkých označených polí, kedy stačí odznačiť koreň stromu. Po označení všetkých želaných príznakov používateľ klikne na tlačítko "Get diagnosis", pre zobrazenie ohodnoteného a zoradeného zoznamu chorôb podľa hodnoty p. Tento krok trvá bohužiaľ dlho pri prvom spustení, čo je zapríčinené potrebou načítať dáta o príznakoch a chorobách z databázy. Pri zmene príznakov a ďalších volaniach však už sú tieto dáta načítané a výpočet 26

36 KAPITOLA 5. POUŽÍVATEĽSKÉ ROZHRANIE 27 Obr. 5.1: Používateľské rozhranie - príznaky trvá podstatne kratšie. Tabuľka chorôb je zobrazená v samostatnom parte, ktorý je zobrazený na obrázku 5.2 na ľavej strane. Niektoré názvy chorôb sú veľmi dlhé, pretože často obsahujú okrem holého názvu aj iné informácie. Z tohoto dôvodu pri označení choroby sa zobrazí jej celý názov aj v časti Info, ktorú je možné vidieť na obrázku 5.2 vľavo dole. Pre označenie choroby je potrebné podobne ako pri príznakoch, zaškrtnúť prislúchajúce políčko pri nej. Ihneď po označení sa podľa génov, ku ktorým je daná choroba asociovaná, vyfiltrujú prislúchajúce riadky v aktuálne otvorenom pacientovom variante. Pri označení viacerých chorôb sa zobrazujú riadky prislúchajúce k aspoň jednej chorobe. Zároveň má používateľ možnosť otvoriť si časť prehliadača (browser), v ktorom sa mu zobrazujú prídavne informácie o chorobe. Pre otvorenie prehliadača treba kliknúť v menu na View a následne zvoliť položku Disease browser. Prehliadač sa otvorí v pravej časti, je zobrazený na obrázku 5.2. V prehliadači sa zobrazuje webová stránka, ktorá prislúcha danej chorobe,

37 KAPITOLA 5. POUŽÍVATEĽSKÉ ROZHRANIE 28 Obr. 5.2: Používateľské rozhranie - choroby podľa toho, z ktorej databázy pochádza. Každá choroba má totiž v rámci HPO uvedené identifikačné číslo a databázu, z ktorej pochádza. Pre každú chorobu sa teda podľa jej identifikátora a databázy zobrazí v prehliadači príslušná stránka.

38 Záver Cieľom tejto práce bolo rozšíriť aplikáciu Variant Annotation Analyzer o modul, ktorý umožňuje používateľovi vyfiltrovať významné záznamy z pacientovho variantu podľa zvoleneých chorôb. K dosiahnutiu tohoto cieľa bolo potrebné vykonať niekoľko krokov. V prvom rade sme sa museli oboznámiť s vývojovým prostredím Eclipse RCP a ďalšími techonológiami, ktoré boli použité pri tvorbe VAA aplikácie. Následne sme museli vhodne integrovať databázu HPO a vybrať vhodné algoritmy na jej spracovanie. Pri implementácií týchto krokov sa niekoľkokrát ukázalo prvotné riešenie ako nevyhovujúco pomalé, avšak niektoré kroky výpočtov sa už nedali zrýchliť. Preto sme zvolili cestu predvypočítania týchto krokov v samostatných programoch a ich výstupy sme zaradili ako vstupné do hlavnej aplikácie. Cieľ práce sa nám podarilo naplniť. Aplikácia dokáže vyfiltrovať pacientov variant podľa konkrétneho vstupu od používateľa. Ďalej umožňuje aplikácia používateľovi zobraziť podrobnejšie informácie o chorobách z webových zdrojov a aktualizovať aplikáciu. Okrem samotného modulu vzniklo popri tejto práci viacero samostatných programov, ktoré majú za úloho predspracovať vstup z exterých zdrojov do podoby použiteľnej v aplikácii. Tieto programy slúžia hlavne pre prográmatora a ich výstupy sa k používateľovi môžu dostať práve pomocou aktualizácií. Ďalšie možnosti rozšírenia aplikácie by sme mohli rozdeliť do dvoch kategórií. Obsahovou možnosťou rozšírenia je napríklad použitie zvieracích ontológií. V súčasnosti sú dostupné ontológie genetických chorôb u niektorých druhov cicavcov (napríklad myší) [11]. 29

39 KAPITOLA 5. POUŽÍVATEĽSKÉ ROZHRANIE 30 K programátorským možnostiam rozšírenia patrí úprava používateľského rozhrania a zrýchlenie načítavania množstva dát z databázy.

40 Literatúra [1] The human phenotype ontology. [Citované ] Dostupné z [2] Artur Czumaj and Andrzej Lingas. Improved algorithms for the all-pairs lowest common ancestor problem in directed acyclic graphs. [3] Jaroslav Budiš et al. Variant annotation analyser, [Citované ] Dostupné z [4] Ada Hamosh, Alan F Scott, Joanna S Amberger, Carol A Bocchini, and Victor A McKusick. Online mendelian inheritance in man (omim), a knowledgebase of human genes and genetic disorders. Nucleic acids research, 33(suppl 1):D514 D517, [5] Dov Harel and Robert Endre Tarjan. Fast algorithms for finding nearest common ancestors. SIAM Journal on Computing, 13(2): , [6] Rastislav Hekel. Modulárny vývoj aplikácií v prostredí eclipse rcp. Bakalárska práca, Univerzita Komenského v Bratislave, [7] Sebastian Köhler, Sandra C Doelken, Christopher J Mungall, Sebastian Bauer, Helen V Firth, Isabelle Bailleul-Forestier, Graeme CM Black, Danielle L Brown, Michael Brudno, Jennifer Campbell, et al. The human phenotype ontology project: linking molecular biology and disease through phenotype data. Nucleic acids research, 42(D1):D966 D974,

41 LITERATÚRA 32 [8] Sebastian Köhler, Marcel H Schulz, Peter Krawitz, Sebastian Bauer, Sandra Dölken, Claus E Ott, Christine Mundlos, Denise Horn, Stefan Mundlos, and Peter N Robinson. Clinical diagnostics in human genetics with semantic similarity searches in ontologies. The American Journal of Human Genetics, 85(4): , [9] Miroslaw Kowaluk and Andrzej Lingas. Lca queries in directed acyclic graphs. In International Colloquium on Automata, Languages, and Programming, pages Springer, [10] Philip Resnik. Using information content to evaluate semantic similarity in a taxonomy. arxiv preprint cmp-lg/ , [11] Cynthia L Smith and Janan T Eppig. The mammalian phenotype ontology: enabling robust annotation and comparative analysis. Wiley Interdisciplinary Reviews: Systems Biology and Medicine, 1(3): , [12] Lars Vogel and Mike Milinkovich. Eclipse 4 RCP: The complete guide to Eclipse application development. vogella series, [13] J. Wynbrandt and M.D. Ludman. The Encyclopedia of Genetic Disorders and Birth Defects. Facts on File Library of Health & Living. Facts On File, Incorporated, 2010.