Modellgetriebene Softwareentwicklung in der Praxis SS13

Aus THM-Wiki
Wechseln zu: Navigation, Suche
Kurs
Kursname Modellgetriebene Softwareentwicklung in der Praxis SS 13
Kurstyp Praktikum
Dozent Priefer
Semester SS 13
Studiengang Master
Link http://homepages.thm.de/~dprf53/lehre.html


Diese Seite dokumentiert die Ergebnisse der Seminare sowie den Fortschritt des Gruppenprojektes.

Zugehörige Wiki-Seiten:

Inhaltsverzeichnis

Kontakt

Moodle [1]

IRC: Quakenet unter #mddp

Seminarergebnisse

Anforderungen an die geplante Web-Anwendung (Social Network)

  • Dennis Voigtländer
  • Michael Mathea
  • Mathias Gutenbrunner

Notes

 Bemerkung: Dieser Text schöpft bei den Möglichkeiten für
 ein Social Network aus dem vollen.
 Aufgrund begrenzter Kapazitäten unserer Veranstaltung sollte er
 keinesfalls als "Pflichtenheft" missverstanden werden.
 Es handelt sich eher um Vorschläge, an denen sich eine Architektur
 orientieren sollte, es ist klar, dass wir letztlich viele Kompromisse
 eingehen werden müssen.
 -
 Der Text sollte als Big Picture und Ideen Steinbruch verstanden werden.
 -
 Er impliziert auch die Anforderung an Modellierungs Sprachen und
 Tools die Erweiterbarkeit und Modularisierbarkeit
 bei der Entwicklung im Blick zu behalten.

Vorüberlegungen

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Social Network

Bei der Analyse der Funktionalität bestehender Social Networks fällt auf, dass deren Funktionsumfang in der Regel nicht über Möglichkeiten hinausgeht, die bereits von bestehenden, standardisierten Internet Technologien abgedeckt werden. Nachrichten können an einen einzigen Empfänger gesendet werden (Äquivalent: Mail) Mitteilungen können an alle Kontakte, Teilmengen der Kontakte oder Mitglieder von Gruppen gesendet werden (Äquivalente: Foren, Verteiler, Newsgroups). Bilder und andere Dateien können einer Teilmenge der Mitglieder des Social Networks (Kontakte / Kreise / Organisationen / Alle Mitglieder des Social Networks (Personen)) oder auch an Nichtmitglieder freigegeben werden (Äquivalente: Dokumenten-Verwaltungs-Systeme, CMS, etc.). Möglichkeiten, die von “alten” Technologien nicht abgedeckt werden, finden sich in der Regel nur in Speziellen Social Networks, in denen der Social Network Aspekt häufig auch in den Hintergrund tritt. (Beispiele: YouTube oder Twitter) Dennoch gibt es eine erstaunliche Anzahl von Menschen, die einem Social Network beitreten und die Analyse der Gründe stellen wir an den Anfang der Anforderungen an Architektur und Erweiterbarkeit.

Gründe für die Entscheidung, ein Social Network zu nutzen

Eine nicht repräsentative Auswertung der Beweggründe, einem Social Network beizutreten ergibt die folgenden Ergebnisse:

  • Auffindbarkeit von Bekannten (Durchsuchbarkeit)
Die Tatsache dass Social Networks die Möglichkeit bieten ihre Mitgliederliste zu durchsuchen um Kontakte wiederzufinden ist ein zentraler Motivationsgrund für viele Nutzer.
  • Aktualisierung und Erhalt von Kontaktinformationen von Bekannten (Adressbuchfunktion)
Da Nutzer ihre Profilinformationen regelmäßig aktualisieren ist es möglich, Änderungen von Adressdaten von Kontakten zu erfahren, über die man ansonsten nicht informiert würde.
Zudem ist es Möglich Kommunikationsmethoden der Social Network Plattform zu verwenden, die erhalten bleiben solange der Kontakt das Social Network nutzt.
  • Möglichkeit den Erhalt von Nachrichten zu Beschränken und so Spam zu vermeiden (Whitelist)
Die Freundschaftsliste eines Social Networks entspricht eine Whitelist, mit dem Vorteil, dass Nutzer die Aufnahme in die Whitelist einfach beantragen können (Freundschaftsanfrage)
  • Zentraler Account und geringe technische Hürde
Ein starkes Argument für den Beitritt zu einem Social Network ist die Tatsache dass dieses im Gegensatz zu den anderen oben genannten, standardisierten Einzeltechnologien über einen zentralen Login zugänglich ist und nur ein minimales technisches Verständnis für die Nutzung vorraussetzt.

Architektur

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Konzeptioneller Überblick
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
FMC Blockdiagramm: Überblick

Die Erkenntnis, dass Standardtechnlogien den Größten Anteil der Funktionalität eines Social Network abdecken können, und dennoch die oben genannten Vorteile eine große Nutzeranzahl überzeugen, führt zu dem Resultat dass eine Social Network implementierung sich auf die Alleinstellungsmerkmale konzentrieren sollte, also Standardisierte Technologien und Verfügbare Software Implementierungen / Frameworks verwenden sollte wo immer dies möglich ist.

Somit sollte der Fokus der Eigenentwicklung auf:

  • Accountverwaltung
  • Rollenverwaltung
  • Kontaktverwaltung
  • Rechteverwaltung

und

  • Durchsuchbarkeit

liegen (funktionaler Kern).

Alle weiteren Funktionalitäten sollten mit vorhandenen Standards und Technologien realisiert werden.

Client Sichten

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Client Sichten

Die meisten Social Networks haben für die Nutzer zu Beginn lediglich ein Web-Frontend bereitgestellt. Auf native Clients wurde aus pragmatischen Gründen verzichtet. Mit der zunehmenden Verbreitung von Smartphones und Tablets erhalten native Clients für Social Networks eine neue Attraktivität, da Web-Frontends in der Regel auf Eigenschaften von klassischen PCs - Große Bildschirme, Bedienung mit Maus oder anderem Pointing Device - optimiert sind. Eine gute Social Network Architektur verzichtet möglichst von vorneherein darauf, die Datenstrukturen auf eine bestimmte Sicht zu optimieren. Optimalerweise sollte eine vollständige Client Unabhängigkeit erreicht werden und ein Protokoll definiert werden das von unterschiedlichsten Clients verwendet werden kann. Somit sollte ein in Joomla integriertes Frontend eine mögliche, aber bei weitem nicht die einzige Sicht auf das Social Network sein.

Web Frontend

Für das Web Frontend sollte verschiedenen Gerätetypen, mit unterschiedlicher Bildschim Größe und unterschiedlichen UI Paradigmen Rechnung getragen werden. Beispielsweise:

  • Smartphones
  • Tablets
  • Desktop PCs mit unterschiedlicher Bildschirm Größe
Native Clients
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Beispiel: Mendeley nativer Desktop Client

Native Clients sollten ein einheitliches Protokoll verwenden. Eine Mögliche Umsetzung wäre es, mithilfe der PHP API von OData eine Web-Protokoll Sicht auf den Funktionalen Kern und die Datenhaltung des Social Network zu generieren, über die dann Clients mit dem Social Network kommunizieren können.

Standard Protocol Views
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Internet Engineering Task Force
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
World Wide Web Consortium

Sehr viele Teilaspekte eines Social Networks lassen sich mit existierenden, standardisierten Protokollen darstellen:

  • Kontaktliste:
    • LDAP (RFC 4511, RFC 2849)
    • CardDAV (RFC 6352)
  • Kalenderdaten:
    • CalDAV (RFC 4791)
  • Nachrichten:
  • Neuigkeiten:
    • Feed Protokolle:
      • Atom
      • RSS
  • Medien Verwaltung:
    • FTP (RFC 959)
    • WebDav (RFC 2518, RFC 4918)
  • Chat:
    • XMPP (RFC 6120, RFC 6121, RFC 3921, RFC 3922, RFC 3923, RFC 6122)
  • Sicht auf Organisationen:
    • Usenet / Netnews Protokolle (RFC 5536, RFC 5537)

Für diese Teilaspekte gäbe es dann bereits ein großes Repartoire an nativen Clients für sehr viele Plattformen/Systeme, ohne dass dafür eine Eigenentwicklung notwendig wäre.

Daten, Strukturen, Entitäten und Beziehungen

