Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

31.08.1990 - 

Software-Entwicklung stellt Anforderungen an DB-Technik

Datenbanken leisten einen Beitrag zur Offenheit

Helmut Abbenhardt ist Projektmanager für Datenbank-Entwicklungen der Softlab GmbH, Zamdorfer Str. 120, 8000 München 80

Zukünftige Software-Produktionsumgebungen zeichnen sich gegenüber heutigen Systemen durch ein höheres Maß an Integrationsfähigkeit für Werkzeuge unterschiedlicher Anbieter und durch größere Offenheit und Anpassungsfähigkeit für individuelle Anwenderwünsche aus. Einen entscheidenden Beitrag hat die Datenbank der Software-Produktionsumgebung zu leisten, ist sie doch der gemeinsame Speicher für alle Daten und Informationen.

Die unterschiedlichen Werkzeuge greifen mit den jeweils ihnen eigenen Sichten (Views) auf die gemeinsamen Daten zu. Solche Datenbanken müssen mit Blick auf Datenmodellierungsmöglichkeiten, Funktionalität, Antwortzeitverhalten oder auch Benutzerverfügbarkeit, höchste Anforderungen erfüllen. Wichtige Anforderungen an die Datenbanktechnik aus Sicht einer Software-Produktionsumgebung werden in diesem Beitrag erörtert und anschließend deren Realisierbarkeit auf Basis der relationalen und der Entity-Relationship-Technologie sowie einer dedizierten Datenbank beurteilt.

Zwei wesentliche Konzepte bestimmen zukünftige Software-Produktionsumgebungen: Offenheit und Integrationsfähigkeit.

Das heutige Angebot an Software-Werkzeugen ist eher durch Einzelwerkzeuge - oder bestenfalls durch lose miteinander gekoppelte Einzelwerkzeuge - gekennzeichnet, als durch wirklich integrierte Lösungen. Diese Situation ist für den Softwareentwickler unbefriedigend, da er berechtigterweise eine durchgängige Unterstützung für den gesamten Software-Lebenszyklus erwartet. Um diesem Bedürfnis entgegen zu kommen, ist es deshalb nicht verwunderlich, daß Werkzeughersteller und Werkzeuganwender bei der Werkzeugintegration einen hohen Aufwand betreiben. Dabei werden unterschiedliche Ansätze verfolgt:

- Direkte Integration einzelner Werkzeuge

Dies geschieht häufig unter Ausnutzung existierender Import-/Export-Schnittstellen der zu integrierenden Werkzeuge. Die Integration ist meist nicht sehr tiefgehend. Die Werkzeuge behalten ihre Benutzerschnittstelle, das Datenhaltungssysteme etc. bei. Eine solche Kopplung kann im Einzelfall durchaus hilfreich sein, ist jedoch im allgemeinen keine brauchbare Lösung zur Erstellung ganzer Software-Produktionsumgebungen. Beispiel für eine solche Kopplung ist die Schnittstelle zwischen PAPICS und PRO-MOD.

- Integration in geschlossenen Umgebungen

Hierbei werden im allgemeinen speziell entwickelte Werkzeuge zu einem Gesamtsystem integriert. Diese Systeme zeichnen sich durch ein hohes Maß an Homogenität aus, sind aber stark in sich abgeschlossen; interne Schnittstellen sind also normalerweise nicht zugänglich.

Deshalb erlauben diese Systeme kaum eine Erweiterung durch Werkzeuge anderer Anbieter (zum Beispiel Information Engineering Workbench/James Martin IEW)

- Integration durch offene Schnittstellen

Bei dieser Vorgehensweise wird davon ausgegangen, daß zu jeder Software Produktionsumgebung eine gewisse Grundfunktionalität gehört. Diese wird in einem "Rahmensystem" oder einer sogenannten "Plattform" bereitgestellt. Die Plattform bietet zusätzlich mächtige und allgemein zugängliche Schnittstellen an, die der Integration der einzubindenden Werkzeuge dienen. Diese Art der Integration setzt im allgemeinen eine Anpassung der einzubringenden Werkzeuge voraus. Deshalb ist es wichtig, daß die Plattform Standardschnittstellen anbietet oder zumindest Schnittstellen, die sich zu Standards oder Quasi-Standards entwickeln können.

