Frameworking

Firma X hat ein Produkt „OLDSYS", eine Kombination aus Software und Hardware für Belegverarbeitung in verschiedenen Branchen.

Aufgaben von OLDSYS:

Das Paket ist sehr erfolgreich, hat aber einige Eigenschaften, die bereits jetzt oder in absehbarer Zukunft zu enormen Problemen führen werden, nichts zuletzt auf Grund der gestiegenen Kundenzahl. Das Kontrolling der Produkte findet kaum statt. Es ist nicht transparent welche Produktfehler in welchem Umfang durch die Servicegruppe abgefangen werden. Entwicklern gelingt es immer wieder, Unzulänglichkeiten der Software auf die Servicegruppen abzuschieben. Die Servicegruppen sind hoch motiviert und haben ein ausgesprochenes „Just do it" Denken.

Eigenschaften von OLDSYS:

Trotz des Erfolges sieht das Management einige technische und soziale Probleme, die zum Wunsch nach einem Redesign von OLDSYS führen.

Problem mit OLDSYS aus der Management Sicht:

Konventionelle Software degeneriert im Laufe der Zeit. Durch notwendige Änderungen und Erweiterungen wird die ursprünglich saubere Struktur zerstört.

Alles dies veranlasst das Management über ein neues Produkt „NEWSYS" nachzudenken. Zwei grundlegende Richtungen bestehen:

Die Entwickler des alten Systems bevorzugen den Gedanken der Weiterentwicklung. Die Geschäftsleitung – beunruhigt durch die bereits deutlich längeren Releasezyklen des alten Systems – entscheidet sich für die Neuentwicklung mit Integration von Komponenten des alten System. Dazu wird ein völlig neues Team angeworben und in der Firma installiert. Die Mitglieder des neuen Teams verfügen über keine Branchen- oder Domainkenntnisse und sehr unterschiedliche OO-Kenntnisse.

In einigen anfänglichen Meetings wird versucht mit einer Gruppe von älteren und neueren Mitarbeitern ein Anforderungsprofile für NEWSYS zu entwickeln. Die Vorschläge der älterne Mitarbeiter sind sehr konkret und detailiert, beziehen sich aber im wesentlichen auf inkrementelle Verbesserungen des bestehenden Systems. Der Prozess schläft nach einigen Monaten ein und wird anschliessend fast selbständig im Team von NEWSYS durchgeführt. Bereits nach kurzer Zeit tritt eine Isolierung des NEWSYS Teams auf, die sich im Laufe der Zeit noch verstärkt, nicht zuletzt durch den Entschluss ein Framework zu bauen. Die Applikationsgruppen stehen dem Projekt zu Anfang wohlwollend gegenüber, nicht zuletzt auf Grund persönlicher und technischer Probleme mit der OLDSYS Gruppe.

Anforderungen an „NEWSYS":

Nach den vernichtenden Ergebnissen des Protoypen entschied sich das NEWSYS Team auf ein Framework Design umzusteigen. Zum damaligen Zeitpunkt gab es praktisch keine verfügbaren Frameworks die man hätte kaufen können.

Die Geschäftsleitung lehnte den sofortigen Einsatz von CORBA (Orbix) ab (zu teuer, Zeitaufwand bei Einarbeitung, zunächst kein distributed computing geplant). In der Folge mussten vom NEWSYS Team wesentliche Broker-Mechanismen selbst implementiert werden. Grob geschätzt gingen in einem Zeitraum von 12 Monaten 80% der Zeit in die Grundlagenentwicklung.

Zur objektorientierten Applikationsprogrammierung ist eine Systembasis nötig, die in C++ nicht vorhanden ist. Lebenswichtige Services müssen entweder selbst entwickelt oder eingekauft werden. 80% der Arbeiten im ersten Jahr sind Grundlagen Technologien.

Eine überraschende Erkenntnis nach der Analyse der physischen Eigenschaften von C++ war, dass die Trennung von Interfaces und Implementationen ein Broker Konzept erzwingt, AUCH wenn die Applikation nur lokal laufen soll.

Zum Zeitpunkt der Entscheidung gab es keinerlei Erfahrung über die Zeitdauer einer Framework Entwicklung. Von Seiten der Applikationsgruppen kam Widerstand, da dort ein Toolkit mit feststehendem API erwartet wurde. Das NEWSYS Team stand somit vor dem Problem, dass einerseits (Geschäftsleitung) ein sehr flexibles System erwartet wurde, andererseits (Applikationsgruppen) ein festes API mit festen Implementationen vorausgesetzt wurde. Hinzu kam, dass die Grundprobleme von C++ (statisches Linken, keine Interfaces) nur schwer vermittelbar waren.

Hohe Kompetenz von Applikationsentwicklern hilft wenig beim Kampf mit Systemstrukturen der Applikation bzw. der Programmiersprache. Lifecycle Betrachtungen sind ebenfalls oft ein fremdes Konzept.

In der Folge stellte sich auch heraus, dass der zentrale Gedanke eines Frameworks: neue Funktionalität durch das Austauschen von „Puzzleteilen" zu erreichen von den Applikationsgruppen nicht mitgetragen wurde. Für die NEWSYS Gruppe war das Framework in erster Linie ein funktionaler Rahmen der Erweiterbarkeit mit bewussten Leerstellen. Für die Applikationsgruppen waren die Leerstellen nicht Möglichkeiten der Erweiterung sondern einfach mangelnde Funktionalität. Dieser Konflikt endete damit, dass die Mitglieder der Framework Entwicklung auch die Applikationen auf Basis des Frameworks entwickelten. Es hatte sich eine unüberbrückbare technische, sprachliche und kulturelle Kluft ergeben.

Ein in diesem Zusammenhang immer wieder aufgeführtes Argument war das des „Pragmatismus". Abstraktionen oder Reengineering wurde abgelehnt mit dem Hinweis, man sei ja „Pragmatiker". Im Laufe der Zeit wurde klar, dass damit eigentlich etwas ganz anderes gemeint war:

Pragmatismus in Software Projekten wird oft als Ausblenden der Lifecycle Problematiken verstanden. Wenn überhaupt Probleme erkannt werden (Softwäre wächst, Wartung und Installation) werden sie nach hinten verschoben.

Beispiel:

Die meisten „alten" Mitarbeiter neigten zu sehr langen Methodenrümpfen. Häufig versuchten sie lediglich bestehenden Code in neuen Klassen wiederzuverwenden. Restrukturierung und Faktorisierung des Codes wurde abgelehnt. Derartige Klassen sind nicht wiederverwendbar und nur schwer zu warten.

Sehr lange Methodenrümpfe sind ein typisches Kennzeichen von ehemaligen C Programmierern die versuchen, alten Code und alte Methodik im OO-Bereich weiter zu verwenden. Diese Methoden machen Klassen nicht wiederverwendbar und können nur global überschrieben werden. Die Methodenlänge ist durchaus als empirisches Kennzeichen des OO-Entwicklungsstandes im Projektmanagement verwendbar.

In einem mehr oder weniger bewussten Prozess entstand in den Monaten nach dem Prototypen ein Framework. Die weiter unten beschriebenen Strukturen sind eine Sichtweise aus dem Nachhinein!

