Forschungsbericht. Projekt BAMOS. Prof. Dr. Ralf Bruns. Fachhochschule Hannover

Größe: px
Ab Seite anzeigen:

Download "Forschungsbericht. Projekt BAMOS. Prof. Dr. Ralf Bruns. Fachhochschule Hannover"

Transkript

1 Projekt BAMOS Forschungsbericht Prof. Dr. Ralf Bruns Fachhochschule Hannover Fachhochschule Hannover Fachbereich Informatik Ricklinger Stadtweg Hannover Tel.: (0511)

2 Vorwort Dieser Bericht beschreibt das Forschungsprojekt BAMOS (Basisarchitektur für mobile Anwendungen in spontanen Netzen), das am Fachbereich Informatik der Fachhochschule Hannover unter der Leitung von Prof. Dr. Jürgen Dunkel und Prof. Dr. Ralf Bruns durchgeführt wurde. Als Industriepartner war die Firma nepatec GmbH (Hannover) am Projekt beteiligt. Das Projektvorhaben wurde mit Fördermitteln der Arbeitsgruppe Innovative Projekte (AGIP) beim Ministerium für Wissenschaft und Kultur des Landes Niedersachsen unterstützt (F.A.- Nr ). Wesentliche Arbeiten in diesem Projekt entstanden während des Forschungssemesters von Prof. Dr. R. Bruns, das durch die Forschungskommission der Fachhochschule Hannover im Sommersemester 2005 befürwortet wurde. Forschungsbericht BAMOS - 2 -

3 Inhaltsverzeichnis 1. Projektkontext Projektergebnisse Basisarchitektur Überblick Service-Beschreibungen...6 Spezifikation der Benutzungsoberfläche mit XForms...7 Aufbau von XForms Ablaufbeschreibungen Generierung mobiler Anwendungen mittels MDA Modellierung...10 Das Metamodell...10 Modellierung der Abläufe...11 Modellierung von Views and Interaktionen Generierung Anwendungsszenario Hardware und Software-Infrastruktur Beschreibung des Szenario Erzielte Ergebnisse Veröffentlichungen Vorträge Beiträge in Zeitschriften und Konferenzen Bachelor-Arbeit...22 Forschungsbericht BAMOS - 3 -

4 1. Projektkontext Sowohl der Verbreitungsgrad als auch die technische Leistungsfähigkeit mobiler Endgeräte (z.b. Personal Digital Assistants, Smartphones, Mobiltelefone) haben innerhalb weniger Jahre eine rasante Entwicklungsdynamik gezeigt. Im Gegensatz dazu weist die Entwicklung mobiler Anwendungen für diese Geräteklasse nach wie vor zahlreiche Defizite auf und stellt die professionelle Software-Entwicklung vor neue Herausforderungen. Heutzutage sind mobile Geräte allgegenwärtig und unterliegen einer quasi permanenten Verfügbarkeit. Die Leistungsfähigkeit der Geräte ist inzwischen so hoch, dass sie neben ihren Standardfunktionen wie Telefonieren und Kalenderverwaltung enormes Potential für fortgeschrittene Anwendungen aufweisen. Die Verbindungsfähigkeiten in lokale Netze über Bluetooth oder WLAN ermöglichen eine ganz neue Verwendungsart für mobile Geräte. Eine neue Qualität von mobilen Informationsdiensten eröffnet sich mobilen Geräten durch die technischen Möglichkeiten der spontanen Vernetzung. Bei einer spontanen Vernetzung können sich mobile Endgeräte einen in Reichweite liegenden Zugriffspunkt suchen, um sich in ein lokales Netz einzubinden. Die Datenübertragung erfolgt hierbei drahtlos. Eine spontane Vernetzung ermöglicht das Anbieten lokaler und damit orts- bzw. situationsgerechter Informationsdienste, bspw. Fahrplanauskünfte oder lokale Veranstaltungshinweise. Darüber hinaus können die im gesamten World Wide Web verfügbaren Dienste genutzt werden. Insgesamt wäre es wünschenswert, mobile Geräte in verschiedensten Umgebungen nutzen zu können, um lokalisierte Dienste in Anspruch zu nehmen. Im Rahmen des Projekts Bamos (Basisarchitektur für mobile Anwendungen in spontanen Netzen) wurde eine Basisarchitektur für mobile Anwendungen in spontanen Netzen konzipiert und prototypisch realisiert. Das Projekt wurde in enger Kooperation des Fachbereichs Informatik der Fachhochschule Hannover mit dem Industriepartner nepatec GmbH (Hannover) durchgeführt. Die Basisarchitektur unterstützt die Entwicklung von mobilen Anwendungen durch die Bereitstellung von Software-Komponenten, die die folgenden Anforderungen und Aufgaben realisieren: Plattformunabhängigkeit Die Entwicklung professioneller Software für Mobilgeräte ist geprägt durch fehlende bzw. nichtkompatible Standards, konkurrierende Hardware- und Betriebssystemplattformen und unterschiedliche Übertragungstechnologien wie Bluetooth, Wireless LAN, GPRS und UMTS. Die BAMOS-Plattform kapselt spezielle Details der software- und hardwaretechnischen Eigenschaften der mobilen Plattform sowie der drahtlosen Kommunikation transparent und stellt standardisierte Schnittstellen bereit. Der Software- Entwickler kann sich somit auf die fachlichen Fragestellungen konzentrieren, ohne sich mit den technischen Besonderheiten der mobilen Plattform auseinandersetzen zu müssen. Spontane Vernetzung Die mobilen Geräte sind in der Lage, einen in Reichweite liegenden Netz-Zugriffspunkt zu finden, und sich über diesen in ein lokales Netz einzubinden (Verbindungsaufbau). Die Datenübertragung erfolgt stets drahtlos und bietet mithilfe von Technologien wie Bluetooth oder Wireless LAN einen kostenfreien Zugriff mit hohen Übertragungsraten. In der Regel sind dem Endgerät das genutzte Netz sowie dessen Topologie und auch die angebotenen Dienste nicht bekannt. Deshalb spricht man von spontaner oder adhoc- Vernetzung (Spontaneous Networking). Lokalisieren von Diensten Nach erfolgreicher Einbindung in ein unbekanntes Netz kann das Mobilgerät alle angebotenen Dienste auffinden und anzeigen (Service Detection). Somit kann der Benutzer einen gewünschten Dienst auswählen. Verändert sich die lokale Umgebung, i.d.r. durch Veränderung des Standortes des mobilen Gerätes, melden sich Forschungsbericht BAMOS - 4 -

5 neuverfügbare Dienste automatisch beim mobilen Geräte an, während sich nicht mehr verfügbare Dienste abmelden. Zugriff auf Dienste Nach Auswahl eines Dienstes wird auf dem Mobilgerät eine an den ausgewählten Dienst angepasste Benutzerschnittstelle generiert, die es ermöglicht Daten für den genutzten Dienst einzugeben, diesen auszuführen und dessen Ergebnisse anzuzeigen (Service Execution). Anbieten von Diensten Damit einem Mobilgerät die Interaktion mit einem unbekannten Dienst möglich ist, wurde eine standardisierte Beschreibung eines Dienstes entwickelt (Service Deployment). Diese Beschreibung umfasst alle Informationen, die das mobile Gerät benötigt, um den Dienst anzubieten. Dazu gehört eine genaue Spezifikation des angebotenen Dienstes, sowie eine Beschreibung der Benutzungsoberfläche und des Dialogablaufs. 2. Projektergebnisse Die im Projekt entwickelte Basisarchitektur unterstützt die Entwicklung mobiler Anwendungen durch die Bereitstellung von zwei Software-Komponenten. Die eine Komponente ist ein Adhoc-Client, der vergleichbar mit einem Internet-Browser jedem mobilen Endgerät den Zugriff auf beliebige Informationsdienste in spontanen Netzen ermöglicht. Die andere Komponente ist ein Service Broker, der vergleichbar mit einem Web-Server in jedem spontanen Netz als Schnittstelle zwischen dem Adhoc-Client und den lokalen Diensten bzw. Web Services fungiert. Die BAMOS-Plattform ermöglicht es mobilen Geräten, verschiedenste unbekannte Dienste in unterschiedlichen lokalen Netzen zu nutzen. Der Adhoc-Client auf dem mobilen Gerät ist generisch konzipiert und besitzt keinerlei Informationen über spezifische Dienste. Die Dienste (bzw. ihre Beschreibungen) werden vom Adhoc-Client zur Laufzeit nachgeladen und dann dem Benutzer grafisch-aufbereitet präsentiert. Die Basis für dieses generische Konzept bildet die Beschreibung des Dialogablauf und der grafischen Präsentation für einen Dienst Basisarchitektur Überblick Das Projekt BAMOS hat eine Software-Architektur entworfen und entwickelt, in der mobile Geräte beliebige ortsgebundene Dienste nutzen können (siehe Abbildung 1). In dieser Architektur gibt es drei Hauptkomponenten, die unterschiedliche Aufgaben wahrnehmen: 1. Adhoc-Client Der Adhoc-Client läuft als Java-Anwendung auf dem mobilen Endgerät und hat die Aufgabe, die verfügbaren Dienste für den Benutzer zu visualisieren und mit dem Service Broker über das drahtlose Netz zu kommunizieren. Technologisch wurde der Adhoc- Client mit J2ME (Java 2 Micro Edition) und MIDP 2.0 (Mobile Information Device Profile) implementiert. Die Komponente verwaltet die verfügbaren lokalen drahtlosen Netzwerke und verbindet sich spontan mit gefundenen Service Brokern. Dies geschieht unabhängig von der eingesetzten Übertragungstechnologie (Bluetooth, Wireless LAN, GPRS und UMTS). Im Rahmen des Projekts wurde zunächst der Verbindungsaufbau über Bluetooth implementiert. Der Adhoc-Client identifiziert alle in seiner lokalen Umgebung angebotenen Dienste (Service Detection) und lädt die Dienste vom Service Broker. Mittels einer dynamisch generierten Benutzungsoberfläche werden die geladenen Dienste dargestellt und die Interaktion mit den Diensten ermöglicht (Service Execution). Nachdem der Benutzer Forschungsbericht BAMOS - 5 -

