Komponentenorientierung – CCD vs. UML

Komponentenorientierte Architekturen sind ja nichts Neues. Die Ge-sellschaft für Informatik (GI e.V.) selbst schreibt in ihrem Informatik-lexikon über Software-Architektur:

Definition (Software-Architektur)

Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.

Komponenten gehören also in die Standardwerkzeugkiste eines guten Architekten und Designers. Wie aber diese Komponenten darstellen? Ich habe den recht pragmatischen An-satz von Ralf Westphal und Stefan Lieser aus dem Clean Code Developer Camp mit der UML 2 ver-glichen und an praktischen Beispielen ausprobiert.

EInfach vs. standardisiert

Eine Notation sollte vor allem klar verständlich und eindeutig sein. Und einfach zu zeichnen vor allem bei schnellen Architekturzeichnungen am Whiteboard oder auf dem Skizzenblatt. Und genau da liegt sicherlich der Vorteil eines einfachen Ansatzes. Hier kann man schnell grobe Designs entwerfen, weglöschen verschieben usw. Wichtig ist aber, dass die Strukturen klar definiert werden. Stefan und Ralf verwenden hierbei zum Beispiel Kreise für Funktionseinheiten und einfache Pfeile für Abhängigkeiten, sowie doppelte Pfeile für Datenflüsse. Wie aber würde dies in UML aussehen? Es gibt Komponentendiagramme. Diese sind aber sehr überfrachtet mit Informationen, die ich vor allem im ersten Ansatz nicht benötige. Der Überblick auf die wichtigen Dinge geht verloren. Was aber tun, wenn der Kunde nun mal UML versteht? Warum ihm dann eine neue Notation verkaufen?

Toolunterstützung

Bei dem einfachen Ansatz gibt es bisher keine oder nur rudimentäre Unterstützung beim Entwerfen. Hier muss man auf Werkzeuge wie zum Beispiel Visio oder das Online-Tool TODO verwenden. Diese Werkzeuge haben aber den Nachteil, dass man schlecht in die Designs “hineinzoomen” kann. Aber dies ist für den schnellen Ansatz auf dem Whiteboard ja auch gar nicht nötig. Es soll einfach, schnell und nicht überfrachtet sein. Für die späteren Architekturbilder kann man dann ja immer noch auf UML zurückgreifen und zum Beispiel mit dem Enterprise Architect die Designs entwerfen. Dann bekommt man alle Vorteile der Werkzeugunterstützung.

Fazit

Ich verwende bei meinen ersten Entwürfen auf dem Skizzenblock oder Whiteboard eine einfache aber klar definierte Notation und für weitergehende Architekturdokumentation, die auch für den Kunden gedacht ist die UML 2 und die passenden Werkzeuge. Was ist eure Meinung dazu? Wie findet Ihr eine einfache Notation im Vergleich zur UML oder anderen? Über Kommentare würde ich mich freuen.

Komponentenorientierte Architekturen sind ja nichts Neues. Die Ge-sellschaft für Informatik (GI e.V.) selbst schreibt in ihrem Informatik-lexikon über Software-Architektur:

Definition (Software-Architektur)

Die grundlegende Organisation eines Systems, dargestellt durch dessen Komponenten, deren Beziehungen zueinander und zur Umgebung sowie den Prinzipien, die den Entwurf und die Evolution des Systems bestimmen.

Komponenten gehören also in die Standardwerkzeugkiste eines guten Architekten und Designers. Wie aber diese Komponenten darstellen? Ich habe den recht pragmatischen An-satz von Ralf Westphal und Stefan Lieser aus dem Clean Code Developer Camp mit der UML 2 ver-glichen und an praktischen Beispielen ausprobiert.

EInfach vs. standardisiert

Eine Notation sollte vor allem klar verständlich und eindeutig sein. Und einfach zu zeichnen vor allem bei schnellen Architekturzeichnungen am Whiteboard oder auf dem Skizzenblatt. Und genau da liegt sicherlich der Vorteil eines einfachen Ansatzes. Hier kann man schnell grobe Designs entwerfen, weglöschen verschieben usw. Wichtig ist aber, dass die Strukturen klar definiert werden. Stefan und Ralf verwenden hierbei zum Beispiel Kreise für Funktionseinheiten und einfache Pfeile für Abhängigkeiten, sowie doppelte Pfeile für Datenflüsse. Wie aber würde dies in UML aussehen? Es gibt Komponentendiagramme. Diese sind aber sehr überfrachtet mit Informationen, die ich vor allem im ersten Ansatz nicht benötige. Der Überblick auf die wichtigen Dinge geht verloren. Was aber tun, wenn der Kunde nun mal UML versteht? Warum ihm dann eine neue Notation verkaufen?

Toolunterstützung

Bei dem einfachen Ansatz gibt es bisher keine oder nur rudimentäre Unterstützung beim Entwerfen. Hier muss man auf Werkzeuge wie zum Beispiel Visio oder das Online-Tool TODO verwenden. Diese Werkzeuge haben aber den Nachteil, dass man schlecht in die Designs “hineinzoomen” kann. Aber dies ist für den schnellen Ansatz auf dem Whiteboard ja auch gar nicht nötig. Es soll einfach, schnell und nicht überfrachtet sein. Für die späteren Architekturbilder kann man dann ja immer noch auf UML zurückgreifen und zum Beispiel mit dem Enterprise Architect die Designs entwerfen. Dann bekommt man alle Vorteile der Werkzeugunterstützung.

Fazit

Ich verwende bei meinen ersten Entwürfen auf dem Skizzenblock oder Whiteboard eine einfache aber klar definierte Notation und für weitergehende Architekturdokumentation, die auch für den Kunden gedacht ist die UML 2 und die passenden Werkzeuge. Was ist eure Meinung dazu? Wie findet Ihr eine einfache Notation im Vergleich zur UML oder anderen? Über Kommentare würde ich mich freuen.

Komponentenorientierung – CCD vs. UML