Viele zentrale Design Pattern wurden aus FRESCO [LINTON] übernommen. Das Ergebnis ein Framework das das logische Modell der Trennung in verschieden Domains um weitere Dimensionen (im folgenden „Strukturen") erweiterte.

Ein Framework ist die Realisierung (im Sinne der UML 1.0) einer „Evolving System" Meta Architektur, die ein Produkt in seinem ganzen Lebenszyklus (Entwurf, Entwicklung, Erweiterung und Spezialisierung, QA, Installation, Konfiguration, Kunden, Wartung etc.) betrachtet. Diese Architektur ist das krasse Gegenteil einer „pragmatischen" Sichtweise, die vor den unvermeidlichen Änderungen eines Systems die Augen verschliesst.

Im Prozess der Realisierung eines Frameworks hebt sich die Trennung zwischen Applikationsentwicklung und Grundlagenentwicklung auf. Mitglieder eines Frameworkteams müssen während der Arbeit umschalten können. Dies stösst bei manchen auf grosse Probleme im Selbstverständnis.

Es wurde bereits erwähnt, dass object creation einer der gravierendsten cold spots eines Systems ist. Dies erklärt sich dadurch, dass im Moment der Instanziierung mehrere Strukturen des Frameworks gleichzeitig beteiligt sind:

Cold Spot Analyse ist die Untersuchung eines Mechanismus daraufhin, welche Teile davon so festgelegt sind, dass sie OHNE Source Code Änderung nicht modifiziert werden können und worin diese Abhängigkeiten bestehen. Cold Spot Analyse verändert das WER, WANN, WELCHE und WIE und untersucht die Konsequenzen auf die logische, physische, runtime und extension sowie die Sourcecode-Struktur.

Wem die folgende Analyse übertrieben erscheint, hat noch nie eine grössere OO- Applikation mit C++ entwickelt.

Ausserhalb eines Framework Konzeptes entsteht bei der Arbeit mit C++ schnell eine fast paranoide Furcht vor Änderungen. Notwendige Verbesserungen im Design unterbleiben weil sie Auswirkungen auf viele Stellen des Source Codes hätten und ausserdem eine Reinstallation erzwingen würden.

Beispiel: Object creation cold spots und ihre strukturelle Dekomposition

X.hpp/cpp

#include <Z.hpp>

#include <Y.hpp>

#include <G.hpp>

Class X {

private:

G myG;

Y myY;

public:

DoIt () {

Z myZ = new Z();

..}

}

Eine multidimensionale Dekomposition zeigt, dass dieses harmlos aussehende Stückchen Source Code MEHRERE cold spots enthält, die verschiedene Strukturen betreffen, z.B.:

C++ unterstützt das Konzept sich entwickelnder Systeme nur ganz gering. Mit wenigen Statements werden physische Abhängigkeiten geschaffen ohne dass dies sofort bemerkt wird. Low Level Implementationsdetails der Programmiersprache beeinflussen das Applikationsdesign. Der ohnehin recht statische Charakter von Klassifizierungsystemen (und nichts anderen sind Klassenhierarchien) wird durch die Programmiersprache noch verstärkt.

Das nächste Beispiel zeigt einen typischen Framework Code in C++. Der Code versucht die eben angesprochenen Probleme zu umgehen.

SyPNContainerDoc.hpp/cpp

// Copyright, usage

// RCSid etc.

// InterfaceVersionID ALL automically generated!!!!!!!!!!!!!!!!!!!!!!!!!

#ifndef SYVDSTORAGEMANAGER_HPP

#include <SyVDStorageManager.hpp> // Storage Manager Interface from Data management Domain

#endif // include protection, reduces build time, generated automatically

#ifndef SYVPDOCPART_HPP

#include <SyVPDocPart.hpp> // Document Part Interface from Problem Domain

#endif

DeclareNormalImplementationClass(SyPNContainerDoc) // macro for reference types and

// smart pointers, declares an implementation for

// a Systor Interface

// the class declaration is a macro that sets platform dependent export/import statements

// depending on the PACKAGE declaration (SBV_Customer is set during build).

// The macro also generates meta class information.

// the comment uses a tag for automatic class reference generation

//- SyPNContainer

SyNClass1(SyPNContainerDoc, SyVPDocPart, SBV_Customer)t

//. This class provides a simple container for document

//. Parts .......

//. Design Patterns: composite object

//. preconditions, postconditions, warnings

{ // this macro will cover anything that is necessary in class declaration (e.g.

// class meta information etc.

NormalImplementationInDeclaration(SyPNContainerDoc)

public addChild(SyVPDocPart_ref) { } Any document part can become a member now, not just Y

doIt () {

// use configuration to find which class to use (could be a pattern for a trader too)

String_ref StorageManagerName = (Broker->lookup(„StorageManager");

// use Broker to get factory to get StorageManager. ONLY interfaces are known by X!

// use tmp macro to count down ref count on returned temporaries

SyVDStorageManager_ref = _tmp(Broker->DMCKit())->StorageManager(StorageManagerName);

..}

private:

G myG; // This is OK if and ONLY if G is declared and implemented IN THE SAME

// physical package as this source file!!!!! (component level insulation)

}

Das Beispiel sieht zunächst ziemlich kompliziert aus allerdings können die meisten Statements automatisch generiert werden. Wesentlich ist die „Künstlichkeit" des Source Codes, die aus der Anwendung von Coding Conventions stammt, die die Trennung der physischen Strukturen sicherstellen.

C++ Code innerhalb eines Frameworks stützt sich stark auf generative Mechanismen, oft als Macros implementiert. Der Code ist hoch ritualisiert und geregelt. Die Entwickler müssen durch kleine Tools unterstützt werden. (NEWSYS beinhaltete z.B. einen Source Code Generator der Templates von Header Files, Implementations Files, Funktionen oder Applikationen erstellte).

Ein C++ Framework braucht umfangreiche Coding Standards die NICHTS mit der Optik des Source Codes zu tun haben. Die Coding Standards beinhalten das gesammelte Design Wissen des Framework Teams. Fremde Benutzer MÜSSEN diese Standards ebenfalls einhalten.

Die tatsächliche Komplexität der dahinterliegenden Macros und Mechanismen wird nicht sichtbar, ihre Kenntniss ist aber auch durch Tools nicht ersetzbar. Programmierer brauchen tiefe System- und Plattformkenntnisse.

Zur Bedeutung von Coding Standards siehe Kapitel Coding Standards.

Bevor in den folgenden Abschnitten die Strukturen eines Frameworks im Einzelnen behandelt werden hier noch das Beispiel von oben als Java Source:

/* SyPNContainerDoc.java

* Copyright, usage

* RCSid etc.

*/

package systor.doc.Implementations

import java.*

import systor.doc.* // document interfaces

import systor.broker.* // broker and factory interfaces

/**

*implements a container part for systor document parts by extending the interface class for document parts

*This class provides a simple container for document Parts

* Design Patterns: composite object

* preconditions, postconditions, warnings

*/

class SyPNContainerDoc implements SyPVDocPart

{

/**

* any doc part type can be added to this container doc part

*/

public addChild(SyVPDocPart) { }

/**

*method uses configuration information and broker and storage manager interfaces

*in a generic way.

*/

public doIt () {

String StorageManagerName = Broker->lookup(„StorageManager");

SyVDStorageManager myMngr = Broker->DMCKit()->storageManager(StorageManagerName);

..}

private G myG();

// a version identifier for evolving classes, see java serialization ap.

// generated by a serialver (do not confuse with source code id!):

static final long serialVersionUID = 1234567890123456L;

}

Dieser Java Source Code sieht weniger kompliziert aus als die C++ Version. Er enthält jedoch MEHR Funktionalität (eingebaute automatische Dokumentation, garbage collection) und hat durch das dynamische Linken nicht das Problem der „fragile superclass" bei dem nachträgliche Änderungen an Basisklassen umfangreiches Recompilieren und Linken aller abgeleiteteten Klassen erzwingt.

Bei Interface Änderungen sind die turn around Zeiten DRASTISCH kürzer als im C++ Fall, etwas das das verbesserte C++ Beispiel oben noch gar nicht berücksichtigt.

Die Mechanismen dahinter die der Programmierer verstehen muss sehen nicht nur weniger kompliziert aus, sie sind es auch. Mit anderen Worten: Die Integration von Teammitgliedern wird schneller gehen.

Noch wichtiger als die physischen Aspekte der Programmiersprachen ist jedoch die folgende Erkenntnis: Die Design Patterns „Broker" und „Factory" sind in Java nicht weniger wichtig als in C++. Sie sind nur leichter zu erzeugen und zu warten. Durch die weniger komplexe physische Struktur erlaubt es Java sich auf die logischen Strukturen und Design Patterns zu konzentrieren.

In diesem Fall bedeutet dies: Der Client braucht nicht die Implementation der Objekte zu kennen, mit denen er arbeitet. Kunden können Klassen spezialisieren und der Client wird ohne Änderung mit den neuen Klassen arbeiten können. Dieselben Pattern erreichen das gleiche Ziel in C++, nur dass sie dort noch zusätzliche Sprachprobleme lösen.

In Java ist die Behandlung physischer Eigenschaften leichter. Die logischen Strukturen, z.B. das Verstecken von spezifischen Objektimplementationen hinter Broker und Factories bleiben gleich. Die hot spots die ein Evolving System braucht werden durch die gleichen Design Patterns wie in C++ erzeugt. Braucht es noch mehr Gründe für einen an Design pattern orientierten Entwicklungsprozess?

Als ich noch ein blutiger Anfänger in der Unix Kernel Division der Siemens AG war und Device Treiber für die damals neuen Multiprozessor Systeme entwickelte, habe ich einmal einen sehr erfahrenen Freund bei Sequent gefragt, was man ein Multiprozessor System baut. Seine Antwort lautete: „Das ist ganz einfach, man muss nur alle globalen oder statischen Variablen mit Locks vor gleichzeitigen Zugriffen schützen." Die Kunst besteht natürlich darin, dies mit Hilfe von spezieller Hardware und geschickten optimierten Algorithmen so zu tun dass n Prozessoren auch ungefähr die n-fache Systemleistung erbringen.

Analog dazu bring Ken Birman distributed computing auf einen Punkt: es ist eigentlich trivial. Das Problem liegt nur darin auf zwangsläufig auftretende Fehler (Hardware,Software,Bedienung) so zu reagieren, dass Reliability und Security gesichert sind und die Performance noch akzeptabel bleibt.

In diesem Sinne definiere ich ein „Frameworking" als das Berücksichtigen aller Abhängigkeiten innerhalb eines Softwaresystems über den gesammten Lebenszyklus hinweg. Die Aufgabe besteht darin, diese Abhängigkeiten und deren Konsequenzen zu erkennen und Techniken zu entwickeln, die ein Degenerieren des Systems verhindern. Und die Kunst ist es, trotzdem in erträglicher Zeit zu einem Produkt zu kommen.

Deshalb geht der nachfolgende Teil genau auf die technischen Strukturen und ihre Verbindungen ein und versucht praktische Lösungen anzubieten.

Die Definition eines Frameworks ist noch nicht vollständig. Birmam (wie viele andere) hebt noch etwas entscheidendes hervor: Den Willen, z.B. Probleme der Reliability und Security ernst zu nehmen und technisch zu lösen. Er zeigt eindrucksvoll dass wir Softwareentwicklung auf gut Glück betreiben und hoffen dass unsere Programme keine Menschen umbringen. Eben dieser Wille scheint neben der Technik die zentrale Rolle zu spielen, wie auch im Falle von NEWSYS.

Die Erfahrungen im NEWSYS Projekt haben gezeigt, dass der Wille u.a. von 2 Faktoren abhängt:

Im Anschluss an die Behandlung der technischen Strukturen eines Frameworks wird daher auf die sozialen Strukturen eingegangen, die seinen Erfolg wesentlich mitbestimmen. Darüberhinaus versuche ich zu zeigen, dass zwischen technischen und sozialen Strukturen eine enge gegenseitige Abhängigkeit besteht und wie man sie günstig beeinflussen kann.

Der Titel „Frameworking" wurde von mir ganz bewusst gewählt um die Arbeit an einem Framework als technischen und sozialen Prozess hervorzuheben.

Natürlich hat Frameworking noch weitere Dimensionen. Neben der technischen und sozialen Dimension steht der Produktionsprozess von Software in einem Mikroökonomischen und einen Makroökonomischen Zusammenhang. Die mikroökonomische Dimension habe ich (vielleicht als Folge der Tatsache dass NEWSYS innerhalb einer kleinen Firma entwickelt wurde in der soziales und ökonomisches hautnah miteinander verbunden sind) einfach unter den sozialen Strukturen mit behandelt. Die Makroökonomische Dimension (hier geht es u.a. um die Frage wie lange sich Softwareentwicklung noch ausserhalb normaler Geschäftsbedingungen abspielen kann? Stichwort: Produkthaftung, Gewährleistung, Qualität, Sicherheit etc.) übersteigt jedoch meine Kompetenz bei weitem und sprengt den Rahmen des Papers, das auf praktische Hilfen beim Frameworking ausgerichtet ist. Meiner Meinung wird jedoch der Tag kommen an dem ein US Gericht die Absicherungsklauseln eines Softwarherstellers für ungültig erklärt und Schadensersatz in enormer Höhe zuspricht. Von diesem Tag an wird „Frameworking" nicht mehr nur nützlich und praktisch für den internen Produktionsprozess sondern eine absolute Notwendigkeit sein.

Die hier gegebene Definition von „Frameworking" vermeidet absichtlich eine Bindung an Objekttechnologie. Zwar wurde NEWSYS unter Verwendung von Objekttechnologie entwickelt und deshalb liegt der Schwerpunkt des Papers auch darauf, aber dies ist keine notwendige Voraussetzung für ein Framework. Viele Operating Systems sind z.B. Nicht-OO Frameworks (Device Driver, pluggable Filesystems, Policies für User/Security, streamsbasierte protocol stacks etc. sind alles Puzzleteile und entsprechen dem Lifecycle Aspekt eines Frameworks)

Ausserdem, und dies ist eine persönlich gefärbte Aussage, habe ich nach wie vor Probleme mit Klassifikationssystemen. Sie sind immer unter gewissen Blickwinkeln und Annahmen entstanden. Und während sie sich im Alltag praktisch einsetzen lassen (und auch notfalls abändern) erweisen sich bisher objektorientierte Systeme beim Wechsel von Perspektiven als sehr unflexibel. Änderungen der Klassifikationen sind aufwendige Massnahmen. Hingegen sind strukturelle Transformationen z.B. von ausgezeichneten (mit Metainformation versehenen) Informationen/Daten relativ leicht und automatisch machbar. In einer Zeit wo sich Organisationen laufend umstrukturieren, d.h. ihre internen Klassifikationssysteme umbauen und flexibler gestalten ist eine Software auf Basis von starren Klassifikationssystemen problematisch.

Beispiel: Class Customer

Wenige Entwickler von Business-Software zögern eine Klasse „Customer" zu definieren. Mit etwas Glück erkennen sie rechtzeitig, dass die Klasse Customer besser nicht von der Klasse Person abgeleitet wird, da es juristische Personen als Customer gibt. [FOWLER] Aber wie sieht es mit dem ontologischen Gehalt von Customer aus? Customer sieht wie eine Basisklasse aus – ein sog. Business Object. In Wirklichkeit handelt es sich bei Customer bereits um eine Relation zwischen anderen Entitäten. Diese Relation kann sich mit der Zeit verändern. Neue Aspekte kommen hinzu. Eventuell wird aus einem Customer ein Partner oder ein Teil der eigenen Firma.

Momentan zeichnet sich ausserdem durch die Agent-Technologie ein Trend ab, der mehr die Kapselung und „Lebendigkeit" eines Objektes betont als die Position innerhalb einer Klassifikation. Unübersehbar ist auch der Trend in Richtung mehr Metainformation, sei es bei Objektdatenbanken oder beim Austausch zwischen Komponenten (Java‘s Infobus z.B. tauscht Daten aus).

Ich weiss es nicht. Momentan glaube ich, dass Strukturen ein Konstrukt unseres Verstandes sind und dass Entities der Realität Hinweise sind nach Strukturen zu suchen, sie zu konstruieren.

Es gibt einige Belege dafür: Strukturen, speziell software Strukturen sind unsichtbar. Wenn sie es nicht mehr sind dann entweder weil sie jemand im Source Code visuell ausgezeichnet, „getaggt" hat oder weil wir mittlerweile Erfahrung gewonnen haben die es uns gestattet, anhand von Source Code Stücken sofort davon betroffene Strukturen zu erkennen.

In bezug auf Strukturen in Frameworks haben wir folgende Situation:

Framework Strukturen sind:

Wie wir an den Source Beispielen oben gesehen haben, kann ein einziges Statement zu mehreren Strukturen gleichzeitig gehören ohne dass irgendetwas in diesem Statement auf diese Tatsache hinweisen würde. Mit einem Statement kann man seine sorgfältig entworfenen logischen Abstraktionen korrumpieren, die aufwendig kreierten physischen Trennungen ruinieren und Erweiterbarkeit und Wartung schwer einschränken.

Zumindest in ihren Konsequenzen sind Software Strukturen real.

Der härteste Teil bei der Behandlung von Software Strukturen in Frameworks ist, sensitiv für die Hinweise in Source Codes zu werden die anzeigen, dass bestimmte Strukturen davon betroffen sein könnten. Object Creation statements sind ein Beispiel dafür. Include Files ein anderes.

Und wenn man diese Hinweise entdeckt hat ist es wichtig deutlich zu machen, zu welchen Strukturen sie gehören und sie entsprechend auszuzeichnen, zu markieren. Coding Standards mit Regeln für Namensgebung etc. sind ein Platz dafür. Sonst werden Neulinge sie nicht wahrnehmen.

Und wenn wir das alles getan haben, kommt das nächste Problem: Sind diese Strukturen miteinander verknüpft und wie kann man dies visualisieren?

Es ist nicht schwer zu zeigen, dass Strukturen in Frameworks miteinander verknüpft sind:

Moderne Software muss reflektiv sein, mit anderen Worten, sie muss über sich selbst Auskunft geben können. Ein Teil der dazu notwendigen Information entsteht während des Build Prozesses, z.B. über package und Komponentennamen, Versionen, Interface Versionen etc. Die Build Struktur muss diese Informationen gewinnen und sie zurück in die Source Struktur leiten (z.B. über compiler defines). Elemente der logischen Struktur werden zur Laufzeit von der Runtime Struktur benutzt um diese Informationen zu verarbeiten, z.B. auf Interface mismatches hinzuweisen. Wenn das Framework selbst zur Laufzeit neue Klassen generieren soll, wird die Verbindung zur Source Struktur noch enger.

Die schwere Frage ist nochmals: Wie erklären und zeigen wir diese Verbindungen und Abhängigkeiten?

Framework Strukturen geben uns 3 Probleme zu lösen:

Einige der wichtigsten technischen Strukturen eines Frameworks sind:

Theoretisch könnten alle verschieden Strukturaspekte in einem einzigen Objekt Modul (file) zusammengefaßt werden. Erweiterungen (kundenspezifische, branchenspezifische oder einfache Fehlerbehebungen würden in diesem File stattfinden. Danach würde neu kompiliert und gelinkt und ein neues Release wäre fertig.

Dies ist bereits bei der Verwendung von C nicht praktisch und C++ stellt darüber hinaus besondere Anforderungen an die physische Struktur.

Die physische Struktur von grösseren C++ Paketen hat wiederum Einfluß auf die logische Struktur, was sich z.B. in besonderen Designtechniken wie Interface/Implementation Trennung oder bestimmten Hilfsklassen wie Factories und Brokern zeigt.

Bezeichnend ist, dass zwischen den einzelnen Strukturen Abhängigkeiten bestehen. Z.B. Sollten die Elemente der physischen Struktur ebenfalls als Klassen modelliert (reflektiert) werden. Dies setzt jedoch Input von der Source Struktur voraus.

Analytische Struktur

Die Komplexität der analytischen Struktur hängt von der Zielrichtung des Frameworks ab. Hier kann man unterscheiden zwischen erweiterbaren und generischen Frameworks.

Erweiterbare Frameworks

Erweiterbare Frameworks lassen in ihren Strukturen Leerstellen, die Anwender durch Einfügen der fehlenden Stellen für ihre Zwecke spezialisieren können. Hier ist das Framework EINFACH, die Arbeit der Anwender üblicherweise relativ komplex.

Der Abstraktionsgrad ist noch nicht sehr hoch, d.h. der Gegenstandsbereich wird teilweise direkt in der Maschine abgebildet. Neue Typen des Gegenstandsbereichs erfordern oft neue Verarbeitungsobjekte im User Interface, im Datenbank Management etc. Dynamische Casts zur Behandlung spezieller Objekte sind teilweise nötig.

Typischerweise gibt es keine Meta Infomationsmodelle. Der Anteil wirklich generischer Module, d.h. Module die einen grossen Gegenstandsbereich ohne extra Anpassung verarbeiten können ist gering. Damit hat die analytische Struktur grossen Einfluss auf die physische und extension Struktur.

A simple Framework based on the puzzle metaphor with hot spots for customization

Erweiterbare Frameworks werden durch die Puzzle Metapher gut beschrieben. Zur Laufzeit sind sie Instanzen spezieller Applikationen. Die analytische Struktur eines erweiterbaren Frameworks leistet im wesentlichen eine „hot spot" Analyse auf Objektlevel.

Genau das Konzept der Flexibilität auf Objektlevel ist jedoch auch die grösste Schwäche des Puzzle-Modells. Wie das Diagramm zeigt, spaltet sich ein Objekt in die verschiedensten Aspekte auf und betrifft ganz unterschiedliche Strukturen. Das Puzzle-Modell funktioniert nur, wenn der Aspekt den das Objekt ausdrückt auf logischer Ebene GENAU LOKALISIERBAR ist. Dies ist typischerweise der Fall in Sub-Frameworks wie z.B. einem Converter Framework Die Unterstützung eines neuen Text Formates ist eines der Paradebeispiele für „Plug and Play" durch Objektaustausch. Anwendungen im Source Code dazu finden sich im ET++ und MET++ Framework [ACKERMANN]

Generische Frameworks

Generische Frameworks sind in ihrem Aufbau sehr KOMPLEX, erlauben aber das einfache Behandeln einer grossen Zahl unterschiedlicher Gegenstände. Sie sind generische Maschinen zur Bearbeitung von Gegenständen der Realität. Eine solche Maschine setzt einen hohen Grad an Abstraktion des Gegenstandsbereiches voraus. Die analytische Struktur muss diese Abstraktionen liefern.

Innerhalb der analytischen Struktur findet eine Dekomposition der Gegenstände der Realität in Grundstrukturen statt. Das Framework arbeitet auf diesen Grundstrukturen. Es gibt in einem Framework nichts was z.B. direkt einem bestimmten Dokument Objekt entsprechen würde. Es gibt keine direkte Entsprechung zu einem speziellen Use Case.

Als generische Maschine kann ein Framework keinen konkret auf spezielle Gegenstände bezogenen Code beinhalten. Überhaupt ist es nicht gut in Framework Code direkt Gegenstände der Realität abzubilden. Es gibt im allgemeinen kein singuläres Programmobjekt das einem Objekt der Realität entsprechen würde (schlicht deshalb weil die Objekttechnologie bisher in keinster Weise echte Objekte abbilden kann und ihnen zudem die ontologische Qualität (noch) fehlt). Als Folge dessen ist auch ein dynamisches Casten meist nicht sinnvoll – WORAUF SOLLTE DENN GEKASTET WERDEN wenn es keine 1:1 Entsprechungen gibt?

Generische Frameworks bestehen aus generischen Modulen die Verarbeitungsanweisungen nicht im Source Code einprogrammiert haben sondern aus Meta Informationen beziehen. Gegenstände der Realität sind in Form von Metamodellen beschrieben auf denen alle Module des Frameworks zugriff haben. Diese Metamodelle sind üblicherweise selbstbeschreibend.

Zur Laufzeit erfolgt im Framework eine Umsetung der Meta Informationen in Cluster und Bäume aus konkreten Programmierobjekten des Frameworks. Der Unterschied zwischen Meta Information als Abbildung der Realität und dessen Umsetzung in Programmobjekte bleibt deutlich sichtbar.

Ein Beispiel:

Es gibt ein Objekt „Kunde" des Gegenstandsbereichs „Banking Business". In einem generischen Framework findet sich keine Klasse „Kunde", keine Klasse „Kundenrecord" in Headerfiles, kein GUI ressource file für eine „Kundenmaske". Was das generische Framework benötigt um ein Objekt „Kunde" des Gegenstandsbereichs zu verarbeiten ist Meta Information über ein solches Objekt.

Diese Metainformation existiert nur ein einziges Mal und ist selbstbeschreibend. Das Framework kann aus dieser Metainformation Views für das GUI sowie datenbank schemata generieren. Es kann ein „Kunden" Objekt des Gegenstandsbereiches durch ein composite Object bestehend aus generischen Objekten des Frameworks repräsentieren.

Neue Anforderungen, z.B. Spezialisierungen von „Kunde" sind plötzlich durch Änderungen der Meta Informationen möglich und erzwingen keine neuen Module (Puzzle Teile)

Hauptzweck der analytischen Struktur ist Abstraktion durch Dekomposition. Eine Besonderheit dabei ist, dass dabei MetaInformation entsteht die programmatisch sichtbar werden muss, d.h. das Framework muss darauf programmatischen Zugriff haben.

Dies findet in der reflektiven Struktur (s.u.) statt. Das wiederum bedeutet, dass die meta information NICHT Dokumentation im Sinne zusätzlicher Schriftstücke sein kann. Sie muss zur Laufzeit zur Verfügung stehen, gepflegt und angepasst werden. Meist geschieht das mit Hilfe des Frameworks selbst, d.h. mit Hilfe von logischen und physischen Elementen die aber zur Reflektiven Struktur des Frameworks gehören.

A generic framework that represents objects with meta information.

Ganz ähnlich einem „aspect weaver" [AOP] setzt das Framework zur Laufzeit eine Instanz von sich so zusammen, dass das Objekt des Gegenstandsbereiches bearbeitet werden kann.

Die analytische Struktur eines generischen Frameworks erarbeitet die Meta Informationen. Die Granularität der „hot spots" ist nicht mehr nur auf Objekt Level sondern lediglich durch die Mächtigkeit der Meta Information beschränkt. Generische Frameworks gleichen eher Betriebssystemen als speziellen Applikationen.

Physische Struktur

Unter der physischen Struktur eines Software Paketes versteht man

• Compile- und Linktime Abhängigkeiten von Objekt Modulen

• Aufteilung von Repositories, Configuration Information in physische Entities

• Trennungen von Interfaces und Implementationen

• Default Implementationen

• Object Creation / Factories

• Die Zusammenfassung von Objekt Modulen zu Komponenten (Packages) sowie die Definition deren Funktionalität. Damit verbunden ist die Organisationsweise des Source Code Trees.

• Die Definition bestimmter Packages als zum Basissystem gehörig bzw. applikationsspezifische Erweiterung

• Compile- und Linktime bzw. Runtime Abhängigkeiten der einzelnen Packages untereinander

• Die Auslieferungsform (Dlls, libraries, exes, config files etc.)

• Performance Aspekte (z.B. Degeneration von Implementationen durch Zahl oder Umfang der Objekte)

• Scaling Structure: Wo sind cold spots die bei Erweiterungen physikalisch nicht skalieren?

Bei der physischen Struktur kommt deutlich eine selbstbezügliches Element des Frameworks zur Geltung. Damit die physiche Struktur ihre Leistungen erbringen kann, stützt sich sich ihrerseits wieder auf Mechanismen der logischen Struktur (Klassen, Regeln etc.) Dieses Element der Selbstbezüglichkeit taucht immer wieder auf, z.B. wenn Konfigurationsfiles als Dokumente aufgefaßt werden, damit sie mit denselben Mitteln des Frameworks für allgemeine Dokumenttypen bearbeitet werden können OBWOHL sie das Framework selbst beschreiben.

So verwendet das Konfigurationsframework innerhalb von NEWSYS genau wie eine Belegapplikation die Dokument Parts des Frameworks. Dies verringert die Zahl der Klassen und Interfaces enorm und bringt leichtere Handhabbarkeit und Polymorphie im Einsatz der Klassen:

Beispiel:

Die eingangs erwähnten Serviceprobleme mit Konfigurationsfiles unter OLDSYS. Bei der manuellen Bearbeitung der Dokumentenbeschreibung entstanden häufig syntaktische und semantische Fehler. OLDSYS war nun seinerseits ein System zur Bearbeitung der Zeichen, Syntax und Semantik in Belegen. Wenn man jetzt selbstbezüglich die Dokumentenbeschreibungen unter OLDSYS als Beleg auffaßt, dann müßte OLDSYS alle Mechanismen bereits besitzen, um mit Hilfe von Prüfroutinen (die teilweise belegspezifisch noch erstellt werden müßten) eine Bearbeitung der EIGENEN Dokumentbeschreibungen zu ermöglichen.

Der ohnehin nötige Editor zum Bearbeiten der Belege könnte dann auch zur Bearbeitung der eigenen Konfigurations Informationen verwendet werden. Den Entwicklern von OLDSYS war diese Analogie nicht aufgefallen und es wurde versucht, einen extra Editor zu entwickeln statt den vorhandenen genereller zu machen.

Unter OLDSYS scheiterte dieses Konzept zusätzlich an der engen Kopplung von Datenhaltung und Editieren.

Das Prinzip der Selbstreferenz in Verbindung mit einem hohen Abstraktionsgrad ist eines der wichtigsten Design Pattern auf System/Architektur Ebene. Gelungene Systeme zeichnen sich durch einen hohen Grad an Selbstreferenz aus.

(vgl. z.B. das Stream Design Pattern das an vielen Stellen in Unix gleich verwendet wird. Das erleichtert sowohl die Implementation als auch die Benutzung.)

Wesentlicher Bestandteil der physischen Struktur eines Frameworks sind die Eigenschaften der zugrundeliegenden Programmiersprache. Für C++ Programmierung bedeutet dies u.a. die Kenntnis von:

1. Bedeutung, Struktur und Verwendung der Vtable bei single und multiple inheritance

2. Behandlung der vom Compiler generierten Methoden (Wann und wie werden sie generiert, wo legt sie der Compiler hin)

3. Aufbau von Objektlayout (compiler abhängig)

4. Konsequenzen aus dem compilerabhängigen binären Layout

5. Konsequenzen aus Source Changes auf das binäre Layout

6. Name mangling und dynamisches Laden

7. DLLs mit C++ Modulen

8. Probleme der statischen Initialisierung

9. Konsequenzen der Verwendung von inlines, templates und default parametern auf den Software Lifecycle.

10. memory allocation operatoren und debugging möglichkeiten bei memory leaks

11. Compilerabhängige Behandlung von Templates

12. Möglichkeiten der Garbage Collection und Meta Object Protokolle für C++

Ein fertiges Framework schützt seine Benutzer vor vielen physischen Details. Während seiner Entwicklung allerdings müssen physischer Eigenschaften der Programmiersprache explizit gemacht und in ihren Konsequenzen verstanden werden. Viele Applikationsprogrammierer machen diese schmerzliche Erfahrung erst wenn es zu spät für ein Projekt ist.

Literatur dazu: [LACOS],[MEYERS1/2], [TALIGENT1], [M.ELLIS], [J.ELLIS]

Zwei Warnungen vorab:

Auf der technischen Seite eines Frameworks lässt sich deutlich ein Abrücken vom Modulgedanken als gliederndes Element erkennen. Strukturen und Aspekte wurden als übergreifende, quer durch Software Schichten laufende Verbindungen erkannt. Dies hat Konseuenzen auch für die soziale Organisation der Software Entwicklung (siehe Organizational and Social Frameworks, [WKR97/1]). Auch hier versagt das „Kästchendenken" als Form der Reduktion von Komplexität.

Die 3 wichtigsten sozialen Strukturen einer Framework Entwicklung sind

Die gröbste Gliederung von NEWSYS besteht aus 5 Domains die zusammen das Framework auf logischer Ebene repräsentieren und jeweils unterschiedliche Services zur Verfügung stellen.

Diese Domains sind lediglich logische Gliederungen der Apekte die sich einem bestimmten Gebiet zuordnen lassen. Damit ist keinesfalls festgelegt durch welche Module oder Packages diese Services tatsächlich zur Verfügung gestellt werden. Ebenfalls unterstellt dieses Schema kein Layering. D.h. die Verbindungen zwischen diesen Domains erlauben 2- oder 3-tier Architekturen. Zu den Problemen des Layer Architectural Design Patterns siehe [SIEMENS].

Orthogonal zu dieser Gliederung verlaufen Domainübergreifende Strukturen wie Fehlerbehandlung und Exceptions, Internationalisierung, User Kontrolle etc. die teilweise wie im Falle der Fehlerbehandlung und Internationalisierung untereinander wiederum verwoben sind. (Fehler müssen in der gewählten locale angezeigt werden). Gedanklich sind diese Funktionalitäten vor allem in der BASE Domain angesiedelt, sie können aber auch anderen Domains zugeordnet werden. User Kontrolle kann z.B. durchaus eine Funktionalität des Models (PDC) sein.

An dieser Stelle wird ganz bewusst zwischen den Begriffen „Interface" und „Protokoll" unterschieden. Beide werden häufig auf Funktionen angewendet, die einem Client zur Verfügung gestellt werden.

Protokolle sind der prozedurale Teil der Benutzung von Interfaces- sowohl interner Interfaces wie z.B zu einer Base-Class als auch externe (public) Interfaces. Sie können leider in den meisten Programmiersprachen noch nicht programmatisch definiert werden, d.h. das vielbesprochene „behavior" von Klassen oder Clustern von Klassen ist immer nur implizit im Source Code enthalten. Beide Begriffe sollten streng getrennt werden, damit dieser Mangel nicht verdeckt wird. Das Einhalten von Protokollen durch Anwender ist eines der grössten Probleme bei der Erweiterung des Frameworks (siehe dazu die Visualisierung eines Template/Hook Protokolls durch Tags im Kapitel zu Coding Standards)

Die Konsequenzen dieser Trennung von Interface und Protokoll an einem Beispiel:

Eine Interface Klasse V wird folgendermassen spezifiziert:

Class V {

Boolean init(args);

Boolean doIt(args);

Void reset();

}

Eine Implementation N1 implementiert dieses Interface wie folgt:

Class N : public V {

Boolean init(args); // soll nur einmal aufgerufen werden

Boolean doIt(args); // kann nur einmal aufgerufen werden

reset(): // tut nichts

}

Eine weitere Implementation N2:

Class N2 : public V {

Boolean init(args); // soll nur einmal aufgerufen werden

Boolean doIt(args); // kann mehrmals aufgerufen werden, vorausgesetzt

// reset() wird dazwischen aufgerufen

reset(): // tut nichts

}

Eine weitere Implementation N3:

Class N3 : public V {

Boolean init(args); // kann mehrfach aufgerufen werden, reset() dazwischen

// nötig.

Boolean doIt(args); // kann mehrmals aufgerufen werden, vorausgesetzt

// init() wird dazwischen aufgerufen

reset(): // wenn gerufen, lässt die init argumente gültig für den

// nächsten doIt() Aufruf

}

Weitere Kombinationen sind denkbar, mit jeweils anderer Semantik und anderen Verpflichtungen für den Client.

ALLE Kombinationen sind jedoch mit dem in V spezifizierten Interface bezüglich der physischen Struktur verträglich. Worin sich die Implementationen unterschieden ist das PROTOKOLL. Da die Klasse V keine Protokoll spezifiziert (momentan ohnehin nur in Form von Kommentaren in der Interface Definition möglich) entstehen inkompatible Implementationen.

Zu diesem fundamentalen Problem hat die OMG ein RFP veröffentlicht und die Firma ICON hat dazu einen Vorschlag eingereicht [CATALYSIS].

Nach den Regeln der automatischen Generierung von Dokumentation hat jede Klasse im Deklarationsteil eine ausführliche Beschreibung ihrer Funktion im Framework zu liefern.

NEWSYS REGEL: Jede InterfaceKlasse ist verpflichtet, ihr dahinterliegendes Protokoll im Header File zu spezifizieren und über die automatische Dokumentation zugänglich zu machen, solange keine programmatischen Möglichkeiten bezüglich Protokollen bestehen.

Der NEWSYS Coding Standard enthält darüber hinaus eine Regel bezüglich minimalen Interfaces zur Vermeidung von semantischen Zweideutigkeiten in Protokollen. (s.u. Programmierregeln)

Achtung: Nicht nur Methoden von Interface-Klassen gehören zum Interface, auch normale Header Files in denen z.B. Konstanten für Parameter eines Protokolls gesetzt werden, gehören logisch zum Interface obwohl sie oft in einem separaten Headerfile Sy.D.... .h sind. Damit stellen sie ein großes Problem für die Kapselung dar: Wenn z.B. eine Implementation eine neue Konstante benötigt, muß dann das Interface geändert werden? Hoffentlich nicht, besser ist es, dann auch eine neue Implementation des clients zu erstellen und beide Implementationen teilen ein privates Header File mit gemeinsamen Definitionen. Die .h-Files bei den Interfaces werden weiter unten nicht extra besprochen.

Die konkreten Packages mit Implementationen unterliegen der weiter unten beschriebenen Source Code und Extension Struktur.

Exkurs: Verschiedene Möglichkeiten der Überwachung von Protokollen

Ausgangspunkt ist die Beobachtung, dass die meisten Klassen bezüglich ihres Protokolls, d.h. ihre „richtigen" Verwendung eher auf gut Glück hin implementiert werden als mit systematischer Fehlerbehandlung. Dies ist verständlich, steigt doch mit jeder Methode der Aufwand, den eigenen State zu sichern, d.h. Sicherheit auch dann zu garantieren, wenn die Methoden in der falschen Reihenfolge aufgerufen werden.

Diesem Problem kann man auf 2 Wegen begegnen. Der konventionelle Weg besteht darin, durch mehr Disziplin bei der Implementation der Klassen die Sicherung des States zu erreichen. Davon abgesehen dass das sehr mühsam und schwierig ist, belastet es auch die Performance des Gesamtsystems enorm. Dieser Ansatz sieht eine Klasse grundsätzlich isoliert, in einem unbekannten und potentiell feindlichen Umfeld tätig.

Ein anderer Ansatz (aus der Hardware Entwicklung) läge darin, auf interne Prüfungen weitgehend zu verzichten. Stattdessen publiziert der Klassenautor das zulässige Protokoll und vertraut darauf, dass die Clients es einhalten. Dies wiederum setzt voraus, dass es Tools gibt, die die Einhaltung des Protokolls garantieren können, sei es zur Compilezeit oder teilweise erst zur Laufzeit.

Das Validierungstool müsste zumindest auf Komponentenebene vollständige Informationen zur Verfügung haben, d.h. wir bewegen uns weg vom einzelnen File als Basis der Compilierung. Das Tool müsste weiterhin die zeitlichen Abläufe verstehen können. Dies bedeutet einen Schritt weg von der Compilierung und hin zur Simulation. Der Nutzen eines solchen Verfahrens wäre enorm: Implementationen von Klassen werden einfacher und performanter.

Ein Nebenergebnis dieser Überlegungen ist, dass das File als bisherige minimale Entwicklungseinheit gleichzeitig zu grob (inkrementelles compilieren auf Methodenebene) als auch zu klein (Sichere Verwendung durch Clients) ist.

Manchmal sieht es so aus, als liesse sich keine sinnvolle Interface Klasse definieren da die Klassenmethoden im wesentlichen Tabelleninhalte oder Parameter physischer Geräte etc. sind. Entscheidend sind die Argument- bzw. Returntypes der Methoden.

Werden z.B. viele Werte mit GetXYZ() zurückgegeben und die Werte sind alle Strings, lohnt es sich über ein symbolisches Interface nachzudenken (composite message design pattern) hier kann der Client über EINE methode z.B. getDataProtocol() ein Objekt der Klasse Dataprotocol erhalten und aus diesem mit getValue(„Token") spezielle Werte erhalten.

Dieses design pattern eignet sich wie gesagt vor allem bei gleichen Value Typen, da natürlich nur eine Klasse von Values zurückgegeben werden kann.

DataProtocol kann dann natürlich durch weitere getXYZ() methoden erweitert werden, die jeweils verschiedene Typen zurückliefern können. Dies wird z.B. in der ResultSet Klasse des Java JDBC Datenbankinterfaces getan.

Hilft alles nichts, kann trotzdem ein allgemeines Interface OHNE die speziellen Methoden definiert werden. Clients die unbedingt die speziellen Methoden brauchen, müssen dann einen dynamic cast durchführen. Es sind jedoch im allgemeinen nur ganz wenige Clients, die dies tun müssen.

Grundsätzlich gilt, dass gerade Klassen die aus einem Reengineering von „alten" Projekten stammen sehr mit „alten" Methoden überfrachtet sind, sie haben sozusagen das alte Design geerbt. Auch die speziellste Klasse hat generelle Typen, so ist z.B. eine Datenbank durchaus einmal als Typ Dokument aufzufassen. Ein spezieller Beleg einer Domain ist ebenfalls ab einer gewissen Ebene nichts anderes als ein Dokument.

Exkurs: zwischen statischem Typing und dynamischer Interpretation

Betrachtet man die Entwicklung von JAVA innerhalb des letzten Jahres fällt auf, dass die verwendete Technologie immer wieder pendelt zwischen einer Betonung von statischem Typing und der Verwendung von interpretativen Verfahren. So kannte das erste Release der GUI-Komponente (AWT) keine statisch getypten Events. Das Dispatching erfolgte über die Interpretation von Symbolen zur Laufzeit. Dies stellte sich in zweifacher Hinsicht als problematisch heraus. Erstens beeinträchtigte es die Performance und zweitens entstanden viele Fehler durch Verwendung der falschen Symbole, die vom Compiler ja nicht geprüft werden konnten.

Das Java Development Kit 1.1 brachte eine Trendwende hin zu einem statisch typisierten Eventmodell. Speziell im Falle der Java Beans ist dieses statische Modell eng an Werkzeuge gekoppelt, die automatische Adapterklassen generieren, die die jeweiligen statischen Eventtypen kennen. Gleichzeitig wurde allerdings auch ein Reflection API eingeführt womit Objekte zur Laufzeit analysiert werden können.

In der neuen Spezifikation des Java Infobus Konzepts dominiert wiederum die dynamische Interpretation. Die Klasse DataItem (analog zum NEWSYS DataProtokoll) erlaubt es symbolische Informationen über ein einfaches generisches Interface zu transportieren.

Auch im CORBA Bereich finden wir beide Verfahren, z.B. im Event-Service. Und interessanterweise waren auch die Entwickler des Component Broker Connectors der IBM gezwungen ganz unten, d.h. am Interface zum Datenbank-Cache, ein symbolisches Interface (DataAccessObject) einzuführen, während die übergeordneten Klassen (Business Object und DataObject) statische Types sind.

Erfahrungen aus Message-Bus Systemen zeigen dieselbe Problematik: Wenn ein System wartbar bleiben soll, scheint ein gewisses Mass an symbolischer Information (mit anschliessender Interpretation zur Laufzeit) unvermeidlich.

Darunter fällt die Art und Weise von Ableitungen die wiederum die jeweiligen physischen Abhängigkeiten bedingen. Eine Ableitung von einer Basisklasse ist ein STATISCHER Vorgang, der Compilieren und Linken bedingt.

Dazu kommen Abhängigkeiten des DMC Packages von OLDSYS Kompatibilitäts Packages wenn sich Interfaces dort ändern sollten.

Wichtig ist, daß alle Komponenten vom Base Package statisch abhängen, jedoch UNTEREINANDER nicht statisch abhängig sind. Das bedeutet, daß z.B. die Änderung einer Implementation in der PDC keine neues Compilieren oder Linken anderer Packages nach sich zieht.

Anpassungen dort sind erst nötig, wenn sich z.B. die Interfaces/Protokolle der PDC ändern und die HIC solche verwendet. Für Zwischenreleases ist es deshalb wichtig, diese Interfaces einzufrieren.

Zur Schicht der konkreten Hilfsklassen besteht eine Linktime Abhängigkeit aller Komponenten. Dies wirkt sich in der Praxis aber nicht gross aus, da der Coding Standard festlegt, dass niemand konkrete Klassen ableiten darf. Die Komponente selbst ist eine dynamische Link Library (DLL) die zur Laufzeit automatisch beim Startup hinzugeladen wird.

Die Art und Weise wie NEWSYS eigene Konfigurationselemente sowie Dokumenten und Workflow Information behandelt, unterscheidet sich grundlegend von OLDSYS. Da das Verfahren sehr gut auf verschiedene Formate erweiterbar ist, intern den Benutzern jedoch immer das gleiche Interface liefert, kann man hier von einem eigenen Subframework innerhalb von NEWSYS sprechen.

NEWSYS behandelt alle Formen symbolischer Information über die gleiche Dokumentenmetapher als „strukturierte Dokumente"

NEWSYS verwendet SGML Techniken wie General- und Parameterentities um das Kopieren und Duplizieren von Information zu vermeiden, was sonst große Wartungs- und Zuverlässigkeitsprobleme mit sich bringt. Damit kann gleichzeitig erreicht werden, daß harte Pfadangaben etc. aus den Systemkonfigurationen verschwinden. Der SGML Parser un Verbindung mit dem Entity-Manager löst Entity-Referenzen zur Laufzeit auf. Installation, Wartung und automatische Updates werden dadurch erleichtert bzw. erst möglich. Die strukturelle Validität der NEWSYS Systemdokumente wird bereits durch den Parser erzwungen.

NEWSYS verwendet ISO Standards für seine Dokumente wie auch deren Meta- Beschreibungen, damit handlesübliche SGML Tools zur Bearbeitung eingesetzt werden können. (Beispiel: Near&Far’s Tools zur graphischen Analyse und zum editieren von Dokument Type Descriptions.

NEWSYS kann das gesamte symbolische Environment des Systems bzw. einer Applikation BEIM STARTUP der Applikation erzeugen. D.H. eine Änderung EINER Stelle in einer Konfigurationsentity wird SOFORT für alle Applikationen wirksam. Dies ist möglich, weil Information referenziert statt kopiert wird.

Da das Includieren über den Entity manager erfolgt, ist sogar das Includieren von Information die sich auf anderen Servern oder im WWW irgendwo befindet möglich. Es muß z.B. als Identifier lediglich eine URL (Protocol://Server/Parameter angegeben werden und die Installation eines Kunden würde zum Startup eine Verbindung zum Hersteller aufbauen und das entsprechende Konfigurationsfile vom Web Server laden.

Das Kozept des Entity-Managements erlaubt darüber hinaus auch das Auflösen von Referenzen zur Laufzeit, d.h. ein dynamisches Abändern der Konfiguration wäre ebenfalls möglich.

Selbstverständlich ist auch das einzelne Parsen und Prüfen aller Konfigurationen mit Hilfe des nsgmls.exe Parsers möglich. Dieser erzeugt einen Zwischencode der ebenfalls von NEWSYS gelesen werden kann.

NEWSYS Konfigurationsframework

Das Konfiguration Framework ist kein in sich abgeschlossener Teil des Framework sondern benutzt die im Framework vorhandenen Mechanismen zur Bearbeitung von Dokumenten. Seine Hauptmerkmale sind:

• Aufsplittung (Faktorisierung) unabhängiger Teile in „sgml entities"

• Bezug auf Symbole über „formal public identifiers"

• logische Dokumentenbeschreibungen in „entities"

• physische Dokumentenbeschreibungen in „entities"

• Systemdefinitionen (Pfade, Drivenamen) in „entities"

Währen der ORB Mechanismus Clients vom Wissen über den Standort von Objekten (und ihre physische Implementation) befreit, ermöglicht das Konfigurationsframework die Unabhängigkeit der Clients von Systemdetails wie Pfaden, Drives, Ressourcen etc. Alle diese können symbolisch adressiert werden. Auflösung der Namen und Adressen sowie Instanzierung sind Aufgaben des Frameworks. (Vgl. dazu auch das JDBC Datenbank-Framework in Java)

Start einer Applikation:

Anmerkung: Mit „Applikation" ist ein gewisser Workflow gemeint und nicht im herkömmlichen Sinn ein Programm in Form eines .exe Files. NEWSYS „Applikationen" sind im allgemeinen lediglich Konfigurationsdateien in SGML.

Aufruf: NewSys.exe MyApplication.sgm

1. Generische Klassen der Application-Domain booten NEWSYS Framework (Broker, Base DLLs)

2. NEWSYS erzeugt ein symbolische Runtime Environment „config". Dabei handelt es sich um etwas ähnliches wie den CORBA Naming Service jedoch mit erweiterter Funktionalität wie z.B. mehrere gleichlautende Token/Objekt Paare pro Context und der Möglichkeit von update events für alle Contexte. Darüberhinaus besassen die Contexte Suchmethoden.

Die Initialisierung dieses Environments erfolgt folgendermassen:

• NSys lädt Config Object mit Parameter appl.sgm über Methode der Base Factory.

• Die Base-Factory lädt ein Config Object mit Parameter appl.sgm

• Das Config-Object fordert einen ConfigBuilder aus der BaseFactory an

• Der ConfigBuilder holt einen ParserEventGenerator aus der SGMLFactory mit argument appl.sgm

• Der SgmlKit erzeugt den richtigen ParserEventGenerator für .sgm files

• Der ParserEventGenerator lädt app.sgm und ruft den SGML-Parser

• Der SGML-Parser validiert appl.sgm und gibt Ergebnisse an den ParserEventGenerator

• Der ParserEventGenerator ruft den Config Builder mit Ergebniss-Events auf

• Der Config Builder baut einen Part-Graph aus den Events auf.

• Das Config-Object initialisiert sich mit Part Graph

• Die Base-Factory gibt das fertige Config-Object zurück

• NSys merkt sich diese Config als „current config". Diese current config ist jederzeit zur Laufzeit erweiterbar durch merge() methoden. Information zum Environment kann in beliebigen Formaten vorliegen, da der jeweilige ParserEventGenerator diese immer in die gleichen SGML-Events transformiert.

3) generische Applikatione Klassen fordern vom NSys Broker Action Objekte an und starten sie als Thread oder Prozess. D.H. es gibt kein Applikation.exe Programm sondern ein oder mehrere DLLs mit Spezialisierungen der NEWSYS Klassen sowie ein symbolisches Environment Application.sgm.

Bei der Erzeugung des symbolschen Runtime Environments wird das Parser Pattern verwendet. Config-Objekte operieren nur auf Graphen von Parts. Physische Formate und syntaktische Validierung erfolgen im Zusammenspiel von Parser und ParserEventGenerator. Neue Config Formate bedeuten neue ParserEventGeneratoren. ConfigBuilder ist vom Type SGMLApplikation, d.h. ParserEventGeneratoren kennen dieses Interface und können an solche Objekte Events weiterreichen.

Wie sieht die logische, physische und runtime Struktur dieser Config aus?

logische Struktur: Ein Graph aus Elementen, validiert durch den Parser

Dokument-Type-Descriptions (DTDs) und Element-Models legen die logische Struktur einer Konfiguration fest:

Was muß in einer legalen Config enthalten sein? Auf welche Weise und Wo muß es enthalten sein?

Der Parser validiert diese logische Struktur wie ein c/c++ Compiler ein sourcefile parst und validiert. Und ganz ähnlich wie dieser andere Files dabei „included", ruft der SGML Parser den Entity Manager wenn er auf eine Symbolreferenz stößt, die nicht bereits vorher definiert wurde.

Wie der c/c++ Compiler arbeitet der SGML Parser letztlich auf der LOGISCHEN Struktur die ein Ganzes bildet, egal ob dieses logische Ganze bereits in einem File zusammengefügt war oder erst durch das Einfügen vieler „Includes" oder in SGML: „Entities" entstanden ist. Eine Besonderheit der SGML Entities ist jedoch, dass sie durch den Entitymanager notfalls zur Laufzeit erst erzeugt werden können, z.B. durch eine Datenbankanfrage oder durch ein „auschecken" der Information aus einem Source Code Control System. Üblicherweise sind Compiler leider kaum so offen gebaut, dass man eine solche Funktionalität nachrüsten könnte.

physische Struktur: Eine Anzahl von Entities

Entities (ähnlich den c/c++ include files) beinhalten die Dokument Type Descriptions, Element Modelle (== Element Definitionen) und Daten. Diese können aus anderen Dokumenten includiert werden, d.h. Information muss nicht kopiert werden.

Runtime Struktur: Wie entsteht ein Config Object?

Wie wird aus einem Anfangsdokument (Appl.sgm) ein Config Object OHNE dass zwischen den Beteiligten Klassen unnötige Compile- oder Linkabhängigkeiten entstehen? Die Lösung liegt darin, Object Allocation immer über Factory Interfaces bzw. Broker durchzuführen wobei die beteiligten Klassen ausschliesslich Interface Definitionen voneinander kennen. Im folgenden Diagramm stellen die Pfeile den Ablauf der Aufrufe dar.

• appl.sgm referenziert über symbolische Namen(Formal Public Identifier) eine bestimmte Entity

• ConfigBuilder aus der BaseFactory erhält Document Name und holt Parser aus SGML Factory

• SGML Parser findet symbolische Referenz in app.sgm und fordert seinen Entity manager auf, die Referenz aufzulösen.

• CATALOG enthält ein Mapping von Symbol auf Entity

• Entity Manager braust durch CATALOG und findet Entity Location. Er übergibt Entity an Storage manager.

• Storage Manager lädt Entity und gibt sie zurück.

• Entity Manager gibt Parser die offene Entity.

• Parser fügt Entity Inhalt in Dokument ein

• Config erhält alle Inhalte OHNE überhaupt zu merken, daß sie aus vielen Teilen entstanden sind bzw. diese Teile ERST ZUR LAUFZEIT ÜBERHAUPT ENTSTANDEN SIND (z.B. durch Datenbank Zugriffe)

• ConfigBuilder bekommt Events vom parser mit dem Inhalt des Dokuments, holt sich C++ Dokument Part Objekte aus Factories, füllt den Inhalt der Dokument Teile ein und verknüpft die Parts zu einem Composite Object.

Hinter dem Konzept der "formal public identifier" steht nichts anderes als das Grundproblem der Informatik: Was bedeutet ein Name? Wie finde ich das, worauf sich ein Name (Link) bezieht?

In Hytime, dem ISO Hypertext Standard findet dieses Konzept breite Anwendung. Die neueste Version des SGML Parser Toolkits von James Clark (SP-Parser) unterstützt auch das Konzept der „architectural forms", die in diesem Zusammenhang eine große Rolle spielen.

Die logische Strukur eines COR ist einfach: Ein Client verwendet eine Factory um z.B. ein Connection Object zu erhalten, das ihn mit einer Datanbank verbindet. Er spezifiziert seinen Request symbolisch, d.h. er gibt keine physischen Charakteristiken der Datenbank an (z.B. Oracle, über TCP/IP, von Server Foo). Aufgabe der Factory ist es, die Verbindung zur richtigen Datenbank herzustellen OHNE Kenntnis des Sinns des symbolischen Request und mit der Möglichkeit Datenbanken dynamisch hinzuzufügen, OHNE die Factory ändern zu müssen.

Diese Anforderungen lagen auch dem JDBC Konzept von Java zu Grunde:

Die Driver werden entweder von der Factory bei der Instanziierung der Factory geladen oder ein Client instanziiert einen Driver selbst, der sich daraufhin bei der Factory registriert. Kommt ein Client Request, leitet ihn die Factory (mit Ausnahme des ersten Teil der URL) und den ersten Driver der Kette weiter. Erkennt der Driver die URL als seine an, gibt er ein Connection Object zurück, das die Factory weiter an den Client reicht.

In diesem Beispiel wäre dies der 2.Driver der Chain. Fühlt sich kein Driver zuständig, wird eine Exception erzeugt. Jeder Driver enthält einen Interpreter der die spezielle URL Semantik seines Drivers versteht.

Diese Implementation des logischen Patterns hat folgende physische Konsequenzen bezüglich Scalierung und Performance:

Sowie die logische Konsequenz, dass bei zwei Drivern mit gleicher URL der erste Driver in der Kette genommen wird.

Wenn der logische Teil der Extension Struktur die Anzahl der Driver als hot spot definiert hat, (d.h. man rechnet mit einer grösseren Zahl von Drivern), dann skaliert diese spezielle Implementation des COR Patterns nicht.

Eine physisch skalierende Implementation wäre z.B. diese:

Hier wird die Interpretation der URL von Driver Proxies vorgenommen, die nur im Falle eines Matches den entsprechenden Driver laden.

Falls die Interpretation selbst zu aufwendig wird muss ein request-pattern basierter Dispatch Mechanismus verwendet werden, bei dem ein weiterer Teil der inneren Struktur der URL in die Factory verlagert wird.

Neben der Wiederverwendbarkeit von Teilen und dem vorgegebenen Ablaufrahmen ist eines der entscheidenden Merkmale von Frameworks die Erweiterbarkeit, sei es durch interne Programmierer oder durch Kunden.

Die logische Struktur von Erweiterbarkeit besteht bei objektorientierten Frameworks in der Ableitung vorgegebener Defaultimplementationen. Die dadurch entstehenden Objekte entsprechen den vom Framework vorgegebenen Interfaces und können somit auch vom Framework polymorph verwendet werden.

Eine mögliche Implementation - vollkommen verträglich mit der logischen Struktur des Frameworks - wäre die kundenspezifische Ableitung neuer Klassen die anschließend mit dem ganzen Framework gelinkt werden (analog zum Anlauf 1 im obigen Exkurs). Die Packages die das Framework ausmachen würden dadurch ständig wachsen und sich ändern. Ein Alptraum in Bezug auf Test und Wartung sowie Handhabbarkeit.

Innerhalb der physischen Struktur des Frameworks muß es deshalb Mechanismen geben, die eine Erweiterung des Frameworks in gekapselter Form gestattet, ohne daß das Framework selbst geändert werden muß. Diese physischen Mechanismen stützen sich selbstverständlich selbst wieder auf logische Mechanismen.

Bevor diese Mechanismen jedoch eingebaut werden, muß eine Analyse der Problem Domain festlegen WELCHE TEILE erweiterbar sein sollen.

Logische Strukturen der Flexibilität und Erweiterung

Innerhalb der logischen Strukturen lassen sich 2 große Mechanismen der Flexibilität ausmachen:

1. Erzeugung neuer Typen, z.B. von Dokumenten, durch Ableitungen (und deren Austausch über Mechanismen der physischen Struktur)

2. Das Zusammenfügen von bereits vorhandenen Typen (Composite Object Pattern, Lego Prinzip).

Es zeigt sich daß erst die Verbindung beider Konzepte Erweiterbarkeit eines Frameworks schafft. Nicht alles läßt sich durch Komposition erreichen und ohne Ableitung muß Code massiv dupliziert werden. Noch schlimmer: Default- oder Basisklassen legen in einem Framework auch VERHALTEN fest bzw. schreiben es vor. Die Verpflichtungen aus einem Interface/Protokoll können in C++ nicht explizit gemacht werden, d.h. wer eine Methode neu implementiert und damit eine Basismethode überschreibt muß die SEMANTIK des Verhaltens verstehen und NEU implementieren. Dies wird in C++ als das INTERNE Protokoll/Interface bezeichnet und ist gerade in einem Framework das auch für das Verhalten einer Applikation einen Rahmen festlegt von entscheidender Bedeutung.

Wird z.B. die Kindliste eines Parts modifiziert, ruft die Methode der Basisklasse der ContainerParts die Methode Modified() auf, eine Methode der allerersten Basisklasse der Parts. Diese wiederum ruft NotifyObservers() auf, eine Methode der Root Klasse, die dadurch alle Observer dieses Parts von einer wichtigen Änderung unterrichtet. Damit wird Verhalten festgelegt, auf das Clients vertrauen. Neuimplementierungen eines Parts ohne Ableitung eines Default Parts sollten sich identisch verhalten!!!

Problem: Das Erben von Verhalten und Implementation in C++ bringt auf Seiten der logischen Struktur des Frameworks große Vorteile, auf Seiten der physischen Struktur jedoch compile und link Abhängigkeiten die den Nutzen der gewonnenen Wiederverwendbarkeit in Frage stellen.

Wer im Hinblick auf seine Applikation Domain den Fehler macht und das falsche Prinzip der Felxibilität einsetzt, wird z.B. durch die sog. „Explosion der Klassen" bestraft. Bei Dokumenten ist z.B. nur ein Lego Prinzip sinnvoll - die Realisierung neuer Dokumenttypen und Elemente ausschließlich über statisches Ableiten führt in kürzester Zeit zum völligen Chaos.

Erst muß analysiert werden, aus welchen Teilen Dokumente typischerweise bestehen und wie Dokumente strukturiert sind. Anschließend werden über das Composite Object (container/contained) Interface diese Teile zu jeweils neuen Dokumenten dynamisch erzeugt. Tauchen völlig neue Dokumenttypen auf, werden sie aus vorhandenen Typen abgeleitet. Ein Dokument ist NIE EIN Objekt sondern ein Baum aus verschiedenen Elementen. Nur so lässt sich die Vielfalt tatsächlicher Dokumente repräsentieren.

Ein Beispiel: Dokumentenmodell eines Belegverarbeitungssystems im Vergleich zu einem allgemeinen Dokumentenverarbeitungs Systems.

Dokumentenmodell des Belegsystems mit cold spots:

Ein Beleg wird repräsentiert durch:

struct Document {

FieldArray* pFieldArray;

Image_pointer pVorderseitenBild;

Image_pointer pRückSeitenBild;

Image_pointer pBitonalesBild;

Beschreibungs_pointer pBeschreibung;

}

Ein Belegcontainer durch:

struct Stapel {

DocumentArray* pDocumentArray;

}

Dieses Modell ist zugeschnitten auf eine Belegverarbeitung bestimmter Art in Verbindung mit bestimmer Hardware. Wenn dann noch das Speichersystem diese Strukturen fix kennt und darauf ausgerichtet ist, dann entsteht eine sehr schnelle jedoch auf solche Dokumente zugeschnittene Software.

Neue Formulartypen die z.B. aus mehreren Belegen pro Formular bestehen lassen sich in dieses Modell nur schwer integrieren. Wie soll der innere Zusammenhang der Belege pro Formular ausgedrückt werden? In OLDSYS wurde versucht dies durch Kunstgriffe wie z.B. die Einführung von Teilcontainern zu beheben. Diese waren jedoch nicht vorgesehen gewesen und führten zu aufwendiger ad-hoc Programmierung.

([BMEYER97] enthält interessante Zahlen über Typen von Änderungen und damit verbundener Softwareaufwand. Erstaunlich ist, dass Änderungen der Datenstrukturen zwar fast alltäglich sind, die meisten Programmierer jedoch zu programmieren als ob dies der grosse Ausnahmefall wäre.)

Dokumentenmodell des allgemeinen Dokument Processing Systems:

Ein Dokument wird repräsentiert durch einen Graphen aus beliebigen Elementen, genannt parts. Auf nichttextuelle Parts wird über Links zugegriffen, im Dokument ist nur die Strukturinformation dazu vorhanden

Es gibt ContainerParts und MonoParts. Alle Parts teilen eine gemeinsame Schnittstelle und lassen sich zur Laufzeit beliebig verknüpfen. Reichen die vorhandenen Parts nicht aus, werden neue abgeleitet und können jederzeit auch mit spezieller Intelligenz versehen werden. (Internes Traversal Pattern, intelligente Dokumente)

Ein auf dem Composite Object Design Pattern beruhendes Runtime System wirft ein interessantes Problem auf: wie sollen welche Objekte zusammengebaut werden? Irgendwo im System muss dieses Wissen vorhanden sein, am besten nicht hart codiert innerhalb einer Programmiersprache sondern leicht zugänglich und änderbar. Es braucht eine Spezifikationsmethode die mindestens die gleiche Mächtigkeit besitzt wie das Composite Object Pattern, d.h. beliebige Strukturen in Form von Bäumen oder Graphen ausdrücken kann.

Gleichzeitig muss diese Wissen aber auch SICHER verwaltet werden können. Der Aufbau eines Dokumentes muss dort beschrieben sein und Verletzungen dieser Struktur müssen entweder erkannt werden oder dürfen vom Runtime System gar nicht erst zugelassen werden.

Die Standard Generalized Markup Language (SGML) oder die Exended Markup Language (das ist die SGML Variante für das WWW) bieten genau das. SGML wurde in NEWSYS dafür eingesetzt.(zu SGML siehe [WKR96/1], zu XML siehe [KHARE/RIFKIN97]

Statische Definition der Elementstruktur eines konkreten zusammengesetzten Dokumentes: (vereinfachtes SGML).

In Worten beschreibt die Definition folgenden Zusammenhang:

Es wird ein Dokumenttyp „KaugAnträge" (Antrag auf Konkurs-Ausfallgeld) definiert, der sich auf der ersten Ebene in „Anschreiben und eine beliebige Menge von Elementen des Typs Kaugantrag (jedoch mindestens einer) zusammensetzt. Diese Elemente wiederum setzen sich aus weiteren Elementen zusammen usw. Es entsteht ein Baum.

<!Doctype KaugAnträge (Anschreiben, Kaugantrag+)>

<!Element Anschreiben (Firmenbriefkopf,Allgemein,Gruß)>

<!Element KaugAntrag (KaugAntragSeite1, KaugAntragSeite2)>

<!Element KaugAntragSeite1 (PersAngaben,FirmenAngaben,Unterschrift)>

<!Element KaugAntragSeite2 (Gehalt,Zeit,Unterschrift)>

<!Element Firmenbriefkopf ......

<!Element Allgemein ....

<!Element Gruß ....

<!Element PersAngaben (Adresse, Name, Vorname, Alter)>

<!Element Adresse (Stadt, PLZ, Strasse)>

Die Strukturelemente eines Dokumenttyps KaugAnträge werden definiert. Dies macht die logische Elementstruktur dieses Dokumentes aus.

Unabhängig davon gibt es einen Dokumenttype „Beleg" der folgendermaßen strukturiert ist:

<!Doctype Beleg - - (VorderSeitenBild?,RückSeitenBild?,BitonalBild?)>

<!Element (VorderSeitenBild,RückSeitenBild,BitonalBild) (PageSpec)

<!ATTLIST (VorderSeitenBild,RückseitenBild,BitonalBild)

picture ENTITY #IMPLIED

„

„>

Der Dokumenttype „Beleg" beschreibt physische Charakteristiken der physischen Formulare hingegen beschreibt der Dokumenttyp KaugAnträge lediglich die logische Struktur von physischen Dokumenten.

Zusätzlich steht in der Verarbeitungsbeschreibung zu diesem Dokument, daß den Elementen Anschreiben, KaugAntrag1 und KaugAntrag2 jeweils ein Dokumenttyp Beleg zugeordnet ist.

D.H. einfach ausgedrückt, daß der Dokumenttype Kauganträge aus einem Formular Anschreiben mit Vorder und Rückseite (man hätte auch einen nur Vorderseiten-Beleg konfigurieren können) und einer Menge von Anträgen besteht. Jeder Antrag besteht aus 2 Blättern, also 4 Seiten) und daß jeweils Blatt eins und zwei zusammengehören.

Verbinden der logischen Struktur mit echten Klassen eines Frameworks

1) Aufbauen der MetaInformation

Aus diesen Informationen kann dann ein sog. Partbuilder zur Laufzeit aus vorhandenen Parts einen Baum aufbauen, der dieses Dokument Kauganträge durch ein Composite Object aus C++ Part Objekten repräsentiert.

2) Aufbauen eines Process Parts als composite object durch den PartWeaver

Der PartWeaver bildet Meta Information in Klassen der Programmiersprache ab und verknüpft sie unter den verschiedenen Aspekten die in der Metainformation gespeichert sind (Dokumentbeschreibungen, Validierungen, Workflow Beschreibungen, Prozessbeschreibungen etc).

In Wirklichkeit sind Workflow Elements und Document Elements in verschiedenen Graphen (Aspekten) wobei Workflow-Elemente Referenzen auf Document-Elemente haben, jedoch nicht umgekehrt (dies würde zu viel Verarbeitungslogik in die Dokumente bringen) Der Client kann je nach Anwendung das Composite Object als Black Box betrachten oder Informationen über seine Struktur erlangen.

PartBuilder und PartWeaver sind nur Implementationen von SGMLApp Interface und sind ihrerseits in eine Builder Factory enthalten.

Zur Laufzeit kann dann dieser Graph durchgegangen werden und auf seine Validität geprüft werden. Selbstverständlich muß auch das Speichersystem diese Flexibilität besitzen, wie sie z.B. für Bento (Grundlage von OpenDoc) oder Structured-Storage (MFC) typisch ist.

Physische Charakteristiken und Workflow Information wird ebenfalls zur Laufzeit in diesem Baum integriert. Diese Information ist ebenfalls wieder in Form von Dokumenten gehalten. (Selbstbezügliches Prinzip)

Laufzeit Struktur des zusammengesetzten Dokumentes als directed acyclic graph (DAG)

Hier handelt es sich um die „flache" Sicht. Clients können diesen DAG extern traversieren und manipulationen an seiner Struktur vornehmen, z.B. Workflow Elemente einfügen oder entfernen. Typische Clients sind Dokument oder Workflow Editoren.

Nicht sichtbar in diesem chart sind die Links von Workflow Elementen zu documents und ihren Teilen. Aus Beschreibungen der Documente und des Workflows (in SGML) werden zur Laufzeit zueinander orthogonal stehende Graphen aus Implementationen von Parts. Clients die auf dieser komplexeren Struktur arbeiten wollen verwenden Methoden des Part Interfaces die ein INTERNES Traversieren ermöglichen, d.h. sie behandeln das ganze Composite Object (das in seiner Zusmmensetzung einem Dokumentenspezifischen Workflow entspricht) als „black box" und sprechen im wesentlichen mit dem top part des compositums. Interne Struktur des Compositums bleibt ihnen verborgen (macht clients unabhängig) und das Compositum selbst kann eigene Intelligenz einsetzen um z.B. bestimmte Prüfungen durchzuführen oder einen gewissen workflow zu starten. Erst in diesem Modus wirkt sich die Kapselung von Intelligenz und Struktur im composite object design pattern voll aus.

Typische Clients sind hier branchenspezifische Editoren die einen Workflow voraussetzen, z.B. die Bearbeitung von kritischen Dokumenten in Banken (Schecks, Einzahlungen etc.) Hier kann der User nicht frei editieren sondern muss durch einen validierenden Workflow geführt werden.

Z.B. werden die Workflow-Parts Änderungen an der Struktur des Dokuments (sie erhalten natürlich Nachricht von solchen) nicht zulassen. Der branchenspezifische Editor wird die Workflow-Elemente des Kompositums überhaupt nicht anzeigen, da sie für den Bearbeiter in diesem Arbeitsschritt nicht änderbar sind.

Sämtliche Parts sind aus der Konfiguration heraus mit Workflow (Prüf) Information versehen, sei es durch Einfügen von Prüfobjekten oder durch Aktivieren eigener Methoden. Der Status des obersten Dokument-Container Parts wird z.B. erst dann auf gut gehen, wenn die Stati seiner Kinder gut sind.

Browser und Editoren können jetzt auf diesem Graphen arbeiten und Änderungen vornehmen, deren Gültigkeit jedoch von den beteiligten Parts intern geprüft werden.

Über den Beleg-Part erhalten die Browser und Editoren die Bilder und können diese manipulieren. Die Graphstruktur erlaubt das Bearbeiten beliebiger Dokumente.

Dies war ein Beispiel für Erweiterung und Flexibilität durch Zusammensetzung. Bei anderen Punkten wird man sich für die Erweiterung durch Ableitung entscheiden. Hier entscheiden die Mechanismen der physischen Struktur, ob eine Änderung des Frameworks selbst (durch compilieren, linken oder dynamisches Einbinden) erfolgt oder ob die Erweiterung in einem Branchen Package landet, wo sich wiederum die Frage des compilieren, linken oder dynamisch Einbinden stellt.

Anmerkung zu orthogonalen Graphen

Bei dem geschilderten Composite Object Design Pattern mit externem und internem traversieren handelt es sich um eine Art Meta-Pattern für Frameworks. Fresco und (M)ET++ verwenden z.B. dieselbe Architektur für andere Zwecke.

NEWSYS spezifisch ist das Konzept der othogonal verlinkten Graphen mit gleichzeitiger aktiver Verbindung zum User Interface. D.h. zu jedem Zeitpunkt konnten entweder vom User oder von der internen Workflow Logikänderungen am Dokument vorgenommen werden. Die Graphen waren dabei verantwortlich für die ununterbrochene Validität des Dokumentes. Dokument Views wurden durch update Methoden des Observer Patterns benachrichtigt. Graphinterne und Intergraph- Kommunication lief über Messages.

Die einzelnen Workflow-Parts waren je nach ihrer speziellen Zielrichtung in unterschiedlicher Höhe des Graphen untergebracht:

Diese Hierarchie spiegelt die Aufteilung des Gegenstandsbereiches „gescanntes Dokument", dessen Validität aus den vier Kriterien besteht:

• Pragmatik: z.B. Vier Augen Prinzip bei Banken

• Semantik: z.B. Zusammenhang zwischen Bankleitzahl,Kontonummer u. Adresse

• Syntaktik z.B. Hat Kontonummer das richtige Format?

• Lexikalik z.B. Hat die OCR Erkennungsfehler signalisiert?

Übergeordnete Parts haben damit die Möglichkeit externes Wissen zur Korrektur unterer Parts einzusetzen bzw. Zusammenhänge zu erkennen. Neben der Kommunikation durch Messages konnten Parts Informationen in einem Dokumentglobalen Namespace deponieren bzw. sich dort für bestimmte Informationstypen registrieren lassen. Hat ein Part eine Information deponiert, bekamen die registrierten Parts eine Update meldung. Dieser Mechanismus (ähnlich dem CORBA naming service) ist gerade in C++ frameworks wichtig, da er die dauernde Anpassung von Methoden durch zusätzliche Parameter unnötig macht.

Einführung von MetaObject Protokollen (Reflection Design Pattern)

Im Laufe der Entwicklung von NEWSYS wurde das SGML Sub-framework immer stärker für die validierte Erzeugung und Verwaltung von Metainformationen eingesetzt. Zielpunkte der Metainformation waren:

1. Erweiterung oder Änderung von Basis Funktionalität (z.B. über Einträge im Implementation Repository)

2. Nutzung der Metainformation für generisches Processing (dynamische Views, dynamisches Erzeugen und Auswerten von Datenbanken etc.)

3. Deskriptive Applikation Domain Languages

4. Automatische Validierung von Abläufen

Abänderung von Basis Funktionalität

Eine wesentliche Voraussetzung von Flexibilität ist die Möglichkeit, über ein Reflection API Zugriff auf interne Mechanismen des Frameworks zu erhalten und diese erweitern bzw. abändern zu können. Jedes Framework enthält noch sog. „cold spots" die mit den normalen Mitteln (Ableitung oder Composition) nicht leicht zu ändern sind.

Ein flexibles Framework wird auch Dinge wie Collaboration von Klassen zur Erzeugung eines Ablaufes in Klassen ausdrücken und zugänglich machen.

Ziel ist hier die „Open Implementation" zu erreichen.

Schöner noch wäre es, die dahinterliegenden Design Patterns auch programmatisch fassen zu können. Die UML1.0 bietet jetzt die Möglichkeit z.B. solche Design Patterns als „parametrisierbare Collaboration" Klasse zu fassen.[UML1.0]

Nutzung von Meta Information für generisches Processing

Ein reflektives Moment des NEWSYS Frameworks ist die symbolische Repräsentation der Applikationsinformation in SGML Dokumenten statt im Source Code. Alle Teile des Frameworks können Metainformationen über Dokumente aus Dokumenten gewinnen und daraus z.B. einen speziellen View aufbauen oder ein Datenbank Schema generieren. Symbolische Requests verwenden diese Metainformation zum Mappen von Tokens und Views auf Values.

Dass dies möglich ist, zeigt nicht zuletzt auch das von Christoph Sutter entwickelte FISH, flexibles Infomationssystem für Hypermedia, [SUTTER97].

Unabhängigkeit von Implementationen durch Descriptive Application Domain Languages

Im NEWSYS Framework werden Dokumentbeschreibungen, Workflow Spezifikationen etc. häufig als „Konfiguration" bezeichnet. Dies ist jedoch ein historisch bedingtes Erbstück aus dem OLDSYS Produkt. In Wirklichkeit handelt es sich um Instanzen kleiner, rein descriptiver Applikation Domain Languages. Die Erstellung einer SGML Document Type Description ist ähnlich der Erstellung einer Applikation Domain Language.

Diese Languages bilden einen Aspekt der Applikation Domain ab und zwar unabhängig vom Runtime System rein deskriptiv.

Beispiel: Archivierung von Dokument und Prüfprozeduren

OLDSYS enthielt einen Mechanismus, um die binären Prüfprozeduren zusammen mit den Dokumenten zu speichern. In der Praxis wurde dieser Mechanismus aus verschiedenen Gründen nie benutzt. Einer davon war sicher, dass die Wahrscheinlichkeit, dass ein OLDSYS Runtime System in 2 Jahren noch die binären Prozeduren würde ablaufen lassen können, wohl als sehr gering angesehen wurden.

Java Programmierer werden an dieser Stelle die Plattformunabhängigkeit von Java hervorheben sowie die physische Flexibilität des dynamischen Linkens. Demgegenüber lässt sich nur hervorheben, dass typische Archivierungszeiten z.B. in der Versicherungsbranche über 100 Jahre sein können!

Mit NEWSYS konnten die Prüfprozeduren DESKRIPTIV erstellt werden. Über mapping Documente wurden sie mit programmatischen Objekten des Frameworks verknüpft. Die Konsequenz war, dass ein Workflow ganz anders implementiert werden konnte, die Spezifikation des Workflows davon aber unberührt blieb.

Dies war gleichzeitig einer der Punkte die zum dauernden Konflikt mit den Mitgliedern des OLDSYS Teams führten. Das Bemühen des Framework Teams zu logischen Beschreibungen der Validität eines Dokumentes zu gelangen, um Freiräume für die Implementation zu erhalten stiess auf völliges Unverständnis. Für OLDSYS Entwickler sass die Logik eines Dokumentes im Source Code, nicht in abstrakten Beschreibungen.

Validierung von Implementationen durch Metainformation

Von der Implementation unabhängige Beschreibungen der Struktur von Dokumenten und der Logik ihrer Bearbeitung sind sicher aus einem Wartungs- und Flexibilitätsgedanken heraus wichtig.

Der wirkliche Vorteil dieses Verfahrens liegt jedoch in der plötzlich möglichen automatisierten Überprüfbarkeit der Implementationen.

Wenn die Logik einer Bearbeitung wie in OLDSYS im Source Code versteckt ist, dann sind die Kriterien für eine Prüfung der Logik entweder im Kopf des Entwicklers oder in Dokumenten zur Prüflogik versteckt und damit für eine automatische Prüfung der Implementation nicht zugänglich.

Beispiel: automatische Prüfung der Validierung von Dokumenten

Voraussetzungen:

1. Spezifikation der Semantik eines Dokuments als MetaInformation

2. Runtime Support zur Informationsgewinnung

Ad 1) Die Kriterien der Semantik eines Dokuments werden in einem MetaDokument erstellt. Dies kann die Form einer State Tabelle haben in der der Entwickler für jeden Bearbeitungsschritt legale Zustände des logischen Dokumentstatus definiert.

Ad 2) Das Problem der Debug Information ist typischerweise, dass sie aus Performance Gründen nur während der Entwicklung im Source Code aktiviert ist und damit nicht einfach durch eine Option eingeschaltet werden kann oder dass die falschen Daten ermittelt wurden, die gerade für den momentanen Fehlerfall nicht aussagekräftig sind.

Der Einsatz des Wrapper Design patterns löst beide Probleme. Eine Wrapper Klasse besitzt das selbe Interface wie die zu wrappende Klasse, d.h. in diesem Fall wie die Dokument und Workflow Parts. Zur Konstruktion Zeit entdeckt z.B. eine Partfactory, dass für den verlangten Part ein Wrapper Part definiert ist.(d.h. DYNAMISCH!)

Sie erzeugt beide Parts und fügt den zu wrappenden Part in den Wrapper Part ein. Ab diesem Moment ist die Tatsache, dass hier 2 Objekte existieren für Clients nicht mehr sichtbar.

Der Wrapper Part empfängt automatisch alle Methodenaufrufe an den eingeschlossenen Part und leitet sie an den Part weiter. Davor und danach hat er die Möglichkeit Ergebnisse zu protokollieren (die er z.B. vor und nach dem Methodenaufruf vom eingeschlossenen Part abgefragt hat). Damit kann z.B. die Statusänderung eines Parts verursacht durch einen Methodenaufruf protokolliert werden.

Das entstandene Protokoll kann jetzt durch ein Tool aufbereitet werden, z.B. kann geprüft werden, ob zu irgeneinem Zeitpunkt ein Partstatus nicht mit dem in der MetaInformation spezifizierten Status übereinstimmt.

Das Ergebnis ist ein validierter Workflow, z.B. Firma X kann einem Kunden aus dem Bankenbereich nachweisen, dass ihr Workflow zur Scheckbearbeitung den rechtlichen Richtlinien der Scheckverarbeitung genügt.

Natürlich lässt sich mit dem Wrapper Design Pattern auch ein rein technisch orientiertes Debugging in einem Framework durchführen. Wrapper Parts sind ebenfalls über das Implementation Repository erzeugbar, d.h. sie sind ohne physische Konsequenzen austauschbar und neue können hinzugefügt werden.

Wrapper Parts können natürlich auch ausserhalb eines konkreten Debuggings als Trigger auf bestimmte Fehlerbedingungen eingesetzt werden (Watchdog) ohne dass der Code von existierenden Parts geändert werden muss.

Er beinhaltet neben den Interface Definitions für alle Domains auch Default Implementationen von Klassen die einerseits für das Framework selbst nötig sind als auch zur Ableitung zur Verfügung stehen und ein default Verhalten implementieren.

unter NEWSYS/Branches/..... finden sich Implementationen, die nur für bestimmte Branchenanwendungen sinnvoll sind.

Packages branchenspezifischer Domains haben drei Möglichkeiten Kernel Packages zu nutzen:

Die drei Möglichkeiten des Package übergreifenden Implementation Reuse gelten für alle Extensions. Aus Wartungsgründen sind nur 2) und 3) empfehlenswert.

Der Begriff „Systemspezifisch" bzw. „ betriebssystemspezifisch" ist doppeldeutig. Er bezeichnet einmal Funktionalitäten einer LOGISCHEN Domain System, ähnlich der Base Domain. Ein Beispiel dafür sind Transport Endpunkte wie Sockets, Named Pipes, Message Queues etc.

Zum anderen bezeichnet er Funktionalitäten die vielleicht auf verschiedenen Plattformen verschieden implementiert werden müssen, OBWOHL die Funktionalitäten selbst keineswegs zur logischen Domain SYSTEM gehören. Mit „verschieden implementiert" ist gemeint, daß die Art und Weise der Implementation SO SEHR UNTERSCHIEDLICH IST, daß kein gemeinsames Source File sinnvoll ist wenn man nicht einen Wald aus „#ifdefs" einführen will. Aus dieser Doppeldeutigkeit entstand einige Konfusion bezüglich der physichen Teile die unter NEWSYS/OS gehören. Deshalb wiederholt sich die allgemeine Domainstruktur (Base, Dmc, Pdc, HIC unter NEWSYS/OS.

Innerhalb des NEWSYS Frameworks werden betriebssystemspezifische Klassen und Funktionen auf folgende Weise intergriert:

Zunächst wird für den gewünschten Service ein Interface in Form einer V Klasse definiert. Dieses Interface befindet sich im interface directory der jeweiligen Domain. Die Implementationen des Services befinden sich in den Directories w32 und os2 unter NEWSYS/os. Für den Framework Kernel ist die Tatsache unsichtbar, daß eine Objektimplementation Betriebssystem spezifisch ist. Die Generiergungsstruktur (imake, cvs) stellt sicher, daß die entsprechenden Packages für jede Plattform erstellt werden.

Historische Besonderheit: OLDSYS Kompatibilitätskomponenten die ursprünglich unter MS-DOS entwickelt wurden beinhalten plattformabhängige Teile. In einem ersten Ansatz (der falsch war) wurden diese Teile unter NEWSYS/OS/os2 eingehängt. Dies ist jedoch aus 2 Gründen unsinnig: Erstens sind nur sehr wenige Teile darin plattformabhängig die sich leicht mit einigen Macros beseitigen lassen. Zweitens gehören sie NICHT zur SYSTEM Domain.

Mittlerweile sind diese Teile mit wenigen Macros plattformunabhängig gemacht worden, womit jeglicher Grund für ihre Existenz unter NEWSYS/OS weggefallen ist. Sie sollten unter Kernel/DMC eingehängt werden.

Regeln für Entities unter NEWSYS/OS:

Wenn ein Service System oder Base Charakter hat ist er ein Kandidat für die logische Domain BASE, sein Interface gehört unter Kernel/Base/intinc. Kann er mit GERINGEM Aufwand plattformunabhängig in einem Source File gemacht werden, sollte seine Implementation auch wirklich in einem File zusammengehalten werden. Wo soll dieser Service physisch in die Source Struktur eingehängt werden?

Die dauernden Erweiterungen zentraler Packages wie z.B. BaseKern.dll ist schädlich. Besser ist es, die Implementation unter NEWSYS/Os/common/Base einzuhängen. Eventuell sollte das Sysutil Kit erweitert werden oder der Service bekommt sein eigenes Package.

Wenn ein Service KEINEN System oder Base Charakter hat aber dennoch völlig unterschiedlich implementiert werden muß: Sein Interface kommt unter das interface directory der jeweiligen logischen Domain. Seine Implementation kommt unter NEWSYS/OS/$(Architecture)/Domain/implementations für die jeweils unterstützten Architekturen, wobei Architecture für UNIX ¦ OS2 | W32 steht.

Solange es geht sollte man COMMON SOURCE CODE anstreben. Dies vereinfacht die Wartung erheblich!!!

Da das Laden von Komponenten über das Implementation Repository symbolisch und dynamisch erfolgt, ist es dem Framework egal, wieviele Packages existieren bzw. welche Services in welchen Packages stecken. Das Generiertool sorgt bei neuen include Pfaden ohnehin dafür, daß mit einer einzigen zentralen config/cf/xxx Änderung alle Projekte automatisch updatebar sind.

Eine Erfüllung der obigen 6 Kriterien war mit den zur Verfügung stehenden Tools (IBM C-set, Visual Age, Visual C++) nicht möglich. In einem selbst erlebten Fall dauerte es 1 Woche bis ein bestimmtes Release eines Prototypen von einem anderen Mitarbeiter erzeugt werden konnte. Er musste dazu ca. 30 Dlls erzeugen sowie Konfigurationen anpassen deren überwiegende Zahl für ihn völlig bedeutungslos war.

Detailkritik:

Ad 1) Definiertheit der Umgebung

Basis eines jeden Produktionsprozesses ist die Definition von Sources, Werkzeugen, Abläufen, Ergebnissen und Installationen. Diese Definition hat an EINER Stelle zu erfolgen. „Private" lokale Definitionen zerstören den einheitlichen Produktionsprozess. Die genannten IDEs lassen eine globale Definition des Produktionsprozesses (unter Berücksichtigung lokaler Gegebenheiten wie abweichende Drives oder Volumes) nicht zu. Z.B. war es mit dem IBM Workframe nicht möglich, bestimmte Defines für alle Entwickler auf allen Maschinen zu setzen.

Ad 2) Qualitätsgesicherte Produktion

