Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Komponentenmodelle - SoSe 20011 Volker Gruhn Lehrstuhl für Software-Technologie Universität Dortmund

Ähnliche Präsentationen


Präsentation zum Thema: "Komponentenmodelle - SoSe 20011 Volker Gruhn Lehrstuhl für Software-Technologie Universität Dortmund"—  Präsentation transkript:

1 Komponentenmodelle - SoSe Volker Gruhn Lehrstuhl für Software-Technologie Universität Dortmund Komponentenmodelle

2 Komponentenmodelle - SoSe By 1999, component software will be the dominant method of new application development Gartner Group 1997

3 Komponentenmodelle - SoSe 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.

4 Komponentenmodelle - SoSe Gliederung Einleitung Teil I - Motivation, Grundlagen, Beispielanwendung Motivation für komponentenbasierte Softwareentwicklung Migration zu komponentenbasierten Anwendungsarchitekturen Vorstellung der Beispielanwendung Gliederung

5 Komponentenmodelle - SoSe Teil II - Die Umsetzung der Szenarien DCOM-Szenario JavaBeans/CORBA-Szenario JavaBeans/Enterprise-JavaBeans-Szenario Teil III Vergleich und Ergebnisse Zusammenfassender Vergleich Gliederung

6 Komponentenmodelle - SoSe 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

7 Komponentenmodelle - SoSe Etablierung von Standards - sogenannter Komponentenmodelle: –DCOM –JavaBeans –Enterprise JavaBeans Vor- und Nachteile der Komponentenmodelle werden aufgeführt –durch theoretische Erörterungen –durch Beispielanwendungen Einleitung

8 Komponentenmodelle - SoSe 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.... Begriffsdefinitionen

9 Komponentenmodelle - SoSe 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. Begriffsdefinitionen

10 Komponentenmodelle - SoSe 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.« Begriffsdefinitionen

11 Komponentenmodelle - SoSe 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. Begriffsdefinitionen

12 Komponentenmodelle - SoSe Metamodell der zentralen Begriffe: Begriffsdefinitionen

13 Komponentenmodelle - SoSe TEIL 1 Motivation, Grundlagen, Beispielanwendung 1 Motivation für komponentenbasierte Softwareentwicklung 2 Migration zu komponentenbasierten Anwendungsarchitekturen 3 Beispielanwendung Motivation

14 Komponentenmodelle - SoSe Motivation für komponentenbasierte Softwareentwicklung 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

15 Komponentenmodelle - SoSe Motivation für komponentenbasierte Softwareentwicklung 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

16 Komponentenmodelle - SoSe 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

17 Komponentenmodelle - SoSe 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

18 Komponentenmodelle - SoSe 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

19 Komponentenmodelle - SoSe Motivation

20 Komponentenmodelle - SoSe Motivation Anwendungsnahe Bausteine –Ziel: Bereitstellung von Abstraktionen, die für den Anwendungsentwickler relevant sind –Grundlage für zahlreiche Innovationen in der Softwareentwicklung

21 Komponentenmodelle - SoSe Motivation

22 Komponentenmodelle - SoSe 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

23 Komponentenmodelle - SoSe 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)

24 Komponentenmodelle - SoSe 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

25 Komponentenmodelle - SoSe 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

26 Komponentenmodelle - SoSe Motivation Verwirklichung dieser Ziele –Anstrebung einer Reihe untergeordneter technischer Ziele: Strukturvorteile objektorientierter Softwaresysteme auf der Ebene des Programmieren im Großen

27 Komponentenmodelle - SoSe Motivation Angestrebte Komponenteneigenschaften –Wohldefinierter Zweck –Kontextunabhängigkeit –Portabilität und Programmiersprachenunabhängigkeit –Ortstransparenz –Trennung von Schnittstelle und Implementierung –Selbstbeschreibungsfähigkeit

