# Eine anstehende (sehr simple) Applikation in UML darstellen (Klassendiagramm)



## Beckenbauer (1. Dez 2010)

Hallo Leute,

ich will eine Applikation erstellen, die sollte so aussehen:

- Klasse GUI
- Klasse Fussballer (Name, Alter, Position, Rückennummer)
- Klasse Sichern

In der Gui soll es eine Tabelle geben und eine Maske wo ich Informationen über den Fussballspieler eingeben kann.
Es sollen 2 Buttons existieren, Fussballer in die Mannschaft hinzufügen und Tabelle sichern.

D. h. wenn das Programm läuft, können 0 bis unendlich viele Objekte der Klasse Fussballer erzeugt werden (0, wenn man keinen Fussballer hinzufügt und das Programm beendet, oder mehrerer wenn man mehrere Spieler der Tabelle hinzufügt.)

Weiterhin können 0 bis unendliche viele Objekte der Klasse Sichern erzeugt werden. Szenario 1: es wird nichts gesichert und das programm beendet. Szenario 2, es wird mehrere Male die Tabelle gesichert.

Wie müsste das Klassendiagramm dazu aussehen? Wie ist in diesem Fall die Beziehung zwischen den Klassen? Könnte mir da jemand einen Vorschlag machen, wäre sehr sehr dankbar!!! :toll:


----------



## Andi_CH (1. Dez 2010)

Eigentor Herr Beckenbauer  Das ist ein Javaforum wenn ich UML tippe kommt nur

Multiple markers at this line
	- Syntax error, insert "AssignmentOperator Expression" to complete Expression
	- UML cannot be resolved to a variable



Ausserdem wird das GUI eigentlich nie modelliert.
Die Klasse Sichern stelle ich in Frage, es handelt sich um die eingegebenen Daten die in Fussballer gespeichert sind - also muss die Klasse Fussballer nur über eine Methode sichern verfügen - das reicht.


----------



## XHelp (1. Dez 2010)

GUI als solchen, vor allem mit Aktionen, stellst du in UML nicht dar.

Mach du doch ein Vorschlag und dann sehen wir weiter.


----------



## Beckenbauer (1. Dez 2010)

so vielleicht?


----------



## XHelp (1. Dez 2010)

Namen in den Kästchen scheinen zu stimmen...
- was sind das für Linien?
- warum sind die Kästen leer?


----------



## Andi_CH (1. Dez 2010)

GUI wird NICHT modelliert
Die Klasse Sichern braucht es NICHT, denn die enthält dieselben Daten wie Fussballer


----------



## Andi_CH (1. Dez 2010)

XHelp hat gesagt.:


> Namen in den Kästchen scheinen zu stimmen...
> - was sind das für Linien?
> - warum sind die Kästen leer?



Die Linien nennt man Assoziationen (man beginnt wirklich so mit zeichnen, bis man es dann später genauer weiss)

In der Klasse Fussballer fehlen die Attribute und bei Sichern auch, aber das sind eh dieselben, womit dann klar wird dass eine der beiden überflüssig ist.


----------



## ARadauer (1. Dez 2010)

Beckenbauer hat gesagt.:


> - Klasse Sichern



Klassen sollten eher die Nomen sein und Methden Verben...
Objkte von Klassen sind Dinge und Methoden werden gemacht...


----------



## XHelp (1. Dez 2010)

Andi_CH hat gesagt.:


> GUI wird NICHT modelliert


Das ist nicht die GUI, das ist einfach nur eine Klasse namens GUI


Andi_CH hat gesagt.:


> Die Klasse Sichern braucht es NICHT, denn die enthält dieselben Daten wie Fussballer


tut sie das? Selbst wenn... wenn es eine Klasse namens "Sichern" existiert, dann muss die hin.


----------



## Andi_CH (1. Dez 2010)

Siehste - sichern ist eben eine doch Methode von Fussballer, aber er glaubt es ja nicht ;-)


----------



## Andi_CH (1. Dez 2010)

In Java mag ich Anfänger sein. In UML definitiv nicht!

Dumm ist nur, dass wenn man viel Erfahrung hat, geht eben vieles gefülsmässig und dann fehlen die Argumente.

Wenn das im ersten Posting eine Requirements-Spec ist erfülle ich alle Requirements mit einer Klasse

Fusballer
Attribute wie beschrieben
Methode sichern()

That's it

Dass war hier als GUI bezeichnet wird ist vermutlich die View
der Fussballer wird vermutlich später mal in Model und Controller aufgeteilt

