en
de

Bessere Kommunikation durch domänenspezifische Sprachen?

25 April 2013
| |
Lesezeit: 4 Minutes

In der Projektpraxis wird gerne übersehen, dass eines der kritischsten Usability Risiken nicht das Produkt, sondern die Kommunikation im Projektteam betrifft. Die Übersetzung von Features zu einer technischen Spezifikation ist umständlich, zeit- und arbeitsintensiv und ausgesprochen fehleranfällig. Abhilfe, zumindest was die Fehleranfälligkeit angeht,  verspricht der Einsatz domänenspezifischer Sprachen.

Die Übersetzungskette als Stille Post

In einem typischen Spezifikations-Prozess beschreibt der Fachexperte das benötigte Feature, der Business Analyst formuliert daraufhin die Business Anforderung, der Requirements Engineer übersetzt die Business Anforderung in eine testbare Systemanforderung und der Entwickler setzt die Anforderung mitsamt Testfall um. Ein bestandener Testfall ist jedoch kein Garant dafür, dass das Feature erfolgreich umgesetzt wurde. Wie beim Spiel der Stillen Post kommt es beim Spezifizieren des Features zu Informationsverlusten und sich fortpflanzenden Interpretationsfehlern. Um diese auszuschliessen, müsste der Fachexperte den Testfall lesen können, was jedoch ohne die nötigen Programmierkenntnisse kaum möglich ist. Blindes Vertrauen auf ein konsistentes  Anforderungsverständnis im Projektteam führt im schlimmsten Fall dazu, dass das falsche Produkt gebaut wird – ein Produkt, welches nicht den Kundenwünschen entspricht.

Wäre es nicht schön, wenn die Übersetzungskette übersprungen werden könnte und es einen direkten Kommunikationskanal zwischen IT und Technik gäbe? Eine mögliche Strategie ist die Verwendung von User Interface Prototypen. Diese werden von Fachexperten und Entwicklern gleichermassen verstanden und können zudem äusserst vielseitig eingesetzt werden. Als alleiniges Spezifikationswerkzeug eignen sie sich jedoch nur für sehr simple, oberflächenzentrierte Anwendungen. Bei grösseren Vorhaben stösst das Werkzeug hingegen schnell an seine Grenzen. Typische Nachteile:

  • Eine vollständige Abdeckung aller Alternativabläufe ist aufgrund des hohen Erstellungsaufwands kaum sinnvoll
  • Keine Möglichkeit, Abläufe unabhängig vom User Interface strukturiert zu erfassen
  • Aufgrund der Unvollständigkeit des Prototypens entsteht ein unerwünschter Interpretationsspielraum beim Ableiten von Akzeptanzbedingungen.

Einen umfassenderen Lösungsansatz für das Kommunikations-Dilemma bieten domänenspezifische Sprachen (DSL). Die Idee klingt verlockend: der Fachexperte formuliert in seiner Fachsprache ein Feature, welches der Entwickler eins zu eins in einen automatisierten Test umwandeln kann.

Eine Gurke die hilft zu kommunizieren

Frameworks wie Cucumber ermöglichen es, mit (halbwegs) natürlicher Sprache und realistischen Beispielen zu beschreiben, wie sich das System verhalten soll. Diese Beschreibung wird vom Framework als automatisierte Tests ausgeführt. Cucumber unterstützt Behavior-Driven Development (BDD) – ein Schlagwort mit viel Buzz-Word Potential welches betont, dass der Entwicklungsfokus auf dem Umsetzen von Geschäftswerten und damit auf der Erfüllung der Kundenbedürfnisse liegt.

Beispiel einer Akzeptanz-Spezifikation aus dem Cucumber-Wiki:

Feature: Search courses
  In order to ensure better utilization of courses
  Potential students should be able to search for courses

  Scenario: Search by topic
    Given there are 240 courses which do not have the topic 
    "biology"
    And there are 2 courses A001, B205 that each have 
    "biology" as one of the topics
    When I search for "biology"
    Then I should see the following courses:
      | Course code |
      | A001        |
      | B205        |

Ein „Feature“ beschreibt als Freitext den Geschäftswert einer gewünschten Produkteigenschaft und besteht aus Szenarien, welche sich wiederum aus sogenannten Schritten zusammensetzen. Schritte beginnen mit den Stichworten ‚Given‘, ‚When‘, ‚Then‘, ‚And‘, ‚But‘  und beschreiben das Systemverhalten mit konkreten Anwendungsbeispielen. Die einzelnen Schritte werden von Entwicklern  als Methoden umgesetzt. Zur Testlaufzeit führt Cucumber die Szenarien aus, indem es für jeden Schritt  die entsprechende Methode aufruft. Tritt ein Fehler auf, wurden die Akzeptanzkriterien nicht erreicht.  Gemäss der BDD Philosophie werden dabei zunächst die automatisierten Akzeptanz-Tests definiert.  Nachdem die Prüfung fehlgeschlagen ist, entwickeln die Programmierer eine Lösung, die gerade ausreicht, um die Tests zu bestehen. Im Ergebnis soll das Produkt nicht weniger aber auch nicht mehr leisten, als in den Tests vorgeschrieben ist.

