Kickoff Meeting

Zusammenfassung/Aufgabenstellung:

• Generierung eines Metamodells für Geschäftsregeln (Business Rules)

• Metamodell soll kompatibel zu AgilPro und JWT sein

• Business Rules = Policies = Regeln und sind Teil von Geschäftsprozessen

• Für das Metamodell soll ein grafischer oder textueller Editor (EMF, XML) erstellt werden, der das neue Metamodell entsprechend abbildet

• Das Metamodell muss bei der Endpräsentation vorhanden sein

Teil 1 - Erstellung des Metamodells:

• Zwischenpräsentation am Fr 16.05.2008 - Ausarbeitung (15 - 20 Seiten) + Präsentation über das Metamodell der verallgemeinerten Businessrules ca. 30 min + 5 - 10 min für Fragen (Inhalt: Motivation,...)

   

Teil 2 - Implementierung eines Editors

• Endpräsentation am Fr 18.07.2008 - Implementierung und Ausarbeitung von Ergebnissen der Zwischenpräsentation und endgültige Endpräsentation
• Anlehnung an die GEF Edit Parts Design Patterns (Model View Controller, Framework Server, Command Stack für UnDo & ReDo Befehle)
• Eine Codegenerierung ist nicht Teil des Praktikums
• GMF ist eine Kombination von GEF und EMF (Betreuer hat mit EMF kaum Erfahrung)
• Der Aufbau des bereits bestehenden Metamodells von Geschäftsprozessen (z.B. Kontollknoten) kann im Wiki der JWT Projektseite eingesehen werden

Arbeitsverteilung und Planung:

Businessrules & Businessproesse, Literatur, existierendes Metamodell, Gliederung, Abstract

Wöchentliche virtuelle Treffen

Max:

• Abstraktion und Formalisierung der BR

Jojo:

• Bestehende Metamodelle analysieren (Geschäftsmodelle) JWT ( Metamodellbeschreibung dafür: http://wiki.eclipse.org/Image:AgilPro_MetamodelDescription.pdf)
• EMF, GEF und JWT einarbeiten

Matze:

• Typische Business Rules identifizieren und aufbereiten
• Verallgemeinerung der BR

Aktuellen Aufgaben bis zum 05.05.08 umsetzen und danach entsprechend Flo Feedback geben (Einladung zu Studiki.de) und Präsentation absprechen.

Typischer Geschäftsprozesse - Beispiele

Car Rental Agency:

We want to set up the rules for a car rental agency in order to calculate rental charges. Charges depend on the vehicle type and rental duration, and also take into account if a discount is to be given. Now we model these rules in the Visual Rules Modeler:

Creating rules is simply done via drag & drop of the rule elements from the palette. We start with a decision on which car type is rented. A decision is represented by a yellow diamond. We offer 3 different car types:
Small, compact and luxury. For the small car, the price is $40 per day. We use the blue assignment element for setting the price.Afterwards an invoice is printed. This is done by an action. Actions are represented by blue spheres. The rule definition for the car type "compact" works the same way. For luxury cars, we want to use a special feature. Since we assume that renters are VIP customers, we want to give a discount on the price. Since we assume that renters are VIP customers, we want to give a discount on the price. We set the price at $60 per day. Since we want to use this discount calculation in other rules as well, we decided to model a separate rule that we describe here. Encapsulating such calculations in separate rules keeps the rules clear and easy to understand. Encapsulating such calculations in separate rules keeps the rules clear and easy to understand. The discount rule basically differentiates between car rental periods of 1 day or more than 1 day. If the rental period is longer than 1 day, a discount of 10% will be granted. This is just a simple rule for demonstration purposes. Any extensions are possible. Extending this rule might be a task for the future – this can be marked in the rule with a note so the task will be kept in mind.

We then subtract the calculated discount from the rental charge. The final price after discounting is now available to be used in the main rule In order to apply the discount rule for a luxury car, we use the “call flow rule” element. We can also print an invoice for these types of car rentals. Now we have finished defining the business rules for pricing. The next step is to specify the rule expressions within the rule elements. At this point, all rule elements still have a red marker indicating that the rule expressions are missing. Let’s start by adding the data element "car type" as part of the decision specification. It is provided as an input to the rule - as shown in the Rule Context that lists all existing data elements relevant for a rule. The car type is first compared with the given type "small". We go on with filling in all the rule expressions. As soon as we are finished, the red markers have disappeared. There is a special feature that we want to show: To calculate the discount, we need new data element that is not yet available. When specifying the new discount calculation, Visual Rules detects that the data element "discount" is missing so it automatically creates a new data element for us. The final price for luxury cars, including the discount, is now ready to be used to calculate rental charges. Our simple price calculation and discounting rules are now ready to be tested. To see how testing is done in Visual Rules, please watch the screencast on "Testing Rules".

Weitere Beispiele von Business Rules:

// TODO add further examples (Matze)

Geschätsregel Definition

A Business Rule is a directive, intended to influence or guide business behavior, in support of Business Policy that has been formulated in response to an Opportunity, Threat, Strength, or Weakness.(www.brportal.org)

A business rule is a statement that defines or constrains some aspect of the business. It is intended to assert business structure or to control or influence the behavior of the business. (www.businessrulesgroup.org)

Business rules may be: defined as business definitions for business use (to represent policies, prac tices and procedures), or defined as executable business rule statements for use in some ruledriven system, or both.
(http://www.omg.org/attachments/pdf/PaulHarmonBParticle.pdf)

Abstraktion der Businessrules (UML + EPK)

Gegenüberstellung der verschiedenen Modelle
Kritischer Vergleich

Gliederung

1 Motivation (Aufgabenstellung - Was, Warum - kaum visuelle Tools für Businessrules vorhanden, Microsoft Werbung, Kennzahlen und Fakten, Ziel -> Modellierung von Businessrules -> grober Überblick über die Arbeit) -> Max

2 Grundlagen - State of the Art (Bis Donnerstag)
2.1 Definition und Abgrenzung der Begriffe Metamodell, Business Rules, Businessprozesse (Beispiele für Businessrules, Vergleich zu den Prozessen) -> Matze
2.2 Untersuchen existierender Ansätze zur Modellirung von Businessrules (UML, EPK)
-> Matze (UML) Max (EPK) 2.3 Untersuchen des existierenden Metamodells zur Modellierung von Geschäftsprozessen (JWT und weitere Tools) -> Jojo

3 Entwicklung eines spezifischen Metamodells für Businessrules (Gemeinsam Wochenende 09., 10., 11.)
3.1 Analyse angewandter Businessrules
3.2 Abstraktion extrahierter Businessrules
3.3 Generierung des Metamodells

4 Zwischenergebnisse der theoretischen Grundlagen

5 Implementierung basierend auf dem neu entwickelten Metamodells

6 Fazit
6.1 Zusammenfassung (Ergebnisse, Vergleich der Modelle)
6.2 Ausblick und Empfehlung (Zu Visualisierung von Business Rules)

Ausarbeitung

Motivation:

Zitat:"Einer IDC-Studie zufolge werden immerhin 9 % der Geschäftsregeln täglich, immerhin weitere 17 % wöchentlich und nochmals 17 % monatlich geändert. Somit haben wir schon gut 45 % der Regeln, die sich innerhalb eines angenommenen Release-Zyklus von mindestens einem Monat ändern würden."

- Restrukturierung der Geschäftsprozesse und kurzen Entwicklungszeiten mit hohem Return-on-Investment in Einklang bringen?
- Unternehmen bezeichnen sich als Prozessorientiert
- konsequentes Denken in Geschäftsprozessen und Geschäftsregeln und damit eine optimale Adressierung der Kundenwünsche
- Dynamik bedeutet, dass der Lebenszyklus von Prozessen und Regeln immer kürzer wird, also Änderungen in immer schnelleren Zyklen notwendig sind.
- So werden Durchlaufzeiten, Durchlaufvolumen und die Qualität u.a. durch Wiederverwendung gesteigert.

Ziele:
- Forderung zu kontinuierlicher Optimierung und weiterer Kostenreduktion.
- Kontrolle und gleichzeitig mehr Flexibilität
- Wiederverwendung bestehender Softwarefunktionen
- Eigenen Wissensdomäne seine Kreativität und sein Know-how einzubringen und auszuleben, ggf. nach kurzer
Einarbeitung ohne aktive Unterstützung eines Entwicklers
- kurzer Analyse und einem Vorgespräch, gemeinsam an die Modellierung von Regeln in einer clientseitigen Eclipse Umgebung zu machen und dort in Regelbäumen die eigenen Entscheidungsschritte niederzulegen.
- Veränderter Software-Release-Zyklus (Konzeption, Realisierung, Test, Qualitätssicherung)
- Verkürzte Konzeptionsphase durch Tool-Gestützte Modellierung von Geschäftsregeln (Währenddessen Definition von Testdaten + Referenzergebnissen)
- Releasezyklus, Änderunsmenge <--> Flexibilität (bei Rules, schneller Time to Market)
- Häufiger Änderungsaufwand -> Einsatz von Business Rules
- Testskripte und Dokumentationsmöglichkeiten heben den daraus generierten Java-Code auf eine Stufe der Testsicherung und Dokumentationsqualität, wie sie innerhalb der reinen Programmierung selten mit Javadoc und JUnit-Tests erreichbar sind bzw. praktiziert werden.

Ziel dieser Arbeit:

- Der IT-Berater oder -Designer konzentriert seine Arbeit auf die Zurverfügungstellung einer architektonischen Basis und die Öffnung von Schnittstellen zu normalerweise arbeits-, kosten- und änderungsintensiven Bereichen der Applikation bzw. des Geschäftsprozesses.
- Der Business-Domain-Experte agiert damit ohne langen Entwicklungsprozess direkt in und an der Entscheidungslogik, die sein Geschäft bewegt.

Methoden:
- Die Industrialisierung hilft dabei mittels Automatisierung und Standardisierung.
- Die Prozessmaschine führt also die Regeln mit anderen Services zu einem neuen Gesamtbild zusammen.
- Einsatz der Regeln im SOA Ansatz
- Regeln werden eben einmal modelliert und implementiert und stehen dann zur Verwendung in verschiedenen Prozessen zur Verfügung.
-> Iterative Definition von Geschäftsregeln (essentiell für komplexe Regeln) -> Lebenszyklusmanagement der Geschäftsregeln
-> Continuous Integration als Vorgehensmodell: Regeln lassen sich kurzfristig ergänzen und modifizieren
- Keine Kodierung der Geschäftsregeln mehr nötig (keine bzw. kürzere Abstimmungsschleifen)

Business Rules allgemein:
- Geschäftsprozessspezifische Logik, wie die Kontrolle des Ablaufs der Prozessaktivitäten, Einhalten von Deadlines und Ausnahmebehandlung
- Über Regeln beschreibt man die Entscheidungslogik, die die prozessübergreifenden Managementpolitiken und Prinzipien darstellt. z.B. mit einer Regelmaschine im Rahmen von Business Rules Management (BRM) implementiert. Die Prozess- und die Regelmaschine dienen beide der Modellierung,
Ausführung und Governance der entsprechenden Logiken.
- Prozesse und Regeln sind zueinander komplementär, denn ein Prozess nutzt typischerweise mehrere Regeln, während eine Regel in verschiedenen Prozessen vorkommen kann.
- Man sagt, Prozesse stünden zu Regeln in einem Verhältnis von m:n. Daher muss man Prozesslogik und Entscheidungslogik strikt voneinander trennen.
- wenn Prozesse und Regeln im Kontext einer serviceorientierten Architektur (SOA) gemanagt werden, dann bringt man beide Zielsetzungen mittels eines SOA-basierenden BPM und BRM zusammen. Denn eine SOA ist eine spezielle Architektur, die darauf abzielt, „Software for Change“ zu ermöglichen.
- Ein Rule-Service kann als Kapselung komplexer Regeln verstanden werden. Mit anderen Worten, ein Rule-Service kann auch einen anderen Rule- Service in seiner Implementierung unabhängig von einer steuernden SOA aufrufen.
- Damit wird eine Regelmaschine zum Bestandteil einer SOA-Infrastruktur und
die Entscheidungslogik wird Teilmenge der Geschäftslogik.
- Rule Service auf Grund seiner Einbettung in die SOA oft als Web-Service-Angebot daher. Die Regeln sind z.B. als JAR verpackt und werden in einem http-Server aufrufbar gemacht.

Wann sollten BRM Lösungen verwendet werden?
- BRM-Services lohnen sich tatsächlich dort, wo eine große Menge an Regeln technisch unabhängig von umgebender IT-Software ins Geschehen eintritt.
- Rules sind also keine klassische Lösung für die Konfiguration von IP-Adressen und Ports oder das Parsen von verschlüsselten Daten oder Logiken zur Erzeugung von Check-Summen. Business Rules sind Geschäftsregeln, weil es genau dieRegeln sind, die sich gerne in Prosatexten mit Entscheidungstabellen wiederfinden oder als „undokumentierbare“ oder sogar politisch oftmals „geheime“ Logiken beschrieben werden, die man dem artfremden IT-Dienstleister eigentlich nur ungern offenbaren will.

Vorteile des SOA Ansatzes:
- Fähigkeit mit Kunden auf einer gemeinsamen
Wellenlänge zu arbeiten
- Bei Beschreibung von Geschäftslogiken weitgehend unabhängig von den
Problemen wie Programmierschlüsselwörtern, Framework-Produkten, Compiles und Unit-Tests zu bewegen
- Keine komplexen Anforderungsdokumente
- Analyse, - Prototyping, Modellierung, Ausführung und Test gehen fast nahtlos ineinander über.

z.B. Rules Tools
- Visual Rules (www.visualrules.de) von Innovations erzeugt für den Endkunden leicht nachvollziehbare Entscheidungsgraphen mit Ad Hoc Ansicht der Regelentscheidungen
- Andere Produkte bevorzugen textuelle „Wenn-Dann“-Sätze oder sogar noch niedere Formulierungen, die sehr programmiersprachennah sind.

z.B. Anwendung der finalen (Web-)Services:
- Preiskalkulationsmodelle zur Optimierung von Angebot und Nachfrage, wir sprechen über Risiko- und Tarifermittlungsmodelle für den Verkauf von Dienstleistungen.
- Marktanalysen und Produktoptimierungen
-> dedizierte Services innerhalb ihrer SOA schaffen, die ihnen unmittelbaren Zugang zu diesen Logiken innerhalb des Geschäftsprozesses verschaffen.

Abkürzungsverzeichnis:
BRM - Business Rules Management
BPM - Business Prozess Management

Quellen

http://de.wikipedia.org/wiki/Ereignisgesteuerte_Prozesskette

Zwischenpräsentation Agenda

1. Einführung
   • Motivation(Max)
   • Definition/Vergleich (Metamodell, Prozess, Business Rules)(Max)
   • Beispiel (Online Music Store - Kurze Einführung in den Sachverhalt)
2. Business Rules
   • Theorie(Matze)
   • Anwendung (Beispielbezug)
   • EPK(Max)
   • UML(Matze)
   • Meta Modell (Graphische Notation + Semantik)(Jojo)
3. Anwendung zur modellierung von Business Rules (MDSD)
   • Anforderungen (Business Case, Usability, Umgebung) (Matze+Jojo)
   • Umgebung (Eclipse, JWT Plugin)(Matze+Jojo)
4. Zwischenfazit und Ausblick(alle)