Masterarbeit. Entwicklung eines graphischen Werkzeugs zum Rapid Protoyping von CEP (Complex-Event Processing)-Systemen.

Größe: px
Ab Seite anzeigen:

Download "Masterarbeit. Entwicklung eines graphischen Werkzeugs zum Rapid Protoyping von CEP (Complex-Event Processing)-Systemen."

Transkript

1 Masterarbeit Entwicklung eines graphischen Werkzeugs zum Rapid Protoyping von CEP (Complex-Event Processing)-Systemen Christoph Wiens Matrikelnummer: September 2011 Erstprüfer: Zweitprüfer: Prof. Dr. Jürgen Dunkel Prof. Dr. Ralf Bruns

2 Selbstständigkeitserklärung Hiermit erkläre ich, dass ich die eingereichte Masterarbeit selbstständig und ohne fremde Hilfe verfasst, andere als die von mir angegebenen Quellen und Hilfsmittel nicht benutzt und die den benutzten Werken wörtlich oder inhaltlich entnommenen Stellen als solche kenntlich gemacht habe. Hannover, den Christoph Wiens

3 Inhaltsverzeichnis 1 Einleitung Motivation Ziel der Arbeit Aufbau Anwendungsbeispiel SWE-Prozess für eine Event-Driven-Architecture Schritt 1: Ereignisquellen Schritt 1.1: Externe Ereignisquellen identifizieren Schritt 1.2: Ereignistypen spezifizieren Schritt 1.3: Mengengerüste festlegen Schritt 2: Ereignismodell Schritt 2.1: Relationen definieren Schritt 2.2: Ereignishierarchie aufbauen Schritt 2.3: Constraints festlegen Schritt 3: Ereignismuster und -regeln Schritt 3.1: Ereignistypen selektieren Schritt 3.2: Restriktionen bestimmen Schritt 3.3: Ereignis- bzw. Beziehungsmuster ermitteln Schritt 3.4: Zusammengesetzte bzw. komplexe Ereignisse definieren Schritt 4: Event Processing Network Schritt 4.1: Regeln fachlich kohärent gruppieren Schritt 4.2: Regelgruppen EPAs zuordnen Schritt 4.3: Agentennetz konstruieren Schritt 5: Physikalische Verteilung Schritt 5.1: Anforderungen spezifizieren Schritt 5.2: Verteilungsmodell entwerfen Schritt 6: Ereignisbehandlung Schritt 6.1: Prozesse, Aktionen oder Dienste anstoßen bzw. aufrufen Schritt 6.2: Neue Ereignisse erzeugen Anforderungsanalyse Spezifikation von Ereignistypen Konstruktion eines EPNs und Definition von Regeln Definition von Event Processing Agents (EPA) Grafische Spezifikation von Regeln Ereigniserzeugung Visualisierung Konzeptionelle Umsetzung der Anforderungen Definition von Ereignistypen mithilfe der UML Aufbau des EPNs Die grafische Sprache zur Regelerstellung Bestimmung der Ereignistypinstanzen

4 4.3.2 Spezifikation von Restriktionen Definition eines Patterns Erstellung eines neuen Ereignisses Bewertung der grafischen Regelsprache Benutzerdefinierte Generierung von Ereignissen Darstellung und Überprüfung der resultierenden EDA Aufbau der Software Die Architektur im Überblick Die Anwendungslogikschicht Ereignis- und Datentypen Agenten Regeln Die grafische Benutzeroberfläche Spezifikation von Ereignistypen Konstruktion eines EPNs und Definition von Regeln Ereigniserzeugung Visualisierung Der UML-Editor Violet Fazit und Ausblick 57 Literatur 60

5 Abkürzungsverzeichnis AST Abstract Syntax Tree BPMN Business Process Model and Notation CEP DSL Complex Event Processing Domain Specific Language DSM Domain Specific Model EDA EPA EPL EPN ESP Event-Driven Architecture Event Processing Agent Event Processing Language Event Processing Network Event Stream Processing MDSD Model Driven Software Development POJOs Plain Old Java Objects RAD Rapid Application Development SQL Structured Query Language UML Unified Modeling Language XML Extensible Markup Language

6 1 Einleitung 1 1 Einleitung Im Folgenden sind einige einleitende Sätze über die Motivation (Abschnitt 1.1), das Ziel (Abschnitt 1.2) und den allgemeinen Aufbau (Abschnitt 1.3) dieser Masterarbeit zu lesen. Sie geben dem Leser eine kurze Einführung zu den Grundgedanken einer ereignisgesteuerten Software-Architektur und über die Aufgabenstellung dieser Arbeit. 1.1 Motivation Damit ein modernes Unternehmen erfolgreich wirtschaften kann, sollte es einige Faktoren beachten. Wichtig ist vor allem eine hohe Agilität und Effizienz in den betrieblichen Geschäftsprozessen [vgl. [3], S. 3] zu bewahren. Dazu gehört bspw. ein produktiver Informationsfluss und ein schnelles Reaktionsvermögen auf Nachrichten verschiedenster Art. Ganz allgemein gestaltet sich die Reaktion auf eine Nachricht in der Regel nach folgendem Ablauf: die Nachricht wird zunächst erkannt, danach verarbeitet und zuletzt wird nach bestimmten Regeln darauf reagiert. Eine Nachricht an sich ist auch ein Ereignis. Ein Ereignis kann eine einfache sein, aber auch die Benachrichtigung über ein fertig gestelltes Produkt oder das Auslesen eines Messwertes an einem Gerät, um nur ein paar wenige Beispiele zu nennen. Die wichtige Erkenntnis ist, dass alles, was passiert, als ein Ereignis deklariert werden kann. Es lässt sich sagen, dass die Welt an sich ereignisgesteuert ist, was allerdings bei vielen Applikationen, die entwickelt werden, keine große Beachtung findet. Diesem Gedanken entsprang nun vor einigen Jahren die Idee der Event-Driven Architecture (EDA). Sie schafft sich einen Vorteil aus dem Konzept des Complex Event Processing (CEP) [12] und führt zu folgender Definition: EDA und CEP repräsentieren einen neuen Stil von Unternehmensanwendungen, bei dem Ereignisse in das Zentrum der Softwarearchitektur rücken - Ereignisorientierung als Architekturstil. [[3], S. 4] EDA ist ein Architekturstil und beschreibt im Vergleich zu der Softwaretechnologie CEP ein allgemeineres Verfahren. CEP wird als die zentrale Technologie für eine EDA eingesetzt und kann somit als Kernbestandteil einer EDA angesehen werden (vgl. [3], S.4). Ereignisse treten in vielen unterschiedlichen Formen und zu unterschiedlichen Zeitpunkten auf, so dass ein Strom von Ereignissen entsteht. In einer EDA werden CEP-Anwendungen dazu benutzt, solch einen Strom zu untersuchen und Ereignisse zu erkennen. CEP-Anwendungen an sich folgen zunächst dem gleichen Prinzip, welches schon weiter oben im Text dargestellt wurde. Tritt nämlich ein Ereignis auf, so wird dieses erkannt, anschließend verarbeitet und zuletzt erfolgt eine Reaktion darauf. Ein Ereignis allein sagt allerdings häufig nicht viel aus, so dass nicht nur einzelne Ereignisse erkannt werden sollen, sondern ganze Muster von Ereignissen. Oft kann nämlich erst im Zusammenhang mit anderen Ereignissen ein einzelnes Ereignis eine Aussagekraft entwickeln. Um nun Muster, die in einem Strom von Ereignissen erkannt werden sollen, und entsprechende Reaktionen darauf zu bestimmen, bieten CEP-Engines die Möglichkeit Regeln zu definieren. Das Hauptaugenmerk bei einer CEP-Anwendung liegt demzufolge bei eben diesem Definieren von Regeln, wozu meist eine eigene Sprache verwendet wird. Bei der CEP-Engine Esper [7] ist diese Sprache bspw. sehr stark an die Syntax von der Structured Query Language (SQL) angelegt. Dies verrät schon, dass gewisse Vorkenntnisse von Vorteil sind, um eigene Regeln zu spezifizieren. Ein weiteres Beispiel ist die Regelsprache der CEP-Engine Drools Fusion [11], bei der Vorkenntnisse aus der objektorientierten Programmierung nützlich sind. Generell ist diese Materie also eher Experten vorbehalten, so dass es für

