CC-REPRINT. Objektorientiertes Reengineering. Harry M. Sneed CC GmbH, Wiesbaden

Transkript

1 CC-REPRINT Objektorientiertes Reengineering Harry M. Sneed CC GmbH, Wiesbaden Published in: Gesellschaft für Informatik, achausschuß 5.1 Management der Anwendungsentwicklung und -wartung im achbereich 5 Wirtschaftsinformatik

2 Copyright No part of this document may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying and recording, for any purpose without the written permission of CC GmbH. Information in this document is subject to change without notice and does not represent a commitment on the part of CC GmbH. This document and the referenced software described in this document is furnished under a license agreement or nondisclosure agreement. The document and the referenced software may be used or copied only in accordance with the terms of the agreement. It is against the law to copy the document or the software on any medium except as specifically allowed in the license or nondisclosure agreement. Copyright 2002 CC GmbH. All rights reserved

3 Harry M. Sneed CC GmbH, Wiesbaden Objektorientiertes Reengineering Bei dem Begriff "Reengineering" muß man unterscheiden zwischen "Business Reengineering bzw. Business Process Reengineering" und "Software Reengineering". Im ersten all handelt es sich um eine Reorganisation des Unternehmens bzw. der Geschäftsprozesse und ist in erster Linie eine rage der Betriebswirtschaft. Im zweiten all geht es um die Restrukturierung der Informationssysteme bzw. der Software und Daten. Dies ist eindeutig eine Aufgabe der Informatik. Allerdings sind diese beiden Disziplinen eng miteinander verzahnt, so daß keine ohne die andere möglich ist. 1. Objektorientiertes Business Reengineering Business Reengineering bedeutet so viel wie die Umstrukturierung eines Unternehmens mit dem Ziel der Effizienzsteigerung. Geprägt wurde dieser Begriff bereits Ende der 80er Jahre durch die Veröffentlichung von Hammer und Champy. Ihrer These zufolge könnte nur eine radikale Änderung der gesamten Aufbauorganisation zum gewünschten Erfolg führen. Parallel zu dieser revolutionären Lehre entstand eine zweite Lehrmeinung, die lediglich eine Optimierung der Geschäftsprozesse propagierte. Business Process Reengineering ist der Begriff für diesen Ansatz. Danach kommt es darauf an, nicht die Aufbauorganisation sondern in erster Linie die Ablauforganisation zu verändern. Die Effizienz des Unternehmens sollte durch die Straffung und vor allem durch die Rechnerunterstützung der einzelnen Geschäftsprozesse erhöht werden. Beide Lehren liefen auf eine Dezentralisierung der Unternehmen hinaus. Große, hierarchische Betriebe sollten in Netze unabhängig agierender Geschäftseinheiten umgewandelt werden. Jede Geschäftseinheit sollte so weit wie möglich autark sein und sich selber tragen. Damit folgt eine Delegierung der Entscheidungskompetenz auf die unterste Ebene. Die Geschäftseinheiten ähneln den Objekten in einem verteilten Softwaresystem. Sie haben einen abgesteckten Verantwortlichkeitsbereich mit wohldefinierten Schnittstellen Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 1

4 nach außen. Sie kapseln ihre Kompetenz bzw. ihr Wissen. Sie werden über Aufträge von außen gesteuert und sie verwalten sich selbst. Nach Robert Mattison's Buch "The object-oriented Enterprise" ist ein objektorientiertes Unternehmen eine lose Zusammensetzung verteilter und vernetzter Geschäftseinheiten, die jedoch gemeinsame Betriebsmittel und Dienstleistungen teilen. Die Geschäftsprozesse entsprechen unktionssequenzen bzw. Transaktionen, die sich wie ein roter aden durch die verteilten Objekte bzw. Geschäftseinheiten ziehen. Wie Softwareobjekte haben Geschäftseinheiten auch einen momentanen Zustand, der jederzeit abfragbar ist, z. B. Mitarbeiterzahl, Ausgaben, Einnahmen und Aufträge in Arbeit. Einzelne Geschäftseinheiten sind auch für bestimmte Geschäftsobjekte zuständig. Hier entsteht die Verbindung zur Software-Welt. Eine real existierende Geschäftseinheit verwaltet eine Menge Geschäftsobjekte und führt Operationen mit diesem Objekten aus. Sie kommunizieren mit Kunden und anderen Geschäftseinheiten über vereinbarte Schnittstellen - z. B. Auftragsformulare, Bestellbögen, Rechnungen und Überweisungen. Die Geschäftsobjekte, über die sie verfügt, sind auf ihren eigenen Rechneranlagen gespeichert und tauschen Nachrichten bzw. Informationen miteinander sowie mit entfernten Geschäftsobjekten fremder Geschäftseinheiten aus. Auch die Geschäftsobjekte haben einen Zustand, der sich ständig ändert, der aber zu einem bestimmten Zeitpunkt abfragbar ist. Der Wert eines Geschäftsobjekts wird durch die Information, die es beinhaltet, sowie durch die unktionalität, die es nach außen anbietet, bestimmt. Genau das gleiche trifft für die Geschäftseinheiten zu. Der Wert einer Geschäftseinheit wird zum Teil durch den Informationsinhalt und die unktionalität ihrer zugehörigen Geschäftsobjekte und zum anderen Teil durch das Wissen und die ähigkeiten ihrer Mitarbeiter bestimmt. Diesen Wert festzustellen, ist das Ziel einer Unternehmensanalyse. Auf jeden all ist es angebracht, wenn die Struktur des Unternehmens mit der Struktur ihres zugrundeliegenden Informations- und Kommunikationssystems übereinstimmt. Ist dieses objektorientiert, so sollte das Unternehmen ebenfalls objektorientiert sein. In letzter Konsequenz heißt dies, Verteilung, Kapselung und Vernetzung der Unternehmenskapazitäten mit dem doppelten Ziel, Managementoverhead und Administration zu minimieren und Eigenverantwortlichkeit zu maximieren. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 2

