Stefan Zörner
30.06.2014
Teil 8 der Blog-Serie. Wir grenzen Entscheidungen von Gegebenheiten ab.
Bei Softwarearchitektur geht es darum, fundamentale Entscheidungen zu treffen. Pflöcke zu setzen, die sich im weiteren Verlauf nur schwer verschieben lassen und die mithin entscheidend für den Erfolg Ihrer Softwarelösung sind. Es geht darum, aus Alternativen für eine wichtige Fragestellung die passende Option auszuwählen. Randbedingungen schränken die Menge gültiger Alternativen ein.
Und um Randbedingungen (oder auch Rahmenbedingungen) geht es in dieser Folge der Starschnitt-Serie. Nun heißt es also wieder: Schere raus und losgeschnippelt …
Während viele Leute ihr Smartphone heute als elektrisches Schweizer Armeemesser für alles einsetzen, bin ich noch altmodisch und bevorzuge Single-Function Devices. Konkret heißt das bei mir, etwa eine eigene Kamera für Photos, einen extra E-Reader, ein spezielles GPS für Geocaching (der Genauigkeit wegen), wiederum anderes GPS für Läufe (Pace-Anzeige und Herzfrequenz) usw. …
Bei Kontrollen im Flughafen ist das Sicherheitspersonal regelmäßig verblüfft, wieviele unterschiedliche USB-Kabel man so mitschleppen kann. Ich habe sogar noch eine richtige Quartz-Armbanduhr (echt, Schweizer Modell).
Und selbstredend verwende ich einen separaten MP3-Player für Musik, vor allem des geringen Gewichts wegen (beim Laufen, s.o.) und der unschlagbaren Akkulaufzeit des Gerätes.
Zu diesem MP3-Player gibt es auch eine nette Software zum Verwalten von Inhalten (Musik, Podcasts) und zum Synchronisieren mit PCs. Sie heißt Media Go.
Na ja, für mein Notebook gibt es sie eigentlich nicht. Auf der Web-Seite des Herstellers gibt es im FAQ die passende Frage “Can I use Media Go on a Mac?”. Und eine verblüffende Antwort:
Media Go is designed to run on the Windows operating system.
Der Satz ließ mich aufhorchen. Man hätte ja auch einfach “Nein” schreiben können. Ich vermute, der Hersteller wollte mit dem Satz irgendetwas Positives ausdrücken: “Wir haben es genau dafür entworfen, deswegen ist es dafür auch besonders toll” (oder so ähnlich).
Bei mir hat es im Hinblick auf die Softwarearchitektur von Media Go allerdings die Frage aufgeworfen: wer hat das entschieden und warum? War das überhaupt eine explizite Entscheidung?
Für mich als Außenstehenden ist es unklar: war Windows eine Vorgabe des Produktmanagements von Media Go? Also zum Beispiel: “Muss auf Windows laufen” (andere Sachen wurden in den Anforderungen nicht erwähnt, und dann lief es halt am Ende unter Windows). Oder lag es eher an den Kenntnissen und Erfahrungen der Softwareentwickler? Vielleicht waren sie sehr versiert unter Windows und konnten Zeitplan und Budget damit einhalten, mit anderen oder weiteren Plattformen hingegen nicht … Wir wissen es im konkreten Fall nicht.
Möglicherweise kaschiert der Satz “… designed to run on …” sogar eine Entscheidung, die nur implizit getroffen wurde. Mit dem Ergebnis muss ich als Benutzer nun leben. Und die Entwickler, welche die Software vielleicht später einmal Portieren wollen, wohl auch.
Das kleine Beispiel beleuchtet ein interessantes Problem, das mir beim Nachdokumentieren von Softwarearchitektur gemeinsam mit Projektteams regelmäßig unterkommt: während Randbedingungen sich eigentlich methodisch völlig klar von Architekturentscheidungen abgrenzen lassen, ist im Nachhinein nicht immer zu unterscheiden, ob etwas eine Vorgabe war, oder ein Freiheitsgrad im Lösungsraum.
Randbedingungen fassen all die Dinge zusammen, die im Rahmen des Architekturentwurfs vorgegeben sind und Entscheidungen entsprechend beeinflussen. Eine typische Kategorisierung unterscheidet zwischen technischen und organisatorischen Randbedingungen und gegebenenfalls noch Konventionen.
Mögliche technische Vorgaben in der Softwareentwicklung:
Beispiele für organisatorische Vorgaben:
Gerade organisatorische Einschränkungen beeinflussen Technologieentscheidungen regelmäßig stark. Bei jeder “Make or Buy”-Entscheidung spielen Budget und Zeitplan eine Rolle. Die Skills der Mitarbeiter sind ein starkes Argument bei der Auswahl von Tools und Frameworks.
Und für das Zusammenspiel von Teamorganisation und Softwarestruktur gibt es sogar ein prominentes Gesetz: Conway’s Law:
Organisationen, die Systeme modellieren, […] sind auf Modelle festgelegt, welche die Kommunikationsstrukturen dieser Organisationen abbilden. – Melvin E. Conway (1968)
In der Praxis spiegelt sich das dann in an der Schichtenarchitektur ausgerichteten Teams wider (GUI-Team, Persistenz-Team, …), oder alternativ dazu vertikal in Featureteams.
Randbedingungen zu kennen ist für den Entwurf einer Softwarearchitektur entscheidend. Bei einer konkreten Fragestellung gibt es Alternativen, Randbedingungen schließen manche aus. Wenn Sie fälschlicherweise eine davon wählen, ist Ihre Lösung unzulässig und wenn Sie das zu spät merken, kann es teuer werden. Im Extremfall scheitert das Projekt (vgl. Definition Softwarearchitektur von Eoin Woods).
Einer Softwarelösung selbst sehen Sie am Ende lediglich an, dass eine bestimmte Technologie eingesetzt wird. Nicht, ob es eine Vorgabe war oder eine Entscheidung des Teams. Und im Falle einer Entscheidung nicht, ob Alternativen in Betracht gezogen wurden.
Für die Nachvollziehbarkeit der Softwarearchitektur ist es daher sehr wichtig, Randbedingungen explizit festzuhalten. Sonst stellt sich später die Frage an die Entwickler: musstest Ihr das so machen oder habt Ihr das selbst entschieden? Wie im Fall von Windows als Zielplattform im Beispiel Media Go.
Doch nun zu unserem Serienstar Gradle. Auch in diesem Fall war es für mich gar nicht so einfach, technische Randbedingungen und Technolgieentscheidungen auseinander zu halten. Open Source Projekte haben oft größeren Einfluss auf Randbedingungen als Umsetzungsteams in Kundenprojekten. Der folgende Schnipsel ist als Beispiel zu sehen.
Technische Randbedingungen
| Thema | Erläuterung |
| Betriebssysteme | Gradle unterstützt (mindestens) Windows, Linux und MacOS |
| JVM | Gradle läuft unter Java JDK, Version 1.5 ("Java 5"), oder höher |
| VCS | Gradle unterstützt die verbreitetsten Versionskontrollsysteme am Markt (freie und kommerzielle) |
| Betriebsmodi | Gradle kann aus den wichtigsten IDEs, von Buildservern und von der Kommandozeile aus gestartet werden |
| Build | Gradle baut sich selbst |
Organisatorische Randbedingungen
| Thema | Erläuterung |
| Lizenz | Gradle ist Open Source und steht unter der Apache License 2.0 (ALv2) |
| Fremdbibliotheken | Es können nur solche Bibliotheken verwendet und mit ausgeliefert werden, deren Lizenz zur ALv2 kompatibel ist |
| Gradleware | Die Firma Gradleware steht hinter Gradle. Ihre Mitarbeiter prägen, wenn auch im engen Kontakt und auf Augenhöhe mit der übrigen Community, schlussendlich die strategische Ausrichtung und Weiterentwicklung von Gradle |
Konventionen
| Thema | Erläuterung |
| Source code | Quelltextverwaltung bei GitHub, https://github.com/gradle |
| Defect Tracking | mit JIRA unter http://issues.gradle.org |
| Community | Interaktion mit Nutzern unter https://discuss.gradle.org |
Beispielsweise beeinflussen die Java Version (Gradle muss auch noch unter Java 5 laufen) und die Lizenz die Auswahl von Fremdbibliotheken, die bei Gradle zum Einsatz kommen können.
Die Programmiersprache muss JVM-basiert sein, im Lösungsraum wäre aber neben Java selbst (was zur Entwicklung von Gradle verwendet wird) auch Groovy gewesen.
Randbedingungen haben in arc42 einen festen Platz: Sie landen im gleichnamigen zweiten Abschnitt der arc42-Gliederung, der ebenso strukturiert ist, wie oben beschrieben (technisch, organisatorisch, Konventionen) und auch wie im Gradle-Beispiel oben gezeigt.
Der entsprechende Abschnitt in arc42 enthält eine Liste an Beispielthemen für Randbedingungen, die Sie beim Erarbeiten der Randbedingungen für Ihr eigenes Projekt hinzuziehen können.
Randbedingungen sind im Projektverlauf typischerweise fest, können sich mit der Zeit aber ändern.
Gradle 2.0 fordert beispielsweise Java 6. Java 5 wird nicht mehr als Laufzeitumgebung unterstützt (Forenbeitrag dazu). In vielen deutschen Versicherungen war der Einsatz von Open Source in Java Projekten zur Jahrtausendwende noch grundsätzlich unzulässig. Heute ist er in geregelten Bahnen (Randbedingungen) auch dort gang und gäbe.
Diese Veränderungen sind ein weiteres Argument dafür, Randbedingungen im Rahmen der Architekturdokumentation festzuhalten. Entscheidungen sind ohne diese zentralen Einflussfaktoren später kaum nachvollziehbar.
Wenn Randbedingungen auch bei der Weiterentwicklung der Softwarearchitektur beachtet werden sollen (oft ist das der Fall, damit die Architektur nicht verwässert), formulieren Sie diese so, dass sie möglichst unempfindlich gegenüber der Zeit sind.
Im Beispiel Gradle habe ich das etwa mit “unterstützt die verbreitetsten Versionskontrollsysteme (VCS) am Markt” anklingen lassen. Wenn später ein neuer Stern am VCS-Himmel erstrahlt, muss die Architektur eine Antwort darauf haben, wie man ihn schnell unterstützt. Falls in Gradle nur bestimmte VCS hart verdrahtet wären und kein Konzept zur Erweiterung vorläge, wäre das ein Risiko, das eine Architekturbewertung, welche die Randbedingungen mit abklopft, aufdecken würde …
Den achten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben, können Sie hier herunterladen. ;-)
In der nächsten Folge geht es übrigens um übergreifende Konzepte. Vereinfacht gesagt ist das der Joker-Abschnitt in arc42. Warum das so ist, kläre dann auf. Es bleibt also spannend …
Dieser Beitrag ist ursprünglich als Teil einer Blog-Serie beim Hanser-Verlag (“Hanser Update”) erschienen. Die Inhalte, ergänzt um reichhaltiges Bonus-Material, sind mittlerweile auch als E-Book bei Leanpub verfügbar.