Software aus Komponenten - Systeme, Adaptionen und Probleme Dr. Welf Löwe und Markus Noga Lehrstuhl Prof. Goos Institut für Programmstrukturen Universität

Software aus Komponenten -Systeme, Adaptionen und Probleme

Dr. Welf Löwe und Markus Noga

Lehrstuhl Prof. GoosInstitut für Programmstrukturen

Universität Karlsruhe

http://i44www.info.uni-karlsruhe.de/

http://www.uni-karlsruhe.de/

Dr. Welf Löwe und Markus Noga 2

Gliederung: Teil I - Grundlagen

Einführung– Motivation– Definition, – Konzepte für Komponenten (klassische, kommerzielle, akademische)

Industrielle Komponentensysteme der 1. Generation– CORBA – (D)COM – Enterprise JavaBeans

Anpassungsprobleme – Daten und Funktion– Interaktion

• Kommunikation• Synchronisation• Protokolle

– Lebendigkeit




Teil II – Weiterführende Konzepte

Lösung der Anpassungsprobleme (aus Teil I, 3.2) durch:– Klassische Komponentensysteme– XML Technologien– Architektursysteme und –sprachen (Darwin, Unicon, Rapide,

ACME)– Erweiterungen des objekt-orientierten Paradigmas– Aspekt-orientiertes Programmieren, Adaptives Programmieren– Kalküle für Komponentensysteme– Metaprogrammieren und Metaprogrammiersysteme– Invasive Komposition




Material & Kontakte

Auf der Website zur Vorlesung: http://i44www.unfo.uni-karlsruhe.de/~lehre/Folien– Laufende Veranstaltung (SS 2001)– Elke Pulvermüller (WS 2000)– Uwe Assmann (SS 1999)

Weitere Informationen bei– noga|[email protected]– Tel. 608-8351 oder -4762

http://i44www.unfo.uni-karlsruhe.de/~lehre/





mailto:noga%[email protected]













Literatur

C. Szyperski. Component software. Beyond object-oriented computing. Addison-Wesley. Guter Überblick. Software - Tools and Techniques. Special Edition on Componentware, 1998. Springer. Guter Kurzüberblick, insbes. der Artikel von Michael Stal.R. Orfali, D. Harkey: Client/Server Programming with Java and Corba. Wiley & Sons. Leicht zu lesen.F. Griffel. Componentware. dpunkt-Verlag. Umfassendes Material, aber etwas anstrengender zu lesen.CORBA. Communications of the ACM, Oct. 1998. Neue Entwicklungen.Sametinger: Software Reengineering with Reusable Components. Springer 1998. Überblick, aber mehr auf abstraktem NiveauGamma et al: Entwurfsmuster. Addison-Wesley. Das unentbehrliche Handwerkszeug des Softwareklempners.W. Pree: Metapatterns. ACM Press. Strukturierung von Entwurfsmustern.W. Pree: Softwareentwicklung mit Frameworks. dpunkt-Verlag.




Standards

Common Object Request Broker Architecture (CORBA). OMG spec., http://www.omg.org/technology/documents/formal/corbaiiop.htm, 2001.The Component Object Model Specification. Microsoft, http://www.microsoft.com/com/resources/comdocs.asp, 1999.Enterprise JavaBeans. Sun, http://java.sun.com/products/ejb/, 2001.Extensible Markup Language (XML) 1.0. W3C Recommendation, http://www.w3.org/TR/1998/REC-xml-19980210, 1998.Simple Object Access Protocol (SOAP) 1.1. W3C Note, http://www.w3.org/TR/SOAP/, 2000.Web Services Description Language (WSDL) 1.1, W3C Note, http://www.w3.org/TR/wsdl, 2001.Universal Description, Discovery and Integration (UDDI) http://www.uddi.org/specification.html, 2000.

http://www.omg.org/technology/documents/formal/corbaiiop.htm











http://www.microsoft.com/com/resources/comdocs.asp














http://java.sun.com/products/ejb/



http://www.w3.org/TR/1998/REC-xml-19980210







