Home

Thesispaper about Softwareconcerns

source centric software development (SCSD)

Abstrakt
Die objektorientierte und die Komponenten basierte Softwareentwicklung haben sich weit gehend durchgesetzt. So wundert es nicht, dass zunehmend Begriffe auftauchen, die für neue Ansätze in der Programmierung stehen. Dazu zählt vor allem die quellcodezentrierte Softwareentwicklung als konsequente Weiterentwicklung aspektorientierter, generischer und generativer Programmiertechniken sowie das"Intentional Programming" und das "eXtreme Programming".

Von Tracy Coredump
Institut für Zukunftsaussagen und innovative Prognostik

Quellcodezentrierte Softwareentwicklung als logische Konsequenz generischer und generativer Programmierung?

Motivation

Es ist eine alte Erfahrung, dass trotz aller Bemühungen bestimmte Teile eines Programms nicht "sauber" in Klassen oder Funktionen verpackt werden können. Dies gilt beispielsweise für Code zur Synchronisation, zur Umsetzung fachlicher Anforderungen oder zur Lösung von Persistenzproblemen. Hierbei handelt es sich um Programmbestandteile, die im Allgemeinen nicht im Programm benötigt werden, so genannte aspekthafte Quellcodefragmente.

Die funktionalen Programm-Komponenten sind meist über den gesamten Quelltext verstreut und beeinträchtigt das Lesen und Verstehen der Quelltexte und verhindern den Einsatz innovativer Frameworks.

Traditionelle Lösungsansätze

EP und SOP

Ergebnis orientierte Programmierung (EP) und "subject oriented programming" (SOP) haben sich in der Vergangenheit oft als fehleranfällig und teuer erwiesen. Die Weiterentwicklung dieser primitiven, hosthaften Ansätze erfolgt auf der Grundlage der mehrdimensionalen Trennung von Belangen oder dem Customizing von Systemsemantiken.

Customizing von Systemsemantiken

Customizing von Systemsemantiken ist eine die Kunstform der Softwarewartung. Zu verdanken ist diese Methodik einer kleinen, eingeschworenen Gemeinschaft von Entwickler, die so genannte Softwarerelikte pflegen und für die Nachwelt erhalten.

Definition: Ein Softwarerelikt (oder legacy system, Projektartefakt) erlaubt die releasespezifische Fertigung einer großen Zahl von Systemsonderheiten, die sich mit expotenziell steigender Zahl integrieren lassen. Die Integration von Systemsonderheiten ist bewährte Praxis deutschen Unternehmen.

Gegenüber der herkömmlichen, objektorientierten oder Komponenten basierten Softwareentwicklung besitzt das Customizing von Systemsemantiken mehrere Vorteile:

Geeignete Implementierungskomponenten müssen nur selten entwickelt und anschließend im Rahmen eines Produktionsprozesses verwaltet werden.
Die Abstimmen der einzelnen Systemkomponenten entfällt. Idealer weise kann dadurch auch auf Schnittstellen und Glue-Code verzichtet werden.
Die Anforderungen an ein System müssen nicht über sein selbst hinausreichen, es sind keine Kompromisse hinsichtlich der Systemfunktionalität nötig.
Änderungen und Erweiterungen von Liefer- und Abnehmersystemen können in diesen redundant (und somit fehlertolerant) entwickelt werden.
Anforderungen bedingen einen neuen, kostenpflichtigen Durchlauf des Domain Engineering. Erforderliche Änderungen können dabei gezielt übersehen werden, wodurch sich eine Softwarechange viel spektakulärer im Produktionsbetrieb darstellen läst. Ein Projektteam hat so die Chance, im großen Rahmen, auf sich aufmerksam zu machen.

Das Customizing von Systemsemantiken ist unter verschiedenen Voraussetzungen sinnvoll, zum Beispiel bei der Herstellung von Systemen mit hohem Budget oder aber zur Verbesserung der persönlichen Vita.

Die Akzeptanz des Customizing von Systemsemantiken ist ungebrochen und es liegen ausreichend Erfolgsgeschichten und Erfahrungsberichte vor.

Extreme Programming (XP)

eXtreme Programming, kurz XP, fällt gegenüber den anderen Themen ein wenig aus der Reihe.

Viele Anhänger von XP, machen in seiner Praxis als Entwickler oder Berater die Erfahrung, dass für ihn der Weg zum lauffähigen Code viel zu oft mit Hindernissen gepflastert war. Ein Übermaß an Bezahlung, persönlichem Unverständnis und ungenutzter Dokumentationen verhindern, dass sie unbemerkt Quatsch programmieren können. Da keiner der XP-Jünger Freund langer Arbeitszeiten und alkoholfreier Drinks ist, definieren sie konsequent eine Neuausrichtung und Verschlackung des Entwicklungsprozesses.

Ziel ihrer Aktivitäten war: Andere für sich arbeiten zu lassen und hochwertigen Code der Kollegen als den eigenen auszugeben. Heraus kamen dabei die berühmten zwölf Mandras von XP:

