Previous Next V-Model Official Homepage by IABG  
Part 3: Collection of Manuals Homepage  
OO  Homepage  

  OOL - Consideration of Object-Oriented Languages

Inhalt  
  • OOS.1 Überblick
  • OOS.2 Auswirkung objektorientierter Vorgehensweisen
  • OOS.3 Anwendung von Ada 95
  • OOS.4 Anwendung von C++
  • OOS.5 Anwendung anderer objektorientierter oder objektbasierter Sprachen
  • OOS.1 Überblick

    Nach einer grundsätzlichen Betrachtung der Auswirkungen des Einsatzes objektorientierter Sprachen im V-Modell wird exemplarisch besonders auf die Sprachen Ada 95 und C++(1) eingegangen. Es wird dargestellt, wie die Arbeits- und Unterstützungshilfen des V-Modells beim Einsatz objektorientierter Sprachen umgesetzt werden sollen. Insbesondere wird gezeigt, wie die Erzeugnisstruktur des V-Modells als Strukturierungshilfe für objektorientierte System- und SW-Entwürfe eingesetzt werden kann.

    OOS.2 Auswirkung objektorientierter Vorgehensweisen

    OOS.2.1 Grundsätzliche Sichtweise des V-Modells

    Die Prinzipien, die objektorientierte Vorgehensweisen erlauben, sind bereits im Regelungsteil des V-Modells verankert.(2) Die dabei zum Einsatz kommenden Elementarmethoden sind im Grundsatz sprachunabhängig und können daher in Verbindung mit jeder der nachfolgend behandelten Sprachen eingesetzt werden.

    Sowohl die Methodenkonzepte als auch die syntaktischen Strukturierungsmittel der jeweiligen Sprache orientieren sich beim Einsatz des V-Modells an der Erzeugnisstruktur als Gliederungsgerüst. Die Zuordnung der Methoden zu diesem Gerüst dokumentiert die Methodenzuordnung.

    Grundsätzlich sind die Elemente der Erzeugnisstruktur Gliederungs- und Verwaltungshilfen für die Elemente des Systems. Sie sind dadurch universell tauglich, daß sie sprachunabhängig genutzt werden können.

    Die Regelungen des V-Modells - und insbesondere die Erzeugnisstruktur - sind unabhängig von der eingesetzten Methode und Programmiersprache anwendbar.

    OOS.2.2 Regeln und Kriterien für die praktische Umsetzung

    Für den Einsatz einer Programmiersprache relevante Elemente der Erzeugnisstruktur sind SW-Einheiten, SW-Komponenten und SW-Module. Unabhängig von der eingesetzten Sprache gilt, daß in keinem Fall eine direkte, vom V-Modell als Standard festgeschriebene Kopplung von Syntaxelementen zur Erzeugnisstruktur erfolgt (z. B. "Jede Klasse ist ein SW-Modul").

    Eine starre, schematisierte Zuordnung von Elementen der Erzeugnisstruktur zu Ausdrucksmitteln einer Programmiersprache ist nicht möglich. Wesentliche Faktoren bei der Zuordnung sind z. B. der Grad der Komplexität des Systems und der Abstraktionsgrad der Zerlegungsebene.

    Das Ergebnis der Zuordnung wird deshalb eine Skala mit überlappenden Zuordnungen von Strukturen des V-Modells zu Strukturen der Programmiersprache sein.

    SW-Einheit

    Das V-Modell gibt keine Aufteilung in SW-Einheiten vor. Es kann daher nicht nach einer "korrekten Aufteilung gemäß V-Modell" gefragt werden. Im Sinne des V-Modells ist jede Aufteilung korrekt. Es ist eine Entwurfsaufgabe, die unter Designgesichtspunkten bei den gegebenen Randbedingungen am besten geeignete Architektur zu finden.

    Die SW-Einheit ist ein Strukturierungsmittel zur Beschreibung der Architekturentscheidungen im V-Modell. Dabei spielen neben SW-technischen auch organisatorische Gesichtspunkte eine Rolle. So können z. B. SW-Anteile, die einem Team zugeordnet werden, zu einer SW-Einheit zusammengefaßt werden. Auch die Integrationsstrategie (und damit die Prüfplanung) kann Argumente zur Aufteilung von Systemen oder Segmenten in SW-Einheiten liefern.

    Es ist nicht gefordert, daß eine SW-Einheit lauffähig im Sinne eines eigenständigen Programms oder Prozesses ist. Eine SW-Einheit wird in jedem Fall als eigenständige Einheit vom KM verwaltet. (KM kann aber auch kleinere Einheiten verwalten.)

    Sinnvoll kann z. B. die Gliederung eines Anwendungssystems in drei SW-Einheiten sein, die die Schichten:

    1. Präsentationsschicht (Windowsoberfläche, GUI, Behandlung von User-Interrupts usw.),
    2. Anwendungsschicht (meist auf fachliche Anforderungen zurückzuführende SW-Anteile) und
    3. Datenschicht (Dateien, Zugriffsroutinen, Datenablage usw.).

    SW-Modul

    SW-Module sind gekennzeichnet durch die Umsetzung der typischen Modularisierungskriterien wie Abgeschlossenheit, schwache Kopplung zwischen Modulen (schmale Schnittstellen) und enge interne Bindung zwischen Funktionen. SW-Module sind von außen als abgeschlossene, testbare und wartbare Einheiten sichtbar. Gutes Moduldesign zeichnet sich auch durch gute Abstraktionsschichten aus: Ein SW-Modul bietet nach außen eine konsistente, verständliche und wartbare Schnittstelle an, die unabhängig von der internen Modulstruktur ist.

    Ein typisches SW-Modul ist z. B. eines zur Berechnung von Steuerzuschlägen. Sein Datengeheimnis sind die aktuell gültigen Steuersätze. Seine Algorithmen kapseln die gesetzlich abgesicherten Berechnungsvorgänge inklusive der Rundungsregeln.

    SW-Komponente

    Komponenten sind i. d. R. Sammlungen von SW-Modulen, die z. B. gemeinsam einen Funktionskreis implementieren. Typische SW-Komponenten sind Bibliotheken (auch die Standardbibliotheken der eingesetzten Software-Entwicklungsumgebung), Mengen zusammengehöriger, wiederverwendbarer SW-Module, Modulmengen, die von mehreren anderen SW-Einheiten benutzt werden, usw.

    Eine typische SW-Komponente ist die C- oder Ada-Standardbibliothek.

    Im folgenden werden sprachabhängig typische Situationen geschildert und in Form von beispielhaften Lösungsvorschlägen beschrieben.

    OOS.3 Anwendung von Ada 95

    OOS.3.1 Die Strukturierungsmittel von Ada 95

    Basis für die Erstellung von Ada-Software ist die Bibliothek. Der Ada-Standard (/DIN ISO IEC 8652/) schreibt im Detail nicht vor, wie eine Bibliothek auszusehen hat. Grundgedanke des Bibliothekskonzepts bei Ada ist es, daß die Bibliothek übersetzte Programmeinheiten aufnimmt, die Beiträge zu einem späteren lauffähigen System sind. Übersetzen von Programmeinheiten und Binden eines Programms finden immer im Kontext einer Bibliothek statt, wobei Konsistenzprüfungen über die Grenzen von Bibliothekseinheiten hinweg vorgenommen werden. Eine Ada-Implementierung kann die Verknüpfung von mehreren Bibliotheken zu einer Bibliothekshierachie unterstützen. Ada 95 schreibt die Struktur und Funktion einer Programmbibliothek nicht mehr so detailliert vor wie Ada 83.

    Ada 95 trägt der Entwicklung Rechnung, daß ein "Programm" nicht mehr zwangsläufig auf einen einzigen Prozessor bzw. auf einen einzigen Adreßraum festgelegt ist. Vielmehr wird unter einem Programm eine Menge von Bausteinen verstanden, die zusammen ein System implementieren und die gleichzeitig auf im allgemeinen mehreren Hardwarekomponenten ablaufen. Diese Bausteine werden bei Ada Partitionen genannt. Im konventionellen Fall ist ein Programm identisch mit einer Partition. Falls ein Programm aus mehreren Partitionen besteht, dann wird von einem verteilten System gesprochen.

    Ada 95 führt neu die Unter-Bibliothekseinheit ("child library unit") ein. Die Unter-Bibliothekseinheit ist eine Bibliothekseinheit, die eine Erweiterung einer bereits bestehenden Bibliothekseinheit darstellt. Unter-Bibliothekseinheiten können beliebig tief geschachtelt sein. Die Unter-Bibliothekseinheiten sind als Sprachmittel die entscheidende Voraussetzung, daß in Ada unter Berücksichtigung der Aufwärtskompatibilität von Ada 83 die Konzepte der Objektorientierung ("tagged types", "programming by extension") eingeführt werden können. Eine komplette Hierarchie bestehend aus Bibliotheks-, Unter-Bibliothekseinheiten und Untereinheiten wird Ada-Subsystem genannt. Der Begriff "Ada-Subsystem" deckt somit einen weiten Bereich ab.

    Zusätzlich zu den Kontextklauseln von Ada 83 bieten die Unter-Bibliothekseinheiten dem Programmierer wesentlich mehr Möglichkeiten zur Programm-Strukturierung und zur störungsfreien Erweiterung bereits bestehender Systeme.

    OOS.3.2 Abbildung auf die Erzeugnisstruktur

    SW-Modul

    Ein SW-Modul ist die kleinste Software-Einheit, die vom Konfigurationsmanagement identifiziert wird. Dieses Verständnis hat seine Analogie in der Bibliothekseinheit (library unit) bzw. Unter-Bibliothekseinheit (child library unit) bei Ada. Eine (Unter-) Bibliothekseinheit im Sinne der Erzeugnisstruktur ist Generische Einheiten dienen dazu, aus einer Programmschablone durch den Vorgang der generischen Ausprägung ausführbare Programmeinheiten zu erzeugen. Eine generische Einheit ist kein Beitrag zu einem laufenden System, deshalb ist eine generische Einheit auch nicht Teil der Erzeugnisstruktur.

    Bibliothekseinheiten enthalten als Bausteine Programmeinheiten (program units). Aus programmiertechnischen Gründen ist eine Programmeinheit nicht identisch mit einer Bibliothekseinheit.

    Der Sprachstandard kennt des weiteren die Untereinheit (program subunit). Diese dient der besseren Strukturierbarkeit von Programmeinheiten. Eine Untereinheit ist immer auf eine Programmeinheit bezogen und von dieser stark abhängig.

    SW-Komponente

    Im Sinne des V-Modells ist eine SW-Komponente die Zusammenfassung mehrerer SW-Module zur Lösung einer Teilaufgabe. Dies hat seine Analogie in einer Struktur von zusammengehörigen Ada-Bibliothekseinheiten. Der Zusammenhang wird durch das Ada-Sprachmittel der Kontextklausel ("with"-clause) hergestellt. Eine SW-Komponente ist eine Kollektion von zusammengehörigen Subsystemen, die die Implementierung der SW-Komponente beinhalten. Falls die SW-Komponente ein ausführbares Programm ist, dann ist das Ada-Äquivalent die Partition. Falls es sich um ein nicht-ausführbares System handelt, dann ist das Äquivalent eine Partition oder ein oder mehrere Ada-Subsysteme.

    SW-Einheit

    Eine SW-Einheit im Sinne des V-Modells ist eine weitgehend selbständige Software-Einheit, die eine definierte Funktion des Systems implementiert. Eine SW-Einheit ist eine Programmeinheit, die separat testbar und in der Regel auch ausführbar ist. Dies deckt sich mit der (in Ada 95 sehr weit gefaßten) Definition des Programms. Ein Ada-Programm ist eine Menge von kommunizierenden Partitionen. Im allgemeinen Fall wird eine SW-Einheit also durch eine oder mehrere Ada-Partitionen realisiert. Diese Definition umfaßt sowohl verteilte Systeme wie Ein-Prozessor-Systeme.

    OOS.3.3 Übersicht

    Tabelle OO.1 zeigt im Überblick die Zuordnung von Ada-Sprachelementen zu den Elementen der Erzeugnisstruktur. Dabei können jeweils mehrere Ausprägungen der Ada-Elemente einer Ausprägung des Elements der Erzeugnisstruktur zugeordnet werden.

    Ada-Sprachelement SW-Einheit SW-Komponente SW-Modul
    Ada-Program    
    Partition  
    Verteiltes System    
    Subsystem
    Bibliothekseinheit    
    Unter-Bibliothekseinheit    
    Untereinheit    

    Tabelle OO.1: Zuordnung von Ada-Sprachelementen zur Erzeugnisstruktur

    OOS.4 Anwendung von C++

    OOS.4.1 The Structural Means of C++

    C++ (/Ellis, Stroustrup/, /ANSI Com. X3J16/) bietet neben den objektorientierten Sprachelementen auch die für prozedurale Sprachen bekannten Elemente. (Da C++ nicht zur Verwendung der objektorientierten Elemente zwingt, spricht man auch von einer "hybriden" objektorientierten Sprache.) Die Abbildung auf die Erzeugnisstruktur des V-Modells beschränkt sich daher nicht nur auf die reinen objektorientierten Sprachmittel, sondern umfaßt auch die prozeduralen Anteile.

    Zentrales Strukturierungsmittel in C++ ist die Klasse. Ein objektorientiertes Programm besteht aus einer Menge von Kassendefinitionen, einer Funktion "main" und optional weiteren Funktionen. Die Sprache selbst kennt außer der Verknüpfung von Klassen über Benutzt- oder Vererbt-Beziehungen keine Zusammenfassung von Klassen zu einer Bibliothek. Dies liegt in der Verantwortung der verwendeten Entwicklungsumgebung und wird oft direkt auf das Dateisystem abgebildet. Klassenbibliotheken sind also kein Sprachkonstrukt, sondern eine verwaltungsmäßige Zusammenfassung von Klassen.

    Bestimmend für die Strukturierung von C++-Programmsystemen ist der Gedanke der Übersetzungseinheit. (Dies ist eine Folge der Abwärtskompatibilität zu C.) Der Sichtbarkeitsbereich von lokalen Variablen und Funktionen kann auf eine übersetzbare Datei eingeschränkt oder für die Verwendung in Funktionen aus anderen Übersetzungseinheiten nach außen bekannt (exportiert) werden.

    Die Abhängigkeiten von Übersetzungseinheiten werden nicht von der Sprache selbst, sondern von zusätzlichen Werkzeugen verwaltet. (Meist werden dazu Werkzeuge wie "make" eingesetzt.).

    OOS.4.2 Abbildung auf die Erzeugnisstruktur

    SW-Einheit

    Eine ausgewählte SW-Einheit ist in C++ diejenige, die die main-Funktion enthält. Jedes Anwendungssystem muß eine solche Funktion beinhalten. Diese SW-Einheit ist in dem Sinne lauffähig, daß sie - bei entsprechender Absättigung der statischen Referenzen auf andere SW-Anteile - nach dem Übersetzungs- und Bindevorgang geladen und gestartet werden kann.

    Eine solche SW-Einheit enthält üblicherweise

    die nur für diese eine SW-Einheit gebraucht werden. (Elemente, die auch von anderen SW-Einheiten verwendet werden, werden sinnvollerweise in eigene, wiederverwendbare SW-Einheiten oder SW-Komponenten integriert.)

    Beim Einsatz einer Schichtenarchitektur können von dieser SW-Einheit die Dienste einer oder mehrerer darunterliegenden SW-Einheiten genutzt werden. Für solche SW-Einheiten ergeben sich mit Ausnahme der Ausführungen zur Funktion "main" dieselben Vorgaben.

    Eine SW-Einheit besteht im allgemeinen aus mehreren SW-Modulen und damit aus mehreren Dateien (s. u.). Das KID einer SW-Einheit enthält die Identifikatoren ihrer SW-Module.

    SW-Modul

    Innerhalb einer SW-Einheit wird nach den üblichen Modularisierungskriterien (Abgeschlossenheit, Änderbarkeit, geringe Kopplung, usw.) weiter strukturiert. Es entstehen SW-Module, die üblicherweise folgende Bestandteile enthalten: Zu jedem SW-Modul sollte es eine Spezifikationsdatei (nach Konvention eine Datei mit der Endung ".h"1) geben, die die Außenschnittstelle bekannt gibt. Die Implementierungsdatei (Endung ".cxx", ".cpp" o. ä.) enthält die Umsetzung der Spezifikation mittels C++-Syntax (sie ist die eigentliche Quelldatei).

    Es wird nicht vorgegeben, wie viele Klassen und Funktionen ein SW-Modul enthalten soll. Sinnvollerweise sollte ein SW-Modul jedoch an seiner Schnittstelle (h-Datei) möglich wenige Klassen einführen (möglichst schmale Schnittstelle). (Ob die Publikation einer Klasse pro SW-Modul eine Ideallösung darstellt, ist abhängig von der Anwendung.)

    Nebeneinanderliegende SW-Module können einander nutzen (aufrufen), ohne daß dafür eine Schichtenbildung über SW-Komponenten (s. u.) erfolgen muß.

    SW-Komponenten

    SW-Komponenten fassen üblicherweise SW-Module zusammen, die von mehreren SW-Einheiten verwendet werden oder generell zur Wiederverwendung zur Verfügung gestellt werden. Aus Gründen der effizienten Strukturierung von SW-Einheiten können auch SW-Module innerhalb einer SW-Einheit zu SW-Komponenten zusammengefaßt werden. Dies gilt sinngemäß auch für geschachtelte SW-Komponenten.

    OOS.4.3 Übersicht

    Tabelle OOS.2 zeigt im Überblick die Zuordnung von C++-Sprachelementen zu den Elementen der Erzeugnisstruktur. Eine SW-Einheit oder ein SW-Modul kann dabei mehrere Elemente der zugeordneten C++-Sprachelemente enthalten.

    C++-Sprachelement SW-Einheit SW-Komponentes SW-Moduls
    Funktion  
    Datenelement  
    Klasse  
    (Klassen-) Bibliothek    

    Tabelle OO.2: Zuordnung von C++-Sprachelementen zur Erzeugnisstruktur

    OOS.5 Anwendung anderer objektorientierter oder objektbasierter Sprachen

    Für andere klassische Programmiersprachen wie COBOL und FORTRAN existieren inzwischen objektorientierte (oder objektbasierte) Erweiterungen(4), die sich aufgrund der historischen Entwicklung an Smalltalk, C++ oder Ada 95 orientieren. Für diese Sprachen gelten die oben aufgeführten Regeln und Anleitungen daher analog. Im folgenden werden daher nur die Zuordnungen zu den Sprachelementen in der Form einer Übersicht präzisiert.

    OOS.5.1 Übersicht der Sprachzuordnung für OO-COBOL

    Tabelle OO.3 zeigt im Überblick die Zuordnung von OO-COBOL-Sprachelementen (/ANSI Com. X3J4/) zu den Elementen der Erzeugnisstruktur. Eine SW-Einheit oder ein SW-Modul kann dabei mehrere Elemente der zugeordneten COBOL-Sprachelemente enthalten.

    Die Ausführungen zu Übersetzungseinheiten und zur Einbindung von Klassenbibliotheken in die Sprache sind wie für C++ gültig. Ebenso wie für C++ existiert derzeit ein ANSI-Draft-Standard für OO-COBOL.

    OO-COBOL-Sprachelement SW-Einheit SW-Komponente SW-Modul
    Program  
    Subprogram  
    Klasse (syntaktisch "program")    
    (Klassen-) Bibliothek  

    Tabelle OO.3: Zuordnung von OO-COBOL-Sprachelementen zur Erzeugnisstruktur

    OOS.5.2 Übersicht der Sprachzuordnung für FORTRAN 90

    Tabelle OO.4 zeigt im Überblick die Zuordnung von OO-FORTRAN-Sprachelementen (/ANSI X3.198/) zu den Elementen der Erzeugnisstruktur. Dabei können jeweils mehrere Ausprägungen der OO-FORTRAN-Elemente einer Ausprägung des Elements der Erzeugnisstruktur zugeordnet werden.

    FORTRAN 90 ist keine objektorientierte, sondern lediglich eine objektbasierte Sprache, da die Konzepte der Vererbung und in der Folge des Polymorphismus nicht unterstützt werden. Von der Sprachphilosophie läßt sich FORTRAN 90 in etwa mit dem Stand von Ada 83 vergleichen. Zur Diskussion der Strukturierungsmittel und der Abbildung auf die Erzeugnisstruktur wird deshalb auch auf Obengesagtes zu Ada verwiesen.

    Nachstehend werden die Sprachelemente von FORTRAN 90 der Erzeugnisstruktur des V-Modells zugeordnet:

    FORTRAN-Sprachelement SW-Einheit SW-Komponente SW-Modul
    Program  
    Subroutine/Funktion  
    Benutzerdefinierte Datentypen  
    Bibliotheken    

    Tabelle OO.4: Zuordnung von FORTRAN-Sprachelementen zur Erzeugnisstruktur


    Notes:

    (1) Ergänzend werden die Sprachen OO-COBOL und FORTRAN 90 berücksichtigt.

    (2) Außerdem wird ein eigenes Szenario zur Darstellung objektorientierter Vorgehensweisen im Handbuch Szenarien (ebenfalls in dieser Handbuchsammlung) geschildert, das unabhängig von der eingesetzten Sprache die Auswirkungen des Einsatzes objektorientierter Technologien klärt.

    (3) Diese "h-Dateien" werden durch eine #include-Anweisung importiert.

    (4) objektorientiert = objektbasiert + Vererbung; objektbasiert = modular + Abstraktion + Instantiierung Allgemeiner Umdruck Nr. 250/3

    Previous Next This page online  •  GDPA Online  •  Last Updated 03.Mar.2004 by C. Freericks