Vorbereitung

Zuerst einmal muss man das Problem in einer für Open Office Calc lesbaren Variante in eine Tabelle eingeben. Als Beispiel nehme ich dieses (sinnlose, beispielhafte) LP:

max  5a +7b -6c +2d
s.t.  6a +8b <= 7
     -4c +9d <= 20
     a,b,c,d >= 0

Als Spreadsheet sieht das Ganze bei mir dann so aus:

In der oberen Tabelle gibt man die Zielfunktion an. Dazu legt man zuerst einmal für jede Variable eine Zelle an (im Bild blau markiert). Jetzt braucht man eine Zelle, in der die Zielfunktion berechnet wird (im Bild rot umrahmt). Diese Berechnung muss natürlich mit Referenzen auf die Zellen erfolgen. Ich habe der Einfachheit halber noch die Koeffizienten aus der Zielfunktion in extra Zellen notiert (grüner Rahmen), so dass ich in der Zielfunktionszelle einfach aufsummieren kann. In der ersten Zelle im grünen Rahmen steht bspw.:

=B2*5

Und in der roten Zelle steht entsprechend nur:

=SUMME(C2:C5)

Wenn man lieber die Zielfunktion direkt eintragen will, würde das in unserem Beispielfall so aussehen:

=5*B2+7*B2-6*B4+2+B5

Der nächste Schritt ist nun die Eingabe der Nebenbedingungen. Es gibt dafür unterschiedliche Möglichkeiten, aber ich habe es jetzt mal übertrieben exakt notiert, damit es übersichtlich bleibt. Die Zellen in der gelb umrahmten Box enthalten die Bedingungen aus dem LP als Gleichung mit Referenzen auf die Zellen in der blauen Box. Die letzte Zeile enthält die erste Nebenbedingung und sieht so aus:

=(-4)*B4+9*B5

Der Teil rechts davon ist nicht so wichtig. Man kann das so machen, aber genauso gut kann man es sich auch schenken.

Der Solver

Nun ruft man über das Menü “Extras” den “Solver” auf. Es öffnet sich ein Dialog, den man wie folgt ausfüllen muss:

Als Ziel gibt man die Zelle mit dem Wert der Zielfunktion an (im Bild oben mit rotem Rahmen). In dem etwas seltsam betitelten Feld “Durch Zellenänderung” soll man die Zellen angeben, in denen die Variablen stehen. Man markiert also den Bereich, der im Bild oben blau umrahmt ist.

Etwas aufwändiger ist es nun, die Nebenbedingungen einzugeben, da man sie alle einzeln angeben muss. Man wählt “hinzufügen” und in dem kleinen Dialog kann man dann die Zelle auswählen, in der der Wert der Nebenbedingung berechnet wird. Dann kann man eine Relation auswählen und einen Wert eingeben (oder wie hier im Beispiel referenzieren).

Wenn es nötig ist, kann man jetzt unter “Optionen” noch einstellen, dass nur positive oder nur ganze Zahlen als Variablenbelegungen erlaubt sind.

Hinweis: Im neuen Open Office 3.0 sieht der Solver etwas anders aus. Funktionieren sollte er aber genauso.

Die Lösung

Ist alles fertig eingegeben, drückt man auf “Lösen” und bekommt (hoffentlich) eine Bestätigung, dass eine Lösung gefunden wurde. In meinem Fall sah das Spreadsheet dann so aus:

Open Office hat nun die Variablen so belegt, dass der Zielfunktions-Wert maximiert wird.

Wenn du dir nochmal mein Beispiel genauer anschauen willst, kannst du dir hier auch das Spreadsheet runterladen. Wenn du den Solver öffnest, ist es möglich durch einen Klick auf “Laden” meine Einstellungen aufzurufen.

• Solver Tutorial Spreadsheet

Aufgabenstellung:

Die Aufgabe unserer Gruppe bestand darin, ein P2P-Pokerspiel zu entwickeln.
Dazu wurde die sieben Mann und eine Frau starke Gruppe in 3 Teilgruppen unterteilt, die jeweils eigenständige Aufgabenstellungen zu erledigen hatten und am Ende alles zu einem funktionierenden Ganzen verschmelzen sollten.
Team 1 war für das Erstellen des eigentlichen Pokerspiels verantwortlich und zwar sollte im speziellen der Spieltyp “Texas Hold’em” implementiert werden. Das Spiel sollte aber erweiterbar für weitere Spieltypen sein und der Spielablauf sollte durch das Server-Client-Konzept realisiert werden.
Team 2 sollte das Matchmaking implementieren. Es sollte also durch den Aufbau eines P2P-Netzwerkes möglich sein, Kontrahenten und Freunde für das gemeinsame Pokervergnügen zu finden. Zudem noch ein Ranking-System mithilfe dessen man sich mit seinen Mitspielern vergleichen kann.
Der Auftrag von Team 3 bestand darin, einen Webcam-Stream einzurichten der es ermöglichen sollte, seine Mitspieler sehen zu können.

