Vom SOM-Geschäftsprozessmodell zur vollständig dokumentenorientierten RESTful SOA Ein modellbasierter Ansatz

Größe: px
Ab Seite anzeigen:

Download "Vom SOM-Geschäftsprozessmodell zur vollständig dokumentenorientierten RESTful SOA Ein modellbasierter Ansatz"

Transkript

1 Vom SOM-Geschäftsprozessmodell zur vollständig dokumentenorientierten RESTful SOA Ein modellbasierter Ansatz Matthias Wolf und Thomas Benker Otto-Friedrich-Universität Bamberg, Lehrstuhl für Wirtschaftsinformatik, insbes. Systementwicklung und Datenbankanwendung, Bamberg, Germany Abstract. Serviceorientierte Architekturen dienen als Aufgabenträger zur Automatisierung von Geschäftsprozessen. Um sicherzustellen, dass diese Aufgabenträger den Anforderungen der Geschäftsprozesse genügen, ist die modellbasierte Ableitung der softwaretechnischen Spezifikation, ausgehend vom Geschäftsprozessmodell, notwendig. Gegenstand der vorliegenden Arbeit ist die modellbasierte Abbildung von SOM-Geschäftsprozessen auf eine Zielarchitektur, die sich durch Dokumentenorientierung und den Architekturstil REpresentational State Transfer (REST) auszeichnet. Letzterer wird in der jüngsten Vergangenheit vermehrt zur Realisierung serviceorientierter Architekturen (RESTful SOA) diskutiert. Die softwaretechnische Spezifikation sieht dazu Vorgangs- und Entitätsservices vor, die über http-verben GET, PUT, POST und DELETE mit auszutauschenden Zustandsinformationen aufgerufen werden. Für den Austausch werden JSON-Dokumente (Java Script Object Notation) verwendet. Die Durchgängigkeit der Dokumentorientierung wird dadurch erreicht, dass JSON-Dokumente nicht nur für den Austausch, sondern auch für die persistente Verwaltung herangezogen werden. Sie bilden den zentralen Entwicklungsgegenstand des vorgestellten modellbasierten Vorgehens, das anhand einer Fallstudie veranschaulicht wird. Keywords: Modellbasierte Entwicklung, RESTful SOA, Dokumentorientierung 1 Einleitung In aktuellen Untersuchungen werden serviceorientierte Architekturen (SOA) auf Basis des Architekturstils Representational State Transfer [1] (RESTful SOA) im Unternehmensumfeld intensiv diskutiert (vgl. [2-5]). SOAs im Allgemeinen dienen der Automatisierung von Geschäftsprozessen, welche häufig mit Geschäftsprozessmodellen gestaltet, analysiert und dokumentiert werden. Als Technologie zur Realisierung wird in der vorliegenden Arbeit REST zugrunde gelegt. Ein Vergleich mit SOAP/WSDL-Services wird ausführlich in den Beiträgen [2-4] diskutiert. Die Vorteile des Einsatzes von REST werden dabei hinsichtlich Flexibilität, Interoperabilität th International Conference on Wirtschaftsinformatik, 27 th February 01 st March 2013, Leipzig, Germany

2 und Skalierbarkeit für ad-hoc Web-Integrationsszenarien im betrieblichen Umfeld gesehen. Bisherige Arbeiten zur Entwicklung von RESTful SOA konzentrieren sich primär auf die softwaretechnische Spezifikation der Aufgabenträgerebene. Geschäftsprozesse als Spezifikation der fachlichen Anforderungen auf Aufgabenebene und die davon ausgehende modellbasierte Ableitung serviceorientierter Anwendungssysteme finden aktuell in der Literatur nur punktuell Berücksichtigung (siehe Kapitel 2). Durch die modellbasierte Ableitung aus Geschäftsprozessmodellen wird jedoch zum einen die Konsistenz zwischen Implementierung und Dokumentation erhöht. Zum anderen wird ein Beitrag zur Beherrschung der Komplexität der Entwicklungsaufgabe geleistet, der sich ein Entwickler ausgesetzt sieht. Hierzu ist ein möglichst hochgradig automatisierbarer modellbasierter Entwicklungsprozess anzustreben. Als Teilaufgaben der Entwicklung sind v.a. die Identifikation von Ressourcen (REST-Services) als zentrale Komponenten der RESTful SOA sowie die Spezifikation zugehöriger Zustandsbeschreibungen in Form von Dokumenten zu nennen. Letztere sind innerhalb von Ressourcen persistent zu verwalten und zwischen diesen auszutauschen. Als Formate, nicht nur zum Austausch, werden häufig XML oder die JavaScript Object Notation (JSON) genutzt [3-4]. Jüngste Entwicklungen unter dem Begriff Dokumentdatenbanken ermöglichen die Persistierung der Zustandsinformationen in der Form ihrer Nutzung durch das Anwendungssystem. JSON-Dokumente sollen in der vorliegenden Arbeit das einzig zu nutzende Datenformat und einen zentralen Entwicklungsgegenstand bei der angestrebten modellbasierten Ableitung einer RESTful SOA darstellen. Dies manifestiert sich in dem Begriff der vollständigen Dokumentenorientierung. Die daraus ableitbare Problemstellung dieser Arbeit lässt sich als Konstruktionsproblem nach [6] klassifizieren und innerhalb der gestaltungsorientierten Wirtschaftsinformatik nach [7] positionieren. Den Untersuchungsgegenstand bildet das modellbasierte Entwicklungsvorgehen zur Spezifikation einer vollständig dokumentenorientierten RESTful SOA ausgehend von einem Geschäftsprozessmodell. Hierzu wird das Semantische Objektmodell (SOM) nach Ferstl und Sinz [8] zugrunde gelegt und bzgl. des Untersuchungsziels, der methodisch geleiteten Überbrückung der semantischen Lücke zwischen Geschäftsprozessmodell und service-orientierter Aufgabenträgerbeschreibung, erweitert. Der Kernbeitrag der vorliegenden Arbeit setzt sich aus zwei wesentlichen Bestandteilen zusammen. Zum einen erfolgt die Spezifikation der SOA, von einem Geschäftsprozessmodell ausgehend, modellbasiert. Damit lassen sich Flexibilität, Nachvollziehbarkeit und der Beitrag zur Beherrschung der Komplexität der Entwicklung service-orientierter Anwendungssysteme steigern. Zum anderen werden die von Geschäftsprozessen zu verwaltenden Dokumente in den Mittelpunkt der Betrachtung gerückt, und die Ausgestaltung der SOA hinsichtlich der Vermeidung von Medienbrüchen an diesem Entwicklungsgegenstand ausgerichtet. Wesentliche Herausforderungen der Untersuchung bestehen dabei in der Spezifikation von Regeln (1) zur Identifikation von REST-Ressourcen, (2) zur Ableitung der Zustandsbeschreibung durch Dokumente sowie (3) zur Ableitung der softwaretechnischen Spezifikation der RESTful SOA. 1230

3 Die Schritte der Problemlösung Analyse der Problemstellung (Kapitel 2: Stand der Literatur), Konzeption (Kapitel 3: Vorstellung des modellbasierten Vorgehens) und Validierung (Kapitel 4: Vorstellung der Fallstudie und Kapitel 5: Diskussion der Ergebnisse) spiegeln sich in der Gliederung dieser Arbeit wieder. Im Methodenspektrum der Wirtschaftsinformatik [9] lässt sich die Arbeit als qualitativ-konstruktiv, im Speziellen als konzeptionell-/argumentativ-deduktive Analyse, klassifizieren. 2 Stand der Literatur REST wurde als Architekturstil für verteilte Systeme in der Dissertation von Roy Fielding [1] vorgestellt. Darin wird u. a. spezifiziert, wie existierende Web-Protokolle verwendet werden können, um Web-Services zu realisieren [3]. Der Architekturstil REST ist dabei durch folgende vier Prinzipien charakterisiert: (1) Als zentrale Komponenten werden Objekttypen und ihre Funktionalität als Ressourcen mit eindeutiger Identifikation (URI) bereitgestellt. (2) Aus Außensicht weisen diese Ressourcen eine einheitliche Schnittstelle in Form der http-operatoren GET (lesen), PUT (aktualisieren), DELETE (löschen) und POST (erzeugen) auf. (3) Für die Darstellung ihrer Zustände kann eine Ressource in mehreren Repräsentationen vorliegen. Diese werden häufig in Dokumentformaten wie XML, HTML, CSV oder JSON verwaltet. (4) Beziehungen zwischen Ressourcen werden über das Konzept der Links (Verknüpfungen) realisiert. Im Rahmen von Serviceaufrufen können diese u.a. auch zur Steuerung der Anwendungslogik genutzt werden. Im Zusammenhang mit der Anwendung der beschriebenen Prinzipien steht auch die Forderung nach zustandsloser Kommunikation. REST sieht für Anfragen an Ressourcen vor, die für die Verarbeitung benötigten Zustandsinformationen als Parameter im Kontext der Anfrage mit zu übergeben. Eng verbunden mit dem Architekturstil REST ist das Konzept der ressourcenorientierten Architektur (ROA). Overdick [10] charakterisiert eine ROA als SOA, welche den REST-Prinzipien genügt, also (all) ihre Entitäten (nicht nur Web-Services) als Ressource expliziert und somit global identifizier- und ansprechbar macht. Die Forderung der einheitlichen Schnittstelle ist eine weitere Einschränkung der klassischen SOA. Auch die im vorliegenden Beitrag entwickelte RESTful SOA ist demzufolge als ressourcenorientierte Architektur klassifizierbar und folgt mit dieser Einordnung auch dem Verständnis von Richardson und Ruby [4]. Mit der Modellierung und modellbasierten Entwicklung der Komponenten einer RESTful SOA beschäftigt sich eine Reihe von Arbeiten. Die dort beschriebenen Ansätze werden anhand folgender Kriterien analysiert: (1) Erfolgt die Identifikation von Ressourcen bzw. Dokumenten modellbasiert? (2) Auf welchen Modellebenen wird die RESTful SOA spezifiziert? (3) Erfolgt der Übergang zwischen den Modellebenen modellbasiert? Den Ausgangspunkt für die Identifikation von Ressourcen bilden zum einen natürlich-sprachliche Beschreibungen, wie fachliche Anforderungen [3-4] oder Beschreibungen von Web-Service-Funktionalitäten [11]. Zum anderen erfolgt eine Ressourcenidentifikation auf Basis von Modellen durch die Analyse von Aktionen in Workflowschemata [12], [5] oder der funktionalen Beschreibung von Interaktionen in 1231