http://www.w3.org/TR/SOAP/

http://www.w3.org/TR/wsdl

http://www.w3.org/TR/wsdl

http://www.uddi.org/specification.html






I.1.1 – Warum Entwicklung mit Komponenten?

Wiederverwendung von Teillösungen: Lösungsannäherung statt neuer ProblemlösungLeichte Konfigurierbarkeit des konstruierten Systems: Varianten, Versionen, ProduktfamilienOutsourcing von TeilproblemenBündelung von Kräften (bei nicht marktdivergierenden Systemeigenschaften)Kostenreduktion

Bewährt in anderen Ingenieursdisziplinen– Maschinenbau (z.B. DIN 2221), – Elektrotechnik, – Architektur




Beispiel: Kostenreduktion

Größe von Klassenbibliotheken– JDK 1.1: circa 1,650 Klassen– JDK 1.2: circa 4,000 Klassen

Je mächtiger, desto höher die Einarbeitungszeit

Reuse rates 0% 25% 50%Time [m.m.] 81,5 45 32# Developers 8 6 5Costs per l.o.c. [DM] 70 37 28Lines per m.m. 165 263 370Savings [DM] - ~ 400.000 ~ 560.000Savings - ~ 45% ~ 60%

From: C. Jones, The Impact of Reusable Modules and Functions, inProgramming Productivity, Mc Graw Hill, 1986




Weitere Ziele

Verbesserung der Produktqualität– Höhere Effektivität durch Konzentration auf Optimierungen– Höhere Verlässlichkeit (Haftungsfrage unklar)– Verlängerung der Lebensdauer – Flexibilisierung

Verbesserungen am Softwareprozess– Höhere Produktivität – Schneller Prototypenbau– Simulation von Architekturen

Dokumentation– Klare Systemstrukturen




Ursprünge

NATO Conference on Software (Garmisch 68) prägte die Begriffe:– Software crisis– Software engineering

McIlroy:– Jede reife Industrie basiert auf Komponenten– Komponenten erlauben Massenproduktion– Systeme werden beherrschbar durch Zusammenbau aus

Komponenten – Später erfand McIlroy bei Bell Labs UNIX pipes,

bis heute das meisteingesetzte Komponentensystem!

Wo stehen wir heute?




Reale Komponentensysteme

LEGOHohlblöckeICsHardware-Busse

Was unterscheidet sie von Methoden der Software-Konstruktion?




Komponenten und Komposition

Entwurf von Komponenten nach Geheimnisprinzip (information hiding) – Explizite Spezifikation von Schnittstellen– Implementierung bleibt verborgen

Komposition– Zusammensetzen von Komponenten nach lokalen

Entwurfsprinzipien, die globale funktionale und nichtfunktionale Eigenschaften zusichern

– Adaption von Komponenten, wenn nötig• Interne Adaption von Komponenten an ihren

Wiederverwendungskontext• Externe Adaption: Anpassung der Schnittstellen für die

Zusammenarbeit




Reale Komponentensysteme

System Schnittstellen Komposition AdaptionLEGO Noppen Stecken -

Hohlblöcke Form, Profil Mörtel Behauen

ICs und Busse

Pins, Signal- Spezifikation

Stecken, Löten

Wandler, Puffer etc.




I.1.2 – Definition von Komponenten

A software componentis a unit of composition with contractually specified interfaces and explicit context dependencies only. It can be deployed independently and is subject to composition by third parties.

Szyperski (ECOOP Workshop WCOP 1997)

A reusable software component is a logically cohesive, loosely coupled module that denotes a single abstraction.

Booch

A software component is a static abstraction with plugs.

Nierstrasz/Dami




Weitere Definitionen

Software components are defined as prefabricated, pretested, self-contained, reusable software modules - bundles of data and procedures - that perform specific functions.

MetaGroup (OpenDoc)

Reusable software components are self-contained, clearly identifyable pieces that describe and/or perform specific functions, have clear interfaces, appropriate documentation, and a defined reuse status.

Sametinger




Komponenten - Unsere Definition