28 Komponentenmodelle - SoSe Motivation Angestrebte Komponenteneigenschaften –Sofortige Einsatzbereitschaft (plug&play) –Integrations- und Kompositionsfähigkeit –Wiederverwendbarkeit –Konfigurierbarkeit, Anpassbarkeit –Bewährtheit –Binärcode-Verfügbarkeit

29 Komponentenmodelle - SoSe 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

30 Komponentenmodelle - SoSe Motivation Wiederverwendung - Häufigkeit und Nutzen:

31 Komponentenmodelle - SoSe Motivation Wiederverwendung entsteht nicht von alleine! Wiederverwendung entsteht nicht adhoc! Wiederverwendung erfordert eine Investitionsentscheidung! Wiederverwendung erfordert ein Budget!

32 Komponentenmodelle - SoSe

33 Komponentenmodelle - SoSe 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

34 Komponentenmodelle - SoSe –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.

35 Komponentenmodelle - SoSe 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

36 Komponentenmodelle - SoSe 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).

37 Komponentenmodelle - SoSe 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!

38 Komponentenmodelle - SoSe Kosten/Nutzen-Relation der Wiederverwendung [Bal96]

39 Komponentenmodelle - SoSe Potentielle Hindernisse bei 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

40 Komponentenmodelle - SoSe 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

41 Komponentenmodelle - SoSe 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)

42 Komponentenmodelle - SoSe 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.

43 Komponentenmodelle - SoSe 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

44 Komponentenmodelle - SoSe Motivation Komponentenbasierte Softwaresysteme mit verschiedenen Komponentenarten eigenentwickelte Komponente zugekaufte Komponente Wrapped Komponente

45 Komponentenmodelle - SoSe 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

46 Komponentenmodelle - SoSe 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]

47 Komponentenmodelle - SoSe 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]

48 Komponentenmodelle - SoSe 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

49 Komponentenmodelle - SoSe 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

50 Komponentenmodelle - SoSe Motivation Erst mal zu einem groben Objektmodell

51 Komponentenmodelle - SoSe Motivation Vergröberung eines Objektmodells zu fachlichen Komponenten PartnerLokationObjekt Schaden / Leistung Vertrieb BuchhaltungVertrag Produkt/Tarif Versicherungs- Vertrag

52 Komponentenmodelle - SoSe Motivation Von den fachlichen Komponenten zu technischen Komponenten

53 Komponentenmodelle - SoSe 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

54 Komponentenmodelle - SoSe Motivation Unterscheidung von Client-Komponenten / Server-Komponenten Client-Komponenten realisieren Benutzungsoberflächen Server-Komponenten realisieren die Geschäftsobjekte Direktgeschäft Außendienst Innendienst Web Browser und Applets Java Anwendung Web Server Applikationsserver mit Geschäftsobjekten (GO) GO

55 Komponentenmodelle - SoSe 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!

56 Komponentenmodelle - SoSe 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

57 Komponentenmodelle - SoSe Motivation Das Zusammenspiel von Komponenten, Komponentenmodellen, Frameworks und Middleware-Systemen Komponentenmodell konkrete Komponenten konkrete Komponenten Framework Entwicklungswerkzeuge komponentenbasierte Anwendungen komponentenbasierte Anwendungen Middleware müssen zueinander passen werden benutzt für sind Grundlagen für Komponenten sind Grundlage für werden betrieben in Software architektur Software architektur

58 Komponentenmodelle - SoSe 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

59 Komponentenmodelle - SoSe 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

60 Komponentenmodelle - SoSe 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

61 Komponentenmodelle - SoSe Migration 6 Auswahl von Produkten 7 Pilotprojekte 5 Definition/Anpassung des Entwicklungsprozesses 1 Ist-Analyse 2 Definition fachliche Architektur 3 Definition softwaretechnische Architektur 8 Einführung 4 Definition systemtechnische Architektur

62 Komponentenmodelle - SoSe 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