4 einem Schema [13]. Dieses Vorgehen setzt damit bereits spezifizierte Client-Server Interaktionen auf der Aufgabenträgerebene voraus. Die Ableitung selbst wird hier natürlich-sprachig erläutert. Dokumente werden in den untersuchten Beiträgen primär unter dem Gesichtspunkt der Ableitung von Repräsentationsformaten diskutiert. Sie werden auf Basis von Ressourcenspezifikationen der REST-Anwendung (meist als Klassendiagramm) entwickelt [11-14]. Auch werden alternative Repräsentationsformate und Best Practices für die Dokumentenbeschreibung vorgestellt und diskutiert [3-5]. Die Spezifikation einer RESTful SOA beginnt in bestehenden Ansätzen meist auf der softwaretechnischen Ebene. Einerseits werden hierfür eigene Metamodelle für die Ressourcenbeschreibung entwickelt [15]. Andererseits erfolgen Struktur- bzw. Verhaltensspezifikationen der ROA mit (erweiterten) UML-Diagrammen [3], [11], [13-14]. Der Übergang auf und die Beschreibung der Implementierungsebene erfolgen durch die Ableitung von Schnittstellenbeschreibungen von Ressourcen unter Verwendung der Web Application Description Language (WADL) [11], [13] oder eigener Komponentenspezifikationen [14]. Zudem werden für die detaillierte Spezifikation von Softwarearchitektur und Implementierung der RESTful SOA eine Vielzahl an Hinweisen, Pattern und Best Practices bereitgestellt [3-4]. Die Überwindung der Lücke zwischen den Ebenen der Softwarearchitektur und der Implementierung erfolgt in den betrachteten Ansätzen nur teilweise regelbasiert. Bezugnehmend auf die drei anfangs formulierten Kriterien ist zusammenfassend festzuhalten, dass in den betrachteten Arbeiten (1) die Identifikation von Ressourcen nicht auf Basis von Geschäftsprozessmodellen auf der Aufgabenebene erfolgt. Die Ressourcenidentifikation erfolgt durch Analyse natürlich-sprachiger Beschreibungen oder Workflow-/Interaktionsschemata. (2) Die Untersuchung der Entwicklung von RESTful SOA konzentriert sich primär auf die Spezifikation der softwaretechnischen Ebene. (3) Die meisten Ansätze beschreiben zudem einen modellbasierten Übergang hin zur Implementierung. Eine Betrachtung der Aufgabenebene in Form von Geschäftsprozessen findet nicht statt. Auch wird die Beziehung zwischen Aufgaben, die mit der SOA automatisiert werden sollen, und den korrespondierenden Komponenten der RESTful SOA unzureichend betrachtet. Die aufgezeigte semantische Lücke zwischen den Abstraktionsebenen der Geschäftsprozesse und der softwaretechnischen Spezifikation soll mit der vorliegenden Arbeit verringert werden. 3 Modellbasierte Spezifikation einer dokumentenorientierten RESTful SOA Zielsetzung der vorliegenden Arbeit ist die modellbasierte Ableitung einer softwaretechnischen Spezifikation zur Automatisierung von Geschäftsprozessen durch eine dokumentenorientierte RESTful SOA. Als methodische Grundlage wird das Semantische Objektmodell (SOM) nach Ferstl und Sinz [8] gewählt. Die SOM-Methodik beinhaltet einen objekt- und geschäftsprozessorientierten Modellierungsansatz, der einen Geschäftsprozess sowohl auf Aufgaben- als auch auf Aufgabenträgerebene struktur- und verhaltensorientiert beschreibt. Die SOM-Methodik bildet das modell- 1232

5 basierte Fundament der vorliegenden Arbeit, weil durch die explizite Spezifikation der strukturorientierten Sicht auf unterschiedlichen Ebenen ein wichtiges Instrument zur Identifikation und Spezifikation von Artefakten (Dokumente, Ressourcen) bzgl. der vorliegenden Zielsetzung bereitgestellt wird. Das in diesem Abschnitt nun detailliert vorgestellte Vorgehen kann zudem an eine bestehende modellbasierte Methodik anknüpfen und diese um eine plattformspezifische Ebene erweitern. Abbildung 1 zeigt die Modellarchitektur einschließlich der Erweiterung zur softwaretechnischen Beschreibung einer dokumentenorientierten RESTful SOA: Geschäftsprozessmodellebene E1: Die SOM-Methodik sieht auf Aufgabenebene die Spezifikation von Geschäftsprozessen anhand einer Struktur- (Interaktionsschema, IAS) und einer Verhaltenssicht (Vorgangs-Ereignis-Schema, VES) vor. Die Koordination betrieblicher Objekte mittels Transaktionen wird im IAS erfasst. Das VES beschreibt die Durchführung der korrespondierenden Aufgaben als Ablaufdiagramm. (E1) Geschäftsprozessmodellebene Produktinfo.> Handel A >Produktinfo. Handelsunternehmen Struktursicht A: Produktinfo. V: Auftrag D: Lieferung IAS Verhaltenssicht Lieferung> >Auftrag Handel Handel D V >Lieferung Auftrag> VES Transformation T1 (E1 zu E2) Güterdistribution Produktinfo. Auftrag Lieferung Produktinfo.> >Auftrag (E2) Fachliche Anwendungsmodellebene Lieferung> Handelsunternehmen KOS >Produktinfo. Auftrag> >Lieferung VOS Transformation T2 (E2 zu E3) A1 A2 A4 A3 transient Produktinfo { Datum :, KdName :,...} Lieferung {Doc_Auftrag, Doc_Produkt,...} persistent : { KdNr :, KdName :,...} Auftrag { AufNr :, AufBez :,...} Produkt { ProdNr :, ProdBez :,...}... Dokumentenstruktur Produkt Auftrag Entitätsservices (E3) Plattformspezifische REST-Architekturmodellebene... Res. Produkt Auftrag URI \portal\produkt\ \portal\produkt\{nr} \portal\auftrag\ \portal\auftrag\{nr} \portal\kunde\ \portal\kunde\{nr} Op. get,put,delete get,put,delete get,put,delete \portal\auftrabw\ Auftr.abw. \portal\auftrabw\{nr} get,put,delete Ressourcenschema Auftragsabwicklung Auftrag Bestätigung Prüfung empfangen Vorgangsservices / BPMN-Schema Abb. 1. Erweiterte Modellarchitektur der SOM-Methodik Fachliche Anwendungsmodellebene E2: Auf Basis der Geschäftsprozessspezifikation wird ein plattformunabhängiges objektorientiertes Modell des Anwendungssystems (AwS), ebenfalls bestehend aus Struktur- (konzeptuelles Objektschema, KOS) und Verhaltenssicht (Vorgangsobjektschema, VOS), modellbasiert abgeleitet. Das KOS differenziert seine Objekttypen nach ihrem Ursprung im Geschäftsprozessmodell als leistungs-, objekt- oder transaktionsspezifisch. Für die Erläuterung der Schritte von Transformation T1 (E1 zu E2) sowie die zugehörige Schemakonsolidierung sei auf die Ausführungen in [8], [16] verwiesen. 1233

6 REST-Architekturmodellebene E3: Die plattformspezifische Aufgabenträgerebene beschreibt die Erweiterung der SOM-Architektur zur Spezifikation einer dokumentenorientierten RESTful SOA durch Vorgangs- und Entitätsservices, die notwendigen transienten und persistenten Dokumente sowie die Schnittstellenspezifikation der Ressourcen. Die Transformation T2 der Objekttypen aus KOS und VOS (auf E2) in die Modellbausteine der Ebene E3 wird modellbasiert durch vier Ableitungsschritte (A1: Identifikation und Spezifikation von Dokumenten, A2: Identifikation und Spezifikation von Entitätsservices, A3: Identifikation und Spezifikation von Vorgangsservices, A4: Spezifikation des Ressourcenschemas) regelbasiert beschrieben. Die Modellebene (E3) und die Spezifikation der Transformation T2 stellen die Erweiterung der SOM-Methodik dar. Grundlage hierzu bildet die Arbeit von Wolf [16]. Das dort vorgestellte, fachlich orientierte Vorgehen wird um softwaretechnische Artefakte erweitert und hinsichtlich der Implementierung detailliert. Die Ableitungsschritte und zugehörigen Regeln werden nachfolgend zunächst allgemein eingeführt und im anschließenden Kapitel 4 anhand einer Fallstudie verdeutlicht: Ableitungsschritt A1: Identifikation und Spezifikation von persistenten und transienten Dokumenten. Dokumente stellen den zentralen Entwicklungsgegenstand der vorliegenden Arbeit dar. In einer RESTful SOA werden diese einerseits transient zum Austausch zwischen Ressourcen (Vorgangs- und Entitätsservices), andererseits zur persistenten Verwaltung des Ressourcenzustands verwendet. In beiden Fällen werden die Dokumente über das Repräsentationsformat JSON beschrieben. Dieses eignet sich auch für die dokumentorientierte persistente Speicherung. In einem ersten Schritt werden Dokumente auf Grundlage des plattformunabhängigen KOS identifiziert und deren Struktur (Dokumenttyp) festgelegt. Hierzu wird dokumentenorientiert konsolidiert. Die Bildung von persistenten Dokumenten orientiert sich dabei an dem Grundsatz nach [17] (S ), Daten auf Grundlage ihrer gemeinsamen Nutzung zu Dokumenten zu aggregieren. Daten, die in einer ACID-Transaktion gemeinsam behandelt werden, sind demzufolge in einem gemeinsamen Dokument abzubilden. Zur weiteren Klassifikation erfolgt die Unterscheidung von persistenten Dokumenten nach Stamm- (A1a) bzw. Transaktionsdaten (A1b): (A1a) Stammdatendokumente leiten sich aus den linksstehenden Objekttypen des KOS ab. Als von einem konkreten Geschäftsvorfall existenzunabhängige Objekttypen treten diese als objektspezifische oder leistungsspezifische Objekttypen auf. Damit werden Daten der am Geschäftsprozess beteiligten betrieblichen Objekte bzw. der Leistungsspezifikation beschrieben. Diesen werden Attribute zugeordnet und festgelegt, ob sie dauerhaft zu speichern sind. Je dauerhaft zu speichernden Objekttyp wird ein korrespondierender Stammdatendokumenttyp abgeleitet. (A1b) Transaktionsdokumente bilden einen konkreten Geschäftsvorfall (Leistungserstellung und deren Koordination) ab. Zur Ableitung der Dokumenttypen werden alle existenzabhängigen transaktionsspezifischen Objekttypen des KOS betrachtet, ihre Dokumentenstruktur spezifiziert sowie die Persistenzeigenschaft (transient = t, persistent = p) festgelegt. Diese Objekttypen werden als Nachrichten interpretiert, die während der Durchführung des Geschäftsprozesses zur Koordination der Leistungserstellung zwischen den beteiligten betrieblichen Objekten ausgetauscht werden. Alle als persistent markierten Objekttypen dienen zudem der Identifikation persistent zu spei- 1234

