Die Präsentation wird geladen. Bitte warten

Die Präsentation wird geladen. Bitte warten

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

Ähnliche Präsentationen


Präsentation zum Thema: "Software aus Komponenten - Systeme, Adaptionen und Probleme Dr. Welf Löwe und Markus Noga Lehrstuhl Prof. Goos Institut für Programmstrukturen Universität."—  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 Dr. Welf Löwe und Markus Noga2 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 Dr. Welf Löwe und Markus Noga3 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 Dr. Welf Löwe und Markus Noga4 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 Dr. Welf Löwe und Markus Noga5 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 Dr. Welf Löwe und Markus Noga6 Standards Common Object Request Broker Architecture (CORBA). OMG spec., The Component Object Model Specification. Microsoft, Enterprise JavaBeans. Sun, http://java.sun.com/products/ejb/ 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 Dr. Welf Löwe und Markus Noga7 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 Dr. Welf Löwe und Markus Noga8 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

9 Dr. Welf Löwe und Markus Noga9 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 Dr. Welf Löwe und Markus Noga10 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 Dr. Welf Löwe und Markus Noga11 Reale Komponentensysteme LEGO Hohlblöcke ICs Hardware-Busse Was unterscheidet sie von Methoden der Software- Konstruktion?

12 Dr. Welf Löwe und Markus Noga12 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 Dr. Welf Löwe und Markus Noga13 Reale Komponentensysteme SystemSchnittstellenKompositionAdaption LEGONoppenStecken- HohlblöckeForm, ProfilMörtelBehauen ICs und Busse Pins, Signal- Spezifikation Stecken, Löten Wandler, Puffer etc.

14 Dr. Welf Löwe und Markus Noga14 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 Dr. Welf Löwe und Markus Noga15 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 Dr. Welf Löwe und Markus Noga16 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 Dr. Welf Löwe und Markus Noga17 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 Dr. Welf Löwe und Markus Noga18 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 Dr. Welf Löwe und Markus Noga19 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)

20 Dr. Welf Löwe und Markus Noga20 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 Dr. Welf Löwe und Markus Noga21 I.1.3 Klassische Konzepte Betrachtung als Komponentensysteme und Diskussion von Problemen bei: –UNIX –XML - Lösungen –Module –Klassen und Vererbung –Rahmenwerke (Frameworks)

22 Dr. Welf Löwe und Markus Noga22 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 Dr. Welf Löwe und Markus Noga23 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 Dr. Welf Löwe und Markus Noga24 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 Dr. Welf Löwe und Markus Noga25 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 Dr. Welf Löwe und Markus Noga26 Probleme Sprachabhängigkeit der –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 Dr. Welf Löwe und Markus Noga27 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 Dr. Welf Löwe und Markus Noga28 Generische oder Abstrakte Klassen Generische/abstrakte Klasse Instanz Syst e m Implementierung

29 Dr. Welf Löwe und Markus Noga29 Probleme Sprachabhängigkeit der –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 Dr. Welf Löwe und Markus Noga30 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 Dr. Welf Löwe und Markus Noga31 Rahmenwerke ParameterklassenInstanzen System Implementierung

32 Dr. Welf Löwe und Markus Noga32 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 Dr. Welf Löwe und Markus Noga33 Copyright © 1997 by Rational Software Corporation Course Offering Student Professor Modellierung mit UML Komponentendiagramm Course.dll People.dll Course User Register.exe Billing.exe Billing System

34 Dr. Welf Löwe und Markus Noga34 Probleme Semantik sehr flexibel Nichts ist definiert, also keine Anpassung nötig Problem der Implementierung Probleme je nach Implementierungssprache oder -system

35 Dr. Welf Löwe und Markus Noga35 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 Dr. Welf Löwe und Markus Noga36 (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)