63 Komponentenmodelle - SoSe 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

64 Komponentenmodelle - SoSe –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

65 Komponentenmodelle - SoSe 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

66 Komponentenmodelle - SoSe 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

67 Komponentenmodelle - SoSe 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

68 Komponentenmodelle - SoSe Beispiel für eine ACDL-Spezifikation einer Komponente Migration KomponenteOrt IdentifikatorfachlichK-02 VerantwortlicherDirk Platz, adesso Komponenten-ObjektmodellKomponenten der fachlichen Klassen Version 1.7 Komponenten RolleServer Verwendete Komponenten- Aufrufende Komponenten(fachlichK-03, Objekt), (fachlichK-04, SchadenLeistung), (fachlich-08, Vertrag) ServiceLokationsVerwaltung Service-IdentifikatorfachlichS-02 KurzbeschreibungBeschreibt alle für eine Versicherung sinnvollen Orte und Streckenangaben. LangbeschreibungEs wird ein Ort, eine Strecke oder eine Route und deren Beziehungen zueinander beschrieben. Ein Ort kann eine postalische Adresse oder eine Service-FunktionPostalischeAdresseErzeugen KurzbeschreibungEine postalische Adresse anlegen. LangbeschreibungDie Stammdaten einer postalischen Adresse werden angelegt,indem über die Service-FunktionPostalischeAdresseLiefern KurzbeschreibungEine postalisch Komponente Komponentenspezifikation Service Service-Funktion Komponentenrealisierung Interface Methode Beispiel für eine ACDL-Spezifikation einer Komponente

69 Komponentenmodelle - SoSe 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

70 Komponentenmodelle - SoSe 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ätPerformanz StrukturierungIntegrierbarkeit ModularitätSkalierbarkeit AbstraktionRobustheit Änderbarkeit Allgemeinheit Inkrementalität Migration

71 Komponentenmodelle - SoSe Definition der softwaretechnischen Architektur Konkrete Ergänzungen der softwaretechnischen Architektur, um Anbindung an Oberflächen Anbindung an Persistenzschicht Wrapper / Integrationskomponenten Normalierung / Denormalisierung Entwurfsmuster Migration

72 Komponentenmodelle - SoSe 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

73 Komponentenmodelle - SoSe 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

74 Komponentenmodelle - SoSe Übersicht Systementwicklung Migration Systemanalyse Systementwurf Systemintegration Überleitung in die Nutzung SE 4-7: Client - Komponentenentwicklung Zusammenbau der Komponenten zum Gesamtsystem Server- Komponentenentwicklung Unabhängige Entwicklung von Server-Komponenten Beschreibung des Systems aus Anwendersicht Zerlegung des Systems inKomponenten, Spezifikation der Leistungen der Komponenten Unabhängige Entwicklung vonClient-Komponenten Server- Komponentenentwicklung

75 Komponentenmodelle - SoSe 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

76 Komponentenmodelle - SoSe 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

77 Komponentenmodelle - SoSe 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

78 Komponentenmodelle - SoSe 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

79 Komponentenmodelle - SoSe 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

80 Komponentenmodelle - SoSe 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

81 Komponentenmodelle - SoSe 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

82 Komponentenmodelle - SoSe 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

83 Komponentenmodelle - SoSe »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

84 Komponentenmodelle - SoSe 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

85 Komponentenmodelle - SoSe 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

86 Komponentenmodelle - SoSe Einführung Umsetzen des neuen Prozesses (inklusive der neuen Organisation) Risiko-Management Klare Projektstrukturen (inklusive klarer Eskalationswege) Unterstützung durch das Top-Management Migration

87 Komponentenmodelle - SoSe 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?

88 Komponentenmodelle - SoSe 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

