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

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|loewe@ipd.info.uni-karlsruhe.de Tel. 608-8351 oder -4762

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 Niveau Gamma 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.

I.1.1 – Warum Entwicklung mit Komponenten? Wiederverwendung von Teillösungen: Lösungsannäherung statt neuer Problemlösung Leichte Konfigurierbarkeit des konstruierten Systems: Varianten, Versionen, Produktfamilien Outsourcing von Teilproblemen Bü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 Quelle: Jones86 p. 155 Entwicklung von Geschäftsanwendungen zur Marktvorhersage für den internen Gebrauch in COBOL. Fall 1: Gutes Design & Strukturierte Programmierung, keine Wiederverwendung Fall 2: Wie oben, zusätzlich Verwendung existierender Bibliotheken Fall 3: Wie oben, Framework statt Bibliotheken

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 LEGO Hohlblöcke ICs Hardware-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 Schnittstellen Komposition Adaption LEGO 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 component is 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 Wissen Komponenten sind wiederverwendbar Komponenten können aus Komponenten zusammengesetzt sein

Komposition Instanziieren generischer Komponenten Zusammensetzen 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 Prozeduraufruf Callbacks und Events Fernaufruf (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 Speicher Uni- oder bidirektionale FIFOs (z.B. pipes, sockets) Blackboards, strukturierte Blackboards (Linda Tupelspace) Transaktionsdienste (Datenbank) Migration von Code (z.B. Java Applets) Wichtige Folie, aber nicht hier. Wo besser?

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änger Ereignisquellen sind meist Dienste Z.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 Skriptsprachen Adaption: 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 Ausgang Einschrä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ückkanal Adaption 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 Programme SOAP (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 Parnas Eigenschaften 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 Protokolle nicht spezifiziert Basiskommunikation Spezifikation von Daten und Prozeduren Synchronisation Protokolle nicht spezifiziert Fehlende 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 Protokolle nicht spezifiziert Basiskommunikation Spezifikation von Daten und Prozeduren Synchronisation Protokolle nicht spezifiziert Adaption durch Spracheigenschaften eingeschränkt (Kontravarianz oder Invarianz bei Vererbung) Fehlende Werkzeuge zur Verteilung Heterogene, verteilte Lösungen erfordern viel Handarbeit!

Rahmenwerke (Frameworks) Rahmenwerke sind Klassensysteme Sie bestimmen Kontrollfluss und Kommunikation einer Anwendung Parametrisierung durch Klassen Rahmenwerke 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

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

Modellierung mit UML Komponentendiagramm Register.exe Billing.exe Billing System Course.dll People.dll Course User Course Offering Student Professor The Unified Modeling Language Reference Manual. Rumbaugh, Jacobson and Booth, Addison-Wesley, 1999. Hier: p. 33 The Unified Modeling Language User Guide. Booch et al, Addison-Wesley, 1999. Kreis: Dienst Box mit Zacken: Komponente Feste Linie ohne Pfeil: Bietet Dienst an Gestrichelter Pfeil: Benutzt Copyright © 1997 by Rational Software Corporation 40

Probleme Semantik sehr flexibel Nichts ist definiert, also keine Anpassung nötig Problem der Implementierung Probleme je nach Implementierungssprache oder -system

I.1.4 Kommerzielle Komponentensysteme Komponentensystem (Plattform, Rahmenwerk) definiert Standards für Komponenten: Schnittstellen, Protokolle, Kommunikations- und Implementierungsbasis stellt Grundvoraussetzungen für Einsatz der Komponenten sicher reguliert Interaktionen zwischen den Komponenten Beispiele: 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 Definitionssprachen Nur externe Adaption: Für verteilte Systeme (marshaling) Für gemischtsprachliche Systeme (IDL) Gemeinsamen Oberbegriff finden

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

CORBA Offener Standard, siehe http://www.corba.org Unabhängig von Sprache und Verteilung Interface definition language IDL Quellcode oder binär Client Java Client C Server C++ IDL Stub IDL Stub IDL skeleton Object adapter Object Request Broker (ORB), Trader, Services

(D)COM Microsoft proprietär, siehe http://www.activex.org Ähnelt CORBA Rein binärer Standard Client C++ Server C++ Client VBasic COM stub COM stub COM skeleton Monikers, Registry

JavaBeans Offener Standard, siehe http://www.javasoft.com Sprachabhängig: nur Java Unabhängig von Verteilung (durch RMI) Quellcode oder Bytecode Java Bean Java Bean Java Bean Bean Container Event InfoBus, RMI

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 Architektursysteme Aspektorientiertes Programmieren Metaprogrammieren und Invasive Programmadaptation als Technik zur Komposition

Architektursysteme Z.B. Unicon, Darwin Basiskommunikation: 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 erhalten Interne Adaption: durch Vererbung Externe Adaption: Klebe- oder Wrappercode durch Konnektoren

Architektursysteme Komponente Komponente Komponente Port 1 Komponente Port Komponente Port Port 2 Komponente Konnektoren spalten Kommunikation aus Komponenten ab

Probleme Keine Standardisierung Künstliche Unterscheidung von Konnektoren und Komponenten Keine Wiederverwendung von Konnektoren Schnittstellen von Komponenten und Konnektoren im laufenden Code

Aspekttrennung & Komposition Wasser Trenne die Pläne für verschiedene Aspekte und webe sie zu einem System zusammen Daten Strom Gas Austausch der Aspekte unabhängig voneinander

Aspect-orientierted programming (AOP) Siehe Kiczales et al: Aspect-oriented Programming. LNCS ECOOP 1998 Verallgemeinerung 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 Aspekt Generierung: Weben aus Aspektspezifikationen Schnittstellen: Join points, an denen Aspekte verwoben werden Adaption: 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 */ 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 ); compute( n - 1, h, t, s ); /** 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 ) ); compute( n - 1, h, t, s );

Aspekte als Sichten Aspekt 1 Aspekt 2 Aspekt 3 Abstraktion = Aspekt Konkretisierung = Weben System

Probleme Orthogonale Aspekte Nicht-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 Programmstellen Komponenten kapseln Entwurfsentscheidungen hinter Kompositionsschnittstellen mit wohldefinierten Webepunkten Programmtransformatoren (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 m Method.begin Method.begin Method.end Method.end

Transformation eines Webepunktes Wrapping eines Test-Aspekts Method m (){ abc.. cde.. return; } Method m (){ print(„enter m“) abc.. cde.. print(„exit m“) return; } Method.begin Method.begin Method.end Method.end

Mehrfache Bindung eines Webepunktes Method m Method.begin Druckaspekt Method.end Transaktions- aspekt

Deklarierte Webepunkte Z.B. Kommunikationstore: Ansprache von Torobjekten (port objects) Method m (){ portOut.out(d); portIn.in(e); } Method m portOut.out OUT port IN port portIn.in

Transformationen für Tore /*** ports */ e = x(d); } m (){ … portOut.out(d); portIn.in(e); } OUT port IN port m (){ /*** ports */ setChanged(d); notifyObservers(d); listen_to(e); }

Einfache Bindung von Toren Method m Method x portOut.out call portIn.in 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 Kommunikation Schnittstellen Generierung Adaption Module Aufrufe Prozeduren 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

Historische Ansätze Netscape ONE: IBM Visual Age und ComponentBroker 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