Dienstag, 15. Oktober 2013

Reengineering – Am Ende gab es nur noch eine Schnittstelle.

Praktisches Beispiel 1.6

Artikelübersicht
1. Teil Reengineering - Die Analyse des Altcodes.
2. Teil Requirements Engineering – erst einmal die Anforderungen definieren.
3. Teil Systemanalyse – vielleicht doch erst mal eine Architektur.
4. Teil Reengineering - Neu, strukturiert und auf lange Sicht schneller.
5. Teil Schon Vorhandenes nutzen wäre schneller gewesen. Beispielcode
6. Teil Reengineering – Am Ende gab es nur noch eine Schnittstelle.


Zum Abschluss meiner Reengineering-Reihe möchte ich eine Frage versuchen zu beantworten, die mir in einem Xing-Forum gestellt wurde. Was, wenn nur noch die Schnittstelle übrig ist? Ich könnte es mir einfach machen und das folgende antworten: Ein Reengineering ist die Umgestaltung, die Restrukturierung und Neugestaltung eines Softwaresystems. Dazu gehört auch die genaue Analyse des Altsystems. In den fünf ersten Posts dieser Reihe ist das herausgearbeitet worden. Wenn von diesem Gesamtsystem jedoch nur noch Teile übrig sind, dann kann man auch nur noch aus diesen Teilen Informationen gewinnen und muss den Rest neu aufbauen.

Schnittstellen sind jedoch bedeutende Bestandteile eines Softwaresystems. "Eine Schnittstelle definiert einen Vertrag, der für den Fall des >>vertragsgemäßen<< Aufrufs die ebenfalls >>vertragsgerechte<< Ausführung einer bestimmten Aktion garantiert." [S.42, REUS09] In Java gibt es das Interface. Das Interface ist eine Ansammlung von öffentlichen Methodennamen. Es gibt Schnittstellen, die Funktionalität anbieten (provided interfaces) und Schnittstellen, die benötigte Funktionalität anzeigen (required interfaces). Schnittstellen legen der Außenwelt einer Komponente also das bereitgestellte und das benötigte Verhalten offen.



Welche Informationen können nun aus einer Schnittstelle gewonnen werden? Eine gute Schnittstelle wurde für eine klar definierte Verantwortlichkeit entworfen. Sie kann z.B. die Fassade einer Komponente sein. Daraus schlussfolgern wir, es handelt sich um eine Schnittstelle, die Funktionalität bereitstellt. Für die Schnittstelle sollten Javadoc-Kommentare angelegt worden sein. Noch wichtiger als diese Kommentare sind gut gewählte Namen für die bereitgestellten Methoden. Bei den meisten Methodennamen sollte klar sein, was man ihnen übergeben muss und was sie daraufhin liefern. Gibt es dazu auch noch eine Schnittstellendokumentation innerhalb einer angelegten Architekturdokumentation, nähern wir uns in Bezug auf die Schnittstelle fast paradiesischen Zuständen. :-) Das Reengineering eines Softwaresystems, wenn nur noch diese Schnittstellen vorhanden sind, ist dann jedoch trotzdem eine Neuimplementierung. Gut definierte Schnittstellen sind dabei jedoch eine große Hilfe. Schlecht konzipierte Schnittstellen können die Arbeit noch schwieriger machen.

Folgende Punkte sollten bei der Konzeption einer Schnittstelle beachtet werden. Eine Schnittstelle wird für eine bestimmte Verantwortlichkeit erdacht. Es sollte vermieden werden, mehrere Verantwortlichkeiten zu vermischen. Mit Hilfe des Names einer Schnittstelle muss man eindeutige Rückschlüsse auf deren Verantwortlichkeit ziehen können. Sie sollte dem Prinzip der Einfachkeit folgen, also so einfach wie möglich sein. Außerdem sollte die Schnittstelle so konstruiert sein, dass sie über eine lange Zeit stabil bleibt und man nicht dazu gezwungen wird, in kurzen Abständen seine Implementierung zu ändern, welche diese Schnittstelle nutzt. Eine strenge Abwärtskompatibilität sollte gewährleistet werden.

