Integration von SBVR in Workflows der Windows Workflow Foundation und Veröffentlichung unter Microsoft SharePoint

Inhaltsverzeichnis

Eidesstattliche Erklärung

Tabellenverzeichnis

Abbildungsverzeichnis

SBVR Beispiele

Abkürzungsverzeichnis

Danksagung

Abstract

Kurzfassung

1 Einleitung
1.1 Problemstellung
1.1.1 Motivation
1.1.2 Fragestellungen
1.1.3 Arbeitshypothesen
1.2 Zielsetzung und Aufbau der Arbeit

2 Loslösen der Geschäftsregeln von Geschäftsprozessen

3 SBVR
3.1 Überblick
3.2 Business Vocabulary
3.2.1 Noun- und Verb Concepts
3.2.1.1 Noun-Concepts
3.2.1.2 Verb Concept
3.3 Business Rules
3.3.1 Arten von Business Rules
3.3.1.1 Strukturelle Business Rules
3.3.1.2 Operative Business Rules
3.4 SBVR Structured English
3.4.1 Font Style
3.4.2 Schlüsselwörter und Phrasen für logische Formulierungen
3.4.2.1 Modal Formulation
3.4.2.2 Quantification
3.4.2.3 Logische Operatoren
3.4.3 Weitere Schlüsselwörter
3.5 Logical Formulation
3.5.1 RuleMotion
3.6 Fazit

4 Microsoft Windows Workflow Foundation
4.1 Überblick
4.2 Microsoft SharePoint Server
4.2.1 Editionen und Lizenzen
4.3 Integration der Workflow Foundation in SharePoint
4.4 Workflowtypen
4.5 Entwicklungsvarianten
4.5.1 XAML
4.6 Workflow Rules
4.6.1 Code Condition
4.6.2 Rule Conditions
4.7 SharePoint Designer
4.8 Fazit

5 Prototyp
5.1 Zielsetzung
5.2 Vorgehensweise
5.2.1 Konzept
5.3 Geschäftsprozess
5.4 SBVR Business Rules
5.5 Umsetzung
5.5.1 SharePoint Designer
5.5.2 Programmatischer Teil
5.5.2.1 Deserialisierung der Logical Formulation
5.5.2.2 Mapping
5.5.2.3 SharePoint Versionsverwaltung und Veröffentlichung
5.5.2.4 Zusammenfassung
5.6 Szenario
5.7 Ergebnisse
5.7.1 Workflow Rules File
5.7.2 SharePoint Designer
5.7.3 Workflow Instanziierung am SharePoint Server
5.8 Fazit

6 Diskussion
6.1 Erkenntnisgewinn
6.2 Kritik
6.3 Fazit und Ausblick

7 Anhang

8 Bibliographie

Eidesstattliche Erklärung

Ich erkläre hiermit an Eides statt, dass ich die vorliegende Arbeit selbststän- dig und ohne Benutzung anderer als der angegebenen Hilfsmittel angefertigt habe. Die aus fremden Quellen direkt oder indirektübernommenen Gedan- ken sind als solche kenntlich gemacht. Die Arbeit wurde bisher in gleicher oder ähnlicher Form keiner anderen Prüfungskommission vorgelegt und auch nicht veröffentlicht

Graz, August 2012

Christoph Daniel Zoller, BSc

Tabellenverzeichnis

Tabelle 1: SBVR Modal Operators und deren logische Äquivalenz

Tabelle 2: SBVR Quantification

Tabelle 3: Logical Operators

Tabelle 4: Common Workflow Attributes

Tabelle 5: Prototyp - Quantification Mapping

Tabelle 6: Prototyp - Mapping Ergebnisse bei Workflowausführung

Abbildungsverzeichnis

Abbildung 1: Arbeitshypothesen

Abbildung 2: Struktur der Diplomarbeit

Abbildung 3: Trennung von Geschäftsprozessen und Business Rules

Abbildung 4: Operative und strukturelle Business Rules

Abbildung 5: Auszug aus dem SBVR Metamodell

Abbildung 6: Grundlegende Aufbau von SBVR

Abbildung 7: Logische Formulierungen

Abbildung 8: Modal Formulation

Abbildung 9: Hierarchie von Semantic Formulation

Abbildung 10: RuleMotion SBVR-Editor

Abbildung 11: .NET Framework Architektur

Abbildung 12: Workflows in SharePoint

Abbildung 13: Rule Condition Editor

Abbildung 14: Überblick der Vorgehensweise im Prototyp

Abbildung 15: Prototyp - Geschäftsprozess in BPMN Notation

Abbildung 16: Prototyp - SharePoint List „Rental“

Abbildung 17: Prototyp - Workflowdarstellung im SharePoint Designer

Abbildung 18: Prototyp - Initiation Form Parameters

Abbildung 19: Prototyp - Workflow Driver Licence Approval Task

Abbildung 20: Prototyp - Auswahl des Autotypen mit „Van“

Abbildung 21: Prototyp - Auswahl des Autotypen mit „Van“

Abbildung 22: Prototyp - Task List

Abbildung 23: Prototyp - Klassendiagramm

Abbildung 24: Prototyp - Befülltes Klassendiagramm

Abbildung 25: Prototyp - Ablauf der programmatischen Umsetzung

Abbildung 26: Prototyp - Publish Workflow Button

Abbildung 27: Prototyp - Workflowinstanziierung vor Mapping

Abbildung 28: Prototyp - Workflowinstanziierung nach Mapping

Abbildung 29: Prototyp - Vorher-Nachher Vergleich Workflow Tasks

Abbildung 30: Zusammenspiel IT - Business

Listings

Listing 1: Logical Formulation in verbalisierter Form

Listing 2: RuleMotion's Interpretation von Logical Formulation

Listing 3: Workflow Definition Schema

Listing 4: Reiner XAML Workflows

Listing 5: Reiner C# Workflow

Listing 6: Mischung aus C# und XAML Workflow

Listing 7: XAML Workflow Grundgerüst

Listing 8: Code Condition

Listing 9: Workflow Rules Bespiel

Listing 10: Prototyp - Deserialisierung Logical Formulation (Auszug)