So, viel Spass noch, ich habe dazu nichts mehr zu sagen ;-)


----------



## Beckenbauer (1. Dez 2010)

ich würde doch gerne eine Extra Klasse für das sichern machen.
Die Klasse Fussballer wir dann das Interface Serializalbe implementieren.
Die Fussballer sollen in einer Arraylist oder String Array gespeichert werden.


----------



## tfa (1. Dez 2010)

> ich würde doch gerne eine Extra Klasse für das sichern machen.


Die könntest du dann "FussballerDao" nennen (DAO=Data Access Object), oder meinetwegen 
einfach "FussballerDatenbank" oder nur "Datenbank". Die Klasse hat dann eben (wie gesagt) die Methode sichern(). 
Hauptwörter für die Klassennamen und Verben für die Methodennamen ist schon eine sinnvolle Konvention.


----------



## fastjack (1. Dez 2010)

Du hast ein paar Sachen vermischt, das ist aber nicht schlimm. Überlege Dir erstmal ein Datenmodell mit geeigneten Datenklassen, z.B. Fussballer (mit Name, Alter etc.), FussballerPool (da sind sie alle drin  ). 
Danach kannst Du dieses Klassen programmieren und Dir geeignete Klassen überlegen, wie Du Deine Daten persistieren möchtest. 
Auf einem Extrablatt kannst Du Dir aufmalen, wie die GUI funktionieren soll? Welche Aktionen sollen möglich sein, welche Dialoge? etc. etc. Das mußt Du dann auch programmieren, unter Benutzung der Zugriffsklassen und der Datenklassen.
Am "einfachsten" und schnellsten kannst Du das im Speicher persistieren, sozusagen im FussballerPool. Der geht aber flöten, wenn die "GUI" beendet wird, außer man sichert ihn. Aber so kann Du schon mal einfach anfangen.


----------



## Beckenbauer (1. Dez 2010)

Mir gehts halt wie gesagt darum, ein UML diagramm zu erzeugen, der programmierteil wird nicht das problem sein.

Der Fall ist der, dass ich in meiner GUI Klasse, objekt der Klasse "Fussballer" und "Sicher" erzeugen kann.
Wie müsste dann die Beziehung zwischen den Klassen sein? :noe:


----------



## fastjack (1. Dez 2010)

Ein Bild des Gesamtkunstwerks macht sich auch immer gut. Also wie agiert die GUI mit den Daten, wo wird die "Sicherung" angestoßen etc. Dazu reichen Papier und Bleistift


----------



## fastjack (1. Dez 2010)

Du bräuchtest eine Liste mit Fussballern. In diese "füllt" die GUI durch anlegen neue Fussballer ein oder ändert bestehende. Die Sicher-Klasse müßte dafür sorge tragen, das die Liste gespeichert und geladen wird.


----------



## Beckenbauer (1. Dez 2010)

wird auf den "zur tabelle hinzufügen" button geklickt, muss ja ein Fussballer Objekt erzeugt werden.

wird auf sichern gedrückt muss ein objekt der klasse sichern erzeugt werden.

wie müsste ich diesen fall in einem UML Diagramm darstellen? :noe:


----------



## ARadauer (1. Dez 2010)

Ich bin auch der Meinung, dass sich Fachobjekte nicht selber persistieren sollen.
Also ich würde einem Fussballer definiv keine sichern Methode geben!
Warum? Das ist nicht seine Aufgabe! Ein Fussballer sicher keine Fussballer... ein Fussballer Datenzugiffsobjekt hingegen schon...
Wie tfa schon sagt.. FussballerDOA ;-)
Sonst mischt man in großen Anwendungenauf einmal Business Logik mit Verahlten der Persistenzschicht..


----------



## ARadauer (1. Dez 2010)

Beckenbauer hat gesagt.:


> wird auf den "zur tabelle hinzufügen" button geklickt, muss ja ein Fussballer Objekt erzeugt werden.
> 
> wird auf sichern gedrückt muss ein objekt der klasse sichern erzeugt werden.
> 
> wie müsste ich diesen fall in einem UML Diagramm darstellen? :noe:


mhn welches UML Diagramm? Da gibst verschiedene... reden wir hier über Klassendiagramme?
Stellt man sowas schon in Klassendiagrammen dar? Ich würd da nur Struktur darstellen...


----------



## Beckenbauer (1. Dez 2010)

Ja ein Klassendiagramm, wo die Beziehung zwischen den Klassen dargestellt werden soll.


----------