7 chernder Dokumente. Ein persistentes Transaktionsdokument stellt die Aggregation ausgetauschter Daten zur Koordination einer Leistungserstellung (D-Transaktion des Geschäftsprozessmodells auf detaillierter Ebene) dar. Das Schreiben und das Lesen von Transaktionsdaten erfolgt somit ausschließlich basierend auf einem Dokument. Ein Beispiel für unterschiedliche Transaktionsdokumenttypen innerhalb eines Geschäftsvorfalls stellen die Koordination und Durchführung der eigentlichen Leistungserstellung und die Abwicklung der Abrechnung dar. Zur Abbildung des Ressourcenzustands wird jedem Transaktionsdokument ein Attribut _STATUS zugewiesen und zulässige Statusausprägungen aus dem initialen KOS sowie der Ablaufspezifikation auf Aufgabenträgerebene abgeleitet. Die Ableitungsregeln der Stamm- und Transaktionsdatendokumente fasst Tabelle 1 zusammen. Tabelle 1. Ableitungsregeln der dokumentenorientierten Konsolidierung des KOS KOS Dokumenttyp p/t Objektspezifischer Objekttyp Stammdatendokument p Leistungsspezifischer Objekttyp Stammdatendokument p Transaktionsspezifischer Objekttypen Aggregation zu Transaktionsdatendokument (differenziert nach Status) p/t Ableitungsschritt A2: Identifikation und Spezifikation von Services zur Verwaltung der Dokumente. Es werden Services identifiziert, die der Verwaltung, also Speicherung von und Zugriff auf die Repräsentation persistenter Dokumente dienen. Diese werden im Folgenden als Entitätsservices bezeichnet und als Ressourcen interpretiert. Für jeden in Schritt A1 identifizierten Dokumenttyp wird zu diesem Zweck ein Service spezifiziert. Aus Innensicht wird je zulässigem http-verb ein Lösungsverfahren basierend auf Attributausprägungen der übergebenen Dokumente spezifiziert. Für Entitätsservices zur Verwaltung von Transaktionsdaten sind die Ausführungsstatus der Transaktion als Zustandsautomat zu berücksichtigen. Über das Attribut _STATUS werden je nach Operation zu lesende bzw. schreibende Daten und zum jeweiligen Zeitpunkt gültige und zu prüfende Integritätsbedingungen festgelegt. Ableitungsschritt A3: Identifikation und Spezifikation von Services zur Vorgangssteuerung. Vorgangsservices sind zur Realisierung der Geschäftslogik notwendig und können ebenfalls als Ressource nach dem REST-Verständnis interpretiert werden. Die Funktionalität wird aus Außensicht dementsprechend über eine REST-Schnittstelle angeboten und in Webclient-basierten Anwendungssystemen aus der Kommunikationsschicht heraus aufgerufen. Die Identifikation der Vorgangsservices erfolgt in Anlehnung an die Arbeit von Krücke und Sinz [18]. Vorgangsservices werden hier anhand von Message Exchange Patterns (MEP) [19] innerhalb des VOS abgegrenzt. Als relevant werden die Muster In-Out (Request-Response) und In-Only angesehen, über die die Kommunikation zwischen Servicenutzer und Serviceanbieter beschrieben wird. Aus Innensicht wird der identifizierte Service unter Verwendung einer ausführbaren Workflowsprache, im Fall der vorliegenden Arbeit mit BPMN (Business Process Model and Notation, [20]) beschrieben. Dabei werden die unter Schritt (A2) identifizierten Entitätsservices durch REST-Aufrufe orchestriert. 1235

8 Ableitungsschritt (A4): Spezifikation des Ressourcenschemas. Das Ressourcenschema spezifiziert einerseits die Schnittstellen einer RESTful-SOA mit URI, Zugriffsoperatoren und Dokumentenstruktur für jede abgeleitete Ressource und dient andererseits der Ergebnisdokumentation parallel zu den Schritten (A1) bis (A3). Als Ressourcen werden Entitäts- und Vorgangsservices unterschieden. Ihre Bereitstellung erfolgt dabei jeweils als Listen- und Individualressource. Listenressourcen bieten Zugriff auf alle Instanzen, Individualressourcen auf eine konkrete Instanz eines Ressourcentyps. Für den Zugriff auf eine Ressource sind, dem REST-Paradigma folgend, aus Außensicht die zulässigen http-verben festzulegen. Standardmäßig werden als Operatoren für Ressourcenlisten GET und POST festgelegt. GET ermöglicht das Abfragen der Instanzen, POST das Anlegen neuer Instanzen. Dies gilt sowohl für das Anlegen neuer Entitäten als auch das Starten eines neuen Vorgangs. Die Abfrage und Manipulation ausgewählter Instanzen erfolgt über die Schnittstelle der Individualressource mit GET, PUT und DELETE. Abschließend ist eine URI je Ressource zu spezifizieren. Diese setzt sich aus der (optionalen) Angabe des Hosts als möglichen Einstiegspunkt und Wurzel der REST-Anwendung sowie den Namen der Services/Ressourcen zusammen. Die Angabe der {id} identifiziert eine Instanz. Über den Status lassen sich Ressourcen nach dem Ausführungsstand filtern. Die Dokumentenstruktur, die für Stamm- und Transaktionsdaten festgelegt wurde (A1), bildet die Grundlage für die Beschreibung der Dokumentenstruktur, die eine Ressource empfangen und senden kann. Tabelle 2 fasst die Ableitungsregeln für das Ressourcenschema zusammen. Tabelle 2. Ableitungsregeln Ressourcenschema Quelle Ressource URI Operator Dokument Entitätsservice Liste \host\servicename\ (Stammdaten) Individual \host\servicename\{id}\ \host\servicename\ JSON { } Entitätsservice Liste?status=transact.status Definition (Transaktions- \host\servicename\{id}\ der Struktur daten) Individual?status=transact.status nach (A1) Vorgangsservice Liste \host\servicename\ Individual \host\servicename\{id} 4 Fallstudie Anhand einer Fallstudie wird nachfolgend das in Kapitel 3 beschriebene Vorgehen zur Ableitung der softwaretechnischen Spezifikation einer dokumentenorientierten RESTful SOA veranschaulicht und die Anwendbarkeit nachgewiesen. 1236

9 4.1 Einführung der Fallstudie Gegenstand der Fallstudie ist der Geschäftsprozess einer Flugvermittlung. Die Dienstleistung wird über ein Online-Portal erbracht und beinhaltet das Vermitteln von Flügen einschließlich der Abfrage von Fluginformationen und der Reservierung. Der Ablauf des Geschäftsprozesses lässt sich wie folgt grob skizzieren: Nachdem der eine Suchanfrage an das Flugportal gestellt und die Ergebnisse durchgesehen hat, kann er einen Flug auswählen. Wurden die Suchergebnisse noch aus dem lokalen Datenbestand bedient, erfolgt jetzt bei der Fluglinie die Abfrage aktueller und gesicherter Fluginformationen durch das Flugportal. Auf diesen Informationen aufbauend wird ein Angebot erstellt und dem n übermittelt. Nach erfolgter Buchung des Angebots werden die Plätze bei der Fluglinie reserviert und der erhält abschließend eine Bestätigung sowie Buchungsunterlagen. Die Struktur des Geschäftsprozesses stellt Abbildung 2 als IAS und die dazu korrespondierende Verhaltenssicht als VES dar. Abb. 2. Geschäftsprozessmodell der Fallstudie Flugvermittlung Die Schritte Vereinbarung (V) und anschließende Durchführung (D) der Flugvermittlung werden in Form betrieblicher Transaktionen erfasst. Diese Transaktionen stellen Kommunikationsbeziehungen zwischen den beteiligten betrieblichen Objekten dar und weisen auf ausgetauschte Informationen hin. Über Transaktion V 12 wird beispielsweise eine Liste mit Flügen (Suchergebnis) von dem Flugportal an den n übermittelt. Die daran beteiligten Aufgaben werden im VES erfasst und sind Suchergebnis senden (Flugportal: Suchergeb. >) sowie Suchergebnis empfangen (: > Suchergeb.). 1237

