Stefan Zörner
12.05.2014
Die Software soll einfach zu erweitern sein. Leicht zu bedienen und gut skalieren. Was heißen in diesem Zusammenhang einfach, leicht und gut? Zumindest so exemplarisch ...
Und weiter mit Gradle zerlegt nach arc42 … In diesem Schnipsel geht es vereinfacht gesagt um “beispielhafte Qualität”. Ich knüpfe dabei an die Qualitätsziele aus Folge 3 der Starschnitt-Serie an.
Zur Erinnerung: Qualitätsziele motivieren die wichtigsten drei bis fünf geforderten Qualitätsmerkmale für Ihr System (z.B. Performance, Benutzbarkeit, Wartbarkeit, …). Qualitätsszenarien (oder auch Bewertungsszenarien) konkretisieren diese nun. Neben ihrer wichtigen Rolle als Kommunikationsmittel, die auch ihre “Anwesenheit” in arc42 erklärt, helfen Szenarien vor allem Entscheidungen früh abzusichern und Softwarearchitektur im Nachhinein zu bewerten. Also insgesamt eine ziemlich feine Sache.
Und so heißt es wieder: Schere raus und losgeschnippelt …
Trends wie Virtualisierung und Cloud-Computing entfernen viele Entwickler immer weiter von der Zielumgebung ihrer Anwendungen. Vielleicht auch um dieser Entfremdung ein wenig entgegen zu wirken entdecken immer mehr Programmierer Kleincomputer wie den Raspberry Pi als Freizeitbeschäftigung. Es ist ein erfrischendes Gefühl, Hard- und Software wieder zusammen wirken zu sehen. Und selber Dinge zu bauen, die direkt mit ihrer Umfeld interagieren.
Die Do-It-Yourself-Bewegung der Gegenwart ist kreativ und unglaublich vielseitig. Gebastelt, geschraubt, programmiert und gelötet wird mittlerweile eigentlich nahezu alles. Das reicht von selbstgemachten Visitenkarten über 3D-Drucker bis zur Kreissägeblattschleuder. – Hagen Fisbeck in “Die Makerbewegung und ihre Auswirkungen auf den Handel” (regital.de)
Ein prominenter Protagonist dieser Bewegung ist der Arduino. In ihm verrichtet ein Atmel AVR-Microprozessor als Herz und Hirn seinen Dienst, der ATmega328 (8 bit). Mit dem Arduino-Board lassen sich recht komfortabel Microcontroller-basierte Sachen machen, die messen, steuern, regeln.
Elliot Williams führt in seinem schönen Buch “Make: AVR Programming – Learning to Write Software for Hardware” (Cover-Abbildung rechts) aus, welche Nachteile er beim Einsatz von Arduino sieht, wenn man sich mit der AVR-Programmierung beschäftigt. Bestimmte Entscheidungen bei der Konzeption von Arduino schränken den “Maker” seiner Meinung nach stark ein, oder behindern ihn zumindest.
Als konkretes (und zugleich leicht verständliches) Beispiel kann die Umbenennung der Pins von Atmel-Datenblatt zu Arduino dienen. Bei AVR-Prozessoren sind die Pins in Bänken organisiert, die mit B, C, D … usw. (Anzahl je nach Typ) bezeichnet sind. Die Pins von Bank B heißen dann PB0, PB1, PB2, …, PB7, Bank C dann PC0, PC1, …
Beim Arduino sind diese Pins allerdings umbenannt worden, um durchgängige Nummern zu realisieren. Einsteigern wird dadurch die Benutzung erleichtert. Die Pins heißen z.B. Digital Pin 0 (kurz D0), Digital Pin 1 (D1) usw. was dazu führt, dass aus dem Original-Pin PB5 dann Digital Pin 13 wird. Siehe folgende Abbildung (nach Quelle).
Die Namen der Pins kommen bei Arduino-Programmen direkt im Quelltext zum Einsatz, wie das “Hello World”-Pendant Blink zeigt. Die Pinnummern gehören also quasi zur API dazu – sie sind für den Benutzer spürbar.
Wer nun mit dem Original-Datenblatt von Atmel zum Prozessor arbeiten möchte, und ein Arduino-Projekt realisiert, muss die Pin-Namen jedes mal übersetzen. Vorhandenes Wissen, das ein Benutzer ggf. aus früheren Experimenten von der AVR-Pinbelegung mitbringt, kann er nicht direkt anwenden. Und wenn er irgendwann von Arduino hin zum “direkten” Arbeiten mit AVR-Prozessoren wechseln möchte, müsste er ebenfalls umdenken. Schade, findet Elliot Williams.
Aber wie schlimm ist das nun eigentlich? Schlussendlich ist Arduino ja dazu da, Hobbyisten den Einstieg in die AVR-Welt zu eröffnen. Sind durchnummerierte Pins nicht praktisch? Andererseits lassen sich Arduino-Quelltexte und Beispiele, etwas aus Tutorials, nicht so ohne weiteres in die direkte AVR-Programmierung übernehmen. Hier ist abzuwägen zwischen leichter Erlernbarkeit auf der einen und Portierbarkeit auf der anderen Seite …
Anforderungen a la “Benutzbarkeit ist superwichtig und Portierbarkeit ist ggf. auch interessant” sind in der Praxis nicht konkret genug, um Entscheidungen zu treffen oder zu bewerten. Qualitätsszenarien gehen daher einen Schritt weiter. Sie sind beispielhafte Verwendungen des Systems, in denen ein Qualitätsmerkmal die Hauptrolle spielt. In ihnen wird Qualität lebendig inszeniert.
Für die Arduino-Plattform und die Problemstellung von oben könnten zwei Qualitätsszenarien zum Beispiel so aussehen:
Ganz generell können solche Szenarien diejenigen, die Anforderungen haben, und diejenigen, die sie umsetzen sollen, früh miteinander ins Gespräch bringen. Plötzlich lassen sich Anforderungen bzgl. Qualität (hier im Beispiel: Benutzbarkeit und Portierbarkeit) greifen und priorisieren, und Risiken bewerten. Ist etwas schwierig umzusetzen? Widersprechen sich Anforderungen vielleicht sogar? Auf dieser Basis lassen sich Entscheidungen sicherer treffen.
Und im Nachhinein erarbeitet (wie in unserem Beispiel zu Arduino geschehen) können Szenarien auch dabei helfen Entscheidungen zu bewerten oder abzusichern. Tatsächlich sind Qualitätsszenarien eigentlich ein Werkzeug aus der qualitativen Architekturbewertung, was auch das gebräuchliche Synonym Bewertungsszenarien erklärt.
In der Praxis haben Qualitätsszenarien einen stets gleichen Aufbau, dargestellt in der folgenden Abbildung (nach Len Bass et al.). Die einzelnen Bestandteile (Quelle, Auslöser, Artefakt, …) helfen Ihnen dabei, Szenarien methodisch herzuleiten. Es ist allerdings nicht erforderlich, dass Ihre Szenarien stets alle Teile aufweisen. Gleichwohl bewahrt das Schema Sie vor Allgemeinplätzen. Eine Quelle und/oder einen Auslöser sollte jedes Ihrer Szenarien haben. “Das System darf niemals ausfallen” hätte beispielsweise nichts von beidem.
Im Beispiel ist der in Elektronik Unkundige die Quelle, sein Wunsch ein Ampel-Projekt umzusetzen der Auslöser, das es blinkt die Antwort, die eine Stunde das Antwort-Maß usw.
Mit diesen zwei Szenarien und weiteren Beispielen könnten wir nun eine Diskussion beginnen, und bewerten ob die Entscheidungen des Arduino-Teams (die Namen der Pinbelegung waren dabei nur ein kleines Beispiel) zu den Anforderungen passen. Im Hinterkopf sollten wir dabei das Mission Statement von Arduino und die damit verbundenen Qualitätsziele behalten.
Arduino is an Open-Source electronics prototyping platform based on flexible, easy-to-use hardware and software. It’s intended for artists, designers, hobbyists and anyone interested in creating interactive objects or environments. – von der Arduino-Webseite)
Dieses Mission Statement würde sich übrigens auch gut auf einem Produktkarton (Thema der ersten Folge dieser Blog-Serie) für Arduino machen.
Statt diese Diskussion zu führen verlassen wir den Arduino nun aber zugunsten unseres eigentlichen Serien-Stars. Im Folgenden also Qualitätsszenarien zu Gradle!
Die folgende Liste enthält konkrete Szenarien, welche die zentralen Qualitätsziele von Gradle (siehe Folge 3), aber auch andere geforderte Qualitätsmerkmale illustrieren sollen.
Die folgende Abbildung ordnet diese Szenarien Qualitätsmerkmalen zu.
Das könnte man nun diskutieren. Geschrieben hatte ich die Qualitätsszenarien eigentlich “nur” als Beispiele für diesen Blog. Inhaltlich plausibel sollten sie natürlich trotzdem sein, und so habe ich mich mit Rene Gröschke (Gradle Inc.) ein wenig zu den Szenarien ausgetauscht und teilweise auch noch einmal nachgeschliffen. Unterm Strich sind sie nun sinnvoll, Gradle erreicht sie in der Regel, teilweise werden sie sogar “übererfüllt”. An dieser Stelle vielen Dank für den Austausch, Rene!
Da Qualitätsszenarien die geforderte Qualität illustrieren, sollten Sie diese lebendig formulieren und konkret machen. Verwechseln Sie das Werkzeug nicht mit Akzeptanzkriterien. Gerade früh formuliert müssen Szenarien meiner Erfahrung nach nicht zwingend objektiv messbar sein. Man sollte sich aber schon sinnvoll darüber unterhalten können, wie man beispielsweise die (Nicht-)Erreichbarkeit einschätzt, oder den fachlichen Nutzen. Später können Sie bei Bedarf Akzeptanzkriterien und Tests aus den Szenarien ableiten.
Szenarien sind Beispiele. Natürlich schreiben Sie nicht sämtliche denkbaren Anforderungen bzgl. Qualität darin fest. Das wären offensichtlich viel zu viele. Trotzdem kommt oft die Frage auf, wieviele Qualitätsszenarien in der Praxis zu formulieren sind, und wir mit ihnen weiter verfahren wird.
Für den Fall eines Architekturüberblicks genügen in der Regel ca. ein Dutzend Szenarien, welche die Qualitätsziele und einige weitere wichtige Qualitätsmerkmale illustrieren. Den Nachweis, dass Sie tatsächlich alle Qualitätsziele “erwischt” haben, können Sie mit Hilfe eines Qualitätsbaums (engl. Utility Tree) führen und belegen. So heißt die baumartige Darstellung am Ende des Gradle-Beispiels oben.
Für andere Anwendungszwecke von Szenarien lässt sich die Frage nach der Anzahl nicht pauschal beantworten. Die Beschreibung des Einsatzes von Qualitätsszenarien etwa in der Architekturbewertung, wo das Werkzeug seine Heimat hat, sprengt den Rahmen dieses Blogbeitrages. Vorrangig geht es in dieser Serie ja darum, Softwarearchitektur festzuhalten und zu kommunizieren. Damit schließt sich natürlich die Frage an …
Für Qualitätsszenarien hält arc42 einen eigenen Abschnitt bereit: Abschnitt 10 (siehe Abbildung unten). Als Form sind dort ebenfalls ein Qualitätsbaum als Einstieg und dann eine Liste oder Tabelle mit den Qualitätsszenarien selbst vorgesehen.
Die Platzierung der Qualitätsszenarien weit hinten in der arc42-Vorlage lässt sich mit der groben Struktur der Gliederung erklären:
Das hindert Sie nicht daran, erste Qualitätsszenarien bereits früh im Projekt anzufertigen, um etwa Qualitätsziele besser mit allen Beteiligten diskutieren zu können.
Den siebten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. ;-)
Geforderte Qualitätsmerkmale gelten als zentraler Einflussfaktor auf Architekturentscheidungen. Einen weiteren wichtigen Einfluss stellen Rand- oder Rahmenbedingungen dar. Diesen widmen wir uns dann in der nächsten Folge. Ein weiterer Schnipsel für unser Gradle-Puzzle.
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.