kramann.info
© Guido Kramann

Login: Passwort:










Informatik3
1 Vom_struct_zur_Klasse
..1.1 Vom_struct_zur_Klasse
..1.2 struct_Programm
..1.3 Klassen_Programm
..1.4 Offene_Fragen
..1.5 Historie
..1.6 Objektabstraktion
..1.7 OO_Kundenverwaltung
..1.8 Objektfaehigkeiten
..1.9 Formatierung
..1.10 Motivation
..1.11 Uebung1
..1.12 Uebung2
2 UML
..2.1 Volumenberechnung
..2.2 UML_Klassendiagramm
..2.3 Konstruktor
..2.4 Statische_Variable
3 Strings
..3.1 Klassenbibliotheken
..3.2 stringUML
..3.3 Uebung3
4 Initialisierungen
4 bluej
5 Zeiger_und_Arrays
..5.1 Zeiger
..5.2 Zeiger_und_Funktion
..5.3 Uebung4
6 Vererbung
..6.1 MesswerteUML
..6.2 MesswerteProgramm
..6.3 VererbungsProgramm
..6.4 Vector
..6.5 Uebung
7 Modifikatoren
..7.1 public_Vererbung
..7.2 protected_Vererbung
8 Listen_und_Templates
..8.1 Containertypen
....8.1.1 ListeUML
....8.1.2 ListeProgramm
..8.2 Templates
....8.2.1 Listentemplate
....8.2.2 STLvectorTemplate
..8.3 Uebung5
..8.4 Uebung6
..8.5 Uebung7
9 Java
..9.1 Uebung
..9.2 GettingStarted
..9.3 Animation
..9.4 Hybrid
..9.5 Threads
10 Delegation
11 LayoutProjekt
12 Fenster
13 Uebung
14 Zwischenprojekt
..14.1 Befehle
..14.2 Planung
..14.3 JNI
..14.4 JNIumsetzen
..14.5 Anwendungsklasse
..14.6 GUI01
..14.7 GUI02
15 Rasterlayout
..15.1 Bilder_Packages
..15.2 interfaces
..15.3 ArrayList
..15.4 clone
..15.5 Uebung
16 Nuetzliches
..16.1 Threads
..16.2 Animation
..16.3 RungeKutta
..16.4 Loesungsansatz
..16.5 Internetprogrammierung
....16.5.1 Codegenerierung
....16.5.2 PHP_Programmierung
....16.5.3 PHP_OOP
....16.5.4 Java
17 Algorithmen
..17.1 RungeKutta
..17.2 Loesungsansatz
..17.3 Evoopt
..17.4 Uebung12
..17.5 Uebung8_2014
..17.6 Ausdruecke
18 Uebung10
19 UML_ALT
..19.1 Flaechenberechnung
..19.2 UML_Flaechenberechnung
..19.3 Implementierung
..19.4 ListeUML
..19.5 ListenImplementierung
..19.6 Anwendung
kramann.info
© Guido Kramann

Login: Passwort:




Entwurf einer einfach verketteten Liste mit UML-Klassen- und UML-Objekt-Diagrammen

Eine zentrale Fertigkeit, die man als Programmierer besitzen sollte, ist die, Files in ein Programm einzulesen, oder abzuspeichern. Neben dem Einlesen aller Zeichen eines Files, müssen diese auch von dem Programm interpretiert werden. So kann es sich um Befehle handeln, die durch Leerzeichen von einander getrennt sind, oder um ein Zahlen-Array. Um die Komplexität der im einzelnen durchzuführenden Teilaufgaben bei der Programmierung so gering wie möglich zu halten, wird im folgenden der Ansatz verfolgt, dass zunächst alle Zeichen, ohne sie zu interpretieren eingelesen wurden und nun als Objekt vom Typ string vorliegen. Im folgenden wird ein Programm entworfen, das in der Lage ist, solch ein string nach vorgegebenen Trennzeichen zu durchsuchen und es in Teilstrings zu zerlegen, die dann in einer Liste abgelegt werden. Die Liste wurde als Datenstruktur zum Speichern der Teilstrings gewählt, da zunächst nicht die Anzahl der zu findenden Teilstrings bekannt ist.

In folgendem UML-Klassen-Diagramm sind die Container-Klasse "ListenContainer" und die Klasse "Liste" dargestellt, deren Objekte durch ein Objekt vom Typ Container-Klasse verwaltet wird.

Die Verwaltung der Listenobjekte in "ListenContainer" soll über die Methoden append(), get(), del() und clear() erfolgen.

In dem Attribut "kopfelement" wird die Referenz auf den Beginn der Liste gespeichert.

Das besondere an der Klasse Liste ist, dass sie ein Attribut "nachfolger" enthält, das vom Typ *Liste ist. Dieses dient dazu, um Listenelemente miteinander zu verketten. Es besitzt noch ein weiteres Attribut, in dem die eigentlichen Daten gespeichert werden. Theoretisch hätte nachfolger auch vom Typ Liste sein können, also kein Pointer. C++ läßt aber keine direkte Referenz auf noch nicht vollständig definierte Klassen zu, da der Compiler dann nicht die Größe des zu allokierenden Speichers kennt. Da aber zum Anlegen eines Zeigers der Speicherbedarf des dahinter liegenden bekannt sein braucht, funktioniert es sehr wohl, Pointer innerhalb einer Klasse auf Objekte des gleichen Typs zu verwenden. Voraussetzung dafür ist, dass die Klasse deklariert ist und das ist mit Angabe des Klassenkopfes der Fall.

Die Methode get() liefert das Listenelement, das an i-ter Stelle steht zurück. Mit append() kann ein neues Listenelement an das Ende der Liste angefügt werden. Da sich ein Benutzer dieser Klasse nicht für die Listenelemente vom Typ Liste interessiert, sondern nur für deren Inhalt, nämlich den Datenstring, liefert get() nicht das Listen-Objekt zurück, sondern dessen Inhalt. Genauso wird der Methode append() nicht ein zuvor mühsam erzeugtes Listenelement übergeben, sondern dessen gewünschter Inhalt. Das Erzeugen des neuen Listenelements übernimmt dann append() selber.

UML KLassen-Diagramm zur Listen-Implementierung

Bild 0-1: UML KLassen-Diagramm zur Listen-Implementierung

Ein weiterer Typ von UML-Diagrammen sind die so genannten Objekt-Diagramme. Diese können dazu benutzt werden, die zur Laufzeit bestehenden Assoziationen zwischen den erzeugten Objekten anzuzeigen. Es handelt sich hierbei um eine Momentaufnahme, da Objekte im Verlauf des Programms ja auch wieder zerstört werden können.

Bei Objektdiagrammen wird bei der Darstellung eines Objektes in einem oberen Kasten der Objektname gefolgt von einem Doppelpunkt und dem zugehörigen Klassenname dargestellt. Der Objektname kann auch weggelassen werden, dann steht nur der Klassenname und links von ihm ein Doppelpunkt da.

Unterhalb des Kastens mit dem Objektnamen kann ein weiterer Kasten mit den Attributen folgen. Die Methoden werden bei Objektdiagrammen nicht angezeigt.

Über den Assoziationen darf auch bei Objektdiagrammen noch eine Beschreibung der Art der Beziehung stehen.

Das untige Objektdiagramm soll verdeutlichen, dass das Container-Objekt den Beginn der Liste als Referenz besitzt, dass der Listenbeginn einen Nachfolger als Listenelement besitzt usw.

UML Objekt-Diagramm zur Listen-Implementierung

Bild 0-1: UML Objekt-Diagramm zur Listen-Implementierung