Abstrakter Datentyp

aus Wikipedia, der freien Enzyklopädie
Wechseln zu: Navigation, Suche

Ein Abstrakter Datentyp (ADT) ist ein Verbund von Daten zusammen mit der Definition aller zulässigen Operationen, die auf sie zugreifen.

Beschreibung[Bearbeiten]

Da der Zugriff nur über die festgelegten Operationen erfolgt, sind die Daten nach außen gekapselt.

Ein ADT beschreibt, was die Operationen tun (Semantik), aber noch nicht, wie sie es tun (Implementierung). Auch kann das Konzept des ADTs unterschiedlich spezifiziert und ein ADT auf verschiedene Weise notiert werden, bspw. durch Pseudocode oder durch eine mathematische Beschreibung. Modernere Programmiersprachen unterstützen allerdings gezielt die Erstellung von ADTs.

Objektorientierte Programmiersprachen unterstützen durch ihr Klassenkonzept die Erstellung von ADTs, da hier Daten und Operationen gebunden werden, die Daten geschützt und die zulässigen Operationen festgelegt werden können. Einige modulare Programmiersprachen wie Ada oder Modula-2 unterstützen ebenfalls gezielt die Erstellung von ADTs. In der Regel ist es möglich, einen ADT durch Definition der Daten und der Signaturen der Operationen festzulegen, während die Semantik als Kommentartext beschrieben wird.

Beispiel
Java unterstützt ADTs durch Klassen, abstrakte Klassen und Interfaces. In einem Interface werden nur Daten und Signaturen der Operationen definiert, eine festgelegte Klasse implementiert erst das Interface. Allgemein legt eine Klasse die Daten und die darauf zulässigen Operationen fest.


Spezifikationen[Bearbeiten]

Ein abstrakter Datentyp kann durch unterschiedliche Spezifikationen angegeben werden. Eine Spezifikation besteht aus einer Signatur und einer Semantik, die Bedeutung und Interaktion der Operationen festlegt.

Mathematisch betrachtet handelt es sich um die Spezifikation einer Termalgebra durch Signatur, Erzeuger und Axiome. Daraus ergibt sich die erste Art der Spezifikation, die mathematisch-axiomatische.

Eine weitere Möglichkeit ist die mathematisch-algebraische Spezifikation, die sich nur in der Angabe der Semantik von der axiomatischen unterscheidet. Die inhaltliche Bedeutung der Operationen wird hierbei durch mathematische Mittel, Matrizen, Vektoren, Folgen, etc. definiert.

Daneben existieren Sonderformen, wie die informelle Methode der Spezifikation – durch Angabe einer Schnittstelle einer Programmiersprache, bspw. als Java-Schnittstellen oder die Implementierung des Datentyps in einer funktionalen Programmiersprache wie Haskell – was im ersten Moment widersprüchlich zu dem Bestreben steht, den Datentyp unabhängig von einer Implementierung zu machen. Die Implementierung in einer funktionalen Programmiersprache dient allerdings als Spezifikation für ADTs, die schließlich in prozeduralen oder objektorientierten Sprachen implementiert werden. Der Vorteil dieser Spezifikation ist, dass gleich getestet werden kann, ob die Spezifikation sinnvoll ist, was bei den anderen Möglichkeiten, besonders der axiomatischen, nicht ohne weiteres möglich ist.

Beispiel[Bearbeiten]

Im Folgenden werden die ADTs Stapelspeicher (Stack, arbeitet nach dem Last-in-First-out-Prinzip) und Warteschlange (Queue, arbeitet nach dem First-in-First-out-Prinzip) in den angesprochenen vier Spezifikationen definiert.

Signatur[Bearbeiten]

Mathematisch-axiomatische und -algebraische Methode[Bearbeiten]

STACK (wird hier definiert)
ELEMENT (ein hier nicht definierter ADT, mit dem der Stack arbeitet)
BOOL
emptyStack: → STACK (erzeugt einen leeren Stack)
isStackEmpty: STACK → BOOL (fragt nach, ob der Stack leer ist)
push: ELEMENT × STACK → STACK (packt ein Element oben auf den Stack)
pop: STACK → STACK (entfernt das oberste Element und gibt den neuen Stack zurück)
top: STACK → ELEMENT (gibt das oberste Element zurück, ohne es zu entfernen)
QUEUE
ELEMENT
BOOL
emptyQueue: → QUEUE
isQueueEmpty: QUEUE → BOOL
enqueue: ELEMENT × QUEUE → QUEUE (fügt ein Element unten an)
dequeue: QUEUE → QUEUE (entfernt das vorderste Element)
head: QUEUE → ELEMENT (gibt das vorderste Element zurück, ohne es zu entfernen)

Informelle Methode (Java)[Bearbeiten]

public interface IStack<E> {
    // Konstruktor in der konkreten Klasse
 
    public boolean isStackEmpty();
    public IStack<E> push(E elem);
    public IStack<E> pop();
    public E top();
}
 
