P [3,4]: Review

Der furchtlose Kollege Klaffenböck aus Team 2 hat hier [1] und hier [2] Entwürfe seines Komponentendiagramms vorgestellt.

Was mich dabei am Entwurf [1] stört:

• "Userprofil anzeigen / erstellen / bearbeiten" sind Anwendungsfälle, (imho) keine Komponenten
• Ebenso die anderen Layer 1 - "Komponenten"

Ad [2]:

• Folie 2: Bearbeiten und Kommentieren sind Anwendungsfälle, mit dem Rest kann ich leben wenn ich es mir richtig interpretiere

Das zieht sich eigentlich durch die meisten Diagramme, und auch der folgende Blogeintrag vermittelt mir irgendwie das Gefühl, dass aus etwas das sinnvollerweise ein Klassendiagramm bzw. Usecase-Diagramm sein sollte, krampfhaft in "Komponenten" gezwängt wird, siehe auch:

(...) darauf praktisch die Inhalte unseres letzten UML-Diagramms abbilden, also "was kann ich mit dem System alles machen?", denn das beschreibt ja meiner Meinung nach die logischen Funktionen

Bei Architektur und Komponenten denke ich da viel mehr ans ganz Grobe, bzw. an die Struktur des Projekts im Filesystem (bzw. das logische Mapping dann dazu, die Java Packages).

Sinnvolle Komponenten könnten dann meiner Meinung nach sein: Java Packages, Verzeichnisse, Bibliotheken (zb Hibernate/PDO/JDBC für den DB-Zugriff --> Komponente Datenbankanbindung), ...

Genau aus diesem Grund ist unser Entwurf auch sehr generisch (er könnte eigentlich für jedes beliebige Projekt genommen werden) und beinhaltet auch keine explizit erwähnten Klassen (wie zB "Prüfung", "Lehrveranstaltung", "Hörsaal", "Prüfungsanmeldung", "Prüfungsergebnis") - all diese Klassen würden meiner Meinung nach dann in ein Klassendiagramm kommen, dass deren Attribute und Beziehungen abbildet - fürs Komponentendiagramm sollte ihr gemeinsamer "Übervater" Entity bzw. Model als Paket bzw. Komponente bestens passen.

Hm ja... Schlafenszeit :p