Lehrveranstaltung Skriptsprachen / Objektorientierte Programmierung
Aus dem Modulhandbuch zu K7461 vom 1. September 2007:
„Aufbauend auf den Kursen ‚Programmiersprachen I und II‘ vermittelt diese Lehrveranstaltung eine Skriptsprache, die aktuell in Internetanwendungen genutzt wird. […] Die Studierenden werden in die Lage versetzt, komplexe Internet-Anwendungen zu verstehen und selbständig Applikationen mittleren Schwierigkeitsgrades zu implementieren.“
Teil der Aufgabenstellung ist es, eine Web-Anwendung zur Demonstration des Ablaufs eines wohlbekannten Algorithmus zu entwicklen und zu programmieren. Die Veranschaulichung des Ablaufs soll dabei bildhaft/animiert realisiert werden.
Die Aufgabe soll in einer Projektgruppe von etwa vier Studenten bearbeitet werden. Es sind die Aufgabenbereiche Projektleitung, Design und Logik sowie Funktionalität personell zu besetzen. Der Prokjektleiter soll dem Dozenten wöchentlich Bericht über den Status erstatten.
Abgabe ist am Donnerstag, 21. Januar 2010. Abzugeben ist ein komplettes und lauffähiges Projekt mit gut dokumentierten Programmen einschließlich Dokumentation der einzelnen Arbeitsanteile der Projektbeteiligten.
Dieses Dokument ist Teil des wöchtentlichen Berichts der Gruppe 5 (Algorithmus: Maximum–Sub-Array–Problem, Divide-and-Conquer–Lösung), bestehend aus Antonia Boemanns, Bianca Förster, Arne Johannessen und Holger Schropp. Es wächst zusammen mit dem Projekt und hält Ergebnisse, aber teils auch Hintergründe fest, die Teil der Durchführung oder der Leitung des Projekts sind.
Design und Implementierung
Allgemeine Hinweise
Soweit möglich und sinnvoll, werden Aufgabenaufteilung und Implementierung ähnlich Contract-first Design im Sinne des diesbezüglichen Montagsvortrags von Volker Birk durchgeführt. Im Wesentlichen sind die Konsequenzen folgende:
- Aufteilung des Gesamtprojekts in mehrere Module
- jedes Modul wird von genau einer Person grundsätzlich eigenständig bearbeitet (jedoch natürlich Hilfe und Unterstützung durch Projektleiter oder andere Entwickler, wann immer nötig)
- sowohl die exakte Abgrenzung der Grenzen zwischen je zwei Modulen als auch die Schnittstellen zwischen beiden Modulen werden von den beiden Modulbearbeitern untereinander vereinbart (führt zu Dezentralisierung des Designs)
- enge Zusammenarbeit bis hin zum Pair Programming dort, wo es sinnvoll ist; gleichzeitig automatisch gute Kapselung der nicht zusammenarbeitenden Module gegeneinander
Die Dokumentation der einzelnen Module auf Projektebene wird überwiegend in den Modulen selbst in Textform vorgenommen. Die Module enthalten alle einen oder wenige JavaScript-„Klassen“ (genauer: Objekte zur Verwendung als Prototyp zusammen mit dem new-Operator). Neben einer kurzen Dokumentation zur „Klasse“ selbst in einem Dokumentationskommentar werden die Schnittstellen aller dieser „Klassen“ jeweils auf Methoden-Ebene dokumentiert. Das Ergebnis ähnelt dem Javadoc-Dokumentationsstil, eine automatische Weiterverarbeitung ist jedoch nicht vorgesehen.
Parallel zur Entwicklung ist eine Anzahl von Struktur- und Sequenzdiagrammen entstanden, deren graphische Qualität jedoch nicht wiedergabefähig ist. Diese (oder auch nur eine Auswahl davon) zur Ergänzung der Dokumentation sauber neu zu zeichnen, hat die Zeit leider nicht erlaubt.
Weitere Eigenschaften von Contract-first Design
Andere Eigenschaften des Contract-first Design nach Volker Birk werden bei uns nicht systematisch integriert. Eine Anwendung von automatisierten Softwaretestverfahren erfolgt lediglich im Einzelfall der Numerik des MSA-Algorithmus; der weitergehende Einsatz wird einerseits durch die fehlende Erfahrung der Mehrzahl der Entwickler, andererseits aber auch durch die Unit-Tests auf DOM-Operationen durch asynchrone gekapselte Objekte inhärente Komplexität erschwert.
Im Übrigen wurde festgestellt, dass der Ausbau der bereits bestehenden JavaScript-Kenntnisse bei der Mehrheit der Mitwirkenden von Vorteil wäre. Dies erfolgt nach Bedarf „on the job“.
Begriffsabgrenzung Contract-first Design
Der Begriff „Contract-first Design“ wird von verschiedenen Personen in unterschiedlichen Zusammenhängen verwendet. Insbesondere entsprechen nicht alle der in den folgenden Quellen beschriebenen relevanten Konzepte Contract-first Design in dem in unserem Falle angewandten Sinn, obschon einzelne Elemente wiederzuerkennen sind:
Zielumgebung
Bereits in den ersten Stunden des Projekts wurde versucht, eine geeignete Definition für die Zielumgebung zu finden, in der die Anwendung lauffähig sein sollte. Interessant für die Zielumgebung sind vor allem Browser-Versionen oder Web-Standards sowie ferner die Pixel-Anzahl („Auflösung“).
Für die Browser-Kompatibilität wurde nach gründlicher Überlegung auf eine Vorabfestlegung der Entwicklungsziele bewusst verzichtet. Angesichts der Tatsache, dass die Anwendung keine Zielgruppe hat, weil sie nicht produktiv eingesetzt werden soll (sondern ausschließlich eine Hausarbeit mit dem Ziel des Erlernens einer Skriptsprache ist, vgl. Modulhandbuch und Aufgabenstellung), und der Tatsache, dass weder die Aufgabenstellung Browser-Versionen oder Web-Standards auch nur erwähnt noch der Dozent der Lehrveranstaltung trotz mehrmaliger Nachfrage des Projektleiters eine konkrete Antwort gab, wäre die Definition einer Zielumgebung Makulatur.
Statt dessen wird hiermit als Zielvorgabe eine Anwendung der relevanten Web-Standards festgelegt, insbesondere HTML 4.01, HTML5 (soweit stabil), CSS Level 2.1, W3C DOM Level 2 und ECMA 262. Abweichungen von den Standards sind nur zulässig, wenn die abweichende Form verbreitet implementiert ist und messbare Vorteile gegenüber der besten konformen Alternative bietet (wie etwa im Falle der innerHTML-Eigenschaft). Angesichts der fehlenden Interoperabilität bestimmter, älterer dieser Standards wird darüber hinaus gefordert, dass die fertige Web-Anwendung in mindestens drei User-Agents korrekt funktioniert (wobei die graphische Ausgabe nicht notwendigerweise identisch sein muss).
Die Pixel-Anzahl wurde erst nach Fertigstellung des Grafik-Mockups (siehe unten) als mögliches Problem erkannt. Die Größen der einzelnen Grafikelemente begründen jedoch die Vermutung, dass handelsübliche Bildschirme mehr als ausreichend zur scroll-freien Darstellung der Anwendung sein werden. Auf eine Festlegung einer konkreten Ziel-Pixelanzahl wurde daher ebenfalls bewusst verzichtet.
Hinweis [Nachtrag per 28. Januar.]
Das Team ist der Ansicht, dass der Aufgabenstellung und den Antworten des Dozenten auf Nachfragen des Projektleiters hinsichtlich einer vorgegebenen Zielumgebung entsprochen wird. Unter anderem ergibt sich dies aus folgender Argumentation:
Der Dozent stellte per E-Mail vom 6. November 2009 klar, dass die Anwendung „in etwa“ auf „zwei wichtige[n] Browser[n]“ laufen solle. Dabei seien „[d]ie exakten Marktanteile […] nicht wichtig.“ Bei wichtigen Browsern besteht einige Auswahl: So dürfte ohne Frage z. B. der „Marktführer“ Firefox hierzu zählen. Aber auch Chrome und Safari dürften mit schätzungsweise 80 Mio. Nutzern weltweit unstrittig wichtige Browser sein, Opera mit weltweit um die 40 Mio. Nutzern wohl ebenso. Unsere Anwendung wurde auf allen vier genannten User Agents efolgreich getestet, womit die Anforderung gar übererfüllt scheint.
Ferner ist das Team der Ansicht, dass der didaktische Wert einer Fokussierung auf den Internext Explorer zumindest dubios ist. Auch müsste die Ethik einer entsprechenden Anforderung kritisch hinterfragt werden, nachdem die aktuelle Version des Internet Explorer dem Team während des Projektzeitraumes nicht kostenlos zur Verfügung stand und überdies nur auf einem einzigen Betriebssystem funktioniert, was den Grundgedanken des Webs im Hinblick auf dessen Interoperabilität zuwiederläuft. Diese Bedenken unterstützt der Projektleiter als Public Invited Expert der HTML-Arbeitsgruppe des World Wide Web Consortium nachdrücklich.