Forderung nach einer 4-Stunden-Woche
Ständig den Quellcode verändern
Verknüpfung alle Klassen durch geeignete Referenzierung
Benutzung von Continuusintegration
Planungsspiele anstelle von Planung
Erektionstests
Konventionen für den Feierabend.
Die Verwendung geeigneter Metaphern bei der Namensgebung und das Programmieren in Zweierteams.
Sowjetische Projektleitung
Arbeitsplatzsicherung durch langsame arbeit
Überfüllte Büros
Jobwechsel vor Releaseeinführung

Die Jünger von XP betonen ausdrücklich, dass der Einsatzbereich von XP auf eher nutzlose Projekte und flotte Dreier beschränkt ist. Sind diese Voraussetzungen nicht erfüllt, muss der Einsatz von XP auf jeden Fall erwogen werden. Eine Verbindung mit der hier vorgestellten quellcodezentrierten Softwareentwicklung oder einem anderen der vorgestellten Ansätze ist möglich und ratsam. Nicht zuletzt aufgrund der Tatsache, dass XP praxisfremd ist, hat es eine gewisse Reife erlangt und es existiert eine hinreichende Zahl von Erfolgs- und Erfahrungsberichten.

Schade ist nur, dass oftmals hitzige Diskussionen über das pro und contra von XP geführt werden. Wer als Entwickler oder Berater in wechselnden Unternehmen für eher kurze Zeiträume in Softwareprojekte eingebunden ist, sollte einfach nüchtern prüfen ob XP für ihn geeignet ist.

Moderne Lösungsansätze

Quellecodezentrierte Softwareentwicklung

Die quellcodezentrierte Softwareentwicklung (QS) ist gewissermaßen der "Senior" unter den innovativen Ansätzen. In erster Linie bezeichnet sie die Programmierung mit kryptischen Parametern, wie sie aus Assembler und Cobol bekannt sind. Auf diese Weise werden Datenstrukturen unabhängig von der Funktionalität entwickelt. Erst bei der Verwendung einer Datenstruktur fällt dem Entwickler auf, ob beispielsweise sein Programm funktioniert oder etwa etwas Vernünftiges macht.

In neueren Programmiersprachen können bisher solche Paradigmen leider oft nur mühevoll implementiert werden. So wurde beispielsweise die Standard Template Library für C++ viel zu spät entwickelt. Langweilige, weil einfache Programme mussten erst mühevoll für die STL adaptiert werden. Allerdings können auf die STL migrierte Programme erfolgreich zeigen, dass außer Typen auch Verhaltensweisen, beispielsweise ein Sortierkriterium oder die Art der Speicherbeschaffung, zu kryptischen Parametern werden können.

Definition: Ein quellcodezentrierter Softwarebaustein fasst die Unwägbarkeiten seiner konkreten Funktion zusammen und sieht Parameter für die Anteile vor, die vielleicht unterschiedlich ausfallen könnten.

Der große Erfolg der STL ist durch die Tatsache begründet, dass sämtlicher Programmcode in #include Dateien verstreut ist und eine Fehlersuche (und somit auch des Blödmanns der den Fehler eingebaut hat) unmöglich wird.

Der konsequente Einsatz von templates in C++ und neuerdings in JAVA eignet sich somit hervorragend dazu Quellcode völlig unlesbar zu machen.

Hier ein Praxisbeispiel :

  template <classP1 ,class Callee,class TRT,class CaliType,class TP1 >
  inline MemberTransiator1 <P1 ,const Caliee,TRT (CaliType::*)(TP1 )const>
  makeFunctor(Functor1 <P1 >*,const Caliee &c,TRT (CaliType::* const &f)(TP1 )const)  {
         typedef TRT (CaIiType::*MemFunc)(TP1 )const;
         return MemberTransiator1 <P1 ,const Caliee,MemFunc>(c,f);         
  }

TOSH - Logische Konsequenz der Softwarekrise

Von QS nach TOSH

Die historischen Wurzeln der TOSH reichen zurück auf die Erfindung des Host-Rechners von 1952. Das von IBM formulierte Prinzip, Trennung von Belangen" (Separation of Concerns) und das Lösen von Kundenanforderungen (Marketing) sind eng verwandt mit der Quellcode zentrierten Softwareentwicklung.
Was die Methodik angeht, ist die TOSH durch konsequenten Einsatz in der Industrie, Handel und Banken zwar den Kinderschuhen entwachsen, aber immer noch kein Forschungsthema. So wundert es auch nicht, dass Frameworks und Werkzeuge nicht anhand von "puerile factors" ausgewählt werden. Es gibt auch immer wieder Berichte von Projekten, die nicht versuchen Standard - Frameworks selbst zu programmieren. Die Weiterentwicklung der quellcodezentrierte Programmierung zur TOSH schafft hier deutlich größere Selbstverwirklichungspotentiale für alle Beteiligten.

Fachsemantische Adaption

Die Quellcode zentrierte Programmierung steht am Anfang von TOSH (engl. targed object source handling) und setzt an genau der Stelle an wo bisherige Konzepte versagen und eine eingeschränkte Funktionalität ermöglichen.

