Thema: Komponenten-Architektur und Komponenten-Frameworks

Größe: px

Ab Seite anzeigen:

Download "Thema: Komponenten-Architektur und Komponenten-Frameworks"

Mona Zimmermann
vor 10 Jahren
Abrufe

1 Seminar Softwaretechnik WS00/01 Softwareentwicklung mit Komponenten Veranstalter: M.Bittner, W.Koch, S. Jähnichen Thema: Komponenten-Architektur und Komponenten-Frameworks Vorträger: Dinh-Loc Hoang 1

2 Gliederung des Vortrags! Begriffe - Komponenten-System-Architektur -Komponenten-Frameworks! Eine Multilayer-Architektur mit drei Stufen! Freie vermittelte Wirkung in einer gestuften Architektur! Ein Beispiel für Komponenten-Frameworks "OpenDoc 2

3 Begriffe(1) A component system architecture consists of! a set of platform decisions,! a set of component frameworks,! an interoperation design for the component frameworks. 3

4 A component framework is An interoperation!a dedicated and design focused for architecture, component frameworks comprises the rules of interoperation among all the!usually around a few key mechanisms, frameworks joined by the system architecture. Abbildung für Komponente System Architektur!and a fixed set of policies for mechanisms at the component level. Bsp.: Architektur von OpenDoc platform WindowsNT platform Linux platform MacOS platform platform decisions (Schnittstelle) Component framework1 (second-order component framework) Interoperation design Component framework2... Component framework n (first-order component frameworks) 4

usually around a few key mechanisms, frameworks joined by the system architecture. Abbildung für Komponente System Architektur!

5 Begriffe(2) A component is a set of normally simultanceously deployed atomic components An atomic component is a module and a set of resources. A module is a set of classes and possibly non-object-oriented contructs,such as procedures or functions A resource is a collection of typed items 5

A module is a set of classes and possibly non-object-oriented

6 Hierarchie von Komponenten-Frameworks hasa component framework Bsp.: OpenDoc component component... component atomic component... atomic component module Resources 6

7 Eine gestufte Komponenten-Architektur! Komponentensysteme können hierarchisch in Schichten ( Layers ) zerlegt werden.! Jeder Teil eines Komponentensystems, auch die Komponenten selbst, können ihrerseits in Schichten zerlegt sein.! Um die Komplexität des Komponentensystem zu beherrschen, wird eine Meta- Architektur eingeführt, die die Systemarchitektur in Stufen (tiers) zerlegt, wobei die Layer-Struktur des Komponentensystems erhalten bleibt.! Komponentensysteme enthalten eine Reihe von Komponentenframeworks (second-tier architecture)! Jedes beteiligte Framework kann seinerseits aus mehren Stufen bestehen, deren unterste Stufe aus Komponenten besteht (first-tier architecture) 7

! Um die Komplexität des Komponentensystem zu beherrschen, wird eine Meta- Architektur eingeführt, die die Systemarchitektur in Stufen (tiers) zerlegt, wobei die

8 Eine Multilayer-Architektur mit drei Stufen Component framework Component Component system (Component framework framework) 8

9 Freie vermittelte Wirkung in einer gestuften Architektur CI CFI CFFI CI stands for component instance CFI for component framework instance CFFI for component system instance (or for component framework framework instance) Direkte Kommunikation (blau-blau) -COM connectable objects -Com messaging service messages -CORBA events JavaBeans evens Indirekte Kommunikation (grün-gelb-blau und gelb-gelb) -Komponentenframework als Mediator 9

instance) Direkte Kommunikation (blau-blau) -COM connectable objects -Com messaging service messages -CORBA

10 Ein Beispiel für Komponenten- Framework! OpenDoc - Einführung - Architektur - Realisierung - Kommunikation zwischen Part-Editoren - Persistenz von Parts - Verbunddokumente 10

11 OpenDoc Kurze Einführung! OpenDoc ist ein Framework zur Verwaltung von Verbunddokumenten (compound documents).! Verbunddokumente haben verschiedene Darstellungsarten wie Text, Graphik, Bilder, Videos, Klänge! Zugriff auf Verbunddokumente direkt ohne den Umweg über ein weiteres, ausserhalb von OpenDoc liegendes Programm 11

12 OpenDoc Architektur(1) Von der Document Shell erzeugte Objekte: Document Shell erzeugt Session Object erzeugt OpenDoc Services Root Part für jedes Dokument 12

13 OpenDoc Architektur(2) Aufgaben der Document Shell:! Erzeugen eines Session-Objekts,! Öffnen bzw. Erzeugen von Dokumenten, d.h. eines Root Parts, i. allg. als Container, der weitere Parts enthalten kann.! Laden der Part-Editoren und deren Integration in das OpenDoc-System,! Entgegennehmen und Weiterleiten von Ereignissen! Verwaltung globaler Variablen. 13

als Container, der weitere Parts enthalten kann.

14 OpenDoc Architektur(3) Struktur je Dokument: Compound Document Management Strutured Storage (Bento) Uniform Data Transfer Automation & Scripting Part Editor... Part Editor Session Dokument Shell 14