6 Service-Anfragen spezifiziert hat, liest der Adhoc-Client diese Eingaben aus und schickt diese an den Service Broker zurück. Service Detection Adhoc Client Connect Load Service Service Broker Service Call Register Service Service Provider local service or Web Service Wireless Adhoc Network Wired Network (local and/or Internet) Service- Directory Abbildung 1: BAMOS-Basisarchitektur 2. Service Broker Der Service Broker ist der Mittelpunkt der BAMOS-Architektur. Er bietet selbst keine Dienste an, sondern unterhält ein Service-Repository mit Beschreibungen von allen verfügbaren Diensten und agiert als Vermittler zwischen Adhoc-Client und den unterschiedlichen Service Providern. Alle verfügbaren Dienste wurden von den Service Providern am Service Broker registriert. Da der Service Broker einen Zugang aus dem drahtlosen Netz bietet, kann der Adhoc-Client mit dem Service Broker eine temporäre Verbindung aufbauen. Der Broker liest das Service-Repository aus und präsentiert dem Adhoc-Client die verfügbaren Dienste. Anhand einer Ablaufsteuerung sorgt er für die korrekte Ausführung der Dienste. Dafür nimmt er die Anfragen des Adhoc-Clients entgegen, leitet diese an den Service Provider weiter, wählt die Bildschirmansicht für den nächsten Dialogschritt und schickt die Antwortparameter des Service Providers zusammen mit der Beschreibung der Bildschirmansicht an den Client zurück. Der Service Broker bildet das Bindeglied zwischen drahtlosem und drahtgebundenem Netz (mit unterschiedlichen Netztechnologien). Der Service Broker enthält ein Verzeichnis (Service Directory) zum Publizieren und Auffinden der fachlichen Dienste, die durch eine XML-basierte Beschreibungssprache komplett beschrieben werden (Service Deployment). Der Service Broker liefert alle erforderlichen technischen Informationen damit der Adhoc-Client eine service-spezifische Benutzerschnittstelle erzeugen kann. Er leitet Anforderungen des Adhoc-Clients an fachliche Services weiter und bereitet die Antworten für den Client auf. Die grundlegende technologische Entwurfsentscheidung fiel mit der Wahl des W3C-Standards XForms als Service- Beschreibungssprache und Nachrichtenformat für die Kommunikation. 3. Service Provider Ein Service Provider bietet fachliche Dienste an und steht gemeinsam mit dem Service Broker in einem drahtgebundenen Netz. Damit die Dienste auch von mobilen Geräten genutzt werden können, registriert der Service Provider diese beim Service Broker. Dies können einerseits ortsbezogene Dienste sein, andererseits öffentliche Dienste aus dem World Wide Web (z.b. Web Services). Danach steht er für Anfragen des Service Broker (weitergeleitet von den Adhoc-Clients) bereit Service-Beschreibungen Die von einem mobilen Endgerät genutzten und auf dem Service Broker abgelegten Dienste müssen so beschrieben werden, dass: Forschungsbericht BAMOS - 6 -

7 1. aus der Beschreibung auf dem mobilen Endgerät eine passende Benutzungsoberfläche dynamisch generiert werden kann und 2. die zur Dienstnutzung erforderlichen Interaktionen festgelegt sind (Ablaufsteuerung). Die Ablaufbeschreibung eines Dienstes verbleibt auf dem Server und wird von einer Ablaufsteuerung interpretiert. Diese Ablaufsteuerung wählt die passende Ablaufbeschreibung aus. Diese Beschreibung definiert die Abfolge von Dialogschritten, in der der Benutzer mit dem Dienst interagieren kann und bestimmt den jeweils nächsten Dialogschritt. Der Vorteil bei diesem Ansatz liegt darin, dass keine Änderungen auf dem mobilen Gerät vorgenommen werden müssen, wenn neue Dienste aufkommen oder sich bekannte Dienste ändern. Eine XML-basierte Spezifikation von Oberflächen und Abläufen bietet sich an, weil sie gut zur Laufzeit eingelesen und daraus dann vom Adhoc-Client eine entsprechende Anwendung erzeugt werden kann. Allerdings verbleibt das Problem, die komplexen XML-Beschreibungen für Ablauf und Oberfläche zu erstellen. Hier können aber generative Ansätze wie die OMG/Model Driven Architecture (MDA) Abhilfe schaffen: Auf Basis von UML-Modellen werden MDA-Werkzeuge benutzt, um die sehr abstrakten XML-Beschreibungen zu generieren. Mit diesem Ansatz lässt sich die mobile Applikationen modellieren und anschließend fast vollständig generieren, d.h. es muss kein Code geschrieben werden, um neue Dienste anzubinden. Spezifikation der Benutzungsoberfläche mit XForms Der Adhoc-Client ist unabhängig von jeglicher Fachlichkeit konzipiert, muss aber dennoch die Interaktion des Benutzers mit fachlichen Diensten ermöglichen. Dafür benötigt der Client eine Beschreibung der Benutzungsoberflächen für einen fachlichen Dienst, mit denen der Benutzer interagieren kann. Diese Oberflächenbeschreibungen stellt der Service Broker zur Verfügung und der Client kann darauf zugreifen. Die grundlegende technologische Entwurfsentscheidung fiel mit der Wahl des W3C-Standards XForms als Service- Beschreibungssprache und Nachrichtenformat für die Kommunikation. Der Vorteil von XForms liegt in der Korrelation zu MIDP, unserer Basistechnologie für die Implementierung des Adhoc-Clients. Die ursprüngliche Intention von XForms-Formularen ist es, in Zukunft die heute üblichen Web-Formulare in XHTML zu ersetzen. XForms ist eine XML-Sprache und bietet den klassischen XHTML-Formularen gegenüber eine Reihe von Neuerungen (s.u.). Da XForms als W3C Recommendation vorliegt, können wir auf einen offenen Standard aufsetzen, der auch in Zukunft relevant sein wird. Das J2ME-Profil MIDP ermöglicht es dem Entwickler, eine relativ simpel strukturierte Benutzungsoberflächen zu schreiben, welche mit einfachen Eingabe- und Interaktionsmöglichkeiten auskommen. XForms kann MIDP-Elemente, wie z.b. Input-Felder und andere MIDP-Konstrukte, sehr gut abbilden. Es fällt auf, dass eine MIDP- Oberfläche einem Web-Formular sehr ähnelt: Elemente wie Eingabefelder, Radio-Buttons oder Listen bieten ähnliche Eingabemöglichkeiten. Auch die Interaktionsmöglichkeiten des Benutzers sind in vielen Anwendungsfällen wie in Web-Formularen auf die Bestätigung ( Submission ) der gemachten Eingaben beschränkt. Deshalb bietet sich die Benutzung von XForms an. Aufbau von XForms Im Gegensatz zu einem herkömmlichen XHTML-Formular erfolgt in einem XForms- Dokument eine Trennung von Model und View. Es besteht daher aus zwei Teilen: Innerhalb des model-tags befindet sich die eigentliche Information, die dem Benutzer angezeigt wird und deren Inhalt er ändern kann. Diese Modellinformation kann aus beliebigem XML bestehen. In dem einfachen Beispiel in Abbildung 2 enthält es Angaben zu Vor- und Nachname einer Person. Im submission-tag steht, was mit dem Modell passieren soll, Forschungsbericht BAMOS - 7 -

