komponentenmodelle - sose 20011 volker gruhn lehrstuhl für software-technologie universität...

Komponentenmodelle - SoSe 2001 1

Volker Gruhn

Lehrstuhl für Software-Technologie

Universität Dortmund

[email protected]

http://ls10-www.informatik.uni-dortmund.de

+49 231 755 2782

Komponentenmodelle


By 1999, component software will be the dominant method of new application development

Gartner Group 1997


Einordnung komponentenbasierte Entwicklung

– Objektorientierte Modellierung führt zu einer großen Menge an

Klassen, Objekten, Beziehungen.

– Auf dieser kleinteiligen Ebene ist es schwierig, sinnvolle

Wiederverwendungs-Einheiten zu finden.

– Deshalb gibt es die Bestrebung, eng zusammengehörende

Klassen zu größeren Wiederverwendungseinheiten

zusammenzufassen.


Gliederung

Einleitung

Teil I - Motivation, Grundlagen, Beispielanwendung

• Motivation für komponentenbasierte Softwareentwicklung• Migration zu komponentenbasierten Anwendungsarchitekturen• Vorstellung der Beispielanwendung

Gliederung


Teil II - Die Umsetzung der Szenarien

• DCOM-Szenario• JavaBeans/CORBA-Szenario• JavaBeans/Enterprise-JavaBeans-Szenario

Teil III Vergleich und Ergebnisse

• Zusammenfassender Vergleich

Gliederung


Einleitung

• Komponentenbasierte Anwendungsentwicklung (cbd)

• Vorteile gegenüber traditioneller prozeduraler, aber auch objektorientierter Softwareentwicklung:

– Anwendungen sind leicht aus vorgefertigten Bausteinen (Komponenten) zusammenzusetzen.

– Komponenten werden von spezialisierten Komponentenentwicklern zur Verfügung gestellt.

– Wiederverwendung der Komponenten durch strikte Kapselung

Einleitung


• Etablierung von Standards - sogenannter Komponentenmodelle:

– DCOM

– JavaBeans

– Enterprise JavaBeans

• Vor- und Nachteile der Komponentenmodelle werden aufgeführt

– durch theoretische Erörterungen

– durch Beispielanwendungen

Einleitung


Begriffsdefinitionen

• Definition für den Komponentenbegriff:

»Eine Komponente ist ein Stück Software in binärer Form, das eine kohärente Funktionalität bietet. Die strikte Kapselung der Implementierung und die damit verbundene ›Black Box‹-Wiederverwendung führt zu einer gewissen Eigenständigkeit der Komponenten und ermöglicht somit eine lose Kopplung zwischen der Komponente und ihrer Umgebung. Die angebotene Funktionalität wird mittels einer oder mehrerer Schnittstellen beschrieben.

...



...

Es wird zwischen dem Begriff Komponente, der die statische Beschreibung einer Komponente (vergleichbar mit der Klasse im objektorientierten Paradigma) bezeichnet, und dem Begriff Komponenteninstanz (vergleichbar mit dem Objekt im objektorientierten Paradigma) unterschieden. Eine Komponenteninstanz kann über eine persistente (vgl. Persistenz) Identität verfügen, so dass sie auch über die Lebensdauer des sie erzeugenden Prozesses hinaus eindeutig referenziert werden kann.



• Eine Komponente ist immer für die Verwendung innerhalb genau eines konkreten Komponentenmodells ausgelegt.

Definition Komponentenmodell:

• »Ein Komponentenmodell legt einen Rahmen für die Entwicklung und Ausführung von Komponenten fest, der strukturelle Anforderungen hinsichtlich Verknüpfungs- bzw. Kompositions-möglichkeiten (Komposition) sowie verhaltensorientierte Anforderungen hinsichtlich Kollaborationsmöglichkeiten an die Komponenten stellt. Darüber hinaus wird durch ein Komponenten-modell eine Infrastruktur angeboten, die häufig benötigte Mechanismen wie Verteilung, Persistenz, Nachrichtenaustausch, Sicherheit und Versionierung implementieren kann.«



Jede Komponente unterstützt eine oder mehrere Schnittstellen, über deren Operationen man auf die Dienste einer Komponenteninstanz zugreifen kann.

Eine Operation umfasst lediglich die Signatur, eine Methode implementiert eine Operation mit einem passenden Funktionsrumpf.



Metamodell der zentralen Begriffe:



TEIL 1 Motivation, Grundlagen, Beispielanwendung

1 Motivation für komponentenbasierte Softwareentwicklung

2 Migration zu komponentenbasierten Anwendungsarchitekturen

3 Beispielanwendung

Motivation



1.1 Flexible Verteilung und Anwendungsnähe

1.2 Die Legostein-Metapher

1.3 Migration zu komponentenbasierten Softwaresystemen

1.4 Grundbegriffe der komponentenbasierten Softwareentwicklung

Motivation



• Wiederverwendung / Ende der dauerhaften Neuentwicklungen

• Ansatz zu Überwindung von Anwendungsstau

• Prinzip der Abstraktion

• Konzentration auf Geschäftslogik

– Nicht auf Persistenz, Transaktionen, etc.

• Notwendige Voraussetzungen

– Komponentenentwickler und Anwendungsentwickler

– Unterstützende Systeme, z.B. Middleware, Applikationsserver

Motivation


• Grundlage ist das Komponentenmodell

– eine Vereinbarung, wie Komponenten aussehen sollen

– Angebot von Querschnittsservices

– Namenskonventionen

• Entscheidung, welches Komponentenmodell verwendet wird

– prägt den gesamten Entwicklungsprozess

• Kompatiblität mit den Entwicklungswerkzeugen

• Eignung Softwareintegrationsaufgaben

• Auswahl des konkreten unterstützenden Middleware-Systems

• Auswahl eines Frameworks

Motivation


• Zielsetzung dieser Vorlesung

– Überblick über gängige Komponentenmodelle

– Kenntnis der Kriterien zum Vergleich von Komponentenmodellen

– Stärken und Schwächen der einzelnen Komponentenmodelle, sodass situationsspezifisch ein passendes Komponentenmodell gewählt werden kann

Motivation


1.1 Flexible Verteilung und Anwendungsnähe

Technische und betriebswirtschaftliche Argumente, die auf zwei Tendenzen zurückzuführen sind:

Flexible Verteilung

• In den letzten Jahrzehnten zunehmende Verteilung von Softwaresystemen

– aus monolithischen und intern nicht strukturierten Systemen wurden two-tier und multi-tier Systeme

– weitere Aufweichung in Systeme, die aus einer Reihe von Bausteinen bestehen

• können flexibel verteilt werden

• sind über vordefinierte Arten von Beziehungen zusammengesetzt

Motivation


Motivation


Motivation

• Anwendungsnahe Bausteine

– Ziel: Bereitstellung von Abstraktionen, die für den Anwendungsentwickler relevant sind

– Grundlage für zahlreiche Innovationen in der Softwareentwicklung


Motivation


Motivation

• Zwei Grundprobleme der Softwareentwicklung

– Vom knappen Fachwissen zur Software

• Konflikt: Fachwissen in den Köpfen einiger weniger Fachleute im Gegensatz zu Anwendern, die die eigentliche Verarbeitungslogik nicht kennen

• Das knappe Wissen über Funktionalität muss schnell in neue Anwendungen umgesetzt werden und optimalerweise mehrfach verwendet werden können


Motivation

• Zwei Grundprobleme der Softwareentwicklung

– Technik dominiert Fachlichkeit

• Konflikt: Funktionale Anforderungen und ihre Umsetzung gehen unter in technischen Details

• Problem: Anwendungsentwickler müssen sich um technische verursachte Probleme kümmern (passende Transaktionsmodelle, geeignete Datenstrukturen, Algorithmen, Softwarestrukturen)


Motivation

Betriebswirtschaftliche Argumente für die komponentenbasierte Entwicklung

– Plattformübergreifende Nutzung

• Vermeidung von Mehrfachentwicklung oder systemtechnisch bedingter Portierungsaufwände

– Möglichkeit des Zukaufs von Komponenten und Integration in existierende Softwarelandschaften

• Einfache Integration miteinander


Motivation

• Verkauf von eigenentwickelten Komponenten

• Fokussierung der Entwicklungsaufwände– Teile von Softwaresystemen können dazugekauft werden

(Finanzbuchhaltungssysteme, Personalbuchhaltungssysteme)

– Entwicklungskonzentration auf Bestandteile, die dem Wettbewerb zuträglich sind

• Unterstützung flexibel anpassbarer Geschäftsprozesse– Integration von Services in Prozesse


Motivation

• Verwirklichung dieser Ziele

– Anstrebung einer Reihe untergeordneter technischer Ziele:

• Strukturvorteile objektorientierter Softwaresysteme auf der Ebene des „Programmieren im Großen“

Programmierenim Kleinen

Programmierenim Großen

Objekt-orientierung

CBD

hohe Affinität!


Motivation

Angestrebte Komponenteneigenschaften

– Wohldefinierter Zweck

– Kontextunabhängigkeit

– Portabilität und Programmiersprachenunabhängigkeit

– Ortstransparenz

– Trennung von Schnittstelle und Implementierung

– Selbstbeschreibungsfähigkeit


Motivation

Angestrebte Komponenteneigenschaften

– Sofortige Einsatzbereitschaft (plug&play)

– Integrations- und Kompositionsfähigkeit

– Wiederverwendbarkeit

– Konfigurierbarkeit, Anpassbarkeit

– Bewährtheit

– Binärcode-Verfügbarkeit


Motivation

• Die Legostein-Metapher– Idee der komponentenbasierten SE: Komplette Anwendungen bauen

unter Verwendung von Bausteinen, die Teile der Anwendungslogik sind.

– Diese Bausteine sind wie Legosteine - stellt sich die Frage nach den passenden Bausteinen ...

– Je spezialisierter Bausteine sind, desto geringer die Chance für Wiederverwendung

– Können sie wiederverwendet werden, ist das von großem Nutzen

KlassenFrameworkKomponenteVorfabrizierteAnwendungIm Fall der Wiederverwendung nimmt dereingesparte Entwicklungsaufwand zupotenzielle Häufigkeit derWiederverwendung nimmt ab


Motivation

• Wiederverwendung - Häufigkeit und Nutzen:


KlassenFramework

Komponente VorfabrizierteAnwendung

Im Fall der Wiederverwendung nimmt dereingesparte Entwicklungsaufwand zu

potenzielle Häufigkeit derWiederverwendung nimmt ab


Motivation

Wiederverwendung entsteht nicht von alleine!

Wiederverwendung entsteht nicht adhoc!

Wiederverwendung erfordert eine Investitionsentscheidung!

Wiederverwendung erfordert ein Budget!



• Wiederverwendung erfordert eine geeignete Infrastruktur, die folgendes leisten muss:

– Mechanismen für die Zur-Verfügung-Stellung wiederverwendbarer Komponenten– Klassifikation wiederverwendbarer Komponenten gemäß mehrerer Kriterien und Suche

nach Komponenten gemäß dieser Kriterien• Aufbauen der Klassifikationssysteme• Klassifizieren und Wiederauffinden der Komponenten und Teilsysteme• Export von Komponenten in andere Verwaltungssysteme und Import aus anderen

Systemen in das eigene Archiv• Berichte über die Klassifikationssysteme und über die Komponenten mit ihren

Klassifikationen– Überprüfung von Dokumentationsstandards – Protokollierung der tatsächlichen Wiederverwendung


– Reporting zum Zwecke der Identifikation von Komponenten, die aus der Wiederverwendungsinfrastruktur entfernt werden können

– Integration mit dem eigentlichen Software-Prozeß!

• Eine weitere unterstützende Maßnahme ist die Benennung des obersten Wiederverwenders.

– Der Wiederverwender erörtert die Chancen der Entwicklung wiederverwendbarer Komponenten und ihrer Wiederverwendung.

– Er sorgt dafür, daß die geeignete Infrastruktur bereitsteht und verbessert diese kontinuierlich.

– Er sorgt für einen geeigneten Füllungsgrad (ggf. durch den Zukauf von Komponenten).– Er mißt er den Grad der Wiederverwendung.


• Eine wichtige organisatorische Maßnahmen ist die Etablierung eines Incentive-Systems:

– Belohnung für die Bereitstellung einer wiederverwendbaren Komponente, die auch tatsächlich wiederverwendet wird.

– Belohnung für die Wiederverwendung einer Komponente.– Belohnung für die Verbesserung einer wiederverwendbaren Komponente.

• Noch mehr als an andere Komponenten sind an wiederverwendbare Komponenten die folgenden Anforderungen zu stellen:

– Allgemeinheit– Qualität– Dokumentation– Zuverlässigkeit / Robustheit / Korrektheit


• Auch hier zeigt sich: die Entwicklung wiederverwendbarer Komponenten ist eine Investition in die Zukunft. Sie amortisert sich nur bei aufeinander folgenden, klar definierten Software-Prozessen.

• Das heißt: Wiederverwendung ist erst ab einer gewissen Reife des Software-Prozesses möglich (frühestens ab Stufe 2 CMM).


Die „Formel 3“[Big94]

• Software muß dreimal entwickelt werden, bevor sie wirklich wiederverwendbar entwickelt werden kann.

• Bevor die „Früchte der Wiederverwendung geerntet“ werden können, muß Software dreimal wiederverwendet werden.

• Folglich: der Einstieg in die Wiederverwendung erfordert eine bewußte und investive Management-Entscheidung, oder noch mal: Wiederverwendung fällt nicht vom Himmel!


Kosten/Nutzen-Relation der Wiederverwendung [Bal96]


Potentielle Hindernissebei der Einführung der Wiederverwendung

[Kau97]

ökonomisch

• fehlendes Commitment• unklare Geschäftsstrategie• Investitionshöhe• fehlende Nutzungs und Verwertungsrechte

ökonomisch

• fehlendes Commitment• unklare Geschäftsstrategie• Investitionshöhe• fehlende Nutzungs und Verwertungsrechte

organisatorisch

• im Prozeß nicht vorgesehen• Verantwortung nicht zugewiesen• fehlender Katalysator • fehlende Infrastruktur

organisatorisch

• im Prozeß nicht vorgesehen• Verantwortung nicht zugewiesen• fehlender Katalysator • fehlende Infrastruktur

soziologisch

• Not-invented-here-Syndrom• Widerstand gegen Veränderungen• Existenzängste („Re-Use ist ein Jobkiller“)• Selbstverständnis des Entwicklers/ geändertes Rollenbild

soziologisch