Projektablauf

Ähnlich wie in Bericht I lief es bei uns ab. Zuerst stand die ausführliche Planung des Projekts an, die aber z.T. immer wieder über den Haufen geworfen wurde. Da wir uns schon dachten, dass unser Projekt etwas aufwendiger sein könnte, fingen wir mit dem Programmieren bereits in den “Pfingstferien” an. Während die ersten Gruppen bereits 2 Wochen nach den “Pfingstferien” mit ihrem Projekt im Großen und Ganzen fertig waren, stieg bei uns unterdessen der Druck. Neben den normalen Übungsblättern, Proseminaren und Klausurvorbereitungen galt es das Netzwerk und Spiel zum Laufen zu bringen. Vor allem Team 2 machte die fehlerhafte P2P-Software schwer zu schaffen. Nachdem auch noch die Milestones mit der Projektabgabe nach vorne verlegt wurden, blieb uns in den letzten Tagen des Projektes nichts anderes über, als uns zusammen am Sand zu treffen und Tief in die Nächte zu programmieren.

Das UML nach der Planung sah bei Team 1 so aus: UML geplant
Am Ende fiel es dann doch etwas umfangreicher aus: UML des fertigen Projekts

Arbeitsklima

Trotz all des Stresses herrschte bei uns im Großen und Ganzen ein angenehmes Arbeitsklima.
In den wöchentlichen Sitzungen mit den Betreuern wurden Probleme angesprochen und Lösungswege überdacht. Abgerundet wurden diese Sitzungen immer von einer Runde Kuchen für alle. Die Kommunikation erfolgte über alle vorstellbaren Formen vom Teamspeakgespräch bis hin zum Ticket im Trac. Am effektivesten war meiner Meinung nach aber doch das gemeinsame Programmieren.

Fazit

Schlussendlich haben wir es doch geschafft, ein halbwegs zufriedenstellendes Ergebnis zu erzielen. Einige Bugs konnten wir trotz allem aus zeitlichen Gründen aber nicht mehr ausbügeln.
Nach der Abgabe der Dokumentation unseres über 18.000 Zeilen umfassenden Projekts waren wir alle ein bisschen froh es endlich hinter uns gebracht zu haben und uns dem zuwenden zu können, was wir im Verlauf der letzten 4 Wochen stark vernachlässigen mussten.

Aufgabenstellung

Das Projekts, an dem ich beteiligt war, sah vor, dass wir eine Software entwickeln, um Daten zu analysieren, die beispielsweise durch Massenspektrometrie ermittelt wurden. Dabei handelt es sich konkret um kurze Bruchstücke (sog. Peptide) von Proteinen, die gegen Proteindatenbanken verglichen werden, indem die Bruchstücke an die Sequenzen der Proteine angelagert werden. Visualisiert werden soll dann in einem Histogramm die Abdeckung der einzelnen Aminosäuren eines Proteins durch die Peptide und das Alignment in einer einfachen grafischen Darstellung. Die Implementierung sollte in Java gemacht werden und alle Funktionen der Software über ein grafisches Interface verfügbar sein.

Projektablauf

In den ersten vier Wochen hatten wir die Aufgabe aus einem zur Verfügung gestellten Lastenheft alle Anforderungen an die Software herauszuarbeiten, ein konkretes Konzept zu erstellen und den gesamten Entwurf in einem Pflichtenheft aufzuschreiben. Teil des Entwurfs war natürlich ein fertiges Klassenmodell notiert in Form eines UML-Diagramms.

Das zweite Drittel des Projekts verbrachten wir dann mit der tatsächlichen Programmierung der modellierten Software. Da wir zu dritt an diesem Projekt saßen, haben wir eine entsprechende Aufteilung des Konzepts vorgenommen, so dass jeder unabhängig von den anderen seinen Teil umsetzen konnte.

Die letzten Wochen waren dann vom Zusammenbau der einzelnen Teile, der Vorbereitung für die Präsentation in der projektbegleitenden Vorlesung, dem Erstellen von Testfällen für die finale Abnahme des Programms und dem Schreiben der Dokumentation geprägt.

