Hallo Anja,
du liegst voll richtig.
Wenn Du Das Problem z.B. mit dem Wasserfallmodell angehst, hast du als erstes die Spezifikationsphase mit Pflichten und Lastenheft. D.h. eine textuelle zusammenstellung der Anforderungen. Das ist naturgemäß unvollständig, fehlerhaft und widersprüchlich.
Das Pflichtenheft sollte/könnte in der Fallstudie gegeben sein.
Als nächstes kommt die Analysephase, die nochmals in Analyse und Design geteilt ist. In der Analyse (Ihr macht Objektorientierte Analyse OOA) entwerft ihr aus der Spezifikation das Fachkonzept. Also die fachlichen Anforderungen. Die Analyse spielt sich in einer idealen Welt ab, ohne dass technische Unzulänglichkeiten beachtet würden. (Speicher, Performance, Speicherung, Anzeige, Netzwerkstabilität…)
Die Diagramme sind auf einem hohen Abstraktionsgrad.
ABER: bereits hier solltet ihr zwischen überwiegend dynamischen Anwendungen (Einfaches Klassendiagramm, viele oder komplexe Geschäftsprozesse) und überwiegend statischen Anwendungen (z.B. Verwaltungssysteme) unterscheiden. Einmal beginnt man besser mit den GP, das andere mal mit dem Klassendiagramm.
Oft wird die Analyse einfacher, wenn man frühzeitig den Prototyp der Oberfläche entwirft und die Aktivitäten gleich mit hin malt. Dann wird die Benutzerführung besser.
Nach der Analyse beginnt man mit dem Design (OOD). Hier werden die Oberflächenklassen beachtet und die Speicherung der Daten. Plötzlich ist nicht mehr alles sofort verfügbar, sondern muss mühsam aus der DB geholt werden. Die Objekte werden nach dem Ende des Geschäftsprozesses gespeichert und wieder aus dem Speicher gelöscht. Hier solltet Ihr verstärkt Sequenzdiagramme einsetzen. Erst was im Sequenzdiagramm richtig läuft, kann auch programmiert werden. Umgekehrt geht es auch: ein Sequenzdiagramm ist die grafische Darstellung eines Debug-Laufs. Kann man in Eclipse, das verwendet ihr wahrscheinlich, sehr schön machen.
Gruß von der BA-Mannheim
Peter
[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]