37 Dr. Welf Löwe und Markus Noga37 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 Dr. Welf Löwe und Markus Noga38 CORBA Offener Standard, siehe Unabhängig von Sprache und Verteilung Interface definition language IDL Quellcode oder binär Client Java Server C++ Client C IDL Stub IDL skeleton IDL Stub Object Request Broker (ORB), Trader, Services Object adapter

39 Dr. Welf Löwe und Markus Noga39 (D)COM Microsoft proprietär, siehe Ähnelt CORBA Rein binärer Standard Client VBasic Server C++ Client C++ COM stub COM skeleton COM stub Monikers, Registry

40 Dr. Welf Löwe und Markus Noga40 JavaBeans Offener Standard, siehe Sprachabhängig: nur Java Unabhängig von Verteilung (durch RMI) Quellcode oder Bytecode Java Bean Event InfoBus, RMI Bean Container

41 Dr. Welf Löwe und Markus Noga41 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 Dr. Welf Löwe und Markus Noga42 I.1.5 Akademische Konzepte Architektursysteme Aspektorientiertes Programmieren Metaprogrammieren und Invasive Programmadaptation als Technik zur Komposition

43 Dr. Welf Löwe und Markus Noga43 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 Dr. Welf Löwe und Markus Noga44 Architektursysteme Komponente Port 2 Komponente Port 1 Port Konnektoren spalten Kommunikation aus Komponenten ab

45 Dr. Welf Löwe und Markus Noga45 Probleme Keine Standardisierung Künstliche Unterscheidung von Konnektoren und Komponenten Keine Wiederverwendung von Konnektoren Schnittstellen von Komponenten und Konnektoren im laufenden Code

46 Dr. Welf Löwe und Markus Noga46 Aspekttrennung & Komposition StromGas Wasser Daten Trenne die Pläne für verschiedene Aspekte und webe sie zu einem System zusammen Austausch der Aspekte unabhängig voneinander

47 Dr. Welf Löwe und Markus Noga47 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 Dr. Welf Löwe und Markus Noga48 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 ); }

49 Dr. Welf Löwe und Markus Noga49 Aspekte als Sichten System Aspekt 1 Aspekt 2 Aspekt 3 Abstraktion = Aspekt Konkretisierung = Weben

50 Dr. Welf Löwe und Markus Noga50 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

51 Dr. Welf Löwe und Markus Noga51 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 Dr. Welf Löwe und Markus Noga52 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

53 Dr. Welf Löwe und Markus Noga53 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

54 Dr. Welf Löwe und Markus Noga54 Mehrfache Bindung eines Webepunktes Druckaspekt Method m Method.end Transaktions- aspekt Method.begin

55 Dr. Welf Löwe und Markus Noga55 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

56 Dr. Welf Löwe und Markus Noga56 Transformationen für Tore m (){ … portOut.out(d); portIn.in(e); … } OUT port IN port m (){ /*** ports */ e = x(d); } m (){ /*** ports */ setChanged(d); notifyObservers(d); listen_to(e); }

57 Dr. Welf Löwe und Markus Noga57 Einfache Bindung von Toren Method m call portIn.in Method x portOut.out call

58 Dr. Welf Löwe und Markus Noga58 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 Dr. Welf Löwe und Markus Noga59 Vergleich der Komponentensysteme SystemKommunikationSchnittstellenGenerierungAdaption ModuleAufrufeProzedurenJe nach Sprache FrameworksPolymorphe Aufrufe MethodenGenerische Klassen Vererbung, Delegation CORBA & Co.RMIMethoden (nach IDL) -Wrapper Architektur- systeme Aufrufe an ToreTore-Konnektoren AOPAspekt (beliebig) Join pointsWeben

60 Dr. Welf Löwe und Markus Noga60 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)

61 Dr. Welf Löwe und Markus Noga61 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 Dr. Welf Löwe und Markus Noga62 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 Dr. Welf Löwe und Markus Noga63 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 Dr. Welf Löwe und Markus Noga Lehrstuhl Prof. Goos Institut für Programmstrukturen Universität."

Ähnliche Präsentationen


Google-Anzeigen