Der dritte Ansatz scheint langfristig der tragfähigste zu sein, da er neben der Integrationsfähigkeit auch eine größtmögliche Offenheit der Gesamtumgebung ermöglicht. Offenheit bedeutet hier insbesondere die Möglichkeit, unterschiedlichste Methoden in der gleichen Umgebung unterstützen zu können, die flexible Erweiterbarkeit sowie die Fähigkeit zur Integration von Werkzeugen unterschiedlicher Anbieter.

Eine solche Plattform hat folgenden grundlegenden Aufbau (Abbildung 1):

- Die Benutzerschnittstelle zur Realisierung eines einheitlichen Erscheinungs-

und Benutzungsbildes für den Anwender einerseits und die Schnittstelle für den Anschluß der verschiedenen Werkzeuge andererseits

- Das Objekt Management System (OMS) als Kernstück der Software-Produktionsumgebung. Alle Werkzeuge operieren unmittelbar auf dem OMS, alle Ergebnisse und Informationen werden also dort gehalten. Die verschiedenen Werkzeuge greifen mit unterschiedlichen Sichten auf die Daten zu.

- Die Life Cycle übergreifenden Werkzeuge, die in allen Phasen des Produktionsprozesses gebraucht werden. Beispiele für solche Werkzeuge sind

- Textsystem

- Bürokommunikations-Funktionen

- diverse Editoren

- Projektmanagement

- Configuration Management.

Die Front-end- und Back-end-Werkzeuge bilden nicht mehr einen direkten Bestandteil der Plattform, sondern gehören zu den "einhängbaren" Komponenten.

Typische Beispiele für Front-end-Werkzeuge stellen Analyse/ Design-Werkzeuge; Maskengeneratoren etc. dar. Diese Werkzeuge sind primär dialogorientiert. Typische Back-end-Werkzeuge sind Codegeneratoren, Testtools etc. Diese Werkzeuge arbeiten eher transformativ.

Die bisherige Darstellung macht deutlich, daß in einer solchen Plattform-Architektur einige Komponenten eine besondere Rolle spielen. OMS ist daher der zentrale Baustein einer Software-Produktionsumgebung, an den spezielle Anforderungen gestellt werden.

Es ist offensichtlich, daß klassische Filesysteme den Datenhaltungs-Anforderungen für Software-Produktionsumgebungen nicht genügen. Daher wird die Funktionalität von Datenbanken benötigt.

Bei der Frage, wie eine solche Datenbank auszusehen hat, muß insbesondere geklärt werden, ob Standard-Datenbanken, wie etwa relationale Systeme, für diese Aufgabenstellungen geeignet sind oder ob es dedizierter Lösungen bedarf.

Dazu sollen zunächst einige wichtige Anforderungen an Datenbanken für Software-Produktionsanwendungen zusammengestellt werden. In dieser Aufstellung sind bewußt solche "allgemeinen" Datenbankeigenschaften nicht aufgelistet worden, die unabhängig von der speziellen Anwendung sind (wie Transaktionsschutz, Recovery etc.). Für Software-Produktions-Datenbanken müssen natürlich diese allgemeinen Eigenschaften ebenfalls erfüllt sein.

- Komplexe Objekte und komplexe Funktionen

Bei komplexen Objekten handelt es sich um Datenobjekten, die aus anderen Datenobjekten (Teilobjekten) zusammengesetzt sind. Die Strukturierung kann dabei beliebig tief sein und ist durch den Anwender frei definierbar. Die Möglichkeit zur Verwaltung komplexer Objekte reicht jedoch nicht aus. Um wirksame Unterstützung zu bieten, müssen auch komplexe Funktionen durch die Datenbank zur Verfügung gestellt werden, die auf komplexen Objekten arbeiten, und zwar unabhängig von deren Struktur, Größe etc.. Beispielsweise muß die COPY-Funktion nicht nur einzelne Files kopieren, sondern auch beliebige komplexe Objekte, ohne daß der Aufrufer die Struktur des zu kopierenden Objekts kennen muß. Ahnliches gilt für Versionen, Zugriffsrechte, Locks etc.

