Universität Leipzig Softwaretechnik Praktikum xodx. Entwurfsbeschreibung. Entwurfsbeschreibung für das Gesamtprojekt Xodx

Transkript

1 Universität Leipzig Softwaretechnik Praktikum xodx Entwurfsbeschreibung Entwurfsbeschreibung für das Gesamtprojekt Xodx Henrik Hillebrand

2 Inhaltsverzeichnis Allgemein... 2 Produktübersicht... 2 Grundsätzliche Struktur- und Entwurfsprinzipien... 2 Struktur- und Entwurfsprinzipien einzelner Pakete... 4 Model... 4 View... 5 Controller... 6 GroupprofileController... 6 GroupController... 6 MemberController... 6 Dynamisches Modell... 7 Datenmodell... 7 Testkonzept... 8 Glossar... 9 Triple Store (Virtuoso)... 9 Linked Data... 9 Activity Steam... 9 Semantic Pingback... 9 DSSN... 9 Quellen... 9 Literatur... 9 Abbildungsverzeichnis

3 Allgemein Hinsichtlich des immer stärker werdenden Trends hin zum Semantic Web und der immer dichter werdenden sozialen Vernetzung durch Social Networks wie Google+ und Facebook hat sich das AKSW der Aufgabe angenommen und ein DSSN geschaffen, zu welchem der Zugangsknoten Xodx entstand. Unser Projekt ist es, diesen Knoten um eine weitere wichtige Funktion zu erweitern, welche es Benutzern ermöglicht sich in Interessensgruppierungen zusammenzufinden, Freundeskreise zu bilden oder Themengruppen zu schaffen. Zusätzlich soll dem Gründer die Möglichkeit gegeben werden seine Gruppen zu bearbeiten, zu löschen und ihre Nutzer zu verwalten. Allgemein kann gesagt werden, dass diese Funktionserweiterung dem Nutzer die Möglichkeit einräumt eine gruppeninterne Kommunikationsplattform zu schaffen, welche in vielerlei Hinsicht eine effiziente Anwendung finden kann. Dazu sei als Beispiel genannt, dass nach Implementierung und Fertigstellung des Projekts, nachfolgende SWP-Gruppen unsere Arbeit als Mittel der Kommunikation nutzen könnten, indem sie einen Xodx-Knoten auf dem ihnen zugeteilten Praktikumsserver installieren. Produktübersicht Nach erfolgreicher Installation einer Xodx-Instanz auf einem lauffähigem Server - oder wahlweise einer lokal laufenden virtuellen Serverumgebung - kann diese über jeden gängigen Webbrowser aufgerufen und verwendet werden. Hierzu muss der Nutzer sich in seinen Xodx-Account einloggen oder einen neuen erstellen. Bei der Erstellung eines neuen Accounts besteht auch die Möglichkeit, diesen mit einem bereits vorhandenen URI zu verknüpfen. Nach dem beschriebenen Login kann der Nutzer nun auf seinem eigenen Profil die von ihm betretenen und erstellten Gruppen einsehen und per Klick auf deren URI mit seinen Freunden, Kollegen oder Gleichgesinnten kommunizieren oder Links und Bilder mit ihnen teilen. Für den Gruppenadministrator ist ein Menü zu sehen, in welchem er die Gruppe verwalten kann. Dieses Menü enthält beispielsweise die Möglichkeit die Attribute, wie Name, Beschreibung usw. der Gruppenressource zu editieren oder diese zu schließen/löschen. Das Teilen von Feeds innerhalb der Gruppe ermöglicht eine Kommunikation mit den in dieser Gruppe befindlichen Mitgliedern. Diese Activity-Feeds können Links, normale Textnachrichten oder Bilder sein. Grundsätzliche Struktur- und Entwurfsprinzipien Da unser gewähltes Projekt auf dem bereits erwähnten Xodx-Knoten aufbaut und für diesen als Erweiterung dient, kann als grundsätzliche Struktur der von unserer Gruppe entwickelten Softwarestudie das Strukturprinzip des Xodx als gegeben empfunden werden. Dies gilt auch, gesondert zu erwähnen, aus dem Grund, da in Xodx bereits die Funktion zum Hinzufügen von Freunden implementiert ist und die Lösch-Funktion selbiger eine Abwandlung dieser darstellt. Grundsätzlich baut Xodx wiederum auf dem DSSN auf, welches intern in 3 verschiedene Ebenen (layer) unterteilt ist: Die Daten-, Anwendungs- und Service-Ebene (siehe Abbildung 1). 2

