Gestaltung von Kooperationsmodulen für Ruby on Rails

Transcription

Gestaltung von Kooperationsmodulen für
Ruby on Rails
Bachelorarbeit
Vorgelegt von:
Bernd Biedermann
Matr. Nr: 6983499
Ausgefertigt am:
Lehrgebiet Kooperative Systeme
FernUniversität in Hagen
Eingereicht bei:
Dr. Till Schümmer
Juni 2009
Hiermit versichere ich, dass ich diese Arbeit selbstständig verfasst, und keine anderen,
als die angegebenen Quellen und Hilfsmittel benutzt, sowie Zitate kenntlich gemacht
habe.
Alle zitierten Internetseiten beziehen sich, so nicht anders angegeben, auf die
Versionen des Monats Mai 2009.
Alle Bilder, die mit keiner Quellenangabe versehen sind, wurden vom Verfasser selbst
erstellt.
Hohenems, 15.6.2009
2009-09-10
Bernd Biedermann
2/107
Inhaltsverzeichnis
Gestaltung von Kooperationsmodulen für Ruby on Rails ............................................. 1 1 Einleitung ............................................................................................................... 7 1.1 Motivation ....................................................................................................... 7 1.2 Aufgabenstellung ............................................................................................ 8 1.3 Übersicht ......................................................................................................... 8 2 Anforderungsanalyse ........................................................................................... 10 2.1 Webbasierte Groupware Anwendungen........................................................ 10 2.2 Analyse der Entwurfsmuster ......................................................................... 12 2.2.1 Groupware und Group Awareness ......................................................... 12 2.2.2 Entwurfsmuster ...................................................................................... 12 2.2.3 Ermittlung der wichtigsten Entwurfsmuster .......................................... 13 2.3 Einzelne Module ........................................................................................... 22 2.4 Elemente sollen sich nahtlos in die Rails Architektur einbinden lassen ....... 23 2.5 Verwendbarkeit ............................................................................................. 24 2.6 Konfigurierbarkeit ......................................................................................... 25 2.7 Codebasis ...................................................................................................... 26 2.8 Zusammenfassung der Anforderungen ......................................................... 26 3 State of the Art ..................................................................................................... 27 3.1 Untersuchung von existierenden Plug-Ins..................................................... 27 3.1.1 Plug-Ins für Synchrone Zusammenarbeit .............................................. 27 3.1.2 Andere Plug-Ins ..................................................................................... 29 3.1.3 Zusammenfassung.................................................................................. 31 3.2 Untersuchung von Open Source Anwendungen ........................................... 32 3.3 Eignung und Defizite bestehender Lösungen für Module ............................ 35 3.4 Fazit ............................................................................................................... 35 4 Beschreibung der Lösungsidee ............................................................................ 36 4.1 Gesamtkonzept und Aufbau der Anwendung, Plug-Ins ................................ 36 4.2 Umsetzung der Entwurfsmuster in Plug-Ins ................................................. 37 4.3 Verwendbarkeit ............................................................................................. 38 4.4 Konfigurierbarkeit ......................................................................................... 39 4.5 Synchronizität................................................................................................ 40 4.6 Modelle.......................................................................................................... 40 5 Details zur Lösung ............................................................................................... 42 5.1 Allgemein ...................................................................................................... 42 5.2 Realisierung der Entwurfsmuster .................................................................. 43 5.2.1 Basisprojekt (Quick Registration, Login, Quick Goodbye) ............. 43 5.2.2 Plug-In cmi_virtual_me (Virtual Me, Availability Status) ................ 45 5.2.3 Plug-In cmi_user_gallery (User Gallery) ............................................. 50 5.2.4 Plug-In cmi_buddy_list (Buddy List, Spontaneous Collaboration) . 52 5.2.5 Plug-In Simple Groups (Group) .............................................................. 56 5.2.6 Plug-In Attachment Fu (Shared File Repository) ............................... 57 5.2.7 Plug-In cmi_room (Room, Bell, Invitation, Spontaneous Collaboration,
User List, Interaction Directory) .......................................................................... 58 5.2.8 Plug-In cmi_message ............................................................................. 62 5.2.9 Plug-In cmi_embedded_chat (Embedded Chat).................................. 64 5.2.10 Plug-In cmi_juggernaut_connection ...................................................... 67 5.2.11 Plug-In cmi_interactive_user_info (Interactive User Info) ................ 68 5.2.12 Plug-In acts_as_versioned (Immutable Versions, Activity Log) ....... 70 2009-09-10
3/107
5.2.13 Plug-In cmi_coll_session (Collaborative Session, User List) ........... 72 5.2.14 Plug-In cmi_remote_subscription (Remote Subscription)..................... 74 5.2.15 Plug-In Juggernaut (Mediated Updates) ............................................. 76 5.3 Weitere Plug-Ins ............................................................................................ 77 5.3.1 Plug-In cmi_user_avatar ........................................................................ 77 5.3.2 Plug-In demo_bike_guide ...................................................................... 79 5.3.3 Plug-In Restful Authentication .............................................................. 80 5.3.4 Plug-In acts_as_state_machine .............................................................. 81 5.3.5 Plug-In Rails Widgets (Tooltips) ........................................................... 83 5.4 Eine Anwendung erstellen ............................................................................ 84 6 Zusammenfassung.............................................................................................. 100 6.1 Wie wurde die Aufgabenstellung gelöst?.................................................... 100 6.2 Ausblick ...................................................................................................... 101 7 Quellenverzeichnis ............................................................................................. 102 2009-09-10
4/107
Abbildungsverzeichnis
Abb. 1: Kategorien von Webanwendungen (Kappel et al 2004, S. 7) ......................... 10 Abb. 2: Hauptbestandteile von Groupware und deren ................................................. 12 Abb. 3: CURE Login Screen ....................................................................................... 14 Abb. 4: Google Docs, Documents ............................................................................... 14 Abb. 5: Facebook Login Screen................................................................................... 15 Abb. 6: ebay Produktsuche (Quelle: http://www.ebay.com/) ...................................... 15 Abb. 7: Skype (Version 3.8.0.188) .............................................................................. 16 Abb. 8: El Dorado, Demo Seite (Quelle: http://eldoradoapp.com/) ............................ 16 Abb. 9: Thetis Demo, Desktop (Quelle: http://sysphonic.com/thetis/) ........................ 17 Abb. 10: eXPlain PMT, Dashboard (Version: 20070423.0) ........................................ 17 Abb. 11: Boxroom Folder ............................................................................................ 18 Abb. 12: Entwurfsmuster und deren Beziehungen zueinander (Vorauswahl) ............. 20 Abb. 13: Model, View, Controller ............................................................................... 23 Abb. 14: Klassen und Tabellen .................................................................................... 24 Abb. 15: Plug-Ins ......................................................................................................... 38 Abb. 16: Modelle und deren Beziehungen zueinander ................................................ 41 Abb. 17: Basisprojekt Abhängigkeiten ........................................................................ 43 Abb. 18: cmi_virtual_me Abhängigkeiten ................................................................... 45 Abb. 19: Virtual Me mit aufgeklapptem Tooltip und Edit user data ........................... 47 Abb. 20: Availability Status ......................................................................................... 48 Abb. 21: Availability State Zustandsdiagramm ........................................................... 49 Abb. 22: cmi_user_gallery Abhängigkeiten ................................................................ 50 Abb. 23: User Gallery mit geöffnetem Tooltip ............................................................ 52 Abb. 24: cmi_buddy_list Abhängigkeiten ................................................................... 53 Abb. 25: Buddy List mit geöffnetem Tooltip .............................................................. 54 Abb. 26: Buddy List Zustandsdiagramm ..................................................................... 55 Abb. 27: Attachment Fu Abhängigkeiten .................................................................... 57 Abb. 28: cmi_room Abhängigkeiten............................................................................ 59 Abb. 29: Manage Rooms ............................................................................................. 61 Abb. 30: User List ........................................................................................................ 61 Abb. 31: CmiRoom Zustandsdiagramm ...................................................................... 62 Abb. 32: cmi_message Abhängigkeiten ...................................................................... 63 Abb. 33: Message Board aufgeklappt mit Anzeige einer neuen Nachricht ................. 64 Abb. 34: cmi_embedded_chat Abhängigkeiten ........................................................... 65 Abb. 35: Chat Board mit aufgeklapptem Tooltip ........................................................ 67 Abb. 36: cmi_interactive_user_info Abhängigkeiten .................................................. 69 Abb. 37: cmi_coll_session Abhängigkeiten ................................................................ 72 Abb. 38: Session State View ........................................................................................ 73 Abb. 39: cmi_remote_subscription Abhängigkeiten ................................................... 74 Abb. 40: Erstellen einer Remote Subscription ............................................................. 75 Abb. 41: cmi_user_avatar Abhängigkeiten.................................................................. 77 Abb. 42: Restful Authentication Abhängigkeiten ........................................................ 80 Abb. 43: acts_as_state_machine Nonprofit (Quelle:
http://www.ibm.com/developerworks/java/library/j-cb03137/figure1.gif ) ................ 82 Abb. 44: Login Screen von CURE und Zugang zu CURE beantragen ....................... 84 Abb. 45: Login Screen und Signup (Zugang beantragen) von Cooperation................ 85 Abb. 46: Schritt 1: Modelle und Beziehungen............................................................. 85 2009-09-10
5/107
Abb. 47: Benutzerprofil editieren in CURE ................................................................ 86 Abb. 48: CMI Plug-In Virtual Me mit aufgeklapptem Tooltip ................................... 86 Abb. 49: Schritt 2: Modelle und Beziehungen............................................................. 87 Abb. 50: Buddy-Liste in CURE ................................................................................... 88 Abb. 51: CMI Buddy List ............................................................................................ 88 Abb. 52: Schritt 3: Modelle und Beziehungen............................................................. 89 Abb. 53: Raum und Seite in CURE ............................................................................. 90 Abb. 54: CMI Room .................................................................................................... 91 Abb. 55: Schritt 4: Modelle und Beziehungen............................................................. 91 Abb. 56: Seite in CURE im Edit Mode ........................................................................ 92 Abb. 57: CMI Room mit Inhalt.................................................................................... 93 Abb. 58: Schritt 5: Modelle und Beziehungen............................................................. 94 Abb. 59: Mailing List in CURE ................................................................................... 95 Abb. 60: CMI Message Board ..................................................................................... 95 Abb. 61: Schritt 6: Modelle und Beziehungen............................................................. 97 Abb. 62: User List in CURE, Quelle:(Schümmer 2006, S. 13) ................................... 98 Abb. 63: CMI User List und Collaborative Session State ........................................... 98 Abb. 64: Schritt 7: Modelle und Beziehungen............................................................. 99 Tabellenverzeichnis
Tabelle 1: Ergebnis der Untersuchung nach der Vorauswahl ...................................... 19 Tabelle 2: Auswahl der zu implementierenden Entwurfsmuster ................................. 21 Tabelle 3: CanHasChat (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) .......................... 27 Tabelle 4: ActiveMessaging (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) .................. 28 Tabelle 5: Juggernaut (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)............................. 29 Tabelle 6: Restful Authentication (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) .......... 29 Tabelle 7: Simple Groups (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) ...................... 30 Tabelle 8: Attachment Fu (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) ...................... 31 Tabelle 9: acts_as_versioned (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt) ................. 31 Tabelle 10: El Dorado .................................................................................................. 32 Tabelle 11: Thetis ........................................................................................................ 33 Tabelle 12: eXPlain PMT ............................................................................................ 34 Tabelle 13: Boxroom ................................................................................................... 34 Tabelle 14: Implementierte Entwurfsmuster ............................................................... 37 Tabelle 15: Konfigurationsmöglichkeiten der Plug-Ins ............................................... 40 2009-09-10
6/107
Einleitung
1 Einleitung
1.1 Motivation
Das Web 1 gewinnt immer mehr an Bedeutung, sei es im Alltag, im Geschäftsleben,
oder in der Weiterbildung. In (Kappel et al 2004, S. 1) wird die Ursache für diese
Tendenz wie folgt begründet:
"Der Grund für diese Omnipräsenz liegt insbesondere in der Natur des Web,
die gekennzeichnet ist durch globale und permanente Verfügbarkeit sowie
komfortablen und einheitlichen Zugriff auf beliebig verteilte, von jedermann
erstellbare Informationen in Form von Webseiten."
Nicht zuletzt aufgrund dieser ständigen Verfügbarkeit entwickelte sich aus einem zum
großen Teil aus relativ statischen html-Seiten bestehende Web das Web 2.0, das
(O'Reilly 2006) so beschreibt:
"Web 2.0 is the business revolution in the computer industry caused by the
move to the Internet as a platform, and an attempt to understand the rules for
success on that new platform."
Diese Entwicklung des Webs hin zu einer Plattform hat zur Folge, dass der Bedarf für
Groupware-Anwendungen 2 ständig steigt.
Das Web-Framework Ruby on Rails 3 ist aufgrund seiner Flexibilität, seiner
Erweiterbarkeit und seiner einfachen Handhabung sehr gut für die Entwicklung eines
Web-basierten kollaborativen Systems geeignet. Für das Framework steht eine große
Zahl von Plug-Ins 4 bereit, die Rails auf viele verschiedene Arten erweitern, und auf
die für die Entwicklung eines kollaborativen Systems zurückgegriffen werden kann.
1
Web, World Wide Web, WWW: Jacobs (2004) definiert den Begriff Web folgendermaßen: "An
information space in which items of interest are identified by Uniform Resource Identifiers."
Neu eingeführte und wichtige Begriffe sowie Dateinamen und Links sind in dieser Arbeit kursiv
geschrieben.
2
Eine Groupware Anwendung (oder ein kollaboratives System) wird von Peter and Trudy JohnsonLenz (1990) wie folgt definiert: “intentional group processes plus software to support them.”
3
Ruby on Rails (kurz RoR, Rails) ist ein Web Development Framework, das in der
Programmiersprache Ruby geschrieben wurde, siehe auch (Hansson 2003).
4
Fowler (2003, S. 499) beschreibt das Entwurfsmuster Plugin folgendermaßen:" Links classes during
configuration rather than compilation." Vereinfacht gesagt stellt eine Host Application eine
Schnittstelle zur Verfügung, über die ein anderes Programm (das Plugin) an den Host angedockt
werden kann, ohne dass der Host bzw. das Plugin geändert werden müssen.
2009-09-10
7/107
Einleitung
1.2 Aufgabenstellung
Im Buch Patterns for Computer-Mediated Interaction (Schümmer und Lukosch 2007)
beschreiben Till Schümmer und Stephan Lukosch in Form von Entwurfsmustern 5 die
Bestandteile von kooperativen Systemen.
Ziel dieser Arbeit ist es, die wichtigsten Entwurfsmuster für ein kooperatives System
aus diesem Buch zu ermitteln, und diese mit Hilfe des Web-Frameworks Ruby on
Rails als Module zu realisieren, sodass sich die kooperativen Elemente nahtlos in die
Ruby on Rails Architektur einbinden lassen.
Es soll eine Bibliothek aus Modulen entstehen, die sich einfach und flexibel
verwenden lassen.
1.3 Übersicht
Diese Arbeit gliedert sich in vier Bereiche, welche zur Einleitung überblicksartig
dargestellt werden.
Anforderungsanalyse
In diesem Abschnitt wird zunächst die Problematik der Entwicklung von
Webanwendungen 6 kurz angerissen, danach wird auf die Entwurfsmuster näher
eingegangen, wobei ein zentraler Punkt die Auswahl der zu implementierenden
Entwurfsmuster darstellt. Zu diesem Zweck wurde eine Studie durchgeführt, in der
mehrere Anwendungen dahingehend untersucht wurden, ob bzw. welche
Entwurfsmuster in den untersuchten Anwendungen umgesetzt wurden.
Nach der Auswahl der zu implementierenden Entwurfsmuster werden weitere
Anforderungen an die zu implementierenden Module diskutiert.
State of the Art
In diesem Kapitel werden verfügbare Anwendungen und Plug-Ins in Bezug auf ihre
Eignung für die Umsetzung der Aufgabenstellung hin untersucht. Für die
Untersuchung werden die in der Anforderungsanalyse erarbeiteten Kriterien
herangezogen.
5
Nach (Winter 2005, S. 356) ist ein Entwurfsmuster (kurz Muster) in der Softwareentwicklung
allgemein eine Beschreibung einer Familie von Lösungen für ein Entwurfsproblem.
Diese Arbeit bezieht sich hauptsächlich auf die Entwurfsmuster aus (Schümmer und Lukosch 2007).
6
Eine Webanwendung (Webbasierte Anwendung) ist ein Softwaresystem, das auf Spezifikationen des
World Wide Web Consortium (W3C) beruht, und Web-spezifische Ressourcen wie Inhalte und Dienste
bereitstellt, die über eine Benutzerschnittstelle, den Webbrowser, verwendet werden. (Kappel et al
2004)
2009-09-10
8/107
Einleitung
Beschreibung der Lösungsidee
Nachdem der Stand der Technik und die Defizite aktueller Anwendungen und PlugIns ermittelt wurden, wird eine Lösungsidee für die Umsetzung vorgestellt. Es wird
gezeigt, wie die Anforderungen, die sich in der Anforderungsanalyse
herauskristallisiert haben, umgesetzt werden können.
Details zur Lösung
Im abschließenden Abschnitt wird die Umsetzung der Lösung im Detail vorgestellt.
Zunächst wird jedes Modul durch eine Beschreibung skizziert, dann wird die
Benutzung des Moduls und die Integration in die Anwendung beschrieben, und
abschließend werden unter dem Punkt Implementierung die interessanten technischen
Details erläutert.
Am Ende des Kapitels wird gezeigt, wie mittels einiger der umgesetzten Module
Schritt für Schritt eine kollaborative Anwendung erstellt werden kann. In jedem
Schritt werden die in dem Schritt verwendeten Module mit den entsprechenden
Elementen in CURE 7 verglichen.
7
CURE ist eine kollaborative Lernplattform, die an der FernUni in Hagen entwickelt wurde (Haake et
al. 2004). Eine nähere Beschreibung zu CURE befindet sich in dieser Arbeit in den Kapiteln 2.2.3.1
und 5.4.
2009-09-10
9/107
Anforderungsanalyse
2 Anforderungsanalyse
In diesem Kapitel wird der Problembereich analysiert, aus den Ergebnissen der
Analyse werden anschließend die Anforderungen an das zu implementierende System
abgeleitet.
2.1 Webbasierte Groupware Anwendungen 8
Einer der großen Vorteile von webbasierten Anwendungen ist, dass Client und Server
über ein Netzwerk miteinander verbunden sind, und dass somit die räumliche
Entfernung zwischen Client und Server unerheblich ist. Des Weiteren muss auf der
Client-Seite keine Software installiert werden, da eine Webanwendung in einem
Webbrowser ausgeführt wird. Dadurch sind webbasierte Anwendungen auch
Plattformunabhängig.
Aufgrund der hohen Anforderungen, die die Benutzer an eine Anwendung der Web
2.0 Generation stellen, sind webbasierte kollaborative Systeme relativ komplex, was
folgende Abbildung veranschaulicht.
Abb. 1: Kategorien von Webanwendungen (Kappel et al 2004, S. 7)
Wie Kappel et al (2004, S. 8) beschreiben, werden webbasierte kollaborative
Anwendungen insbesondere zur Kooperation bei unstrukturierten Vorgängen
eingesetzt, wobei der Bedarf an Kommunikation zwischen den kooperierenden
Benutzern dabei besonders hoch ist.
Die Komplexität der Realisierung webbasierter kollaborative Anwendungen der Web
2.0 Generation wird noch dadurch gesteigert, dass das im Web üblicherweise für die
Übertragung von Daten verwendete http 9 naturgemäß schlecht für synchrone
8
Die Begriffe Groupware Anwendung und kooperatives System werden in dieser Arbeit synonym
verwendet.
9
http steht für Hypertext Transfer Protocol.
2009-09-10
10/107
Anforderungsanalyse
Zusammenarbeit 10 geeignet ist: Die Kommunikation zwischen Client und Server
verläuft bei einer Webanwendung im Normalfall so, dass der Client erst eine
Verbindung zum Server aufbaut, und dann eine Anfrage an den Server schickt. Die
Webanwendung, die auf dem Server läuft, verarbeitet die Anfrage, und der Server
sendet das Ergebnis der Anfrage zurück an den Client. Diese Art der Kommunikation
wird auch als request-response Prinzip oder synchrone Kommunikation bezeichnet
(Kappel et al 2006, S. 71).
Für ein kollaboratives System ist es jedoch notwendig, dass Informationen (wie z.B.
eine Änderung, die ein Client durchführt) möglichst in Echtzeit an alle anderen
Clients verteilt werden, was mit dem request-response Prinzip schwierig umzusetzen
ist.
10
Synchrone / asynchrone Zusammenarbeit (engl. collaboration) wird von Schümmer und Lukosch
(2007, S. 407) wie folgt definiert: "Object usage may be at the same time (synchronous) or at different
points in time (asynchronous)." Synchrone Zusammenarbeit ist also das zeitgleiche Arbeiten von
mehreren Personen an einem Objekt, und asynchrone Zusammenarbeit das zeitlich versetzte Arbeiten
von mehreren Personen an einem Objekt. Mit object wird hier ein shared object bezeichnet - das ist ein
Objekt, welches von mehr als einem Benutzer verwendet wird.
2009-09-10
11/107
Anforderungsanalyse
2.2 Analyse der Entwurfsmuster
Im folgenden Abschnitt werden die Hauptbestandteile einer Groupware vorgestellt,
und die Entwurfsmuster aus (Schümmer und Lukosch, 2007) eingeführt. Im
Anschluss daran werden die wichtigsten Entwurfsmuster für die Implementierung
ermittelt.
2.2.1 Groupware und Group Awareness
Wie schon eingangs erwähnt, sind heute webbasierte kollaborative Systeme in einer
unüberschaubaren Anzahl in unterschiedlichsten Einsatzgebieten in Verwendung. Als
Beispiele seien an dieser Stelle Facebook 11, BSCW 12 und Google Docs 13 erwähnt.
Die Hauptbestandteile einer Groupware Anwendung sind nach (Gerosa 2006)
Kommunikation, Koordination und Kooperation. Diese stehen in einer Beziehung
zueinander, wobei die zentrale Rolle dabei den Group Awareness Elementen
zukommt.
Abb. 2: Hauptbestandteile von Groupware und deren
Beziehungen zueinander (Fuks 2006)
2.2.2 Entwurfsmuster
Groupware-Anwendungen können nach der Art klassifiziert werden, wie sie
Gruppenarbeit unterstützen. Je nach Ausrichtung der Groupware stehen
unterschiedliche Elemente im Vordergrund.
Im Buch Patterns for Computer Mediated Interaction (Schümmer und Lukosch,
2007) wurden die wichtigsten Elemente, aus denen eine Groupware Anwendung
bestehen kann, in Entwurfsmustern beschrieben und nach Layern und Clustern
strukturiert. Die Layer teilen die Entwurfsmuster ein in Community Support, Group
11
http://www.facebook.com/
http://www.bscw.de/
13
http://docs.google.com
12
2009-09-10
12/107
Anforderungsanalyse
Support und Base Technology, und die Cluster gruppieren die einzelnen
Entwurfsmuster nach unterschiedlichen Anwendungsgebieten, wie z.B. Arriving in
the Community, Synchronous Awareness oder Textual Communication.
Diese Entwurfsmuster dienen als Grundlage für diese Arbeit, die wichtigsten Muster
für ein kollaboratives System sollen als Module implementiert werden.
2.2.3 Ermittlung der wichtigsten Entwurfsmuster
Im folgenden Abschnitt wird die Vorgehensweise erläutert, die zur Ermittlung der zu
implementierenden Entwurfsmuster geführt hat.
2.2.3.1 Untersuchung: Entwurfsmuster in Anwendungen
Zunächst wurde eine Voruntersuchung 14 durchgeführt, in der einige Anwendungen
dahingehend untersucht wurden, welche Entwurfsmuster aus Schümmer und Lukosch
(2007) in den Anwendungen vorkommen. Die Auswahl der zu untersuchenden
Anwendungen wurde so getroffen, dass zum Einen der Fokus auf Anwendungen mit
Group Awareness Elementen gerichtet wurde, und dass zum anderen ein möglichst
breites Spektrum von Entwurfsmustern für die Untersuchung abgedeckt wurde.
Untersuchte Anwendungen
•
CURE (Collaborative Universal Remote Education)
CURE ist eine kollaborative Lernplattform, die an der FernUni in Hagen
entwickelt wurde. CURE baut auf dem Raumkonzept auf, das bedeutet, dass die
Lernumgebung aus Räumen besteht, Räume können miteinander verlinkt werden
(Haake et al. 2004, S. 3 ff.). Benutzer kooperieren in CURE, indem sie in einem
Raum die vom Raum zur Verfügung gestellten Kommunikationsmedien nutzen.
Zudem können die Benutzer in den Räumen Seiten erstellen, und bearbeiten.
CURE kann unter folgendem Link aufgerufen werden: http://mapper.fernunihagen.de/CURE/
14
Die Untersuchung wurde zwischen dem 6.12.2008 und dem 31.12.2008 durchgeführt, sie ist
natürlich nicht repräsentativ.
2009-09-10
13/107
Anforderungsanalyse
Abb. 3: CURE Login Screen
(Quelle: http://mapper.fernuni-hagen.de/CURE/)
•
Google Docs
Google Docs ist eine Groupware, mit der mehrere Benutzer gleichzeitig
Dokumente von unterschiedlichem Format bearbeiten können. In Google Docs
kooperieren Benutzer, indem sie Dokumente teilen (share), und diese bearbeiten.
Die Homepage befindet sich auf: http://docs.google.com
Abb. 4: Google Docs, Documents
(Quelle: http://docs.google.com/ )
•
facebook
Facebook ist eine Website zur Bildung und Unterhaltung sozialer Netzwerke
(Facebook 2009). In der Grundversion von Facebook beschränkt sich die
Kooperation im Wesentlichen auf den Austausch von Nachrichten, Bildern und
Videos. Da Facebook aber durch Plug-Ins erweiterbar ist, sind zahlreiche PlugInswie Spiele, Kommunikationsanwendungen und Spaßprogramme verfügbar.
Die Homepage ist unter dem Link http://www.facebook.com/ zu erreichen.
2009-09-10
14/107
Anforderungsanalyse
Abb. 5: Facebook Login Screen
(Quelle: http://www.facebook.com/)
•
eBay
eBay ist eine bekannte Internet Auktionsplattform, auf der Benutzer durch
Vorbereitung und Durchführung von Handelstransaktionen miteinander
kooperieren. Die Plattform lässt sich über den Link http://www.ebay.com/
erreichen.
Abb. 6: ebay Produktsuche (Quelle: http://www.ebay.com/)
•
15
Skype
Skype ist eine VoIP 15-Software mit Chat-Funktionalitäten. Benutzer kooperieren
mit Skype, indem sie miteinander telefonieren, chatten, oder untereinander Daten
austauschen. Skype kann über eine Plug-In Schnittstelle erweitert werden,
zahlreiche Plug-Ins für Kooperation sind verfügbar.
Der Link zur Homepage von Skype lautet: http://skype.com
VoIP ist die Abkürzung für Voice over IP.
2009-09-10
15/107
Anforderungsanalyse
Abb. 7: Skype (Version 3.8.0.188)
•
El Dorado
El Dorado ist eine vollständige Community Web Applikation, die in Ruby on
Rails geschrieben wurde. Für die Kooperation stehen ein Forum, ein Gruppenchat
und ein File Repository zur Verfügung.
Die Homepage befindet sich unter dem Link http://almosteffortless.com/eldorado/
Abb. 8: El Dorado, Demo Seite (Quelle: http://eldoradoapp.com/)
•
Thetis
Thetis ist eine Groupware mit Fokus auf Content-Management-System /
Knowledge Management. Thetis basiert auf Ruby on Rails. Für die Kooperation
stehen Items (ähnlich wie Threaded Discussion), ein Shared File Repository und
das Programm PaintMail (ein Zeichenprogramm) zur Verfügung. Die Homepage
von Thetis ist unter folgendem Link abrufbar: http://rubyforge.org/projects/thetis/
2009-09-10
16/107
Anforderungsanalyse
Abb. 9: Thetis Demo, Desktop (Quelle: http://sysphonic.com/thetis/)
•
eXPlain PMT (Project Management Tool)
Das Programm eXPlain PMT ist eine Groupware zur Koordination von Extreme
Programming Aktivitäten, insbesondere zur Verwaltung von Projekten und deren
Story Cards. Die Benutzer kooperieren über das Dashboard, das als Interaction
Directory dient, miteinander. Die Software basiert auf Ruby on Rails, die
Homepage von eXPlain PMT befindet sich auf:
http://wiki.github.com/explainpmt/explainpmt
Abb. 10: eXPlain PMT, Dashboard (Version: 20070423.0)
•
Boxroom
Boxroom ist ein Projekt, das auf Ruby on Rails basiert, und das als Grundlage für
eine Web-Applikation zur Verwaltung von Dateien entwickelt wurde. In Boxroom
erfolgt die Kooperation durch den Austausch von Dateien. Die Homepage von
Boxroom lässt sich über folgenden Link abrufen:
http://boxroom.rubyforge.org/index.html
2009-09-10
17/107
Anforderungsanalyse
Abb. 11: Boxroom Folder
(Quelle: http://boxroom.rubyforge.org/screenshots.html )
Vorgehensweise bei der Untersuchung
Zunächst wurden sämtliche Entwurfsmuster aus (Schümmer und Lukosch 2007)
aufgelistet. Danach wurde jede einzelne Anwendung dahingehend untersucht, welche
Entwurfsmuster in der jeweiligen Anwendung umgesetzt wurden.
2.2.3.2 Vorauswahl
Um die Anzahl der zu implementierenden Entwurfsmuster zu verringern, wurde eine
Vorauswahl getroffen. Dabei wurden alle Entwurfsmuster, die in den untersuchten
Anwendungen gar nicht, oder nur einmal vorgekommen sind, und einen niedrigen
Reifegrad 16 aufweisen, aus der Auswahl entfernt.
Ergebnis der Untersuchung nach der Vorauswahl
Tabelle 1 zeigt das Ergebnis der Untersuchung nach der Vorauswahl. Die linke Spalte
gibt den Namen des Entwurfsmusters an, dann folgt eine Spalte rechts daneben die
Anzahl, in wie vielen der untersuchten Anwendungen das entsprechende
Entwurfsmuster vorgekommen ist. Im Index der Tabelle befindet sich ggf. ein
Kommentar zum entsprechenden Punkt der Untersuchung.
16
Der Reifegrad (maturity) der Entwurfsmuster (Schümmer und Lukosch 2007, S. 30) wird in Form
von Sternen (asterisks) neben dem Namen des Entwurfsmusters angegeben, wobei ** dem höchsten
Reifegrad entspricht, und keine Sterne den niedrigsten Reifegrad darstellt.
2009-09-10
18/107
Anforderungsanalyse
Tabelle 1: Ergebnis der Untersuchung nach der Vorauswahl
Aus der Untersuchung geht unter anderem hervor, dass jede untersucht Groupware
Anwendung eine Benutzerverwaltung besitzt. Außerdem ist auffällig, dass
Entwurfsmuster für synchrone Group Awareness (wie z.B. Remote Field of Vision 17
oder Remote Selection) kaum umgesetzt wurden.
17
Namen von Entwurfsmustern werden in dieser Arbeit durch eine spezielle Schriftart hervorgehoben.
2009-09-10
19/107
Anforderungsanalyse
2.2.3.3 Auswahl der Entwurfsmuster
Die Anzahl der Verwendung der einzelnen Entwurfsmuster in den untersuchten
Anwendungen kann nicht als einziges Kriterium für die Auswahl der Muster
herangezogen werden 18. Das Ergebnis der Untersuchung dient somit nur als Richtwert
für die Auswahl. Als weiteres Kriterium wird deshalb die Beziehungen der
Entwurfsmuster zueinander 19 ausgewählt.
Abb. 12: Entwurfsmuster und deren Beziehungen zueinander (Vorauswahl)
18
Dies lässt sich unter Anderem dadurch begründen, dass die Auswahl der untersuchten Anwendungen
nicht repräsentativ ist, und die Anzahl der Muster nicht mit deren Wichtigkeit korrelieren muss.
19
Related Patterns (Schümmer und Lukosch, 2007)
2009-09-10
20/107
Anforderungsanalyse
Es werden somit jene Entwurfsmuster ausgewählt, die in den Anwendungen der
Untersuchung mindestens sechs mal vorgekommen sind, und zusätzlich werden jene
Entwurfsmuster ausgewählt, die oft zusammen mit den am häufigsten
vorgekommenen Mustern verwendet werden (Related Patterns). Muster für synchrone
Group Awareness werden aufgrund der Erkenntnisse aus Abschnitt 2.2.1 bei der
Auswahl höher priorisiert, deshalb wurden User List und Spontaneous
Collaboration zusätzlich ausgewählt.
Nicht explizit als Modul implementiert wurde das Muster Masquerade. Darauf wurde
verzichtet, weil die Zugriffsrechte auf Benutzerdaten einerseits in gewissem Rahmen
durch den Anwendungsentwickler konfigurierbar sind, und die Entwurfsmuster so
implementiert werden, dass die Details der anderen Benutzer lediglich für die
Buddies 20 des Benutzers zugänglich gemacht werden.
Aus dem Cluster Textual Communication wird lediglich Embedded Chat umgesetzt,
weil die anderen ausgewählten Muster nicht in Beziehung zu den anderen Mustern
aus Textual Communication stehen.
Zusammenfassung der Auswahl der Entwurfsmuster
Aus den vorangegangenen Schritten ergibt sich somit folgende Auswahl der zu
implementierenden Entwurfsmuster:
Cluster
Arriving in the Community
Protect Users
Modify Shared Artifacts
Create Places for Collaboration
Textual Communication
Synchronous Group Awareness
Session Management
Management of Shared Objects
Name
Quick Registration
Login
Virtual Me
User Gallery
Buddy List
Availability Status
Quick Goodbye
Group
Shared File Repository
Room
Interaction Directory
Bell
Invitation
Embedded Chat
User List
Spontaneous Collaboration
Interactive User Info
Collaborative Session
Centralized Objects
Remote Subscription
Mediated Updates
Immutable Versions
Tabelle 2: Auswahl der zu implementierenden Entwurfsmuster
Nachdem die zu implementierenden Entwurfsmuster ermittelt wurden, werden nun
die weiteren Anforderungen an diese Muster näher untersucht.
20
Buddy: siehe Kapitel 5.2.4
2009-09-10
21/107
Anforderungsanalyse
2.3 Einzelne Module
Modularität ist die Aufteilung eines Ganzen in Teile, diese Teile werden als Module
bezeichnet (Wikipedia 2009b). Bereits in der Aufgabenstellung wurde definiert, dass
die Entwurfsmuster als Module zu realisieren sind.
Booch (1993) definiert den Begriff Modularität wie folgt:
"Modularität ist die Eigenschaft eines Systems, das in einen Satz kohäsiver
und locker gekoppelter Module zerlegt worden ist."
Starke Kohäsion bedeutet, dass ein Modul ein logisch zusammenhängendes
Teilproblem behandelt, und schwache Kopplung heißt, dass die Abhängigkeit eines
Moduls von anderen Modulen möglichst klein sein sollte (Winter 2005, S. 333 ff.).
Die Entwurfsmuster sollen also in einzelnen Modulen realisiert werden, die in Bezug
zu anderen Modulen möglichst lose gekoppelt sind, und eine starke Kohäsion nach
innen aufweisen. Die Module sollen nach dem Baukastenprinzip verwendet werden
können.
Einbindung von Modulen in Rails
Bei der Frage, auf welche Art und Weise die Module selbst in die Zielanwendung
eingebunden werden können, bietet Rails grundsätzlich folgende Möglichkeiten an
(Fischer 2008, S. 343 ff.):
• Libraries
Diese können im einfachsten Fall nur aus einer einzelnen Datei bestehen. Sie
werden üblicherweise in das Verzeichnis /lib kopiert und über das Schlüsselwort
require 'Bibliothek' 21 in eine Anwendung eingebunden.
• Gems
Werden üblicherweise ins Ruby-Verzeichnis installiert und systemweit verfügbar
gemacht, müssen nicht ins /lib-Verzeichnis kopiert werden, sondern können direkt
über require 'name' in die Anwendung eingebunden werden.
• Plug-Ins
Befinden sich im Verzeichnis vendor/plugins direkt unter der Wurzel des
Anwendungsverzeichnisses. Jedes Plug-In besitzt einen eigenen Generator, dieser
kann durch script/plugin install name_des_plugins aufgerufen werden.
Plug-Ins können direkt in das Zielverzeichnis der Anwendung kopiert werden.
Jede Anwendung kann so unterschiedliche Plug-Ins verwenden, und die Plug-Ins
können auch einfach wieder entfernt werden. Außerdem kann der Code von PlugIns über die Datei init.rb, die jedesmal beim Start der Anwendung gelesen wird,
direkt in die Anwendung eingebunden werden.
Plug-Ins erscheinen für die Realisierung der Entwurfsmuster am geeignetsten zu sein,
deshalb werden die Entwurfsmuster als Plug-Ins implementiert.
21
Die Nichtproportionalschrift wird in dieser Arbeit für Codebeispiele und Befehle verwendet.
2009-09-10
22/107
Anforderungsanalyse
2.4 Elemente sollen sich nahtlos in die Rails Architektur
einbinden lassen
Nachdem die Vorgabe lautet, dass sich die kooperativen Elemente nahtlos in die Ruby
on Rails Architektur einbinden lassen sollen, werden als nächstes einige
Eigenschaften und Prinzipien der Rails Architektur diskutiert.
Model, View, Controller
Die Rails-Architektur folgt dem Model, View, Controller (MVC) Entwurfsmuster
(Krasner und Pope 1988, S. 26–49). Dem entsprechend repräsentieren in Rails die
Models die Daten in der Anwendung und implementieren die Domänenlogik, die
Views bilden das User Interface, und die Controller sind für das Handling der
Benutzeranfragen, und für die Vermittlung zwischen den Views und den Models und
für die Geschäftslogik verantwortlich.
Folgende Abbildung veranschaulicht die MVC Architektur:
1. Der Webbrowser sendet eine Anfrage an den Controller.
2. Der Controller interagiert mit dem Model.
3. Der Controller ruft die View auf.
4. Die View wird vom Webbrowser angezeigt.
Abb. 13: Model, View, Controller
Daraus lassen sich folgende Anforderungen ableiten:
• Die Datenhaltung und die Domänenlogik wird in den Models implementiert.
• Alle Benutzeranfragen werden von den Controllern entgegengenommen, und an
die Views, bzw. an die Models weitergeleitet.
• Die Controller implementieren die Geschäftslogik.
• Die Views werden vom Controller aufgerufen, Views beinhalten, wenn möglich,
keine Logik.
Convention over Configuration
Eines der Grundprinzipen von Rails lautet Convention over Configuration. Nach
diesem Prinzip wird davon ausgegangen, dass wenig Konfiguration notwendig ist,
wenn bestimmte Konventionen eingehalten werden.
Einige dieser Konventionen lauten (WikiBooks 2009a):
2009-09-10
23/107
Anforderungsanalyse
•
•
•
•
•
•
Sourcecode- Dateien sind immer in Kleinbuchstaben mit Underscores als
Trennzeichen benannt.
Klassennamen sind immer in der CamelCase Schreibweise geschrieben.
Models sind im Singular, Tabellen im Plural benannt.
Controller sind im Plural benannt.
Primärschlüssel haben die Bezeichnung id.
Fremdschlüssel haben die Bezeichnung name_id.
Abb. 14: Klassen und Tabellen
(Quelle: http://openbook.galileocomputing.de/ruby_on_rails/)
Daraus lassen sich folgende Anforderungen ableiten:
• Die Rails-Konventionen sollen eingehalten werden.
• Wenn möglich, soll externe Konfiguration, wie z.B. über Konfigurationsdateien,
vermieden werden.
Don´t Repeat Yourself (DRY)
Hunt (2000) definiert DRY folgendermaßen:
"Every piece of knowledge must have a single, unambiguous, authoritative
representation within a system."
Dieses Grundprinzip von Rails besagt also, dass Wiederholungen (Redundanzen) in
der Programmierung vermieden werden sollen.
Daraus lässt sich folgende Anforderungen ableiten:
• Code soll nicht dupliziert werden.
2.5 Verwendbarkeit
Wie in der Aufgabenstellung definiert, sollen sich die Module einfach und flexibel
verwenden lassen.
Da die Hauptbenutzer der Module Anwendungsentwickler sind, beginnt die
Betrachtung der Verwendbarkeit bei der Generierung und Installation der
Komponenten in die Anwendung durch den Anwendungsentwickler. Die Module
sollen einfach und ohne größeren Aufwand in die Anwendung installierbar sein.
2009-09-10
24/107
Anforderungsanalyse
Nach der Installation erfolgt die Integration in die Anwendung. Bei diesem Schritt
integriert der Anwendungsentwickler die installierten Komponenten des Moduls in
seine Anwendung.
Ein weiteres Merkmal
Plattformunabhängigkeit.
in
Bezug
auf
die
Verwendbarkeit
ist
die
2.6 Konfigurierbarkeit
Konfigurierbarkeit ist bei Modulen unerlässlich, weil die Module in bestehende
Anwendungen integriert werden, und auch flexibel einsetzbar sein sollen. Folgende
Möglichkeiten für die Konfigurierung wurden ermittelt:
1. Generierung und Installation in die Anwendung
Da die Module als Plug-Ins realisiert werden, bietet sich die erste Möglichkeit der
Konfiguration bereits bei der Generierung und der Installation des Plug-Ins in die
Anwendung, über den Aufruf des Generators.
2. Tabelle
Nach der Generierung werden, sofern erforderlich, die Tabellen für die Datenbank
erstellt. Hier bietet sich auch die nächste Konfigurationsmöglichkeit, indem die
Struktur der Tabelle vom Anwendungsentwickler nach Bedarf durch Hinzufügen
bzw. Entfernen von Attributen angepasst wird.
3. Model-Ebene
Eine weitere in Rails übliche Möglichkeit der Konfigurierung erfolgt direkt auf
Model-Ebene:
o Objekte können durch eine der von ActiveRecord 22 standardmäßig zur
Verfügung gestellten Arten von Beziehungen miteinander verknüpft werden
(Hansson et al. 2009, S. 360ff).
o Models können durch ein Plug-In erweitert werden (hier ist das acts_as_...
Paradigma sehr beliebt 23).
o Im Model selbst können Parameter im Code geändert werden, die dessen
Eigenschaften beeinflussen.
4. Integration
Auch bei der Einbindung (Integration) der Module in die Anwendung bieten sich
Konfigurationsmöglichkeiten an: Zum einen verwenden Module oft lokale
22
Active Record ist ein Entwurfsmuster, das von Martin Fowler definiert wurde. Er beschreibt es so:
"An object that wraps a row in a database table or view, encapsulates the database access, and adds
domain logic on that data." (Fowler 2003, S. 160)
Der ActiveRecord Mechanismus von Rails arbeitet nach diesem Prinzip, er generiert eine
objektrelationale Abbildung (object relational mapping, ORM) zwischen den Ruby-Objekten der
Anwendung und den Zeilen und Spalten der Datenbank. (Orsini 2007)
Alle Models sind in Rails von der Klasse ActiveRecord abgeleitet.
23
In (WikiBooks 2009b) ist das acts_as Paradigma wie folgt beschrieben: "Acts as methods define
additional behavior for an ActiveRecord object. Often extension of ActiveRecord objects by plugins is
implemented using a custom acts_as_ method."
2009-09-10
25/107
Anforderungsanalyse
Variablen (wie z.B. @users), deren Inhalt durch den Anwendungsentwickler beim
Aufruf des Moduls bestimmt wird, und zum anderen besteht die Möglichkeit,
Module beim Aufruf durch Parameter zu konfigurieren.
5. Externe Konfigurationsdatei
Eine weitere Möglichkeit zur Konfigurierung besteht darin, Konfigurationsdaten
über eine externe Datei bereitzustellen. Dies kann entweder über eine durch das
Plug-In selbst bereitgestellte Konfigurationsdatei erfolgen, oder aber über eine der
von Rails zur Verfügung gestellten Konfigurationsdateien 24.
Von den ermittelten Kunfigurierungsmöglichkeiten sind die Punkte 1, 3 und 4 zu
bevorzugen, weil die Konfigurierung von außen erfolgt, und somit kein, bzw. nur ein
minimaler manueller Eingriff in den Code des Plugins erforderlich ist. Änderungen an
der Tabelle (Punkt 2) sollten im Normalfall nicht notwendig sein, weil dies zu
zusätzlich erforderlichen Änderungen im Code führen kann. In Einzelfällen können
manuelle Eingriffe in den Code gerechtfertigt sein.
Die Konfigurierung über eine externe Datei sollte nach Möglichkeit vermieden
werden, weil dies dem Grundprinzip Convention over Configuration widerspricht.
Grundsätzlich widerspricht die Vorgabe, dass die Module konfigurierbar sein sollen,
nicht dem Prinzip Convention over Configuration, da die in Abschnitt 2.4 angeführten
Konventionen trotz der Konfigurierbarkeit der Module einzuhalten sind.
2.7 Codebasis
Für die Extrahierung von Code aus bestehenden Anwendungen, müssen grundsätzlich
folgende Bedingungen erfüllt sein:
• Verfügbarkeit des Sourcecodes, dies schließt auch das Lizenzmodell mit ein
• Aktualität des Sourcecodes (Kriterium: aktuelle Rails Version)
2.8 Zusammenfassung der Anforderungen
Neben den zu implementierenden Entwurfsmustern, die bereits am Ende des Kapitels
2.2.3 angeführt wurden, ergeben sich somit folgende Anforderungen an die Module:
•
•
•
•
•
•
•
•
24
Einzelne, lose gekoppelte Module mit starker Kohäsion
Die Module sind als Plug-Ins implementiert
Die Implementierung entspricht den Vorgaben der Rails Architektur
Die Plug-Ins sind einfach zu installieren
Die Plug-Ins sind einfach in die Anwendung integrierbar
Plattformunabhängigkeit
Die Plug-Ins sind konfigurierbar
Sourcecode verfügbar und aktuell (nur für Anwendungen)
siehe dazu z.B. (Hansson 2009, S. 264 ff.)
2009-09-10
26/107
State of the Art
3 State of the Art
Nachdem die Anforderungen definiert worden sind, wird nun untersucht, wie diese
umgesetzt werden können.
In diesem Kapitel werden einige Plug-Ins und Open Source Anwendungen in Bezug
auf ihre Eignung zur Erfüllung der Anforderungen aus Abschnitt 2 näher untersucht.
Abschließend folgt ein Fazit, inwiefern sich die untersuchten Anwendungen und PlugIns dafür eignen, um eine Bibliothek von Modulen für kooperative Anwendungen zu
erstellen.
3.1 Untersuchung von existierenden Plug-Ins
Die Untersuchungen sind jeweils so aufgebaut, dass zu Beginn das jeweilige Plug-In
kurz vorgestellt wird, dann folgt eine Bewertung des Plug-Ins anhand der ermittelten
Anforderungen, ein Fazit rundet die Betrachtung ab.
Zunächst werden Plug-Ins untersucht, die sich als Grundlage für die synchrone
Zusammenarbeit eignen könnten.
3.1.1 Plug-Ins für Synchrone Zusammenarbeit 25
CanHasChat
Dies ist ein Chat Plug-In, das die Nachrichten mittels XMPP 26 verschickt. Die
Homepage von CanHasChat befindet unter folgendem Link:
http://agilewebdevelopment.com/plugins/can_has_chat
•
Ziel
Das Plug-In wurde dahingehend untersucht, ob es sich als Grundlage für die
Realisierung des Entwurfsmusters Embedded Chat eignet.
•
Bewertung und Fazit
Da das Plug-In nicht auf MS Windows installierbar ist, kommt es nicht für die
Verwendung in Frage.
Anforderung
Bewertung
9
Embedded Chat
9
Als Plug-In implementiert
Entspricht den Vorgaben der Rails Architektur
9
Einfach zu installieren
9
Einfach in die Anwendung integrierbar
8
Plattformunabhängig
Konfigurierbar
Tabelle 3: CanHasChat (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
25
26
Diese Untersuchungen wurden zwischen dem 19.12.2008 und dem 18.1.2009 durchgeführt
Extensible Messaging and Presence Protocol (http://www.jabber.org/)
2009-09-10
27/107
State of the Art
ActiveMessaging
ActiveMessaging ist ein Messaging Framework für Ruby On Rails, das für den
Transport der Nachrichten unterschiedliche Messaging Systeme (unter anderem
Stomp 27, JMS 28 und WebSphere MQ 29) unterstützt, die Homepage befindet sich auf:
http://code.google.com/p/activemessaging/wiki/ActiveMessaging
•
Ziel
Das Plug-In wurde dahingehend untersucht, ob es sich als Grundlage für die
Realisierung des Entwurfsmusters Embedded Chat eignet. Zudem wurde
untersucht, ob es sich als Grundlage für die Module des Clusters Synchronous
Group Awareness eignet.
•
Bewertung und Fazit
Das Modul eignet sich grundsätzlich sowohl für die Realisierung eines
Embedded Chat Moduls, als auch für die Verteilung der synchronen Nachrichten
an die Clients. Als kleiner Nachteil erscheint, dass die Clients die Nachrichten
pollen müssen 30. Ein Vorteil ist, dass auf einfache Art und Weise unterschiedliche
Kommunikationsprotokolle verwendet werden können.
Anforderung
Bewertung
9
Embedded Chat, synchrone Entwurfsmuster
9
9
9
9
9
9
9
Konfigurierbar
Tabelle 4: ActiveMessaging (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
Juggernaut
Juggernaut ist ein Plug-In auf Basis von Flash 31, das es ermöglicht, dass der Server
quasi in Echtzeit aktiv Daten an die Clients verteilt (push), und so synchrone
Webanwendungen ermöglicht.
Die Projektseite ist unter http://juggernaut.rubyforge.org/ zu finden, eine google group
befindet sich unter http://groups.google.com/group/Juggernaut-for-Rails.
•
Ziel
Das Plug-In wurde dahingehend untersucht, ob es sich als Basis für die Module
des Clusters Synchronous Group Awareness eignet.
27
Stomp (Streaming Text Orientated Messaging Protocol): http://xircles.codehaus.org/projects/stomp
JMS (Java Message Service): http://java.sun.com/products/jms/
29
WebSphere MQ (IBM): http://www-01.ibm.com/software/integration/wmq/
30
Quelle: http://groups.google.com/group/activemessagingdiscuss/browse_thread/thread/63f17d759b57eba2/b1325bcd490929b6?lnk=gst&q=poller#b1325bcd49
0929b6 )
31
Adobe Flash: http://www.adobe.com/support/documentation/de/flash/
28
2009-09-10
28/107
State of the Art
•
Bewertung und Fazit
Juggernaut scheint als Kommunikations-Infrastruktur für ein synchrones
kollaboratives System sehr gut geeignet zu sein. Ein Nachteil ist, dass die
Installation unter MS Windows nicht reibungslos funktioniert 32.
Anforderung
Bewertung
9
Embedded Chat, synchrone Entwurfsmuster
9
9
9
9
9
9
Konfigurierbar
Tabelle 5: Juggernaut (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
3.1.2 Andere Plug-Ins
Restful Authentication
Restful Authentication ist ein Plug-In für die Benutzerverwaltung mit Login und
Authentisierung. Die Homepage ist unter folgendem Link abrufbar:
http://agilewebdevelopment.com/plugins/restful_authentication
•
Ziel
Das Plug-In wurde in Bezug auf seine Eignung für die Realisierung der
Benutzerverwaltung, und für die Umsetzung der Entwurfsmuster Quick
Registration, Login und Quick Goodbye, untersucht.
•
Bewertung und Fazit
Restful Authentication ist in der Rails-Welt sehr verbreitet, und hat sich für die
Benutzerverwaltung und Authentisierung bewährt. Das Plug-In erfüllt alle
Anforderungen, lediglich die Integration in eine bestehende Anwendung wurde
nicht bewertet, da das Plug-In für die Realisierung der Benutzerverwaltung
ausgewählt wurde, und somit die Integration in eine bestehende Anwendung
nebensächlich ist.
Anforderung
Bewertung
9
Quick Registration, Login, Quick Goodbye
9
9
9
9
9
9
Konfigurierbar
Tabelle 6: Restful Authentication (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
32
Siehe Anhang, Installation von Juggernaut.
2009-09-10
29/107
State of the Art
Simple Groups
Simple Groups ist ein Plug-In, das Rails um die Funktionalität für die Verwaltung von
Gruppen erweitert, die Homepage befindet sich auf
http://agilewebdevelopment.com/plugins/simple_groups.
•
Ziel
Es wurde untersucht, ob sich das Plug-In für die Umsetzung des Entwurfsmusters
Group eignet.
•
Bewertung und Fazit
Das Plug-In scheint sehr gut für die Umsetzung des Entwurfsmusters Group
geeignet zu sein.
Anforderung
Bewertung
9
Group
9
9
9
9
9
9
9
Konfigurierbar
Tabelle 7: Simple Groups (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
Attachment Fu
Dieses Plug-In wurde als Unterstützung für das Handling von Dateien entwickelt. Die
Homepage ist unter http://agilewebdevelopment.com/plugins/attachment_fu zu
finden.
•
Ziel
Das Plug-In wird in Bezug auf seine Eignung für die Umsetzung des
Entwurfsmusters Shared File Repository untersucht.
•
Bewertung und Fazit
Obwohl das Plug-In auf den Umgang mit Bilddateien spezialisiert ist, eignet es
sich auch als Grundlage für die Entwicklung eines Shared File Repository.
Außerdem kann es für die Verwaltung des User Avatars 33 verwendet werden.
Lediglich die Installation der vom Plug-In benötigten Komponenten für die
Bildverarbeitung ist relativ aufwändig.
Soll eine Versionierung der Artefakte inklusive Zeitstempel erfolgen, so kann ein
zusätzliches Plug-In (wie z.B. acts_as_versioned) verwendet werden.
33
"Die grafische Repräsentation eines Benutzers in der virtuellen Umgebung wird als Avatar
bezeichnet." (Rechenberg und Pomberger 2002, S. 851)
2009-09-10
30/107
State of the Art
Anforderung
Bewertung
9
9
9
9
9
9
9
Konfigurierbar
Tabelle 8: Attachment Fu (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
acts_as_versioned
Dieses Plug-In ermöglicht es, ein Model um Versionierungs-Funktionalitäten zu
erweitern, die Homepage befindet sich auf
http://agilewebdevelopment.com/plugins/acts_as_versioned.
•
Ziel
Das Plug-In wurde mit dem Ziel untersucht, eine Versionierung von Artefakten
mit Zeitstempel zu realisieren (Immutable Versions).
•
Bewertung und Fazit
Die Untersuchung hat gezeigt, dass Versionierung mit diesem Plug-In sehr gut
umgesetzt werden kann. Deshalb wird es auch zur Implementierung von
Immutable Versions, und allen anderen Entwurfsmustern, die Versionierung
benötigen, ausgewählt.
Anforderung
Bewertung
9
Immutable Versions
9
9
9
9
9
9
9
Konfigurierbar
Tabelle 9: acts_as_versioned (9: erfüllt, -: mäßig erfüllt, 8: nicht erfüllt)
3.1.3 Zusammenfassung
Aufgrund der Untersuchungen der Plugins aus den Abschnitten 3.1.1 und 3.1.2
werden folgende Plugins für die Implementierung der jeweiligen Entwurfsmuster
ausgewählt:
• Juggernaut: als Infrastruktur für Plugins, die synchrone Zusammenarbeit erfordern
• Restful Authentication: Quick Registration, Login, Quick Goodbye
• Simple Groups: Group
• Attachment Fu: Shared File Repository
• acts_as_versioned: Immutable Versions
2009-09-10
31/107
State of the Art
3.2 Untersuchung von Open Source Anwendungen
Die bereits in Abschnitt 2.2.3.1 vorgestellten Rails- basierten Anwendungen El
Dorado, Thetis, eXPlain PMT und Boxroom werden nun dahingehend untersucht, ob
sie sich als Basis für die Umsetzung der Entwurfsmuster eignen, bzw. ob Teile der
Anwendungen extrahiert und für die Umsetzung einzelner Entwurfsmuster verwendet
werden können. Ein besonderer Schwerpunkt wird bei der Untersuchung auf die
Umsetzung der Muster des Clusters Synchronous Group Awareness gelegt.
Zusätzlich zu den in der Anforderungsanalyse definierten Kriterien, wird die Anzahl
der in den Anwendungen umgesetzten Muster aus den jeweiligen Clustern für die
Bewertung herangezogen. Diese Anzahl ist aus der Tabelle 1 aus Abschnitt 2.2.3.1
entnommen.
Somit ergeben sich folgende Kriterien für die Bewertung der Anwendungen:
• Die Anzahl der in den Anwendungen umgesetzten Muster aus den jeweiligen
Clustern, im Vergleich zu den ausgewählten Mustern
• Verfügbarkeit des Sourcecodes
• Aktualität des Sourcecodes (Rails-Version)
Zu jeder untersuchten Anwendung folgt nun eine kurze Zusammenfassung der
Analyse, und ein Fazit in Bezug auf die Eignung für die Extrahierung von Codeteilen
für die Erstellung von Modulen.
El Dorado
El Dorado ist eine vollständige Community Web Applikation.
•
Analyse
Die Applikation selbst bietet aus Benutzersicht viele Möglichkeiten, Elemente des
Clusters Synchronous Group Awareness sind jedoch nur eingeschränkt vorhanden.
Als Plug-In für das Shared File Repository wurde Attachment Fu verwendet.
Anforderung
Anzahl Muster aus Cluster Arriving in the Community
Anzahl Muster aus Cluster Protect Users
Anzahl Muster aus Cluster Modify Shared Artifacts
Anzahl Muster aus Cluster Textual Communication
Anzahl Muster aus Cluster Create Places for Collaboration
Anzahl Muster aus Cluster Synchronous Group Awareness
Anzahl Muster aus Cluster Session Management
Anzahl Muster aus Cluster Management of Shared Objects
Anzahl Muster aus Cluster Data Consistency Support
Code verfügbar?
Rails-Version
Tabelle 10: El Dorado
•
Ergebnis
4/5
0/2
1/2
1/1
2/4
2/3
0/1
2/3
0/1
ja
2.2.2
Fazit
Die Anwendung ist zwar recht umfangreicht und macht einen soliden Eindruck,
aber besonders die interaktiven Elemente sind vom Funktionsumfang her recht
2009-09-10
32/107
State of the Art
eingeschränkt, deshalb erscheint die Extrahierung einzelner Entwurfsmuster nicht
besonders erfolgsversprechend zu sein. Da als Grundlage für das Shared File
Repository Attachment Fu verwendet wurde, würde die Extrahierung dieses Teils
keine erkennbaren Vorteile im Vergleich zur direkten Verwendung von
Attachment Fu bringen.
Thetis
Thetis ist eine Groupware mit Fokus auf Content-Management-System / Knowledge
Management.
•
Analyse
Das Programm wirkt zwar unübersichtlich, bietet aber viele Möglichkeiten,
besonders was den Cluster Modify Shared Artifacts betrifft.
Anforderung
Code verfügbar?
Rails-Version
Tabelle 11: Thetis
•
Ergebnis
3/5
0/2
2/2
0/1
2/4
0/3
0/1
2/3
0/1
ja
2.1.2
Fazit
Trotz der vielen Möglichkeiten, die Thetis bietet, wird davon ausgegangen, dass
eine Neuentwicklung unter Verwendung der Plug-Ins Restful Authentication,
Simple Groups und Attachment Fu ein vergleichbares Ergebnis bringt, jedoch
effizienter ist, als die Extrahierung der entsprechenden Codeteile aus Thetis.
eXPlain PMT
eXPlain PMT ist eine Groupware zur Koordination von Extreme Programming
Aktivitäten, insbesondere zur Verwaltung von Projekten und deren Story Cards.
•
Analyse
Die Elemente für Synchronous Group Awareness sind nur eingeschränkt
brauchbar, denn die Kommunikation erfolgt entweder über Email oder über das
Dashboard (eines pro Projekt) über das Anlegen eines Milestones.
2009-09-10
33/107
State of the Art
Anforderung
Code verfügbar?
Rails-Version
Tabelle 12: eXPlain PMT
•
Ergebnis
3/5
1/2
0/2
0/1
2/4
2/3
0/1
2/3
0/1
ja
2.0.2
Fazit
Aufgrund der eingeschränkten Brauchbarkeit der Synchronous Group Awareness
Elemente (siehe Ergebnisse der Untersuchung aus Abschnitt 2.2.3.1) erscheint
eine Adaptierung von eXPlain PMT nicht sinnvoll zu sein.
Boxroom
Boxroom ist ein Projekt, das als Grundlage für eine Web-Applikation zur Verwaltung
von Dateien verwendet werden kann.
•
Analyse
Das File Repository sieht vielversprechend aus, es liegt jedoch in der RailsVersion 1.2.2 vor. Die Volltextsuche hat nicht funktioniert, was aber auch auf ein
Installationsproblem zurückzuführen sein könnte.
Anforderung
Code verfügbar?
Rails-Version
Tabelle 13: Boxroom
•
Ergebnis
3/5
0/2
2/2
0/1
0/4
0/3
0/1
2/3
0/1
ja
1.2.2
Fazit
Aufgrund der nicht aktuellen Version von Rails, und der ungelösten Probleme mit
der Volltextsuche kommt die Verwendung des Projekts zur Implementierung von
Entwurfsmustern nicht in Frage
2009-09-10
34/107
State of the Art
3.3 Eignung und Defizite bestehender Lösungen für Module
Plug-Ins
Im Web ist eine große, ständig wachsende Menge von Plug-Ins verfügbar. Darunter
sind auch welche zu finden, die das eine oder andere Entwurfsmuster für kooperative
Anwendungen abdecken, und die gestellten Anforderungen erfüllen.
Es gibt jedoch keine umfassende Sammlung von Plug-Ins, die es ermöglicht, daraus
ein kollaboratives System zu erstellen. Besonders Plug-Ins für synchrone Group
Awareness Elemente sind kaum verfügbar.
Anwendungen
Unter den untersuchten Anwendungen erfüllt keine die Anforderungen so treffend,
dass diese ohne größere Anpassungen als Basis für diese Arbeit geeignet ist. Das
Extrahieren von Codeteilen einer Anwendung, um daraus neue Module zu erstellen,
erscheint aus folgenden Gründen nicht sehr zielführend zu sein: Die wichtigen
Entwurfsmuster aus dem Cluster Synchronous Group Awareness wurden in allen
untersuchten Anwendungen kaum hinreichend umgesetzt, weiters können viele der
Funktionalitäten, die in den Anwendungen gut umgesetzt wurden, durch andere,
eigenständige Plug-Ins, ebenfalls abgedeckt werden, was wesentlich effizienter ist.
3.4 Fazit
Ziel dieser Arbeit ist es, eine umfassende Bibliothek von Kooperationsmodulen zur
Verfügung zu stellen, mit denen ein kollaboratives System erstellt werden kann,
wobei der Schwerpunkt bei der Realisierung der Module auf Group Awareness gelegt
werden soll.
Alle untersuchten Anwendungen kommen aus den oben genannten Gründen nicht
dafür in Frage.
Eine vollständige Bibliothek komplett aus frei verfügbaren Modulen zusammen zu
stellen erscheint nicht praktikabel zu sein, denn selbst wenn für jedes Entwurfsmuster
ein verwendbares Plug-In gefunden würde (was als recht unwahrscheinlich erscheint),
wäre das Entwickeln eines kompletten kollaborativen Systems durch das Verwenden
von vielen Plug-Ins aus unterschiedlichen Quellen für den Anwender schwierig und
ineffizient. Einerseits stellen die meisten Plug-Ins unterschiedliche Anforderungen an
vorinstallierte Plug-Ins und die Umgebung, und andererseits müssen die meisten PlugIns unterschiedlich gehandhabt und unterschiedlich in die Zielanwendung integriert
werden. Auch das Kapseln der Plug-Ins aus unterschiedlichen Quellen würde aus
oben genannten Gründen keine zufriedenstellende Usability bringen.
Als beste Möglichkeit erscheint es daher, die Module selbst zu entwickeln, und je
nach Eignung bzw. Verfügbarkeit bestehende Plug-Ins entweder als Basis zu
verwenden, sie zu integrieren, oder sie so anzupassen, dass sie den Anforderungen
entsprechen.
2009-09-10
35/107
4 Beschreibung der Lösungsidee
Nachdem die Anforderungen definiert wurden, und der State of the Art ermittelt
wurde, wird in diesem Kapitel die Lösungsidee beschrieben.
4.1 Gesamtkonzept und Aufbau der Anwendung, Plug-Ins
Durch die Vorgabe, dass einerseits aus den Modulen eine vollständige Groupware
Anwendung erstellt werden soll, und andererseits die Module flexibel eingesetzt
werden können sollen, lassen sich zwei Anwendungsfälle ableiten:
1. Die Module sollen in eine bereits bestehende Anwendung integriert werden.
Dies ist zum Beispiel der Fall, wenn ein Anwendungsentwickler eine bereits
bestehende Anwendung um kooperative Elemente erweitern möchte, es ist aber
auch denkbar, dass einzelne Elemente einer bestehenden Anwendung durch neue
ersetzt werden sollen.
2. Ein kollaboratives System soll von Grund auf neu erstellen werden.
Die Benutzer stehen bei der Zusammenarbeit im Mittelpunkt, deshalb ist die
Benutzerverwaltung ein zentraler Bestandteil einer kollaborativen Anwendung. Es ist
davon auszugehen, dass in Anwendungsfall 1 von einem System ausgegangen wird,
das bereits über eine Benutzerverwaltung verfügt. In Anwendungsfall 2 hingegen soll
ein System inklusive Benutzerverwaltung erstellt werden.
Umsetzung
Um diese beiden Anwendungsfälle zu berücksichtigen, wurde das gesamte Projekt aus
zwei Grundbestandteilen aufgebaut:
•
Basisanwendung, Cooperation
Die Basisanwendung beinhaltet als zentralen Bestandteil die Benutzerverwaltung
und implementiert bereits die Entwurfsmuster Quick Registration, Login und
Quick Goodbye. Alle anderen Module können auf diese Anwendung aufbauen.
Cooperation lässt sich als Gesamtpaket installieren.
•
Ein Paket, das alle implementierten Module beinhaltet, mit CMI 34 bezeichnet
Alle umgesetzten Entwurfsmuster (außer jene, die bereits in der Basisanwendung
enthalten sind) wurden als Plug-Ins 35 implementiert. Sie befinden sich in einem
gemeinsamen Verzeichnis mit dem Namen cmi. Dieses Verzeichnis kann direkt in
das plugins Verzeichnis der Zielanwendung kopiert werden, sämtliche Module
34
Diese Abkürzung steht für Computer Mediated Interaction.
Im folgenden Text werden die Begriffe Modul und Plugin synonym verwendet, wenn aus dem
Kontext klar hervorgeht, was damit gemeint ist.
35
2009-09-10
36/107
werden dann von dort aus wie in Rails üblich über den Generator des Plug-Ins in
die Anwendung installiert.
Dieses Konzept ermöglicht es, dass Anwendungsfall 1 erfüllt werden kann, indem auf
das Basisprojekt verzichtet wird, und lediglich die benötigten Module in die
Anwendung installiert werden.
In Anwendungsfall 2 kann das Basisprojekt als Grundlage für die gesamte
Anwendung verwendet werden, die benötigten Module werden dann in das
Basisprojekt installiert.
4.2 Umsetzung der Entwurfsmuster in Plug-Ins
Um für die Plug-Ins eine schwache Kopplung und starke Kohäsion zu erreichen,
wurden die in Abschnitt 2.2 ausgewählten Entwurfsmuster so umgesetzt, dass
Entwurfsmuster mit starken Abhängigkeiten (wie das z.B. für Room, Invitation und
Bell zutrifft) in Plug-Ins zusammengefasst wurden.
Tabelle 14 gibt einen Überblick, wie die Entwurfsmuster in Plug-Ins (bzw. dem
Basisprojekt) umgesetzt wurden. Die Spalte Plug-In gibt an, in welchem Plug-In
dieses Entwurfsmuster umgesetzt wurde, die durch * gekennzeichneten Muster
wurden durch ein externes Plug-In realisiert.
Name
Quick Registration
Login
Virtual Me
User Gallery
Buddy List
Availability Status
Quick Goodbye
Group
Room
Interaction Directory
Bell
Invitation
Embedded Chat
User List
Spontaneous Collaboration
Interactive User Info
Collaborative Session
Centralized Objects
Remote Subscription
Mediated Updates
Immutable Versions
Activity Log
Plug-In
Basisprojekt
cmi_virtual_me
cmi_user_gallery
cmi_buddy_list
cmi_virtual_me
Basisprojekt
Simple Groups*
Attachment Fu*
cmi_room
cmi_embedded_chat
cmi_room, cmi_coll_session
cmi_buddy_list, cmi_room, cmi_coll_session
cmi_interactive_user_info
cmi_coll_session
cmi_room
cmi_remote_subscription
Juggernaut*
acts_as_versioned*
Tabelle 14: Implementierte Entwurfsmuster
2009-09-10
37/107
Wurden Komponenten identifiziert, die von mehreren Plug-Ins benötigt werden, so
wurden diese in separaten Plug-Ins ausgelagert, diese implementieren somit nicht
direkt ein Entwurfsmuster.
Folgende Abbildung zeigt die Plug-Ins und deren Beziehungen zueinander. Einige
Beziehungen zwischen Plug-Ins sind optional, und wurden durch das Stereotyp
<<optional>> gekennzeichnet. Optionale Plug-Ins werden vom jeweiligen Plug-In
selbst nicht benötigt, das Plug-In funktioniert also vollständig ohne die optionalen
Abhängigkeiten. Möchte der Benutzer jedoch die Funktionalität des optionalen PlugIns nutzen, so muss dieses zusätzlich eingebunden werden.
Ausgelagerte Plug-Ins sind in der Abbildung grau hinterlegt.
Aus Gründen der Übersichtlichkeit sind die Abhängigkeiten zu Plug-Ins aus externen
Quellen, die nicht direkt Entwurfsmuster implementieren, hier nicht abgebildet.
Abb. 15: Plug-Ins
4.3 Verwendbarkeit
Generierung , Installation in die Anwendung
Das Verzeichnis, das die Module beinhaltet lässt sich per copy/paste in das plugins
Verzeichnis der Zielanwendung überführen. Danach können die einzelnen Plug-Ins,
wie in Rails üblich, über ruby script\generate generator [options] [args]
generiert, und in die Anwendung installiert werden.
Jedes Plug-In verfügt, sofern erforderlich, über einen eigenen Generator.
2009-09-10
38/107
Integration in die Anwendung
Wie die Integration der Plug-Ins im Einzelnen erfolgt, ist in Abschnitt 5 beschrieben.
Grundsätzlich wurde jedoch darauf Wert gelegt, dass für den Anwender möglichst
wenig Aufwand bei der Integration entsteht, und diese somit so einfach wie möglich
erfolgen kann.
4.4 Konfigurierbarkeit
Folgende Tabelle gibt einen Überblick über die Konfigurierungsmöglichkeiten der
einzelnen Plug-Ins. Die äußerst linke Spalte gibt den Namen des Plug-Ins an, die
Spaltenüberschriften die Art der Konfiguration. Dabei bedeutet:
•
•
•
•
•
•
Generierung, Installation in die Anwendung
Das Ergebnis der Installation kann durch Angabe von Parametern beeinflusst
werden.
Tabelle
Durch Änderungen in der Migrationsdatei 36 wird das Model konfiguriert (z.B.
indem Attribute geändert werden).
Model-Ebene
Das Model wird durch Parameter direkt im Model geändert.
Model erweitern
Ein Model wird durch das Plug-In erweitert (z.B. über acts_as_...).
Integration
Konfiguration durch die Art der Integration in die Anwendung.
Konfig.- Datei
Das Plug-In kann durch eine externe Konfigurationsdatei konfiguriert werden.
36
Die Versionierung des Datenbank-Schemas erfolgt in Rails über Migrationen. In (Fischer 2008, S.
41) wird eine Migration wie folgt beschrieben: "Migrationen sind kleine Ruby-Programme, die eine
Datenbank von einer Version in die nächst höhere oder niedrigere 'befördern'."
2009-09-10
39/107
Wie die Konfigurierung im Detail erfolgt, wird im Abschnitt 5.2 beschrieben.
Generierung,
Installation
Tabelle
ModellEbene
Modell
erweitern
Integration
9
Basisprojekt
9
cmi_virtual_me
9
9
9
9
cmi_user_gallery
cmi_buddy_list
Simple Groups
9
cmi_embedded_chat
cmi_coll_session
cmi_interactive_user_info
9
9
Attachment Fu
cmi_room
9
9
9
9
cmi_remote_subscription
9
9
9
Juggernaut
9
Tabelle 15: Konfigurationsmöglichkeiten der Plug-Ins
acts_as_versioned
Konfig.Datei
9
9
9
4.5 Synchronizität
Als Basis für die Umsetzung der Entwurfsmuster, die Synchronizität erfordern, wurde
aufgrund der Ergebnisse der Untersuchung (siehe Abschnitt 3.1) das Plug-In
Juggernaut ausgewählt.
Folgende Entwurfsmuster beinhalten synchrone Komponenten, die mit Juggernaut
umgesetzt wurden:
• Buddy List
• Spontaneous Collaboration
• Bell
• Invitation
• Embedded Chat
• User List
• Collaborative Session
Alle Plug-Ins, die eine optionale Abhängigkeit zu Juggernaut besitzen, können auch
ohne Juggernaut verwendet werden. Dann ist das Verhalten der Plug-Ins asynchron.
4.6 Modelle
Da Rails- Anwendungen nach dem MVC Pattern aufgebaut sind, werden auch in
dieser Arbeit die Daten der Plug-Ins durch Models repräsentiert.
Folgende Abbildung zeigt die Modelle der Plug-Ins, und deren Beziehungen
zueinander. Aus Gründen der Übersichtlichkeit sind nur die Modelle der neu
2009-09-10
40/107
entwickelten Plug-Ins abgebildet, jene der Plug-Ins aus externen Quellen wurden
nicht berücksichtigt.
Eine detaillierte Beschreibung der Architektur, und der Modelle, befindet sich im
Abschnitt 5.2, in der Beschreibung der einzelnen Plug-Ins.
Abb. 16: Modelle und deren Beziehungen zueinander
2009-09-10
41/107
Details zur Lösung
5 Details zur Lösung
In diesem Kapitel wird auf die Realisierung der einzelnen Entwurfsmuster
eingegangen.
5.1 Allgemein
Zunächst werden die Anforderungen an das System definiert, danach wird die
Installation der Komponenten auf dem System beschrieben, und im Anschluss daran
werden die getroffenen Sicherheitsmaßnahmen kurz vorgestellt.
Anforderungen an das System
Die CMI Plug-Ins können unabhängig vom Basisprojekt verwendet werden. Einzige
Vorbedingung ist, dass das bestehende Projekt eine Benutzertabelle mit dem Namen
user und einem Schlüssel id besitzt, und dass das Projekt eine sessions Tabelle hat.
Weiters müssen die Methoden des Moduls AuthenticatedSystem des Plug-Ins
Restful Authentication zur Verfügung stehen 37.
Die gesamte Anwendung wurde unter Microsoft Windows XP entwickelt. Als UnixPlattform wurde Ubuntu 8.10 verwendet.
Alle Module wurden mit den Browsern Firefox 3.0.8 und Chrome 1.0.154 getestet.
Als Rails Version wurde 2.2.2 zusammen mit Ruby 1.8.6 verwendet.
Generell wird vorausgesetzt, dass der verwendete Webbrowser so konfiguriert ist,
dass Javascript aktiviert ist.
Installation
Eine nähere Beschreibung zur Installation von Cooperation ist im Abschnitt 5.2.1 zu
finden.
Die Installation des Verzeichnisses cmi, das die implementierten Plug-Ins beinhaltet,
kann einfach per copy/paste in das plugins Verzeichnis der Zielanwendung erfolgen.
Wie die Module im Einzelnen installiert werden, ist in der Dokumentation des
entsprechenden Moduls nachzulesen.
Sicherheit
Die Benutzerverwaltung und Authentisierung wurde in der Basisanwendung mittels
des Plug-Ins Restful Authentication implementiert.
Der Login Zustand des Benutzers wird über den Before Filter in der Datei
application.rb global für die Anwendung überprüft.
37
Genauer gesagt werden im gesamten Projekt davon nur die Methoden logged_in?,
:login_required und current_user verwendet.
2009-09-10
42/107
Details zur Lösung
Die Sicherheitsabfragen für die einzelnen Module erfolgen über Before Filter in den
jeweiligen Controllern.
Die Definition eines Administrators kann in der Datei application.rb über die
Methode is_admin? erfolgen.
5.2 Realisierung der Entwurfsmuster
Es folgt nun die Beschreibung des Basisprojekts und der Plug-Ins, und wie die
entsprechenden Entwurfsmuster implementiert wurden. Jeder Abschnitt ist
üblicherweise wie folgt aufgebaut:
• Abhängigkeiten
Zu Beginn zeigt ein Paketdiagramm die erforderlichen, und optionalen
Abhängigkeiten auf. Die optionalen Abhängigkeiten sind durch das Stereotyp
<<optional>> gekennzeichnet, ausgelagerte Plug-Ins sind grau hinterlegt, und
Plug-Ins aus externen Quellen sind gepunktet dargestellt (siehe auch 4.2).
• Beschreibung
Hier erfolgt eine allgemeine Beschreibung des Moduls.
• Generierung und Installation in die Anwendung
Unter diesem Punkt wird beschrieben, wie die Komponenten des Plug-Ins
generiert werden, und wie diese in die Anwendung installiert werden. Hier werden
auch die Optionen, die der jeweilige Generator anbietet, vorgestellt.
• Integration in die Anwendung
Nachdem das Plug-In installiert wurde, können dessen Komponenten in die
Anwendung integriert werden. Wie diese Integration erfolgt, wird hier
beschrieben.
• Implementierung
In diesem Abschnitt wird auf einige Implementierungsdetails näher eingegangen.
5.2.1 Basisprojekt (Quick Registration, Login, Quick Goodbye)
Abhängigkeiten
Das Basisprojekt besitzt Abhängigkeiten zu den externen Plug-Ins Restful
Authentication und acts_as_state_machine.
Abb. 17: Basisprojekt Abhängigkeiten
2009-09-10
43/107
Details zur Lösung
Beschreibung
Das Basisprojekt basiert auf dem Plug-In Restful Authentication. Näheres zur
Benutzung von Restful Authentication ist in dessen Benutzerdokumentation auf
http://agilewebdevelopment.com/plugins/restful_authentication beschrieben.
Generierung und Installation in die Anwendung
•
Anwendung in das Zielverzeichnis kopieren
Die Basisanwendung kann direkt aus dem Repository in das Zielverzeichnis
kopiert werden, es sind keine weiteren Schritte für die Installation notwendig,
wenn die Anforderungen an das System erfüllt sind.
•
Datenbank erzeugen
Nachdem das Projekt ins Zielverzeichnis kopiert wurde (bzw. ins Zielprojekt
integriert wurde), muss die Datenbank für die Benutzer und die Sessions erzeugt,
und migriert werden.
Dies wird unter MS Windows durch rake db:create RAILS_ENV=production 38
mit anschließendem rake db:migrate erreicht.
•
Server
Um die Anwendung zu verwenden, muss zuerst der Rails-Server gestartet werden.
Das wird durch den Aufruf von ruby script\server erreicht. Der Server läuft,
auf dem Rails default Port 3000.
•
Konfigurierung
Die Anwendung kann, wie in Rails üblich, über die Datei environment.rb
konfiguriert werden.
Benutzung
Nach der Installation des Projekts sollte der ActionMailer 39 so konfiguriert werden,
dass das Versenden von Emails möglich ist. Damit die versendeten Links stimmen,
sollte die Konstante YOURSITE in der Datei user_mailer.rb angepasst werden.
Die Registrierung eines neuen Benutzers (Quick Registration) erfolgt über die
Action signup 40. Nach Eingabe der Daten wird eine Email mit einem Aktivierungslink
an die angegebene Adresse gesendet (ein Aktivierungslink ist nach folgendem
Schema aufgebaut: http://hostname:port/activate/activation_code). Nachdem der
Account aktiviert wurde, kann sich der neue Benutzer über die Action login einloggen
(Login).
Für den Logout steht die Action logout zur Verfügung.
38
Da die gesamte Anwendung unter MS Windows entwickelt wurde, wird für die Beschreibungen
jeweils die Syntax für MS Windows verwendet.
39
ActionMailer ist Bestandteil des Rails Frameworks und wird in diesem Projekt zum Versenden von
Emails verwendet. Die Konfigurierung des ActionMailers erfolgt über die Datei environment.rb.
40
Der vollständige Link für den Aufruf lautet somit z.B. http://localhost:3000/signup
2009-09-10
44/107
Details zur Lösung
Über forgot_password kann ein neues Passwort angefordert werden.
Soll der Account gelöscht werden (Quick Goodbye), so kann dies durch Aufruf von
set_deleted erreicht werden. Der Account wird in der Datenbank als gelöscht
markiert, und der Benutzer ist nach dem nächsten Logout gesperrt. Der Account wird
wird jedoch nicht gelöscht. Dies hat den Vorteil, dass bestehende Referenzen auf den
Account, wie z.B. auf dessen Virtual Me, gültig bleiben, und nicht verwaisen.
Über main gelangt man auf die Hauptseite, auf der auf einfache Art und Weise
Beispielcode für die meisten CMI Plug-Ins eingebunden werden kann.
5.2.2 Plug-In cmi_virtual_me (Virtual Me, Availability Status)
Abhängigkeiten
Das Plug-In cmi_virtual_me besitzt eine direkte Abhängigkeit zum externen Plug-In
acts_as_state_machine, da der Availability Status des Users als State Machine 41
realisiert wurde.
Die optionale Abhängigkeit zu cmi_interactive_user_info wird lediglich zur
Einstellung des Availability Status durch den Benutzer benötigt.
Abb. 18: cmi_virtual_me Abhängigkeiten
5.2.2.1 Virtual Me
Beschreibung
Das Modul cmi_virtual_me ist ein Plug-In nach dem acts_as... Prinzip - das heißt, ein
Model (in diesem Fall ein User) kann durch das Einfügen von acts_as_virtual_me
erweitert werden, man erhält somit direkt über den User, der erweitert wurde, Zugriff
auf die acts_as_virtual_me Attribute und Methoden. Es wird vorausgesetzt, dass
der User (bzw. das Model, das erweitert wird), das Attribut user_id besitzt.
41
Eine State Machine ( Zustandsmaschine) ist ein Modell des Verhaltens, bestehend aus Zuständen,
Zustandsübergängen und Aktionen. (Wikipedia 2009a)
2009-09-10
45/107
Details zur Lösung
Der Aufruf von ruby script\generate cmi_virtual_me kopiert die
entsprechenden Dateien in das Anwendungsverzeichnis und generiert eine
Migrationsdatei, die die entsprechende Tabelle erzeugt, nachdem die Migration
mittels rake db:migrate durchgeführt wurde.
Über den Parameter --skip-migration kann das Erzeugen der Migration
übersprungen werden.
Zusätzlich wird das Plug-In cmi_user_avatar automatisch mit installiert, falls es noch
nicht vorhanden ist. Die Assoziation zwischen CmiUserAvatar und User muss
jedoch ggf. noch manuell im User Model, durch Einfügen der Zeile has_one
42
:cmi_user_avatar im User Model, definiert werden , da es nicht möglich ist, die
Relationen zwischen den Tabellen aus dem Datenbankschema zu bestimmen
(Hansson 2009, S. 358). Im Anschluss daran muss noch im Model, das erweitert
werden soll, die Zeile acts_as_virtual_me eingefügt werden.
Wird das Modul installiert, so wird eine neue Tabelle in der Datenbank angelegt.
Diese Tabelle enthält die Attribute, um die der User erweitert werden soll.
Soll der User um andere Attribute als die vorgegebenen erweitert werden, kann dies
direkt in der Migrations-Datei erfolgen. Die Spalten user_id und state werden
jedoch vom Plug-In selbst benötigt, und dürfen somit nicht gelöscht werden.
Die Attribute von Virtual Me können nun auf verschiedene Arten, wie im folgenden
Beispiel gezeigt, gelesen bzw. geschrieben werden (der Parameter a_user entspricht
dabei einem User):
•
lesen

<%= a_user.get_virtual_me_attr('country') %>

<%= a_user.country_vme %>
•
schreiben

<%= a_user.set_virtual_me_attr(:country => 'Deutschland', :last_name =>
'Giesinger') %>

<%= a_user.set_virtual_me_attr('country', 'Deutschland') %>

<%= a_user.country_vme = 'Deutschland' %>
Benutzung - Nach Benutzerdaten suchen
Die Anforderung, dass Benutzer nach bestimmten Kriterien durchsucht werden
können sollen (siehe auch User Gallery), wurde im Plug-In cmi_virtual_me
42
Aus Gründen der Benutzbarkeit wurde hier, wie auch in den anderen Plug-Ins, darauf verzichtet, die
Assoziation durch den Generator in das assoziierte Model per default einzufügen.
2009-09-10
46/107
Details zur Lösung
implementiert. Dazu ruft man über den User die Methode find_string_in_users
auf, und übergibt den Suchstring und ein Array mit den Spalten, die durchsucht
werden sollen. Die Spalten können sich dabei sowohl in der users-, als auch in der
cmi_virtual_me- Tabelle befinden. Rückgabewert ist ein Array mit den Usern, in
denen der gesuchte String gefunden wurde. Die Spaltennamen müssen deshalb als
Parameter mit übergeben werden, damit die Suche durch den Anwendungsentwickler
auf bestimmte Spalten eingegrenzt werden kann.
Anwendungsbeispiel
search_string = 'd.b'
columns = ['login', 'email', 'first_name', 'last_name']
found_users = User.find_string_in_users(search_string, columns)
Benutzung - Benutzerdaten editieren
Die View für das Editieren der Benutzerdaten (cmi_virtual_me_edit.html.erb) wird
vom Generator in das Verzeichnis cmi_general installiert.
Diese View kann standardmäßig über die Interactive User Info, oder über den Link
/cmi_virtual_mes/edit/user_id aufgerufen werden. Sie stellt sowohl die Möglichkeit,
die User Attribute (wie Email und Avatar), als auch die Virtual Me Attribute zu
editieren, zur Verfügung. Wird ein neues Bild für den User Avatar ausgewählt, wird
dieses Bild nach dem Betätigen des Buttons Update User zum Server übertragen, und
dort im Verzeichnis public\cmi_user_avatars\user_id\version abgespeichert.
Abb. 19: Virtual Me mit aufgeklapptem Tooltip und Edit user data
2009-09-10
47/107
Details zur Lösung
5.2.2.2 Availability Status
Dieses Entwurfsmuster ist ebenfalls im Plug-In cmi_virtual_me implementiert.
Beschreibung
Der Benutzer kann seinen Availability Status einstellen, dieser Status ist für andere
Benutzer sichtbar.
Die Aktualisierung des Availability Status kann über einen Before Filter erfolgen,
der die Class Method update_session des CmiHelper Moduls aufruft. Es empfiehlt
sich, einen solchen Filter überall da einzufügen, wo Benutzeraktionen erfolgen, sowie
beim Logout, so wie dies im Basisprojekt bereits implementiert ist (siehe z.B.
destroy
Methode im sessions_controller.rb bzw. before_filter im
main_controller.rb).
Beispiel:
• Einen Before Filter definieren:
•
before_filter :update_session
die dazu gehörende Methode sieht so aus:
def update_session
CmiHelper.update_virtual_me(session, new_state)
end
Benutzung
Der Availability Status kann durch den Benutzer über die Interactive User Info
eingestellt werden.
Abb. 20: Availability Status
Es gibt jedoch auch Availability States, die nicht vom Benutzer selbst eingestellt
werden, sondern durch die Applikation. Beispiele dafür sind online/offline, diese
werden von der Anwendung eingestellt, wenn sich ein Benutzer ein- bzw. ausloggt.
Ein Spezialfall ist der Status away, dieser kann einerseits durch den Benutzer selbst
gewählt werden, andererseits wird der Status automatisch gesetzt, wenn ein Benutzer
über einen bestimmten Zeitraum hinweg inaktiv ist.
Implementierung
2009-09-10
48/107
Details zur Lösung
Wird beim Aufruf von update_virtual_me für new_state einer der definierten
Availability States angegeben, so wird der gewünschte Status eingestellt, sofern
erlaubt. Wird als new_state ein leerer String angegeben, so wird in der Class Method
update_virtual_me_state der Klasse CmiVirtualMesController versucht, den
Status automatisch zu bestimmen.
Die Methode update_virtual_me hat die zusätzliche Funktion, dass für jeden User
ein Virtual Me in der Datenbank angelegt wird, falls dieser noch nicht vorhanden ist.
Der Availability Status selbst wird in der Tabelle cmi_virtual_mes in der Spalte
state abgespeichert.
Die Zustände und Zustandsübergänge sind als State Machine mit dem Plug-In
acts_as_state_machine im Model CmiVirtualMe realisiert.
Abb. 21: Availability State Zustandsdiagramm
Sollen neue bzw. andere Zustände definiert werden, so kann das direkt in den Klassen
CmiVirtualMeController und CmiVirtualMe im Code geändert werden, dies erfolgt
über die in acts_as_state_machine übliche Syntax (siehe Abschnitt 5.3.4).
Das Plug-In acts_as_state_machine wurde um Methoden erweitert, die es
ermöglichen, alle bzw. alle möglichen Folgezustände vom momentanen Zustand aus
zu ermitteln. Diese Folgezustände können dann direkt, oder noch zusätzlich gefiltert,
verwendet werden, um z.B. über Links einen Zustandsübergang auszulösen. Diese
Lösung funktioniert unabhängig von den definierten Zuständen und macht die
Anwendung deshalb besonders flexibel.
Anwendungsbeispiel
Durch folgenden Code werden von einem gegebenen Zustand aus die möglichen
Folgezustände ermittelt, und als Links in die Anwendung eingefügt:
1. <% possible_states =
virtual_me.possible_events_from_state(virtual_me.state) %>
2. <% possible_states = CmiVirtualMesController.filter_states
(possible_states, virtual_me.state) %>
3. <% possible_states.each do |state_to_set| %>
4.
<%= link_to state_to_set.to_s, :controller => "cmi_virtual_mes",
:action => "do_" + state_to_set.to_s,
:params => { :the_user => the_user } %>
5. <% end %>
2009-09-10
49/107
Details zur Lösung
Ausgehend vom Zustand online und dem in Abb. 21 dargestellten Zustandsdiagramm,
ergibt sich folgender Programmablauf:
In Zeile 1 werden zunächst vom aktuellen Zustand eines virtual mes aus die
möglichen Folgezustände ermittelt, und der Variablen possible_states zugewiesen.
Der Inhalt von possible_states ist nun :away, :offline, :busy.
Danach werden in Zeile 2 die Zustände gefiltert, denn nicht alle möglichen
Folgezustände sollen durch den Benutzer eingestellt werden können. Der Inhalt von
possible_states ist dann :away, :busy.
Diese Zustände werden danach über den Code der Zeilen 4 und 5, in der View als
Links dargestellt, siehe dazu Abb. 20 oben.
5.2.3 Plug-In cmi_user_gallery (User Gallery)
Abhängigkeiten
Das Plug-In cmi_user_gallery besitzt direkte Abhängigkeiten zu den Plug-Ins Tooltips
und cmi_user_avatar, wobei das Plug-In cmi_user_avatar automatisch mit installiert
wird, falls es noch nicht vorhanden ist.
Die optionale Abhängigkeit zu cmi_virtual_me ist erforderlich, falls nach Daten in der
User- bzw. der Virtual Me Tabelle gesucht werden können soll.
Abb. 22: cmi_user_gallery Abhängigkeiten
Beschreibung
Die User Gallery zeigt alle Benutzer einer Anwendung an, egal, ob sie gerade aktiv
sind, oder nicht.
Mit ruby script\generate cmi_user_gallery werden die erforderlichen Dateien
in das Anwendungsverzeichnis kopiert.
Zusätzlich wird das Plug-In cmi_user_avatar automatisch installiert, falls es noch
nicht vorhanden ist. Der optionale Parameter --skip-migration verhindert das
Erzeugen der Migrationsdatei.
Die Assoziation zwischen CmiUserAvatar und User (has_one :cmi_user_avatar)
muss noch manuell im User Model definiert werden.
2009-09-10
50/107
Details zur Lösung
Das Modul kann in die Anwendung eingebunden werden, indem das Partial
_cmi_user_gallery.html.erb an der gewünschten Stelle in eine View eingefügt wird.
Über den Aufruf kann der Inhalt des angezeigten Tooltips durch die Übergabe von
Parametern für externe Links (ext_links) konfiguriert werden, wobei der Aufruf
mit- oder ohne Parameter erfolgen kann:
•
Beispiel 1: Aufruf ohne Parameter
Nur die per default definierten Inhalte und Links erscheinen im Tooltip.
Dies kann z.B. durch Einfügen folgender Zeile in die Datei index.html.erb
erfolgen:
<%= render(:partial => "cmi_general/cmi_user_gallery.html.erb" %>
•
Beispiel 2: Aufruf mit Parameter
Zusätzlich zu den per default definierten Inhalten und Links können Inhalte bzw.
Links über die Parameter beim Aufruf definiert werden.
Der User Gallery wird dabei beim Aufruf über den Parameter :locals ein String
übergeben, der auf ein Partial verweist, in dem diese zusätzlichen Inhalte definiert
sind. Diese Inhalte sind dann in der Anwendung über den Tooltip des Users in der
User Gallery aufrufbar:
<%= render(:partial => "cmi_general/cmi_user_gallery.html.erb",
:locals => {:ext_links =>
"/cmi_general/cmi_user_gallery_create_buddy_links.html.erb"}) %>
Da die Links zum Einfügen eines Benutzers in die Buddy List im per default
konfigurierten Partial cmi_user_gallery_create_buddy_links.html.erb implementiert
sind, wird empfohlen, die User Gallery mit dem passenden Parameter ext_links (wie
oben in Beispiel 2 gezeigt), aufzurufen.
Benutzung
Die User Gallery zeigt jeden User durch dessen Login Name und User Avatar an.
Hat ein Benutzer keinen Avatar definiert, so wird ein Standard- Bild angezeigt.
•
Aktionen mit anderen Benutzern über die User Gallery
Über die User Gallery sind Aktionen mit anderen Usern möglich. Per Mausklick
auf den entsprechenden User Avatar öffnet sich ein Tooltip, der die möglichen
Aktionen mit diesem Benutzer anbietet.
2009-09-10
51/107
Details zur Lösung
Abb. 23: User Gallery mit geöffnetem Tooltip
•
Nach Benutzerdaten suchen:
Das Plug-In cmi_virtual_me stellt die Methode find_string_in_users bereit,
die das Suchen nach Benutzerdaten ermöglicht. Soll also nach Benutzerdaten
gesucht werden können, so kann dies nur in Kombination mit cmi_virtual_me
erfolgen.
Implementierung:
Standardmäßig werden alle User aus der User Tabelle in der User Gallery angezeigt,
die sich im Status aktiv befinden (also nicht User, die noch nicht aktiviert sind, oder
User, die gesperrt wurden, siehe Quick Goodbye). Die Abfrage der aktiven Benutzer
erfolgt über die Methode filtered_users(user) im CmiHelper. Sollen also nur
bestimmte Benutzer angezeigt werden, so können die Benutzer an dieser Stelle bei
Bedarf beliebig gefiltert werden.
Die User Avatars sind im Plugin cmi_user_avatar realisiert, in der User Gallery
werden sie vom Partial _cmi_current_user.html.erb dargestellt.
Die Tooltips wurden mit dem Plug-In Tooltips realisiert, das natürlich für die
Verwendung der User Gallery zuerst installiert werden muss.
Weitere mögliche Benutzerinteraktionen können z.B. durch ein zusätzliches Partial
konfiguriert werden (siehe oben).
5.2.4 Plug-In cmi_buddy_list (Buddy List, Spontaneous
Collaboration)
Abhängigkeiten
Das Plug-In cmi_buddy_list besitzt direkte Abhängigkeiten zu den Plug-Ins
cmi_message, acts_as_state_machine, cmi_user_avatar (wird automatisch installiert)
und Tooltips.
Optionale Abhängigkeiten bestehen zu cmi_user_gallery (zum Hinzufügen bzw.
Entfernen von Benutzern zur eigenen Buddy List über das entsprechende Icon),
2009-09-10
52/107
Details zur Lösung
cmi_virtual_me (für den Availability Status) und Juggernaut (für das synchrone
Verteilen der Buddy Requests).
Abb. 24: cmi_buddy_list Abhängigkeiten
Beschreibung
Die Namen der bekannten Benutzer (Friends, Buddies) werden in der Buddy List
zusammen mit ihrem Avatar und dem Availability State angezeigt. Des weiteren ist
die Buddy List ein Startpunkt für verschiedene Benutzerinteraktionen.
Alle erforderlichen Komponenten werden über den Aufruf ruby script\generate
cmi_buddy_list generiert und installiert. Es wird unter anderem eine Migration
angelegt, das kann jedoch durch Angabe des Parameters --skip-migration
Das Plug-In besitzt eine Abhängigkeit zum Infrastruktur-Plug-In cmi_message. Soll
Buddy List ohne die vorherige Installation von cmi_message installiert werden, muss
der Parameter --skip-cmi-messages angegeben werden.
Zusätzlich wird das Plug-In cmi_user_avatar automatisch installiert, falls es noch
nicht vorhanden ist. Die Assoziation mit dem User Model (has_one
:cmi_user_avatar) muss jedoch noch manuell erfolgen.
Wie immer, muss die Migration nach der Installation noch ausgeführt werden.
Die Views werden in das Verzeichnis /app/views/cmi_buddy_list installiert.
Die users und cmi_buddy_lists stehen in einer 1:n Beziehung zueinander, wobei
die Einträge in der cmi_buddy_lists Tabelle den Buddies der User entsprechen. Vor
2009-09-10
53/107
Details zur Lösung
der Verwendung muss diese Assoziation durch das Einfügen von has_many
:cmi_buddy_lists im User Model definiert werden.
Die Buddy List kann durch Einfügen des Partials _cmi_buddy_list.html.erb in eine
View eingebunden werden. Die anzuzeigenden Buddies und zusätzliche, über den
Tooltip der Buddy List aufrufbare Links, sind dabei über den Aufruf konfigurierbar.
Beispiel für die Verwendung der View:
Das Partial wird in der Datei index.html.erb des Basisprojekts wie folgt eingefügt:
<% the_user_ids = CmiHelper.get_buddy_ids_by_conditions(current_user,
"state == 'confirmed'")%>
<%= render(:partial => "cmi_buddy_list/cmi_buddy_list.html.erb",
"/cmi_buddy_list/cmi_buddy_list_default_links.html.erb",
:the_user_ids => the_user_ids}) %>
Konfigurierung
Der Inhalt der Buddy List View ist über den Parameter :locals beim Aufruf
folgendermaßen konfigurierbar:
• the_user_ids:
Ein Array, welches die User ids der Buddies enthält, die in der Buddy List
angezeigt werden sollen.
• ext_links:
Ein String, der auf ein Partial verweist, in dem zusätzliche externe Links oder
sonstige Inhalte definiert sind, die dann in der Anwendung über den Tooltip des
Users in der Buddy List aufrufbar sind.
Wird dieser Parameter nicht angegeben, so erscheinen keine zusätzlichen Links.
Abb. 25: Buddy List mit geöffnetem Tooltip
Der Availability Status wird nur angezeigt, wenn das Modul Virtual Me installiert ist.
2009-09-10
54/107
Details zur Lösung
Benutzung
Möchte ein Benutzer einen anderen Benutzer in seine eigene Buddy List aufnehmen,
so klickt er auf das Icon des anderen Benutzers in der User Gallery, und wählt dort
den Link Add to Buddies.
Der andere Benutzer erhält nun eine Mitteilung über die Kontaktaufnahme per Email
und über Juggernaut. Ist der andere Benutzer mit der Anfrage einverstanden, und
möchte den Benutzer in seine Buddy List aufnehmen, so kann er den zusammen mit
der Nachricht verschickten Aktivierungslink aufrufen. Nun werden beide Benutzer in
die jeweilige Buddy List eingetragen.
Möchte einer der Beiden die Freundschaft aufkündigen, so kann er dies über den
entsprechenden Link in der User Gallery, oder über den äquivalenten Link in der
Buddy List, erreichen. Beide Benutzer werden dann aus beiden Listen entfernt.
Die Buddy List ist der ideale Startpunkt für Spontaneous Collaboration mit anderen
Benutzern.
Implementierung
Der Prozess wie zwei Benutzer miteinander sich miteinander befreunden (Buddies
werden), wird durch eine State Machine abgebildet. Die State Machine ist durch
acts_as_state_machine realisiert. Folgende Zustände sind möglich: new, requested,
confirmed, declined.
Abb. 26: Buddy List Zustandsdiagramm
Wenn eine Buddy Anfrage erfolgt, und es existiert noch kein passender Eintrag in der
cmi_buddy_lists Tabelle der Datenbank, so wird ein neuer Eintrag mit dem Zustand
new angelegt, und durch einen Request-Event sofort in den Zustand requested
überführt. Von da aus kann er durch Aufruf eines Aktivierungslinks mit dem richtigen
activation_code in den Zustand confirmed überführt werden. Von confirmed kann er
unter anderem in den Zustand declined überführt werden.
Beispiel für einen Aktivierungslink:
http://localhost:3000/cmi_buddy_lists/do_confirm/f86e103587afad45734f99446a9e24
721caf2599
Der Availability State der Buddy List aktualisiert sich in einem periodischen Zeitraum
selbst, dies ist über einen periodically_call_remote Aufruf realisiert. Das führt
dazu, dass der Availability Status der Buddies stets aktuell ist. Das Intervall der
2009-09-10
55/107
Details zur Lösung
Aktualisierung
ist
durch
das
:frequency
_cmi_buddy_list_users.html.erb einstellbar.
Attribut
im
Partial
Buddy List benötigt das Infrastruktur-Plug-In cmi_message für die Verteilung der
Buddy Request Messages an die Benutzer.
5.2.5 Plug-In Simple Groups (Group)
Abhängigkeiten
Simple Groups besitzt keine Abhängigkeiten zu anderen Plug-Ins.
Beschreibung
Benutzer sollen mit Gruppen wie mit anderen Benutzern agieren können, um z.B.
allen Gruppenmitgliedern eine Nachricht zukommen zu lassen.
Plug-In installieren
Dieses Entwurfsmuster wird durch das externe Plug-In Simple Groups realisiert.
Die Homepage von Simple Groups ist im Web unter dem Link
http://agilewebdevelopment.com/plugins/simple_groups zu finden, die Quellen befinden sich auf GitHub (http://github.com/JonMidhir/simple_groups/tree/master).
Die Installation auf einem Unix System erfolgt wie in der Installationsanleitung auf
der Homepage beschrieben. Für die Installation auf MS Windows muss zuerst ein
Zugang zu GitHub 43 geschaffen werden, danach kann die Installation des Plug-Ins
über ruby script\plugin install http://github.com/JonMidhir/simple
_groups.git/ erfolgen.
Die Installation erfolgt durch die Ausführung von ruby script\generate
simple_groups Group, der Parameter Group gibt dabei den Namen der Gruppe an,
und ist frei wählbar.
Weiters muss das User Model durch Group erweitert werden, dies wird durch das
Einfügen von include_simple_groups im User Model erreicht.
Danach muss noch die Migration durchgeführt werden.
43
GitHub ist ein, in der RoR Community sehr beliebtes, Version Control System. Dessen Homepage
lässt sich über den Link http://github.com/ aufrufen.
Eine Beschreibung, wie GitHub unter MS Windows verwendet werden kann, befindet sich im Anhang.
2009-09-10
56/107
Details zur Lösung
Das Plug-In bringt keine Views, und keinen Controller mit, sämtliche Methoden
werden direkt über das erweiterte Model zur Verfügung gestellt (z.B. user.group).
Eine Auflistung aller Methoden ist auf der Homepage des Plug-Ins zu finden.
5.2.6 Plug-In Attachment Fu (Shared File Repository)
Abhängigkeiten
Attachment Fu besitzt für die Bildverarbeitung Abhängigkeiten zu den externen
Komponenten ImageMagic und MiniMagick, wobei anstatt diesen optional auch
andere Programme verwendet werden können.
Abb. 27: Attachment Fu Abhängigkeiten
Beschreibung
Den Benutzern soll das Handling mit Dateien ermöglicht werden, es sollen Dateien
über ein gemeinsam genutztes File Repository ausgetauscht werden können.
Shared File Repository wird unter Verwendung des externen Plug-Ins Attachment
Fu umgesetzt.
Installation
Attachment
Fu
wird
über
den
Befehl
ruby
script\plugin
install
http://svn.techno-weenie.net/projects/plugins/attachment_fu/ installiert.
Das Plug-In benötigt für die Bildverarbeitung noch zusätzliche Komponenten. Eine
Beschreibung
dazu
befindet
sich
im
Web
unter
dem
Link
http://clarkware.com/cgi/blosxom/2007/02/24#FileUploadFu, eine kurze Beschreibung für die Installation von MiniMagick auf MS Windows ist im Anhang zu finden.
Für die Integration in die Anwendung wird allgemein folgende Vorgehensweise
empfohlen:
• Model und Migration erstellen
• Controller erstellen
• View für den File Upload erstellen
2009-09-10
57/107
Details zur Lösung
•
View für die Anzeige der Dateien erstellen
Die Konfigurierung erfolgt über Parameter direkt im Model.
Ein interessantes Tutorial zur Verwendung von Attachment Fu befindet sich auf der
Seite http://clarkware.com/cgi/blosxom/2007/02/24#FileUploadFu.
Da das Plug-In cmi_user_avatar unter Verwendung von Attachment Fu implementiert
wurde, kann die Verwendung dieses Plug-Ins am Beispiel von cmi_user_avatar
nachvollzogen werden.
Implementierung
Das
Plug-In
bietet
zahlreiche
Konfigurationsmöglichkeiten,
die
durch
has_attachment im entsprechenden Model deklariert werden können.
An dieser Stelle werden nur einige davon erwähnt:
•
:content_type
•
:thumbnails
Legt fest, welche Datentypen gespeichert werden können.
Es können auch Thumbnails der Dateien gespeichert bzw. angezeigt werden. Hier
bietet das Plug-In weitere Optionen.
•
:storage
Die Daten können wahlweise auf dem Filesystem, in einer Datenbank oder aber
auch auf einem Amazon Simple Storage Service (S3) 44 abgespeichert werden.
•
:path_prefix
Der Pfad-Prefix des Orts, an dem sich die Dateien auf dem Server befinden.
Attachment Fu speichert die Dateien per default in Unterverzeichnissen ab, die nach
der id der Datei benannt sind. Das kann sich je nach Anwendungsfall als störend
erweisen. Eine Anleitung um dieses Verhalten zu umgehen, befindet sich unter
folgendem Link:
http://almosteffortless.com/2007/03/25/working-with-attachment_fu/.
Soll zusätzlich eine Versionierung der Artefakte erfolgen, so kann dies durch das
Plug-In acts_as_versioned realisiert werden.
5.2.7 Plug-In cmi_room (Room, Bell, Invitation, Spontaneous
Collaboration, User List, Interaction Directory)
Abhängigkeiten
Das Plug-In cmi_room besitzt direkte Abhängigkeiten zu den Plug-Ins
cmi_buddy_list, cmi_message und acts_as_state_machine.
Eine optionale Abhängigkeit besteht zu Juggernaut, für die synchrone Verteilung der
Nachrichten.
44
Amazon S3: siehe http://aws.amazon.com/s3/
2009-09-10
58/107
Details zur Lösung
Abb. 28: cmi_room Abhängigkeiten
Beschreibung
Für die kollaborative Gruppenarbeit wird ein Raum zur Verfügung gestellt. Dieser
Raum bietet alle Optionen an, die für die Gruppenarbeit benötigt werden.
Das Plug-In wird über den Aufruf von ruby script\generate cmi_room users
installiert. Der Parameter users gibt, ähnlich wie bei der Installation von
cmi_interactive_user_info, die User Tabelle an. Als weiterer Parameter kann --skipmigration angegeben werden.
Das Plug-In benötigt das Infrastruktur-Plug-In cmi_message, soll cmi_room ohne die
vorherige Installation von cmi_message installiert werden, kann dies durch Angabe
des Parameters --skip-cmi-messages erreicht werden.
Nach der Ausführung der Migration muss das User Model noch mit CmiRoom
assoziiert werden, bevor es verwendet werden kann. Dies erfolgt durch das Einfügen
folgender Zeile im User Model: has_and_belongs_to_many :cmi_rooms.
Um cmi_room zu verwenden, genügt es, die View cmi_room.html.erb wie folgt an der
gewünschten Stelle (z.B. in der Datei main/index.html.erb) einzubinden:
<%= render(:partial => "cmi_rooms/cmi_room.html.erb") %>
Ähnlich wie bei cmi_buddy_list werden Mitteilungen über Änderungen in den
Räumen über den ActionMailer, und über Juggernaut durch das Plug-In
cmi_message, verschickt.
2009-09-10
59/107
Details zur Lösung
Benutzung
•
Verwalten von Räumen
Räume können erstellt, geändert und gelöscht werden, wobei derjenige Benutzer,
der einen Raum erstellt hat, automatisch auch der Besitzer des Raums ist, und als
einziger (neben dem Administrator) seine Räume editieren und löschen kann.
Dies alles geschieht über die View cmi_manage_rooms.html.erb.
Diese View dient somit auch als Interaction Directory.
Einen neuen Raum erstellen
Nachdem die View zum Erstellen eines neuen Raums geöffnet wurde, können
über die Buddy List Benutzer in einen Raum eingeladen werden. Der Besitzer des
Raums ist automatisch auch ein Mitglied des Raums.
Bevor der Raum über den Button Create room erzeugt werden kann, muss dem
Raum noch ein Name gegeben werden, dieser Name muss innerhalb aller aktiven
Räume eindeutig sein.
Nachdem der Raum erzeugt wurde, wird eine Mitteilung an alle Mitglieder des
Raums gesendet.
Einen Raum editieren
Über den entsprechenden Link erreicht der Benutzer die View zum Editieren eines
Raums, von dieser View aus können Mitglieder zum Raum hinzugefügt, oder
entfernt werden.
Werden die Änderungen gespeichert, so wird wiederum eine Mitteilung an alle
Mitglieder des Raums gesendet.
Einen Raum löschen
Über den entsprechenden Link kann ein Raum vom Besitzer gelöscht werden.
Dieser Raum kann nicht wieder aktiviert werden, obwohl er nicht gelöscht,
sondern nur in den Zustand closed versetzt wird. Der Grund dafür ist, dass ein
Raumname nur einmalig in der Anwendung vorkommen darf, und Namen von
Räumen, die im Zustand closed sind, wieder neu vergeben werden können.
Mitglied eines Raums werden
Über den Link Ring the Bell kann man dem Administrator eines Raums eine
Mitteilung zukommen lassen, und ihn so bitten, sich in den entsprechenden Raum
einzuladen (Bell).
2009-09-10
60/107
Details zur Lösung
Abb. 29: Manage Rooms
•
Betreten eines Raums, User List
Jedes Mitglied kann einen Raum betreten, dazu muss es nur den entsprechenden
Link in der View cmi_my_rooms.html.erb aufrufen.
In einem Raum werden sowohl sämtliche Mitglieder des Raums (über eine Buddy
List des aktuellen Raums), als auch alle Mitglieder, die sich gerade im Raum
befinden (User List), angezeigt. Beide Views zeigen ständig den aktuellen
Zustand an.
Abb. 30: User List
Die User List bietet zusammen mit der Buddy List des Raums einen Startpunkt
für Spontaneous Collaboration mit anderen Benutzern.
•
Andere Benutzer in einen Raum einladen
Befindet sich ein Benutzer in einem Raum, so kann er andere Benutzer in diesen
Raum einladen (Invitation). Dies erfolgt über einen Link im entsprechenden
Raum. Der eingeladene Benutzer erhält dann eine Nachricht über diese Einladung,
die Nachricht enthält einen Link auf den entsprechenden Raum. Der eingeladene
Benutzer ist dann auch automatisch Mitglied dieses Raums.
2009-09-10
61/107
Details zur Lösung
Implementierung
Rooms und Users stehen in einer n:m Beziehung zueinander, dies ist über die JoinTabelle cmi_rooms_users realisiert.
Ein Raum kann die States new, active und closed einnehmen, die States wurden durch
das Plug-In acts_as_state_machine realisiert.
Folgende Abbildung zeigt das Zustandsdiagramm, der Zustand new ist als
Startzustand definiert:
Abb. 31: CmiRoom Zustandsdiagramm
Die User List ist durch ein Partial _cmi_room_users_currently_in_room.html.erb
realisiert, das über einen periodical_call_remote Aufruf stets aktualisiert wird,
dessen Intervall kann durch den Parameter :frequency konfiguriert werden.
Beispiel für den Aufruf der User List:
<%= periodically_call_remote(:update => 'users_currently_in_room',
:url => { :controller => '/cmi_rooms',
:action => :show_users_currently_in_room,
:room_id => @room.id }, :frequency => 30 )%>
Jedes Mal, wenn die Action cmi_a_room des CmiRoomControllers aufgerufen wird,
wird die gesamte View cmi_a_room.html.erb bei allen Benutzern automatisch
aktualisiert, sofern Juggernaut installiert ist.
Wie in den anderen implementierten Entwurfsmustern, die Daten bearbeiten bzw. auf
Daten zugreifen, implementiert auch cmi_room das Entwurfsmuster Centralized
Objectses werden also sämtliche Artefakte zentral auf dem Server gespeichert, und
alle Benutzer des Raums greifen darauf zu, und können die Artefakte bearbeiten.
5.2.8 Plug-In cmi_message 45
Abhängigkeiten
Das Plug-In cmi_message besitzt für die Verteilung der Nachrichten optionale
Abhängigkeiten zum Plug-In Juggernaut und zum ActionMailer.
45
Dieses Plug-In implementiert kein Entwurfsmuster, sondern ist ein Teil der Infrastruktur, der separat
installiert wird.
2009-09-10
62/107
Details zur Lösung
Abb. 32: cmi_message Abhängigkeiten
Beschreibung
Das Plug-In cmi_message ist ein eigenständiges Modul, das die Infrastruktur für das
Versenden von Nachrichten zur Verfügung stellt. Es wird von mehreren CMI-PlugIns verwendet.
Das Plug-In wird über den Befehl ruby script\generate cmi_message installiert.
Folgende Parameter können beim generieren angegeben werden:
--without-juggernaut: Überspringt den Check, ob Juggernaut installiert ist.
--install-juggernaut: Führt das Install Script (install.rb) von Juggernaut aus,
siehe auch Installation von cmi_embedded_chat.
--skip-migration: Die Migration wird nicht angelegt.
Nach der Ausführung der Migration muss das User Model noch mit dem CmiMessage
Model assoziiert werden, das wird durch das Einfügen folgender Zeile im User Model
erreicht: has_many :cmi_messages
Integration in die Anwendung und Benutzung
Grundsätzlich muss zwischen automatisch generierten Nachrichten, die ggf. mit einer
benutzerdefinierten Nachricht versehen werden können, und von Benutzern erzeugten
Nachrichten (wie z.B. Emails) unterschieden werden.
Zu den automatisch generierten Nachrichten gehören unter anderem Buddy Requests
(siehe Plugin cmi_buddy_list), Ring Bell Requests und Room Invite Requests (beide
cmi_room).
Die automatisch generierten Nachrichten werden von der Anwendung an die
betreffenden Benutzer versendet, das Versenden erfolgt sowohl über Email, als auch
über Juggernaut. Ist Juggernaut nicht installiert, bzw. ist der Juggernaut Server nicht
gestartet, wird die Nachricht nur per Email versendet.
Die Nachrichten können über das Partial _cmi_message_board.html.erb, welches in
das Verzeichnis views/cmi_messages installiert wird, angezeigt werden. Dieses Partial
kann wie folgt in die Anwendung eingebunden werden:
<%= render(:partial => "cmi_messages/cmi_message_board.html.erb") %>
2009-09-10
63/107
Details zur Lösung
Folgende Abbildung zeigt das Message Board mit Nachrichten:
Abb. 33: Message Board aufgeklappt mit Anzeige einer neuen Nachricht
Realisierung
Alle Nachrichten werden in der Tabelle cmi_messages abgespeichert. Das Versenden
der Messages erfolgt einerseits von CmiMessage aus über den ActionMailer, und
andererseits jeweils direkt vom entsprechenden Controller aus über Juggernaut.
Vorteil der Juggernaut-Variante ist, dass der Empfänger der Nachricht über das
Message Board sofort eine Mitteilung über das Eintreffen der neuen Nachricht erhält,
und dass das Message Board über Juggernaut stets aktualisiert wird.
Eine Message wird durch das Model CmiMessage repräsentiert, die Message Typen
sind im Model über die Konstante TYPES definiert. Jede Message wird beim Erzeugen
mit einem Ablaufdatum versehen. Dieses Datum kann dazu verwendet werden, um
abgelaufene Messages zu filtern. Zudem steht das Attribut has_been_read zur
Verfügung, das ebenfalls dazu verwendet werden kann, um Nachrichten zu filtern.
5.2.9 Plug-In cmi_embedded_chat (Embedded Chat)
Abhängigkeiten
Das Plug-In cmi_embedded_chat besitzt direkte Abhängigkeiten zu den Plug-Ins
Juggernaut und cmi_juggernaut_connection, welches automatisch mit installiert wird.
Optional ist die Abhängigkeit zum Plugin cmi_buddy_list, dieses wird für den Aufruf
des Private Chats über die Buddy List benötigt.
2009-09-10
64/107
Details zur Lösung
Abb. 34: cmi_embedded_chat Abhängigkeiten
Beschreibung
Dieses Plug-In realisiert einen synchronen Chat zwischen beliebigen Benutzern,
wobei entweder ein privater Chatraum eröffnet werden kann, oder einer von mehreren
bereitgestellten, öffentlichen Chaträumen, verwendet werden kann. Ein privater Chatraum ist ein Chatraum, der von einem Benutzer erstellt wurde. Der Benutzer kann
andere Benutzer in diesen privaten Chatraum einladen, nur die jeweiligen Benutzer
haben Zugriff zu diesem Raum. Dies funktioniert unabhängig vom Plugin cmi_room.
Das Plug-In stellt die Komponenten für zwei unterschiedliche Anwendungsfälle zur
Verfügung, die je nach Bedarf eingesetzt werden können:
• Anwendungsfall 1: independent
Der Chat soll unabhängig von der Anwendung verwendet werden können.
Die für diesen Anwendungsfall bereitgestellten Komponenten lassen sich
unabhängig von der restlichen Anwendung verwenden. Die View zum Aufrufen
der Chats wird über einen separaten Link bereitgestellt.
• Anwendungsfall 2: integrated
Der Chat soll sich nahtlos in die anderen Module integrieren lassen.
Es werden Komponenten bereitgestellt, die sich in die anderen Module integrieren
lassen. Somit kann ein Chat an einer beliebigen Stelle in die Anwendung
eingebunden werden.
Beim Aufruf von ruby script\generate cmi_embedded_chat werden zunächst die
Komponenten für das Management der Juggernaut-Kanäle, die Komponenten von
cmi_juggernaut_connection, installiert.
Danach werden die eigentlichen Komponenten für den Chat in die Anwendung
installiert, wobei je nach Wunsch entweder alle Komponenten, oder wahlweise nur
die Komponenten für die Anwendungsfälle independent oder integrated installiert
werden. Dies wird über die Parameter --skip-integrated und --skipindependent gesteuert.
Zudem wird für cmi_juggernaut_connection eine Migration angelegt, die eine Tabelle
für die Verwaltung der Verbindungen erzeugt. Die Migration muss natürlich wie
immer über rake db:migrate ausgeführt werden, bevor das Modul verwendet
werden kann.
Über den Parameter --skip-migration kann das Erzeugen der Migration
Der Parameter --install-juggernaut führt die install.rb von Juggernaut aus, somit
kann das Juggernaut Plug-In einfach in das plugins-Verzeichnis kopiert werden, und
der Generator von cmi_embedded_chat übernimmt die Installation von Juggernaut.
2009-09-10
65/107
Details zur Lösung
Je nach Anwendungsfall erfolgt die Integration unterschiedlich:
•
Anwendungsfall independent
Die installierten Komponenten stehen mit den restlichen Modulen (außer den
Usern) nicht in Beziehung, und können deshalb unabhängig von der eigentlichen
Anwendung verwendet werden. Die Chaträume befinden sich in einer separaten
View, und werden über den Link /cmi_embedded_chat aufgerufen.
•
Anwendungsfall integrated
Hier werden öffentliche und private Chaträume unterschiedlich aufgerufen.
o Öffentliche Chaträume
Diese können vom Benutzer über das Chat Board aufgerufen werden. Das
Chat Board kann an einer beliebigen Stelle (z.B. im Layout), durch Einfügen
folgender Zeile, in die Anwendung eingebunden werden:
<%=render(:partial=>"cmi_embedded_chat/cmi_chat_board.html.erb")%>
o Private Chaträume
Diese werden vom Benutzer über die Buddy List, per Mausklick auf den Link
private chat, erzeugt. Dieser Link kann durch Einfügen folgender Zeile (z.B.
im Partial _cmi_buddy_list_default_links.html.erb) erstellt werden:
<%= link_to "Private chat",
{:controller => 'cmi_embedded_chat', :action => 'invite_private',
:params => { :client_id => a_user[:id],
:current_user_id => current_user.id } },
:popup => ['_blank','height=300,width=600,scrollbars=yes'] %><br/>
Da jeder private Chatraum bestimmten Benutzern zugeordnet ist, muss diese
Assoziation durch has_many :cmi_private_chat_rooms im User Model
deklariert werden.
Benutzung
Zunächst den Juggernaut Server über juggernaut -c juggernaut.yml starten, und
den Rails-Server starten.
•
Anwendungsfall independent
Die Startseite für den Chat kann über den Link /cmi_embedded_chat aufgerufen
werden. Von da aus können über die chatroom links die Chaträume betreten
werden. In diesen Räumen kann der Benutzer mit allen Teilnehmern, die sich
darin befinden, chatten.
Zudem gelangt der Benutzer über den Link Invite in einen privaten Chatraum, in
den er nun andere Benutzer einladen kann. Jeder eingeladene Benutzer erhält eine
Mitteilung auf seiner Chat-Hauptseite, und gelangt über einen Link, der in der
Mitteilung enthalten ist, ebenfalls in den entsprechenden Chatraum.
2009-09-10
66/107
Details zur Lösung
•
Anwendungsfall integrated
Der Aufruf eines öffentlichen Chatraums erfolgt über das Chat Board. Private
Chaträume werden über die Buddy List erzeugt, der eingeladene Benutzer wird
über das Chat Board über die Einladung informiert, von dort aus kann er dann den
Chatraum über einen Link betreten. Sämtliche privaten Chaträume werden in der
Datenbank abgespeichert, und können so lange, bis sie abgelaufen sind (jeder
private Chatraum besitzt ein Attribut expires_at), über den entsprechenden Link
im Chat Board betreten werden.
Abb. 35: Chat Board mit aufgeklapptem Tooltip
Implementierung
•
Kommunikation
Die synchrone Verteilung der Messages erfolgt über Juggernaut. Die Chat
Messages selbst werden über Juggernaut Channels an alle verteilt, die mit dem
entsprechenden Kanal verbunden sind, und die entsprechende View geöffnet
haben.
Die Verwaltung der Kanäle erfolgt über das Modul cmi_juggernaut_connection.
•
Private Chaträume (integrated)
Wird die Variante integrated verwendet, so werden die privaten Chaträume in
einer Tabelle (cmi_private_chat_rooms) abgespeichert, und können über das Chat
Board nach dem Verlassen erneut betreten werden. Die Verwaltung erfolgt
automatisch über das Attribut expires_at, das bei der Erzeugung gesetzt wird.
Abgelaufene Chaträume können nicht mehr betreten werden.
5.2.10
Plug-In cmi_juggernaut_connection
Abhängigkeiten
Das Plug-In cmi_juggernaut_connection besitzt keine Abhängigkeiten zu anderen
Plug-Ins.
2009-09-10
67/107
Details zur Lösung
Beschreibung
Dieses Modul beinhaltet die Komponenten für das Management der JuggernautKanäle. Die Kanäle selbst werden über ihre Namen verwaltet. Kanalnamen sind
beliebige, durch den Anwendungsentwickler definierte Strings.
Die Komponenten werden von den entsprechenden Modulen automatisch installiert,
es steht kein separater Generator zur Verfügung.
Implementierung
Die Verwaltung der Chat-Kanäle erfolgt über den CmiConnectionsController.
Dieser bietet die Methode get_new_juggernaut_channel(name) an, über die ein
neuer Juggernaut-Kanal, der durch einen Namen identifiziert wird, angefordert
werden kann. Ist der Kanal bereits vorhanden, so wird die Nummer des vorhandenen
Kanals zurückgegeben. Kanalnamen können aus beliebigen Strings bestehen. Da alle
Aufrufe über die Kanalnamen erfolgen, ist gewährleistet, dass keine Unbefugten auf
die Kanäle zugreifen können.
Die Kanäle werden in der Tabelle cmi_connections abgespeichert.
Per default sind die ersten zehn Kanäle für allgemeine Zwecke (wie zum Beispiel für
fix vorgesehene Chat-Kanäle) reserviert. Diese Zahl kann ist als Konstante definiert,
und kann beliebig geändert werden. Alle Kanäle, die über dieser Konstante liegen,
werden dynamisch zugeteilt.
Jeder Zugriff auf einen Kanal aktualisiert das Attribut last_served_at des
entsprechenden Kanals. Dadurch ist es möglich, nicht mehr verwendete Kanäle zu
identifizieren, und aus der Tabelle zu löschen. Der CmiConnectionsController
bietet dazu die Methode clean_up_channels an.
5.2.11
Plug-In cmi_interactive_user_info (Interactive User
Info)
Abhängigkeiten
Das Plug-In cmi_interactive_user_info besitzt direkte Abhängigkeiten zu den Plug-Ins
Tooltips und cmi_user_avatar.
Die optionale Abhängigkeit zu cmi_virtual_me besteht für das Editieren der Daten des
virtual me.
2009-09-10
68/107
Details zur Lösung
Abb. 36: cmi_interactive_user_info Abhängigkeiten
Beschreibung
Über die Interactive User Info wird die Interaktion mit anderen Benutzern
ermöglicht.
Mit ruby script\generate cmi_interactive_user_info users wird das Modul
installiert. Der Parameter users ist optional und gibt den Namen der User- Tabelle an.
Wird der Parameter angegeben, so wird eine Migration angelegt, die zur User-Tabelle
eine neue Spalte user_avatar hinzufügt. Dies ist jedoch nur als Alternative gedacht,
denn per default wird der User Avatar des separaten Plug-Ins cmi_user_avatar
verwendet, das automatisch mit installiert wird, falls es noch nicht vorhanden ist. Die
Assoziation mit dem User Model (has_one :cmi_user_avatar) muss jedoch ggf.
noch manuell ins User Model eingefügt werden.
Die View _cmi_current_user.html.erb wird in das Verzeichnis app\views\cmi_general
generiert, und realisiert die View für die Interactive User Info.
Als weitere Option steht für die Installation der Parameter --skip-migration zur
Verfügung.
Vor der Verwendung der Interactive User Info ist nach der Installation noch ein rake
db:migrate erforderlich.
Zur
Verwendung
der
Interactive
User
Info
kann
das
Partial
_cmi_current_user.html.erb, das in das Verzeichnis app\views\cmi_general installiert
wird, in die gewünschten Views eingebunden werden.
Im tooltip image_tag des Partials können nun Links zu beliebigen Aktionen
erstellt werden.
Beispiel für die Verwendung der View (z.B. in index.html.erb einfügen):
<%= render(:partial => "cmi_general/cmi_current_user.html.erb") %>
Benutzung
Per Mausklick auf das Benutzer-Icon öffnet sich ein Tooltip, von dem aus die
weiteren möglichen Aktionen erreichbar sind.
2009-09-10
69/107
Details zur Lösung
Vordefinierte Aktionen sind:
•
•
Change state
Hier kann der Availability State des Benutzers eingestellt werden.
Edit user data
Ein Formular zum Editieren der Benutzerdaten und der Daten vom Virtual Me
des Users, wird geöffnet. Da diese Einstellungen nur zusammen mit dem Plug-In
cmi_virtual_me sinnvoll sind, wird empfohlen, dieses Plug-In zusammen mit
cmi_interactive_user_info zu installieren.
Implementierung
Sämtliche Aktionen mit dem eigenen Benutzer sind über das User Icon möglich, und
werden über einen Tooltip, der durch das Plug-In Tooltips realisiert ist, in der Datei
_cmi_current_user.html.erb erstellt. Die Aktionen mit anderen Benutzern erfolgt
ähnlich über die Buddy List bzw. über die User Gallery.
5.2.12
Plug-In acts_as_versioned (Immutable Versions,
Activity Log)
Abhängigkeiten
Das Plug-In acts_as_versioned besitzt keine Abhängigkeiten zu anderen Plug-Ins.
Beschreibung
Die Entwicklung eines Artefakts soll in einem Version Tree abgespeichert werden. Zu
diesem Zweck werden alle Versionen eines Artefakts zusammen mit einem
Zeitstempel abgespeichert (Immutable Versions). Bei Bedarf kann auf eine frühere
Version zurückgegriffen werden.
Soll die zeitliche Entwicklung eines Artefakts genau nachvollzogen werden, so kann
das Muster Activity Log implementiert werden. Es muss zusätzlich bei jedem Zugriff
auf das Artefakt, bzw. bei jeder Änderung am Artefakt ein Kommentar zu der
Änderung mit abgespeichert werden.
Dieses Entwurfsmuster wurde durch das externe Plug-In acts_as_versioned realisiert.
Dessen
Homepage
lässt
sich
im
Web
über
den
Link
http://agilewebdevelopment.com/plugins/acts_as_versioned, bzw. auf GitHub über
http://github.com/technoweenie/acts_as_versioned/tree/master aufrufen.
Anders als auf der Homepage angegeben, wird empfohlen, das Plug-In von GitHub
über den Link http://github.com/technoweenie/acts_as_versioned herunterzuladen,
und in das plugins Verzeichnis des Projekts zu kopieren. In dieser Form ist das Plug-
2009-09-10
70/107
Details zur Lösung
In auch bereits im Repository des Projekts enthalten, es kann somit auch direkt von
dort verwendet werden.
Prinzip des Plug-Ins:
•
•
Das Model, das versioniert werden soll, wird in einer zweiten Tabelle gespiegelt,
in dieser zweiten Tabelle werden sämtliche Versionen des Models abgespeichert.
Das entsprechende Model wird nach dem acts_as Prinzip, durch Einfügen von
acts_as_versioned im Model, um alle notwendigen Methoden für den Zugriff
und die Steuerung der Versionen erweitert. Der Zugriff auf die Versionen erfolgt
direkt über die Instanzvariablen.
Beispiel: Das Model Tour soll eine Versionierung erhalten.
•
Erstellen einer mirror table:
Es wird eine neue Migration angelegt, die den Namen TourVersions erhält. Die
Tabelle
selbst
wird
über
Tour.create_versioned_table
erzeugt,
Fremdschlüssel ist die tour_id von Tour.
class CreateToursVersions < ActiveRecord::Migration
def self.up
Tour.create_versioned_table do |t|
t.column :version, :integer
t.column :tour_id, :integer
t.string :title
end
end
def self.down
Tour.drop_versioned_table
end
end
•
Zugriff auf die Daten
Im Model Tour wird die Zeile acts_as_versioned eingefügt.
Über @tour.versions kann nun auf alle Versionen von @tour zugegriffen
werden.
Ein gutes Tutorial zur Verwendung des Plug-Ins befindet sich auf
http://www.urbanhonking.com/ideasfordozens/archives/2006/02/learns_to_use_a_1.ht
ml, allerdings bezieht es sich nicht auf die aktuelle Version des Plug-Ins.
2009-09-10
71/107
Details zur Lösung
5.2.13
Plug-In cmi_coll_session (Collaborative Session, User
List)
Abhängigkeiten
Das Plug-In cmi_coll_session besitzt für den synchronen Update der View eine
optionale Abhängigkeit zu Juggernaut.
Abb. 37: cmi_coll_session Abhängigkeiten
Beschreibung
Der Kontext einer kollaborativen Sitzung (Collaborative Session) wird als Session
Objekt modelliert, welches den Session State visualisiert, und die Benutzer bei der
Session unterstützt.
Dazu wird ein Objekt der Klasse CmiCollSession erzeugt, welches mit dem Model,
in dem die Session stattfindet, assoziiert ist. Die Verwaltung des Session Objekts
erfolgt über das assoziierte Objekt.
Das Modul wird über den Befehl ruby script\generate cmi_coll_session
session_table generiert, und in die Anwendung installiert, wobei der Parameter
session_table den Namen der Tabelle angibt, in dessen Model die Session
stattfindet.
Folgende Parameter können ebenfalls bei der Generierung mit angegeben werden:
--without-juggernaut: Überspringt den Check, ob Juggernaut installiert ist.
--install-juggernaut: Führt das Install-Script (install.rb) von Juggernaut aus.
Anwendungsbeispiel: Die Session findet in CmiRoom statt, dann wird der Generator
wie folgt aufgerufen: ruby script\generate cmi_coll_session cmi_rooms.
Nach der Ausführung der Migration muss das entsprechende Model (z.B. CmiRoom)
mit dem CmiCollSession Model assoziiert werden. Dies wird durch Einfügen
folgender Zeile z.B. im CmiRoom Model erreicht:
has_and_belongs_to_many :cmi_coll_sessions
Folgende Schritte sind für die Verwaltung und Aktualisierung der Collaborative
Session erforderlich:
2009-09-10
72/107
Details zur Lösung
•
Session betreten
Eine Session kann über die Methode enter_coll_session(object, user)
betreten werden. Existiert die Session noch nicht, so wird sie erzeugt.
Beispiel: In cmi_room wird enter_coll_session jedesmal beim Betreten des
Raums, in der Methode cmi_a_room vom CmiRoomController, aufgerufen:
CmiCollSession.enter_coll_session(@room, @user)
•
Benutzerstatus setzen
Das Ändern des Benutzerstatus erfolgt ähnlich wie das Initialisieren, ein Beispiel
dafür ist im ToursController in der Methode new_tour_room implementiert.
Der Benutzerstatus der Session wird automatisch auf den Standardwert
zurückgesetzt, wenn innerhalb einer im Model definierbaren Zeitspanne keine
Benutzeraktion stattfindet.
•
Session State View bei allen Clients aktualisieren
Ist das Juggernaut Plug-In installiert, so wird bei jeder Status-Änderung, der
Session State View automatisch synchron bei allen Clients aktualisiert (User
List).
Wie dies umgesetzt werden kann, ist im CmiRoomsController in der Methode
update_immediate_cmi_session gezeigt.
Die Session State View kann durch folgenden Aufruf in die Anwendung eingebunden
werden:
<%= render(:partial => "cmi_coll_session/cmi_coll_session_state.html.erb",
:locals => {:room => @room}) %>
Benutzung
Die Session State View zeigt die aktuelle Aktivität der Benutzer an, sie unterstützt
somit die Spontaneous Collaboration mit anderen Benutzern:
Abb. 38: Session State View
Implementierung
Schon beim Generieren des Plug-Ins wird angegeben, in welchem Model die
Collaborative Session stattfinden wird, das heißt, mit welchem Model die Session in
Beziehung steht (in diesem Beispiel ist es CmiRoom).
Das CmiCollSession Model ist so allgemein gehalten, dass es in jedem beliebigen
Container verwendet werden kann, lediglich für das Initialisieren des Objekts müssen
2009-09-10
73/107
Details zur Lösung
ggf.
Anpassungen
vorgenommen werden (siehe dazu z.B. die Methode
enter_coll_session in der Klasse CmiCollSession).
CmiCollSession und das Container Model stehen in einer n:m Beziehung
zueinander, die Assoziation erfolgt über die cmi_coll_sessions_... Join Table.
Der Session State der Benutzer kann, so wie oben beschrieben wurde, eingestellt
werden. Wie die Clients über Juggernaut aktualisiert werden, ist in der Methode
update_immediate_cmi_session im CmiRoomsController gezeigt.
Für das Entfernen von verwaisten Sessions steht die Methode maintain_all in der
Klasse CmiCollSession zur Verfügung. Wird diese Methode aufgerufen, dann wird
der Benutzerstatus aller Benutzer aktualisiert, und nach Ablauf einer definierten
Zeitspanne ohne Benutzeraktion, wird der entsprechende Status auf den Standardwert
zurückgesetzt.
5.2.14
Plug-In cmi_remote_subscription (Remote
Subscription)
Abhängigkeiten
Das Plug-In cmi_remote_subscription besitzt eine direkte Abhängigkeit zum Plug-In
cmi_message.
Abb. 39: cmi_remote_subscription Abhängigkeiten
Beschreibung
Das Plug-In cmi_remote_subscription ermöglicht es den Benutzern, sich bei einem
Model zu registrieren, um per Email eine Nachricht zu erhalten, wenn eine Änderung
an einem entsprechenden Model durchgeführt wurde.
Soll die Benachrichtigung direkt an den Client weitergereicht werden, muss auf
Juggernaut zurückgegriffen werden.
Das Modul wird mittels ruby script\generate cmi_remote_subscription
installiert, folgende Parameter können beim generieren angegeben werden:
2009-09-10
74/107
Details zur Lösung
--skip-cmi-messages: Die Installation überspringt den Check, ob das Plug-In
cmi_message bereits in die Anwendung installiert wurde.
--skip-environment: Der CmiRemoteSubsciptionObserver wird nicht in der Datei
environment.rb registriert.
Nach Ausführung der Migration durch rake db:migrate muss nun noch die
Beziehung zum User Model, durch einfügen der Zeile has_many
:cmi_remote_subscriptions in das User Model, definiert werden.
Nachdem die Installation durchgeführt wurde, muss ggf. noch der ActionMailer
eingerichtet werden, dann ist cmi_remote_subscription einsatzbereit.
Damit die Benutzer Mitteilungen über die Änderungen an den registrierten Objekten
erhalten, muss das entsprechende Model im CmiRemoteSubscriptionObserver, der
sich im models Verzeichnis befindet, registriert werden.
Dies geschieht z.B. für CmiRoom durch Einfügen der Zeile observe CmiRoom im
Observer.
Benutzung
•
Remote Subscriptions einrichten
Über den Link /cmi_remote_subscriptions gelangt der Benutzer auf die
Konfigurationsseite, auf der er sich für Änderungen an bestimmten Models
registrieren kann.
Abb. 40: Erstellen einer Remote Subscription
•
Empfangen der Nachrichten
Jedes Mal, wenn ein registriertes Model geändert wird, wird im Observer die
entsprechende Methode aufgerufen. Darin wird überprüft, welche Benutzer sich
für diese Änderung registriert haben. Diesen Benutzern wird dann die passende
Nachricht zugeschickt, gleichzeitig wird die Nachricht auch in Form eines
CmiMessage Objekts in der Datenbank abgespeichert, wo sie somit auch über das
Message Board (siehe cmi_message) zugänglich ist.
2009-09-10
75/107
Details zur Lösung
Implementierung
Über die Datei environment.rb wird der CmiRemoteSubscriptionObserver in der
Anwendung als Observer registriert.
Der aktuelle Benutzer (current_user) wird dem Observer über den CmiHelper zur
Verfügung gestellt, dieser wiederum wird über einen before_filter in der Datei
application.rb aktualisiert.
Das Versenden der Nachrichten erfolgt über den ActionMailer.
5.2.15
Plug-In Juggernaut (Mediated Updates)
Abhängigkeiten
Das Plug-In Juggernaut besitzt keine direkten Abhängigkeiten zu anderen Plug-Ins.
Beschreibung
Wie bereits in Abschnitt 3.1.1 beschrieben wurde, basiert Juggernaut auf Flash und
ermöglicht es dem Server, Daten aktiv an die Clients zu verteilen. Deshalb wurde
Juggernaut für die Realisierung des Entwurfsmusters Mediated Updates ausgewählt.
Die Projektseite von Juggernaut ist unter http://juggernaut.rubyforge.org/ zu finden,
eine aktive Google Group befindet auf http://groups.google.com/group/Juggernautfor-Rails.
Eine Anleitung zur Installation von Juggernaut befindet sich im Anhang.
Die Konfigurierung von Juggernaut erfolgt durch ein eigenes Konfigurationsfile, das
sich im Wurzelverzeichnis der Anwendung befindet, und den Namen juggernaut.yml
trägt.
Das Senden der Nachrichten an die entsprechenden Clients kann in Juggernaut wie in
folgendem Beispiel gezeigt, erfolgen (siehe z.B. distribute_immediate_message
(receiver) der Klasse CmiBuddyListsController).
2009-09-10
76/107
Details zur Lösung
begin
#send to Juggernaut clients...
render :juggernaut => {:type => :send_to_clients, :client_ids =>
[receiver.id.to_i.to_i]} do |page|
#the div with the id "msg_board_messages" will be replaced
page.replace_html "msg_board_messages", :partial =>
'/cmi_messages/cmi_new_message.html.erb',
:locals => {:user => receiver}
end
end
Die View kann folgendermaßen implementiert werden:
<%= javascript_include_tag :defaults, :juggernaut %> 
<%= juggernaut :client_id => current_user[:id] %>

<h3>Message board:</h3>
<div id="msg_board_messages" style="list-style:none"> </ul>
<%= render :partial => "/cmi_messages/cmi_messages.html.erb", :locals => {:user
=> current_user} %>

</div>
Tutorials:
Ein gutes Tutorial, um eine Chat-Anwendung zu erstellen, befindet sich hier:
http://www.dorkalev.com/2008/04/juggernaut-up-to-date-tutorial-1042008.html
Wie die Juggernaut-eigene Users List abgefragt, und in das eigene Programm
eingebunden werden kann, wird unter folgendem Link beschrieben:
http://slightlycoded.com/blog/juggernaut-part-2-connected-users-list
5.3 Weitere Plug-Ins
Im Folgenden werden Plug-Ins beschrieben, die nicht direkt Entwurfsmuster
implementieren, die aber für die Umsetzung der Entwurfsmuster benötigt werden.
5.3.1 Plug-In cmi_user_avatar
Abhängigkeiten
Das Plug-In cmi_user_avatar besitzt eine direkte Abhängigkeit zum externen Plug-In
Attachment Fu.
Abb. 41: cmi_user_avatar Abhängigkeiten
2009-09-10
77/107
Details zur Lösung
Beschreibung
Dieses Plug-In stellt die Komponenten bereit, die in diesem Projekt für einen User
Avatar benötigt werden.
Da der User Avatar von mehreren Plug-Ins, die unabhängig voneinander installiert
werden können, verwendet wird, wurde er in ein separates Modul ausgelagert.
Die Installation dieses Plug-Ins wird im Normalfall automatisch von den Plug-Ins, die
es verwenden 46, durchgeführt, deshalb ist eine separate Installation üblicherweise
nicht erforderlich.
Soll das Plug-In jedoch trotzdem eigenständig installiert werden, kann dies über den
Befehl ruby script\generate cmi_user_avatar erreicht werden, optional kann
als Parameter --skip-migration angegeben werden.
Da der User Avatar in einer 1:1 Beziehung mit dem User steht, muss nach der
Migration noch folgende Zeile im User Model eingefügt werden:
has_one :cmi_user_avatar
Integration in die Anwendung, Benutzung
Es sind keine zusätzlichen Schritte notwendig, die Verwendung der Komponenten des
Plug-Ins ist bereits in den entsprechenden, übergeordneten Plug-Ins, integriert.
Implementierung
Das Pllug-In basiert auf dem externen Plug-In Attachment Fu. Die Verwendung des
User Avatars kann eingeteilt werden in:
• Einen neuen User Avatar erstellen
Über die View cmi_virtual_me_edit.html.erb 47 kann ein User Avatar ausgewählt,
und auf den Server hochgeladen werden. Attachment Fu generiert aus dem
gewählten Bild nun zwei neue Bilder, das Standard-Bild und das Thumbnail, lädt
beide auf den Server, und generiert die Einträge in der entsprechenden Tabelle.
Die Parameter für die Bilder können im Model definiert werden.
• Den User Avatar verwenden
Beispiel: the_user ist eine Instanz des, um die Methoden von Attachment Fu
erweiterten Models, User.
Beide Bilder können nun nach Wunsch wie folgt in der Anwendung eingesetzt
werden:
the_user.cmi_user_avatar.public_filename
the_user.cmi_user_avatar.public_filename(:thumb)
46
47
Dies sind: cmi_virtual_me, cmi_user_gallery, cmi_buddy_list und cmi_interactive_user_info.
Wird durch das Plug-In cmi_virtual_me installiert.
2009-09-10
78/107
Details zur Lösung
5.3.2 Plug-In demo_bike_guide
Abhängigkeiten
Das Plug-In demo_bike_guide besitzt keine direkten Abhängigkeiten.
Beschreibung
Dieses Modul dient zur Demonstration der Anwendung, insbesondere für das Plug-In
cmi_room. Es wird gezeigt, wie das Demo-Modul in die Anwendung bzw. in einen
Raum eingebunden werden kann.
Bike Guide dient zur Verwaltung von Mountainbike-Routen. Es können Routen
erstellt werden, diese können dann zu Räumen hinzugefügt werden.
Jedem Raum können beliebige Routen zugeordnet werden.
Hinweis: demo_bike_guide dient nur zu Demonstrationszwecken, es wurden hier
keine besonderen Maßnahmen bezüglich Sicherheit und Erweiterbarkeit getroffen.
Die Installation des Moduls erfolgt über den Befehl ruby script\generate
demo_bike_guide, wobei der Parameter --skip-migraion optional angegeben
werden kann, wenn keine Migrationsdateien angelegt werden sollen.
Soll das Modul zusammen mit einer anderen Anwendung, als dem Basisprojekt,
verwendet werden, so müssen in der Datei routes.rb noch die zusätzlichen Routes
eingetragen werden:
map.resources :tours
map.show_tour_room '/show_tour_room/:id', :controller => 'tours', :action =>
'show_tour_room'
map.new_tour_room '/new_tour_room', :controller => 'tours', :action => 'new_tour_room'
map.add_tour_room '/add_tour_room', :controller => 'tours', :action => 'add_tour_room'
map.remove_tour_room '/remove_tour_room', :controller => 'tours', :action =>
'remove_tour_room'
Vor der Verwendung muss das CmiRoom Model noch mit dem Tour Model in
Beziehung gesetzt werden, das erfolgt durch das Einfügen der Zeile
has_and_belongs_to_many :tours in der Datei cmi_room.rb.
Bike-Guide kann wie folgt in einen Room, z.B. in der View cmi_a_room.html.erb,
eingebunden werden:
<%= render :file => "/tours/index_room.html.erb",
:params => {:layout => true} %>
2009-09-10
79/107
Details zur Lösung
Benutzung
Die Verwaltung der Touren selbst erfolgt über den Link /tours.
Befindet man sich in einem Raum, so können beliebige Touren zu diesem Raum
hinzugefügt, bzw. auch wieder entfernt werden.
Realisierung
CmiRoom und Tour stehen in einer n:m Beziehung zueinander, und werden über die
Join Tabelle cmi_rooms_tours miteinander verknüpft.
Als Erweiterung wäre z.B. vorstellbar, eine weitere Tabelle einzuführen, in der
zusätzliche Daten zu den Routen (wie zum Beispiel Rundenzeiten einzelner Benutzer
oder Kommentare und Diskussionsbeiträge einzelner Benutzer) verwaltet werden
könnten. Das führt jedoch über das Ziel dieser Arbeit hinaus, und deshalb wurde
darauf verzichtet.
5.3.3 Plug-In Restful Authentication
Abhängigkeiten
Das Plug-In Restful Authentication besitzt eine direkte Abhängigkeit zu
acts_as_state_machine.
Abb. 42: Restful Authentication Abhängigkeiten
Beschreibung
Restful Authentication stellt die Funktionalität für die Benutzerverwaltung und
Authentisierung zur Verfügung. Folgende Funktionen werden abgedeckt 48:
• Login / Logout
• Sichere Passwortverwaltung
• Account-Aktivierung per Email
• Freigabe des Accounts durch den Administrator
• Methoden für die Autorisierung und Zugriffskontrolle
Die Homepage von Restful Authentication lässt sich über den
http://agilewebdevelopment.com/plugins/restful_authentication aufrufen.
48
Link
Quelle: http://wiki.github.com/technoweenie/restful-authentication
2009-09-10
80/107
Details zur Lösung
Installation
Das Plug-In ist bereits im Repository dieser Arbeit enthalten, und kann so direkt ohne
weitere Installation verwendet werden. Alternativ dazu kann das Plug-In mittels ruby
script\plugin install http://svn.techno-weenie.net/projects/plugins/
restful_authentication/ installiert werden.
5.3.4 Plug-In acts_as_state_machine
Abhängigkeiten
Das Plug-In acts_as_state_machine besitzt keine direkten Abhängigkeiten zu anderen
Plug-Ins.
Beschreibung
Mittels dieses Plug-Ins kann ein Model um Funktionalitäten einer State Machine
erweitert werden. Die Homepage des Plug-Ins lässt sich über folgenden Link
aufrufen: http://agilewebdevelopment.com/plugins/acts_as_state_machine
Installation
Das Plug-In wird über ruby script\plugin install http://elitists
textdriven.com/svn/plugins/acts_as_state_machine/trunk installiert. Da das
originale Plug-In um zwei Class Methods erweitert wurde, die für das Plug-In
cmi_virtual_me erforderlich sind, wird empfohlen, das Plug-In direkt aus dem
Repository zu verwenden. Alternativ dazu können die beiden Methoden auch manuell
in das Plug-In eingefügt werden.
Folgendes Beispiel stammt von der Homepage von acts_as_state_machine. Es wird
gezeigt, wie das Model Nonprofit um folgende State Machine erweitert wird, und
wie eine State Machine definiert, und verwendet werden kann:
2009-09-10
81/107
Details zur Lösung
Abb. 43: acts_as_state_machine Nonprofit (Quelle:
http://www.ibm.com/developerworks/java/library/j-cb03137/figure1.gif )
•
Model erweitern und Zustände definieren:
class Nonprofit < ActiveRecord::Base
acts_as_state_machine :initial => :created, :column => 'status'
# These are all of the states for the existing system.
state :submitted
state :processing
state :nonprofit_reviewing
state :accepted
•
Eventhandler definieren, die die Zustandsübergänge auslösen
event :accept do
transitions :from => :processing, :to => :accepted
transitions :from => :nonprofit_reviewing, :to => :accepted
end
event :receive do
transitions :from => :submitted, :to => :processing
end
# either a CTP or nonprofit user edits the entry, requiring a review
event :send_for_review do
transitions :from => :processing, :to => :nonprofit_reviewing
transitions :from => :nonprofit_reviewing, :to => :processing
transitions :from => :accepted, :to => :nonprofit_reviewing
end
end
•
Die Zustandsübergänge können nun z.B. wie folgt aufgerufen werden, wenn
nonprofit eine Instanzvariable von Nonprofit ist:
nonprofit.accept!
Implementierung
Das Plug-In wurde wie folgt erweitert:
•
Die Methode all_possible_events gibt ein Array zurück, das alle
Zustandsübergänge enthält.
2009-09-10
82/107
Details zur Lösung
def all_possible_events
returning Array.new do |events|
self.class.read_inheritable_attribute
(:transition_table).each_pair do |event, value|
events << event
if value.detect{|transition|
transition.from == current_state }
end
end
end
end
•
Die Methode possible_events_from_state gibt ein Array zurück, das alle
Zustandsübergänge enthält, die von dem als Parameter übergebenen Zustand aus
möglich sind.
def possible_events_from_state(from_state)
to_arr = Array.new
transitions = self.class.read_inheritable_attribute
(:transition_table)
transitions.each_pair do |event, value|
value.each do |trans_state|
if trans_state.from.to_s == from_state.to_s
to_arr.push(trans_state.to)
end
end
end
return to_arr
end
5.3.5 Plug-In Rails Widgets (Tooltips)
Abhängigkeiten
Das Plug-In Rails Widgets besitzt keine direkten Abhängigkeiten.
Beschreibung
Tooltips ist ein Bestandteil des Plug-Ins Rails Widgets, dessen Homepage über den
Link http://wiki.github.com/paolodona/rails-widgets/tooltips aufgerufen werden kann.
Tooltips bietet die Möglichkeit, User Interface Elemente um einen Tooltip zu
erweitern, dieses Plug-In wird in mehreren CMI-Plug-Ins verwendet.
Installation
Eine Installationsanleitung ist auf der Homepage zu finden. Das Plug-In kann auch
direkt aus dem Projekt-Repository verwendet werden, dann erfolgt die Installation
durch Aufruf von rake widgets:setup.
2009-09-10
83/107
Details zur Lösung
5.4 Eine Anwendung erstellen
In diesem Abschnitt wird erläutert, wie mittels einiger der vorgestellten Plug-Ins
zusammen mit der Basisanwendung in sieben Schritten eine kollaborative
Anwendung erstellt werden kann.
Jeder dieser Schritte wird mit einer Aufgabenstellung 49 eingeleitet. Danach folgt ein
Beispiel, wie diese Aufgabenstellung in CURE implementiert wurde. Im Anschluss
daran wird gezeigt, wie die Aufgabenstellung mit den jeweiligen Plug-Ins umgesetzt
werden kann. Zur Verdeutlichung wird jeweils am Ende des Schritts ein Diagramm
dargestellt, das die Modelle der Plug-Ins der aktuellen Konfiguration, und deren
Beziehungen zueinander, abbildet. Die neu hinzugefügten Modelle sind jeweils rot
eingefärbt.
Schritt 1: Login
Aufgabenstellung
Verbindet sich der Benutzer mit dem Server, soll ein Login Screen erscheinen, der
dem Benutzer die Möglichkeit bietet, einen neuen Account anzulegen, bzw. sich
einzuloggen, wenn der Benutzer bereits einen gültigen Account besitzt.
Beispiel CURE
Folgende Abbildung zeigt den Login Screen von CURE mit dem Bereich für den
Login, dem Link zur Beantragung eines neuen Zugangs, und einem Ausschnitt aus
dem Formular zur Beantragung eines Zugangs zu CURE.
Abb. 44: Login Screen von CURE und Zugang zu CURE beantragen
49
Die Aufgabenstellungen sind größtenteils an Abschnitte aus (Schümmer 2006) angelehnt.
2009-09-10
84/107
Details zur Lösung
Vergleich: Cooperation/CMI
Als Vergleich zu CURE, nun eine Abbildung des Login Screens des Basisprojekts:
Abb. 45: Login Screen und Signup (Zugang beantragen) von Cooperation
Umsetzung
Die Benutzerverwaltung inklusive Login ist bereits im Basisprojekt enthalten. Zur
Verwendung wird das Basisprojekt aus dem Repository ausgecheckt, und die
Migration durchgeführt. Nach den Starten des Servers ist der Login Screen über den
Link hostname:port erreichbar.
Generierte Modelle
Folgende Abbildung zeigt alle bisher generierten Modelle, und deren Beziehungen
zueinander:
Abb. 46: Schritt 1: Modelle und Beziehungen
Siehe auch:
Basisprojekt, Abschnitt 5.2.1
Schritt 2: Introduce Yourself
Aufgabenstellung
Der Benutzer möchte sein eigenes Benutzerprofil, sein Virtual Me, anlegen. Dieses
beinhaltet eine nähere Beschreibung des Benutzers und dessen Bild.
2009-09-10
85/107
Details zur Lösung
Beispiel CURE
Der Aufruf des Benutzerprofils erfolgt über das User Icon, wobei zwischen
Benutzerprofil zeigen und Benutzerprofil editieren gewählt werden kann.
Abb. 47: Benutzerprofil editieren in CURE
Das Editieren des eigenen Benutzerprofils erfolgt, wie die anderen Aktionen, die mit
dem eigenen Benutzer möglich sind, hier ebenfalls über das User Icon.
Oberhalb des User Icons wird zusätzlich der Availability Status des Benutzers
angezeigt.
Abb. 48: CMI Plug-In Virtual Me mit aufgeklapptem Tooltip
2009-09-10
86/107
Details zur Lösung
Umsetzung
Das Entwurfsmuster Virtual Me wird durch das Modul cmi_virtual_me umgesetzt.
Nachdem alle Abhängigkeiten von cmi_virtual_me installiert wurden (im Normalfall
fehlt an dieser Stelle nur noch Attachment Fu), wird das Plug-In mittels ruby
script\generate cmi_virtual_me in die Anwendung installiert. Im Anschluss
daran können bei Bedarf noch die Attribute in der Migrationsdatei
(cmi_create_virtual_mes.rb) angepasst werden, bevor die Migrationen durchgeführt
werden. Danach müssen im User Model noch die Zeile has_one :cmi_user_avatar
für die Assoziierung mit dem User Avatar, und die Zeile acts_as_virtual_me für
die Erweiterung des Users durch acts_as_virtual_me, eingefügt werden..
Das virtual me ist jetzt bereits vollständig, und könnte schon in der Anwendung
verwendet werden.
Benutzerfreundlicher ist die Verwendung jedoch über die Interactive User Info,
deshalb wird ein weiteres Plug-In durch Aufruf der Befehle ruby script\generate
50
cmi_interactive_user_info , und rake db:migrate, in die Anwendung
installiert.
Nun kann das Partial _cmi_current_user.html.erb, das in das Verzeichnis
app\views\cmi_general installiert wurde, an der gewünschten Stelle (z.B. im Layout
des Cooperation-Projekts in der Sektion <div id="side">) eingebunden werden,
und ist vollständig verwendbar.
Generierte Modelle
zueinander:
Siehe auch:
cmi_interactive_user_info, Abschnitt 5.2.11
cmi_virtual_me, Abschnitt 5.2.2.1
cmi_user_avatar, Abschnitt 5.3.1
Attachment Fu, Abschnitt 5.2.6
Tooltips, Abschnitt 5.3.5
50
Die Abhängigkeit zum Plug-In Tooltips sollte zusätzlich berücksichtigt werden.
2009-09-10
87/107
Details zur Lösung
Schritt 3: Andere Benutzer
Aufgabenstellung
Alle Benutzer des Systems 51 sollen angezeigt werden (User Gallery), und je nach
Kontext sollen zusätzlich noch alle Bekannten des Benutzers (Buddies), bzw. alle
Benutzer eines Raums, angezeigt werden (Buddy List).
Beispiel CURE
Die Buddy-Liste in CURE befindet sich auf der Startseite eines Raumes (Hall), und
zeigt alle Buddies des eingeloggten Benutzers an. Die Aktionen Add personal Buddy,
show profile und Mail mit den Benutzern können aufgerufen werden.
Abb. 50: Buddy-Liste in CURE
CMI stellt dafür die Module cmi_buddy_list und cmi_user_gallery bereit, die an einer
beliebigen Stelle in die Anwendung eingebunden werden können.
Aus Benutzersicht unterscheiden sich die beiden Listen hauptsächlich dadurch, dass
die Buddies durch den Benutzer selbst in die Buddy List hinzugefügt bzw. entfernt
werden können, dass die Buddy List auch den Availability Status der Benutzer
anzeigt, und dass in den beiden Listen unterschiedliche Aktionen mit den Benutzern
möglich sind.
Die Benutzeraktionen erfolgen jeweils über den Tooltip des User Icons.
Abb. 51: CMI Buddy List
51
Je nach Bedarf kann es erforderlich sein, dass nicht alle Benutzer, sondern nur bestimmte Benutzer
angezeigt werden.
2009-09-10
88/107
Details zur Lösung
Umsetzung
•
User Gallery
Das Plug-In wird über den Befehl ruby script\generate cmi_user_gallery
in die Anwendung installiert. Zur Anzeige der User Gallery muss das Partial
_cmi_user_gallery.html.erb an einer beliebigen Stelle (z.B. im Projekt
Cooperation in der Datei index.html.erb) durch Einfügen folgenden Codes
eingebunden werden:
<%= render(:partial => "cmi_general/cmi_user_gallery.html.erb",
"/cmi_general/cmi_user_gallery_create_buddy_links.html.erb"}) %>
•
Buddy List
Bevor das Plug-In installiert werden kann, muss das Plug-In cmi_message
installiert werden, dies erfolgt durch ruby script\generate cmi_message. Die
Installation der Buddy List selbst erfolgt durch Aufruf von ruby
script\generate cmi_buddy_list. Das Assoziieren der beiden Models
(CmiMessage und CmiBuddyList) mit dem User Model durch Einfügen der Zeilen
has_many :cmi_buddy_lists und has_many :cmi_messages im User Model,
und die Ausführung der Migrationen, schließen die Installation ab.
Das Partial _cmi_buddy_list.html.erb kann nun wie folgt, z.B. in der Layout Datei
cooperation.html.erb, eingefügt werden:
<% the_user_ids =CmiHelper.get_buddy_ids_by_conditions
(current_user, "state == 'confirmed'")%>
<%= render(:partial => "cmi_buddy_list/cmi_buddy_list.html.erb",
"/cmi_buddy_list/cmi_buddy_list_default_links.html.erb",
:the_user_ids => the_user_ids}) %>
Generierte Modelle
zueinander:
Siehe auch:
cmi_user_gallery, Abschnitt 5.2.3
cmi_buddy_list, Abschnitt 5.2.4
cmi_message, Abschnitt 5.2.8
2009-09-10
89/107
Details zur Lösung
Schritt 4: Räume für die Zusammenarbeit erstellen und verwalten
Aufgabenstellung
Die Zusammenarbeit soll in Räumen erfolgen. Räume sollen erstellt und verwaltet
werden können, die Inhalte und Ergebnisse der Zusammenarbeit sollen in Räumen
abgespeichert werden.
Beispiel CURE
In CURE werden virtuelle Räume als Ort für die Zusammenarbeit genutzt. Die Inhalte
von Räumen werden als Seiten bezeichnet, ein Raum kann viele Seiten (Pages)
beinhalten 52.
Abb. 53 zeigt einen Raum (1.) und eine sich darin befindende Seite (2.).
Abb. 53: Raum und Seite in CURE
Cooperation organisiert Zusammenarbeit ebenfalls durch virtuelle Räume. Von einem
Startpunkt aus gelangt der Benutzer zu den verschiedenen Räumen. Von dort aus
können die Räume betreten werden. Die Verwaltung der Räume erfolgt über den Link
manage rooms. Über diesen Link kann der Benutzer neue Räume erstellen, und der
jeweilige Besitzer kann seine eigenen Räume editieren.
Räume können beliebige Inhalte besitzen, ein Beispiel dazu wird im Schritt 5 gezeigt.
52
siehe (Schümmer 2006, S. 8)
2009-09-10
90/107
Details zur Lösung
Abb. 54: CMI Room
Umsetzung
Das Plug-In wird über den Aufruf von ruby script\generate cmi_room users in
die Anwendung installiert. Nach der Ausführung der Migration muss das User Model
noch mit dem Model CmiRoom assoziiert werden, das erfolgt durch das Einfügen von
has_and_belongs_to_many :cmi_rooms im User Model.
Die View cmi_room.html.erb dient als Startpunkt für alle weiteren Views, und kann
wie folgt (z.B. direkt in main/index.html.erb) in die Anwendung eingebunden werden:
<%= render(:partial => "cmi_rooms/cmi_room.html.erb") %>
Von dieser View aus sind alle weiteren Optionen erreichbar.
Generierte Modelle
zueinander:
2009-09-10
91/107
Details zur Lösung
Siehe auch:
cmi_room, Abschnitt 5.2.7
Schritt 5: Inhalte von Räumen
Aufgabenstellung
In Räumen sollen Inhalte, wie das Ergebnis von Zusammenarbeit, abgespeichert
werden können.
Beispiel CURE
In CURE werden die Inhalte von Räumen als Seiten bezeichnet. Seiten können aus
strukturiertem Text (durch Verwendung einer Art von Wiki Syntax), oder aus binären
Inhalten bestehen 53. Seiten können miteinander verlinkt werden.
Abb. 56: Seite in CURE im Edit Mode
Räume können beliebige Inhalte haben. Es wird empfohlen, die Inhalte über ein
separates Model, das über eine Tabelle mit den Räumen verknüpft ist, auszuführen
(siehe folgendes Beispiel für die Umsetzung).
53
Siehe (Haake et al. 2004, S. 4) und (Schümmer 2006).
2009-09-10
92/107
Details zur Lösung
Abb. 57: CMI Room mit Inhalt
Umsetzung
Anhand des Beispiels demo_bike_guide wird nun gezeigt, wie Inhalte in einen Raum
eingefügt werden können.
Die Installation des Beispielmoduls erfolgt über den Befehl ruby script\generate
demo_bike_guide, mit anschließendem rake db:migrate.
Vor der Verwendung muss das CmiRoom Model noch mit dem Tour Model in
Beziehung gesetzt werden, das erfolgt durch Einfügen der Zeile
has_and_belongs_to_many :tours in der Datei cmi_room.rb.
Das Beispiel kann wie folgt in einen Room (am besten in die Datei
cmi_a_room.html.erb) eingebunden werden:
<%= render :file => "/tours/index_room.html.erb",
:params => {:layout => true} %>
2009-09-10
93/107
Details zur Lösung
Generierte Modelle
zueinander:
Siehe auch:
demo_bike_guide, Abschnitt 5.3.2
cmi_room, Abschnitt 5.2.7
Schritt 6: Kommunikation mit anderen Benutzern
Aufgabenstellung
Die Anwendung soll den Benutzern je nach Situation das passende Kommunikationsmedium bereitstellen.
Beispiel CURE
In CURE erfolgt die Kommunikation über die Mailing List 54, das ist eine Mailbox, die
sich in einem Raum befindet, und die Nachrichten in Threads geordnet darstellt. Alle
Nachrichten werden auch zusätzlich über Email verschickt (wenn konfiguriert). Auch
ein Embedded Chat Modul ist vorhanden.
54
Siehe (Schümmer 2006, S. 18)
2009-09-10
94/107
Details zur Lösung
Abb. 59: Mailing List in CURE
Grundsätzlich müssen die Nachrichten unterteilt werden in automatisch generierte
Nachrichten (die vom Benutzer zusätzlich mit einem Mitteilungstext versehen werden
können), und vom Benutzer generierte Nachrichten, wie Emails und ChatNachrichten.
Alle Nachrichten (Emails, Buddy Requests, ...), außer Chat-Nachrichten, werden in
einer Tabelle abgespeichert, und können über das Message Board, das zusammen mit
dem Plug-In cmi_message installiert wird, abgerufen werden. Nachrichten sind den
Benutzern zugeordnet, sie können über Email und/oder Juggernaut an die Empfänger
verteilt werden.
Beim Chat wird zwischen privaten und öffentlichen Chaträumen unterschieden. Der
Aufruf der Chaträume kann wahlweise entweder unabhängig von der Anwendung,
oder integriert in die Anwendung, erfolgen.
Abb. 60: CMI Message Board
2009-09-10
95/107
Details zur Lösung
Umsetzung
•
Automatisch generierte Nachrichten und Emails
Die Infrastruktur für die Verteilung und Betrachtung von Emails und automatisch
generierten Nachrichten wird durch das Modul cmi_message bereitgestellt, das
bereits installiert wurde.
Das Versenden der Nachrichten erfolgt entweder nach einer Benutzeraktion (wie
z.B. einer Buddy Anfrage), oder über die Interactive User Info (Email).
Diese Nachrichten können über das Message Board betrachtet werden.
Das Message Board kann in eine View eingebunden werden, indem das Partial
cmi_message_board.html.erb an der gewünschten Stelle wie folgt in eine View
eingefügt wird:
<%= render(:partial=>"cmi_messages/cmi_message_board.html.erb")%>
Sollen die Nachrichten zusätzlich über Juggernaut an die Clients verteilt werden,
so muss das Juggernaut Plug-In installiert, und der Juggernaut Server gestartet
werden. Alles Weitere geschieht transparent für den Benutzer.
Werden die Nachrichten über Juggernaut verteilt, so erfolgt dies synchron, und
beim Empfangen einer neuen Nachricht wird dies im Message Board angezeigt.
•
Chat
Der Embedded Chat wird durch ein separates Modul (cmi_embedded_chat)
realisiert. Für dieses Beispiel werden die Komponenten der Version integrated
installiert. Dies wird durch Aufruf des Generators mit dem Befehl ruby
script\generate cmi_embedded_chat --skip-independent erreicht. Nun ist
noch ein rake db:migrate erforderlich, und da jeder private Chatraum
bestimmten Benutzern zugeordnet ist, muss noch diese Assoziation durch
has_many :cmi_private_chat_rooms im User Model definiert werden.
Das Chat Board wird direkt ins Layout durch Einfügen folgender Zeile in der
Datei cooperation.html.erb eingebunden:
<%=render(:partial=>"cmi_embedded_chat/cmi_chat_board.html.erb")%>
Die Privaten Chatrooms werden über die Buddy List erzeugt, der Link dazu wird
in der Datei cmi_buddy_list_default_links.html.erb durch Einfügen folgenden
Codes erzeugt:
<%= link_to "Private chat",
{:controller => 'cmi_embedded_chat', :action => 'invite_private',
:params => { :client_id => a_user[:id],
:current_user_id => current_user.id } },
:popup => ['_blank','height=300,width=600,scrollbars=yes'] %><br/>
2009-09-10
96/107
Details zur Lösung
Generierte Modelle
zueinander:
Siehe auch:
cmi_embedded_chat, Abschnitt 5.2.9
Juggernaut, Abschnitt 5.2.15
Schritt 7: Zusammenarbeit und Synchrone Group Awareness
Aufgabenstellung
Durch synchrone Group Awareness soll die Zusammenarbeit unterstützt werden. In
einer synchronen Collaborative Session ist es wichtig, dass alle Benutzer darüber
informiert sind, welche anderen Benutzer sich gerade an der Sitzung beteiligen,
welchen Availability Status sie haben, und was sie gerade machen.
Beispiel CURE
In CURE wird Group Awareness während der synchronen Zusammenarbeit über die
User List erreicht. Alle Benutzer, die sich gerade im Raum befinden, werden in der
User List angezeigt. In der User List ist auch ersichtlich, auf welcher Seite sich die
Benutzer gerade befinden 55.
55
Siehe (Schümmer 2006, S. 13)
2009-09-10
97/107
Details zur Lösung
Abb. 62: User List in CURE, Quelle:(Schümmer 2006, S. 13)
Hier wird synchrone Group Awareness durch mehrere Elemente realisiert:
• Buddy List und Availability Status
Die Buddy List zeigt die Buddies zusammen mit deren Availability State an (siehe
Schritt 3 oben).
• User List
Die User List zeigt an, welche User sich gerade im Raum befinden (siehe
cmi_room).
• Collaborative Session View
Diese View zeigt den Collaborative Session State an, das heißt welche Tätigkeiten
die Benutzer in der Collaborative Session gerade ausführen.
Abb. 63: CMI User List und Collaborative Session State
Umsetzung (Collaborative Session)
Die Installation des Plug-Ins cmi_coll_session in die Anwendung erfolgt über ruby
script\generate cmi_coll_session cmi_rooms.
Danach wird die Migration durchgeführt, und das entsprechende Model (hier
CmiRoom) mit dem CmiCollSession Model assoziiert. Dies wird durch das Einfügen
folgender Zeile z.B. im CmiRoom Model erreicht:
has_and_belongs_to_many :cmi_coll_sessions
2009-09-10
98/107
Details zur Lösung
Jedesmal, wenn eine Session betreten wird, wird das CmiSession Objekt erzeugt,
bzw. aktualisiert. In diesem Beispiel geschieht dies jedesmal beim Betreten des
Raums in der Methode cmi_a_room des CmiRoomControllers:
CmiCollSession.enter_coll_session(@room, @user)
Das Ändern des Benutzerstatus (im Session Objekt) erfolgt ähnlich, ein Beispiel dazu
kann im ToursController in der Methode new_tour_room gefunden werden.
Die Session State View kann folgendermaßen in eine Anwendung eingebunden
werden (in der Beispielanwendung passt sie z.B. sehr gut in cmi_a_room.html.erb):
<%=render(:partial=>cmi_coll_session/cmi_coll_session_state.html.erb"
, :locals => {:room => @room}) %>
Generierte Modelle
zueinander:
Siehe auch:
cmi_coll_session, Abschnitt 5.2.13
Juggernaut, Abschnitt 5.2.15
cmi_virtual_me, Abschnitt 5.2.2
2009-09-10
99/107
Zusammenfassung
6 Zusammenfassung
Zum Abschluss folgt nun noch einmal eine Zusammenfassung der Anforderungen,
und wie die Aufgabenstellung umgesetzt wurde.
Danach folgt ein Ausblick auf mögliche weitere Arbeiten auf diesem Gebiet, und es
wird aufgezeigt, welche Punkte im Rahmen dieser Arbeit nicht behandelt werden
konnten.
6.1 Wie wurde die Aufgabenstellung gelöst?
Motiviert von den Herausforderungen, die die Web 2.0 Generation an Groupware
Anwendungen stellt, war das Ziel dieser Arbeit, Kooperationsmodule für Ruby on
Rails zu entwickeln. Als Grundlage für die Realisierung der Module dienten die
Entwurfsmuster aus (Schümmer und Lukosch 2007).
Zu Beginn wurden die wichtigsten Entwurfsmuster ermittelt. Dazu wurde eine Studie
durchgeführt, die eine grobe Richtung für die Auswahl vorgab. Ein überraschendes
Ergebnis war dabei, dass sowohl die untersuchten Open Source Anwendungen, als
auch einige der untersuchten kommerziellen Anwendungen in Bezug auf Group
Awareness noch viel Verbesserungspotential aufweisen.
Im nächsten Schritt wurden die Anforderungen an kooperative Module in der Ruby on
Rails Umgebung ermittelt. Neben anderen Kriterien können dabei Modularität,
Verwendbarkeit und Konfigurierbarkeit als besonders wichtig hervorgehoben werden.
Danach wurde untersucht, ob unter den verfügbaren Plug-Ins geeignete
Kooperationsmodule für die Entwicklung einer Groupware Anwendung zu finden
sind. Erfreulich ist, dass für Ruby on Rails sehr viele qualitativ hochwertige Module
frei erhältlich sind, die bei Bedarf recht einfach anpassbar bzw. erweiterbar sind. Wie
sich gezeigt hat, sind kooperative Module jedoch kaum darunter zu finden.
Im Anschluss daran wurden die wichtigsten Module als Rails Plug-Ins umgesetzt,
wobei sich als Strategie zur Umsetzung der Aufgabenstellung recht schnell
herauskristallisiert hat, ausgehend von einem Basisprojekt, die meisten der
Entwurfsmuster als Plug-Ins selbst zu implementieren, und bei Bedarf und
Verfügbarkeit auf bestehende Plug-Ins zurückzugreifen.
Um der Anforderung der Modularität gerecht zu werden, wurden teilweise mehrere
Muster in einem Plug-In zusammengefasst. Mitunter war es recht schwierig, die
Entwurfsmuster den Modulen zuzuordnen, denn einerseits sollen die Module
möglichst lose gekoppelt, flexibel einsetzbar und nach Bedarf miteinander
kombinierbar sein, und andererseits sollen sie einfach zu installieren sein, was sich
widersprechen kann. Außerdem war es nicht immer leicht, die Grenze zwischen
Modul und Anwendung zu ziehen.
2009-09-10
100/107
Zusammenfassung
Die größte Herausforderung war aber mit Sicherheit die Umsetzung der
Entwurfsmuster, die synchronizität erfordern. Diese Muster wurden auf Basis des
Plug-Ins Juggernaut implementiert.
6.2 Ausblick
Eine Erkenntnis dieser Arbeit ist, dass in der Ruby on Rails Welt, besonders was die
Verfügbarkeit von Plug-Ins für kooperative Elemente betrifft, noch viel Aufholbedarf
besteht. Diesbezüglich leistet diese Arbeit einen ersten Beitrag.
Natürlich gibt es zu den implementierten Entwurfsmustern auch noch die eine oder
andere Idee zur Verbesserung bzw. Erweiterung. Interessanter erscheint jedoch, die
Bibliothek zu erweitern, und die noch offenen Entwurfsmuster ebenfalls als Plug-Ins
zu implementieren. Eine große Herausforderung stellen dabei sicherlich die noch
nicht implementierten Entwurfsmuster aus dem Cluster Synchronous Group
Awareness wie z.B. Remote Selection oder Remote Field of Vision dar, aber auch
andere Entwurfsmuster, wie z.B. Shared Editing, erscheinen für die Umsetzung
interessant zu sein. Der Bedarf besteht, wie die Untersuchung in Kapitel 3 gezeigt hat.
2009-09-10
101/107
Quellenverzeichnis
7 Quellenverzeichnis
Booch, Grady (1993): Object-Oriented Analysis and Design with Applications,
Addison-Wesley 2003, ISBN-10: 0805353402
Facebook (2009): Seite „Facebook“. In: Wikipedia, Die freie Enzyklopädie.
Bearbeitungsstand: 22. Mai 2009, 10:08 UTC. URL:
http://de.wikipedia.org/w/index.php?title=Facebook&oldid=60311407 (Abgerufen:
26. Mai 2009, 15:39 UTC)
Fischer Jens (2008): Professionelle Webentwicklung mit Ruby on Rails 2, mitp, 2008,
ISBN 978-3-8266-1683-9
Fowler Martin (2003): Patterns of Enterprise Application Architecture, Pearson
Education 2003, ISBN 0-321-12742-0
Fuks Hugo (2006): Development of Groupware based on the 3C Collaboration Model
and Component Technology, Hugo Fuks, 2006, http://groupware.les.inf.pucrio.br/groupware/publicacoes/CRIWG2006.pps
Gerosa et al (2006): Development of Groupware Based on the 3C Collaboration
Model and Component Technology, Marco Aurélio Gerosa et al., Springer Berlin /
Heidelberg, 2006, ISBN 978-3-540-39591-1
Haake Jörg M., Schümmer Till, Haake Anja, Bourimi Mohamed und Landgraf Britta
(2004): Supporting flexible collaborative distance learning in the CURE platform. In:
Proceedings of the 37th Hawaii International Conference on System Sciences - 2004.
2004, Hagen. S. 1.
Hansson David Heinemeier (2003): Web development that does not hurt,
http://rubyonrails.org/
Hansson David Heinemeier, Thomas Dave und Ruby Sam (2009): Agile Web
Development with Rails, Third Edition, The Pragmatic Bookshelf 2009, ISBN-10: 1934356-16-6
Jacobs Ian (2004): Architecture of the World Wide Web, Volume One, Introduction,
W3C 2004, http://www.w3.org/TR/webarch/
Kappel Gerti, Pröll Birgit, Reich Siegfried und Retschitzegger Werner (2004): Web
Engineering, Systematische Entwicklung von Web-Anwendungen, dpunkt 2004,
ISBN 3-89864-234-8
Kappel Gerti, Pröll Birgit, Reich Siegfried und Retschitzegger Werner (2006): Web
Engineering: The Discipline of Systematic Development of Web Applications, Wiley
2006, ISBN-13: 978-0470015544
2009-09-10
102/107
Quellenverzeichnis
Krasner Glenn E. und Pope Stephen T. (1988): A cookbook for using the model-view
controller user interface paradigm in Smalltalk-80, Journal of Object-Oriented
Programming, 1(3), 1988, ISSN:0896-8438
Hunt Andy (2000): Pragmatic Software Development Tips,
http://www.pragprog.com/the-pragmatic-programmer/extracts/tips
O'Reilly Tim (2006): Web 2.0 Compact Definition: Trying Again,
http://radar.oreilly.com/archives/2006/12/web-20-compact.html
Orsini Rob (2007): Rails Kochbuch, O’Reilly 2007, ISBN 978-3-89721-714-0
Rechenberg Peter und Pomberger Gustav (2002): Informatik-Handbuch, 3. Auflage,
Hanser 2002, ISBN 3-446-21842-4
Schümmer Till (2006): CURE in a Nutshell, FernUniversität in Hagen 2006,
http://mapper.fernuni-hagen.de/CURE/doc/Manual.pdf
Schümmer Till und Lukosch Stephan (2007): Patterns for Computer Mediated
Interaction, Wiley 2007, ISBN 978-0-470-02561-1
Wikibooks (2009a): Seite "Ruby on Rails/Getting Started/Convention Over
Configuration". In: Wikibooks. Bearbeitungsstand: 8 May 2009, 00:08. URL:
http://en.wikibooks.org/wiki/Ruby_on_Rails/Getting_Started/Convention_Over_Conf
iguration (Abgerufen: 1. Juni 2009, 22:43 UTC)
Wikibooks (2009b): Seite "Ruby Ruby on Rails/ActiveRecord". In: Wikibooks.
Bearbeitungsstand: 8 May 2009, 00:08. URL:
http://en.wikibooks.org/wiki/Ruby_on_Rails/ActiveRecord#Acts_as (Abgerufen: 4.
Juni 2009, 15:47 UTC)
Wikipedia (2009a): Seite "Endlicher Automat". In: Wikipedia, Die freie
Enzyklopädie. Bearbeitungsstand: 20. Mai 2009, 08:35 UTC. URL:
http://de.wikipedia.org/w/index.php?title=Endlicher_Automat&oldid=60243837
(Abgerufen: 1. Juni 2009, 16:02 UTC)
Wikipedia (2009b): Seite „Modularität“. In: Wikipedia, Die freie Enzyklopädie.
Bearbeitungsstand: 3. April 2009, 18:19 UTC. URL:
http://de.wikipedia.org/w/index.php?title=Modularit%C3%A4t&oldid=58645710
(Abgerufen: 10. Juni 2009, 14:42 UTC)
Winter Mario (2005): Methodische objektorientiert Softwareentwicklung,
dpunkt.verlag 2005, ISBN 3-89864-273-9
2009-09-10
103/107
Quellenverzeichnis
A. Anhang
1. Installation von Juggernaut
•
Ubuntu
Gegebenenfalls muss zuerst Flash installiert werden, dazu kann der Flash Player unter
folgendem link heruntergeladen werden:
http://get.adobe.com/flashplayer, dann .deb for Ubuntu 8.04+ (= 10.0 r15) auswählen.
Juggernaut kann problemlos, wie auf der Homepage beschrieben, installiert werden.
Von der Anleitung abweichend ist lediglich, dass die Installation des Plug-Ins selbst
durch ruby script/plugin install http://github.com/maccman/juggernautplugin.git/ erfolgt.
•
MS Windows
Flash: Die für diese Arbeit getestete und verwendete Version des Flash Players ist
10.0 r12
Leider lässt sich Juggernaut aufgrund des fehlenden C-Compilers unter MS Windows
nicht ohne weiteres installieren. Darum an dieser Stelle eine kurze Beschreibung, wie
Juggernaut auch auf MS Windows zum Einsatz gebracht werden kann:
o Installation von GitHub:
Juggernaut wird seit kurzem auf GitHub gehostet. Um Juggernaut von GitHub zu
installieren, muss man sich erst einen Zugang dafür verschaffen (siehe GitHub).
o Installation ohne GitHub
Da sich die Installation von der Anleitung auf der Homepage etwas unterscheidet,
wird der folgende Weg empfohlen (Quelle:
http://ctrlshiftesc.wordpress.com/2008/08/26/installing-juggernaut-gem-headachepainkiller/):
1.
2.
3.
4.
gem
gem
gem
gem
install
install
install
install
json
json_pure
eventmachine
juggernaut –ignore-dependencies
5. Nun folgende Änderung in der Datei
\ruby\lib\ruby\gems\1.8\specifications\juggernaut-0.5.4.gemspec im rubyVerzeichnis durchführen:
s.add_dependency(%q eventmachine, [">= 0.10.0"])
s.add_dependency(%q json, [">= 1.1.2"]) # —- ändern in 1.1.1
s.add_dependency(%q hoe, [">= 1.5.1"]) #— ändern in 1.3.1
6. Jetzt noch das Juggernaut-Plug-In ins plugins-Verzeichnis des Projekts
installieren: Wenn dazu die aktuelle Version von www.rubyforge.org
verwendet wird, erscheint eine Fehlermeldung ( „No expansion found for
:juggernaut" unter Rails 2.2.2). Deshalb wird empfohlen, entweder die aktuelle
Juggernaut-Version von GitHub zu installieren, oder das Plug-In aus dem
Cooperation- Repository auszuchecken. Die Installation des Plug-Ins wird
2009-09-10
104/107
Quellenverzeichnis
dann durch Angabe des Parameters --install-juggernaut bei der
Installation des jeweiligen CMI-Plug-Ins durchgeführt.
7. Juggernaut benötigt eine Konfigurationsdatei, die mittels juggernaut -g
juggernaut.yml ins Wurzelverzeichnis des Projekts kopiert wird. Alternativ
dazu kann auch die vorkonfigurierte Datei des CMI-Plug-Ins verwendet
werden, diese wird bei der Installation des Plug-Ins mit installiert (Vorsicht,
die eigenen Dateien ggf. vor der Installation des entsprechenden Plug-Ins
sichern).
8. Der Juggernaut Server wird mittels juggernaut -c juggernaut.yml
gestartet.
2. Installation von MiniMagick und ImageMagic auf MS Windows
Die Quelle für diese Beschreibung ist unter dem Link
http://samuelschroeder.com/2007/07/31/installing-imagemagick-and-minimagick-onwindows/ zu finden.
Beschreibung:
Um aus Bildern Thumbnails zu erzeugen, greift das Plug-In Attachment Fu auf eine
externe Komponente zurück. Eine von mehreren dafür geeigneten Komponenten ist
MiniMagick.
MiniMagick benötigt wiederum als Precondition das Programm ImageMagic.
•
ImageMagic installieren
Ein Setup für ImageMagic kann von http://www.imagemagick.org/script/binaryreleases.php#windows heruntergeladen werden, und wird wie in MS Windows
üblich installiert.
•
MiniMagick installieren
Entweder wird das gem durch gem install mini_magick installiert, oder man
lädt das Plug-In von http://rubyforge.org/frs/download.php/21736/mini_magick1.2.3.tgz herunter und kopiert es in das plugins Verzeichnis des Projekts (in dieser
Form ist das Plug-In auch im Repository enthalten, und kann direkt von dort
verwendet werden).
3. Installation von GitHub auf MS Windows
Die Homepage lässt sich über den Link http://github.com/ aufrufen.
Eine Anleitung, wie man sich Zugang zu GitHub verschafft, um Rails Plug-Ins von
GitHub auf einer MS Windows Plattform zu installieren, ist unter folgendem Link zu
finden:
http://jamie.ideasasylum.com/2008/08/installing-rails-plugins-with-git-on-windows/
2009-09-10
105/107
Quellenverzeichnis
4. Bekannte Fehler und deren Behebung
Fehlermeldung:
INSTALLDIR/vendor/plugins/juggernaut/lib/juggernaut.rb:5:in
`read': No such file or directory - INSTALLDIR /config/juggernaut_hosts.yml
(Errno::ENOENT)
• Ursache:
Sobald sich das Plug-In Juggernaut im plugins Verzeichnis befindet, versucht
Juggernaut, beim initialisieren auf die Konfigurationsdatei juggernaut_hosts.yml
zuzugreifen. Ist die Datei nicht vorhanden, erscheint diese Fehlermeldung.
• Behebung:
Falls Juggernaut verwendet werden soll, die entsprechende Datei ins config
Verzeichnis kopieren (ist im Repository vorhanden).
Sonst das gesamte Verzeichnis Juggernaut_plugin aus dem plugins-Verzeichnis
des Projekts löschen.
Fehlermeldung: Nachdem auf eine Seite zugegriffen wurde, erscheint folgende
Fehlermeldung im Logfile:
ActionController::RoutingError (No route matches
"/javascripts/widgets/tooltip.js" with {:method=>:get}):
•
•
Ursache:
Das Plug-In rails-widgets befindet sich im pluginsVerzeichnis, es wurde aber
(noch) nicht installiert.
Behebung:
Das Plug-In rails-widgets installieren (empfohlen), oder das gesamte Verzeichnis
aus dem plugins Verzeichnis entfernen.
Fehlermeldung im Logfile:
ActionController::RoutingError (No route matches
"/javascripts/juggernaut/juggernaut.js" with {:method=>:get}):
•
•
Ursache:
Juggernaut ist nicht richtig installiert.
Behebung:
Das Plug-In richtig installieren.
Fehlermeldung:
Wird der Juggernaut-Server gestoppt, so crasht Flash, wenn noch eine Verbindung zu
Juggernaut besteht.
• Behebung:
Vor dem Beenden des Juggernaut-Servers alle Verbindungen schließen.
Fehlermeldung:
"uninitialized constant CmiRemoteSubscriptionObserver (NameError)" beim starten
des Servers, oder:
`load_missing_constant': uninitialized constant CmiRemoteSubscriptionObserver
(NameError) beim installieren des Plug-Ins cmi_remote_subscription
• Ursache:
2009-09-10
106/107
Quellenverzeichnis
•
Möglicherweise ist der CmiRemoteSubscriptionObserver in der Datei
environment.rb registriert, der Observer befindet sich aber nicht (mehr) an der
richtigen Stelle im Models Verzeichnis.
Behebung:
Eintrag aus environment.rb löschen, oder das Plug-In neu installieren.
Fehlermeldung:
"Size is not included in the list" bei der Verwendung von Attachment Fu unter MS
MS Windows.
• Ursache:
Das Kopieren von Dateien unter MS Windows ist zu langsam.
• Behebung:
Siehe http://epirsch.blogspot.com/2008/01/fixing-attachmentfu-on-windowslike.html.
Fehlermeldung:
Wenn versucht wird, auf eine Seite zuzugreifen, erscheint die Meldung "undefined
method `has_attachment' for #<Class: ... >" im Webbrowser.
• Ursache:
Eine Komponente versucht, eine Methode des Plug-Ins Attachment Fu aufzurufen,
das Plug-In ist jedoch nicht installiert.
• Behebung:
Das Plug-In Attachment Fu installieren.
Fehlermeldung:
Die Ausführung einer Migration wird mit folgender Fehlermeldung abgebrochen:
"rake aborted!
Multiple migrations have the version number"
• Ursache:
CMI legt für jede Migration eine eigene Datei an. Wenn das Projekt so
konfiguriert ist, dass die Migrationen automatisch mittels UTC-based Migration
Versioning nummeriert werden, ergibt sich so ein Versionskonflikt zwischen
diesen Dateien.
• Behebung:
Das Projekt kann über die Datei environment.rb konfiguriert werden, so dass die
Migrationsdateien in aufsteigender Reihenfolge nummeriert werden:
config.active_record.timestamped_migrations = false
(Quelle: http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utcbased-migration-versioning)
Danach die Migrationsdateien löschen, und das gewünschte Plug-In neu
installieren.
2009-09-10
107/107

Gestaltung von Kooperationsmodulen für Ruby on Rails

Transcription

Similar documents

1 Einstieg - Spider

Marktanalyse der Dienstleistungsbedürfnisse im Kabelfern

Programm - Ibero-Amerikanisches Institut

Fachexkursion Bulgarien 2014 - BASIS

Klassenlektüren für die 3. und 4. Klasse

User Profile Wizard 3.5

Handbuch als PDF Dokument zum