Deutsch | English | Español

Auch für die ABAP-Entwicklung gilt: Verträge sind einzuhalten!

3. Februar 2017

Design By Contract und Kapselung sind zwei zentrale Konzepte in der Softwareentwicklung. Sie dienen der Sicherheit und Stabilität. Gut entwickelte Applikationen beachten diese Prinzipien.

VON SEBASTIAN SCHÖNHÖFER UND MARKUS HEID, VIRTUAL FORGE

Für wen bedeutet dies nun Sicherheit und Stabilität? Für den Aufrufenden und den Aufgerufenen!

In der Regel stellt ein Modul sogenannte Contracts (Verträge) zur Verfügung. Jeder dieser Verträge beschreibt, was als Eingabe zu erwarten ist, was gemacht und ggf. was als Ergebnis zurückgegeben wird.  Es gilt in der Softwareentwicklung das gleiche Prinzip wie in der Realität: „Pacta sunt servanda!“ (lat.; dt. Verträge sind einzuhalten). Auch wenn es gelegentlich, wie auch im normalen Leben, Meinungsverschiedenheiten darüber gibt, was unter einer erfolgreichen Erfüllung eines Vertrages zu verstehen ist.

Unter der oben erwähnten Kapselung versteht man zum einen, dass der Aufrufende nicht wissen muss, wie die versprochene Leistung zustande kommt. Zum anderen dass der Aufgerufene die Möglichkeit hat, die geforderten Eingaben zu überprüfen, bevor man mit diesen weiterarbeitet.

Als Analogie kann man sich eine klassische papiergebundene Banküberweisung vorstellen: Herr Fischer füllt den Überweisungsschein aus, er gibt als Eingabe den Namen des Empfängers, die IBAN, den Überweisungsbetrag, sowie Verwendungszweck und, optional, den Überweisungstermin an (sowie noch Datum und Unterschrift). Dies wirft Herr Fischer nun in den vorgesehenen Überweisungskasten. Dabei ist es ihm vollkommen egal ob nun auf Seiten der Bank Herr Müller oder Frau Schneider den Schein entgegennimmt und die Überweisung ausführt.

Herr Müller bzw. Frau Schneider wiederum haben die Möglichkeit, die Eingabeparameter zu prüfen, z. B. stimmt die IBAN oder wurde die Überweisung korrekt unterschrieben. Zusätzlich wird intern noch überprüft, ob das Konto ausreichend Deckung aufweist. Stimmen alle Randbedingungen, so wird die Überweisung veranlasst und als Ergebnis verschwindet der Betrag vom Konto des Herrn Fischers und taucht wieder auf dem Konto des Empfängers auf.  Zusätzlich gibt es noch eine Überweisungsbestätigung für den Überweisenden.

Umgeht man nun diesen definierten Contract und greift direkt auf interne Vorgänge zu, so können sich für beide Seiten eine Reihe von Problemen ergeben:

Nehmen wir an Herr Fischer hat niemals gelernt eine Überweisung auszufüllen, sondern hat Herrn Müller bzw. Frau Schneider immer direkt angerufen. Nun sind aber Herr Müller bzw. Frau Schneider plötzlich aus irgendeinem Grund nicht mehr erreichbar. Auf jeden Fall kann Herr Fischer plötzlich kein Geld mehr überweisen und da er ein langsamer Lerner ist, dauert es mehrere Monate bis er sich beigebracht hat, einen Überweisungsschein auszufüllen. In dieser Zeit laufen Rechnungen auf, er bekommt Mahnungen inkl. Mahngebühren und am Ende sogar das Schreiben eines Inkassoanwaltes. Das ist natürlich aus Sicht des Herrn Fischers wenig erstrebenswert.

Nun betrachten wir das ganze einmal aus Sicht der Bank. Was für ein Problem kann sich hier ergeben? Nehmen wir nun mal an, dass Herr Müller bzw. Frau Schneider von einem bemerkenswert naiven, aber unerschütterlichen Glauben an das Gute und Ehrliche im Menschen beseelt sind und ohne Rückfrage oder Misstrauen prompt alles ausführen, was eine beliebige Person wünscht. Herr Müller bzw. Frau Schneider bearbeiten also momentan die Überweisung des Herrn Fischer und alle benötigte Überprüfungen waren erfolgreich, da klingelt auf einmal das Telefon und eine Stimme beauftragt, den Überweisungsbetrag zwar auf dem Konto des Empfängers gutzuschreiben, aber stattdessen vom Konto des Herrn Schmitt abzubuchen. Herr Müller bzw. Frau Schneider entsprechen natürlich auch sofort den Wunsch dieser mysteriösen Stimme. Was im übrigen Herrn Schmitt bei der nächsten Durchsicht der Kontoauszüge sehr überrascht hat. Das ist natürlich aus Sicht der Bank auch nicht besonders erstrebenswert.

Um nun die Analogie zu verlassen und zurück zur Programmierung zu kommen:  ABAP bietet den Programmierer Möglichkeiten an, definierte Schnittstellen zu umgehen und direkt auf interne Felder, welche normalerweise verborgen sind, zuzugreifen. Als Konsequenz daraus werden die oben beschrieben Prinzipien Design By Contract und Kapselung umgangen. Aus dem Überweisungsszenario kann man bereits erkennen, dass ein direkter Schreib-/Lesezugriff auf ein internes Feld eines Moduls keinerlei Plausibilitätscheck unterliegt und somit die Integrität der Anwendung gefährden kann. Weiterhin kann das zugegriffene Feld jederzeit verschwinden, z.B. im Rahmen eines Softwareupdates. Ein direkter Zugriff auf Felder innerhalb eines Moduls kompromittiert somit nicht nur die Sicherheit sondern auch die Stabilität (Robustness) einer Applikation.

Aus diesem Grund bietet VirtualForge CodeProfiler for ABAP den eigens auf diese Situation zugeschnittenen Testfall Nr. 304, welcher in der Lage ist, solche Codestellen zu finden und somit der QA die Möglichkeit gibt, diese zu überprüfen und dem Entwickler, diese zu bereinigen.

 



@Virtual_Forge auf Social Media:

social_twitter_active.png social_xing_active.png social_linkedin_active.png social_google_active.png