Komponentenbasierte Software-Entwicklung

Ein erster Überblick

Praxisseminar SS 02 Klaus-Peter Löhr

Karsten Otto

Entwicklungsaufwand verringern!Qualität verbessern!

Qualifizierung Automatisierung Wiederverwendung .......der Entwickler

Entwürfe Spezifikationen Code .....

Module/Klassen Rahmenwerke „Komponenten“aus Bibliotheken

„Komponentenbasierte Entwicklung“ (Neu- oder Weiterentwicklung)

System wird durch Anpassung und Zusammenbaubereits vorhandener Softwarekomponenten konstruiert.

Aufwand:

- Auffinden geeigneter Komponenten

- Anpassung (z.B. Parametrisierung)

- Entwicklung fehlender Komponenten

- Zusammenbau

Idealerweise: schnelles Zusammenstöpseln statt

aufwendigen Programmierens !

Beliebtes Beispiel: Datenfluß-Architekturen

wie etwa die Pipeline in der Unix Shell:

trans | grep $1 | sort System aus3 Komponenten

Allgemeine Situation in abstrakter Sicht:

System

Kitt (glue) neue Komponenten

„Komponente“ ?

Exemplar eines (evtl. parametrisierten) Komponententyps

(component instance vs. component/component type)

„Kitt“ ?

Vereinbarung der Architektur des Systems, d.h.

- Angabe der Komponenten und ihrer Typen

- Festlegung der Interaktion zwischen ihnen

(graphisch oft durch Konnektoren dargestellt)

mittels geeigneter formaler Sprache

(Programmiersprache, Skriptsprache, Koordinationssprache,Architekturbeschreibungssprache, graphische Sprache, .....)

trans | grep $1 | sort

Konnektor

abstrakt –

grün =Datenflußstil

konkreteArchitektur –

Konnektor = Kanal

Code

Fundamentale Konstruktionsprinzipien

Kapselung, Autarkie, Rekursivität

Kapselung: Funktionalität einer Komponente ist durch Schnittstelle,Spezifikation und Parameter des Komponententypserschöpfend beschrieben

Autarkie: Eine Komponente ist für die Erbringung ihrer Funktio-nalität (möglichst) nicht auf die Mitwirkung anderer Komponenten angewiesen

Rekursivität:

Rekursivität:

System ist selbst wiederum als gekapselter Komponententypbei der Komposition eines größeren Systems verwendbar

„Subsystem“ = komponierte Komponente

kein konzeptioneller Unterschied zwischen „Programmieren im Kleinen“, „... im Großen“

„Architekturstil“ = „Programmierparadigma“

Standards für Komponenten

erleichtern Komposition (kein „architectural mismatch“)

ermöglichen Komponenten-Industrie(COTS – „components off the shelf“)

sind von hoher Komplexität

können schnell obsolet werden

. . . und es gibt nicht den einen Standard

Typische Eigenschaften standardisierter Komponentenmodelle:

vom Anwender einstellbare Parameter, properties, attributes, ...erlauben gewisse Modifikationen des Verhaltens

objektorientierte Schnittstellen erlauben Aufrufe von Operationen,die gewisse Dienste erbringen (supplied interfaces)

zur Funktionalität kann der Aufruf anderer Komponenten mitgeforderten Schnittstellen gehören (required interfaces)

ereignisbasierte Interaktion zusätzlich zur aufrufbasiertenInteraktion

Ausführungsumgebung mit bestimmter Funktionalität erforderlich(container)

Verteilung mit Fernaufrufen und Fernsignalisierung

Packaging und Deployment

Beispiel JavaBeans

„kleine“ Java-Objekte gemäß bestimmten Konventionen

hauptsächlich GUI-Elemente für die Konstruktion graphischer

Benutzerschnittstellen:

Properties bestimmen Aussehen der Elemente,

Ereignis (Taste/Maus) bei einem Element löst Ereignisbehandlung aus – Aufruf eines Listeners

mit Unterstützung durch entsprechende Entwicklungssysteme

(VisualAge, JBuilder, NetBeans, ...)

Beispiel COM/DCOM

(Microsoft)

Windows-Objekte:

sprachunabhängiger, binärer „Standard“ für Objektschnittstellen

COM – Component Object Model:

sprachunabhängige Klassen als Binärcode

in DLL- oder EXE-Dateien; lokale Fernaufrufe;

Basis für OLE – Object Linking and Embedding

DCOM – Distributed COM:

Objekterzeugung und –benutzung auch stationsübergreifend:

echte Fernaufrufe

Windows-Objekte

Binäre Konventionen für Objekte mit einer oder mehreren Schnittstellen:

Jedes Objekt ist über ein ausgezeichnetes Schnittstellenobjekt (!)mit Schnittstelle IUnknown erreichbar.

Objekt ist möglicherweise über weitere Schnittstellenobjekte erreichbar;deren Schnittstellen sind Erweiterungen von IUnknown.

Binäre Repräsentation eines Schnittstellenobjekts (Beispiel IPersist):

Daten

QueryInterface

AddRef

Release

GetClassID

„vtable“

Darstellung eines Objekts mit Schnittstellen:IUnknown

IPersist . . . .

SchnittstelleIUnknown

! Einzuhalten von OO-Übersetzer (und C-Programmierer!)

COM - Component Object Model

Klasse = Binärcode für Objekterzeugung, identifiziert durch CLSID

Zuordnung zwischen CLSID und Code-Datei(en)

- DLL oder EXE - ist im Windows Registry vermerkt.

Datei kann Code für mehrere Klassen enthalten.

Class Object / Class Factory = Fabrikobjekt,

das erzeugt werden muß, bevor mit seiner Hilfe

Objekte der zugehörigen Klasse erzeugt werden können

DCOM - Distributed COM

= COM + echte Fernaufrufe + Sicherheit + Threading ( NT Servers)

Fernaufrufe: - benutzen DCE RPC,

- at-most-once-Fehlersemantik,

- Orphan Detection

Fernerzeugung einer Objektfabrik ist möglich, wenn im lokalen Registry

unter clsid ein entsprechender Eintrag steht, mit Daten

RemoteServerName = Stationsname oder –adresse

ActivateAtStorage = "Y" oder "N" (für Aktivierung persistenter Objekte)

Codes von Klassen und Klienten sind ortstransparent!

Beispiel Microsoft .NET

.NET Framework =

CLR – Common Language Runtime

ist objektorientierte virtuelle Maschine für Ausführung von „managed code“

Reichhaltige Klassenbibliotheken für die CLR

C# als „typische“ Sprache für die CLR

Neugestaltete Web-Unterstützung: ASP.NET,

Web Services, ...

„ .NET Components“ ?

Übersetzer erzeugen nicht nur Code, sondern auch beigepackte

Metadaten - Versionsnummern,

- Schnittstellenbeschreibungen,

- . . .(hilfreich ist Disassembler ildasm)

Zusammengehörige Code-Dateien können zu einer größeren

Baugruppe (assembly) zusammengefaßt werden, die mit einer

Bekanntmachung (manifest) beschrieben wird, die u.a.

Versionsnummern und externe Bezugnahmen enthält.

Die Baugruppe ist die Einheit von Versionierung, Vertrieb und Installation.