89 Komponentenmodelle - SoSe Use-Case-Diagramm der Beispielanwendung Beispielanwendung DecideOnPro- jectAcceptance ResourcePlanning DefineProject Structure Controlling VetoChanges AcceptChanges EnterAbsenceTime «extend» ViewToDoList «extend» ManagerDeveloper TimeAdjustment TimeRecording «extend»

90 Komponentenmodelle - SoSe 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

91 Komponentenmodelle - SoSe 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

92 Komponentenmodelle - SoSe Gantt-Diagramm für projektübergreifende Ressourcenzuordnung Beispielanwendung Müller Meier KW 16KW 17KW 18 Schmidt Task1 Task14 Task15 Task16Task5.3 UrlaubTask16

93 Komponentenmodelle - SoSe 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

94 Komponentenmodelle - SoSe 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

95 Komponentenmodelle - SoSe 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

96 Komponentenmodelle - SoSe Analysemodell der Beispielanwendung Beispielanwendung

97 Komponentenmodelle - SoSe 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

98 Komponentenmodelle - SoSe 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

99 Komponentenmodelle - SoSe KAPITEL 4: DCOM-Szenario 4.1 COM Übersicht 4.2 Übergang zu DCOM 4.3 Anwendung auf das Beispiel

100 Komponentenmodelle - SoSe KAPITEL 4.1: COM Übersicht Historie Was ist COM Schnittstellen Referenzzählung Erzeugen von Komponenteninstanzen GUID IDL Automation Komponentenkategorien Versionierung Containment und Aggregation Komponenten-Server Nebenläufigkeit Persistenz Monikers Verbindungspunkte ATL

101 Komponentenmodelle - SoSe 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

102 Komponentenmodelle - SoSe COM-Übersicht Die historische Entwicklung von COM

103 Komponentenmodelle - SoSe 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

104 Komponentenmodelle - SoSe 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

105 Komponentenmodelle - SoSe 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

106 Komponentenmodelle - SoSe /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

107 Komponentenmodelle - SoSe 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

108 Komponentenmodelle - SoSe 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

109 Komponentenmodelle - SoSe 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?

110 Komponentenmodelle - SoSe 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?

111 Komponentenmodelle - SoSe 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

112 Komponentenmodelle - SoSe 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 ); ULONGAddRef( ); ULONGRelease( ); } Schnittstellen

113 Komponentenmodelle - SoSe 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

114 Komponentenmodelle - SoSe 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

115 Komponentenmodelle - SoSe Grafische Darstellung einer Komponente mit Ihren Schnittstellen ProjectPlanner IUnknown IPersistFile IPersistStorage IProjectPlanner Schnittstellen

116 Komponentenmodelle - SoSe 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

117 Komponentenmodelle - SoSe 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 IProjectPlanner aufrufen. Schnittstellen

118 Komponentenmodelle - SoSe 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. Die Umsetzung der Szenarien

119 Komponentenmodelle - SoSe 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 ) Schnittstellen

120 Komponentenmodelle - SoSe 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

121 Komponentenmodelle - SoSe C++-Deklaration der ProjectPlanner-Komponente class CProjectPlanner : public IProjectPlanner, public IPersistFile, public IPersistStorage { public: HRESULT __stdcall QueryInterface(const IID& iid, void** ppv); //... }; Schnittstellen

122 Komponentenmodelle - SoSe Speicherstruktur der ProjectPlanner-Komponente Schnittstellen CProjectPlanner Zeiger auf IProjectPlanner- vtable Zeiger auf IPersistFile- vtable Zeiger auf IPersistStorage- vtable Instanz-Daten von C ProjectPlanner QueryInterface AddRef Release addProject removeProject... IProjectPlanner QueryInterface AddRef Release GetClassID IsDirty... IPersistFile QueryInterface... IPersistStorage vtable

123 Komponentenmodelle - SoSe 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

124 Komponentenmodelle - SoSe 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. Die Umsetzung der Szenarien

125 Komponentenmodelle - SoSe 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

126 Komponentenmodelle - SoSe 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

127 Komponentenmodelle - SoSe 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

128 Komponentenmodelle - SoSe 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

129 Komponentenmodelle - SoSe 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

130 Komponentenmodelle - SoSe Die COM-Funktion GoGetClassObject HRESULT __stdcall GoGetClassObject( const CLSiD& clsid, DWORD dwClsContext, CONSERVERINFO* pServerInfo, const IID& iid, void** ppv ); Referenzzählung

131 Komponentenmodelle - SoSe 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

132 Komponentenmodelle - SoSe Die COM-Funktion GoCreateInstance HRESULT __stdcall GoCreateInstance( const CLSID& rclsid, IUnknown* pUnkOuter, DWORD dwClsContext, const IID& riid, void** ppv ); Referenzzählung

133 Komponentenmodelle - SoSe 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 ). 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