• Not-invented-here-Syndrom• Widerstand gegen Veränderungen• Existenzängste („Re-Use ist ein Jobkiller“)• Selbstverständnis des Entwicklers/ geändertes Rollenbild

technisch

• fehlende Erfahrung mit praktischen Anwendungen• mangelndes Know-How• Schwächen im Software-Engineering- Prozeß• fehlende Tools

technisch

• fehlende Erfahrung mit praktischen Anwendungen• mangelndes Know-How• Schwächen im Software-Engineering- Prozeß• fehlende Tools


• Der Zweck der Wiederverwendung kann– die Wiederverwendung innerhalb eines Produktes sein

– die Wiederverwendung innerhalb einer Produktfamilie (also innerhalb einer Menge von Varianten und Versionen des geleichen Produktes) sein

– die Wiederverwendung innerhalb der Software-Prozesse eines Unternehmens sein

– die Wiederverwendung über Unternehmensgrenzen hinweg sein


Wiederverwendung nach Anwendungsbereich

Unterscheidung zwischen

• vertikaler Wiederverwendung (gleicher Anwendungsbereich) und

• horizontaler Wiederverwendung (anwendunsgbereichunabhängige

Basisbausteine).

Unterscheidung zwischen • geplanter (als Bestandteil des Software-Prozesses) und • ungeplanter Erstellung wiederverwendbarer Komponenten

Ungeplante Wiederverwendung erfordert den Einsatz von Re-Techniken) (vgl. Rolle Wartungsexperte)


Arten der Wiederverwendung

Unterscheidung zwischen• white-box-Wiederverwendung (wiederverwendbare Komponenten

werden getestet, bevor sie wiederverwendet werden) und– bei geringer Reife der Wiederverwendungsinfrastruktur

• black-box-Wiederverwendung (wiederverwendbare Komponenten werden unmittelbar übernommen).– unbedingt anzustreben, weil nur dann das Aufwandsargument

vollständig greift.

– erst ab einer konsolidierten Wiederverwendungskultur möglich.


Evolutionäre Verbesserung der Wiederverwendung

Stufe 1: Ad-Hoc-Wiederverwendung: der eine tut´s, der andere nicht.

Stufe 2: Wiederverwendung verfügbarer Software: aus dem

existierenden Fundus von Software wird systematisch ausgesucht.

Stufe 3: Entwicklung für Wiederverwendung: die Entwicklung versucht,

wiederverwendbare Komponenten zu erstellen.

Stufe 4: Verwendung von Domänenmodellen, statistische Steuerung des

Prozesses: die Abstraktion der wiederverwendbaren Komponenen erreicht das

Niveau der Anwendung, der Grad der Wiederverwendung wird gemessen

Stufe 5: Organisationsweite Ausrichtung auf Wiederverwendung:

Wiederverwendung prägt Kalkulation, Methoden, Verfahren, Prozesse


Motivation

Komponentenbasierte Softwaresysteme mit verschiedenen Komponentenarten


eigenentwickelteKomponente

zugekaufteKomponente

Wrapped Komponente


Motivation

Migration zu komponentenbasierten Softwaresystemen

• Neue Software und neue Vorgehensmodelle können nur schrittweise eingeführt werden

• Geeignet hierfür sind evolutionäre und architekturzentrierte Migrationsstrategien

• Existierende Software wird Stück für Stück durch Komponenten ersetzt

• Neuentwicklungen: wiederverwendbare Komponenten



Motivation

Grundbegriffe der komponentenbasierten Softwareentwicklung

Definitionen:

• »Components are software units that are context independent both in the conceptual and the technical domain.« [12]

• »A component denotes a self-contained entity (black-box) that exports functionality to its environment and may also import functionality from its environment using well-defined and open interfaces. In this context, an interface defines the syntax and semantics of the functionality it comprises (i.e., it defines a contract between the environment and the component). Components may support their integration into the surrounding environment by providing mechanics such as introspection or configuration functionality.« [59]



Motivation

• »Eine Softwarekomponente ist ein Baustein mit vertraglich spezifizierten Schnittstellen und nur ausdrücklichen Kontextabhängigkeiten. Eine Softwarekomponente kann unabhängig verwendet werden und leicht mit anderen Komponenten integriert werden.« [61]

• »Eine Komponente ist ein Stück Software, das klein genug ist, um es in einem Stück zu erzeugen und pflegen zu können, groß genug ist, um eine sinnvolle Funktionalität zu bieten und eine individuelle Unterstützung zu rechtfertigen sowie mit standardisierten Schnittstellen ausgestattet ist, um mit anderen Komponenten zusammenzuarbeiten.« [27]



Motivation

Eine Komponente realisiert bestimmte Funktionalitäten, die sie nach außen in Form von Services bekannt macht:

– Services können von anderen Komponenten benutzt werden

– mehrere logisch zusammengehörende Services können in Form einer Schnittstelle gruppiert werden

– ein Service kann auch in mehreren Schnittstellen vorkommen



Motivation

• Komponenten werden zunächst auf der fachlichen Ebene (Geschäftsobjekte - business objects) beschrieben:

– Fachliche Beschreibungen identifizieren logisch eng zusammenhängende Anwendungsteile

• Produktbaustein

• Trarif

• Vertrag

• Lokation



Motivation

Erst mal zu einem groben Objektmodell


exist

Objektabstract

exist

Betrieb

exist

PrivatGebaeude

exist

Partnerabstract

exist

Bankverbindung

exist

Partneradresse

exist

Partnerbeziehung

exist

Organisation

exist

Person

exist

Lokationabstract

exist

Strecke

exist

PartnerRolleexist

GliedertaxeZulaessigkeit

exist

VU_LeistungBestandteilabstract

exist

VersicherungsVertragBausteinabstract

exist

ElementarBaustein

exist

Kombibaustein

exist

StrukturBausteinabstract

exist

VN_Verpflichtung

exist

VersichertesObjekt

exist

VersichertesEreignis

exist

VersicherterSchaden

exist

VersicherteSonstigeVereinbarung

exist

VersicherteVU_Leistung

exist

AnpassungVersicherungsSummeZulaessigkeit

exist

VN_VerpflichtungBestandteilZulaessigkeitabstract

exist

SfrZulaessigkeit

exist

SelbstbehaltZulaessigkeit

exist

ZuAbschlagZulaessigkeit

exist

BeitragsanpassungZulaessigkeit

exist

GewinnbeteiligungZulaessigkeit

exist

Zuordnung Merkmaltyp

exist

WerteRegel

exist

WerteTabelle

exist

ZulaessigeMerkmalwerte

exist

MerkmalTyp

exist

VN_VerpflichtungBestandteilabstract

exist

Merkmalwerte

exist

VertragsBeziehung

exist

Vertrag

MitversicherungsVertrag RueckversicherungsVertrag RahmenVertrag

exist

Kategorie

Sparten_ElementarBaustein

exist

K_VersicherungsVertrag

spartenspezifisch

K_ElementarBaustein

exist

ZuordnungKategorie

exist

ZusammensetzungsRegeln

exist

ZusammensetzungsRolleInRegel

exist

VersicherungsVertragsTypZusammensetzung

exist

VersicherungsVertragsTyp

exist

VersicherungsVertragstypProduktZusammensetzung

exist

Produktzusammensetzung

exist

StrukturBausteinTypabstract

exist

SonstigeVereinbarungTyp

exist

VN_VerpflichtungsTyp

exist

VU_LeistungsTyp

exist

SchadenTyp

exist

EreignisTyp

exist

ObjektTyp

exist

Produktabstract

exist

ElementarProdukt

exist

KombiProdukt

exist

Tarif

exist

TarifTabelle

exist

TarifTabelleSpaltenZuordnung

exist

Selbstbehalt

exist

Beitragsanpassung

exist

Gewinnbeteiligung

exist

Sfr

exist

ZuAbschlag

exist

GliedertaxeModell

exist

AnpassungVersicherungsSumme

exist

AnpassungVersicherungsSummeStufe

exist

Gliedertaxe

exist

SelbstbehaltStufe

exist

BeitragsanpassungStufe

exist

GewinnbeteiligungStufe

exist

SfrStufeSchadenquote

exist

SfrStufeJahre

Diese Version des fachlichen OO-Modells ist nocht nicht freigegeben.Vorraussichtlicher Freigabetermin ist der 30. Juli 99.

In dem fachlichen OO-Modell ist noch nicht die Paragraphenverwaltungenthalten. Ziel der Paragraphenverwaltung ist es abhängig von einem Produktund Vertrag die zugehörigen Paragraphen zu liefern.

exist

Kumul

exist

ZuAbschlagStufe

exist

BedingungZulaessigkeit

exist

BedingungZusammensetzung

exist

Bedingung

exist

Telekommunikation

exist

Ortabstract

exist

Route

exist

Gebiet

exist

PostalischeAdresse

exist

ObjektRolle

exist

Objektbeziehung

exist

KFZ

exist

Abstellflaeche

exist

AKZ

exist

Transport

exist

FirmenIndustrieGebaeude

exist

BeschaedigtesObjekt

exist

Schaedigung

exist

Konto

exist

Ereignis

exist

Leistungsbuchung

exist

AnspruchForderung

exist

Schadensfall

exist

Reserve

VU_LeistungBestandteilZulaessigkeitabstract

exist

Provisionsanspruch

exist

VertriebsResultat

exist

VertriebsResultatTyp

exist

Bewertung

exist

AgenturKondition

exist

AgenturVertrag

exist

Meldebogen

exist

VersicherungsVertrag

bietet an

0..1

1

VerpflichtungBestandteil

Zulaessigkeit

bietet an

bietet an

0..1

1

LeistungBestandteil

Zulaessigkeit

bietet an

ist ergänzbar durch

Zulässigkeit0..*

1


hängt ab von

Wertebereich

Rolle0..1

1

hängt ab von

hängt ab von

Zulaessigkeit

Rolle0..1

0..1

hängt ab von

hat

Bankverbindung

Rolle

0..1

1..*

hat

wird beschrieben durchAdresse Ort

11wird beschrieben durch

beginnt

Strecke

Ort

1

0..*

beginnt

besteht ausStreckenRoute

1..*0..*besteht aus

besteht aus

0..1

1

besteht aus

nimmt wahrPartnerRolle

1..* 1nimmt wahr

hat

Adresse

Kommunikationsart0..*

0..1

hat

hat

Partner

Adresse

1..*

1

hatbezieht sich auf

Beziehung

Partner1

0..*

bezieht sich auf

hatPartner

Beziehung0..*

1hat

hatPartner Kommunikationsart

0..*1hat

befindet sich anLoaktion

1 0..*befindet sich an

nimmt wahrObjekt Rolle

1..*1nimmt wahr

beziehr sich auf

1

0..*

beziehr sich aufsetzt sich zusammen gemaess

0..*

1

setzt sich zusammen gemaess

ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Objekt1

0..*

bezieht sich auf

hatObjekt

Beziehung0..*

1hat

tritt ein an

Lokation

Ereignis

1..*

0..1tritt ein an

wird gebildet aufgrundSchadensfall

Reserve

0..1

0..*

wird gebildet aufgrund


Reserve

Ereignis

0..1

0..*


resultiert aus

Schadensfall

Ereignis1

0..*

resultiert aus

wird abgedeckt durch

Schadensfall

Vertragsbaustein

0..1

0..*


führt zu einer Veränderung

Buchung

Buchhaltungskonto0..1

0..1


hat

Partner

AnspruchForderung

0..*

1

hat

führt zu

AnspruchForderung

Buchung1..*

1..*

führt zu

leiten sich ab

Schadensfall

AnspruchForderung0..*

1

leiten sich ab

reguliertSchadensfall Schaedigung

0..*1reguliert

betrifft

Schadensfall

Partner1..*

0..1

betrifft

wird benutzt für

1

0..1

Buchhaltungskonto

Partner

wird benutzt für

wird benutzt fürProvisionsanspruchBuchhaltungskonto

0..1 0..*wird benutzt für

beeinflußtSchaden Vertriebsresultat

0..10..1beeinflußt

beeinflußtVertriebsresultat

1..*

0..1

beeinflußt

hängt abKonditionVertriebsresultattyp

0..* 0..*hängt ab

erzeugtVertriebsresultat Bewertung

1..*1erzeugt

hängt ab

Kondition

Produkt

0..1

1..*

hängt ab

ergänzt

Kondition

Bewertung0..*

1

ergänzt

besteht aus

Vertrag

Kondition1..*

1

besteht aus

leitet sich ab

Provisionsanspruch

Bewertung0..*

0..1

leitet sich ableitet sich ab

Provisionsansoruch

Vertriebsresultat0..*

1

leitet sich ab

bezieht sich auf

Vertriebsresultat

Vertriebsresultattyp1

0..*

bezieht sich auf

wird beschrieben durch

Versicherungsvertrag

Merkmal

1..*

0..1


ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Vertrag1

0..*

bezieht sich auf

hat

Vertrag

Beziehung0..*

1

hat

setzt sich zusammen aus


V.Bst.1..*

1


wird beschrieben durchMerkmalProdukt

1..*0..1wird beschrieben durch

besteht ausMerkmal Wertebereich

1..*1besteht aus

ergänzt

0..1

0..*

ergänzt

besteht aus

Vertragsbaustein

Strukturbaustein0..*

1

besteht aus

besteht aus

Kombibaustein

Vertragsbaustein

1..*

0..1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet


VN_Verpflichtung

VerpflichtungBestandteil0..*

0..*


besteht aus0..1

1

besteht aus

besteht aus

K-Elementarbaustein0..1

1

besteht aus beteht aus

spartenspezifischer Baustein0..1

1

beteht aus

Merkmalwerte

Strukturbaustein

0..1

0..*

Merkmalwerte


0..1

0..*

MerkmalwerteVertragsbaustein

0..1 0..*

verwendetVertrag

Buchhaltungskonto

0..1

0..1verwendet

hat

0..*

1

hat

gilt füt

Vertrag

Partner

1..*

0..1

gilt füt

hängt ab von

Zulässigkeit

Rolle

0..1

0..1

hängt ab von

gelten

Sonderfall

0..1

1..*

gelten

besteht aus

Merkmaltyp

Merkmal

1

1..*

besteht aus

gehört zu

Zuordnung

Kategorie

0..*

1

gehört zu

gehört zu

Zuordnung

Merkmaltyp

0..*

1

gehört zu

kommt vor als

ObjektRolle

VersichertesObjekt0..1

1

kommt vor als

kommt vor als

ObjektRolle

Beschaedigtes Objekt0..1