Personen

Jeder Nutzer des Social Network wir dort als Person repräsentiert.

Profil

Jede Person hat eine Profilseite. Die Sichtbarkeit von Profilinformationen sollte sich nach den unten folgenden Sichtbarkeitskriterien steuern lassen.

Mitteilungen

Jede Person kann Mitteilungen schreiben. Die Sichtbarkeit der Mitteilungen sollte sich ebenfalls nach den unten aufgeführten Kriterien steuern lassen.

Sichtbarkeitskriterien für Mitteilungen und Profilinformationen
Sichtbarkeitskriterien
  • Sichtbarkeit für Nutzer, die nicht im Social Network angemeldet sind
  • Sichtbarkeit für angemeldete Nutzer
  • Sichtbarkeit für indirekte Kontakte
  • Sichtbarkeit für Kontakte
  • Sichtbarkeit für Kontakte in bestimmten Kreisen
  • Sichtbarkeit für Mitglieder bestimmter Organisationen (Gruppen, Seiten)
  • Sichtbarkeit für Mitglieder bestimmter Organisationen mit einer bestimmten Rolle


Durchsuchbarkeit
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Facebook Personensuche
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
XING Personen Suchmaske

Die Liste der Personen des Social Network kann von Nutzern durchsucht werden.

  • Es sollte die Möglichkeit bestehen, nur von Kontakten oder indirekten Kontakten eines bestimmten Grades oder Mitgliedern bestimmter Organisationen gefunden zu werden. Dies sollte von jedem Nutzer für das eigene Profil individuell konfiguriert werden können.
  • Beliebige Profilfelder sollten als Suchkriterien zur Verfügung stehen
  • Es sollten jedoch nur solche Felder in das Such Ergebnis einfließen, die für den suchenden Nutzer auch freigegeben sind.
Kontakte, Kreise, Indirekte Kontakte
Kontakte

Zwei Personen können in einer Kontaktrelation stehen, wenn dies von beiden Personen bestätigt wurde.

Kreise
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Kreise: Kategorien von Kontakten mit Überschneidungen

Jede Person kann jeden Kontakt einem oder mehreren Kreisen (Kontaktkategorien) zuordnen. Dies kann Konsequenzen für die Sichtbarkeit von:

  • Profilinformationen
  • Mitteilungen

haben. Weiterhin kann dies Einfluss auf die Medien haben mit denen ein Kontakt mit der Person kommunizieren darf, beispielsweise:

  • Erlaubnis Nachrichten zu schreiben
  • Erlaubnis zu chatten
Indirekte Kontakte

Ebenso wie Kontakten oder Kreisen die oben genannten Rechte eingeräumt oder verweigert werden können, kann dies auch mit indirekten Kontakten (Kontakten zweiten oder dritten Grades) geschehen.

Gruppen, Seiten, Organisationen

Social Networks bieten ihren Nutzern oft verschiedene Möglichkeiten an, sich auszutauschen oder zu informieren. Oft kann man konzeptionell zwischen Gruppen und Seiten unterscheiden, wobei Gruppen den Austausch zwischen ihren Mitgliedern ermöglichen sollen, während Seiten ihre Abonenten lediglich informieren ohne ihnen die Möglichkeit der Interaktion zu geben.

Konzept der Organisation

Gruppen und Seiten lassen sich konzeptionell zu Organisationen mit unterschiedlichen Rollen zusammenfassen. Personen können Mitglied in mehreren Organisationen sein, Organisationen haben mehrere Mitglieder. Eine Seite, die lediglich informieren soll wäre nach diesem Verständnis eine Organisation, in der die meisten Mitglieder die Rolle "Abonent" haben, und nur wenige eine andere Rolle wie "Redakteur", "Bürokrat" oder "Moderator". Das Konzept sollte allgemein genug angelegt sein, dass sich auch reale Organisationen wie Redaktionen, Unternehmen, Hochschulen oder Vereine darin abbilden lassen.

Rollen in Organisationen
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Beispiel für Rollen in Organisationen

Eine Person kann bezogen auf eine Organisation eine oder mehrere Rollen innehaben, was sich jedoch nicht auf andere Organisationen auswirkt. John Doe kann somit im Unternehmen U Vorgesetzter von Max Mustermann sein, während Max Mustermann in dem Verein V "Vereinsvorsitzender" ist in dem John Doe lediglich einfaches "Mitglied" ist. Selbstverständlich kann eine Organisation auch rein Virtuell sein - Beispiele wären eine diskussionsgruppe für Funktionale Sprachen oder ein Forum zum Austausch von Kochrezepten. Rollen aus der realen Welt sollten auch Auswirkungen auf die Rechtevergabe in der Social Network Organisation haben. Eine Person mit der Rolle "Personalverantwortlicher" könnte beispielsweise die Rolle von Max Mustermann im Unternehmen U von "Gruppenleiter" zu "Projektleiter" ändern, während der "Abteilungsleiter" die Rolle "Personalverantwortlicher" wieder entziehen kann, wenn ein Mitarbeiter ständig Beförderungen einträgt, die eigentlich gar nicht vorgesehen waren.

Rollen Templates

Da die Anzahl und Variabilität der Rollen in Organisationen beliebig ist, wäre es von Vorteil, wenn ein Set von Rollen-Templates in dem Social Network gibt, aus dem sich durch Modifikation neue Rollen generieren lassen.

Abgeleitete Rollen

Eine weitere Möglichkeit wäre, Rollen von bestehenden Rollen ableiten zu können, so dass nur die Veränderung (Restriktion oder Erweiterung von Rechten) angegeben werden muss. Ändert sich die Ober-Rolle, hat das dann auch Auswirkungen auf die abgeleiteten Rollen.

Visuelle Repräsentation von Organisationen
Beispiel: Bild Marke der Technischen Hochschule Mittelhessen

Folgende Medienelemente sollten zur graphischen Repräsentation von Organisationen hinterlegt werden können:

  • Bild Marke farbig (Vektor Grafik)
  • Bild Marke monochrom (Vektor Grafik)
  • Wort Bild Marke farbig (Vektor Grafik)
  • Wort Bild Marke monochrom (Vektor Grafik)
  • Titel Bild
  • Hintergrund Bild
Naming auf URI Basis

Beispiele:

  • Personen
    • "John Doe"@social.local
    • "Max Mustermann"@social.example.org
  • Organisationen
    • "Functional Languages"@social.local
    • "Alumni"@social.thm.de
  • Unterorganisationen
    • "Functional Languages"@social.local/Scala
    • "Alumni"@social.thm.de/Informatik
  • Beliebige Untergliederung von Organisationen:
    • "Technische Hochschule Mittelhessen"@social.example.org/FB/MNI/WebMedia
    • "Technische Hochschule Mittelhessen"@social.example.org/Verw/PB
    • "Technische Hochschule Mittelhessen"@social.example.org/FB/MNI/VA/MDDP/S13/Tools

Erweiterbarkeit

Sind Authentifizierung und Kontaktliste allgemein genug definiert, sind vielfältige Erweiterungen unter Verwendung von weiteren Standardtechnologien möglich. Denkbar wäre die Erweiterung um Chat Funktonalität auf Basis des XMPP Protokolls, eine Terminverwaltung mit Unterstützung gängiger Kalender Protokolle wie CalDav, die Verfügbarkeit von Adressbuchdaten über entsprechende offene Protokolle, der Abruf von Nachrichten, die über das Social Network verschickt werden per IMAP, POP oder SMTP, der Abruf von Beiträgen in Gruppen und des Streams über Webfeed Protokolle und vieles mehr.

Überlegungen zu Interoperabilität, Dezentralität und Verteiltheit

Durch die Verwendung von Standardisierten Internet Technologien wären bereits viele Vorraussetzungen geschaffen das Social Network zu einer dezentralen Technologie mit mehreren Providern bzw. Servern auszubauen. Die wichtigste Leistung die dafür noch zu erbringen wäre, wäre eine dezentrale Kontaktliste und eine dezentrale Rechteverwaltung. Es handelt sich hierbei jedoch um eine Überlegung für die Zukunft, die nicht notwendigerweise in der aktuellen Veranstaltung umgesetzt werden muss.

Client Screens