Listing 11: Prototyp - Editieren des .xoml.rules File

Listing 12: Prototyp - Versions File

Listing 13: Prototyp - Workflow Config File

Listing 14: Prototyp - Edit Rules Version in der Workflow Config

Listing 15: Prototyp - Update Config Version und Veröffentlichung

Listing 16: Prototyp - Vorher-Nachher-Vergleich des Rules Files

Listing 17: Prototyp - Auszug der SBVR Logical Formulation

Listing 18: Prototyp - Workflow Rules File

SBVR Beispiele

SBVR Beispiel 1: Fact Type

SBVR Beispiel 2: Characteristic

SBVR Beispiel 3: n-ary Fact Type

SBVR Beispiel 4: Necessity Statement

SBVR Beispiel 5: Impossibility Statement

SBVR Beispiel 6: Restricted Possibility Statement

SBVR Beispiel 7: Obligation Statement

SBVR Beispiel 8: Prohibition Statement

SBVR Beispiel 9: Restricted Permission Statement

SBVR Beispiel 10: Schlüsselwort „the“

SBVR Beispiel 11: Schlüsselwort „that“

SBVR Beispiel 12: Umwandlung Logical Formulation

SBVR Beispiel 13: Prototyp - Eingesetzte Business Rules

SBVR Beispiel 14: Prototyp - Mapping Business Rule

SBVR Beispiel 15: Prototyp - Modifizierte Mapping Business Rule

Abkürzungsverzeichnis

Abbildung in dieser Leseprobe nicht enthalten

Danksagung

An erster Stelle bedanke ich mich bei meiner Familie, insbesondere bei mei- nen Eltern, die mich im Zuge meiner gesamten Ausbildung immer unterstützt haben. Sie gaben mir zu jeder Zeit den notwendigen Rückhalt, auch in schwierigen Zeiten.

Des Weiteren danke ich meinem Diplomarbeitsbetreuer, FH-Prof. Dr. DI Erwin Zinser, aber auch DI(FH) Alexander Sellner, die mir sowohl in fachlicher als auch in persönlicher Hinsicht eine große Hilfe waren. Sie gaben mir die richtungsweisenden Impulse und Antworten auf meine Fragen, die einen großen Anteil zum Erfolg meiner Diplomarbeit beigetragen haben.

Nicht zuletzt möchte ich mich bei Wilfried Mittendrein und Gerhard Rabl für die äußerst genaue und zeitintensive Korrektur meiner Diplomarbeit bedan- ken.

Abstract

Modern business processes are subject to many influences. These influences arise from fast progress, such as legal and technological changes, as well as from the rapid development of markets. In order to consider all influences on business processes and general business design respectively, so-called Business Rules are introduced. Business Rules are obliged to be adaptable not only by IT-professionals but also by business people. To meet these re- quirements, this Master Thesis deals with the question of how to express business rules that can be validated and interpreted by machines and how to integrate them into business processes.

Besides providing theoretical background of Semantic Business Rules and Business Vocabulary (SBVR) and the Microsoft Windows Workflow Founda- tion (WWF), this Master Thesis presents a concept of how to map SBVR Business Rules to WWF workflows. In this regard a simple sequential work- flow with conditions expressed in declarative language are created. In further consequence, the prototype works as a mapper that enables SBVR Business Rules to effect on workflow-conditions. Moreover, the prototype clarifies if this intervention has direct impact on already published workflows.

Results show that Business Rules expressed in SBVR can intervene WWF workflows. Hence more flexibility is enabled when modifications have to be executed. Additionally, it has been shown that modifications made by the mapper have no direct effect on already deployed workflows.

SBVR proves to be technically very useful and enables interesting fields in developing workflows with flexible adaptability for business people. The prototype implementation proves the constructed concept of integrating business rules expressed in SBVR into WWF workflows.

For future investigations this thesis shows that an integration of SBVR Business Rules into WWF workflows is basically possible. Since workflowmodifications by the mapper have no direct effect on already deployed workflows, more investigations in this regard are required.

Kurzfassung

Moderne Geschäftsprozesse unterliegen einer Vielzahl an Einflüssen, welche sich aus der Schnelllebigkeit der Zeit, wie beispielsweise gesetzliche und technologische Veränderungen, sowie ständig wechselnde Marktentwicklun- gen, ergeben. Um all diese Einflüsse in Geschäftsprozessen bzw. im generel- len Businessdesign berücksichtigen zu können, wurden sogenannte Ge- schäftsregeln eingeführt. Von diesen wird heutzutage vorausgesetzt, dass sie im hohen Grade adaptierbar sind. Darüber hinaus wird gefordert, dass diese Adaptierbarkeit nicht nur durch IT-Personal sondern auch durch Personen aus den Fachbereichen durchgeführt werden kann. Um all diesen Anforde- rungen gerecht zu werden, behandelt diese Diplomarbeit die Integration von Semantic Business Vocabulary and Business Rules (SBVR) in Geschäftspro- zessen.

Neben dem theoretischen Basiswissen rund um SBVR und der Microsoft Windows Workflow Foundation (WWF) wird in dieser Arbeit ein Prototyp er- stellt, welcher SBVR Business Rules in WWF Workflows abbildet (mapped). Dabei wird ein sequentieller Workflow erstellt, in dessen Bedingungen mithilfe des Prototyps eingegriffen wird. Zudem wird geklärt, ob diese Eingriffe unmit- telbar Auswirkungen auf bereits veröffentlichte Workflows haben.

Es konnte erfolgreich festgestellt werden, dass SBVR Business Rules in WWF Workflows abgebildet werden können. Des Weiteren wurde zur Er- kenntnis gebracht, dass Veränderungen durch den Prototyp nicht unmittelbar auf bereits am SharePoint Server veröffentlichte Workflows Einfluss haben.

Zusammenfassend kann festgehalten werden, dass SBVR ein technologisch sehr brauchbarer Standard ist und in der Entwicklung von Workflows sowie der in geforderten Adaptierbarkeit großes Potential in sich trägt.