Ein qualitätsgesicherter Produktionsprozess setzt die Definiertheit (siehe 1) und automation voraus. Alle betrachteten Tools zwangen zu interaktiven Anpassungen und Eingaben. Inkompatibilitäten der Module durch falsche Optionen oder Tools waren die Folge. Es war implizites Detailwissen zur Produktion nötig.

AD 3) Automation des Produktionsprozesses

Ein Produktionsprozess darf keine interaktiven Eingaben enthalten aus 2 Gründen: Um Fehler zu vermeiden und Zeit zu sparen. Es ist nett wenn man durch GUIs Optionen wählen KANN. Wenn fortwährend Optionen gewählt werden MÜSSEN (z.B. beim Aufsetzen eines neuen Projektes im gleichen Buildprozess) entsteht ein Wartungsalptraum.

GUIs sind nicht die richtige Lösung für einen Produktionsprozess

Wenn z.B. der Produktionsprozess definiert an einer Stelle geändert wird, muss EIN Kommando genügen um ALLE Projekte die sich lokal auf Maschinen befinden automatisch andzupassen.

Nicht nur Projects, auch die insgesammt nötigen Tools müssen automatisch installiert werden.

Ad 4) Multi – user fähig

Keine der genannten IDEs unterstützt Multi-User Entwicklungen. Jeder Entwickler setzt GUI gestützt seine eigene Entwicklungsumgebung auf. Es gibt keinen Automatismus zum erzeugen fremder Module auf der eigenen Maschine.