In den folgenden Unterkapiteln werden alle Anforderungen beschrieben, die in Bezug auf die Funktionalität eines sozialen Netzwerkes verfügbar sein sollten.

Benutzerkonten-Login und -Logout
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Facebook Login / Register

( Eine grundsätzliche Anforderung an ein soziales Netzwerk, die erfüllt sein muss, bevor ein Benutzerkonto angelegt wird, ist die kostenlose Nutzung der Plattform. Wenn diese Anforderung nicht erfüllt werden würde, wäre es in der heutigen Zeit sehr schwierig, das entsprechende Netzwerk entsprechend zu etablieren. ) Für die Nutzung des sozialen Netzwerkes wird zwischen zwei verschiedenen Nutzergruppen unterschieden, den Administratoren und den Usern.

An die Benutzerkontenverwaltung werden nun folgende Anforderungen gestellt
  • Login:
Beim Login ins Benutzerkonto muss zwischen zwei Fällen differenziert werden:
  • Der User besitzt ein eigenes Benutzerkonto:
In diesem Fall erfolgt eine Anmeldung mit Nutzerkennung und persönlichem Passwort.
  • Der User möchte ein neues Benutzerkonto erstellen:
In diesem Fall muss eine Registrierung des Users erfolgen, bei der alle vom Netzwerk geforderten Daten vom User eingetragen werden müssen (Ein Beispiel, welche Daten hier relevant sein können wird in der PowerPoint-Präsentation angegeben). Im Anschluss gibt der User eine Benutzerkennung und ein persönliches Passwort an. Letztendlich wird die Registrierung mit der Freischaltung des neuen Kontos abgeschlossen.
  • Logout:
Es muss die Möglichkeit eines sicheren Verlassens des eigenen Benutzerkontos durch einen Logout erschaffen werden. Der Sinn davon ist, dass die persönlichen Daten auf dem eigenen Benutzerkonto nicht durch dritte eingesehen oder manipuliert werden können.
  • Mechanismus bei vergessenem Passwort:
Für den Fall, dass ein User sein Passwort vergisst, sollte eine Möglichkeit geschaffen werden, das eigene Passwort angezeigt zu bekommen. Dies darf allerdings nur dann passieren, wenn man eindeutig als Inhaber des Benutzerkontos identifiziert werden kann. Zur Gewährleistung dieser Eindeutigkeit, sollte bei der Registrierung eines Users, benutzerdefiniert eine Sicherheitsfrage mit Antwort festgelegt werden, dessen Antwort nur der Inhaber des Kontos kennt.
Navigationselemente (Leiste)
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Navigationselemente im XING Browser Frontend

Von jedem der vier Hauptfenster aus sollen bestimmte Grundfunktionalitäten verfügbar sein. Realisieren ließe sich dies durch eine Leiste, die permanent, unabhängig von der Ansicht, eingeblendet wird. Zu diesen Grundfunktionalitäten zählen folgende

  • Nachrichten-Screen
  • Verwaltung von Kontakten
  • Verwaltung von Fotos / Medien / Dateien
Aufteilung der Ansicht in vier Hauptfenster mit Fensterfunktionalität

An die Ansicht im Benutzerkonto des sozialen Netzwerkes wird nun die Anforderung gestellt, dass vier verschiedene Hauptfenster verwirklicht werden, zwischen den durch entsprechende Reiter gewechselt werden kann. Außerdem sollen auf den Hauptfenstern bestimmte Funktionalitäten verwirklicht werden.

Neuigkeiten-Screen
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Diaspora* Neuigkeiten Ansicht im Web Frontend
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
XING Neuigkeiten Sicht in nativer iPhone App
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
SAP StreamWork Update Fenster in nativer iPad App

In dieser Ansicht soll man die Möglichkeit bekommen, Nachrichten einem gewissen Kreis an Personen mitzuteilen und zusätzlich auch Nachrichten von einem bestimmten Personenkreis zu lesen. Damit dies möglich wird, muss es ein Nachrichtenfenster geben, in welches die entsprechende Nachricht eingetragen werden kann und zusätzlich dazu ein Absende-Button, mit dem man eine Nachricht an die „Neuigkeits-Ansicht“ schicken kann. Welche Nachrichten man selber in dieser Ansicht sehen kann bzw. wer die eigenen Nachrichten sieht, soll von der Kategorie derjenigen Personen abhängig sein, die jeweils in den benutzerdefinierten Einstellungen angegeben wird. Beispiele für solche Kategorien können sein, dass entweder alle Personen, nur Freunde oder nur sehr gute Freunde entsprechende Nachrichten lesen können. Des Weiteren sollte noch die Funktion des Löschens einer abgeschickten Nachricht verwirklicht werden, sodass derjenige, der eine Nachricht abgeschickt hat, auch in der Lage ist, sie wieder von der Neuigkeiten-Ansicht zu löschen.

Pinnwand

Auf der eigenen Pinnwand sollen sowohl der Inhaber eines Benutzerkontos, als auch andere User Nachrichten eintragen können. Darüber hinaus soll der Inhaber des Kontos jederzeit Nachrichten von seiner Pinnwand löschen können, egal ob er sie selber geschrieben hat oder ein anderer User. Außerdem soll der User, der eine Nachricht auf die Pinnwand eines anderen Users geschrieben hat, diese wieder löschen dürfen. Der Inhaber des Benutzerkontos kann, genau wie in der Neuigkeiten-Ansicht, einstellen, welcher Personenkreis auf die eigene Pinnwand zugreifen darf bzw. für wen sie sichtbar ist. Zusätzlich soll sowohl für die eigene Pinnwand als auch für die Neuigkeiten-Ansicht ein Mechanismus entwickelt werden, der es ermöglicht, seine eigene Meinung zu einem bestimmten Sachverhalt zu äußern. Dies kann zweierlei geschehen, entweder durch einen „Like“-Button (am Beispiel von facebook) oder durch ein Kommentarfeld. Auch hier muss wieder möglich sein diese Meinung zurückzunehmen bzw. zu löschen. Die Regelung, wer berechtigt ist, entsprechende Löschvorgänge vorzunehmen, entspricht der zu Beginn dieses Unterpunktes.

Profilseite
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Google+ Profilsicht im nativen iPad Client

Auf der Profilseite eines Users werden persönliche Informationen zum User veröffentlicht. Nur er selbst hat hier die Möglichkeit bestimmte Informationen zu veröffentlichen bzw. zu löschen. Dies passiert allerdings nicht in dieser Ansicht, sondern in der Bearbeitungs-Ansicht zum eigenen Profil, welche nur dem Inhaber eines Benutzerkontos zugänglich ist. Zugriff auf die Profilseite eines Users hat nur derjenige Personenkreis, welcher vom jeweiligen User als dazu berechtigt bestimmt wird.

  • Folgende Bildelemente sollten zur visuellen Repräsentation des Profils hinterlegt werden können:
    • Profil Bild
    • Titel Bild
    • Hintergrund Bild
Seite zum Bearbeiten des eigenen Profils
Profil Bearbeiten

Wie im vorherigen Absatz beschrieben, können in dieser Ansicht vom Inhaber eines Kontos bestimmte Daten zur eigenen Person eingetragen werden. Diese Daten werden anschließend veröffentlicht. Die Veröffentlichung findet allerdings nur an denjenigen Personenkreis statt, den man in dieser Ansicht als berechtigt einträgt. Ein Beispiel dafür, welche Daten auf der Profilseite eingetragen werden können, ist in der PowerPoint-Präsentation zu finden.

Nachrichten-Screen

Bei dieser Funktionalität soll eine Ansicht geöffnet werden, die zweigeteilt ist. Zum Einen sollen Nachrichten gelesen werden können, die persönlich an einen User gesendet wurden, und somit von keinem anderen User eingesehen werden können. Zum anderen sollen persönliche Nachrichten an einen oder mehrere bestimmte User gesendet werden können, welche schließlich auch nur von dem bzw. den Empfängern gelesen werden können. Dazu ist es notwendig, dass es ein Nachrichtenfenster gibt, in welches die persönliche Nachricht eingetragen werden kann, ein Empfängerfeld, in welches der oder die Empfänger der Nachricht eingetragen werden und ein „Absende“-Button, welcher die jeweilige Nachricht dem bzw. den entsprechenden Empfängern zustellt.

Verwaltung von Kontakten