1

kommt vor als

ist entstanden am

Schaedigung

Objekt1

0..*

ist entstanden am

bietet an1*

bietet an

setzt sich zusammen gemäßVersicherungvertrag

Regel0..*

1setzt sich zusammen gemäß

bezieht sich aufRegel Produkt

10..*bezieht sich auf

setzt sich zusammen gemäß

Kombiprodukt

Regel1..*

1


besteht ausBaustein

1..*

0..1besteht aus


Produkt

Baustein1..*

1


wird angewendet inZusammensetzungsregel Rolle

1..*1wird angewendet in hängt ab von

VersicherungsproduktszusammensetzungRolle

0..* 0..1hängt ab von

hängt ab von

Rolle


0..*

0..1hängt ab von

hängt ab von

Versicherungszusammensetzung

Rolle0..*

0..1

hängt ab von

bezieht sich auf

Regel

Produkt1

0..*

bezieht sich auf



Regel1..*

1


bezieht sich auf

Regel

Vers.Vertrag1

0..*

bezieht sich auf

bezieht sich auf

Tabelle

0..1

1..*

bezieht sich auf

bezieht sich auf

Vertragsbaustein

Produkt

1

0..*

bezieht sich auf

sind abgeschlossen

0..*

1

sind abgeschlossen

hat als Geltungsbereich

Lokation0..*

1



V.Bst.

Lokation0..*

0..*


bezieht sich auf

StrukturBaustein

Baustein

1

0..*

bezieht sich auf

bezieht sich auf

1

1bezieht sich auf

bezieht sich auf

Produkt

Tarif

1..*

1

bezieht sich auf

wird verwendet als

Ausgabe

Einagbe0..10..1

wird verwendet als

legt fest

Tarif

Zuordnung

1..*

1

legt fest

verwendet

Zuordnung

Merkmale0..1

0..*

verwendet

legt fest

Zuordnung

Tariftabelle1

1..*

legt fest

setzt sich zusammen ausTarif Tariftabelle

1..*1setzt sich zusammen aus

liegt zugrundeVertragsbaustein

Tarif1

1liegt zugrunde

besteht aus

Anpassung

Stufe1..*

1

besteht aus besteht aus

Modell

Stufe1..*

1

besteht aus ergänzt

Selbstbehalt

Stufe0..*

1

ergänztwird beschrieben durch

Beitragsanpassung

Stufe1..*

1

wird beschrieben durchwird beschrieben durch

Gewinnbeteiligung

Stufe1..*

1

wird beschrieben durchergänzt

Sfr

Stufe0..*

1

ergänzt ergänzt

Sfr

Schadenquote0..*

1

ergänzt

faßt zusammen


Kumul

0..*

0..*

faßt zusammen

endet

Strecke

Ort1

0..*

endet

besteht aus

0..1

1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

liegt in

Ort

Gebiet

0..1

0..*

liegt inbesteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

hat

0..1

0..*

hat

ergänzt

Stufe

ZuAbschlag

0..*

1

ergänzt

ist ergaenzbar durch

0..*

0..1




Zulaessigkeit0..*

0..1



Motivation

Vergröberung eines Objektmodells zu fachlichen Komponenten


exist

Objektabstract

exist

Betrieb

exist

PrivatGebaeude

exist

Partnerabstract

exist

Bankverbindung

exist

Partneradresse

exist

Partnerbeziehung

exist

Organisation

exist

Person

exist

Lokationabstract

exist

Strecke

exist

PartnerRolleexist


exist


exist


exist

ElementarBaustein

exist

Kombibaustein

exist


exist

VN_Verpflichtung

exist

VersichertesObjekt

exist


exist

VersicherterSchaden

exist


exist


exist


exist


exist

SfrZulaessigkeit

exist


exist


exist


exist


exist


exist

WerteRegel

exist

WerteTabelle

exist


exist

MerkmalTyp

exist


exist

Merkmalwerte

exist

VertragsBeziehung

exist

Vertrag


exist

Kategorie


exist


spartenspezifisch

K_ElementarBaustein

exist

ZuordnungKategorie

exist


exist


exist


exist


exist


exist


exist


exist


exist


exist

VU_LeistungsTyp

exist

SchadenTyp

exist

EreignisTyp

exist

ObjektTyp

exist

Produktabstract

exist

ElementarProdukt

exist

KombiProdukt

exist

Tarif

exist

TarifTabelle

exist


exist

Selbstbehalt

exist

Beitragsanpassung

exist

Gewinnbeteiligung

exist

Sfr

exist

ZuAbschlag

exist

GliedertaxeModell

exist


exist


exist

Gliedertaxe

exist

SelbstbehaltStufe

exist


exist


exist


exist

SfrStufeJahre



exist

Kumul

exist

ZuAbschlagStufe

exist


exist


exist

Bedingung

exist

Telekommunikation

exist

Ortabstract

exist

Route

exist

Gebiet

exist

PostalischeAdresse

exist

ObjektRolle

exist

Objektbeziehung

exist

KFZ

exist

Abstellflaeche

exist

AKZ

exist

Transport

exist


exist

BeschaedigtesObjekt

exist

Schaedigung

exist

Konto

exist

Ereignis

exist

Leistungsbuchung

exist

AnspruchForderung

exist

Schadensfall

exist

Reserve


exist

Provisionsanspruch

exist

VertriebsResultat

exist


exist

Bewertung

exist

AgenturKondition

exist

AgenturVertrag

exist

Meldebogen

exist


bietet an

0..1

1


Zulaessigkeit

bietet an

bietet an

0..1

1

LeistungBestandteil

Zulaessigkeit

bietet an


Zulässigkeit0..*

1


hängt ab von

Wertebereich

Rolle0..1

1

hängt ab von

hängt ab von

Zulaessigkeit

Rolle0..1

0..1

hängt ab von

hat

Bankverbindung

Rolle

0..1

1..*

hat



beginnt

Strecke

Ort

1

0..*

beginnt


1..*0..*besteht aus

besteht aus

0..1

1

besteht aus


1..* 1nimmt wahr

hat

Adresse


0..1

hat

hat

Partner

Adresse

1..*

1

hatbezieht sich auf

Beziehung

Partner1

0..*

bezieht sich auf

hatPartner

Beziehung0..*

1hat


0..*1hat




1..*1nimmt wahr

beziehr sich auf

1

0..*


0..*

1


ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Objekt1

0..*

bezieht sich auf

hatObjekt

Beziehung0..*

1hat

tritt ein an

Lokation

Ereignis

1..*

0..1tritt ein an


Reserve

0..1

0..*



Reserve

Ereignis

0..1

0..*


resultiert aus

Schadensfall

Ereignis1

0..*

resultiert aus


Schadensfall

Vertragsbaustein

0..1

0..*



Buchung


0..1


hat

Partner

AnspruchForderung

0..*

1

hat

führt zu

AnspruchForderung

Buchung1..*

1..*

führt zu

leiten sich ab

Schadensfall


1

leiten sich ab


0..*1reguliert

betrifft

Schadensfall

Partner1..*

0..1

betrifft

wird benutzt für

1

0..1

Buchhaltungskonto

Partner

wird benutzt für




0..10..1beeinflußt


1..*

0..1

beeinflußt


0..* 0..*hängt ab


1..*1erzeugt

hängt ab

Kondition

Produkt

0..1

1..*

hängt ab

ergänzt

Kondition

Bewertung0..*

1

ergänzt

besteht aus

Vertrag

Kondition1..*

1

besteht aus

leitet sich ab

Provisionsanspruch

Bewertung0..*

0..1


Provisionsansoruch


1

leitet sich ab

bezieht sich auf

Vertriebsresultat


0..*

bezieht sich auf



Merkmal

1..*

0..1


ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Vertrag1

0..*

bezieht sich auf

hat

Vertrag

Beziehung0..*

1

hat



V.Bst.1..*

1





1..*1besteht aus

ergänzt

0..1

0..*

ergänzt

besteht aus

Vertragsbaustein


1

besteht aus

besteht aus

Kombibaustein

Vertragsbaustein

1..*

0..1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet


VN_Verpflichtung


0..*


besteht aus0..1

1

besteht aus

besteht aus


1



1

beteht aus

Merkmalwerte

Strukturbaustein

0..1

0..*

Merkmalwerte


0..1

0..*


0..1 0..*

verwendetVertrag

Buchhaltungskonto

0..1

0..1verwendet

hat

0..*

1

hat

gilt füt

Vertrag

Partner

1..*

0..1

gilt füt

hängt ab von

Zulässigkeit

Rolle

0..1

0..1

hängt ab von

gelten

Sonderfall

0..1

1..*

gelten

besteht aus

Merkmaltyp

Merkmal

1

1..*

besteht aus

gehört zu

Zuordnung

Kategorie

0..*

1

gehört zu

gehört zu

Zuordnung

Merkmaltyp

0..*

1

gehört zu

kommt vor als

ObjektRolle


1

kommt vor als

kommt vor als

ObjektRolle


1

kommt vor als

ist entstanden am

Schaedigung

Objekt1

0..*

ist entstanden am

bietet an1*

bietet an


Regel0..*





Kombiprodukt

Regel1..*

1


besteht ausBaustein

1..*

0..1besteht aus


Produkt

Baustein1..*

1






hängt ab von

Rolle


0..*

0..1hängt ab von

hängt ab von


Rolle0..*

0..1

hängt ab von

bezieht sich auf

Regel

Produkt1

0..*

bezieht sich auf



Regel1..*

1


bezieht sich auf

Regel

Vers.Vertrag1

0..*

bezieht sich auf

bezieht sich auf

Tabelle

0..1

1..*

bezieht sich auf

bezieht sich auf

Vertragsbaustein

Produkt

1

0..*

bezieht sich auf

sind abgeschlossen

0..*

1

sind abgeschlossen


Lokation0..*

1



V.Bst.

Lokation0..*

0..*


bezieht sich auf

StrukturBaustein

Baustein

1

0..*

bezieht sich auf

bezieht sich auf

1

1bezieht sich auf

bezieht sich auf

Produkt

Tarif

1..*

1

bezieht sich auf

wird verwendet als

Ausgabe

Einagbe0..10..1

wird verwendet als

legt fest

Tarif

Zuordnung

1..*

1

legt fest

verwendet

Zuordnung

Merkmale0..1

0..*

verwendet

legt fest

Zuordnung

Tariftabelle1

1..*

legt fest




Tarif1

1liegt zugrunde

besteht aus

Anpassung

Stufe1..*

1


Modell

Stufe1..*

1


Selbstbehalt

Stufe0..*

1


Beitragsanpassung

Stufe1..*

1


Gewinnbeteiligung

Stufe1..*

1


Sfr

Stufe0..*

1

ergänzt ergänzt

Sfr

Schadenquote0..*

1

ergänzt

faßt zusammen


Kumul

0..*

0..*

faßt zusammen

endet

Strecke

Ort1

0..*

endet

besteht aus

0..1

1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1


0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

liegt in

Ort

Gebiet

0..1

0..*

liegt inbesteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

hat

0..1

0..*

hat

ergänzt

Stufe

ZuAbschlag

0..*

1

ergänzt


0..*

0..1




Zulaessigkeit0..*

0..1


Partner

Lokation

Objekt

Schaden /Leistung

VertriebBuchhaltung

Vertrag

Produkt/Tarif

Versicherungs-Vertrag


Motivation

Von den fachlichen Komponenten zu technischen Komponenten


exist

Objektabstract

exist

Betrieb

exist

PrivatGebaeude

exist

Partnerabstract

exist

Bankverbindung

exist

Partneradresse

exist

Partnerbeziehung

exist

Organisation

exist

Person

exist

Lokationabstract

exist

Strecke

exist

PartnerRolleexist


exist


exist


exist

ElementarBaustein

exist

Kombibaustein

exist


exist

VN_Verpflichtung

exist

VersichertesObjekt

exist


exist

VersicherterSchaden

exist


exist


exist


exist


exist

SfrZulaessigkeit

exist


exist


exist


exist


exist


exist

WerteRegel

exist

WerteTabelle

exist


exist

MerkmalTyp

exist


exist

Merkmalwerte

exist

VertragsBeziehung

exist

Vertrag


exist

Kategorie


exist


spartenspezifisch

K_ElementarBaustein

exist

ZuordnungKategorie

exist


exist


exist


exist


exist


exist


exist


exist


exist


exist

VU_LeistungsTyp

exist

SchadenTyp

exist

EreignisTyp

exist

ObjektTyp

exist

Produktabstract

exist

ElementarProdukt

exist

KombiProdukt

exist

Tarif

exist

TarifTabelle

exist


exist

Selbstbehalt

exist

Beitragsanpassung

exist

Gewinnbeteiligung

exist

Sfr

exist

ZuAbschlag

exist

GliedertaxeModell

exist


exist


exist

Gliedertaxe

exist

SelbstbehaltStufe

exist


exist


exist


exist

SfrStufeJahre



exist

Kumul

exist

ZuAbschlagStufe

exist


exist


exist

Bedingung

exist

Telekommunikation

exist

Ortabstract

exist

Route

exist

Gebiet

exist

PostalischeAdresse

exist

ObjektRolle

exist

Objektbeziehung

exist

KFZ

exist

Abstellflaeche

exist

AKZ

exist

Transport

exist


exist

BeschaedigtesObjekt

exist

Schaedigung

exist

Konto

exist

Ereignis

exist

Leistungsbuchung

exist

AnspruchForderung

exist

Schadensfall

exist

Reserve


exist

Provisionsanspruch

exist

VertriebsResultat

exist


exist

Bewertung

exist

AgenturKondition

exist

AgenturVertrag

exist

Meldebogen

exist


bietet an

0..1

1


Zulaessigkeit

bietet an

bietet an

0..1

1

LeistungBestandteil

Zulaessigkeit

bietet an


Zulässigkeit0..*

1


hängt ab von

Wertebereich

Rolle0..1

1

hängt ab von

hängt ab von

Zulaessigkeit

Rolle0..1

0..1

hängt ab von

hat

Bankverbindung

Rolle

0..1

1..*

hat



beginnt

Strecke

Ort

1

0..*

beginnt


1..*0..*besteht aus

besteht aus

0..1

1

besteht aus


1..* 1nimmt wahr

hat

Adresse


0..1

hat

hat

Partner

Adresse

1..*

1

hatbezieht sich auf

Beziehung

Partner1

0..*

bezieht sich auf

hatPartner

Beziehung0..*

1hat


0..*1hat




1..*1nimmt wahr

beziehr sich auf