Ad 5) Flexibel

Grössere Entwicklungen benötigen immer wieder spezielle Schritte bei der Generierung, teilweise auch als Workaround um Limits der IDEs (Anzahl Files, Ablauf Definition nur durch File Extensions bestimmbar, Environment Grösse zu knapp etc.). Plattformunabhängigkeit zwingt ebenfalls zu grosser Flexibilität. Z.B. musste der Build auf Microsoft Plattformen plötzlich den Package Namen über ein CC – define in den Source Code reichen. Ohne ein flexibles Tool bedeutet dies ein Anpassen aller Projekte!

Konvertierungen und anderes Processing muss sich an jeder Stelle des Produktionsprozesses enfügen lassen, ohne dass alle Projekte geändert werden müssen.

Lokale Besonderheiten auf Maschinen dürfen keine Rolle spielen (IBM Workframe enthielt z.b. die Source Pfade ABSOLUT!

Alle Definitionen müssen SYMBOLISCH sein. Sinnvolle Default Mappings zu harten Pfaden etc. existieren, können aber lokal überschrieben sein.

Der Produktionsprozess muss in der Lage sein verschieden Releases oder Modes (Profiled, Debugged, Produktion) auf EIN Kommando hin zu erzeugen, OHNE dass lokale Einstellungen bei Projekten erfolgen. Dies wiederum setzt eine definierte Source und Installationsstruktur voraus die es erlaubt, verschiedene Versionen oder Modes von Modulen GLEICHZEITIG zu verwalten.

Ad 6) Plattformunabhängig

