Montag, 17. November 2008

P3: Architektur

Haben heute Nachmittag in einer Marathonsitzung versucht, dieses Komponentenmodell auf die Reihe zu bringen. Leider stellte es sich heraus, dass wir trotz all der geforderten Aufgaben, die bisher abzugeben waren, noch nicht einmal selbst alle Komponenten/Aspekte unseres Projektes kennen.

Ständig kehrten wir zum Anfang zurück um alles vom Beginn an neu aufzurollen. Startend bei der Anmeldemaske haben wir überlegt, was der angemeldete User von dort aus machen kann. Dabei ertappten wir uns ständig, dass wir aus dem statischen Komponentendiagramm ausbrechen und in das dynamische Aktivitätsdiagramm eindringen wollten.

So hatte zumindest ich während der Erstellung des (bisherigen) Diagramms das Gefühl, dass wir wesentliche Schritte der Objektmodellierung ausgelassen hätten. Zum anderen muss man aber auch dazu sagen, dass wir womöglich unter den Folgen eines schlecht modellierten Use-Case-Diagramms leiden, welches wir für diesen Arbeitsschritt nicht wirklich zu Hilfe nehmen konnten.
Folglich lautet hier die einzig richtige Lösung, dass wir zum Use-Case-Diagramm zurückkehren und dieses noch einmal überarbeiten sollten. Aber natürlich fehlt dazu wieder einmal die Zeit (schließlich ist ja morgen Abgabetermin).

Obwohl wir im Grunde rechtzeitig mit der Aufgabe angefangen hatten (Donnerstag vor einer Woche) erleben wir nun doch dieselben Probleme, als wenn wir auf den letzten Drücker angefangen hätten.

Unser bisheriges Workingdraft ist über Theresas Blog zu bewundern, doch dieses wurde bereits wieder wesentlich abgeändert. Über das neue Diagramm werde ich dann hoffentlich bald berichten können.

1 Kommentar:

Michael Derntl hat gesagt…

Zu dem, dass Sie "aus dem statischen Komponentendiagramm ausbrechen und in das dynamische Aktivitätsdiagramm eindringen wollten": Das ist auch im Komponentendiagramm ersichtlich. Einige der Komponenten entsprechen Tätigkeiten. Es sollte eher so sein, dass die Komponenten "Behältnisse" für Klassen/Seiten/Code sind, der diese Tätigkeiten unterstützt. Sie könnten z.B. Ihre Komponenten "Protokoll Eingabemaske", "Anzeige eines Protokolls" und "Erstellen einer neuen Version eines Protokolls" in eine einzige Komponente zusammenfassen.

Auch auf der unteren Ebene: "Datenbankzugriff:Protokolle" bietet 3 Schnittstellen an, für jede DB-operation eine. Die Schnittstellen könnte man in eine einzige Zusammenfassen.

Nehmen Sie das jetzt nicht zu wörtlich, aber für Orientierung: Stellen Sie sich vor, Sie müssten die Klassen, Seiten und Skripts die Sie für die Webseite implementieren in ein Verzeichnissystem bringen, wobei zusammengehörige Elemente in ein gemeinsames Verzeichnis kommen, z.b. alle Eingabemasken in /ui/forms. Anhand dessen könnten Sie vielleicht einfacher die Komponenten identifizieren. UI = Benutzerschnittstelle Subsystem (Schicht), Forms: Komponente in diesem Subsystem. Die Forms Komponente wird wohl aus der Logikschicht Komponenten verwenden (/logik/protokollmanager), die auf die DB Schicht zugreifen (/db/protkolle) usw ...

Es müssen gar nicht so viele Komponenten wie in Ihrem System sein.