Beispiele für komplexe Objekte bei der Softwareentwicklung sind die einzelnen Teilprodukte einer Komponente, die Komponenten eines Systems oder aber auch die einzelnen Kapitel einer Beschreibung sowie die Knoten eines graphischen Diagramms.

Um komplexe Objekte und komplexe Funktionalität innerhalb einer Datenbank realisieren zu können, muß die Datenbank Mechanismen zur Abstraktion von der Struktur anbieten und die Bestimmung von semantisch sinnvollen, benutzerdefinierten Teilobjekten ermöglichen.

- Referenzielle Integrität

Für eine Software-Produktionsumgebung ist es wichtig, daß einmal zwischen Objekten definierte Referenzen auch ihre Gültigkeit und Verläßlichkeit bewahren. So muß auf eine Abfrage der Art "Welche Übersetzungseinheit benutzen Include ABC?" eine Liste ausgegeben werden, bei der sichergestellt ist, daß alle referenzierten Programme noch Bestandteil des Systems sind und an der referenzierten Stelle im Datenbestand zu finden sind.

Für die Datenbank bedeutet diese Anforderung, daß zum Beispiel alle relevanten Relationen modifiziert werden müssen, wenn Objekte gelöscht, kopiert oder verschoben werden.

- Objekte unterschiedlicher Granularität

In Software-Produktionsumgebungen müssen Objekte unterschiedlichster Granularität behandelt und verwaltet werden können. Auf der einen Seite sind ein Knoten innerhalb eines Design-Diagramms mit wenigen Bytes an Informationen, aus Benutzersicht ebenso als ein (komplexes) Objekt zu betrachten, wie auf der anderen Seite ganze Systemkonfigurationen mit vielen Megabytes.

Um diese Anforderungen an die Datenbank effizient abdecken zu können, muß das Datenbank-Managementsystem intern mit unterschiedlichen Speicher und Zugriffsmechanismen arbeiten. Diese unterschiedliche interne Handhabung sollte an der Datenbankschnittstelle nicht mehr sichtbar sein.

- Dynamische Modifikation von Schemadaten

Die Schemadefinitionen einer Software-Produktionsdatenbank sind häufigen Änderungen unterworfen. Mit dem Projektfortgang werden neue Objekte angelegt oder Objekte entfallen. Schemadefinitionen werden -etwa durch Subschemata verfeinert, aus einem Typen FILE werden Subtypen SPEZIFIKATION, INCLUDE oder BENUTZERHANDBUCH.

Das Datenbank-Managementsystem muß für diese Funktionalität flexible und mächtige Mechanismen zur Verfügung stellen. Darüber hinaus muß die Datenbank die Konsistenzprüfung auf Schema- und Instanzenebene unterstützen.

- Zahlreiche unterschiedliche Datentypen

Die Anzahl der in einer Software-Produktionsumgebung vorkommenden Objekt-, Relations- und Attributtypen ist sehr groß. Insbesondere wenn mächtige Entwicklungsmethoden unterstützt werden sollen, steigt die Zahl schnell an. Umfassende Methoden wie LSDM (nationaler Standard für Software-Engineering in Großbritannien) haben etwa 100 Objekttypen, 400 Relationstypen und 300 Attributtypen. Bei der Vielzahl der Anwendungen die auf einer EntwickIungsdatenbank laufen, läßt sich leicht die zu bewältigende Größenordnung vorstellen.

Die für solche Aufgaben geeignete Datenbank muß in der Lage sein, große Meta-Datenmengen handhaben zu können. Auf diese Meta-Daten muß mit hoher Geschwindigkeit sehr häufig zugegriffen werden, da für zahlreiche Datenbankzugriffe die Metainformationen zu Konsistenzüberprüfungen benötigt werden.

- Flexible Unterstützung für Strukturmuster

Strukturmuster dienen dem einheitlichen und effizienten Aufbau von Verwaltungsstrukturen für die Projektdaten. Dabei müssen neben dem Aufbau der Struktur

