Tracking-Info
Blog

+49 - 511 - 270 416 0

info@aldebaran.de

Wann ist Software-Sanierung sinnvoll?

Ursprünglich haben Sie ein kleines Programm zur Vereinfachung der Abläufe geschrieben und dies über Jahre weiterentwickelt, so dass es inzwischen wesentlich für Ihre Geschäftsabläufe geworden ist. Aber nun stellen Sie immer wieder fest „geht nicht“ oder „zu aufwändig“, wenn weitere Änderungen notwendig sind?

Das ist ärgerlich, aber ein Stück weit ein natürlicher Prozess, denn auch Software kommt in die Jahre: Sei es, dass die eingesetzte Technologie nicht mehr unterstützt wird und eine Migration erforderlich macht – oder der Code ist so gewachsen, dass bereits kleine Änderungen große Fehler an unerwarteter Stelle produzieren. Vielleicht war die Anwendung auch nur als kleines Tool geplant. Aber es funktionierte so gut, dass inzwischen immer mehr Funktionalitäten oder Schnittstellen gewünscht werden – die Umsetzung übersteigt allerdings die internen Kapazitäten oder Kompetenzen?

Wie auch immer der Hintergrund ist: Die gute Nachricht ist, dass wir einiges für Sie und Ihre Legacy Systeme (Altsysteme) tun können! Nach einer Analyse der Ist-Situation und neuen Anforderungen können wir Ihnen die Möglichkeiten zur Sanierung Ihrer Software aufzeigen.

Nehmen Sie Kontakt mit uns auf und wir schauen, wie wir Ihnen helfen können!


Was wir für Ihre Software tun können und wie

Im Folgenden zeigen wir Ihnen die häufigsten/typischen Handlungsfelder bei der Software-Sanierung auf:

I. Trennen von Code der Bedienoberfläche und der Geschäftslogik

Programmcode für die Bedienoberfläche sollte getrennt sein von Programmcode, der Geschäftsvorfälle implementiert. Durch diese Trennung wird eine zweischichtige Struktur erzeugt, was folgende Vorteile hat:

II. Modularisierung

Die Architektur sollte so beschaffen sein, dass zusammengehöriger Programmcode und Daten in Modulen zusammengefasst werden. Jedes Modul befasst sich mit einem abgegrenzten Aspekt (Separation of Concerns). Die Module sollten klar definierte, schlanke Schnittstellen aufweisen und keinen direkten Durchgriff auf enthaltene Daten zulassen. Durch diese Kapselung wird es möglich, Module getrennt voneinander zu entwickeln, zu testen und auch nötigenfalls auszutauschen.

Die Vorteile der Modularisierung sind:

III. Variablen und Konstanten

Globale Variablen sind eine häufige Fehlerquelle. Sie bergen die Gefahr, dass nicht genau definiert ist, wie und aufgrund welchem Anlass die Variable geändert wird und wo sie überall benutzt wird. Auch kann es in komplexer werdenden Programmen leicht zu einer Unklarheit über die Bedeutung einer globalen Variable kommen. Schließlich machen globale Variablen Programmcode schlecht les- und damit verstehbar.

Durch die Eliminierung globalen Variablen werden die verarbeiteten Daten so gespeichert, dass sie im Zugriff der Programmteile sind, die sie brauchen, nicht aber anderswo her.

Konstante Werte sollten im Programmcode an einer einzigen Stelle festgelegt und als Symbol definiert werden, anstatt sie zu wiederholen. Damit wird die Fehleranfälligkeit verringert.

Die Vorteile einer Eliminierung von globalen Variablen und die Einführung von Symbolen für Konstanten sind:

IV. Parameter und Rückgabewerte

Methoden und Klassen sollten per Parameter und Rückgabewerte miteinander Daten austauschen, anstatt globale Objekte oder globale Variablen zu benutzen. Auch sollten die übergebenen Werte nur das enthalten, was auch verwendet wird.

Die Vorteile der sauberen Datenkommunikation per Parameter und Rückgabewert sind:

V. Mehrfachen Code zusammenfassen

Programmcode sollte nicht kopiert werden. Wenn die gleiche Funktionalität an mehreren Stellen benötigt wird, so sollte diese Funktion in einem Modul ausgelagert und so von allen Stellen benutzbar gemacht werden („DRY“ Regel: Don't repeat yourself).

Durch die Zusammenfassung von mehrfachem Code ergeben sich folgende Vorteile:

VI. Datenbankzugriffe kapseln und sicher machen

Datenbankzugriffe sollten auf eine einheitliche Art gekapselt werden. Anstatt die Zugriffe an vielen Stellen im Code zu verstreuen, sollte es dafür spezielle Datenzugriffsmodule geben. Die Datenbankzugriffe sollten in Transaktionen gekapselt werden, um die Datenkonsistenz sicherzustellen. Es muss sichergestellt werden, dass in Datenbankzugriffen verwendete Werte nicht zu Sicherheitsproblemen durch z.B. SQL Injection führen – etwa durch die Verwendung von parametrisierten Datenbank-Statements.

Durch diese Maßnahmen wird erreicht:

VII. Fehlerbehandlung

Fehler sollten vom Programmcode unterschieden werden in

Für die Behandlung von Fehlern sollte das Sprachelement der Exception verwendet werden. Exceptions sollten nur da behandelt werden, wo sinnvoll reagiert werden kann – das ist in der Regel in der Bedienoberfläche.

Dadurch werden folgende Vorteile erreicht:

VIII. Logging

Das Programm sollte meist wichtige Ereignisse und, je nach Einstellung, auch andere Ereignisse, in einem einheitlichen Logfile festhalten.

Durch den Einbau von Logging wird Folgendes erreicht:

IX. Einführen von automatischen Tests für die Geschäftlogik (Unit Tests)

Die Geschäftslogik kann, wenn sie von der Bedienoberfläche getrennt ist (siehe Abschnitt I.), einzeln getestet werden. Idealerweise ist sie auch modularisiert (siehe Abschnitt II.). Diese Tests können automatisiert werden (Unit Tests).

X. Einführen von automatischen Tests für die Oberfläche (UI-Tests)

Die Bedienoberfläche und mit ihr das ganze Programm kann mit automatischen Tests ausgestattet werden. Dabei werden Benutzeraktionen simuliert. Auf diese Weise kann die gesamte Anwendung auf Herz und Nieren getestet werden.

Die Vorteile davon sind:

Weiterführende Links