Auch hinter dieser Funktionalität verbergen sich einige Einzelfunktionalitäten: Es muss ein Suchfenster geben, über welches Freunde gesucht werden können. Es muss ein Button existieren, welcher eine Freundschaftsanfrage an die ausgewählte Person sendet. Es muss durch einen Button die Funktion verwirklicht werden, dass ein User eine an ihn gestellte Freundschaftsanfrage bestätigen kann. Es muss möglich sein Freunde entsprechenden Personenkreisen zuzuordnen. Kategorien hierfür wären: Bekannte, Freunde, sehr gute Freunde, etc.

Verwaltung von Fotos / Medien / Dateien

Diese Funktionalität soll das Hochladen von Fotos auf ein soziales Netzwerk verwirklichen. Dazu wird ein Fenster benötigt, in dem zum Einen der Pfad ausgewählt werden kann, aus dem das Foto hochgeladen wird. Zum Anderen muss ein zweites Fenster vorhanden sein, in dem das Foto, was hochgeladen werden soll, aus der Menge aller Fotos, die unter diesem Pfad gespeichert sind, ausgewählt werden kann. Im Anschluss daran soll es möglich sein ein Album für Fotos anzulegen bzw. Fotos einem Album zuzuweisen.

Für eines der hochgeladenen Fotos soll es möglich sein, dieses als Profilfoto festzulegen. Außerdem sollen je nach Bedürfnis des Users bestimmte Fotos auf Pinnwänden oder der Neuigkeiten-Ansicht eingetragen werden können.

Gruppenverwaltung

Darunter ist zu verstehen, dass User Gruppen beitreten und darüber mit einem ganz persönlich definierten Personenkreis Nachrichten austauschen können, nämlich nur mit den Gruppenmitgliedern. Des weiteren spiegelt jede Gruppe die Interessen eines Users wider.

Event-Manager
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
XING Events

Mit dieser Funktionalität könnten Events (mit Eventtitel, Zeitpunkt & Veranstaltungsort) erstellt und Einladungen zu diesem Event an einen definierten Personenkreis versendet werden. Zusätzlich könnte es eine Art Rückmelde-Mechanismus geben, in dem der Eingeladene angeben kann, ob er die Einladung annimmt und entsprechend würde der Event-Manager zählen, wie viele Teilnehmer die Einladung wahrnehmen.

Optionale Zusatzfunktionen für die Screens

Dieses Unterkapitel fungiert als Ausblick für mögliche zukünftige Funktionalitäten des sozialen Netzwerkes, welches im Rahmen des Moduls Modellgetriebene Software-Entwicklung erschaffen werden soll.

Verlinkungen erstellen

Diese Funktion könnte einerseits URL’s erkennen und als Link sicht- & nutzbar machen. Außerdem könnte man hiermit Personen in Nachrichten auf der Neuigkeiten-Ansicht & Pinnwand oder auf Bildern verlinken.

Automatische Synchronisation der Neuigkeiten-Ansicht

Mit dieser Funktionalität würde sich die Neuigkeiten-Ansicht vollkommen selbstständig synchronisieren, d.h. es würden neue Freundschaftsbeziehungen, Bilder, die hochgeladen wurden und Bilder oder Nachrichten, die auf Pinnwände eingetragen wurden automatisch auf der Neuigkeiten-Ansicht angezeigt werden.

Bewerten und Weiterverbreiten von Beiträgen
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Bewerten und Weiterverbreiten

Es sollten Möglichkeiten vorgesehen werden, Beiträge zu bewerten und weiter zu verbreiten:

  • Like
  • Dislike
  • Rate
  • Vote
  • Reshare
  • Permalinks
  • Tagging durch Leser

Anforderungen an die Sicherheit

Security

Bei den Anforderungen die Sicherheit müssen zu allererst mögliche Angriffsflächen eines Social-Network erörtert werden. Zum einen ist es wichtig, dass jeder Nutzer bestimmen kann, wer seine sensiblen Daten einsehen kann. Außerdem ist es sehr wichtig, dass der Nutzer nicht nur Sicher vor Angriffen von aussen sondern auch von innen ist. Es stellt sich also die Frage wer vor wem geschützt werden muss. Wir kamen zu dem Schluss, dass Nutzerdaten nicht nur vor anderen Nutzern gesichert werden müssen, sondern auch vor dem Provider. Dazu zählen Dinge wie Passwörter oder auch einfache Konversationen über einen Chat.

Anforderungen
  1. Es muss an einer zentralen Stelle, für jeden Kontakt eines Nutzers, eine Rechteverwaltung geben, welche die Einsehbarkeit der Nutzerinformationen für die Kontakte verwaltet.
  2. Nutzer ist verantwortlich für die Rechteverteilung.
  3. Nutzer müssen sich Registrieren und Authentisieren(Ohne Email-Adresse oder logischen Kombinationen wie Vorname, Nachname).
  4. Sichere Passwörter erzwingen.
  5. Einsicht und Bearbeitung von sensiblen Daten müssen zusätzlich abgesichert werden (Erneute Passwortabfrage, Passwörter niemals anzeigen).
  6. Daten, bei denen Ausspähen verhindert werden muss, sind durch Einsatz des SSL-Protokolls zu schützen (Chat, Nutzerkennung).
  7. Session-ID’s dürfen nicht geklaut werden können (Beispielsweise binden der SessionID an die IP-Adresse des Nutzers).
  8. Erkennung von automatisierten Angriffen (Denial of Service Attacken)
  9. Inputfilterung (SQL-Injektion, Filterung möglicherweise durch WebShields)
  10. Weiterleitungen prüfen

Datenschutzbestimmungen

Fehler beim Erstellen des Vorschaubildes: Datei fehlt

Grundsätzlich erfordern Soziale Netzwerke durch ihre größe und Fülle an Informationen, Interessen und Beziehungen von Personen besondere Verantwortung zum Schutz der Daten. Es gilt, eine benutzerfreundliche Lösung bezüglich des Datenschutzes und der Formulierung der Allgemeinen Geschäftsbedingung zu finden.

Anforderungen
  • 1. Einholung von informierten Einwilligungen: Einwilligungen, die gemäß Art. 2 h, 7 a der Richtlinie 46/95/EG Grundlage für die Datenverarbeitung sein sollen.
  • 2 h) "Einwilligung der betroffenen Person" jede Willensbekundung, die ohne Zwang, für den konkreten Fall und in Kenntnis der Sachlage erfolgt und mit der die betroffene Person akzeptiert, daß personenbezogene Daten, die sie betreffen, verarbeitet werden.

Die Mitgliedstaaten sehen vor, daß die Verarbeitung personenbezogener Daten lediglich erfolgen darf, wenn eine der folgenden Voraussetzungen erfuellt ist:

  • 7 a) Die betroffene Person hat ohne jeden Zweifel ihre Einwilligung gegeben;
  • 2. Einholung einer informierten Einwilligung der Nutzerinnen und Nutzer für die Nutzung von Cookies.
  • 3. Löschung von Daten: Unverzügliche und vollständige Löschung von Daten, die Nutzerinnen und Nutzer aus ihren Profilen entfernt haben.
  • 4. Möglichkeit pseudonymer Nutzung.
  • 5. Standardeinstellungen: Datenschutzfreundliche Standardeinstellungen bzgl. Der Sichtbarkeit von Profildaten für Dritte.
  • 6. Möglichkeit der kompletten Abmeldung vom Dienst, so dass die Daten umgehend komplett gelöscht werden und dem Nutzer dieses auch bestätigt wird.
  • 7. Minderjährigenschutz
  • 8. Weitergabe von Daten an Dritte sind zu unterlassen sofern keine Einwilligung existiert.

Implementierungsvorschläge

Implementierungsvorschläge
Neuigkeiten-Ansicht
Vorhandene Erweiterungen für die diskutierten CMS

Für die implementierung einer Neuigkeiten Ansicht, die Beiträge aus Organisationen (Seiten, Gruppen, Foren), und von Kontakten zusammenfasst würde sich ein Feed Aggregator empfehlen, der so verändert werden müsste, dass er alle Feeds, die aus Kontakten und Mitgliedschaften resultieren zusammenfasst.

  • Ein beispiel für Joomla wäre der Google AJAX RSS Reader.
  • Eine Joomla Erweiterung, die auch Atom unterstützt (was bei einer Nutzung von OData Bibliotheken von Vorteil wäre) ist Scroll Feed Display.
  • Aggregator für Drupal bietet ebenfalls feed aggregation, und zwar für RSS, Atom, und RDF.
  • Eine Entsprechung für Typo 3 wäre RSS Aggregator (Unterstützung von RSS und Atom).