public interface IQueue<E> {
 
    public boolean isQueueEmpty();
    public IQueue<E> enqueue(E elem);
    public IQueue<E> dequeue();
    public E head();
}

Spezifikation durch eine funktionale Programmiersprache (Haskell)[Bearbeiten]

data Stack e = E | S e (Stack e)
isStackEmpty :: Stack a → Bool
push :: e → Stack e → Stack e
pop :: Stack e → Stack e
top :: Stack e → e
 
data Queue e = E | Q (Queue e) e
isQueueEmpty :: Queue e → Bool
enqueue :: e → Queue e → Queue e
dequeue :: Queue e → Queue e
head :: Queue e → e

Semantik[Bearbeiten]

Auch bei genauerer Betrachtung der (identischen) Signaturen sind keine Unterschiede zwischen den Datentypen zu erkennen. Erst mit der Definition der Semantik ergeben sich Unterschiede.

Mathematisch-axiomatische Methode[Bearbeiten]

 x: ELEMENT
 s: STACK
 isStackEmpty(emptyStack()) = TRUE
 isStackEmpty(push(x,s)) = FALSE
 pop(emptyStack()) = ERROR
 pop(push(x,s)) = s
 top(emptyStack()) = ERROR
 top(push(x,s)) = x
 push(top(s),pop(s)) = s, falls s nicht leer
 x: ELEMENT
 q: QUEUE
 isQueueEmpty(emptyQueue()) = TRUE
 isQueueEmpty(enqueue(x,q)) = FALSE
 head(emptyQueue()) = ERROR
 head(enqueue(x,q)) = IF isQueueEmpty(q) THEN x ELSE head(q)
 dequeue(emptyQueue()) = ERROR
 dequeue(enqueue(x,q)) = IF isQueueEmpty(q) THEN q ELSE enqueue(x, dequeue(q))

Mathematisch-algebraische Methode[Bearbeiten]

SETS ELEMENT = E (Menge der Elemente) x \in E
     STACK = S = \lbrace \langle \rangle \rbrace \cup \lbrace \langle x_1{,}...{,}x_n \rangle|x_i \in E \and\ n\in \mathbb{N} \land n \ge 1 \rbrace
FUNCTIONS
    emptyStack      = \langle \rangle
    isStackEmpty(S) = (S == \langle \rangle)
    push(S,x)       = \langle x \rangle, falls (S == \langle \rangle)
                    = \langle x_1{,}...{,}x_n{,}x \rangle, falls (S == \langle x_1{,}...{,}x_{n} \rangle)
    top(S)          = \perp, falls (S == \langle \rangle)
                    = x_n\,, falls (S == \langle x_1{,}...{,}x_{n} \rangle, n \ge 1)
    pop(S)          = \perp, falls (S == \langle \rangle)
                    = \langle \rangle, falls (S == \langle x \rangle)
                    = \langle x_1{,}...{,}x_{n-1} \rangle, falls (S == \langle x_1{,}...{,}x_{n} \rangle, n \ge 2)
SETS ELEMENT = E (Menge der Elemente) x \in E
     QUEUE = Q = \lbrace \langle \rangle \rbrace \cup \lbrace \langle x_1{,}...{,}x_n \rangle|x_i \in E \and\ n\in \mathbb{N} \land n \ge 1 \rbrace
FUNCTIONS
    emptyQueue      = \langle \rangle
    isQueueEmpty(Q) = (Q == \langle \rangle)
    enqueue(Q,x)    = \langle x \rangle, falls (S == \langle \rangle)
                    = \langle x{,}x_1{,}...{,}x_n \rangle, falls (S == \langle x_1{,}...{,}x_{n} \rangle)
    head(S)         = \perp, falls (S == \langle \rangle)
                    = x_n\,, falls (S == \langle x_1{,}...{,}x_{n} \rangle, n \ge 1)
    dequeue(S)      = \perp, falls (S == \langle \rangle)
                    = \langle \rangle, falls (S == \langle x \rangle)
                    = \langle x_1{,}...{,}x_{n-1} \rangle, falls (S == \langle x_1{,}...{,}x_{n} \rangle, n \ge 2)

Informelle Methode (Java)[Bearbeiten]

Semantik: durch Angabe von Voraussetzung und Effekt/Ergebnis der Methode (beim objektorientierten Programmieren entfällt meist die Notwendigkeit, als Voraussetzung die Existenz der Datenstruktur anzugeben, da die Methode an ein Objekt gebunden ist, was schon existiert).

public interface IStack<E> {
    // Konstruktor in der konkreten Klasse
 
    // Ergebnis: true, wenn der Stack leer ist, false andernfalls
    public boolean isStackEmpty();
 
    // Effekt: Der Stack enthält das Element elem als oberstes Element.
    // Ergebnis: Der Stack nach dem Einfügen des Elements elem.
    public IStack<E> push(E elem);
 