Programmeinheiten mit standardisierter Basiskommunikation– Abstrakt (nur Schnittstelle), generisch oder konkret (mit Implementierung)– Klassen und Module sind Komponenten, Objekte nicht!

Entworfen mit standardisierten Verträgen zur Komposition:– Export-Schnittstelle sichert semantische Eigenschaften zu– Import-Schnittstelle definiert Voraussetzungen zur ihrer Garantie

• Explizit oder• Implizit (als Parameter von Konstruktoren oder anderen Methoden)

– Keine implizites WissenKomponenten sind wiederverwendbarKomponenten können aus Komponenten zusammengesetzt sein




Komposition

Instanziieren generischer KomponentenZusammensetzen von Komponenten laut Verträgen:– Über Funktionen und Daten– Über Kommunikation, Synchronisation und Protokolle– Problem der globalen Lebendigkeit?– Wie erreicht man nichtfunktionale Eigenschaften?

Mangelnde Passung erfordert Adaption der Komponenten:– Externe Adaption durch Wrappercode– Interne Adaption:

• Offenes Einsetzen• Invasiver Austausch nicht-funktionaler Aspekte (z.B.

Basiskommunikation tauschen, Synchronisation einfügen etc.)




Eigenschaften von Komponenten

Können aus Spezifikation generiert werden (generische Komponenten)Unterscheidung funktionaler und nicht-funktionaler Aspekte– Funktion und Daten, – Kommunikation und Synchronisation, – Verteilung, – Persistenz, etc.

Können dynamisch geladen und ersetzt werden – Programme können Komponenten mit Reflektion betrachten und

deren Dienste feststellen– Ignorieren unbekannter funktionaler Aspekte




Einige Kommunikationsarten

Normaler ProzeduraufrufCallbacks und EventsFernaufruf (remote procedure call, remote method invokation)– Einpacken der Objekte in Byte-Strom, Verschicken, Auspacken– Kann in heterogenen Systemen eingesetzt werden– Z.B. Java RMI, CORBA etc.

Gemeinsamer SpeicherUni- oder bidirektionale FIFOs (z.B. pipes, sockets)Blackboards, strukturierte Blackboards (Linda Tupelspace)Transaktionsdienste (Datenbank)Migration von Code (z.B. Java Applets)




Beispiel: Callbacks und Events

Aufrufer übergibt Prozedurvariable oder Verweis auf Objekte (anonymous classes in Java, Callback-Service in Corba)Rückruf durch Rahmenwerk, Bibliothek oder Server

Ereignisse (events) zur asynchronen Kommunikation– Technisch über Rückruf gelöst– Reihenfolge meist nicht zugesichert

dynamisch variierbarer EmpfängerEreignisquellen sind meist DiensteZ.B. in Java Beans, Corba Event Service




I.1.3 Klassische Konzepte

Betrachtung als Komponentensysteme und Diskussion von Problemen bei:– UNIX – XML - Lösungen– Module– Klassen und Vererbung– Rahmenwerke (Frameworks)




UNIX

Basiskommunikation: Byte-Ströme von Quelle zu Senke– Einfach und flexibel– In einem Rechner: Pipes– In Rechnernetzen: Sockets

Komponenten sind eigenständige Programme– Schnittstellen: Standardeingabe, Standardausgabe– Generierung: durch make etc.

Komposition mit Pipes in Shells und SkriptsprachenAdaption:– Interne nicht unterstützt– Externe durch eigenständige Komponenten, meist programmierbare

Filter (awk, cut, grep, sed, etc.)




Probleme

Komponenten haben jeweils nur einen Ein- und AusgangEinschränkung auf Ketten von Filtern (Pipelines)– Allgemeinerer Einsatz von Pipes und Sockets möglich. – Programme in C/C++ können so außerhalb des Modells agieren. – Komposition mit Werkzeugen wie Shells, Skripte dort unmöglich.

Einschränkung auf asynchrone Protokolle ohne RückkanalAdaption schwierig– Formale Modellierung der Daten fehlt– Standardwerkzeuge beherrschen maximal reguläre Muster