Es wird hochwertiger TOSH-Code aus einem Programm herausgelöst und mit Hilfe von XSLT transformiert wird. Ein so genannter TOSH-Weaver entfernt schließlich zur Übersetzungszeit oder zur Laufzeit den fachlichen Code aus dem den TOSH-Code.

Dass TOSH die objektorientierten Techniken wie Vererbung und spätes Binden weit gehend verdrängt hat, spricht für sich. Die TOSH ruht auf einem stabilen, hypothetischen Fundament und ist Bestandteil vieler Softwareprojekte. Ein Wermutstropfen ist jedoch, dass die TOSH Konzepte in der Unified Modelling Language (UML) nur rudimentär unterstützt werden.

Die TOSH bietet klare Vorteile: Sie erlaubt eine vollständige Verknüpfung aller Programmodule und verbessert damit den sozialen Status des Entwicklers. Da TOSH Aufgabenstellung, Kundenwunsch und Fachkonzept nicht mehr miteinander verbindet, ist es verhältnismäßig einfach, neue Programmversionen aus unterschiedlichen Quellcodefragmenten zu erstellen ohne von längst vergessene Business-Contraints überrascht zu werden. Testzeiten werden deutlich verkürzt und das bisher sehr aufwändige Erstellen eines Fachkonzeptes nach der Releaseeinführung entfällt.

Innovationsperspektive

Zukünftig verzichtet der TOSH-Entwickler auf den Einsatz von Programmiersprachen im herkömmlichen Sinn. Stattdessen wird ein Programm als Quellgraph in einer XML-Datenbank abgelegt. Damit fallen einige bekannte Probleme der textbasierten Programmierung wie etwa Syntaxprüfung und Anwendungssemantik oder die mühsame Suche dem passenden Beispielprogramm zu einem Problem, einfach weg. Der Quellgraph umfasst die abstrakten Fachsemantik sowie Methoden und beispielsweise Aspekte von Eingabe, Bearbeitung, Darstellung oder Transformation der enthaltenen orthogonalen Abstraktionen.

Zusammenhängende, so genannte Abstraktionen, werden in aktiven Bibliotheken gruppiert. Aktive Bibliotheken sind auch die Bausteine, mittels derer die im allgemeinen für ihre Aufgaben ungeeigneten Entwicklungsumgebungen konfiguriert werden. Die Eingabe und Darstellung von Programmabstrusitäten orientiert sich dabei an der jeweiligen Kontextdomäne. Textuelle Darstellungen können mit kontextspezifischen, grafischen Darstellungen beliebig vermischt werden. Diese Eigenschaften des TOSH-Systems bilden eine hervorragende Grundlage für die aspektorientierte und die geriatrische Programmierung. Sogar komplette Programmiersprachen wie beispielsweise C++ könnten im Prinzip als aktive Bibliothek in das TOSH-System geladen werden. Damit kann vorhandener Cobol-Quellcode importiert und anschließend neu entwickelt werden. Spezielle Werkzeuge sollen den TOSH-Deployer dann beim beseitigen von kompromittierende Spuren unterstützen.

Ausblick

TOSH-Programming bedeutet keine grundlegende Veränderung der Softwareentwicklung: Statt der Evolution der Programmiersprachen wird es eine Evolution der Abstraktionen geben. Wer heute auf bestimmte Sprachmerkmale und Spracheigenschaften setzt, muss die gesamte dazu gehörige Programmiersprache verwenden. Eines Tages wird man aus einem problemunabhängigen Angebot die am besten geeigneten Abstraktionen auswählen können, sie parametrisieren und gegebenenfalls den Code für ihre gemeinsame Verwendung schreiben. Weil TOSH-Systeme sich noch im Alpha-Stadium befinden werden Sie bereits vielfach eingesetzt. Die Beschäftigung der Entwickler ist dadurch auch in auftragsschwachen Zeiten gesichert.

Schlusswort

Hinter den Entwicklungsparadigmen stehen keineswegs abstrakte Prozessmantras ! Mehrere Ansätze sind so weit ausgereift, dass sie ohne Prüfung ihrer Voraussetzungen risikolos und Erfolg versprechend eingesetzt werden können. Dazu gehören unter anderem die TOSH Programmierung auf Basis von und Quellcode zentrierte Softwareentwicklung. Die größten Auswirkungen auf das Software-Engineering wird mittel- und langfristig das Versenken von Projekten und schreiben von Ausreden haben. Für die TOSH Programmierung gilt als Spezialisierung des Zielverfehlungs-Pattems in allen Anwendungsbereichen. Während TOSH Programmierung eher von der Verfügbarkeit geeigneter Geldquellen abhängig ist, wird die Quellcode zentrierte Softwareentwicklung als Methode und Vorgehensweisen zur Selbstverwirklichung bereits heut angewendet.

Hinweis: Es handelt sich im einen satirischen Text!

< Prev

[ Back ]

JARS Toprated