10 Der modellierte Geschäftsprozess wird nun in eine fachliche AwS-Spezifikation transformiert, welche als Ausgangsbasis für die Identifikation und die Spezifikation von Dokumenten, Entitätsservices und Vorgangsservices verwendet wird. Das IAS wird in ein initiales konzeptuelles Objektschema (KOS) transformiert. Hierbei werden die beteiligten betrieblichen Objekte (, Flugportal und Fluglinie) sowie die erbrachte Leistung (Flugvermittlung) links im KOS als existenzunabhängige Objekttypen angeordnet. Die Transaktionen werden entsprechend dem Ablauf ihrer Ausführung als transaktionsspezifische Objekttypen rechts davon angeordnet. Die Verhaltenssicht des Anwendungsmodells wird im Vorgangsobjektschema (VOS) dargestellt. Hierzu wird jede Aufgabe des VES in einen Vorgangsobjekttyp transformiert und die Schnittstellen zu den aufrufenden oder aufgerufenen betrieblichen Objekten bestimmt. In der Fallstudie werden die Aufgaben des Flugportals automatisiert, weshalb nur dessen Vorgangsobjekttypen im Folgenden zu betrachten sind. Die Ergebnisse der initialen Ableitung von KOS und VOS zeigt Abbildung 3. Abb. 3. Plattformunabhängige AwS-Spezifikation der Flugvermittlung 4.2 Identifikation und Spezifikation von Dokumenten (A1) Ausgehend vom initialen konzeptuellen Objektschema (Abb.3) wird die dokumentenorientierte Konsolidierung mit den Schritten (A1a) Ableitung von Stammdatendokumenten sowie (A1b) Ableitung von Transaktionsdatendokumenten vorgenommen: (A1a) In Tabelle 3 wird das Ergebnis der Konsolidierung der Stammdaten dargestellt. und Fluglinie beschreiben Geschäftspartner, die im Rahmen der Durchführung des Geschäftsprozesses kontaktiert werden und über das Flugportal Leistungen anbieten bzw. abrufen. Das Flugportal an sich dient der Vermittlung von Flügen, die lokal verwaltet werden. Insofern besteht für das Flugportal die Notwendigkeit zur Spezifikation und Speicherung eines Dokumenttyps Flug. Der Objekttyp Flugvermittlung ergibt sich aus der eigentlichen Leistung, die das Flugportal gegenüber dem n erbringt. Diese Leistung lässt sich anhand verschiedener Bestandteile, wie 1238

11 Kostensätze, AGBs usw. näher beschreiben. Zur persistenten Verwaltung dieser Leistungsspezifikation wird ebenfalls ein eigener Dokumenttyp erzeugt. Tabelle 3. Ergebnis der Stammdatenkonsolidierung Objekttyp Persistent? Dokumentttyp Dokumentformat Ja nnummer, Name, Anschrift, usw. Flugportal Ja Flug FlugNr., Start-/Zielzeit, Start-/Zielflughafen, Plätze usw. Fluglinie Ja Fluglinie LinienNr., Bezeichnung, Anschrift, Kontaktdaten, usw. Flugvermittlunlung: Kosten, Rücktritt, Rahmenbedingungen zur Flugvermitt- Ja AGB usw. (A1b) Zur Identifikation von Transaktionsdatendokumenten werden die Persistenzeigenschaften (transient = t, persistent = p) der transaktionsspezifischen Objekttypen festgelegt (vgl. Tabelle 4). Die dabei als persistent markierten Dokumenttypen werden zur Bildung des persistenten Transaktionsdatendokumenttyps FlugBuchung aggregiert. Als Struktur ergibt sich somit das folgende Dokumentformat: Transaktionsnummer (TNr), Status, Datum, ndaten (siehe Dokumenttyp ), Flugdaten (siehe Dokumenttyp Flug ). Die Überprüfung der Datenkonsistenz obliegt den Entitätsservices, die nachfolgend in Abschnitt 4.3 vorgestellt werden. Tabelle 4. Analyse transaktionsspezifischer Objekttypen Objekttyp Dokumentstruktur p/t Suche Datum, Uhrzeit, Start-/Zielflughafen t Suchergebnis Liste mit Flügen (siehe Dokumenttyp Flug) t Flugwahl TNr, Flug, _Status = FLUG-AUSGEWAEHLT p Flugstatus Flugnummer t Flugdaten TNr, Flug, _Status = FLUGSTATUS-GEPRUEFT p Angebot TNr, Flug, _Status = FLUG-ANGEBOTEN, Datum p Buchung TNr, Flug, _Status = FLUG-GEBUCHT, Datum, p Reservierung TNr, Flug, _Status = FLUG-RESERVIERT, Datum, p Reservierungsbestätigung TNr, Flug, _Status = BUCHUNG-BESTAETIGT, Datum, p Best./Unterlagen Flug, t 4.3 Identifikation und Spezifikation von Entitätsservices (A2) Für jeden unter Schritt (A1) identifizierten Dokumenttyp wird ein Entitätsservice erzeugt und die zulässigen http-operatoren festgelegt. Dienste zur Stammdatenverwaltung ergeben sich für die Dokumenttypen Flug (GET, PUT, POST), (GET, PUT, POST), Fluglinie (GET) und AGBs (GET). Die Zugriffsoperatoren ergeben sich durch Analyse der Ablaufspezifikation im VOS (Abb. 3) und dem Kontext der Servicenutzung. So kann es während der Ausführung des Geschäftsprozesses 1239

12 nur zum lesenden Zugriff auf die Dokumente Fluglinie und AGB kommen. Das Löschen von Stammdaten im Rahmen des Geschäftsprozesses ist nicht vorgesehen. Zur Verwaltung von Transaktionsdaten wird ebenfalls ein Entitätsservice angelegt. Für Dokumente des Typs FlugBuchung ist lesender (GET), schreibender (POST, PUT) und löschender (DELETE) Zugriff zu definieren. Die zulässigen Status der Ressource zur Steuerung des Lösungsverfahrens sind in Tabelle 4 mit hinterlegt. 4.4 Identifikation und Spezifikation von Vorgangsservices (A3) Auf Basis des initialen VOS aus Abbildung 3 werden die Vorgangsservices der RESTful SOA identifiziert (A3a) und ihre Innensicht spezifiziert (A3b). Nach den Message Exchange Pattern In-Out und In-Only werden für die Fallstudie die Vorgangsservices Suche, Angebot und Buchung identifiziert. Über diese findet die vom n initiierte Interaktion mit selbigem statt. Die Vorgangsobjekttypen des VOS werden bei der Spezifikation der Innensicht detaillierter beschrieben. Ein nutzt z. B. den Buchungsservice durch das Starten einer neuen Vorgangsserviceinstanz mit POST auf \flugportal\angebot\ und Übergabe der korrespondierenden Dokumentdaten FlugBuchung. Abb. 4. Schema der Vorgangsservices und Ausschnitt des Lösungsverfahrens (BPMN) Für das Beispiel wird ein Ausschnitt der Innensicht (Lösungsverfahren) zum Vorgangsservice Angebot betrachtet (vgl. Abbildung 4). Die Funktionalität zur Erstellung des Angebots für den n beginnt mit dem Lesen der Flugdaten mittels GET auf die Ressource \flugportal\flug\{id} sowie dem Lesen und Prüfen der ndetails (GET auf \flugportal\kunde\{nr} ). Zur Erstellung des Angebots wird die korrespondierende Flugbuchung durch PUT und Übergabe eines Dokuments mit den erstellten Angebotsdaten aktualisiert. Als Antwort auf seine Anfrage erhält der die URI auf das neu erstellte Angebot. 1240

13 4.5 Spezifikation des Ressourcenschemas (A4) Für die Fallstudie ergibt sich das in Tabelle 5 dargestellte Ressourcenschema. Als Host wird \flugportal\ festgelegt. Die Entitätsservices der Stammdaten Flug,, Fluglinie (betriebliche Objekte) und AGB (Leistung) werden jeweils als Listen- und Individualressource bereitgestellt. Der Zugriff auf die Fluglinie und die AGBs erfolgt dabei nur lesend (vgl. Abschnitt 4.3). Der Entitätsservice FlugBuchung verwaltet die Flugbuchungstransaktion anhand ihrer Status. Entsprechend ist der Stand einer Flugbuchung nach Status geordnet zugreif- und manipulierbar. Die Vorgangsservices Suche, Angebot und Buchung werden ebenfalls als Listenund Individualressourcen bereitgestellt. Tabelle 5. Ressourcenschema der Fallstudie Ressource URI Operator Dokument Flug \flugportal\flug\ \flugportal\flug\{id} \flugportal\kunde\ \flugportal\kunde\{id} Fluglinie \flugportal\fluglinie\ get \flugportal\fluglinie\{id} get AGBs \flugportal\agbs\ get JSON { } \flugportal\flugbuchung\ FlugBuchung vgl. Tab. 3 \flugportal\flugbuchung\{id} FlugBuchung (je Status) \flugportal\flugbuchung\?status=x \flugportal\flugbuchung\{id}\?status=x Suche \flugportal\suche\ \flugportal\suche\{id} Angebot \flugportal\angebot\ \flugportal\angebot\{id} Buchung \flugportal\buchung\ \flugportal\buchung\{id} 5 Zusammenfassung der Ergebnisse und Ausblick In der Arbeit wird ein mehrstufiger modellbasierter Ansatz vorgeschlagen, der die schrittweise Ableitung der plattformspezifischen Beschreibung einer dokumentorientierten RESTful SOA ausgehend von SOM-Geschäftsprozessmodellen zum Gegenstand hat. Hierzu wird ein methodisch geleitetes Vorgehen zur Spezifikation von Vorgangs- und Entitätsservices vorgeschlagen, das das Dokument als Entwicklungsartefakt in den Mittelpunkt rückt. Beide Servicearten werden als Ressourcen im REST-Sinne interpretiert und sind über http-verben und transiente JSON-Dokumente aufrufbar. Entitätsservices dienen der Verwaltung von Stamm- und Transaktionsdaten. Sie gehen aus persistenten Dokumenten hervor, die mittels dokumentenorientierter Konsolidierung des konzeptuellen Objektschemas abgeleitet werden. Die Konzepte des SOM-Geschäftsprozesses werden dabei über drei Abstraktionsebenen hinweg modellbasiert in dazu korrespondierende Bausteine der REST-Architektur überführt. 1241