1

0..*


0..*

1


ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Objekt1

0..*

bezieht sich auf

hatObjekt

Beziehung0..*

1hat

tritt ein an

Lokation

Ereignis

1..*

0..1tritt ein an


Reserve

0..1

0..*



Reserve

Ereignis

0..1

0..*


resultiert aus

Schadensfall

Ereignis1

0..*

resultiert aus


Schadensfall

Vertragsbaustein

0..1

0..*



Buchung


0..1


hat

Partner

AnspruchForderung

0..*

1

hat

führt zu

AnspruchForderung

Buchung1..*

1..*

führt zu

leiten sich ab

Schadensfall


1

leiten sich ab


0..*1reguliert

betrifft

Schadensfall

Partner1..*

0..1

betrifft

wird benutzt für

1

0..1

Buchhaltungskonto

Partner

wird benutzt für




0..10..1beeinflußt


1..*

0..1

beeinflußt


0..* 0..*hängt ab


1..*1erzeugt

hängt ab

Kondition

Produkt

0..1

1..*

hängt ab

ergänzt

Kondition

Bewertung0..*

1

ergänzt

besteht aus

Vertrag

Kondition1..*

1

besteht aus

leitet sich ab

Provisionsanspruch

Bewertung0..*

0..1


Provisionsansoruch


1

leitet sich ab

bezieht sich auf

Vertriebsresultat


0..*

bezieht sich auf



Merkmal

1..*

0..1


ist zugeordnet

0..*

0..1

ist zugeordnet

bezieht sich auf

Beziehung

Vertrag1

0..*

bezieht sich auf

hat

Vertrag

Beziehung0..*

1

hat



V.Bst.1..*

1





1..*1besteht aus

ergänzt

0..1

0..*

ergänzt

besteht aus

Vertragsbaustein


1

besteht aus

besteht aus

Kombibaustein

Vertragsbaustein

1..*

0..1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet


VN_Verpflichtung


0..*


besteht aus0..1

1

besteht aus

besteht aus


1



1

beteht aus

Merkmalwerte

Strukturbaustein

0..1

0..*

Merkmalwerte


0..1

0..*


0..1 0..*

verwendetVertrag

Buchhaltungskonto

0..1

0..1verwendet

hat

0..*

1

hat

gilt füt

Vertrag

Partner

1..*

0..1

gilt füt

hängt ab von

Zulässigkeit

Rolle

0..1

0..1

hängt ab von

gelten

Sonderfall

0..1

1..*

gelten

besteht aus

Merkmaltyp

Merkmal

1

1..*

besteht aus

gehört zu

Zuordnung

Kategorie

0..*

1

gehört zu

gehört zu

Zuordnung

Merkmaltyp

0..*

1

gehört zu

kommt vor als

ObjektRolle


1

kommt vor als

kommt vor als

ObjektRolle


1

kommt vor als

ist entstanden am

Schaedigung

Objekt1

0..*

ist entstanden am

bietet an1*

bietet an


Regel0..*





Kombiprodukt

Regel1..*

1


besteht ausBaustein

1..*

0..1besteht aus


Produkt

Baustein1..*

1






hängt ab von

Rolle


0..*

0..1hängt ab von

hängt ab von


Rolle0..*

0..1

hängt ab von

bezieht sich auf

Regel

Produkt1

0..*

bezieht sich auf



Regel1..*

1


bezieht sich auf

Regel

Vers.Vertrag1

0..*

bezieht sich auf

bezieht sich auf

Tabelle

0..1

1..*

bezieht sich auf

bezieht sich auf

Vertragsbaustein

Produkt

1

0..*

bezieht sich auf

sind abgeschlossen

0..*

1

sind abgeschlossen


Lokation0..*

1



V.Bst.

Lokation0..*

0..*


bezieht sich auf

StrukturBaustein

Baustein

1

0..*

bezieht sich auf

bezieht sich auf

1

1bezieht sich auf

bezieht sich auf

Produkt

Tarif

1..*

1

bezieht sich auf

wird verwendet als

Ausgabe

Einagbe0..10..1

wird verwendet als

legt fest

Tarif

Zuordnung

1..*

1

legt fest

verwendet

Zuordnung

Merkmale0..1

0..*

verwendet

legt fest

Zuordnung

Tariftabelle1

1..*

legt fest




Tarif1

1liegt zugrunde

besteht aus

Anpassung

Stufe1..*

1


Modell

Stufe1..*

1


Selbstbehalt

Stufe0..*

1


Beitragsanpassung

Stufe1..*

1


Gewinnbeteiligung

Stufe1..*

1


Sfr

Stufe0..*

1

ergänzt ergänzt

Sfr

Schadenquote0..*

1

ergänzt

faßt zusammen


Kumul

0..*

0..*

faßt zusammen

endet

Strecke

Ort1

0..*

endet

besteht aus

0..1

1

besteht aus

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1


0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

ist zugeordnet

0..*

0..1

ist zugeordnet

liegt in

Ort

Gebiet

0..1

0..*

liegt inbesteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

besteht aus

0..1

1

besteht aus

hat

0..1

0..*

hat

ergänzt

Stufe

ZuAbschlag

0..*

1

ergänzt


0..*

0..1




Zulaessigkeit0..*

0..1


Partner

Lokation

Objekt

Schaden /Leistung

Vertrieb

Buchhaltung

Vertrag

Produkt/Tarif

Versicherungs-Vertrag

Mitvers.-vertrag

Vertra g

Rückve rs.-vertrag Ra hmen-

vertrag

Versicherungsvertra gStrukturbaustein

Versicherungs-vertrag

Leistungs-erweite rung

Verpflichtungs-erweite rung

Produkt Merkmal

Tarif

Be dingung

Obje kt

Schade n/Leistung

Lokation

Partner

Buchhal tung

Vertrie b


Motivation

Technische Komponenten (Softwarekomponenten)

• sind Bestandteile der lauffähigen Software

• Realisierung gemäß eines Komponentenmodells

• Zusammenspiel wird in der softwaretechnischen Architektur festgelegt

• müssen mit Infrastruktursystemen (Middleware, Datenbank, Betriebssystem) interagieren

– Zusammenspiel wird in der systemstechnischen Architektur festgelegt



Motivation

Unterscheidung von Client-Komponenten / Server-Komponenten

• Client-Komponenten realisieren Benutzungsoberflächen

• Server-Komponenten realisieren die GeschäftsobjekteKlassenFrameworkKomponenteVorfabrizierteAnwendungIm Fall der Wiederverwendung nimmt dereingesparte Entwicklungsaufwand zupotenzielle Häufigkeit derWiederverwendung nimmt ab

Direktgeschäft

Außendienst

Innendienst

Web Browser

Web Browser und Applets

JavaAnwendung

Web Server

Applikationsservermit

Geschäftsobjekten

(GO)

GOGO

GO

GOGOGO


Motivation

Trend bei Client-Komponenten

• Fat clients (zweite Hälfte der 80er)

• Thin clients (90er)

• Ultra thin clients (zweite Hälfte der 90er)

• Browser-basierte Clients (aktuell)

Und entsprechende Anforderungen an Client-Komponenten und Client-Komponentenmodelle!



Motivation

Geschäftskomponenten

• werden bereits im Systementwurf identifiziert

• dienen als Bausteine der komponentenbasierten Architektur

Komponenten auf Geschäftsobjektebene

• kapseln ganze Geschäftsobjekte und realisieren die Geschäftslogik

• implementieren ganze Transaktionen des unterstützten Geschäftes oder große Teile daraus

• sind anwendungsabhängig

• sind einzeln ablauffähig



Motivation

Das Zusammenspiel von Komponenten, Komponentenmodellen, Frameworks und Middleware-Systemen


KomponentenmodellKomponentenmodell

konkrete

Komponenten

konkrete

Komponenten

FrameworkFramework

EntwicklungswerkzeugeEntwicklungswerkzeuge

komponentenbasierte

Anwendungen

komponentenbasierte

Anwendungen

MiddlewareMiddleware

müssen

zueinander

passen

werden

benutzt

für

sind

Grundlagen

für

Komponenten

sind

Grundlage

für

werden

betrieben

in

Software

architektur

Software

architektur


Motivation

Funktionalitäten von Middleware-Systemen

• Datentransfer

• Kommandoübermittlung (synchroner und asynchroner Aufruf)

• Empfang von Anfragen

• Vermeidung von Verklemmungen

• Etablierung und Beendigung von Kommunikationskanälen



Motivation

Infrastrukturaufgaben:

• Nachrichtenempfang und Aktivierung der zugehörenden Objekt-Methoden

• Verwalten der Objekt-Lebenszyklen (erzeugen, aktivieren, ändern, löschen, deaktivieren)

• Namensdienst zur Identifikation der Objekte

• Kontrolle der Zugriffe auf die Objekte

• Persistenzmanagement (automatische Synchronisation mit Persistenzspeicher)

• Objekt-Relationales Mapping (Abbildung der Objekte auf relationale Strukturen)

• Transaktionsmanagement (Sicherstellen der ACID-Eigenschaften von Operationen auf Objekten) inklusive verteilte Transaktionen



Kapitel 2: Migration zu komponentenbasierten Anwendungsarchitekturen

• Um komponentenbasierte Entwicklung erfolgreich einzuführen, – muss eine Zielsoftwarelandschaft identifiziert werden,

– müssen die benötigten Werkzeuge ausgewählt und ausprobiert werden,

– müssen Mitarbeiter geschult werden,

– müssen die unterschiedlichen Arten von Architekturen identifiziert und definiert werden.

Migration


Migration

6 Auswahl vonProdukten

7 Pilotprojekte

5 Definition/Anpassung desEntwicklungsprozesses

1 Ist-Analyse

2 Definition fachliche Architektur

3 Definition softwaretechnischeArchitektur

8 Einführung

4 Definition systemtechnischeArchitektur


1 Ist-Analyse

Konkret muss die Ist-Analyse folgende Ergebnisse erarbeiten:

– Identifikation und Beschreibung der existierenden Anwendungssysteme– Aspekte zu diesen Anwendungssystemen

• Geschäftsvorfälle• wesentliche Objekttypen (Geschäftsobjekte)• Programmiersprachen, etc.

– Beziehungen zwischen bestehenden Systemen• Benutzt-Beziehungen• Qualifizierung der gefundenen Beziehungen

– Identifikation der systemtechnischen Infrastruktur– Analyse existierender Architekturvorgaben

Migration


Aus den genannten Ergebnissen heraus lassen sich Aussagen darüber treffen,

– welche Schnittstellen zur Einbindung von Altanwendungen notwendig sind;

– welche Anwendungen gut sind, welche besser nicht weiter eingesetzt werden;

– welche Anwendungen in mehreren, verschiedenen Geschäftsprozessen genutzt werden und damit automatisch Kandidaten für zukünftige Komponenten sind;

Migration


– welche Anwendungen von mehreren Anwendungen aufgerufen werden und dadurch ebenfalls zu Kandidaten für Komponenten werden;

– welche Abhängigkeiten zwischen den Altanwendungen bestehen, um damit Risiken und Seiteneffekte einer komponentenbasierten Neuentwicklungen zu verdeutlichen;

– wann welche bestehenden Softwaresysteme abgelöst werden können und in welchem Zeit- und Kostenintervall die Ablösung durch ein neues System am wirtschaftlichsten ist.

Migration


Ist-Analyse mit Hilfe eines strukturierten Fragebogens

• Die Struktur wird genutzt für eine Auswertungsdatenbank

• Hauptaugenmerk liegt auf – fachlichem Teil

• administrative Daten

(verantwortliche Personen)

• systemtechnische Daten

(Rechner, Betriebssysteme, Netzwerke...)

– und softwaretechnischem Teil

(Programmiersprache, Entwicklungswerkzeuge)

Migration


• Weitere Möglichkeit der Auswertung: grafische Darstellung der Aufrufbeziehungen– Name der Anwendungssysteme und Zuordnung zu

Anwendungsbereichen (nicht unbedingt Organisationseinheiten);

– Direkte Aufrufbeziehungen (Call-Schnittstelle) zwischen Anwendungen und die Aufrufrichtung;

– Aufrufbeziehungen, die keiner konkreten Anwendung zugeordnet werden können, sind den Anwendungsbereichen zugeordnet;

– Qualifizierung des Aufrufs in Bezug auf die Datenmanipulation (create, read, update) über diese Schnittstelle bzw. hinsichtlich der Nutzung eines Unterprogramms;

– Reine Datenflussbeziehungen unter Angabe des verwendeten Mediums (Datei, Datenbank, etc.) mit der Flussrichtung.

Migration


2 Definition der fachlichen Architektur

• Notwendig: fachliche Basis - Beschreibung der Geschäftsobjekte mit Hilfe eines UML-Klassendiagramms

• Das Objektmodell dient zur Abgrenzung des Wirkungsbereichs der einzelnen Anwendungen

• Identifikation von Komponenten

• Ergebnis: Spezifikation von Komponenten und Abhängigkeiten

Migration


Beispiel für eine ACDL-Spezifikation einer Komponente

Migration

Komponente OrtIdentifikatorfachlich K-02Verantwortlicher Dirk Platz, adessoKomponenten-Objektmodell Komponenten der fachlichen Klassen

Version 1.7Komponenten Rolle ServerVerwendete Komponenten-Aufrufende Komponenten (fachlichK-03, Objekt),

(fachlichK-04, SchadenLeistung),(fachlich-08, Vertrag)

Service LokationsVerwaltungService-Identifikator fachlichS-02Kurzbeschreibung Beschreibt alle für eine Versicherung

sinnvollen Orte und Streckenangaben.Langbeschreibung Es wird ein Ort, eine Strecke oder eine Route

und deren Beziehungen zueinanderbeschrieben.Ein Ort kann eine postalische Adresse odereine . . . . . . .

Service-Funktion PostalischeAdresseErzeugenKurzbeschreibung Eine postalische Adresse anlegen.Langbeschreibung Die Stammdaten einer postalischen Adresse

werden angelegt, indem über die . . . . . . .Service-Funktion PostalischeAdresseLiefernKurzbeschreibung Eine postalisch .......

Komponente

Komponentenspezifikation

Service

Service-Funktion

Komponentenrealisierung

Interface

Methode

Beispiel für eine ACDL-Spezifikation einer Komponente


3 Definition der softwaretechnischen Architektur

• Die softwaretechnische Architektur legt die Komponenten der Softwarelandschaft fest.

• Komponentenschnitt: welche Komponenten realisieren den Funktionsumfang der einzelnen Anwendungssysteme und welchen Datenhaushalt umfasst eine Komponente