auch Initialisierungen einzelner Objekte vorgenommen werden. Bestimmte Strukturen in Projektdatenbeständen treten dabei - auch mit leichten Abweichungen von einem Grundmuster - sehr häufig auf.

Als Beispiel dient das Strukturmuster für ein komplexes Objekt MODUL: Es besteht aus verschiedenen Teilobjekten wie SPEZIFIKATION, SOURCECODE, TESTTREIBER, TESTERGEBNIS, etc.. jedes dieser Teilobjekte kann noch weiter strukturiert sein, wie TESTTREIBER in TESTFALL1, TESTFALL2 und TESTDATEN. Je nach Anforderung eines konkreten Moduls werden einige dieser Teilobjekte jedoch nicht immer gebraucht oder zusätzliche Objekte kommen hinzu. So entfällt in dem in Abbildung 2 skizzierten Beispiel TESTFALL2 und es gibt ein zusätzliches Objekt PERFORMANCE MESSERGEBNIS.

An die Datenbank werden für die Unterstützung dieser Funktionalität sowohl Anforderungen an die flexible und komfortable Handhabung von Strukturmustern, als auch an die Überprüfung der benutzerdefinierten Konsistenzbedinungen gestellt. Diese Konsistenzbedingungen können sehr komplex sein.

- Unterschiedliche Sichten auf die gleichen Daten

Die integrierende Rolle der Datenbank für eine Software-Produktionsumgebung beruht weitgehend auf der Annahme, daß alle im Softwareproduktionsprozeß Beteiligten benutzt werden können. Dabei werden einzelne Informationen im allgemeinen nur einmal gespeichert, aber von den verschiedenen Benutzern (Menschen wie Werkzeugen) in unterschiedlicher Zusammensetzung benutzt und in verschiedener Weise interpretiert. Die einzelnen Anwendungen haben dabei unterschiedliche Sichten auf die Daten. Beispielsweise werden die Daten, die von einem Front-end-Design-Werkzeug in der Entwurfsphase erzeugt wurden, von unterschiedlichsten Werkzeugen im Verlauf des Software Produktionsprozesses benutzt.

- Der Codegenerator greift auf diese Daten zu und erzeugt, zusammen mit weiteren Informationen, daraus Coderahmen für eine Zielsprache.

- Ein Testwerkzeug benutzt die Schnittstellen- und Datendefinitionen, um daraus Testfälle abzuleiten.

- Aus den funktionalen Beschreibungen werden die Informationen für die spätere Benutzerdokumentation abgeleitet.

- Ein Management-Werkzeug greift auf die mit den Entwurfsergebnissen assoziierten Planungs- und Aufwandsdaten zu, um daraus eine Projektübersicht zu erzeugen.

- An die Datenbank ergibt sich aus diesen Vorstellungen nicht nur die Anforderung nach benutzerdefinierbaren virtuellen Views auf die Daten, sondern auch nach sehr schnellen Zugriffen auf solche Views.

- Versionen und Varianten von komplexen Objekten

Für die Entwicklung und Wartung von Softwaresystemen, insbesondere von Systemen mit langer Lebensdauer, unterschiedlichen Einsatzbereichen oder von Produkten, ist eine Unterstützung von mehreren Versionen und Varianten unumgänglich. Eine mächtige Versionsverwaltung ist die Basis für das Konfigurations-Management. Zur Versionsverwaltung muß die Datenbank Unterstützung für zumindest historische Versionen (Zeitversionen) und Varianten (Parallele Versionen) geben. Weitere Funktionen wie temporäre Versionen (Schnappschüsse) sind wünschenswert.

Um für diese Funktionalität eine brauchbare Performance zu bekommen, muß die Versionsfunktionalität in die Datenbank eingebaut sein.

Nur so lassen sich Konzepte wie logische Kopien realisieren.

- Zugriffskontrolle auf komplexe Objekte

In einer Software-Produktionsdatenbank muß der Zugriffsschutz auf dem Niveau komplexer Objekte erfolgen. Mit einem einzigen, schnellen Datenbankzugriff müssen die Zugriffsrechte also für beliebig große, semantisch sinnvolle Datenbestände eingerichtet, geändert, gelöscht oder geprüft werden können.

