Post on 27-Aug-2020
Von Geschäftregeln zurService-orientierten Architektur
Model Driven Enterprise Engineering™
Markus Schacher, KnowBodyHohlstrasse 534, 8048 Zürich, Schweiz
www.knowgravity.com
Von Geschäftregeln zur Service-orientierten Architektur 2
Abstract
Beim Aufbau einer Service-orientierten Architektur (SOA) spielt ein fundiertes Geschäftsmodell (bestehend aus Geschäftsstrategie, Geschäftsvokabular, Geschäftsregeln und Geschäftsprozessen) eine zentrale Rolle. In den vergangenen drei Jahren wurden durch die OMG (Object Management Group) verschiedene Spezifikationen ausgearbeitet, welche die Erstellung solcher Geschäftsmodelle standardisieren. Mit dem Fokus auf Geschäftsregeln zeigt dieses Tutorial, wie sich auf der Basis solcher Geschäftsmodelle eine agile unternehmensweite IT-Infrastruktur gestalten lässt.
Im ersten Teil dieses Tutorials werden anhand einer durchgängigen Fallstudie die OMG-Spezifikationen Business Motivation Model (BMM), Semantics of Business Vocabularies and Rules (SBVR), Business Process Modeling Notation (BPMN) und Organization Structure Metamodel (OSM) vorgestellt. Darauf aufbauend wird im zweiten Teil des Tutorials erläutert, wie sich insbesondere Prozesse und Regeln auf Basis einer Service-orientierten Architektur automatisieren lassen. Dabei kommen weitere, IT-orientierte OMG-Spezifikationen wie die Executable UML (xUML) sowie die Model Driven Architecture (MDA) zur Sprache. Schliesslich wird aufgezeigt, wie sich verschiedene Technologien zur Regelautomatisierung in eine SOA integrieren lassen.
Von Geschäftregeln zur Service-orientierten Architektur 3
Inhalt
• Es waren einmal…
• Geschäftsregeln
• Geschäftsprozesse
• die Unified Modeling Language
• service-orientierte Architekturen
• Da kamen…
• die Object Management Group (OMG)
• KnowGravity Inc.
• Und es entstand Model Driven Enterprise Engineering™ mit…
• Strategiemodellen
• Operationelle Modellen
• IT-Support Modellen
• Technologiemodellen
• Fallstudie „Engineering von Services“ mit Demonstration
Von Geschäftregeln zur Service-orientierten Architektur 4
Ihr KnowBody in diesem Workshop
• Markus Schacher• 1959: Geboren in Zürich• 1982: Abschluss des Studiums an der HTL Winterthur• 1982-1988: Software Engineer bei Siemens• 1987/88: Nachdiplomstudium ETH Zürich• 1988-1992: Consultant bei Zühlke• 1992-2001: Consultant bei Born Informatik• 2001: Mitgründer der Firma KnowGravity• Heute:
• Business/System/Software Engineering Consultant• Spezialist für Executable UML (xUML)• Co-Autor eines Buches zum Business Rules Ansatz• Architekt von CASSANDRA und KnowEnterprise®
• erfahrener Kursleiter & Speaker• Aktives Mitglied der Business Rules Group (BRG) und der Object Management Group (OMG)
Es waren einmal…
Geschäftsregeln
Von Geschäftregeln zur Service-orientierten Architektur 7
Begriffe
Geschäftsregel / Business Rule
• Aus Geschäftssicht: Eine Direktive, die das Geschäftsverhalten beeinflussen oder leiten soll, um damit eine Geschäftspolitik zu unterstützen, die als Reaktion auf eine Chance, Bedrohung, Stärke oder Schwäche formuliert wurde.
• Aus IT Sicht: Eine Aussage, die Aspekte des Geschäfts definiert oder einschränkt. Damit wird beabsichtigt, die Struktur des Geschäftes festzulegen oder das Verhalten des Geschäfts zu kontrollieren oder zu beeinflussen.
Von Geschäftregeln zur Service-orientierten Architektur 8
Begriffe (2)
• Business Rule AnsatzEine Menge von Techniken und Technologien, die sowohl Business Engineering als auch IT Systementwicklung abdecken, mit dem Ziel, agile Geschäfts- und IT-Systeme zu betreiben, welche direkt durch Geschäftsleute kontrolliert werden.
• Business Rule EngineEine technische Software-Komponente, die für die effiziente Ausführung und Überwachung von Geschäftsregeln verantwortlich ist.
Von Geschäftregeln zur Service-orientierten Architektur 9
Bridging the Gap
Gemeinsame Sprache!
Mensch
Computer
Von Geschäftregeln zur Service-orientierten Architektur 10
BRA Big Picture
Markt &Gesetze
BRManagement
beeinflusst
beeinflusst
Externali-sierung
BusinessRules
Geschäfts-prozesse
treiben
Umsetzungmittels Knowledge Management
Umsetzung mittels BR Technologie
S. 19
Von Geschäftregeln zur Service-orientierten Architektur 11
Transparente Regeln
Von Geschäftregeln zur Service-orientierten Architektur 12
Diskussion/Fragestellungen
• Woher kommen Geschäftsregeln?
• Wer definiert Geschäftsregeln?
• Wer ist von Geschäftsregeln betroffen?
• Wer führt Geschäftsregeln aus?
Geschäftsprozesse
Von Geschäftregeln zur Service-orientierten Architektur 14
Begriffe
• GeschäftsprozessEine Menge von Geschäftsaktivitäten mit dem Zweck, ein Geschäftsresultat zu erzielen, typischerweise im Umfeld einer Organisationsstruktur, die funktionale Rollen und Beziehungen festlegt.
• GeschäftsaktivitätEine spezifische Komponente eines Geschäftsprozesses, die typischerweise durch ein Individuum in entsprechender Rolle ausgeführt wird.
• WorkflowDie vollständige oder teilweise Automatisierung eines Geschäfts-prozesses, bei der Dokumente, Informationen oder Aufgaben von einem Teilnehmer gemäss einer Menge von Regeln zu einem anderen zur Weiterbearbeitung weitergeleitet werden.
Von Geschäftregeln zur Service-orientierten Architektur 15
Begriffe (2)
• ModellEine auf bestimmte Zwecke ausgerichtete vereinfachende Beschreibung der Wirklichkeit.
• GeschäftsprozessmodellEine zweckorientierte, vereinfachte Abbildung eines oder mehrerer Geschäftsprozesse.
Gängige Zwecke der Geschäftsprozessmodellierung:
• Dokumentation (Kommunikation) der operationell vorgeschriebenen Geschäftsprozesse
• Analyse der tatsächlich ausgeführten Geschäftsprozesse (Instanzen)
• Konzeption neuer oder verbesserter Geschäftsprozesse
• Abstimmung von Geschäftsprozessen zwischen Organisationen
• Automatisierung von Geschäftsprozessen
Von Geschäftregeln zur Service-orientierten Architektur 16
Elemente der Geschäftsprozessmodellierung
Gängige Elemente
• Was: Aktivitäten
• Wann: Abhängigkeiten
• Warum: Entscheidungen
• Wer: Ausführende/Verantwortlichkeiten
Weniger gängige Elemente
• Womit: Ressourcen
• Wo: Orte
• Rollen, Organisationsstrukturen
• Instanzen von Prozessen
Von Geschäftregeln zur Service-orientierten Architektur 17
Arten von Geschäftsprozessen
Stark repetitive Prozesse (Straight-Through Processing, STP)• Hohe Volumina• Einfache, standardisierte Aufgaben• Einfache, standardisierte Entscheidungen• Kaum Ausnahmen• Beispiele: Abwicklung einer Bestellung, eines Antrages oder einer Zahlung
Tendenziell einmalige Prozesse (kreative Prozesse)• Tiefe Volumina• Komplexe, unerwartete Aufgaben• Komplexe, unerwartete Entscheidungen• Ausnahmen sind die Regel• Beispiele: Suche nach einer Lösung, Diagnose einer Störung
Mischformen• Repetitive Grobstruktur, einmalige Details• Beispiele: Abwicklung eines Projektes
Von Geschäftregeln zur Service-orientierten Architektur 18
Diskussion/Fragestellungen
• Machen Sie Geschäftsprozessmodellierung?
• Was sind Ihre Gründe zur Modellierung von Geschäftsprozessen?
• Mit welcher Art von Geschäftsprozessen haben Sie zu tun?
• Welche Notationen verwenden Sie zur Modellierung von Geschäftsprozessen?
Unified Modeling Language
Von Geschäftregeln zur Service-orientierten Architektur 20
„De Facto“-Standard für SW-Modellierung
Modellierung struktureller Aspekte von Software Systemen:• Klassendiagramme• Objektdiagramme• Paketdiagramme• Kompositionsstrukturdiagramme
Modellierung dynamischer Aspekte von Software Systemen:• Anwendungsfalldiagramme• Aktivitätsdiagramme• Interaktionsübersichtdiagramme• Sequenzdiagramme• Kommunikationsdiagramme• Zustandsdiagramme• Zeitverlaufsdiagramme
Modellierung technischer Aspekte von Software Systemen:• Komponentendiagramme• Verteilungsdiagramme
Von Geschäftregeln zur Service-orientierten Architektur 21
Besondere Elemente der UML
• Action SemanticsDefiniert die Semantik einer Menge elementarer Aktionen in lösungsneutraler Form, um beispielsweise Objekte zu instanzieren, Beziehungen herzustellen, Nachrichten zu versenden, etc.
• Object Constraint LanguageDefiniert die Semantik sowie eine Syntax, für Ausdrücke in lösungsneutraler Form, beispielsweise logische, numerische oder Mengenausdrücke, etc.
Von Geschäftregeln zur Service-orientierten Architektur 22
Verwendung der UML
Die UML lässt sich für verschiedene Aufgaben einsetzen:
• Zur Skizzierung von Ideen
• Zur Modellierung von Anforderungen
• Zur Modellierung von Lösungen/Architekturen
• Zur Visualisierung von Quellcode
• Zur Beschreibung von nicht-Software Zusammenhängen
• Zur Entwicklung einer domänenspezifischen Sprache (DSL) via Profiling
Von Geschäftregeln zur Service-orientierten Architektur 23
Diskussion/Fragestellungen
• Verwenden Sie die UML?
• Wer verwendet die UML als Notation (IT und/oder Fachseite)?
• Wozu verwenden Sie die UML?
• Was sind die Hauptschwierigkeiten beim Einsatz der UML?
Service-orientierte Architekturen
Von Geschäftregeln zur Service-orientierten Architektur 25
Begriffe
• Service (allgemein)Eine nicht-materielle Dienstleistung, welche ein Dienstleister gegenüber einem Nutzer auf dessen Wunsch zur Befriedigung eines Bedürfnisses erbringt.
• Service (SOA)Eine Komponente, die eine wohl definierte, geschäftsmotivierte Funktionalität über eine standardisierte Schnittstelle anderen Services oder Anwendungen zur Verfügung stellt.
• (Software-)ArchitekturEine Beschreibung der grundlegenden Komponenten sowie deren Zusammenspiel (Interaktionsmuster) innerhalb eines Software-Systems.
Von Geschäftregeln zur Service-orientierten Architektur 26
SOA
Eine Service-orientierte Architektur (SOA) ist im wesentlichen• eine Software Architektur,• die von Schnittstellendefinitionen ausgeht• und eine ganze Software-Landschaft auf Schnittstellen, Schnittstellen-Implementationen und Schnittstellen-Aufrufen aufbaut.
SOA wäre besser als „Schnittstellen-orientierte Architektur“ bezeichnet.[Gartner, 2003]
Nutzen einer SOA• Geschäftsorientiert durch Kohäsion rund um Geschäftsfunktion• Flexibilität durch lose Kopplung und Orchestrierung• Wiederverwendbarkeit durch öffentliche Schnittstellen• Legacy-Migration durch schrittweise SOA-Einführung
Von Geschäftregeln zur Service-orientierten Architektur 27
SOA Standardisierung
• Die Open SOA Initiative (www.osoa.org) bzw. OASIS Open CSA(www.oasis-opencsa.org) haben SOA-spezifische Standards erarbeitet:
• Service Component Architecture (SCA)Ein Set von Spezifikationen, die ein Modell zum Bau von Applikationen uns Systemen nach SOA Prinzipien beschreiben.
• Service Data Object (SDO)Ein Set von Spezifikationen, die den Zugriff auf sowie die Manipulation von Daten aus heterogenen Quellen vereinfachen und vereinheitlichen.
• Das SOA Consortium™ (www.soa-consortium.org), gesponsert durch BEA, Cisco, IBM, SAP und Sparx ist ein SOA Anwenderforum, welches den Erfahrungsaustausch fördert sowie „SOA Best Practices“ identifiziert.
Von Geschäftregeln zur Service-orientierten Architektur 28
Diskussion/Fragestellungen
• Setzen Sie bereits auf SOA?
• SOA = Web-Services?
• Welche Granularität haben Ihre Services?
• Schwierigkeiten beim Aufbau einer SOA?
Da kamen…
Von Geschäftregeln zur Service-orientierten Architektur 30
Die Object Management Group™ (OMG)
Die Object Management Group ist ein internationalesnon-profit Industriekonsortium, welches Spezifikationen zurUnternehmensintegration für verschiedenste Technologienund Domänen entwickelt und diese kostenlos publiziert.Zu den bekanntesten gehören
• Common Object Request Broker Architecture (CORBA)Middleware zur plattformunabhängigen Integration von Applikationen
• Unified Modeling Language (UML)Modellierungssprache für Software-Systeme und anderes
• Model Driven Architecture (MDA)Ganzheitlicher Ansatz zum Umgang mit Technologie-und Marktveränderungen
• Systems Modeling Language (SysML)Modellierungssprache auf der Basis der UML für technische Systeme
Von Geschäftregeln zur Service-orientierten Architektur 31
Geschäftsorientierte OMG-Spezifikationen
Seit ca. 2004 arbeitet die OMG an geschäftsorientierten OMG-Spezifikationen, die nicht auf Software-Systeme ausgerichtet sind:
• Business Process Definition Metamodel (BPDM)
• Business Process Modeling Notation (BPMN)
• Organization Structure Metamodel (OSM)
• Semantics of Business Vocabularies and Rules (SBVR)
• Business Motivation Model (BMM)
Von Geschäftregeln zur Service-orientierten Architektur 32
KnowGravity Inc.: Bridging the Gap
Von Geschäftregeln zur Service-orientierten Architektur 33
Unser Angebot
Consulting
DoingTraining
BrokeringRunning
Situative Anwendung von Know-howaus unseren Kernkompetenzen in Projekten
Werkzeuge zur automatisierten Know-how Anwendung
Schulung von Know-how aus unseren Kernkompetenzen
Anwendung von Know-howaus unseren Stammgebieten zur Problemlösung und Projektabwicklung
Vermittlung von Know-how aus anderen als unseren Kernkompetenzen
Know-How
ShapingErarbeitung und Standardisierung
von neuem Know-how
Consulting
DoingTraining
BrokeringRunning
Situative Anwendung von Know-howaus unseren Kernkompetenzen in Projekten
Werkzeuge zur automatisierten Know-how Anwendung
Schulung von Know-how aus unseren Kernkompetenzen
Anwendung von Know-howaus unseren Stammgebieten zur Problemlösung und Projektabwicklung
Vermittlung von Know-how aus anderen als unseren Kernkompetenzen
Know-How
ShapingErarbeitung und Standardisierung
von neuem Know-how
…und es entstand dieModel Driven Enterprise Architecture™
Ein ganzheitlicher Ansatz für „Business Driven IT“
Von Geschäftregeln zur Service-orientierten Architektur 35
Ausgangslage
• Die OMG hat schon länger eine Menge solider IT-orientierter Spezifikationen
• Die OMG hat neu nun auch eine Menge Business-orientierter Spezifikationen
• All diese Spezifikationen sind allerdings unabhängig voneinander entstanden und nicht wirklich aufeinander abgestimmt
• KnowGravity Inc. setzt bereits seit Jahren auf ganzheitliche Business-orientierte Engineering-Ansätze
• Aufgrund der Profilierung im Bereich „Business Rules Approach“ ist KnowGravity Inc. bei der Ausarbeitung der OMG-Spezifikationen „Business Motivation Model“ und „Semantics of Business Rules and Vocabulary“ aktiv beteiligt
• Als UML-Schulungsanbieter seit mehr als 11 Jahren, entsprechender Projekterfahrung und Entwickler eines xUML-Tools hat KnowGravity Inc. ausgezeichnetes Software Engineering Know-how
Von Geschäftregeln zur Service-orientierten Architektur 36
Ziele
Es soll ein methodisches Framework entwickelt werden, das
• sowohl Business Modelle als auch IT Modelle gleichgewichtig unterstützt
• sämtliche Modelle konzeptionell integriert und somit eine durchgängige Traceability ermöglicht
• so weit wie nur irgendwie möglich auf OMG-Spezifikationen beruht
• wo nicht bereits durch OMG-Spezifikation festgelegt, Notationen definiert
• keine Einschränkungen bezüglich methodischem Vorgehen auferlegt
Von Geschäftregeln zur Service-orientierten Architektur 37
Geschäftsmotivation Geschäftsgestaltung
IT-Konzeption IT-Realisation
Model Driven Enterprise Engineering™
Strategie-Modell
OperationellesModell
Technologie-Modell
IT-Support-Modell
Motivation VokabularRegelnProzesse
Organisation
AnforderungenProjekte
Spezifikationen
ArchitekturDeploymentsTransformation
Was? Wie?
Ges
chäf
tspe
rspe
ktiv
eIT
-Per
spek
tive
Von Geschäftregeln zur Service-orientierten Architektur 38
MDEE basiert auf bewährten Ansätzen
OMG Spezifikationen:• Motivation: Business Motivation Model (BMM)• Vokabular & Regeln: Semantics of Business Vocabularies and Business Rules
(SBVR)• Prozesse: Business Process Modeling Notation (BPMN) und Business Process
Definition Metamodel (BPDM)• Organisation: Organization Structure Metamodel (OSM)• Anforderungen: Systems Modeling Language (SysML)• Spezifikation: Executable UML (xUML)• Architektur & Deployments: Unified Modeling Language 2 (UML 2)• Transformationen: Model Driven Architecture (MDA)
Ergänzende Ansätze:• SSM/CATWOE: Formulierung einer gemeinsamen Vision• Riva: Prozessarchitektur und Rollen• PRINCE2: Projekt-, Change- und Release-Management• Zachman Framework: Enterprise Architektur
Strategie-Modell:Geschäftsmotivation
mit OMG’s
Business Motivation Model (BMM)Motivation
Von Geschäftregeln zur Service-orientierten Architektur 40
Das Business Motivation Model (BMM)
Das Business Motivation Model (BMM) wurde ursprünglich von der Business Rules Group entwickelt und ist seit Dezember 2005 eine Spezifikation der Object Management Group (OMG). Es wird im Zusammenhang mit Corporate Governance verwendet, um
• Unternehmensstrategien zu entwickeln• Unternehmensstrategien sich ändernden Situationen anzupassen• Unternehmensstrategien und operative Richtlinien zu dokumentieren• Nachweise und Begründungen bei Compliance Anforderungen (SOX,
Basel II, etc.) zu liefern.
Im Zusammenhang mit der OMG dient es zudem als verbindendes Element verschiedener Spezifikationen
• Vokabular- und Geschäftsregelmodellierung (SBVR)• Geschäftsprozessmodellierung (BPDM, BPMN)• Organisationsstrukturmodellierung (OSM).
Von Geschäftregeln zur Service-orientierten Architektur 41
Das BMM im Überblick
EndVision
amplified by
Desired Result
quantifies
quantified by
amplifiescomposed
ofpart of
Goal
composed of
part ofObjective
acts asInfluencer
Internal Influencer
Corporate Value
External InfluencerEnvironment Technology Regulation
Supplier Customer Competitor Partner
Stated Unstated
Infrastructure Issue Assumption
Habit
Management Prerogative
Resource QualityPotential Impact
Risk Potential Reward
Assessment
Strength Weakness
Opportunity Threat
identifies
is significant to
judged ina judgment about
impacted by influences expressed in
expressesimpact ofinfluence on
Means
Course of Action
Directive
BusinessPolicy
part of
composed of
implementsimplemented by
component of plan for
planned by means of
composed of
part of
enabled by
enables
formulatedbased on
guided byguides
source of
governs
determines Strategy
composed of
part ofTactic
Mission
motivated by
makes operative
supports the achievement of
impacted by influences expressed in
expressesimpact ofinfluence on
provides theimpetus for
has achievement supported by
acts as
provides theimpetus for
motivated by
channels efforts towards
supported by
made operative by
a role played by
established by
establishes
defines
recognized by
made by
recognizes
defined by
guidedby
shapedby
makes
realizes
defined by
OrganizationUnit
BusinessProcess realized by
guides
governs
determines
BusinessRule
derived frombasis for
effects enforcement levelhas enforcement
level effected by
Von Geschäftregeln zur Service-orientierten Architektur 42
Beispiel: Motivation Model
«Goal»Service availability
«Potential Impact»{impact type = Risk}Loosing customers
«Objective»{criterion = percent of car requests fulfilled.}
{timeframe = End of this year}Car availability
«Mission»Our Mission
«Objective»{timeframe = End of next year}
Customer
«Goal»Customer expectation
«Assessment»{assessment type = threat}
Assessment of budget airlines
sales
«Strategy»Airport focus
«Influencer»{influencer source = external}{influencer type = competitor}
Budget airlines
«Vision»Our Vision
walk-in rental
«assesses effect on»
«quantifies»
«part of»
«part of»
«causes employment of»
«quantifies»
«amplifies»
«judges»
«identifies»
«made by»
«planned by means of»
«makes operative»
«realizes»
Operationelles Modell:Geschäftsgestaltung
mit OMG'sSemantics of Business Vocabulary and Business Rules (SBVR),
Business Process Modeling Notation (BPMN), Business Process Definition Metamodel (BPDM)und Organization Structure Metamodel (OSM)
VokabularRegelnProzesse
Organisation
Von Geschäftregeln zur Service-orientierten Architektur 44
Was ist SBVR?
Semantics of Business Vocabulary and Business Rules (SBVR) ist die Antwort auf den OMG RfP "Business Semantics of Business Rules" und wurde von dieser im September 2005 als "offizielle OMG-Spezifikation" adoptiert. SBVR definiert
• wie ein Vokabular aufgebaut werden soll, nämlich aus
• Semantischen Konzepten
• Community-spezifischen Begriffen und Synonymen für diese Konzepte
• Präzisen Definitionen dieser Konzepte
• wie sich auf der Basis dieses Vokabulars Business Rules (fachliche Zusammenhänge) präzise, aber in natürlicher Sprache formulieren lassen
• wie sich Vokabular und Business Rules zwischen verschiedenen Werkzeugen austauschen lassen.
S-Beaver
Von Geschäftregeln zur Service-orientierten Architektur 45
reale Welt
strukturelle
operative
Geschäftsregeln
Beeinflussung
Fakten
Dinge
Vokabular
Abbildung
SBVR
Durchsetzung
Geschäftsregeln auf SBVR-Basis
Von Geschäftregeln zur Service-orientierten Architektur 46
Arten von Geschäftsregeln
Strukturelle Regeln (aletische Regeln)
• Repräsentieren Definitionen bzw. Konventionen, die Eigenschaften wichtiger Konzepte beschreiben
• Basieren auf der alethischen Logik, welche die Operatoren "es ist notwendig, dass", "es ist möglich, dass" und "es ist unmöglich, dass" basiert
• Beispiel: "Ein Kunde ist ein VIP, wenn er mindestens 1000€ Umsatz pro Jahr macht."
Operative Regeln (deontische Regeln)
• Repräsentieren Vorschriften, die ggf. verletzt werden können und daher durchgesetzt werden müssen
• Basieren auf der deontischen Logik, welche die Operatoren "es ist obligatorisch, dass", "es ist erlaubt, dass" und "es ist verboten, dass" basiert
• Beispiel: "Einem VIP muss mindestens 10% Rabatt gewährt werden."
(Nur) operative Regeln besitzen eine Durchsetzung (Enforcement)!
Von Geschäftregeln zur Service-orientierten Architektur 47
Core Concepts
amount
portion
quantity
length
physical value
number
amount
portion
quantity
length
physical value
number
credit limit
price per day
total price
open amount
number of days
UK EU-Rent Employees (active)
Swiss EU-Rent Employees
distance
rental
car modelcar
mileage
discount
specialdiscount
renter
country
branch SBVR
is blacklisted
is phased-out
is VIP
wants upgrade
books
belongs
tofrom
is in
is upgrade for
has
is in
has
has
has
is booked by
has signed
has
has
has
is of
uses
has
is signed by
«is role of»
«is role of»
«is role of»
«is role of»
Beispiel: Vokabular
Von Geschäftregeln zur Service-orientierten Architektur 48
Beispiel: Geschäftsregeln
Es ist notwendig, dass der Gesamtpreis von jeder Miete ist die Anzahl Tage *Preis pro Tag von dem Fahrzeugtyp der ist gebucht von dieser Miete.
It is necessary that the total price of each rental is the number of days * price per day of the car model that is booked by that rental.
price per day
total price
number of days
UK EU-Rent Employees (active)
Swiss EU-Rent Employees
rentalcar model
has has
is booked by has
Preis pro Tag
Gesamtpreis
Anzahl Tage
UK EU-Rent Employees
Swiss EU-Rent Employees (active)
MieteFahrzeugtyp
hat hat
ist gebucht von hat
Von Geschäftregeln zur Service-orientierten Architektur 49
Beschreibung von Konzepten
Pro Konzept wird typischerweise folgendes festgelegt:• Dessen primäre Bezeichnung (Begriff)• Allfällige Synonyme• Präzise Definition des Konzeptes• Quellenangaben• Verantwortliche
Eine präzise Definition eines Konzeptes ist immer nach einem der folgenden Schemata aufgebaut:
Schema 1: Intensionale DefinitionNeues Konzept = allgemeines Konzept
+ spezifische EigenschaftenBeispiel: Mann: Eine Person, die männlichen Geschlechts ist
Schema 2: Extensionale DefinitionNeues Konzept = entweder spezifisches Konzept1 oder
spezifisches Konzept2 oder …Beispiel: Person: Entweder ein Mann oder eine Frau
Von Geschäftregeln zur Service-orientierten Architektur 50
BPMN, BPDM und OSM
Die Business Process Modeling Notation (BPMN) wurde 2004 von der Business Processing Modeling Initiative (BPMI.org) entwickelt und nach deren Fusion mit der OMG im Dezember 2005 eine offizielle OMG Spezifikation. BPMN ist eine Notation, welche
• die graphische Darstellung von Geschäftsprozessen erlaubt• Elemente wie Ereignisse, Aktivitäten, (komplexe) Abhängigkeiten,
Artefakte, Meldungen und Ausführende (Swimlanes) unterstützt• sich auf BPEL4WS abbilden lässt.
Business Process Definition Metamode (BPDM) und Organization Structure Metamodel (OSM) sind Draft OMG Spezifikationen von Metamodellen, die
• Prozessinformationen wie Ereignisse, Prozesse, Aktionen, Dokumente, Flüsse, Rollen, etc. aber auch Prozess Choreographien strukturieren
• Elemente einer Organisationsstruktur wie Organisationen, Organisations-einheiten, Positionen, Rolle, Personen, etc. strukturieren.
Diese Spezifikationen werden nun innerhalb der OMG zu einem einheitlichen Ganzen konsolidiert.
Von Geschäftregeln zur Service-orientierten Architektur 51
Beispiel: Organisationsstruktur
{head = John}sales
{head = Rolf}sales
{staff = Bruno}{percent = 50%}
scheduler
{head = Jim}London
{staff = Christof}sales assistant
{head = Beatrice}Zürich
{head = Fraser}corporate marketing
{staff = Caroline}marketing assistant
{staff = John}sales 1
{staff = Caroline}{percent = 60%}
sales 2
{staff = Céline}accountant
«Organization» {head = Jason}EU-Rent
cooperates with
Von Geschäftregeln zur Service-orientierten Architektur 52
Beispiel: Geschäftsprozess
make offer
check availability
create rental contract
AND Gateway
ready to handover car
logistics
book car model
assign car
customer wants to rent a car
express requirements
acceptable?
rental contract{artifact type = document}
customer not interested
renter
rental request
«involves»«involves»
no
yes
«involves»«involves»
Von Geschäftregeln zur Service-orientierten Architektur 53
Beispiel: Verantwortlichkeiten
EU-Rent
sales
make offer
check availability
create rental contract
AND Gateway
ready to handover car
«Organizational Unit»logistics
logistics
book car model
assign car
«Organizational Unit»
«Organization»renter
customer wants to rent a car
express requirements
acceptable?
rental contract{artifact type = document}
customer not interested
renter
«Role»
rental request
«involves»«involves»
no
yes
«involves»«involves»
IT-Support-Modell:IT-Konzeption
mit OMG’s
Systems Modeling Language (SysML) und Executable UML (xUML)
AnforderungenProjekte
Spezifikationen
Von Geschäftregeln zur Service-orientierten Architektur 55
SysML und xUML
Die Systems Modeling Language (SysML) ist eine auf der UML basierende Sprache zur ganzheitlichen Systemmodellierung und ist seit April 2006 eine offizielle OMG Spezifikation. SysML unterstützt die Modellierung von
• Anforderungen an Systeme (SW und HW)• Struktur von Systemen (SW und HW)• Physikalischen / mathematischen Systemzusammenhängen.
In MDEE verwenden wir hauptsächlich den Anforderungs-Teil der SysML.
Die executable UML (xUML) ist eine Erweiterung der UML um eine präzise und ausführbare Semantik. Nach verschiedenen Produkt-orientierten Ansätzen ist seit April 2005 eine OMG Spezifikation in Arbeit. In MDEE verwenden wir eine stark erweiterte Version der OMG-Spezifikation mit folgenden Möglichkeiten:
• Umfassende Verhaltensmodellierung auf Basis OCL und Action Semantics• Umfassende Integration regelbasierter Modellierung• Ausführbare Use Case Modelle.
Von Geschäftregeln zur Service-orientierten Architektur 56
Beispiel: Anforderungen
«Rule Set»Car Logistics
«Project»EU-Rent CAT
Release1
Release2
«Requirement»
Rq4.1functionalPrices shall be automaticallycalculated by the IT system accordingrule "R4: total price".
autom. pricing
«Test Case»TC1: Pricing
«Requirement»
Rq4.1.1functionalDiscounts shall be automaticallycalculated by the IT system accordingto "RS1: volume discount".
autom. discounting
«Requirement»
Rq4functionalBusiness rules shall be automated.
Automated business rules
«Requirement»
NFRq1non-functionalThe ruleset "RS1: volumediscount" for discountsshall be maintainable bybusiness people.
NFRq1
R«Structural Rule»
RS1: volume discount
«Requirement»
Rq4.2functionalScheduling of cars shall be performedautomatically according to ruleset CarLogistics
car scheduling
R«Structural Rule»
R4: total price
«Rulebase Type»Pricing
«Requirement»
Rq1functionalInformation about renters and rentalsshall be maintained in the IT system.
Rental information
«Requirement»
Rq2functionalInformation about cars and car modelsshall be maintained in the IT system.
Car Information
rental rentercar
car model
«verify»
«satisfy»
«satisfy»
«satisfy»
«satisfy»
«satisfy»
«satisfy»
«satisfy»
«trace»
«trace»
«derived from»
«trace»
«trace» «trace»
«trace»
«trace»
Von Geschäftregeln zur Service-orientierten Architektur 57
Beispiel: Ausführbare UML-Modelle
sales clerk«xUML Actor»
car manager«xUML Actor»
car clerk«xUML Actor»
handle rental«xUML Use Case»
handle renter«xUML Use Case»
define carmodel
«xUML Use Case»
handle cars«xUML Use Case»
handover car«xUML Use Case»
«include» «include»
«extend»
handle renter
Description:EURIS
«xUML Service»
Create a new renter as a person personCreate a new renter as an organization organizationPut a renter on the blacklist blacklist renterRemove a renter from the blacklist rehabilitate renterChange a renter's credit limit change credit limitDeclare a renter as a VIP renter is VIP(generated event)... show organization(generated event)... show person
Von Geschäftregeln zur Service-orientierten Architektur 58
Beispiel: Ausführbare UML-Modelle (2)
normal
advance reservation
advance reservation/ '/discount' := ( 15 if 'number of days' >= 14 and 'signing renter'.'is VIP'; 10 if 'number of days' >= 14 and not 'signing renter'.'is VIP'; 10 if 'number of days' >= 7 and 'number of days' < 14 and 'signing renter'.'is VIP'; 5 if 'number of days' >= 7 and 'number of days' < 14 and not 'signing renter'.'is VIP'; 5 if 'number of days' < 7 and 'signing renter'.'is VIP'; 0 otherwise)
available
maintain car['using rental' \= []]/ box 'Car is currently in use!'
on maintenance
normal
sell car['using rental' \= []]/box 'Car still in use!'
car
car/ find CM where id = model; if CM = [] then (box 'Invalid car model!'; rollback); tie to CM via 'is of'; id := vin; mileage := 0; 'next service' := 'is of'.'service interval'; '/is available' := (in_state(#('normal'.'available')) and 'using rental' = [])
when( mileage >= 'next service' )['using rental' = []]/
maintenance completed/ 'next service' := mileage + 'car model'.'service interval'
when( 'car model' = [] and 'using rental' = [] )/ sell car['using rental' = []]/
«xUML Domain Object»renter
id : textis VIP : booleancredit limit : real/has open amount : real/is on blacklist : boolean
«xUML Domain Object»car model
id : textprice per day : realservice interval : ordinal/available cars : any/is phased-out : boolean
«xUML Domain Object»rental
number of days : ordinalexpected return : timepoint/total price : real/discount : ordinal/penalty : real
«xUML Domain Object»person
«xUML Domain Object»organization
«xUML Domain Object»walk-in rental
«xUML Domain Object»advance reservation
«xUML Domain Object»car
id : textmileage : ordinalnext service : ordinal/is available : boolean
*
1 signing renter
signed rentals*
1
booked model
booking rentals
** downgrade upgrade
0..1 1
used carusing rental
*
1 is of
cars
Technologie-Modell:IT-Realisation
mit OMG’s
Unified Modeling Language (UML) und Model Driven Architecture (MDA)
ArchitekturDeploymentsTransformation
Von Geschäftregeln zur Service-orientierten Architektur 60
UML und MDA
Die Unified Modeling Language (UML) ist eine der wichtigsten Spezifikationen der OMG und bildet Grundlage des MDEE-Profils. UML 2.1 wird in MDEE verwendet, um
• die technische Ziel-Architektur mittels erweitertem Deployment Diagramm zu beschreiben
• den Deployment Prozess als regelgesteuerten „Geschäftsprozess“ zu spezifizieren
• Design Patterns als Design-Entscheidungen zu dokumentieren.
Die Model Driven Architecture (MDA) ist das zentrale Framework der OMG, welches Modelle verschiedenster Art untereinander integriert. Auf der Basis von MDA werden in MDEE
• verschiedene Perspektiven unterschieden:• Computation Independent Model (CIM): Business Perspektive• Platform Independent Model (PIM): IT-Perspektive / IT Support Modell• Platform Specific Model (PSM): IT-Perspektive / Technologie Modell
• Modelltransformationen ermöglicht, z.B. CIM � PIM � PSM � Betrieb• via MOF/XMI Modelle zwischen verschiedenen Werkzeugen austauschbar.
Von Geschäftregeln zur Service-orientierten Architektur 61
Beispiel: Deployment Diagramm
Mobile Device2ADSL/WLAN Gateway
WLAN
Jupiter (London)
Operating System : Solaris
AppServer : IBM Websphere
Rule Engine : JRules
RB1 : Pricing (ILOG)
App1 : CRM
DBMS : Oracle
C-DB : Customers
P-DB : Products
Pricing.hlp : Pricing Help
LAN
Notebook1: MS Office
Desktop1: MS Office
Internet
Desktop2: MS Office
Pluto (Zürich)
DBMS : Oracle
Locales : Customers
Pricing.hlp : Pricing Help
EU-Rent VPN
Desktop3: MS Office
Router1
Hub
Hub2
IEEE 802.11
VPN
VPN
VPN
ADSL
IEEE 802.11
IEEE 802.11
Von Geschäftregeln zur Service-orientierten Architektur 62
Beispiel: Modell-Transformationen
«Transformation»{last run = 12.03.2007 12:47:16}
«TR23P2RA»Create Process Requirements
«Process Model»Business Processes
RMRM«Requirements Model»
Generated Requirements
«Transformation»{last run = 28.04.2007 08:08:52}
«TR23P2UA»Generate Use Case Model
«Transformation»{last run = 28.04.2007 08:34:44}
«TR23V2DA»Generate Domain Object Model
«xUML Model»Generated xUML Model
«Transformation Controller»{last run = 05.01.2007 09:36:48}
«TRCTSequence»Generate xUML Model
«Transformation Controller»{last run = 05.01.2007 09:36:46}
«TRCTSequence»Generate all
accept payment
«Vocabulary»Mini EU-Rent Vocabulary
branch
«Transformation»{last run = 28.04.2007 08:34:50}
«TR23V2RA»Create Vocabulary Requirements
«Transformation Controller»{last run = 05.01.2007 09:36:46}
«TRCTSequence»Create Requirements
«Transformation Controller»{last run = 12.03.2007 11:25:17}
«TRCTSequence»Generate Requirements & Use Cases
«Rule Set»Promotion Discount
«Transformation»{last run = 28.04.2007 09:51:35}
«TR20R2RA»Deploy Promotion Rules
«include»
«output»
«include»
«include»
«output» «output»
«call» «call»
«call»
«exclude» «call» «call» «include»
«output»
«exclude»
«call»
«call»
«call»
«include»
Fallstudie „Engineering von Services“ mit Demonstration
Von Geschäftregeln zur Service-orientierten Architektur 64
Strategiemodell
«Goal»Service availability
«Potential Impact»{impact type = Risk}Loosing customers
«Objective»{criterion = percent of car requests fulfilled.}
{timeframe = End of this year}Car availability
«Mission»Our Mission
«Objective»{timeframe = End of next year}
Customer
«Goal»Customer expectation
«Assessment»{assessment type = threat}
Assessment of budget airlines
sales
«Strategy»Airport focus
«Influencer»{influencer source = external}{influencer type = competitor}
Budget airlines
«Vision»Our Vision
walk-in rental
«assesses effect on»
«quantifies»
«part of»
«part of»
«causes employment of»
«quantifies»
«amplifies»
«judges»
«identifies»
«made by»
«planned by means of»
«makes operative»
«realizes»
Von Geschäftregeln zur Service-orientierten Architektur 65
EU-Rent
sales
make offer
{IT support = none}
check availability
{IT support = supported}
create rental contract
AND Gateway
ready to handover car
«Organizational Unit»logistics
logistics
book car model
assign car
{IT support = automated}
«Organizational Unit»
«Organization»renter
customer wants to rent a car
express requirements
acceptable?
rental contract{artifact type = document}
customer not interested
renter
«Role»
rental request
«involves»«involves»
no
yes
«involves»«involves»
Geschäftsprozess „walk-in rental“
Von Geschäftregeln zur Service-orientierten Architektur 66
Anforderungen
Id Text
F-01 Business activity check availability in process walk-in rental needs to be supported by an IT system provided to the following performers: sales.
F-02 Business activity assign car in process walk-in rental needs to be automated by an IT system.
F-03 Business activity calculate price in process create rental contractneeds to be automated by an IT system.
F-04 Business activity create contract in process create rental contract needs to be supported by an IT system provided to the following performers: sales.
F-05 …
Von Geschäftregeln zur Service-orientierten Architektur 67
Use Cases
sales
checkavailability
createcontract
initiales Modell
sales clerk
car clerkfront clerk
createcontract
update renter'scredentials
handover car
register renter
get overview
«include»
«include»
«include»
«extend»
EURIS
verfeinertes Modell
Von Geschäftregeln zur Service-orientierten Architektur 68
Traceability zur Impact Analyse
BPD1
T1
T2
T3
O1 O2
BPD2
T2
T4
O3
Rq1 Rq2 Rq3 Rq4 Rq5
Herleitung vonAnforderungen
Rq1 Rq2 Rq3 Rq4 Rq5
Use Cases for BPD1
T1
T3
T2O1
O2
Use Cases for BPD2
T2
T4O3
Umsetzung vonAnforderungen
"Rq3: Unterstützung von O2 bei der Ausführung von T3 im Rahmen von BPD1"
Von Geschäftregeln zur Service-orientierten Architektur 69
Transformationen
«Transformation»{last run = 21.01.2008 15:09:35}
«TR23P2RA»Generate Requirements
check availability
make offer
assign car
calculate price
create contract
RMRM«Requirements Model»Requirements Model
«Transformation»{last run = 21.01.2008 15:37:31}
«TR23P2UA»Generate Use Cases
«xUML Model»xUML Model
«include»
«include»
«include»
«include»
«include»
«output»
«include»
«output»
Von Geschäftregeln zur Service-orientierten Architektur 70
Services
create contract
Description:EURIS
«xUML Service»:Decision Service«xUML Service»
:Query Service«xUML Service»
If new renter then
register renter person
register renter's driver license set driver license
If VIP then
register renter as VIP renter is VIPend
end
create a new rental new walk-in rentalcalculate its price calculate price
If necessary then
update new rental change daysrecalculate its price calculate price
end
assign car to rental assign car
view new rental rental details
Von Geschäftregeln zur Service-orientierten Architektur 71
Jupiter (London)
Solaris1 : [Solaris]
AppServer1 : [IBM Websphere]
Decision Service : [JRules]
RB1 : Pricing
ER1HP : EURIS
Query Service : [Oracle]
C-DB : Customers
P-DB : Products
Price List.hlp : Pricing HelpSolaris1 : [Solaris]
AppServer1 : [IBM Websphere]
Decision Service : [JRules]
RB1 : Pricing
ER1HP : EURIS
AppServer1 : [IBM Websphere]
Decision Service : [JRules]
RB1 : Pricing
ER1HP : EURIS
Decision Service : [JRules]
RB1 : PricingRB1 : Pricing
ER1HP : EURIS
Query Service : [Oracle]
C-DB : Customers
P-DB : Products
C-DB : Customers
P-DB : Products
Price List.hlp : Pricing Help
Applikationen
Zusammenfassung
MDEE: Modelle, Techniken und Standards
Von Geschäftregeln zur Service-orientierten Architektur 73
Zusammenfassung
Das (echte) Schweizer Armeemesser für Unternehmensgestaltung basierend auf OMG Spezifikationen:
BMM
SBVRBPMNBPDMOSM
SysMLxUML
UMLMDA
Von Geschäftregeln zur Service-orientierten Architektur 74
Woher kommt Agilität?
Geschäftsmotivation Geschäftsgestaltung
IT-Konzeption IT-Realisation
Strategie-Modell
OperationellesModell
Technologie-Modell
IT-Support-Modell
konventionelle Implementation oder Generierung
Änderung wenig volatiler Funktionen
Von Geschäftregeln zur Service-orientierten Architektur 75
Woher kommt Agilität? (2)
Geschäftsmotivation Geschäftsgestaltung
IT-Konzeption IT-Realisation
Strategie-Modell
OperationellesModell
Technologie-Modell
IT-Support-Modell
Auf der Basis interpretativer Business Rule Technologie
Änderung hoch volatiler Funktionen
Von Geschäftregeln zur Service-orientierten Architektur 76
Erfahrungen
• Die wenigsten Kunden/Projekte verwenden alle vier Quadranten des MDEE Frameworks
• SBVR-Vokabulare scheinen eine Lösung für ein oft vorkommendes Problem zu sein
• Die Integration zwischen Prozessen und Regeln ist noch verbesserbar
• BPMN eignet sich nur bedingt für Prozesse, die auch Menschen involvieren
• SysML Requirements Diagramme sind von beschränktem Nutzen (nicht aber das dahinter stehende Modell)
• xUML lohnt sich auch für komplexe kommerzielle Systeme (Beispiel: 10 Tage für eine komplexe Verkaufsapplikation; 2 Tage für eine einfache Bank)
• Vollständige Traceability durch integriertes Metamodell hilft bei der Impact-Analyse
• Transformationen eröffnen neue Horizonte
Von Geschäftregeln zur Service-orientierten Architektur 77
Aktueller Stand OMG-Spezifikationen (1)
• BMM
• Im September 2007 als 1.0 Beta 3 publiziert
• Voraussichtlich im 1. Quartal 2008 offiziell freigegeben
• RTF zur Bildung der Version 1.1 per Oktober 2008 gestartet
• SBVR
• Im Januar 2008 als 1.0 publiziert
• RTF zur Bildung der Version 1.1 per Juli 2008 gestartet
• BPMN/BPDM/OSM
• BPMN Im September 2007 als 1.1 Beta 3 publiziert
• Voraussichtlich im 1. Quartal 2008 offiziell freigegeben
• RTF zur Bildung der Version 1.2 per März 2008 gestartet
• BPDM Im Juli 2007 als 1.0 Beta 1 publiziert
• RFP für BPMN 2.0 mit Integration von BPDM mit ersten Submissions per Juni 2008 (Abschluss ca. 2009)
• Überarbeitete OSM-Submissions per Februar 2008 erwartet, aber noch keine öffentliche Version verfügbar
Von Geschäftregeln zur Service-orientierten Architektur 78
Aktueller Stand OMG-Spezifikationen (2)
• SysML• Im September 2007 als 1.0 offiziell verfügbar• RTF zur Bildung der Version 1.1 per Juli 2008 gestartet
• UML/xUML/OCL• UML 2.1.1 seit Februar 2007 offiziell verfügbar• RTF zur Bildung der Version 2.2 per Juli 2008 gestartet• „xUML Foundation“ Submissions per Mai 2008 erwartet, aber noch keine öffentliche Version verfügbar
• OCL 2.0 seit Mai 2006 offiziell verfügbar, keine RTF aktiv• MDA
• MDA Tool Component Submissions per Juni 2007, aber noch keine öffentliche Version verfügbar
• QVT 1.0 seit Juli 2007 als 1.0 Beta 2 publiziert; • Voraussichtlich im 2. Quartal 2008 offiziell freigegeben• RTF zur Bildung der Version 1.1 per Oktober 2008 gestartet
Von Geschäftregeln zur Service-orientierten Architektur 79
ISBN 3-540-25676-8
Besten Dank für Ihre Aufmerksamkeit!
Umfas
sende
Unters
tützung
durch
KnowEn
terprise
®