Für zukünftige Untersuchungen konnte in dieser Arbeit gezeigt werden, dass eine Integration von SBVR in WWF Workflows möglich ist. Da Workflow- Modifikationen durch den Prototyp am SharePoint Server keine unmittelbare Wirkung zeigten, sind in diesem Feld weitere Untersuchungen erforderlich.

1 Einleitung

Werden in Unternehmen, unabhängig von ihrer Branche oder Größe, Ge- schäftsprozesse eingeführt, stehen Faktoren wie Geschwindigkeit, Kosten- bewusstsein, Standardisierung, die Automatisierung von Abläufen mithilfe von Informationstechnologien und eine schnelle Modifizierbarkeit im Vordergrund. Diese Faktoren sind wesentlich, um prozessbezogene Zielsetzungen dauer- haft erreichen zu können. Vor allem jedoch stellen effiziente Modifikations- und Anpassungsfähigkeiten von Prozessen, welche durch Gesetzesänderun- gen, Marktentwicklungen oder anderen Einflüssen bedingt sind, große Her- ausforderungen in Unternehmen dar. Um diesen Anforderungen gerecht zu werden, müssen Unternehmen effiziente Geschäftsprozesse definieren und ausführen, mit denen agil auf die unterschiedlichsten Einflüsse reagiert wer- den kann (vgl. Grob u. a., 2008, S. 368; Scheer u. a., 2010, S. 12).

Unternehmen, welche mit möglichst wenig Zeitverzögerung auf neue Anforderungen reagieren können und imstande sind, ihre internen Strukturen (Ziele, Prozesse und Strategie) anzupassen, werden Real-Time-Enterprises (RTE) genannt. Um dieses Ziel erreichen zu können, ist es zum einen notwendig, dass die zum Teil komplexen Prozesse effizient anpassbar bzw. modifizierbar gestaltet werden. Zum anderen müssen richtige Entscheidungen bezüglich Prozessmodifikationen möglichst zeitnah getroffen werden. Diese Diplomarbeit befasst sich vor allem mit der ersten Anforderung der effizienten Modifizierbarkeit (vgl. Scheer u. a., 2010, S. 2-5).

Informationssysteme, in denen Geschäftsprozesse einwirken, müssen in wei- terer Hinsicht nicht nur schnell und effizient modifizierbar sein, sondern es müssen Änderungen auch im laufenden Betrieb vollzogen werden können. Ein weiterer Faktor in diesem Zusammenhang ist eine schnelle Lokalisierbar- keit der betroffenen Stelle, an der Änderungen notwendig sind. Diese beiden Anforderungen sind erforderlich, da Stillstandszeiten in Unternehmen unmit- telbar umsatzwirksam sind und von Unternehmenskunden in der Regel nicht toleriert werden (vgl. Endl, 2004, S. 4).

1.1 Problemstellung

1.1.1 Motivation

Inkonsistenzen in der Transformation von Businessanforderungen hin zur IT, auch unter dem Begriff „Business-IT-Gap“ bekannt, stellen nach wie vor gro- ße Herausforderungen in Unternehmen dar. Dieser „Gap“ entsteht auf der einen Seite oftmals durch ineffiziente und missverständliche Kommunikation zwischen IT und Business. Auf der anderen Seite kommt es vor, dass die eingesetzten IT-Systeme zwar fehlerfrei sind, die organisatorische Ausrich- tung des Unternehmens jedoch nur unzureichend im System berücksichtigt wird. Dies sind nur zwei mögliche Ursachen, warum IT und Business nicht wie erwartet zusammenarbeiten. In dieser Diplomarbeit wird dabei speziell auf den Eingriff in Geschäftsprozesse mithilfe von Business Rules eingegan- gen, um Änderungen schnell und effizient vollziehen zu können. Im Detail wird in diesem Kontext gezeigt, wie mithilfe von SBVR (Semantic Business Rules und Business Vocabulary) in Workflows der Microsoft Windows Work- flow Foundation (WWF) eingegriffen werden kann (vgl. McDavid, 2003, o. S.).

Der Einsatz von Business Rules in Unternehmen bietet sowohl Entwicklerinnen und Entwicklern, als auch Managerinnen und Managern, Business Analysten und anderen Business-Verantwortlichen Vorteile. Auf der einen Seite wird Personen ohne technischem Hintergrund die Möglichkeit gegeben, in das Design von Applikationen und in die Prozesslogik einzugreifen und mitzubestimmen. Auf der anderen Seite sind EntwicklerInnen nicht gezwungen, sich mit der Tiefe des zugrundeliegenden Business befassen zu müssen und können sich deswegen besser auf deren wesentliche Aufgabe, der Umsetzung konzentrieren (vgl. Schauecker, 2008, o. S.).

Eine Möglichkeit in diesem Zusammenhang ist, mit formal definierten Geschäftsregeln, welche auch von nicht-technik-affinen Benutzerinnen und Benutzern verstanden und bearbeiten werden können, in Geschäftsprozesse einzugreifen. Dabei soll kein IT-Personal an derartigen Eingriffen als unterstützende Rolle beteiligt sein (vgl. Grob u. a., 2008, S. 268).

Kommt des Weiteren der Standard SBVR in einem Unternehmen zum Ein- satz, können unternehmensweite Begriffe in einer sogenannten Terminologie definiert und gesammelt werden. Diese Terminologie kann in weiterer Folge dazu verwendet werden, Geschäftsregeln zu formulieren. Der große Vorteil solcher semantischen Regeln ist, dass sie einer bestimmten, im OMG (Open Management Group) Standard definierten Struktur unterliegen und in weiterer Folge in ein maschinen-interpretierbares Format transformiert werden kön- nen. Dadurch können sie in Geschäftsprozesse und Applikationen sehr gut integriert werden (vgl. Chapin, 2008, o. S.).

1.1.2 Fragestellungen

Durch die zuvor definierte Problemstellung ergeben sich folgende wissen- schaftliche Fragestellungen, welche in dieser Diplomarbeit behandelt werden:

- Kann mit formalen Geschäftsregeln des SBVR Standards ohne Unter- stützung von IT-Personal in Workflows der Microsoft Windows Work- flow Foundation (WWF) eingegriffen werden, um somit die Adaptier- barkeit und Flexibilität dieser zu erhöhen?
- Ist dieser Eingriff auch im laufenden Betrieb möglich, um somit Still- stands-Zeiten in Unternehmen zu vermeiden?

1.1.3 Arbeitshypothesen

Darauf aufbauend ergeben sich folgende Hypothesen:

- H0: Es ist möglich, anhand von SBVR Business Rules, welche nach SBVR Logical Formulation transformiert werden, in WWF Workflows einzugreifen.
- H1: Es ist möglich, Eingriffe in laufende, bereits am SharePoint Server veröffentlichte WWF Workflows zu vollziehen, welche bei der nächsten Instanziierung des Workflows unmittelbar Wirkung zeigen.

Abbildung 1: Arbeitshypothesen

Abbildung in dieser Leseprobe nicht enthalten

1.2 Zielsetzung und Aufbau der Arbeit

Ziel dieser Diplomarbeit ist zu zeigen, wie anhand von Geschäftsregeln des Standards SBVR in Geschäftsprozesse eingegriffen werden kann. Die Geschäftsprozesse werden dabei als Workflows der Microsoft Windows Workflow Foundation (WWF) realisiert.

Zu Beginn dieser Arbeit, aber auch generell als Motivation zu sehen, wird auf das Loslösen der Geschäftsprozesse von Business Rules eingegangen. Hier liegt der Fokus vor allem auf konzeptionelle Aspekte, um Business Rules in Geschäftsprozesse einzubetten.

Im nächsten Kapitel wird der Standard SBVR (Semantic Business Rules and Vocabulary) beleuchtet. Einleitend wird dargelegt, aus welcher Idee heraus SBVR entstanden ist und welche Synergien zwischen Business- und IT dabei entstehen. Im nächsten Schritt wird das Konzept und das zugrundeliegende Metamodell von SBVR im Detail erklärt, bevor dann die Umwandlung in ein maschinenlesbares Format (SBVR Logical Formulation) mithilfe des SBVR Editors des Unternehmens RuleMotion (vgl. RuleMotion Ltd., o. J., o. S.) voll- zogen wird.

Anschließend wird die Funktionsweise der WWF des .Net Frameworks untersucht. Dabei wird speziell auf XAML (Extensible Application Markup Language) eingegangen, in denen die Workflows deklarativ erstellt werden.

Im letzten Teil der Arbeit werden die aufgestellten Hypothesen anhand eines Prototyps untersucht. Dabei wird vor der praktischen Umsetzung eine theoretische Herangehensweise erarbeitet, die anschließend für das Mapping von SBVR Business Rules hin zu WWF Workflows herangezogen wird.

Abbildung 2: Struktur der Diplomarbeit

Abbildung in dieser Leseprobe nicht enthalten

Diese Diplomarbeit wurde in deutscher Sprache verfasst. Sämtliche Fachbegriffe im Kontext des Standards SBVR und der WWF sind in englischer Sprache niedergeschrieben. Das hat den Grund, dass sämtliche Fachausdrücke der Standards in englischer Sprache definiert sind und in deutscher Sprache zum Teil nicht entsprechend bedeutungsvoll und inhaltsreich ausgedrückt werden können. Für eine unterscheidbare Darstellung werden diese, neben direkten Zitaten, auch kursiv formatiert.

Des Weiteren wird darauf hingewiesen, dass Kommentare in Listenings in englischer Sprache ausgedrückt wurden, da dieses Vorgehen in der professionellen Programmierungüblich ist.

Beim Verfassen dieser Diplomarbeit wurde darauf geachtet, geschlechtsneut- rale Formulierungen zu verwenden. War dies bei bestimmten Begriffen nicht möglich, wurde abwechselnd die weibliche und männliche Form verwendet.

Loslösen der Geschäftsregeln von Geschäftsprozessen

2 Loslösen der Geschäftsregeln von Geschäfts- prozessen

Um ein gemeinsames Verständnis für den Begriff Regel (Rule) und Ge- schäftsregel (Business Rule) zu erlangen, folgen zu Beginn zwei Definitionen.

Das deutsche Universalwörterbuch von Duden beschreibt eine Regel wie folgt:

„ aus bestimmten Gesetzm äß igkeiten abgeleitete, aus Erfah- rungen und Erkenntnissen gewonnene, in Ü bereinkunft fest- gelegte, für einen jeweiligen Bereich als verbindlich geltende Richtlinie; [in bestimmter Form schriftlich fixierte] Norm, Vor- schrift “ (Duden - Deutsches Universalwö rterbuch, 2006, Stichwort „ Regel “ )

Ein weiterer, in dieser Diplomarbeit oft verwendeter Begriff ist die sogenannte Business Rule, die von Hay u. a. wie folgt definiert wird:

„ [...] a statement that defines or constrains some aspect of the business “ (Hay u. a., 2000, S. 4-5)

Geschäftsregeln erlauben es, bestimmte Strukturen im Geschäftsumfeld geltend zu machen, dessen Verhalten zu kontrollieren und beeinflussen (vgl. Hay u. a., 2000, S. 4-5).

Regeln im Allgemeinen, aber auch Geschäftsregeln, werden zu einem be- stimmten Zeitpunkt festgelegt. Die Schnelllebigkeit der heutigen Zeit, in der sich Gesetze, Technologien, Geschäftsumfeld, Sichtweisen in Führungsebe- nen aber auch der Markt an sich in einem rasanten Tempo verändern, lassen Business Rules oft nur für bestimmte Zeit gültig sein. Eine nachträgliche An- passung der Business Rules und der damit implizierte Eingriff in bestehende Systeme ist allerdings mit hohen Kosten und Zeitaufwand verbunden. Daher bedarf es bereits in der Konzeptionsphase einer Herangehensweise, um dy- namisch auf Anforderungen reagieren zu können (vgl. Deeg, 2008, S. 1).

Loslösen der Geschäftsregeln von Geschäftsprozessen

Müssen in Unternehmen Business Processes (Geschäftsprozesse) geändert werden, ist oft nicht klar, welche Business Rules davon betroffen bzw. wo Änderungen durchzuführen sind.