7 1 Einleitung 2 Laien kaum möglich ist, eigene Regeln zu einer CEP-Anwendung beizusteuern. Wird nun aber bspw. der Aktienmarkt mittels einer EDA überwacht und ein Aktienhändler möchte für sich eine eigene Regel definieren, so wird dieses Vorhaben sehr schwierig, da er sich erst sehr stark mit der Erstellung von Regeln auseinander setzen muss, bevor er erste brauchbare Resultate bekommt. Regelsprachen von verschiedenen CEP-Engines sind daher generell eher schlecht geeignet für den normalen Gebrauch in Unternehmen, ohne die Hilfe von Experten in Anspruch nehmen zu müssen. Hinzu kommt, dass bspw. die Regel-Syntax von Esper so komplex ist, dass das Ergebnis einer Regel, die im System registriert wurde, häufig nicht zu dem erwarteten Resultat führt. Dies zeigt, dass es auch häufig für Fachkräfte schwierig sein kann, Regeln zu definieren ohne Fehler einzubauen. 1.2 Ziel der Arbeit Im vorausgegangenen Abschnitt wurde auf die Problematik der Definition von Regeln in einer CEP- Engine eingegangen. In dem Paper [18] wurde diese Problematik aufgegriffen, und es entstand die Idee dieser Abhilfe zu schaffen, indem eine grafische Spezifikation von Regeln erschaffen wird, die es auch einem Domänen-Experten außerhalb des IT-Sektors ermöglicht, eigene Regeln zu definieren. Dabei entstand ein webbasierter grafischer Editor, mit dem komplexe Pattern in der Regelsprache von Esper beschrieben werden können. Das Ziel dieser Arbeit ist vergleichbar mit dem des genannten Papers, gestaltet sich aber insgesamt deutlich umfangreicher. Es soll dementsprechend mit einfachen, verständlichen und ggf. allgemein bekannten Methoden eine Regelsprache entstehen, so dass die Definition von Regeln auf einfachem Wege vonstatten geht. Weiterhin soll es sowohl für Experten dieser Domäne, als auch für Menschen ohne Programmierkenntnisse oder großem Verständnis für Softwaretechniken ermöglicht werden, Regeln zu definieren und zu testen. Dieses Ziel ist allerdings nur ein Teilziel. Genauer soll nämlich ein Rapid Prototyper entstehen, der es ermöglicht auf, schnellem Wege eine Testumgebung für eine komplette EDA aufzubauen, so dass mit dieser Regeln getestet und auf ihre Richtigkeit überprüft werden können. Der Begriff des Rapid Prototypings wurde ursprünglich durch Fertigungsverfahrenstechniken geprägt und später auf die Software-Entwicklung übertragen. Nach [17] ist das allgemeine Prototyping in der Softwareentwicklung ein (iteratives) Verfahren [...], bei dem die wesentlichen Schritte mehrfach durchlaufen werden, bis die gewünschte Produktqualität erreicht ist. Weiter heißt es, dass dabei der Anwender sehr stark in den Entwicklungsprozess mit einbezogen wird, so dass eine kooperative Gestaltung des Systems durch Entwickler und Anwender vonstatten geht. Das Vorgehensmodell des Rapid Application Development (RAD) sollte an dieser Stelle kurz erwähnt werden, da es die Idee des Rapid Prototyping beinhaltet und populär gemacht hat. Bei dem Modell soll zugunsten einer schnellen Entwicklung einer prototypischen Software eine minimale Planung stattfinden [20], so wie auch der Rapid Prototyper dieser Arbeit dabei helfen soll, ohne große Planung eine Testumgebung für eine EDA zu entwerfen. Prototyping ist zudem ein äußerst effizienter Lösungsweg, um Anforderungen an Software nachzuvollziehen, die Komplexität eines Problems zu minimieren und eine frühe Validierung des Systems zu erlangen. Werden bei dem Verfahren zusätzlich grafische Sprachen eingesetzt, so wie es in dieser Arbeit der Fall sein soll, gestaltet sich das Prototyping umso hilfreicher (vgl. [21]). Ein Prototyp bringt viele Vorteile mit sich und wird nach [14] als ein vereinfachtes Modell eines Systems dargestellt, was aus den folgenden Gründen erstellt wird:

8 1 Einleitung 3 Anforderungen, Spezifikationen und das Design formulieren und evaluieren Die Realisierungsmöglichkeit, das System-Verhalten, die Performanz etc. demonstrieren Das Risiko der Fehlentwicklung identifizieren und reduzieren Ideen und Gedanken austauschen, speziell zwischen verschiedenen Gruppen von Experten Fragen zu speziellen Eigenschaften des Systems beantworten Wegen dieser vielfältigen Vorteile soll in dieser Arbeit also ein Rapid Prototyper für CEP-Systeme entstehen, welcher der Kategorie des experimentellen Prototypings zugeordnet werden kann. In den Folien zur Vorlesung [2] sind diese und noch weitere Arten des Prototypings beschrieben. Bei der genannten Art stehen die folgenden Punkte im Vordergrund, welche auch für den Rapid Prototyper größtenteils gelten sollen: Überprüfung von Architekturmodellen Teilentwürfen Lösungsideen Effizienzmessungen kritischer Teile Machbarkeitsstudien Zusätzlich zu dem Erlernen des Prozesses der Erstellung einer EDA, was der Anwender während der Benutzung der Software erfahren soll, soll auch die Problematik der syntaktisch korrekten Schreibweise von Regelsprachen gelöst werden. Da bspw. bei Esper Regeln mittels eines String in der Engine registriert werden, gibt es keine Möglichkeit, die Regel vor dem Kompilieren auf ihre Richtigkeit zu überprüfen. Dieses Problem soll mit dem Rapid Prototyper vermieden werden, da die Regeln nach der grafischen Definition auf die Event Processing Language (EPL) von Esper umgewandelt werden sollen, so dass sie keine syntaktischen Fehler oder gar Tippfehler aufweisen. 1.3 Aufbau Im ersten Kapitel SWE-Prozess für eine Event-Driven-Architecture erfolgt zunächst eine Einführung in den allgemeinen Entwicklungsprozess zur Entwicklung einer EDA. Anhand sechs verschiedener Hauptschritte wird der Prozess im Detail dargestellt. Das dritte Kapitel ist das erste Kapitel, das zur Entwicklung des Rapid Prototypers beiträgt, indem es die Anforderungsanalyse beschreibt. Diese Analyse orientiert sich vor allem an dem vorherigen Kapitel. Es folgt die Konzeptionelle Umsetzung der Anforderungen an die zu entwickelnde Software, in dem genauer auf die mögliche Realisierung des Rapid Prototypers eingegangen wird. Dieses Kapitel enthält u.a. die Entwicklung der grafischen Sprache zur Regelerstellung. Anschließend wird im fünften Kapitel auf die konkrete Umsetzung eingegangen, indem der Aufbau der Software beschrieben wird. Dieser Teil der Arbeit enthält die Software-Architektur und erläutert die Klassendiagramme sowie die Realisierung der grafischen Oberfläche mit der grafischen Sprache. Das anschließende Kapitel Fazit und Ausblick ist das sechste und somit letzte Kapitel, mit dem diese Masterarbeit letztendlich abgeschlossen wird Anwendungsbeispiel Um Problemstellungen und Lösungen, die in der Arbeit beschrieben werden, einfacher zu erläutern und besser verstehen zu können, wird an dieser Stelle ein Anwendungsbeispiel eingeführt. Dieses wird