Wenn man ein System von Komponenten hat, in dem die Verträge der Komponenten über Schnittstellen festgelegt wurden, so sollten diese Schnittstellen auch einer Versionierung unterliegen. Die Schnittstelle und die Zugriffslogik können dabei in eine eigene Komponente ausgelagert werden. Das folgende Bild wurde aus [S.111, FILD12] übernommen.



"Wenn eine weitere Datenquelle hinzukommt, existiert einfach ein weiterer Eintrag in der Liste. Die Verwendung ist komplett unabhängig von den Implementierungen der Datenquellen, ...". [S.111, FILD12] Ulf Fildebrandt verwendet diese Komponenten in einem OSGi-Laufzeitsystem. Er kann zur Laufzeit beliebige neue Datenquellen nachladen.

Zum Schluss möchte ich noch einmal darauf hinweisen, dass eine Schnittstelle eine Vertragsdefinition ist, die über einen möglichst langen Zeitraum Bestand haben sollte. Für eine solche Schnittstelle ist es möglich neue Implementierungen zu schaffen, die bessere Algorithmen und bessere oder andere Techniken benutzen. Da Schnittstellen einen langfristig konstanten Charakter besitzen und sie höchstens erweitert werden, lohnt sich eine Architekturdokumentation in jedem Fall. Nachkommende Entwicklergenerationen werden dafür sehr dankbar sein.

Stefan Zörner schlägt in seinem Buch [ZÖR12] die folgende Vorlage vor: "
Abschnitt Inhalte
Steckbrief Genauer Name der Schnittstelle, Kurzbeschreibung der Funktionalität, ggf. Autoren und Besitzer (zwischen wem wurde die Schnittstelle ausgehandelt?), ggf. Version
Interaktion Je nach Schnittstellenart Operationen (z.B. Funktionen, Methoden) oder Datenaustausch (z.B. Nachrichten). Je Interaktion:
  • Beschreibung der Syntax (Technik)
  • Beschreibung der Semantik (Fachlichkeit)
  • Fehlerbehandlung
Datentypen und Konstanten Bei den Interaktionen verwendete und gemeinsam mit der Schnittstelle definierte Aufrufparameter, Rückgabewerte, Konstanten, Datenformate
Fehlerbehandlung Generelles zur Fehlerbehandlung, alternativ oder ergänzend zu den Ausführungen bei den Interaktionen
Einstellungen Konfigurationsmöglichkeiten, welche die Schnittstelle oder der Baustein bieten, z.B. zum Logging
Qualitätsmerkmale Aussagen oder Qualitätsmerkmale, an die Implementierer gebunden sind und auf die sich Nutzer verlassen können
Entscheidungen beim Entwurf Fragestellung, Einflüsse, Annahmen, Alternativen und Begründungen für Entwurfsentscheidungen im Zusammenhang mit der Schnittstelle, falls angebracht
Beispielverwendung Pseudocode oder Quelltext bei Operationen, Beispieldaten bei Datenformaten

"[S103, ZÖR12]

Das Buch von Stefan Zörner [ZÖR12] kann ich nur weiter empfehlen. Es lohnt sich von Anfang bis zum Ende und man merkt die Begeisterung des Schreibenden.

Die Anfangsfrage, was machen wir, wenn nur noch die Schnittstelle übrig ist, kann man also nur beantworten, wenn man weiß, welche Qualität diese hat. Die Implementierung muss dann so oder so erfolgen, aber sie kann schneller oder langsamer sein, je nachdem, wie viele Informationen aus der Schnittstelle gezogen werden konnten.

  • [FIELD12]: Ulf Fieldebrandt: "Software modular bauen", 1. Auflage, dpunkt.verlag GmbH, Heidelberg, 2012
  • [REUS09] Ralf Reussner, Wilhelm Hasselbring: "Handbuch der Software-Architektur", 2. überarbeitete und erweiterte Auflage, dpunkt.verlag GmbH, Heidelberg, 2009
  • [ZÖR12] Stefan Zörner: "Softwarearchitekturen dokumentieren und kommunizieren", Carl Hanser Verlag München, 2012


vorheriger Post dieses Themas


Print Friendly Version of this page Print Get a PDF version of this webpage PDF

Keine Kommentare:

Kommentar veröffentlichen