Bei Microsoft ohnehin kein Thema. IBM Tools längst noch nicht auf allen Plattformen obwohl ein Weg dorthin sichtbar ist. Ein besonderes Problem stellen kleine Tools und Scripts dar, wenn sie beim Produktionsprozess eingesetzt werden. Die GNU Utilities helfen hier plattformübergreifen. Wichtig ist die verwendete Script Sprache. Sie sollte ebenfalls plattform unabängig sein, was z.B. bei Rex (visual rexx etc.) nicht unbedingt der Fall ist bzw. war.

IDEs sind typischerweise zugeschnitten auf einen einzelnen Entwickler. Wenn z.B. das Framework oder die Applikation im Laufe der Zeit immer modularer wird (was eigentlich gut ist) steigt gleichzeitig der Aufwand bei der Übersetzung und Installation. 50 Services in dynamik link libraries oder exe files bedeuteten z.B. beim IBM Workframe 50 verschiedene Projekte mit harten Source Pfaden. Mal genommen mit der Anzahl der Entwickler kann man sich schnell ausrechnen, dass die Wahrscheinlichkeit dass alle Optionen auf allen Maschinen bei allen Entwicklern gleich sind, gleich NULL ist. Obskure Runtime Probleme sind die Folge.

Die Entwicklungsumgebung für Frameworks oder grössere Applikationen muss auf Knopfdruck automatisch installiert werden können. Die einzelnen Projektfiles gehören zum Source Code. Selbst bei der ohnehin zu empfehlenden Trennung von Interface und Implementationsklassen bleibt ein Rest von compile oder linktime Abhängigkeiten.