• Für jede Komponente muss festgelegt werden, welche Dienste sie anderen Komponenten außerhalb der Architektur anbieten

Migration


Definition der softwaretechnischen Architektur

• In Ergänzung der fachlichen Architektur werden softwaretechnische Prinzipien und nicht-funktionale Anforderungen berücksichtigt!

Prinzipien: Typische nicht-funktionale Anf.Striktheit und Formalität Performanz

Strukturierung Integrierbarkeit

Modularität Skalierbarkeit

Abstraktion Robustheit

Änderbarkeit

Allgemeinheit

Inkrementalität

Migration


Definition der softwaretechnischen Architektur

• Konkrete Ergänzungen der softwaretechnischen Architektur, um

• Anbindung an Oberflächen

• Anbindung an Persistenzschicht

• Wrapper / Integrationskomponenten

• Normalierung / Denormalisierung

• Entwurfsmuster

Migration


4 Definition der systemtechnischen Architektur

• legt die Ablaufumgebung für jede Komponente fest

• neue Komponenten sind oft nur dann ablauffähig, wenn der Zugriff auf existierende Funktionalitäten gewährleistet ist.

• Typische Bestandteile der systemtechnsichen Architektur:– Rechner, Netzwerk, Betriebssysteme, DBMSe,

Kommunikationsprotokolle, Middleware

• Zusammenspiel der systemtechnischen Aspekte muss im Rahmen der Architekturdefinition überprüft und nachvollziehbar dokumentiert werden!

Migration


5 Anpassung des Entwicklungsprozesses

• Entwicklungsprozesse müssen auf die Erfordernisse der komponentenbasierten Entwicklung angepasst werden:

– Ein Gesamtsystem wird als eine Menge von Komponenten angesehen, die identifiziert, spezifiziert und meistens im Vergleich zur bisherigen Entwicklungspraxis weitgehend unabhängig entwickelt werden. Diese Menge setzt sich zusammen aus Geschäfts- und Infrastrukturkomponenten mit der eigentlichen Geschäftslogik, die durch die Architektur vorgesehen sind, und Client-Komponenten, die die Benutzerschnittstelle mit der Dialogsteuerung enthalten.

– Die Architekturdefinitionen müssen in einzelnen, klar definierten Entwicklungsaktivitäten verbindlich berücksichtigt werden.

Migration


Übersicht Systementwicklung

Migration

Systemanalyse

Systementwurf

Systemintegration

Überleitung in die Nutzung

SE 4-7: Client-

Komponentenentwicklung

Zusammenbau derKomponenten zum

Gesamtsystem

Server-Komponentenentwicklung

Unabhängige Entwicklungvon Server-Komponenten

Beschreibung desSystems aus Anwendersicht

Zerlegung desSystems in Komponenten,

Spezifikation der Leistungen der Komponenten

Unabhängige Entwicklungvon Client- Komponenten

Server-Komponentenentwicklung


Aufgaben der Entwicklungsphasen:

• Systemanalyse:

– Das Ziel dieser Aktivität ist es, die Anforderungen an das Softwaresystem aufzunehmen und unter anderem mittels UML zu dokumentieren. Grundlage ist die als Ziel definierte Anwendungsarchitektur, denn es muss festgestellt werden, welche Bestandteile der angestrebten Anwendungsarchitektur im Rahmen des konkreten Projektes abgedeckt werden können.

Migration


• Systementwurf:

– Das Ziel dieser Aktivität ist es, das in den Anwenderforderungen beschriebene System in Server-Komponenten (für die Geschäftslogik) und Client-Komponenten (für die Benutzerschnittstellen und die Dialogsteuerung) zu zerlegen.

Als Grundlage und Vorgabe dienen dabei das Objektmodell, der Komponentenschnitt und die Komponentenbeschreibungen der softwaretechnischen Architektur. Weiterhin werden die Anforderungen an das Gesamtsystem den einzelnen Komponenten zugewiesen. Es wird beschreiben, wie die einzelnen Komponenten im Verlauf von Geschäftsvorfällen miteinander interagieren. Außerdem werden die einzelnen Dienste, die die Komponenten anbieten spezifiziert.

Migration


• Komponentenentwicklung:

– Das Ziel dieser Aktivität ist es, die einzelnen durch den Systementwurf identifizierten und spezifizierten Komponenten weitgehend unabhängig voneinander zu entwickeln.

Die Entwicklung einer Komponente hängt ganz wesentlich davon ab, ob es sich um eine Client-Komponente mit um eine Server-Komponente handelt. Bei der Entwicklung selbst ist das gewählte Komponentenmodell von entscheidender Bedeutung. Das Ergebnis der Komponentenentwicklung sind vollständig entwickelte Server- und Client-Komponenten des Systems.

Migration


• Systemintegration:

– Das Ziel dieser Aktivität ist es, die entwickelten Client- und Server-Komponenten zu einem Gesamtsystem zusammenzufügen.

• Überleitung in die Nutzung:

– Das Ziel dieser Aktivität ist es, das fertig entwickelte und integrierte System zum Einsatz in die Produktion zu bringen. Dazu ist es in der Regel erforderlich, die Komponenten an den jeweiligen Standorten zu installieren. Außerdem müssen die Altdatenbestände migriert werden. Danach kann abschließend der tatsächliche produktive Betrieb des Systems aufgenommen werden.

Migration


Definition der organisatorischen Konsequenzen

• Neu zu entwickelnde Komponenten werden mit bereits existierenden kombiniert ->– Entwicklung nicht allein für ein einziges Projekt ->

– Gewährleistung, dass die Entwicklung nicht dem Zeit- und Kostendruck eines einziges Projektes unterliegt

– Problemlösung: Entwicklung der projektspezifischen Komponenten von der Entwicklung der projektübergreifenden Komponenten organisatorisch trennen

Migration


6 Auswahl von Werkzeugen

• Grundlage: – Kriterienliste– Gewichtung– Explizite Identifikation der KO-Kriterien– Zeitliche Rahmen– Ausführliche Untersuchung einer Shortlist von Kandidaten

• Zielsetzung: Transparente und nachvollziehbare Entscheidungen unter sich schnell ändernden Rahmenbedingungen

• Und immer dran denken: Technologiezentriertheit ist ein grundlegendes Risiko!

Migration


7 Pilotprojekte

• Alle wesentlichen Entscheidungen sollten in Pilotprojekten überprüft werden

• Ziel: Vor einer breiten Einführung den Architekturrahmen weiterentwickeln und das Vorgehensmodell anpassen

• Folge: Entscheidungsrisiken werden so minimiert

Migration


Wichtige Eigenschaften von Pilotprojekten:

• Ernsthaftigkeit:

Kandidaten für Pilotprojekte sollten nicht hochkritisch sein, um den Spielraum, der für die Überprüfung und eventuell Anpassung von Auswahl- und Technologieentscheidungen vorhanden sein muss, zu erzielen. Dennoch sollte das Projekt ein Mindestmaß an Geschäftskritikalität besitzen.

Die Ergebnisse, die in »Spielprojekten« erzielt werden, finden oft nicht die Akzeptanz, die für eine unternehmensweite Verbreitung notwendig ist. Solche Projekte werden auch häufig vorzeitig gestoppt, ohne dass Aussagen über die Technologieentscheidungen getroffen werden können.

Migration


• »Coached« Anwendung von Architekturrahmen und Vorgehensmodell:

»Coached« bedeutet, dass Pilotprojekte nicht einfach mit den Entscheidungen allein gelassen werden, sondern dass zu jeder Entscheidung ein »Coach« definiert wird, der dem Entwicklungsteam bei der Fragen und Problemen zur Verfügung steht.

Das Coaching geht dabei bis hin zur konkreten Anleitung bei der Anwendung der ausgewählten Technologien. Dieser Aspekt ist besonders wichtig, da neue Technologien häufig gerade wegen des Mangels an Support während der Einführungsphase scheitern.

Migration


• Zielorientierung:

Oft werden neue Technologien in Pilotanwendungen überprüft, ohne dass ganz klar ist, welcher Art die Aussagen nun sind, die getroffen werden sollen. Die Ziele, die in den Pilotanwendungen verfolgt werden müssen deshalb klar definiert und eingegrenzt werden. Schließlich ist es sehr einfach, ein Pilotprojekt mit Ansprüchen zu überfrachten. Dagegen ist es oft möglich, die unterschiedlichen Ziele auf mehrere Pilotprojekte zu verteilen.

Migration


• Beispiele für Ziele, die im Zusammenhang mit der Einführung komponentenbasierter Softwareentwicklung in Pilotprojekten untersucht werden, sind:

– Überprüfung der nicht-funktionalen Qualitätsziele (Performanz, Robustheit, Wartbarkeit);

– Überprüfung von Produktivität und Zuverlässigkeit des Softwareprozesses;

– Überprüfung der Anwendbarkeit des Vorgehensmodells durch Entwickler.

Migration


8 Einführung

• Umsetzen des neuen Prozesses (inklusive der neuen Organisation)

• Risiko-Management

• Klare Projektstrukturen (inklusive klarer Eskalationswege)

• Unterstützung durch das Top-Management

Migration


Kapitel 3: Vorstellung der Beispielanwendung

• Projektplanung: Management Resource Planning Tool (MRPT) soll Transparenz schaffen:

– Wer arbeitet derzeit in welchem Projekt?

– Wie ist es um den Projektfortschritt einzelner Projekte bestellt?

– Wie liegen einzelne Projekte in der Zeit?

– Wie entwickelt sich die Ressourcen-Auslastung?


• Projektübergreifende Ressourcenplanung berücksichtigt:

– Die Verfügbarkeit der Ressourcen/Mitarbeiter

– Geplanter Urlaub der Mitarbeiter

– Geplante Projektunterbrechung

– Die Fähigkeiten beziehungsweise die Ausbildung der Mitarbeiter (Skills)

– die „Ortsansässigkeit“ der Mitarbeiter

Beispielanwendung


• Use-Case-Diagramm der Beispielanwendung

Beispielanwendung

DecideOnPro-jectAcceptance

ResourcePlanning

DefineProjectStructure

Controlling

VetoChanges

AcceptChanges

EnterAbsenceTime

«extend»

«extend»

«extend»

ViewToDoList«extend»

«extend»

Manager Developer

TimeAdjustment

TimeRecording

«extend»


• DefineProjectStructure:

dient der Definition der Projektstruktur. Dazu zählt die hierarchische Vorgangsstruktur mit Vorgängen, Teilvorgängen und Meilensteinen, deren Vorgänger-Nachfolger-Beziehungen sowie etwaige zeitliche Nebenbedingungen. Eine Option ist der Import eines Projektplans aus einem Projektplanungswerkzeug wie z.B. MS-Project

Beispielanwendung


• ResourcePlanning:

Hier kann die manuelle Ressourcenzuordnung vorgenommen werden. Zentrales Werkzeug dabei ist ein Gantt-Diagramm, in das Vorgänge (»Tasks«) aus der Projektstruktur, die als Baum oder Tabelle angezeigt wird, per Drag&Drop eingefügt werden können, um auf diese Weise den Vorgang einer Ressource einem Zeitintervall zuzuordnen. Die nachfolgende Abbildung skizziert dieses Gantt-Diagramm: Die Zeilen sind Ressourcen zugeordnet, die Spalten repräsentieren die Zeitachse. Durch eine geeignete Farbgebung kann die Projektzugehörigkeit der einzelnen Tasks visualisiert werden.

Beispielanwendung


• Gantt-Diagramm für projektübergreifende Ressourcenzuordnung

Beispielanwendung

Müller

Meier

KW 16 KW 17 KW 18

Schmidt

Task1 Task1Task14 Task14 Task15

Task16Task5.3 Task5.3

Urlaub Task16


• DecideOnProjectAcceptance: bietet Unterstützung bei der Entscheidung, ob beziehungsweise wann ein neues Projekt angenommen werden kann. Es wäre denkbar, dazu wiederum das Gantt-Diagramm zu verwenden.

• Controlling: Dieser Anwendungsfall beinhaltet diverse Auswertungen und Statistiken hinsichtlich Projektfortschritt, Ressourcenauslastung und dergleichen.

• ViewToDoList: Die vom Manager im Gantt-Diagramm durchgeführten Ressourcenzuordnungen bewirken eine Änderung der persönlichen »ToDo«-Liste eines Mitarbeiters (Akteur »Developer«). Diese Liste kann vom Mitarbeiter eingesehen werden und die Änderungen können akzeptiert (Use Case »AcceptChanges«) oder zurückgewiesen (Use Case »VetoChanges«) werden.

Beispielanwendung


• TimeRecording: Mitarbeiter verbuchen die von ihnen geleisteten Stunden unter Bezug auf einen Task. Bei Bedarf wird zusätzlich der Use Case »TimeAdjustment« durchgeführt.

• TimeAdjustment: Wenn sich im Projektverlauf herausstellt, dass man den Soll-Aufwand für einen Task über- oder unterschätzt hat, so kann der geschätzte verbleibende Restaufwand erfasst werden.

• EnterAbsenceTime: Verwaltung von Abwesenheitszeiten, wie zum Beispiel Urlaub.

• AcceptChanges: Neue Aufgaben, die einem Mitarbeiter übertragen werden, oder Änderungen an bestehenden Plänen, können akzeptiert oder zurückgewiesen werden. Ersteres erledigt dieser Use Case, Letzteres übernimmt »VetoChanges«.

• VetoChanges: dient der Zurückweisung von geplanten Änderungen.

Beispielanwendung


Priorisierung und Auswahl der Use Cases

• Dreh- und Angelpunkt der Anwendung ist der Use Case »ResourcePlanning«

• Um die Anwendung mit Testdaten versorgen zu können, wird der Anwendungsfall »DefineProjectStructure« ebenfalls berücksichtigt.

• Eine Umsetzung der Use Cases, die den Akteur »Developer« betreffen, hätte eine zusätzliche grafische Benutzeroberfläche erfordert und damit den Implementierungsaufwand unnötig erhöht.

• Die Anwendungen können auf mehreren Rechnern simultan gestartet und eingesetzt werden.

Beispielanwendung


Analysemodell der Beispielanwendung

Beispielanwendung


• Die zentrale Klasse ist der Vorgang (»Task«).

• Sie bildet zusammen mit der Klasse »CompositeTask« das Composite-Pattern [24], so dass beliebig tief geschachtelte Hierarchien von Vorgängen und Untervorgängen ermöglicht werden.

