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

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

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

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

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

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

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011

Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen. OOP München, 26.01.2011 Model Driven SOA Modellgetriebene Entwicklung von SOA Anwendungen OOP München, 26.01.2011 I N H A L T 1. SOA das erste Projekt 2. Prozesse Ergebnisse aus dem Fachbereich 3. Der Business Analyst und BPMN

Mehr

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.

EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel. EINFÜHRUNG IN DIE WIRTSCHAFTSINFORMATIK -ÜBUNGEN- Marina Tropmann-Frick mtr@is.informatik.uni-kiel.de www.is.informatik.uni-kiel.de/~mtr FRAGEN / ANMERKUNGEN Vorlesung Neue Übungsaufgaben MODELLIERUNG

Mehr

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2

Filterregeln... 1. Einführung... 1. Migration der bestehenden Filterregeln...1. Alle eingehenden Nachrichten weiterleiten...2 Jörg Kapelle 15:19:08 Filterregeln Inhaltsverzeichnis Filterregeln... 1 Einführung... 1 Migration der bestehenden Filterregeln...1 Alle eingehenden Nachrichten weiterleiten...2 Abwesenheitsbenachrichtigung...2

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

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

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen

SiteAudit Knowledge Base. Move Add Change Tracking. Vorteile Übersicht. In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen SiteAudit Knowledge Base Move Add Change Tracking Dezember 2010 In diesem Artikel: Vorteile Übersicht Funktionsübersicht Berichte anpassen MAC Benachrichtigungen Vorteile Übersicht Heutzutage ändern sich

Mehr

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8

Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 8 Prof. Dr. Wilhelm Schäfer Paderborn, 8. Dezember 2014 Christian Brenner Tristan Wittgen Besprechung der Aufgaben: 15. - 18. Dezember 2014 Übungsaufgaben zur Vorlesung Modellbasierte Softwareentwicklung

Mehr

Was ist ein Compiler?

Was ist ein Compiler? Was ist ein Compiler? Was ist ein Compiler und worum geht es? Wie ist ein Compiler aufgebaut? Warum beschäftigen wir uns mit Compilerbau? Wie ist die Veranstaltung organisiert? Was interessiert Sie besonders?

Mehr

Was ist Application Lifecycle Management?

Was ist Application Lifecycle Management? Was ist Application Lifecycle Management? Von David Chappell Gefördert durch die Microsoft Corporation 2010 Chappell & Associates David Chappell: Was ist Application Lifecycle Management? Seite 2 von 7

Mehr

Copyright 2014 Delta Software Technology GmbH. All Rights reserved.

Copyright 2014 Delta Software Technology GmbH. All Rights reserved. Karlsruhe, 21. Mai 2014 Softwareentwicklung - Modellgetrieben und trotzdem agil Daniela Schilling Delta Software Technology GmbH The Perfect Way to Better Software Modellgetriebene Entwicklung Garant für

Mehr

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter

Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Geschäftsprozessimplementierung mit BPMN, ADF und WebCenter Johannes Michler PROMATIS software GmbH Ettlingen Schlüsselworte Geschäftsprozess, Horus, SOA, BPMN, ADF, WebCenter Einleitung Die Umsetzung

Mehr

Ereignisbehandlung 21

Ereignisbehandlung 21 Ereignisbehandlung 21 3 Ereignisbehandlung Dieses Kapitel beschäftigt sich mit der Ereignisbehandlung, d.h. der Reaktion eines Programms auf Eingaben durch benutzende Personen. Nach einigen ersten Beispielen

Mehr

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert

Ein Schlüssel ist eine Menge von Attributen (also eines oder mehrere), die eine Datenzeile (Tupel) einer Tabelle eindeutig identifiziert Maika Büschenfeldt Datenbanken: Skript 1 1. Was ist eine relationale Datenbank? In Datenbanken können umfangreiche Datenbestände strukturiert abgelegt werden. Das Konzept relationaler Datenbanken soll

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

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

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

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9

Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Prof. Dr. Wilhelm Schäfer Paderborn, 15. Dezember 2014 Christian Brenner Tristan Wittgen Musterlösung zur Vorlesung Modellbasierte Softwareentwicklung Wintersemester 2014/2015 Übungsblatt 9 Aufgabe 1 Codegenerierung

Mehr

Modellbasierte Softwareentwicklung mit EMF

