Nach zwei einführenden Artikeln zum ROSALIND-Projekt komme ich in diesem Artikel zum Thema Projektaufbau. Das soll auch gleichzeitig der letzte organisatorische Artikel zum Thema sein. Anschließend möchte ich meine ersten Implementierungen vorstellen.

Der Projektaufbau

Zur Lösung der Probleme habe ich mich für C# 4.5 und Visual Studio 2012 entschieden, was nicht ganz überraschend sein sollte. Abbildung 1 zeigt den Aufbau der Visual Studio Solution, die vier Projekte enthält.

Abb. 1: Visual Studio Solution für das ROSALIND-Projekt.

Twainsoft.Lessons.Rosalind.App

Das App-Projekt ist als StartUp-Projekt eingestellt und implementiert eine Konsolenanwendung. Diese gibt die Lösung des Problems aus, das aktuell bearbeitet wird, und schreibt beim Start alle bisher erstellten Lösungen als .txt-Datei auf die Festplatte. Diese Dateien können als Antwortdateien beim ROSALIND-Projekt hochgeladen werden. Das Projekt übernimmt somit die Formatierung der Problemlösungen, damit die Klassen beziehungsweise Methoden mit der eigentlichen Implementierung allgemeinere Ergebnisse zurück liefern können und sich nicht an das gewünschte Format halten müssen. Der konkrete Aufbau des Projekts ist auch in Abbildung 1 zu sehen, da bisher nur die wenig spannende Main-Methode vorhanden ist.

Twainsoft.Lessons.Rosalind.Data

Das Data-Projekt enthält lediglich die Datensätze zu den einzelnen Aufgabenstellungen. Damit sind nicht die Beispieldatensätze gemeint, die bei jeder Problembeschreibung direkt mit angegeben werden, sondern die Dateien, die zum Einreichen einer Lösung heruntergeladen werden müssen. Abbildung 2 zeigt den aktuellen Aufbau des Projekts. Gruppiert sind die Dateien nach den Aufgabennummern in jeweils eigenen Verzeichnissen. Zur besseren Identifikation behalten die Dateien den originalen Namen des ROSALIND-Projekts bei.

Abb. 2: Aufbau des Projekts Twainsoft.Lessons.Rosalind.Data.

Twainsoft.Lessons.Rosalind.Tests

Das Tests-Projekt enthält den Part des Projekts, der für die Überprüfung der implementierten Lösungen zuständig ist. Hier sind alle erstellten Unit-Tests gebündelt. Gruppiert werden diese nach den Aufgabennummern und befinden sich gemeinsam im Verzeichnis TestCases. Der Ordner Data dagegen enthält die Testdaten, die von den Unit-Tests benötigt werden. Mit diesen Testdaten sind die Beispieldatensätze gemeint, die bei jeder Problembeschreibung mit angegeben werden. Anders als im eben beschriebenen Data-Projekt werden bisher aber nur größere Beispieldatensätze als Dateien gespeichert. Das ist erstmalig beim GC-Problem der Fall, bei dem eine größere Datei im FASTA-Format angegeben ist. Handelt es sich bei den Beispieldaten nur um eine einzelne Zeichenkette, werden diese direkt im Unit-Test mit angegeben. Abbildung 3 zeigt den Aufbau des Projekts.

Abb. 3: Aufbau des Projekts Twainsoft.Lessons.Rosalind.Tests.

Twainsoft.Bioinformatics

Das Bio-Informatik-Projekt ist das Herzstück meiner ROSALIND-Lösungen (siehe Abbildung 4). Hier befinden sich die eigentlichen Implementierungen für die einzelnen Problemstellungen. Aktuell gibt es beispielsweise die Klassen DNA und RNA. Diese gruppieren die Problemstellungen, die sich auf die Bereiche DNA beziehungsweise RNA beziehen. In einer ersten Version war jede Lösung in einer eigenen Klasse kodiert und in einer noch früheren Version als Erweiterungsmethoden für die String-Klasse. Beide Ansätze haben sich ziemlich schnell als unpraktisch herausgestellt. Ob der aktuelle Ansatz lange bestehen bleibt, wird sich schnell zeigen. Da das Projekt mit der Konsolenanwendung die Formatierung der Lösungen enthält, geben die Implementierungen in diesem Projekt allgemeinere Ergebnisse zurück und halten sich an kein bestimmtes Ausgabeformat.

Abb. 4: Aufbau des Projekts Twainsoft.Bioinformatics.

Fazit

Bisher bin ich ganz zufrieden, was den Projektaufbau und die Organisation der Lösungsansätze angeht. Es gibt aber auch einige Punkte, die mir nicht so gut gefallen. Da ist zum einen die Implementierung der Konsolenanwendung. Die Formatierung der Lösung könnte noch ausgelagert werden, damit die Konsolenanwendung einen nicht ganz so chaotischen Eindruck macht. Auch über die Organisation der Beispieldaten der Unit-Tests sollte ich bei Gelegenheit noch einmal nachdenken. Eventuell sollten alle Testdaten als Dateien vorliegen, auch wenn es sich nur um eine einzelne Zeichenkette handelt. Das würde den Umfang der Unit-Tests verringern und sowohl die Lesbarkeit als auch die Wartbarkeit erhöhen. Zum Thema Wartbarkeit ist auch noch zu sagen, dass es sich in Zukunft vermutlich lohnt, zwischen einem Algorithmus und einer Datenklasse zu unterscheiden. Aktuell sind diese beiden Ansätze noch vermischt.

So viel zunächst zum Thema Projektaufbau. Die Vorstellung meiner ersten Lösungsvorschläge folgt in Kürze.