• Ein Task verwaltet drei Zeitspannen:

– Die Eigenschaft »durationEstimated« erfasst den geschätzten Aufwand einer Aufgabe,

– in »durationAccumulated« werden die bereits geleisteten Aufwände kumuliert. Ist abzusehen, dass der verbleibende, geschätzte Restaufwand von der Differenz der beiden vorgenannten Werte abweicht, so kann

– in »durationRemainingEstimated« der aktualisierte Schätzwert für den Restaufwand vermerkt werden.

Beispielanwendung


• Die Vorgänger-Nachfolger-Relation zwischen Tasks wird durch die verschiedenen spezifischen Ausprägungen der Klasse »TaskLink« modelliert.

• Eine Instanz der Klasse »EndBeginTaskLink« fordert beispielsweise, dass die Nachfolger-Aufgabe erst begonnen werden darf, wenn die Vorgänger-Aufgabe abgeschlossen ist.

• Über das Attribut »interval« kann ein zusätzlicher zeitlicher Abstand zwischen den beiden Aufgaben modelliert werden. »ResourceAssignment« ist das Bindeglied zwischen einem Vorgang und der ihm zugeordneten Ressourcen. Hier wird der Termin und die Dauer einer Ressourcenzuordnung verwaltet; ihr Zustand (vorgeschlagen, akzeptiert, zurückgewiesen) geht aus dem Attribut »state« hervor.

• Etwaige terminliche Beschränkungen können mittels der Spezialisierungen der Klasse »DateConstraint« eingebracht werden.

Beispielanwendung


KAPITEL 4: DCOM-Szenario

4.1 COM Übersicht4.2 Übergang zu DCOM4.3 Anwendung auf das Beispiel


KAPITEL 4.1: COM Übersicht4.1.1 Historie4.1.2 Was ist COM4.1.3 Schnittstellen4.1.4 Referenzzählung4.1.5 Erzeugen von Komponenteninstanzen4.1.6 GUID4.1.7 IDL4.1.8 Automation4.1.9 Komponentenkategorien4.1.10 Versionierung4.1.11 Containment und Aggregation4.1.12 Komponenten-Server4.1.13 Nebenläufigkeit4.1.14 Persistenz4.1.15 Monikers4.1.16 Verbindungspunkte4.1.17 ATL


4.1. COM Übersicht

• COM stellt einen gewachsenen Standard dar.

• Neben funktionalen Erweiterungen und Überarbeitungen gab es in der Vergangenheit verwirrende Namensänderungen.

• Haupteinfluss hat das Paradigma des dokumentenzentrierten Arbeitens.

– Verbunddokumente gestatten dem Anwender, verschiedene Dokumentbestandteile unterschiedlicher Herkunft in einem Gesamtdokument zu vereinen.

– Die Bearbeitung findet in dem Gesamtdokument statt. (Beispiel: Excel-Spreadsheet eingebettet in ein Word-Dokument)

– Technologie nannte Microsoft »Object Linking and Embedding (OLE)«und basierte in der ersten Fassung auf »Dynamic Data Exchange (DDE)«

Die Umsetzung der Szenarien


COM-Übersicht

Die historische Entwicklung von COM

OLE 1

DDE

OLE 2

COM

“OLE“

Sammelbegriff für COM-Technologien

ActiveX

Sammelbegriff fürInternet-

TechnologienDCOM

NT 4.0

OLE

Akronym für ObjectLinking &

Embedding

ActiveX

Sammelbegriff fürCOM-basierteTechnologien

COM+

Windows 2000

Custom Controls

Windows SDK

VBX

Visual Basic, 16-Bit

OLE-Controls

Portabilität32-Bit

OCX ´96

Fensterlose ´Controls´bessere Performanz

ActiveX-Controls

Anpassungen fürInternet-Einsatz

t


• Da OLE 1 schwierig zu programmieren war und eine schlechte Performanz hatte wurde 1993 COM ins Leben gerufen.

• OLE 2 basierte nun auf COM - diese Technologie ging in ihrer Funktionalität über OLE hinaus.

• COM wurde nun in vielen Bereichen eingesetzt, fälschlicherweise jedoch oft als OLE benannt.

• Folge: OLE wurde zum Sammelbegriff für COM-Technologien benutzt und nicht mehr als Akronym für »Object Linking and Embedding«.

COM-Übersicht


• 1996 wird ActiveX eingeführt, welches auch Gebrauch von den COM-Technologien machte.

• OLE bekommt wieder seine alte Bedeutung, ActiveX wird zum neuen Sammelbegriff für COM-basierte Technologien.

• Mitte 1996 wird Windows NT 4.0 fertiggestellt und damit das Distributed COM (DCOM) eingeführt.

– COM öffnet sich nun verteilten Anwendungen.

– Für den Klienten einer Komponente bleibt es (fast) transparent, ob er auf eine Komponente zurückgreift, die lokal oder einem anderen Rechner liegt.

COM-Übersicht


• Eng verwoben mit der Entwicklung des COM ist der Werdegang der sogenannten »Controls«.

• »Windows SDK Custom Controls« dienen der Wiederverwendung von Bedienelementen für Dialogfenster.

– Beschränkung: sie können nur in C oder C++ entwickelt werden.

• Verbesserung durch »Visual Basic Custom Controls« (VBX)

– Beschränkung: nur 16-Bit-Architektur, nur Intel-Plattformen, Simulationen von Methoden durch Action Properties

COM-Übersicht


• 1993/94 werden die Nachteile der VBX behoben:

– COM bildet die Basis.

– Controls sind 32-Bit-fähig und können in verschiedenen Container-Typen eingesetzt werden.

• Neuer Name: OLE Controls

• 1996 entsteht die OCX-´96-Spezifikation (OLE Custom Controls)

– »fensterlose« Controls

– bessere Performanz

COM-Übersicht


• OCX werden in »ActiveX Controls« umbenannt.

• OCX und ActiveX Controls stimmen im wesentlichen überein,letztere werden lediglich für Internet-Einsätze optimiert.

• Andere Firmen beginnen mit der Portierung für andere Plattformen (z.B. Solaris, HP/UX, OS/390, Digital Unix, OpenVMS) und Microsoft selbst liefert eine Portierung für Mac OS.

COM-Übersicht


• Aktueller Stand der Entwicklung: COM+ als integraler Bestandteil von Windows 2000

– Komponenten-Entwicklung wird in Java, Visual Basic und Visual C++ möglich.

– Einige Mechanismen werden ins Betriebssystem verlagert.

COM-Übersicht


4.1.2 Was ist COM?

• COM ist ein Komponentenmodell von Microsoft.

• COM ist eine Spezifikation für die Erstellung von COM-Komponenten.

• Diese sind interoperabel und dynamisch austauschbar und können als »Black Box« wiederverwendet werden.

• Es ist gleichgültig, in welcher Programmiersprache eine COM-Komponente entwickelt wird. Sie muss lediglich ein spezielles binäres Format aufweisen.

Was ist COM?


• COM vereinheitlicht Techniken, die das Ziel haben, auf existierende Funktionalität zurückzugreifen (z.B. Aufrufe von Betriebssystem-funktionen oder Kommunikation über ein Netzwerk).

• COM standardisiert den Zugriff auf das Dienstangebot einer Softwarekomponente und erreicht damit Interoperabilität zwischen Komponenten.

• COM definiert eine Vielzahl von Schnittstellen, auf denen die Kommunikation mit einer Komponente basiert. Eigene Schnittstellen können definiert werden.

• COM enthält ein »Application Programming Interface« (API) in Form der »COM-Library«.

Was ist COM?


4.1.3 Schnittstellen

• Eine Schnittstelle fasst eine Menge von normalerweise zusammengehörigen Operationen zusammen.

• Eine Operation ist die abstrakte Beschreibung einer Funktion - zunächst ist also kein Code mit ihr assoziiert.

• Im COM-Umfeld wird eine Operation durch ihren – Namen,

– die Anzahl und Art der erwarteten Übergabeparameter,

– den Typ des Rückgabewertes

– sowie einige Zusatzinformationen beschrieben.

Schnittstellen


Beispiel: Definition der COM-Schnittstelle IUnknown in Microsofts Interface Definition Language (IDL)

interface IUnknown

{

HRESULT QueryInterface( [in] REFIID riid, [out, iid_is(riid)] void**

ppvObject );

ULONG AddRef( );

ULONG Release( );

}

Schnittstellen


Beispiel: Definition der COM-Schnittstelle IUnknown1 in Microsofts Interface Definition Language (IDL)

• IUnknown weist drei Operatoren auf:QueryInterface, AddRef und Release

– QueryInterface erwartet zwei Parameter: Einen Eingabeparameter ([in]) und einen Ausgabeparameter ([out])

– REFIID ist eine Typdefinition für eine Referenz auf einen Interface Identifier (IID), ein 16-Byte-Wert, der eine Schnittstelle weltweit eindeutig kennzeichnet.

– Der zweite Parameter ist ein Zeiger auf einen void-Zeiger, der angibt wo das Ergebnis vom Typ void* abgelegt werden soll.

– Der Operationsrückgabewert ist vom Typ HRESULT, ein 32-Bit-Wert, der den Erfolg oder Misserfolg des Funktionsaufrufs anzeigt.

Schnittstellen


• Eine COM-Komponente kann beliebig viele solcher Schnittstellen implementieren.

• Es ist unerheblich, ob dies Standard-COM-Schnittstellen oder selbst definierte Schnittstellen sind.

• Die Implementierung von IUnknown ist allerdings für jede COM-Komponente obligatorisch.

• Komponentenschnittstellen werden grafisch mit einer Notation dargestellt, die auch Einzug in die »Unified Modeling Language« (UML) gefunden hat.

Schnittstellen


Grafische Darstellung einer Komponente mit Ihren Schnittstellen

ProjectPlanner

IUnknown

IPersistFile

IPersistStorage

IProjectPlanner

Schnittstellen


• Ein Klient besitzt keinen direkten Verweis auf eine Komponenteninstanz, sondern er kann nur über »Schnittstellenzeiger« mit einer Komponente interagieren.

• Über einen Schnittstellenzeiger kann ein Klient alle Operationen dieser Schnittstelle aufrufen, die dann von der Komponente implementiert werden.

• Direkter Zugriff auf etwaige Instanzdaten ist nicht möglich, eine Komponente stellt sich also dem Klienten als »Black Box« dar.

Schnittstellen


Die Benutzung von IUnknown::QueryInterface

ProjectPlanner

IUnknown

IProjectPlanner

Klient

1. Klient benutzt IUnknown-Schnittstellenzeiger, um mit Aufruf von QueryInterface(IID_IProjectPlanner) einen Zeiger auf IProjectPlanner zu erfragen.

2. Komponente liefert IProjectPlanner-Zeiger zurück.

3. Klient kann nun Opera-tionen von IProjectPlanneraufrufen.

Schnittstellen


Schnittstellen - Wie gelangt ein Klient an einen Schnittstellenzeiger?

• Bei der Erzeugung einer neuen Komponenteninstanz, erhält der Klient den IUnknown-Schnittstellenzeiger dieser Instanz.

• Über die Operation QueryInterface von IUnknown kann der Klient die Komponente befragen, ob sie diejenige Schnittstelle unterstützt, die er durch die im ersten Parameter übergebene IID spezifiziert hat.

– Positiver Fall: Der entsprechende Schnittstellenzeiger wird im zweiten Parameter zurückgeliefert und der HRESULT-Rückgabewert signalisiert Erfolg.

– Negativer Fall: Der Klient erhält den HRESULT-Rückgabewert >E_NOINTERFACE<, der anzeigt, dass die gewünschte Schnittstelle nicht von der Komponente angeboten wird - der Schnittstellenzeiger wird auf NULL gesetzt.



• Jede COM-Schnittstelle muss von IUnknown erben, direkt oder transitiv.

• Somit ist sichergestellt, dass jede COM-Komponente die drei Operatoren von IUnknown unterstützt und diese auf jedem Schnittstellenzeiger aufgerufen werden können.

• COM sieht ausschließlich die Schnittstellenvererbung vor, eine Implementationsvererbung (wie bei C++) ist nicht möglich.

• Code-Wiederverwendung wird mit anderen Mitteln erreicht (Containment und Aggregation, vgl. 4.1.11)

Schnittstellen


• Die Komponenten müssen ein bestimmtes binäres Format haben.

• Es ist dabei ein Format gewählt worden, welches sich mit einem C++-Compiler generieren läßt.

• Dabei handelt es sich um die vtable, eine Tabelle in dem die Adressen der virtuellen Methoden einer Klasse verwaltet werden.

• Darum wird eine COM-Komponente in C++ typischerweise als Klasse modelliert und sie erbt von allen gewünschten Schnittstellen (Mehrfachvererbung) und implementiert die geerbten abstrakten Methoden.

Schnittstellen


C++-Deklaration der ProjectPlanner-Komponente

class CProjectPlanner : public IProjectPlanner,

public IPersistFile,

public IPersistStorage

{

public:

HRESULT __stdcall QueryInterface(const IID& iid, void** ppv);

//...

};

Schnittstellen


Speicherstruktur der ProjectPlanner-Komponente

Schnittstellen

CProjectPlanner

Zeiger auf IProjectPlanner-vtable

Zeiger auf IPersistFile-vtable

Zeiger auf IPersistStorage-vtable

Instanz-Daten von CProjectPlanner

QueryInterface

AddRef

Release

addProject

removeProject

...

IProjectPlanner

QueryInterface

AddRef

Release

GetClassID

IsDirty

...

IPersistFile

QueryInterface

...IPersistStorage

vtable


• Die vtable unterteilt sich logisch in mehrere Segmente, in denen die Funktionszeiger der verschiedenen Schnittstellen verwaltet werden.

• Vor den eigentlichen Instanzdaten für die Attribute der Komponentenklasse werden Zeiger auf die verschiedenen Segmente im Speicher abgelegt.

• Diese Zeiger entsprechen den Werten, die man in C++ erhält, wenn eine Typkonvertierung (cast) der Komponentenklasse auf eine der Basisklassen/Schnittstellen durchführt.

• Einem Klienten, der per QueryInterface um eine Schnittstellenzeiger bittet, wird der Wert dieses Zeiger übermittelt.

Schnittstellen


C++ Deklaration der ProjectPlanner-Komponente

• Bemerkenswert ist, dass die IUnknown-Methoden mehrfach in der vtable auftreten, da die Schnittstellenklasse IUnknown nicht virtuell beerbt wird.