Erwünschtes Verhalten

Der DSL-Ansatz mag Mehraufwand generieren, er bietet jedoch auch einen entscheidenden Vorteil. Aufgrund der natürlichen Sprache der ausführbaren Akzeptanz-Kriterien ist für den technikfernen Fachexperten jederzeit nachvollziehbar, welches Verhalten implementiert ist und wo fachliche Detaillierungen, Änderungen und Erweiterungen notwendig sind. Neben Englisch ist Gherkin, die von Cucumber verwendete DSL, in 36 weiteren Sprachen verfügbar. Cucumber selber ist in Ruby geschrieben, kann aber auch im Kontext anderer Technologien wie Java und C# zum Testen verwendet werden.

Warum nicht gleich selber Programmieren?

DSLs haben in der Software-Entwicklung zwar eine bessere Usability als abstrakte Kommunikationswerkzeuge wie UML – gemessen an Technologie-Visionen der 60er Jahre  sind sie jedoch eher ein Rückschritt. Programmiersprachen wie COBOL (COmmon Business-Oriented Language) wurden gezielt mit Hinblick auf die natürliche Sprache und einen betriebswirtschaftlichen Kontext entworfen. Durch die niedrigen Einstiegshürden sollten bestenfalls Fachexperten zum Programmierer der eigenen Anforderungen werden. Dieser Ansatz ist bekanntermassen gescheitert. COBOL wurde und wird zwar erfolgreich genutzt – aber nicht von Fachexperten sondern von Entwicklern.

Ein ähnliches Beispiel aus der jüngeren Vergangenheit sind deklarative GUI-Beschreibungssprachen wie MXML (Flash) und XAML (Microsoft). Diese sollten zumindest Interaction Designer zum Self-Service am Quellcode bewegen. Vergeblich. Nach wie vor ziehen Gestalter und auch Entwickler als gemeinsame Schnittstelle das liebgewonnene Bitmap vor.

Bessere Usability, aber noch nicht gut genug

Ob sich DSLs als direkter Kommunikationskanal zwischen Fachabteilung und IT durchsetzen werden, bleibt abzuwarten. Behaviour-Driven Development ist ein populäres Thema, in dessen Windschatten auch DSLs ihren Exotenstatus verlieren könnten. In einem Kundenprojekt, welches ich vor kurzem unterstützen durfte, wird Cucumber bereits seit über einem Jahr erfolgreich im agilen Kontext eingesetzt. Allerdings erforderte dies zunächst eine umfangreiche Schulung der Business Analysten. Noch effizienter wäre es natürlich, wenn die Product Owner eigenständig Features in Gherkin schreiben würden. Dafür muss die Usability des DSL-Ansatzes jedoch deutlich verbessert werden. Mögliche Ansätze:

  • Bereitstellen von visuell repräsentablen Feature-Templates mit weniger Techi-Ambiente und dafür eingebauter Hilfestellung bei der Formulierung geeigneter Szenarien
  • Steigerung der Motivation durch Ausbau der DSL in Richtung Storytelling
  • Verknüpfung von Szenarien mit User Interface Prototypen oder Storyboards

Zu guter Letzt bleibt noch klarzustellen, dass der Einsatz von DSL-gestützten Werkzeugen wie Cucumber nicht die mündliche Kommunikation im Projektteam ersetzen kann oder soll. Ähnlich wie User Stories dienen die textuellen Beschreibungen als Aufhänger, um fokussierte Diskussionen zwischen Fachexperten und Entwicklern zu ermöglichen. Der DSL-Ansatz besticht dabei durch hohe Allgemeinverständlichkeit einerseits sowie durch eine enge Verzahnung mit automatisierten Akzeptanztests andererseits.

Verwendete und weiterführende Quellen

Cucumber Wiki: https://github.com/cucumber/cucumber/wiki

Martin Fowler: “BusinessReadableDSL”,  15. Dezmber 2008. http://martinfowler.com/bliki/BusinessReadableDSL.html

Kommentare (2)

Muss das Telefonspiel sein?

11 Juli 2013 um 15:03

[…] ist auch Thorstens Erfahrung mit dem Telefonspiel – oder Stille Post, wie er es nennt – und Cucumber […]

Andreas Kleffel

1 März 2014 um 09:02

Ich möchte nicht ausschließen, dass Gherkin für bestimmte Einsatzzwecke gut geeignet ist. Das Beispiel mit der Kurssuche finde ich aber absolut negativ. Gherkin ist dafür völlig ungeeignet.

Ein wichtiger Grundsatz ist die Angemessenheit von Dokumentationsmitteln. Für eine solche Suche ist aber sicher ein grober Wireframe die geeignetste Dokumentationsform.

Warum soll überdies jetzt jede Art der Anforderung Testgetrieben ausgedrückt werden?

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.