    // Voraussetzung: Der Stack ist nicht leer.
    // Effekt: Das oberste Element wird vom Stack gelöscht.
    // Ergebnis: Der Stack nach dem Löschen.
    public IStack<E> pop();
 
    // Voraussetzung: Der Stack ist nicht leer.
    // Ergebnis: Das oberste Element.
    public E top();
}
public interface IQueue<E> {
    public boolean isQueueEmpty();
    public IQueue<E> enqueue(E elem);
    public IQueue<E> dequeue();
    public E head();
}

Spezifikation durch eine funktionale Programmiersprache (Haskell)[Bearbeiten]

emptyStack = E
isStackEmpty E = True
isStackEmpty (S x xs) = False
push e xs = S e xs
pop (S x xs) = xs
top (S x xs) = x
 
emptyQueue = E
isQueueEmpty E = True
isQueueEmpty (Q xs x) = False
enqueue e xs = Q xs e
dequeue E = E
dequeue (Q (E) x) = E
dequeue (Q (Q ys y) x) = enqueue x (dequeue (Q ys y))
head E = error "Queue ist leer."
head (Q (E) x) = x
head (Q (Q ys y) x) = head (Q ys y)

Angestrebte Eigenschaften[Bearbeiten]

Anzustrebende Eigenschaften eines gut programmierten ADT und meist auch einer gut spezifizierten Datenstruktur sind:

  • Universalität (implementation independence): Der einmal entworfene und implementierte ADT kann in jedes beliebige Programm einbezogen und dort benutzt werden (z. B. in Form einer Unit).
  • Präzise Beschreibung (precise specification): Die Schnittstelle zwischen Implementierung und Anwendung muss eindeutig und vollständig sein.
  • Einfachheit (simplicity): Bei der Anwendung interessiert die innere Realisierung des ADT nicht, der ADT übernimmt seine Repräsentation und Verwaltung im Speicher selbst.
  • Kapselung (encapsulation): Die Schnittstelle soll als eine hermetische Grenze aufgefasst werden. Der Anwender soll sehr genau wissen, was ein ADT tut, aber keinesfalls, wie er es tut.
  • Geschütztheit (integrity): Der Anwender kann in die interne Struktur der Daten nicht eingreifen. Die Gefahr, Daten ungewollt zu löschen bzw. zu verändern sowie Programmierfehler zu begehen, ist dadurch deutlich herabgesetzt.
  • Modularität (modularity): Das modulare Prinzip erlaubt übersichtliches und damit sicheres Programmieren und leichten Austausch von Programmteilen. Bei der Fehlersuche können einzelne Module sehr isoliert betrachtet werden. Viele Verbesserungen können über ADTs nachträglich ohne die geringste Änderung in sämtlichen Umgebungs- bzw. Anwendungsprogrammen übernommen werden.

Wird objektorientiert programmiert, können diese Eigenschaften besonders leicht erfüllt werden, weil das objektorientierte Paradigma auf natürliche Weise die Erstellung von ADTs unterstützt. Eine weitere Möglichkeit zur Erstellung von ADTs (auch in Verbindung mit objektorientierter Programmierung) sind generische Typen.

Literatur[Bearbeiten]

  • Barbara Liskov, Stephen Zilles: Programming with abstract data types. in SIGPLAN Notices, Vol. 9, No. 4, pp 50–59, 1974
  • John Guttag: Abstract Data Types and the Development of Data Structures. in Communications of the ACM, Vol. 20, No. 6, pp. 396–404. 1977
  • J. A. Goguen, J. W. Thatcher, E. W. Wagner: An Initial Algebra Approach to the Specification, Correctness and Implementation of Abstract Data Types. in Current Trends on Programming Methodology, Vol. IV, (Yeh R.T. Ed.), Prentice-Hall Int., 1978
  • Hartmut Ehrig, Bernd Mahr: Fundamentals of Algebraic Specification 1 – Equations and Initial Semantics. Springer-Verlag, 1985
  • Luca Cardelli, Peter Wegner: On Understanding Types, Data Abstraction, and Polymorphism. in Computing Surveys, Vol. 17, No. 4, pp. 470–522 Dezember 1985
  • John C. Mitchell, Gordon D. Plotkin: Abstract Data Types Have Existential Type. in ACM Transaction on Programming Languages ans Systems, Vol. 10, No. 3, pp. 470–502. Juli 1988
  • Peter Müller: Introduction to Object-Oriented Programming Using C++. Kapitel zu ADTs online.
  •  Jorge Martinez: Ordered algebraic structures: proceedings of the Gainesville conference sponsored by the University of Florida 28th February-3rd Marchf, 200. Kluwer Academic Publishers, Dordrecht; Boston 2002, ISBN 978-1-4020-0752-1 (eingeschränkte Vorschau in der Google-Buchsuche, abgerufen am 5. Juli 2010).
  •  Rolke/Sennholz: Grund- und Leistungskurs Informatik. Cornelsen, Düsseldorf 1992, ISBN 3-464-57312-5.