Ein Business Process ist eine zeitlich-logische Abfolge von Tätigkeiten, welche Schritt für Schritt zur Erreichung eines geschäftlichen oder betrieblichen Ziels ausgeführt werden.

Abbildung 3 stellt in diesem Zusammenhang eine Herangehensweise dar, welche eine strikte Trennung zwischen Business Processes und Business Rules vollzieht und zentrales Thema dieses Kapitels ist.

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 3: Trennung von Geschäftsprozessen und Business Rules (modifiziertübernommen aus Deeg, 2008, S. 1)

In diesem Ansatz wird in einem Business Process selbst nur auf die anzuwendenden Business Rules verwiesen, welche zu jedem Zeitpunkt an zentraler Stelle geändert werden können (vgl. Deeg, 2008). Darüber hinaus gibt es nach Pitschke noch weitere Gründe einer Loslösung:

- Business Rules existieren unabhängig von Business Processes und steuern das Verhalten in Unternehmen.
- Eine getrennte Verwaltung von Business Rules erhöht den Grad der Wiederverwendung. Außerdem wird ein und dieselbe Business Rule oft in verschiedenen Business Processes benötigt.
- Ein weiterer Grund für die Loslösung ist die Tatsache, dass sich Busi- ness Rulesöfter als Business Processes verändern.

(vgl. Pitschke, 2011, S. 81)

Neben den positiven Auswirkungen stellt eine derartige Herangehensweise auch neue Anforderungen an ein Unternehmen. Grob u. a. weisen darauf hin, dass bei der Gestaltung von Business Rules auf eine valide und konsistente Logik hinsichtlich einer zielsetzungsgerechten Prozessausführung zu achten ist, um Prozesszielabweichungen auf Ebene von Instanzen vorzubeugen. Da Business Rules oftmals komplexen und dynamischen Einflussfaktoren unterliegen, wird die Wartung des Bestands an Business Rules oft als Daueraufgabe eines eigenes Bereichs, dem sogenannten Business Rule Management (BRM), angesehen (Grob u. a., 2008, S. 269).

Eine weitere Herausforderung beim Loslösen der Business Rules von Ge- schäftsprozessen ist die Trennung zwischen Prozess- und Entscheidungslo- gik. In diesem Zusammenhang stellt ein anschauliches Beispiel die Mehr- wertsteuerregelung in Österreich dar. Die Prozesslogik definiert dabei, dass, wenn etwas mehrwertsteuerpflichtig ist, ein bestimmter Betrag aufaddiert werden muss. Hingegen legt die Entscheidungslogik fest, welcher Umsatz (Betrag) mehrwertsteuerpflichtig ist und die entsprechenden Prozentsätze dafür (vgl. Deeg, 2008, S. 1-2).

Deeg und Pitschke unterscheiden ferner auch zwischen operativen und struk- turellen Regeln (siehe auch Kapitel 3.3.1). Strukturelle Regeln sind unbeug- sam, haben definitorischen Charakter und sind meist für einen fachlich be- grenzten Bereich gültig. Wird ein Geschäftsprozess modifiziert, bleiben struk- turelle Regeln unberührt. Operative Regeln hingegen steuern den Prozessab- lauf, das Zusammenwirken verschiedener Funktionen und können verletzt werden. Ändert sich die Entscheidungslogik in einem Business Process, hat dies zu meist auch Auswirkung auf die korrespondierenden operativen Regeln (vgl. Deeg, 2008, S. 2; vgl. Pitschke, 2011, S. 83).

Zur Verdeutlichung der Trennung zwischen Geschäftsprozess und Geschäftsregeln dient das Beispiel aus Abbildung 4. In diesem werden aus einem Business Rule Repository die benötigten Business Rules selektiert. Dabei stellt die operative Geschäftsregel eine Entscheidungslogik im Geschäftsprozess dar. Im „Ja“ Zweig, in welchem eine Mehrwertsteuer anfällt, wird eine strukturelle Business Rule ausgeführt, die wiederum den Prozentsatz der Mehrwertsteuer festlegt (vgl. Deeg, 2008, S. 1).

Abbildung 4: Operative und strukturelle Business Rules

(modifiziertübernommen aus Deeg, 2008, S. 1)

Der vorhin bereits erwähnte Begriff des Business Rule Repository dient zur strukturierten Ablage und Verwaltung von Business Rules. Der Nutzen liegt zum einen darin, dass Modifikationen der Business Rules von Verantwortlichen aus Fachbereichen bzw. aus dem Business-Bereich an zentraler Stelle ermöglicht wird. Zum anderen ist der Einsatz eines derartigen Systems auch ein Schritt weg von der Heterogenität von Informationssystemen in Unternehmen. Es erlaubt eine vom Ort der späteren Verwendung und Implementierung unabhängige Speicherung und Verwaltung von Business Rules (vgl. Endl, 2004, S. 5; Hoheisel & Pfahrer, 1999, S. 1).

Um in Geschäftsprozesse mithilfe von Geschäftsregeln einzugreifen und steuern zu können, bedarf es formalisierter, in natürlicher Sprache ausdrückbarer und von Maschinen interpretierbarer Regeln. Das nächste Kapitel stellt in diesem Sinne den Standard SBVR vor, der die zuvor genannten Anforderungen erfüllt (vgl. Endl, 2004, S. 5).

3 SBVR

In diesem Kapitel wird das Thema SBVR (Semantic Business Vocabulary and Business Rules) aufgearbeitet. Zu Beginn folgt eine allgemeine Beschreibung des Standards, außerdem werden die wichtigsten Vorteile erläutert. An- schließend werden die wesentlichsten Fachbegriffe des SBVR Business Vo- cabulary (Geschäftsvokabular) und dessen zugrundeliegendes Metamodell betrachtet, bevor im nächsten Schritt SBVR Business Rules näher erklärt werden. Das anschließende Kapitel geht im Detail auf meist verbreitete Nota- tion zur Definition von Business Rules namens SBVR Structured English ein. Im letzten Teil dieses Kapitels wird der Aufbau der maschinenlesbaren Logi- cal Formulation erörtert.

