Hallo, herzlich willkommen zur Vorlesung zum Abschnitt 5 der über Software-Re-Engineering.
Und bevor wir in diesen Kapitel einsteigen,
möchte ich kurz etwas dazu sagen, warum diese Strukturierung,
die Einteilung in Re-Engineering-Maßnahmen auf Quellcode-Ebene und oberhalb Quellcode-Ebene.
Die Bedeutung liegt darin, der Grund liegt darin,
dass Quellcode die Basis ist,
für die wir auf jeden Fall sicher haben,
für die wir, wenn wir Veränderungen am System vornehmen.
Das ist sozusagen die Bezugsbasis und oberhalb der Bezugsbasis
gibt es Möglichkeiten, das noch besser zu tun.
Lassen Sie uns kurz das mal anschauen zu den Fragen,
kommen wir später
Es geht zunächst erst mal um Ebenen von Re-Engineering Maßnahmen.
Wir haben hier eine Tabelle mit sechs, fünf Zeilen,
ja, und der eine,
die vierte davon ist oder die fünfte, ist,
ich fange mal da unten an,
Ja, und darüber, also das ist die Ebene,
auf der wir auf jeden Fall Veränderungen vornehmen.
Das können, das können, ja. Klassen sein.
Funktionen, Variablen, ja. Vielleicht sogar so etwas
wie Schleifen im Steuerfluss. Und darüber haben wir,
wir machen daraus jetzt eine kleine Tabelle.
Deswegen teile ich das
mal hier
Das ist voller die Ebene. Insgesamt kommen darüber, weitere drei Ebenen, Ebene.
Und wir schauen uns an, welche Bearbeitungsgegenstände es gibt.
Und oberhalb des Quellcodes haben wir irgendwie auf Entwurf oder Architektur.
Ich schreibe jetzt mal Architektur. Und das wäre,
da geht es meistens um Komponenten und Schnittstellen
Auf jeden Fall Verantwortlichkeiten,
also Aufgaben für die so eine Komponente
zuständig ist
Und das ist so eine Komponente, hat auch irgendwelche Qualitätseigenschaften,
so wie zum Beispiel besonders gute Wartbarkeit,
besonders gute Performance oder bestimmte auch durchaus Mängel Richtung Sicherheit oder so etwas.
Aber es gibt auch noch eine Ebene darüber und das
ist die Domäne mit Domäne, meine ich, Einsatzbereich.
Ein Gebiet, wo so etwas eingesetzt wird,
die Architektur, halt, da war es falsch,
dass ich merke gerade, da kommt ja noch was dazwischen.
Und zwar kommen erstmal
die fachlichen Anforderungen
Ja, und darüber kommt die Domäne. Gerade noch gemerkt,
ich hoffe, Sie konnten es noch korrigieren.
Also die fachlichen Antwortungen, das sind die Dinge,
die so eine Antwort durch so ein System erfüllen muss.
Das wären Geschäftsprozesse, Benutzerrollen
Fachliche Regeln und Benutzeroberfläche. Gui, ja? So,
und in der Domäne oben drüber, da gibt es
fachliche Eigenschaften wie so etwas, typischerweise gegliedert ist.
Eine Funktionenhierarchie von möglichen Funktionen in einer Domäne,
Schnittstellen oder eine Referenzarchitektur
Oh, das passt nicht mehr ganz hin, dass da immer mal ab.
Guck mal, sehen Sie das ja noch gerade so?
Ja, so, jetzt lassen Sie mich kurz etwas dazu sagen, was ich damit meine.
Äh, Änderungen gibt es auf allen diesen Ebenen,
ja, und das ist Und das genauso gibt es,
dass man einen guten Entwurf, eine gute Strukturen erreichen möchte,
ebenfalls auf einer Ebene.
Das heißt auch, Re-Engineering. Ja, und das führte,
das bedeutet letztlich, wenn wir Re-Engineering machen wollen,
dann müssen wir irgendwie versuchen, diese Quellcode-Ebene.
Das ist ja die Ebene, für die wir,
die hebe ich mal hervor, auf der wir letztlich das System bearbeiten,
weil häufig keine Modelle da sind, weil wir davon ausgehen können,
Quellcode ist immer da.
Und wenn wir jetzt Re-Engineering auf den anderen Ebenen machen wollen,
oberhalb, dann müssen wir die zurückführen.
Oder in Beziehung setzen
Ein Beispiel. Wir sind in der Versicherungsdomäne. Ja,
das wäre also die Versicherungsdomäne ist also das Gebiet für Software,
für Versicherungen. Versicherungen haben ein paar Kennzeichen, die sie
von anderen Systemen unterscheiden. Das wäre zum Beispiel zur Aufenthaltung,
dass wir relativ stabile Prozesse haben über viele Jahre,
die sich im Kern eigentlich nicht ändern. Gut,
das haben viele Antonomänen auch, dass wir viele Datenbestände haben,
die über viele Jahre erhalten werden müssen,
gerade in Lebensversicherungen denken sie sowas an 50 Jahre Laufzeit oder eine Rentenversicherung,
wo sie auch,
wo man als junger Mensch schon einzahlen kann und später doch
bis zum Alter etwas bekommen möchte
Da müssen die Daten lange verhalten, lange Stabilität.
Ja, also das sind Eigenschaften, die für die Domäne
der Versicherungssachen zutrifft. Dann gibt es typische Funktionen,
die in dieser Domäne üblich sind, typische Schnittstellen,
wie normalerweise, wie werden die Daten über Kunden,
die heißen dort Partner, wie werden die gespeichert.
Und da gibt es typische Architekturen, wie so ein System für eine Versicherung normalerweise aussieht.
Und wenn wir auf dieser Ebene etwas ändern wollten,
zum Beispiel eine neue, grundsätzliche Funktion hinzufügen,
dann müssten wir die versuchen,
abzubilden auf die fachlichen Anforderungen,
auf die Architektur von jedem System,
was es da gibt und wenn
eine Ende an den Quell kommt
Gut, also auf der Ebene der Domäne wird es,
betrachten wir Änderungen nicht, weil das wird schon relativ selten passiert.
Aber auf der Ebene der fachlichen Anforderungen,
das ist die häufigste Quelle von Änderungen, weil ganz häufig
zum Beispiel fachliche Regeln geändert werden sollen oder die grafische Benutzeroberfläche soll geändert werden.
Oder man will es, statt vorher von Sachbearbeiter im Haus,
wenn man das jetzt vom online machen lassen,
vom Kunden selbst die Daten zu pflegen oder von der Werkstatt gleich die,
vom Dienstleister gleich die Rechnung eintragen oder sowas.
Oder man möchte Geschäftsprozesse optimieren, Gemüte oder Änderungen
gegenüber nördlicher Neuen gesetzt
Regelungen. All diese fachlichen Aufgaben müssen am Ende
im Quellcode stattfinden. Wir müssen im Quellcode umgesetzt werden.
Dazu muss ich zunächst in der Architektur die entsprechenden Komponenten finden,
die Schnittstellen finden, in denen ich da etwas tun muss.
Und dann muss ich entsprechend Änderungen, Klassenfunktionen, was auch immer, vornehmen.
Dieser Bezug ist deswegen so wichtig und das bringt uns dazu,
zum ersten Kapitel, hier zum ersten Abschnitt von 5, nämlich Trasibility.
Und lassen Sie mich noch etwas zur Situation in der Realität sagen,
zur Situation in Projekten. So ist das häufig so,
dass schon, gerade wenn agil entwickelt wird,
Leute sich Mühe geben, gute Strukturen zu entwickeln.
Aber trotzdem haben wir einen Zeitdruck. Wir haben durchaus Mitarbeiterfluktuation.
Wir haben die Situation, dass man nicht alles überblickt.
Und dann kommt es eben dazu, dass tatsächlich sowohl auf
der Quellcode als auch auf der Architekturebene Umstrukturierungen da notwendig sind.
Manchmal macht man Umstrukturierungen auch auf Ebene fachliche Antwortungen. Also das sind solche Re-Engineering-Maßnahmen,
die auf allen Ebenen passieren können, um Dinge zu beheben,
um Dinge glattzuziehen, um Dinge in der Struktur zu verbessern,
zum Beispiel die Verständlichkeit oder die Einheitlichkeit.
Oder selbst bei fachlichen Antwortungen möchte man das anpassen,
an einen Standard in der Branche
oder sowas
So, und wir brauchen immer diese Bezüge. Ein weiterer Punkt,
den wir, den wir unbedingt erwähnen müssen,
wenn wir oberhalb von Rengineering-Maßnahmen oberhalb vom Quellcode sprechen,
also auf dieser Ebene, meistens fachliche Anforderungen und Architektur,
ist, dass wir davon ausgehen müssen,
dass die Dokumentation dazu nicht vollständig ist.
Das hat zum einen damit zu tun,
dass man sich beim Dokumentieren auf das fokussiert,
was gerade relevant ist oder was man Notwendigkeit hat festzuhalten und das kann
zehn Jahre später eine andere Sicht erfordern oder mit sich bringen,
dass man etwas anderes gut findet.
Aber es kann auch sein, dass man man diese Dokumente nicht vollständig hat.
Also entweder man fokussiert sich auf bestimmte Sachen, hat dadurch das
nicht vollständig oder es fehlt einfach das, was unwahrscheinlich.
Und da unaktuell. Und deswegen müssen wir das jeweils immer hier
auf den Quellcode beziehen, weil der Quellcode ist ja bekanntermaßen lauffähig,
sonst würde das System nicht im Einsatz sein.
Also das, deswegen ist dieses in Beziehungssätzen zum Quellcode hier ganz wichtig.
Das Wort Quellcode kann man hier immer noch in ihren Sichtbarkeitsabschnitt schieben.
So, Ja, also das wollen wir, das wollen wir erreichen.
Und diese Verknüpfung, das ist unser erstes Thema Trasibility.
Ups. Ich möchte ja eigentlich wieder eins weiterschieben. Ja,
also ich möchte zunächst drüber sprechen, was ist Trasibility?
Und dann, was wir mit den Modellen machen können.
So, das war der Abschnitt 5.1, Trasibility.
Preis von Trace, die Spur, Trasibility,
da geht es um Nachverfeuerbarkeit
Das ist mit Verzwischenung, Verknüpfungen zwischen Artefakten.
Im Lebenszyklus zum Beispiel Anforderungen, Entwurf, Entwurf Implementierung.
Zwecks Nachverfolgung, das ist das, was wir erreichen wollen.
Wir haben häufig als Gegenstand, als Trigger für Änderungen,
Änderungen auf den oberen Ebenen. Ich zeichne das nochmal hier. Ja,
also wir haben eine Änderung, die auf fachliche Antwortungen sich bezieht.
Und jetzt hätten wir gern eine Verbindung und sagen,
welche Komponente ist denn für einen Geschäftsprozess zuständig.
Und wenn wir von den Komponenten haben, wollen wir wissen,
welche Klasse daraus ist für ein Dings zuständig. Und deswegen haben wir hier,
ich habe hier gleich die Pfeile reingeschrieben, ja,
also wir haben einfach eure Trasibility-Links zwischen Anforderungen und Entwurf,
Entwurf und Implementierung.
Sie können durchaus das deutsche Wort benutzen, Nachverfolgbarkeit.
Das ist erstmal die Eigenschaft und diese Verbindung werden häufig
als Links bezeichnet. So, wozu brauchen wir Trasibility?
Das ist die Definition Wozu benötigt zum einen um Verknüpfungen,
die zwischen den unterschiedlichen Ebenen herzustellen?
Wir stellen so
das heißen
Das ist das Erste, was wir erreichen wollen.
Und das Zweite ist, dass wir diese Links dann
M-Ende nutzen, um das verstehen zu können.
Verstehen, nachverfolgen oder Vollständigkeitsprüfung
Ja, also wir wollen erreichen,
dass wir Anforderungen in Bezug setzen können zu dem System,
dass wir also verstehen, was wozu Komponenten da sind.
Das ist der eine wichtige Punkt.
Und der zweite wichtige Punkt ist, dass wir schauen,
ob jede Anforderung irgendwo in einer Komponente umgesetzt wird.
Es geht dabei um die Ebenen, die wir oben schon bestehen haben.
Einforderungen, Entwurf und Entwurf, Implementierung. So,
dabei hilft uns die Möglichkeit, solche Links irgendwie sichtbar zu machen,
damit wir dies verfolgen und die Prüfung auf Vollständigkeit machen können.
Ich gebe ihr noch jeweils ein Beispiel für das Verstehen.
Was ist die fachliche Aufgabe einer Komponente
Für das Nachverfolgen Wäre das jetzt,
dass wir prüfen,
woraufhin wirkt sich
eine Änderung aus
Ja, und das dritte, die Vollständigkeitsprüfung,
wie kriege ich das jetzt hier nach vorne?
Vielleicht am besten mit einer anderen Farbung.
Sind alle Anforderungen umgesetzt
Diese Links ermöglichen uns diese Beantwortung dieser Fragen,
ist total toll, weil ihr uns Sicherheit gebt,
dass wir alles richtig gemacht haben,
dass wir die Sicherheit bei der Entscheidung, was überhaupt betroffen ist,
wo etwas zu tun ist und überhaupt den Überblick zu gewinnen.
Hervorragend, oder? Das kleine Problem ist,
dass das Aufstellen solcher Links hohen Aufwand erfordert.
Und gleichzeitig ist es so, dass die Links uns nur helfen,
wenn wir die vollständig haben und widerspruchsvoll.
Nein, wir brauchen eine neue Seite
Lassen Sie uns eine kurze Bewertung des Konzepts Trasibility
Links vornehmen.
Diese Links sind sehr hilfreich
Und zwar insbesondere dann, wenn Sie vollständig sind,
das ist der große Punkt. Ja,
also wenn wir wissen, da fehlen 30 Prozent der Links,
dann hilft uns eine Aufwandsschätzung nicht richtig viel und eine Vollständigkeitsprüfung
würden wir auch nicht machen können
Und Werkzeugunterstützung ist uns eine große Hilfe, wenn es
darum geht, solche Anforderungen auszuwerten, solche Trisibilitien auszuwerten.
Gleichzeitig müssen wir sagen, dass es einen hohen Aufwand erfordert,
diese Links von Hand zu erstellen
Und das Gleiche trifft auf die Prüfung zu. Wenn wir verstehen wollen,
ob jede Anforderung durch ein Hochselement abgedeckt wird,
dann müssen wir den Gesamten aller Antwortungen verstehen und den gesamten Entwurf verstehen.
Das ist das, was wir hier in dem Bild hatten. Ja,
also wenn wir solche Verknüpfungen haben wollen, wollen die prüfen,
ob sie das tatsächlich tun, dann müssen wir das ganz verstehen.
Das ist ein kritischer Punkt, der wirklich schwierig ist. Und wenn wir,
schwierig ist ja deswegen, wir schreiben noch zusätzlich hin,
Und die Prüfung der Links erfordert ebenfalls einen hohen Aufwand.
Diesen Aufwand etwas zu verringern, könnten wir auf die Idee kommen,
Werkzeuge einzusetzen. Die Unterstützung durch Werkzeuge könnte eben darin bestehen,
Dass wir Vollständigkeitsprüfungen durchführen mit Hilfe von Werkzeugen,
das wäre ein wichtiger Punkt
. . .