4 Abbildung 1: Ebenen-Modell des DSSN Die Daten-Ebene (Abb. 1) beinhaltet die RDF-Ressourcen, Media-Daten wie Bilder und letztlich die Activity-Feeds. Diese Daten werden über einen URI eindeutig benannt und können per Linked Data abgerufen und benutzt werden. Zudem besteht noch die Möglichkeit jede Ressource zu kommentieren oder andere Relationen zwischen ihnen zu erzeugen (Freundschaften zwischen Personen-Ressourcen o.ä.), welche auch in der Daten-Ebene gespeichert werden. Die Service- und Anwendungsebene stellt die Dienste oder Anwendungen bereit - mit anderen Worten die Oberfläche -, die gebraucht werden um innerhalb des Knotens auf Konten registrierter Xodx-Nutzer zuzugreifen, aber auch für beliebige andere Nutzer des DSSN. Die Ebene verfügt daher bspw. über den Profilmanager und das Teilen von Media-Daten, Benachrichtigungen und anderem. Zusätzlich zu erwähnen sei, dass Xodx selbst, und damit auch unsere Erweiterung, auf bereits bestehende Bibliotheken und Frameworks zurückgreift, die die Arbeit mit den angesprochenen Protokollen und RDF-Ressourcen erheblich vereinfacht. Dieses vermeidet Dopplungen im Code und erhöht die Qualität des Quellcodes wenn es um Struktur und Übersichtlichkeit geht. So nutzt Xodx das Erfurt-Framework - welches dem Programmierer den Zugriff auf Triple Stores und deren Modelle vereinfacht und mittel SPARQL die Nutzung dieser effizient ermöglicht -, das Saft- Framework - welches als Grundgerüst für Xodx dient und das MVC-Entwurfsmuster nutzt - und letztlich das lib-dssn-php - welches die Verarbeitung von Aktivitystreams erleichtert. Da durch das SAFT-Framework das MVC-Entwurfsmuster verwendet wird, liegen als zusätzliche Strukturelle Ebenen die Model-, View-, und Controllerebene über den angesprochenen DSSN- Ebenen, welche durch ein Layout-System auf der View-Ebene und der Controller "ResourceController" und zusätzliche actions in der Controller-Ebene die den Zugriff für den Programmierer noch weiter vereinfachen. Erweitert wird dieses bisherige Modell um einige neue Klassen, die, wie eingangs beschrieben, das Xodx-Projekt um die Gruppenfunktion ergänzt. Die genaue Funktion der einzelnen Klassen wird im nachfolgenden Punkt genauer erläutert, die Klassen selbst im nachstehenden Klassendiagramm aufgeführt. 3