Die gesamte Dauer des Projekts wurde wöchentlich in einem Seminar mit den beiden Betreuern besprochen, ob Teilziele erreicht wurden und wie weiter vorgegangen werden soll. Gearbeitet wurde zur Unterstützung der Teamarbeit mit Subversion, dessen Verwendung uns zu Beginn des Projekts allen neu war und nun ziemlich zur Routine geworden ist.

Arbeitsklima

Während der Seminare war die Atmosphäre sehr angenehm und locker. Nach einigen allgemeinen Dingen in den einzelnen Arbeitsgruppen (insgesamt 3 Gruppen von jeweils 3 Studenten) wurde meistens projektspezifisches besprochen, wobei meistens diskutiert wurde, um letztendlich im Konsens zu einer Einigung zu kommen. Dabei waren unsere eigenen Ideen sehr gefragt, was eigentlich durchgängig das gesamte Projekt über immer der Fall war. Wir hatten nur die grobe Vorgabe, was die Software tun soll, und gänzlich freie Hand in der Gestaltung.

Fazit

Sowohl vom Umfang her, als auch von der Aufgabenstellung war das Projekt ziemlich gut auf unsere Situation abgestimmt. Wir haben bei der insgesamt recht stressfreien, wenn auch dennoch zeitaufwendigen, Umsetzung eine ganze Menge über Abläufe und natürlich auch Programmierung gelernt und das war ja das erklärte Ziel der ganzen Veranstaltung.

Programmieren ist definitiv ein wichtiger Teil des Informatik- und damit auch des Bioinformatik-Studiums. Immernoch sehr beliebt ist hierbei die Sprache Java, mit der sich in Tübingen jeder (Bio-)Informatik-Student irgendwann einmal herumschlagen muss. Viele greifen dabei zur IDE eclipse, doch annähernd genauso viele wissen garnicht, was man mit eclipse alles machen kann und dieses Programm zu mehr macht als nur einem relativ langsamen und überladenen Texteditor.

Wenn man nämlich mal an dem Punkt angelangt ist, dass der Compiler sich nicht mehr über irgendwelche Syntaxfehler beklagt, dann kommt man oft in die Situation, dass sich bei der Ausführung Probleme ergeben, wie beispielsweise die immer wieder sehr beliebte “ArrayIndexOutOfBoundsException”, die den Programmierer darauf hinweist, dass er irgendwo einen Denkfehler gemacht hat und auf etwas zugreifen will, das nicht existiert. Und hier wird es jetzt interessant, denn eclipse bietet mit seinem Debugger eine gute Möglichkeit, um solchen Fehlern ein wenig auf den Zahn zu fühlen. Wenn jetzt Fragezeichen aufgetaucht sind und die Frage “Was zum Geier ist ein Debugger?” im Raum steht, spätestens dann lohnt es sich jetzt hier weiterzulesen.

Was kann der Debugger?

Wenn ein Programm ausgeführt wird (also von der Java Virtual Machine interpretiert wird), dann läuft es einfach so lange durch, bis es entweder fertig ist oder einen Fehler produziert. Mittels des Debuggers kann man das Programm gezielt während der Ausführung anhalten und einen Blick ins Innere der Virtual Machine werfen. Konkret heißt das, dass man beispielsweise die Variablenbelegungen zum Zeit der Ausführung begutachten kann.

Wie starte ich den Debugger?

Zuerst mal muss man sich klarmachen, dass es nur dann Sinn macht den Debugger zu starten, wenn man eine grobe Idee hat, wo man genauer hinschauen will. Wenn man nämlich einfach direkt statt auf “Run” auf “Debug” drückt, um das Programm auszuführen, passiert nichts Besonderes, sondern es wird eben einfach das Programm ausgeführt und nach der Ausführung beendet. Das ist natürlich nicht der Sinn der Sache.

Bevor man den Debugger startet muss man einen oder mehrere sogenannte Breakpoints setzen. Das sind Haltepunkte, an denen der Debugger die Ausführung unterbricht und uns den Blick ins Innere ermöglicht. Um solche Haltepunkte zu setzen, gibt es in eclipse mehrere Möglichkeiten. Die einfachste ist, neben der Zeile, in der man anhalten möchte, auf die Leiste einen Doppelklick zu machen, die normalerweise die Symbole für Warnungen und Fehler enhält. Dort erscheint dann ein blauer Punkt.

Solche Punkte kann man soviele setzen, wie man möchte. Wenn man sie mit einem Rechtsklick erwischt, dann gibt es in diesem Menü auch die Möglichkeit Breakpoints zu deaktivieren. Das ist während eines Debugvorgangs oft die bessere Idee als den Punkt direkt wieder zu entfernen.