Letzten Endes waren wir bei NEWSYS gezwungen auf das imake tool aus der XWindow Umgebung zurückzufallen - sehr zum anfänglichen Missfallen der GUI orientierten Kollegen - die jedoch nach erfolgreichen automatischen Generierungen schnell begeistert waren.

Wichtig für Benutzer eines Frameworks - egal ob reiner Benutzer (black box) oder Erweiterer (white box): Nur ganz wenige Entwickler kennen die internen Abhängigkeiten der Module und Packages untereinander. Deshalb muss auf automatische Weise sichergestellt werden, dass die benötigten Module auch generiert werden.

Die meisten sog. IDEs unterstützen weder grössere Gruppen von Entwicklern noch bieten sie einen automatischen und daher qualitätsgeprüften Entwicklungsprozess. Die komplette Kontrolle des eigenen Produktionsprozesses ist unabdingbar. Ressourcen sind dafür einzuplanen.

Zur Zeit ist noch der grösste Teil der im Entwicklungsprozess verwendeten Tools Filebasiert. Zunehmend werden jedoch von Toolherstellern Repositories eingesetzt, z.B. im VisualAge Java der IBM. Grund für die Einführung eines Repositories ist der Wunsch, die Granularität von Änderungen kleiner als nur pro File zu bestimmen, z.B. übersetzt ein inkrementeller Kompiler nur die Methoden, die sich tatsächlich geändert haben. Dies bringt eine schnellere Übersetzungszeit. Zusätzlich kontrolliert das Repository noch Abhängigkeiten zwischen Klassen, z.B. wenn sich eine Methode einer Klasse ändert, wird der Programmierer automatisch auf betroffene abhängige Klassen hingewiesen.

