Protokoll der Gruppe:  Brainstorm mkH
                                      Vom: 18.12.00

Anwesende:   Brigitte Bonder        bonder@uni-muenster.de              Sitzungsleiter: Holger Picker
                     Wolfgang Hoppe       hoppew@math.uni-muenster.de    Protokollantin: Brigitte Bonder
                     Holger Picker            pickerh@uni-muenster.de
                     Martin Swobodzinski Martin.Swobodzinski@t-online.de
                    Ludmilla Scheinker   scheink@math.uni-muenster.de
                     Knut Willems           xenon@uni-muenster.de

Das ganze Programm wurde grundlegend vom Aufbau,d.h. von der Code-Struktur, her geändert.
Es gibt nun eine Klasse Start, in der bei Ausführung eine Instanz der Klasse UMLTOPP
erstellt wird und damit die Methode start() ausgeführt wird.
Die Methode start() sorgt dafür, daß das GUI_UMLTOPP - Fenster (also unsere Anfangsarbeitsumgebung)
sichtbar wird.
Desweiteren existieren nun nicht mehr getrennte Klassen und Gui´s
sondern die Klasse "Klasse" enthält z.B. die Gui_Klasse (graphische Oberfläche von Klasse),
die Klasse Info,  innere Klassen Methode und Attribute zur internen Speicherung.

Durch diese Datenkapselung erhalten wir, wie gefordert, unabhängige Komponenten
Dies ist bereits für die Klasse "Klasse" verwirklicht, für die anderen Komponenten wird es
in analoger Weise geschehen.
 

Außerdem liegt das Editierfenster für die Verbindungen vor:

welche Fenster sollen parallel geöffnet sein können ? :

Es musste verhindert werden, dass mehrere Editierfenster derselben Komponente gleichzeitig
geöffnet sind. Dahingegen dürfen unterschiedliche Editierfenster gleichzeitig auf sein.
Hierzu gibt es in der seit der letzten Stunde in der neuen Klasse UMLTOPP die
boolean - Werte klasse_offen, usecase_offen etc. Zu Beginn sind sie auf false gesetzt,
wird ein Editierfenster geöffnet, wird dieser WErt auf true gesetzt, bis das Fenster wieder
geschlossen wird. Man kann also nur ein Fenster öffnen, wenn der Boolean - Wert auf
false steht.

saubere Objektzerstörung realisieren :

Da, wenn man eine Gui schließt, dann nicht auch gleich die erstellte
Instanz zur internen Speicherung der Komponente entfernt wird, machen wir das jetzt selber und warten nicht auf den
den  Java Garbage - Collector.

neues Konzept für das Use - Case - Editierfenster :

Aufgrund der andauerenden Probleme mit dem Hinzufügen und ordentlichen Anzeigen der
kleinen Fenster zur Dateneingabe bei den UseCases
entwarfen wir ein völlig neues Kozept auf der Grundlage unserer gesammelten GUI-Erfahrungen:
Das Guifenster enthält wie bisher Felder für die Nameneingabe und den Info - Button.
Darunter folgt eine JList, die default - mäßig einige Angaben enthält:
Akteur, Vorbedingung, Ablauf, Nachbedingung.
"Akteur" ist markiert. Über einen darunter befindlichen Button "Neues Element" kann man leere Fenster hinzufügen,
die immer unter dem markierten Element eingefügt werden, über "Element löschen" kann man ein markiertes Element entfernen.
Hat man nun ein Element der Liste markiert, so erscheint der Name im darunterbefindlichen
JTextField. Den Namen kann man verändern oder überhaupt erst eingeben, falls das Element
neu hinzugefügt wurde und noch leer ist. Unter dem JTextField liegt eine JTextArea. Hier
kann man den Ablauf, die Bedingungen etc. eingeben und mit dem Button "Übernehmen"
wird der Text intern gespeichert und der Name in der Liste angezeigt. Markiert man wieder
einen Namen in der Liste, so wird der Text hierzu in der TextArea angezeigt und kann
bearbeitet werden.
 
 

Hausaufgaben:

Martin: Erstellung der Use - Case - GUI
Knut: Fertigstellen der Klasse "Klasse",
         Zusammenstellen des Programms aus Knuts und Martins Ergebnissen
Ludmilla: Fertigstellen der  Verbindungen - GUI
Holger: XML - Code in Javanahem PseudoCode
Brigitte: Fertigstellen der Klasse "Objekt"