Allgemeine Probleme mit Skripten:– Schlecht skalierbar– Schlecht wartbar




XML Lösungen

XML Baum- bzw. Termsprache– Leicht zu Parsen– Baum und und Graphstrukturen Explizit über Syntax bzw. Namen

Komponenten sind weiterhin eigenständige ProgrammeSOAP (Simple Object Access Protokol) als Kommunikationsmethode– Meist http basierte Kommunikation

XML als Austauschformat, XSLT zur Datenanpassung – Pfadsprache zur Musterbeschreibung und regelbasierte Musterersetzung– andere Graphersetzungssysteme denkbar, nicht Standard

UNIX als Komponentensystem kann subsumiert werden




Module (à la Parnas)

Every module hides an important design decision behind a well-defined interface which does not change when the decision changes.

David ParnasEigenschaften

– Feste Schnittstellen– Kapselung, Geheimnisprinzip (information hiding)– Statische Bindung: Keine dynamische Erzeugung

Durchdringt viele moderne Sprachen (Modula, Ada, Java, C/C++ usw.)Betrachtung als Komponentensystem:

– Basiskommunikation: Prozeduraufruf– Schnittstellen: Prozeduren mit Parametern, globale Variable– Generierung: sprachspezifisch für generische Module– Adaption explizit und manuell




Probleme

Sprachabhängigkeit der– Basiskommunikation– Spezifikation von Daten und Prozeduren– Synchronisation

Protokolle nicht spezifiziertFehlende Werkzeuge für– Komposition– Adaption– Verteilung

Heterogene, verteilte Lösungen erfordern viel Handarbeit!




Objektorientierte Klassensysteme

Klassen sind Module– Haben mehrere zur Laufzeit erzeugte Instanzen (Objekte) – Objekte haben Zustände (evtl. persistent)

Vererbung und Untertypbeziehungen– Polymorphie – Späte Bindung von Aufrufen

Betrachtung als Komponentensystem:– Basiskommunikation: Polymorphe Methodenaufrufe, Variable– Schnittstellen: Polymorphe Methoden, Objekt- und Klassenvariable– Generierung: sprachspezifisch, oft mit generischen Klassen– Adaption: durch Vererbung oder Delegation




Generische oder Abstrakte Klassen

Generische/abstrakte Klasse

Instanz

System Implementierung




Probleme

Sprachabhängigkeit der– Basiskommunikation– Spezifikation von Daten und Prozeduren– Synchronisation

Protokolle nicht spezifiziertAdaption durch Spracheigenschaften eingeschränkt(Kontravarianz oder Invarianz bei Vererbung) Fehlende Werkzeuge zur Verteilung

Heterogene, verteilte Lösungen erfordern viel Handarbeit!




Rahmenwerke (Frameworks)

Rahmenwerke sind KlassensystemeSie bestimmen Kontrollfluss und Kommunikation einer Anwendung Parametrisierung durch KlassenRahmenwerke als Komponentensysteme:– Basiskommunikation: Methodenaufrufe– Schnittstellen: Hot spots - Mengen von polymorphen Methoden– Generierung: Instantiierung der Parameterklassen oder

Implementierung der abstrakten Klassen gemäß den Einschränkungen des Rahmens

– Adaption: durch Vererbung oder Delegation




Rahmenwerke

Parameterklassen Instanzen

System Implementierung

Implementierung




Probleme

Oft sprachabhängigKeine Wiederverwendung in fremdem Kontext(Grund: sehr gute Normierung/Standardisierung)Rahmen legt Möglichkeiten im Voraus fest:– Adaption– Verteilung– Heterogene Lösungen




Copyright © 1997 by Rational Software Corporation

Course CourseOffering

Student Professor

Modellierung mit UML Komponentendiagramm

Course.dll

People.dll

Course

User

Register.exeBilling.exe

BillingSystem




Probleme

Semantik sehr flexibelNichts ist definiert, also keine Anpassung nötigProblem der ImplementierungProbleme je nach Implementierungssprache oder -system




