1                  Einleitung Der Wechsel allein ist das Beständige. Arthur Schopenhauer   Das Brockhaus-Lexikon definiert Evolution als eine "langsam, kontinuierlich fortschreitende Entwicklung". Auch Software-Systeme sind einer kontinuierlichen Fortentwicklung unter­worfen. Für einzelne Anwendungen ist es eine akzeptierte Tatsache, daß sie nicht einmal geradlinig entwickelt und fortan unverändert eingesetzt werden können. Doch wie stellt sich die Situation für Frameworks dar ? Können sie eine solide und vor allem stabile Basis für Anwendungen sein, oder sind auch Frameworks einer Evolution unterworfen ? Und wenn sie einer Evolution unterworfen sind, wie kann man mit ihr umgehen ? 1.1          Ausgangspunkte und Aufbau der Arbeit Im Rahmen einer Kooperation zwischen dem Softwaretechnik-Center des Fachbereichs Informatik der Universität Hamburg und der Firma Micrologica Computersysteme GmbH, Bargteheide, hatte ich Gelegenheit, die langjährige Erfahrung von Micrologica im Telefonie-Bereich in ein Framework zur Steuerung von Telekommunikationsanlagen (Tk-Anlagen) umzusetzen. Anhand der Entwicklung dieses Frameworks habe ich auch viele Erfahrungen gemacht, die sich auf die Evolution von Frameworks beziehen. Da die Evolution von Frameworks noch ein offenes Forschungsthema ist, möchte ich in dieser Arbeit die Erfahrungen und meine Schluß­folgerungen daraus vorstellen. Die wenigen Publikationen, die es in diesem Bereich gibt, habe ich als "Absicherung" verwendet, um zum einen einen breiteren Blickwinkel zu bekommen, auch auf Aspekte, die bei meiner konkreten Arbeit nicht aufgetreten sind. Andererseits dienen sie mir als Indiz für die Übertragbarkeit meiner Erfahrungen auf andere Frameworks. Besonders beeinflußt wurde diese Arbeit von dem Artikel von Roberts und Johnson, in dem sie in einer Mustersprache beschreiben, welche Evolutionsschritte ein reifendes Framework in einer idealisierten Evolution durchmachen kann (siehe [RobJohn 96]). Hierauf aufbauend möchte ich den Gründen nachspüren, die bei der Framework-Konstruktion die Basis für Art und Umfang der Evolution legen. In Kapitel 2gebe ich zunächst einen Überblick über die Begriffe und Techniken, die bei der Konstruktion von Frameworks verwendet werden und den Begriff der Framework-Evolution definieren. Dieses Kapitel soll die begrifflichen Grund­lagen für die weitere Diskussion legen. Dann beschreibe ich in Kapitel 3 den Anwendungsbereich der Telefonie-Systeme und erläutere, welche Probleme mit dem erstellten Framework gelöst werden sollen. Die hier vorgestellten Eigenheiten der Telefonie werden in den weiteren Kapiteln immer wieder als Ursachen für diverse Evolutionsschritte eine Rolle spielen. Im Anschluß daran wird in Kapitel 4 ein grober Überblick über das erstellte Framework gegeben. Um das Verständnis dieser Kapitel zu erleichtern, enthält Anhang B ein Glossar der verwendeten Telefonie-Begriffe. Einige Evolutionsschritte des Telefonie-Frameworks werden in Kapitel 5exemplarisch vorgestellt und ihre Ursachen und Auswirkungen diskutiert. Aus diesen Erfahrungen werde ich dort, wo es möglich ist, Folgerungen ableiten, die auch auf andere Frameworks übertragbar sind. Eines der wichtigsten Ergebnisse dieser Arbeit wird in Kapitel 6vorgestellt. Ausgehend von den Erfahrungen mit der Evolution des Frameworks bin ich zu einer Strukturierungs-Technik für Frameworks gekommen, der "Partitionierung". Diese Technik ähnelt dem "Layering" von Frameworks, wie es beispielsweise in [BGKLRZ 97] vorgeschlagen wird, ist aber durch konkrete Konstruktionstechniken und Strukturierungsrichtlinien angereichert. Kapitel 7 zieht ein Resümee der Arbeit und gibt einen Ausblick auf zukünftige Entwicklungen. In Anhang A ist die verwendet Literatur aufgeführt. 1.2          Verwendete Notationen Für Klassendiagramme wird eine an [GHJV 95] angelehnte Notation verwendet:   Klasse Klasse mit Methoden (vMethodB ist abstrakt) Klasse mit Methoden und Attributen Abbildung 1: Notationen für Klassen   Vererbung Benutzung Methode mit Implementation (Pseudocode) Abbildung 2: Beziehungen zwischen Klassen Zur Darstellung der Kommunikation zwischen Prozessen werden einfache Interaktions­diagramme in der Art von Abbildung 3 verwendet. Da es sich um (gepufferte) asynchrone Kommunikation handelt, muß nicht dargestellt werden, wo der Kontrollfluß verläuft - er wird durch diese Kommunikation nur indirekt beeinflußt. Abbildung 3: Interaktionsdiagramm Die meisten Beispiele mit Quelltext in dieser Arbeit folgen der bei Micrologica durch Qualitäts­richtlinien [Koschek 95] vorgeschriebenen Form der ungarischen Notation. Es werden folgende Präfixe für Namen verwendet (auszugsweise):   oc Klassentyp (object class) o Exemplar einer Klasse (object) p Pointer v Void i Integer b Bool Abbildung 4: Namenspräfixe 1.3          Danksagung Ich möchte mich bedanken bei der Firma Micrologica Computersysteme GmbH und allen Mitarbeitern, die mich durch viele Gespräche und ihre konstruktive Zusammenarbeit bei der Erstellung des Telefonie-Frameworks unterstützt haben. Mein weiterer Dank gilt Prof. Heinz Züllighoven und Dr. Walter Bischofberger für die Betreuung dieser Diplomarbeit. Insbesondere danke ich auch Wolfgang Strunk für unzählige erhellende Diskussionen und Thomas Pfohe für die Mitarbeit bei der Erstellung des Telefonie-Frameworks.