Gliederung der Ausarbeitung von Edzard Höfig zum Thema ...
Gliederung der Ausarbeitung von Edzard Höfig zum Thema ...
Gliederung der Ausarbeitung von Edzard Höfig zum Thema ...
Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.
YUMPU macht aus Druck-PDFs automatisch weboptimierte ePaper, die Google liebt.
Reverse<br />
engineering<br />
Design Recovery (die Wie<strong>der</strong>gewinnung des Systementwurfs aus den vorhandenen<br />
Artefakten) ist dagegen kaum automatisierbar, da während des<br />
Wie<strong>der</strong>gewinnungsprozesses fachspezifisches Wissen mit in die hervorgebrachten<br />
Modelle einfliesst. Die durch das Design Recovery gewonnenen Abstraktionen gehen<br />
über jene hinaus, die ohne „Domänenwissen“ eines menschlichen Expertens aus<br />
dem System ableitbar wären.<br />
Refactoring<br />
Die Transformation eines Systems auf <strong>der</strong> gleichen<br />
Anfor<strong>der</strong>ungen<br />
Abstraktionsebene (siehe Abbildung 7) wird als<br />
‚refactoring’ o<strong>der</strong> ‚restructuring’ bezeichnet. Für die<br />
Design<br />
Durchführung <strong>der</strong> Neustrukturierung ist meistens kein<br />
Domänenwissen nötig, dadurch lässt sich dieser Prozess<br />
hervorragend automatisieren. Beim Refactoring bleibt<br />
Code<br />
das Systemverhalten nach außen unverän<strong>der</strong>t: Die<br />
Än<strong>der</strong>ungen sind lokal zu Objekten o<strong>der</strong><br />
Systemkomponenten und betreffen nicht die Umgebung<br />
Implementation<br />
des Systems. Refactoring bedeutet u.A.:<br />
� die Aufteilung <strong>von</strong> Klassen in spezifische und allgemein verwendbare<br />
Komponenten<br />
� die Verschiebung <strong>von</strong> Operationen in <strong>der</strong> Klassenhierarchie<br />
� das Säubern <strong>von</strong> Klassenschnittstellen<br />
� Die Neuformatierung <strong>von</strong> Quellkode mit dem Ziel <strong>der</strong> besseren<br />
Verständlichkeit 4<br />
Einige Refactoring-Ansätze sind geradezu trivial und unter Umständen sehr<br />
sprachnah: z.B. die Verschiebung <strong>von</strong> Variablendeklarationen an die Stelle, wo sie<br />
erstmalig benutzt werden.<br />
Für verschiedene Möglichkeiten des Refactorings gibt es bereits Beschreibungen in<br />
Form <strong>von</strong> Patterns 5 Abbildung 7) Refactoring<br />
.<br />
Reengineering<br />
Abstraktes System<br />
Altsystem<br />
Forward<br />
engineering<br />
Reuse<br />
Neusystem<br />
Abbildung 8) Reengineering<br />
Um ein bestehendes System neu implementieren zu<br />
können, ist es nötig alle drei vorgestellten Prozesse zu<br />
benutzen. Wie in Abbildung 8) dargestellt wird das<br />
vorhandene Altsystem in einem Reverse Engineering<br />
Schritt analysiert und damit in ein abstraktes System<br />
überführt, welches die Grundlage <strong>zum</strong> Forward<br />
Engineering eines Neusystems bildet. Vorhandene<br />
Komponenten werden nach Möglichkeit<br />
wie<strong>der</strong>verwendet, eventuell nachdem sie verschiedene<br />
Refactoring Schritte durchlaufen haben.<br />
Die Sammlung wie<strong>der</strong>verwendbarer Komponenten<br />
geschieht in einem Repository, das auch alle weiteren,<br />
nach Wichtigkeit gefilterten, Daten aus <strong>der</strong> Artefaktakquisition aufnimmt. Beson<strong>der</strong>s<br />
wichtig ist dabei die Aufnahme des Wissens und <strong>der</strong> Erfahrungen <strong>der</strong> User,<br />
4<br />
Dies läuft unter dem Begriff des ‚Pretty Printing’ und ist beispielsweise in guten Editoren werksseitig<br />
eingebaut .<br />
5<br />
siehe [Link II]<br />
7
Change language