MMT-Logo
Sitemap | English
Home | Lehre | Forschung | Team | Service | Demos
Gefördert durch


 Europäische Union
Europäische Union


 Europäischer Sozialfonds in Sachsen
Europäischer Sozialfonds (ESF-080951805)


 Freistaat Sachsen
Freistaat Sachsen

Übersicht

EDYRA-Logo

Projektergebnisse und Demos

 

Überblick

Basierend auf den Konzepten aus dem Forschungsprojekt CRUISe widmet sich EDYRA der Bereitstellung von Methoden und Werkzeugen, die es Endnutzern ermöglichen, selbstständig Mashups zu erstellen. Im Wesentlichen soll der Endnutzer dabei durch Empfehlungen sowie geeignete Abstraktion von technischen Details unterstützt werden, seine Aufgaben zu erledigen und somit situationsspezifische Probleme zu lösen.

Die Zielgruppe von EDYRA sind Nicht-Programmierer, Domänenexperten ohne Programmierkenntnisse, die daran interessiert sind, sich selbstständig maßgeschneiderte Anwendungen zu erstellen. Solche Endnutzer sind u.a. wie folgt charakterisierbar

Zu den Kernkonzepten gehört weiterhin die Verschmelzung von Entwicklung und Nutzung der Mashupanwendung, auch Live Sophistication genannt. Dabei bietet die Mashup-Laufzeitumgebung die notwendigen Werkzeuge direkt mit, sodass der Nutzer sofortiges Feedback zu seinen Kompositionsschritten erhält.

Im Rahmen des Projekts wurde neben einer client-seitigen auch eine verteilte Laufzeitumgebung entwickelt. Weiterhin dienen Repositories von Komponenten, Anwendungen und Kompositionswissen als Backend und bieten zusätzlich Webservices als Schnittstelle zur Mashup-Laufzeitumgebung an.

CRUISe
Abbildung 1: Grober Überblick der EDYRA-Architektur

Semantische Beschreibung von Komponenten (SMCDL)

Das grundlegende Komponentenmodell entspricht dem von CRUISe vorgeschlagenen. Dabei werden Komponenten aller Anwendungsebenen (UI, Logik, Daten) einheitlich als Black-Box mit öffentlicher Schnittstelle angesehen, sodass Komponenteninterna und Implementierungsdetails versteckt werden. Komponenten können beispielsweise Web Services auf Basis von REST und SOAP, Feeds, aber auch JavaScript-APIs und Widgets repräsentieren.

Zur Beschreibung von Komponenten dient die Semantic Mashup Component Description Language (SMCDL). Sie setzt das Komponentenmodell um und erweitert es um semantische Annotationen (s. Abbildung 2). Diese bieten die Möglichkeit, durch Referenzen auf Domänenontologien, die folgenden Aspekte der Komponentensemantik zu beschreiben.

Semantische Komponentenbeschreibung
Abbildung 2: Überblick zu den semantischen Annotationen in SMCDL

Im Rahmen von EDYRA wurde die Deklaration der funktionalen Semantik überarbeitet. Capabilities sind Tupel aus <activity, entity, requiresInteraction> und beschreiben somit, welche Aktivität/Aufgabe auf/mit einem Domänenobjekt durchgeführt wird. Ob der Endnutzer in die Aktivität involviert ist, gibt der Eintrag requiresInteraction an. Capabilities können auf Ebene der gesamten Komponente sowie der Schnittstelle angegeben werden. Events selbst referenzieren die Capabilties, die zu deren Auftreten führen, mittels dependsOn.

Weiterhin wurde es in EDYRA ermöglicht, Anforderungen von Komponenten an ihren Kontext deklarativ zu beschreiben (Element requirements). Damit kann beispielsweise angegeben werden, dass eine Komponente bestimmte Technologien (Software und Hardware) von der Laufzeitumgebung benötigt, um ordnungsgemäß zu funktionieren. Aber auch Anforderungen an den Nutzer, z.B. das Vorhandensein von Accounts zwecks Zugriff auf Services, sind denkbar. Der Zusammenhang zwischen Anforderungen und Capabilities der Komponente wird mittels Referenzierung (Attribut capsRef) hergestellt. Technologisch dienen derzeit SPARQL-Queries zur Formulierung der Anforderungen und werden beim Matching von Komponenten gegen die semantische Komponentenbeschreibung abgeglichen.

Implementierungsdetails der Komponente werden im sogenannten Binding angegeben.

Zusätzliches Material:

Vertiefende Informationen:

Mashup-Kompositionsmodell (MCM)

Zur deklarativen Beschreibung aller Aspekte eines Mashups wird in EDYRA weitgehend auf das Kompositionsmodell von CRUISe aufgesetzt. Im Wesentlichen werden folgende anwendungsspezifische Aspekte im Kompositionsmodell abgedeckt:

Während in CRUISe das Kompositionsmodell in einem dedizierten Autorenwerkzeug erstellt wurde und kein Fokus auf End-User-Development gelegt wurde, stellt in EDYRA die Laufzeitumgebung selbst Funktionalitäten zur Erstellung und Modifikation von Mashups bereit. Dadurch kommt der Anwendungsentwickler, im Falle von EDYRA der Endnutzer ohne Programmierkenntnisse, nicht direkt in Kontakt mit dem Kompositionsmodell.

Vertiefende Informationen:

Mediationstechniken für Mashups

Mediation dient der Auflösung von Inkompatibilitäten auf Siganturebene insofern möglich. Dazu wurden in einer studentischen Arbeit, aufsetzend auf den in dieser Publikation vorgestellten Konzepten, folgende Mediationstechniken definiert:

For each communication channel (explicit like Link etc. and implicit like drag & drop) a mapping definition exists. It declaratively describes the mediation techniques necessary for coupling two compatible signatures S1 and S2 where Si= { parameter-type+ }. Mapping definitions are part of the communication model.

Vertiefende Informationen:

Empfehlungsgestützte Mashup-Entwicklung

In EDYRA, end users are guided by recommendations on composition steps like adding and substituting components or integrating whole subcompositions including several channels and components. Thereby, a hybrid recommendation approach is utilized, combining semantics-based techniques and statistical analysis of existing mashup applications to leverage the knowledge of the crowd.

The overall approach has similarities to an adaptation loop, which, separated from the application, includes continuous monitoring of the context and the application, analyzing (i. e., evaluation of trigger conditions and calculating recommendations in terms of patterns), planing (i. e., deriving an action specification), and adapting the application by executing the plan (i. e., implementation of the action specification).

Triggers are entities that start the recommendation procedure. They continuously monitor the application, context and/or user interactions and check conditions to determine whether to set off or not. There are different types of Triggers:

If a trigger fires, it delivers a data structure with all necessary information to the Recommendation Manager. The latter consolidates, filters, and priorizes triggers. Then, useful recommendations in terms of Patterns are queried and ranked for each trigger and shown to the user. Patterns are composition fragments and can be semantically reasoned or mined from existing composition models. For the pattern selected by the user, an Action Specification is derived. The latter states all steps required to integrate a pattern in the running mashup and is executed by the adaptation system.

Architektur
Abbildung 3: Architektonischer Überblick der EDYRA-Plattform mit Fokus auf Empfehlungskonzepten

Vertiefende Informationen:

CapView

Wie in der Architekurgrafik zu sehen ist, existieren in EDYRA mehrere Ansichten auf die Mashup-Komposition. Die LiveView stellt lediglich die UI-Repräsentation der Komponenten entsprechend des Layouts dar. Weitere Ansichten können die Live-Ansicht überlagern und somit, passend zu den Erfahrungen und Fertigkeiten der Nutzergruppe, Details zur zugrundeliegenden Komposition preisgeben. Die ProfessionalView zeigt alle Informationen zu Interfaces an, lässt die Verknüpfung zu und bietet Testfeatures an. Eine Abstraktion vom Kompositionsmodell findet dabei nicht statt, sodass technische Konzepte, Datenstrukturen etc. verstanden werden müssen. Hier setzt die CapView an und bietet eine aufgaben-/aktivitäts-orientierte Abstraktion des Kompositionsmodells. Dadurch sollen folgende Anwendungsfälle mithilfe der CapView realisiert werden. Ein Nicht-Programmierer möchte...

Wesentliche Annahme ist, dass Komponenten zur Erfüllung von Aufgaben dienen können, und dass ein Verbund von Komponenten entsprechend komplexe Aufgaben erledigen kann. Dazu benötigen Komponenten möglicherweise Eingaben bzw. produzieren Ausgaben. Dies lässt sich auf das oben definierte Modell abbilden: Aufgaben → Capabilities und Ein-/Ausgaben → Operations/Events.

Beispielhafter Überblick der CapView

Abbildung 4: Beispielhafter Überblick der CapView

Die CapView ist eine funktional abstrahierende Ansicht auf ein in Ausführung bzw. Entwicklung befindliches Mashup.

Vertiefende Informationen:

Selbst ausprobieren – Plattformdemo

Zur Erprobung und Validierung der erarbeiteten Konzepte wird kontinuierlich an einer Livedemo gearbeitet.

Obwohl viel Schweiß investiert wird, ist zu bedenken, dass es sich dabei um einen Forschungsprototyp handelt, d.h., Bugs sind nicht auszuschließen. Daher ist der Zugang derzeit beschränkt. Bitte wenden Sie sich an einen der Projektmitarbeiter, falls Sie die Demo ausprobieren möchten.

Publikationen