Auch hier wird der Zwang zur dynamischen Verwaltung von Informationen sichtbar da sonst Äbhängigkeiten (die als Links ausgedrückt werden können) nicht direkt verfolgt werden können.

Diese Entwicklung ist sicherlich zu begrüssen im Sinne grösserer Sicherheit der Generierung. Problematisch wird es für einen automatischen Build, wenn kein Zugriff auf das Repository in 2 Richtungen möglich ist. Ein API zum Repository muss gestatten, die Informationen auszulesen bzw. neu zu setzen. Sonst ist eine Integration der Information in übergeordnete Repositories nicht möglich.

Eine weitere Schwierigkeit von Repositories liegt darin, dass sie plötzlich auch sämtliche Aufgaben eines Source Code Control Systems übernehmen müssen (Multi-User Fähigkeit etc.). Ein Tool wie CVS oder Clearcase „sieht" nur noch ein File (der Inhalt des Repositories), d.h. bisher übliche Massnahmen zur Verwaltung von Änderungen (z.B. in Verbindung mit einem Error Tracking System) funktionieren nicht mehr. Nur das Repository weiss über Änderungen bescheid.

Man kann sich vorstellen auf welche Schwierigkeiten man in einem auf distributed objects basierenden System stösst, mit IDL Spezifikationen, Java und C++ Klassen, Runtime Environment in Form von Naming Service (abgebildet auf DCE) und Modellierungstools wie Rose oder Paradigm. Fast jedes dieser Tools besitzt ein eigenes Repository. Wie sollen diese Repositories synchronisiert werden ohne massiven manuellen (und daher fehlerträchtigen) Einsatz?

In einer solchen Umgebung ist es bereits ein grosses Problem die Konsistenz des Systems sicherzustellen. Es müssen dazu:

Darüber hinaus wird es in Zukunft noch viel wichtiger sein, VOR einer Änderung ihre Auswirkungen bestimmen zu können. Wie kann dies geschehen wenn noch nicht einmal klar ist, WO Änderungen anfangen? Fängt der Entwicklungsprozess mit einem OO-Modell an? Fängt er auf Grund von Legacy Applikationen mit einem Entity-Relationship Modell existierender Datenmodelle an? Fängt er mit GUI Ressource Files an?

Ich weiss auf diese Fragen zur Zeit keine Antwort. Die Vorstellung eines zentralen Repositories mit ALLEN Inhalten ist attraktiv, in der Praxis jedoch nicht machbar. Nötig wäre ein Workflow System der Generierung, basierend auf Tool-unabhängigen Informationen und dynamisch mit Behavior verbindbar. Voraussetzung dafür sind APIs zu den Tools und Repositories sowie eine Sprache die in der Lage ist, beliebige Inhalte und ihre Verbindungen auszudrücken: SGML/XML. Dies widerspricht natürlich dem Interesse der Hersteller, die statt modulare Verwendbarkeit nur allumfassende IDEs anstreben.

WARNUNG: Wer Tools mit Repositories anschafft, sollte sich über die dadurch entstehenden Abhängigkeiten vom Hersteller sowie die Auswirkungen auf den Generierungsprozess im Klaren sein.

Der Source Code des NEWSYS Frameworks wird auf einem zentralen Server mit den plattformunabhängigen Tools RCS und CVS verwaltet. Entwickler arbeiten mit lokalen Bäumen, die durch CVS upgedatet und verwaltet werden können. Zu beiden Tools gibt es umfangreiche Dokumentation. Source Code Verwaltung muss vom Build Prozess aus erreichbar sein, z.B. um geänderte Versionen auf Kompatibilität der Interfaces zu untersuchen.

Dazu wird das Tool Imake verwendet. In der NEWSYS Version 1.0 stehen die zentralen Config Files unter NEWSYS/config/cf, in der Version 2.0 (OS2 und W32) ist Imake ein eigenes Projekt und die anderen Projekte überschreiben in ihrem config/cf Verzeichnis lediglich was unbedingt nötig ist. Dieses Konzept folgt einem Vorschlag aus dem Buch zum Imake.

Alle für NEWSYS nötigen Fremdprodukte, soweit sie im Hause selbst generiert werden, befinden sich im automatischen Generierprozeß.

Dieser Prozess umfasst:

In jedem Verzeichnis das automatisch bearbeitet werden soll, befindet sich ein sog. Imakefile - die Projektbeschreibung. Er enthält keine plattformabhängigen Optionen sondern gilt für alle Plattformen gleich. Plattformabhängige Optionen stehen in speziellen globalen config Dateien. Aus ihnen und den Anweisungen des Imakefiles sowie den Regeln des imake.rules files wird ein Makefile automatisch generiert der hochgradig plattform,host und user abhängig ist. Dieser Makefile erzeugt das oder die Targets die im Imakefile beschrieben sind.

Der wesentliche gedankliche Unterschied zwischen Imake und IDEs ist, dass Imake ganz im SGML Sinne eine blosse Beschreibung der Materialen, Tools und Abläufe in strukturierter Weise gestattet. Das Imake Tool bearbeitet diese Beschreibungen und erzeugt Makefiles. An KEINER Stelle werden Definitionen des Build Prozesses verdoppelt sondern die Abläufe werden IMMER aus diesen Definitionen erzeugt. Es gibt keine Teilung des Produktionsprozesses in Dokumentation der Definitionen und Projektfiles die diese Definitionen enthalten (verdoppeln). Die Definitionen selbst sind immer verfügbar für die Definition neuer Abläufe und verschwinden nicht in obskuren binären Project Files.

So wie das Source Control System dafür sorgt, dass es von jeder Version eines Sources nur EINE Entity gibt, so sorgt das Imake System dafür, dass vom Source des Produktionsprozesses selbst (Definitionen und Regeln) nur EINE Entität existiert.

Ein auf strukturierten Beschreibungen basierter automatischer Generierungsprozess ist übrigens kompatibel mit der Verwendung von IDEs. Dazu gibt es zwei Möglichkeiten:

Jeder Projektmanager sollte die Effektivität des Generierungsprozesses regelmässig testen. Ein guter Zeitpunkt dafür ist z.B. die Einstellung eines neuen Mitarbeiters.

Der Härtetest: Kann ein neuer Mitarbeiter am ersten Tag eine Version der Applikation oder des Frameworks durch EIN Kommando generieren? Auf einer bis dahin bezüglich Entwicklungsumgebung LEEREN Maschine, d.h. kein Source, keine Compiler/Tools, keine Ressourcen?

Sie sind Source Code genauso wie Ressource Files oder Header Dateien. Sie werden im Source Code Control System verwaltet und im Build Prozess konvertiert, bearbeitet und installiert.

Dazu gehören:

ALLE sind in SGML zu schreiben. Sie sind Bestandteil des Source Codes und werden beim Build prozess geparst. WEHE jemand schreibt nicht geparste Konfiguration Files in die Source Verwaltung!!!

newsrc.cmd hilft bei der Erzeugung neuer Source Files

i2rtf.exe erzeugt aus Header files automatisch Dokumentation im Rich Text Format

i2html.cmd erzeugt aus Header files automatisch Dokumentation im HTML Format.

Unter Imake/config/util befinden sich weitere kleine tools die bei der Generierung nötig sind und von dort automatisch geholt werden.

SGML Parser kann Konfigurations Files auf syntaktische und teilweise semantische Richtigkeit prüfen.

Alle Source Files haben den NEWSYS Coding Conventions zu entsprechen. Diese regeln Memory Management, Naming und Packaging etc. Class References werden automatisch erzeugt. Teil der Coding Conventions ist die Liste der Pflichtlektüre.

JEDE DOKUMENTATION ZU ARCHITEKTUR UND MECHANISMEN HAT DIE VERWENDETEN DESIGN PATTERNS EXPLIZIT ZU DOKUMENTIEREN. DESIGN PATTERNS SIND INTEGRALER BESTANDTEIL DES FRAMEWORKS.

Es gibt KEINE Ausnahme!

Standardmässig leistet ein Source Code Management Tool wie z.B. RCS/CVS speziell im Hinblick auf die Besonderheiten von C++ wenig Dienste. Eine Änderung drückt sich lediglich in einer neuen RCSID des Source Files aus. Damit ist nichts gesagt über den Scope und die Konsequenzen der Änderung:

