Warning: Constant ABSPATH already defined in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php on line 28
Warning: Cannot modify header information - headers already sent by (output started at /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-config.php:28) in /customers/e/7/0/florian-oeser.de/httpd.www/wordpress/wp-includes/feed-rss2.php on line 8
Name: Florian Oeser
Matrikelnummer: 780586
Gruppe: B
eMail: florian.oeser(at)gmail.com
Wolfinger, Reinhard, et al. „Adding genericity to a plug-in framework.“ ACM SIGPLAN Notices.Vol. 46. No. 2. ACM, 2010.
Im Bereich der Softwareentwicklung spricht man von einem Plug-in, wenn eine oder mehrere Softwarekomponenten eine bestehende Anwendung um eine bestimmte Funktionalität erweitern (ohne Neustart). Dadurch lassen sich Anwendungen optimal und kosteneffizient skalieren.
Im Kern basiert das Paper auf einem Plug-in Framework für Microsoft .NET, welches ebenfalls von einem Teil der Autoren entwickelt wurde. Das Plux.NET getaufte Framework ermöglicht Software-Kompositionen durch eine Art „Plug & Play“-Mechanismus.
Plux.NET definiert ein Kompositionsmodel und führt dabei die „Slot & Plug“-Metapher ein. Ein Slot spezifiziert einen Vertrag (Interface) und eine Liste von Parametern mit deren Namen und Typen. Dies geschieht deklarativ über .NET-Attribute (Metadaten), welche später zur Laufzeit über Reflection ausgelesen werden können. Ein Plug stellt eine konkrete Implementierung des korrespondierenden Slot-Interfaces dar. Die Angabe des passenden Slots sowie die Angabe konkreter Parameterwerte, geschieht wieder deklarativ.
Plux.NET selbst ist Plug-in basiert. Das bedeutet, das die eigene Anwendung ebenfalls als Plug-in implementiert werden muss. Das Framework definiert einen entsprechenden Slot (Interface), welcher mit einem passenden Plug in der eigenen Anwendung implementiert wird. Wird nun Plux.NET gestartet, sucht dieses nach eben solchen Plug’s und startet seinerseits die eigentliche Anwendung, da diese den besagten Slot implementiert hat. Weiterhin muss die Anwendung einen Slot definieren (öffnen), welches wieder einen konkreten Plug aufnehmen kann. Findet nun das Plux.NET-Framework zur Runtime ein entsprechendes Plug, welches zu dem definierten Slot passt, wird dieses geladen und der Anwendung übergeben. Der Anwendung wurde also ein Plug-in hinzugefügt.
Zusammenfassend besitzt Plux.NET ein Kompositionsmodel, welches eine Anwendung aus Komponenten zusammenfügt, welche wiederum aus einer definierten Anforderung (Slot) und einer passenden Implementierung (Plug) bestehen. Das Framework verbindet diese automatisch anhand der deklarierten Metadaten.
Sollen nun aber Komponenten an unterschiedlichen Stellen oder zu unterschiedlichen Zwecken in der Anwendung zum Einsatz kommen (wiederverwendet werden), bräuchte man verschieden ausgeprägte Metadaten. Beispielsweise könnte man sich zwei Grids in zwei verschiedenen Views vorstellen, welche beide wiederum an zwei verschiedene Datenquellen gebunden werden sollen. Implementiert man die Grid’s als Slot’s und die Datenquellen als Plug’s, würde das Kompositionsmodel automatisch beide Datenquellen an beide Grid’s binden. Dies ist nicht gewünscht, schließlich sollte das Grid in einer bestimmten View auch nur an die für es vorgesehene Datenquelle gebunden werden.
Die Plug’s müssten also selektiv mit den Slot’s verbunden werden. Ohne einen generischen Ansatz müssten die Kompositionen programmatisch definiert werden. Es wäre auch denkbar die Metadaten anzupassen und für jede View ein spezifisches Grid (Slot) zu definieren, zu welchem dann nur genau eine Datenquelle (Plug) implementiert ist. Beide Wege wären mit dem Plux.NET-Framework möglich, sind aber aus vielen Gründen ungeeignet. Beispielsweise würde das Anpassen der Metadaten immer auch zur Folge haben, das neue Subklassen (für die jeweiligen Slots/Plugs) angelegt werden müssten, obwohl eben eine Änderung der Metadaten hinreichend wäre.
Die Autoren beschreiben in ihrem Paper einen Template-basierten Ansatz für die Metadaten, welcher ebenfalls im Plux.NET-Framework implementiert wurde. Die entsprechenden Slot- und Plugnamen und die Parameterwerte werden mit Platzhaltern ersetzt. Die Metadaten sind somit unvollständig und werden erst zur Laufzeit parametrisiert, sobald eine Komponente verbunden wird und deren konkrete Ausprägung bekannt ist. Die Informationen darüber können aus einer externen Quelle wie einer Konfigurationsdatei stammen.
Ausarbeitung Beta
Adding genericity to a plug-in framework (.pdf, 438KB)
Ausarbeitung Final
Adding genericity to a plug-in framework (.pdf, 325KB)
Präsentation
Link zur Präsentation in Google Docs
Adding genericity to a plugin framework_Präsentation_Florian Oeser (.pdf, 527KB)
Name: Florian Oeser; Matrikelnummer: 780586; eMail: florian.oeser(at)gmail.com
]]>Inhalt dabei ist zunächst ein Firmenprofil welches die Firma und deren Entwicklungen, in unserem Fall CasualGames, beschreibt. Danach gehen wir auf die in der SE allgemein üblichen Qualitätssicherungsmaßnahmen, wie beispielsweiße den Betatest, ein. Folgend versuchen wir drei, für die Spieleentwicklung wichtige, Qualitätsmerkmale zu operationalisieren: DDD (Detailed Design Document), Spielspaß u.A. mit Hilfe eines Questionnaires und zu guter Letzt das allgemein hin bekannte QM-Merkmal Korrektheit.
QM-Handbuch (.pdf, 652KB)
Der zweite Übungsteil bestand darin verschiedene Softwaremetriken auf ein Code Snippet anzuwenden und hat nix direkt mit dem Handbuch zu tun. Wer sich aber auch dafür interessiert oder eine Vorlage braucht ist mit Folgendem gut beraten. Untersucht wurden LOC (Lines of Code), die Halstead-Metrik, Zyklomatische Komplexität nach McCabe und verschiedene Codeüberdeckungsgrade.
Metriken (.pdf, 1.284MB)
Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!
]]>Bestandteil der Arbeit ist weiterhin ein Kommunikationsprotokoll, welches den Ablauf der Übertragung regelt bzw. beschreibt. So wird in diesem Dokument unter anderem geklärt, wie die zu übertragenden Metadaten auszusehen haben oder wie mit eventuell auftretenten Fehlern umzugehen ist. Das sichert eine stabile und fehlerfreie Bildübertragung ab.
Die Umsetzung war nicht immer ganz einfach und es gab einige Tücken zu überwinden. Gerade die im Protokoll beschrieben Timeouts machten mir anfangs Sorgen und es dauerte bis ich eine entsprechende Lösung gefunden bzw. auch richtig umgesetzt hatte. Es gab zwar hier und da auch noch ein paar andere Probleme, welche aber meist auf die eingerosteten C-Kenntnisse und deren Kniffe meinerseits zurückzuführen waren. Auch egal nun bin ich ja fertig, es läuft alles perfekt und man ist wieder eine Erfahrung reicher geworden
Hier nun der Source, das Kommunikationsprotokoll und direkt auch das MonoDevelop-Projekt:
C-Socket Server/Client zur Bildübertragung (.rar, 250KB)
Interessante/Weiterführende Links zum Thema
Client-Server Socketprogrammierung
Tipps zur Socketprogrammierung
Helmut Herold – Linux/Unix-Systemprogrammierung
Wie immer keine Garantie auf Richtigkeit der Vollständigkeit!
]]>
Aufgabenstellung war es, verschiedene Interaktionselemente bzw. Dialoge, durch ein freigewähltes Usability-Testverfahren auf Aspekte wie Form, Farbwahl, Positionierung etc. hin zu überprüfen. Die Ergebnisse wurden in einem Prüfprotokoll festgehalten welches diese Aspekte bewertet, kommentiert und Verbesserungsvorschläge aufzeigt.
Dieses Prüfprotokoll und die Präsentation möchte ich euch wieder zum freien Download zur Verfügung stellen.
Analyse eBay.de (.rar, 1,2MB)
Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!
]]>Wir möchten euch die Präsentation und das Handout zum freien Download zur Verfügung stellen.
Inhalt der Präsentation und des Handout’s ist die kurze Vorstellung beider Modelle sowie der eigentliche Vergleich.
Präsentation + Handout (.zip, 224KB)
Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!
]]>Inhalt sind verschiedene Definitionen von Software-Ergonomie, Regeln, die Softwareergonomische Relevanz haben und deren Anwendung/Analyse auf die Webseite von google.de
HCI-Analyse zu google.de (.pdf, 55KB)
Wie immer keine Garantie auf Richtigkeit oder Vollständigkeit!
]]>Von diesen Themes gibt es viele und ich möchte euch einfach mal meine kleine Auswahl präsentieren. Bilder findet ihr dann auf den entsprechenden Link:
Diese beiden Themes sind nur für 2005!Jedoch findet ihr auf dem Blog auch einen Post wo die Portierung beschrieben wird.
Ragnarok Grey/Blue
Alle Themes wurden von Tomas Restrepo erstellt. Vielen Dank dafür!
Das Theme in VS wird über Tools->Import and Export Settings importiert.
Im übrigen verwende ich Schriftgröße 8. Diese ist ‚platzsparend‘ aber zugleich noch gut lesbar. Als Schrift verwende ich entweder ‚Courier New‘ (default) oder ‚Verdana‘. Letzteres wegen dem Buchstabenabstand und weil ähnlich geformte Buchstaben gut zu unterscheiden sind!
]]>Wir haben ebenfalls eine Präsentation für den Vortrag ausgearbeitet, die ich auf Anfrage euch auch zukommen lassen kann.
In diesen Sinne viel Spass beim Lesen
Semesterarbeit: Web 2.0 und Ajax (.pdf, 558KB)
Keine Garantie auf Richtigkeit/Vollständigkeit!
]]>