• Also weist jeder Schnittstellenzeiger die Fähigkeiten von Iunknown auf.

• COM erfordert eine eindeutige Assoziation zwischen Komponenteninstanz und IUnknown-Schnittstellenzeiger.

– Eine Nachfrage des IUnknown-Schnittstellenzeigers liefert in allen Schnitstellen einer Komponenteninstanz immer den gleichen Wert.

– Diese Invariante ermöglicht es zu entscheiden, ob zwei Schnittstellenzeiger auf dieselbe Komponente verweisen.



4.1.4 Referenzzählung

• Neben QueryInterface weist IUnknown noch zwei weitere Operationen auf: AddRef und Release.

• Diese werden verwendet, um einen Referenzzähler-Mechanismus zu implementieren.

• Benutzt ein Klient eine Komponenteninstanz bzw. eine ihrer Schnittstellen, muss er AddRef aufrufen um damit die Komponenteninstanz einen internen Referenzzähler inkrementiert.

• Wird die Schnittstelle nicht mehr benötigt, sollte dies durch einen Aufruf von Release anzeigen, um den Referenzzähler wieder zu dekrementieren.

Referenzzählung


Beispiel für QueryInterface und Referenzzählung

HRESULT save(IProjectPlanner+ planner){

IPersistFile* file = NULL,Hresult hr = planner ->QueryInterface( IID_IPersistFile,

(void**)&file );if (SUCCEEDED(hr))

{ // AddRev wurde bereits auf file abgerufen hr = file->IsDirty(); if (SUCCEEDED(hr) && (hr != S_FALSE))

{ // Speichern... }; // angeforderter Schnittstellenzeiger wird nicht mehr benötigt file->Release();};return hr;

};

Referenzzählung


4.1.5 Erzeugen von Komponenteninstanzen

• Der Entwickler einer COM-Komponente ist verpflichtet, neben der Komponente auch eine dazugehörige Class Factory zur Verfügung zu stellen.

• Diese hat die Aufgabe, auf Anforderung eine neue, nicht-initialisierte Instanz der entsprechenden Komponente zu erzeugen.

• Die Class Factory ist eine normale COM-Komponente, muss allerdings die Schnittstelle IClassFactory unterstützen.

Referenzzählung


Die Schnittstelle IClassFactory

interface IClassFactory : IUnknown

{

HRESULT CreateInstance( IUnknown* PUnkOuter,

REFIID riid,

void** ppvObject );

HRESULT LockServer([in] BOOL fLock);

\\ Referenzzählung für Fabrik

}

Referenzzählung


• Nachdem geklärt ist, wie eine Komponenteninstanz erzeugt wird, stellt die Frage, wie man an die dazu benötigte Fabrik gelangt.

• Dies wird durch die COM-Bibliothek gelöst.

• Analog zu den Schnittstellen jeder Komponente werden weltweit eindeutig sogenannte CLSID (Class Identifier) zugeordnet.

• Die COM-Funktion GoGetClassObject erwartet unter anderem eine solche CLSID als Parameter und liefert die passende Fabrik. CLSID ist das maschinenlesbare Pendant zu den lesbaren Schnittstellennamen.

Referenzzählung


Die COM-Funktion GoGetClassObject

HRESULT __stdcall GoGetClassObject(

const CLSiD& clsid,

DWORD dwClsContext,

CONSERVERINFO* pServerInfo,

const IID& iid,

void** ppv

);

Referenzzählung


• Eine Fabrik kann neben der obligatorischen IClassFactory-Schnittstelle noch weitere beliebige Schnittstellen unterstützen.

• Mit welcher Schnittstelle man arbeiten möchte, kann man über den IID-Parameter von GoGetClassObject steuern.

• Damit GoGetClassObject anhand einer CLSID die entsprechende Komponente instanziieren kann, sind einige Information in der Registrierungsdatenbank (registry) von Microsoft Windows zu hinterlegen.

• GoGetClassObject gewählt dem Klienten weitgehende Kontrolle über die Instanziierung einer Komponenteninstanz.

• Mit Hilfe der Funktion GoCreateInstance kann man mühselige Arbeit verkürzen (Fabrik ermitteln, damit Instanz erzeugen, Fabrik später freigeben)

Referenzzählung


Die COM-Funktion GoCreateInstance

HRESULT __stdcall GoCreateInstance(

const CLSID& rclsid,

IUnknown* pUnkOuter,

DWORD dwClsContext,

const IID& riid,

void** ppv

);

Referenzzählung


• Die bisher nicht genannte Operation LockServer der Schnittstelle IClassFactory dient der Referenzzählung der Fabriken.

• Fabriken werden vom normalen Referenzzähler ausgeschlossen und immer bei Beendigung eines Out-Of-Process-Servers freigegeben (vgl. 4.1.12).

• Ein Klient, der eine Referenz auf eine Fabrik besitzt, kann die Terminierung eines Servers durch den Aufruf von LockServer(TRUE) unterbinden, damit die Referenz nicht ungültig wird. Wird die Fabrik nicht mehr benötigt, wird dies durch LockServer(FALSE) kundgetan.

Referenzzählung


4.1.6 Weltweit eindeutige Bezeichner - GUID

• Die Interface Identifier (IID) und Class Identifier (CLSID) wurden bereits als Beispiele für die Globally Unique Identifier (GUID) genannt.

• GUID-Werte werden weitergehend zur Kennzeichnung weiterer COM-Elemente gebraucht (Beispiele: Komponentenkategorien oder Typenbibliotheken).

GUID


4.1.6 Weltweit eindeutige Bezeichner - GUID

• COM ist auf eine weltweit eindeutige Identifizierung angewiesen, damit diese GUID-Werte immer korrekt sind, werden sie durch einen Algorithmus lokal auf dem Rechner erzeugt.

GUID

• Ein GUID-Wert setzt sich aus 128 Bits zusammen:

• 48 Bits kennzeichnen den Rechner, mit dem die GUI erzeugt wurde.

• 60 Bits enthalten einen Zeitstempel (der die 100-Nanosekunden-Intervalle seit dem 15.10.1582 zählt).

• 4 Bits enthalten die GUID-Versionsnummer.

• 16 Bits werden anhand der Systemzeit berechnet (um Eindeutigkeit bei schnell hintereinander erzeugten GUID-Werten sicherzustellen).


• Microsoft Visual C++ enthält zwei Hilfsprogramme, um GUID-Werte generieren zu lassen:

– UUIDGEN.EXE (Kommandozeilen-Programm)

– GUIDGEN.EXE (grafische Bedienoberfläche)

• Programmierer können auf die COM-Funktion GoCreateGuid zurückgreifen.

GUID


4.1.7 IDL

• GUID-Werte ermöglichen eine eindeutige Identifizierung von Schnittstellen. Wo wird beschrieben, welche Operationen eine Schnittstelle aufweist?

• COM macht hier keine Vorgaben, ein Komponenten-Entwickler kann also selber bestimmen, in welcher Form eine Schnittstelle dokumentiert wird.

• Notwendig ist lediglich die Information, um das Format der vtable ableiten zu können.

IDL


IDL - Beschreibung von Schnittstellen

• In der Regel wird die Interface Definition Language (IDL) zur Beschreibung von Schnittstellen und den sie implementierenden Komponenten benutzt.

• Da CORBA ebenfalls eine IDL besitzt, spricht man auch von der MIDL (Microsoft IDL) und OMG IDL, um die beiden Sprachen voneinander zu unterscheiden.

IDL


MIDL-Auszug für die ProjectPlanner-Komponente (1/2)

[ object, uuid(67359BB5-2874-11D3-00C04FEDFA33), dual, helpstring(“IProjectPlanner-Schnittstelle“), pointer_default(unique)]interface IProjectPlanner : IDispatch{ [id(1)] HRESULT addProject( [in] ITask* project,

[in] short r, [in] short g, [in] short b ); [id(2)] HRESULT removeProject([in] ITask* project),

[propget, id(3)] HRESULT ProjectCardinal ([out, retval] short *pVal);

IDL



[id(4)] HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal);

// ...

};

[ uuid(67359BB6-2874-11D3-831D-00C04FEDFA33), helpstring(“ProjectPlanner Class“)]coclass ProjectPlanner{ [default] interface IProjectPlanner;

interface IPersistStorage; interface IPersistFile;

};

IDL


Aufgaben der IDL-Dateien

• Dokumentation von Komponenten und Schnittstellen

• Automatisches Generieren der Proxy und der Stub

• Kompilieren in so genannte Typbibliotheken

IDL


4.1.8 Automation und die IDispatch-Schnittstelle

• Automation bezeichnet eine Technik, die den Zugriff auf COM-Komponenten erlaubt, ohne zur Compile-Zeit Kenntnis über die Binärstruktur der zu nutzenden Komponenten zu haben.

• Im Gegensatz zum direkten Zugriff über zB Header-Dateien

• Eine Komponente, die Automation unterstützt, implementiert die von IUnknown abgeleitete Schnittstelle IDispatch, welche einen dynamischen Operationsaufruf gestattet.

• Eine solche Komponente bezeichnet man auch als Automation Server.

• Klient wird Automation Controller bezeichnet

Automation


• Ein Automation Controller übergibt dem Automation Server einen oder mehrere Operationsnamen in der IDispatch Operation GetIDsOfNames.

• Dieser erhält für jede Operation eine so genannte DISPID (als 32-Bit-Integer) zurück, sofern die entsprechende Operation von der Komponente unterstützt wird.

• Unter Angabe einer DISPID kann eine entsprechende Operation über die IDispatch-Operation Invoke aufgerufen werden.

• Diese Operationen bezeichnet man als Dispinterface (Dispatch Interface).

• Typüberprüfung findet zur Laufzeit statt, dadurch entstehen Performanznachteile. Außerdem ist die Implementierung des Automation Controllers aufwendiger.

Automation


Arbeiten mit dem Dispatch Interface

• Die Operationsparameter müssen an Invoke in varianten Strukturen (VARIANT) verpackt übergeben werden.

• Elementare Datentypen werden unterstützt, Strings müssen als BSTR übergeben werden.

• Insbesondere stehen die Schnittstellenzeiger IUnknown und IDispatch zur Verfügung.

Automation


• Dispinterface-Aufrufe haben eine schlechte Performanz - bedingt durch das Ein- und Auspacken der Parameter.

• Wichtig für Automation-konforme Dispinterfaces:Eine Operation darf nur einen einzigen [out,retval]-Rückgabeparameter aufweisen, und dieser muss der letzte Parameter einer Operation sein.

Automation



[ object, uuid(67359BB5-2874-11D3-00C04FEDFA33), dual, helpstring(“IProjectPlanner-Schnittstelle“), pointer_default(unique)]interface IProjectPlanner : IDispatch{ [id(1)] HRESULT addProject( [in] ITask* project,

[in] short r, [in] short g, [in] short b ); [id(2)] HRESULT removeProject([in] ITask* project),

[propget, id(3)] HRESULT ProjectCardinal ([out, retval] short *pVal);

Automation



[id(4)] HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal);

// ...

};

[ uuid(67359BB6-2874-11D3-831D-00C04FEDFA33), helpstring(“ProjectPlanner Class“)]coclass ProjectPlanner{ [default] interface IProjectPlanner;

interface IPersistStorage; interface IPersistFile;

};

Automation


• Neben Dispinterface und IDispatch kann ein Automation-Server auch die “normalen” vtable-Schnittstellen veröffentlichen. Die Gesamtschnittstelle wird auch als duale Schnittstelle bezeichnet.

• Duale Schnittstellen erfordert eine Typbibliothek, damit Klienten schneller und sicherer auf ihre vtable-Schnittstelle zugreifen können.

Automation


Die Struktur einer dualen COM-Schnittstelle

Automation

Zeiger auf IProjectPlanner-vtable QueryInterface

AddRef

Release

addProject

removeProject

...

IUnknown

vtable

GetTypeInfoCount

GetTypeInfo

GetIDsOfNames

Invoke

IDispatch

IProjectPlannerDelegation


4.1.9 Komponentenkategorien

• Problem: Klient möchte eine Operation einer Komponente aufrufen, weiss aber nicht welche Komponente sie umsetzt. Dazu müsste der Klient alle verfügbaren Komponenten instaziieren und QueryInterface aufrufen.

• Lösung: Komponentenkategorien.

• Komponentenkategorien erleichtern den Austausch von Komponenten zur Laufzeit und das Hinzufügen von neuen Komponenten.

Komponentenkategorien


• Eine Kategorie wird durch eine GUID namens Category Identifier (CATID) identifiziert, sie repräsentiert eine oder mehrere Schnittstellen.

• Eine Komponente kann bekannt geben, welche Kategorien sie verbindlich unterstützt.

• Eine Komponente kann Kategorien auflisten, die im Gegenzug ein Klient unterstützen muss, damit dieser die Komponente beherbergen kann -> zB Call-Back



• Diese Informationen werden unter den Schlüsseln »Implemented Categories« und »Required Categories« unter den CLSID-Einträgen der Komponente in der Registry-Datenbank abgelegt. Eine Instanziierung einer Komponente für Tests ist nicht erforderlich.

• Der Component Category Manager gestattet die Verwaltung und Abfrage dieser Informationen über die Schnittstellen ICatRegister und ICatInformation.



4.1.10 Versionierung

• Problem nicht nur bei langlebigen Systemen: Versionierung

• COM lässt keine Versionierung zu! (»Implicit Contracts«)

• Nach der Freigabe einer Schnittstelle darf sie nicht mehr verändert werden

• Reihenfolgebedingungen dürfen nicht verletzt werden.

Versionierung


• Möchte man eine Komponente erweitern, erfordert dies eine neue Schnittstelle mit einer neuen IID.

• Die Koexistenz von bereits existierenden Klienten und Anwendungen, wird durch die lose Kopplung zwischen Komponenten und dem QueryInterface-Mechanismus ermöglicht.

• Ein Klient, der auf die neue Funktionalität angewiesen ist, erlangt den dafür nötigen Schnittstellenzeiger über die neue IID. Existierende Klienten bleiben aber von den Änderungen völlig unberührt.

• Mit der oben dargestellten Methode realisiert COM auch Polymorphie.

Versionierung


4.1.11 Containment und Aggregation

• COM unterstützt keine Implementationsvererbung zwischen Komponenten, weil diese eine Komponente eng an die Implementierung einer anderen Komponente bindet. (»fragile base class«)

• Dafür bietet COM ein alternatives Vererbungskonzept: Schnittstellenvererbung.

• Komponente muss also eigene Schnittstellen und geerbte Schnittstellen implementieren.

