artikulieren Designentscheidungen, die die primären Verhaltens- und Struktureigenschaften eines Programms (Softwaresystems) bestimmen. Strategische Entscheidungen betreffen globale, systemweite Belange und haben die folgenreichsten Implikationen. Zu den strategischen Entscheidungen gehören die Wahl des Programmierparadigmas („objektorientierte Programmierung“), des Architekturstils („Pipes und Filter“), des Anwendungsrahmens („Microsoft Foundation Classes“), der komponentenbasierten Softwareentwicklungsstandards („Enterprise JavaBeans“) und der Entwurfsprinzipien („universelle Basisklasse“) sowie Annahmen, die zu einer architektonischen Fehlanpassung führen können („Der Softbench Broadcast Message Server erwartet, dass alle Komponenten eine grafische Benutzeroberfläche haben“) und gesetzeskonforme Regelmäßigkeiten („jede Klasse im System erbt von Klasse C“). Aufgrund der Konsequenzen, die sie mit sich bringen, müssen strategische Entscheidungen früh im Softwareentwicklungsprozess getroffen werden und sollten explizit festgelegt werden, bevor ein detaillierter Entwurf durchgeführt wird.
Im Gegensatz dazu artikulieren taktische Entwurfsanweisungen Entwurfsentscheidungen, die ein bestimmtes Modul betreffen. Taktische Entscheidungen beschreiben oft ein Muster von Korrelationen zwischen einer Sammlung von Modulen (Objekten, Prozeduren, Klassen usw.) und einer anderen. Intuitiv gesprochen sind taktische Anweisungen „lokal“ in dem Sinne, dass ihr Geltungsbereich auf einen Teil des Programms beschränkt ist und nicht außerhalb davon liegt. Taktische Entscheidungen umfassen die Wahl von Entwurfsmustern (‚Factory Method‘), Refactorings (‚Replace Conditional With Polymorphism‘) und Programmiersprachen (‚counted pointer‘) und werden in der Regel viel später als strategische Entwurfsentscheidungen im Softwareentwicklungsprozess getroffen.
Auch wenn ich der allgemeinen Regel global = strategisch und lokal = taktisch weitgehend zustimme, sollte sie nicht als absolut betrachtet werden. Es ist möglich, dass ein Segment eines Systems Aspekte aufweist, die die Gesamtarchitektur stark beeinflussen (was die Booch’schen Kriterien für die Bedeutung rechtfertigt). Aus diesem Grund vertrete ich nicht die Meinung, dass funktionale Anforderungen Design und nicht-funktionale Architektur sind.
Arnon Rotem-Gal-Oz, Architekturmanager bei Nice Systems, identifiziert in seinem Vortrag „Software Architecture“ mehrere Aspekte der Architektur. Die Architektur umfasst die Hauptkomponenten eines Systems, ihre Beziehungen und Interaktionen. Daten und Verhalten dieser Hauptkomponenten sind für die Architektur nur unter dem Gesichtspunkt der Interaktionen zwischen diesen Komponenten relevant. Wie Booch bezeichnet auch Rotem-Gal-Oz die Architektur als die am schwierigsten zu ändernden Teile des Systems. Wie Eden, Kazman und Hirshfeld definiert er die Architektur als die Designentscheidungen, die am frühesten im Prozess getroffen werden müssen.
Der Wert strategischer, grundlegender Designentscheidungen sollte offensichtlich sein. Da diese Aspekte des Systems sowohl schwierig als auch kostspielig zu ändern sind, sollte es einen erheblichen Anreiz geben, optimale Entscheidungen zu treffen. Wie Kevlin Henney in „What is Software Architecture?“ auf developerFusion schreibt:
Die Frage ist nicht, ob ein System eine Architektur hat oder nicht, sondern ob seine Architektur gut ist oder nicht. Alle Systeme haben eine Architektur, ob gewollt oder ungewollt, explizit oder implizit, gut oder schlecht – sogar „keine Architektur“-Systeme haben eine Architektur!
Indem wir die Architektur mit den Kosten der Veränderung in Verbindung gebracht haben, haben wir eine einfache Möglichkeit, die Qualität der Architektur zu bewerten. Es geht nicht darum, dass eine gute Architektur die Erstellung eines Systems billig macht, sondern darum, dass es auch billig zu entwickeln ist. Mit anderen Worten: Eine gute Architektur ist eine Architektur, bei der die Bedeutung von Designentscheidungen minimiert wird. Es steht Ihnen frei, viele Aspekte eines Systems zu ändern, ohne befürchten zu müssen, dass solche Änderungen schwierig oder kostspielig sind oder eine Kaskade von Fehlern verursachen. Eine gute Architektur ist daher eine nachhaltige Architektur.
Angesichts der kritischen Bedeutung dieser Designentscheidungen macht es wenig Sinn, sie dem Zufall zu überlassen. Eine nachhaltige, flexible Architektur wird sich nicht von selbst entwickeln. Es bedarf einer ausreichenden Planung und Koordinierung durch eine Person, die die Rolle des Architekten innehat (unabhängig davon, ob es sich um eine Vollzeit- oder Teilzeitstelle handelt). Innerhalb dieses Rahmens können dann dezentralisierte Designentscheidungen getroffen werden.
Gelegentlich höre ich Leute, die immer noch das agile Mantra gegen Big Design/Requirements Up Front erheben. Die Sache ist die, dass das Agile Manifest nie gesagt hat, man solle absichtlich den Kopf in den Sand stecken, was den Zweck des Systems angeht. Es war ein Vorstoß gegen die monatelange Analyse, bei der nichts als Dokumente herauskamen, aber das Ziel war, einen Mittelweg zu finden. Niemand hat jemals gesagt „kein Design im Vorfeld“ oder „keine Anforderungen im Vorfeld“.
(Udi Dahan aus „A CQRS Journey – with and without Microsoft“)
Reposted from Form Follows Function