14 Das Geschäftsprozessmodell stellt somit nicht nur eine zur Implementierung konsistente Dokumentation dar, sondern auch den Ausgangspunkt des Entwicklungsprozesses. Das bereitgestellte Regelwerk unterstützt den Entwickler bei der Bewältigung Komplexität zur Überbrückung der semantischen Lücke zwischen Geschäftsprozess und softwaretechnischer Spezifikation. Dazu trägt nicht zuletzt die Trennung von struktur- und verhaltensorientierter Sicht auf den verschiedenen Modellebenen der SOM-Methodik bei. Über eine Fallstudie wird das Vorgehen näher erläutert und die Anwendbarkeit aufgezeigt. Die Skalierbarkeit des beschriebenen Ansatzes auf komplexere Anwendungsszenarien wird durch SOM als modellbasierter Geschäftsprozessmodellierungsansatz über Aufgaben- und Aufgabenträgerebene mit REST als Zielarchitektur der SOA gefördert. Gerade REST zielt als Architekturstil auf den Entwurf verteilter Architekturen für hoch-skalierbare Systeme, z. B. dem WWW, ab. Anhand des beschriebenen Regelwerks wurde ein Prototyp am Fallbeispiel implementiert und erfolgreich gegen seine Anforderungen validiert. In diesem Rahmen wurden auch Technologien hinsichtlich der Unterstützung von REST und Dokumentenorientierung evaluiert. Vorgangsservices wurden mit BPMN auf der Plattform Activiti 1, Entitätsservices auf Basis von Java EE und dessen API JAX-RS 2 implementiert. Zur Realisierung der durchgängigen Dokumentenorientierung wurde das dokumentenorientierte Datenbanksystem Couchbase 3 ausgewählt, das zur Datenverwaltung ebenfalls das Format JSON nutzt. Somit wird der Bruch zwischen Anwendungslogik und relationaler Datenhaltung vermieden. Künftige Forschungsarbeiten lassen sich an den Eckpunkten der vorliegenden Arbeit identifizieren. Zur Erhöhung des Automatisierungsgrades der Entwicklung sollte der Ansatz hinsichtlich einer metamodellbasierten Integration der Modellebenen erweitert werden. Ausgehend von den Ergebnissen bzgl. persistenter Dokumente sind Dokumentdatenbanken als Basistechnologie sowie Einsatzmöglichkeiten und Architekturen von nicht-relationalen Datenbanken in Unternehmen, wie auch von McKinsey [21] motiviert, zu untersuchen. Literatur 1. Fielding, R.T.: Architectural styles and the design of network-based software architectures. PhD thesis, University of California, Irvine (2000) 2. Pautasso, C., Leymann, F., Zimmermann, O.: Restful web services vs. "big"' web services. In: Proceedings of the 17 th international conference on World Wide Web - WWW '08, p ACM Press (2008) 3. Tilkov, S.: REST und HTTP. Einsatz der Architektur des Webs für Integrationsszenarien. dpunkt, Heidelberg, Neckar (2011) 4. Richardson, L., Ruby, S.: RESTful web services. O'Reilly, Farnham (2007) 1 Activiti BPM Plattform ( 2 JAX-RS ( 3 Couchbase ( 1242

15 5. Erl, T., Carlyle, B., Pautasso, C., Balasubramanian, R.: SOA with REST. Principles, patterns & constraints for building enterprise solutions with REST. Prentice Hall, Upper Saddle River, NJ (2013) 6. Sinz, E.J.: Konstruktionsforschung in der Wirtschaftsinformatik: Was sind die Erkenntnisziele gestaltungsorientierter Wirtschaftsinformatikforschung? In: Österle, H., Winter, R., Brenner, W. (eds.): Gestaltungsorientierte Wirtschaftsinformatik. Ein Plädoyer für Rigor und Relevanz. Infowerk, Nürnberg (2010) 7. Österle, H., Becker, J., Frank, U., Hess, T., Karagiannis, D., Krcmar, H., Loos, P., Mertens, P., Oberweis, A., Sinz, E.J.: Memorandum zur gestaltungsorientierten Wirtschaftsinformatik. Zeitschrift für betriebswirtschaftliche Forschung, (2010) 8. Ferstl, O.K., Sinz, E.J.: Grundlagen der Wirtschaftsinformatik. Oldenbourg, München (2013) 9. Wilde, T., Hess, T.: Forschungsmethoden der Wirtschaftsinformatik. Wirtschaftsinformatik 49 (4), (2007) 10. Overdick, H.: The Resource-Oriented Architecture. In: 2007 IEEE Congress on Services (Services 2007), pp IEEE (2007) 11. Porres, I., Rauf, I.: Modeling Behavioral RESTful Web Service Interfaces in UML. In: Chu, W., Wong, W.E., Palakal, M.J., Hung, C.-C. (eds.): Proceedings of the 2011 ACM Symposium on Applied Computing - SAC '11, pp ACM Press (2011) 12. Xu, X., Zhu, L., Liu, Y., Staples, M.: Resource-Oriented Architecture for Business Processes. In: th Asia-Pacific Software Engineering Conf., pp IEEE (2008) 13. Laitkorpi, M., Selonen, P., Systa, T.: Towards a Model-Driven Process for Designing ReSTful Web Services. In: IEEE Int. l Conf. on Web Services, pp IEEE (2009) 14. Pérez, S., Durao, F., Meliá, S., Dolog, P., Díaz, O.: RESTful, resource-oriented architectures: a model-driven approach. In: Chiu, D.K. (ed.): WISE LNCS, Vol. 6724, pp Springer, Berlin et al. (2011) 15. Schreier, S.: Modeling RESTful applications. In: Proceedings of the Second International Workshop on RESTful Design - WS-REST '11, p ACM Press (2011) 16. Wolf, M.: Modellbasierte Spezifikation von RESTful SOA auf Basis von Geschäftsprozessmodellen. In: Mattfeld, D.C., Robra-Bissantz, S. (eds.): Multikonferenz Wirtschaftsinformatik 2012, pp GITO, Berlin (2012) 17. Fowler, M., Sadalage, P.J.: NoSQL distilled. Addison-Wesley, Boston, Mass. (2012) 18. Krücke, A., Sinz, E.J.: Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen. In: Sinz, E.J., Bartmann, D., Bodendorf, F., Ferstl, O.K. (eds.): Dienstorientierte IT-Systeme für hochflexible Geschäftsprozesse. Univ. of Bamberg Press, Bamberg (2011) 19. W3C: Web Services Description Language (WSDL) Version 2.0 Part 2: Adjuncts, OMG: Business Process Model and Notation (BPMN). Version 2.0, /spec/bpmn/2.0/pdf 21. Manyika, J., Chui, M., Brown, B., Bughin, J., Dobbs, R., Roxburgh, C. and Hung Byers, A.: Big Data: The next frontier for innovation, competition, and productivity, The_next_frontier_for_innovation 1243

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen

Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen 9 3 Web Services 3.1 Überblick Web Services stellen eine Integrationsarchitektur dar, die die Kommunikation zwischen verschiedenen Anwendungen mit Hilfe von XML über das Internet ermöglicht (siehe Abb.

Mehr

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse?

Ein Beispiel. Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Ein Beispiel Ein Unternehmen will Internettechnologien im Rahmen des E- Business nutzen Welche Geschäftsprozesse? Dipl.-Kfm. Claus Häberle WS 2015 /16 # 42 XML (vereinfacht) visa

Mehr

Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen

Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen Entwurf partieller SOA auf der Grundlage von Geschäftsprozessmodellen forflex-tagung 2011 27.05.2011 Dipl.-Wirtsch.Inf. Andree Krücke Prof. Dr. Elmar J. Sinz Gliederung 1. SOA-Ziele und Unternehmensanforderungen

Mehr

SAP NetWeaver Gateway. Connectivity@SNAP 2013

SAP NetWeaver Gateway. Connectivity@SNAP 2013 SAP NetWeaver Gateway Connectivity@SNAP 2013 Neue Wege im Unternehmen Neue Geräte und Usererfahrungen Technische Innovationen in Unternehmen Wachsende Gemeinschaft an Entwicklern Ausdehnung der Geschäftsdaten

Mehr

Implementierung von Web Services: Teil I: Einleitung / SOAP

Implementierung von Web Services: Teil I: Einleitung / SOAP Implementierung von Web Services: Teil I: Einleitung / SOAP Prof. Dr. Kanne - FSS 2007 Carl-Christian Kanne, February 25, 2007 Web Services - p. 1/12 Web Services: Allgemein XML Datenaustauschformat plattformunabhängig

Mehr

Zustandsgebundene Webservices

Zustandsgebundene Webservices Zustandsgebundene Webservices Präsentation ausgewählter Problemstellungen der Informatik Markus Oertel oer@uni-paderborn.de Universität Paderborn 25. September 2005 Zustandsgebundene Webservices Seite

Mehr

Workflow, Business Process Management, 4.Teil

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

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Feinentwurf Softwareentwicklungspraktikum Sommersemester 2007 Feinentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Skript Pilotphase em@w für Arbeitsgelegenheiten

Skript Pilotphase em@w für Arbeitsgelegenheiten Die Pilotphase erstreckte sich über sechs Meilensteine im Zeitraum August 2011 bis zur EMAW- Folgeversion 2.06 im August 2013. Zunächst einmal musste ein grundsätzliches Verständnis für das Verfahren geschaffen

Mehr

RESTful Web. Representational State Transfer

RESTful Web. Representational State Transfer RESTful Web Representational State Transfer 1 Warum REST? REST ist die Lingua Franca des Webs Heterogene (verschiedenartige) Systeme können mit REST kommunizieren, unabhängig von Technologie der beteiligten

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

Einfache und effiziente Zusammenarbeit in der Cloud. EASY-PM Office Add-Ins Handbuch

Einfache und effiziente Zusammenarbeit in der Cloud. EASY-PM Office Add-Ins Handbuch Einfache und effiziente Zusammenarbeit in der Cloud EASY-PM Office Add-Ins Handbuch Inhaltsverzeichnis 1. Einführung... 3 2. Ribbonmenü... 4 3. Dokument... 5 3.1 Öffnen... 5 3.2 Speichern... 6 3.3 Speichern

Mehr

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Java Enterprise Architekturen Willkommen in der Realität Ralf Degner (Ralf.Degner@tk-online.de), Dr. Frank Griffel (Dr.Frank.Griffel@tk-online.de) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen

Mehr

Anforderungen an die HIS

Anforderungen an die HIS Anforderungen an die HIS Zusammengefasst aus den auf IBM Software basierenden Identity Management Projekten in NRW Michael Uebel uebel@de.ibm.com Anforderung 1 IBM Software Group / Tivoli Ein Feld zum

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 9 17. Dezember 2002 www4.in.tum.de/~rumpe/se

Mehr

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08

Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements. von Stephanie Wilke am 14.08.08 Prozessbewertung und -verbesserung nach ITIL im Kontext des betrieblichen Informationsmanagements von Stephanie Wilke am 14.08.08 Überblick Einleitung Was ist ITIL? Gegenüberstellung der Prozesse Neuer

Mehr

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente

Autorisierung. Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Autorisierung Sicherheit und Zugriffskontrolle & Erstellen einer Berechtigungskomponente Dokumentation zum Referat von Matthias Warnicke und Joachim Schröder Modul: Komponenten basierte Softwareentwickelung

Mehr

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008

Diplomarbeit. Konzeption und Implementierung einer automatisierten Testumgebung. Thomas Wehrspann. 10. Dezember 2008 Konzeption und Implementierung einer automatisierten Testumgebung, 10. Dezember 2008 1 Gliederung Einleitung Softwaretests Beispiel Konzeption Zusammenfassung 2 Einleitung Komplexität von Softwaresystemen

Mehr

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP)