8 wenn es ausgefüllt und abgeschickt wird. Den Einsatz von mehreren Modellen in einem Dokument sieht XForms ebenfalls vor. Neben dem Modell spezifizieren weitere Elemente die Präsentation des Modells und die Interaktionsmöglichkeiten mit diesem. Dazu bietet XForms eine Reihe von Ein- und Ausgabeelementen, die im Wesentlichen denen aus herkömmlichen Web-Formularen gleichen, wenn sie auch anders notiert werden. Über XPath-Ausdrücke in den ref-attributen verweist jede Darstellungskomponente auf sein Element aus dem Modell. Im Beispiel ermöglichen zwei Eingabefelder die Ansicht und Anpassung der Angaben zu Vor- und Nachnamen der Person. Das submit-element spezifiziert den View für eine Submission aus dem Modell, welche typischerweise über einen Button dargestellt wird, im Beispiel trägt dieser die Aufschrift Absenden. Drückt ein Benutzer auf den Knopf und löst damit ein Submit aus, werden seine Eingaben an die entsprechenden Stellen in das Modell eingefügt und dieses Modell (alles was innerhalb des instance-tags steht) anhand der Angaben im submission-tag verarbeitet. Im typischen Einsatz im Web-Umfeld schickt der Browser das Modell an einen Web-Server. Innerhalb unseres Einsatzfeldes wird das ausgefüllte Modell aber an den Service Broker, z.b. über Bluetooth, übertragen. Abbildung 2: Aufbau eines XForms-Dokuments 2.3 Ablaufbeschreibungen Neben der Beschreibung der Oberflächen in XForms muss der Service Broker wissen, welche XForms-Dokumente auf welche Submits folgen, d.h. die Abfolge der Dialogschritte, und wie die Service Provider einzubinden sind. Dafür existiert im Service Broker eine Ablaufsteuerungskomponente, welche anhand einer Ablaufbeschreibung arbeitet. Auf Grundlage dieser Ablaufbeschreibung nimmt die Ablaufsteuerung eine XForms-Submission entgegen, identifiziert anhand dessen den auszuführenden Dienst, extrahiert die Parameter für die fachliche Funktion aus den übertragenen Daten und ruft den Service Provider auf. Das darauf folgende XForms-Template wird bestimmt und, mit den Ausgaben der fachlichen Funktion gefüllt, an die View-Komponente zurückgegeben. Diese parst das neue XForms- Dokument und stellt es dar. Für die Beschreibung des Prozesses wurde eine einfache XML-Sprache entworfen, die unsere Anforderungen ideal abbildet, aber nicht zu generisch oder mit unnötigen Konstrukten überladen ist. Um zu verstehen, wie diese Beschreibung aufgebaut ist, müssen wir wieder eine Detailstufe tiefer gehen und uns ansehen, wie in BAMOS ein Dienst definiert ist und aus welchen Bestandteilen er besteht. Abbildung 3 zeigt den detaillierten Aufbau eines Dienstes. Forschungsbericht BAMOS - 8 -

9 In BAMOS besteht ein Dienst aus einer Abfolge von Interaktionen, welche zusammen Nutzen für den Anwender bringen. Ein Dienst kann ein eng umgrenzter einfacher Dienst (z.b. nur eine Info), aber auch eine Zusammenfassung mehrerer Dienste (Mensa-Service und Haltestellenfahrplan unter dem Deckmantel FHService ) sein. Jede Interaktion beinhaltet einen Screen (ein XForms-Template für eine Oberfläche), der dem Benutzer gezeigt wird und mit dem der Benutzer interagieren kann. Dieses Template kann initial mit Informationen gefüllt werden, die sich aus vorhergehenden Interaktionen ergeben. Aber zu einer Interaktion gehört auch, dass der Benutzer ein Submit absetzen kann, woraufhin seine Eingaben zu Parametern einer Dienst-Methode werden, die aufgerufen wird und deren Rückgabewert zur Ausgabe dieser Interaktion und zur Eingabe der nächsten Interaktion wird. Innerhalb der aktuellen Interaktion wird entschieden, welches die Folge-Interaktion ist. Abhängig von den gemachten Eingaben des Benutzers können sich unterschiedliche Interaktionen an eine erledigte Interaktion anschließen. Service Call from SuperService Interaction Interaction Interaction Interaction Interaction Parameter FH: o Mensaplan o Üstra select Parameter XForms- Template Method of ServiceStub Abbildung 3: Service-Komposition mit Interaktionen Dieses Service-Konzept wird in XML kodiert. Die Abbildung 4 zeigt exemplarisch die XML- Beschreibung für eine Interaktion eines Dienstes. Das Element service bildet dabei den Rahmen und beinhaltet mehrere interaction-elemente. Diese beinhalten wiederum mit dem Element xform Informationen über das zugehörige XForms-Template und mit method über die aufzurufende fachliche Methode einer Service-Implementierung inkl. der Abbildung von Eingabe- und Ausgabe-Attributen. Die Elemente next bzw. nextdefault definieren Informationen über die Folge-Interaktion und definieren somit die Reihenfolge der Interaktionen für einen Dienst. Forschungsbericht BAMOS - 9 -

10 <bm:service id="fhservice" caption="fh-service"> <bm:class name="de.fhhannover.fhservice" />... <bm:interaction id="motd"> <bm:xform src="motd.xml"> </bm:xform> <bm:method name="selectfb"> <bm:param path="/motd/choice" id="0"/> <bm:outparam name="motd" id="0"> </bm:outparam> </bm:method> <bm:nextdefault target="motd-info"/> </bm:interaction>... </bm:service> Abbildung 4: Service-Interaktionen in der XML-basierten Workflow-Sprache 3. Generierung mobiler Anwendungen mittels MDA Die Code-Generierung mittels MDA (Model Driven Architecture) erfolgt auf Basis einer geeigneten domänenspezifischen Modellierungssprache (DSL domain specification language). Im Projektkontext bilden die auf den mobilen Endgeräten ablaufenden Anwendungen die zu modellierende Domäne Modellierung Als Basis der DSL wird im Projekt die UML (Unified Modeling Language) benutzt, weil UML sich als Standardmodellierungssprache für objektorientierte Software-Entwicklung etabliert hat und darüber hinaus die Grundlage für gängige MDA-Werkzeuge darstellt. Die Ablaufbeschreibungen werden in Form von UML-Aktivitätsdiagrammen dargestellt, Detailinformationen werden in UML-Klassendiagrammen modelliert. Das Metamodell Die UML muss um geeignete domänenspezifsche Modellelemente erweitert werden, bspw. zur Beschreibung der Abläufe oder der im Mobiltelefon angezeigten Screens. In MDA wird dazu ein Metamodell benötigt, welches den Sprachumfang der Modellierung festlegt. Für die dynamischen Teile (den groben Ablauf) eignet sich besonders gut ein UML- Aktivitätsdiagramm, welches für unsere Zwecke in seiner Standardform ausreicht. Deshalb ist für dieses Modell eine Erweiterung nicht notwendig (außer um Constraints). Für die statischen Bestandteile (die Interaktionen) eignen sich besonders gut Klassendiagramme, welche aber in ihrer Standardform nicht genügend Semantik mitbringen, um Dienste, Interaktionen, Dienste-Implementierungen, XForms-Elemente usw. zu unterscheiden. Deshalb erweitern wir im UML-Metamodell das Modellelement Klasse und Beziehung. Diese neuen Elemente werden im Folgenden zur Beschreibung von Diensten und Interaktionen benutzt. Abbildung 5 zeigt dieses Metamodell. Forschungsbericht BAMOS

11 Class Association initmethod implclass service interaction contains method xfelement input select select1 output Abbildung 5: Das Metamodell Um die genauen Abhängigkeiten zwischen den neu definierten Elementen formal zu spezifizieren, sind Constraints nötig, welche dann Teil des Metamodells werden. Diese Abhängigkeiten kann man nicht einfach in UML modellieren. Modellierung der Abläufe Für den groben Ablauf eines Dienstes sind normale Aktivitätsdiagramme geeignet, wie beispielhaft in Abbildung 6 dargestellt. In diesem Diagramm werden die Abfolgen der Interaktionen dargestellt, die einen Dienst realisieren. Über Guards an den Transitionen wird festgelegt, unter welchen Umständen welche Transition für die Folge-Interaktion zu verfolgen ist. In dem Beispiel in Abbildung 6 können auf die Interaktion fhstart unterschiedliche Interaktionen folgen. In die Entscheidungsraute führt eine Transition mit der Action /fhstart/choice hinein und aus der Raute heraus mehrere Transitionen mit unterschiedlichen Guards. Dadurch wird festgelegt, dass der Wert in der XForms- Submission in /fhstart/choice den Ausschlag gibt über die Weiterleitung. Sollte keiner der Guard-Werte passen, wird die Default-Transition beschritten. In der Form wird der konkrete Ablauf eines Dienstes modelliert, ohne im Detail festzulegen, wie die einzelnen Interaktionen konkret aussehen. [default] [default] fhstart [default] [default] /fhstart/choice [mensa] [motd] cafeteria [default] cafeteriaday [cafeteria] tram motd [default] motd-info Abbildung 6: Modellierung der Abläufe durch Aktivitätsdiagramme Forschungsbericht BAMOS