Sinnvoll wäre ein Tag analog der Java VersionUID mithilfe dessen der Programmierer bestimmen kann, ob die neue Version einer Klasse Interface-kompatibel zur alten ist. Der symbolische Lademechanismus des Frameworks kann dann prüfen ob eine Instanz der neuen Klasse zum gegenwärtigen Zustand des Frameworks passt.

Wenn keine Interface Änderung vorliegt, kann die neue Klasse bedenkenlos zur Laufzeit instanziiert werden, da die Interface/Implementation Trennung jede Kenntnis des Clients über Methodenaddressen (ausserhalb der virtuellen Interface Methoden) verhindert. Und selbst diese sind nur als relativer Offset bekannt, d.h. die Position einer Klasse innerhalb eines Packages kann sich verschieben bzw. mithilfe der Repository Einträge sogar in ein ganz anderes Package verlagern.

Der Build Mechanismus könnte leicht so erweitert werden, dass er prüft ob eine Änderung sich auf das Interface auswirkt und dann automatisch eine geänderte VersionUID erzeugen.

Bezeichnenderweise waren auch die Taligent Leute gezwungen den Buildprozess durch eigene Tools und Compiler incrementeller zu machen. Globale Source Ids die nur die Tatsache einer Änderung signalisieren waren zu grob. Ebenso der Make Mechanismus der lediglich das globale Datum einer Änderung berücksichtigt.

Gerade in Bezug auf die Wartbarkeit wird der Vorteil von Java durch das dynamische Binden zur Laufzeit besonders deutlich. Dieses Verhalten könnte in C++ ebenfalls implementiert werden, nur müsste der dynamische Lader dann auch die Vtable der Klasse sowie interne Referenzen innerhalb der Klasse auf EIGENE virtual functions anpassen. Dieses Vorgehen wäre nicht portabel und aufwendig.

Da Objekte nicht mehr statisch miteinander gelinkt werden sondern einander über Factories oder Broker anfordern, kann es passieren, dass durch einen Konfigurationsfehler eine Klasse zur Laufzeit nicht vorhanden ist. Der Default Mechanismus des Frameworks generiert in diesem Fall eine Exception (analog CORBA_bind() exceptions) und der Client kann diese fangen und verarbeiten.

Wünschenswert wäre es, wenn der Buildprozess die Abhängigkeiten vorher festhalten und zur Verfügung stellen könnte. Beim Boot der Applikation könnte dann das Framework sicherstellen, dass alle gewünschten Klassen zur Laufzeit auch vorhanden sind oder einen Fehler mitteilen.

Folgende Voraussetzungen gelten für Fremdprodukte damit sie im Rahmen des NEWSYS Frameworks verwendet werden können.

Praktisch jede Applikation oder Toolkit benötigt konkrete Klassen wie Container, Listen etc. Alle Teile von NEWSYS sind berechtigt, diese Klassen jederzeit zu verwenden. Einzige Bedingung ist daß vorher ein Typedef auf eine NEWSYS Klasse vorgenommen wird, damit bei der vollständigen Implementation in IDL eine Wrapper Klasse definiert werden kann.

Liegt die Bibliothek im Source Code vor, wird sie auf dieselbe Weise generiert mit Imake wie auch NEWSYS und andere Produkte.

Das NEWSYS Framework verwendet zur plattformunabhängigen Bearbeitung von graphische Events eine externe Klassenbibliothek.

Konkrete Probleme bei der Integration eines sog. GUI Builders waren:

Die GUI Bibliothek wird generiert sondern auf dem ComponentServer installiert und durch Imake automatisch includiert. Neue Versionen der GUI Bibliothek (DLLs) erzwingen neue Versionen der HIC Packages des Frameworks da die Bibliothek keine Interface/Implementation Trennung kennt.

Das SP Toolkit von James Clark beinhaltet einen SGML Parser und Entity Manager. Das NEWSYS Configuration Framework verwendet dieses Toolkit zum Validieren von Dokumenten.

SP wird im Hause generiert auf den Plattformen OS/2 und W32. Das Toolkit behandelt plattformunabhängig Zeichensätze (unicode u.a.) und ist selbst durch zusätzliche StorageManager Typen erweiterbar. Momentan wird unterstützt: File Storage, HTTP, Filedescriptor etc.

Ein Resultat der Strukturdefinitionen war, dass uns Strukturen im Framework drei Probleme aufgeben:

Mittlerweile sind wir in der Lage, Framework Strukturen zu finden und zu erklären, aber bis jetzt befindet sich dieses Wissen nur in unserem Kopf. Eine systematische Entwicklung braucht mehr. Neben individuellem Training und Weiterbildung ist ein Coding Standard das erste Tool, das unser Design- und Architekturwissen sichtbar macht.

Ein coding standard in einem Framework Projekt hat NICHTS mit der Optik des Source Codes zu tun. Er ist stattdessen eine Realisierung des objekt-orientierten Wissenstandes des Teams und deckt eine grosse Zahl von micro design Fragen ab. Der Coding Standard enthält die Programmierregeln, abgeleitet aus der Erfahrung mit dem Framework. Und er enthält Markup (Auszeichnungen, visible tags) die versuchen Stellvertreter für die unsichtbaren Strukturen zu sein.

Ein Coding Standard füllt die Lücke zwischen Design/Architektur Level und der tatsächlichen Codierung.

Der coding standard eines mittleren Projektes nimmt schnell die Form eines dicken Buches an. Im ersten Moment erscheint er überaus restriktiv, man muss sich richtiggehend einleben. Hinzukommt, dass der Coding Standard kontinuierlich mit Framework und Tool zusammen weiter entwickelt werden muss. Eine dauernde Pflegeaufgabe.

Ist dieser ganze Aufwand wirklich nötig? Zum Verständnis habe ich einige - schmerzhaft erworbene - Erfahrungen meines letzten Framework Projektes zusammengefasst. Sie sind im Gegensatz zu den obigen Strukturen stark auf C++ bezogen.

Aus eigenen Erfahrungen schätze ich, dass die Einarbeitung eines neuen Mitarbeiters in eine grössere C++ Applikation ca. 1 Jahr und bei einem Framework bis zu eineinhalb Jahren dauern kann, bis der Mitarbeiter in der Lage ist, Designentscheidungen selbständig zu treffen unter Beachtung ALLER Konsequenzen auch für Auslieferung und Wartung.

Toolunterstützte Coding Standards sind hier eine grosse Hilfe. Sie entlasten den Entwickler von einem Teil der Entscheidungen, sichern dass die entstandenen Sourcen verträglich mit dem System sind und dass bestimmte Entscheidungen "defensiv" vorbelegt sind. Beispiele sind: Macros für Forward Declarations die die const Problematiken lindern, Plattformunabhängigkeit sichern und die Gefahren der automatischen Methodengenerierung durch den Compiler verringern.

Die Erstellung eines Frameworks bringt eine Welle von Konventionen und Absprachen mit sich, die Teil des Coding Standards werden müssen.. Aufgabe des Coding Standards ist es, gerade diese internen Verpflichtungen und Vorgehensweisen deutlich zu machen und ihre Einhaltung so weit möglich zu erzwingen.

Oft stellt man fest, dass bestimmte Bereiche in C++ Projekten völlig unscharf oder gar nicht definiert wurden. Gerade Systemaspekte wie Memory Management, Object Sharing und Multithreading werden nicht durch Regeln und Mechanismen erfasst.

Coding Standards sind verpflichtet in ALLEN Design Fragen eine Antwort zu liefern. Was in einem C++ Projekt nicht definiert ist, wird schiefgehen und lässt sich nur mit grossem Aufwand reparieren.

Coding Standards im C++ Bereich haben folgende Aufgaben:

Meine Erfahrung in einem grösseren Framework Projekt bezüglich Coding Standards und Tools war , dass zwischen beiden eine enge wechselseitige Abhängigkeit besteht.

C++ erzwingt strikte, teilweise unangenehme Konventionen bei der Programmierung, wenn Reuse, Wartbarkeit und Verständlichkeit ein Ziel sind. Ohne Tools die z.B. Templates fuer Header und Implementation Files erzeugen bleibt die Akzeptanz der Coding Standards gering und fehlerhaft.

Andererseits ist der Einsatz von Tools wiederum stark vom Coding Standard abhängig:

Je rigoroser und formaler die Coding Standards sind, desto leichter können Tools eingesetzt werden. Aus regel- und strukturlosem Matsch kann auch das beste Tool keine weitergehende Information erzeugen. Gerade das automatische Prozessing ist aber bei C++ wichtig, da kleine Änderungen oft grosse Source Code Auswirkungen haben. Der Einsatz von Entwurfsumgebungen wie Together++ und OEW++ hatte im Projekt NEWSYS nicht den erhofften Zuwachs an Flexibilität gebracht. Diese Tools hatten Probleme im Reverse Engineering Bereich, Schwierigkeiten mit der Integration von IDL Präprozessoren und waren generell nicht übermässig stabil. Oft blieb nur der Rückgriff auf kleine Tools wie stream Editoren oder REXX scripts.

Ohne Tools kommt ein Coding Standard nicht zum Leben. Tools müssen die Anwendung des Coding Standards erleichtern bzw. automatisieren. Andererseits können ohne die Konventionen und Namensregeln des Coding Standards einfache Tools kaum angewendet werden.

Beispiel: Ein kleines, vom Framework Team selbst entwickeltes interaktives Tool zur Erzeugung von Header und Implementation Files (sowie Interface Klassen).

Das Tool frägt folgende Facts ab:

Aus diesen Angaben erzeugt das Tool folgendes:

Ohne dieses Tool werden die Konventionen nicht eingehalten. Es fehlt noch das nachträgliche automatische Einfügen weiterer Methoden.

Jedes eingesetzte generative Tool sollte auch bereits erstellte Targets nochmals neu überarbeiten können. Gerade wenn der Source Code umfangreicher wird, sind rekursiv generative Verfahren unumgänglich.

Im NEWSYS Framework wurde das Tool an einem Wochenende in Vrexx programmiert und danach kontinuierlich erweitert, gemeinsam mit der Entwicklung der coding standards. Weitere derartige Mini Tools waren: implementation2interface (erzeugt aus einer ersten Implementation eine abstrakte Interface Klasse) sowie das umgekehrte interface2implementation.

Dank dieser Tools konnte Metainformation sowie die Class Reference aller Klassen automatisch erzeugt werden. Die automatische Dokumentation verwendete eine angepasste Version des i2rtf tools aus Fresco (erzeugt rich text format) und später i2html (erzeugt html doc.) Alle diese Tools waren sehr einfach und schnell geschrieben bzw. angepasst.

Der Beitrag kleiner selbstgefertigter Tools zur Produktivität der Framework Entwicklung ist unschätzbar. Projektleiter müssen für Entwicklung und Pflege solcher Tools Zeit einplanen.

Noch besser: Der Einsatz eines eigenen Preprocessors. Fresco z.B. enthält einen idl compiler im source code, der public domain ist. Er wäre das ideale Tool zur Verwaltung des eigenen Source Codes und könnte leicht angepasst werden.

Jedes grössere Projekt braucht eine explizite Memory Management Policy. Sie muss klar dokumentiert sein.

Wenig brauchbar sind Kommentare in Methoden von der Art: Client muss delete sagen bzw. darf nicht delete sagen etc. Ein solches Vorgehen zwingt den Klient immer genau zur Betrachtung der Interna verwendeter Klassen.

Besser ist eine einheitliche Policy unter Einsatz von Reference Counting und Smart Pointern (die enge Kopplung der beiden Techniken ist nicht vermeidbar, siehe Exceptions). Z.B. kann folgende Regel gelten: Wenn der Empfänger parameter einer Methode über die Laufzeit der Methode hinweg festhält, muss der Reference Count erhöht werden. Return Werte von Funktionen sind dagegen immer bereits um eins erhöht worden.

Dieses Vorgehen ist generell nicht schlecht (z.B. auch bei Corba eingesetzt), jedoch auch nicht der Weisheit letzter Schluss.

Mehrere Probleme entstehen:

Clients vergessen die Freigabe von Ressourcen und es entstehen Memory Leaks. Dem kann durch den konsequenten Einsatz von automatisch generierten Smart Pointern entgegengewirkt werden.

Objekte anderer Bibliotheken die nicht über dieses Ref Counting verfügen müssen anders behandelt werden. Gerade dabei entstehen subtile Memory leaks (allocated mit new und array operator, freigegeben ohne und umgekehrt)

Hier hilft der Einsatz z.B. von Purify. Durch Instrumentierung der Binaries gelingt es Purify Memory Allocation Fehler sogar in Systembibliotheken zu finden. Es hat sich beim Polytool Framework als Unschätzbar erwiesen.

Entgegen dem reinen Verlassen auf Konvention bringt reference counting zweifellos mehr Sicherheit. Das grösste Problem damit tritt jedoch bei komplexen Datenstrukturen wie Trees und DAGs auf, die jedoch meist gerade den Kern komplexer Frameworks darstellen, da sie beim composite object Pattern entstehen. Reference Counting verschlechtert die Performance bei Tree Traversal enorm (20-30%) und zwingt teilweise zu obskuren Techniken wie z.B. dass das Root Objekte eines DAGs im Konstruktor seinen eigenen Ref Count erhöhen muss, damit das Freigeben seiner Kinder funktionieren kann. Diese dekrementieren nämlich ihrerseits den Refcount des Root objects und wenn das letzte Child dies getan hat, kehrt der Flow of Control zum Root Object zurück. Nur dass dieses mittlerweile ref count gleich Null hatte und bereits freigegeben wurde. Generell treten mit Reference Counting Probleme mit zirkulären Datenstrukturen auf.

Zu Garbage Collection Techniken: [WILSON], speziell C++:[JELLIS]

Letztlich hilft bei komplexen Datenstrukturen nur ein Garbage Collector, der es bezüglich der Performance durchaus mit Reference Counting aufnehmen kann.(Siehe: Memory Allocation Costs in Large C and C++ Programs, [ZORN]. Beim Reto Team ist ein kommerzielles Produkt für C++ erfolgreich im Einsatz.

Je mehr Denkarbeit in die Zusammensetzung von Klassennamen investiert wird, um so leichter ist die nachfolgende automatische Generierung von Paketen, DLLs und Dokumentation.

Strukturelemente sind hier:

An dieser Stelle kann nur ein kleiner Ausschnitt aus den Programmierregeln eines Frameworks erwähnt werden. Ausgewählt wurden sie im Hinblick auf ihre Konsequenzen bezüglich Source Code Änderungen und Runtime Fehlern.

Bei jedem Stück Dokumentation sind folgende Fragen zu stellen:

Ad 1)

So weit wie irgend möglich sollte Dokumentation automatisch erzeugt werden. Dazu müssen extra Tags sowie strenge Konventionen der Source Code Struktur eingeführt werden.

Ad 2)

Jede Trennung erzeugt ein Wartungsproblem. Das Argument, dass extra Dokumentation übersichtlicher als Source Code Studium ist, gilt keinesfalls, da Tools beliebige Sichtweisen auf Source Code erzeugen können.

Ad 3) Vom Source getrennte Dokumente sowie Meta- Dokumente zeigen an, dass sich ein Sachverhalt nicht programmatisch ausdrücken lässt und mithin einen Mangel in der Informatik. In vielen Fällen liegt jedoch einfach eine verkehrte Sicht des Verhältnisses von Tools und Dokumentation vor wie im Beispiel des Buildprocesses:

Es kann nicht sein, dass die Parameter die bei einer IDE eingestellt wurden um ein Projekt zu erzeugen anschliessend dokumentiert werden und jeder Entwickler muss die Parameter neu eingeben bei einem neuen Projekt. Stattdessen müssen die Parameter der Generierung an einer Stelle beschrieben werden und aus dieser Beschreibung wird ein Makefile bzw. ein Projektfile erzeugt:

Beschreibung IST Source Code