Anforderungs Vorschlag

Optional könnte für den Benutzer die Möglichkeit eingerichtet werden nur eine Teilmenge dieser Neuigkeiten anzuzeigen.

Z.B. über
  • Kategorien und
  • Filter
OData Protokoll
OData
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Atom

Eine gute Basis für die einfache Realisierung von Standardkonformen Protokoll-Sichten wäre OData. (Siehe auch die Wikipedia Seite zu OData) Es stehen Bibliotheken für sehr viele Programmiersprachen und Plattformen zur Verfügung, auch eine OData Produzenten (Server) Bibliothek für PHP (OData Producer Library for PHP).

Das Protokoll bietet von Haus aus unterschiedlichste Sichten auf die Daten (SOAP, JSON, ATOM, ... Siehe: OData Dokumentation), was eine enorm flexible Architektur erlauben würde.

Weitere Links:

Fragen

Trennung von Nutzerdaten und Profildaten

Es ist zu überlegen, ob Nutzerdaten möglicherweise vollständig getrennt von Profildaten vorgehalten werden sollten: Personenbezogene Daten wie vollständiger Name, Adresse, Geburtsdatum und Kontonummer eines Nutzers könnten bei kostenpflichtiger Nutzung des Social Network zu erheben sein. Möglicherweise ist aber der Nutzer nicht damit einverstanden, dass diese Daten potenziell in sein Profil eingehen könnten.

Erfassung von Adminstrator Rollen im allgemeinen Rollenkonzept

Es ist zu überlegen, ob ein Social Network ein Backend braucht, oder ob sich Administrator Rollen mit dem oben beschriebenen, allgemeinen Rollenkonzept abdecken lassen.

Betreiben von CMS unabhängiger Serverstruktur
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Extensible Messaging and Presence Protocol (XMPP)
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
XMPP Kommunikation nach RFC 6120

Da PHP basierte CMS einigen Beschränkungen unterliegen wäre zu überlegen ob einige Dienste als seperate Serverstruktur realisiert werden und lediglich eine Client sicht als CMS Erweiterung realisiert wird.

  • Ein Beispiel bei dem sich diese Frage stellt wäre ein integrierter Chat auf XMPP basis. Es gibt einen Open Source Client auf Flash Basis (SparkWeb), und auch eine API auf der er basiert (XIFF API).
Das wäre eine gute Grundlage um daraus eine Chat Erweiterung für ein CMS zu realisieren, aber die Serverseite müsste davon natürlich seperat und CMS unabhängig betrieben werden.
  • Eine ähnliche Frage stellt sich bei 1 zu 1 Nachrichten (Ein Mailserver wäre denkbar - ist aber auch einiges an Aufwand)
Generieren ließen sich für einen Mail Server wohl höchstens Install Scripts und Konfigurations Files
Links
Drei Schichten Architektur?

Wollen wir uns für eine drei Schichten Architektur mit

  • Client Sicht (z.B. Web Frontend)
  • Dienste Sicht (z.B. Nachrichten)
  • und Funktionalem Kern (Authentifizierung, Authorisierung, Rollen, Kontakte, User-/Profildaten)

entscheiden?

Das hätte Konsequenzen für:

  • Referenz Anwendung
  • Wekzeugentwicklung
Option auf Verteiltheit?
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Verteilter Social Network Ansatz

Je mehr ein Social Network auf Standardisierten Internet Technologien aufbaut, desto stärker stellt sich die Frage, ob der Entwurf nicht so gestaltet werden sollte, dass es sich zu einem dezentralen (verteilten) Social Network ausbauen lässt. Das heißt es gäbe mehrere Social Network Provider, deren Server interoperabel sind. Chat, Mail und Feeds würden diese Möglicheit bereits bieten. Die die im Referat als Kern des Social Networks benannten Komponenten:

  • Authentifizierung
  • Authorisierung
  • Rollenmanagement
  • Kontaktverwaltung
  • User- und Profildaten

sollten dann so ausgelegt sein, dass sich Verteiltheit einfach nachrüsten lässt.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Gegenüberstellung: Diaspora* und Facebook (Community Work)

Vorteile wären:

  • Unternehmen können ihren eigenen Social Network Server betreiben. Verlässt beispielsweise ein Recruiter ein Unternehmen nimmt er seine geschäftlichen Kontakte nicht mit.
  • Privatnutzer können ihren Provider nach eigenen Kriterien wie Datenschutz oder Funktionsumfang wählen
  • Hochschulen oder Unternehmen können Kooperationen über das Social Network koordinieren und bleiben Herr ihrer Daten und Mitarbeiter
  • Kleine Social Networks kränkeln oft allein wegen ihrer mangelnden Größe (wenn da niemend ist den man kennt, muss man selber auch nicht beitreten). Durch einen Verteilten Ansatz ließe sich dieser negative Effekt kompensieren.
  • Ein verteilter Social Network Kern bietet auch sonst völlig neue Perspektiven. Szenarien wie ein verteilter Workflow zum bearbeiten von digitalen Medien oder Dokumenten wären langfristig denkbar.
  • Der gedanke des Internets, der auch auf Anwendungsebene dezentrale Architekturen präferiert bliebe gewahrt
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Diaspora*
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
friendica
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
identi.ca
Beispiele für Verteilte Soziale Netzwerke:
Protocol Bridges

Diese Überlegung eher ein Ausblick:

Ein verteiltes Social Network könnte Protokoll Brücken zu anderen verteilten Social Network Standards implementieren:
Weitere Fragen

Weitere Fragen als PDF Datei

Anforderungen an eine MDD-Infrastruktur: Modellierungssprache

  • Markus Bader
  • Daniel Kirsten
  • Jens Mehler

Dieser Abschnitt beschäftigt sich mit den Anforderungen an die Modellierungssprache in Bezug auf die Entwicklung eines Social Networks, stellt verschiedene Sprachen vor und bewertet diese bzgl. der Anforderungen.

Der Text basiert auf unserer Präsentation.

Gliederung

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Kern der Untersuchung: PIM, PSM und Sichten der beteiligten Entwickler

Unterscheidet man in der klassischen Abstraktion noch zwischen CIM, PIM und PSM, so wird das CIM i. d. R. durch eine GPL (General Purpose Language) beschrieben, welche nicht direkt in ein PIM umgewandelt werden kann. Aus diesem Grunde werden für die hier stattfindende Betrachtung der Modellierungssprachen nur die Ebenen PIM und PSM betrachtet.

Von zentraler Relevanz sind hier jedoch das PIM (Platform Independent Model) und das PSM (Platform Specific Model). Es wurde untersucht, was diese Modelle beinhalten müssen, welche Sprachen dies wie effektiv ermöglichen und wie die beiden Ebenen sinnvoll miteinander verwendet werden können (z. B. durch bidirektionale Synchronisation).

Weiterhin spielen die unterschiedlichen Sichten der Werkzeug- und Anwendungsentwickler eine Rolle. Deswegen werden diese zunächst beschrieben, um an die tatsächlichen Anforderungen zu gelangen.

Sicht der Werkzeugentwickler

Zunächst sollte eine Sprache möglichst effektiv sein, d. h. sie sollte einfach sein und bei möglichst vollständigem Funktionsumfang bzw. ausreichender Mächtigkeit einen geringen Overhead haben. Ebenso muss der Workflow zum Generierung und Testen einfach und schnell sein, um die Entwicklung nicht unnötig zu behindern.

Besonders wichtig ist die Unterstützung durch Programme. Durch die modellgetriebene Generierung und die Verwendung unterschiedlicher Technologien werden i. d. R. eine Vielzahl von Artefakten generiert, die evtl. bidirektional synchronisiert werden sollen. Dies spielt insbesondere eine Rolle, wenn die PIM und PSM durch unterschiedliche Technologien verwirklicht werden. Deswegen sollten die Tools zur Unterstützung der Technologien ebenfalls untereinander kompatibel sein.

Sicht der Anwendungsentwickler