3.1 Überblick

Im Jahr 2008 verabschiedete die OMG (Open Management Group) den Standard SBVR und schaffte dadurch die Möglichkeit, ein Business Design in Bezug auf Business Vocabulary und Business Rules in natürlicher Sprache zu erstellen. Im Umfeld eines Unternehmens ergeben sich in diesem Zusammenhang folgende Vorteile:

- Einer der wichtigsten Aspekte ist die Auflösung der Sprachbarriere zwischen IT und Business. SBVR schafft die Möglichkeit, Business Semantik zwischen Communities gemeinsam zu nutzen, um so In- konsistenzen und Diskrepanzen zwischen diesen vorzubeugen (vgl. Raj, Prabhakar & Hendryx, 2008, S. 29).

Unter Business Semantik wird eine für alle Stakeholder eines Unter nehmens oder Organisation gültige Terminologie verstanden.

- Der nächste positive Aspekt, den SBVR mit sich bringt, ist die Deklara- tion eines domänenspezifischen Vokabulars. Wird in einem Unterneh- men ein Geschäftsprozessmodell (GPM) erstellt, erfolgt die Bezeich- nung der einzelnen Elemente des Modells in willkürlicher, natürlicher Sprache. Dadurch können Interpretationsspielräume entstehen, wel- che in der Literatur auch als Sprachdefekte (z.B. Synonyme oder Ho- monyme) bekannt sind. Dieser Umstand führt vor allem dann zu Prob- lemen, wenn ein GPM als Kommunikationsmedium innerhalb oder zwischen Unternehmen oder Organisationen verwendet wird. Um dies zu vermeiden, ermöglicht SBVR die Definition eines domänenspezifi- schen Vokabulars. Den Elementen des GPM können dadurch konsis- tente Begriffe aus diesem Vokabular zugewiesen werden (vgl. Fellmann & Thomas, 2009, S. 506).

- Stetig komplexer werdende Geschäftsprozesse in Unternehmen erfor- dern ein logisches Rahmenwerk, wie es SBVR bietet, um eine maschi- nelle Verarbeitung und Validierung dieser zu ermöglichen (vgl. Fell- mann & Thomas, 2009, S. 506-507).

SBVR ist kompatibel mit der Herangehensweise der Model Driven Architec- ture (MDA) und gliedert sich dabei in den Computation Independent Model (CIM) Layer, dieser mehrschichtigen Architektur ein. MDA ist ebenfalls ein von der OMG anerkannter Standard und dient in erster Linie zur modellge- triebenen Softwareentwicklung. Er basiert auf dem Prinzip Separation Of Concerns aus architektonischer Perspektive und vollzieht eine Trennung zwischen Technik und Funktionalität. Im CIM Layer der MDA, in welchem SBVR eingebettet ist, liegt der Fokus am Business an sich und nicht auf den Details des verwendeten IT-Systems (vgl. Bollen, 2009, S. 303; Object Management Group, 2003, Kap. 2.1.2; Raj u. a., 2008, S. 30).

Mit dem Entwicklungsparadigma Separation Of Concerns ist das Auftrennen einer Applikation in eigenständige, so weit als mö glich unabhängige Module bzw. Bestandteile gemeint.

Des Weiteren beruht SBVR auf dem Paradigma des Fact Oriented Modelling (FOM). Facts in FOM werden in kontrollierten Phrasen, in natürlicher Sprache ausgedrückt, welche einer bestimmten Struktur unterliegen. Anders als z.B. eim Entity-Relationship-Diagramm (ERD) oder dem UML- Klassendiagrammen gibt es in FOM keine Attribute, da Facts durch Bezie- hungen untereinander die erwünschten Eigenschaften erlangen. Ein großer

Vorteil dieser Befreiung von Attributen ist die semantische Stabilität, da nachträgliche Änderungen keine Umstrukturierungen nach sich ziehen, wie es beispielsweise im UML-Klassendiagramm oder ERD häufig der Fall ist (vgl. Halpin, 2011, o. S.).

Generell wird in SBVR zwischen Meaning (Bedeutung) und Expression (Ausdruck) unterschieden. Mit Ausdruck ist die Art der Kommunikation gemeint (z.B. Text, Diagramme oder Gesten), jedoch abgesehen von deren Bedeutung. Die Bedeutung hingegen drückt aus, was z.B. mit einem Wort (Concept) oder einem Statement (Proposition) gemeint ist und steht in der Hierarchie des SBVR Metamodells aus Abbildung 5 an oberster Ebene.

Meaning: „ what is meant by a word, sign, statement, or description; what someone intends to express or what some- one understands “ (Object Management Group, 2008, S. 19)

Meanings können auf verschiedene Arten ausgedrückt (unterschiedliche Ex- pressions) werden. Diagramme erlauben es beispielsweise, Relationen in- nerhalb von Modellen sehr anschaulich darzustellen, sind jedoch unpraktisch in der Definition eines Business-Vokabulars oder Business-Rules. Im Kontext von SBVR wird für den Ausdruck (Expression) eine Teilmenge der englischen Sprache für die Formulierung eines Geschäftsvokabulars und die darauf be- ruhenden Geschäftsregeln verwendet. Die bekanntesten Notationen nennen sich SBVR Structured English (siehe Kapitel 3.4) und RuleSpeak (vgl. Bollen, 2009, S. 305; Goedertier, Mues, & Vanthienen, 2007, S. 41; Object Manage- ment Group, 2008, S. 17-18).

Die in den folgenden Kapiteln angeführten SBVR Structured English Beispiele sind mit den in Kapitel 3.4.1 definierten Font-Styles formatiert und referenzieren sich auf das „EU-Rent Example“ des SBVR Standards (vgl. Object Management Group, 2008, Annex E: EU-Rent Example).

3.2 Business Vocabulary

Durch ein Business Vocabulary wird in SBVR eine eigenständige Domäne hinsichtlich der in einem Unternehmen zu verwendenden Terminologie defi- niert (vgl. Chapin, 2008, S. 4). Eine treffende Beschreibung dazu kommt von Raj u. a.:

