Seite 1 von 1
Tipps für UML?
Verfasst: 10.12.2006 19:21
von DarkDragon
Hallo,
UML ist für mich wie Deutsch: Unlogischer als Mathematik. Desshalb fällt es mir auch schwer z.B. zwischen Komposition und Assoziation zu unterscheiden. Ich brauche ein paar Tipps wie man Deutsche Texte zu einem UML Diagramm umwandelt. Ich komm immer auf andere Ergebnisse als auf der Musterlösung zu sehen ist.
Verfasst: 10.12.2006 20:50
von Froggerprogger
Es gibt bei UML nicht nur eine einzige richtige Lösung, sondern durchaus eine ganze Reihe verschiedener.
Mein Vorgehen ist dabei in etwa so:
Phase 1:
- alle Substantive im Text markieren, die irgendwie einen eigenständigen Begriff bescheiben, z.B. Auto, Personalausweis, Fahrzeug, Karre, etc.
- Dabei auch alle Eigenschaften mitnotieren, z.B. Farbe des Autos, Nummer des Personalausweises. Diese werden später die Attribute.
Auch werden oft gleich Methoden mitgenannt, z.B. beschleunigen(), etc.
- Synonyme auflösen, also z.B: Karre = Auto
- Manchmal kann man entscheiden, ob man etwas als Attribut oder Klasse modelliert, z.B. ob man Punkt als Klasse mit Attributen x, y, z modelliert oder direkt als Array-Attribut
Phase 2:
- Jetzt gehts um die Beziehungen untereinander:
- Vererbung, z.B: Auto IST Fahrzeug. Attribute und Methoden werden geerbt
- "Besteht aus", also Aggregation, z.B: Reifen ----<> Auto
- Den Rest "Hat zu tun mit" als Assoziationen. Hier gibt es die größte Freiheit und Quellen für Fehler, insbesondere bei den Kardinalitäten. Also immer wieder Beispielinstanzen des Diagramms durchspielen und schauen, ob es ungewollte Kombinationen gibt, oder ob einige gewünschte nicht erzeugt werden können. Das ist der Hauptpunkt: Die Menge der validen Instanzen soll mit der im Text formulierten übereinstimmen.
Alles in allem ist es meiner Meinung nach immer ein wenig schwammig, aber trotz allem bleibt die UML wirklich ein hilfreiches Mittel, wenn man komplexere Programme angeht, insbesondere wenn man nacher objektorientiert programmiert und die Klassen direkt aus den Klassendiagrammen runtercoden kann.
Verfasst: 10.12.2006 21:11
von DarkDragon
Danke

. Bis Dienstag muss ich das können

Verfasst: 27.03.2007 16:56
von DarkDragon
Also ich meld mich jetzt nochmal nach langer Zeit (Der Lehrer hat die Arbeit immer wieder aufgeschoben, aber ich habs auch vergessen hier eine Rückmeldung zu schreiben): Der Schnitt der Arbeit war 3 komma irgendwas Punkte. Ich hatte 6 (von 15 möglichen Noten-Punkten). Ich halte es nicht für sinnvoll Abiturnievauarbeiten zu schreiben. Lieber vorher lauter 15 Punkte und im Abitur schriftlich 5 oder so, dann reicht das gut für alle aus unserer Klasse. Einige jammern jetzt schon, dass sie wahrscheinlich nächstes Jahr nichtmehr da sein werden, weil sie schon in 2 Fächern unterbelegt waren und darunter war das Profilfach IT.
Hoffentlich wird die Arbeit am Donnerstag über Zustandsdiagramme und Anwendungsfalldiagramme nicht genauso schrecklich.
Als ich nicolaus mein Pflichtenheft vom Projekt gezeigt hab, hat er gemeint das wäre eine Spitzenarbeit. Ich geh aber erst aufs Gymnasium und bekomme dort schlechte Noten (WAS FÜR ANSPRÜCHE WERDEN DA GESTELLT?!). Der Lehrer selbst hat schon gemeint, dass er einen Prof. auf einer Uni kennt, dem er ein paar Projekte gezeigt hat. Die Antwort des Professors bestand aus einem großen Staunen und der Bemerkung seine Studenten würden so etwas niemals bewältigen.