Der Anwendungsentwickler, also der "Benutzer" des Modells, muss die von den Werkzeugentwicklern erstellten Modelle und DSL (Domain Specific Language) verwenden. Dazu müssen diese möglichst einfach und intuitiv sein, bei gleichzeitiger Vollständigkeit bzgl. der Anforderungen. Um diese intuitive Bedienbarkeit und eine flache Lernkurve zu ermöglichen, müssen bestimmte Teilaspekte berücksichtigt werden, wie z. B. eine intuitive und lesbare Syntax, Einheitlichkeit und eine knappe und klare Dokumentation.

Ein besonders zu erwähnender Konfliktpunkt ist hierbei eine mögliche Divergenz zwischen der Fachverständlichkeit und der technischen Umsetzbarkeit. So soll ein (Meta-)Modell per Definition so beschrieben werden, dass technische Aspekte zu Gunsten einer guten Verständlichkeit einer fachlichen Person weichen. So kann es aber passieren, dass das Fachmodell sich den technischen Aspekten derart entfremdet, dass bei der weiteren Generierung und Konkretisierung eine technische Umsetzung schwierig bis unmöglich wird. Da in diesem Projekt sowohl Anwendungs- als auch Werkzeugentwickler beide Informatiker sind und alle eng zusammenarbeiten, ist dieser Konflikt vermutlich von geringer Bedeutung. Dennoch muss er ständig überprüft werden.

Inhalte und Anforderungen an PIM

Ein PIM-(Meta-)Modell ist ein plattformunabhängiges Modell, welches später in ein plattformspezifisches Modell (PSM) umgewandelt werden kann. Es hat typischerweise folgende Eigenschaften:

  • generische Beschreibung der Domäne
  • Wiederverwendbarkeit für verschiedene Plattformen
  • Transition in PSM möglich

Gemäß unseren Überlegungen besteht ein PIM-Metamodell im Wesentlichen aus der Beschreibung der Entitäten und der Aktionen/Workflows.

So existieren in einem Social Network beispielsweise die Entitäten:

  • Benutzer
    • Freunde
    • Gruppe
  • Pinnwand
  • Fotoalbum
  • Nachrichten
    • Posts
    • Instant Messaging
    • Chat

Diese werden dann mit sinnvollen Eigenschaften versehen, so dass ein Benutzer beispielsweise einen Benutzernamen, eine E-Mail-Adresse und eine Liste von Freunden hat.

Für diese Entitäten werden weiterhin Aktionen (auch: Workflows, Abläufe) definiert. Für die Aktion "Freund hinzufügen" könnte ein Ablauf in etwa wie folgt aussehen:

  1. Freund suchen
  2. Anfrage senden
  3. Anfrage beantworten
  4. Kontakte bei beiden Benutzern anlegen

Besonders zu beachten sind hierbei die Abhängigkeiten zwischen den beteiligten Entitäten. So könnte diese Aktion z. B. durch die Funktionsrelation add_friend(User x User) → Contact beschrieben werden).

Inhalte und Anforderungen an PSM

Das PSM konkretisiert ein gegebenes PSM auf eine spezifische Plattform, ist in unserem Projekt also CMS-abhängig. Es werden alle Systemspezifika integriert, welche für die Code-Generierung notwendig sind. Im konkreten Fall für das CMS-System Joomla! müssen also z. B. folgende Aspekte beachtet werden:

  • Aufteilung in Erweiterungen (Components, Modules, etc.)
  • Beachtung der Programmlogik (z. B. MVC-Pattern)
  • Anbindung anderer Erweiterungen (z. B. Verwendung und Erweiterung der Benutzerverwaltung)
  • Aufteilung der Workflows in Sichten (welche dann durch MVC implementiert werden)
  • Backing der Entitäten durch Datenbanktabellen und Datenmodelle (MVC-Modells)
  • Einführung von Konfigurationen (bestimmte Dinge können in Joomla! nur durch Konfigurationsdateien umgesetzt werden)

Hierbei muss das Modell derart ausgearbeitet werden, dass direkt und ohne weitere Zwischenlayer Code-Generatoren angebunden werden können. Dazu muss das PSM selbstverständlich kompatibel zu den Generatoren sein.

Sprachen

In diesem Abschnitt sollen verschiedene Sprachen bzw. Modellkonzepte kurz vorgestellt und hinsichtlich der Anforderungen bewertet werden. Dabei weiterhin zur Alternative steht die Entwicklung einer eigenen Sprache.

CMS-ML / -IL
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Übersicht über CMS-ML/-IL

Die Content Management System Modeling Language bzw. CMS Intermediate Language ist eine Sprache, die speziell für das Modellieren von Anwendungen mit CMS entwickelt wurde. Dabei stellt die ML den höheren Abstraktionsgrad auf einem Level mit dem PIM dar, wogegen die IL CMS-spezifisch auf der PSM-Ebene agiert. Die ML kann dabei auch grafisch verwendet werden.

Die saubere Trennung der beiden Modellebenen sowie die Spezialisierung auf CMS macht diese Sprache augenscheinlich sehr geeignet für das Projekt. Als negative Argumente lassen sich aufführen, dass die Sprache ggf. zu viele Funktionen bietet und somit Overhead produziert und dass die Sprache möglicherweise Inkompatibilitäten zu Joomla! aufweist.

SWAL
Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Das Metamodell von SWAL

Die von der Philipps-Universität Marburg entwickelte Simple Web Application Language beschreibt eine Sprache, die speziell auf die typische Struktur von Webanwendungen abbildet. Sie stellt grundsätzlich eine höhere Abstraktionsebene (PIM) dar; für einfache Implementierungen (z. B. direkt auf HTML) sind auch Konkretisierungen möglich.

Die Sprache ist relativ jung und bietet bislang keinerlei Programmunterstützung. Die direkte Integration von CMS ist nicht vorhanden, weswegen man dies manuell modellieren müsste. Aus diesem Grunde ist die Sprache nur für das PIM gut geeignet.

WebML

Die Web Modeling Language ist ähnlich zu SWAL eine Modellierungssprache zur Entwicklung von Webanwendungen. Sie basiert komplett auf UML. Es existiert eine Weiterentwicklung der OMG mit der Bezeichnung IFML.

Mit WebML ist jedoch nur eine Modellierung einzelner Webseiten möglich. Eine Verteilung von Funktionen auf mehrere Komponenten oder gar die Integration eines CMS sind nicht vorgesehen. Deswegen ist diese Sprache für die Zwecke des Projektes ungeeignet.

UWE

Das UML-based Web Engineering basiert namensgebend auf UML und stellt nach dem Selbstverständnis eine leichtgewichtige und weitergehend standardisierte Variante dessen dar. Die Untersuchung zeigte jedoch sehr starke Ähnlichkeiten zu WebML.

Dazu gehören auch die Schwächen. Ein Framework und andere Fremdstrukturen können nicht eingefügt werden. Deswegen ist auch diese Sprache für das Projekt ungeeignet.

Eigene Sprache

Es besteht grundsätzlich die Möglichkeit, eine eigene Sprache zu entwickeln. Dies bring mehrere Vorteile:

  • individuell skalierbar, unnötiger Overhead wird vermieden
  • gute Anpassbarkeit zu anderer Sprache (z. B. zwischen PIM und PSM)
  • jederzeit erweiterbar

Natürlich bedeutet die Entwicklung einer eigenen Sprache immer einen entsprechenden Mehraufwand. Es stellt sich jedoch die Frage, wie groß dieser tatsächlich ist. Auch bei Verwendung einer vorhandenen Sprache benötigt man eine gewisse Einarbeitungszeit, bei einer Eigenentwicklung wird dieser Zeitaufwand für die Entwicklung abgelöst. Gerade eine direkt intuitive Sprache wie Xtext ermöglicht hier eine sehr schnelle Entwicklung.

Die Gruppe ist zu dem Ergebnis gekommen, dass sich das Konstruieren einer eigenen Sprache besonders dann lohnt, wenn die Sprache sehr klein und sehr speziell ist. Dies ist in dem Projekt bei der PSM der Fall. Sie hat eine übersichtliche Größe und wird für die spezielle Anwendung (Umwandeln eines PIM in ein CMS-spezifisches PSM für Joomla!-spezifische Codegeneratoren) benötigt.

