Eclipse:Seminar SS2010

Aus Eclipse
Version vom 23. Juli 2010, 08:57 Uhr von Thies (Diskussion | Beiträge)

(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu: Navigation, Suche

Seit November 2001 – als IBM der Open-Source-Gemeinde mit der Freigabe von Eclipse ein 40-Millionen-Dollar-Geschenk machte – hat die damals nur als Java-Entwicklungsumgebung gedachte Plattform Eclipse große Entwicklungsschritte gemacht. Nicht zuletzt wegen der durchdachten Architektur und des allgegenwärtigen Plugin-Mechanismus konnten sich diverse Werkzeuge etablieren, welche das Eclipse-Framework als Ablaufplattform nutzen. Neben den Java Development Tools, welche als Beispiel eines besonders gelungenen Plugins gelten können, finden sich sowohl kommerzielle, wie freie Plugins für fast jede Aufgabe der Softwareentwicklung von der Modellierung bis zur Programmierung – längst nicht mehr nur in Java.

Entwickelt man eine Applikation als ein Plugin, sinkt durch die schon gegebene Funktionalität des umgebenden Frameworks der Implementierungsaufwand. Umgekehrt muss vermehrt Aufwand für die Recherche eingeplant werden, wie vorhandene Funktionen genutzt werden können. Im Rahmen dieses Seminars wollen wir oft benötigte Erweiterungspunkte des Eclipse-Frameworks untersuchen und beschreiben. Die Ergebnisse sollen in dem am Lehrgebiet betriebenen Eclipse-Wiki hinterlegt werden, um bei kommenden Fachpraktika und Abschlussarbeiten oft benötigte Informationen an zentraler Stelle vorzuhalten.

Zeitplan

15.3.2010 Themenwünsche Bis zu diesem Datum sollten Sie Ihren Erst-, Zweit- und Drittwünsch für ein Seminarthema in der unten stehenden Themenliste vermerkt haben. Sollte ein Thema von mehreren Teilnehmern gewünscht werden, spielt es keine Rolle, welcher Teilnehmer sich zuerst eingetragen hat. Die Listen werden vor der Themenverteilung zufällig permutiert. Wir werden eine Verteilung anstreben, bei welcher alle Teilnehmer ein Thema mit möglichst hoher Priorität erhalten.
16.3.2010 Bearbeitungsbeginn Bis zu diesem Datum werden Sie ihr Seminarthema zugewiesen bekommen haben und können mit der Bearbeitung beginnen.
13.6.2010 Fertigstellung der Artikel Bis zu diesem Termin müssen Sie Ihre Artikel fertiggestellt haben. Bitte hinterlegen Sie auf Ihrer Benutzerseite eine Zusammenfassung, aus welcher sich ergibt, an welchen Artikeln Sie in welchem Umfang mitgearbeitet haben.
27.6.2010 Ende des Reviews Nach Fertigstellung der Artikel folgt eine Review-Phase. Jeder Teilnehmer bekommt einen Buddy zugewiesen, dessen Artikel er sichtet. Kleinere Korrekturen sollen dabei direkt vorgenommen werden, darüber hinausgehende Kritik soll auf der Diskussionsseite zum jeweiligen Artikel geäußert werden. Zum Ende der Review-Phase erhalten Sie (private) Nachricht von mir, ob Ihre bisherige Arbeit den gestellten Anforderungen genügt und ob Sie zur Präsenzphase zugelassen werden.
11.7.2010 Einpflegen der Review-Kommentare beendet Bis zu diesem Termin sollen alle geäußerten Kritikpunkte auf den Diskussionsseiten der von Ihnen erstellten Artikel abgearbeitet sein.
24.7.2010 Präsenzphase in Hagen Einen Tag lang werden wir in Hagen zusammenkommen, um gegenseitig die Arbeitsergebnisse vorzustellen. Das Seminar wird ab 9 Uhr am Hauptkampus der FernUni, TGZ, Erdgeschoss, Raum F08 stattfinden und bis 18 Uhr andauern.

Teilnehmer

Teilnehmer sind:

Betreut wird das Seminar von Andreas Thies und Jens von Pilgrim.

Schriftliche Ausarbeitung

Im Rahmen eines Seminars ist neben einem mündlichen Vortrag stets auch eine schriftliche Leistung zu erbringen. Ziel dieses Seminars ist der Aufbau eines Wikis, weswegen an dieser Stelle – im Gegensatz zu herkömmlichen Seminaren – leicht geänderte Kriterien Anwendung finden müssen.

Zunächst einmal steht in einem Wiki die gemeinsame Bearbeitung im Vordergrund. Manche der Themen überschneiden sich Thematisch, weswegen hier auch mehrere Teilnehmer gemeinsam an einzelnen Textpassagen arbeiten können und sollen. Um dennoch bei Abschluss des Seminars für jeden Teilnehmer eine individuelle Bewertung abgeben zu können, sind Sie gebeten, auf Ihrer Benutzerseite Ihre Mitarbeit zu dokumentieren, indem Sie eine Liste der von Ihnen erstellten Artikel bzw. Abschnitte hinterlegen. Was den Gesamtumfang Ihrer Mitarbeit insgesamt angeht, werden von Ihnen für alle Artikel zusammen ca. 20 Druckseiten erwartet, was in etwa 80.000 Bytes Wiki-Code, also dem drei- bis vierfachen dieses Artikels entspricht (in der Versionsliste einer Artikels können Sie sehen, wie viele Bytes die aktuelle Version einnimmt).

Auch wenn sich Themen oder Artikel wenig oder gar nicht mit den Themen Ihrer Kommilitonen überschneiden, sollen Sie dennoch von den Möglichkeiten des Wikis profitieren können. Dazu werden sogenannte Buddies eingeführt. Jeder Teilnehmer bekommt einen Buddy zugewiesen, der nach Fertigstellung der Artikel diese liest und zur Verbesserung beiträgt. Bei kleineren Fehlern kann direkt bearbeitet und korrigiert werden, größere Probleme sollten auf der jeweiligen Diskussionsseite des Artikels erörtert werden, so dass der ursprüngliche Autor sich dieser annehmen kann.

Weitere Änderungen im Vergleich mit dem klassischen Seminar ergeben sich für Sie in der Quellenarbeit. Da in einem Wiki zu einem aktuellen Thema vermehrt Informationen zusammengetragen werden, welche mitunter nicht gedruckt publiziert sind, kommen für Sie als Quellen neben gedruckter Basisliteratur (die natürlich am Artikelende zu nennen ist) auch Internettutorials, FAQs oder gar Newsgroups in Frage. Nutzen Sie hier die Möglichkeit der Verlinkung! Eher als bei jeder anderen Form der Veröffentlichung ist bei einer Website der Anreiz für den Leser am höchsten, eine als Link gegebene Quelle zu verfolgen. Enthalten Sie Ihren Lesern diese Chance nicht vor.

Zu guter Letzt ist bei der Benutzung des Wikis noch eine rechtliche Komponente zu beachten: die FernUni legt fest, dass die Inhalte aller FernUni-Wikis unter der der GNU-Lizenz für freie Dokumentation stehen. Fremde Inhalte außerhalb eines zulässigen Zitats in eigenen Artikel wörtlich zu übernehmen, verbietet sich für das wissenschaftliche Arbeiten und somit während dieses Seminars ohnehin. Ein wenig Achtsamkeit ist aber zusätzlich bei Abbildungen gegeben. In gedruckten Arbeiten kann man sich hier mitunter noch auf das Bildzitat berufen. Soweit Abbildungen aber eine gewisse Schöpfungshöhe aufweisen, dürfen wir sie im Wiki nicht ohne weiteres unter GNU-Lizenz stellen. Fertigen Sie im Zweifel bitte eigene Abbildungen an.

Seminarvorträge

Ihre Ergebnisse werden Sie am 24.7.2010 Ihren Mitstudierenden in Form eines Vortrages präsentieren. In Ihrem Seminarvortrag sollen Sie binnen 20-25 Minuten Redezeit einen umfassenden Überblick über das von Ihnen bearbeitete Thema geben, wobei auch kurze Live-Demonstrationen den Vortrag sinnvoll ergänzen können. Stellen Sie sich auf eine anschließende, 10-15 Minuten dauernde Frage- und Diskussionsrunde ein.

Struktur

Der Vortrag sollte klar strukturiert sein. Bei wissenschaftlichen Arbeiten bietet sich meist folgende Grobgliederung an:

  1. Überblick über den Vortrag
  2. Kurze Einführung in das Themengebiet
  3. Klares Herausarbeiten der Problemstellung
  4. Entwicklung der Lösung zu diesem Problem
  5. Zusammenfassung des Vorgetragenen und Bewertung der Ergebnisse
  6. Quellenangaben

Selbstverständlich sind Abweichungen von dieser Struktur möglich, die genannten Punkte sollten aber in jedem Vortrag enthalten sein.

Aufbereitung

Die vortragsmäßige Aufbereitung des Themas erfordert in der Regel folgende Tätigkeiten:

  • Gliedern des Inhalts in kleine Einheiten, die sich für die Darstellung auf einer Folie eignen
  • Anschauliche Darstellung des Themas (z. B. durch Bilder, Diagramme usw.)
  • Finden geeigneter Beispiele (Beispiele sollte kurz, verständlich und aussagekräftig sein.)
  • Zielgruppenorientierung: Der Vortrag sollte auf den Wissensstand der Zuhörenden, also Studierenden in höherem Semester, zugeschnitten sein.

Und noch ein Tipp: Vermeiden Sie die Präsentation längerer Programmpassagen. Sollten Sie auf Programmcode nicht verzichten wollen, so muss auch dieser entsprechend aufbereitet werden, indem nur die wesentlichen Teile gezeigt werden. Meist genügt es, sogenannten Pseudocode zu zeigen, der nur die Essenz des Programms enthält.

Folien

Um die Zuhörenden nicht nur auditiv, sondern auch visuell anzusprechen, sind Folien meist das geeignete Medium. Dabei gilt es einige Grundsätze zu beachten:

  • Jede Folie sollte inhaltlich eine abgeschlossene Einheit bilden. Sie trägt eine Überschrift, die genau den Inhalt der Folie wiedergibt.
  • Folien sollen nur Stichworte enthalten. Das Publikum kann nicht gleichzeitig Ihren Ausführungen folgen und ausformulierte Sätze lesen.
  • Folien müssen übersichtlich sein: Packen Sie nicht zuviel auf eine Folie, sonst kann sich der Zuhörende nicht darauf zurechtfinden. Mehr als fünf Stichpunkte sollten es nicht sein.
  • Benutzen Sie eine ausreichend große Schrift, damit auch Zuhörende in den hinteren Reihen den Text mühelos lesen können.
  • Verwenden Sie nicht zu viele Folien. In der Regel dauert die Präsentation einer Folie zwischen zwei und drei Minuten. Als Richtschnur für einen 30 minütigen Vortrag gelten daher ca. 15 Folien.

Vortrag

Der Vortrag selbst soll etwa 20-25 Minuten dauern. Eine Einführung in die Vortragstechnik würde hier zu weit führen, weshalb wir nur auf einige häufig auftretende Fehler aufmerksam machen:

  • Sprechen Sie ruhig und deutlich.
  • Versuchen Sie, Kontakt zum Publikum herzustellen. Dadurch bemerken Sie, ob Ihnen die Zuhörenden folgen können. Wenden Sie sich auf keinen Fall der Projektionsfläche zu.
  • Gehen Sie auf Fragen ein. Fragen während des Vortrages sind nicht als lästige Unterbrechung zu verstehen, sondern weisen meist darauf hin, dass Sie einen Punkt noch deutlicher erklären müssen.

Themenliste

Folgende Seminarthemen stehen Ihnen zur Bearbeitung zur Auswahl. Die angegebene Literatur ist dabei jeweils nur als erster Einstieg zu werten; siehe dazu auch den Abschnitt zur schriftlichen Ausarbeitung.

Eclipse Plugins (Bearbeitet von Gabriel Wetzler)

Das Equinox-Komponentenmodell bildet das Grundgerüst zu Eclipse. Jede Erweiterung zu Eclipse erfolgt in Form einer eigenen Komponente – eines Plugins – womit man bei der Erweiterung von Eclipse zwangsläufig in Kontakt mit den Details der Komponenteninteraktion gerät. Im Rahmen dieses Themas soll in mehreren Wiki-Artikeln dargestellt werden, wie sich Plugins über Extension Points den Kontrollfluss übergeben, was das „Hollywood-Prinzip“ ist, wie und wo Extensions und Extension Points deklariert werden, wie die Plugin-Struktur die Sichtbarkeit auf Java-Pakete einschränken kann (aber nicht soll), wie sich der Lebenszyklus eines Plugins gestaltet (Lazy Evaluation) und was ein Activator ist.

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

Refactoring und Refactoring-Tools in Eclipse (Bearbeitet von Eduard Unger)

In der aktuellen Version bietet Eclipse an die 30 Refactoring Tools an. Durch den sehr ähnlichen Ablauf (zu refaktorisierendes Element auswählen, Parameter spezifizieren, Vorschau und Durchführung) bietet sich ein Framework an, in welches die Refactoring Tools eingebettet sind und welches immer gleiche Aufgaben (z.B. die Vorschau) übernimmt. In Eclipse erfolgt dies innerhalb des Language Toolkit (LTK). Im Rahmen dieses Themas sollen Artikel erstellt werden, welche zweierlei leisten. Einerseits soll erklärt werden, wie die schon vorhandenen Refactoring Tools innerhalb anderer Plugins nutzbar gemacht werden können, also welche Klassen relevant sind, wie Refactoringparameter übergeben werden können und wie Erfolg oder Misserfolg eines durchgeführten Refactorings ermittelt werden kann. Andererseits soll aufgezeigt werden, wie eigene Refactoring Tools entwickelt werden. Welche Schnittstellen sind zu implementieren? Welche Verträge einzuhalten?

Zeichnen in Eclipse (Bearbeitet von Alexandru Dratva)

Viele Anwendungen in Eclipse benötigen einen graphischen Editor, zumeist um Diagramme darzustellen. Mit dem Graphical Editing Framework (GEF) bietet Eclipse eine komfortable Grundlage für die Implementierung solcher Editoren. GEF baut dabei auf dem Model-View-Controller-Muster (MVC) auf, welches im Rahmen dieses Seminarthemas zunächst kurz eingeführt werden soll. Weiterhin ist es Aufgabe, GEF und das zugrunde liegende Draw2D in eigenen Artikeln darzustellen sowie auch praktisch zu zeigen, wie typische Diagrammkomponenten gezeichnet werden können. Ebenso soll auch auf GEF3D eingegangen werden.

JUnit in Eclipse (Bearbeitet von Christian Nölke)

Tests und insbesondere Unit-Tests sind unerlässlich für die Softwareentwicklung. Im Rahmen dieses Themas sollen Artikel angelegt werden, welche die JUnit-Integration innerhalb von Eclipse zum Thema haben. Insbesondere soll erklärt werden, wie man JUnit erweitern kann, innerhalb anderer Plugins JUnit-Tests auslösen kann und die Testergebnisse intern ausliest.

Der Workspace (nicht bearbeitet)

Der Workspace ist die Basis aller in einer Eclipse-Instanz verfügbaren Ressourcen und ist eng an das zugrunde liegende Dateisystem gekoppelt. Zu diesem Seminarthema sollen Artikel angelegt werden, die Beschreiben, wie der Workspace aufgebaut ist, welche Arten von Elementen er enthält und was für Attribute seine Elemente haben können. Dies umfasst besonders die Erklärung des Umgangs mit den Typen IWorkspace, IResource, IProject, IJavaProject. Auch soll geklärt werden, wie auf Dateisystemebene Änderungen vorgenommen werden können (z.B. Kopieren von Projekten).

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

Dokumentation und Hilfe (Bearbeitet von Tobias Kastl)

Auch die pfiffigste Programmfunktion nützt dem Endanwender nichts, wenn er sie entweder nicht versteht oder nicht findet. Heutige Anwendungsprogramme leben davon, dass sie ohne gedrucktes Handbuch auskommen und sich dafür innerhalb der Programmoberfläche selbst dokumentieren. Eclipse bietet hierzu reichlich Gelegenheit. In mehreren Artikeln soll für dieses Thema dargestellt werden, wie dem Benutzer Hilfe angeboten werden kann; dies umfasst die klassische Hilfe ebenso, wie kontextabhängige Hilfefenster. Weiterhin soll dokumentiert werden, wie Update-Sites aufgesetzt werden und welche Arten des Brandings in Eclipse möglich sind.

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

C/C++ in Eclipse (nicht bearbeitet)

Längst ist Eclipse keine reine Java-IDE mehr. Seit Version 3 und dem Schritt zu einer Plugin-Architektur sind Java-spezifische Funktionen in eigene Komponenten – den sogenannten Java Development Tools – ausgelagert, was den Weg für eine Unterstützung weiterer Programmiersprachen geebnet hat. Im Rahmen dieses Seminarthemas soll die C/C++-Unterstützung in Form der C Development Tools (CDT) abgeklopft werden. Insbesondere soll darauf eingegangen werden, wie Zugriff auf den C-Quelltext aktiver Editoren vorgenommen werden kann und wie Zugriffe auf den abstrakten Syntaxbaum geschehen können. Darüber hinaus sollte auch kurz auf die Refactoring Tools innerhalb der CDT eingegangen werden, welche genau diese Art von Zugriff auf den Quellcode benötigen.

Python in Eclipse (Bearbeitet von Alexander Bürger)

Mit dem Plugin PyDev kann Eclipse um Unterstützung für die Programmiersprache Python erweitert werden. Im Rahmen dieses Seminarthemas sollen Informationen darüber gesammelt werden, wie Erweiterungen von PyDev Zugriff auf Editoren, Syntaxbaum usw. erhalten können. Da es mit jython eine Python-Implementierung in Java gibt, soll darüber hinaus zumindest kurz auch auf die Erweiterbarkeit von PyDev mit Python eingegangen werden.

Interaktion mit dem Benutzer (Bearbeitet von Timo Vogel)

Eclipse bietet viele Möglichkeiten, dem Benutzer Informationen darzustellen. Die direkteste Form der Rückmeldung bieten Popup-Fenster, für erweiterte Interaktionsmöglichkeiten kommen mehrschrittige Dialoge (Wizards) in Frage. Sollen Benutzereingaben mehrfach Verwendung finden, bieten sich Preference Pages und Property Pages an. Die Verwendung all dieser soll im Rahmen dieses Seminarthemas Eingang ins Eclipse-Wiki finden.

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

Menüs, Views, Perspectives und Run Configurations (nicht bearbeitet)

In Eclipse besteht für Plugins eine Vielzahl von Möglichkeiten, innerhalb der IDE sichtbar zu werden. Einerseits soll zu diesem Thema ausführlich geklärt werden, in welchen Menüs unter welchen Bedingungen Einträge gemacht werden können (so beispielweise Kontextmenüeinträge im Explorer, Werkzeugleisten, „show in“- und „refactor“-Submenüs…). Darüber hinaus soll dargestellt werden, wie Plugins eigene Views und Perspectives in die IDE einbringen können und wie ein Plugin eigene Run-Configurations beisteuern kann.

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

Builder, Natures, Marker und Quick Fixes (Bearbeitet von Siegfried Bereuter)

Die Stärke der Java Development Tools resultiert zu einem guten Teil aus dem inkrementellen Compiler, welcher beim Hinzufügen von Ressourcen oder Änderungen am Code unmittelbar angestoßen wird. Solche Dienste sind in Eclipse als Builder bekannt und werden über Natures mit bestimmten Projekten assoziiert. Die Kommunikation mit dem Benutzer erfolgt über Marker, die direkt im Quellcode angezeigt werden können. Auf Wunsch kann dem Benutzer mit so genannten Quick Fixes direkt die Möglichkeit zur Reaktion gegeben werden. Zu diesem Seminarthema soll beantwortet werden, wie man eigene Builder implementiert und entsprechende Natures auf Projekte anwendet und wie Marker erstellt, optisch gestaltet und mit Quick Fixes versehen werden können.

  • Literatur: Clayberg, Rubel: Eclipse Plug-ins (3rd Edition)

Eigenes Thema

Haben Sie eigene Ideen für ein Seminarthema? Ich freue mich über einen Vorschlag per Email.

Themenwahl

Sie können bei der Themenwahl einen Erst-, Zweit-, und Drittwunsch äußern. Dazu tragen Sie bitte in der folgenden Liste Ihren Benutzernamen an den entsprechenden Stellen insgesamt dreimal ein (jeweils einmal hinter Erstwahl, Zweitwahl und Drittwahl). Sollte bereits ein anderer Teilnehmer denselben Wunsch geäußert haben (also z.B. Zweitwahl bei Zeichnen in Eclipse) setzen Sie Ihren Benutzernamen dahinter. Ob Sie oder Ihr Kommilitone den Wunsch zuerst geäußert hat, spielt keine Rolle; die Reihenfolge wird vor Themenvergabe permutiert.

  • Eclipse Plugins
    • Erstwahl: kastl, bereuter
    • Zweitwahl: buerger,wetzler
    • Drittwahl:dratva, unger, vogel
  • Refactoring Tools in Eclipse
    • Erstwahl: unger,wetzler
    • Zweitwahl:
    • Drittwahl:
  • Zeichnen in Eclipse
    • Erstwahl:
    • Zweitwahl:dratva
    • Drittwahl:
  • JUnit in Eclipse
    • Erstwahl: buerger, vanporten
    • Zweitwahl: unger, Bedyk
    • Drittwahl: noelke,wetzler
  • Der Workspace
    • Erstwahl:
    • Zweitwahl:bereuter
    • Drittwahl: Bedyk
  • Dokumentation und Hilfe
    • Erstwahl: noelke, vogel
    • Zweitwahl: kastl
    • Drittwahl:
  • C/C++ in Eclipse
    • Erstwahl: dratva, Bedyk
    • Zweitwahl: vanporten
    • Drittwahl: buerger
  • Python in Eclipse
    • bearbeitet von Alexander Bürger (eigener Vorschlag)
  • Interaktion mit dem Benutzer
    • Erstwahl:
    • Zweitwahl: noelke, vogel
    • Drittwahl: kastl
  • Menüs, Views, Perspectives und Run Configurations
    • Erstwahl:
    • Zweitwahl:
    • Drittwahl: vanporten
  • Builder, Natures, Marker und Quick Fixes
    • Erstwahl:
    • Zweitwahl:
    • Drittwahl: bereuter

Buddies

Jeder Seminarteilnehmer wird ab dem Abgabetermin am 13.6 von einem Buddy begleitet. Die Buddies sollen gegenseitig ihre Artikel sichten und Verbesserungsvorschläge machen. Kleinere Korrekturen sollen dabei direkt auf den Wiki-Seiten vorgenommen werden, darüber hinausgehende Kritik soll auf der Diskussionsseite zum jeweiligen Artikel geäußert werden. Die Buddies sind folgendermaßen aufgeteilt: