Konzeption und Implementation einer Multimedia Datenbank ...softlang/SchensErwinBScThesis.pdf ·...

Fachbereich 4: Informatik

Konzeption und Implementation

einer Multimedia Datenbank

mithilfe von Megamodellierung

Bachelorarbeit

zur Erlangung des Grades

Bachelor of Science

im Studiengang Informatik

vorgelegt von

Erwin Schens

Erstbetreuer: Prof. Dr. R. Lämmel, Institut für Informatik, FachbereichInformatik, Universität Koblenz-LandauZweitbetreuer: Dipl.-Inform. J. Freiling, TUTORize GmbHWeiterer Betreuer: A. Varanovich, Institut für Informatik, FachbereichInformatik, Universität Koblenz-Landau

Koblenz, im August 2014

Kurzfassung

Die TUTORize GmbH bietet ein Lernmanagementsystem an, mit dem Personalgeschult werden kann. Schulungen erfolgen über eine Weboberfläche und bestehenaus verschiedenen Kapiteln, welche in einzelne Lernelemente unterteilt sind. Lern-elemente können Videos, Audios, Dokumente, Webinare, SCORM Schulungen alsauch Quizzes sein. Dabei kann ein Schulungsersteller seinen Kurs nach Beliebenzusammenstellen und zum Lernen bereitstellen. Die einzelnen Lernelemente müs-sen manuell hochgeladen werden. Dies ist nicht nur bei größeren und komplexeraufgebauten Schulungen zeitaufwändig, es können auch Duplikate auftreten. Umdies zu vermeiden und den Schulungserstellern eine bessere Bedienbarkeit sowieeine gesteigerte Produktivität zu ermöglichen, entwickelt die TUTORize GmbH ei-ne Multimedia Datenbank. Die Multimedia Datenbank soll als ein Webservice zurVerfügung stehen damit auch externe Systeme diese anbinden können. Durch eineVielzahl von verwendeten Technologien wird die Multimedia Datenbank zu einemkomplexen und großen Softwareprojekt. Wenn ein Softwareprojekt größer wird soleidet nicht nur die Wartbarkeit sondern es wird auch zunehmend schwieriger neueTechnologien einzubinden und den Einsatz der bereits vorhandenen Technologienzu validieren. Diese Validierung soll durch Megamodelle erfolgen. Megamodelleentwickeltes sich aus dem Model Driven Engineering und abstrahieren ein Systemauf einer hohen Ebene. Diese Abstraktion kann für ein besseres Verständnis desSystems genutzt werden und ermöglicht Softwareentwicklern Systeme wartbarer zumachen. Diese Ausarbeitung beschäftigt sich mit der Implementation einer Multi-media Datenbank sowie deren Megamodellierung und der Anwendung von diesenMegamodellen durch die Softwaresprache MegaL.

2

Abstract

The TUTORize GmbH offers a Learn-Mangagement-System to educate and trainemployees at small and large companies. Employees can be trained through web-based tutorials. Every tutorial has many sections and every section can containmany section elements. A section element can be a Video, Audio, Image, Docu-ment, Web Based Training, SCORM or a Quiz. The creator of these tutorials needsto upload his media and wait for it to be processed. These waiting times can belong if a big media is uploaded and processed. To reduce time and increase pro-ductivity the TUTORize GmbH wants to offer a multimedia database to managemedia files and to support tutorial creators by offering them a powerful tool tomanage their content. The Multimedia Database will be a web-based service andis available to third party companies who want to implement this tool into theirown system. If a software project becomes large it is hard to verify existing tech-nologies and to implement new technologies into the system. To counter this issuemegamodeling will be used to model the multimedia database at a very high level.Megamodeling originated from Model Driven Engineering and is used to modelcomplex and big systems to get a better understanding about them. This thesisis about implementing a multimedia database which is tightly coupled with theLearning-Management-System from the TUTORize GmbH and to verify the imple-mentation and technologies with megamodels. These megamodels will be appliedto the project through the software language MegaL.

3

Erklärung

Ich versichere, dass ich die vorliegende Arbeit selbständig verfasst und keine an-deren als die angegebenen Quellen und Hilfsmittel benutzt habe und dass dieArbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vor-gelegen hat und von dieser als Teil einer Prüfungsleistung angenommen wurde.Alle Ausführungen, die wörtlich oder sinngemäß übernommen wurden, sind alssolche gekennzeichnet. Die Vereinbarung der Arbeitsgruppe für Studien- und Ab-schlussarbeiten habe ich gelesen und anerkannt, insbesondere die Regelung desNutzungsrechts.

Mit der Einstellung dieser Arbeit in die Bibliothek bin ich einver-standen.

ja � nein �

Der Veröffentlichung dieser Arbeit im Internet stimme ich zu. ja � nein �

Koblenz, den 6. August 2014

Inhaltsverzeichnis

1 Einleitung 91.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.2 Aufbau der Arbeit . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3 Verwandte Arbeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2 Grundlagen 122.1 Multimedia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

2.1.1 Audio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.1.2 Bilder . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.3 Video . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.1.4 Text . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.2 Multimedia Datenbanken . . . . . . . . . . . . . . . . . . . . . . . . 142.2.1 Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.2 Eigenschaften . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2.3 Einsatzgebiete von MMDBMS . . . . . . . . . . . . . . . . . 172.2.4 NoSQL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

2.3 Megamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192.3.1 Model Driven Engineering . . . . . . . . . . . . . . . . . . . 192.3.2 Megamodellierung . . . . . . . . . . . . . . . . . . . . . . . 202.3.3 MegaL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.4 Sonstige . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222.4.1 Representational State Transfer . . . . . . . . . . . . . . . . 222.4.2 MVC-Muster . . . . . . . . . . . . . . . . . . . . . . . . . . 25

3 Konzept 263.1 Multimedia Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.1.1 Systemvision . . . . . . . . . . . . . . . . . . . . . . . . . . 263.1.2 Anforderungsliste . . . . . . . . . . . . . . . . . . . . . . . . 283.1.3 Systemarchitektur . . . . . . . . . . . . . . . . . . . . . . . . 293.1.4 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313.1.5 Integration ins TUTORize Business Solutions System . . . . 32

4

INHALTSVERZEICHNIS 5

3.2 Megamodellierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.1 MVC-Muster . . . . . . . . . . . . . . . . . . . . . . . . . . 333.2.2 Ruby on Rails . . . . . . . . . . . . . . . . . . . . . . . . . . 343.2.3 Ruby on Rails Projekstruktur . . . . . . . . . . . . . . . . . 353.2.4 Request und Response . . . . . . . . . . . . . . . . . . . . . 35

4 Implementation 384.1 Frameworks und Technologien . . . . . . . . . . . . . . . . . . . . . 38

4.1.1 MongoDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 384.1.2 Rails . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.3 Sidekiq . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.4 Carrierwave . . . . . . . . . . . . . . . . . . . . . . . . . . . 404.1.5 FFMPEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Multimedia Datenbank . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.1 Ressourcen . . . . . . . . . . . . . . . . . . . . . . . . . . . 414.2.2 REST API . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2.3 Verarbeitung von Multimedia . . . . . . . . . . . . . . . . . 434.2.4 Ausliefern von Multimedia . . . . . . . . . . . . . . . . . . . 444.2.5 Integration ins TUTORize Business Solutions System . . . . 44

4.3 MegaL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 454.3.1 Bitbucket als neuer Provider . . . . . . . . . . . . . . . . . . 454.3.2 Evaluator für Request und Response . . . . . . . . . . . . . 454.3.3 Anwenden der Megamodelle . . . . . . . . . . . . . . . . . . 47

5 Fazit 50

6 Ausblick 54

A 55

Tabellenverzeichnis

3.1 HTTP Endpunkte für die Ressource Mediaelement . . . . . . . . . 313.2 HTTP Endpunkte für die Ressource Mediaversion . . . . . . . . . . 323.3 HTTP Endpunkte für die Ressource Media . . . . . . . . . . . . . . 323.4 HTTP Endpunkte um Medien auszuliefern . . . . . . . . . . . . . . 32

4.1 Projektmetriken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

5.1 Umsetzung der funktionalen Anforderungen . . . . . . . . . . . . . 525.2 Umsetzung der nicht funktionalen Anforderungen . . . . . . . . . . 53

6

Abbildungsverzeichnis

2.1 Systematische Audiokategorisierung [Lu00] . . . . . . . . . . . . . . 132.2 Model Driven Engineering Modell nach [MKUW04] . . . . . . . . . 192.3 Vorgang um Megamodelle in MegaL anzuwenden [LV14] . . . . . . 23

3.1 Komponenten der Multimedia Datenbank . . . . . . . . . . . . . . . 303.2 Datenmodell der MMDB . . . . . . . . . . . . . . . . . . . . . . . . 303.3 Ruby on Rails Megamodell [LSAS14] . . . . . . . . . . . . . . . . . 34

A.1 Megamodell von MDE [FN04] . . . . . . . . . . . . . . . . . . . . . 56A.2 Komplettes Ruby on Rails Megamodell [LSAS14] . . . . . . . . . . 57A.3 Ruby on Rails Megamodell Projektstruktur [LSAS14] . . . . . . . . 57A.4 MVC-Muster Megamodell [LSAS14] . . . . . . . . . . . . . . . . . . 58A.5 Ruby on Rails Megamodell Request und Response [LSAS14] . . . . 58A.6 TUTORize Media Solutions verwendete Gems . . . . . . . . . . . . 59A.7 Multimedia Datenbank Komponenten Megamodell . . . . . . . . . . 59A.8 Sequenzdiagramm zur Medienverarbeitung . . . . . . . . . . . . . . 60A.9 Sequenzdiagramm zur Ausliefern von Medien . . . . . . . . . . . . . 60A.10 Mockup um Medienelemente anzeigen . . . . . . . . . . . . . . . . . 61A.11 Mockup - Anzeigen eines Medienelementes . . . . . . . . . . . . . . 62A.12 Mockup - Neue Version erstellen . . . . . . . . . . . . . . . . . . . . 63A.13 Mockup - Versionen anzuzeigen . . . . . . . . . . . . . . . . . . . . 64A.14 Implementation - Element auswählen . . . . . . . . . . . . . . . . . 64A.15 Implementation - Neues Element anlegen . . . . . . . . . . . . . . . 65A.16 Implementation - Versions Vorschau . . . . . . . . . . . . . . . . . . 65A.17 Implementation - Medienversionen anzeigen . . . . . . . . . . . . . 66

7

Listings

4.1 Mongoid Modul um Klassen über Mongoid zu persistieren . . . . . 414.2 Mongoid Felddeklaration . . . . . . . . . . . . . . . . . . . . . . . . 414.3 Kommandozeilen-Tool Befehl für eine HTTP Anfrage . . . . . . . . 424.4 REST API Authentifikationsmethode . . . . . . . . . . . . . . . . . 424.5 REST API Authentifikationsmethode 2 . . . . . . . . . . . . . . . . 434.6 Konfigurationsdatei mit Zugangsdaten für ein Repository . . . . . . 454.7 Serialisierte Routes . . . . . . . . . . . . . . . . . . . . . . . . . . . 464.8 Extrahierte Fragmente aus den Controllern . . . . . . . . . . . . . . 464.9 Serialisierter Request und Response . . . . . . . . . . . . . . . . . . 474.10 MegaL Events der Projektstruktur - Entities . . . . . . . . . . . . . 484.11 MegaL Events der Projektstruktur - Relationships . . . . . . . . . . 484.12 MegaL Events - Request und Response . . . . . . . . . . . . . . . . 49

8

Kapitel 1

Einleitung

1.1 Motivation

Die TUTORize GmbH stellt ein Lernmanagementsystem zur Verfügung um Per-sonal in Unternehmen mithilfe von Medien auszubilden. Dieses Lernmanagement-system bildet den technischen Kern einer komplexen Webbasierten E-LearningInfrastruktur. Es handelt sich dabei um eine auf einem Webserver installierte Soft-ware, die Lernmedien und deren Nutzung unterstützt und Instrumente für daskooperative Arbeiten bereitstellt. Mit wachsenden Benutzerzahlen erhöhen sichdie eingesetzten Medien und somit auch der benötigte Speicherplatz. Viele dieserMedien sind Duplikate oder zu großen Teilen identisch zu bereits vorhandenen Me-dien. Schulungsersteller müssen deshalb bei größeren Schulungen darauf achten dassich keine Elemente wiederholen. Probleme bereitet nicht nur das Austauschen mitanderen Schulungserstellern sondern auch die effiziente Suche nach Medien. Diesewerden bissher nur über Metadaten wie Titel und Beschreibung gesucht und nichtüber deren Inhalt. Um diese Probleme zu lösen soll eine Multimedia Datenbankzum Einsatz kommen. Mithilfe einer Multimedia Datenbank müssen Schulungs-ersteller nicht mehr eigene Lernmedien hochladen, sondern können direkt in derdieser nach bestimmten Inhalten und Medien suchen. Dies soll die Qualität derenstehenden Schulungen als auch die Produktivität der Schulungsersteller fördern.Multimedia Datenbanken eignen sich gut um Lerninhalte zu verwalten und zuanalysieren [Jal01]. Die Multimedia Datenbank ist ein Webservice, welcher vie-le verschiedene Technologien und Entwurfsmuster verwendet. Um den korrektenEinsatz dieser Technologien und Entwurfsmuster zu verifizieren, werden Megamo-delle auf das Projekt angewendet. Megamodelle sollen dem Zweck dienen, diesesProjekt und die eingesetzten Technologien zu visualisieren und damit ein besse-res Verständis zu schaffen. Zudem soll auch die Megamodellierungssprache MegaLzum Einsatz kommen und sowohl die Entwicklung als auch den Entwurf der Mul-

9

KAPITEL 1. EINLEITUNG 10

timedia Datenbank unterstützen. Dazu soll die Funktionalität von MegaL getestetund gegebenenfalls erweitert werden.

1.2 Aufbau der Arbeit

Die Arbeit ist in vier Kapitel unterteilt. Im Kapitel 2 werden die Grundlagen vonMultimedia, Multimediadatenbanken, Megamodellierung und Webservices behan-delt. Das Kapitel 2 soll ein Grundverständnis und eine gemeinsame Wissensbasisüber die Arbeit geben. Kapitel 3 behandelt das Softwarekonzept zur TUTORizeMultimedia Datenbank sowie die Megamodellierung von den verwendeten Tech-nologien und der Multimedia Datenbank. Zum Softwarekonzept gehören die Sy-stemvision, Anforderungsliste sowie die Systemarchitektur. Die Megamodellierungzeigt die Verwendung und den Aufbau des Webframeworks Ruby on Rails sowieeine Anfrage an einen Webservice, welcher ein MVC Muster realisiert. Das Kapitel4 beschäftigt sich mit der Umsetzung der Multimedia Datenbank. Dabei wird dieImplementation der Komponenten wie sie im Kapitel 3 beschrieben sind gezeigt.Im letzten Teil des Kapitels 3 wird die Erweiterung der Megamodellierungsspra-che MegaL durch einen neuen Provider als auch durch die Evaluierung einer neuenBeziehung gezeigt. Das Kapitel 5 besteht aus einem persönlichen Fazit zu der Im-plementation der Multimedia Datenbank und der Anwendung von Megamodellendurch die Megamodellierungssprache MegaL. Im letzten Kapitel 6 wird sowohl einAusblick auf die Weiterentwicklung der Multimedia Datenbank als auch der vonMegaL gegeben.

1.3 Verwandte Arbeiten

Es wird eine Multimedia Datenbank konzipiert und implementiert. Diese soll dieEigenschaften umsetzen, die in [Lu00] beschrieben sind. Softwarearchitekturen vonMultimedia Datenbanken werden sowohl in [Jal01], [Lu00] als auch in [SK00] be-schrieben. Eine Kerneigenschaft ist die inhaltsbasierte Suche von Multimedia istund implementiert werden. Inhaltsbasierte Suchalgorithmen und Verfahren werdenin [I.S05] beschrieben. Dabei soll der Inhalt einer Suchanfrage systematisch analy-siert und aus dem extrahierten Wissen die passende Datei gefunden werden. DieAnalyse von Medien hängt dabei von der Art des Mediums ab. Medien können Au-dios, Videos, Bilder, Text sowie andere Dokumente sein. Jede Art benötigt eine an-dere Analysemethode. Analysemethoden von Medien werden in [Lu00] beschrieben.Die implementierte Multimedia Datenbank soll im Anschluss durch Megamodelleverifiziert und beschrieben werden. Megamodellierung und die damit verbundenMegamodelle beschreiben ein System auf einer hohen Abstraktionsebene. Dabei

KAPITEL 1. EINLEITUNG 11

werden Metamodelle, Modelle sowie Fragmente von einem System mithilfe von de-finierten Beziehungen in Verbindung gebracht [BJRV05]. Megamodelle wie sie in[LZ13a] und [FLV12] definiert werden sind Graphische Modelle, die über Knotenund Kanten verfügen. Knoten sind Komponenten eines Systems, die durch Bezie-hungen verbunden werden um ein hohes abstraktes Verständnis zu bekommen. DieMegamodellierung entwickelte sich aus dem Model Driven Engineering und ist so-mit eine Erweiterung zu traditionellen Modellen der Softwareentwicklung [FN04].Das anwenden der graphischen Megamodelle erfolgt mithilfe der SoftwarespracheMegaL. MegaL wird in [LZ13b] sowie in [LV14] beschrieben. Die SoftwarespracheMegaL wurde aus den theoretischen Arbeiten der Megamodellierung entwickeltwelche in [FN04] sowie [Fav05] beschrieben sind. MegaL verfügt über ein Typsy-stem sowie ein Verfolgbarkeitsmechanismus mit dem es möglich ist zuvor abstraktmodellierte Entitäten auf konkrete Elemente in einem System zurückzuführen. Dasumgesetzte Typsystem von MegaL orientiert sich an [JSB12] und [JK06]. MegaLverlässt sich dabei auf Webressourcen, die über HTTP zur Verfügung stehen wiein [LV14] beschrieben und geht in die Richtung von Linked Data.

Kapitel 2

Grundlagen

Dieses Kapitel soll eine gemeinsame Wissensbasis sowie notwendige Grundlagenschaffen für das Verständnis der Arbeit. Das Grundlagen Kapitel unterteilt sichin vier Abschnitte. Der erste Abschnitt 2.1 erklärt die Multimediatypen Audio,Video, Bilder und Text. Im Abschnitt 2.2 werden Multimedia Datenbanken de-finiert sowie deren Eigenschaften und Funktionsweisen. Der dritte Abschnitt 2.3beschäftigt sich mit Model Driven Engineering, Megamodellierung und der Mega-modellierungssprache MegaL. Zuletzt wird im Abschnitt 2.4.1 eine Definition vonREST gegeben und das Entwurfsmuster Model-View-Controller 2.4.2 erläutert.

2.1 Multimedia

Dieser Abschnitt behandelt verschiedene Typen von Multimedia. Es werden dieMultimediatypen Audio, Video, Bilder und Text erklärt. Die Multimedia Daten-bank soll in der Lage sein diese zu verarbeiten und zu unterstützen.

2.1.1 Audio

Audio ist eine Störung im Luftdruck, welche das menschliche Ohr wahrnimmt. Die-se Störung muss in einem Frequenzbereich zwischen 20 und 20000 Hz liegen, damitsie wahrgenommen wird [Lu00]. Audios bestehen aus vielen Fragmenten, welcheals Samples bezeichnet werden. Samples werden zu einer Sequenz zusammengefügtum so eine Audiospur zu erstellen. Das menschliche Gehör kann zwischen verschie-denen Kategorien von Audios unterscheiden und in die zwei Kategorien Sprechenoder Musik einordnen. Eine Kategorisierung kann systematisch erfolgen und wirdin Abbildung 2.1 dargestellt. Dabei werden die Eigenschaften Centroid, Silenceratio und Zero cross tolerance benutzt um eine Kategorisierung durchzuführen.

12

KAPITEL 2. GRUNDLAGEN 13

High centroid? High silence ratio?High ZCR

variabilit?

Audio inputNo Yes Yes

NoNoYes

Music Music Solo music

Speech

Abbildung 2.1: Systematische Audiokategorisierung [Lu00]

Centroid ist ein Maß um ein Frequenzspektrum zu charakterisieren und findet inder digitalen Signalverarbeitung Einsatz. Sie gibt an, wo sich der Mittelpunktdes Spektrums befindet.

Silence ratio bezeichnet das Verhältnis von Stille zu hörbaren Geräuschen. Stil-le wird definiert als die absolute Amplitude, welche unter einem gewissenGrenzwert liegt. Die Silence ratio ist das Verhältnis zwischen der Summevon Stille zu der gesamten Länge des Audios.

Zero cross tolerance (ZCR) ist der Wert, der zeigt, wie oft sich die Frequenzvom positiven in den negativen Bereich verändert.

2.1.2 Bilder

Digitale Bilder bestehen aus vielen kleinen Punkten. Diese Punkte werden Pixeloder Picture-elements genannt. Ein Bild besteht aus einer festen Anzahl von Pixelnund ist zweidimensional, besteht somit aus einer Horizontalen und einer VertikalenAchse. Somit ergibt sich die Gesamtanzahl der Pixel durch das Produkt von Ver-tikalen und Horizontalen Pixeln. Ein Pixel wird durch eine bestimmte Bitanzahlgespeichert. Eine höhere Bitanzahl ermöglicht feinere Abstufungen im Farbraum.Ein Schwarz-Weiß-Bild besteht aus einem Farbraum, welcher mit acht Bit kodiertist. Pixel haben dabei unterschiedliche Helligkeitsintesitäten. Bei einem Schwarz-Weiß-Bild ist 0 schwarz und 256 weiß. Farbe kann erzeugt werden, indem mehrereEbenen mit den Farbkanälen Rot, Grün und Blau hintereinander gelegt werdenund somit eine Farbmischung entsteht [Lu00].

2.1.3 Video

Ein Video ist eine Sequenz von Bildern, welches bei einer konstanten Rate abge-spielt wird. Das menschliche Auge empfindet ein Video erst ab 25 Bildern pro


Sekunde als flüssig. Videos werden im Internet oft benutzt um Inhalte auszutau-schen oder zum kommunizieren. Dabei muss eine Kompression des digitalen Videosstattfinden, um die Netzwerklast zu reduzieren. Moderne Webbrowser unterstüt-zen verschiedene Formate von Videos. Ein Format bezeichnet ein enkodiertes Videomit einem Codec. Codecs sind Algorithmen zum Enkodieren und Dekodieren vonVideos in ein bestimmtes Format um eine Kompression zu erreichen. [Lu00]

2.1.4 Text

Ein Text ist die Aneinanderreihung von alphanumerischen Zeichen. Die am weite-sten verbreitete Repräsentation von alphanumerischen Zeichen ist der AmericanStandard Code for Information Interchange (ASCII). Dabei werden acht Bits fürjedes Zeichen zum Speichern verwendet. Sieben davon beschreiben das darzustellen-de Zeichen und das achte ist ein Paritätsbit. Texte sind strukturiert und bestehenaus einem Titel, Kapiteln und Paragraphen. Obwohl Texte keinen großen Speicher-bedarf haben, ist es wünschenswert diesen zu komprimieren. Text kann verlustfreikomprimiert werden. Die Komprimierung nutzt dabei die Eigenschaft aus, dassbestimmte Zeichen öfter vorkommen als andere. Texte können durchsucht werden.Bekannte Tools zum Durchsuchen von Dateien auf UNIX Betriebssystemen sindgrep und awk. Diese Tools verwenden eingegebene Suchmuster um eine Datei zudurchsuchen. Dabei wird die Datei komplett durchsucht bis eine Übereinstimmungmit dem vorgegebenen Muster gefunden wird. Im schlechtesten Fall wird somit diekomplette Datei durchsucht.

2.2 Multimedia Datenbanken

Dieser Abschnitt beschäftigt sich mit Multimedia Datenbanken sowie mit NoSQL.Es wird in 2.2.1 der Begriff einer Multimedia Datenbank definiert sowie in 2.2.2die Eigenschaften. In 2.2.3 werden Einsatzgebiete von Multimedia Datenbankenmotiviert. Weil die zu implementierende Multimedia Datenbank keine relationa-le Datenbank benutzt, sondern eine objektorientierte um Daten zu persistent zuhalten, wird in 2.2.4 NoSQL erklärt.

2.2.1 Definition

Multimedia Datenbank Management Systeme (kurz MMDBMS) sind hochperfor-mante Datenbanksysteme, welche Multimediadaten verarbeiten und speichern. DieVerarbeitung ermöglicht es, Fakten zu extrahieren und Medien zu analysieren. Fak-ten sind inhaltsbasierte Objekte wie Stimmen, Farben, Strukturen und Personen.


Weitere Fakten, die aus Metadaten gewonnen werden sind unter anderem Auf-nahmedatum, Aufnahmeort, Ersteller, Dauer sowie der Farbraum. Ein MMDBMSwird über folgende Punkte definiert [SK00].

1. Unterstützung für verschiedene Arten von Multimedia. Dabei müssen Multi-mediadateien als Typ erkannt werden. Typen werden definiert als.

Type = Structure+Operations (2.1)

Somit muss ein erkanntes Medium eine definierte Datenstruktur haben aufder gewisse Operationen durchgeführt werden können.

2. Unterstützung für hoch performanten, kostengünstigen und ausreichend großenSpeicherplatz.

3. Ein MMDBMS muss die aufgelisteten Datenbankeigenschaften aufweisen.

DatabaseCapabilities = Persistance+ (2.2)

Transactions+ (2.3)

ConcurrencyControl+ (2.4)

Recovery+ (2.5)

Querying+ (2.6)

V ersioning+ (2.7)

Integrity+ (2.8)

Security+ (2.9)

Performance (2.10)

Diese werden in 2.2.2 beschrieben.

4. Informationen sollen aus Medien extrahiert werden. Dieser Vorgang wird alsInformation Retrieval bezeichnet.

2.2.2 Eigenschaften

Multimedia Datenbank Management Systeme weisen die Datenbankeigenschaftenauf, wie sie in der Definition 3 aufgelistet werden [SK00].

Persistance (Persistenz) ist die Eigenschaft Objekte persistent abzuspeichern.In MMDBMS ist Persistenz die Eigenschaft Multimedia Dateien auf derFestplatte abzuspeichern. Dabei müssen nicht nur die Dateien abgespeichertwerden, sondern auch die damit verbundenen Metadaten und extrahiertenFakten.


Transactions (Transaktionen) sind Sequenzen von Anweisungen welche ausge-führt werden. Sie sind atomar und führen die Datenbank von einem Zustandin einen neuen Zustand.

Concurrency Control (Nebenläufigkeit) ermöglicht den parallelen Zugriff aufdie Datenbank. Transaktionen werden nacheinander ausgeführt und es wirdzwischen Lese- und Schreibtransaktionen unterschieden. Lesetransaktionenkönnen parallel ausgeführt werden ohne die Datenbank in einen inkonsisten-ten Zustand zu führen. Schreibtransaktionen müssen sequenziell ausgeführtwerden, da sonst Nebeneffekte auftreten und die Datenbank in einen inkon-sistenten Zustand gelangt.

Recovery (Wiederherstellung) ist die Eigenschaft, die dem MMDBMS ermög-licht fehlerhafte oder nur Teilweise durchgeführte Transaktionen vollständigzurückzurollen (Rollback). Es wird zwischen drei Arten von Fehlern unter-schieden, welche eine Transaktion scheitern lassen. Diese sind Transaktions-fehler, Systemfehler und Multimediafehler.

Querying (Abfrage) ist das Abfragen von Informationen aus einer Datenbank.Dabei können Ergebnisse dieser Abfrage Objekte oder relationale Mengensein. Der Benutzer spezifiziert dabei in einer definierten Abfragesprache, waser erwartet.

Versioning (Versionierung) erlaubt es Daten welche viele Änderungen durch-laufen und damit verschieden Zustände zu einer bestimmten Zeit haben dieseZustände wieder beliebig wieder herzustellen.

Integrity (Integrität) bezeichnet die Eigenschaft einer Datenbank, von einemkonsistenten Zustand in einen anderen konsistenten Zustand zu gelangen.Ein konsistenter Zustand besteht aus Daten, welche zu einem gegebenenSchema valide sind.

Security (Sicherheit) erlaubt es verschiedenen Benutzern, den Zugang zu derDatenbank zu restriktiveren. Restriktionen können dabei Lese- und Schreib-zugriffe auf bestimmte Datensätze sein sowie eine Authentifikation, um dieDatenbank zu benutzen.

Performance (Performanz) ist die Anforderung an eine Datenbank, perfor-mant und effizient zu sein. Performanz bedeutet das Lese- und Schreibtrans-aktionen effizient und zeitnah ausgeführt werden.


Information Retrieval

Information Retrieval ist das Beschaffen von Informationen aus einer Datenbank[Lu00]. Dabei unterscheiden sich Datenbanksysteme zu Information-Retrieval-Systemenin der Art wie Zugriffe auf Daten erfolgen. Eine Datenbankabfrage spezifiziert ei-ne Suche nach Daten anhand exakt formulierter Bedingungen, wie das folgendeSQL-Beispiel zeigt.s e l e c t ISBNfrom Buchwhere T i t e l = "Multimedia−Datenbanken"

Eine Suchanfrage in einem Information-Retrieval-System hingegen ist in der Regelunpräzise formuliert, wie das folgende Beispiel zeigt.Finde a l l e Text Dokumente , d i e das Thema"Multimedia−Datenbanken" haben .

Eine Multimedia Datenbank kombiniert die Konzepte von Datenbanken und vonInformation-Retrieval-Systemen. Ein Information-Retrieval-System wird bei derVerwaltung von schwach strukturierten Daten verwendet. Schwach strukturierteDaten sind Medien, da der Inhalt von diesen Medien nur schlecht direkt erschlossenwerden kann [I.S05].

2.2.3 Einsatzgebiete von MMDBMS

Einsatzgebiete von MMDBMS sind Systeme, bei denen Medien verwaltet werdensollen. Eine Verwaltung beinhaltet die Indexierung und Suche von Medien. EinMMDMS ist dann wichtig, wenn viele Mediendaten verwaltet werden sollen undzeitgleich viele externe Anwendungen auf demselben Datenbestand arbeiten sollen.Eine Anwendung von einem MMDBMS lässt sich klassifizieren.

statische Anwendung: Diese Anwendungen zeichnen sich durch einen hohenAnteil von lesenden Zugriffen im Vergleich zu Änderungszugriffen auf dieMultimedia Datenbank aus.

dynamische Anwendung: Bei den dynamischen Anwendungen wird die Multi-media Datenbank häufig modifiziert.

passive Anwendung: In diesen Anwendungen geht die Initiative von der Anwen-dung aus, das MMDMBS spielt dabei eine passive Rolle, indem es nur aufAufforderung reagiert.


aktive Anwendung: In einer aktiven Anwendung übernimmt das MMDBMS dieaktive Rolle und zwingt die Anwendung in eine passive Rolle.

Retrieval Anwendung: In solchen Anwendungen wird zur Realisierung von in-haltsbasierten Suchanforderungen spezielle Retrieval-Funktionalität benötigt.

Standard-Datenbankanwendung: Für diese Anwendung reichen zur Suche dieAnfragesprachen von gewöhnlichen Datenbanksystemen aus.

Diese Unterscheidung ist wichtig, da viele Anwendungen zwar eine Verwaltung vonMediendaten, aber keine inhaltsbasierte Suche benötigen. In diesem Fall brauchtdas Datenbanksystem keine Retrieval Komponente zur Verfügung zu stellen [I.S05].

2.2.4 NoSQL

NoSQL (Not Only SQL) sind Datenbanken, welche kein SQL (Structured QueryLanguage) benutzen und keine festen Schemata benötigen. Das Prinzip von NoS-QL Systemen ist die horizontale Skalierung und Partitionierung über viele Server.NoSQL Systeme unterstützen viele einfache Lese- und Schreiboperationen pro Se-kunde. NoSQL Systeme folgen dem Prinzip von BASE. BASE ist ein Akronymfür Basically Available, Soft state and Eventually consistent. Somit steht diesesPrinzip im Gegensatz zu dem Prinzip von relationalen Datenbanksystemen. Diesefolgen dem Prinzip von ACID. ACID ist ein Akronym für Atomicity, Consistency,Isolation, Durability. NoSQL Systeme sind durch das BASE-Prinzip flexibler inder Gestaltung ihrer Datenstrukturen [RA13].

Key-Value: Daten werden in der Form Schlüssel zu Wert gespeichert. JederSchlüssel muss einzigartig sein weil diese dazu benutzt werden um den as-sozierten Wert zu beziehen. Die Abfragegeschwindigkeit dieser Datenbankenist schneller als die einer relationalen Datenbank.

Column-oriented: In einer spaltenorientierten (column-oriented) Datenbank wer-den Daten als Spalten in derselben Datei abgespeichert, die dann Column-families genannt werden. Diese Art der Datenbank wird oft bei leseintensivenAnwendungen eingesetzt.

Document: Diese sind den Key-Value Datenbanken ähnlich. Der Wert wird ent-weder im JSON oder im XML-Format abgespeichert. Es wird bei Anwen-dungen benutzt, bei denen sich das Datenmodell gelegentlich ändert wie beiCRM (Customer Relationship Management System).

Graph: Graph Datenbanken benutzen Graphstrukturen mit Knoten, Kanten undEigenschaften. Graph Datenbanken werden oft bei sozialen Netzwerken ein-gesetzt.


Model Metamodel Platform

Mapping MappingFunction MappingRule

is_captured_in

application_of

describes

1..*

targetsource

1..* 10..1 1..* 0..1

targetsource

1..* 1..*

1

Abbildung 2.2: Model Driven Engineering Modell nach [MKUW04]

2.3 Megamodellierung

Dieser Abschnitt befasst sich mit den Grundlagen von Model Driven Engineering,Megamodellierung sowie der Megamodellierungssprache MegaL. Im Teil 2.3.1 wirdModel Driven Engineering definiert. Danach wird im Teil 2.3.2 Megamodellierungdefiniert. Im letzten Teil 2.3.3 wird die Megamodellierungssprache MegaL erklärt.

2.3.1 Model Driven Engineering

Model Driven Engineering (oft auch Model Driven Development) ist ein Oberbe-griff der es Entwicklern ermöglicht, Funktionalitäten sowie die Architektur voneinem System abstrakt zu modellieren. Aus diesen Modellen kann lauffähige Soft-ware erzeugt oder generiert werden [AK03]. Beim Model Driven Engineering istalles ein Modell [Fav04b]. Modelle sind vereinfachte Abbildungen von Systemenmit dem Ziel Fragen zu diesem zu beantworten [Fav04b]. Modelle müssen nach[KWB03] eine Beschreibung eines Systems sein und in einer wohldefinierten Spra-che sein. Eine wohldefinierte Sprache hat eine wohldefinierte Syntax und Semantikwelche von einem Computer interpretiert werden kann. Somit kann Model DrivenEngineering sich selbst über ein Modell beschreiben (Abbildung 2.2).

Abbildung 2.2 zeigt die wesentlichen Konzepte von Model Driven Engineering.Dieses Modell ist nach [Fav04b] nicht vollständig und definiert Model Driven En-gineering nicht präzise genug. Wenn Systeme größer und komplexer werden, sokann Abbildung 2.2 diese nicht mehr präzise und abstrakt genug darstellen. Esexistieren laut diesem Modell keine Meta-Metamodelle und Metamodelle könnenkeine Modelle an sich mehr sein [Fav04b]. Im folgenden Abschnitt wird auf diesesProblem eingegangen und es werden Megamodelle eingeführt.


2.3.2 Megamodellierung

Megamodellierung und die damit verbundenen Megamodelle werden durch zwei un-terschiedliche Ansätze definiert. Der erste Ansatz von Jean-Marie Favre bezeichnetMegamodelle als ein Modell von Model Driven Engineering [Fav04a]. Der andereAnsatz bezeichnet ein Megamodell als ein Modell, welches andere Modelle oderMetamodelle verwaltet und registriert [JB04]. Der Ansatz, der in dieser Ausarbei-tung verwendet wird, ist der von Jean-Marie Favre. Somit ist ein Megamodell eineMenge von Entitäten und Relationen, welche Aspekte des MDE modeliert [Fav04a].Somit zielt dieser Ansatz der Megamodellierung darauf ab, komplexe Softwarepro-zesse zu veranschaulichen ohne sich dabei in technologische Details zu vertiefen.Megamodelle sind Modelle, welche Metamodelle, Grammatiken, Transformationensowie weitere Softwarekomponenten enthalten [LZ13a]. Ein Megamodell ist einGraph mit Knoten und Kanten. Knoten können dabei Programme, Grammatiken,Schemata sowie abstrakte Modelle sein. Kanten verbinden diese Knoten mit ei-ner Beziehung. Ein Megamodell für Model Driven Engineering zeigt AbbildungA.1. Dabei steht das System als ganzes im Mittelpunkt und wird über Relationenmodelliert.

DecomposedIn ist die Relation, welche ein System in kleinere Subsysteme zerlegt[FN04]. Eine Zerlegung erfolgt durch die Anwendung dieser Relation aufein Tupel. Folgendes Beispiel aus [FN04] verdeutlicht die Zerlegung einesSystems, bestehend aus dem Tupel (0011,1101).

(0011, 1101)δ1101 (2.11)

Es wird ausgedrückt, dass 1101 ein Teil des Gesamtsystems (0011,1101) ist.

RepresentationOf beschreibt, dass ein Modell selbst ein System sein kann. So-mit können Systeme weiter abstrahiert werden [FN04]. Folgendes Beispielverdeutlicht diese Relation. Das Tupel (0011,1101) repräsentiert ein System.Dieses System kann auch eine Dezimale representation sein (3, 14). Somitkönnen wir folgendes ausdrücken.

(0011, 1101)µ(3, 14) (2.12)

ConformsTo beschreibt das ein Modell einem Metamodell entsprechen muss. Die-se Relation hat verschiedene Bedeutungen, je nach der eingesetzten Techno-logie [FN04]. Bei XML-Schemas müssen XML-Dateien diesem Schema ent-sprechen.

ElementOf beschreibt, dass ein Teil eines Systems ein Element eines anderenSystems ist.


IsTransformedIn beschreibt den Vorgang der Umwandlung von einem Systemin ein anderes System. Das folgende Beispiel zeigt die Anwendung dieserRelation.

1τ2 (2.13)

Die 1 wird zu einer 2 transformiert. Dabei übernimmt die 1 die Quelle und die2 das Ziel. Genau dasselbe kann auch auf Programme angewendet werden.Wenn p1 ein Programm ist und p2 ein anderes Programm so können wirsagen das p2 eine transformation von p1 ist.

2.3.3 MegaL

MegaL ist eine einheitliche Megamodellierungssprache, vorgeschlagen von Favre,Lämmel und Varanovich in [FLV12]. In MegaL werden Komponenten von Syste-men als Entitäten dargestellt und diese mithilfe von Beziehungen verbunden. DaMegaL über ein Typsystem verfügt, haben die modellierten Komponenten immereinen konkreten Typen. Typen sind immer Subtypen von Entity [LV14].Die folgen-den Entitäten werden von MegaL vordefiniert.

Set < Entity - Ein Set ist eine mathematische Menge.

Artifact < Entity - Physikalisch vorhandene Entitäten wie Dateien oder Ordner.

Language < Set - Sprachen die eine Menge von Zeichenketten bilden.

Technology < Entity - Konzeptionelle Entitäten.

Concept < Entity - Konzepte die als eine abstrakte Entität behandelt werden.

File < Artifact - Eine physikalisch vorhandene Datei.

Folder < Artifact - Ein physikalisch vorhandener Ordner.

Function < Entity - Eine Entität die eine bestimmte Funktion darstellt.

FunctionApplication < Entity - Die anwendung einer Funktion.

Die definierten Entitäten werden mithilfe von Beziehungen verbunden. In Me-gaL haben Beziehungen ein Typsystem. Dabei besteht der Typ einer Beziehungaus der Verbindung von zwei Entitäten.

elementOf < Entity * Set - Eine Entität ist Teil einer Menge.

partOf < Entity * Entity - Eine Entität beinhaltet eine andere Entität.


conformsTo < Artifact * Artifact - Konformität zu einem bestimmten Metamo-dell.

defines < Artifact * Entity - Ein konkretes Artefakt definiert eine Entität. AlsBeispiel wäre eine Grammatik definiert eine Sprache.

inputOf < Entity * FunctionApplication - Die Entität die als Eingabe für eineFunktionsanwendung benutzt wird.

outputOf < Entity * FunctionApplication - Die Ausgabeentität die aus einerFunktionsanwendung stammt.

Die definierten Entitäten und Beziehungen können benutzt werden um Megamo-delle aufzustellen und diese anzuwenden. Dabei muss die Interpretation von dendefinierten Megamodellen von MegaL aus erfolgen. Bei der Interpretation durchMegaL werden die definierten Megamodelle aufgelöst zu definierten Ressourcen.Die Beziehungen zwischen den aufgelösten Entitäten erfolgt dabei durch Evaluato-ren. Ein Evaluator ist dabei ein Programm das versucht die Beziehung zu beweisenund dabei eine Verfolgbarkeit (Traceability) aufbaut. Der Vorgang wie MegaL einMegamodell anwendet wird in der Abbildung 2.3 dargestellt. Dabei wird ein ge-gebenes Megamodell geparsed und es wird auf gültige Syntax geprüft. Im zweitenSchritt werden die Konfigurationen hinzugenommen und geparsed sowie externePlugins geladen die zum Analysieren benötigt werden. Beim Auflösen des Megamo-dells werden alle Entitäten im definierten Megamodell mit Ressourcen verbundenund werden danach evaluiert. Die Evaluation wird von den Evaluatoren durchge-führt die mithilfe von gegebenen Ressourcen versuchen die Beziehung zwischenzwei Entitäten nachzuweisen. Dabei werden Aktionen und Vorgänge von einemEventrecorder aufgezeichnet und zu einem Report am Ende zusammengefasst.

2.4 Sonstige

2.4.1 Representational State Transfer

Representational State Transfer (kurz REST) bezeichnet den Architekturstil ei-nes Webservices. Bei REST stehen Resourcen im Vordergrund. REST ist in denBereich ROA (Ressource Oriented Architecture) einzuordnen. Der Architekturstilwurde erstmals im Jahre 2000 von Roy Thomas Fielding in seiner Dissertationmit dem Titel Architectural Styles and the Design of Network-based Software Ar-chitectures [Fie00] definiert. Der Fokus dieser Architektur liegt auf Skalierbarkeit,Erweiterbarkeit und Interoperabilität. Folgende Bedingungen liegen einer RESTful-Architektur zugrunde.


Megamodel Configuration Plugins Resources

Parse Extend Analyze Resolve Evaluate

event bus

Event recorderReport

parses parseslo

adsinvokes

links

to

invokes uses

eventseventsevents

Abbildung 2.3: Vorgang um Megamodelle in MegaL anzuwenden [LV14]

Client-Server: Durch Kapselung von Client und Server können diese getrenntvoneinander entwickelt werden. Der Server fällt schlanker aus und gewinntan Skalierbarkeit.

Stateless: Mit Stateless bzw. Zustandslosigkeit ist nicht gemeint, dass Client undServer ihren Zustand nicht wechseln dürfen. Allerdings muss jede Operationin sich abgeschlossen sein. Dies birgt mehrere Vorteile. Die API wird klarund deutlich gehalten und es muss nicht aus dem Kontext ermittelt werden,was eine Anfrage bedeutet. Außerdem können Links auf Ressourcen ohneWeiteres gesichert und wieder verwendet werden. Zustandslosigkeit wirkt sichauch in Verbindung mit Caching positiv auf Stabilität und Skalierbarkeit aus,da keine seperaten Sitzungsdaten benötigt werden.

Caching: Das Caching selbst senkt die Latenz und das aufkommende Datenvolu-men.

Uniform Interface: Eine zentrale Rolle nimmt das Schlüsselwort Uniform Inter-face ein. REST ist eine ressourcenorientierte Architektur und steht damit imGegensatz zu den meisten Implementierungen aus dem Bereich SOA. Umsich durch Ressourcen zu navigieren, wird ein schlankes Interface gefordert.Im Kontext von HTTP steht Uniform Interface für die HTTP-MethodenGET, POST, PUT, PATCH und DELETE.


Layered System: Mit Layered System wird ein geschichteter, modularer Aufbaugefordert, der bei der Wartung, Wiederverwendbarkeit und Erweiterbarkeitdient.

Code on Demand: Code on Demand dient einer stärkeren Entkopplung von Cli-ent und Server. Code kann je nach Bedarf auf den Client ausgelagert werden.

Der zentrale Aspekt von REST ist die Forderung nach einer gemeinsamen Schnitt-stelle. Um dieser Forderung nachzukommen, stützt sich REST auf folgende Ele-mente.

1. Eindeutig identifizierbare Ressourcen

2. URIs bzw. Verknüpfungen

3. Standard HTML Funktionen

4. Verschiedene Repräsentationen der Ressourcen

Ressourcen

REST ist ressourcenzentriert. Mit dem Abfragen, Erstellen, Bearbeiten und Lö-schen von Ressourcen wechselt der Client seinen Zustand. Ressourcen sind dieGrundbausteine einer RESTful API. Eine Ressource muss addressierbar sein undkann mehrere Repräsentationen haben.

Repräsentationen

Zu jeder Ressource gehört mindestens eine Repräsentation. Ein Browser z.B. wirdvon einem Webservice sicherlich ein HTML Dokument anfordern, um die Res-source vernünftig darstellen zu können, während eine App z.B. XML oder JSONverwenden würde. Das eigentliche Auswählen der Media Types sollte allerdingsnicht per Parameter, sondern mittels Content Negotiation erfolgen. Content Nego-tiation ist die Art der Repräsentation die ein Client anfordert. Dies geschieht imHTTP-Header. Dazu muss das Attribut Accept mit dem entsprechenden MIME-Typ hinzugefügt werden.

Funktionen

Auf die mittels URI adressierbaren Ressourcen wird mit generischen Funktionen zu-gegriffen. Mit GET können Repräsentationen angefragt werden. Mit POST könnenRessourcen erstellt, mit PUT verändert und mit DELETE gelöscht werden. DenFunktionen werden die Attribute Idempotenz und Sicherheit zugeordnet [RR07].Eine Operation gilt als sicher, wenn sie aufgerufen werden kann, ohne den Zustand


einer Ressource zu ändern. Ein Beispiel für eine sichere Operation ist GET. Res-sourcen, welche mit GET angefordert werden, dürfen nicht verändert werden. DE-LETE ist nicht sicher, da damit Ressourcen gelöscht werden können. IdempotenteOperationen erbringen immer dasselbe Resultat, egal wie oft sie hintereinanderaufgerufen werden. PUT ist idempotent. POST ist weder idempotent noch sicher.

2.4.2 MVC-Muster

Das MVC-Muster ist ein Softwaredesignmuster welches aus drei Objekten besteht.Diese Objekte sind Model, View und Controller. Jedes dieser Objekte ist für einespezielle Aufgabe vorgesehen [Bur92].

Model (dt. Modell) bildet die Datenstruktur sowie die Geschäftslogik einer An-wendung ab die das MVC-Muster umsetzt. Das Modell ist von der View unddem Controller unabhängig. Eine Änderung im Modell wird meistens durcheinen Beobachter an den Controller weitergegeben.

View (dt. Präsentation) ist die Darstellungsschicht des Systems. Die View ist fürdie Darstellung des Modells sowie für die Entgegennahme von Benutzerinter-aktionen verantwortlich.

Controller (dt. Steuerung) ist für die Verwaltung der Präsentation zuständigund nimmt Benutzereingaben von der Präsentation entgegen und verarbeitetdiese. Ebenfalls ist der Controller zuständig für Präsentationsänderungenwenn sich das Modell verändert.

Kapitel 3

Konzept

Dieses Kapitel beschreibt das Softwarekonzept der Multimedia Datenbank sowiedie Megamodellierung der eingesetzten Technologien. In 3.1 wird die Systemvision,Anforderungsliste, Systemarchitektur sowie das Konzept zur REST API beschrie-ben. Der zweite Teil 3.2 stellt Megamodelle für das Webframework Ruby on Railsauf und setzt diese in MegaL um.

3.1 Multimedia Datenbank

Dieser Abschnitt befasst sich mit dem Konzept der Multimedia Datenbank. DerAbschnitt ist in fünf Teile unterteilt. In Teil 3.1.1 wird die Systemvision der Multi-media Datenbank beschrieben. Der zweite Teil ist die Anforderungsliste 3.1.2. Imdritten Teil 3.1.3 dieses Abschnittes wird die Systemarchitektur beschrieben. Dervierte Teil 3.1.4 beschäftigt sich mit dem Konzept der REST API für die Multime-dia Datenbank. Der letzte und fünfte Teil 3.1.5 ist das Konzept von der Integrationins TUTORize Business Solutions System.

3.1.1 Systemvision

Das Produkt, das entwickelt werden soll, ist eine Multimedia Datenbank mit demNamen TUTORize Media Solutions (kurz TMS). Diese ist an das TUTORize Busi-ness Solutions System (kurz TBS) angebunden und eng gekoppelt. Im TMS Systemkönnen Medien verschiedener Art gespeichert und verwaltet werden. Medien sinddabei Videos, Audios, Bilder und Texte. Beim einfügen von neuen Medien werdendiese analysiert. Die Analysemethode ist variiert bei den Medienarten und liefertverschiedene Fakten für deren Inhalt. Die Analyse und Faktenextraktion eines Vi-deos besteht aus einem Audiofingerabdruck und einer inhaltsbasierten Erkennenvon Objekten. Die erkannten Objekte werden als Zusatzinformation zu dem Video

26

KAPITEL 3. KONZEPT 27

abgespeichert und können dabei Farben, Personen und Gegenstände sein. Ein Au-diofingerabruck wird ebenfalls als Metainformation zu dem Video abgespeichert.Dieser Fingerabdruck wird dafür verwendet, das Video über eine Audiosuche zufinden. Audios haben ebenfalls einen Fingerabdruck in ihren Metainformationenund werden in die Kategorie Sprechen oder Musik eingeordnet. Die Kategorisierungzusammen mit dem Fingerabdruck soll für eine inhaltssuche benutzt werden. AuchBilder werden analysiert und darauf erkannter Inhalt wird als Metainformation ab-gespeichert. Inhalte können hierbei Personen, Gegenstände und Farben sein. Textewerden hinsichtlich der Anzahl der Wörter als auch des Inhaltes analysiert. DerAdministrator hat zusätzlich noch die möglichkeit, Inhalte mit Schlagwörtern zuversehen. Schlagworte geben den analysierten Medien Zusatzinformationen Ã1

4ber

deren Inhalt. Medien können über eine intelligente Inhaltssuche schnell gefundenwerden. Da Inhalt sich über die Zeit verändert, müssen sich auch die vorhandenenMedien im TMS die Möglichkeit haben sich zu verändern. Dazu sollen Medienversionierbar sein. Jedes Medium bildet eine Version und kann mehrere Unter-versionen besitzen. Jede Unterversion enthält die veränderten Daten gegenüberseiner Elternversion. Wenn eine bestimmte Version abgerufen wird, so soll das Me-dium aus seinen verschiedenen Versionen vom TMS wieder zusammengesetzt undausgeliefert werden. Da MongoDB Dokumente nur eine bestimmte Größe habenkönnen, sind Medien, die diese Größe überschreiten, zerkleinert und stückweise ab-gespeichert. Das Ausliefern dieser Medien soll durch das TMS bereitgestellt werden.Medien werden dabei aus der MongoDB wieder zusammengesetzt und ausgeliefert.Falls nur ein bestimmter Abschnitt des Mediums gefordert wird, so liefert dieMongoDB nur diesen Abschnitt aus. Es werden nur die Daten ausgeliefert, diezu diesem Zeitpunkt für die Wiedergabe benötigt werden. Das TBS bindet dasTMS über eine REST API an. Dabei verfügt das TMS über eine Lizenzverwal-tung, welche den Zugriff restriktiveren kann. Restriktionen beinhalten Lese-oderSchreibrechte für Benutzer auf bestimmte Medien. Das TMS kann komplett überdas TBS konfigurierbar sein. Durch die enge Kopplung der beiden Systeme istes möglich, Schulungskurse schnell und einfach zu erstellen, ohne Medien hoch-zuladen. Bei der Schulungserstellung soll der Zugriff auf das TMS möglich sein.Dabei kann der Schulungsersteller Medien durch eine inhaltsbasierte Suche findenkönnen, und als Schulungselement zur Verfügung stellen. Wenn ein gewünschtesMedium gefunden wurde, so kann entweder die aktuellste Version übernommenwerden oder alte Versionen. Der Versionsverlauf soll dabei dem Schulungserstellerso einfach wie möglich dargestellt werden.


3.1.2 Anforderungsliste

Funktionale Anforderungen

1. Eine REST API für die Multimedia Datenbank muss implementiert werden.

2. Die implementierte REST API in der Multimedia Datenbank muss die ver-fügbaren Ressourcen als XML und JSON repräsentation anbieten.

3. Ressourcen müssen über die REST API erstellt, bearbeitet, gelöscht undangezeigt werden.

4. Ein Zugriff auf eine Ressource muss erst nach einer Authentifikation erfolgen.Zugriffe sind dabei lesende oder schreibende.

5. Eine Authentifikation muss über einen Zugangsschlüssel und dem passendenAccount erfolgen. Der Zugangsschlüssel wird dabei zufallsmäßig generiertund ist einzigartig für jeden Klienten.

6. Medien müssen in der MongoDB abgespeichert und abgerufen werden. Zumabspeichern von großen Medien muss GridFS benutzt werden.

7. Die REST API muss das Erstellen von Medien die den Medientypen Video,Audio, Bilder und Text haben unterstützen.

8. Eine Faktextraktion von Medien die über die REST API erstellt worden sindkann erfolgen. Eine Faktextraktion beinhaltet das Analysieren des Inhaltsund dessen Speicherung für eine Inhaltsbasierte Suche.

Nicht-funktionale Anforderungen

1. Die Multimedia Datenbank muss als ein Zusatzmodul für das TUTORizeBusiness Solutions System integriert werden. Dieses Zusatzmodul muss ein-und ausschaltbar sein.

2. Die Integration in das TUTORize Business Solutions System muss die be-reits vorhanden Datenstruktur nicht verändern sondern soll, wenn nötig nurerweitern.

3. Als Datenspeicher muss MongoDB zum Einsatz kommen. Zusätzlich dazumuss GridFS benutzt werden um binäre Daten abzuspeichern.

4. Die Multimedia Datenbank muss in der Programmiersprache Ruby geschrie-ben sein und muss das Webframework Ruby on Rails benutzen.


5. Eine Dokumentation für die REST API sowie die verfügbaren Endpunktemuss vorhanden sein.

6. Videos müssen abhängig von der Eingabequalität in die Qualitätsstufen Nied-rig, Mittel, Hoch und HD transkodiert werden.

7. Audios müssen als MP3 und als OGG transkodiert werden und zur Verfügungstehen.

8. Der Zugriff auf die Multimedia Datenbank soll regulierbar sein durch einenAdmininstrator.

9. Die Multimedia Datenbank kann effizient und schnell Medien verarbeitendurch eine Lastverteilung auf mehrere Server.

3.1.3 Systemarchitektur

Die Multimediadatenbank besteht aus vier Hauptkomponenten (Abbildung 3.1).

REST-API bietet Informationen über Medienressourcen an. Dabei können dieseRessourcen in XML oder in JSON ausgeliefert werden.

Streaming-API bietet es an Medien auszuliefern. Dabei werden Videos und Au-dios gestreamt. Streamen bedeutet, dass Teile des Mediums erst ausgeliefertwerden, wenn sie benötigt werden.

Processing ist die Verarbeitungskomponente. Beim Processing werden Medien,welche über die REST-API hochgeladen werden, verarbeitet. Videos werdenin die verschiedenen Qualitätsstufen transkodiert. Audios werden in MP3 alsauch in OGG transkodiert. Bilder werden in verschiedene Auflösungsstufenumgewandelt.

Storage ist die Komponente, welche sich darum kümmert, dass sowohl Medien alsauch Ressourcen in der MongoDB gespeichert werden. Dazu wird die RubyBibliothek Mongoid benutzt.

Folgendes Datenmodell (Abbildung 3.2) wird verwendet um die Datenbank ab-zubilden. Dabei existiert ein Medienelement, welches viele Medienversionen hat.Eine Medienversion hat viele Subversionen. Eine Subversion muss zu einer Eltern-version gehören. Eine Medienversion verfügt über ein Medium. Ein Medium kannein Video, Audio, Image oder Text sein. Weiterhin haben Medienelemente vieleTags. Ein Tag kann nur zu einem Medienelement gehören.

Das dargestellte Datenmodell wird von der REST API als verschiedene Res-sourcen dargestellt. Dabei existieren folgende Ressourcen.


Processing

Streaming APIStorage

REST-API

TBS

Medienanalysieren

Medienabrufen

Medienspeichern

Ressourcenanbieten

Medienstreamen

Abbildung 3.1: Komponenten der Multimedia Datenbank

title: Stringdescription: String

MediaElement

tag_value: StringTag*

0..1

version_message: Stringversion_hash: Stringprocessing_status: String

MediaVersion

0..*

1

Media11

resolutions: Hashmedia_file: VideoUploader

Videomedia_file: VideoUploader

Audio

media_file: VideoUploaderImage

text_field: StringText

1

0..*

-parent_version

-sub_versions

Abbildung 3.2: Datenmodell der MMDB


MediaElement ist die Ressource, welche viele Medienversionen vereint. Das Me-diaElement ist die zentrale Ressource, um Medien zu erstellen.

MediaVersion beschreibt eine Version eines Mediums zu einem bestimmten Zeit-punkt. Eine MediaVersion kann viele Subversionen haben. Damit sollen Medi-en, welche nur marginal vom Inhalt her abweichen, effizient verwaltet werden.

Media ist das Medium an sich. Das Medium enthält seine physikalische Medien-datei, welche abgerufen werden kann.

Diese Ressourcen werden über die REST API verwaltet. Die REST API bietetCRUD Methoden an, um diese zu bearbeiten.

3.1.4 REST API

Die REST API verfügt über folgende HTTP-Endpunkte.

MediaElement Ressource

Die Ressource MediaElement kann über die REST-API angezeigt, bearbeitet, er-stellt und gelöscht werden. Die HTTP Endpunkte werden in der Tabelle 3.1 auf-geführt.

URL Methode Beschreibung/v1/media_elements GET Alle Medienelemente

/v1/media_elements/:id GET Medienelement mit ID/v1/media_elements POST Neues Medienelement als Ressource erzeugen

/v1/media_elements/:id PATCH / PUT Medienelement bearbeiten/v1/media_elements/:id DELETE Medienelement löschen

Tabelle 3.1: HTTP Endpunkte für die Ressource Mediaelement

Mediaversion Ressource

Die Ressource Mediaversion kann über die REST-API angezeigt und erstellt wer-den. Die HTTP Endpunkte werden in Tabelle 3.2 aufgeführt.

Media Ressource

Die Ressource Media kann über die REST-API nur angezeigt werden. Die HTTPEndpunkte werden in Tabelle 3.3 angezeigt.


URL Methode Beschreibung/v1/media_versions GET Keine Funktion

/v1/media_versions/:id GET Medienversion mit ID von der URL/v1/media_versions POST Neue Medienversion erstellen

/v1/media_versions/:id PATCH / PUT Keine Funktion/v1/media_versions/:id DELETE Keine Funktion

Tabelle 3.2: HTTP Endpunkte für die Ressource Mediaversion

URL Methode Beschreibung/v1/medias GET Keine Funktion

/v1/medias/:id GET Media mit der ID aus der URL/v1/medias POST Keine Funktion

/v1/medias/:id PATCH / PUT Keine Funktion/v1/medias/:id DELETE Keine Funktion

Tabelle 3.3: HTTP Endpunkte für die Ressource Media

Mediastreaming

Medien können über folgende HTTP Endpunkte dargestellt in Tabelle 3.4 bezogenwerden.

URL Methode Beschreibung/v1/files/videos/:id/:filename_low GET Videodatei in niedrig ausliefern

/v1/files/videos/:id/:filename_medium GET Videodatei in mittel ausliefern/v1/files/videos/:id/:filename_high GET Videodatei in hoch ausliefern/v1/files/videos/:id/:filename_hd GET Videodatei in HD ausliefern

/v1/files/audios/:id/:filename GET Audiodatei ausliefern/v1/files/images/:id/:filename GET Bilddatei ausliefern

Tabelle 3.4: HTTP Endpunkte um Medien auszuliefern

3.1.5 Integration ins TUTORize Business Solutions System

Die Integration ins TUTORize Business Solutions System erfolgt über die RESTAPI. Im TUTORize Business Solutions System existieren bereits Schulungselemen-te. Schulungselement können dabei Videos, Audios, Text, Dokument, Scorm, Quizund Webinar sein. Diese Schulungselemente haben alle einen Typen. Nun wird einneuer Typ eingeführt, welcher ein Multimediadatenbank Element repräsentierensoll. Dieser Typ heißt MediaDatabaseElement. Ein MediaDatabaseElement enthält


die Ressource ID eines Mediums sowie die Information darüber, welche Medien-version für eine Schulung verwendet werden soll. Die Integration der MultimediaDatenbank erfolgt durch einen weiteren Menüpunkt in den Verwaltungseinstellun-gen. In dem Menü können mehrere Mediendatenbanken verwaltet werden. Auchkönnen Medienelemente in diesem Menüpunkt angeschaut, durchsucht, bearbeitetund erstellt werden wie in Abbildung A.13 und Abbildung A.12 dargestellt. Dabeiwerden dem Benutzer die verschiedenen Medienversionen so einfach wie möglich ineiner Zeitlinie präsentiert. Das Erstellen eines neuen Schulungselementes, welchesMedien aus der Multimedia Datenbank verwendet, erfolgt über die normale Schu-lungserstellung. Beim Auswählen eines Schulungselementes kann zwischen den ver-schiedenen Typen gewählt werden. Wenn der Datenbanktyp ausgewählt worden ist,so kann in einem Dialog die Datenbank nach den verschiedenen Medienelementendursucht werden wie in Abbildung A.11 und Abbildung A.10 dargestellt. Wenn einpassendes Medienelement gefunden worden ist so kann dieses ausgewählt werdenund steht damit bereit.

3.2 Megamodellierung

Dieser Abschnitt befasst sich mit der Megamodellierung des Webframeworks Rubyon Rails sowie der Megamodellierung der Multimedia Datenbank, die entwickeltwird. In 3.2.1 wird das MVC-Muster durch ein Megamodell beschrieben. Danachwird in 3.2.2 das Webframework Ruby on Rails mit einem Megamodell beschrie-ben. In 3.2.3 wird die Projektstruktur eines Ruby on Rails Projektes durch einMegamodell beschrieben sowie der Datenfluss einer Anfrage bis zu einer Antwort3.2.4. Die Megamodelle der Multimedia Datenbank stellen graphisch die Kompo-nenten und deren Beziehungen in A.7 dar. Detailierte Megamodelle der einzelnenKomponenten der Multimedia Datenbank werden in 3.1.3 beschrieben.

3.2.1 MVC-Muster

Das MVC Muster wie im Grundlagenteil 2.4.2 erklärt, wird in Abbildung A.4 alsein Megamodell dargestellt. Dabei stellen die einzelnen Teile des MVC-MustersModel, View und Controller eine eigene Entität dar. Jede dieser Entitäten istmit der Relation partOf mit der abstrakten Entität MVC verbunden. Die MVCEntität ist mit der Relation instanceOf mit der Entität DesignPattern verbunden.Die Umsetzung in MegaL folgt aus dem graphischen Megamodell.

Pattern < SetMVC : PatternDes ignPattern : SetCon t r o l l e r : A r t i f a c t


Model : A r t i f a c tView : Ar t i f a c t

MVC instanceOf Des ignPatternCon t r o l l e r partOf MVCModel partOf MVCView partOf MVC

3.2.2 Ruby on Rails

Ruby on Rails wird im Megamodell 3.3 als eine Entität beschrieben, welche mitdrei Relationen zu den Entitäten Ruby, MVC und Web Application Frameworkverbunden ist. Die Relation zur Entität Ruby ist dependsOn und beschreibt, dassRuby on Rails sich auf die Programmiersprache Ruby stützt und somit Ruby einwichtiger Bestandteil des Webframeworks ist. Ruby on Rails die Instanz eines WebApplication Frameworks und stützt sich auf das MVC-Muster.

Abbildung 3.3: Ruby on Rails Megamodell [LSAS14]

Die Umsetzung in MegaL aus dem graphischen Megamodell.

Ruby : LanguageRuby on Ra i l s : TechnologyMVC : PatternWeb app l i c a t i o n framework : Entity

Ruby on Ra i l s dependsOn RubyRuby on Ra i l s ins tanceOf Web app l i c a t i o n frameworkRuby on Ra i l s dependsOn MVC


Abbildung A.2 zeigt das komplette Ruby on Rails Framework als ein Megamo-dell. Dabei steht Ruby on Rails als Entität in der Mitte und verlässt sich auf vieleTeilkomponenten, die das Framework modellieren.

3.2.3 Ruby on Rails Projekstruktur

Da Ruby on Rails eine fest vorgegebene Projektstrukur hat, kann diese mit ei-nem Megamodell beschrieben werden. Abbildung A.3 zeigt einen Ausschnitt derProjektstruktur.

Die Umsetzung in MegaL aus dem graphischen Megamodell.

Ruby : Languageapp : Folderviews : Folderc o n t r o l l e r s : Folder

v i ewFi l e s : F i l e+mode lFi l e s : F i l e+c o n t r o l l e r F i l e s : F i l e+

views partOf appmodels partOf appc o n t r o l l e r s partOf app

v i ewFi l e s partOf viewsmode lFi l e s partOf modelsc o n t r o l l e r F i l e s partOf c o n t r o l l e r s

mode lFi l e s elementOf Rubyc o n t r o l l e r F i l e s elementOf Rubyv i ewFi l e s elementOf Ruby

3.2.4 Request und Response

Das Megamodell in Abbildung A.5 modelliert den Datenfluss einer Anfrage aneinen Webservice, welches mit dem Webframework Ruby on Rails realisiert wur-de. Dabei werden die im folgenden beschriebenen Entitäten verwendet um denDatenfluss zu modellieren.

HTTP Request ist die physikalische Anfrage, welche erzeugt wird wenn eineWebseite angefragt wird. Diese Anfrage setzt die HTTP Spezifikationen umund besteht aus einer Request URL, Request Header, Request Method sowie


einem Request Body. Die Request URL beinhaltet die Adresse, an welchesich die Anfrage richtet. Der Request Header besitzt Metainformationen diedem Webserver beim Verarbeiten der Anfrage helfen die richtige Antwort zuerzeugen. Die Request Method beschreibt die Art der Anfrage und richtensich nach der HTTP Spezifikation von Get, Put, Patch, Post und Delete. Beieiner REST API entscheidet die Request Method ob eine Ressource angezeigt,bearbeitet oder gelöscht werden soll. Im Request Body befinden sich Daten,welche mit der Anfrage an den Webserver geschickt werden.

HTTP Response ist die physikalische Antwort, welche von einem Webserver zu-rückkommt. Eine Antwort von einem Webserver ist konform zu der HTTPSpezifikation. Dabei besteht eine Antwort aus einem Response Code sowieeinem Response Body. Der Response Code gibt den Status an wie die Verar-beitung der Anfrage erfolgt ist. Die Statuscodes sind von der HTTP Spezi-fikation festgelegt. Der Response Body beinhaltet Daten, welche von einemWebserver zurückkommen. Bei einer REST API befindet sich im ResponseBody die angeforderte Ressource.

HTTP Specification beschreibt die HTTP Spezifikation, wie sie auf [Gro99] spe-zifiert ist. Diese HTTP Spezifikation existiert als ein Textdokument und kannsomit überprüft werden.

Rack ist ein Webserver Interface, welches in der Programmiersprache Ruby ge-schrieben ist. Es ermöglicht mit HTTP Requests und Responses umzugehen.

Rails ist das Ruby Webframework. Rails ist ein MVC Framework um schnell undproduktiv Webapplikationen zu schreiben. Rails verlässt sich auf Rack umAnfragen zu bearbeiten und Antworten zu erzeugen.

In der Abbildung A.5 werden diese Artefakte und Technologien in einem Mega-modell miteinander verbunden und Kernbeziehungen gezeigt. Der Datenfluss voneinem Request über den Webservice bis zu einem Response erfolgt mithilfe einesControllers und der darin definierten Methode. Der Controller ist ein Teil von Railsund wird durch eine Routing Datei definiert. Die Routing Datei legt dabei fest,welcher einkommende Request mit welcher Controller Methode bearbeitet werdensoll und legt somit die Abbildung dieser Methode zu einem HTTP Endpunkt fest.Ein Megamodell in MegaL folgt aus der Abbildung A.5 Die Anwendung der Me-gamodelle wird in 4.3.3 gezeigt.

r eque s t : A r t i f a c t+response : Ar t i f a c t+c o n t r o l l e r : F i l e+route s : F i l e


r eque s t correspondsTo c o n t r o l l e rc o n t r o l l e r conformsTo route sresponse correspondsTo c o n t r o l l e r

Kapitel 4

Implementation

Dieses Kapitel befasst sich mit der Implementation der Multimedia Datenbanksowie dem Anwenden der Megamodelle auf verschiedene Projekte. Im Abschnitt4.1.5 werden die eingesetzten Frameworks, Technologien und Bibliotheken behan-delt. Abschnitt 4.2.5 beschreibt die Implementation der Multimedia Datenbank.Es wird die Implementation der REST API, Faktextraktion sowie der StreamingKomponente erläutert. Im letzten Abschnitt 4.3.3 werden die Megamodelle, welcheim Konzept Kapitel vorgestellt werden, angewendet.

4.1 Frameworks und Technologien

Dieser Abschnitt befasst sich mit den verwendeten Technologien und Frameworks.Es werden die Technologien MongoDB 4.1.1, Rails 4.1.2, Sidekiq 4.1.3, Carrierwave4.1.4 sowie FFMPEG 4.1.5 erläutert.

4.1.1 MongoDB

MongoDB ist eine Quelloffene NoSQL Dokumenten Datenbank, welche von der10gen Company entwickelt und gewartet wird. Es wurde mit dem Ziel entwickeltwachsende Datenmengen zu verarbeiten. MongoDB ist in der ProgrammierspracheC++ geschrieben und die Abfragesprache basiert auf Javascript. Daten werden alsKollektionen gespeichert. Jede Kollektion enthält viele Dokumente. Ein Dokumentist als JSON ähnlichen Form gespeichert genannt BSON. BSON unterstützt dieDatentypen Boolean, Float, String, Integer, Date und Binary. Daten werden alsSchlüssel-Werte Paare repräsentiert. Werte können weitere Dokumente, Arraysoder Arrays von Dokumenten sein. Da MongoDB eine schemalose Datenbank ist,können zu jedem Dokument zusätzliche Felder hinzugefügt werden. Datenkollek-tionen können per Sharding über mehrere Knoten verteilt werden. Ein Knoten ist

38

KAPITEL 4. IMPLEMENTATION 39

dabei eine MongoDB Instanz, welche auf einem anderen Server liegen kann. DieseKnoten werden über einen Master Knoten zusammengeführt und verwaltet. So-mit kann eine MongoDB Datenbank über mehrere Server verteilt werden um beiwachsenden Anfragen gut zu skalieren. Sharding bietet neben der Skalierbarkeitauch eine Backup Funktion an [RA13]. Wie viele Datenbanksysteme verfügt auchMongoDB über Indexe. Indexe sind notwendig für Perfomanceoptimierungen. Eswerden folgende Arten von Indexen in MongoDB unterschieden [Mon14].

Primary and Secondary Indexes: Ein einzigartiger Index wird für alle Doku-mente auf dem ID-Feld erstellt. MongoDB wird automatisch dieses Feld gene-rieren und einen einzigartiger Wert zuweisen. Alle benutzerdefinierten Indexewerden als Secondary Indexe bezeichnet. Benutzer können jedes Feld für einSecondary Index benutzen.

Compound Indexes: Ein Compound Index bezeichnet den Mengendurchschnittvon mehreren Indexen. Ein Beispiel für einen Compound Index ist die Su-che nach einem Benutzer. Dieser besitzt einen nach Vornamen, Nachnamensowie Wohnort. Wenn diese drei Felder einen Compound Index besitzen sowird die Dokumentenabfrage optimiert und die Indexe werden für eine Suchekombiniert.

Unique Indexes: Unique Indexes werden dazu benutzt, dass MongoDB beimEinfügen von vorhandenen Werten diese ablehnt. Standardmäßig sind Indexenicht einzigartig.

Array Indexes: Diese werden für Felder benutzt, welche ein Array beinhalten.Dabei wird jeder Arraywert als ein seperater Indexeintrag gespeichert.

Sparse Indexes: Sie beinhalten nur Einträge für Dokumente welche ein bestimm-tes Feld haben. Standardmäßig ist der Sparse Index ausgeschaltet.

TTL Indexes: TTL (Time to Live) ist ein Index, der dafür sorgt, dass Datennach Ablauf einer gewissen Zeit aus der Datenbank gelöscht werden.

Text Search Indexes: MongoDB bietet einen nativen Index für Textsuche an.Dabei kann der Benutzer Regeln und Tokens für die Suche definieren.

Hash Indexes: Berechnen einen Hashwert für ein Feld. Das Haupteinsatzgebietfür diesen Index ist die Verteilung von MongoDB Instanzen über mehrereNetzwerke.

Geospatial Indexes: Werden zur Optimierung von 2D-Koordinaten benutzt.


MongoDB wurde für die Multimedia Datenbank verwendet, weil es durch denEinsatz von GridFS ermöglicht, große Mediendateien in kleinen Teildateien zuspeichern und diese bei Bedarf abzurufen. Somit ist ein Streaming von Medienmöglich.

4.1.2 Rails

Ruby on Rails ist ein quelloffenes unter der MIT-Lizenz freigegebenes Webframe-work, welches in der Programmiersprache Ruby geschrieben ist, um Datenbankba-sierte Webanwendungen zu schreiben. Dabei folgt es den Prinzipien Do not repeatyourself (DRY). DRY sagt aus, dass sich Code nicht wiederholen soll. Ruby on Railsist daher als Umgebung so angelegt, dass einmalige Deklaration und Wiederverwen-dung so einfach wie möglich gemacht werden. DRY trägt somit zur Zuverlässigkeit,Verständlichkeit und Wartbarkeit des Systems bei. Nachträgliche Änderungen müs-sen somit nur an einer Stelle durchgeführt werden [BK07]. Ein weiteres Prinzip vonRuby on Rails lautet Convention over Configuration und verhindert viele Konfi-gurationen durch feste Namens- und Projektstrukturkonventionen . Dadurch wirddie Produktivität gesteigert.

4.1.3 Sidekiq

Sidekiq 1 ist eine Ruby Bibliothek, welche Hintergrundverarbeitung mithilfe vonThreads realisiert. Sidekiq verfügt über sogenannte Worker die in einem Hinter-grundprozess Daten verarbeiten. Sidekiq verwendet den Key-Value-Store Redis,um seine Jobs zu verwalten und um gescheiterte Jobs zu einem späteren Zeitpunktwieder aufzunehmen.

4.1.4 Carrierwave

Carrierwave 2 ist eine Ruby Bibliothek, welche es ermöglicht Dateien in eine Ruby-anwendung hochzuladen und abzuspeichern. Carrierwave wird oft in Kominationmit Ruby on Rails verwendet, um Dateien über einen Browser hochzuladen undzu verarbeiten.

4.1.5 FFMPEG

FFMPEG ist ein Multimedia Framework, das multimediale Inhalte kodiert, deko-diert, transkodiert, muxt, demuxt, streamt, filtert und abspielt [Tom06]. FFMPEG

1https://github.com/mperham/sidekiq2https://github.com/carrierwaveuploader/carrierwave


wird in der Multimediadatenbank dazu benutzt, Videos in die verschiedenen Qua-litätsstufen zu transkodieren.

4.2 Multimedia Datenbank

Dieser Abschnitt befasst sich mit der Implementation der Multimedia Datenbank.In Abschnitt 4.2.1 wird die Implementation der Ressourcen wie sie in Abbildung3.2 dargestellt sind gezeigt. Danach wird in 4.2.2 die Implementation der RESTAPI erläutert und wie diese die Ressourcen in verschiedenen Repräsentationen aus-liefert. In Abschnitt 4.2.3 sowie in 4.2.4 wird die Verarbeitung sowie das Ausliefernvon Multimediainhalten durch die REST API gezeigt. Der letzte Abschnitt 4.2.5dieses Kapitels zeigt die Integration ins TUTORize Business Solutions System undwie die dort bereits vorhandene Datenstruktur um Medien zu verwalten erweitertwurde um Medien von der Multimedia Datenbank anzuzeigen.

4.2.1 Ressourcen

Die in Abbildung 3.2 gezeigten Ressourcen werden als Ruby Klassen modelliert undmit der Funktionalität von dem Mongoid Modul erweitert. Die Erweiterung ist einModul das in die Klasse eingebettet wird. Durch das einbetten dieses Moduls erhältdie Klasse alle Funktionalitäten und Methoden des Moduls und kann somit vonder Mongoid Gem persistent in der MongoDB abgespeichert werden. Das Modulkann folgendermassen in die Klasse eingebunden werden.

i n c lude Mongoid : : Document

Listing 4.1: Mongoid Modul um Klassen über Mongoid zu persistieren

Attribute einer Klasse, welche ein Modell darstellt können über die field Funktioneingefügt werden. Diese field Funktion wird durch das einbinden des MongoidModuls verfügbar.

f i e l d : attribute_name , Typ

Listing 4.2: Mongoid Felddeklaration

Dabei ist der erste Parameter der Attributname, dieser wird als Schlüssel in derMongoDB benutzt. Der zweite Parameter bestimmt den Typen des Attributs. Ty-pen können Primitiv sein wie Integer, Float, Double und Char sein oder komplexereObjekte wie Date und String. Die verfügbaren Typen werden von der MongoDBfestgelegt. Somit können keine eigens definierten Typen verwendet werden.


4.2.2 REST API

Die REST API verwaltet die Ressourcen wie sie in Abbildung 3.2 dargestellt wer-den. Dabei bietet die REST API zwei Arten der Repräsentation an. Diese sindXML und JSON. Damit ein geschützter Zugriff auf die Ressourcen erfolgt verfügtdie REST API über eine Authentifikation. Diese wird in 4.2.2 erklärt. Die RESTAPI erhält durch eine Versionierung die Möglichkeit Modellerweiterungen oderModelländerungen durchzuführen ohne dabei bereits bestehende Klienten einzu-schränken oder ihren Anbindung neu zu implementieren. Die Versionierung wirdin 4.2.2 gezeigt.

Authentifikation

Um Zugriff auf Ressourcen durch die REST API zu bekommen muss eine Authenti-fizierung durchgeführt werden. Diese Authentifizierung ist eine Symbolbasierte (To-kenbasierte). Dies bedeutet, dass ein Zugangstoken in jeder Anfrage an die RESTAPI mitgeschickt werden muss. Zusätzlich zum Zugangstoken muss ein Tenant, al-so ein Accountname, mitgeschickt werden. Dazu muss der HTTP-Header mit demSchlüssel Tenant-Domain mitgeschickt werden. Beispiele für Anfragen an die APIwerden im Folgenden mit curl gezeigt. Curl ist ein Kommandozeilenprogramm, dasDateien innerhalb von Rechnernetzen überträgt. Curl steht unter der MIT-Lizenzund ist auf verschiedenen Betriebssystemen vorhanden. Im Folgenden wird ein curlBefehl gezeigt, welcher alle benötigten Header zu einer Anfrage anzeigt.

cu r l http : / / . . .−X GET | POST | PATCH | PUT | DELETE−H "Accept : . . . "−H " Author iza t ion : Token token = . . . "−H "Tenant−Domain : . . . "−H "Content−Type : . . . "−d " . . . "

