Präsentation herunterladen
Die Präsentation wird geladen. Bitte warten
Veröffentlicht von:Angelika Fried Geändert vor über 8 Jahren
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
Ähnliche Präsentationen
© 2024 SlidePlayer.org Inc.
All rights reserved.