Änderungen der Zugriffsrechte an Objekten kommen in einer Software-Produktionsumgebung häufig vor. Analoge Aussagen gelten auch für die Datenbank-internen Locks an Objekten.

Die Datenbank muß die Modifikation oder Prüfung eines Zugriffsrechts (und auch eines Locks) auf komplexe Objekte in jener Weise unterstützen, daß nicht jedes einzelne Teilobjekt des komplexen Objekts angefaßt werden muß. Im günstigsten Fall reicht die Modifikation/Prüfung an genau einer Stelle. Da sich bei großen Datenbeständen die Übersicht über die vergebenen Rechte schwierig gestalten kann, sind von der Datenbank Hilfsmittel bereitzustellen, die die notwendige Transparenz für den menschlichen Benutzer herstellen.

- Navigierender und mengenorientierter Datenzugriff

Für Software Produktionsdatenbanken sind meist mehrere Zugriffsmethoden notwendig. Zumindest jedoch sind navigierende und mengenorientierte Zugriffe auf die verwalteten Daten notwendig. Durch navigierende Zugriffe findet man Objekte anhand der Projektstruktur; mengenorientierte Zugriffe werden für Anfragen der Art "Wo wird Objekt x benutzt?" benötigt.

Die Datenbank muß zumindest diese beiden Zugriffsarten performant unterstützen. -

- Schneller Direktzugriff

Viele Werkzeuge einer Software-Produktionsumgebung arbeiten interaktiv. Dies setzt sehr hohes Antwortzeitverhalten der Werkzeuge und damit auch der Datenbank voraus. Besonders graphische Entwurfswerkzeuge und Informationsfunktionen stellen an die Datenbank hohe Anforderungen. Beispielsweise erfordert so eine kleine Veränderung eines graphischen Diagramms, wie das Verschieben eines Knotens, bereits fünf bis zehn Datenbankzugriffe.

Um die hohen Direktzugriffsanforderungen abdecken zu können, bedarf es unterschiedlichster Speicher- und Caching-Mechanismen innerhalb der Datenbank. Diese Caching-Mechanismen hängen stark vom Benutzerprofil der Datenbank ab und müssen deshalb an die jeweiligen Bedürfnisse anpaßbar sein.

- Design-Transaktionen

Entwicklungsschritte in der Softwareproduktion, die in sich eine abgeschlossene Einheit bilden, benötigen nicht selten Tage, Wochen oder gar Monate, etwa die Bearbeitung eines Entwurfsdiagramms oder die Codierung eines Moduls. Während dieses Zeitraums sollte der Bearbeiter exklusives Modifikationsrecht an den benötigten Objekten haben, andere jedoch nicht am lesenden Zugriff hindern und vom System zugesichert bekommen, daß nach Beendigung der Arbeiten alle Änderungen in konsistenter Form allgemein verfügbar gemacht werden können.

Zur Realisierung dieser Datenbankeigenschaft müßte die Datenbank Techniken wie Booking-in/Booking-out-Verfahren bereitstellen.

- Spezielle semantische Eigenschaften

Es gibt mehrere Anforderungen von Software-Produktionsumgebungen wie automatische Änderungen von Statusinformationen oder No-Copy-Attribute, die sich auf unterschiedlichste Art und Weise realisieren lassen. Eine Möglichkeit, diese Leistungen besonders performant bieten zu können, ist es, eine Basisunterstützung für solche Mechanismen durch die Datenbank bereitstellen zu lassen.

Der Nachteil hierbei ist ein Verlust an Allgemeinheit: Der Grat zwischen sinnvoller Spezialisierung und Verlust an Universalität ist schmal.

Im Überblick soll nun versucht werden, die Anforderungen an Software Produktionsdatenbanken auf derzeit gängige Datenbank-Technologien abzubilden.

Im Vergleich stehen die relationale und die Entity-Relationship-Technologie sowie eine dedizierte Software-Produktionsdatenbank.