9 1 Einleitung 4 im Laufe der Arbeit immer wieder aufgegriffen, so dass sich der Leser in der Regel an einem konkreten Beispiel orientieren kann. Der folgende Absatz beschreibt das Beispiel. Am Aktienmarkt soll der Wert der Aktie einer bestimmten Firma überwacht werden. Es erfolgen in unregelmäßigen zeitlichen Abständen Aktualisierungen des Aktienwertes, bei denen sich dieser positiv oder negativ verändert, es findet also eine Kursänderung statt. Diese Werte werden gesammelt, so dass es bspw. möglich ist, den sogenannten gleitenden Durchschnitt des Kurses zu berechnen [vgl. [1]]. Die Verwendung dieses Indikators ist eine beliebte Methode bei der Aktienanalyse, um Auf- bzw. Abwärtstrends zu erkennen. Es wird dabei anhand einer bestimmten Anzahl der letzten Aktienwerte bzw. über einen bestimmten Zeitraum das arithmetische Mittel gebildet, mit dem anschließend ein Trend erkannt werden kann. Für das Beispiel soll ein Aktienhändler beim Kauf bzw. Verkauf von Aktien automatisch beraten werden, indem er frühzeitig über mögliche Trends informiert wird. Dies geschieht, indem er zum Kaufen von Aktien animiert wird, wenn der aktuelle Wert einer Aktie erst unter dem gleitenden Durchschnitt liegt und zum nächsten Zeitpunkt über diesem, also ein Positivtrend erkannt wird. Andersherum verhält es sich beim Verkaufen. Liegt der Wert erst über dem gleitenden Durchschnitt und nach der nächsten Veränderung unter diesem, so soll der Aktienhändler seine Aktien wieder verkaufen. Im Idealfall fährt er mit diesem Verfahren einen Gewinn ein.

10 2 SWE-Prozess für eine Event-Driven-Architecture 5 2 SWE-Prozess für eine Event-Driven-Architecture Das Ziel dieser Arbeit ist es, einen Rapid Prototyper zu entwerfen, der einen Anwender bei der Entwicklung einer EDA unterstützt. Dabei soll sich die Software an einem allgemeinen Verfahren zur Erstellung einer EDA orientieren. Diesen Prozess gilt es im Folgenden zu identifizieren und im Detail zu beschreiben. Um ein Softwaresystem anhand einer EDA zu entwickeln, bedarf es - wie in der allgemeinen Software-Entwicklung auch - eines Verfahrens, welches ein strukturiertes Vorgehen vorgibt. Nach [[3], S. 214ff] gibt es sechs verschiedene Prozessschritte zur Entwicklung einer EDA, die sequenziell abgearbeitet werden sollten. Abbildung 2.1 zeigt diese Schritte im Überblick. Das Vorgehen erinnert Ereignisquellen Ereignismodell Muster/ Regeln Event Processing Network Physikal. Verteilung Behandlung Abbildung 2.1: Prozessschritte der EDA-Entwicklung [[3], S. 214] an das Wasserfallmodell 1, verhält sich aber doch grundsätzlich anders. Bei der Entwicklung einer EDA kann es nämlich häufig zu Änderungen der Ergebnisse in den einzelnen Phasen kommen, womit das unbedingte und ständige Einhalten der Abfolge der Phasen kaum möglich ist. Die Pfeile in der Abbildung sollen dies verdeutlichen. In den folgenden Abschnitten 2.1 bis 2.6 wird nun auf die einzelnen Schritte im Detail eingegangen, so dass deutlich wird, was in diesen zu beachten ist und inwiefern sie zu einer letztendlich funktionierenden Architektur beitragen. Dabei wird jeder einzelne Schritt noch einmal in verschiedene Unterschritte untergliedert und erläutert. Die Erklärungen orientieren sich größtenteils an den Ausführungen in den Kapiteln Prozessschritte für EDA aus [3] (S. 214ff). 2.1 Schritt 1: Ereignisquellen Im ersten Schritt werden zunächst die Ereignisquellen identifiziert (Schritt 1.1), danach die Ereignistypen spezifiziert (Schritt 1.2) und schließlich die Mengengerüste festgelegt (Schritt 1.3). Abbildung 2.2 zeigt den Prozessschritt im Detail. Ereignisquellen Ereignismodell Muster/ Regeln Event Processing Network Physikal. Verteilung Behandlung Externe Ereignisquellen identifizieren Ereignistypen spezifizieren Mengengerüste festlegen Abbildung 2.2: Prozessschritt 1: Ereignisquellen 1 Vorgehensmodell in der Softwareentwicklung, bei dem die einzelnen Entwicklungsphasen sequenziell aufeinander aufbauen.

11 2 SWE-Prozess für eine Event-Driven-Architecture Schritt 1.1: Externe Ereignisquellen identifizieren Eine EDA kann nur entstehen, wenn Ereignisse produziert werden, weshalb es unabdingbar ist, dass es Quellen gibt, die eben dieses tun. Solche externen Ereignisquellen können bspw. Sensoren, RFID- Lesegeräte, Nachrichten-Ticker, Softwaremodule, Web Services, Handels- oder auch Netzwerkdaten sein (vgl. [[3], S. 62]). Diese Quellen gilt es zu identifizieren, so dass im nächsten Schritt die Ereignistypen spezifiziert werden können Schritt 1.2: Ereignistypen spezifizieren Für jede Quelle muss bestimmt werden, welche Ereignisse erzeugt werden und welche Eigenschaften diese aufweisen sollen. Es werden dabei verschiedene Ereignistypen definiert, die jeweils durch die gleichen Attribute beschrieben werden und somit eine bestimmte Art von Ereignis repräsentieren. Die Typen, die in diesem Schritt definiert werden, sind die sogenannten simple event types, da sie die einfachsten Ereignisse darstellen, die in der EDA auftauchen. Es lässt sich sagen, dass Quellen Instanzen dieser einfachen Ereignistypen generieren und somit ein bestimmtes Vorkommnis im Kontext des betrachteten Anwendungsproblems [[3], S. 214] beschreiben Schritt 1.3: Mengengerüste festlegen Ferner muss für jede Quelle definiert werden wie, wann und in welcher Häufigkeit Ereignisse generiert werden sollen. Entweder entstehen Ereignisse durch Aktionen, die nicht zeitlich vorhersehbar sind, oder es werden bspw. automatisierte Messungen in bestimmten regelmäßigen Intervallen vorgenommen, die dann jeweils ein Ereignis hervorrufen. 2.2 Schritt 2: Ereignismodell Um die in Schritt 1 definierten Ereignistypen in Beziehung zu setzen und einen Überblick über alle Ereignistypen zu erschaffen, wird in diesem zweiten Schritt ein Modell erstellt. Zunächst werden die Relationen definiert (Schritt 2.1), so dass anschließend der Aufbau einer Ereignishierarchie erfolgt (Schritt 2.2) und danach optional Constraints für die einzelnen Ereignistypen festgelegt werden können (Schritt 2.3). In Abbildung 2.3 ist der Prozessschritt im Detail abgebildet. Ereignisquellen Ereignismodell Muster/ Regeln Event Processing Network Physikal. Verteilung Behandlung Relationen definieren Ereignishierarchie aufbauen Constraints festlegen Abbildung 2.3: Prozessschritt 2: Ereignismodell Schritt 2.1: Relationen definieren Zwischen den einzelnen Ereignistypen können temporale, räumliche, kausale und sonstige Beziehungen bestehen, woraus sich ggf. komplexere Ereignistypen (complex event types) oder zusammengesetzte

