Klassendiagramm

[Dog86]

Hallo Leute,

passt evtl. nicht ganz hier rein, aber ich hoffe ihr könnt mir meine Frage dennoch beantworten.

Ich habe ein Klassendiagramm von einer Vereinssoftware auf basis eines Lastenhefts erstellt..das ganze Lastenheft werde ich hier mal nicht posten. Das Lastenheft ist eine Aufgabe unserer Schule.

Was ich jetzt aber wissen wollte ist ob mein Klassendiagramm so grundsätzlich passen würde. Also ob es da keine grundlegenden Entwurfsprobleme gibt oder ähnliches. Sollte sich jmd. finden der Lust hätte mich komplett zu unterstützen, dann kann ich ihm das Lastenheft gern noch zukommen lassen. Ich habe darauf auch schon eine Analyse usw. gemacht.

Also, gibt es bei diesem Diagramm irgendwelche Dinge die euch direkt ins Auge fallen?

 

[Dog86]

Keiner eine Meinung dazu?

 

[hdi]

also beim schnellen Überlfiegen fällt mir auf:

1) Klasse Person sollte abstrakt sein und somit auch als solches im Klassendiagramm gekennzeichnet sein (<<abstract>>).
Es gibt ja keine "Person" an sich, nur Schiedsrichter, Spieler usw. Diese erben davon und implementieren die jeweiligen Methoden bzw. Eigenschaften

2) Du solltest dich an die Namenskonventionen halten. Memebervariablen schreibt man in camelCase, booleans heissen "is...",
d.h. statt "Erwachsen" sollte es heißen "isErwachsen" usw, statt "Email" sollte es heißen "eMail" usw.

3) Vereinsposition & Benutzerrolle sollten als Enumeration implementiert sein, und ich glaube das muss man dann auch kennzeichen (<<enum>>). Ich weiss nicht ob du noch mehr solcher Klassen drinnen hast, aber generell: Jede Klasse, die nicht wirklich etwas richtiges speichert, sondern nur durch ihren Typ einen gewissen Status angibt, sollte eine enumeration sein.

mehr ist mir auf den ersten Blick nicht aufgefallen.

edit:

4) Die Methoden import() und export() der Provider sollten einen Kommentaren bekommen, was die rein logisch machen. Denn sie hängen mit nichts im KlassenDiagramm zusammen und man kann nicht wissen wofür die da sein sollen.

 

[eRaaaa]

ich fang mal an, was mir aufgefallen ist (beim rüberschauen).

klasse spiel:

• tore würde ich lieber als int speichern, anstelle strings.
• ein spiel besteht doch immer aus zwei mannschaften?! die würde ich in einem spiel dann auch da reinlegen.(nicht als string, sondern z.b. als mannschaftsarray)
  

klasse person:
beitrag, wäre doch eher ein attribut der unterklasse spieler ?!

klasse mannschaft:
aus deinem string "spielklasse", vllt überlegen daraus eine eigene klasse zu machen

puhh.jo, denke das wars erstmal von mir
vllt sagt ja wer von den "profis" noch was dazu :>

 

[hdi]

eRaaaaa hat Recht, da stimmt was nicht.

Die Beziehungen zwischen Mannschaft, Spiel und Spielplan sind irgendwie nicht richtig. Ein Spiel zB sollte nicht x Spielpläne kennen, sondern gar keinen. Und ein Spielplan sollte nicht x Mannschaften kennen, sondern gar keinen. (Nur Spiele) Dafür sollte ein Spiel genau 2 Mannschaften kennen.

Außerdem hast du glaub ich noch einen Fehler in der Sportabteilung: Beziehungen zu anderen Klassen werden nicht als Attribute angegeben, sondern eben durch die Verbindungen. D.h. die Vectoren da werden nicht eingetragen, das sieht man ja aus den Verbindungen zu den Klassen. Eine Liste ist einfach eine Verbindung mit dem Multiplikator *.

Das gilt auch für alle anderen Klassen, in denen du sowas eingetragen hast: In UML Klassendiagrammen werden nur primitive Datentypen und Strings als Attribute eingetragen, meinetwegen noch Attribute von java-eigenen Typen. Aber niemals Referenzen auf eigene Klassen.