ROFL Prog 1

Sorry, couldn't resist to blog this one and didn't found a picture in better quality. There's allready exames preparation time over at switzerland?
[via Prog1-Wiki]

Eclipse ist eine professionelle Software-Entwicklungsumgebung. Die Programmiersprache Java wird von Eclipse standardmässig unterstützt, allerdings existiert mit dem CDT (C/C++ Development Tooling) auch eine Erweiterung für die Entwicklung mit den Programmiersprachen C und C++.
Während in den Eclipse Java Development Tools (JDT) verschiedene Refactorings angeboten werden, steht für CDT erst ein automatisiertes Refactoring zur Verfügung.
Unter Refactoring versteht man eine Vorgehensweise in der Softwareentwicklung bei der die Qualität von Quellcode gesteigert wird, ohne dabei dessen Funktionalität zu verändern. Refactoring reduziert mittelfristig den Aufwand für die Fehleranalyse und für funktionale Erweiterun-gen. Refactorings sind in klar definierte Schritte aufgeteilt. Wenn diese automatisch ausgeführt werden können, erleichtert dies die Arbeit der Entwickler und ist deshalb für Entwicklungs-umgebungen ein starker Wettbewerbsvorteil.

Es sollen verschiedene Refactorings implementiert werden um den Entwicklern ihre Alltagsarbeit zu erleichtern. Die Refactorings sollen möglichst viele Eigenschaften von C++ unterstützen, Kommentare und Makros sollen bei den Codetransformationen behandelt werden und wieder richtig zurückgeschrieben werden. Die bestehende Infrastruktur von Eclipse im Allgemeinen und CDT im Speziellen soll verwendet werden und wo nötig erweitert werden.
Der bestehende Code des CDT wurde so erweitert, dass die Refactorings „Replace Magic Number with Symbolic Constant“, „Move Field“, „Move Method“, „Extract Subclass“ und „Extract Method“ automatisiert möglich sind.
Durch das Erweitern des Parsers und des Abstract-Syntax-Tree war es uns möglich auch von Eclipse CDT nicht behandelte Codestellen zu parsen und korrekt zu erkennen. Durch diese Erweiterung der bestehenden Infrastruktur können nun auch Kommentare und Makros erkannt und während der Durchführung des Refactorings korrekt behandelt werden.
Damit der Code aus dem Abstract-Syntax-Tree wieder in Quellcode umgewandelt werden kann, wurde ein Codegenerator implementiert.
Um die Refactorings effizient zu testen, wurde das Testingframework JUnit so erweitert, dass die Testdefinitionen aus einer Datei gelesen werden können. Um die Testdefinitionen möglichst einfach zu bearbeiten, wurde ein kleiner Editor für Eclipse entwickelt. Mit CruiseControl wurde die von uns angepasste Version von Eclipse CDT bei jeder Änderung getestet und für sieben verschiedene Plattformen übersetzt.
"Studieren nach Punkten" entwickelt sich bei mir momentan grossartig. Nebenstehende Statistik ist zwar mehr Bug als offizielle Ankündigung, lässt aber den Schluss zu das der Diplomarbeit nichts mehr im Wege steht.Für alle die noch im Lernendspurt für "Software Engineering 3" sind habe ich noch einen kleinen Lesetipp. Heiko Maass erklärt in seiner Artikelserie "Generics Gala" die ganze Java 1.5 Generics Geschichte nochmals ausführlich. Ich denke dass diese bei Unklarheiten weiterhilft. Vielen Dank auch nochmals an dieser Stelle.
Vergessen sollte man auch den Artikel "J2SE 5.0 in a Nutshell" nicht. Der Artikel erklärt relativ kurz was in Java 1.5 neu eingeführt wurde und ist auf dem Skripte-Server ein wenig versteckt. (Ich glaube nicht das Java 6.0 gross Prüfungsstoff sein wird. Für alle dies trotzdem noch lernen wollen liegen ein paar Folien auf dem Server oder ein wenig detailiertere Infos ebenfalls im javablog unter "Mustang Mäeutik").
Im Internet würde Bob für den Austausch von Nachrichten einen public key für die Identifikation eines Services auf seinem Server erzeugen und diesen bei einem Entry-Point hinterlegen.Alice erfährt nun über eine geheime Nachricht (Toter Briefkasten, Zitronen Schrift oder anderes was Agenten sonst noch so brauchen um geheime Nachrichten auszutauschen) wo Bob das den Schlüssel hinterlegt hat.
Alice findet einen Hash Wert des Public Key (Schliessschlüssel) und findet den Entry Point von Bob.Alice schickt nun einen Agenten mit einem Erkennungszeichen (Zeitung, Nelke oder ähnliches) an ein zufällig ausgewähltes Büro. Sie sendet das Erkennungszeichen und das Büro zu welchem sie den Agenten geschickt hat, in einer Kiste das mit dem Schlüssel von Bob verschlossen hat, zu. Der AA Agent übergibt das Packet an den schon lange wartende BA Agenten. Dieser bringt das Packet an Bob.
Alice baut eine Verbindung zu einem zufälligen Torserver, dem Rendezvous-Punkt, auf. Damit Bob die Verbindung von Alice erkennen kann erstellt diese ein Rendezvous-Cookie (Erkennungszeichen). Diese Informationen übermittelt sie mit dem öffentlichen Schlüssel von Bob verschlüsselt an Bob's Entry-Point.Wenn Bob nun mit der Verbindung einverstanden ist schickt er den Agenten nun mit dem Erkennungszeichen zu dem Verbindungsbüro von Alice. Nun können die Agenten über dieses Büro Nachrichten austauschen ohne den Standort des jeweils anderen zu kennen.
Beim Rendezvous-Punkt werden, mit Hilfe des Rendezvous-Cookie, die beiden Verbindungen "zusammengeschlossen".Die ganze TOR-Geschichte ohne Agenten gibt’s im Übrigen auch bei Wikipedia.