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 zuvor definierte Modell abbilden: Aufgaben → Capabilities und Ein-/Ausgaben → Operations/Events.
Die CapView ist eine funktional abstrahierende Ansicht auf ein in Ausführung bzw. Entwicklung befindliches Mashup. Grundlegende Eigenschaften der CapView sind (vgl. Abbildung 2):
Nach dem Umschalten in die CapView, sieht der Endnutzer zunächst alle Repräsentationen, die ihre Komponenten überlagern und deren Labels in der Basiskonfiguration (s. unten) sind. Weiterhin sind die bestehenden Verbindungen dargestellt. Der Endnutzer kann nun eine Repräsentation bzw. einen speziellen Port auswählen. Diese wird nachfolgend als r0 bezeichnet. Die Menge aller verknüpfbaren Repräsentationen für r0 ist L0 und kann weiter unterteilt werden in die Menge S0 ⊆ L0 (Repräsentationen, die Eingaben für r0 liefern können) und T0 ⊆ L0 (Repräsentationen, die Ausgaben von r0 konsumieren können).
Nach der Selektion von r0 werden...
Die automatische Erstellung von Labels ist ein Kernbestandteil der CapView und wird vom Label Generator übernommen (s. Architekturgrafik). Dieser baut auf eine Menge generischer Regeln auf und nutzt dabei im Wesentlichen das Wissen aus Ontologien und ein Wörterbuch aus.
Im einfachsten Fall (keine Selektion) wird eine Basiskonfiguration für Labels generiert.
Andernfalls, d.h., sobald eine Selektion existiert, tritt die kontextsensitive Labelgenerierung in Kraft. Diese ändert nicht r0, sondern alle r ∈ L0. Dabei werden kurze Sätze über die Labels hinweg gebildet, um Ursache und Wirkung zu verdeutlichen. Dies wird erreicht durch das Anhängen oder Voranstellen von "..." sowie der unterschiedlichen Behandlung von rj ∈ T0 und ri ∈ S0. Je nach Konstellation der durch die beiden involvierten r repräsentierten Interfacebestandteile (endweder Capabilities oder Property) gibt es grundlegende Regeln. Zudem existieren spezielle Regeln, die die semantischen Beziehungen von entities und Parametern beachten und z.B. greifen falls keine eindeutige Abbildung zwischen Aus- und Eingabeparametern existiert (Beispiel im Abschnitt Rekonfigurieren und in Abbildung 5) oder falls Mediationstechniken zum Einsatz kommen (unteres Beispiel in Abbildung 4, in dem ein semantischer Split Event → Location stattfindet, was durch "location of" angezeigt wird).
Existiert eine Selektion durch den Nutzer, kann eine Verbindung mit hervorgehobenen passenden Repräsentationen vorgenommen werden bzw. bestehende Verbindungen verändert und gelöscht werden.
Im Falle mehrerer Parameter und/oder mehrerer Optionen für deren Mapping obliegt es dem Endnutzer, die Zuordnung der Parameter festzulegen. Hierbei kann die von der Empfehlung stammende Belegung akzeptiert oder entsprechend angepasst werden. Im Beispiel ist zu sehen, dass der Ausgabeparameter vom Typ "Event" nicht komplett zur Flugsuche genutzt wird, sondern lediglich die Zeit und der Ort des Events (durch einzelne Eingabeports in Abbildung 5 gekennzeichnet). Zudem benötigt die Flugsuche mehrere Eingabeparameter (Zeitpunkt, Start-, Zielort), sodass es mehrere Möglichkeiten gibt, den Ort des Events abzubilden (angedeutet durch eine Kombobox mit zwei Einträgen im Label des ersten Eingabeports). Falls Clustering angewendet wurde, ist es Aufgabe der Laufzeitumgebung auf die passenden Operationen bzw. Events zurück zu schließen.
Verbindungen werden via Drag&Drop oder Einzelklicks der Ports erstellt. Dabei sind grundsätzlich beide Richtungen (source ↔ target) möglich.
Die Laufzeitumgebung trägt schließlich Sorge dafür, dass alle notwendigen Details gemäß dem Kompositionsmodell korrekt instanziiert werden, sodass die Verbindung auf Implementierungsebene und somit in der LiveView funktionstüchtig ist.
Hier finden sich weiterführende Informationen zur CapView, u.a. zu Evaluationsergebnissen und die formalen Regeln zur Labelgenerierung:
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.