15 OpenDoc Realisierung! SOM (System Object Model) als Basis von OpenDoc -SOM ist ein CORBA-konformer ORB (Object Request Broker) -Beschreibung der Schnittstelle zu SOM in SOMs IDL -Alle OpenDoc-Services, Part-Editoren etc. sind als shared libraries realisiert! Der Aufbau von Part-Editoren -Methoden und ihre Funktionalität für die Realisierung: Drag&Drop, Embedding, Frames, Facet, Containing Parts, Binding, UserInteraction-Events, Methoden reichen aus, um die Zusammenarbeit eines Part-Editors mit OpenDoc zu realisieren.! Erweiterung bestehender Parts durch Vererbung -Für den Einsatz von Parts genügt es, über die IDLs und die shared libralies der Parts zu verfügen. -SOMs IDL unterstützt Mehrfachvererbung, was die Entwicklung neuer Parts oftmals erleichtert 15

Part-Editoren etc. sind als shared libraries realisiert!

16 OpenDoc Kommunikation zwischen Part-Editoren(1) Event-Verarbeitung in OpenDoc Part Editor1 Part Editor1... Part Editor1 Dokument Shell Dispatcher Arbitrator Interne Verarbeitung Ereignis Betriebssystem 16

17 OpenDoc Kommunikation zwischen Part-Editoren(2)! Extensionen -Erweitern von Part-Editoren um zusätzliche Funktionalität -Extensionen zum programmgesteuerten Datenaustausch zwischen Part- Editoren. -Kennzeichnung jeder Extension durch einen category name. -Private Extensionen und öffentliche Extensionen. -Nutzung von Extensionen eines anderen Part-Editors! Nachrichtenaustausch-Semantic Events -Verwendung von Semantic Events für die Kommunikation zwischen Parts. -für Kommunikation zwischen verschiedenen Dokumenten auf verschiedenen Rechnern. 17

Part- Editoren. -Kennzeichnung jeder Extension durch einen category name. -Private Extensionen und öffentliche Extensionen.

18 OpenDoc Kommunikation zwischen Part-Editoren(3)! Empfang und Verarbeitung von Semantic Events -Erzeugung folgender Objekten durch Verarbeitung bestimmten Semantic Events:. Semantic Interface,. Helper-Objekt -Initialisierung der Event Handler- und Accessor-Funktionen! Senden von Semantic Events -Message Interface -OpenDoc stellt Methoden zum Erzeugen und Senden von Nachrichten und zur Adressierung der Ziel-Objekte zur Verfügung. 18

19 OpenDoc Persistenz von Parts(1) Ein Storage DraftUnits sind die Objekte, in denen die Ein Objekt der Storage System Daten spiegelt der den einzelnen Entwicklungsstand Parts-Editoren des abgelegt sind Dokuments ist die zu zentrale einem Instanz bestimmten zur Steuerung Zeitpunkt dokumentiert von Speichersystem somit die Bento Entstehungsgeschichte des Dokuments verwaltet eine Liste von Container- realisiert Objekten eine Versionsverwaltung OpenDocs Speichersystem ( Bento) : Struktur von Bento Storage System Container Container Container Container Container Dokument Dokument Draft Draft Draft Storage Unit Storage Unit Storage Unit 19

Speichersystem somit die Bento Entstehungsgeschichte des Dokuments verwaltet eine Liste von Container- realisiert Objekten eine Versionsverwaltung OpenDocs

20 OpenDoc Persistenz von Parts(2)! Aufbau von Storage Units -Identifizieren jeder Storage Unit über eine 32 Bit Nummer und -Innerhalb des Dokuments eindeutig. -Ablegung der Daten in Storage Units in Properties (Property-Liste) -Properties : Daten, Meta-Daten oder Verweise auf andere Storage Units! Nutzung von Storage Units zur Speicherung von Objekt-Daten -Keine Einschränkungen über Art, Anzahl und Wertebereich von Properties 20

21 OpenDoc Verbunddokumente Realisierung von Verbunddokumenten Part Frame Facet Canvas Shape Dokumentbezogene Sicht... Fensterbezogene Sicht 21

22 BlackBox versus OpenDoc (1) Ähnlichkeit:! Beides sind Komponenten-Frameworks meistens für visuelle Komponenten.! Beide haben Konzept des containers und recursive embedding.! Beide haben Konzept des compound documents.! Ähnlich bei der Modellierung des Compound-documents: BlackBox: views, contexts, frames, port riders and ports OpenDoc: parts, frames, facets, shapes and canvases Aber Einschränkung:! BackBox weniger komplex als OpenDoc " nur Unterstützung eines restriktiven Dokumenten-Modells. (z. B.: Es gibt keine allgemeine Unterstützung für die Versionierung des Dokuments, keine allg. Objektreferenzierung) 22

23 BlackBox versus OpenDoc (2)! BlackBox ist umfassender als OpenDoc: es hat eine vollständig integrierte Entwicklungsumgebung! Bei BlackBox ist eine auf Component Pascal basierte Umgebung, Nutzung umfasst: -performmance-critical low-level programming, -interfacing to external platform-specific dynamic link libraries, -implementation of new components, -scripting 23

Ähnliche Dokumente

Java Enterprise Architekturen Willkommen in der Realität

Java Enterprise Architekturen Willkommen in der Realität Ralf Degner ([email protected]), Dr. Frank Griffel ([email protected]) Techniker Krankenkasse Häufig werden Mehrschichtarchitekturen