Nun ist es an der Zeit den Debugger zu starten. Dies geht über das Symbol “Debug” direkt neben dem Icon “Run”, mit dem man normalerweise die Ausführung des Programms veranlasst. (Passenderweise ist das Icon mit einem Käfer versehen.) Wenn man einfach auf den Button klickt, wird der Debugger mit der zuletzt verwendeten Einstellung aus dem “Run”-Menü gestartet. Man kann auch direkt auswählen, dass man als Java-Applikation debuggen möchte. Das geht absolut äquivalent wie das simple Starten des Programms:

Wenn man einen Breakpoint gesetzt hat, dann fragt eclipse während der Ausführung, ob man in die “Debug-Perspektive” wechseln möchte. Das sollte man bestätigen und am besten direkt auch den Haken setzen, damit eclipse nicht wieder nachfragt. Nun erscheint eine neue Übersicht, die viel mehr Informationen enthält, als die vorherige. Um zur einfachen Ansicht zurückzukehren, kann man oben rechts auf “Java” klicken. Jetzt mal eine kurze Erklärung zu den einzelnen Komponenten von links oben nach rechts unten:

• Debug:
  Dieser Bereich enthält den Stack der aktuellen Ausführung. Aus diesem Fensterchen kann man ersehen, welche Methoden gerade im Moment aufgerufen wurden und dazu geführt haben, dass der aktuelle Breakpoint erreicht wurde. Außerdem findet man hier die Schaltfläche (grüner Pfeil nach rechts), mit dem man den nächsten Auswertungsschritt einleiten kann, sowie den Button, um die Ausführung abzubrechen (rotes Quadrat).
• Variables:
  Der vielleicht interessanteste Teil der Debug-Perspektive. Hier kann man sich die zum aktuellen Ausführungszeitpunkt belegten Variablen und natürlich die Werte anschauen.
• Quelltext:
  Das ist ja nichts Neues bis auf die Tatsache, dass hier immer die aktuelle Zeile hervorgehoben wird, in der die Ausführung angehalten wurde. Hier kann man auch noch während des Debuggens Breakpoints setzen und entfernen. Veränderungen am Code wirken sich allerdings erst nach einem Neustart des Debuggers aus.
• Outline:
  Ebenfalls ein bekanntes Element aus der üblichen Java-Perspektive.

Über die Möglichkeit schrittweise durch die Ausführung einer Schleife genau zu verfolgen, was mit den Werten passiert etc., kann man meistens sehr gut Fehlerquellen ermitteln, die man vielleicht vorher nicht bedacht hat. Auch bei Rekursionen kann das sehr nützlich sein, da im “Debug”-Fenster als Stack aufgezeigt wird, welche Methoden aufgerufen wurden und man sich so genauer ein Bild davon machen kann, was genau der Quelltext, den man zwar selber verfasst, aber vielleicht nicht ganz verstanden hat, eigentlich wirklich auslöst.

Zum Schluss kann ich nur empfehlen einfach mal mit dem Debugger herumzuspielen und vielleicht auch mal gezielt ein paar Fehler zu verursachen und sie zu beobachten. Während des normalen Programmierens treten zwar normalerweise auch genug Fehler auf, um Routine zu bekommen im Debuggen, aber da sollte es nach Möglichkeit dann schon etwas leichter von der Hand gehen, da man doch eher nicht die Zeit oder den Nerv hat sich mit den Details des Debuggers auseinanderzusetzen.

Wenn noch Fragen offen geblieben sind, dann nutzt doch einfach die Kommentar-Funktion hier im Blog oder schreibt mir eine eMail mit euren Anregungen.

Viel Erfolg beim Debuggen.

• Vorlesung findet statt am Do 10:15-11 Uhr und Fr 09:15-10:45 Uhr
• Vorlesung morgen am 11. Mai fällt aus
• Klausur findet statt am 25.10.07 im N7 von 14-17 Uhr
• Nachklausur ist am 26.11.07, Raum und Zeit noch unklar – hängt davon ab wie viele durchfallen
• Biologen finden das Wort “Algo” sehr amüsant

Es wird wieder ein Tutorium geben bei Herrn Helge Miller, welches ich nur empfehlen kann. Für dieses gibt es 2 Termine in der Woche:

• Montag 11:15-13:00 Uhr
• Dienstag 11:15-13:00 Uhr

Dieses findet im E-Bau in E3A40 statt.

Folien zur Vorlesung werden Online gestellt…vermutlich auf der Homepage des Instituts.
Ist aber noch nichts zu finden – der Benutzername und Passwort ist jedenfalls der selbe wie vor einem Jahr.

