Stefan Zörner
29.10.2013
Entscheidungen treffen heißt bei Software oftmals Kompromisse machen. In vielen Fällen zwischen qualitativen Eigenschaften, die Ihre Lösung dann hat, oder eben nicht. Besser, sie hat die unwichtigen nicht.
Nach Produktkarton und Systemkontext hier nun der dritte Schnipsel meines arc42-Starschnitts zu Gradle. Dieses mal geht es um Qualitätsziele. Als Synonym dafür ist “Architekturziele” gebräuchlich. Das unterstreicht ihre Bedeutung als Einflussfaktor auf Architekturentscheidungen (Architekturtreiber) – im Grunde sind es die wichtigsten architekturrelevanten Anforderungen.
Also wieder: Schere raus und losgeschnippelt …
Wer ein Programm entwirft, das Schach spielt (eine sogenannte Schach-Engine), trifft viele interessante Entscheidungen. Etwa: Wie stelle ich die aktuelle Spielsituation als Datenstruktur dar (wo stehen die Figuren auf dem Brett)? Da gibt es sehr unterschiedliche Möglichkeiten.
Naheliegend ist ein zweidimensionales Array mit 8 Zeilen und 8 Spalten für die 64 Felder, in dem jeweils die Figur gespeichert ist, die auf dem Feld steht. Man kann alternativ auch ausnutzen, dass ein long 64 Bit hat. Jedes Bit repräsentiert dann ein Feld, und wir kreuzen in einer long-Variablen an, wo die weißen Bauern stehen. Das selbe machen wir mit einer weiteren long-Variable für die schwarzen Bauern. Im Schach gibt es sechs Figurenarten und zwei Farben. Also 12 long-Variablen, und alles ist gespeichert. Das Ganze ist sehr effizient. Man kann beispielsweise durch bitweises Verodern leicht die freien Felder ermitteln, oder die Felder, wo der Gegner steht. Dafür ist es recht kompliziert zu implementieren, wie die Figuren laufen. Zumindest verglichen mit dem 2-dimensionalen Array, wo man direkt mit den Koordinaten arbeiten kann.
Was nehmen wir? Wenn Effizienz entscheidend ist, wohl die Bit-Darstellung. Wir nehmen in Kauf, dass der Quelltext für die Gangarten der Figuren schwieriger zu verstehen und damit zu warten ist. Wenn wir uns eine neue Figur ausdenken, und deswegen auf 10 x 10 Feldern spielen wollen, ist das bei der Array-Varriante leicht zu ändern. Die Bit-Darstellung ist hier weniger flexibel. Tatsächlich müssen wir verstehen, ob in dieser Situation eher Effizienz oder Wartbarkeit gefragt ist. Ein typisches Paar von sogenannten Qualitätsmerkmalen, die sich hier wechselseitig beeinflussen, und ausbalanciert werden müssen.
Wartbarkeit <=> Effizienz
Nun kann man leicht argumentieren, dass die Schachregeln wohl recht stabil sind, und nicht unbedingt damit zu rechnen ist, dass das Spielbrett vergrößert werden muss. Es könnte aber auch andere Anforderungen im Bereich Wartbarkeit geben, etwa dass Algorithmen leicht austauschbar seien sollen. Oder dass tatsächlich alternative Schachregeln leicht umgesetzt werden können. Wie wäre es mit Schach 960, Räuber-Schach, Zombie-Schach, Atom-Schach …? (siehe Buchtipp rechts).
Wollen wir mit unserer Lösung im Computerschach ganz vorne mitspielen oder eine Plattform zum Experimentieren mit Spielregeln und/oder Algorithmen schaffen? Hier gilt es Klarheit zu schaffen und die Qualitätsmerkmale zu priorisieren.
Wenn es um Weltmeisterschaften geht, ist Stefan Meyer-Kahlen der richtige Ansprechpartner. Sein Programm Shredder holte bisher 17 Weltmeistertitel in unterschiedlichen Kategorien des Computerschach, den letzten 2013 in Yokohama. Aus meinem persönlichen Austausch mit ihm:
Bei Shredder ist die Effizienz klar im Vordergrund, die Wartbarkeit des Quelltextes muss da leider manchmal hinten anstehen. (Stefan Meyer-Kahlen, Autor von Shredder)
Die unterschiedliche Beinflussung von Wartbarkeit und Effizienz je nach Wahl der Alternative für konkrete Fragestellungen ist ein typisches Beispiel, aber bei weitem nicht das einzige. Ein weiteres “Klassikerpaar” sind Sicherheit und Benutzbarkeit. Regelmäßig können Sie eine Entscheidung nicht treffen oder bewerten, wenn Sie nicht die geforderten Qualitätsmerkmale kennen. Diese Merkmale neigen übrigens dazu, im Deutschen auf -heit, -keit oder -tät zu enden. Die Tagcloud unten zeigt Qualitätsmerkmale, wie sie auch in der ISO/IEC 9126, einem Modell zur Softwarequalität, beschrieben sind.
Die wichtigsten geforderten Qualitätsmerkmale für ein Softwaresystem heißen Qualitätsziele. Typischerweise werden als Qualitätsziele im Rahmen eines Architekturüberblicks die Top-3 bis Top-5 genannt, und es wird versucht, diese zu priorisieren. Also das oberste Ziel vorn an zu stellen usw.
Im Idealfall nennt ein Architekturüberblick die Ziele aber nicht nur, er motiviert sie auch. Also nicht “Performance ist superwichtig”, sondern auch, was genau mit Performance in der konkreten Aufgabenstellung gemeint ist (Zeitverhalten, Verbrauchsverhalten, …), und warum es eine so entscheidende Rolle spielt.
Das folgende Beispiel illustriert dies wieder an unserem Serienstar Gradle.
Die folgende Tabelle beschreibt die zentralen Qualitätsziele von Gradle, wobei die Reihenfolge eine grobe Orientierung bezüglich der Wichtigkeit vorgibt.
| Qualitätsmerkmal | Ziel |
| Erweiterbarkeit | Gradle lässt sich leicht um neue Funktionalität erweitern. Es kann auf lange Sicht dem technologischen Fortschritt bei Tools und Entwicklungsmethodik folgen. |
| Effizienz | Teams und einzelne Entwickler erhalten durch kurze Buildzeiten schnelle Rückmeldungen; Gradle steigert so ihre Produktivität. |
| Interoperabilität | Gradle arbeitet mit bestehenden Werkzeugen wie Ant und Maven und deren Öko-Systemen nahtlos zusammen. |
| Erlernbarkeit | Entwickler und Buildmanager finden sich schnell in Gradle zurecht, der Einstieg und das Erstellen erster Build-Skripte fallen ihnen leicht. |
| Installierbarkeit | Der Aufwand, der zum Installieren von Gradle notwendig ist, um einen Build auszuführen ist, sehr gering. |
| Skalierbarkeit | Gradle bleibt auch bei sehr umfangreichen Builds und in Multi-Projekt-Szenarien handhabbar und effizient. |
Welches die richtigen Qualitätsziele sind, entscheiden die maßgeblichen Stakeholder. Sichern Sie ab, dass die Stakeholder sowohl die Ziele als auch deren Priorisierung akzeptiern.
Als Form für die Zutat hat sich eine Tabelle mit zwei Spalten (Qualitätsmerkmal, Ziel/kurze Erläuterung) bewährt. Nicht nur die bloße Nennung (“Gefordert sind Benutzbarkeit, Performance und Sicherheit”), sondern das Herausstellen und Motivieren der wichtigsten ca. 3-5 Merkmale. Es besteht insbesondere nicht der Anspruch, alle geforderten Qualitätsmerkmale zu nennen, sondern wirklich auf die zentralen zu fokussieren.
Zum Inhalt: Achten Sie darauf, dass die Qualitätziele zu den Inhalten des virtuellen Produktkartons (vgl. Schnipsel #1) passen. Jedes der Ziele muss für alle Beteiligten ausreichend motiviert sind. Stellen Sie in der Auflistung eine sinnvolle Reihenfolge der Ziele her (das Wichtigste zuerst, wenn möglich fachlich gruppiert).
Wenn Sie ein bestehendes Systems nachdokumentieren, macht es einen Unterschied, ob Sie den Istzustand beschreiben (“Welche Ziele erreichen wir jetzt mit unserer Lösung gut?"), das ursprüngliche Soll (“Welche Ziele wollten wir erreichen, als wir gestartet sind?") oder zukünftige Ziele (“Wo wollen wir mit der Weiterentwicklung hin?"). Alles drei kann je nach Situation sinnvoll sein, seien Sie sich aber bewusst, was Sie tun und vermischen Sie das nicht kommentarlos in einer Liste.
Qualitätsziele geben Orientierung für den Architekturentwurf und lenken die Entscheidungen in eine Richtung. Im Architekturüberblick nehmen sie einen prominenten Platz ein, da sie ein wichtiger Aufhänger sind um die Architektur nachvollziehbar zu machen.
Im konkreten Fall sind Qualitätsziele aber oft nicht genau genug, um im Architekturentwurf Alternativen sicher gegeneinander abzuwägen, angemessene Kompromisse zu finden und die Qualitätsmerkmale so auszubalancieren. Hier sind Qualitätsszenarien ein interessantes Werkzeug, um Qualitätsziele zu konkretisieren. Ich behandele sie in einem späteren Schnipsel dieser Serie.
Qualitätsziele haben ihren festen Platz in arc42, und zwar in Abschnitt 1 “Einführung und Ziele” in Unterabschnitt 1.2, siehe Abbildung unten.
Und auch im begleitenden Text zur arc42-Vorlage wird ihre Bedeutung deutlich betont.
Beginnen Sie NIEMALS mit einer Architekturentwicklung, wenn diese Ziele nicht schriftlich festgelegt und von den maßgeblichen Stakeholdern akzeptiert sind. (aus der Vorlage zu arc42)
Den dritten Gradle-Schnipsel zum farbig ausdrucken, ausschneiden und aneinanderkleben können Sie hier herunterladen. ;-)
Die bisherigen Zutaten drehten sich alle vorrangig um architekturrelevante Anforderungen. In der nächsten Folge stelle ich mit der Bausteinsicht endlich auch mal eine Zutat vor, die der Lösungsecke zuzurechnen ist. Sie können dort zum Beispiel Strukturentscheidungen festhalten.
Vielen Dank an an dieser Stelle an René Gröschke (Gradleware) für seine Rückmeldungen zur Serie und auch sein Feedback zu den Gradle-Qualitätszielen bereits im Vorfeld zu dieser Folge!
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.