Bei den relationalen und Entity-Relationship-Datenbanken wurden keine einzelnen Vertreter der jeweiligen Gattung betrachtet, sondern generelle Eigenschaften der jeweiligen

Technologie berücksichtigt. Dies kann im Einzelfall dazu führen, daß für eine bestimmte Datenbank manche Eigenschaften stärker oder schwächer ausgeprägt sind als in der Bewertung (Abbildung 3).

Als Repräsentant für die dedizierte Datenbank wurde das Maestro II OMS von Softlab genommen.

Bei den dedizierten Datenbanken werden derzeit unterschiedliche Ansätze verfolgt. Deshalb ist es in dieser Sparte Momentan nicht möglich, allgemeingültige Aussagen zu machen.

Auf der Basis aller drei betrachteten Technologien sind die hier aufgeführten Anforderungen prinzipiell erfüllbar. Deshalb gehen in die Beurteilung auch wesentlich die Kriterien "Aufwand für die Machbarkeit" und "Performance" ein.

Eine kurze zusammenfassende Beurteilung der unterschiedlichen Ansätze ergibt folgende Aussagen:

- Relationale Datenbanken bieten vor allem Vorteile wie die mittlerweile weitgehend ausgereifte Technik, die gute und mächtige Hilfsfunktionalität um die Datenbank herum (Utilities) sowie die vertraute Handhabung.

Nachteile dagegen sind die eingeschränkte Flexibilität, die fehlende komplexe Funktionalität sowie die schlechte Performance für die benötigte Funktionalität und zudem die nicht ausreichende Mächtigkeit, um semantische Eigenschaften auszudrücken.

- Entity-Relationship-Datenbanken lassen deutlich als Vorteil die hohe Flexibilität durch das stark allgemeine Datenmodell erkennen.

Nachteile sind die Schwierigkeit, semantisch sinnvolle Substrukturen bilden zu können, aber auch die Schwierigkeit, komplexe Funktionalität zu realisieren.

- Dedizierte Datenbanken weisen als Vorteile auf die auf die Bedürfnisse abgestimmte Funktionalität mit Blick auf Datenmodellierung, Zugriff, Versionsverwaltung und spezieller semantischer Anforderungen, etc. sowie die zur Funktionalität relativ hohe Performance.

Nachteile stehen dagegen wie die eingeschränkte Universalität, der Umgang mit neuer Technologie, weiterhin die noch nicht absehbaren langfristigen Entwicklungen sowie die hohen Entwicklungskosten.

Auf der Basis der derzeit verfügbaren Implementierungen scheinen Standarddatenbanken als taugliches Instrument für Software-Entwicklungsumgebungen wegen der zu geringen Flexibilität und unzureichenden Performance nicht geeignet zu sein: Entity-Relationsship-Datenbanken bieten gute Grundvoraussetzungen, haben aber einige prinzipielle Nachteile (wie Substrukturierung). Dedizierte Lösungen, in denen ein ausgewogener Kompromiß zwischen Universalität und integrierten semantischen Eigenschaften gefunden wurde, haben - zumindest aus technischen Gesichtspunkten - momentan erhebliche Vorteile vorzuweisen.

Literatur:

K. Dittrich: Objektorientierte Datenbanksysteme, Informatik Spektrum, 12 (1989) 4,S. 215-218.

S. Hudson, R. King: The Cactis Project: Database Support for Software Environments, IEEE Transactions on Software Engineering, 14 (1988) 6, S. 709 ff.

G. Greiter: Charakteristische Eigenschaften der Datenbank POINTE/PUS, Tagungsband "Software-Entwicklungs-Systeme und -Werkzeuge", Kapitel 14.2, Technische Akademie Esslingen, 1987.

Dieser Beitrag basiert auf einem Referat des CSE-Anwender-Kongresses "Software für den Computer ans dem Computer" im September 1989. Er ist zusammen mit über 20 weiteren Fachvorträgen als Kongreß-Dokumentation in der CSE-Edition erschienen. Informationen bei: CSE Conferences, Seminars, Education, Rheinstraße 28, 8000 München 40, Telefon 0 89/3 60 86-1 69.