Modellbasierte Softwareentwicklung mit EMF Softwaretechnik I, WS 2009/10 Modellbasierte Softwareentwicklung mit EMF Übungsblatt 5 13. November 2009 Organisatorisches Zur Bearbeitung der Übungsaufgabe stehen Ihnen die folgenden 3 Wochen (Kalenderwochen

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

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

Einführung in Generatives Programmieren. Bastian Molkenthin

Einführung in Generatives Programmieren. Bastian Molkenthin Einführung in Generatives Programmieren Bastian Molkenthin Motivation Industrielle Entwicklung *!!*,(% % - #$% #!" + '( & )!* Softwareentwicklung Rückblick auf Objektorientierung Objektorientierte Softwareentwicklung

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

Software Engineering Analyse und Analysemuster

Software Engineering Analyse und Analysemuster Software Engineering Analyse und Analysemuster Prof. Adrian A. Müller, PMP, PSM 1, CSM Fachbereich Informatik und Mikrosystemtechnik 1 Klassendiagramme in der Analyse Im Rahmen der Anforderungsanalyse

Mehr

Unified Modeling Language (UML)

Unified Modeling Language (UML) Kirsten Berkenkötter Was ist ein Modell? Warum Modellieren? Warum UML? Viele, viele Diagramme UML am Beispiel Was ist ein Modell? Ein Modell: ist eine abstrakte Repräsentation eines Systems, bzw. ist eine

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

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

Use Cases. Use Cases

Use Cases. Use Cases Use Cases Eigenschaften: Ein Use Case beschreibt einen Teil des Verhaltens eines Systems aus externer Sicht (Formuliert in der der Fachsprache der Anwendung) Dies geschieht, indem ein Systemdialog beschrieben

Mehr

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2

EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0. EDV Kurs 13/2 EinfÅhrung in die objektorientiere Programmierung (OOP) unter Delphi 6.0 EDV Kurs 13/2 Inhaltsverzeichnis 1 Objekte... 1 2 Klassen... 3 2.1 Beziehungen zwischen Klassen... 4 2.1.1 Vererbung... 4 2.1.2

Mehr

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration

KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13. Dokumentation KREDITVERZEICHNIS. Teil 2. Konfiguration KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 1/13 Dokumentation KREDITVERZEICHNIS Teil 2 Konfiguration Stand 20.02.2013 KREDITVERZEICHNIS Konfiguration Ausgabe: 20.02.13 2/13 Inhalt 1. KONFIGURATION...

Mehr

Übung 2: Spezifikation von Auszügen eines Provisionssystems

Übung 2: Spezifikation von Auszügen eines Provisionssystems Übung 2: Spezifikation von Auszügen eines Provisionssystems Für die zweite Übung sollten Sie wieder auf einer einheitlichen Ausgangslage aufsetzen können. Dazu ist es nötig, zunächst einen groben Überblick

Mehr

Software-Architektur. Spektrum k_/takademischht VERLAG

Software-Architektur. Spektrum k_/takademischht VERLAG Oliver Vogel / Ingo Arnold /Arif Chughtai / Edmund Ihler/Uwe Mehlig/Thomas Neumann/ Markus Völter/Uwe Zdun Software-Architektur Grundlagen - Konzepte - Praxis ELSEVIER SPEKTRUM AKADEMISCHER VERLAG Spektrum

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

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent

Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Outlook 2003 - Aufbaukurs 19 Modul 2: Automatisierung des Posteingangs - Regel- und Abwesenheits-Assistent Wie kann ich die Bearbeitung von Nachrichten automatisieren? Wie kann ich Nachrichten automatisch

Mehr

Systemdenken und Gestaltungsmethodik System-Modellierung

Systemdenken und Gestaltungsmethodik System-Modellierung Systemdenken und Gestaltungsmethodik System-Modellierung Prof. Dr.-Ing. Stefan Brunthaler TFH Wildau 2008ff Master Telematik Ausgangsbasis Es liegt ein kosten-nutzen-optimales Lösungskonzept vor. Die Architektur

Mehr

Informationssystemanalyse Use Cases 11 1

Informationssystemanalyse Use Cases 11 1 Informationssystemanalyse Use Cases 11 1 Use Cases Slide 1 Als ein populäres Mittel um Anforderungen zu erfassen und Systeme zu beschreiben, werden Use Cases benutzt. Sie bilden die Basis für eine umfassendere

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

Die Softwareentwicklungsphasen!

Die Softwareentwicklungsphasen! Softwareentwicklung Die Softwareentwicklungsphasen! Die Bezeichnungen der Phasen sind keine speziellen Begriffe der Informatik, sondern den allgemeinen Prinzipien zur Produktion integrierter Systeme entliehen.

Mehr

PROJEKT STATUSMEETING WEBU-UNIFR, 07.01.2015

PROJEKT STATUSMEETING WEBU-UNIFR, 07.01.2015 PROJEKT STATUSMEETING WEBU-UNIFR, 7.. AGENDA Besprechung Erkenntnisse Usability Tests Beurteilung des Prototyps durch Probanden Fazit Maxomedia AG betreffend Konzept Empfehlung weiteres Vorgehen (Phase

Mehr

Vortrag von: Ilias Agorakis & Robert Roginer

Vortrag von: Ilias Agorakis & Robert Roginer MDA Model Driven Architecture Vortrag von: Ilias Agorakis & Robert Roginer Anwendungen der SWT - WS 08/09 Inhalt Was ist MDA? Object Management Group (OMG) Ziele Konzepte der MDA Werkzeuge Vor- und Nachteile

Mehr

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers

Daniel Warneke warneke@upb.de 08.05.2006. Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns Daniel Warneke warneke@upb.de 08.05.2006 Ein Vortrag im Rahmen des Proseminars Software Pioneers Design Patterns 1/23 Übersicht Einleitung / Motivation Design Patterns Beispiele Rolle des

Mehr

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3

Enterprise Computing Einführung in das Betriebssystem z/os. Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013. WebSphere MQ Teil 3 UNIVERSITÄT LEIPZIG Enterprise Computing Einführung in das Betriebssystem z/os Prof. Dr. Martin Bogdan Prof. Dr.-Ing. Wilhelm G. Spruth WS2012/2013 WebSphere MQ Teil 3 Trigger el0100 Copyright W. G. Spruth,

Mehr

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023

Kapitel 33. Der xml-datentyp. In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 Kapitel 33 Der xml-datentyp In diesem Kapitel: Der xml-datentyp 996 Abfragen aus xml-datentypen 1001 XML-Indizierung 1017 Zusammenfassung 1023 995 996 Kapitel 33: Der xml-datentyp Eine der wichtigsten

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

Produktskizze. 28. November 2005 Projektgruppe Syspect

Produktskizze. 28. November 2005 Projektgruppe Syspect 28. November 2005 Carl von Ossietzky Universität Oldenburg Fakultät II Department für Informatik Abteilung Entwicklung korrekter Systeme Inhaltsverzeichnis 1 Einleitung 3 2 Die graphische Oberfläche der

Mehr

Vgl. Oestereich Kap 2.7 Seiten 134-147

Vgl. Oestereich Kap 2.7 Seiten 134-147 Vgl. Oestereich Kap 2.7 Seiten 134-147 1 Sequenzdiagramme beschreiben die Kommunikation/Interaktion zwischen den Objekten (bzw. verschiedenen Rollen) eines Szenarios. Es wird beschrieben, welche Objekte

Mehr

Softwaretechnik (Allgemeine Informatik) Überblick

Softwaretechnik (Allgemeine Informatik) Überblick Softwaretechnik (Allgemeine Informatik) Überblick 1 Einführung und Überblick 2 Abstraktion 3 Objektorientiertes Vorgehensmodell 4 Methoden der Anforderungs- und Problembereichsanalyse 5 UML-Diagramme 6

Mehr

Erfolg ist programmierbar.

Erfolg ist programmierbar. 4578954569774981234656895856512457895456977498 3465689585651245789545697749812346568958561245 9545697749812346568958565124578954569774981234 6895856512457895456977498123465689585612457895 6977498123465689585651245789545697749812346568

Mehr

Flexibilität im Prozess mit Oracle Business Rules 11g

Flexibilität im Prozess mit Oracle Business Rules 11g Flexibilität im Prozess mit Oracle Business Rules 11g Michael Stapf ORACLE Deutschland GmbH Frankfurt Schlüsselworte: Geschäftsregeln, Business Rules, Rules Engine, BPEL Process Manager, SOA Suite 11g,

Mehr

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004

Software Design Patterns. Ausarbeitung über. Security Patterns SS 2004 Ausarbeitung über SS 2004 Dennis Völker [dv04@hdm-stuttgart.de] Steffen Schurian [ss59@hdm-stuttgart.de] Überblick Sicherheit sollte eine Eigenschaft moderner, verteilter Anwendungen sein, jedoch ist ein

Mehr

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378

DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN. Nr. 378 DISKUSSIONSBEITRÄGE DER FAKULTÄT FÜR BETRIEBSWIRTSCHAFTSLEHRE MERCATOR SCHOOL OF MANAGEMENT UNIVERSITÄT DUISBURG-ESSEN Nr. 378 Umsetzung ausgewählter Supply-Chain-Operations-Reference-Metriken durch das

Mehr

VBA-Programmierung: Zusammenfassung

VBA-Programmierung: Zusammenfassung VBA-Programmierung: Zusammenfassung Programmiersprachen (Definition, Einordnung VBA) Softwareentwicklung-Phasen: 1. Spezifikation 2. Entwurf 3. Implementierung Datentypen (einfach, zusammengesetzt) Programmablaufsteuerung

Mehr

Was ist Software-Architektur?

Was ist Software-Architektur? Was ist Software-Architektur? Stephan Schulze Martin Knobloch 28.04.2004 Seminar: Software-Architektur Humboldt Universität zu Berlin sschulze knobloch@informatik.hu-berlin.de Gliederung Begriffsbestimmung

Mehr

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.

Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch. Vgl. Kapitel 5 aus Systematisches Requirements Engineering, Christoph Ebert https://www.sws.bfh.ch/studium/cas/swe-fs13/protected/re/re_buch.pdf 2 Nach derbefragung aller Stakeholder und der Dokumentation

Mehr

Auswertung der Workload-Befragung mit MS ACCESS

Auswertung der Workload-Befragung mit MS ACCESS Auswertung der Workload-Befragung mit MS ACCESS Inhaltsverzeichnis 1. Aufbereitung der Daten... 2 1.1. Herstellung der Textfiles... 2 1.2. Import der Textdateien... 3 1.3. Verbindungen erstellen... 8 2.

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

Avira Management Console 2.6.1 Optimierung für großes Netzwerk. Kurzanleitung

Avira Management Console 2.6.1 Optimierung für großes Netzwerk. Kurzanleitung Avira Management Console 2.6.1 Optimierung für großes Netzwerk Kurzanleitung Inhaltsverzeichnis 1. Einleitung... 3 2. Aktivieren des Pull-Modus für den AMC Agent... 3 3. Ereignisse des AMC Agent festlegen...

Mehr

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski

Systemanalyse I Software-Entwicklung. Die Phase Design.? Prof. Dr. Susann Kowalski Die Phase Design Design Entwerfen der Benutzeroberfläche, des Bedienablaufs und der Softwarearchitektur Umsetzen des fachlichen Modells auf technische Möglichkeiten; Spezifikation der Systemkomponenten

Mehr

Version 8.0 Brainloop Secure Dataroom Artikel Serie - Folge 3

Version 8.0 Brainloop Secure Dataroom Artikel Serie - Folge 3 Version 8.0 kommt in Kürze! Was ändert sich? Lesen Sie Folge 3 unserer Serie: Zusammenarbeit im Datenraum Lesen Sie in der dritten Folge unserer Artikel-Serie, wie Sie effizient über den Datenraum mit

Mehr

Grundlagen der Informatik II. Teil I: Formale Modelle der Informatik

Grundlagen der Informatik II. Teil I: Formale Modelle der Informatik Grundlagen der Informatik II Teil I: Formale Modelle der Informatik 1 Einführung GdInfoII 1-2 Ziele/Fragestellungen der Theoretischen Informatik 1. Einführung abstrakter Modelle für informationsverarbeitende

Mehr

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG

Produkt und Methode. SIRIUSlogic 4.0 in der Praxis. SIRIUS Consulting & Training AG. www.sirius-consult.com. SIRIUS Consulting & Training AG Produkt und Methode SIRIUSlogic 4.0 in der Praxis SIRIUS Consulting & Training AG www.sirius-consult.com SIRIUSlogic 4.0 Warum ein weiteres Prozessmanagement Werkzeug? Motivation Was muß das Tool leisten

Mehr

Zum Beispiel ein Test

Zum Beispiel ein Test Zum Beispiel ein Test Torsten Mandry OPITZ CONSULTING Deutschland GmbH Gummersbach Schlüsselworte Beispiele, Specification by Example, Akzeptanztest, Lebende Spezifikation, Java Einleitung Beispiele helfen

Mehr

ELWIS 3.0. Dokumentation E-Mail-Verteilerlisten

ELWIS 3.0. Dokumentation E-Mail-Verteilerlisten ELWIS 3.0 Dokumentation E-Mail-Verteilerlisten Dienstleistungszentrum Informationstechnik im Geschäftsbereich des BMVBS (DLZ-IT BMVBS) Bundesanstalt für Wasserbau Am Ehrenberg 8, 98693 Ilmenau Stand, 10.02.2011

Mehr

2.11 Kontextfreie Grammatiken und Parsebäume

2.11 Kontextfreie Grammatiken und Parsebäume 2.11 Kontextfreie Grammatiken und Parsebäume Beispiel: Beispiel (Teil 3): Beweis für L(G) L: Alle Strings aus L der Länge 0 und 2 sind auch in L(G). Als Induktionsannahme gehen wir davon aus, dass alle

Mehr

UML-DSLs effizient eingesetzt. Insight 07, 13.11.2007 Klaus Weber

UML-DSLs effizient eingesetzt. Insight 07, 13.11.2007 Klaus Weber UML-DSLs effizient eingesetzt Insight 07, 13.11.2007 Klaus Weber Einladung Domänenspezifische Sprachen (DSLs) sind notwendige Voraussetzung für den Erfolg einer MDA-Strategie. MID favorisiert statt der

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

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6.

6. Modellierung von Informationssystemen. 6.1 Einleitung 6.2 Konzeptuelles Modell 6.3 OASIS Spezifikation 6.4 Execution Model 6. 6. Modellierung von Informationssystemen Spezialseminar Matr. FS 2000 1/10 Volker Dobrowolny FIN- ITI Quellen: Oscar Pastor, Jaime Gomez, Emilio Insfran, Vicente Pelechano The OO-Method approach for information

Mehr

BIF/SWE - Übungsbeispiel

BIF/SWE - Übungsbeispiel BIF/SWE - Übungsbeispiel Arthur Zaczek Feb 2015 1 Allgemein 1.1 Ziele Ziele dieses Übungsbeispieles ist es: GUI: Implementierung einer grafischen Oberfläche mit JavaFX oder WPF UI-Komponente: Implementierung

Mehr

4 Grundlagen der Datenbankentwicklung

4 Grundlagen der Datenbankentwicklung 4 Grundlagen der Datenbankentwicklung In diesem Kapitel werden wir die Grundlagen der Konzeption von relationalen Datenbanken beschreiben. Dazu werden Sie die einzelnen Entwicklungsschritte von der Problemanalyse

Mehr

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle

Praktikum Grundlagen der Programmierung. Diverse Grundlagen. Dr. Karsten Tolle Diverse Grundlagen Dr. Karsten Tolle Vorgehensmodelle im Software Engineering Wasserfallmodell Rapid Prototyping Spiralmodell V-Modell Rational Unified Process extrem Programming Test Driven Development

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

3 Quellencodierung. 3.1 Einleitung

3 Quellencodierung. 3.1 Einleitung Source coding is what Alice uses to save money on her telephone bills. It is usually used for data compression, in other words, to make messages shorter. John Gordon 3 Quellencodierung 3. Einleitung Im

Mehr

Codierungstheorie Rudolf Scharlau, SoSe 2006 9

Codierungstheorie Rudolf Scharlau, SoSe 2006 9 Codierungstheorie Rudolf Scharlau, SoSe 2006 9 2 Optimale Codes Optimalität bezieht sich auf eine gegebene Quelle, d.h. eine Wahrscheinlichkeitsverteilung auf den Symbolen s 1,..., s q des Quellalphabets

Mehr

Objektorientierte Modellierung (1)

Objektorientierte Modellierung (1) Objektorientierte Modellierung (1) Die objektorientierte Modellierung verwendet: Klassen und deren Objekte Beziehungen zwischen Objekten bzw. Klassen Klassen und Objekte Definition Klasse Eine Klasse ist

Mehr

2 Grundkonzepte im Überblick

2 Grundkonzepte im Überblick 7 In diesem Kapitel führen wir die wichtigsten Begriffe und Charakteristika aktiver Datenbanksysteme ein und stellen die Teilaufgaben vor, die bei ihrem Aufbau zu bewältigen sind. All dies geschieht hier

Mehr

13 OOP MIT DELPHI. Records und Klassen Ein Vergleich

13 OOP MIT DELPHI. Records und Klassen Ein Vergleich 13 OOP MIT DELPHI Delphi war früher "Object Pascal". Dieser Name impliziert eine Funktionalität, welche in der Welt der Programmierung nicht mehr wegzudenken ist: die objektorientierte Programmierung,

Mehr

Die Kontor.NET ebay-schnittstelle bindet Vorgänge auf der ebay Verkaufsplattform in Kontor.NET ein und ermöglicht ein weitgehend automatisches

Die Kontor.NET ebay-schnittstelle bindet Vorgänge auf der ebay Verkaufsplattform in Kontor.NET ein und ermöglicht ein weitgehend automatisches Die Kontor.NET ebay-schnittstelle bindet Vorgänge auf der ebay Verkaufsplattform in Kontor.NET ein und ermöglicht ein weitgehend automatisches Abwickeln von ebay-bestellungen. 1 Sie können einen oder mehrere

Mehr

Einführung in die Modellierung

Einführung in die Modellierung Einführung in die Modellierung Christian Huemer Business Informatics Group Institute of Software Technology and Interactive Systems Vienna University of Technology Favoritenstraße 9-11/188-3, 1040 Vienna,

Mehr

Vorlesung "Software-Engineering"

Vorlesung Software-Engineering Vorlesung "Software-Engineering" Rainer Marrone, TUHH, Arbeitsbereich STS Vorige Vorlesung Pflichtenheft (requirements specification document) Charakterisierung von Software-Qualität Detaillierte Anforderungsanalyse

Mehr

Anforderungen: Management

Anforderungen: Management Anforderungen: Management Anforderungen: Management Der Begriff der Anforderungsanalyse ist grundsätzlich vom Begriff des Anforderungsmanagements zu trennen, obwohl beide Konzepte in vie l- fältiger Weise

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

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

SEA. Modellgetriebene Softwareentwicklung in der BA

SEA. Modellgetriebene Softwareentwicklung in der BA SEA Modellgetriebene Softwareentwicklung in der BA MDA bei der BA Ziele/Vorteile: für die Fachabteilung für die Systementwicklung für den Betrieb Wie wird MDA in der BA umgesetzt? Seite 2 MDA bei der BA

Mehr

2. Automatische Codegenerierung mittels dynamischer Spezialisierung

2. Automatische Codegenerierung mittels dynamischer Spezialisierung 2 Automatische Codegenerierung mittels dynamischer Spezialisierung 1/16 Quelle: Vicente Pelechano, Oscar Pastor, Emilio Insfran Automated code generation of dynamic specializations: An approach based on

Mehr

Proseminar C-Programmierung. Strukturen. Von Marcel Lebek

Proseminar C-Programmierung. Strukturen. Von Marcel Lebek Proseminar C-Programmierung Strukturen Von Marcel Lebek Index 1. Was sind Strukturen?...3 2. Padding 5 3. Vor- und Nachteile von Padding..8 4. Padding gering halten 9 5. Anwendungsgebiete von Strukturen.11

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

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0

ActiveCharts. Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Jens Kohlmeyer 05. März 2007 Institut für Programmiermethodik und Compilerbau ActiveCharts Verknüpfung von Modellen und Code bei der modellgetriebenen Softwareentwicklung mit UML 2.0 Seite 2 Übersicht

Mehr

3. Das Relationale Datenmodell

3. Das Relationale Datenmodell 3. Das Relationale Datenmodell Das Relationale Datenmodell geht zurück auf Codd (1970): E. F. Codd: A Relational Model of Data for Large Shared Data Banks. Comm. of the ACM 13(6): 377-387(1970) DBMS wie

Mehr

Scheinaufgabe im Fach Web Engineering

Scheinaufgabe im Fach Web Engineering Otto-von-Guericke-Universität Magdeburg Fakultät für Informatik Institut für Verteilte Systeme Scheinaufgabe im Fach Web Engineering Thomas Thüm 07. August 2006 Matrikel: 171046 Lehrveranstaltung: Web

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

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

Vorwort. Aufbau und Struktur

Vorwort. Aufbau und Struktur Vorwort Herzlich willkommen zu einem Fachbuch aus dem Verlag Comelio Medien. Dieses Buch aus dem Bereich Datenbanken soll Sie dabei unterstützen, die Oracle SQL zu lernen, um DB-Objekte zu erstellen und

Mehr

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12

Softwaretechnik. Vertretung von Prof. Dr. Blume Fomuso Ekellem WS 2011/12 Vertretung von Prof. Dr. Blume WS 2011/12 Inhalt Test, Abnahme und Einführung Wartung- und Pflegephase gp Vorlesung Zusammenfassung Produkte und Recht (Folien von Prof. Blume) 2 , Abnahme und Einführung

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