Enterprise Applikation Integration und Service-orientierte Architekturen. 09 Simple Object Access Protocol (SOAP) Enterprise Applikation Integration und Service-orientierte Architekturen 09 Simple Object Access Protocol (SOAP) Anwendungsintegration ein Beispiel Messages Warenwirtschaftssystem Auktionssystem thats

Mehr

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf

Softwareentwicklungspraktikum Sommersemester 2007. Grobentwurf Softwareentwicklungspraktikum Sommersemester 2007 Grobentwurf Auftraggeber Technische Universität Braunschweig

Mehr

Man liest sich: POP3/IMAP

Man liest sich: POP3/IMAP Man liest sich: POP3/IMAP Gliederung 1. Einführung 1.1 Allgemeiner Nachrichtenfluss beim Versenden von E-Mails 1.2 Client und Server 1.2.1 Client 1.2.2 Server 2. POP3 2.1 Definition 2.2 Geschichte und

Mehr

Bundeskanzlei BK Programm GEVER Bund. als Basis für GEVER. 29. November 2012

Bundeskanzlei BK Programm GEVER Bund. als Basis für GEVER. 29. November 2012 Bundeskanzlei BK Programm GEVER Bund Geschäftsprozesse als Basis für GEVER 29. November 2012 Zielsetzung der Präsentation Sie erhalten einen Überblick über den Stand der Entwicklung von GEVER als Geschäftsverwaltungssystem

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

BSI Technische Richtlinie

BSI Technische Richtlinie BSI Technische Richtlinie Bezeichnung: IT-Basisinfrastruktur Funktionalitätsspezifikation Anwendungsbereich: De-Mail Kürzel: BSI TR 01201 Teil 1.1 Version: 1.2 Bundesamt für Sicherheit in der Informationstechnik

Mehr

SDD System Design Document

SDD System Design Document SDD Software Konstruktion WS01/02 Gruppe 4 1. Einleitung Das vorliegende Dokument richtet sich vor allem an die Entwickler, aber auch an den Kunden, der das enstehende System verwenden wird. Es soll einen

Mehr

ESB - Elektronischer Service Bericht

ESB - Elektronischer Service Bericht Desk Software & Consulting GmbH ESB - Elektronischer Service Bericht Dokumentation des elektronischen Serviceberichts Matthias Hoffmann 25.04.2012 DESK Software und Consulting GmbH Im Heerfeld 2-4 35713

Mehr

Orientierungshilfen für SAP PI (Visualisierungen)

Orientierungshilfen für SAP PI (Visualisierungen) EINSATZFELDER FÜR DIE KONFIGURATIONS-SZENARIEN INTERNE KOMMUNIKATION UND PARTNER-KOMMUNIKATION UND DIE SERVICE-TYPEN BUSINESS-SYSTEM, BUSINESS-SERVICE UND INTEGRATIONSPROZESS Betriebswirtschaftliche Anwendungen

Mehr

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release

White Paper. Konfiguration und Verwendung des Auditlogs. 2012 Winter Release White Paper Konfiguration und Verwendung des Auditlogs 2012 Winter Release Copyright Fabasoft R&D GmbH, A-4020 Linz, 2011. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen

Mehr

Definition Informationssystem

Definition Informationssystem Definition Informationssystem Informationssysteme (IS) sind soziotechnische Systeme, die menschliche und maschinelle Komponenten umfassen. Sie unterstützen die Sammlung, Verarbeitung, Bereitstellung, Kommunikation

Mehr

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar?

Sind Prozessmanagement-Systeme auch für eingebettete Systeme einsetzbar? Sind Prozessmanagement-Systeme auch eingebettete Systeme einsetzbar? 12. Symposium Maritime Elektrotechnik, Elektronik und Informationstechnik, 8.-12. Oktober 2007 Rostock, Deutschland Rostock, Deutschland

Mehr

Erstellen einer E-Mail in OWA (Outlook Web App)

Erstellen einer E-Mail in OWA (Outlook Web App) Erstellen einer E-Mail in OWA (Outlook Web App) Partner: 2/12 Versionshistorie: Datum Version Name Status 13.09.2011 1.1 J. Bodeit Punkte 7 hinzugefügt, alle Mailempfänger unkenntlich gemacht 09.09.2011

Mehr

SSI WHITE PAPER Design einer mobilen App in wenigen Stunden

SSI WHITE PAPER Design einer mobilen App in wenigen Stunden Moderne Apps für Smartphones und Tablets lassen sich ohne großen Aufwand innerhalb von wenigen Stunden designen Kunde Branche Zur Firma Produkte Übersicht LFoundry S.r.l Herrngasse 379-381 84028 Landshut

Mehr

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum

Agile Vorgehensmodelle in der Softwareentwicklung: Scrum C A R L V O N O S S I E T Z K Y Agile Vorgehensmodelle in der Softwareentwicklung: Scrum Johannes Diemke Vortrag im Rahmen der Projektgruppe Oldenburger Robot Soccer Team im Wintersemester 2009/2010 Was

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

Integration verteilter Datenquellen in GIS-Datenbanken

Integration verteilter Datenquellen in GIS-Datenbanken Integration verteilter Datenquellen in GIS-Datenbanken Seminar Verteilung und Integration von Verkehrsdaten Am IPD Lehrstuhl für Systeme der Informationsverwaltung Sommersemester 2004 Christian Hennings

Mehr

Updatebeschreibung JAVA Version 3.6 und Internet Version 1.2

Updatebeschreibung JAVA Version 3.6 und Internet Version 1.2 Updatebeschreibung JAVA Version 3.6 und Internet Version 1.2 Hier finden Sie die Beschreibung der letzten Änderungen und Aktualisierungen. Bei Fragen und Anregungen steht das EDI-Real-Team unter +43 732

Mehr

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz

Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Anwendungshandbuch Vorgaben und Erläuterungen zu den XML-Schemata im Bahnstromnetz Version: 1.0 Herausgabedatum: 31.07.2015 Ausgabedatum: 01.11.2015 Autor: DB Energie http://www.dbenergie.de Seite: 1 1.

Mehr

Die Lernumgebung des Projekts Informationskompetenz

Die Lernumgebung des Projekts Informationskompetenz Beitrag für Bibliothek aktuell Die Lernumgebung des Projekts Informationskompetenz Von Sandra Merten Im Rahmen des Projekts Informationskompetenz wurde ein Musterkurs entwickelt, der den Lehrenden als

Mehr

1 Einleitung. 1.1 Motivation und Zielsetzung der Untersuchung

1 Einleitung. 1.1 Motivation und Zielsetzung der Untersuchung 1 Einleitung 1.1 Motivation und Zielsetzung der Untersuchung Obgleich Tourenplanungsprobleme zu den am häufigsten untersuchten Problemstellungen des Operations Research zählen, konzentriert sich der Großteil

Mehr

White Paper. Installation und Konfiguration der PVP Integration

White Paper. Installation und Konfiguration der PVP Integration Copyright Fabasoft R&D GmbH, A-4020 Linz, 2010. Alle Rechte vorbehalten. Alle verwendeten Hard- und Softwarenamen sind Handelsnamen und/oder Marken der jeweiligen Hersteller. Diese Unterlagen sind streng

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

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

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

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER

Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos im Zusammenspiel mit shop to date von DATA BECKER Abamsoft Finos in Verbindung mit der Webshopanbindung wurde speziell auf die Shop-Software shop to date von DATA BECKER abgestimmt. Mit

Mehr

Erstellung eines Verfahrensverzeichnisses aus QSEC

