Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

Software aus Komponenten - Systeme, Adaptionen und Probleme

Ähnliche Präsentationen


Präsentation zum Thema: "Software aus Komponenten - Systeme, Adaptionen und Probleme"—  Präsentation transkript:

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

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

3 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

4 Material & Kontakte Auf der Website zur Vorlesung: Folien Laufende Veranstaltung (SS 2001) Elke Pulvermüller (WS 2000) Uwe Assmann (SS 1999) Weitere Informationen bei Tel oder -4762

5 Literatur C. Szyperski. Component software. Beyond object-oriented computing. Addison-Wesley. Guter Überblick. Software - Tools and Techniques. Special Edition on Componentware, 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 Neue Entwicklungen. Sametinger: Software Reengineering with Reusable Components. Springer Ü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.

6 Standards Common Object Request Broker Architecture (CORBA). OMG spec., The Component Object Model Specification. Microsoft, Enterprise JavaBeans. Sun, Extensible Markup Language (XML) 1.0. W3C Recommendation, Simple Object Access Protocol (SOAP) 1.1. W3C Note, Web Services Description Language (WSDL) 1.1, W3C Note, Universal Description, Discovery and Integration (UDDI)

7 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

8 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

9 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

10 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?

11 Reale Komponentensysteme
LEGO Hohlblöcke ICs Hardware-Busse Was unterscheidet sie von Methoden der Software-Konstruktion?

12 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

13 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.

14 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

15 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

16 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

17 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.)

18 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

19 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?

20 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

21 I.1.3 Klassische Konzepte Betrachtung als Komponentensysteme und Diskussion von Problemen bei: UNIX XML - Lösungen Module Klassen und Vererbung Rahmenwerke (Frameworks)

22 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.)

23 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

24 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

25 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

26 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!

27 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

28 Generische oder Abstrakte Klassen
Generische/abstrakte Klasse Instanz System Implementierung

29 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!

30 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

31 Rahmenwerke Parameterklassen Instanzen System Implementierung

32 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

33 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, 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

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

35 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

36 (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

37 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

38 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

39 (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

40 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

41 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

42 I.1.5 Akademische Konzepte
Architektursysteme Aspektorientiertes Programmieren Metaprogrammieren und Invasive Programmadaptation als Technik zur Komposition

43 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

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

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

46 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

47 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

48 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 );

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

50 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

51 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.

52 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

53 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

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

55 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

56 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); }

57 Einfache Bindung von Toren
Method m Method x portOut.out call portIn.in call

58 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

59 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

60 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)

61 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

62 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

63 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


Herunterladen ppt "Software aus Komponenten - Systeme, Adaptionen und Probleme"

Ähnliche Präsentationen


Google-Anzeigen