API-Design. Kai Spichale
Чтение книги онлайн.
Читать онлайн книгу API-Design - Kai Spichale страница 17
Название: API-Design
Автор: Kai Spichale
Издательство: Bookwire
Жанр: Математика
isbn: 9783960886037
isbn:
Abb. 3–1 Allgemeines Vorgehen beim API-Entwurf mit Feedbackschleifen
Bevor Sie eine API entwerfen können, müssen Sie deren Rolle in der Gesamtarchitektur einordnen. Je nach System kann die API ein ganz entscheidender, wenn nicht sogar der entscheidende Bestandteil der Architektur sein – wenn es beispielsweise darum geht, mit der API die einzelnen Bestandteile so voneinander zu trennen, dass sie sich unabhängig voneinander weiterentwickeln können, enthält die API die Summe der wichtigen Entscheidungen.
Nachdem Sie die Klassen und Interfaces der zu entwerfenden API mithilfe der Codebeispiele in mehreren Review- und Feedbackschleifen identifiziert haben, könnten Sie eine formale Spezifikation erstellen. Falls Sie keine Programmiersprachen-API, sondern eine Web-API entwerfen, würden die Beispiele typischerweise aus HTTP-Requests und Responses bestehen.
3.2Heuristiken und Trade-offs
In sehr kleinen Projekten entsteht ein Entwurf häufig informell, während der Softwareentwickler vor seinem Computer sitzt [McConnell 2004]. Der Entwurf besteht vielleicht aus Pseudocode, der einige Klassenschnittstellen skizziert. Danach folgt schon die eigentliche Umsetzung. Für größere Projekte ist ein Entwurf jedoch sehr wichtig. Der fertige Softwareentwurf sollte durchdacht und gut strukturiert sein und alle priorisierten Anforderungen umsetzen. Doch der Prozess, der zu diesem Ergebnis führt, sieht bei Weitem nicht so ordentlich aus. David Parnas und Paul Clements bringen es auf den Punkt [Parnas & Clements 1986]:
»Die Vorstellung, dass ein Softwareingenieur seinen Entwurf in einem rationalen, fehlerfreien Weg aus den Anforderungen ableitet, ist ziemlich unrealistisch. Kein System ist jemals auf diese Weise entwickelt worden, und wahrscheinlich wird das auch nie passieren. Selbst die Entwicklung kleiner Programme in Lehrbüchern und Artikeln sind unrealistisch. Sie wurden überarbeitet und aufpoliert, bis der Autor uns gezeigt hat, was er beabsichtigte, und nicht, was tatsächlich geschah.«
Daher muss man akzeptieren, dass »die erste Version niemals perfekt ist« [Tulach 2008]. Fast jedes Programm muss im Verlauf der Zeit weiterentwickelt werden, weil sich Anforderungen ändern. Wichtige Anforderungen in der Vergangenheit können morgen ungültig sein. Es könnte auch sein, dass Benutzer eine API für Aufgaben einsetzen, für die sie ursprünglich nicht konzipiert wurde.
Aus diesem Grund ist das in diesem Kapitel beschriebene Vorgehen eine Heuristik und kein deterministischer Algorithmus, den Sie Schritt für Schritt abarbeiten können, um sicher zum bestmöglichen Ergebnis zu gelangen.
3.3Anforderungen herausarbeiten
Bevor man über eine mögliche Lösung nachdenken kann, muss man erst einmal wissen und verstehen, wie die Anforderungen lauten. Systematisch ermittelte Anforderungen minimieren das Risiko, das falsche System zu bauen. Anforderungen sind häufig verborgen unter mehreren Schichten aus falschen Annahmen, Missverständnissen und politischen Entscheidungen. Anforderungen können nicht einfach eingesammelt werden, sie müssen ausgegraben werden [Hunt & Thomas 1999].
Vorgaben kritisch hinterfragen
Anforderungen sind noch keine Lösungen, wenngleich vermeintliche »Anforderungen« implizite technische Lösungen oder Einschränkungen enthalten können. Diese Vorgaben müssen kritisch hinterfragt werden, um bessere technische Lösungen finden zu können.
Anforderungen verständlich und genau formulieren
Anforderungen sollten einfach und verständlich formuliert sein, um Missverständnisse von vornherein zu vermeiden. Genauigkeit ist ebenfalls wichtig: Eine Aussage wie »Die Schnittstelle muss intuitiv und einfach verständlich sein« ist nicht hilfreich, weil »intuitiv« nicht quantifizierbar ist. Die Anforderung »Die Schnittstelle muss fehlerfrei sein« ist nicht realisierbar, denn nicht triviale Software enthält immer Fehler. Auch Anforderungen wie »Die Software läuft mit der neuesten Java-Version« sind zu ungenau, weil beispielsweise nicht klar ist, ob das SDK oder das JRE gemeint ist.
Kompromisse fair verteilen
Kompromisse müssen gemacht werden, wenn Anforderungen unterschiedlicher Benutzergruppen in Konflikt zueinander stehen. Es ist empfehlenswert, in solchen Fällen die Abstriche gleichmäßig auf alle Benutzer zu verteilen, sodass jeder eine Lösung erhält, mit der er arbeiten kann, obwohl sie für niemanden perfekt ist [Bloch 2006].
Mit wenigen Seiten anfangen
Den Entwurf einer API sollte man mit einem Umfang von zunächst nur wenigen Seiten beginnen. Denn nicht jeder Kollege, den man um Feedback bittet, hat Zeit und Lust ein hundertseitiges Dokument zu lesen. Ein kurzer Entwurf kann außerdem auch leichter verändert werden. Agilität ist am Anfang wichtiger als Vollständigkeit.
3.4Wenn Use Cases nicht ausreichen
Use Cases sind eine etablierte Technik zur Ausarbeitung von Benutzeranforderungen. Use Cases dokumentieren die Vereinbarungen zwischen den Beteiligten eines Projektes über das Verhalten des geplanten Systems. Das Verhalten des Systems ist die Reaktion auf das Handeln eines Hauptakteurs, der ein bestimmtes Ziel verfolgt. Für jeden Use Case werden deswegen Szenarien für die Verwendung des Systems entwickelt. Ein Use Case ist relativ abstrakt und fasst mehrere Szenarien, die dieselben Ziele betreffen, zusammen.
Man kann Use Cases formlos schreiben, häufig werden auch Templates verwendet. Alistair Cockburn empfiehlt eine kurze informelle Variante (casual version) und eine stark strukturierte Variante (fully dressed version) [Cockburn 2000]. Wem keine der beiden Varianten gefällt, kann diese für sein Projekt anpassen. Man sollte in jedem Fall sicherstellen, dass Use Cases ein Ziel haben, einfach zu lesen sind und nicht zu viele Schritte enthalten.
Use Cases vermitteln Entwicklern ein allgemeines Verständnis über das beabsichtigte Verhalten des Systems. Allerdings brauchen Entwickler mehr Informationen als in Use Case enthalten sind. Aus diesem Grund ist neben den Use Cases auch eine Anforderungsspezifikation (software requirements specification) notwendig, die die funktionalen und nicht funktionalen Anforderungen detaillierter beschreibt.
Use Cases sind ungeeignet für beispielsweise Hardwareprodukte mit Steuerungssoftware, für Data-Warehouse-Projekte, Datenverarbeitung mit Batch-Jobs und andere komplexe Datenverarbeitungssoftware. Denn in den genannten Beispielen ist die Komplexität in den Berechnungsalgorithmen verborgen. Der Gebrauch der Software, die mit den Use Cases dargestellt wird, ist im Vergleich dazu trivial. Die Use Cases können in diesen Fällen die für Entwickler interessanten Informationen nicht beschreiben.
Eine wichtige Alternative sind die Event-Response-Tabellen [Wiegers 2006]. In Abhängigkeit des Zustandes des Systems reagiert das System auf ein Ereignis mit einer bestimmten Reaktion oder Antwort. Ereignisquellen sind beispielsweise Sensoren, zeitbasierte Trigger oder Benutzeraktionen.
3.5Entwurf mit Szenarien und Codebeispielen
Hilfreich zum Entwurf einer API sind Beispiele, die die Verwendung der API aus Clientperspektive zeigen. Als Grundlage für diese Beispiele sind repräsentative Anwendungsszenarien СКАЧАТЬ