Die logische und die physische Swolarchie beschreiben Software noch nicht als System. Sie definieren lediglich die Bestandteile aus zwei unterschiedlichen Blickwinkeln. Sie beschreiben, welche Bestandteile aus welchen anderen bestehen. Durch Aufspannen einer Modulhierarchie können Sie sich schrittweise der Problemlösung nähern. Sie verfeinern sie durch neue Hierarchieebenen, wo sie sie für noch zu kompliziert/undurchsichtig halten. Dabei geht es aber nur um grundsätzliche Verantwortlichkeiten im Sinne der Produktion von Anwendernutzen und noch nicht darum, wie der am Ende konkret entsteht. Für ein gegebenes Modul ist die Leitfrage: "Aus welchen Rollen/Submodulen könnte dieses Modul bestehen, die zusammen seine Leistung erbringen?"
Die Modularisierung einer Software dient nur der Ermittlung derjenigen Rollen, die zur Lösung des Gesamtproblems "irgendwie" nötig sind. Ziel ist eine Menge von Modulen, die als Komponenten implementiert werden können.
Click image to enlarge
Am Ende der Modularisierung wissen Sie also, was grundsätzlich zu tun ist. Es ist dann klar, welche Bauteile herzustellen sind, aus denen die Software dann zusammengesetzt werden kann. Wie das dann geschieht, beschreibt die physische Swolarchie. Die Modulhierarchie ist sozusagen der Herstellungsplan, die physische Swolarchie der Bauplan für Software.
Modellierung ist kein Selbstzweck. Sie dient vielmehr der Beantwortung von Fragen:
- Wer tut am Ende was?
- Wo tut wer etwas?
- Wie tut wer etwas?
Warum und Wofür sind der Ausgangspunkt und durch die Anforderungen an die zu entwickelnde Softwarelösung gegeben.
Die Modulhierarchie ist die Antwort auf die erste Frage. Ihr Ergebnis ist eine Liste von Rollen oder Verantwortlichen, den Hybriden, die am Ende die "Fabrik Software" konstituieren. Die Modularisierung ermittelt diese Verantwortlichen aber nur, setzt sie quasi nur ungeordnet in einen Raum. Das kann auf jeder Ebene des Herstellungsplans geschehen (s. die Schnitte im obigen Bild).
Der Bauplan beantwortet die zweite Frage. Er legt fest, wo die Hybriden im späteren Softwaresystem zum Einsatz kommen, zu welchen Superkomponenten oder Prozessen sie zusammengesetzt werden müssen, um ein im Sinne der Anforderungen funktionsfähiges Ganzes zu ergeben.
Und wer beantwortet die dritte Frage? Es ist ein weiterer Plan nötig, der Kooperationsplan. Ein Kooperationplan beschreibt für einen Schnitt durch eine Ebene von logischer oder physischer Swolarchie die Verbindungen zwischen den Swolons. Er definiert, wie die Swolons miteinander kooperieren/kommunizieren, um zusammen Anwendernutzen hertzstellen.
Click image to enlarge
Die Beziehungen zwischen Swolons in einem Schnitt müssen dabei natürlich grundsätzlich denen in anderen entsprechen, die denselben Systemausschnitt beschreiben. Bei den Kooperationsplänen für Schnitt 1 und Schnitt 2 im vorstehenden Bild ist das der Fall. Die gestrichelten Pfeile zeigen das Mapping von logischen Swolons auf physische inkl. ihrer Verbindungen. Die Modellierung muss hier also ein Auge auf die Konsistenz der unterschiedlichen Pläne haben.
In UML werden Kooperationspläne als Kollaborationsdiagramme dargestellt. Ich möchte mich in dieser Serie jedoch nicht zu sehr an UML binden, um den allgemeinen Begriff der Swolons nicht mit Bedeutungen aufzuladen, die ihm angesichts seiner Jugend schaden könnten. UML wurde vor allem aus C++ und Java geboren und hat seine Wurzeln bei allem Willen zur Allgemeingültigkeit also in der Objektorientierung. Mein Ziel ist jedoch, über die Objektorientierung hinaus zu gehen, sozusagen auf sie zu steigen, um auf ein höheres Level bei der Softwareentwicklung zu kommen. Komplexe Software zu beschreiben darf nicht (zu früh) von Konzepten der Objektorientierung behindert werden.
Paket-, Komponenten-, Klassen- und Kollaborationsdiagramme haben alle ihren Wert. Wenn Sie sie zur Darstellungen von Swolarchien benutzen wollen, dann tun Sie das gern. "Software als System" steht dem nicht im Wege. Ob die Diagramme dann allerdings so hübsch aussehen, wie die Grafiken in dieser Postingreihe... das weiß ich nicht ;-)
Keine Kommentare:
Kommentar veröffentlichen