Listing 4.3: Kommandozeilen-Tool Befehl für eine HTTP Anfrage

Dabei steht das H für einen Header der mit der Anfrage mitgeschickt wird. Das dstellt die Daten dar welche mit einer Anfrage mitgeschickt werden sollen. Anfragenan die REST API werden bevor sie von einem konkreten Controller bearbeitetwerden durch den einen Versionscontroller geleitet der den Zugriff regelt und beieiner nicht ausreichenden Authentifizierung die Abfrage ablehnt. Dabei wird zuerstder Tenant also der Account der anzufragenden Ressource gesetzt dies passiertdurch folgende Methode.

de f set_tenant_from_header@domain = Account . find_by (


subdomain : r eque s t . headers [ ’HTTP_TENANT_DOMAIN’ ])

i f @domainMongoid : : Mult itenancy . current_tenant = @domain

e l s ehead : not_found

endend

Listing 4.4: REST API Authentifikationsmethode

Wenn der Account gefunden wurde so wird die Anfrage zu einer weiteren Methodeweitergeleitet.

de f r e s t r i c t_a c c e s sauthenticate_or_request_with_http_token { | token , opt i ons |

Account . find_by ( auth_token : token ) &&@domain . auth_token == token

}end

Listing 4.5: REST API Authentifikationsmethode 2

In der Anfrage wird überprüft ob der mitgeschickte Zugangstoken auch mit demZugangstoken des Accounts übereinstimmt. Falls dieser übereinstimmt so wird dieAnfrage weiterverarbeitet. Wenn es nicht übereinstimmt so bekommt der Klientden HTTP Status 401 zurück. Der HTTP Status 401 bezeichnet einen unerlaubtenZugriff auf eine Webressource.

Versionierung

Die REST API hat eine URL Versionierung. Damit hat jede URL zu einer Res-source eine Versionsnummer in der URL. Eine URL zu der einer Webresource überdie REST API hat folgende Struktur.

http :// api . . . . com/v1 / . . .

4.2.3 Verarbeitung von Multimedia

Abbildung A.8 zeigt den Prozess der Erstellung und Verarbeitung. Verarbeitenbezeichnet den Vorgang, der Fakten von Medien extrahiert als auch in verschie-dene Formate umwandelt, um die Inhalte auszuliefern. Dabei wird vom Client


ein Request an die TUTORize Media Solutions REST-API geschickt. Dieser Re-quest enthält die benötigten Parameter wie sie von der REST API gefordert sind,um eine neue Medienversion zu erstellen sowie das Medium, das für diese Versionverwendet werden soll. Nachdem diese Anfrage erfolgreich bei der REST API ange-kommen ist, wird eine neue Medienversion initialisiert und es wird geprüft, ob dieMediendatei verarbeitet werden soll. Falls die Mediendatei verarbeitet werden soll,übernimmt der Sidekiq Mediaworker asynchron die Verarbeitung und die Medien-version wird gespeichert mit dem entsprechenden Status. Nach dem Speichern wirddem Client der HTTP-Statuscode 201 zurückgeschickt. Dieser HTTP-Statuscodebedeutet, dass eine neue Ressource erstellt worden ist. Zusätzlich kriegt der Clientdie URL zurück, unter der er die neu erstellte Ressource erreichen kann.

4.2.4 Ausliefern von Multimedia

Medien werden von der Streaming API ausgeliefert. Das Sequenzdiagramm in Ab-bildung A.9 zeigt, wie Medien von der Streaming API ausgeliefert werden. An dieStreaming API wird eine Anfrage geschickt mit der benötigten Byteposition. DieByteposition beschreibt das Intervall, welches der Client braucht, um das Mediumanzuzeigen. Dieses Intervall wird von der Streaming API aus der geforderten Dateiextrahiert und berechnet. Das extrahierte Intervall besteht aus zusammengesetztenTeilstÃ1

4cken der Datei, welche als Chunk bezeichnet werden. Ein Chunk hat dabei

eine festvorgegeben Bytegrößse. Diese Chunks werden dann von der MongoDB an-gefordert und bezogen. Wenn das Intervall korrekt zusammengesetzt wurde, wirddieses an den Client gesendet.

4.2.5 Integration ins TUTORize Business Solutions System

Die Integration ins TUTORize Business Solutions System erfolgt durch die An-bindung der REST API sowie einer Erweiterung des Models SectionElement. ZurAnbindung der REST API wird das Gem RestClient verwendet. Dieser abstrahiertdas Zusammenbauen der Requests mit den benötigten Headern und des Payloads.Die Zugangsdaten zur Mediendatenbank werden von einem Model verwaltet, wel-ches den Zugangsschlüssel, verwendete API version, URL zur Mediendatenbanksowie den Accountnamen speichert. Der Zugriff auf die REST API erfolgt durchdie Umsetzung eines Mediendatenbank Klienten, welcher Methoden für den Zugriffauf die Multimedia Datenbank kapselt. Medienelemente und neue Medienversionenzu bereits vorhandenen Medienelementen können im Menü der Multimediadaten-bankverwaltung erstellt, bearbeitet und gelöscht werden. Wenn eine neue Schulungerstellt wird, kann der Ersteller, wenn eine Lizenz vorhanden ist, die Multimediada-tenbank durchsuchen und Medien zu seiner Schulung hinzufügen. Beim Auswähleneiner Schulung wird ein neues Kurselement angelegt mit dem Typen, welches ein


Mediendatenbankelement kennzeichnet. Das neue Kurselement enthält Informatio-nen zur Ressource ID sowie die URLs zum beziehen der Medien.

4.3 MegaL

Dieses Kapitel beschäftigt sich mit der Erweiterung der MegamodellierungsspracheMegaL. Die erste Erweiterung wird in Abschnitt 4.3.1 beschrieben. Die zweiteErweiterung wird in Abschnitt 4.3.2 behandelt.

4.3.1 Bitbucket als neuer Provider

MegaL linkt Entitäten zu Webressourcen von verschiedenen Quellcode Providern.Diese haben einen offenen Zugang zum Quellcode und benötigen keine Authenti-fizierung. Bisherige Projekte auf die Megamodelle angewendet wurden liegen aufsolchen frei zugänglichen Providern. Wenn ein Projekt jedoch auf einem Provi-der liegt, welcher eine Authentifikation benötigt, so ist ein Zugriff von MegaL aufdie Webressourcen nicht mehr möglich. Die Multimedia Datenbank, welche durchMegamodelle validiert werden soll liegt auf solch einem Provider. Der Provider istBitbucket und verfügt über eine REST API, mit der eine Authentifikation erfolgenkann. Dazu wurde MegaL um diesen Provider erweitert. Die Authentifikationsda-ten werden in der Konfigurationsdatei für das jeweilige Megamodell hinterlegt undvon MegaL verwendet. Die Schlüssel für eine Authentifikation werden in 4.6 dar-gestellt.

{. . ." repo " : " . . . . " ,"username" : " . . . " ,"branch" : " . . . ". . .

}

Listing 4.6: Konfigurationsdatei mit Zugangsdaten für ein Repository

4.3.2 Evaluator für Request und Response

Wie im Konzept Kapitel beschrieben, stellen dynamische Megamodelle eine Her-ausforderung beim Anwenden der Megamodelle auf ein Projekt dar. Das in Kapitel3 beschriebene und in Abbildung A.5 dargestellte Megamodell ist ein dynamischesMegamodell. Das Anwenden des Megamodells setzt statisch vorhandene Artefak-te voraus, mit denen die Evaluation der Beziehung erfolgen kann. Dazu werden


die serialisierten Routingtabellen sowie die extrahierten Fragemente des Ruby onRails Projektes benötigt als auch der serialisierte Request. Die Routingtabellensowie die extrahierten Fragmente aus den Controllern als auch der serialierte Re-quest, wird als ein JSON Array in 4.7, 4.8 und 4.9 dargestellt. Das Erzeugen dereinzelnen Fragmente wird durch einen Testfall durchgeführt und muss vor demAnwenden des Megamodells ausgeführt werden. Mithilfe dieser Artefakte wird einsogenannter CorrespondanceChecker realisiert der es ermöglicht das Megamodellumzusetzen. Dazu wird der serialisierte Request analysiert und es wird die AnfrageURL extrahiert. Danach wird die extrahierte URL in den serialisierten Routing-tabellen nachgeschlagen um die Controller Methode zu finden, die diese Anfragebearbeiten soll. Wenn eine Controller Methode gefunden wurde, so wird in denextrahierten Fragmenten der Controllern nach dieser Methode gesucht und wenndiese gefunden wurde, so ist eine Korrespondenz nachgewiesen.

[. . .

{"name" : "api_media_elements" ," verb" : "GET" ,"path" : "/v1/media_elements" ," a c t i on " : " index" ," c o n t r o l l e r " : "media_elements"

}. . .]

Listing 4.7: Serialisierte Routes

[{

" r e sour c e " : " https : / / . . . / app/ c o n t r o l l e r s /media_elements_contro l ler . rb" ,

"name" : "media_elements" ," c l a s s i f i e r " : " c l a s s " ," fragments " :[

{" r e sour c e " : " https : / / . . . / app/ c o n t r o l l e r s /

media_elements_contro l ler . rb/method/ index" ,"name" : " index" ," c l a s s i f i e r " : "method" ," source " : " de f index end"

}. . .

]}


]

Listing 4.8: Extrahierte Fragmente aus den Controllern

{" ht tp_ inte r a c t i ons " : [. . .{

" r eque s t " : {"method" : " get " ," u r i " : " http : / / . . . / v1/media_elements" ,"body" : {

. . .} ," headers " : {

. . .}

} ," response " : {

" s t a tu s " : {" code" : 200 ,"message" : "Ok"

} ," headers " : {

. . .} ,"body" : {

. . .} ," http_vers ion " : " 1 . 1 "

} ," recorded_at " : " . . . "

}]. . .

}

Listing 4.9: Serialisierter Request und Response

4.3.3 Anwenden der Megamodelle

Die Megamodelle A.3 und A.5 werden auf die implementierte Multimedia Daten-bank angewendet. Die Tabelle 4.1 zeigt Metriken der Multimedia Datenbank, umeine Einschätzung der Projektgröße zu bekommen.


Name Codezeilen Klassenanzahl Methodenanzahl

Controllers 335 9 34Helpers 14 0 0Models 251 14 9

Javascripts 18 0 1Libraries 114 2 13

Tabelle 4.1: Projektmetriken

Die Anwendung des Megamodells A.3 lieferte das Ergebnis, dass die Projekt-struktur einfach überprüft werden kann durch MegaL. Es wird der Verfolgbarkeits-mechanismus benutzt um die Anwendung auszuwerten. Die Ausgabe der MegaLEvente wird in 4.10 und 4.11 gezeigt.

{. . .

{" event" : "EntityLookupStarted" ," source " : "Ruby : Language" ," en t i t y " : "Ruby"

} ,{

" event" : "EntityLinkingSucceeded " ," source " : "Ruby : Language" ," en t i t y " : "Ruby" ," r e sour c e " : " https : // g ithub . com/ruby/ruby"

}. . .

{" event" : "EntityLookupStarted" ," source " : "app : Folder " ," en t i t y " : "app"

} ,{

" event" : "EntityLinkingSucceeded " ," source " : "app : Folder " ," en t i t y " : "app" ," r e sour c e " : " https : // b i tbucket . org / . . . / app"

} ,. . .

}

Listing 4.10: MegaL Events der Projektstruktur - Entities

{. . .


{" event" : " Re la t i onsh ipEva lua t i onSta r t ed" ," source " : " c o n t r o l l e r s partOf : app" ," l e f t " : " c o n t r o l l e r s " ," r e l " : "megal . r e l a t i o n s h i p s . FolderPartOfFolder " ," r i g h t " : "app"

} ,{

" event" : " Re la t ionsh ipEva luat ionSucceeded " ," source " : " c o n t r o l l e r s partOf : app" ," l e f t " : " c o n t r o l l e r s " ," r e l " : " FolderPartOfFolder " ," r i g h t " : "app"

}. . .

}

Listing 4.11: MegaL Events der Projektstruktur - Relationships

Wie in 4.3.2 beschrieben setzt die Anwendung des Megamodels A.5 die statischvorhandenen Artefakte 4.7 und 4.8 voraus. Das Anwenden des Megamodels liefertedie Ausgabe 4.12.

. . .{

" event" : " Re la t i onsh ipEva lua t i onSta r t ed" ," source " : " r eque s t correspondsTo : c o n t r o l l e r " ," l e f t " : " r eque s t " ," r e l " : "megal . r e l a t i o n s h i p s . Art i factCorrespondsToFi l e " ," r i g h t " : " c o n t r o l l e r "

} ,{

" event" : " Re la t ionsh ipEva luat ionSucceeded " ," source " : " r eque s t correspondsTo : c o n t r o l l e r " ," l e f t " : " c o n t r o l l e r s " ," r e l " : "megal . r e l a t i o n s h i p s . Art i factCorrespondsToFi l e " ," r i g h t " : " c o n t r o l l e r "

}. . .

Listing 4.12: MegaL Events - Request und Response

Kapitel 5

Fazit