„ SBVR Business Vocabulary is the collection of business enti- ties, their instances and relationships between them, which can be used by any organization in their writing and talking during the course of their business. “ (Raj u. a., 2008, S. 30)

Ein Business Vocabulary besteht aus einer Menge verschiedener Subtypen von Concepts. Ein Concept selbst stellt einen Subtyp von Meaning dar und ist in der SBVR Spezifikation als „ unit of knowledge created by a unique combi- nation of characteristics “ (Object Management Group, 2008, S. 19) definiert. Da der Begriff Concept sehr abstrakt ist, wird hier auch noch die Erläuterung von Hendryx angeführt:

„ A concept exists only in the mind of a person who is thinking about it. A particular concept corresponds to a thing or things in the world. “ (Hendryx, 2005, S. 4)

Unter einem Thing (Gegenstand) versteht die ISO alles, was mit unseren Sinnen wahrnehmbar oder vorstellbar ist. Es kann sowohl materiell als auch gegenstandslos sein.

Abbildung 5 stellt das SBVR Metamodell dar, wobei der Fokus in den folgen- den Kapiteln ausschließlich auf Concepts und dessen Subtypen liegt, da die- se, wie bereits erwähnt, für die Definition eines Geschäftsvokabulars und in weiterer Folge für Business Rules notwendig sind (vgl. Object Management Group, 2008, S. 19).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 5: Auszug aus dem SBVR Metamodell

(modifiziertübernommen aus Umber, Bajwa & Asif Naeem, 2011, Kap. 3.3)

3.2.1 Noun- und Verb Concepts

Generell unterscheidet SBVR bei Concepts zwischen den Subtypen Noun Concepts und Verb Concepts.

3.2.1.1 Noun-Concepts

OMG Definition: „ concept that is the meaning of a noun or noun phrase “ (Object Management Group, 2008, S. 19)

Eine Nominalphrase (noun phrase) wird als jener Teil einer Wortgruppe bezeichnet, welcher ein Nomen näher bestimmt. Beispielsweise „ the new car “ .

Ein in der Literatur und auch in dieser Arbeit häufig verwendetes Synonym für Noun Concept ist der Ausdruck Term. Wie das Metamodell aus Abbildung 5 darlegt, unterscheidet die SBVR Spezifikation zwischen drei verschiedenen Sub-Typen von Terms (vgl Raj u. a., 2008, S. 30).

Zu Beginn das Individual Concept, welches vergleichbar ist mit der Instanz einer Klasse, sowie Volkswagen eine Ausprägung einer Automarke ist (vgl. Object Management Group, 2008, S. 21; Raj u. a., 2008, S. 36). Dabei definiert die OMG ein Individual Concept wie folgt:

„ a (noun) concept that corresponds to only one object [thing] “ (Object Management Group, 2008, S. 21)

Der nächste Subtyp nennt sich Object Type und vereinigt eine Reihe von Terms, welche in Kombination einzigartig sind. Ein Beispiel dafür ist rental car, in welchem die Terms „car“ und „rental“ in Kombination sich von anderen Object Types unterscheiden lassen (vgl. Object Management Group, 2008, S. 19-20). Die dazugehörige Definition der OMG lautet:

„ noun concept that classifies things on the basis of their common properties “ (Object Management Group, 2008, S. 19)

Der dritte und letzte Sub-Typ nennt sich Fact Type Role und ist wie folgt defi- niert: „ role that specifically characterizes its instances by their involvement in an actuality that is an instance of a given fact type “ (Object Management Group, 2008, S. 20)

Unter Actuality werden Tatsachen, Umstände oder Zustände, welche in der Wirklichkeit mö glich sind, verstanden.

Ein Fact Type Role entspricht einem Term, welcher eine zentrale Beteiligung in einem Fact Type (im Kapitel 3.2.1.2 näher erläutert) hat. Ein einschlägiges Beispiel dafür ist der Term “driver” im Fact Type “rental has driver”, welcher eine elementare Rolle in einer Autovermietung hat (vgl. Object Management Group, 2008, S. 20).

3.2.1.2 Verb Concept

OMG Definition: „ concept that is the meaning of a verb phra- se that involves one or more noun concepts and whose in- stances are all actualities “ (Object Management Group, 2008, S. 21)

Ein Verb Concept, häufiger jedoch wird das Synonym Fact Type verwendet, muss laut SBVR-Spezifikation zumindest einen Term enthalten. Wichtig außerdem ist, dass jeder Term in einem Fact Type eine definierte Rolle darstellt (vgl. Object Management Group, 2008, S. 21).

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 1: Fact Type

Bei Fact Types wird neben andere zwischen den Subtypen Characteristic und Binary Fact Type unterschieden.

Eine Characteristic ist ein Fact Type mit genau einem Term (vgl. Object Management Group, 2008, S. 21).

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 2: Characteristic

Hingegen hat ein Binary Fact Type genau zwei Terms, wobei auch Fact Ty- pes mit mehr als zwei Terms möglich sind (vgl. Object Management Group, 2008, S. 21). In SBVR Beispiel 3 ist ein n-ary Fact Type mit n = 3 dargestellt:

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 3: n-ary Fact Type

Für eineübersichtlichere Darstellung könnte dieser Fact Type auch auf zwei separate Fact Types aufgeteilt werden (vgl. Raj u. a., 2008, S. 30).

Andere mögliche Ausprägungen von Fact Types sind Associative Fact Types, Partitive Fact Types und Categorization Fact Types. Diese sind jedoch sehr spezifisch und für die Zwecke dieser Diplomarbeit nicht erforderlich. Eingehende Literatur zu diesen finden LeserInnen unter (Object Management Group, 2008, Kap. 11.1.5.1).

3.3 Business Rules

Der grundlegende Aufbau einer SBVR Business Rule (in der Literatur oft als „SBVR Mantra“ zu finden) kann wie folgt beschrieben werden: Rules sind aufgebaut durch Fact Types und Fact Types wiederum sind aufgebaut durch Terms. Wie in Abbildung 6 ersichtlich, impliziert diese Mantra eine chronolo- gische Vorgehensweise, da zuerst Terms definiert werden müssen, um aus diesen im nächsten Schritt Fact Types formulieren zu können. Erst nach der Definition von Fact Types können schlussendlich SBVR Business Rules ge- formt werden (vgl. Bollen, 2009, S. 304; Raj u. a., 2008, S. 30).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 6: Grundlegender Aufbau von SBVR