5 ResourceController GroupController - $_groups : array() - _callmemberapi ($uri, $fields) - _createapiuri ($memberuri, $callaction) - _subscribegrouptofeed ($personuri, $groupuri) - _unsubscribegroupfromfeed ($personuri, $groupuri) + changegroup ($groupuri, $newname, $newtopic) + changegroupaction ($template) + creategroup ($name, $description) + creategroupaction ($template) + deletegroup ($groupuri) + deletegroupaction ($template) + getgroup ($groupuri) + getgroupbyauthoruri ($authoruri) + getgroupfeeduri ($resourceuri) + getpersonbyauthoruri ($authoruri) + homeaction ($template) + joingroup ($personuri, $groupuri) + joingroupaction ($template) + leavegroup ($personuri, $groupuri) + leavegroupaction ($template) + showaction ($template)... PersonController - $_persons : array() + addfriend ($personuri, $contacturi) + addfriendaction ($template) + deletefriend ($personuri, $contacturi) + deletefriendaction ($template) - _issuee24fix ($date) + getfeed ($personuri, $type = 'activity') + getnotifications ($personuri) + getperson ($personuri) + getuserforperson ($personuri) + rdfaction ($template) + showaction ($template) GroupprofileController MemberController + listaction($template) - _callapi ($uri, $fields) - _createapiuri ($memberuri, $callaction) # _issubscribed ($groupuri, $feeduri) # _subscribetofeed ($subscriberuri, $feeduri, $local = false) # _unsubscribefromfeed ($unsubscriberuri, $feeduri, $local = false) + addmember ($personuri, $groupuri) + addmemberaction ($template) + deletemember ($personuri, $groupuri) + deletememberaction ($template) + getactivitystream ($groupuri) + getsubscribedresources ($groupuri) + subscribetoresource ($subscriberuri, $resourceuri, $feeduri = null, $local = false) + unsubscribefromresource ($unsubscriberuri, $resourceuri, $feeduri = null, $local = false) Group - $_uri - $_name - $_description - $_app + construct ($uri, $app) + geturi () + getname () + setname ($name) + getdescription () + setdescription ($description) Abbildung 2: Klassenmodellierung des Gruppenkonzeptes Struktur- und Entwurfsprinzipien einzelner Pakete Wie zuvor erwähnt dient das Saft-Framework dem Zweck, dem Entwurfsmuster MVC konkret in Xodx folge leisten zu können. Daher ist im nachfolgenden die Struktur der einzelnen Pakete in die Ebenen eben jenes Entwurfsprinzip unterteilt und in diesen näher erläutert. Model Unsere Xodx-Erweiterung greift im Bereich der Model-Ebene, welche für die Speicherung der Daten und Anbindung an die Datenbank zuständig ist, auf die in dem Triple Store gespeicherten Einträge zu. Hier werden neue Relationen eingetragen, welche die Gruppenfeeds in Relation mit der Gruppe und dem Schreiber setzen und zusätzlich die Verbindungen zwischen den Mitgliedern und der Gruppe selbst über das Prädikat foaf:member. Im Datenmodell sind weiterhin ersichtlich, welche Verbindungen in der Datenbank von uns gespeichert, verändert oder beim Auflösen der Gruppe gelöscht werden. Der Zugriff auf diese Relationen erfolgt, wie auch in Xodx selbst und im Vorprojekt, über den Triple Store Virtuoso. 4

6 View Auf der View-Ebene wird es ein Template geben, das alle Gruppen der eigenen Xodx Instanz auflistet (Abb. 3). Weiterhin gibt es dort einen Link, der zur Seite führt, auf der man eine Gruppe erstellen kann. Für Letzteres ist auch ein Template vorgesehen, das eine Eingabemaske bietet, um eine Gruppe zu erstellen (Abb. 4). Abbildung 3: Liste aller Gruppen Abbildung 4: Erstellung einer neuen Gruppe Weiterhin wird das Template des eigenen Profils und das anderer Profile so weit verändert, dass eine dynamisch erstellte Gruppenliste anhand des nebenstehenden Schemas (Abb. 5) zu sehen sein wird, welche auf die zugehörige Gruppenressource verweist. Zusätzlich wird es möglich sein, diese Gruppen per Klick auf den Button Leave Group zu verlassen, und durch Eingabe einer gültigen Gruppen-URI im zugehörigen Feld einer neuen Gruppe beizutreten. Zusätzlich wird ein neues Template erstellt, welches die Gruppenressource selbst wiederspiegelt. Darin ist ein Activity-Feed und ggf. ein Administrationsmenü sichtbar sein. Der Activity-Feed ermöglicht es, wie eingangs erwähnt, mit den Mitgliedern zu kommunizieren, Bilder und Links zu teilen oder einen Verlauf über hinzugekommene und ausgetretene Mitglieder zu erhalten. Abbildung 5: Gruppenliste Das Template dieser Ressource ist bereits als vorläufiger Entwurf in Abbildung 6 (als Nicht-Mitglied) und in Abbildung 7 (als Mitglied) zu sehen. 5