5 2. Objektorientiertes Software Reengineering Software Reengineering bedeutet die Transformation vorhandener Programme in eine andere orm mit dem gleichen Inhalt. Wesentlich ist dabei die funktionale Äquivalenz der neuen mit der alten Version, d. h. bei gleicher Eingabe muß die reengineerte Version die gleichen Ausgaben wie die ursprüngliche Version produzieren. Damit werden dem Transformationsalgorithmus enge Grenzen gesetzt. Es ist aber die einzige Möglichkeit, die Korrektheit der Transformation zu bestätigen. Als der Begriff Software Reengineering in den 80er Jahren geprägt wurde, ging es in erster Linie darum, die Programme zu strukturieren bzw. die GOTO-Verzweigungen zu entfernen. Später wurde das Ziel erweitert, um die Programme auch noch zu modularisieren bzw. in kleinere, getrennt aufrufbare Bausteine zu zergliedern. Weitere Ziele waren die Reformierung des Source- Codes zwecks besserer Lesbarkeit, die Auslagerung der I/O-Operationen in eine I/O-Schale und die Entfernung der Literale. Das Programm blieb jedoch noch in der gleichen Programmiersprache und im gleichen prozeduralen Programmiermodus. Das Ziel des klassischen Software Reengineerings war also in erster Linie die Steigerung der Programmwartbarkeit. Es sollte für die Wartungsprogrammierer leichter werden, die Programme zu ändern. Im ESPRIT-Metrik-Projekt wurde eine empirische Untersuchung durchgeführt, um nachzuweisen, inwiefern dies gelungen ist. Harry Sneed hat auf der internationalen Wartungskonferenz im Jahre 1990 darüber berichtet. Das Buch "Software- Sanierung" aus dem Jahre 1991 behandelt das gleiche Thema. Inzwischen haben sich die Ziele des Software Reengineerings jedoch geändert. Es geht jetzt weniger um die Wartbarkeit, sondern viel mehr um die Wiederverwendbarkeit. Vor allem geht es darum, prozedural strukturierte Programme in objektorientierte Programme umzuwandeln. Aus C wird C++ und aus COBOL wird OO-COBOL gemacht. Auch wenn die Programme nicht konvertiert werden, so sollten sie wenigstens kapselbar sein. Dies bedeutet auf jeden all eine Umstrukturierung. Objektorientiertes Software Reengineering ist demzufolge die Umstrukturierung der Programme, mit dem Ziel, sie in eine objektorientierte Architektur einzubinden. Dies könnte so aussehen, daß aus den prozeduralen Code-Abschnitten Methoden gemacht werden und daß aus Masken, Dateien, Datenbanken und Unterprogrammen getrennte Klassen gebildet werden. Dadurch wird das alte, prozedurale Programm wiederverwendet, um ein neues, objektorientiertes Programm mit der gleichen unktionalität zu erzeugen. Die Betonung liegt hier auf der gleichen unktionalität. Der Benutzer darf nichts merken. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 3

6 Die größte Schwierigkeit beim objektorientierten Reengineering ist die Identifizierung der Objekte im Source-Code. Die oben genannten Kandidaten - Masken, Dateien, Datenbanken und Unterprogramme - sind nur einige der vielen Objektkandidaten. Mehr über objektorientiertes Software Reengineering finden Sie im Buch "Objektorientierte Software-Migration" vom Addison-Wesley Verlag sowie im Buch "Objektorientiertes Reverse Engineering" von Gall und Kölsch im Oldenburg Verlag. Reprint aus Gesellschaft für Informatik,, achausschuß 5.1, Seite 4