I.1.4 Kommerzielle Komponentensysteme

Komponentensystem (Plattform, Rahmenwerk) definiert Standards für Komponenten: Schnittstellen, Protokolle, Kommunikations- und Implementierungsbasisstellt Grundvoraussetzungen für Einsatz der Komponenten sicherreguliert Interaktionen zwischen den KomponentenBeispiele:– Corba– (D)COM– (Enterprise) JavaBeans– IBM SOM– OpenDoc




(D)COM, CORBA und JavaBeans

Basiskommunikation: – Normale Prozeduraufrufe an Kommunikationssystem– Weiterleitung über normale Aufrufe und Fernaufrufe

Standardisierte Schnittstellen – set/get Properties, – IUnknown (COM), QueryInterface (Corba)– Namensdienste etc.

Generierung: aus Klassen und DefinitionssprachenNur externe Adaption:– Für verteilte Systeme (marshaling) – Für gemischtsprachliche Systeme (IDL)




Komponenten in kommerziellen Systemen

Objekte, die in einen Softwarebus gesteckt werden könnenMit dem Bus und einer Menge von standardisierten Schnittstellen bilden sie ein Komponentensystem (Plattform)

Softwarebus




CORBA

Offener Standard, siehe http://www.corba.orgUnabhängig von Sprache und VerteilungInterface definition language IDLQuellcode oder binär

ClientJava

ServerC++

ClientC

IDL Stub IDL skeletonIDL Stub

Object Request Broker (ORB), Trader, Services

Object adapter

http://www.corba.org/









(D)COM

Microsoft proprietär, siehe http://www.activex.org Ähnelt CORBARein binärer Standard

ClientVBasic

ServerC++

ClientC++

COM stub COM skeletonCOM stub

Monikers, Registry

http://www.activex.org/









JavaBeans

Offener Standard, siehe http://www.javasoft.comSprachabhängig: nur JavaUnabhängig von Verteilung (durch RMI)Quellcode oder Bytecode

Java Bean

Java Bean

Java Bean

Event InfoBus, RMI

Bean Container

http://www.javasoft.com/









Probleme

Unterschiedliche Basiskommunikation der Systeme, – z.B. können Corba Komponenten nicht direkt COM Komponenten

verwenden– Wrapping mit zusätzlicher Indirektion oder – Invasive Änderung der Komponente nötig (unmöglich bei

Binärlösung)

Keine formale Definition von Protokollen– Komponenten mit gleichen Schnittstellen i.a. nicht

wiederverwendbar– Lösung Standardisierung:

• Schnittstellenidentifikation ist eindeutig (COM)• Reflektion




I.1.5 Akademische Konzepte

ArchitektursystemeAspektorientiertes ProgrammierenMetaprogrammieren und Invasive Programmadaptation als Technik zur Komposition




Architektursysteme

Z.B. Unicon, DarwinBasiskommunikation:– Prozeduraufrufe an sog. Tore (communication ports)– Art der Kommunikation zwischen Komponenten ist transparent

Schnittstellen: – Tore, an die Konnektoren angreifen– Explizite Anwendung von Konnektoren pro Kommunikation

(in objektorientierten Systemen wird Kommunikationen gemeinsam durch Vererbung verändert)

– Schnittstellen bleiben zur Laufzeit erhaltenInterne Adaption: durch VererbungExterne Adaption: Klebe- oder Wrappercode durch Konnektoren




Architektursysteme

Komponente

KomponentePort 2

Komponente

Port 1

PortPort

Konnektoren spalten Kommunikation aus Komponenten ab




Probleme

Keine StandardisierungKünstliche Unterscheidung von Konnektoren und KomponentenKeine Wiederverwendung von KonnektorenSchnittstellen von Komponenten und Konnektoren im laufenden Code




Aspekttrennung & Komposition

Strom Gas

WasserDaten

Trenne diePläne für

verschiedene Aspekte

und webe sie zu einem System

zusammen

Austausch der Aspekte unabhängig voneinander