(modifiziertübernommen aus Raj u. a., 2008, S. 30)

3.3.1 Arten von Business Rules

SBVR unterscheidet generell zwischen strukturellen und operativen Business Rules.

3.3.1.1 Strukturelle Business Rules

Wie bereits im Kapitel 2 erläutert, greifen strukturelle Business Rules nicht in den Prozessablauf ein, sind verbindlich und haben definitorischen Charakter (vgl. Raj et al., 2008, S. 31). Die SBVR Spezifikation definiert diese wie folgt:

„a rule that is a claim of necessity“(Object Management Group, 2008, S. 161)

Bei strukturellen Geschäftsregeln wird des Weiteren zwischen Necessity Bu- siness Rule S tatements, Impossibility Business Rule Statements und Restric- ted Possibility Rule Statements unterschieden. Eine wesentliche Eigenschaft dieser ist, dass sie mithilfe von Negationen logisch äquivalent ausgedrückt werden können. Diese Eigenschaft ist ebenso für operative Geschäftsregeln gültig. Eine genauere Erläuterung zur logischen Äquivalenz von Business Rules folgt in Kapitel 3.4.2.1, in dem modale Operatoren behandelt werden.

Ein Necessity Statement ist nach SBVR Spezifikation eine „ structural rule [...] that is expressed positively in terms of necessity rather than negatively in terms of impossibility “ (Object Management Group, 2008, S. 168).

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 4: Necessity Statement

Hingegen ist ein Impossibility Statement eine „ structural rule [...] that is ex pressed negatively in terms of impossibility rather than positively in terms of necessity “ (Object Management Group, 2008, S. 168).

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 5: Impossibility Statement

Die letzte Ausprägung von strukturellen Business Rules nennt sich Restricted Possibility Statement und ist definiert als „ structural rule [...] that is expressed as possibility being acknowledged only when a given condition is met “ (Object Management Group, 2008, S. 168).

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 6: Restricted Possibility Statement

3.3.1.2 Operative Business Rules

Im Gegensatz zu strukturellen Business Rules können Operative verletzt werden und greifen in den Prozessfluss ein. In der SBVR Spezifikation sind diese wie folgt definiert: „ business rule that is a claim of obligation ” (Object Manage ment Group, 2008, S. 161)

Bei operativen Business Rules wird zwischen Obligation S tatements, Prohibition Statements und Restricted Permission Statements unterschieden.

Ein Obligation Statement ist eine „ operative rule [...] that is expressed positi- vely in terms of obligation rather than negatively in terms of prohibition “

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 7: Obligation Statement

Der nächste Subtyp nennt sich Prohibition Statement und ist als „ operative rule [...] that is expressed negatively in terms of prohibition rather than positi- vely in terms of obligation “ (Object Management Group, 2008, S. 167) defi- niert.

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 8: Prohibition Statement

Zuletzt, das sogenannte Restricted Permission Statement, welche als eine „ operative rule [...] that is expressed as permission being granted only when a given condition is met “ (Object Management Group, 2008, S. 167) definiert ist.

Abbildung in dieser Leseprobe nicht enthalten

SBVR Beispiel 9: Restricted Permission Statement

3.4 SBVR Structured English

SBVR Structured English ist die am meisten verbreitete Notation und gilt als de facto Standard, um SBVR Modelle zu verbalisieren. In dieser Ausdrucksform wird der sogenannte Prefix Style verwendet, welcher sich dadurch auszeichnet, dass die später in Kapitel 3.4.2.1 erläuterten Modal Operations sich am Beginn eines Statements befinden.

„It is obligatory that each driver of a rental is qualified.“

Eine weitere bekannte Notation nennt sich RuleSpeak, welche hingegen den Mixfix-Style verwendet, in dem Modalitäten inmitten einer Geschäftsregel verwendet werden.

„Each driver of a rental must be qualified.“

(vgl. Object Management Group, 2008, S. 237; Solomakhin, 2011, S. 10-11).

3.4.1 Font Style

Eine weitere Technik, welche in SBVR Structured English zur Anwendung kommt, ist eine unterschiedlich stilistische Darstellung von Terms, Fact Types und anderen Schlüsselwörter. Dabei sind in der SBVR Spezifikation vier un- terschiedliche Font Styles für die unterschiedlichen formalen Bedeutungen definiert.

Abbildung in dieser Leseprobe nicht enthalten

Mengenbestimmungen, Artikel, logische Operatoren und sämtliche andere linguistische Symbole verwendet wird. Anführungszeichen und die Definition von Zeitabschnitten werden ebenfalls mit dieser Formatierung gekennzeichnet (vgl. Object Management Group, 2008, S. 238).

3.4.2 Schlüsselwörter und Phrasen für logische Formulierungen

SBVR Structured English stellt ein vordefiniertes Vokabular zur Verfügung, um die Struktur und Bedeutung von Business Rules formal zu regulieren. Die wichtigsten logischen Formulierungen sind Logical Operations, Modal Opera- tions und Quantifiers. Die in den folgenden Unterkapiteln verwendeten Buch- staben n und m sind Platzhalter für ganze Zahlen, hingegen werden p und q für Phrasen und Propositionen verwendet (vgl. Object Management Group, 2008, S. 239).

Abbildung in dieser Leseprobe nicht enthalten

Abbildung 7: Logische Formulierungen

(modifiziertübernommen aus Object Management Group, 2008, S. 241)

Die Geschäftsregel aus Abbildung 7 verwendet zwei verschiedene Typen von logischen Formulierungen. Den Modaloperator, welcher, wie bereits erwähnt, im Prefix Style von SBVR Structured English immer an erster Stelle einer Business Rule angeführt ist und zwei Mengenbestimmungen (Quantifier), welche sich jeweils auf die beiden nachfolgenden Terms beziehen (vgl. Object Management Group, 2008, S. 241).

[...]