Erstellung eines Verfahrensverzeichnisses aus QSEC Erstellung eines Verfahrensverzeichnisses aus QSEC Im QSEC-Reporting-Modul steht ab der Version 4.2 ein neuer Bericht zur Verfügung. Es besteht nun die Möglichkeit, einen BDSG-konformen Datenschutzbericht

Mehr

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 17: 3-Schichten-Architektur 2

Drei-Schichten-Architektur. Informatik B - Objektorientierte Programmierung in Java. Vorlesung 17: 3-Schichten-Architektur 2 Universität Osnabrück 1 3 - Objektorientierte Programmierung in Java Zur Erinnerung: Aufteilung der Schichten GUI Vorlesung 17: 3-Schichten-Architektur 2 Fachkonzept Fachkonzept - Datenhaltung Datenhaltung

Mehr

Flash, Network und Facebook. Steven Mohr steven@stevenmohr.de

Flash, Network und Facebook. Steven Mohr steven@stevenmohr.de Flash, Network und Facebook Steven Mohr steven@stevenmohr.de Gliederung 1. Wie ist eine Facebook-App aufgebaut 2. Basics 3. Erste Demo einer kleinen Flash-Facebook-App 4. Friends, Achievements und Invites

Mehr

Arbeiten mit den Mastercam Werkzeug-Managern

Arbeiten mit den Mastercam Werkzeug-Managern Arbeiten mit den Mastercam Werkzeug-Managern Mastercam besitzt zwei Werkzeug-Manager zum Anlegen, Ändern und Verwalten Ihrer Werkzeuge; wobei der eine als (klassischer) WZ-Manager und der andere als (stand-alone)

Mehr

Ein mobiler Electronic Program Guide

Ein mobiler Electronic Program Guide Whitepaper Telekommunikation Ein mobiler Electronic Program Guide Ein iphone Prototyp auf Basis von Web-Technologien 2011 SYRACOM AG 1 Einleitung Apps Anwendungen für mobile Geräte sind derzeit in aller

Mehr

Betr.: Neuerungen eps Online-Überweisung

Betr.: Neuerungen eps Online-Überweisung Studiengesellschaft für Zusammenarbeit im Zahlungsverkehr GmbH. Tel. +43/1/505 32 80-0 Fax: +43/1/505 32 80-77 Internet: www.stuzza.at E-Mail: office@stuzza.at A-1070 Wien, Stiftgasse 15-17/8 Betr.: Neuerungen

Mehr

Inhalt. meliarts. 1. Allgemeine Informationen... 2 2. Administration... 2 2.1 Aufruf... 2 2.2 Das Kontextmenü... 3 3. E-Mail Vorlagen...

Inhalt. meliarts. 1. Allgemeine Informationen... 2 2. Administration... 2 2.1 Aufruf... 2 2.2 Das Kontextmenü... 3 3. E-Mail Vorlagen... Inhalt 1. Allgemeine Informationen... 2 2. Administration... 2 2.1 Aufruf... 2 2.2 Das Kontextmenü... 3 3. E-Mail Vorlagen... 4 Seite 1 von 7 meliarts 1. Allgemeine Informationen meliarts ist eine Implementierung

Mehr

Durchführung der Datenübernahme nach Reisekosten 2011

Durchführung der Datenübernahme nach Reisekosten 2011 Durchführung der Datenübernahme nach Reisekosten 2011 1. Starten Sie QuickSteuer Deluxe 2010. Rufen Sie anschließend über den Menüpunkt /Extras/Reisekosten Rechner den QuickSteuer Deluxe 2010 Reisekosten-Rechner,

Mehr

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI?

Service. Was ist eine Enterprise Service Architecture und wie reagiert SAP. Warum Monitoring in ZENOS, was monitort die XI? Service Was ist eine Enterprise Service Architecture und wie reagiert SAP Allgemeine Definition Was gehört in ZENOS (Service-Layer)? Business Logik ZENOS als Provider für SAP-based Services (ESA/SOA) Warum

Mehr

Online Banking System

Online Banking System Online Banking System Pflichtenheft im Rahmen des WI-Praktikum bei Thomas M. Lange Fachhochschule Giessen-Friedberg Fachbereich MNI Studiengang Informatik Erstellt von: Eugen Riske Yueksel Korkmaz Alper

Mehr

Beschreibung des MAP-Tools

Beschreibung des MAP-Tools 1. Funktionen des MAP-Tool 2. Aufbau des MAP-Tools 3. Arbeiten mit dem MAP-Tool Beschreibung MAP-Tool.doc Erstellt von Thomas Paral 1 Funktionen des MAP-Tool Die Hauptfunktion des MAP-Tools besteht darin,

Mehr

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5

Systemen im Wandel. Autor: Dr. Gerd Frenzen Coromell GmbH Seite 1 von 5 Das Management von Informations- Systemen im Wandel Die Informations-Technologie (IT) war lange Zeit ausschließlich ein Hilfsmittel, um Arbeitsabläufe zu vereinfachen und Personal einzusparen. Sie hat

Mehr

PHP Kurs Online Kurs Analysten Programmierer Web PHP

PHP Kurs Online Kurs Analysten Programmierer Web PHP PHP Kurs Online Kurs Analysten Programmierer Web PHP Akademie Domani info@akademiedomani.de Allgemeines Programm des Kurses PHP Modul 1 - Einführung und Installation PHP-Umgebung Erste Lerneinheit Introduzione

Mehr

Installationsanleitung für CashPro im Mehrbenutzerzugriff/Netzwerkbetrieb

Installationsanleitung für CashPro im Mehrbenutzerzugriff/Netzwerkbetrieb Installationsanleitung für CashPro im Mehrbenutzerzugriff/Netzwerkbetrieb CashPro basiert auf Accesstechnologie 2003 und ist auch unter den aktuellen Accessversionen 2007 bis 2013 einsetzbar und Mehrbenutzerfähig.

Mehr

7. Übung - Datenbanken

7. Übung - Datenbanken 7. Übung - Datenbanken Informatik I für Verkehrsingenieure Aufgaben inkl. Beispiellösungen 1. Aufgabe: DBS a Was ist die Kernaufgabe von Datenbanksystemen? b Beschreiben Sie kurz die Abstraktionsebenen

Mehr

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek

arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek arlanis Software AG SOA Architektonische und technische Grundlagen Andreas Holubek Speaker Andreas Holubek VP Engineering andreas.holubek@arlanis.com arlanis Software AG, D-14467 Potsdam 2009, arlanis

Mehr

Speicher in der Cloud

Speicher in der Cloud Speicher in der Cloud Kostenbremse, Sicherheitsrisiko oder Basis für die unternehmensweite Kollaboration? von Cornelius Höchel-Winter 2013 ComConsult Research GmbH, Aachen 3 SYNCHRONISATION TEUFELSZEUG

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

WEBINAR@LUNCHTIME THEMA: "SAS STORED PROCESSES - SCHNELL GEZAUBERT" HELENE SCHMITZ

WEBINAR@LUNCHTIME THEMA: SAS STORED PROCESSES - SCHNELL GEZAUBERT HELENE SCHMITZ WEBINAR@LUNCHTIME THEMA: "SAS STORED PROCESSES - SCHNELL GEZAUBERT" HELENE SCHMITZ HERZLICH WILLKOMMEN BEI WEBINAR@LUNCHTIME Moderation Anne K. Bogner-Hamleh SAS Institute GmbH Education Consultant Training

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

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten

Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei Lieferanten Handelsplatz Köln.de Leitfaden zur Projektplanung bei en Realisierung der Anbindung an den Handelsplatz Koeln.de Leitfaden zur Projektplanung bei en Autor: Christoph Winkelhage Status: Version 1.0 Datum:

Mehr

Generierung von Serviceverträgen auf Basis objektorientierter ereignisgesteuerter Prozessketten

Generierung von Serviceverträgen auf Basis objektorientierter ereignisgesteuerter Prozessketten Generierung von Serviceverträgen auf Basis objektorientierter ereignisgesteuerter Prozessketten Jörg Hartmann Universität Leipzig jhartmann@informatik.uni-leipzig.de 25.09.2012 Jörg Hartmann, SKIL 2012,

Mehr

Prof. Dr.-Ing. Rainer Schmidt 1

Prof. Dr.-Ing. Rainer Schmidt 1 Prof. Dr.-Ing. Rainer Schmidt 1 Business Analytics und Big Data sind Thema vieler Veröffentlichungen. Big Data wird immer häufiger bei Google als Suchbegriff verwendet. Prof. Dr.-Ing. Rainer Schmidt 2

Mehr

Look Inside: desite. modellorientiertes Arbeiten im Bauwesen. B.I.M.

Look Inside: desite. modellorientiertes Arbeiten im Bauwesen. B.I.M. Building Information Modeling Look Inside: desite modellorientiertes Arbeiten im Bauwesen. B.I.M. desite MD unterstützt Sie bei der täg lichen Arbeit mit Gebäudemodellen und ermöglicht den Zugang zu den

Mehr

Kommunikations-Management

Kommunikations-Management Tutorial: Wie importiere und exportiere ich Daten zwischen myfactory und Outlook? Im vorliegenden Tutorial lernen Sie, wie Sie in myfactory Daten aus Outlook importieren Daten aus myfactory nach Outlook

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

Arbeiten mit UMLed und Delphi