12 2 SWE-Prozess für eine Event-Driven-Architecture 7 Ereignistypen (composed event types) ableiten können. Es können also Ereignisse durch das Auftreten von anderen Ereignissen bzw. Ereignismustern (siehe auch Schritt 3 in Abschnitt 2.3) entstehen. Diese Beziehungen müssen allesamt definiert werden, so dass ein vollständiges Modell entsteht. Da die dadurch entstehenden Ereignistypen abstrakter sind als die einfachen Ereignistypen aus dem ersten Schritt, wird von einer höheren Abstraktionsebene gesprochen Schritt 2.2: Ereignishierarchie aufbauen Das Modell muss alle Abstraktionsebenen der Ereignistypen beinhalten, so dass eine Hierarchie von Ereignistypen entsteht, die zusätzlich noch alle Beziehungen beinhaltet. Es bietet sich an, die Modellierung einer Ereignishierarchie wie die Modellierung von Klassendiagrammen mithilfe der Unified Modeling Language (UML) zu gestalten. Den Ereignistypen können Attribute zugewiesen und mittels entsprechender Pfeile kann die Vererbungshierarchie abgebildet werden. Beziehungen werden ebenso mittels verbindenden Pfeilen bzw. Strichen dargestellt. Zunächst können nur die externen Ereignistypen spezifiziert werden. In den späteren Schritten - bspw. bei der Bildung einer Regel - ergeben sich meist neue komplexere bzw. zusammengesetzte Ereignistypen, die dem Modell nachträglich zugefügt werden müssen Schritt 2.3: Constraints festlegen Es können schließlich noch Beschränkungen - sogenannte Constraints - für die verschiedenen Ereignistypen definiert werden. Sie dienen dazu, dass von vorne herein alle Ereignisse gefiltert werden, die die Bedingungen der Constraints nicht erfüllen, dementsprechend also fehlerhafte Ereignisse gar nicht erst in das System gelangen. Anders ausgedrückt bedeutet dies, dass Constraints die Bedingungen für sinnvolle Ereignisse festlegen. 2.3 Schritt 3: Ereignismuster und -regeln Das Herzstück der Entwicklungsprozesse für eine EDA ist die Definition von Regeln, die das Definieren von Ereignis- bzw. Beziehungsmustern beinhaltet. Im weiteren Verlauf wird dabei von folgendem Standardvorgehen bei der Erstellung von Regeln ausgegangen: Es müssen für jede Regel zunächst die zu verarbeitenden Ereignistypen selektiert werden (Schritt 3.1), danach können Restriktionen für diese Typen bestimmt (Schritt 3.2) und die zu erfüllenden Muster ermittelt werden (Schritt 3.3). Zuletzt besteht die Möglichkeit, komplexe bzw. zusammengesetzte Ereignisse zu definieren, die nach dem Feuern einer Regel erzeugt werden (Schritt 3.4). Der Prozessschritt wird in Abbildung 2.4 detailliert aufgezeigt. Ereignisquellen Ereignismodell Muster/ Regeln Event Processing Network Physikal. Verteilung Behandlung Ereignistypen selektieren Restriktionen bestimmen Ereignis- bzw. Beziehungsmuster ermitteln Zusammengesetzte bzw. komplexe Ereignisse definieren Abbildung 2.4: Prozessschritt 3: Ereignismuster- und Regeln

13 2 SWE-Prozess für eine Event-Driven-Architecture Schritt 3.1: Ereignistypen selektieren In einer Regel wird ein Ereignisstrom untersucht, in dem sich verschiedenste Ereignisse verschiedenster Typen befinden. Daher muss für jede Regel zunächst eine Selektion stattfinden, mit der festgelegt wird, welche Ereignisse von welchem Typ verarbeitet werden sollen Schritt 3.2: Restriktionen bestimmen Sollen Nebenbedingungen gelten, so dass eine Regel nur gefeuert wird, wenn Ereignisse bestimmte Eigenschaften erfüllen, dann können Restriktionen bestimmt werden. Es können dabei für jedes einzelne Ereignis und dessen Attribute Voraussetzungen zum Erfüllen der Restriktion bestimmt werden. Dabei ist es auch möglich Ereignisse in Relation zu setzen, so dass bspw. ein Attributwert eines Ereignisses in Beziehung mit dem Attributwert eines anderen Ereignisses steht. Wenn die Attribute der Ereignisse also bestimmte Werte annehmen sollen, werden dabei mathematische Operatoren wie bspw. > oder < (für Zahlen) oder auch allgemein der Gleichheitsoperator, sowie logische Verknüpfungen wie und verwendet Schritt 3.3: Ereignis- bzw. Beziehungsmuster ermitteln Sagen einzelne einfache Ereignisse alleine meist wenig aus, so ergeben sie in der Anordnung eines bestimmten Musters und evtl. unter bestimmten Voraussetzungen (siehe Schritt 3.2) einen abstrakteren Sinn. Soll also geprüft werden, ob in einem Ereignisstrom ein bestimmtes Muster auftritt, so muss zunächst bestimmt werden wie dieses aussieht. Damit es später im Strom gefunden und extrahiert werden kann, wird das Muster innerhalb einer Regel definiert, die dann gefeuert wird, wenn das Muster auftritt Schritt 3.4: Zusammengesetzte bzw. komplexe Ereignisse definieren Feuert eine Regel - wird also ggf. das definierte Muster gefunden und alle Restriktionen sind erfüllt - so kann ein zusammengesetztes bzw. ein komplexes Ereignis erstellt werden. Ein zusammengesetztes Ereignis (composite/aggregated event) bezieht sich meist nur auf einen Ereignistypen, welcher in keinem komplexen Muster auftreten muss. Dieser eine Ereignistyp wird über eine bestimmte Zeit oder Länge beobachtet, so dass bestimmte Attributwerte aggregiert werden können, so dass wiederum auf die Aggregation bspw. eine arithmetische Operation ausgeführt werden kann. Das Ergebnis wird dem neu entstehenden Ereignis als Attributwert mitgegeben. Ein komplexes Ereignis (complex event) hingegen entspringt in der Regel aus einem komplexen Ereignismuster, welches Ereignisse verschiedener Typen beinhaltet. Es besitzt häufig nicht viele Attribute, da es mehr dazu dient, über das Auftreten eines Musters zu informieren anstatt Informationen weiter zu tragen. Letztendlich wird das neue Ereignis meist an einen oder mehrere andere Agenten weitergesendet und dort weiterverarbeitet. Das Beschreiben und Extrahieren einer Bedeutung aus einem Ereignisstrom ist also die Kernaufgabe des dritten Prozessschrittes. Um Regeln zu definieren, bedarf es letztendlich einer Sprache, einer