Als Werkzeuge kommen aufgrund der Betrachtung und Verwendung in der Vorlesung die Tools Xtext und Ecore/EMF in Frage.

Ergebnis

Nach der Vorstellung der Nachforschungen und einer anschließenden Diskussion im Plenum sind wir zu folgendem Ergebnis gekommen:

  • Geeignet sind CMS-ML/-IL, SWAL und eine eigene Sprache
  • Für das PIM wird SWAL bzw. eine SWAL-ähnliche Sprache benutzt. Die genaue Entscheidung findet während der Praxisphase statt.
  • Für das PSM wird aufgrund der besonderen Anforderungen und schlechten Integration anderer Sprachen eine eigene Sprache für das CMS Joomla! entwickelt. Besonders die Struktur der Erweiterungen unterscheidet sich stark von anderen Konzepten und ist nicht generisch abbildbar.

In Testversuchen und Beispielen wird die Praxistauglichkeit dieses Ansatzes überprüft.

Anforderungen an eine MDD-Infrastruktur: Editor

  • Ilyas Güclü
  • Tobias Hessler
  • Arne Schaprian

Modellierungsschichten

  • Metaebene 1 (PIM)
Abstraktes Modell (Social Network)
Plattformunabhängig
  • Metaebene 2 (PSM)
Plattformspezifisches Modell (Joomla)
  • Instanzebene
Konkrete Instanz (Business Social Network)

Technologien Metaebenen

Xtext
+ generiert viel (Ecore, Parser, Texteditor)
+ untereinander referenzierbar
+ einfache DSL Definition
- u.U. Unübersichtlich
Ecore
+ visuelle Modellierung
+ Baum - Modellierung
- teilweise schlechte Sychronisation zwischen Diagram und Ecore
- Problematisch bei der Darstellung von großen Modellen
- kein Texteditor (Instanzebene)
UML
+ sehr bekannte Modellierungssprache
- nur Baummodellierung
- kein Generator
XML
+ bekannte Modellierungssprache
- komplexe Struktur
- kein Generator

Technologien Instanzebene

GMF / Eugenia
+ visuelle Modelierung
+ intuitiv Bedienbar (Anwendungsentwickler)
- unübersichtlich mit steigender Größe
- komplexer Erstellungsprozess
Textueller Editor (Xtext)
+ Syntaxhighlighting
+ Autocompletion
- abhängig von Xtext
Baumeditor
+ visuelle Modellierung
+ intuitiv Bedienbar (Anwendungsentwickler)
+ einfacher Erstellungsprozess

Unsere Wahl

  • Metaebene 1 (PIM)
Xtext
  • Metaebene 2 (PSM)
Xtext
  • Instanzebene
Textueller Editor / Baumeditor

Anforderungen an eine MDD-Infrastruktur: Generator

  • Eric Hartmann
  • Ivo Senner
  • Patrick Karré

Vortrag: Anforderungen an den Generator

Was macht der Generator

  • erzeugt Verzeichnisstruktur
  • Dateien mit dem Code anhand eines Modells
  • Code besteht aus statischen, dynamischen und wiederkehrenden Codefragmenten
  • erzeugt Tests

Funktionale Anforderungen

  • Generatordesign
    • Unterstützte Plattformen
    • Anwendungsarchitektur
    • Anwendungsdesign
    • Individueller Code
  • Benötigte anwendungsspezifische Informationen
    • Anwendungsfälle
    • Rollen
    • Datenstrukturen
    • Services
    • Darstellung

Nicht-Funktionale Anforderungen

  • Einfaches Einfügen von individuellem Code
  • Gut lesbarer Code
  • Vermeiden von sog. ”code smells”

Codeanalyse

Ermitteln von...

  • Verzeichnisstrukturen
  • statischen Inhalten
  • schematisch wiederkehrenden Inhalten
  • dynamischen Inhalten

Joomla Codeanalyse

Anwendung auf andere CM-Systeme, Vergleich mit anderen Web Frameworks

  • Niklas Simonis
  • Jan Cilius
  • Ilyas Yildiz

Ausarbeitung (PDF): Datei:AnwendungaufandereCMS.pdf

Joomla

Grundlegende Funktionen

Joomla in der Version 2.5 bietet folgende grundlegenden Funktionen, die direkt nach der Installation für Administratoren zur Verfügung stehen:

  • User Manager

Verwaltung von Benutzer des CM-Systems, unterteilt in Guest, Registered, Author, Publisher, Manager, Administrator, Super Administrator.

  • Kategorie Manager

Verwaltung von Kategorien innerhalb des CM-Systems

  • Artikel Manager

Im Artikelmanager können neue Artikel (Content-Seiten) hinzugefügt, bearbeitet und gelöscht werden.

  • Rechtesystem

Joomla bietet ein umfangreiches Rechtesystem, welches mittels einer ACL (Access Control List) realisiert wird. Mit dieser Liste wird festgelegt welcher Benutzer welche Objekte (Dienste oder Dateien) sehen oder arbeiten darf.

  • Menü Manager

Dieser Manager dient zum Bearbeiten der Menüs. Hier können einzelne Menüpunkte angelegt werden oder auch hierarchisch angeordnet werden.

  • Sprach Manager

Der Sprachmanager unterstüzt die Multi-Languagefähigkeit, hier können Sprachen installiert/gelöscht werden oder auch als Standard festgelegt werden.

  • Extension Manager

Mittels des Extension-Managers kann sowohl das System gepflegt werden, d.h. das CM-System auf die neueste Version zu bringen, die Datenbankstruktur aktuell zu halten, als auch zusätzliche Erweiterungen zu verwalten.

  • Media Manager

Der Media Manager dient zur Verwaltung aller Medien die innerhalb des Systems verwendet werden. Zum Beispiel Bilder, Videos oder andere Medien.

Versionierung
  • Joomla

Untersucht wurde Joomla in der Version 2.5.11, die Version 2.5.0 hat LTS (Long Time Support) und wird mind. 5 Jahre unterstüzt. Die Zahl 11 steht für das letzte Sicherheitsupdate, welches am 27 April 2013 erschien.

  • Plattform

Aktuell wird das Framework in der Version 12.1 verwendet. Zu finden ist eine umfangreiche Dokumentation unter http://api.joomla.org/.

Erweiterungstypen
  • Komponenten

Komponenten sind die umfangreichste und komplexeste Art von Erweiterung für das CMS. Die Komponente dient zur Verwaltung der Daten, steuert die Darstellung, bietet Funktionalität und übernimmt Aufgaben, die nicht zu den Grundfunktionen Joomla!-Kern-Anwendung gehören. Üblicherweise werden Komponenten über das Backend gesteuert und können mit Modulen und Plugins zusammenarbeiten. Ebenso verwenden Komponenten üblicherweise MySQL Tabellen.

  • Module

Module sind hingegen weniger umfangreich, sind jedoch flexibler und mehrmals im Seitenlayout verwendbar. Module können sowohl eigenständig sein, aber auch mit Komponenten zusammen arbeiten oder Bestandteil dieser sein. Oftmals werden Module verwendet um Inhalt einer Komponente darzustellen, dabei greift das Modul auf die Tabellen einer Komponente in der Datenbank zu. Die Modul Position lassen sich im Backend im Modul-Manager verwalten.

  • Plugins

Plugins sind ein Stück Programm-Code, die ausgeführt werden, wenn bestimmte Ereignisse auftreten. Mit ihnen lassen sich Programm-Codes über Ereignisse unterschiedlich steuern. Beispielsweise ist ein Editor ein Plugin, dieser wird nur aufgerufen, wenn das Ereignis onGetEditorArea auftritt.

  • Templates

Templates sind für die optische Darstellung zuständig, sprich alles, was mit den eigentlichen Grafiken, Formatierung, Anordnung der Modul Positionen und Inhalt zu tun hat. Joomla! verwendet sowohl für die Frontend- als auch für die Backend Gestaltung Templates. Für die Erstellung solcher Templates sind lediglich HTML, PHP, CSS und JavaScript nötig. Ebenso lassen sich die Templates im Backend verwalten und bearbeiten.

  • Libraries

Eine Bibliothek in Joomla! ist eine Sammlung von Funktionen, die global innerhalb des CMS zur Verfügung stehen, dass heißt mehrere Komponenten können auf diese Funktionen zugreifen und diese verwenden. Externe Bibliotheken können im Installations-Manager installiert werden.