• Vorlesung “Software Engineering” (Prof. Huson)
• Praktikum bzw. Seminar

Die Praktika bzw. Seminare werden von unterschiedlichen Lehrstühlen angeboten, um alle Studenten ausreichend betreuen zu können. Entsprechend unterscheiden sich dann auch die Themen.

Ein herzliches Dankeschön und ein dickes Lob an dieser Stelle mal an Prof. Kohlbacher, der uns wiedermal das Licht ins Dunkle getragen hat.

Nachtrag (24.03.):

Auf der Vorlesungsseite findet sich inzwischen folgende Information:

Die Themen der Seminare werden am 16. April in der ersten Vorlesung vorgestellt. Nach der Vorstellung der Themen wird es die Möglichkeit geben, Präferenzen für die jeweiligen Seminare anzugeben. Die Studierenden werden dann auf die verschiedenen Seminare verteilt, möglichst unter Berücksichtigung der Präferenzen.

Nachtrag (01.04., Update 14.04.):

Inzwischen gibt es eine vorläufige und unvollständige Themenliste zum Programmierprojekt, die in den nächsten Wochen wohl noch erweitert wird, sobald die einzelnen Lehrstühle neue Informationen veröffentlichen:

• Literature Mining in der Systembiologie
• Implementierung eines 3D-Clustering-Verfahrens
• Implementierung und Anwendung des Apriori-Algorithmus
• 2D/3D Strukturvergleich mit Graphalgorithmen
• Peptide Viewer
• Sekundärstrukturvorhersagen zu Sequenzen
• Genome-Viewer (in drei Teilprojekten)
• Drahtloses Informations- und Aktionssystem in drei Teilprojekten
• Peer-2-Peer Poker in 3 Teilprojekten

Update:
Der am 8. Februar stattfindende Mikrobiologische Kurs wurde auf 8-12 Uhr vorverlegt, sodass es nun keine Überschneidung mit der PC-Klausur mehr gibt.

Für das restliche Semester und in Zukunft für das gesamte Semester haben die Bioinformatiker Übungen zur physikalischen Chemie. Das soll dafür sorgen, dass ein Verständnis für den Umgang mit den relevanten Formeln entsteht etc. Da eigentlich schon seit Beginn des Wintersemesters entsprechende Übungen in den Plan hineingehören, ist das zwar kein sonderlich unerwarteter Schritt, aber doch schön, dass sich da endlich etwas getan hat.

Da die Klausur durchweg so schlecht ausgefallen ist, wird wohl überlegt ein klein wenig am Maßstab zu drehen, damit eine Chance besteht in der zweiten Klausur (deren Termin sich nachwievor mit dem mikrobiologischen Kurs überschneidet, der ebenfalls eine Pflichtveranstaltung ist) genug Punkte zu holen, um letztendlich bestanden zu haben. Dazu gibt es aber keine konkreteren Informationen bisher.

Die Kritik ist also zumindest teilweise nicht ganz auf taube Ohre gestoßen. Inwieweit sich die Situation jetzt noch zum Positiven wendet was konkret den Jahrgang 2005 betrifft, bleibt abzuwarten. Aber so kann man zumindest etwas beruhigter in die “Ferien” gehen. In diesem Sinne:

Frohes Fest und einen guten Rutsch ins neue Jahr!

Noch wissen wir nicht was uns auf uns zukommt.
60 Minuten später: Dank einem gut durchdachten und bis ins letzte Detail ausgetüffelten Sitzsystem finden alle Studenten in N7 auf Anhieb ihren Platz.
14:15 Uhr – die Schlacht beginnt.
Keine 24 Stunden später die Ernüchterung: Dem Aushang ist zu entnehmen: kein einziger Bioinformatiker hat die 50% geschafft, die es zu erreichen galt. Schnitt 25%. 100% Durchfallquote. Fragen werfen sich auf: Ist eine angemessene Korrektur von rund 150 Klausuren in weniger als 24h möglich? Warum hat kein Bioinformatiker bestanden? Lag es daran, dass wir keine Übungsblätter und Tutorien hatten? Lag es daran, dass wir die Klausur unterschätzt haben (Stichwort 1-2 Rechenaufgaben? Steckt dahinter ein tieferer Sinn, den wir nicht durchschauen?

Ich für meinen Teil bin etwas enttäuscht – über die (unangemessene) Klausur selbst – über das Schnellkorrekturverfahren und ein etwas übersichtlicheres Skript wäre auch nett gewesen.

Fühlt euch frei zu kommentieren. ;)