134 Komponentenmodelle - SoSe 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

135 Komponentenmodelle - SoSe 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 zählt). 4 Bits enthalten die GUID-Versionsnummer. 16 Bits werden anhand der Systemzeit berechnet (um Eindeutigkeit bei schnell hintereinander erzeugten GUID-Werten sicherzustellen).

136 Komponentenmodelle - SoSe 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

137 Komponentenmodelle - SoSe 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

138 Komponentenmodelle - SoSe 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

139 Komponentenmodelle - SoSe MIDL-Auszug für die ProjectPlanner-Komponente (1/2) [ object, uuid(67359BB D3-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

140 Komponentenmodelle - SoSe MIDL-Auszug für die ProjectPlanner-Komponente (2/2) [id(4)] HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal); //... }; [ uuid(67359BB D3-831D-00C04FEDFA33), helpstring(ProjectPlanner Class) ] coclass ProjectPlanner { [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile; }; IDL

141 Komponentenmodelle - SoSe Aufgaben der IDL-Dateien Dokumentation von Komponenten und Schnittstellen Automatisches Generieren der Proxy und der Stub Kompilieren in so genannte Typbibliotheken IDL

142 Komponentenmodelle - SoSe 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

143 Komponentenmodelle - SoSe 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

144 Komponentenmodelle - SoSe 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

145 Komponentenmodelle - SoSe 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

146 Komponentenmodelle - SoSe MIDL-Auszug für die ProjectPlanner-Komponente (1/2) [ object, uuid(67359BB D3-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

147 Komponentenmodelle - SoSe MIDL-Auszug für die ProjectPlanner-Komponente (2/2) [id(4)] HRESULT get_ProjectAt([in] short index, [out, retval] ITask* *pVal); //... }; [ uuid(67359BB D3-831D-00C04FEDFA33), helpstring(ProjectPlanner Class) ] coclass ProjectPlanner { [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile; }; Automation

148 Komponentenmodelle - SoSe 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

149 Komponentenmodelle - SoSe Die Struktur einer dualen COM-Schnittstelle Automation Zeiger auf IProjectPlanner- vtable QueryInterface AddRef Release addProject removeProject... IUnknown vtable GetTypeInfoCount GetTypeInfo GetIDsOfNames Invoke IDispatch IProjectPlanner Delegation

150 Komponentenmodelle - SoSe 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

151 Komponentenmodelle - SoSe 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 Komponentenkategorien

152 Komponentenmodelle - SoSe 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. Komponentenkategorien

153 Komponentenmodelle - SoSe 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

154 Komponentenmodelle - SoSe 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

155 Komponentenmodelle - SoSe 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

156 Komponentenmodelle - SoSe 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 und Aggregation

157 Komponentenmodelle - SoSe "Containment" (im Sinne von Delegation) um Implementierungen wiederzuverwenden Client äußeres Objekt inneres Objekt AB

158 Komponentenmodelle - SoSe Struktur einer Komponente bei Containment Containment und Aggregation Äußere Komponente Interface 1 Interface 2 Innere Komponente Interface 3 Klient

159 Komponentenmodelle - SoSe 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) Containment und Aggregation

160 Komponentenmodelle - SoSe Interface 1 äußere Komponente Interface 2 Interface 3 innere Komponente Struktur einer Komponente bei Aggregation Containment und Aggregation

161 Komponentenmodelle - SoSe 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 und Aggregation

162 Komponentenmodelle - SoSe "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. Containment und Aggregation

163 Komponentenmodelle - SoSe 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

164 Komponentenmodelle - SoSe Prinzipielle Struktur eines COM-Servers COM-Server Komponente X Fabrik für X Komponente Y Fabrik für Y Server-Registrierung / -Verwaltung Komponenten-Server

165 Komponentenmodelle - SoSe 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

166 Komponentenmodelle - SoSe 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

167 Komponentenmodelle - SoSe 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

168 Komponentenmodelle - SoSe Ortstransparenz durch Stub und Proxy Klienten-Prozess Klient Proxy für X Server-Prozess Stub für X Kompo- nente X LPC oder RPC Komponenten-Server

169 Komponentenmodelle - SoSe 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

170 Komponentenmodelle - SoSe Die COM-Funktion GoCreateInstance HRESULT __stdcall GoCreateInstance( const CLSID& rclsid, IUnknown* pUnkOuter, DWORD dwClsContext, const IID& riid, void** ppv ); Komponenten-Server

171 Komponentenmodelle - SoSe 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

172 Komponentenmodelle - SoSe 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

173 Komponentenmodelle - SoSe 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

174 Komponentenmodelle - SoSe 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

175 Komponentenmodelle - SoSe 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

176 Komponentenmodelle - SoSe 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

177 Komponentenmodelle - SoSe Structured Storage Datei Stream Root Storage Storage Stream Storage Stream Storage Stream Persistenz

178 Komponentenmodelle - SoSe 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) Die Umsetzung der Szenarien

179 Komponentenmodelle - SoSe 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

180 Komponentenmodelle - SoSe 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

181 Komponentenmodelle - SoSe 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

182 Komponentenmodelle - SoSe 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 IPersistFile 3. CoCreateInstance 4. Load(D:\...\Projektplan.ppl) 5. IProjectPlanner-Zeiger wird zurückgeliefert IProjectPlanner

183 Komponentenmodelle - SoSe 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

184 Komponentenmodelle - SoSe 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

185 Komponentenmodelle - SoSe 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

186 Komponentenmodelle - SoSe Vermeidung von Referenzzyklen bei bidirektionaler Kommunikation: Verbindungspunkte Server- Komponenteninstanz Klient IX IY Subkomponente

187 Komponentenmodelle - SoSe 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

188 Komponentenmodelle - SoSe 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.

189 Komponentenmodelle - SoSe Connectable Objects Zentrales Element: Verbindungspunkte - eine generische Lösung für bidirektionale Kommunikation [ uuid(67359BB D3-831D-00C04FEDFA33), helpstring("ProjectPlanner Class") ] coclass ProjectPlanner { [default] interface IProjectPlanner; interface IPersistStorage; interface IPersistFile; [default, source] interface IProjectPlannerClient; }; Verbindungspunkte

190 Komponentenmodelle - SoSe Einrichten eines Verbindungspunktes Verbindungspunkte Server- Komponenteninstanz IUnknown Klient 1. QueryInterface( IConnectionPointContainer) IConnection- PointContainer 2. FindConnectionPoint (IID_Ixyz) Connection Point für xyz IConnectionPoint 3. Advise IUnknown 3.1. QueryInterface(Ixyz) Sink für xyz Ixyz Notifizierungen


Herunterladen ppt "Komponentenmodelle - SoSe 20011 Volker Gruhn Lehrstuhl für Software-Technologie Universität Dortmund"

Ähnliche Präsentationen


Google-Anzeigen