7 Abbildung 6: Darstellung der Gruppe (nicht beigetreten) in Xodx Abbildung 7: Darstellung der Gruppe (beigetreten) in Xodx Darüber hinaus gibt es im View die Möglichkeit eine Controller Innerhalb der Controller-Ebene werden ebenfalls einige Erweiterungen vorgenommen werden. So wird diese um die folgenden drei Klassen erweitert werden: GroupprofileController Der GroupprofileController verarbeitet die Auflistung von Gruppen in Xodx er ist ein Pendant zum ProfileController. GroupController Der GroupController enthält alle nötigen Funktionalitäten um Gruppen zu erstellen, zu löschen, ihnen beizutreten und letztlich eben diese wieder zu verlassen. Außerdem dient er der Verwaltung der gruppeninternen Activities. Die genaue Funktionsübersicht ist dem Klassendiagramm zu entnehmen. MemberController Der MemberController dient der Mitgliederübersicht und der Gruppenübersicht auf den Profilen. Wie auch im GroupController erwähnt, können für den MemberController ebenfalls alle Funktionen im Klassendiagramm ermittelt werden. 6

8 Dynamisches Modell Person 1 Server 1 Person 2 Gruppe Server 2 joingroup(personuri, groupuri) Sights Reads Group creategroup(personuri, name) create notify and subscribe share notes & fotos notify addactivity(groupuri, personuri, verburi, objecturi) deletegroup(groupuri) terminate notify update Abbildung 8: Sequenzdiagramm des Gruppenkonzeptes Das oben zu sehende Diagramm zeigt den zeitlichen Ablauf der Interaktion zweier Personen mit einer Gruppe. So ist nacheinander zu sehen, wie eine Person eine Gruppe erstellt, eine zweite Person dieser beitritt, eine Aktivität in dieser teilt und im Anschluss daran eben jene wieder von ihrem Ersteller gelöscht wird. Das X markiert die vollständige Löschung der Ressource, was zur Folge hat, dass niemand mehr auf sie zugreifen kann. Datenmodell Das unten zu sehende Datenmodell zeigt auf abstrahierter Ebene die Verbindungen zwischen den Personen (foaf:person), welche der Gruppe zugehörig sind und der Gruppe (foaf:group) selbst, sowie die Verbindung zwischen dem Gründer der Gruppe und ihr. Des Weiteren ist die Verbindung zwischen einer Person und seinen Feed-Subscribtion zu erkennen, über welche er die Feeds der Gruppe beziehen kann. Die hier als Pfeile dargestellten Verbindungen symbolisieren die Prädikate, wobei der Pfeil vom Subjekt auf das Objekt des Tripels zeigt. Die Gruppe oben links beschreibt die privaten Gruppen (auch: Freunde gruppieren ). Die im Datenmodell angezeigten Verbindungen bzw. Tripel sind weitestgehend im Virtuoso Store eingetragen und dort in tabellarischer Form über den Conductor mittels SPARQL zu extrahieren. 7

9 feeduri User s own feed dssn:activityfeed User foaf:person foaf:member foaf:member Group 1 foaf:group dssn:activityfeed dssn:subscribedto feeduri dssn:subscriptiontopic baseuri &c=ressource&id=random User s feed for group 1 dssn:activityfeed dssn:subscription rdf:type User has subscribed the group dssn:subscriptionhub pubsubhubbub.appspot.com dssn:subscribedto baseuri &c=push&a=callback dssn:subscriptioncallback Group has subscribed the user feed for this particular group baseuri &c=ressource&id=random feeduri Group s feed dssn:subscription rdf:type User has subscribed the group baseuri &c=push&a=callback dssn:subscriptioncallback dssn:subscriptionhub pubsubhubbub.appspot.com User has subscribed this group Abbildung 9: Datenmodell des Gruppenkonzepts in Xodx Testkonzept Innerhalb des Projekts greifen wir hauptsächlich auf zwei gängige Testkonzepte zurück. Zum einen ist dies PHPUnit, welches zum automatisierten Testen der erweiterten und neu implementierten Klassen dient. Hierzu entwickelt jedes Mitglied, welches an der Implementierung mitwirkt, eine Testklasse, welche das Durchführen automatisierter Tests ermöglicht. Da die zu implementierenden Klassen ihre Operationen jedoch größtenteils im Virtuoso Store durchführen, ist es schwer, hier geeignete Testfälle zu entwickeln. 8