Arbeiten mit UMLed und Delphi Arbeiten mit UMLed und Delphi Diese Anleitung soll zeigen, wie man Klassen mit dem UML ( Unified Modeling Language ) Editor UMLed erstellt, in Delphi exportiert und dort so einbindet, dass diese (bis auf

Mehr

teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep

teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep teischl.com Software Design & Services e.u. office@teischl.com www.teischl.com/booknkeep www.facebook.com/booknkeep 1. Erstellen Sie ein neues Rechnungsformular Mit book n keep können Sie nun Ihre eigenen

Mehr

Datenanalyse - Schnittstellendesign

Datenanalyse - Schnittstellendesign Datenanalyse - Schnittstellendesign Der Plan ist es eine Schnittstelle zu konstruieren, die aus Future Wertpapier- und Kontotransaktionen eine Wertpapiertransaktion generiert, die bereits den aus dem Geschäft

Mehr

Java und XML 2. Java und XML

Java und XML 2. Java und XML Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Java und XML Hauptseminar Telematik WS 2002/2003

Mehr

Stand 10.2011 vr bank Südthüringen eg 1 von 10. Smart TAN plus Umstellungsanleitung VR-NetWorld Software

Stand 10.2011 vr bank Südthüringen eg 1 von 10. Smart TAN plus Umstellungsanleitung VR-NetWorld Software Stand 10.2011 vr bank Südthüringen eg 1 von 10 Smart TAN plus Umstellungsanleitung VR-NetWorld Software INHALTSVERZEICHNIS 1. Einführung 3 2. Allgemeine Informationen 4 3. Schritt 1 die Anmeldung des Generators

Mehr

Prüfung Software Engineering I (IB)

Prüfung Software Engineering I (IB) Hochschule für angewandte Wissenschaften München Fakultät für Informatik und Mathematik Studiengruppe IB 4 A Sommersemester 2015 Prüfung Software Engineering I (IB) Datum : 09.07.2015, 14:30 Uhr Bearbeitungszeit

Mehr

Homebanking-Abkommen

Homebanking-Abkommen Homebanking-Abkommen Der Bundesverband der Deutschen Volksbanken und Raiffeisenbanken e.v., Bonn, Bundesverband deutscher Banken e.v., Köln, Bundesverband Öffentlicher Banken Deutschlands e.v., Bonn Deutscher

Mehr

Sybase Central Dokumentation Aktivierung der Monitoringfunktion

Sybase Central Dokumentation Aktivierung der Monitoringfunktion Sybase Central Dokumentation Aktivierung der Monitoringfunktion Version 1.0 14. Dezember 2012 Inhaltsverzeichnis 1 EINLEITUNG... 3 2 ZIELSETZUNG... 3 3 VORGEHENSWEISE... 3 4 ANHANG... 7 4.1 DOKUMENTHISTORIE...

Mehr

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695

Database Exchange Manager. Infinqa IT Solutions GmbH, Berlin Stralauer Allee 2 10245 Berlin Tel.:+49(0) 30 2900 8639 Fax.:+49(0) 30 2900 8695 Database Exchange Manager Replication Service- schematische Darstellung Replication Service- allgemeines Replikation von Daten von bzw. in ein SAP-System und einer relationalen DMS-Datenbank Kombination

Mehr

IDS-Connect Warenkorbaustausch mit dem Großhandel Kurzbeschreibung

IDS-Connect Warenkorbaustausch mit dem Großhandel Kurzbeschreibung PN Handwerk IDS-Connect Warenkorbaustausch mit dem Großhandel Kurzbeschreibung PN Software Inhalt IDS-CONNECT... 3 Folgende Funktionen werden unterstützt:... 3 Einstellungen... 3 Artikel-Info... 8 Warenkorb

Mehr

How to do? Projekte - Zeiterfassung

How to do? Projekte - Zeiterfassung How to do? Projekte - Zeiterfassung Stand: Version 4.0.1, 18.03.2009 1. EINLEITUNG...3 2. PROJEKTE UND STAMMDATEN...4 2.1 Projekte... 4 2.2 Projektmitarbeiter... 5 2.3 Tätigkeiten... 6 2.4 Unterprojekte...

Mehr

Support-Tipp Mai 2010 - Release Management in Altium Designer

Support-Tipp Mai 2010 - Release Management in Altium Designer Support-Tipp Mai 2010 - Release Management in Altium Designer Mai 2010 Frage: Welche Aufgaben hat das Release Management und wie unterstützt Altium Designer diesen Prozess? Zusammenfassung: Das Glück eines

Mehr

How-to: Webserver NAT. Securepoint Security System Version 2007nx

How-to: Webserver NAT. Securepoint Security System Version 2007nx Securepoint Security System Inhaltsverzeichnis Webserver NAT... 3 1 Konfiguration einer Webserver NAT... 4 1.1 Einrichten von Netzwerkobjekten... 4 1.2 Erstellen von Firewall-Regeln... 6 Seite 2 Webserver

Mehr

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement

Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement Abschlussklausur Geschäftsprozessmodellierung und Workflowmanagement (Wintersemester 2007/2008, Freitag, 08.02.2008, Leo18) Es können maximal 120 Punkte erreicht werden. 1 Punkt entspricht etwa einer Minute

Mehr

EINFÜHRUNG 06.06.2013 IOZ AG 1

EINFÜHRUNG 06.06.2013 IOZ AG 1 BPMN BPMN2.0 EINFÜHRUNG 06.06.2013 IOZ AG 1 EINFÜHRUNG GESCHÄFTSPROZESSMODELLIERUNG Was ist Geschäftsprozessmodellierung? Darstellung von geschäftlichen Abläufen und deren Interaktion Was wird inhaltlich

Mehr

ICS-Addin. Benutzerhandbuch. Version: 1.0

ICS-Addin. Benutzerhandbuch. Version: 1.0 ICS-Addin Benutzerhandbuch Version: 1.0 SecureGUARD GmbH, 2011 Inhalt: 1. Was ist ICS?... 3 2. ICS-Addin im Dashboard... 3 3. ICS einrichten... 4 4. ICS deaktivieren... 5 5. Adapter-Details am Server speichern...

Mehr

VENTA KVM mit Office Schnittstelle

VENTA KVM mit Office Schnittstelle VENTA KVM mit Office Schnittstelle Stand: 24.05.2013 Version: VENTA 1.7.5 Verfasser: Jan Koska 1. Funktionsumfang der Office Schnittstelle Die in VENTA KVM integrierte Office Schnittstelle bietet zahlreiche

Mehr

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem

Fachbericht zum Thema: Anforderungen an ein Datenbanksystem Fachbericht zum Thema: Anforderungen an ein Datenbanksystem von André Franken 1 Inhaltsverzeichnis 1 Inhaltsverzeichnis 1 2 Einführung 2 2.1 Gründe für den Einsatz von DB-Systemen 2 2.2 Definition: Datenbank

Mehr

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009

Geschäftsprozesse modellieren mit BPMN. Nürnberg, 10.11.2009 Geschäftsprozesse modellieren mit BPMN Nürnberg, 10.11.2009 I N H A L T 1. Warum noch ein Notation? 2. Grundlegende BPMN-Elemente 3. Prozess versus Interaktion 4. Services 5. Fazit Warum noch eine Notation?

Mehr

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper)

Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10. Technische Informationen (White Paper) Upgrade auf die Standalone Editionen von Acronis Backup & Recovery 10 Technische Informationen (White Paper) Inhaltsverzeichnis 1. Über dieses Dokument... 3 2. Überblick... 3 3. Upgrade Verfahren... 4

Mehr

GS-Programme 2015 Allgemeines Zentralupdate

GS-Programme 2015 Allgemeines Zentralupdate GS-Programme 2015 Allgemeines Zentralupdate Impressum Business Software GmbH Primoschgasse 3 9020 Klagenfurt Copyright 2014 Business Software GmbH Die Inhalte und Themen in dieser Unterlage wurden mit

Mehr

Ihre Interessentendatensätze bei inobroker. 1. Interessentendatensätze

Ihre Interessentendatensätze bei inobroker. 1. Interessentendatensätze Ihre Interessentendatensätze bei inobroker Wenn Sie oder Ihre Kunden die Prozesse von inobroker nutzen, werden Interessentendatensätze erzeugt. Diese können Sie direkt über inobroker bearbeiten oder mit

Mehr

Erfassung von Umgebungskontext und Kontextmanagement

Erfassung von Umgebungskontext und Kontextmanagement Erfassung von Umgebungskontext und Kontextmanagement Jörg Schneider, Christian Mannweiler, Andreas Klein, Hans D. Schotten 13.05.2009 Inhalt 1. Einleitung 2. Anforderungen 3. Kontext Erfassung und Verteilung

Mehr

Übung: Verwendung von Java-Threads

Übung: Verwendung von Java-Threads Übung: Verwendung von Java-Threads Ziel der Übung: Diese Übung dient dazu, den Umgang mit Threads in der Programmiersprache Java kennenzulernen. Ein einfaches Java-Programm, das Threads nutzt, soll zum

Mehr

Modellbasierte Spezifikation von RESTful SOA auf Basis von Geschäftsprozessmodellen

Modellbasierte Spezifikation von RESTful SOA auf Basis von Geschäftsprozessmodellen Modellbasierte Spezifikation von RESTful SOA auf Basis von Geschäftsprozessmodellen Matthias Wolf Veröffentlicht in: Multikonferenz Wirtschaftsinformatik 2012 Tagungsband der MKWI 2012 Hrsg.: Dirk Christian

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

Übungsklausur vom 7. Dez. 2007

Übungsklausur vom 7. Dez. 2007 Übungsklausur vom 7. Dez. 2007 Ein Lösungsmuster Teilbereiche der Softwaretechnik Software Anforderungen Software Entwurf Software Konstruktion Software Test Software Wartung Software Konfigurationsmanagement

Mehr

Task: Nmap Skripte ausführen

Task: Nmap Skripte ausführen Task: Nmap Skripte ausführen Inhalt Einfache Netzwerkscans mit NSE Ausführen des Scans Anpassung der Parameter Einleitung Copyright 2009-2015 Greenbone Networks GmbH Herkunft und aktuellste Version dieses

Mehr

Objektorientierte Programmierung

Objektorientierte Programmierung Objektorientierte Programmierung 1 Geschichte Dahl, Nygaard: Simula 67 (Algol 60 + Objektorientierung) Kay et al.: Smalltalk (erste rein-objektorientierte Sprache) Object Pascal, Objective C, C++ (wiederum

Mehr