thesis - Institut für Informatik

Leopold-Franzens-Universität Innsbruck
Institut für Informatik
Datenbanken und Informationssysteme
WorkflowManager - Entwicklung einer
Java-basierten Weboberfläche zur Verwaltung
von genetischen Analysen
Bachelor-Arbeit
Mathias Neuner
betreut von
Dipl.-Ing. Sebastian Schönherr
Mag. Stefan Coassin
Innsbruck, 18. Februar 2010
Zusammenfassung
Ziel dieser Arbeit ist die Erstellung einer Java-basierten Webapplikation
zur Verwaltung und Aufbereitung von DNA Proben, die im Rahmen von
Studien an der Sektion für Genetische Epidemiologie an der Medizinischen Universität Innsbruck erfasst werden.
Die Webapplikation bietet die Möglichkeit unterschiedliche medizinische
Studien zu verwalten und ermöglicht es erstmals den kompletten Arbeitsablauf eines Labors effizient auszuführen. Durch verschiedene Exportmöglichkeiten verringert sich der Aufwand zur Weiterverarbeitung
der Proben durch diverse DNA Roboter drastisch. Anhand des simplen
Aufbaus der Benutzeroberfläche, die sich an den bisherigen Workflow
der Mitarbeiter orientiert, kann der Benutzer ohne aufwendiger Einschulung die Applikation verwenden. Da die Webapplikation auf jedem PC
im Netzwerk erreichbar ist und an eine zentrale Datenbank angebunden
ist, kann von jedem Arbeitsplatz aus auf die Studien bzw. Proben zugegriffen werden. Für die Labormitarbeiter wird die Verarbeitung und
Aufbereitung der Proben dadurch um ein vielfaches Mass erleichtert, da
keine manuellen Kopieroperationen und Dateiverwaltung mehr durchgeführt werden müssen.
Abstract
The aim of this bachelor project is to develop a Java based webapplication for processing and preparing DNA samples, which are captured at
the Division of Genetic Epidemiology at the University of Innsbruck.
The web application offers the possibility to manage a variety of medical studies and makes it the first time possible, to perform efficiently
the complete workflow of a Laboratories. Through various export opportunities the effort for processing samples by various DNA robots is
minimized. The simplicity of the User interface, which is oriented on
the basis of the previous workflow of the employees, the user does not
need a special enrollment for the application. Since the webapplication
is reachable on any PC in the network and is connected to a central
database, studies and samples can be accessed from any workstation.
For the laboratory staff the processing and preparation of samples is to
a considerably degree easier, since no manual file copy operations and
administration is needed any more.
Inhaltsverzeichnis
1 Einleitung
1
2 Anforderungen und Ziele
3
3 Technologien
3.1 Java . . . . . .
3.2 Java Servlets .
3.3 Hibernate . . .
3.4 MySQL . . . .
3.5 Apache Tomcat
3.6 ExtJS . . . . .
.
.
.
.
.
.
7
7
7
8
9
9
9
.
.
.
.
.
.
.
.
13
13
15
15
16
17
17
17
19
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Implementierung
4.1 Relationales Datenbankmodell . . .
4.2 Serverarchitektur . . . . . . . . . . .
4.2.1 MVC Pattern . . . . . . . . .
4.2.2 Projektstruktur . . . . . . . .
4.2.3 O/R Mapping mit Hibernate
4.2.4 Businesslogik . . . . . . . . .
4.2.5 Servlets . . . . . . . . . . . .
4.3 Grafische Benutzeroberfläche . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5 Installation
21
5.1 Datenbankinstallation . . . . . . . . . . . . . . . . . . . . 21
5.2 Java Installation . . . . . . . . . . . . . . . . . . . . . . . 22
5.3 Apache Tomcat Installation . . . . . . . . . . . . . . . . . 22
6 Zusammenfassung
25
Literaturverzeichnis
27
Appendix
29
A.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
A.2 Verwaltung von Studien . . . . . . . . . . . . . . . . . . . 29
III
INHALTSVERZEICHNIS
A.2.1 Studien Anlegen und Einspielen . . . . . .
A.2.2 Samples Importieren . . . . . . . . . . . .
A.2.3 Proben Importieren . . . . . . . . . . . .
A.2.4 Layouts Generieren . . . . . . . . . . . . .
A.2.5 Samplesheets Generieren . . . . . . . . . .
A.2.6 Samplesheets Generieren . . . . . . . . . .
A.3 Exportieren . . . . . . . . . . . . . . . . . . . . .
A.3.1 Roboter DNA Konzentration Exportieren
A.3.2 Layouts Exportieren . . . . . . . . . . . .
A.3.3 Samplesheets Exportieren . . . . . . . . .
A.4 QC Generierung . . . . . . . . . . . . . . . . . .
IV
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
29
31
31
32
32
32
32
34
34
34
34
Name1, Name2
Kapitel 1
Einleitung
An der Sektion für Genetische Epidemiologie der Medizinischen Universität Innsbruck werden in den Labors laufend DNA Proben analysiert
und ausgewertet. Im Rahmen von Studien wird versucht anhand der Proben Rückschlüße auf bestimmte Krankheiten wie zum Beispiel Diabetes
zu erzielen. Für diese Studien werden tausende DNA Proben von Patienten zusammengetragen. Durch die Anzahl mehrerer Studien ergibt
sich dadurch eine beträchtliche Menge an Daten. Um eine Übersicht aller
Proben zu erhalten, werden die Proben mittels Sample IDs gekennzeichnet und dazugehöriger DNA Konzentration und Qualitätswert in Excel
Dateien abgelegt. Die Verarbeitung und Auswertung dieser Proben erfolgt computergesteuert und wird von speziellen Robotern durchgeführt.
Dazu werden die Proben in speziellen DNA Behältern, den sogenannten Plates, aufbereitet. Damit der Roboter die jeweilige Plattenbelegung
verarbeiten kann, wird eine zusätzliche Datei benötigt, die die genauen
Informationen der DNA Behälter beinhaltet.
Diese Dateien werden von den Labormitarbeitern momentan manuell zusammengeführt und auf einem Fileserver innerhalb einer Ordnerstruktur
abgelegt, was bei großen Studien einen beträchtlichen Aufwand zur Folge hat. Es ist daher kein Automatismus vorhanden, der alle Daten einer
Studie zentral verwaltet und aufbereitet. Dadurch ergeben sich natürlich
potentielle Fehlerquellen, die beim Zusammenstellen einer Studie Folgen
auf die weitere Verarbeitung haben kann. Dieser fehlende Automatismus
soll durch eine Webapplikation behoben werden, die den beschriebenen
Workflow unterstützt und weiters die Handhabung der verschiedenen
Dateien bzw. Dateiformate erleichtert. Durch die Erreichbarkeit der Anwendung über einen beliebigen Webbrowser wird keine separate Installation auf dem jeweiligen Rechner der Labormitarbeiter benötigt.
In dieser Arbeit wird die Konzeption und Implementierung der We1
KAPITEL 1. EINLEITUNG
bapplikation vorgestellt und setzt sich aus folgenden Kapitel zusammen:
In Kapitel 2 werden die konkreten Anforderungen erläutert, die an die
Applikation gestellt wurden. Kapitel 3 beschreibt die für die Umsetzung
benötigten Technologien. In Kapitel 4 werden die einzelnen Stufen der
Implementierungsphase genauer beschrieben und vorgestellt. Kapitel 5
befasst sich mit der Installation der Webapplikation auf einem Server
und der Einrichtung der Datenbank. In Kapitel 6 wird in einer Zusammenfassung über die Arbeit resümiert.
2
Name1, Name2
Kapitel 2
Anforderungen und Ziele
In diesem Kapitel werden alle Anforderungen, die an die Webapplikation
gestellt wurden, näher erläutert. Grundsätzlich soll die Anwendung die
unter Kapitel 1 beschriebenen Abläufe unterstützen und den Aufwand
der Labormitarbeiter an der Sektion für Genetische Epidemiologie der
Medizinischen Universität Innsbruck minimieren. Zusätzlich sollen die
erfassten Daten der Studien in einer Datenbank erfasst und gespeichert
werden und nicht wie bisher in Excel Dateien abgespeichert werden. In
weiterer Folge werden die wichtigsten Anforderungen im Detail beschrieben.
Rechtemanagement
Damit nicht jeder Benutzer, der über einen Webbrowser auf die Applikation zugreift, alle Studien einsehen und bearbeiten kann, ist eine
Benutzerauthentifizierung erforderlich. Erst nach erfolgreichem Login
sollen dem Benutzer alle Studien angezeigt werden. Damit neue und bestehende Mitarbeiter als Anwendungsbenutzer angelegt werden können,
müssen Benutzer im System angelegt, bearbeitet und gelöscht werden
können.
Import bestehender Studien
Bestehende und fertig zusammengestellte Studien sollen ebenfalls über
die neue Applikation einsehbar und verwaltbar sein. Daher wird eine Importfunktionalität von bestehenden Studien benötigt. Die Daten einer
bestehenden Studie werden in einer Archivierungsdatei (ZIP) zusammengefasst. Innerhalb dieser ZIP Datei besteht für jedes vorhandene
Layout eine CSV Datei. Der Dateiname der ZIP Datei kann beliebig
sein, was allerdings nicht auf den Namen der CSV Dateien zutrifft. Dieser muss sich aus dem Namen der Studie und der Layout Nummer,
getrennt durch einen Bindestrich, zusammensetzen. Die CSV Datei besteht aus einer Spalte mit der Position, einer Spalte für die Sample ID
3
KAPITEL 2. ANFORDERUNGEN UND ZIELE
und einer Spalte für eine DNA Konzentration, die optional ist. Dadurch
sollen alle bestehenden Sample IDs und die manuell zusammengestellten
Layouts im System vorhanden sein.
Anlegen neuer Studien
Für neue Studien ist immer eine dazugehörige Liste mit Sample IDs vorhanden, die in einer Textdatei gespeichert ist. Das Anlegen einer Studie
soll daher mit dem gleichzeitigen Einspielen der Sample IDs erfolgen.
Zur Studie selbst sollen noch folgende Daten gespeichert werden können,
die beim Anlegen angegeben werden: Name, Identifikationsnummer, Beschreibung und die Positionen der NTCs (Non Template Controls - sogenannte Negativproben). Wobei die Angabe der NTCs in Form von
Koordinaten angegeben werden müssen (z.B.: B3 G11).
Import von Konzentrationswerten
Da beim Anlegen einer Studie noch keine Konzentrationswerte angegeben bzw. vorhanden sind, sollen diese Werte, die entweder in einer CSV
oder TSV Datei vorliegen, nachträglich eingespielt werden können. Ist
ein Wert beim Import schon in der Datenbank vorhanden, wird dieser
überschrieben.
Darstellung der Layouts bzw. Samplesheets
Ein Layout repräsentiert die Darstellung von 96 Sample IDs, die in Form
eines Koordinatensystems angeordnet werden. Hierbei wird für die xAchse von 1-12 und für die y-Achse von A-H buchstabiert. Samplesheets sind größere DNA Behälter, die aus 384 Sample IDs bestehen und
sich jeweils aus 4 Layouts zusammensetzen, wodurch sich ein dementsprechendes größeres Koordinatensystem ergibt. Die generierten Layouts
bzw. Samplesheets sollen in einer tabellarischen Form optisch dargestellt
werden. In dieser Ansicht soll es auch möglich sein, die Anordnung der
Sample IDs zu bearbeiten. Ebenfalls soll ein Benutzer sich ein Layout
selbst zusammenstellen können.
Exportfunktion
Damit die Studien von diversen Gerätetypen bzw. Robotern weiterverarbeitet werden kann, wird eine Exportfunktion benötigt. Der Export
sollte für eine gesamte Studie in einer ZIP Datei zusammengefasst werden, die pro Layout bzw. Samplesheet eine CSV Datei im jeweiligen
benötigten Format enthält.
Nachträgliches Bearbeiten von Proben
Da Proben sich im Nachhinein als fehlerhaft herausstellen können, ist es
notwendig eine Probe dementsprechend zu markieren bzw. den Konzentrationswert oder den Qualitätswert zu bearbeiten. Es wird daher eine
4
Name1, Name2
KAPITEL 2. ANFORDERUNGEN UND ZIELE
Auflistung der Sample IDs benötigt, um die dementsprechende Probe zu
manipulieren.
Qualitätssicherung
Für die Qualitätssicherung der Studien, werden sogenannte Quality Control (QC) Layouts bzw. Samplesheets benötigt. Diese Layouts bzw. Samplesheets sollen im Grunde aus einer Schnittmenge von Sample IDs einer
gesamten Studie bestehen. Der Labormitarbeiter soll dabei bestimmte
Positionen eines Layouts angeben können über welche dann die entsprechenden Sample IDs ermittelt und wiederum in separate Layouts abgelegt werden. Um einen Überblick über die Schnittmenge zu erhalten,
sollte es für den Labormitarbeiter möglich sein, sich den prozentualen
Anteil aller Sample IDs anzeigen zu lassen zu können.
Berücksichtigung von NTC und fehlerhaften Proben
Pro Studie gibt es fix definierte NTC Positionen. An diesen Positionen
dürfen keine Sample IDs positioniert sein. Dementsprechend muss diese
Position ausgelassen und als NTC Position dargestellt werden. Ist ein
Sample als fehlerhaft deklariert, soll dies ebenfalls visuell als Fehler erkennbar sein.
Abbildung 2.1 stellt noch einmal einen Überblick über die Grundfunktionalitäten der Webaplikation dar.
Name1, Name2
5
KAPITEL 2. ANFORDERUNGEN UND ZIELE
Abbildung 2.1: Übersicht der Funktionalitäten
6
Name1, Name2
Kapitel 3
Technologien
Im folgenden Kapitel werden Softwaretechnologien vorgestellt, die in
der Umsetzung der Anforderungen verwendet bzw. benötigt wurden. Es
handelt sich bei allen Technologien um Open Source Software.
3.1
Java
Java1 ist eine objektorientierte Programmiersprache der Firma Sun Microsystems. Java-Programme werden in Bytecode übersetzt und dann in
einer speziellen Umgebung ausgeführt, die als Java-Laufzeitumgebung
oder Java-Plattform bezeichnet wird. Deren wichtigster Bestandteil ist
die Java Virtual Machine (Java-VM), die die Programme ausführt, indem sie den Bytecode interpretiert und bei Bedarf kompiliert (HotspotOptimierung). Java-Programme sind plattformunabhängig, was bedeutet dass sie in aller Regel ohne weitere Anpassungen auf verschiedenen Computern und Betriebssystemen, für die eine Java-VM existiert,
lauffähig sind. Sun selbst bietet Java-VMs für die Betriebssysteme Linux,
Solaris und Windows an. In dieser Bakkalaureatsarbeit wird sowohl zur
Entwicklung als auch im Einsatz am Produktivsystem die Java Version
6 Update 7 verwendet.
3.2
Java Servlets
Als Servlets werden Java Klassen bezeichnet, deren Instanzen innerhalb eines Java Webservers Anfragen von Clients entgegen nehmen und
beantworten. Weiterhin sind sie fester Bestandteil aller Java EE Anwendungsserver. Die Servletkomponenten müssen die Schnittstelle javax.servlet.Servlet oder eine davon abgeleitete implementieren. Normalerweise wird eine Klasse erstellt, die von der Klasse HttpServlet abgelei1
http://www.java.com
7
KAPITEL 3. TECHNOLOGIEN
tet wird, die wiederum Servlet implementiert. Der Inhalt der Antworten
kann dabei dynamisch, also im Moment der Anfrage, erstellt werden
und muss nicht bereits statisch (etwa in Form einer HTML-Seite) für
den Webserver verfügbar sein. Ein HttpServlet muss immer die Methoden GET und POST implementieren. Das Klientenprogram (in den
meisten Fällen ein Internetbrowser) verwendet nämlich für einen Server
Request die Methode GET oder POST. Bei einem GET Aufruf werden
die Parameter Wertepaare durch das Zeichen "?" in der URL angeführt.
Diese Aufruf wird meistens verwendet, um eine Liste von Parametern
zu übertragen, die die Gegenstelle bei der Bearbeitung einer Anfrage
berücksichtigen soll. Bei einem POST Aufruf befinden sich die Daten
nicht in der URL, daher können über diese Methode große Datenmengen
wie zum Beispiel Bilder oder Dateien übertragen werden. Die Variablen
stehen anstatt in der URL im Body Teil des Requests. Die HttpServlet
Methoden verfügen als Parameter jeweils einen HttpServletRequest und
einen HttpSerlvetResponse. Aus dem HttpServletRequest können die
Parameter bzw. die Wertepaare, die vom Klientenprogramm übermittelt
wurden ausgelesen werden. Der HttpServletRsponse wird verwendet um
dem Aufrufer zu "antworten". Mit Hilfe eines OutputStreams können
Texte als auch Dateien dem Aufrufer zurückgesendet werden.
3.3
Hibernate
Hibernate2 ist ein Open-Source-Persistenz- und ORM-Framework für
Java. Hibernates Hauptaufgabe ist das Object Relational Mapping (OR-Mapping, kurz ORM). Es ermöglicht, gewöhnliche Objekte mit Attributen und Methoden (im Java-Bereich POJOs genannt) in relationalen Datenbanken zu speichern und aus entsprechenden Datensätzen
wiederum Objekte zu erzeugen. Beziehungen zwischen Objekten werden
auf entsprechende Datenbankrelationen abgebildet. Darüber hinaus bietet Hibernate Mechanismen, um auf Datenbanken zugreifen zu können,
ohne diese Zugriffe explizit in SQL programmieren zu müssen. Dafür
generiert Hibernate, abhängig vom SQL-Dialekt der verwendeten Datenbank, die SQL Statements. Somit bleibt die Applikation selbst von
der gewählten Datenbank unabhängig. Anwendungsseitig kann Hibernate in Java Applikationen und Servlet Engines benutzt werden oder in
einen Applikationsserver integriert werden.
2
8
http://www.hibernate.org
Name1, Name2
KAPITEL 3. TECHNOLOGIEN
3.4
MySQL
Der MySQL3 Server ist ein relationales Datenbankverwaltungssystem.
Es ist als Open-Source-Software sowie als kommerzielle Enterpriseversion für verschiedene Betriebssysteme verfügbar und bildet die Grundlage für viele dynamische Webauftritte. Ursprünglich wurde MySQL Server vom schwedischen Unternehmen MySQL AB entwickelt. Im Februar
2008 wurde MySQL AB von Sun Microsystems übernommen, das nun
für die Weiterentwicklung des Codes verantwortlich ist. Aufgrund der
Tatsache, daß es MySQL auch als Open-Source-Software gibt, ist dieses
Datenbanksystem sehr verbreitet und findet sich selbst als Teil weiterer
Open Source Projekte wieder. MySQL lässt sich problemlos auf verschiedenen Betriebssystemen installieren. Mit Hilfe von frei verfügbaren
Adminstrationswerkzeugen (MySQL GUI Tools) kann die jeweilige Installation problemlos administriert und gewartet werden.
3.5
Apache Tomcat
Apache Tomcat4 stellt eine Umgebung zur Ausführung von Java-Code
auf Webservern bereit. Es handelt sich um einen in Java geschriebenen
Servlet-Container, der mithilfe des JSP-Compilers Jasper auch JavaServer Pages in Servlets übersetzen und ausführen kann. Zusätzlich wird mit
einer Tomcat Distribution noch ein kompletter HTTP-Server ausgeliefert. Vorläufer von Apache Tomcat wurden meist als Servlet- und/oder
JSP-Engine klassifiziert. Mit dem Erscheinen von Tomcat waren komfortablerweise beide Funktionalitäten in einem Produkt vereinigt. Tomcats
HTTP-Server wird vor allem zur Entwicklung eingesetzt, während in
Produktion zumeist ein Apache Web-Server vor den Tomcat eingesetzt
wird. Dazu wird in den Webserver ein Connector-Plugin eingebunden,
das Anfragen für dynamische Inhalte an Tomcat weiterleitet. Das Plugin
implementiert hierzu das Apache JServ Protocol (AJP).
3.6
ExtJS
ExtJS5 ist ein clientseitiges JavaScript- bzw. Ajax-Framework für interaktive Webanwendungen, das für Open-Source-Projekte unter der
freien GPL, für andere Projekte unter kommerziellen Lizenzen erhältlich ist. In erster Linie bietet ExtJS eine umfangreiche Sammlung von
Steuerelementen. Ursprünglich war Ext JS eine Sammlung von Funktionserweiterungen für die Yahoo User Interface Library (YUI) unter
3
http://www.mysql.com
http://tomcat.apache.org
5
http://www.extjs.com
4
Name1, Name2
9
KAPITEL 3. TECHNOLOGIEN
dem Namen yui-ext. Aufgrund wachsenden Umfangs und steigender Popularität entwickelte sich daraus die unabhängige Bibliothek Ext JS.
In der aktuellen Version 3.1 bietet Ext JS unter anderem JavaScriptErweiterungen und Klassen für Ajax-Unterstützung, zur Document Object Model-Manipulation sowie zur Ereignis-Programmierung. Die Javascript API von ExtJS verwendet JSON in der Implementierung. Durch
diese Notation ist diese Library in ein objektorientiertes Klassenkonstrukt aufgebaut. In der Programmierung mit ExtJS muss daher auch
JSON verwendet werden, was allerdings kein allzu großer Nachteil ist,
da die Klassenstruktur auch im eigenen Javascript Quellcode weiterverwendet werden kann. Einer der großen Vorteile dieser Klassenstruktur
ist die Möglichkeit der Vererbung. So känn zum Beispiel von einer ExtJS
GUI Komponente (Dialogfenster, Tabellen usw.) geerbt werden und mit
eigenen Verhaltensweisen bzw. Konfigurationen versehen werden. Diese
eigene Klasse kann nun beliebig in der eigenen Applikation wiederverwendet werden. Ein weiterer Vorteil sind auch die zahlreich vorhandenen Extensions, die von einer breiten Benutzer Community bereitgestellt
werden.
An folgendem Beispiel wird gezeigt wie mit Hilfe der ExtJS Library
und der JSON-schreibweise ein simples Fenster-Element erstellt wird,
welches der Benutzer beliebig Verschieben und die Größe andern kann
(Abbildung 3.1). Das Look and Feel“ der grafischen Elemente erinnert
”
stark an die Elemente einer üblichen Desktopapplikation.
var win = new Ext.Window({
title: ’Status’,
width: 200,
height: 100,
modal: true,
closable: true,
html: ’Changes saved successfully’
});
Abbildung 3.1: Einfaches Fenster
Da in einem üblichen Webbrowser keine Elemente wie für Desktopapplikationen zu Verfügung stehen, bedient sich ExtJS an den Document
Object Models (DOM) um den Inhalt und die Struktur der Webseite
10
Name1, Name2
KAPITEL 3. TECHNOLOGIEN
zu ändern. Im Falle dieses einfachen Fensters wird mit Hilfe von DIVElementen und Stylesheets, ein eben nur im optischen Sinne, vorhandenes Fenster dargestellt.
Name1, Name2
11
Kapitel 4
Implementierung
Im folgenden Kapitel werden die verschiedenen Bestandteile der Implementierung vorgestellt. Weiters werden auch Problemstellungen und deren Lösung, die sich in der Entwicklungsphase ergeben haben erläutert.
4.1
Relationales Datenbankmodell
Den wichtigsten Bestandteil der Software bildet die Datenbank. Die Datenbank ist so konzeptioniert, dass sämtliche Anforderungen abgebildet und eventuelle Erweiterungen an das System vorgenommen werden
können. Daher erfolgte im ersten Schritt die Erstellung eines EntityRelationship Modells (ER-Model) anhand der Chen Notation1 , da zwischen den einzelnen Entitäten der Webapplikation mehrere Relationen
zu Stande kommen (siehe Abbildung 4.1).
Für das Speichern der Informationen einer Studie wird die Tabelle STUDY verwendet. Hier werden alle angegebenen Werte wie Studienname,
Beschreibung und Identifikationsnummer gespeichert. Beim Anlegen einer neuen Studie müssen auch die NTC Positionen angegeben werden,
die flächendeckend für alle Layouts der Studie verwendet werden. Die
Positionen der NTCs werden in der Tabelle NTC NINE SIX WELL gehalten, wobei jede Position nur einer Studie zugeordnet sein kann. Die
Positionen werden wie in einem Koordinatensystem gehalten. Es gibt daher ein Feld POSITION X als auch ein Feld POSITION Y. Wird beim
Anlegen einer Studie zum Beispiel der Wert B4 eingegeben, wird für
POSITION X der Wert 4 und für POSITION Y der Wert B gespeichert.
Die Tabelle SAMPLE enthält alle Samples, die zu den Studien eingespielt wurden. Durch einen Fremdverschlüssel auf die Tabelle STUDY,
können alle Samples einer Studie zugeordnet werden. Ein kombinierter
1
http://de.wikipedia.org/wiki/Chen-Notation
13
KAPITEL 4. IMPLEMENTIERUNG
Abbildung 4.1: Datenbankmodell
14
Name1, Name2
KAPITEL 4. IMPLEMENTIERUNG
Unique Constraint auf die Sample ID und den Fremdschlüssel auf eine Studie, stellt sicher, dass eine Sample ID nur einmal innerhalb einer
Studie vorkommt. Zu einem Sample werden außerdem noch die Konzentration, der Qualitätswert, die Information ob ein Sample als Fehler
deklariert ist und das Einfügedatum gespeichert.
Generierte Layouts werden in der Datenbank in der Tabelle LAYOUT
gehalten. Im Gegensatz zu den NTC Positionen werden die Positionen
der Sample IDs nicht mittels X und Y Koordinaten festgelegt, sondern
werden durch eine Kombination aus einer fortlaufenden Nummer und
der Nummer des Layouts berechnet. Die ersten 96 verwendeten Sample
IDs erhalten für die Positionnummer die Werte 0-95 und für die Layoutnummer den Wert 1. Für die weiteren Layouts wird die Positionsnummer fortgesetzt, so erhält die Sample ID auf dem folgenden Layout die
Positionsnummer 96 und die Layoutnummer 2.
Analog zur Generierung und Ablage der Layouts erfolgt auch die Verwaltung der Samplesheets.
Für die QC Generierung wird das gleiche Konstrukt wie für Layouts
und Samplesheets angewendet, allerdings werden hierfür eigene Tabellen
verwendet.
In einem weiteren Modelierungsschritt wird das erstellte ER Diagramm
in ein relationales Datenmodell überführt, da für die Implementierung
weitere Informationen notwendig sind. Im relationalen Datenmodell werden die Objekte und Beziehungen in Form von zweidimensionalen Tabellen dargestellt.
4.2
4.2.1
Serverarchitektur
MVC Pattern
Für die Serverarchitektur wurde auf das MVC Pattern2 zurückgegriffen. Das MVC-Pattern ist ein Architekturmuster zur Strukturierung von
Softwareprojekten in die drei Einheiten Datenmodellschicht (Model),
Präsentation (View) und Programmsteuerungsschicht (Control) (Abbildung3 4.2). Ziel dieser Struktur ist ein flexibler Programmentwurf, der
eine spätere Änderung oder Erweiterung erleichtert und eine Wiederverwendbarkeit der einzelnen Komponenten ermöglicht. Es ist dadurch
beispielsweise möglich eine Anwendung zu schreiben, die das selbe Modell benutzt und sowohl eine Windows- oder Linux-Oberfläche realisiert,
als auch aber auch eine Weboberfläche beinhaltet. Beides basiert auf dem
gleichen Modell, Controller und View müssen dabei jeweils neu konzi2
3
http://de.wikipedia.org/wiki/Model View Controller
Bildquelle: http://www.octalsoftware.com/images/stories/mvc-php.png
Name1, Name2
15
KAPITEL 4. IMPLEMENTIERUNG
piert werden.
Abbildung 4.2: Klassisches MVC Pattern
4.2.2
Projektstruktur
Damit das MVC Pattern umgesetzt werden kann, ist es auch notwendig
die benötigten Ressourcen und Klassen strukturiert aufzuteilen. Webressourcen (Javascript Dateien) liegen in einem eigenen Ordner getrennt
vom serverseitigen Quellcode. Dieser befindet sich in einem eigenen Verzeichnis und ist dort wiederum in verschiedene Packages aufgeteilt. Die
Packages teilen in die Präsentationsschicht und die Datenmodellschicht
auf.
16
Name1, Name2
KAPITEL 4. IMPLEMENTIERUNG
4.2.3
O/R Mapping mit Hibernate
Die Datenhaltungsschicht, die Teil der Datenmodellschicht ist, ist für
das Speichern und Laden der Daten verantwortlich. Diese Aufgabe wird
durch die im Package com.workflow. database.beans enthaltenen Beans
durchgeführt. Wie für die Implementierung mit Hibernate üblich gibt es
für jede Tabelle in der Datenbank eine dementsprechende Java Klasse
(Bean). Folgende Java Klasse repräsentiert eine simple Java Bean Klasse:
public class MyBean {
private String name;
public MyBean(){}
public void setName(String name){
this.name = name;
}
public String getName(){
return this.name;
}
}
Eine Java Bean Klasse hat die Eigenschaft, dass auf ihre privaten Variablen, wie in diesem Fall der String name mittels der Methode getName()
zugegriffen werden kann. Analog zur Zugriffsmethode gibt es auch eine
Methode setName(), mit welcher die Variable name gesetzt werden kann.
4.2.4
Businesslogik
Die Businesslogik ist in das Package com.workflow.management in verschiedene Klassen ausgelagert. Diese Schicht ist vorallem für die Verbindung zwischen der Datenbank und der Präsentationsschicht zuständig.
Hier werden beispielsweise die Daten, die in der Datenbank gespeichert
werden dementsprechend aufbereitet.
4.2.5
Servlets
Ein Request eines Klienten (beispielsweise eines Webbrowsers) wird von
den Servlet entgegen genommen und verarbeitet. Welches Servlet angesprochen wird, wird in der web.xml Datei der Webapplikation festgelegt. Die Präsentationschicht liegt im Ordner für die Webresourcen
bzw. im Package com.workflow.servlet. Die Servlet Klassen sind für die
Kommunikation mit der Weboberfläche zuständig, wobei diese Kommunikation mittels JSON Objekten erfolgt. Der serverseitige Teil dieser
Schicht besteht aus 5 Servlets, welche in der Datei web.xml (wie für
Name1, Name2
17
KAPITEL 4. IMPLEMENTIERUNG
alle Webapplikationen erforderlich) definiert sind. Die Servlets werden
direkt vom Klienten (Webbrowser) angesprochen und haben den direkten Zugriff auf den Request des Aufrufers. Aus dem Request werden
die relevanten Daten ausgelesen und der Bussinesslogik weitergeleitet.
Im folgenden werden die wichtigsten Servlets und deren Aufgaben kurz
erläutert:
• AuthenticationServlet
Beim Einloggen auf der Startseite der Webapplikation wird dieses Servlet aufgerufen. Je nach erfolgreicher bzw. nicht erfolgreicher Authentifizierung wird eine dementsprechende Antwort an
den Browser zurückgeschickt. Im Erfolgsfall wird der Benutzer auf
die Hauptseite der Applikation weitergeleitet bzw. bei einem fehlerhaften Authentifizierungsversuch wird dem Benutzer eine Fehlermeldung angezeigt.
• WorkflowServlet
Dieses Servlet ist die zentrale Stelle für alle Requests, welche die
Verwaltung der Studien betreffen. Über dieses Servlet werden alle
Informationen zu einer Studie abgefragt. Dies betrifft sowohl die
Auflistung der Sample IDs als auch die Anzeige und Generierung
der Layouts bzw. Samplesheets.
• InitializationServlet
In der Datei web.xml kann die Reihenfolge festgelegt werden, welches Servlet an erster Stelle initialisiert werden soll. Im Falle dieser
Webapplikation wurde dieses Servlet festgelegt, um dort das Auslesen der Konfigurationsdatei, das Initialisieren der Datenbank und
das Einrichten der Logdatei vorzunehmen. Für das Auslesen der
Konfigurationsdatei wird davon ausgegangen, dass unter dem Pfad
/opt/workflow/config/WorkflowManager.conf eine gültige Datei
vorhanden ist, welche auch einen lesenden Zugriff des Tomcat Prozesses zuläßt. Eine gültige Konfigurationsdatei besteht aus folgendem Inhalt.
#Database configuration
username=workflow
password=workflow
hostname=localhost
schemaname=workflow
Die Logdatei wird im Ordner /var/workflow/logs/ WorkflowManager.html angelegt. Durch die spezifische HTML Layout Einstellung des Output Formats kann diese Datei in einem HTML-fähigen
Browser betrachtet werden.
18
Name1, Name2
KAPITEL 4. IMPLEMENTIERUNG
• DownloadServlet
Alle Requests welche den Export einer Studie, Reports bzw. eines
Layouts betrifft, werden über dieses Servlet verarbeitet. Je nach
Anfragetyp wird eine CSV oder ZIP Datei zurückgeliefert. Der
Webbrowser bietet dem Benutzer anschließend eine Möglichkeit
die Datei zu Speichern bzw. zu Öffnen.
4.3
Grafische Benutzeroberfläche
Die grafische Benutzeroberfläche wurde mit dem Javascript Framework
ExtJS implementiert. Durch die diversen grafischen Elemente wie zum
Beispiel Fenster und Menüs bzw. Kontextmenüs ergab sich die Möglichkeit eine desktopähnliche Benutzeroberfläche zu gestalten. Als Grundgerüst wurde die Idee des Dateiexplorers (unter Windows) aufgenommen
und somit eine ähnliche Benutzersteuerung, wie bisher von den Labormitarbeiter gewohnt, umgesetzt. Der Hauptbildschirm (Abbildung 4.3)
wurde in drei Teile aufgegliedert. Im oberen Bereich befindet sich eine
Menüleiste, welche einen Button zum Abmelden als auch einen Button zum Anlegen einer neuen Studie beinhaltet. Auf der linken Seite
befindet sich eine Baumstruktur, die in der ersten Ebene alle vorhandenen Studien auflistet. Wird eine Studie aufgeklappt, erscheinen alle
Ansichtsmöglichkeiten zur ausgewählten Studie. Auf der rechten Seite
befindet sich der größte Bereich, der ungefähr 80% der Ansicht einnimmt.
Hier wird die jeweils selektierte Ansicht dargestellt.
Zusätzlich zum Hauptbildschirm bieten sich noch folgende Ansichten:
• Tabellarische Auflistung aller Sample IDs einer Studie
• Auswahl und Anzeige von 96 Well Layouts
• Auswahl und Anzeige von 384er Samplesheets
• Auswahl und Anzeige der Layouts der Qualitätssicherung
• Auswahl und Anzeige der SNPs
• Auswahl und Anzeige der benutzerdefinierten Layouts
Die Steuerung von Aktionen auf Studien erfolgt über ein Kontextmenü in
der Baumstruktur. Das Menü erscheint nur bei einem Rechtsklick auf
den Studiennamen. Folgende Aktionen können dabei aufgerufen werden.
• Generierung der 96 Well Layouts
• Generierung der 384er Samplesheets
Name1, Name2
19
KAPITEL 4. IMPLEMENTIERUNG
Abbildung 4.3: Hauptbildschirm mit der Studienübersicht auf der linken Seite. Der Großteil der Oberfläche wird auf der rechten Seite des
Bildschirms beansprucht um die verschiedenen Ansichten darzustellen.
• Generierung der Qualitätssicherung
• Auswahl und Anzeige der benutzerdefinierten Layouts
Die Benutzeroberfläche bietet dem Benutzer ein einfache Bedienung und
schnellen Zugriff auf die wesentlichen Features.
20
Name1, Name2
Kapitel 5
Installation
Das folgende Kapitel beschreibt ein Installation der Software WorkflowManager unter einem Linux1 Betriebssystem. Sämtliche benötigten und
in der Folge angeführten Installationen, werden auf ein und demselben
Server vorgenommen.
5.1
Datenbankinstallation
Nach erfolgreicher Installation von MySQL kann nun das benötigte Datenbankschema installiert werden. Dazu ist es nötig sich mit einem Benutzer anzumelden, der über die Berechtigungen verfügt ein Schema
anzulegen und Benutzer zu verwalten.
Mit folgender Kommandozeileneingabe erfolgt der Login.
mysql -h hostname -u root -p
Als erster Schritt ist es notwendig das Datenbankschema an sich anzulegen. Der Name des Datenbankschemas wird in diesem Fall als worklfow
benannt.
CREATE DATABASE workflow;
Zusätzlich wird ein weiterer Benutzer angelegt, unter welchem später
die Webapplikation auf die Datenbank zugreifen wird. Dieser Benutzer
erhält ebenfalls den Namen ẅorkflow.̈
CREATE USER ’workflow’@’localhost’ IDENTIFIED BY ’workflow’;
Als Hostname wird localhost verwendet, da die gesamte Konfiguration
1
http://de.wikipedia.org/wiki/Linux
21
KAPITEL 5. INSTALLATION
direkt am Server vorgenommen wird. Anschließend müssen dem angelegten Benutzer noch Berechtigungen zugewiesen werden. Der Benutzer benötigt für das Datenbankschema workflow die Berechtigung Datensätze zu Löschen, Einzufügen, zu Lesen und zu Aktualisieren.
GRANT SELECT,INSERT,UPDATE,DELETE ON workflow.* TO ’workflow’@’localhost’;
Im nächsten Schritt kann nun die Tabellenstruktur des Schemas angelegt werden. Dies erfolgt in diesem Fall über die Importfunktion einer
MySQL Dumpdatei workflow.sql, welche die genaue Definition des Schemas enthält. Um diese Datei einspielen zu können, muss die Applikation
MySQL verlassen werden und in der Linuxkonsole folgender Befehl ausgeführt werden:
mysql -u root -p workflow.sql
Nach Ausführung des letzten Befehls ist die Installation und Einrichtung der Datenbank für die Webapplikation abgeschlossen.
5.2
Java Installation
Damit der WorkflowManager korrekt in Betriebnahme genommen werden kann, wird auf dem Server eine Java Installation mit Version 6 Update 7 benötigt. Es ist ausreichend die Java Runtime Environment (JRE)
zu installieren, da auf dem Produktivsystem kein Java Quellcode mehr
kompiliert wird.
5.3
Apache Tomcat Installation
Da der WorkflowManager innerhalb eines Servlet Container laufen muss,
wird die Installation eines Apache Tomcat in der Version 5.20 benötigt.
Diese Version des Tomcat wird in der aktuellen Fedora Linux Distribution mit ausgeliefert und ist dort in Form einer Standardinstallation
als Serverprozess verfügbar. Standardmäßig ist die Tomcat Installation
so eingerichtet, dass sich die Webapplikationen des Servers im Verzeichnis /var/lib/tomcat5/webapps/ als WAR Datei befinden müssen. Eine
WAR Datei (Web Application Archive) ist eine komprimierte Datei ähnlich einer ZIP Datei, welche die sämtliche Ordnerstruktur und die kompilierten Java Klassen der Webapplikation enthält. Beim Starten des
Tomcat Servers werden alle sich in diesem Ordner befindlichen Dateien entpackt, wobei der entpackte Ordner genau den selben Namen wie
die vorhandene WAR Datei bekommt - auch als Deploy Name bekannt.
22
Name1, Name2
KAPITEL 5. INSTALLATION
Nach erfolgreichem Starten des Tomcat Servers ist die Applikation unter URL http://servername:8080/WorkflowManager erreichbar. Damit
die Portnummer in der URL nicht angegeben werden muss, wird der
Apache Server dementsprechend konfiguriert, dass normale HTTP Requests, die auf den Port 80 eingehen, an den Tomcat Server weitergeleitet
werden.
Name1, Name2
23
Kapitel 6
Zusammenfassung
Die Webapplikation erfüllt alle an sie gestellten Anforderungen. Studien können ohne großen Aufwand angelegt und zentral verwaltet werden.
Die zur Weiterverarbeitung benötigte Aufbereitung von speziellen Dateiformaten steht durch verschiedene Exportmöglichkeiten zu Verfügung.
Durch eine benutzerfreundliche und simple Struktur der Benutzeroberfläche kann sie auf einfache Art und Weise erweitert werden, um weitere
Workflows der Labormitarbeiter zu unterstützen. Der zentrale Zugriff
und Verwaltung der Studiendaten ist keine Synchronisierung bzw. Abgleichung von Excel Dateien mehr notwendig.
Die Verwendung eines etablierten Javascript Frameworks bietet die Unterstützung aller gängigen Webbrowser, womit jeder Benutzer seinen
favorisierten Browser auch für diese Applikation verwenden kann.
In einer weiteren Iteration kann die Benutzerverwaltung ausgebaut werden, indem für die einzelnen Operationen dementsprechende Berechtigungen eingeführt werden, die einem Benutzer zugeordnet werden können.
Weiters lässt sich auch die bereits vorhandene Funktionalität der Qualitätssicherung erweitern.
25
Literaturverzeichnis
[che] Definition Chen-Notation, http://de.wikipedia.org/wiki/
Chen-Notation, zugegriffen am 17.01.2010.
[ext] Javascript Framework, http://www.extjs.com, zugegriffen am
10.05.2009.
[hib] O/R Mapping Library Java, http://www.hibernte.org, zugegriffen am 04.05.2009.
[jav] Wiki Artikel Linux, http://de.wikipedia.org/wiki/Linux, zugegriffen am 17.01.2010.
[lin]
Java Dokumentation, http://java.sun.com, zugegriffen am
17.01.2010.
[mvc] Definition MVC Pattern, http://de.wikipedia.org/wiki/
Model View Controller, zugegriffen am 04.05.2009.
[tom] Tomcat Servlet Container, http://tomcat.apache.org, zugegriffen am 04.05.2009.
27
Benutzerhandbuch
A.1
Login
Nach Aufruf der URL, unter welcher der WorkflowManager installiert
wurde, erscheint als Startseite eine Loginmaske (Abbildung 1).
Für Benutzername und Passwort werden die selben Daten wie für die
Abbildung 1: Loginmaske
Authentifizierung verwendet. Nach einem erfolgreichen Anmeldevorgang
erfolgt die Weiterleitung zur Hauptseite (Abbildung 2).
A.2
A.2.1
Verwaltung von Studien
Studien Anlegen und Einspielen
Unter dem Menüpunkt Studien - Anlegen (Abbildung 3) öffnet sich ein
Dialogfenster (Abbildung 4).
Jede Studie muss einen Studiennamen erhalten und kann optional dazu auch über eine Identifikationsnummer verfügen. Beide Werte werden
verwendet, um die Studie in der Auflistung aller Studien im linken Anzeigebereich des Hauptfensters genau zu identifizieren. Ebenfalls wird
der Name und die Identifikationsnummer auch bei der automatischen
29
LITERATURVERZEICHNIS
Abbildung 2: Hauptseite
Abbildung 3: Menüeintrag Studie anlegen
Abbildung 4: Dialogfenster Studie anlegen
30
Name1, Name2
LITERATURVERZEICHNIS
Benennung der Exportdateien verwendet. Die ebenfalls optionale Beschreibung wird lediglich als Tooltip bei der Auflistung der Studien verwendet und dient nur einen informativen Zweck. Als Sampledatei muss
eine Textdatei im Dateisystem ausgewählt werden, welche eine Liste von
Sample IDs enthält. Für ein erfolgreiches Anlegen einer Studie muss eine
gültige ausgewählt sein. Die NTC Positionen, welche ebenfalls für den
Import notwendig sind, werden in Form von xy Koordinaten angegeben.
Wobei für die x-Achse die Werte 1-12 und für die y-Achse die Werte A-H
gültig sind. Mehrere NTC Positionen werden durch Leezeichen getrennt
angegeben. Durch das Bestätigen der Eingaben mit dem "Speichern"
Knopf, wird die Studie angelegt und die Sample IDs aus der angegebenen
Textdatei eingespielt.
A.2.2
Samples Importieren
Um nachträglich weitere Sample IDs zu einer bestehenden Studie einspielen zu können, gibt es die Möglichkeit durch einen Rechtsklick auf
die gewünschte Studie eine weitere Datei zu importieren (Abbildung 5).
Abbildung 5: Eine weitere Datei mit Sample IDs einspielen
A.2.3
Proben Importieren
Um eine Studie zu vervollständigen werden noch Konzentrations- und
Qualitätswerte benötigt, welche ähnlich wie Sample IDs importiert werden. Ebenfalls über einen Rechtsklick auf die gewünschte Studie wird
der Menüeintrag "Proben importieren" aufgerufen. Es erscheint anschließend ein neues Dialogfenster wie in Abbildung 6.
Hier besteht die Möglichkeit zwei verschiedene Importformate zu verwenden. Zum einen eine Nanodrop Datei und zum anderen eine Nanoquant Datei. Die anschließend ausgewählte Datei muss eine CSV Datei
sein, welche im Format der dementsprechenden Auswahl entspricht.
Name1, Name2
31
LITERATURVERZEICHNIS
Abbildung 6: Proben einspielen
A.2.4
Layouts Generieren
Damit Layouts betrachtet werden können müssen sie zuerst generiert
werden. Durch die Auswahl des Menüpunktes 96 Layout generieren werden aus allen Sample IDs zur ausgewählten Studie Layouts generiert.
Sind vor dieser Aktion schon Layouts vorhanden, werden diese automatisch gelöscht bzw. uberschrieben.
A.2.5
Samplesheets Generieren
Analog zur Generierung von Layouts, werden auch die Samplehseets
generiert.
A.2.6
Samplesheets Generieren
Bestehende Layouts können durch einen Doppelklick auf die gewünschte
Position geändert werden. Es erscheint eine Auswahlmöglichkeit in Form
einer Dropdown Box (Abbildung 7), in der alle in der Studie enthaltenen
Sample IDs aufgelistet werden. Nach Auswahl der gewünschten Sample
ID wird diese Änderung automatisch in der Datenbank übernommen.
A.3
Exportieren
Damit die vorhandenen und gesammelten Daten der Studien auch weiterverwendet werden können, gibt es die Möglichkeit die Studien in diversen Formaten zu exportieren. Die Exportfunktion erfolgt ebenfalls
über das Kontextmenü (Abbildung 8). Bei allen Exportfunktionen besteht die Möglichkeit ein einzelnes Layout bzw. Samplesheet als CSV
Datei oder die gesamte Studie als ZIP Datei, welche für jedes Layout
bzw. Samplesheet eine CSV Datei enthält, auszuwählen.
32
Name1, Name2
LITERATURVERZEICHNIS
Abbildung 7: Auswahl einer neuen Sample ID
Abbildung 8: Kontextmenü für den Export
Name1, Name2
33
LITERATURVERZEICHNIS
A.3.1
Roboter DNA Konzentration Exportieren
Spezielle Ausgabe einer CSV Datei. Es ist außerdem möglich den Inhalt
der ersten Spalte per Auswahl zwischen P1 und Q1 zu definieren. Die
exportierte Datei enthält die Spalten Quelle-Label, Quelle-Position und
Konzentration, wobei die Quellenposition aus einer einfachen Durchnummerierung besteht.
A.3.2
Layouts Exportieren
Beim Standardmäßigen Export von Layouts gibt es ebenfalls die Möglichkeit ein einziges Layout oder alle Layouts der gesamten Studie zu Exportieren.
A.3.3
Samplesheets Exportieren
Analog zum Export der Layouts können auch die Samplesheets exportiert werden.
A.4
QC Generierung
Um bei einer bestehenden Studie eine Qualitätskontrolle generieren zu
können, muss eine QC Generierung ausgeführt werden. Für die Berechnung der verwendeten Sample IDs ist es notwendig die gewünschten
Positionen anzugeben (Abbildung 9). Um nicht sofort eine komplette
Generierung anzustoßen besteht die Möglichkeit anhand der vorhandenen Eingaben die Abdeckung vorauszuberechnen.
Abbildung 9: Erforderliche Eingabe für QC Generierung
34
Name1, Name2

thesis - Institut für Informatik

Produkte

Unterstützung

thesis - Institut für Informatik

Dieses Dokument Sammlung (en)

Dieses Dokument gespeichert

Schlagen Sie uns vor, wie wir StudyLib verbessern können