10 Deswegen nutzen wir zusätzlich Selenium, wo wir sich oft wiederholende Testabläufe speichern können um diese im Anschluss daran automatisiert durchführen lassen zu können. Diese sogenannten Stresstests dienen der Simulation möglicher realer Extremsituationen, in denen eine hohe Auslastung auftritt. Da es sich bei unserem Projekt um eine soziale Plattform im Internet handelt, auf welche von überall zugegriffen werden kann, ist ein solcher Test der Performance äußert wichtig. Abseits dieser Testverfahren wird zusätzlich mit Hilfe von Mantis Bug Tracking ein effizientes Fehlermanagement organisiert und jedes Mitglied verfügt unabhängig der laufenden Xodx-Instanz des Praktikums-Servers eine eigene Instanz, lokal laufend auf einer VM. Glossar Triple Store (Virtuoso) Ein Tripel ist die Einheit bestehend aus drei Elementen Subjekt, Prädikat und Objekt. Eine Ressource als Subjekt wird mit einer weiteren Ressource als Prädikat zusammen mit einer dritten Ressource als Objekt näher beschrieben. Das Tripel besteht aus den beiden Enden des Links und der Art des Links und ist somit eine logische Aussage. Die Link-Struktur des Tripels bildet einen gerichteten benannten Graph, welcher die logische Aussage darstellt. Die Graphdatenbank benutzt diese um vernetzte Informationen darzustellen und zu speichern. Linked Data Bezeichnet im WWW Daten, welche frei verfügbar sind und über einen zugehörigen URI direkt via HTTP abgerufen werden können. Zusätzlich besteht die Möglichkeit, auf andere Daten zu verweisen, welche auch über einen URI identifiziert werden. Activity Steam Ein Activity Stream ist eine Liste von aktuellen Aktivitäten (Activities), die ein Individuum (z.b. Person oder Gruppe) innerhalb eines sozialen Netzwerks veröffentlicht hat. Dazu zählen unter anderem Posts, Links und andere Ressourcen. Semantic Pingback Semantic Pingback ist eine, auf die Veröffentlichung von RDF-Ressourcen mit Linked Data angepasste Methode, die es Web-Autoren erlaubt Benachrichtigungen anzufordern, falls jemand eine Ressource verlinkt. DSSN Das DSSN ist eine Architektur eines dezentralisierten semantischen sozialen Netzwerks. Es wurde von der AKSW entwickelt. Quellen Literatur "An Architecture of a Distributed Semantic Social Network" von Sebastian Tramp + et al. ( ) Natanael Arndt (2013): Xodx, Konzeption und Implementierung eines Distributed Semantic Social Network Knotens (Masterarbeit) 9

11 Abbildungsverzeichnis Abbildung 1: Ebenen-Modell des DSSN... 3 Abbildung 2: Klassenmodellierung des Gruppenkonzeptes... 4 Abbildung 3: Liste aller Gruppen... 5 Abbildung 4: Erstellung einer neuen Gruppe... 5 Abbildung 5: Gruppenliste... 5 Abbildung 6: Darstellung der Gruppe (nicht beigetreten) in Xodx... 6 Abbildung 7: Darstellung der Gruppe (beigetreten) in Xodx... 6 Abbildung 8: Sequenzdiagramm des Gruppenkonzeptes... 7 Abbildung 9: Datenmodell des Gruppenkonzepts in Xodx