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.

TeaserBild_Folge_7

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 …

Sachen machen (Making things)

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 auf 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.

Arduino_SpaceInvaders

Ein Arduino Uno (links) bei der Arbeit

Doch nicht so toll?

lrg

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).

PinMapping

Pinbelegung ATmega328 (notiert in schwarz) und Bezeichnungen Arduino (in rot) — Ausschnitt

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 …

Beispielhafte Qualität

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:

  • [BEN01] Ein in Elektronik Unkundiger mit Programmiererfahrung möchte mit einem Arduino drei LEDs nach Art einer Ampel zum Leuchten bringen. Nach einer Stunde ist das Projekt erfolgreich ohne Lötarbeiten abgeschlossen und es blinkt.
  • [PRT01] Ein Programmierer möchte ein für Arduino entwickeltes Programm auf einem anderen AVR-Mikrocontroller (zum Beispiel ATtiny13) betreiben. Dies gelingt ihm ohne Änderung des Quelltextes.
ATtiny

Ein ATtiny ist ziemlich klein

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.

Typischer Aufbau

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.

BestandteileQualitaetsszenario

Typische Bestandteile eines Qualitätsszenarios, und ein Beispiel

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!

– – – 8< – – –

Schnipsel #7: Qualitätsszenarien für GradleKleinesPuzzleTeilNr7

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.

  • [ANP01] Ein IDE-Anbieter möchte Gradle-Projekte in seinem Produkt unterstützen. Dies gelingt ihm ohne Änderung am Gradle-Quelltext in weniger als 5 Personentagen Aufwand.
  • [EFF01] Ein Gradle-Benutzer lässt sich die verfügbaren Tasks eines Projektes anzeigen. Er erhält nach maximal 5s eine Rückmeldung.
  • [ERL01] Ein Entwickler mit Ant/Ivy-Kenntnissen stellt einen bestehenden Ant/Ivy-Build auf Gradle um. Dies gelingt im deutlich schneller als mit Maven.
  • [ERL02] Ein Gradle-Neuling erstellt ein einfaches Java-Projekt mit Gradle. Spätestens nach einer Stunde übersetzt der Quelltext, laufen erste Tests, und sein Build produziert ein jar-File.
  • [ERW01] Ein Build-Master möchte eine neue Programmiersprache (3GL), für die Gradle noch keine Funktionalität bereithält,  mit Gradle unterstützen. Rudimentäre Tasks zum Übersetzen etc. laufen bereits nach einem Tag.
  • [ERW02] Ein externer (d.h. Gradleware-fremder) Entwickler stellt eigene Gradle-Funktionalität allgemein (öffentlich) bereit. Im Anschluss müssen Verwender von Builds-Skripten, die diese Funktionalität nutzen, dafür nichts separat installieren.
  • [INT01] Für eine von Gradle nicht out-of-the-box unterstützte Aufgabe steht ein Ant-Task zur Verfügung. Das Einbinden in einen Gradle-Build erfordert keine tieferen Groovy/Java-Kenntnisse.
  • [IST01] Ein Entwickler ohne Gradle-Kenntnisse (und ohne Gradle-Installation auf seinem Notebook) checkt ein Projekt, das mit Gradle gebaut wird, aus Subversion aus. Spätestens 1 Minute später startet er den Build.
  • [SKA01] Die Anzahl der Subprojekte in einem Gradle-Build verdoppelt sich. Die Zeit, um ein bestehendes Subprojekt neu zu bauen, bleibt gleich.
  • [SKA02] Die Anzahl der Quelltextdateien in einem Projekt wächst von 20 auf 200. Das Neubauen bei Änderung einer einzelnen Quelltext-Datei, zu der keine Abhängigkeiten bestehen, dauert gleich lang.
  • [STA01] Gradleware veröffentlicht eine neue Gradle-Version. Bestehende Projekte lassen sich damit ohne Änderung bauen.
  • [ZUV01] Ein Build erfordert ein Artefakt aus einem Maven-Repository. Der Build wird initial angestoßen, aber es besteht keine Verbindung zum Repository. Der Benutzer wird darüber informiert, der Build bricht ab.

Die folgende Abbildung ordnet diese Szenarien Qualitätsmerkmalen zu.

Qualitätsbaum

Qualitätsbaum: Zuordnung der Szenarien zu Qualitätsmerkmalen

– – – >8 – – –

Erfüllt Gradle diese Szenarien eigentlich?

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 (Gradleware, @breskeby) 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!

Wie konkret müssen Szenarien sein?

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.

Wie viele Qualitätsszenarien fertigen Sie für Ihr Projekt an?

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 …

Wo kleben wir den Schnipsel hin?

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.

Schnipsel #7 abheften in arc42

Die Platzierung der Qualitätsszenarien weit hinten in der arc42-Vorlage lässt sich mit der groben Struktur der Gliederung erklären:

  • Aufgabe (Abschnitte 1-3)
  • Lösung (Abschnitte 4-9)
  • Bewertung (Abschnitte 10-11)

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.

Zum Weiterlesen

  • Qualitätsszenarien sind auch ein Dokumentationsmittel in meinem Buch Softwarearchitekturen dokumentieren und kommunizieren. Eines der Fallbeispiele des Buches, eine Schach-Engine, ist online verfügbar und besitzt ebenfalls Qualitätsszenarien und einen Qualitätsbaum: Qualitätsszenarien DokChess
  • Hagen Fisbeck schreibt hier auf regital.de: „Die Makerbewegung und ihre Auswirkungen auch auf den Handel“
  • Der Klassiker: Len Bass et al., „Software Architecture in Practice“, 3. Auflage Addison-Wesley 2012. Beschreibt Qualitätsszenarien, ihren hier ebenfalls gezeigten Aufbau und Einsatz in der Architekturbewertung.
  • Stefan Toth empfiehlt in seinem Buch Vorgehensmuster für Softwarearchitektur Qualitätsszenarien zum Erarbeiten und Priorisieren architekturrelevanter Anforderungen. Er diskutiert u.a. auch wie man sie in einem Scrum-Backlog mitführt.

Ausblick

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.

Ich hoffe, Sie finden weiterhin Gefallen an dieser kleinen Serie und freue mich auf Ihre Fragen und Rückmeldungen. Kommentieren Sie einfach hier im Blog oder schreiben Sie mir (E-Mail: stefan.zoerner[ät]embarc.de). Wünsche greife ich gerne in den nächsten Folgen auf, Fragen beantworte ich direkt hier.

Sie haben einen Schnipsel des arc42-Starschnitts zu Gradle verpasst? Hier finden Sie alle bisherigen Folgen.