12 Modellierung von Views and Interaktionen In dem Aktivitätsdiagramm wurde der grobe Ablauf modelliert, nicht jedoch, wie jede einzelne Interaktion aussieht. Deshalb wählen wir ein erweitertes Klassendiagramm, um die Details eines Dienstes mit seinen Interaktionen abzubilden. Mit Stereotypen werden dabei Klassen semantisch angereichert und somit neue Typen für Service, Interaktion usw. erschaffen. Über Abhängigkeiten werden die einzelnen Typen in Beziehung gesetzt. Abbildung 7 zeigt dieses Diagramm exemplarisch für eine Interaktion. Damit existieren für einen Dienst mehrere dieser Diagramme, und zwar für jede Interaktion genau eins. In dem Beispiel-Diagramm wird folgendes modelliert: Die Service-Klasse (implclass), welche den Zugriffspunkt auf einen Service Provider darstellt, wird an den Dienst (service) gekoppelt und die aufzurufende Methode (method) per contains- Beziehung an die implclass gehängt. An dem Dienst hängt die zu spezifizierende Interaktion (interaction), die wiederum auf die fachliche Methode verweist und mit dem Wurzelelement eines XForms-Modells (xfelement) verbunden ist. Dieses Wurzelelement beinhaltet mehrere Modell-Elemente (xfelement), welche mit einem zusätzlichem Stereotyp die Art des Interaktionselements definieren (z.b. output oder select1). Über die Attribute dieser Elemente werden die Interaktionselemente initialisiert. Die Reihenfolge der Elemente aus dem Screen wird über das order-constraint an der Beziehung zwischen Wurzelelement und Unterelementen festgelegt. Das Mapping zwischen Interaktionselementen und Eingabeparameter für die fachliche Methode wird über eine Abhängigkeit mit Constraint geregelt. In dem Beispiel besagt die 0 an der Abhängigkeit, dass das ausgewählte Element aus dem select1-element choice zum 1. Eingabeparameter der Methode selectfb wird. Somit ist die gesamte Interaktion beschrieben. Weitere Feinheiten (die aus diesem Beispiel nicht hervorgehen) werden hier nicht näher betrachtet. <<service>> fhservice -caption : String = FH-Service <<implclass>> de.fhhannover.fhservice {0=motd} <<contains>> motd -submitlabel : String = Ok! <<method>> selectfb <<xfelement>> motd {0} <<contains>> {order=0} <<xfelement>> <<output>> advice -value : String = Please.. <<contains>> {order=1} <<xfelement>> <<select1>> choice -label : String = MOTDs -labels : List = {Computer... -values: List = {cs,ec,et,ic} Abbildung 7: Modell für eine Beispiel-Interaktion Forschungsbericht BAMOS

13 [default] [default] cafeteria cafeteriaday [default] [mensa] [cafeter i a] fhstart tram /fhstar t/c hoic e [motd] {0} motd [defaul t] motd-info [default] [default] 3.2. Generierung Nachdem die Applikation bzw. der Dienst mit ihrem Ablauf und den Interaktionen modelliert ist, können die Beschreibungen generiert werden, welche zur Laufzeit der Applikation benötigt werden. Dies sind zum einen die Beschreibungen der Oberflächen in XForms, aus denen vom mobilen Gerät zur Laufzeit Oberflächen generiert werden. Zum anderen wird die Ablaufbeschreibung generiert, mit deren Hilfe der Service Broker zur Laufzeit zwischen Adhoc-Client und Service Provider vermittelt. Abbildung 8 zeigt genau diese Transformation. PIM1 PIM2 <xml> <xml> <xml> XForms- <xml> Template XForms- Template XForms- Template XForms- Template PIM-to-PIM- Transformation <xml> workflowdescription Abbildung 8: Transformation zwischen PIMs Aus den Beispielmodellen aus Abbildung 6 und 7, welche einen Teil eines Dienstes modellieren, wird somit ein XForms-Template für die Interaktion und ein Teil der Ablaufbeschreibung generiert. Wie das Generierungsergebnis aus diesen Modellen aussieht, zeigen die Abbildungen 4 und Abbildung 9. <bamos xmlns:xf="http://www.w3.org/2002/xforms"> <xf:model> <xf:instance> <motd> <advice>please choose the Institute!</advice> <choice /> </motd> </xf:instance> <xf:submission xf:id="bspform" /> </xf:model> <xf:output xf:ref="/motd/advice"> <xf:label /> </xf:output> <xf:select1 xf:ref="/motd/choice"> <xf:label>motds</xf:label> <xf:item> <xf:label>computer Science</xf:label> <xf:value>cs</xf:value> </xf:item>... </xf:select1> <xf:submit xf:submission="bspform"> <xf:label>ok!</xf:label> </xf:submit> </bamos> Abbildung 9: Generiertes XForms-Termplate Forschungsbericht BAMOS

14 Es wurden Beschreibungen generiert, die zur Laufzeit benötigt werden. Dazu werden diese im Repository des Service Brokers abgelegt. Es müssen also keine Änderungen am Adhoc- Client vorgenommen werden. Der Service Broker verarbeitet die Ablaufbeschreibung und erstellt dadurch ein Objekt-Geflecht, welches jeden Dienst repräsentiert und die Ausführung des jeweiligen Dienstes ermöglicht. Die eigentliche Fachlichkeit des Dienstes (also der Service Provider) wurde nicht generiert, sondern wird nur aufgerufen. Der Service Broker schickt die XForms-Beschreibung zu einer Interaktion zum Adhoc-Client, wenn der Benutzer zur entsprechenden Interaktion wechselt. Der Adhoc-Client liest diese Beschreibung aus und erstellt daraus eine MIDP-Oberfläche mit Formular, Eingabe- und Ausgabeelementen sowie Commands. Was die Komponenten der Architektur mit welchen generierten Artefakten tun, stellt zusammenfassend die Abbildung 10 dar. PIM2 <xml> <xml> <xml> XForms- <xml> Template XForms- Template XForms- Template XForms- Template <xml> workflowdescription Mobile Client generation at runtime Service Broker Runtime-environment MIDP-Objects: -Forms -Input-/Output-fields -Commands Java-Objects: -implement workflow for every service Abbildung 10: Generierungsprozess zur Laufzeit Damit ist ein Framework geschaffen, welches es ermöglicht, beliebige Service Provider in die Architektur anzubinden, ohne Änderungen am Adhoc-Client vornehmen zu müssen. Somit werden mithilfe von MDA Dienste für mobile Geräte verfügbar gemacht. Wenn die Anbindung von Diensten beschreibbar ist, können diese Beschreibungen modelliert und generiert werden. Dieses Vorgehen hat mehrere Vorteile: - Wenn Beschreibungen den Ablauf von Diensten festlegen, muss die Ablaufsteuerung auf dem Service Broker nicht programmatisch geändert werden, wenn neue Dienste angebunden werden sollen oder sich angebundene Dienste ändern. - Wenn zudem die Oberflächen für den Benutzer am mobilen Gerät mit XForms beschrieben werden, können diese Beschreibungen zur Laufzeit auf das mobile Gerät übertragen werden, so dass die Applikation auf dem mobilen Gerät absolut unabhängig von jeglichen Fachlichkeiten existieren kann. So bedürfen neue oder geänderte Dienste auch keiner Änderung am mobilen Gerät. Dies ermöglicht eine sehr gute Erweiterbarkeit und Einsetzbarkeit in verschiedensten Szenarien. Da diese Beschreibungen in XML vorliegen und damit unhandlich zu erstellen sind, ist die Modellierung und Generierung dieser Beschreibungen der nächste logische Schritt. Mit Hilfe von MDA können diese Beschreibungen dann einfach und intuitiv erstellt werden, so dass ohne detaillierte Kenntnisse der XML-Syntax neue Service Provider angebunden werden können und eine maximale Erweiterbarkeit erreicht wird. Forschungsbericht BAMOS

15 4. Anwendungsszenario Die Tragfähigkeit der entwickelten Basisarchitektur wurde im Projekt anhand des folgenden Anwendungsszenarios nachgewiesen Hardware und Software-Infrastruktur Mobile Endgeräte - Als mobile Endgeräte wurden Mobiltelefone vom Typ Nokia 6600, Siemens S65 oder SonyEricson P910i mit integrierten Java-Bluetooth-Stack (JABWT) und PDAs vom Typ Hewlett Packard IPAQ hx47000 mit Bluetooth-Stack-Implementierung von Avetana eingesetzt. - Auf jedem mobilen Endgerät läuft der generische im Projekt implementierte Adhoc-Client. Der Adhoc-Client ist in der Lage, die auf dem Server abgelegten Dienste- Beschreibungen entgegenzunehmen, anzuzeigen und die zur Dienstnutzung erforderlichen Informationen an den Server zu senden. Server mit Service Broker: - Der Service Broker wurde auf einem Notebook mit integriertem Bluetooth implementiert. - Auf dem Server läuft der in Java implementierte Service Broker. Insgesamt sind im beschriebenen Anwendungsszenario drei einfache Dienste beispielhaft implementiert: 1. Mensaplan Es werden die am aktuellen Tag angebotenen Mensagerichte angezeigt. Der Dienst wurde implementiert, indem der Server die entsprechende Webseite des Studentenwerks aufruft und die Information ausliest. 2. Uestra-Fahrplan Es werden die auf die aktuelle Uhrzeit bezogenen nächsten Abfahrtzeiten der Straßenbahn an der FH-Haltestelle angezeigt. Der Dienst wurde implementiert, indem der Server die entsprechende Webseite der Hannoverschen Verkehrsbetriebe Uestra aufruft und die Information ausliest. 3. Message-of-the-day Es wird zufällig ein Tages-Motto aus einer Menge von gespeicherten Zitaten uns Aussprüchen zurückgeben. - Jeder Service ist beschrieben (a) durch eine entsprechende XForms (siehe Abschnitt 2.2.), die den auf dem mobilen Endgerät angezeigten Screen und die verarbeitenden Daten spezifiziert sowie (b) durch die in XML-Format definierte Ablaufbeschreibung (siehe Abschnitt 2.3), die den Informationsfluss und die Auswahl der anzuzeigenden Screens festlegt. Sämtliche dieser komplexen XML-Spezifikationen können mithilfe von Model Driven Architecture aus semantisch angereicherten UML-Modellen generiert werden Beschreibung des Szenario Sobald ein mobiles Endgerät in die Reichweite des Bluetooth-Netzes des Servers kommt, verbindet es sich spontan mit dem Service Broker, zeigt die zur Verfügung stehenden Dienste an und ermöglicht dem Nutzer einen ausgewählten Dienst zu verwenden. Im Einzelnen finden die folgenden Schritte statt: 1. Spontane Vernetzung Auf dem mobilen Endgerät ist der als J2ME-Java-Programm implementierte Adhoc-Client gestartet. Sobald sich das mobile Endgerät (Telefon oder PDA) in Reichweite des Server-Bluetooth-Netzes befindet, wird automatisch via Bluetooth eine Verbindung zum Service Broker aufgebaut. Forschungsbericht BAMOS

16 2. Service Broker schickt Startseite Der Service Broker schickt nun eine XForms-Startseite an das mobile Endgerät (Abbildung 11): Adhoc Client Service Broker Services: Service overview XForms XForms- Generation o FH-Service o Wetter select XForms- Submit FH-Service chosen Submission- Procession FH-Service XForms Abbildung 11: Austausch von XForms zwischen Adhoc-Client und Service Broker Der Aufbau des XForms-Formats ist komplex und wird in Abbildung 12 angezeigt. Abbildung 12: An Mobilgerät übertragene XForms-Startseite Forschungsbericht BAMOS

17 3. Mobilgerät zeigt Startseite an Das Mobilgerät zeigt nun die Startseite mit Diensteanbietern an, indem der Adhoc-Client die vom Server empfangene XForms-Seite rendert und die angebotenen Diensteanbieter anzeigt (Abbildung 13): Abbildung 13: Screen der angebotenen Dienste 4. Dienstanbieter-Auswahl wird an Server geschickt Im mobilen Endgerät wird nun eine Auswahl eines Dienstanbieters getroffen und nach Drücken des Submit-Buttons die Auswahlentscheidung an den Server gesendet (Abb. 14). Im Beispiel sollen die vom FH-Service angebotenen Dienste angezeigt werden. Abbildung 14: XForms-Submit mit Auswahl des Dienstanbieters an Service Broker 5. Angebotene Dienste werden an Mobilgerät geschickt Der Server wählt anhand der Ablaufbeschreibung die nächste XForms und schickt die entsprechende Übersicht der vom Dienstanbieter angebotenen Dienste an das Forschungsbericht BAMOS

18 Mobilgerät (Abbildung 15). Abbildung 15: Service Broker schickt XForms an Mobilgeräts 6. Mobilgerät wählt einen Dienst Vom Adhoc-Client wird die XForms-Seite ge-rendert und der Nutzer wählt auf dem entsprechenden Screen den gewünschten Dienst (hier uestra). Seine Wahl wird als XForms-Dokument an den Service Broker geschickt (Abb. 16 und 17). Abbildung 16: Screen für Auswahl der Dienste Forschungsbericht BAMOS

19 Abbildung 17: XForms-Submit mit Dienstauswahl 7. Service-Broker schickt Dienst-XForms an Mobilgerät Der Service Broker nimmt die Auswahl in Empfang, wählt anhand der Ablaufbeschreibung des Dienstes die an das Mobilgerät zu schickende XForms aus (Abbildung 18), die dann schließlich am Mobilgerät die gewünschten Informationen anzeigt (Abbildung 19). Forschungsbericht BAMOS

20 Abbildung 18: XForms des Dienstes Abbildung 19: Angezeigter Dienst auf dem mobilen Endgerät Forschungsbericht BAMOS

Innovator 2007. Anbindung an openarchitectureware. Connect. Klaus Weber. www.mid.de

Innovator 2007. Anbindung an openarchitectureware. Connect. Klaus Weber. www.mid.de Innovator 2007 Anbindung an openarchitectureware Klaus Weber Connect www.mid.de Anbindung an openarchitectureware (oaw) Wozu dient die Anbindung an openarchitectureware? Für Innovator Object excellence

Mehr

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1

Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Objektorientierter Software-Entwurf Die Unified Modeling Language 4 1 Die Unified Modeling Language Die UML (hier in der Version 0.9) ist ein Satz von Notationen zur Beschreibung objektorientierter Softwaresysteme.

Mehr

Christian Kurz SWT Projekt WS 07/08

Christian Kurz SWT Projekt WS 07/08 Christian Kurz SWT Projekt WS 07/08 1. Allgemeine Aspekte der generativen GUI- Entwicklung 2. Entwicklung mit Hilfe von GUI-Designern 3. Entwicklung mit Hilfe deklarativer GUI- Sprachen 4. Modellgetriebene

Mehr

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen

Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Modellgetriebene Entwicklung von grafischen Benutzerschnittstellen Stefan Link, Thomas Schuster, Philip Hoyer, Sebastian Abeck Institut für Telematik, Fakultät für Informatik Universität Karlsruhe (TH)

Mehr

Graphischer Editor für die technologieunabhängige User Interface Modellierung

Graphischer Editor für die technologieunabhängige User Interface Modellierung Universität Augsburg Lehrstuhl für Softwaretechnik und Programmiersprachen Prof. Dr. Bernhard Bauer Praktikum Modellgetriebene Softwareentwicklung SS 2008 Graphischer Editor für die technologieunabhängige

Mehr

Modellbasierte Entwicklung von Web Services mit Design by Contract

Modellbasierte Entwicklung von Web Services mit Design by Contract Modellbasierte Entwicklung von Web Services mit Design by Contract Gregor Engels 1,2, Marc Lohmann 1, Stefan Sauer 1,2 1 Institut für Informatik, 2 Software Quality Lab (s-lab) Universität Paderborn, 33095

Mehr

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN

PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN PLATTFORMÜBERGREIFENDE ENTWICKLUNG MITHILFE MODELLGETRIEBENER METHODEN UND TECHNOLOGIEN Mathias Slawik, WI (M), 3. FS Aktuelle Themen der Wirtschaftsinformatik, HTW Berlin, WS 10/11 Gliederung 2 Methode

Mehr

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH

Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme. Tillmann Schall, anaptecs GmbH Modellgetriebene Entwicklungsprozesse in der Praxis - eine Bestandsaufnahme Tillmann Schall, anaptecs GmbH : Agenda Grundlagen modellgetriebener Entwicklungsprozesse Schritte zur Einführung Erfahrungen

Mehr

1 YAWL Yet Another Workflow Language

1 YAWL Yet Another Workflow Language 1 YAWL Yet Another Workflow Language Das YAWL Workflow-Management-System wurde von Wil van der Aalst und seinem Team an der Eindhoven University of Technology entwickelt. Das System ist in seiner jetzigen

Mehr

Model Driven Architecture

Model Driven Architecture { AKTUELLES SCHLAGWORT* / MODEL DRIVEN ARCHITECTURE Model Driven Architecture Martin Kempa Zoltán Ádám Mann Bei der Model Driven Architecture (MDA) bilden Modelle die zentralen Elemente des Softwareentwicklungsprozesses.

Mehr

Modellgetriebene Softwareentwicklung bei der IBYKUS AG

Modellgetriebene Softwareentwicklung bei der IBYKUS AG Modellgetriebene Softwareentwicklung bei der IBYKUS AG Theorie Teil 4: Domänenspezifische Sprachen Dr. Steffen Skatulla IBYKUS AG 1 Inhalt Teil 4: Domänenspezifische Sprachen Nutzung vorhandener Sprachen

Mehr

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten

CORBA-Konzept. Ziele. Common Object Request Broker Architecture CORBA. Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Ziele Common Object Request Broker Architecture CORBA Plattformunabhängige Kommunikation Transparente Verteilung von Objekten CORBA-Konzept Object Management Group Spezifiziert den CORBA-Standard

Mehr

Model Driven Architecture Praxisbeispiel

Model Driven Architecture Praxisbeispiel 1 EJOSA OpenUSS CampusSource Model Driven Architecture Praxisbeispiel 2 Situation von CampusSource-Plattformen Ähnliche Funktionen (Verwaltung von Studenten und Dozenten, Diskussionsforen,...), jedoch

Mehr

Modellierung von Sicherheitsaspekten mit UML. Hauptseminar Softwaretechnologie Modellierung von Sicherheitsaspekten mit UML Florian Heidenreich 2004

Modellierung von Sicherheitsaspekten mit UML. Hauptseminar Softwaretechnologie Modellierung von Sicherheitsaspekten mit UML Florian Heidenreich 2004 Modellierung von Sicherheitsaspekten mit UML 1 1 Übersicht 1 Übersicht 2 Einführung / Motivation 3 Mechanismen zur Erweiterung der UML 4 UMLSec 5 SecureUML 6 Unterstützung durch Tools 7 Zusammenfassung

Mehr

Softwareentwicklung mit UML

Softwareentwicklung mit UML Softwareentwicklung mit UML Die Unified Modeling Language im Projekteinsatz 2.12.2003, Seite 1 Übersicht 1 Einleitung 2 Die Unified Modeling Language (UML) 3 Vorgehensmodelle und UML 4 Ausblick 4.1 UML

Mehr

Effektive Architekturdokumentation mit arc42

Effektive Architekturdokumentation mit arc42 01 Whitepaper: Technologie > Architekturdokumentation Cofinpro die Experten für Kredit und Wertpapier Effektive Architekturdokumentation mit arc42 Inhalt 1 Software-Architektur mit arc42 2 2 arc42 2 3

Mehr

3.9 Grundelemente einer Benutzeroberfläche

3.9 Grundelemente einer Benutzeroberfläche 92 3 Grundlagen einer ios-anwendung 3.8.4 Target-Actions Einer der häufigsten Anwendungsfälle bei einer Oberfläche ist das Betätigen einer Schaltfläche durch einen Anwender, woraufhin eine bestimmte Aktion

Mehr

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014

Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung. Klaus Kusche, September 2014 Die Bedeutung abstrakter Datentypen in der objektorientierten Programmierung Klaus Kusche, September 2014 Inhalt Ziel & Voraussetzungen Was sind abstrakte Datentypen? Was kann man damit grundsätzlich?

Mehr

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme

MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme MDA MDA mit mit Open-Source-Software Eine Eine Bestandsaufnahme Gerhard Wanner (wanner@hft-stuttgart.de) Stefan Stefan Siegl Siegl (s.siegl@novatec-gmbh.de) Agenda Model Driven Architecture (MDA) Einführung/Übersicht/Motivation

Mehr

White Paper. Embedded Treiberframework. Einführung

White Paper. Embedded Treiberframework. Einführung Embedded Treiberframework Einführung White Paper Dieses White Paper beschreibt die Architektur einer Laufzeitumgebung für Gerätetreiber im embedded Umfeld. Dieses Treiberframework ist dabei auf jede embedded

Mehr

Die nächste Revolution in der modelgetriebenen Entwicklung?

Die nächste Revolution in der modelgetriebenen Entwicklung? Die nächste Revolution in der modelgetriebenen Entwicklung? Me Johannes Kleiber Software Engineer bei FMC Johannes.Kleiber@fmc-ag.com Themen Überblick Window Workflow Foundation Workflows modellieren WF

Mehr

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer

Klausur Kommunikation I. Sommersemester 2003. Dipl.-Ing. T. Kloepfer Kommunikation I 1 Klausur Kommunikation I Sommersemester 2003 Dipl.-Ing. T. Kloepfer Bearbeitungsinformationen Aufbau der Klausur Die Klausur ist wie folgt aufgebaut: Die Klausur ist in 18 Aufgaben unterteilt.

Mehr

Web 2.0 Software-Architekturen

Web 2.0 Software-Architekturen Web 2.0 Software-Architekturen Servlets als Controller einer MVC Web Architektur Prof. Dr. Nikolaus Wulff HTTP und HTML Das HyperText TransferProtokoll (HTTP) beschreibt eine einfache verbindungslose Kommunikation,

Mehr

Software Engineering II

Software Engineering II Software Engineering II Codegenerierung für den SmartIO Editor mit der Modeling Workflow Engine Wintersemester 10/111 Fachgebiet Software Engineering Albert Zündorf / Wiederholung Bisher im Laufe des Semesters

Mehr

3. Konzepte der objektorientierten Programmierung

3. Konzepte der objektorientierten Programmierung 3. Konzepte der objektorientierten Programmierung 3.1 Basiskonzepte 3.2 Generalisierung / Spezialisierung 3.3 Aggregation 3.4 Assoziation 3.5 Nachrichten 3.6 Polymorphismus 3. Konzepte der Objektorientierung

Mehr

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle

Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Konzeption und Realisierung eines logikbasierten Anfragewerkzeugs für UML-Modelle Doktoranden-, Diplomandenseminar, Institut für Informatik, TU Clausthal 23. Juni 2009 Motivation: Modelle werden in der

Mehr

Projekt AGB-10 Fremdprojektanalyse

Projekt AGB-10 Fremdprojektanalyse Projekt AGB-10 Fremdprojektanalyse 17. Mai 2010 1 Inhaltsverzeichnis 1 Allgemeines 3 2 Produktübersicht 3 3 Grundsätzliche Struktur und Entwurfsprinzipien für das Gesamtsystem 3 3.1 Die Prefuse Library...............................

Mehr

Modellgetriebene Softwareentwicklung (Model Driven Software Development - MDSD) SS 2014

Modellgetriebene Softwareentwicklung (Model Driven Software Development - MDSD) SS 2014 Modellgetriebene Softwareentwicklung (Model Driven Software Development - MDSD) SS 2014 Wahlpflichtfach (2 SWS) für Bachelor Andreas Schmidt Einführung/Organisation 1/19 Ziele der Vorlesung Vorstellung

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Paynet Adapter Spezifikationen Voraussetzungen Datum : 21.07.08 Version : 1.0.0.2 21.07.2008 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung... 3 2 Architektur... 3 2.1 Grundsätze

Mehr

objectif / SOA /.NET Inhalt Technologien ObjectiF Beispiel Vergleich: ObjectiF Rational Rose Quellenverzeichnis 20.01.2008 Christian Reichardt 2 Technologien 20.01.2008 Christian Reichardt 3 Methodenaufruf

Mehr

Spezifikationen und Voraussetzung

Spezifikationen und Voraussetzung Projekt IGH DataExpert Yellowbill Adapter Spezifikationen Voraussetzungen Datum : 22.08.2013 Version : 1.0.0.2 22.08.2013 Seite 1 von 7 Inhaltsverzeichnis 1 Einleitung...3 2 Architektur...3 2.1 Grundsätze

Mehr

Von SAP R/3 zu mysap ERP und NetWeaver

Von SAP R/3 zu mysap ERP und NetWeaver Von SAP R/3 zu mysap ERP und NetWeaver Bremerhaven 06.05.2006 T4T Bremerhaven 1 Inhaltsverzeichnis 1. Motivation für SAP NetWeaver 2. SAP R/3 mysap ERP und SAP Business Suite 3. Application Platform T4T

Mehr

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de

Fortgeschrittene Servlet- Techniken. Ralf Gitzel ralf_gitzel@hotmail.de Fortgeschrittene Servlet- Techniken Ralf Gitzel ralf_gitzel@hotmail.de 1 Themenübersicht Ralf Gitzel ralf_gitzel@hotmail.de 2 Übersicht Servlet Initialisierung Attribute und Gültigkeitsbereiche Sessions

Mehr

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges

Agenda. Clients aus drei verschiedenen Perspektiven: Was ist ein Dialog? Komponentenarchitektur innerhalb eines Dialoges Komponentenbasierte Client-Architektur Hamburg, 16.11.2007 Bernd Olleck IT-Beratung Olleck Agenda Clients aus drei verschiedenen Perspektiven: Technische Infrastruktur Fachliche Sicht Aufgaben eines Clients

Mehr

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft

Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Einbindung eines Buchungs- und Ticketingsystems in eine bestehende Anwendungslandschaft Harald Lange sd&m Lübecker Str. 1 22087 Hamburg harald.lange@sdm.de Abstract: Mit der Einführung eines Buchungs-

Mehr

KM - Knowledge Management. SAP ERP Central Component

KM - Knowledge Management. SAP ERP Central Component KM - Knowledge Management SAP ERP Central Component Release 5.0 Release-Informationen Copyright 2004 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen

Mehr

Buzzword Bingo Game Documentation (Java based Game)

Buzzword Bingo Game Documentation (Java based Game) Buzzword Bingo Game Documentation (Java based Game) Meppe Patrick Djeufack Stella Beltran Daniel April 15, 2011 1 Inhaltsverzeichnis 1 Einleitung 3 2 Aufgabenstellung 3 3 Allgemeines zu Buzzword Bingo

Mehr

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG

ALM mit Visual Studio Online. Philip Gossweiler Noser Engineering AG ALM mit Visual Studio Online Philip Gossweiler Noser Engineering AG Was ist Visual Studio Online? Visual Studio Online hiess bis November 2013 Team Foundation Service Kernstück von Visual Studio Online

Mehr

Inhaltsübersicht. n Aufgabenstellung. n Lösungsüberblick. n Herausforderungen. n Entwicklung der Generatoren. n Zusammenfassung/Schlussfolgerungen

Inhaltsübersicht. n Aufgabenstellung. n Lösungsüberblick. n Herausforderungen. n Entwicklung der Generatoren. n Zusammenfassung/Schlussfolgerungen Dr. Christoph Niemann otris software AG Königswall 21 D-44137 Dortmund Tel. +49 (0)231 958069 0 www.otris.de Modellgetriebene Entwicklung eines WLAN-Management- Systems copyright by by otris software AG:

Mehr

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete

Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems. Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Allgemeines 2 Produktübersicht 2 Grundsätzliche Struktur und Entwurfsprinzipien des Gesamtsystems 3 Grundsätzliche Struktur und Entwurfsprinzipien der einzelnen Pakete Account-Verwaltung 5 Freund-Funktionen

Mehr

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner

Proseminar Website-Management-Systeme ZOPE/CMF. Andreas M. Weiner Proseminar Website-Management-Systeme ZOPE/CMF Andreas M. Weiner Technische Universität Kaiserslautern Fachbereich Informatik Arbeitsgruppe Softwaretechnik Betreuer: Dipl. Inf. Christian Stenzel Überblick

Mehr

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems

SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems SoaML-basierter Entwurf eines dienstorientierten Überwachungssystems Michael Gebhart (1), Jürgen Moßgraber (2), Thomas Usländer (2), Sebastian Abeck (1) (2) (1) Cooperation & Management, Karlsruher Institut

Mehr

Modellgetriebene Softwareentwicklung

Modellgetriebene Softwareentwicklung Modellgetriebene Softwareentwicklung 30.10.2008 Dr. Georg Pietrek, itemis AG Inhalt Wer ist itemis? Modellgetriebene Entwicklung Ein Praxis-Beispiel Fazit 2 Vorstellung IT-Dienstleister Software-Entwicklung

Mehr

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann

Model Driven SOA. < J Springer. Anwendungsorientierte Methodik und Vorgehen in der Praxis. Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Gerhard Rempp Mark Akermann Martin Löffler Jens Lehmann Model Driven SOA Anwendungsorientierte Methodik und Vorgehen in der Praxis Mit Illustrationen von Martin Starzmann < J Springer Inhaltsverzeichnis

Mehr

5. Übung zur Vorlesung Service-orientierte Architekturen

5. Übung zur Vorlesung Service-orientierte Architekturen 5. Übung zur Vorlesung Service-orientierte Architekturen Webservices und WSDL SoSe 2011 Anmerkung Hausaufgabe 03 BPMN Auch hier gilt: Layout! Zu Unterschieden zw. BPMN und eepk Relative Aussagen sind geschickter

Mehr

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA

Liste der Handbücher. Liste der Benutzerhandbücher von MEGA Liste der Handbücher Liste der Benutzerhandbücher von MEGA MEGA 2009 SP4 1. Ausgabe (Juni 2010) Die in diesem Dokument enthaltenen Informationen können jederzeit ohne vorherige Ankündigung geändert werden

Mehr

Service-Orientierte Architekturen

Service-Orientierte Architekturen Hochschule Bonn-Rhein-Sieg Service-Orientierte Architekturen Kapitel 2: Einführung in Service-Orientierte Architekturen Vorlesung im Masterstudiengang Informatik Sommersemester 2010 Prof. Dr. Sascha Alda

Mehr

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse

Andreas Lux 16.03.2010. Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Andreas Lux 16.03.2010 Verknüpfung unterschiedlicher Modellsprachen (BPMN, UML, DSL) zur Anforderungsanalyse Warum unterschiedliche Sprachen? Nicht alle Probleme eignen sich, um mit Standardsprachen beschrieben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

Kapitel 6. Vererbung

Kapitel 6. Vererbung 1 Kapitel 6 2 Ziele Das sprinzip der objektorientierten Programmierung verstehen Und in Java umsetzen können Insbesondere folgende Begriffe verstehen und anwenden können: Ober/Unterklassen Subtyping Überschreiben

Mehr

SECTINO. Security for Inter-Organizational Workflows

SECTINO. Security for Inter-Organizational Workflows SECTINO Security for Inter-Organizational Workflows Framework zur Modellierung und Realsisierung sicherheitskritischer organisationsübergreifender Workflows Kooperation Research Group Quality Engineering

Mehr

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg

Modellgetriebene Softwareentwicklung von mobilen Anwendungen. Gabriele Taentzer WS 2014/15 Philipps-Universität Marburg Modellgetriebene Softwareentwicklung von mobilen Anwendungen WS 2014/15 Philipps-Universität Marburg Organisation der LV Umfang: 6 SWS, 9 ECTS Punkte Veranstalter:, Daniel Strüber, Steffen Vaupel Kontakt:

Mehr

Inhaltsverzeichnis. xiii

Inhaltsverzeichnis. xiii Inhaltsverzeichnis 1 Einleitung... 1 1.1 Ausgangslage und Zielsetzung des Buches...2 1.2 Was ist Software-Architektur?...8 1.3 Leser-Leitfaden... 11 1.3.1 Buchaufbau... 11 1.3.2 Zielpublikum... 15 1.3.3

Mehr

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de

Beispielhaft MDSD in der Praxis. Dr. Shota Okujava shota.okujava@isento.de www.isento.de Beispielhaft MDSD in der Praxis Dr. Shota Okujava shota.okujava@isento.de www.isento.de Agenda Einführung Softwareentwicklungsprozess und MDSD Technologien und Werkzeuge Demo Entwicklung der Metamodelle

Mehr

xcall Technische Dokumentation

xcall Technische Dokumentation xcall Technische Dokumentation zu Version 4.x Autor: Martin Roth Erstelldatum: 14.08.2008 Version: 1.4 Seite 2 / 7 Zweck...3 Schnittstellenarchitektur...3 Outbound-Schnittstellen...3 Outlook...3 TwixTel...3

Mehr

Remote Communications

Remote Communications HELP.BCFESDEI Release 4.6C SAP AG Copyright Copyright 2001 SAP AG. Alle Rechte vorbehalten. Weitergabe und Vervielfältigung dieser Publikation oder von Teilen daraus sind, zu welchem Zweck und in welcher

Mehr

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann

Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Data Lineage goes Traceability - oder was Requirements Engineering von Business Intelligence lernen kann Andreas Ditze MID GmbH Kressengartenstraße 10 90402 Nürnberg a.ditze@mid.de Abstract: Data Lineage

Mehr

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de

FH LU JEE Vorlesung SS 2014. Ralf Gitzel ralf_gitzel@hotmail.de FH LU JEE Vorlesung SS 2014 Ralf Gitzel ralf_gitzel@hotmail.de 1 Einführung + Organisatorisches Ralf Gitzel ralf_gitzel@hotmail.de 2 Dozent Dr. Ralf Gitzel Promotion an der Universität Mannheim in Wirtschaftsinformatik

Mehr

Übungen zur Android Entwicklung

Übungen zur Android Entwicklung Übungen zur Android Entwicklung Aufgabe 1 Hello World Entwickeln Sie eine Hello World Android Applikation und laden diese auf den Emulator. Leiten Sie hierfür die Klasse android.app.activity ab und entwerfen

Mehr

Von der UML nach C++

Von der UML nach C++ 22 Von der UML nach C++ Dieses Kapitel behandelt die folgenden Themen: Vererbung Interfaces Assoziationen Multiplizität Aggregation Komposition Die Unified Modeling Language (UML) ist eine weit verbreitete

Mehr

Workflow, Business Process Management, 4.Teil

Workflow, Business Process Management, 4.Teil Workflow, Business Process Management, 4.Teil 24. Januar 2004 Der vorliegende Text darf für Zwecke der Vorlesung Workflow, Business Process Management des Autors vervielfältigt werden. Eine weitere Nutzung

Mehr

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung

Software-Qualität im Rahmen modellgetriebener Softwareentwicklung Software-Qualität im Rahmen modellgetriebener Softwareentwicklung OFFIS Technologiecluster Enterprise Application Integration niels.streekmann@offis.de 09.07.2008 Seite 1 / 13 Software-Qualität: Unterschiedliche

Mehr

0. Inhaltsverzeichnis

0. Inhaltsverzeichnis 0. Inhaltsverzeichnis 0. Inhaltsverzeichnis...1 1. Kurze Einführung WebService Architektur...2 1.1 Synchrones Modell:...2 1.2 Asynchrones Modell:...2 1.3 Vorteile:...3 1.4 Voraussetzungen...3 2. Testseite

Mehr

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design

Design im Softwareentwicklungsprozess. Stand der Dinge & Designziel. fachliche & technische Architektur. generelles Vorgehen bei Grob-Design Design im Softwareentwicklungsprozess traditionell Geschäftsprozessmodellierung Requirements Engineering Analyse Design Implementierung Tests Design 1 test-getrieben: nur 1. Design top-down hier testgetrieben

Mehr

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen.

In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. 181 In diesem Kapitel werden wir nun mehrere Anwendungen von XML in der betrieblichen Praxis vorstellen. Sie sollen XML bei der Arbeit zeigen. Wir beginnen mit dem Startup-Unternehmen Seals GmbH aus Frankfurt,

Mehr

Softwareentwicklung mit Enterprise JAVA Beans

Softwareentwicklung mit Enterprise JAVA Beans Softwareentwicklung mit Enterprise JAVA Beans Java Enterprise Edition - Überblick Was ist J2EE Java EE? Zunächst mal: Eine Menge von Spezifikationen und Regeln. April 1997: SUN initiiert die Entwicklung

Mehr

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG

YAKINDU Requirements. Requirements Engineering, Management and Traceability with Eclipse. Lars Martin, itemis AG. itemis AG YAKINDU Requirements Requirements Engineering, Management and Traceability with Eclipse Lars Martin, itemis AG Agenda YAKINDU Requirements Motivation: Warum Requirements Engineering? Grundlagen: Requirements

Mehr

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses

Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Anwendernahe Wissensmodellierung mittels Logikregeln in frühen Phasen des Softwareentwicklungsprozesses Gunter Grieser, Simon Spielmann, Guido Schuh, Boris Kötting, Ralf Leonhard AGENDA Das Projekt Unser

Mehr

Integration Services - Dienstarchitektur

Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Integration Services - Dienstarchitektur Dieser Artikel solle dabei unterstützen, Integration Services in Microsoft SQL Server be sser zu verstehen und damit die

Mehr

Ein hierarchischer, modellgetriebener Ansatz zur Codegenerierung. R. Gitzel, M. Schwind

Ein hierarchischer, modellgetriebener Ansatz zur Codegenerierung. R. Gitzel, M. Schwind Ein hierarchischer, modellgetriebener Ansatz zur Codegenerierung R. Gitzel, M. Schwind Agenda! Überblick/Motivation! Hintergrund! Technische Umsetzung! Zentrale Ergebnisse 2 Überblick Ziele! Know-how-Aufbau/Stand

Mehr

UML Diagramme. Aktivitätsdiagramm

UML Diagramme. Aktivitätsdiagramm Di, 15. April 2008 Thema: Requirements Techniken (Teil 3) Vorlesung von David Kurmann Autor: Oliver Röösli oliver.roeoesli@stud.fhz.ch UML Diagramme Aktivitätsdiagramm Das Aktivitätsdiagramm (engl. activity

Mehr

Web-Anwendungsentwicklung mit dem Delivery Server

Web-Anwendungsentwicklung mit dem Delivery Server Web-Anwendungsentwicklung mit dem Delivery Server Java-Framework auf Basis der Open API Bernfried Howe, Webertise Consulting GmbH WEBertise Consulting Dipl. Informatiker (Wirtschaftsinformatik) 2001-2010

Mehr

Datenhaltung für Android Model First. 30.03.2011 Christian Ingenhaag, Frederik Götz, Carl Steeg

Datenhaltung für Android Model First. 30.03.2011 Christian Ingenhaag, Frederik Götz, Carl Steeg Datenhaltung für Android Model First 30.03.2011 Christian Ingenhaag, Frederik Götz, Carl Steeg Agenda Datenhaltung in Android Motivation / Projektziele Projekt Umsetzung Stand der Entwicklung Fazit 2 Datenhaltung

Mehr

Client/Server-Systeme

Client/Server-Systeme Fachbereich Informatik Projektgruppe KOSI Kooperative Spiele im Internet Client/Server-Systeme Vortragender Jan-Ole Janssen 26. November 2000 Übersicht Teil 1 Das Client/Server-Konzept Teil 2 Client/Server-Architekturen

Mehr

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt. Software Engineering Dokumentation von Softwarearchitekturen Die Inhalte der Vorlesung wurden primär auf Basis der Vorlesung Software Engineering von Prof. Dr. Faustmann (FHW Berlin Fachbereich II) erstellt.

Mehr

Model Driven Development einige wichtige Grundprinzipien

Model Driven Development einige wichtige Grundprinzipien Model Driven Development einige wichtige Grundprinzipien Johannes Scheier j@scheier software.ch Copyright by Scheier Software Engineering Seite 1 Inhalt Was ist Model Driven Development (MDD)? Was verspricht

Mehr

Generieren von Nodelock Lizenzen. Hilfe für www.intergraph.com/sgi/license

Generieren von Nodelock Lizenzen. Hilfe für www.intergraph.com/sgi/license Generieren von Nodelock Lizenzen Hilfe für www.intergraph.com/sgi/license SG&I Lizenzen April 2010 2010 Intergraph SG&I Deutschland GmbH. Alle Rechte vorbehalten. Der Inhalt dieses Dokuments ist urheberrechtlich

Mehr

Gefahren aus dem Internet 1 Grundwissen April 2010

Gefahren aus dem Internet 1 Grundwissen April 2010 1 Grundwissen Voraussetzungen Sie haben das Internet bereits zuhause oder an der Schule genutzt. Sie wissen, was ein Provider ist. Sie wissen, was eine URL ist. Lernziele Sie wissen, was es braucht, damit

Mehr

Praktikum Internetprotokolle - POP3

Praktikum Internetprotokolle - POP3 Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik/Rechnernetze 19. Mai 2008 1 Aufgabenstellung Praktikum

Mehr

Entwicklung von Web-Anwendungen auf JAVA EE Basis

Entwicklung von Web-Anwendungen auf JAVA EE Basis Entwicklung von Web-Anwendungen auf JAVA EE Basis Java Enterprise Edition - Überblick Prof. Dr. Bernhard Schiefer Inhalt der Veranstaltung Überblick Java EE JDBC, JPA, JNDI Servlets, Java Server Pages

Mehr

Usability-Test für mobile Java-Anwendungen

Usability-Test für mobile Java-Anwendungen Usability-Test für mobile Java-Anwendungen Problemstellung / Abgrenzung Usability Engineering / Patterns Usability Test Tool-Kette Fazit Roland Petrasch Usability-Test für mobile Java-Anwendungen Problemstellung

Mehr

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696

Dokumentation zum Projekt Mail-Adapter in SAP PI. 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Dokumentation zum Projekt Mail-Adapter in SAP PI 17.01.2011 Sinkwitz, Sven 519707 Theel, Thomas 519696 Inhalt 1. Einleitung... 2 2. Vorgehen... 3 1. Datentyp für die Mail einrichten... 3 2. Message Typen

Mehr

Glossarverwaltung GV3

Glossarverwaltung GV3 Glossarverwaltung GV3 Designbeschreibung VQWiki Leszek Kotas Sebastian Knappe Gerrit Mattausch Raimund Rönn 23. Mai 2004 Inhaltsverzeichnis 1 Allgemeines 3 1.1 Kurzcharakteristik.................................

Mehr

Das Interceptor Muster

Das Interceptor Muster Das Interceptor Muster Implementierung des Interceptor Musters basierend auf OSGi and Friends Benjamin Friedrich Hochschule für Technik und Wirtschaft des Saarlandes Praktische Informatik - Entwurfsmuster

Mehr

Elektronische Vollmachten - Demonstrator

Elektronische Vollmachten - Demonstrator www.egiz.gv.at E-Mail: post@egiz.gv.at Telefon: ++43 (316) 873 5514 Fax: ++43 (316) 873 5520 Inffeldgasse 16a / 8010 Graz / Austria Elektronische Vollmachten - Demonstrator Version 1.0.0, 09.01.2007 DI

Mehr

Integrating Architecture Apps for the Enterprise

Integrating Architecture Apps for the Enterprise Integrating Architecture Apps for the Enterprise Ein einheitliches Modulsystem für verteilte Unternehmensanwendungen Motivation und Grundkonzept Inhalt Problem Ursache Herausforderung Grundgedanke Architektur

Mehr

Konzept / Architektur Diagramme

Konzept / Architektur Diagramme Architektur-Modell Konzept / Architektur Diagramme Im Übergang Analyse Design wird das System konzipiert und seine Architektur entworfen: Subsystem-Modell (execution view) UML 1.x Package Diagram «subsystem»

Mehr

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte

Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Integration mobiler Endgeräte in Medizinprodukte und Medizintechnik-nahe Produkte Agenda Problemstellung Medizinprodukt App Grundlagen Szenarien (Problemstellungen und Lösungsansätze) 03.06.2013 2 Innovationen

Mehr

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen

SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen Daniel Liebhart SOA goes real Service-orientierte Architekturen erfolgreich planen und einführen ISBN-10: 3-446-41088-0 ISBN-13: 978-3-446-41088-6 Inhaltsverzeichnis Weitere Informationen oder Bestellungen

Mehr

Rechnernetze Projekt SS 2015

Rechnernetze Projekt SS 2015 30/03/15 Seite 1 Aspektorientierte Programmierung logische Aspekte (Concerns) im Programm separieren Crosscutting Concerns (Ziel: generische Funktionalitäten über mehrere Klassen hinweg zu verwenden -

Mehr

Übungen zur Softwaretechnik

Übungen zur Softwaretechnik Technische Universität München Fakultät für Informatik Lehrstuhl IV: Software & Systems Engineering Markus Pister, Dr. Bernhard Rumpe WS 2002/2003 Lösungsblatt 1 17. Oktober 2002 www4.in.tum.de/~rumpe/se

Mehr

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme

Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Mobile Agenten am Beispiel JADE (Java Agent DEvelopment Framework) Vorstellung in der Übung zu Konzepte Verteilter Systeme Agenda Mobile Agenten allgemein JADE - Java Agent DEvelopment Framework Anwendungsfall

Mehr

Sensordaten mit SNMP verteilen

Sensordaten mit SNMP verteilen Sensordaten mit SNMP verteilen Axel Wachtler und Ralf Findeisen Chemnitzer Linux Tage 17.03.2013 Einleitung Systembeschreibung Was ist SNMP? Implementierung Demo Ausblick Systemüberblick Sensor- und Gatewayknoten

Mehr

Techniken der Projektentwicklungen

Techniken der Projektentwicklungen Von der Analyse zum Entwurf 5. Termin Vom Use Case zum Domänenmodell Bis zum nächsten Mal Vom Use Case zum Domänenmodell Vom Use Case zum Domänenmodell Was ist ein Domänenmodell? Graphische Beschreibung

Mehr

Design by Contract zur semantischen Beschreibung von Web Services

Design by Contract zur semantischen Beschreibung von Web Services Design by Contract zur semantischen Beschreibung von Web Services Gregor Engels 1, Marc Lohmann 1, Stefan Sauer 2 1 Institut für Informatik, 2 Software Quality Lab (s-lab) Universität Paderborn, 33095

Mehr

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1

Präsentation. homevisu Familie. Peter Beck. Juni 2011. www.p-b-e.de. 2011 p b e Peter Beck 1 Präsentation homevisu Familie Peter Beck Juni 2011 2011 p b e Peter Beck 1 Funktionensumfang Der Funktionsumfang das provisu Framework. Modular und durch Plug-In erweiterbar / anpassbar. Plug-In Schnittstelle

Mehr

Aktuelle Sicherheitsprobleme im Internet

Aktuelle Sicherheitsprobleme im Internet Herbst 2014 Aktuelle Sicherheitsprobleme im Internet Wirtschaftsinformatik: 5. Semester Dozenten: Rainer Telesko / Martin Hüsler Fachhochschule Nordwestschweiz FHNW / Rainer Telesko - Martin Hüsler 1 Inhalt

Mehr

Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse

Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse Qargo.com Qargo X - Online Freight-Exchange-System - Frachtenbörse Dokumentation Version: 1.0 Stand: 08.08.2008 Seite 1 von 16 Inhaltsverzeichnis 1 Erste Schritte... 3 1.1 Über qargo x... 3 1.2 Installation...

Mehr

Ergebnisdienst. Inline Speedskating Competition Software. Inline Speedskating Competition Software Dokumentation Ergebnisdienst

Ergebnisdienst. Inline Speedskating Competition Software. Inline Speedskating Competition Software Dokumentation Ergebnisdienst Inline Speedskating Competition Software Ergebnisdienst Be presented in the Web Rainer Keppeler Klingäckerstr. 51/1 72766 Reutlingen rainer.skater@t-online.de Datenfluss Definition Wettkampfklassen, Setzen,

Mehr