Softwarearchitektur

Hier verwendet Joomla das MVC (Model View Controller) Pattern. (Alle rot markierten Elemtente sind generierbar.)

Struktur Dateiebene - Komponente
Joomla Komponente Root Ordner

Unterteilung der Quellcodedateien in Front- und Backend.

Dabei sind die Namenskonventionen einzuhalten. Der Root-Ordner enthält einen “admin” und “site” Ordner. Ebenso sind die Setup Datei (XML) und ggf. ein externes Installations-Script (PHP) enthalten.

Fehler beim Erstellen des Vorschaubildes: Datei fehlt
Joomla Komponente Admin/Site

Innerhalb der Unterordner ist das MVC Pattern wieder zu erkennen.

  • models
  • views
  • controllers



Zusätzlich gibt es einen übergeordneten Controller und eine Einstiegsdatei. “helpers” enthält Klassen, die von mehreren Sourcefiles verwendet werden. “sql” enthält alle Sourcefiles für die Datenbank, d.h. Installations-Script, Deinstallations-Script und für jede Version eine extra Update-Script.







Joomla Komponente Views
  • Views kann mehrere Unterordner enthalten, für jede View einen separaten Ordner.

Dieser beinhaltet eine “view.html.php”, welche das Template im “tmpl”-Ordner lädt. Hier ist mind immer eine default-Datei enthalten.







Joomla Komponente Controllers
  • Controllers beinhaltet für jede View eine extra

Controller-Klasse, hier ist keine Hierarchie erforderlich.







Joomla Komponente Models
  • Models enthälft für jede View eine Model-Klasse, und lädt

die Daten für die jeweilige View.





In jedem Ordner, egal welche Ebene ist eine “index.html” mit leerem Inhalt zu erzeugen.

Struktur Dateiebene - Modul
Joomla Modul Ordner

Eine Erweiterung vom Typ Modul beinhaltet nur “Frontend”-Quellcode.
Ein Modul enthält mindestens ein Setup-File, eine Einstiegsdatei, einen Sprachordner und einen “tmpl” Ordner mit einem Default-Template.
Alle anderen Ordner und Dateien sind nicht immer notwendig.













Struktur Dateiebene - Plugins
Joomla Plugin Ordner

Ein Plugin beinhaltet ebenso einen Sprachornder, zusätzlich ist ein Setup-File und eine Einstiegsdatei enthalten.
Innerhalb der Einstiegsdatei wird das jeweilige Event definiert, wann das Plugin aktiv wird.






Rechtesystem

Die Access Control List wurde mit Version 2.5 umgestellt und ist nun umfangsreicher. Hier eine kleine Zusammenfassung:

Typ Version 1.5 Version 2.5
Groups 7 feste Gruppen (Public, Registered, Author, Editor, Publisher, Manager, Administrator, Super Administrator Beliebig viele user-definierte Gruppen
User & Groups Ein Benutzer konnte nur einer Gruppe zugeordnet werden. Ein Benutzer kann beliebig vielen Gruppen zugeordnet werden.
Access Levels 3 feste Access Levels (Public, Registered, Special) Beliebig viele user-definierte Access Levels
Access Levels & Groups Beziehung zwischen Gruppen und Access Levels waren fest. Gruppen werden ACLs zugeordnet, Jede Kombination ist möglich.
Datenbankmanagementsystem

Joomla verwendet zur Datenhaltung eine MySQL-Datenbank, dabei kann in der globalen Konfiguration unterschieden werden zwischen MySQL und MySQLi.

Mit PHP5 wurde MySQLi eingeführt. Vorteile sind hier:

  • OOP Zugriff, wodurch arbeiten im Team oder an Fremdprojekten vereinfacht wird.
  • Größere Geschwindigkeit
  • Verbesserte Sicherheit - Verbindung benutzt eine SSH-ähnliche Authentifizierung
  • Binärprotokoll wird verwendet, dadurch stehen mehr Funktionen zur Verfügung und die Verarbeitung ist schneller und effizienter.
  • Keine Standard Verbindung, Prepared Statements erzwingen eine saubere und somit sichere Programmierung
  • Verbesserte Trace- und Debug-Funktionen
  • Multi-Queries werden unterstützt.

Jede Erweiterung (üblicherweise nur Komponenten) besitzt seine eigenen Tabellen mit seiner eigenen spezifischen Struktur.

Links

[| Joomla 2.5 Component Tutorial]

Drupal

Grundlegende Funktionen
  • Verwaltung von "Blocks"
    • Header
    • Sidebar
    • Footer
    • ...
  • Verwaltung von Inhaltstypen
    • Artikel
    • "Basic pages" für statische Inhalte
  • Verwaltung von Menüs
  • Verwaltung von "Taxonomy"
    • Kategorien
    • Tags
  • Verwaltung von Themes
    • visuelle Darstellung der Seiten
    • Farben
    • Anordnung
  • Verwaltung von Benutzern
    • Benutzer anlegen und bearbeiten
    • Rechte vergeben
  • Verwaltung von Modulen
  • globale Einstellungen
Erweiterungstypen

In Drupal gibt es Erweiterungen nur in Form von Modulen, die im Backend installiert und hinzugeschaltet werden können.

Softwarearchitektur
  • einfache Struktur, daher sehr übersichtlich
  • Grundfunktionen in "includes" (*.inc)
  • Themes und deren Templates in "themes"
  • Erweiterungen in Form von Modulen
    • zu finden im Verzeichnis "modules"
    • pro Modul genau ein Verzeichnis
    • API-Funktionen und Templates in separate Dateien ausgelagert
Struktur Dateiebene - Modul
Drupal Root Ordner

In Drupal werden alle Extensions in den “modules” Ordner installiert.
Jeder Erweiterung enthält dort seinen eigenen Ordner.
Dieser enthält dann wieder um alle Quelldateien.



Drupal Module Ordner

Eine Extension enhält immer folgende Dateien, dabei ist die Namensgebung (Naming Conventions) zu beachten.

  • extension.admin.inc
  • extension.info
  • extension.install
  • extension.module



Ebenso könne Dateien wie

  • CSS Files
  • API Files
  • JavaScript-Files
  • Template-Files
  • Page-Files

vorhanden sein.



Innerhalb der Quelldateien gibt es zahlreiche Funktionen die sich auch an die Namensgebung halten müssen.
Hier haben wir die zwingend erforderlichen Dateien untersucht.



Drupal Install File
Drupal Info File
  • Install Datei

Hier sind die Standard Funktionen zu erkennen, sowie für jede Version eine update-Funktion inklusive Versionsnummer.

  • Info Datei

Die Info-File enthält alle wichtigen Informationen bzgl. einer Erweiterung.

  • Module Datei

Enthält alle Funktionen die im Frontend verfügbar sind.

  • Admin Datei

Enthält alle Funktionen die für einen Administrator zur Verfügung stehen.







Rechtesystem
  • komplexes Rechtesystem
    • Rollen anlegen, Berechtigungen zuweisen
    • Benutzer anlegen, Rollen zuweisen
    • vorgegebene Rollen: anonymer Benutzer, authentisierter Benutzer
    • weitere Rollen können beliebig angelegt werden
  • Vergabe der Berechtigungen sehr fein granular möglich
    • geordnet nach Modulen
Datenbankmanagementsystem
  • MySQL, PostgreSQL
  • verhältnismäßig viele Tabellen
  • Größenordnung vergleichbar mit Joomla
  • zusätzliche cache-Tabellen für diverse Funktionen

Jedes Modul kann Daten aus beliebigen Datenbanktabellen beziehen. Die Namensgebung hier spielt keine Rolle. Üblicherweise enthält eine Tabelle die speziell zu einer Extentsion gehört aber den Namen.

Links

[| Drupal Coding Standards - Naming Conventions]

WordPress

Typo 3

Ergebnis

Projektverlauf

Werkzeug-Entwicklung

Teamleitung: Ivo Senner, Eric Hartmann


Die Dokumentation zum Projektverlauf ist unter Modellgetriebene Softwareentwicklung in der Praxis Werkzeugentwicklung zu finden.

Anwendungs-Entwicklung

Die Dokumentation ist unter dieser Seite zu finden.