Von Geschäftregeln zur Service-orientierten …...Von Geschäftregeln zur Service-orientierten Architektur 8 Begriffe (2) • Business Rule Ansatz Eine Menge von Techniken und Technologien,

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.


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


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


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.


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.


Bridging the Gap

Gemeinsame Sprache!

Mensch

Computer


BRA Big Picture

Markt &Gesetze

BRManagement

beeinflusst

beeinflusst

Externali-sierung

BusinessRules

Geschäfts-prozesse

treiben

Umsetzungmittels Knowledge Management

Umsetzung mittels BR Technologie

S. 19


Transparente Regeln


Diskussion/Fragestellungen

• Woher kommen Geschäftsregeln?

• Wer definiert Geschäftsregeln?

• Wer ist von Geschäftsregeln betroffen?

• Wer führt Geschäftsregeln aus?

Geschäftsprozesse


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.


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


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


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



• 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


„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


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.


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



• 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


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.


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


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.



• Setzen Sie bereits auf SOA?

• SOA = Web-Services?

• Welche Granularität haben Ihre Services?

• Schwierigkeiten beim Aufbau einer SOA?

Da kamen…


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


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)


KnowGravity Inc.: Bridging the Gap


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“


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


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


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


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


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).


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


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


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


reale Welt

strukturelle

operative

Geschäftsregeln

Beeinflussung

Fakten

Dinge

Vokabular

Abbildung

SBVR

Durchsetzung

Geschäftsregeln auf SBVR-Basis


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)!


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


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


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


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.


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


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



Beispiel: Verantwortlichkeiten

EU-Rent

sales

make offer

check availability


AND Gateway


«Organizational Unit»logistics

logistics

book car model

assign car

«Organizational Unit»

«Organization»renter



acceptable?



renter

«Role»

rental request


no

yes


IT-Support-Modell:IT-Konzeption

mit OMG’s

Systems Modeling Language (SysML) und Executable UML (xUML)

AnforderungenProjekte

Spezifikationen


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.


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»


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


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


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.


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


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


«TR23P2UA»Generate Use Case Model


«TR23V2DA»Generate Domain Object Model

«xUML Model»Generated xUML Model

«Transformation Controller»{last run = 05.01.2007 09:36:48}

«TRCTSequence»Generate xUML Model


«TRCTSequence»Generate all

accept payment

«Vocabulary»Mini EU-Rent Vocabulary

branch


«TR23V2RA»Create Vocabulary Requirements


«TRCTSequence»Create Requirements


«TRCTSequence»Generate Requirements & Use Cases

«Rule Set»Promotion Discount


«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


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»


EU-Rent

sales

make offer

{IT support = none}

check availability

{IT support = supported}


AND Gateway


«Organizational Unit»logistics

logistics

book car model

assign car

{IT support = automated}

«Organizational Unit»

«Organization»renter



acceptable?



renter

«Role»

rental request


no

yes


Geschäftsprozess „walk-in rental“


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 …


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


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"


Transformationen


«TR23P2RA»Generate Requirements

check availability

make offer

assign car

calculate price

create contract

RMRM«Requirements Model»Requirements Model


«TR23P2UA»Generate Use Cases

«xUML Model»xUML Model

«include»

«include»

«include»

«include»

«include»

«output»

«include»

«output»


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


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]



RB1 : Pricing

ER1HP : EURIS



RB1 : Pricing

ER1HP : EURIS


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


Zusammenfassung

Das (echte) Schweizer Armeemesser für Unternehmensgestaltung basierend auf OMG Spezifikationen:

BMM

SBVRBPMNBPDMOSM

SysMLxUML

UMLMDA


Woher kommt Agilität?



Strategie-Modell


Technologie-Modell

IT-Support-Modell

konventionelle Implementation oder Generierung

Änderung wenig volatiler Funktionen


Woher kommt Agilität? (2)



Strategie-Modell


Technologie-Modell

IT-Support-Modell

Auf der Basis interpretativer Business Rule Technologie

Änderung hoch volatiler Funktionen


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


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


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


ISBN 3-540-25676-8

Besten Dank für Ihre Aufmerksamkeit!

Umfas

sende

Unters

tützung

durch

KnowEn

terprise

®

Documents

Von Geschäftregeln zur Service-orientierten …...Von Geschäftregeln zur Service-orientierten Architektur 8 Begriffe (2) • Business Rule Ansatz Eine Menge von Techniken und Technologien,