Refine
Year of publication
Document Type
- Doctoral Thesis (92) (remove)
Has Fulltext
- yes (92)
Is part of the Bibliography
- no (92)
Keywords
- Verteiltes System (3)
- Beschreibungskomplexität (2)
- FPGA (2)
- Information Retrieval (2)
- Mehragentensystem (2)
- Organic Computing (2)
- Relationale Datenbank (2)
- ALICE (1)
- Abfrageverarbeitung (1)
- Abstraction (1)
Institute
- Informatik (92) (remove)
Gegenstand dieser Arbeit war die Analyse der Komplexität von Kosten- und Erlösrechnungssystemen und ihrer Auswirkung auf die Auswahl geeigneter Instrumente für die EDV-gestützte Realisierung dieser Systeme, wobei insbesondere auf die bisherigen Ansätze der Datenbank- und Wissensuntersrutzung der Kosten- und Erlösrechnung eingegangen werden sollte. Das zweite Kapitel befaßt sich mit einer Analyse der Komplexität der in Deutschland am weitesten verbreiteten Kosten- und Erlösrechnungssysteme. Die Untersuchung der grundlegenden Gestaltungsmerkmale von Kosten- und Erlösrechnungssystemen auf ihre Komplexitätsrelevanz zeigte, daß einige Merkmale die Komplexität sehr stark beeinflussen, andere dagegen kaum, darunter auch in der betriebswirtschaftlichen Diskussion so wesentliche wie der verwendete Kostenbegriff. Den größten Einfluß auf die Komplexität von Kosten- und Erlösrechnungssystemen besitzen die Kosten- und Erlösstrukturierung sowie die Verarbeitungsarten, -methoden und -inhalte. Ein Vergleich der Grenzplankostenrechnung nach Kn.GER und FLAUT, stellvertretend Im überwiegend zweckmonistische Kostenrechnungssysteme, und der Einzelkostenrechnung nach RIEBEL als zweckpluralistischem Kosten- und Erlösrechnungssystem bezüglich der komplexitätsrelevanten Merkmale ergab eindeutige Unterschiede zwischen diesen Systemen. Während die Grenzplankostenrechnung polynomiale Platz- und Funktionskomplexitäten niedriger Grade (überwiegend quadratisch und nur im Rahmen der innerbetrieblichen Leistungsverrechnung kubisch) aufweist, treten in der Einzelkostenrechnung an mehreren entscheidenden Stellen exponentielle Komplexitäten auf. Die Analyse der Komplexität dieser beiden Kosten- und Erlösrechnungssystemen zeigt einen eindeutigen Zusammenhang zwischen vielseitiger Auswertbarkeit und der Komplexität eines Systems auf, der bei einer Beurteilung von Kosten- und Erlösrechnungssystemen berücksichtigt werden muß. Für die Gestaltung von Kosten- und Erlösrechnungssystemen bedeutet dies eine grundsätzliche Wahlmöglichkeit zwischen Systemen begrenzter Auswertbarkeit und niedriger Komplexität sowie Systemen mit größerer Auswertungsvielfalt, aber deutlich höherer Komplexität. Die Komplexität von Kosten- und Erlösrechnungssystemen ist jedoch nicht als eine Folge der Auswahl eines Rechnungssystems zu betrachten, sondern resultiert letztlich aus der Komplexität einer Unternehmung und ihrer Umwelt, die unterschiedlich detailliert abgebildet werden können. Da diese Komplexitäten in Zukunft eher noch zunehmen werden, ist grundSätzlich mit einem Trend zu universelleren und komplexeren Systemen zu rechnen. Die Erweiterung der Grenzplankostenrechnung hin zu größerer Komplexität sowie die Entwicklung neuerer Ansätze wie der Prozeßkostenrechnung bestätigen beide diesen Trend. Für die weitere Untersuchung wird vorausgesetzt, daß die Grenzplankostenrechnung und die Einzelkostenrechnung die entgegengesetzten Enden eines Komplexitätsspektrums von Kosten- und Erlösrechnungssystemen bilden und daher auch das Spektrum der Anforderungen an die Instrumente zu ihrer EDV-Implementierung begrenzen. Unter einer Anzahl von neueren Entwicklungen in der EDV wurden daher zwei Konzepte ausgewählt, die zur Behandlung verschiedener Aspekte der Komplexität geeignet sind: Datenbanksysteme zur Behandlung der Platzkomplexität und Wissenssysteme zur Behandlung der Funktionskomplexität. Im folgenden werden die Erfahrungen, die bei der Realisierung von Datenbank- und Wissenssystemen für die Kosten- und Erlösrechnung gemacht wurden, unter dem Gesichtspunkt der Komplexität von Kosten- und Erlösrechnungssystemen bewertet. Bei der Betrachtung von Datenbanksystemen ist zu berücksichtigen, daß sich im Laufe der Zeit zwei unterschiedliche Anwendungstypen herauskristallisiert haben: konventionelle Datenbankanwendungen, die den herkömmlichen Paradigmen von Datenbanksystemen entsprechen, und neuere Datenbankanwendungen, die z.T. wesentlich höhere Anforderungen stellen und so die Entwicklung neuer Datenbanksysteme erforderlich machten. Beide Systeme der Kosten- und Erlösrechnung eignen sich grundSätzlich als Datenbankanwendungen, d.h. sie rechtfertigen den Einsatz von Datenbanksystemen zur Verwaltung ihrer Datenmengen. Während die Grenzplankostenrechnung aber den konventionellen Datenbankanwendungen zuzurechnen ist, weist die Einzelkostenrechnung bereits wesentliche Merkmale neuerer Datenbankanwendungen auf. Im Gegensatz zu Datenbanksystemen sind die Anforderungen an Wissenssysteme und ihre Eigenschaften sehr unpräzise, z.T. sogar widersprüchlich formuliert. Auf der Basis der gängigen Eigenschaftskataloge erscheint die Kosten- und Erlösrechnung nicht als typische Wissenssystemanwendung. Trotzdem wurden bereits mehrere Wissenssysteme für Kosten- und Erlösrechnungsprobleme (Abweichungsanalyse, Betriebsergebnisanalyse, Bestimmung von Preisuntergrenzen, konstruktionsbegleitende Kalkulation und Teilprobleme der Prozeßkostenrechnung) realisiert, von denen jedes einige der Eignungskriterien für Wissenssystemanwendungen erfüllt. Die behandelten Beispiele für Wissenssysteme im Rahmen der Kosten- und Erlösrechnung basieren überwiegend auf der Grenzplankostenrechnung. Es ist daher anzunehmen, daß die Einzelkostenrechnung auf Grund ihrer höheren Komplexität weitere Anwendungsprobleme für Wissenssysteme enthält. Insgesamt sind jedoch die Unterschiede zwischen der Grenzplankostenrechnung und der Einzelkostenrechnung im Hinblick auf den Einsatz von Wissenssystemen wesentlich weniger ausgeprägt als dies für den Einsatz von Datenbanksystemen der Fall war. Nachdem beide Systeme der Kosten- und Erlösrechnung sowohl als Datenbankanwendungen geeignet sind als auch Anwendungsprobleme für Wissenssysteme aufweisen, ist auch die Verbindung von Wissenssystemen und Datenbanksystemen in Betracht zu ziehen. Daher wurde im Anschluß die jeweiligen Vor- und Nachteile von Datenbank- und Wissenssysteme gegenübergestellt. Die Vorteile von Datenbanksystemen liegen auf den maschinennäheren Ebenen, auf denen die Vorkehrungen für Datenschutz, Datensicherung, reibungslosen Mehrbenutzerbetrieb sowie die effiziente Ausführung der Operationen geschaffen werden. Die Vorteile von Wissenssystemen liegen in der größeren Mächtigkeit der Problemlösungskomponente, der Wissenserweiterungskomponente und der Erklärungskomponente. Ein neueres Beispiel für eine Zusammenarbeit von Datenbank- und Wissenssystemen ist die Auswertung eines speziell für derartige Zwecke angelegten Data Warehouse durch das Data Mining sowie andere Analysesysteme. Ein Data Warehouse stimmt in wesentlichen Merkmalen mit der Grundrechnung der Einzelkostenrechnung überein und zeigt, daß eine Grundrechnung auf der Basis heutiger EDV -Systeme realisierbar ist. Zur Auswertung einer Datenbank dieser Größe sind spezielle Analysesysteme notwendig. Für standardisierte Auswertungen eines Data Warehouse wurden OLAP-Systeme entwickelt, deren Operationen Verallgemeinerungen mehrdimensionaler Deckungsbeitragsrechnungen sind. Bei nicht standardisierbaren Auswertungen empfiehlt sich dagegen der Einsatz von Wissenssystemen, für den das Data Mining ein Beispiel liefert. Diese Kombination von Datenbanksystem, konventionellen und Kl-Auswertungen erscheint für eine Verwendung in der Kosten- und Erlösrechnung bestens geeignet. Das vierte Kapitel befaßt sich mit Ansätzen zur Strukturierung von Daten- und Wissensbasen, die bei Datenbanksystemen als Datenmodelle, bei Wissenssystemen als Wissensrepräsentationstechniken bezeichnet werden. Dabei wurde der Unterteilung des dritten Kapitels gefolgt und zwischen konventionellen und neueren Datenmodellen sowie Wissensrepräsentationstechniken unterschieden. Die Betrachtung des Relationenmodells als Vertreters der konventionellen Datenmodelle ergab, daß es für die Grenzplankostenrechnung völlig ausreicht. Die Erfahrungen mit der Realisierung einer Grundrechnung auf der Basis des Relationenmodells haben dagegen gezeigt, daß seine syntaktischen und semantischen Mängel zu weitgehenden Vereinfachungen beim Schemaentwurf zwingen, die wiederum die Operationen der Auswertungsrechnungen unnötig komplizieren. Aus der Vielzahl semantischer und objektorientierter Datenmodelle, die für neuere Datenbankanwendungen entwickelt wurden, hat sich trotz Unterschieden in Details eine Anzahl von Konzepten herauskristallisiert, die den meisten dieser DatenmodelIe gemeinsam sind. Mit Hilfe dieser Konzepte sind die Probleme, die bei der Verwendung des Relationenmodelis auftraten, vermeidbar. Im Grunde sind daher fast alle semantischen und objektorientierten Entwurfsmodelle zur ModelIierung einer Grundrechnung geeignet. Wichtig ist jedoch,daß die Grundrechnung auch mit einem Datenbanksystem realisiert wird, dem eines dieser Datenmodelle zugrunde liegt, da bei einer Transformation auf ein relationales Datenmodell wesentliche Entwurfsüberlegungen - und damit der größte Teil des Vorteils,den semantische und objektorientierte Entwurfsmodelle bieten -, verloren gehen. Zur Realisierung einer Grundrechnung erscheinen objektrelationale Datenbanksysteme am besten geeignet, da sie einerseits objektorientierte Konzepte mit mächtigen und komfortablen Anfragesprachen verbinden und andererseits aufwärtskompatibel zu den weitverbreiteten relationalen Datenbanksystemen sind. Da sich die objektorientierten Datenmodelle als für die Modellierung einer Grundrechnung geeignet erwiesen haben, wurden unter dem Gesichtspunkt der Verbindung von Datenbank- und Wissenssystemen nur objektorientierte Wissensrepräsentationstechniken in Betracht gezogen. Zwischen semantischen und objektorientierten Datenmodellen einerseits und objektorientierten Wissensrepräsentationstechniken, vor allem semantischen Netzen und Frames, andererseits bestehen weitgehende Übereinstimmungen. Daher können z.B. framebasierte Wissenssysteme direkt auf objektorientierten Datenbanksystemen realisiert werden. Inzwischen werden aber auch objektorientierte Programmiersprachen wie C++ oder Smalltalk zur Implementierung von Wissenssystemen verwendet, von denen die objektorientierte Sprache C++ am geeignetsten erscheint, da die meisten objektorientierten und objektrelationalen Datenbanksysteme eine C++-Schnittstelle aufweisen. Abschließend ist daher festzustellen, daß das Paradigma der Objektorientierung, das in Entwurfssprachen, Datenmodellen, Wissensrepräsentationstechniken und Programmiersprachen wesentliche Einflüsse ausgeübt hat, für die Realisierung der datenbankgestützten Grundrechnung eines zweckpluralistischen Kosten- und Erlösrechnungssystems wie der Einzelkostenrechnung sowie darauf aufbauender Auswertungsrechnungen, die z.T. als Wissenssysteme realisiert werden, wesentliche Vorteile besitzt. Über die adäquatere ModelIierung der Strukturen hinaus entsteht durch den Einsatz objektorientierter Techniken zum Entwurf und zur Implementierung aller System teile ein möglichst homogenes System, das nicht zusätzlich zu der inhärenten Komplexität noch weitere Probleme durch ungeeignete Darstellungskonzepte oder schlechte Abstimmung schafft.
Eine verteilte Infrastruktur für typ- und diensterweiterbare orthogonale digitale Bibliotheken
(2002)
Ziel dieser Arbeit war es, eine verteilte Infrastruktur zu entwickeln, die die Realisierung skalierbarer erweiterbarer orthogonaler Digitaler Bibliotheken erlaubt. Dabei sollte die Skalierbarkeit sowohl hinsichtlich der Zahl der unterstützten Anwender als auch hinsichtlich der Zahl der gespeicherten Dokumente gewährleistet sowie die Erweiterbarkeit um neue Typen und um neue Dienste sichergestellt werden. In einem ersten Schritt wurde ein Modell skalierbarer erweiterbarer orthogonaler Digitaler Bibliotheken entworfen, das die für Erweiterbarkeit und Orthogonalität notwendigen Elemente und Mechanismen identifiziert. Anhand dieses Modells erfolgte dann eine Untersuchung existierender Systeme zur Verarbeitung digitaler Dokumente im Hinblick auf ihre Eignung zur Realisierung einer skalierbaren, erweiterbaren, orthogonalen Digitalen Bibliothek. Resultat dieser Untersuchung war, daß in existierenden Systemen zur Verarbeitung digitaler Dokumente Erweiterbarkeit nur auf Kosten der Orthogonalität oder Skalierbarkeit unterstützt wird. Als Grund dafür wurde eine mangelnde Unterstützung der transparenten Erweiterung und Interpretation der Zuordnungsfunktion durch diese Systeme erkannt. Die Ursache dieses Mangels ist die unzureichende Benennung der Elemente der Zuordnungsfunktionen in den existierenden Systemen. Um eine Infrastruktur für Digitale Bibliotheken zu entwickeln, die die genannten Anforderungen erfüllt, wurden drei Maßnahmen getroffen: die Einführung einer systemweit eindeutigen Benennung der Elemente der Zuordnungsfunktion, der Entwurf eines Mechanismus zur transparenten Verteilung der Zuordnungsfunktion in der Digitalen Bibliothek und die Entwicklung eines Mechanismus zur transparenten Bereitstellung von Dokumentmethoden in den, an der Digitalen Bibliothek beteiligten Rechnerknoten. Die eindeutige Benennung wurde durch die Definition orthogonaler Operationen ermöglicht. Die Verteilung der Zuordnungsfunktion in der Digitalen Bibliothek konnte durch die Einführung von Metadokumenten erreicht werden. Das Konzept der Metadokumente basiert auf der Erkenntnis, daß die Komponenten der Digitalen Bibliothek nur die Teile der Zuordnungsfunktion benötigen, die sich auf die Dokumente beziehen, die sie bearbeiten. Diese dokumentspezifischen Teile der Zuordnungsfunktion erhält man durch Partitionieren der Zuordnungsfunktion entlang der Dimension der Dokumente. Die dokumentspezifischen Zuordnungsfunktionen werden dann zusammen mit dem Dokumentinhalt in Form eines Metadokuments zusammengefaßt. Aufgrund des Verzichts auf eine Typabbildung ist in jedem Metadokument die vollständige dokumentspezifische Zuordnungsfunktion gespeichert. Die Verteilung der Zuordnungsfunktion in der Digitalen Bibliothek ist damit allein durch den Transport des Dokumentinhalts in Form der Metadokumente möglich geworden. Die transparente Bereitstellung der Dokumentmethoden konnte durch Verwendung von mobilen Programmen zur Implementierung von Dokumentmethoden erreicht werden. Digitale Bibliotheken lassen sich so durch Erstellung eines entsprechenden Metadokuments durch den Dokumentautor transparent um neue Dokumenttypen erweitern. Es wurde gezeigt, wie auf der Basis dieser Infrastruktur eine Vielzahl verschiedener Dokumenttypen realisiert werden können. Dazu zählen Dokumente, die unterschiedliche Formen der Präsentation realisieren, sowie Dokumente zur verteilten Datenhaltung, zur Aggregation von Dokumenten und zur Realisierung zugriffsgeschützter und vertraulicher Dokumente. Die Erweiterung um neue Dienste wurde durch die Definition mobiler Dokumente ermöglicht, die die Verteilung neuer Dienstfunktionen innerhalb der Digitalen Bibliothek erlauben. Mobile Dokumente können, analog zu nicht mobilen Dokumenten, durch den Autor des Dokuments, in diesem Fall den Gestalter des Dienstes, transparent in die Digitale Bibliothek integriert werden. Zusammen mit der Möglichkeit zur Einführung neuer orthogonaler Operationen läßt sich dadurch das Dienstspektrum der Digitalen Bibliothek dynamisch erweitern. Die Elemente der Infrastruktur wurden unter der Verwendung standardisierter Protokolle und existierender Laufzeitumgebungen für interpretierte Sprachen realisiert. Auf der Basis dieser Realisierung wurden verschiedene Dokumente implementiert, anhand derer die Umsetzbarkeit der entwickelten Konzepte demonstriert werden konnte. Der Einsatz plattformunabhängiger Sprachen zur Implementierung von Dokumentmethoden ermöglicht eine Integration zukünftiger Plattformen in die Infrastruktur, ohne daß dazu eine Änderung der existierenden Dokumente und Methoden notwendig wird. In dieser Arbeit wurde eine Infrastruktur entworfen, auf deren Grundlage sich skalierbare erweiterbare orthogonale Digitale Bibliotheken realisieren lassen. Das resultierende System läßt sich durch die Dokumentautoren und Dienstgestalter transparent um neue Dokumenttypen und Dienste erweitern. Durch die konsequente Vermeidung zentraler Komponenten konnte die Skalierbarkeit des Systems in der Zahl der unterstützten Anwender sowie in der Zahl der verwalteten Dokumente sichergestellt werden. Ausgehend von den in dieser Arbeit entwickelten Konzepten können weitergehende Fragestellungen diskutiert werden. So kann die Möglichkeit zur einer engeren Integration der Präsentation aggregierter multimedialer Dokumente, wie sie z. B. im InformediaProjekt bei der synchronisierten Darstellung geographischer Regionen und darauf bezogener VideoDaten vorgenommen wird (vgl. [13]), untersucht werden. Eine Integration unterschiedlicher Dokumente im Präsentationsraum könnte durch die Definition einer orthogonalen MultimediaPresentOperation geschehen, die die Angabe von Koordinaten im Dokument und Präsentationsraum, wie sie z. B. in HyTime [64] möglich ist, zur Kontrolle der Präsentation erlaubt. In der vorliegenden Arbeit wurde der Schutz einzelner AusführungsServer gegen böswillige Dokumentmethoden behandelt. Mit der Möglichkeit zur Erstellung mobiler Dokumente verdient der Schutz des ServerVerbundes zur Begrenzung der Ressourcennutzung durch einen Initiator ebenfalls eine eingehendere Betrachtung. Hier könnten Konzepte aus Infrastrukturen für mobile Agenten, z. B. AgentTcl [42], angepaßt werden, z. B. die Kontingentierung der Ressourcennutzung auf den Rechnerknoten innerhalb einer administrativen Domäne und die Verwendung elektronischen Geldes zur Limitierung der Ressourcennutzung durch mobile Dokumente, die sich zwischen mehreren administrativen Domänen bewegen. Zur Effizienzsteigerung könnten Verfahren zur Übersetzung von plattformunabhängigem Zwischencode in nativen Code der Zielmaschine, wie sie beispielsweise in [33] beschrieben sind, eingesetzt werden. In diesem Zusammenhang sind geeignete Mittel für eine Durchsetzung der Sicherheitsanforderungen auszuwählen und ihr Einfluß auf den zu erwartenden PerformanceGewinn zu untersuchen.
Die Integration von Dienstgüte-Vorkehrungen in objektorientierte Verteilungsinfrastrukturen befähigt Anwendungsentwickler, den Verteilungs-induzierten Problemen verteilter Systeme zu begegnen. Im Rahmen dieser Arbeit wurde die generische Einbettung von Dienstgüte-Vorkehrungen in verteilte Objektsysteme untersucht und ein Lösungsansatz präsentiert. Zunächst wurde eine Analyse der für das Dienstgüte-Management notwendigen Aufgaben vorgestellt. Ausgehend von einem verteilten Objektmodell wurde untersucht, wie Dienstgüte-Vorkehrungen integriert werden können. Dienstgüte-Vorkehrungen stellen bei einem zugrundeliegenden Ob- jektmodell nicht-einkapselbare Verantwortlichkeiten dar. Die enge Bindung der Dienstgüte-Vorkehrungen an einen Dienst führt so zu Vermaschungen in den Strukturen der Implementierung. Damit ist die getrennte Wieder- verwendung beider erschwert. Zusätzlich werden unterschiedliche Abstrak- tionen vermischt. Die aspektorientierte Programmierung (AOP) behandelt solche Vermaschungen. Dienstgüte wurde bei der Integration in ein verteil- tes Objektmodell als ein Aspekt im Sinne der AOP klassifiziert. Ausgehend von den Anforderungen an das Dienstgüte-Management wur- de ein Rahmenwerk auf Basis eines verteilten Objektmodells entworfen. Der in dieser Arbeit dargestellte Schwerpunkt liegt auf der Spezifikation von Dienstgüte-Charakteristiken und deren Umsetzung in die Implementie- rungssprache der Anwendungsobjekte. Für die Unterstützung der Ende-zu- Ende-Dienstgüte-Erbringung ist der Einbezug von Dienstgüte-Vorkehrun- gen des Netzwerks, Betriebssystems oder spezieller Bibliotheken notwendig. Die resultierende Hierarchie von Dienstgüte-Mechanismen wird durch die vorgestellte Integration in eine Verteilungsinfrastruktur unterstützt. Durch die Integration der Dienstgüte-Spezifikation in die Schnittstel- lenbeschreibungssprache erlaubt das Rahmenwerk einen aspektorientierten Ansatz ohne die Einführung weiterer Sprachen zur Spezifikation oder Im- plementierung. Die Spezifikation von Dienstgüte-Charakteristiken in der erweiterten IDL wird in spezielle Entwurfsmuster in der Zielsprache umge- setzt. Diese Entwurfsmuster separieren die Anwendungsobjekte weitgehend von den Dienstgüte-Vorkehrungen. Die auf der Ebene der Anwendungsobjekte generierten Vorlagen für die Dienstgüte-Vorkehrungen können durch einen modifizierten bzw. schon da- für ausgelegten Verteilungsinfrastrukturkern in das System integriert wer- den. Eine einheitliche statische Schnittstelle erlaubt einen einfachen re- effektiven Ansatz. So ist der Zugriff auf Dienstgüte-Vorkehrungen tieferer Schichten wie auch die Integration anwendungsspezifischer Dienstgüte-Vor- kehrungen auf der Netzwerkschicht möglich. Das Rahmenwerk bietet somit eine klare Trennung der Verantwortlich- keiten, die sowohl Anwendungsentwickler wie auch Dienstgüte-Implemen- tierer unterstützt. Die aus der Schnittstellenbeschreibungssprache generier- ten Einheiten stellen für die Anwendungsobjekte eine Abstraktion dar, die sowohl die Verteilungsaspekte wie auch die Dienstgüte-Vorkehrungen ein- fach nutzbar anbietet und von der zugrundeliegenden Plattform isoliert. Eine sich aus dieser Arbeit ergebende Fragestellung besteht in der Er- weiterung und Verallgemeinerung des aspektorientierten Ansatzes. Die im Rahmen der Analyse betrachteten Dienstgüte-Charakteristiken sind aus dem systemnahen Bereich und insbesondere aus der Betrachtung typi- scher Probleme in verteilten Systemen und den daraus erwachsenen Anwen- dungsanforderungen gewonnen. Nicht-funktionale Aspekte der Dienster- bringung lassen sich weiter fassen. So kann ausgehend von den bereitge- stellten Abstraktionen untersucht werden, inwieweit auf Anwendungsebe- ne nicht-funktionale Eigenschaften in ähnlicher Weise einbettbar sind. Im Rahmen dieser Arbeit wurde beispielsweise eine Dienstgüte-Charakteristik zur Parallelisierung von Berechnungen realisiert. Eine anwendungsbezogene Dienstgüte-Charakteristik könnte numerische Optimierungen realisieren, die von den reinen mathematischen Operationen zu trennen ist. Andere Beispiele aus der Multimedia-Kategorie sind durch die Qualität einer Au- dio-Übertragung gegeben. So kann bei einer geringen Bandbreite durch die Kompression der Daten eine bessere Qualität der Audiowiedergabe ereicht werden, als durch Übertragung der Rohdaten. Die Kompressionsrate kann von der Anwendung isoliert und durch entsprechende Dienstgüte-Mecha- nismen realisiert werden. Qualitätsunterschiede ergeben sich durch mögli- che verlustbehaftete Kompression und de notwendigen Anforderungen an Hardware- oder Software-Unterstützung. Andere Kriterien für die Qualität lassen sich weniger leicht vor der Anwendung verbergen. Die Wiedergabe von Stereo- oder Mono-Audiodaten erfordert entsprechende Anwendungen und auch Ausstattungen der Endgeräte. Im Kontext dieser Arbeit wurde ein Objektmodell betrachtet, das eine starke Bindung zwischen Schnittstellen und Objekten besitzt. Insbeson- deren wurde bei der Umsetzung der Schnittstellenbeschreibungssprache in die Zielsprache eine Umsetzung gewählt, die Dienste als Objekte reprä- sentiert. Involviert die Diensterbringung verschiedene Objekte, kann nur ein Objekt als Stellvertreter all dieser Dienste den Service anbieten. Dieses Objekt ist für die Einhaltung von Dienstgüte-Vereinbarungen mit Klien- ten verantwortlich. Innerhalb der Objekte, die den Service realisieren, sind für die Dienstgüte-Erbringung dann ggf. weitere interne Dienstgüte-Vor- kehrungen zu etablieren. Komponentenmodelle versprechen hier einen all- gemeineren Ansatz, der die Integration von Dienstgüte-Vorkehrungen loh- nenswert erscheinen lässt. Zum einen unterstützen Komponentenmodelle definierte Schnittstellen zur Interaktion zwischen den beteiligten Objek- ten einer Komponente, und zum anderen bieten Komponenten eine über die Schnittstellenbeschreibungssprache hinausgehende Beschreibung ihrer Funktionalität in einer Komponentenspezifikation. Diese Komponentenspe- zifikation verspricht einen guten Ansatz, um Dienstgüte-Spezifikationen der Komponenten zu integrieren. Neben den beiden bislang beschriebenen Forschungsrichtungen, die je- weils ein Rahmenwerk für das Dienstgüte-Management voraussetzen und darauf aufbauen, existieren innerhalb des in der Arbeit vorgestellten Rah- menwerkes weitere offene Forschungsfragen. Die Ausgestaltung von Preisen bei der Vergabe von Ressourcen und die damit verbundenen Richtlinien für die Vergabe und auch den Entzug stellen noch kein abgeschlossenes Gebiet dar. Hier ist der Einbezug anderer Disziplinen vielversprechend. Preisrichtlinien für manche Ressourcen, die bei Nicht-Nutzung verfallen wie Netzwerkkapazität sind Gegenstand der Forschung in der Betriebs- wirtschaftslehre. Die Gestaltung von Vergaberichtlinien, insbesondere aber die Festlegung von Vergütungen bei Nichterbringung eines festgesetzten Dienstgüte-Niveaus oder Kompensationen bei dem Entzug von Ressourcen mit einer damit einhergehenden Verletzung der Dienstgüte-Vereinbarung, wirft rechtliche Fragen über die Gültigkeit solcher Richtlinien auf. Weitere, nicht-interdisziplinäre Fragestellungen, ergeben sich aus der Frage der Wiederverwendbarkeit und Dokumentation von Dienstgüte-Vor- kehrungen im Rahmenwerk. Die Erstellung eines Katalogs mit einem ein- heitlichen Aufbau wie es bei Entwurfsmustern üblich ist verspricht eine geeignete Dokumentationsform. Allerdings muss eine solche Dokumentati- on zwei Zielgruppen gerecht werden. Zum einen sind dies Anwendungsent- wickler, die eine gegebene Dienstgüte-Implementierung anwenden wollen und Informationen für die Nutzung und Anpassung der Anwendung benö- tigen und zum anderen Dienstgüte-Entwickler, die auf bereits existierende transportspezifische Dienstgüte-Mechanismen aufbauen. Für die hier skizzierten Forschungsrichtungen ist ein Rahmenwerk für das Dienstgüte-Management unerlässlich. Das in dieser Arbeit vorgestellte Rahmenwerk bietet eine gute Ausgangsbasis.
Wir haben Interaktion in der Kommunikationskomplexität untersucht und dabei die drei Modi probabilistische, (beschränkt) nichtdeterministische und quantenmechanische Kommunikation betrachtet. Bei allen drei Modi haben wir herausgefunden, dass Interaktion für Effzienz oft unerlässlich ist, im nichtdeterministischen Fall gibt es eine Abhängigkeit zwischen dem Einfluss der Interaktion und der erlaubten Anzahl der nichtdeterministischen Ratebits. Abgesehen von dem erreichten besseren Verständnis des Kommunikationsmodells haben wir verschiedene Anwendungen auf andere Berechnungsmodelle beschrieben, bei denen untere Schranken der Kommunikation zu unteren Schranken für andere Ressourcen in diesen Modellen geführt haben. Ein Beispiel eines kommunikations- und interaktionsbeschränkten Modells sind endliche Automaten, welche wir in allen drei Modi untersucht haben. Ein weiteres Beispiel sind Formeln, für die wir eine Verbindung zwischen Einweg Kommunikation und Formellänge herstellen konnten. Diese Verbindung führte zu unteren Schranken für probabilistische, nichtdeterministische und Quanten Formeln. Dabei sind die unteren Schranken für Quanten Formeln und probabilistische Formeln im wesentlichen gleich. Für monotone Schaltkreise haben wir gezeigt, wie nichtdeterministisches Raten die Tiefe drastisch reduzieren kann, und wie eine geringfügige Einschränkung der nichtdeterministischen Ratebits zu einer Tiefenhierarchie führt. Insgesamt lässt sich feststellen, dass die Schwäche interaktionsbeschränkter Kommunikation mathematisch nachvollziehbar ist. Außerdem scheint ein solches Verhalten in der Welt einfacher Berechnungsmodelle häufig aufzutreten. Oder anders gesagt, viele Berechnungsmodelle sind deshalb einfacher zu verstehen, weil sie durch interaktionsbeschränkte Kommunikation analysierbar sind.
Schemaevolution in objektorientierten Datenbanksystemen auf der Basis von Versionierungskonzepten
(2000)
Gegenstand dieses Kapitels ist zunächst die Zusammenfassung der in dieser Arbeit erreichten Ergebnisse im Hinblick auf die ursprüngliche Zielsetzung, also die Unterstützung von Schema evolution in objektorientierten Datenbanksystemen. Anschließend folgen Überlegungen, welche der erzielten Ergebnisse zur Lösung von Problemen in anderen Arbeitsbereichen herangezogen werden können und auf welche Weise dies geschehen kann. Die Arbeit schlie?t mit einem Ausblick auf weitere Arbeiten im von uns bearbeiteten Themengebiet. Erreichte Ziele Ausgangspunkt unserer Arbeit war die Beobachtung, dass die Evolution von Datenbankschema ta, welche zur Anpassung an sich ändernde funktionale und nichtfunktionale Anforderungen 130 der Diskurswelt benötigt wird, durch die gegenwärtig verfügbaren Modelle und Systeme nicht adäquat unterstützt wird. Wir stellten daraufhin die Hypothese auf, dass ein Modell auf der Basis der Versionierung von Schemata mit einer entsprechenden Abbildung der Änderungen auf die Objektebene dies leisten kann. Wir konnten in dieser Abhandlung zeigen, dass das nach diesen Gesichtspunkten entworfene COASTModell die daran gestellten Erwartungen erfüllt und Sche maänderungen in Gegenwart existierender Objekte und Applikationen erfolgreich realisierbar sind. Die einzelnen Arbeitsschritte und Ergebnisse ergaben sich dabei wie folgt: - Problemanalyse und grober Modellentwurf: Die Notwendigkeit einer Unterstützung für Schemaevolutionsprozesse ergab sich aus der Beobachtung, dass vor allem moderne An wendungsbereiche eine flexible Anpassung an ständig veränderliche Umstände erfordern. Während des Betriebs einer Datenbank aufkommende Änderungsanforderungen lassen sich zur Entwurfszeit nicht vorhersehen und sind im Rahmen fest vorgegebener Datenbanksche mata nur schwerlich adäquat umsetzbar. Wir konnten in diesem Zusammenhang bei den vorhandenen Systemen zur Unterstützung der Schemaevolution das Fehlen einer Berück sichtigung im Betrieb beøndlicher Datenbankapplikationen feststellen. Gleichzeitig blieben Anforderungen an flexibel koppelbare Datenbankzustände für verschiedene Schemaausprä gungen bisher unberücksichtigt. Das an dieser Stelle grob skizzierte Modell zur Lösung des Problems beruhte folgerichtig auf dem Einsatz von Versionierungskonzepten auf der Ebene der Datenbankschemata. Solche Versionierungskonzepte hatten ihre Fähigkeiten zur Unterstützung von Evolutionsprozessen insbesondere auch im Zusammenhang mit Entwurfsaufgaben bereits zuvor sowohl auf der Ebene kompletter Datenbanken als auch auf der einzelner Objekte nachgewiesen. - Untersuchung bestehender Lösungsansätze: Wir konnten für das Lösungsmodell vier ele mentare Aspekte identiøzieren: Durchführung von Änderungen auf Schemaebene unter Verwendung von Versionierungskonzepten, Erzeugung und Verwaltung der Abhängigkeits beziehungen zwischen den Schemaversionen, Abbildung der Änderungen auf die Objekt ebene sowie flexible Konzepte zur Steuerung und Durchführung der Objektpropagation. Da kein Modell existierte, das all diese Punkte berücksichtigt, mussten wir uns in der Literatur recherche auf Ansätze beschränken, die sich mit einzelnen Aspekten unserer Aufgabenstel lung befassen. Aus dieser Perspektive stellt sich unser Modell zu einem Teil als Integration früherer Arbeiten dar. Zum anderen Teil beruht unser Modell in den grundlegenden Aspek ten der Behandlung von Ableitungsbeziehungen sowie der Steuerung und Durchführung der Objektpropagation auf gänzlich neuen Ansätzen. Die wesentliche Erkenntnis dieses Arbeitsschrittes ist somit die Feststellung, dass einerseits verschiedene Konzepte bestehen der Ansätze übernommen werden konnten, obwohl keine Arbeit alle Anforderungen an unser Modell erfüllte, und andererseits einige Aspekte bislang nahezu vollständig ignoriert wurden. - Detaillierte Modellbildung: Aufgrund der Erkenntnisse über bestehende Arbeiten entwarfen wir in diesem Arbeitsschritt COAST als Modell zur Durchführung von Schemaänderun gen in Anwesenheit von Objekten und Applikationen. Grundbestandteile unseres Ansatzes sind die Schemaversionen, die vergleichbar einer Konøgurationsverwaltung semantisch in Zusammenhang stehende Klassenversionen zu konsistenten Teilstrukturen zusammenset zen. Für die Durchführung von Schemaänderungen haben wir zwei grundsätzlich verschiedene Wege analysiert und resultierende Konsequenzen studiert. Dem internen Ansatz folgend wird eine von dem jeweiligen Einsatzgebiet des Systems unabhängige, fest vorgegebene und konzeptionell vollständige Taxonomie von Schemaänderungsprimitiven bereitgestellt, de ren Semantik a priori bekannt ist und demzufolge bei allen weiteren Schritten auf Schema und Objektebene berücksichtigt werden kann. Der externe Ansatz, als Alternative, erlaubt die Durchführung applikationsspezifischer Schemaänderungen und erhöht damit die Flexi bilität. Der Prozess des Einbringens extern erstellter Schemaversionen in das System kann dabei in vielfältiger Weise unterstützt werden. Bemerkenswerterweise fanden sich die auf Schemaebene angewandten Konzepte analog auf Instanzenebene wieder und zwar bei den Objektversionen, deren Zusammenhang sich in Form von Propagationsgraphen widerspiegelt ähnlich den Ableitungsbeziehungen auf Sche maebene. Die Steuerung der Objektpropagation sowohl zum Zeitpunkt der Schemaände rung als auch später, als Reaktion auf verändernde Datenbankzugrioee ist im behandelten Umfeld mit Sicherheit einzigartig. - Validierung des Modells: Aussagen zur Tauglichkeit des Modells im Hinblick auf seine Kon zeptionsziele konnten wir durch eine Evaluierung anhand unserer sehr detailliert beschrie benen Vorgaben erhalten. Damit ist gleichzeitig ein Vergleich mit bisherigen Lösungswegen insgesamt und mit einzelnen Vertretern davon gegeben. Die Evaluierung konnte in allen Aspekten belegen, dass das COASTModell zur Unterstützung von Schemaänderungen in Benutzung befindlicher Datenbanksysteme gut geeignet ist. Wir möchten an dieser Stelle nochmals betonen, dass COAST in vielerlei Hinsicht einfach erweitert werden kann und im Vergleich zu bisherigen Systemen durch erheblich flexiblere Möglichkeiten der Einflussnahme und eine verbesserte Tauglichkeit ausgezeichnet wird. Zu nächst sind sowohl die hier vorgestellte Schemaänderungstaxonomie als auch die damit ver bundene Propagationssprache vielfältig um komplexe Operationen erweiterbar. Weiterhin kann die Menge verwendbarer Propagationsflags insbesondere mit Blick auf das Verhalten bei komplexen Schemaänderungen hin ergänzt werden. Aber bereits die hier dargestell ten Möglichkeiten der Propagationssteuerung decken das gesamte Spektrum von isolierten Schemaversionen am einen Ende bis hin zur kompletten Propagation am anderen Ende ab. In Erweiterung der Konzepte auf der Basis von Sichtenmechanismen können durch die Objektversionierung beliebige Änderungen des Datenbankzustandes durchgeführt wer den. Damit wird ein erheblicher Beitrag für die Transparenz der Schemaevolution für die Applikationsentwickler geleistet. Die für die Tauglichkeit wichtigste Eigenschaft besteht zweifelsfrei in der Möglichkeit, be stehende Applikationen auch noch nach der Durchführung von Schemaänderungen ohne Anpassung weiterverwenden zu können. Damit erweitert sich der Einsatzbereich von Sche maänderungen auf sehr große, komponentenbasierte Systeme auf der Basis zahlreicher Einzelapplikationen. - Hinweise für den Datenbankentwurf: Um den Schemaversionierungmechanismus adäquat einsetzen zu können, erweisen sich Aussagen über den Schemaänderungsprozess als notwen dig. Daher haben wir diesen Prozess systematisch in Teilschritte zerlegt, die nacheinander betrachtet werden können. Bereits während der Modellbildung haben wir dort, wo sich ei nem Schemaentwickler Alternativen im Umgang mit COAST bieten, diese aufgezeigt und ihre jeweiligen Konsequenzen untersucht. Im Ergebnis resultiert für den Schemaentwick ler im Vergleich zu unversionierten Systemen ein zusätzlicher Spezifikationsaufwand. Dies ist jedoch für die Erreichung unserer Ziele unvermeidbar und der Gesamtaufwand für die Durchführung einer Schemaänderung reduziert sich dem Versionierungskonzept folgend er heblich, nicht zuletzt, weil aus der Sicht der Applikationsentwickler die volle Transparenz gewährleistet wird. - Realisierungsbetrachtungen: Um Erkenntnisse über den Realisierungsaufwand sowie die zu erwartenden Leistungsmerkmale zu erhalten, haben wir zweierlei Ansätze für eine pro totypische Realisierung untersucht. Zum einen haben wir einen Schemaversionierungsme chanismus als Aufsatz auf dem kommerziellen Objektdatenbanksystem O 2 implementiert. Auch wenn sich dies konzeptionell als möglich erwiesen hat, so haben sich dort an mehre ren Stellen erhebliche Einbußen bezüglich der Transparenz gezeigt [Wöh96]. Daher haben wir uns verstärkt mit dem zweiten, deutlich aufwendigeren Weg beschäftigt: die Eigenent wicklung eines kompletten, objektorientierten Datenbankmanagementsystems, bei dem die Konzepte von COAST transparent und von Anfang an im Kern integriert werden konnten. Die Realisierung der verzögerten Propagation kann bei realistischen Zugriffsprofilen mit einer gewissen Lokalität bezüglich der Schemaversionen größenordnungsmäßig mit unver sionierten Systemen vergleichbare Laufzeiten erreichen. Konzeptionell bedingt muss zwar ein größerer Platzbedarf als bei einem statischen System (ohne Schemaänderungen) in Kauf genommen werden. Im Vergleich zu anderen Konzepten der Schemaevolution, etwa den Ansätzen auf der Basis von isolierten Datenbanken oder mit materialisierten Sichten tritt aber kein Mehraufwand auf. In all diesen Varianten wird, ähnlich wie bei Puffern absichtlich Platz zugunsten einer erhöhten Zugriffsgeschwindigkeit investiert. Je ähnlicher sich verschiedene Schemaversionen sind und je intensiver die Propagation zwischen ihnen demnach ausfällt, desto besser sind die Voraussetzungen für platzsparende Mechanismen auf der Basis von mehreren Schemaversionen gemeinsam genutzter Objektversionen. In die sem Zusammenhang konnten wir eine Reihe von Verbesserungsmöglichkeiten identifizieren, die den COASTPrototyp Systemen auf der Basis von Sichtenmechanismen gleichstellen würden. Übertragbarkeit der Ergebnisse Die Tragfähigkeit der Konzepte des COASTModells für die Unterstützung evolutionärer Sche maänderungen haben wir erfolgreich belegen können. Im folgenden sprechen wir noch einige Möglichkeiten an, die in dieser Abhandlung gewonnenen Erkenntnisse auch im Zusammenhang mit anderen Konzepten einzusetzen. - Abschnitt 2.2 hatte allgemeine Versionierungskonzepte vorgestellt, wie sie typischerweise auf Objekte angewendet werden, um deren inhaltliche Evolution abzubilden. Wir haben dieselben Konzepte in der vorliegenden Arbeit auf Schemata als Instanzen der Metaebene angewendet, um deren evolutionäre Entwicklung zu unterstützen. Dabei hat sich die Ver wendung versionierter Datenbankobjekte ebenfalls als sehr hilfreich erwiesen. Die Versio nen eines Objektes bei der Schemaversionierung repräsentieren ein Objekt in verschiedenen Datentypen. Von Situationen abgesehen, in denen das Modifikationsflag abgeschaltet ist und Änderungen daher gewollt nicht propagiert werden, repräsentieren die Versionen eines Objektes denselben logischen Objektwert. Damit unterscheiden sich die hier verwendeten Objektversionen von denen der klassischen Objektversionierung. Letztere stellen nämlich verschiedene logische Objektwerte dar, die allerdings alle demselben Datentyp entsprechen. Die vorangegangene, vergleichende Betrachtung zeigt einerseits, dass die beiden Formen der Versionierung unterschiedliche Ziele verfolgen, und andererseits legt sie die Vermutung nahe, dass es sich um orthogonale und damit gewinnbringend kombinierbare Ansätze han delt. Verschiedene Typen zur Darstellung desselben logischen Objektwertes hier stehen verschiedenen Objektwerten desselben Typs dort gegenüber. Tatsächlich lässt sich unser Ansatz um Mechanismen zur Objektversionierung erweitern, indem jede unserer Objektversionen nun durch verschiedene klassische Objektversionen ersetzt wird. Damit entsteht ein zweidimensionaler Raum von Objektversionen: entlang der einen Dimension liegt jeweils ein logischer Objektwert in verschiedenen Typen, entlang der anderen Dimension liegen jeweils verschiedene logische Zustände eines Objektes, die durch denselben Typ repräsentiert werden. Um die Kombination der beiden Versionierungskonzepte zu erreichen, sind allerdings noch einige Fragen näher zu untersuchen. Diese beschäftigen sich beispielsweise mit dem Zu sammenhang zwischen den Objektversionen entlang der beiden Dimensionen und mit der Propagation versionierter Objekte. Hier ist beispielsweise zu klären, ob alle, oder wenn nicht welche der logischen Objektwerte eines Objektes in andere Schemaversionen zu pro pagieren sind. Schließlich bietet die Realisierung des integrierten Gesamtkonzeptes zahl reiche Ansatzpunkte für technische Optimierungen und erfordert diese auch, um sowohl den Zeitaufwand für die Propagation als auch den Platzbedarf für die Speicherung der zweidimensional versionierten Objekte zu reduzieren. - Wir waren in der Literaturrecherche auf das Sichtenkonzept als Grundlage zur Simulati on von Schemaänderungen eingegangen und hatten dabei einige Deøzite bei der Lösung der hier betrachteten Aufgabenstellung identiøziert. Dies impliziert jedoch keine Aussa ge über die Tragfähigkeit von Sichten in dem Umfeld, für das sie ursprünglich konzipiert worden waren. Aufgrund der mit COAST erzielten Transparenz, die eine Schemaversion nach außen hin wie ein Schema eines unversionierten Systems erscheinen läßt, kann ein Sichtenkonzept auf dem COASTModell aufgesetzt werden. Konzeptionelle Schwierigkei ten sind durch die Kombination von Sichten und Schemaversionen nicht zu erwarten: Beim Ableiten neuer Schemaversionen können auf den Vorgängern definierte Sichten bei Bedarf mitintegriert werden und das Anlegen, Ändern und Löschen von Sichten kann durch die Primitive des Sichtenmechanismus erfolgen. In einem beide Konzepte integrierenden System kann entsprechend der gestellten Anforderungen entschieden werden, ob diese besser durch Anlegen einer neuen Sicht oder durch Ableiten einer neuen Schemaversion erfüllt werden. - Einen Schritt über die Integration eines separaten Sichtensystems hinaus geht die Über legung, ob Sichten nicht sogar durch Schemaversionen simuliert werden können. Damit wäre dann auch eine vollständig homogene Integration beider Konzepte in einem System erreicht. Um diese Überlegung zu verfolgen, betrachten wir die konzeptionellen Kompo nenten eines Sichtensystems und analysieren kurz, wie diese auf die Konzepte von COAST abgebildet werden können. Die für den Schemaentwickler zu verwendende Schnittstelle eines Sichtensystems ist durch die Sichtendefinitionssprache gegeben. Die dort zur Verfügung stehenden Konstrukte die nen zunächst der Definition des Sichtschemas und sind insoweit durch die Primitive der COASTODL abgedeckt. Darüber hinaus bestimmt eine Sichtendefinition die Extension der Sichtklassen durch Angabe je einer Anfrage, wobei das Ergebnis dieser Anfrage dem Schema der definierten Sichtklasse entsprechen muss bzw. dieses implizit erst bestimmt. Um diesen Teil eines Sichtenkonzeptes zu simulieren, sind in COAST zwei Erweiterungen not wendig. Zum einen wird eine Anfragesprache benötigt. Diese wäre für die Vervollständigung von COAST sowieso erforderlich und könnte sich konzeptionell sehr stark an bestehenden objektorientierten Anfragesprachen orientieren. Ein Anfragesystem muss zu jeder Anfrage zunächst das Schema ihres Resultates ermitteln und dieses könnte dann mit den Primiti ven der COASTODL erstellt werden. Daraufhin muss das Anfragesystem die eigentliche Durchführung der Anfrage auf der Datenbank erledigen. Dies beschreibt gleichzeitig die zweite in COAST erforderliche Erweiterung. Für die Durchführung der Anfrage und ins besondere der darin ggf. enthaltenen Selektion von Objekten müsste eine entsprechende Erweiterung der Propagationssprache von COAST vorgenommen werden. Änderungen von Objekten in Sichtklassen sind aufgrund des Sichtenänderungsproblems i.Allg. nicht durchführbar, da in der Sichtendefinitionssprache keine Möglichkeit besteht, die Auswirkungen einer solchen Änderung auf die Objekte des Basisschemas zu spezifi zieren. Daher bieten einige Konzepte Erweiterungen an, die man in COAST durch Ver wendung von Rückwärtskonvertierungsfunktionen bereits hat. Durch die Vorwärts und Rückwärtskonvertierungsfunktionen können beide Richtungen von Abbildungen zwischen (simuliertem) Basisschema und (simuliertem) Sichtschema sogar homogen durch dasselbe Konzept spezifiziert werden. Die Propagationsflags wären zur Simulation alle eingeschaltet und durch die Verwendung der verzögerten Propagationsmechanismen von COAST liefert die Simulation von Sich ten durch Schemaversionen zusätzlich ein optimiertes Konzept der Materialisierung von Sichten. - Das Konzept der direkten Schemaevolution hatte sich bei der Anwendung in dem hier beschriebenen Einsatzgebiet als zu restriktiv erwiesen. Nichtsdestotrotz kann die direkte Schemaevolution in Einzelfällen für die Durchführung von Schemaänderungen genügen, insbesondere solange noch keine Applikationen für eine Schemaversion implementiert sind. Folgerichtig können Situationen entstehen, wo selbst eingefrorene Schemaversionen noch in eingeschränktem Umfang änderbar wären, auch wenn dies i.Allg. nicht der Fall ist. Daher haben wir eine Kombination der direkten Schemaänderung mit dem Versionierungsansatz auf der Basis des Datenmodells von O 2 untersucht [FL96] (siehe Abschnitt 5.4.2). Dort konnten wir durch eine Klassiøkation der Schemaänderungsprimitive feststellen, ob den im Einzelfall gegebenen Umständen zufolge die Ableitung einer neuen Schemaversion erfor derlich ist oder nicht. Auf diesem Wege kann die Zahl entstehender Schemaversionen und damit auch der sich ergebende Verwaltungsaufwand reduziert werden. - Die in Datenbanksystemen benötigten Änderungsoperationen lassen sich drei elementaren Kategorien zuordnen:
This thesis has explored how structural techniques can be applied to the problem of formal verification for sequential circuits. Algorithms for formal verification which operate on non-canonical gate netlist representations of digital circuits have certain advantages over the traditional techniques based on canonical representations as BDDs. They allow to exploit problem-specific knowledge because they can take into account structural properties of the designs being analyzed. This allows us to break the problem down into sub-problems which are (hopefully) easier to be solved. However, in the past, the main application of such structural techniques was in the field of combinational equivalence checking. One reason for this is that the behaviour of a sequential system does not only depend on its inputs but also on its internal states, and no concepts had been developed to-date allowing structural methods to deal with large sets of states. An important goal of this research was therefore to develop structural, non-canonical forms of representing the reachable states of a finite state machine and to develop methods for reachability analysis based on such representations. In order to reach this goal, two steps were taken. Firstly, a framework for manipulating Boolean functions represented as gate netlists has been established. Secondly, using this framework, a structural method for FSM traversal was developed serving as the basis for an equivalence checking algorithm for sequential circuits. The framework for manipulating Boolean functions represented as multi-level combinational networks is based on a new concept of an implicant in a multi-level network and on an AND/ORtype enumeration technique which allows us to derive such implicants. This concept extends the classical notion of an implicant in two-level circuits to the multi-level case. Using this notion, arbitrary transformations in multi-level combinational networks can be performed. The multi-level network implicants can be determined from AND/OR reasoning graphs, which are associated with an AND/OR reasoning technique operating directly on the gate netlist description of a multi-level circuit. This reasoning technique has the important property that it is complete, i.e. the associated AND/OR trees contain all prime implicants of a Boolean function at an arbitrary node in a combinational circuit. In other words, AND/OR graphs constructed for a network function serve as a representation of this function. A great advantage over BDDs is that AND/OR graphs, besides representing the logic function, also represent some structural properties of the analyzed circuitry. This permits to develop heuristics that are specially tailored for certain applications such as logic optimization or verification. Another advantage which is especially useful for logic optimization is the fact that the proposed AND/OR enumeration scheme is not restricted to the use of a specific logic alphabet such as B3 = {0, 1, X}. By using Roth’s D-calculus based on B5 = {0, 1, D, D-Komplement} permissible implicants can be determined. Transformations based on permissible implicants exploit observability don’t-care conditions in logic synthesis by creating permissible functions at internal network nodes. In order to evaluate the new structural framework for manipulating Boolean functions represented as gate netlists, several experiments with implicant-based optimization of multi-level circuits were performed. The results show that implicant-based circuit transformations lead to significantly better optimization results than traditional synthesis techniques. Next, based on the proposed structural methods for Boolean function manipulation, techniques for representing and manipulating the set of states of a sequential circuit have been developed. The concept of a “stub circuit” was introduced which implicitly represents a set of state vectors as the range of a multi-output function given as a gate netlist. The stub circuit is the result of an existential quantification operation which is obtained by functional decomposition using implicant-based netlist transformations and a network cutting procedure. Using this existential quantification operation, a new structural FSM traversal algorithm was formulated which performs a fixed point iteration on the set of reachable states represented by the stub circuit. The proposed approach performs a reachability analysis of the states of a sequential circuit. It operates on gate netlists and naturally allows to incorporate structural properties of a design under consideration into the reasoning. Therefore, structural FSM traversal is an interesting alternative to traditional symbolic FSM traversal, especially in those applications of formal verification, where structural properties can be exploited. Structural FSM traversal was applied to the problem of sequential equivalence checking. Here, structural similarities between the designs to be compared can effectively reduce the complexity of the verification task. The FSM to be traversed is a special product machine called sequential miter. The special structural properties of this product machine have made it possible to formulate an approximate algorithm for structural FSM traversal, called record and play(). This algorithm uses an approximation on the reachable state set represented by the stub circuit which is very beneficial for performance. Instead of calculating the stub circuit using the exact algorithm, implicant-based transformations directly using structural design similarities are performed. These transformations, together with existential quantification implemented by the cutting procedure, lead to an over-approximation of the reachable state set. By this overapproximation, only such unreachable product states are added to the set of states represented by the stub circuit which are unreachable at the current point in time but which are nevertheless equivalent. Therefore, more product states are added to the set of reachable states sometimes leading to drastic acceleration of the traversal, i.e. the fixed point is reached in much fewer steps. The algorithm record and play() was applied to the problem of checking the equivalence of a circuit with its optimized and retimed version. Retiming is a form of sequential circuit optimization which can radically alter the state encoding of a circuit. Traditional FSM traversal techniques often fail because the BDDs needed to represent the reachable state set and the transition relation of the product machine become too large. Experiments were conducted to evaluate the performance of record and play() on a standard set of sequential benchmark circuits. The algorithm was capable of proving the equivalence of optimized and retimed circuits with their original versions, some of which (to our knowledge) have never before been verified using traditional techniques like symbolic FSM traversal. The experimental results are very promising. Future research will therefore explore how structural FSM traversal can be applied to model checking.
Funktionsorientierte Bausteine zur Integration kontinuierlicher Medien in verteilte Anwendungen
(1997)
Das Ziel der vorliegenden Arbeit war die Entwicklung einer komfortablen Beschreibung verteilter Anwendungen, die kontinuierliche Medien integrieren. Die Klarheit des Ansatzes ergibt sich aus der Beschränkung auf die anwenderrelevanten Funktionalitäten. Weitere Gebiete, die systembezogen sind, wurden nur soweit wie nötig behandelt. Die Aufgaben anderer Bereiche, wie des Betriebssystems und des Managementsystems sowie der Kommunikationsdienste, konnten nur gestreift werden, indem die anwendungsabhängigen Anforderungen spezifiziert wurden. Durch deren Extraktion und die Zuordnung der Anforderungen an die einzelnen Bereiche, ergibt sich eine klarere Sicht auf Betriebssystem, Management und Kommunikationsdienste und deren notwendige Weiterentwicklung. Das entwickelte Funktionenmodell beschreibt zusammenhängend alle mit kontinuierlichen Medien verbundenen Arbeiten. In der vorliegenden Arbeit wurde gezeigt, wie aus den Funktionen auf kontinuierlichen Medien durch die Spezifikation geeigneter Schnittstellen Bausteine zur Integration der Medien in verteilte Anwendungen erstellt werden. Die Beschrei bung der Bausteine erfolgt durch diese Schnittstellen; es sind Steuer-, Daten- und Managementschnittstellen. Die Herauslösung der gesonderten Beschreibung der Multimedia-Datenflußstruktur schafft einerseits die Grundlage für eine Teilklassifikation der Anwendungen nach Medien-Gesichtspunkten. Andererseits kann die Erstellung einer Anwendung aus einer bestimmten Anwendungsklasse, wie zum Beispiel ein einfaches Wiedergabesystem, durch die gesonderte Beschreibung der Multimedia-Datenflußstruktur schneller in der Bausteinstruktur realisiert werden. Das Funktionenmodell wird auch in [Fritzsche96] beschrieben. Das in dieser Arbeit konzipierte Bausteinmodell gewährleistet eine integrierte Beschreibung von Geräten, Werkzeugen und Anwendungen kontinuierlicher Medien. Die verwendete Beschreibungstechnik erlaubt dabei nicht nur eine übersichtliche Darstellung sondern bietet auch hierarchische Strukturierungen an. Das Zusammenspiel der Bausteine erfordert zu sätzliche Komponenten zur Steuerung und Abstimmung der einzelnen Funktionen, die in dieser Arbeit neu eingeführt werden. Es lassen sich sowohl zentralistische als auch verteilte Steuerungen realisieren. Mit einer entsprechenden Schnittstelle versehen kann eine Steuerkomponente eine ganze Gruppe von Bausteinen dem Benutzer als Einheit zur Verfügung stellen. Somit lassen sich auch verschiedene Medien und/oder mehrere Funktionen gemeinsam mit einer Steuerkomponente zu einem Baustein zusammenfassen. Diese zusammenge setzten Bausteine bieten nun echte Multifunktionalität und Multimedialität. Durch die Komponenten- und Anwendungsmodellierung nach [Zimm93] wird darüber hinaus eine flexible, auch dynamisch änderbare Anwendungsstruktur vom Anwendungs-Management ermöglicht. Das Bausteinmodell wird auch in [Fritzsche96] behandelt. Bisherigen Ansätzen für Multimedia-Komponenten fehlt die allgemeine Interoperabilität der Komponenten. Diese kann nur durch eine umfassende, formale Spezifikation der Komponenten-Schnittstellen, insbesondere aber von Steuerschnittstellen, erfolgen. Zur Spezifikation der Schnittstellen ist die Integration der kontinuierlichen oder zeitabhängigen Medien als abstrakte Datentypen unabdingbar. Auf diese Art werden aus den Komponenten Bausteine. Im vorliegenden Ansatz wurden erstmalig Steuerschnittstellen für Multimedia-Komponenten spezifiziert und als Hierarchie dargestellt. Der neue Ansatz erlaubt es daher, multimediale Systeme nach einem Baukastensystem zu erstellen, indem Bausteine durch Bindung untereinander zu einer Anwendung zusammengesetzt werden. Nach der Verbindungsstruktur der multimedialen Anwendung können verschiedene Anwendungstypen unterschieden werden. Die Definition der Komponentenschnittstellen bezieht sich auf ein abstraktes Datenmodell für kontinuierliche Medien. Das Datenmodell ist eine eigenständige Weiterentwicklung der Ansätze von [Herrtw91] und [Gibbs94] und kann auch zur Realisierung der Komponenten verwendet werden. Multimediadaten wurden zunächst auf zwei Ebenen als Sequenz und Sequenzelemente modelliert. Daraus lassen sich bereits einige Funktionen auf den Daten ableiten, die von den Bausteinen realisiert werden müssen. Kennzeichnend für die Sequenzelemente ist, daß sie die Zeitparameter Zeitpunkt und Dauer besitzen und damit eine explizite Integration der Zeit in das Datenmodell realisieren. Aus diesen Parametern der Elemente können auch für die Sequenz die Parameter Zeitpunkt und Dauer abgeleitet werden. Somit könnte eine Sequenz selbst wieder Element einer Sequenz werden. Da diese Sequenzen von Sequenzen aber zum Teil schwer zu handhaben sind und zum Aufbau von sehr komplexen Verschachtelungen verleiten, wird in dieser Arbeit eine andere Erweiterung der Datenhierarchie, eine Liste, vorgestellt. Diese Erweiterung führt nur eine weitere Hierarchieebene oder Granularitätsstufe ein, ist aber durch die vorgegebenen Funktionen gleichmächtig wie die Verschachtelung der Sequenzen, im Operationsablauf aber leichter nachzuvollziehen. Die Liste repräsentiert die gröbste Granularitätsstufe. Diese ist mit der Titelfolge einer Schallplatte oder einer CD vergleichbar. Die einzelnen Teile haben zueinander nur eine lose Ordnung. In der ersten Verfeinerung der Granularität wird in jedem einzelnen Listenelement eine strenge zeitliche Ordnung gefordert; ein Listenelement ist eine Sequenz. In der zweiten Stufe der Verfeinerung, der Unterteilung der Sequenzen, treten die bereits bekannten Se quenzelemente auf. Die Daten werden im Ticker-Schrittgeber-Modell interpretiert. Dieses Modell erhält zwei Zeitebenen, den Ticker als Bezugssystem der Funktionen untereinander und den Schrittgeber als Steuerung der einzelnen Funktionen. Ein zweistufiges Uhrenmodell mir festgesetzten Operationen und Uhrenbeziehungen wird in dieser Arbeit neu eingeführt. Die Beziehung zwischen Schrittgeber und Ticker ist, daß ein Schritt nach einer bestimmten Anzahl von Ticks erfolgt. Der Startwert des Tickers kann frei gewählt werden, ebenso der Startwert des Schrittgebers. Für den Schrittgeber bestimmt sein Start-Tick, wann er beginnt fortzuschreiten. Ein Schrittgeber ist mit genau einer Sequenz verbunden, deren Start-Schritt beschreibt, bei welchem Schrittwert das erste Sequenzelement gültig wird. Die Start-Zeitpunkte der Elemente und ihre Dauern werden in Schritten gemessen. Das Datenmodell für Multimedia wurde in [Fritzsche95] veröffentlicht. Implementierungen Als Grundlage für die Entwicklung der Bausteine zur Integration kontinuierlicher Medien in verteilte Anwendungen wurden die Funktionen auf den Medien herangezogen. Diese sind in ihren einfachsten Formen die Grundfunktionen Perzeption, Präsentation und Speicherung der Medien, wobei die Speicherung in die Funktionen Schreiben in den Speicher und Lesen aus dem Speicher geteilt wird. Die durch die Perzeption festgelegten, oder künstlich erzeugten Mediendaten können zwischen den einzelnen Funktionen übertragen werden. Eine Bearbeitung der Daten ist beim Austausch zwischen den Funktionen möglich. Die Veränderung der Daten und ihr Bezug zu den Grundfunktionen wird durch die Verarbeitungsfunktionen der Typen f 1 bis f 5 beschrieben. Die Funktionen werden durch Operationen gesteuert, die aus dem Datenmodell abgeleitet werden. Insbesondere wird so auch die explizite Veränderung der Zeitparameter möglich. Somit bietet das Datenmodell eine geeignete Grundlage für jede Art der Verarbeitung kontinuierlicher Medien. Das entwickelte Modell unterstützt die Anwendungserstellung durch objektorientierte Ansätze auf den Ebenen der Konzeption, der Anwendungsspezifikation und der Komponentenentwicklung. Konzeptionell bietet das Funktionenmodell die schnelle und übersichtliche Darstellung der Anwendung. Die aus dem Funktionenmodell ableitbare Anwendungsspezifikation unterstützt die weitere Entwicklung durch Anwendungs- und Komponentenschablonen, sowie durch die vorgefertigte und erweiterbare Hierarchie der Schnittstellen und durch die Bibliotheken für Standardbausteine. Die Verwendung dieser Elemente der Anwendungsspezifikation läßt sich teilweise automatisieren. Das Ergebnis der Anwendungsspezifikation ist eine Menge von Komponenten, die alle vollständig spezifiziert sind. Diese Komponenten sind die funktionsorientierten Bausteine zur Integration kontinuierlicher Medien in verteilte Anwendungen. Im ersten Schritt wurde das vorgestellte Datenmodell mit seinen Operationen in einer objektorientierten Programmiersprache (C [Lipp91]) implementiert [Braun92]. Darauf aufbauend wurden verschiedene Anwendungsfunktionen und Normalisierungsoperationen entwickelt und für den Bereich Audio realisiert [Bast93]. Die von den Funktionen auf kontinuierlichen Medien abgeleiteten Bausteine werden, wie in der vorliegenden Arbeit ausführlich dargestellt, als Komponenten verteilter Anwendungen realisiert. Aus den verschiedenen Realisierungsebenen sollen hier zwei Beispiele hervorgehoben werden. Zunächst wird auf die Komponentenrealisierung eingegangen; danach folgt die Realisierung von Tickern und enger Kopplung. Diese beiden Punkte stellen zentrale Aufgaben des Ansatzes dar. Realisierung von Komponenten Die Realisierung der Komponenten gliedert sich in zwei Abschnitte. Der erste Abschnitt ist die Zerlegung einer Komponente in Standardobjekte nach [Zimm93]. Die Standardobjekte entstammen Kommunikationsklassen, Stub- und Dispatcherklassen, Anwendungsklassen und Kooperationsprotokollklassen. Die Objekte der Anwendungsklassen realisieren die Anwendungsfunktionalität der Komponente. Das Ausprogrammieren dieser Objekte stellt den zweiten Abschnitt der Komponentenrealisierung dar. Dazu liefert das entwickelte Datenmodell die Programmierunterstützung. Zur Abbildung der Spezifikationskonstrukte der Komponenten auf Implementierungskonstrukte wird in [Zimm93] eine Methode vorgestellt, die die unterschiedlichen Konstrukte für Schnittstellen, Kommunikationskontexte und Komponenten auf Klassen und Objekte abbildet. So entsteht eine Klassenhierarchie von C Klassen [Lipp91] für kommunikations-, anwendung-s und managementorientierte Objekte. Weiterhin wird in [Zimm93] ein Verfahren vorgestellt, durch das in Abhängigkeit von den Eigenschaften einer Komponente parallel ablaufende Datenflüsse in ein System von leichtgewichtigen Prozessen (Threads) transformiert werden können. Als Resultat gewinnt man eine modulare Softwarearchitektur der Komponente, die sich aus interagierenden Objekten und zugehörigen Threads zusammen setzt. In [Zimm93] werden folgende Objektklassen unterschieden: . Kommunikationsklassen . Stub- und Dispatcherklassen . Anwendungsklassen . Kooperationsprotokollklassen. Eine elementare Objektarchitektur aus diesen Klassen ist in Abbildung 54 dargestellt. Es gibt jeweils eine Realisierung für eine Supplier-Komponente und eine Consumer- Komponente. Die Anwendungsobjekte können bezüglich ihrer Funktionalität in initiierende und akzeptierende Objekte eingeteilt werden. Im Falle unidirektionaler Schnittstellen sind die Anwendungsobjekte auf der Konsumentenseite (z.B. Benutzerkomponente) für die Initiierung von Methoden an Schnittstellenobjekten verantwortlich. Beispielsweise ist ein Anwendungsobjekt innerhalb der Benutzerkomponente für die Initiierung der Steueroperationen verantwortlich. Im Falle von interaktiven Komponenten [Zimm93] erfolgt dazu ein Benutzerdialog mit einem interaktiven Benutzer. Also realisiert innerhalb der Benutzerkomponente das Anwendungsobjekt einen solchen Benutzerdialog. Anwendungsobjekte auf der Konsumentenseite stellen somit typischerweise keine eigenen Methoden bereit, sondern bestehen lediglich aus einem Konstruktor. Auf der akzeptierenden Seite, den Anbieter (Supplier), realisiert ein Anwendungsobjekt die Operationen an einer Schnittstelle. Dazu wird eine Methode accept benötigt, falls ein verbindungsorientierter Kommunikationskontext zugrunde liegt. Diese Methode dient der Behandlung eingehender Verbindungswünsche. In [Alireza94] werden verschiedene Komponentenrealisierungen ausführlich vorgestellt. Die Realisierung der Ticker und Schrittgeber stellt die Einbettung der zeitbezogenen Komponenten in ihre (Betriebssystem) Umgebung dar. Ähnlich, wie eine Komponente über den Socketmechanismus Zugang zum Kommunikationssystem erhält, erhält eine zeitbezogene Komponente über den Ticker-Schrittgeber-Mechanismus Zugang zum Zeitbezugssystem. Denn die Schrittgeber beziehen sich auf Ticker, Ticker aber auf die Systemzeit. Da auch die Systemzeit als Takt zur Verfügung gestellt wird, können Ticker und Schrittgeber wegen ihrer ähnlichen Funktionalitäten aus einer gemeinsamen Zeitgeberklasse abgeleitet werden. Im Anhang C ist die Deklaration dieser gemeinsamen Klasse angegeben. In einer Anwendung beziehen sich die Schrittgeber verschiedener Komponenten auf einen gemeinsamen Ticker. Dieser Ticker liegt in der Systemumgebung der den Komponenten gemeinsamen interaktiven Benutzerkomponente. Die interaktive Benutzerkomponente verteilt die Ticks über die Steuerschnittstellen an die Komponenten und realisiert so die enge Kopplung der Komponenten. Bei einer Tickrate von 600 Hz ist es nur innerhalb eines Systems sinnvoll jeden Tick als Ereignis zu verteilen. Anstatt nun zu jedem Tick ein Ereignis zu verteilen werden bei der Tickverteilung Tickwerte mit fester Rate verteilt, wobei diese Rate in die Größenordnung der Schritte fällt. Um die Übertragungsraten gemäß den Anforderungen an der Steuerschnittstelle klein zu halten, wird zu jedem Schritt nur ein Teil (1 Byte) des Tickwertes übertragen. Begonnen wird mit der Übertragung des höchstwertigen Bytes, so daß im letzten Schritt einer Tickerübertragung mit dem letzten Byte der genaue aktuelle Tickwert übertragen wird. Ähnliche Verfahren werden bereits bei anderen Synchronisations verfahren verwendet. Eine genaue Beschreibung sowie die Kodierung für die verschachtelte Übertragung von Tickwerten und SchnittstellenAufrufen wird in [Hesme93] vorgestellt. Weitere Entwicklung Zur Realisierung verteilter multimedialer Anwendungen, muß man die einzelnen verteilten Komponenten bestimmen und ihre Funktion beschreiben. Die Komponenten tauschen unter einander Steuerungsinformationen und Multimediadaten aus. Diese Daten und das beim Austausch verwendete Protokoll sollten allgemein standardisiert sein, um den Zusammen schluß heterogener Systeme zu ermöglichen. In der vorliegenden Arbeit wurde gezeigt, wie sowohl die Daten als auch das Zusammenspiel der Komponenten festgelegt werden können. Obwohl alle Geräteklassen und Geräte funktionen sowie verschiedene Werkzeuge entwickelt wurden, und das vorgestellte Modell die gesamte Entwicklung verteilter multimedialer Anwendungen unterstützt, ist dieses große Gebiet noch lange nicht erschöpfend behandelt. Eine Erweiterung der Managementschnittstellen und die Realisierung von komplexen Werkzeugen sind die vordringlichsten Aufgaben. Damit entsteht ein mächtiges Entwicklungswerkzeug für Multimediaanwendungen. Funktionsorientierte Bausteine zur Integration kontinuierlicher Medien in verteilte Anwendungen Eine weitere Aufgabe ist die genauere Untersuchung der Nebenbedingungen, die zur Unterscheidung der Funktionen der Typen f 1 bis f 5 führten. Aus diesen Untersuchungen sowie aus den Ergebnissen der Ticker- und Schrittgeber-Realisierung lassen sich dann genauer spezifizierte Anforderungen an die Betriebs- oder Kommunikations-Systeme ableiten.
Das Thema dieser Arbeit ist die Dienstvermittlung in offenen verteilten Systemen und die Rolle, die ein Typsystem dabei einnimmt. Ein Typsystem besteht aus einer Typbeschreibungssprache und der Definition einer Typkonformität. Die Typbeschreibungssprache erlaubt die Spezifiation von Typen, wohingegen mit der Typkonformität während eines Vermittlungsvorgangs überprüft wird, ob Angebot und Nachfrage zusammenpassen. In dieser Arbeit wurde zunächst nachgewiesen, daß es sinnvoll ist, bei einem Typ zwischen seiner Intension und seiner Extension zu unterscheiden. Die Intension eines Typs ist die Gesamtheit aller Beschreibungen, die auf diesen zutreffen. Die Extension eines Typs repräsentiert dagegen eine konkrete Beschreibung (d.h. Spezifikation eines Dienstangebots). Eine Interpretation ordnet jeder Extension eine Intension zu. Um in einem offenen verteilten System Dienste vermitteln zu können, müssen sich Dienstnutzer und {anbieter auf die Extensionen aller Typen einigen. Einem Typ kommt hierdurch die Rolle eine Standards zu, der allen beteiligten Parteien a priori bekannt sein muß. Daraus resultiert eine injektive Interpretation, die jeder Intension genau eine Extension zuordnet. Die eindeutig bestimmte Extension einer Intension fungiert als systemweiter Standard. Ein Typ als Standard steht im Widerspruch zu der Vielfalt und Dynamik eines offenen Dienstmarktes. Der Standardisierungsprozeß von Extensionen, der einem Vermittlungsvorgang vorausgehen muß, hemmt gerade die Dynamik des Systems. Die Konsequenz daraus ist, daß neben den Diensten auch die Diensttypen Gegenstand der Vermittlung sein müssen. Diese Schlußfolgerung ist bisher noch nicht formuliert worden. Es wäre somit wünscheswert, nicht{injektive Interpretationen zuzulassen, so daß eine Intension mehrere Extensionen besitzen kann, die unterschiedliche Sichten der Dienstnutzer und {anbieter repräsentieren. Die Analyse einiger bestehender Typsysteme zeigte, daß mit diesen eine nicht-injektive Interpretation nicht realisierbar ist. Im Hauptteil dieser Arbeit wurden zwei neue Typsysteme vorgestellt, die diese Eigenschaft unterstützen. Das deklarative Typsystem erweitert die Schnittstellenbeschreibungssprache eines syntaktischen Typsystems, indem semantische Spezifiationen zugelassen werden. Die deklarative Semantik dient dabei als Grundlage für die Beschreibung der Semantik einer Typspezifikation. Die Extension entspricht einem definiten Programm bestehend aus einer endlichen Menge von Horn-Klauseln. Die Intension eines Typs korrespondiert mit dem kleinsten Herbrand-Modell des definiten Programms, welches die semantische Spezifikation des Typs darstellt. Die Forderung nach der Möglichkeit nicht{injektiver Interpretationen ergibt sich aus den Eigenschaften der deklarativen Semantik, wonach verschiedene definite Programme ein identisches kleinstes Herbrand-Modell besitzen können. Das zweite in dieser Arbeit vorgestellte Typsystem entspringt einem wissensbasierten Ansatz. Grundlage bildet eine Wissensrepräsentationstechnik, die anwenderbezogene semantische Spezifikationen erlaubt. Ein Konzeptgraph als wissensbasierte Typspezifikation vereinigt in sich unterschiedliche Beschreibungen eines Typs. Ein Konzeptgraph, der selbst eine Extension darstellt, repräsentiert somit die Vereinigung mehrerer Extensionen eines Typs. Die Intension ist jedoch durch einen Konzeptgraph nicht eindeutig bestimmt. Dieser stellt lediglich eine Approximation dar. Hier liegt ein fundamentaler Unterschied in den beiden Typsystemen. Während eine Extension im deklarativen Typsystem auch immer eindeutig eine Intension charakterisiert, ist dies bei dem wissensbasierten Typsystem nicht der Fall. Die Konsequenz daraus ist, daß dieser Umstand bei einem Vermittlungsvorgang berücksichtigt werden muß. Ein wissensbasierter Vermittler muß über ein spezielles Vermittlungsprotokoll die Verfeinerung einer wissensbasierten Typspezifikation erlauben, die zu einer besseren Approximation der Intension führt. Das deklarative Typsystem besitzt aufgrund der Unentscheidbarkeit der deklarativen Typkonformität keine praktische Relevanz. Es zeigt jedoch, wie mit Hilfe der deklarativen Semantik der Open World Assumption genüge geleistet werden kann. Im Vergleich dazu kann das wissensbasierte Typsystem als "Fuzzyfizierung" des deklarativen Typsystems angesehen werden. Die wissensbasierte Typbeschreibungssprache ermöglicht im Sinne der Fuzzy Logik unscharfe Spezifikationen, die im Laufe der Zeit verfeinert werden. Ein Vorteil des wissensbasierten Ansatzes ist die Möglichkeit von anwenderbezogenen Typspezifikationen. Ein anderer Vorteil besteht darin, daß eine wissensbasierte Typbeschreibungssprache eine Meta-Sprache repräsentiert, in der Spezifikationen aus anderen Domänen dargestellt werden können. Ungeachtet dieser Vorteile bleibt jedoch der Beweis offen, daß die wissensbasierte Dienstvermittlung tatsächlich eine geeignete Methodik für die Vermittlung von Typen darstellt.