14 2 SWE-Prozess für eine Event-Driven-Architecture 9 sogenannten EPL. Diese wird in einer Event Processing Engine - wie etwa Esper oder Drools Fusion - eingesetzt und vereinfacht das Beschreiben von Regeln und Mustern innerhalb einer Regel auf eine enorme Art und Weise. Bspw. orientiert sich bei der CEP-Engine Esper die EPL an der SQL-Syntax. 2.4 Schritt 4: Event Processing Network Die erstellten Regeln werden zunächst in fachlich kohärente Gruppen strukturiert [[3], S. 215] (Schritt 4.1) und anschließend gruppenweise jeweils einem sogenannten Event Processing Agent (EPA) zugeordnet (Schritt 4.2). Durch das Empfangen und Senden von Ereignissen, das zwischen den EPAs stattfindet, entsteht ein Agentennetz (Schritt 4.3). Abbildung 2.5 stellt den Prozessschritt mit seinen Unterschritten grafisch dar. Ereignisquellen Ereignismodell Muster/ Regeln Event Processing Network Physikal. Verteilung Behandlung Regeln fachlich kohärent gruppieren Regelgruppen EPAs zuordnen Agentennetz konstruieren Abbildung 2.5: Prozessschritt 4: Event Processing Network Schritt 4.1: Regeln fachlich kohärent gruppieren Es ist häufig der Fall, dass verschiedene Regeln eng miteinander verknüpft sind oder thematisch zusammen passen. So ist es möglich Gruppen von Regeln zu bilden, die in einem Zusammenhang stehen Schritt 4.2: Regelgruppen EPAs zuordnen Nach [13] ist ein EPA - auch als CEP-Komponente bekannt - ein Softwaremodul, das komplexe Ereignisse verarbeitet und zu verschiedenen Zeitpunkten entweder als Ereignisquelle oder auch als Ereignissenke arbeiten kann. Jedem Agenten wird in diesem Unterschritt eine bestimmte Menge an Regeln (eine Regelgruppe), die auf ihm ausgeführt werden sollen, zugewiesen. Jeder Agent greift somit auf eine eigene Regelbasis zu und führt so nur die Regeln aus, die sich in seiner Basis befinden, ohne von anderen Regeln Notiz zu nehmen Schritt 4.3: Agentennetz konstruieren Da durch die Ausführung einiger Regeln neue Ereignisse entstehen oder Ereignisse einfach gefiltert und anschließend weitergeleitet werden, dienen andere Agenten als Empfänger dieser Ereignisse. Durch diesen Austausch von Ereignissen entsteht eine gewisse Kommunikation und somit ein Netzwerk zwischen den Agenten - das Event Processing Network (EPN). Nach [13] ist ein EPN eine Menge von EPAs und eine Menge von Ereignis-Kanälen, die die EPAs miteinander verbinden.

Complex Event Processing im Überblick

Complex Event Processing im Überblick Complex Event Processing im Überblick 2 Complex Event Processing ist eine von David Luckham entwickelte Softwaretechnologie, um kontinuierliche Ereignisströme zu verarbeiten [17]. Dieses Kapitel stellt

Mehr

Complex Event Processing für intelligente mobile M2M- Kommunikation

Complex Event Processing für intelligente mobile M2M- Kommunikation Complex Event Processing für intelligente mobile 2- Kommunikation Hochschule Hannover arcel etzdorf, Prof. Dr. Ralf Bruns, Prof. Dr. Jürgen Dunkel, Henrik asbruch Inside 2 Ilja Hellwich, Sven Kasten 2

Mehr

Event Stream Processing & Complex Event Processing. Dirk Bade

Event Stream Processing & Complex Event Processing. Dirk Bade Event Stream Processing & Complex Event Processing Dirk Bade Die Folien sind angelehnt an eine Präsentation der Orientation in Objects GmbH, 2009 Motivation Business Activity Monitoring Sammlung, Analyse

Mehr

Geschäftsprozessmanagement

Geschäftsprozessmanagement Geschäftsprozessmanagement Der INTARGIA-Ansatz Whitepaper Dr. Thomas Jurisch, Steffen Weber INTARGIA Managementberatung GmbH Max-Planck-Straße 20 63303 Dreieich Telefon: +49 (0)6103 / 5086-0 Telefax: +49

Mehr

Befragung und empirische Einschätzung der Praxisrelevanz

Befragung und empirische Einschätzung der Praxisrelevanz Befragung und empirische Einschätzung der Praxisrelevanz eines Vorgehensmodells zur Auswahl von CRM-Systemen D I P L O M A R B E I T zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen

Mehr

6 Architektur-Mittel (WOMIT)

6 Architektur-Mittel (WOMIT) 6 Architektur-Mittel (WOMIT) Abb. 6-1: Positionierung des Kapitels im Ordnungsrahmen. Dieses Kapitel befasst sich mit der WOMIT-Dimension des architektonischen Ordnungsrahmens, indem es grundlegende Konzepte

Mehr

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle

Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung. Kapitel B Vorgehensmodelle Der Projektmanager (nach GPM / IPMA) Fragen zur Selbsteinschätzung und für die Prüfungsvorbereitung Kapitel B Vorgehensmodelle Inhaltsverzeichnis 1 B Vorgehensmodell... 3 1.1 Welche Vorgehensmodelle sind

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

Software Engineering Übung 4 Architektur, Modulentwurf

Software Engineering Übung 4 Architektur, Modulentwurf software evolution & architecture lab Software Engineering Übung 4 Architektur, Modulentwurf 1 Informationen 1.1 Daten Ausgabe Di 27.10.2009 Abgabe So 08.11.2009 bis 23:59 Uhr Besprechung am Di 17.11.2009

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

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector

7.4 Analyse anhand der SQL-Trace. 7.3.5 Vorabanalyse mit dem Code Inspector 7.4 Analyse anhand der SQL-Trace 337 7.3.5 Vorabanalyse mit dem Code Inspector Der Code Inspector (SCI) wurde in den vorangegangenen Kapiteln immer wieder erwähnt. Er stellt ein paar nützliche Prüfungen

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

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

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I)

Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Projektmodell Softwareentwicklung: Unified Software Development Process / Unified Process (Teil I) Historisch Kulturelle Informationsverarbeitung Hauptseminar: KLIPS 2.0 Dozent: Prof. Dr. Thaller Referent:

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

EAI - Enterprise Application Integration

EAI - Enterprise Application Integration EAI - Enterprise Application Integration Jutta Mülle WS 2005/2006 EAI - Folie 1 Überblick und Begriffsbildung Zusammenfassung und Ausblick hinweise EAI - Folie 2 Conclusion EAI Enterprise Application Integration

Mehr

Aufgaben und Lösungshinweise zum Lehrbuch

Aufgaben und Lösungshinweise zum Lehrbuch Aufgaben und Lösungshinweise zum Lehrbuch UVK Verlagsgesellschaft mbh 204 Aufgaben zu Kapitel 4 Aufgabe : (Grundlagen von IT-Services) Nennen Sie vier Kriterien, die für die Gebrauchstauglichkeit eines

Mehr

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung

Block R (Rahmen): SE Aktivitäten 21.10.04 2. Vorlesung Methoden des Software Engineering. Block R Rahmen Aktivitäten der Software-Entwicklung Block R (Rahmen): SE Aktivitäten 21.10.04 1 Vorlesung Methoden des Software Engineering Block R Rahmen Aktivitäten der Software-Entwicklung Martin Wirsing Einheit R.2, 21.10.2004 Block R (Rahmen): SE Aktivitäten

Mehr

Leseprobe. Jürgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner, Arne Koschel. Systemarchitekturen für Verteilte Anwendungen

Leseprobe. Jürgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner, Arne Koschel. Systemarchitekturen für Verteilte Anwendungen Leseprobe Jürgen Dunkel, Andreas Eberhart, Stefan Fischer, Carsten Kleiner, Arne Koschel Systemarchitekturen für Verteilte Anwendungen Client-Server, Multi-Tier, SOA, -Driven Architectures, P2P, Grid,

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Musterlösung Name: Matrikelnummer: Note: Prüfungstag:

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

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit

Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests. Masterarbeit Entwicklung eines Scheduling-Verfahrens zur Optimierung der Reihenfolge von Prototypentests Masterarbeit zur Erlangung des akademischen Grades Master of Science (M.Sc.) im Masterstudiengang Wirtschaftswissenschaft

Mehr

BPMN. Suzana Milovanovic

BPMN. Suzana Milovanovic BPMN Suzana Milovanovic 2 Übersicht Klärung von Begriffen, Abkürzungen Was ist BPMN? Business Process Diagram (BPD) Beispielprozess Entwicklung von BPMN BPMN in der Literatur 3 Grundlegende Begriffe Business

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

7. Analyse-Phase: Datenmodellierung Software Engineering

7. Analyse-Phase: Datenmodellierung Software Engineering 7. Analyse-Phase: Datenmodellierung Software Engineering Hochschule Darmstadt Haardtring 100 D-64295 Darmstadt Prof. Dr. Bernhard Humm Hochschule Darmstadt, 20. November 2006 Einordnung in den Kontext

Mehr

Einführung in die Programmierung mit Java. Hörsaalübung

Einführung in die Programmierung mit Java. Hörsaalübung Einführung in die Programmierung mit Java Hörsaalübung Folie 1 Grundlagen der Objektorientierung Seit Anfang der Neunzigerjahre Standardmethode der Softwareentwicklung. Die OOP Objektorientierte Programmierung

Mehr

Dipl. Inf. Ali M. Akbarian

Dipl. Inf. Ali M. Akbarian Dipl. Inf. Ali M. Akbarian 2012 Einführung Globalisierung, Innovation und Kundenzufriedenheit sind auch in Zukunft die wichtigsten Herausforderungen der Unternehmen. Diese Herausforderungen verlangen:

Mehr

PRÜFUNG. Grundlagen der Softwaretechnik

PRÜFUNG. Grundlagen der Softwaretechnik Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner PRÜFUNG Grundlagen der Softwaretechnik Name: Matrikelnummer: Note: Prüfungstag: 21.09.2012 Prüfungsdauer:

Mehr

Universität Trier. FB IV Wirtschafts- und Sozialwissenschaften. SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm

Universität Trier. FB IV Wirtschafts- und Sozialwissenschaften. SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm Universität Trier FB IV Wirtschafts- und Sozialwissenschaften SS 2008 Veranstalterin: Dipl.-Wirt.-Inf. Ariane Gramm Übung Wirtschaftsinformatik I Teil 2 Thema: Erläuterung der eepk Eingereicht am 12.06.2008

Mehr

Objektorientiertes Programmieren für Ingenieure

Objektorientiertes Programmieren für Ingenieure Uwe Probst Objektorientiertes Programmieren für Ingenieure Anwendungen und Beispiele in C++ 18 2 Von C zu C++ 2.2.2 Referenzen und Funktionen Referenzen als Funktionsparameter Liefert eine Funktion einen

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

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

Complex Event Processing. Sebastian Schmidbauer 18.01.2011

Complex Event Processing. Sebastian Schmidbauer 18.01.2011 Complex Event Processing Sebastian Schmidbauer 18.01.2011 Cirquent im Profil Zahlen Kompetenzen 350 300 250 200 150 100 50 0 1748 1747 1722 1515 1041 1180 286 266 247 260 165 139 2003 2004 2005 2006 2007

Mehr

Aufgabenstellung und Zielsetzung

Aufgabenstellung und Zielsetzung Aufgabenstellung und Zielsetzung In diesem Szenario werden Sie eine Bestellung, vorliegend im XML-Format, über einen Web-Client per HTTP zum XI- System senden. Dort wird die XML-Datei mittels eines HTTP-Interfaces

Mehr

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit

IT-basierte Erstellung von Nachhaltigkeitsberichten. Diplomarbeit IT-basierte Erstellung von Nachhaltigkeitsberichten Diplomarbeit zur Erlangung des Grades eines Diplom-Ökonomen der Wirtschaftswissenschaftlichen Fakultät der Leibniz Universität Hannover vorgelegt von

Mehr

Geschäftsprozessanalyse

Geschäftsprozessanalyse Geschäftsprozessanalyse Prozessmodellierung weitere Begriffe: workflow business process modelling business process (re-)engineering 2 Was ist ein Prozess? Prozesse bestehen aus Aktionen / Ereignissen /

Mehr

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage.

Integration mit. Wie AristaFlow Sie in Ihrem Unternehmen unterstützen kann, zeigen wir Ihnen am nachfolgenden Beispiel einer Support-Anfrage. Integration mit Die Integration der AristaFlow Business Process Management Suite (BPM) mit dem Enterprise Information Management System FILERO (EIMS) bildet die optimale Basis für flexible Optimierung

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

Softwarewiederverwendung und Patterns

Softwarewiederverwendung und Patterns Begrifflichkeiten und Beschreibungssystematik Begriffe Literatur zu Patterns Übersicht über die behandelten Konzepte Beschreibungsschema 97 Begriffe Glossar Patterns (Muster) sind ein Mittel der Wiederverwendung

Mehr

CEPaaS. Complex Event Processing as a Service. Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH

CEPaaS. Complex Event Processing as a Service. Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH CEPaaS Complex Event Processing as a Service Bernhard Seeger Philipps-Universität Marburg RTM Realtime Monitoring GmbH Daniar Achakeyev, Daniel Schäfer, Philip Schmiegelt CEP-Forschung in Marburg: aus

Mehr

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2

Finaler Testbericht. Finaler Testbericht. 1 Einführung 2. 1.1 Warum Softwaretests?... 2 Inhaltsverzeichnis 1 Einführung 2 1.1 Warum Softwaretests?.................................... 2 2 Durchgeführte Tests 2 2.1 Test: allgemeine Funktionalität............................... 2 2.1.1 Beschreibung.....................................

Mehr

Präsentation zum Thema XML Datenaustausch und Integration

Präsentation zum Thema XML Datenaustausch und Integration Sebastian Land Präsentation zum Thema XML Datenaustausch und Integration oder Warum eigentlich XML? Gliederung der Präsentation 1. Erläuterung des Themas 2. Anwendungsbeispiel 3. Situation 1: Homogene

Mehr

Software Engineering Klassendiagramme weiterführende Konzepte

Software Engineering Klassendiagramme weiterführende Konzepte Software Engineering Klassendiagramme weiterführende Konzepte Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassenattribut: static Implementierung in Java public

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

Reaktive Systeme und synchrones Paradigma