Das Ziel dieser Arbeit war die Konzeption und Implementation einer MultimediaDatenbank, welche als ein Webservice zur Verfügung stehen soll, sowie die Integra-tion ins TUTORize Business Solutions System. Zudem sollten Megamodelle denEinsatz der verwendeten Technologien verifizieren und für ein besseres Verständnisder Funktionsweise und den Aufbau des Projektes sorgen. Die Multimedia Daten-bank wurde als ein Webservice realisiert, der über eine REST API bedient werdenkann. Medien können über diese Schnittstelle in die Multimedia Datenbank ein-gefügt werden, sowie über die gleiche Schnittstelle abgerufen werden. AbgerufeneMedien werden nicht als ganze Datei angefordert, sondern es können nur bestimm-te Teile des Mediums abgerufen werden, die zum Anzeigen benötigt werden. Diesresultiert in geringeren Wartezeiten beim Laden von Medien sowie einer verrin-gerten Netzwerkauslastung. Die Analyse von Medien zur Faktenextraktion ist einkomplexer Vorgang, der nur teilweise umgesetzt wurde. Es wurde nur die Fakten-extraktion für Audiodateien realisiert. Diese analyse und extraktion besteht ausdem erstellen eines digitalen Fingerabdrucks, welcher für eine Inhaltssuche benutztwerden kann. Eine Faktenextraktion für Bilder und Videos wurde in der Multime-dia Datenbank nicht realisiert. Metadatenextraktion wie Bitrate, Länge, Codecund Farbraum werden jedoch von allen Medien extrahiert und gespeichert. DieUnterstützung durch Megamodellierung wurde durch Megamodelle für das Web-framework Ruby on Rails, als auch durch ein Megamodel für eine Anfrage an einenWebservice realisiert. Die entstandenen Megamodelle wurden mithilfe der Mega-modellierungssprache MegaL angewendet. Die Anwendung erfolgte für die Projekt-struktur als auch für die Anfrage an den Webservice. Andere Megamodelle wurdennur graphisch dargestellt, da dessen Anwendung sich nur in begrenzten Maße aus-führen ließ. Durch die Anwendung der Megamodelle wurde auch MegaL erweitert.Die Erweiterungen bezogen sich auf die Implementation eines neuen Providers zudem Entitäten gelinkt werden können, als auch einem Evaluator für die Korre-spondenz zwischen einer Anfrage und einem Controller in einem MVC-Webservice.

50

KAPITEL 5. FAZIT 51

Die Tabellen 5.1 und 5.2 zeigen die Umsetzungen bezüglich der Anforderungsliste3.1.2.

KA

PIT

EL

5.

FA

ZIT

52

Funktionale AnforderungenAnforderung Erfüllt Teilweise erfüllt Nicht erfüllt Beschreibung

#1 x - - -#2 x - - -

#3 - x -Nicht alle Webressourcen sollen

verfügbar sein#4 x - -#5 x - -#6 x - -

#7 - x -Das einfügen von Texten in die

Multimedia Datenbank wird nichtunterstützt.

#8 - x -Es existiert nur eine Faktenextraktion für

Audiodateien

Tabelle 5.1: Umsetzung der funktionalen Anforderungen

KA

PIT

EL

5.

FA

ZIT

53

Nicht-funktionale Anforderungen

Anforderung Erfüllt Teilweise erfüllt Nicht erfüllt Beschreibung

#1 x - - -#2 x - - -#3 x - - -#4 x - - -#5 x - - -#6 x - - -#7 - - - Es findet keine Transkodierung statt

#8 - x -Zugriff kann über das Rechtesystem

des TUTORize Business Solutions System gesteuert werden

Tabelle 5.2: Umsetzung der nicht funktionalen Anforderungen

Kapitel 6

Ausblick

Betrachtet man abschließend den Prototypen der Multimedia Datenbank wird er-sichtlich, dass es viele Möglichkeiten gibt diese zu erweitern. Zum Beispiel fehlennoch Faktenextraktionen zu Videos, Bildern und Texten. Außerdem besteht dieMöglichkeit, eine Weboberfläche für die Multimedia Datenbank zu entwickeln, inder Medien ohne Abhängigkeit zum TUTORize Business Solutions System hoch-geladen werden können. Durch die REST API ergibt sich die Möglichkeit Applika-tionen im mobilen Bereich zu entwickeln damit Benutzer nicht mehr ortsgebundenihre Lernmedien anschauen müssen und Suchanfragen über die Aufnahmefunktionihres Mobilgerätes erfolgen können. Durch die Auslagerung der inhaltsbasiertenSuche in eine Ruby Bibliothek besteht die Möglichkeit Suchverfahren zu erweitern.Wird zum Beispiel die aktuelle Suche im TUTORize Business Solutions System umdie Funktionalität erweitert Medien nach Inhalt zu suchen, so bekommen Benut-zer ein mächtiges Werkzeug um mit dem Lernmanagementsystem umzugehen. DasAnwenden sowie aufstellen der Megamodelle für Ruby on Rails führen zu der Frageob dadurch das komplette Webframework abgebildet wurde. Ausgehend von dieserFrage können durch Anwendung von weiteren Megamodellen mehr Fälle erschlos-sen werden und es kann sich somit an ein vollständiges Megamodell angenähertwerden. Folgende weiterführenden Arbeiten an MegaL ließen sich hier anschließen.Neue Beziehungen zu Entitäten würden die Anwendung von Megamodellen erwei-tern, indem Sachverhalte durch aussagekräftigere Beziehungen modellieren lassen.Weiterhin ist die Anwendung von Megamodellen durch MegaL noch sehr komplexund erfordert eine relativ hohe Einarbeitung. Auf der Grundlage der Bedienbar-keit ergibt sich ein Forschungsbedarf um MegaL im Produktiveinsatz einzusetzen,damit Projekte durch Megamodelle validiert werden.

54

Anhang A

55

ANHANG A. 56

System

Set

*sus

*model

*metamodel

*cmodel

*composite

*part

DecomposedIn RepresentationOf

ConformsTo

ElementOf

Tranformation

source*

target*

IsTransformedIn

defRange*defDomain*

1 1

*element

* set

Abbildung A.1: Megamodell von MDE [FN04]

ANHANG A. 57

Abbildung A.2: Komplettes Ruby on Rails Megamodell [LSAS14]

Abbildung A.3: Ruby on Rails Megamodell Projektstruktur [LSAS14]

ANHANG A. 58

Abbildung A.4: MVC-Muster Megamodell [LSAS14]

Abbildung A.5: Ruby on Rails Megamodell Request und Response [LSAS14]

ANHANG A. 59

Abbildung A.6: TUTORize Media Solutions verwendete Gems

Abbildung A.7: Multimedia Datenbank Komponenten Megamodell

ANHANG A. 60

Client

createMediaVersion(media_version, media_file)

Sidekiq Mediaworker

HTTP-Statuscode 201 with created resource

TUTORize Media Solutions REST API

start_processing()alt

[needs_processing?]

[else]

create_version()

create_version()

Abbildung A.8: Sequenzdiagramm zur Medienverarbeitung

Client Streaming API

requestVideo(range)

MongoDB

get_needed_chunks()

calculate_needed_chunks()

chunks

set_response_code_and_content()

send_data(video_chunks)

Abbildung A.9: Sequenzdiagramm zur Ausliefern von Medien

ANHANG A. 61

Abbildung A.10: Mockup um Medienelemente anzeigen

ANHANG A. 62

Abbildung A.11: Mockup - Anzeigen eines Medienelementes

ANHANG A. 63

Abbildung A.12: Mockup - Neue Version erstellen

ANHANG A. 64

Abbildung A.13: Mockup - Versionen anzuzeigen

Abbildung A.14: Implementation - Element auswählen

ANHANG A. 65

Abbildung A.15: Implementation - Neues Element anlegen

Abbildung A.16: Implementation - Versions Vorschau

ANHANG A. 66

Abbildung A.17: Implementation - Medienversionen anzeigen

Literaturverzeichnis

[AK03] Atkinson, Colin ; Kühne, Thomas: Model-driven development:A metamodeling foundation. In: IEEE Software 20 (2003), S.36–41. http://dx.doi.org/10.1109/MS.2003.1231149. – DOI10.1109/MS.2003.1231149

[BJRV05] Bézivin, Jean ; Jouault, Frédéric ; Rosenthal, Peter ; Valdu-

riez, Patrick: Modeling in the Large and Modeling in the Small.In: Model Driven Architecture. Berlin, Heidelberg : Springer BerlinHeidelberg, 2005 (Lecture Notes in Computer Science), 33-46

[BK07] Bächle, Michael ; Kirchberg, Paul: Ruby on Rails. In: IEEESoftware 24 (2007), Nr. 6, S. 105–108

[Bur92] Burbeck, Steve: Applications programming in smalltalk-80 (tm):How to use model-view-controller (mvc). In: Smalltalk-80 v2 5 (1992)

[Fav04a] Favre, Jean-Marie: Foundations of Model (Driven) (Reverse) Engi-neering – Episode I: Story of The Fidus Papyrus and the Solarus. In:POST-PROCEEDINGS OF DAGSTHUL SEMINAR ON MODELDRIVEN REVERSE ENGINEERING, 2004

[Fav04b] Favre, Jean marie: Towards a Basic Theory to Model Model DrivenEngineering. In: In Proc. of the UML2004 Int. Workshop on SoftwareModel Engineering, 2004

[Fav05] Favre, Jean marie: Foundations of meta-pyramids: Languages vs.metamodels episode II: Story of thotus the baboon. In: Language En-gineering for Model-Driven Software Development, number 04101 inDagstuhl Seminar Proceedings. Internationales Begegnungs und For-schungszentrum für Informatik (IBFI), Schloss Dagstuhl, 2005

[Fie00] Fielding, Roy T.: Architectural Styles and the Design of Network-based Software Architectures, Diss., 2000. – AAI9980887

67

LITERATURVERZEICHNIS 68

[FLV12] Favre, Jean-Marie ; Lämmel, Ralf ; Varanovich, Andrei: Mode-ling the Linguistic Architecture of Software Products. In: Proceedingsof the 15th International Conference on Model Driven EngineeringLanguages and Systems. Berlin, Heidelberg : Springer-Verlag, 2012(MODELS’12), 151–167

[FN04] Favre, Jean marie ; NGuyen, Tam: Towards a Megamodel to ModelSoftware Evolution through Transformations. In: SETRA Workshop,Elsevier ENCTS, 2004, S. 59–74

[Gro99] Group, Network W.: Hypertext Transfer Protocol - HTTP/1.1. http://www.w3.org/Protocols/rfc2616/rfc2616.html, June 1999

[I.S05] I.Schmitt: Ähnlichkeitssuche in Multimedia Datenbanken. Olden-bourg, 2005

[Jal01] Jalal, Samir K.: Multimedia Database: Content and Structure. 2001

[JB04] Jean-Bézivin, Patrick V. Frédéric Jouault J. Frédéric Jouault: Onthe Need for Megamodels, 2004

[JK06] Jouault, Frédéric ; Kurtev, Ivan: Transforming Models with ATL.In: Proceedings of the 2005 International Conference on SatelliteEvents at the MoDELS. Berlin, Heidelberg : Springer-Verlag, 2006(MoDELS’05), 128–138

[JSB12] Jackson, Ethan K. ; Schulte, Wolfram ; Bjørner, Nikolaj: Detec-ting Specification Errors in Declarative Languages with Constraints.In: Proceedings of the 15th International Conference on Model DrivenEngineering Languages and Systems. Berlin, Heidelberg : Springer-Verlag, 2012 (MODELS’12), 399–414

[KWB03] Kleppe, Anneke G. ; Warmer, Jos ; Bast, Wim: MDA Explained:The Model Driven Architecture: Practice and Promise. Boston, MA,USA : Addison-Wesley Longman Publishing Co., Inc., 2003

[LSAS14] Lämmel, Ralf ; Schens, Erwin ; Andrei, Varanovich ; Software-

sprachen, AG: Arbeitsgruppeninterne Sammlung aus Megamodel-len, FB4 - Universität Koblenz-Landau, 2014

[Lu00] Lu, Guojun: In: Multimedia Database Management Systems, 2000

[LV14] Lämmel, Ralf ; Varanovich, Andrei: Interpretation of LinguisticArchitecture. In: ECMFA, 2014, S. 67–82

LITERATURVERZEICHNIS 69

[LZ13a] Lämmel, Ralf ; Zaytsev, Vadim: An Abstract View on Megamode-ling Approaches. 2013. – Online since 22 July 2013. 10 pages

[LZ13b] Lämmel, Ralf ; Zaytsev, Vadim: Language support for megamodelrenarration. 2013. – In Proceedings of XM 2013. Available online athttp://ceur-ws.org/Vol-1089/

[MKUW04] Mellor, Stephen J. ; Kendall, Scott ; Uhl, Axel ; Weise, Dirk:MDA Distilled. Redwood City, CA, USA : Addison Wesley LongmanPublishing Co., Inc., 2004

[Mon14] MongoDB, Inc.: MongoDB Operations Best Practices, April 2014

[RA13] Rupali Arora, Rinkle Rani A.: Modeling and Querying Data inMongoDB. In: International Journal of Scientific and EngineeringResearch 4 (2013)

[RR07] Richardson, Leonard ; Ruby, Sam: Restful Web Services. First.O’Reilly, 2007

[SK00] Setrag Khoshafian, A. Brad B.: Multimedia and Imaging Data-bases. San Francisco, California : Morgan Kaufmann Publishers, Inc.,2000

[Tom06] Tomar, Suramya: Converting Video Formats with FFmpeg. In:Linux J. 2006 (2006), Juni, Nr. 146, 10–. http://dl.acm.org/

citation.cfm?id=1134782.1134792

Konzeption und Implementation einer Multimedia Datenbank ...softlang/SchensErwinBScThesis.pdf ·...

Documents

Transcript of Konzeption und Implementation einer Multimedia Datenbank ...softlang/SchensErwinBScThesis.pdf ·...