Containment und Aggregation


• Allerdings ist Implementationsvererbung auf Programmiersprachenebene möglich.

• ActiveX Template Libary (ATL) bietet zahlreiche Template-Klassen, die entsprechende Funktionaltäten zur Vererbung bereitstellen.

• COM bietet zwei Techniken zur Code-Wiederverwendung:

– Containment

– Aggregation



"Containment" (im Sinne von Delegation) um Implementierungen wiederzuverwenden

ClientäußeresObjekt

inneresObjekt

A B


Struktur einer Komponente bei Containment


Äußere Komponente

Interface 1

Interface 2

Innere Komponente

Interface 3

Klient


Containment

• Die äußere Komponenteninstanz erzeugt die innere Komponenteninstanz.

• Äußere Komponenteninstanz ist alleiniger Klient der inneren.

• Bei der Implementierung der inneren Komponente müssen keine Vorkehrungen getroffen werden.

• Jede Komponente kann als innere Komponente im Sinne von Containment dienen.

• Sonderfall bei Unterstützung der gleichen Schnittstelle durch äußere und innere Komponenteninstanz (-> Delegation)



Interface 1

äußere Komponente

Interface 2

Interface 3

innere Komponente

Struktur einer Komponente bei Aggregation



Aggregation• Spezialfall von Containment, dient zur Vermeinung von Containment-

Kaskaden.• Klient kann direkt auf die innere Komponenteninstanz zugreifen durch

Schnittstellenzeiger, damit kann die innere Komponenteninstanz nicht von der äußeren kontrolliert werden.

• Aggregration ist transparent für den Klient.• Innere Komponente muss vorbereitet sein

(d.h. nicht alle Komponenten sind aggregierbar).• Implementierung der inneren Komponente aufwendig, da COM-

Grundregel: 1. Jeden Schnittstellenzeiger kann man über jeden Schnittstellenzeiger ermitteln.

2. Jede Komponente hat einen eindeutigen IUnknown-Schnittstellenzeiger.



• "Containment" funktioniert mit allen COM-Objekten• Aggregation funktioniert nur mit solchen Objekten, die als "innere"

Objekte entwickelt worden sind (Referenzzähler, Funktionieren von QueryInterface)– äußeres Objekt bietet nur Schnittstelle A und IUnknown

– inneres Objekt bietet Schnittstelle B und IUnknown

– wegen der Aggregation wird Schnittstelle B nach außen sichtbar

– wenn ein Client QueryInterface auf der Schnittstelle B aufruft, dann sollte hiervon der Zähler des äußeren Objekts betroffen werden, aber wie soll das innere Objekt Kenntnis von der Schnittstelle A haben?

– Lösung: ein inneres Objekt delegiert alle Aufrufe an IUnknown an die äußeren Objekte, hierzu muss ein inneres Objekt wissen, wie es aggregiert ist.



4.1.12 Komponenten-Server

• COM sieht zwei „Verpackungsbehälter“ vor, in denen COM-Komponenten den späteren Klienten zur Verfügung gestellt werden können:

– Dynamic Link Library (DLL)

– das ausführbare Modul (EXE-Format)

• Beherbergen diese Formate COM-Komponenten, spricht man von COM-Servern.

Komponenten-Server


Prinzipielle Struktur eines COM-Servers

COM-Server

Komponente X

Fabrik für X

Komponente Y

Fabrik für Y

Server-Registrierung / -Verwaltung

Komponenten-Server


• Ein COM-DLL-Server muss die folgenden vier Einsprungpunkte (exportierte Funktionen) unterstützen:

– DllRegisterServer: Diese Funktion speichert in der Windows-Registierungsdatenbank, welche Komponente in welcher DLL untergebracht ist.

– DllUnregisterServer: Dies ist das Gegenstück zu oben genannter Funktion.

– DllGetClassObject: Diese Funktion gibt eine Schnittstellenzeiger auf die zur spezifizierten CLSID zurück.

– DllCanUnloadNow: Diese Funktion gibt dem Laufzeitsystem Auskunft, ob die DLL aus dem Hauptspeicher entfernt werden kann.

Komponenten-Server


• Ein COM-EXE-Server kann keine Funktionen wie eine DLL exportieren.

• Eine (De-) Registrierung erfolgt über Kommandozeilenargumente (/RegServer bzw. /UnRegServer)

• Ein COM-EXE-Server ist im Vergleich zu einer DLL aktiv, somit kann dieser sich selbst terminieren, wenn seine Dienste nicht mehr benötigt werden.

• Eine COM-Server-DLL bezeichnet man als In-Process-Server, da der Code der DLL in den Adressraum des aufrufenden Prozesses eingeblendet wird.

• Ein EXE-Modul läuft in einem separaten Prozess, darum nennt man dies einen Out-of-Process-Server.

• Befindet sich ein Out-of-Process-Server auf dem gleichen Rechner wie der Prozess des Klienten, bezeichnet man ihn als Local Server, ansonsten wird er Remote Server genannt.

Komponenten-Server


Marshaling und Demarshaling

• Der Zugriff auf einen In-Process-Server ist einfach, da keine Prozessgrenzen überwunden werden.

• Wird auf einen Out-of-Process-Server zugegriffen, ist Marshaling und Demarshaling notwendig.

• Marshaling bezeichnet das Verpacken der Operationsparameter für den Transport über Prozessgrenzen.

• Demarshaling ist der Vorgang des Auspackens beim Empfänger.

• Diese Vorgänge werden in den Stub und den Proxy verlagert. Stub und Proxy werden als DLL implementiert, da sie direkten Zugriff auf Komponentendaten benötigen.

• Ortstransparenz durch Stub und Proxy.

Komponenten-Server


Ortstransparenz durch Stub und Proxy

Klienten-Prozess

KlientProxyfür X

Server-Prozess

Stubfür X

Kompo-nente X

LPCoderRPC

Komponenten-Server


Proxy- bzw. Stub-DLL - Drei Wege:

• Standard Mashaling: Generierung durch MIDL-Compiler aus der IDL-Beschreibung einer Komponente in passende DLLS für Proxy und Stub

• TypeLib Mashaling: Demarshaling der Parameter benötigte Metainformationen werden aus der Typbibliothek entnommen

• Custom Marhalling: Man kann das Marhaling bzw. Demarshaling vollständig selbst in die Hand nehmen.

Komponenten-Server


Die COM-Funktion GoCreateInstance

HRESULT __stdcall GoCreateInstance(

const CLSID& rclsid,

IUnknown* pUnkOuter,

DWORD dwClsContext,

const IID& riid,

void** ppv

);

Komponenten-Server


Die CLSCTX-Konstanten

typedef enum tagCLSCTX{ CLSCTX_INPROC_SERVER = 1, CLSCTX_INPROC_HANDLER = 2, CLSCTX_LOCAL_SERVER = 4, CLSCTX_REMOTE_SERVER = 16} CLSCTX;

Komponenten-Server


4.1.13 Nebenläufigkeit

• inter-concurrency: Zugriff von mehrere Threads auf eine Komponenteninstanz.

• intra-concurrency: Bereitstellung der Komponenteninstanzen in mehreren Threads.

• COM stützt sich auf die im Betriebssystem verfügbaren Threads.

• Ältere COM-Komponenten sind nicht Thread-sicher, Kompatiblität durch Unterstützung des Apartment Model

Nebenläufigkeit


Apartment Model

• Single-threaded Apartment (STA): Komponenteninstanz verfügt über einen Thread, Aufrufe von außen werden in eine Warteschleife eingereiht.

• Implementierung einfach, aber Performanzverlust durch Marshaling/Demarshaling für Aufrufe über Apartmentgrenzen hinweg.

• Multithreaded Apartment (MTA): mehrere Threads in einem Apartment zusammengefasst, direkter Zugriff auf die Komponenteninstanz.

• Entwickler ist zuständig für die Thread-Sicherheit.

Nebenläufigkeit


• Apartment wird durch Aufrufen des entsprechende COM-Bibliotheksfunktions initialisiert

• CoInitialize: Standartmäßig STA.

• CoInitializeEx: Erlaubt die Spezifikation des Threading-Modells durch einen zusätzlichen Parameter.

• Bei In-Process-Server geschieht die Initialisierung über die Registrierungsdatenbank, da COM-Server schon die Initialisierung vorweg genommen hat.

• Im Gegensatz zu Out-of-Process-Server muss ein In-Process-Server das gleiche Threading-Model wie der Klient verwenden.

Nebenläufigkeit


4.1.14 Persistenz

• Persistenz gestattet Instanzen, ihren Zustand auf einem nichtflüchtigen Speichermedium abzulegen (z.B. Datenbank).

• Komponenteninstanz kann Prozess überleben und in einem anderen rekonstruiert werden.

• Persistenz muss explizit vom Entwickler übernommen werden.

• Clients müssen die Persistenz verwalten.

Persistenz


• Structured Storage, für Kontrolle und Steuerung stehen IPersist*-Schnittstellen zur Verfügung.

• Structured Storage aus OLE motiviert. Verbunddokument besteht aus mehreren, voneinander unabhängigen Komponenteninstanzen.

Persistenz


Structured Storage

Datei

Stream

Root Storage

Storage Storage

Stream Storage Stream Storage

Stream Stream Stream Stream

Persistenz


• Storages und Streams sind gewöhnliche COM-Komponenten.

• IStorage und IStream sind die die dazugehörigen Schnittstellen.

• Direct Mode: sämtliche Änderungen werden sofort abgespeichert.

• Transacted Mode: Änderungen werden zwischengespeichert und erst bei einem Commit persistent.

• Revert: Änderungen können verworfen werden (Rollback)



IPersist-Schnittstellen

• IPersistStream: Verwaltung der Persistenz einer Kompontente

• IPersistStreamInit: fügt eine weitere Operation hinzu, Initialisierung eines Objektes

• IPersistStorage: Verwlatung der Daten in einem Storage statt in einem Stream

• IPersistFile: Repräsentation der Schnittstellen zu einer normalen Datei („flat file“)

Persistenz


• IPersistPropertyBag: wird von ActiveX-Controls unterstützt. Das eigentliche Laden und Speichern der Daten übernimmt der Klient.

• IPersistMemory: Binärer Datenaustausch über einen gemeinsamen Speicherbereich von Klient und Komponenteninstanz.

• IPersistMoniker: Wie IPersistFile, doch die Instanzdaten werden über einen Dateinamen (Moniker) referenziert.

Persistenz


4.1.15 Monikers

• Durch Moniker können Komponenteninstanzen eindeutig benannt und später referenziert werden.

• Moniker assoziieren eine spezifische Komponenteninstanz mit einem Namen.

• Ein Moniker ist eine COM-Komponente mit der Schnittstelle IMoniker

• Wichtigste Operation ist die BindToObject

• Ein Moniker kann selbst persistente Daten enthalten, zB Name der Datei, in der der Zustand des Objektes abgespeichert ist.

Monikers


Ablauf beim Binden einer File-Moniker-Referenz

Monikers

Klient

File Moniker

"D:\Projekte\COM\Projektplan.ppl"

1. BindToObject

D:\Projekte\COM\Projektplan.ppl

2. Ermittlung der CLSID

ProjectPlanner

IMoniker

IPersistFile3. CoCreateInstance

4. Load(“D:\...\Projektplan.ppl“)

5. IProjectPlanner-Zeiger wird zurückgeliefert

IProjectPlanner


• Weitere Moniker-Typen: Item Monikers oder Composite Monikers, die für OLE relevant sind.

• Monikers können direkt von einem Klienten erzeugt werden - werden aber häufiger von der Komponenteninstanz generiert.

• Die Instanz fungiert dann als „Lieferant“ (Moniker Provider)

• Kreierung wie gewohnt über CoCreateInstance oder CreateFileMoniker

• Einbindung erfolgt idR synchron. Jedoch ist auch asynchrones Einbinden möglich über die Schnittstelle IBindStatusCallback.

Monikers


4.1.16 Verbindungspunkte

• Was tun, wenn z.B. der Server den Klienten über Änderungen seines Zustands notifizieren möchten (anstatt - wie bisher umgekehrt)?

• Lösungsansatz: bidirektionale Kommunikation

Verbindungspunkte


Bidirektionale Kommunikation mit Referenzzyklus:

• Beide Komponenteninstanzen blockieren gegenseitig die Freigabe der jeweils anderen Instanz (Referenzzyklus)

• Die Folge „Memory Leaks“ - Performanz- und Stabilitätsprobleme aller Prozesse auf dem Rechner.

Verbindungspunkte

Server-Komponenteninstanz

Klient IX

IY


Vermeidung von Referenzzyklen bei bidirektionaler Kommunikation:

Verbindungspunkte


Klient IX

IY

IYSubkomponente


• Sämtliche Aufrufe werden an den eigentlichen Klienten delegiert.

• weak reference auf die IY-Schnittstelle (Bezeichnung für Schnittstellen, deren Besitzer keinen AddRef-Aufruf (und damit keinen Release-Aufruf) ausführt.

• Referenzzyklus wird daher vermieden.

• Unterstützung jeder weiteren Schnittstelle erfordert die Duplizierung dieser Struktur, evtl. wird nur ein Klient unterstützt, Vermischung der Server-Schnittstelle mit Verwaltungsoperationen.

Verbindungspunkte


Connectable Objects• Generische Lösung für bidirektionale Kommunikation.• Serverkomponente publiziert beim Klienten benötigte Schnittstelle

(source).• Serverkomponente muss Schnittstelle IConnectionPointContainer

unterstützen.• Für jeden Outgoing Interface muss die Serverkomponente eine

Verbindungspunkt-Instanz mit der Schnittstelle IConnectionPoint liefern können.


Connectable Objects• Zentrales Element: Verbindungspunkte - eine generische Lösung für

bidirektionale Kommunikation

[ uuid(67359BB6-2874-11D3-831D-00C04FEDFA33), helpstring("ProjectPlanner Class")]coclass ProjectPlanner{ [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile; [default, source] interface IProjectPlannerClient;};

Verbindungspunkte


Einrichten eines Verbindungspunktes

Verbindungspunkte


IUnknownKlient1. QueryInterface(IConnectionPointContainer)

IConnection-PointContainer

2. FindConnectionPoint(IID_Ixyz)

ConnectionPoint für xyz

IConnectionPoint3. Advise

IUnknown3.1. QueryInterface(Ixyz)

Sink für xyzIxyz

Notifizierungen

komponentenmodelle - sose 20011 volker gruhn lehrstuhl für software-technologie universität...

Documents