Und da sagt nochmal einer, wir Schüler hätten es zu leicht.
Eine kleine Frage hätte ich da noch zum Anwendungsfall/Geschäftsprozessdiagramm:
Wie kann man die Unterschiede zwischen Erweitern - Beinhalten - Assoziation besser erkennen?
Ich mein Assoziationen sind ja eigentlich nur Wege wie man zu einem Anwendungsfall kommt. Erweitern bedeutet man kann zusätzlich zu diesem Anwendungsfall kommen und Beinhalten bedeutet es wird automatisch auch zu diesem Anwendungsfall kommen.
Ist das so richtig? Und wieso mache ich eigentlich die Anwendungsfalldiagramme immer so klein?

Verfasst: 27.03.2007 18:38
von Froggerprogger
In den UseCase (Anwendungsfall)-Diagrammen haben wir extend (Erweitern) und include (Beinhalten) leider nur am Rande behandelt.
Was mir noch grob dazu einfällt:
A ----- <<extend>> -----> B
UseCase B ist die 'Hauptaktivität', welche z.B. unter gewissen Nebenbedingungen (insbesondere also ggf. nur manchmal) erweitert wird durch die Funktionalität von A. D.h. in B gibt es eine Stelle, in der ggf. zu A verzweigt wird, und dann zu B zurückgekehrt wird. So könnten z.B. in A optionale Sonderbehandlungen für Aktoren gepackt werden, die von anderen Aktoren erben, die A nutzen.
A <----- <<include>> ----- B
UseCase B ist wieder die 'Hauptaktivität'. Zur Abarbeitung benötigt sie immer die Aktion A, welche quasi als Unterprogrammaufruf abgearbeitet wird. Dies kann man nutzen, um etwas umfassendere UseCases auseinanderzuziehen, oder häufiger verwendete Teilaufgaben zu kapseln.
Insgesamt wurde uns von zu häufigem Gebrauch von extend und include abgeraten, da sie sonst das UseCase-Diagramm zu unübersichtlich machen. Insbesondere soll man darin ja noch keine richtige funktionale Zerlegung betreiben, sondern eher gröbere Abläufe identifizieren und ihre Zusammenhänge darstellen. Als ganz grobe Richtlinie war angesagt, etwas ist ein UseCase, wenn nach dessen Abarbeitung ein Kaffeetrinker einen Schluck Kaffee trinken würde.
Unsere Schwerpunkte waren allerdings Klassendiagramme und StateCharts (Zustandsdiagramme), letztere dann auch mit Superstates, History-States und anderem solchen Zeug.
Klingt aber schon krass, was da von euch in den Klausuren verlangt wird - und insbesondere, wie es dafür benotet wird. Es wäre ja in Ordnung, die Schüler stark zu fordern, aber dann auch in der Benotung etwas milder zu sein. In beiden Fällen wird man wohl etwa gleichviel mitnehmen, aber ist im zweiten Falle besser motiviert und hat später einen besseren Notenschnitt. Was bringen einem die besten Abiturinhalte, wenn man nachher mit seinem Schnitt keinen Studienplatz bekommt.
Ist denn der Lehrer mit dem erstaunten Prof.-Bekannten auch derjenige, der die Noten vergibt? Das fände ich seltsam. Wenn ich Lehrer wäre, würde ich versuchen, eine Balance zwischen schweren/umfangreichen Inhalten und strenger Benotung zu finden, aber nicht beides lasch oder beides strikt.
Zumindest drücke ich dir die Daumen.
Verfasst: 27.03.2007 18:55
von DarkDragon
Erstmal danke für die Tipps.
>> Ist denn der Lehrer mit dem erstaunten Prof.-Bekannten auch derjenige, der die Noten vergibt? Das fände ich seltsam.
Ja, ist er. Und ich finde es auch seltsam.
>> Zumindest drücke ich dir die Daumen.
Danke

.
[EDIT]
So, Arbeit ist geschrieben, jetzt warte ich nurnoch ein paar Wochen auf die Ergebnisse. Ich meld mich dann wieder wenn ich die Ergebnisse weiß.