Reaktive Systeme und synchrones Paradigma Sascha Kretzschmann Freie Universität Berlin Reaktive Systeme und synchrones Paradigma Einführung in das Seminar über synchrone Programmiersprachen Worum geht es? INHALT 2 Inhalt 1. Einleitung - Wo befinden

Mehr

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22

Wintersemester Maschinenbau und Kunststofftechnik. Informatik. Tobias Wolf http://informatik.swoke.de. Seite 1 von 22 Kapitel 19 Vererbung, UML Seite 1 von 22 Vererbung - Neben der Datenabstraktion und der Datenkapselung ist die Vererbung ein weiteres Merkmal der OOP. - Durch Vererbung werden die Methoden und die Eigenschaften

Mehr

Software-Entwicklung

Software-Entwicklung Software-Entwicklung SEP 96 Geschichte der Programmierung Aufgaben von, Anforderungen an Programme mit der Zeit verändert 1 Programmierung über Lochkarten z.b. für Rechenaufgaben 2 maschinennahe Programmierung

Mehr

Optimieren von Requirements Management & Engineering

Optimieren von Requirements Management & Engineering Xpert.press Optimieren von Requirements Management & Engineering Mit dem HOOD Capability Model Bearbeitet von Colin Hood, Rupert Wiebel 1. Auflage 2005. Buch. xii, 245 S. Hardcover ISBN 978 3 540 21178

Mehr

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster

SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster SWT MN Vorlesung 19.04.2006 2. Übungsblatt Hausaufgaben und Hörsaalübungen zum Themenbereich UML-Modellierung mit Rollen und OOA-Muster Aufgabe 1 analytische Aufgabe Die Eigenschaften und Einsatzbereiche

Mehr

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung

Der Unified Process ist ein generischer Prozeß zur objektorientierten Software- Erstellung Unified Process Eine Einführung von Hannes Fischer Fischer Software Elfenstr. 64 70567 Stuttgart Deutschland Copyright 2000 Hannes Fischer Unified Process Wie wird heute gearbeitet? Der Unified Process

Mehr

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language:

SQL. strukturierte Datenbankabfragesprache eine Datenbanksprache zur. Structured Query Language: SQL Structured Query Language: strukturierte Datenbankabfragesprache eine Datenbanksprache zur Definition, Abfrage und Manipulation von Daten in relationalen Datenbanken In der SQL-Ansicht arbeiten In

Mehr

Kapitel DB:III. III. Konzeptueller Datenbankentwurf

Kapitel DB:III. III. Konzeptueller Datenbankentwurf Kapitel DB:III III. Konzeptueller Datenbankentwurf Einführung in das Entity-Relationship-Modell ER-Konzepte und ihre Semantik Charakterisierung von Beziehungstypen Existenzabhängige Entity-Typen Abstraktionskonzepte

Mehr

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE

BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE CO-MAT-TECH 2004 14-15 October 2004 BEDEUTUNG VON AUSGANGSZUSTÄNDEN BEIM TESTEN VON OBJEKTORIENTIERTER SOFTWARE IMPORTANCE OF INITIAL STATES BY TESTING OF OBJECT-ORIENTED SOFTWARE Roman NAGY External doctorand

Mehr

Suche schlecht beschriftete Bilder mit Eigenen Abfragen

Suche schlecht beschriftete Bilder mit Eigenen Abfragen Suche schlecht beschriftete Bilder mit Eigenen Abfragen Ist die Bilderdatenbank über einen längeren Zeitraum in Benutzung, so steigt die Wahrscheinlichkeit für schlecht beschriftete Bilder 1. Insbesondere

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

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

Grundlagen verteilter Systeme

Grundlagen verteilter Systeme Universität Augsburg Insitut für Informatik Prof. Dr. Bernhard Bauer Wolf Fischer Christian Saad Wintersemester 08/09 Übungsblatt 5 26.11.08 Grundlagen verteilter Systeme Lösungsvorschlag Aufgabe 1: Erläutern

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

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

Der Aufruf von DM_in_Euro 1.40 sollte die Ausgabe 1.40 DM = 0.51129 Euro ergeben.

Der Aufruf von DM_in_Euro 1.40 sollte die Ausgabe 1.40 DM = 0.51129 Euro ergeben. Aufgabe 1.30 : Schreibe ein Programm DM_in_Euro.java zur Umrechnung eines DM-Betrags in Euro unter Verwendung einer Konstanten für den Umrechnungsfaktor. Das Programm soll den DM-Betrag als Parameter verarbeiten.

Mehr

Inhalt: Version 1.7.5

Inhalt: Version 1.7.5 Inhalt: Objekte ohne Methoden Objekte mit einfachen Methoden Objekte und Methoden mit Parametern Objekte und Methoden mit Rückgabewert Objekte mit einem Array als Attribut Beziehungen zwischen Objekten

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

Kapitel 2: Der Software-Entwicklungsprozess

Kapitel 2: Der Software-Entwicklungsprozess Wie konstruiert man Software? Kapitel 2: Der Software-Entwicklungsprozess SoPra 2008 Kap. 2: Der Software-Entwicklungsprozess (1/10) Der Software-Entwicklungs-Prozess Historisches 1960JJ adhoc Techniken

Mehr

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme

Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Universität Stuttgart Institut für Automatisierungs- und Softwaretechnik Prof. Dr.-Ing. Dr. h. c. P. Göhner Integrierte modellgestützte Risikoanalyse komplexer Automatisierungssysteme Dipl.-Ing. Michael

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

Erweiterte Messagingfunktionen in OWA

Erweiterte Messagingfunktionen in OWA Erweiterte Messagingfunktionen in OWA Partner: 2/6 Inhaltsverzeichnis 1. Speicherplatznutzung... 4 2. Ordnerverwaltung... 5 2.1 Eigene Ordner erstellen... 5 2.2 Ordner löschen... 7 2.3 Ordner verschieben

Mehr

Rapide An Event-Based Architecture Definition Language

Rapide An Event-Based Architecture Definition Language Rapide An Event-Based Architecture Definition Language Ralf Bettentrup Seminar: Architekturbeschreibungssprachen Wozu Rapide? Computer mit Modem Provider Broker Client Broker PC Prov 1 Client 1 RS-232

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

A Platform for Complex Event Processing

A Platform for Complex Event Processing A Platform for Complex Event Processing Einführung Business Process Technology Prof. Dr. Mathias Weske Matthias Kunze Nico Herzberg Business Process Technology Seit 2001 Untersuchung realer Probleme des

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

Numerische Datentypen. Simon Weidmann

Numerische Datentypen. Simon Weidmann Numerische Datentypen Simon Weidmann 08.05.2014 1 Ganzzahlige Typen 1.1 Generelles Bei Datentypen muss man immer zwei elementare Eigenschaften unterscheiden: Zuerst gibt es den Wertebereich, zweitens die

Mehr

Data Flow One Engine V 3.1

Data Flow One Engine V 3.1 Data Flow One Engine V 3.1 Data Flow One Engine V3.1 Für eine gute Performance Data Flow One ist eine Standardsoftware im EAI-Bereich, welche es dem Benutzer ermöglicht, auf einfache, graphisch unterstützte

Mehr

Geschäftsprozessmodellierung essmodellierung mit BPEL

Geschäftsprozessmodellierung essmodellierung mit BPEL Geschäftsprozessmodellierung essmodellierung mit BPEL Autor: Stefan Berntheisel Datum: 8. Januar 2010 Stefan Berntheisel Hochschule RheinMain Fachseminar WS 09/10 Agenda Grundlagen Business Process Execution