Aspect-orientierted programming (AOP)

Siehe Kiczales et al: Aspect-oriented Programming. LNCS ECOOP 1998Verallgemeinerung von Architektursystemen:

– Architektursysteme sind spezielle Aspektsysteme: Ihre beiden Aspekte sind anwendungsspezifische Funktionalität und Kommunikation

– Weitere Aspekte: Synchronisation, Verteilung, Persistenz etc.Transparenz durch aspektbeschreibende Sprachen

Basiskommunikation: ein AspektGenerierung: Weben aus AspektspezifikationenSchnittstellen: Join points, an denen Aspekte verwoben werdenAdaption:

– Interne Adaption: Aspekte bilden Teile von Komponenten, d.h. interne Adaption durch Austausch von Aspekten

– externe Adaption: Weben von Klebecode um Komponenten herum




Aspekte eines Programms(Algorithmus und Animation)

/** The black code is the algorithmic aspect *//* * The red code is the animation aspect. */import java.io.*;public class Hanoi extends java.util.Observable implements java.util.Observer { public Hanoi() { addObserver( new PrintObserver() );} protected void compute( int n, String s, String t, String h ) { if(n > 1){ compute( n - 1, s, h, t ); } setChanged(); notifyObservers( new displayPack( s, t ) ); if(n > 1){ compute( n - 1, h, t, s ); } }

/** The black code is the algorithmic aspect */

import java.io.*;public class Hanoi {

public Hanoi() {…} protected void compute( int n, String s, String t, String h ) { if(n > 1){ compute( n - 1, s, h, t ); }

if(n > 1){ compute( n - 1, h, t, s ); } }




Aspekte als Sichten

System

Aspekt 1 Aspekt 2 Aspekt 3

Abstraktion=

Aspekt

Konkretisierung=

Weben




Probleme

Orthogonale Aspekte– Keine Interaktionen zwischen den Aspekten– Weben einfach

Nicht-orthogonale Aspekte– Z.B. Funktionalität und Synchronisation, Funktionalität und

Verteilung, Protokolle und Synchronisation etc.– Getrennte Spezifikation unmöglich– Weben unklar

Aspekt als Sicht– Abstraktion von Systemeigenschaften– Umkehrungsfunktion nicht immer

• Eindeutig• Widerspruchsfrei mit anderen Aspekten




Invasive Komposition

Webepunkte sind statisch eindeutig berechenbare ProgrammstellenKomponenten kapseln Entwurfsentscheidungen hinter Kompositionsschnittstellen mit wohldefinierten WebepunktenProgrammtransformatoren (auch Kompositionsoperatoren) erkennen und transformieren Webepunkte einer Kompositionsschnittstelle. Klassifikation:– Kein Komponentensystem!– Technik zur Komposition von allen Systemen funktioniert.




Invasive Komposition

Standard-Webepunkte, z.B. für wrapping: Method.begin und Method.end

Method m (){

abc.. cde..

return;}

Method.begin

Method.end

Method m

Method.begin

Method.end




Transformation eines Webepunktes

Wrapping eines Test-Aspekts

Method m (){ print(„enter m“) abc.. cde.. print(„exit m“) return;}

Method.begin

Method.end

Method m (){

abc.. cde..

return;}

Method.begin

Method.end




Mehrfache Bindung eines Webepunktes

DruckaspektMethod m

Method.end

Transaktions-

aspekt

Method.begin




Deklarierte Webepunkte

Z.B. Kommunikationstore: Ansprache von Torobjekten (port objects)

Method m (){

portOut.out(d); portIn.in(e);

}

OUT port

IN port Method m

portOut.out

portIn.in




Transformationen für Tore

m (){ … portOut.out(d); portIn.in(e); …}

OUT portIN port

m (){

/*** ports */ e = x(d); }m (){ /*** ports */ setChanged(d); notifyObservers(d); listen_to(e);}




Einfache Bindung von Toren

Method m

call

portIn.in

Method x

portOut.out

call




Transformation mit Kompositoren

Ein Kompositor ist ein Metaprogramm:– Programmtransformator – Bindet ungebundene Webepunkte an Code

Aufgaben– Erkennen von Webepunkten– Transformation durch Manipulation von Webepunkten

(Binden der Webepunkte, Weben, weaving)– Codegenerierung




Vergleich der Komponentensysteme

System Kommunikation Schnittstellen Generierung Adaption

Module Aufrufe Prozeduren Je nach Sprache

Je nach Sprache

Frameworks Polymorphe Aufrufe

Methoden Generische Klassen

Vererbung, Delegation

CORBA & Co. RMI Methoden (nach IDL)

- Wrapper

Architektur-systeme

Aufrufe an Tore Tore - Konnektoren

AOP Aspekt (beliebig)

Join points Weben Weben




Historische Ansätze

Netscape ONE:– HTML, Java, JavaScript– Internet foundation classes (Java Klassen für Netzwerk)– Internet inter-ORB protocol (IIOP, Konnektoren basierend auf

CORBA)– Transport und applikationsspezifischer Protokolle

IBM Visual Age und ComponentBroker– Entwicklungsumgebung auf VisualAge-Basis – CBToolkit (Komponenten auf CORBA IDL basierend)– CBConnector (Verknüpfung und Management)




Weitere historische Ansätze

IBM System Object Model (SOM)– Sprachunabhängiges Binärformat mit Versionen– Binäre Aufwärtskompatibilität (“release order”, Erhalt alter Offsets in Komponenten)– Unterstützung von Metadaten (Reflexion, Introspektion, Intercession):

wie in Smalltalk können Klassen über Klassen nachdenken und Code transformieren– Mehrfachvererbung von Code

Apple OpenDoc: Aktive strukturierte Dokumente (setzt auf IBM SOM auf)– “compound document“, “document parts”– Teile: ”native data“ / andere Teile– Open Scripting Architecture basierend auf AppleScript– Structured files mit Bento (ähnlich zu Microsofts COM/OLE)

• Dokument-Versionen von Dokumentbäumen mit Deltatechnik• Flexibles Speichermodell für Datenströme und Einzeldateien• Annotationen für Modifikationen an Dateien

– Mittlerweile in Corba integriert




Probleme der bisherigen Systeme

Fehlen von Standards für Anwendungsbereiche:– Verbindungsstandards nicht genug – Wie einen Standard erreichen? Marktmacht Microsoft, Corba Facilities, ...

Bessere Verträge für höhere Sicherheitsansprüche an Komponenten– erweiterte Verträge: Protokolle (Corba IIOP), – Spezifikation von nicht-funktionalen Eigenschaften Zeit- und Speicherbedarf

Dienstvermittlung: – Semantikerkennung unmöglich – Standardisierung, aber Versionen zerstören Konsistenz

Wasserkopfprobleme (besonders bei Corba deutlich)Technische Probleme

– Speicherbereinigung (garbage collection)– Problem der Syntaktisch Fragilen Basisklassen: bei Versionsänderungen – Persistenzprobleme: müssen bereits ausgelieferte Komponenten nachübersetzt

werden– Austauschformate: Standard oder XML Lösungen– Objekt-Mobilität, -Migration: Senden kleiner Objekte statt Referenzen




Probleme des Systementwurfs

Bisherige Entwurfskonzepte nicht auf Komponenten-Software übertragbar

– Top-down Entwurf bei vorgegebenen Komponenten?– Verfeinerung auf nicht vollständig spezifizierten Komponenten (Aspekte

fehlen, generische Komponenten, Komponenten vor invasiver Kopplung)– unabhängige Erweiterungen, viele Quellen– Globale Lebendigkeit

Managementprobleme– Qualitätssicherung bei anzupassenden Komponenten– Softwareprozeß

Rechtliche Probleme– Urheberrecht an Komponenten– Haftung bei Fehlern



Documents

Software aus Komponenten - Systeme, Adaptionen und Probleme Dr. Welf Löwe und Markus Noga Lehrstuhl Prof. Goos Institut für Programmstrukturen Universität