Anwendungs-Modernisierung mit Design Recovery, Teil 3

20. September 2011 | Von | Kategorie: Software Development + Change Mgmt.

Eine der wichtigsten Aufgaben bei der Anwendungsmodernisierung ist die sinnvolle Wiederverwendung der extrahierten Designs der Altanwendung. Wir zeigen Ihnen, welche Möglichkeiten Sie dabei haben.

Es gibt noch eine andere Artikelversion, diese finden Sie hier.

Im letzten Teil dieser Artikelreihe beschäftigen wir uns damit, wie das neue Anwendungsgerüst mit Leben erfüllt wird, indem die Business-Logik in den Rahmen der neuen Anwendung übertragen wird.
Zum Thema Application Mapping auf IBM i sind in NEWSolutions erschienen:
Robert Cancilla: Gegenwart und Zukunft

  • Teil 1: Februar/März 2010
  • Teil 2: April/Mai 2010
  • Teil 3: Juni/Juli 2010

Robert Cancilla: Programme ändern Programme

Teil 1: August/September 2010
Teil 2: Oktober 2010

Robert Cancilla: Schätze in Legacy-Anwendungen finden

Teil 1: Dezember 2010
Teil 2: Januar 2011
Teil 3: Februar 2011

Robert Cancilla: Anwendungsmodernisierung mit Design Recovery

Teil 1: April 2011
Teil 2: Mai/Juni 2011

Hinzufügen der Business-Logik

In einem früheren Artikel dieser Reihe wurde bereits einmal beschrieben, wie man die Business-Logik aus dem RPG-Code einer bestehenden Anwendung extrahieren, indizieren und dokumentieren kann. Ein Ansatz wäre, diese dokumentierten Business-Regeln manuell zu den passenden Business-Logik-Klassen der modernen Anwendung hinzuzufügen. Dieser Ansatz ist jedoch nur in Fällen praktikabel, bei denen lediglich ein kleiner Teil der bisherigen Business-Logik wiederverwendet werden soll sowie für kleinere Programme, die nur wenig oder überhaupt keine Business-Logik enthalten, die über das hinaus geht, was bereits in der JSF-Seite, der JSF Bean und in den Datenbank-I/O-Beans enthalten ist. Ich möchte noch einmal darauf hinweisen, dass das, was ich hier als Beispiel für die Verwendung von JSF und Java beschreibe, genauso auch für .NET und sogar für moderne RPG-Anwendungen gilt.

Ein anderer, mehr praxisorientierter Ansatz, der bereits automatisiert wurde, ist das Refactoring interaktiver Programme bis zu einem Punkt, an dem nur noch die Verarbeitung der Business-Logik wiederverwendet wird. Natürlich muss das Refactoring mit einer Restrukturierung einhergehen, die das prozedurale Konzept in ein ereignisgesteuertes umwandelt. Auch diese Vorgehensweise ist sowohl für Java als auch für .NET und für moderne RPGLE-Komponenten verwendbar. Bei der ersten Modernisierungsarbeit sollte die Business-Logik-Bean als einzelne Klasse (Modul/Programm) erstellt werden, die alle modernen, ereignisgesteuerten JSF-Seiten versorgt, die das ursprüngliche Programm ersetzen. So entsteht eine wartbare Architektur, die moderne Codierungspraktiken einsetzt und trotzdem noch einige Referenzen zu den bisherigen Transaktionen beibehält. Abbildung 9 zeigt eine schematische Darstellung des Architektur-Mappings zwischen altem und neuem Entwurf am Beispiel eines einzelnen Programms.

Schlagworte: , , , , , , , , ,

Schreibe einen Kommentar

Sie müssen eingeloggt sein, um einen Kommentar schreiben.