Mehr

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final

Systembeschreibung. Masterplan Kommunikationsinterface. ASEKO GmbH. Version 1.0 Status: Final Systembeschreibung Masterplan Kommunikationsinterface ASEKO GmbH Version 1.0 Status: Final 0 Inhaltsverzeichnis 1 Einleitung... 2 2 Architektur... 2 2.1 Anbindung an die MKI Lösung... 2 2.2 Inbound Kommunikationsmethoden...

Mehr

Erweiterbare Programmiersprachen und DSLs

Erweiterbare Programmiersprachen und DSLs Erweiterbare Programmiersprachen und DSLs Markus Voelter, Freiberufler/itemis Bernhard Merkle, SICK AG Dieser Vortrag (und dieses Paper) beschreiben einen neuartigen Ansatz für die Entwicklung eingebetteter

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 16: 3-Schichten-Architektur 1 Fachkonzept - GUI Universität Osnabrück Drei-Schichten-Architektur 3 - Objektorientierte Programmierung in Java Vorlesung 6: 3-Schichten-Architektur Fachkonzept - GUI SS 2005 Prof. Dr. F.M. Thiesing, FH Dortmund Ein großer

Mehr

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management

Anforderungsmanagement im Projekt BIS-BY. BIS-BY: Requirement Management Anforderungsmanagement im Projekt BIS-BY von B. KREUZER Schlüsselwörter: Änderungswünsche, Anforderungsmanagement, DOORS Kurzfassung Softwaresysteme unterliegen während ihrer Entwicklung und während ihres

Mehr

Objektorientierte Analyse und Design

Objektorientierte Analyse und Design Folien basieren auf folgendem Buch: Objektorientierte Analyse und Design Kernziele: Strukturen für erfolgreichen SW-Entwicklungsprozess kennen lernen Realisierung: Von der Anforderung zur Implementierung

Mehr

Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1.

Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1. Lösungsvorschlag für das Übungsblatt 1. Aufgabe 1. Zusammengefasst aus Ihren Beiträgen Wie bewerten sie das System ingesamt? Das Watson System verdeutlicht den Fortschritt der Künstlichen Intelligenz Forschung/Computerlinguistik/Informatik

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

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System?

Der Entwicklungsprozess. Oder wie entwickle ich ein eingebettetes System? Der Entwicklungsprozess Oder wie entwickle ich ein eingebettetes System? Einleitung Problemstellung erläutern, Eine Entwicklungsprozess ist ein Prozess, der beschreibt, wie man eine Entwicklung anzugehen

Mehr

Abb.: Darstellung der Problemfelder der Heine GmbH

Abb.: Darstellung der Problemfelder der Heine GmbH Entwicklung eines SOLL-Konzeptes Kehl Olga 16.05.10 Wie aus der Ist-Analyse ersichtlich wurde, bedarf die Vorgehensweise bei der Abwicklung von Projekten an Verbesserung. Nach der durchgeführten Analyse

Mehr

Dokumentation zur Anlage eines JDBC Senders

Dokumentation zur Anlage eines JDBC Senders Dokumentation zur Anlage eines JDBC Senders Mithilfe des JDBC Senders ist es möglich auf eine Datenbank zuzugreifen und mit reiner Query Datensätze auszulesen. Diese können anschließend beispielsweise

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

Softwaretechnik (WS 11/12)

Softwaretechnik (WS 11/12) Universität Augsburg, LSt. Softwaretechnik, K. Stenzel, H. Seebach, G. Anders Softwaretechnik (WS 11/12) Lösungsvorschlag 5 Aufgabe 1 (System Behavior: System Sequence Diagrams) (10/5 Punkte) a) Was sind

Mehr

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach

Inhaltsverzeichnis. Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach sverzeichnis Daniel Liebhart, Guido Schmutz, Marcel Lattmann, Markus Heinisch, Michael Könings, Mischa Kölliker, Perry Pakull, Peter Welkenbach Integration Architecture Blueprint Leitfaden zur Konstruktion

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

Grundlagen der Verwendung von make

Grundlagen der Verwendung von make Kurzskript zum Thema: Grundlagen der Verwendung von make Stefan Junghans Gregor Gilka 16. November 2012 1 Einleitung In diesem Teilskript sollen die Grundlagen der Verwendung des Programmes make und der

Mehr

Data Mining-Modelle und -Algorithmen

Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining-Modelle und -Algorithmen Data Mining ist ein Prozess, bei dem mehrere Komponenten i n- teragieren. Sie greifen auf Datenquellen, um diese zum Training,

Mehr

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung?

Kapitelübersicht. Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge. Was bedeutet Objektorien+erung? Kapitelübersicht Was ist So#waretechnik? Historische Entwicklung der So9waretechnik Prinzipien, Methoden, Werkzeuge Was bedeutet Objektorien+erung? ObjektorienCerte Analyse und Design die Objektmodellierung

Mehr

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs

WHERE Klausel Generierung mit.net und Oracle. Aus unserer Projekterfahrung und Architektur-Kurs Betrifft Art der Info Quelle WHERE Klausel Generierung mit.net und Oracle Technical Info Aus unserer Projekterfahrung und Architektur-Kurs Where ist the WHERE? Der Artikel untersucht die Möglichkeiten,

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

Drei Strategien, die First-Call-Resolution zu verbessern

Drei Strategien, die First-Call-Resolution zu verbessern Drei Strategien, die First-Call-Resolution zu verbessern Das Messen von Kennzahlen ist allen Managern im Kunden-Service- Bereich ein Begriff. Die meisten von ihnen messen weit mehr als die branchenüblichen

Mehr

Jochen Bauer 08.01.2010

Jochen Bauer 08.01.2010 08.01.2010 Um was geht s und wie läuft s ab? Eclipse-EMP-MDT: Standards unter einem Dach! Gliederung 1. der Model (MDT) 2. Model-Driven- (MDD) und MDT 3. Interne Domain-Specific-Languages (DSL) 4. 5. 6.,

Mehr

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16

Probeklausur. Lenz Belzner. January 26, 2015. Lenz Belzner Probeklausur January 26, 2015 1 / 16 Probeklausur Lenz Belzner January 26, 2015 Lenz Belzner Probeklausur January 26, 2015 1 / 16 Definieren Sie Software Engineering in Abgrenzung zu Individual Programming. Ingenieursdisziplin professionelle

Mehr

Datenhaltung für Android. Model First

Datenhaltung für Android. Model First Datenhaltung für Android Model First Frederik Götz, Johannes Tysiak 26.05.2011 Unser Ziel! 26.05.2011 Datenhaltung in Android - Model First» Frederik Götz, Johannes Tysiak 2 Agenda Android Quickstart Datenhaltung

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

Modellierung von RFID-Prozessen mit offen Softwarestandards

Modellierung von RFID-Prozessen mit offen Softwarestandards Modellierung von RFID-Prozessen mit offen Softwarestandards Dipl.-Ing. Marcel Amende Leitender Systemberater Business Unit Server Technology Middleware Tec Agenda I. Vom IT-Konzept

Mehr

Sructred Query Language

Sructred Query Language Sructred Query Language Michael Dienert 11. November 2010 Inhaltsverzeichnis 1 Ein kurzer Versionsüberblick 1 2 SQL-1 mit einigen Erweiterungen aus SQL-92 2 3 Eine Sprache zur Beschreibung anderer Sprachen

Mehr